皆さま、こんにちは。ソニー・ミュージックエンタテインメントのかなめです。
私は普段、社内の業務システム開発のプロジェクトマネジメントや運用保守業務を行っています。この記事では数ある業務システムの中からデータ連携に特化したシステム「クロスロード」について紹介します。
データ連携が社内で注目されるようになった背景からシステム開発時に苦労したこと、今も抱えている課題と今後の展望についてお話したいと思います。
ソニーミュージックグループが置かれていた状況
昨今、エンタメ業界はSNSやサブスクリプションの活用など、世の中の変化に対応しながら急速にビジネスの領域を拡大しています。もちろん、ソニーミュージックグループも例外ではなく、ビジネスの領域や取り扱う情報の規模の拡大に比例して構築するシステム数も増加の一途をたどっています。
こうした急速なデジタル化の結果、CD売上データや音楽配信実績などの楽曲に関するデータや、どんな人がどこでこの曲を聴いているのかといった楽曲に伴うユーザーの行動データなど、取得するタイミングや形式も違うさまざまなデータをシステムで取り扱う必要が出てきました。そのため、データベースのアーキテクチャーもさまざまな形を取らざるを得ず、システム間のデータ連携の方法も多様になる傾向があり、頭を悩ませていました。
システムのクラウド化の促進
そもそも、なぜデータ連携の必要性が高まったのか。背景として、クラウド環境へのシステムの移行・構築プロジェクトの推進が挙げられます。
私たち情報システム部門では、従来のオンプレミスで構築・運用しているシステムをクラウド環境へ移すことを「LIFT」、現行のシステムを単に移行するのではなく新たにクラウド環境にシステムを構築することを「SHIFT」と呼んでいます。このLIFT＆SHIFTプロジェクトを進める際に課題となったのがデータ連携です。
ソニーミュージックの業務システムは、アーティストやアニメ作品を軸にして360度で展開しているさまざまなビジネスを密に連携させる必要があり、１つのシステムから他のシステムへデータ連携行うことが頻繁にあります。これまでは、各システムが１対１でデータを連携していることが多かったため、管理が複雑化し、それを運用するための人的なコストも高くなっている状況でした。
また、LIFT＆SHIFTプロジェクトを進めるうえで、移行期間中の対応としてオンプレミスとクラウド間のデータ連携が必要になり、各システムで都度データ連携のアーキテクチャーを検討・構築する必要がありました。
当時を振り返るとなかなかに苦労した状況だったと思います。
こうした課題を抱えてプロジェクトを進めていく中で、段々と各アプリケーションでデータ連携を考えるのではなく、“データ連携の一元管理と運用管理コストの最適化を実現するためのハブとなるシステムを構築する”という案が出てきたというわけです。
データ連携基盤の構想
このような経緯を経て、データ連携基盤「クロスロード」の構想が始まりました。ただ、前述した通り、システム数の増加に伴いデータベースのアーキテクチャーがさまざまあることや、全てのデータベースに対応した連携システムにしないといけないなど、解決するべき課題はいくつもありました。
そこでまずは、“基盤”としてさまざまなシステムに利用してもらえるように、あえて機能を最小限に抑え、だれもが汎用的に使用できるシステムとして、データ連携にフォーカスしたシステムとして構築することにしました。
また、システム間で連携されるデータはさまざまなシステムで利用されているデータでありビジネスの根幹となるデータとります。そのため、データをきちんと管理したい、という理由から既存のデータベースをブラックボックス化したまま、システムから他のシステムへ丸ごと同期・コピーさせることを選択肢から除外しました。
すでにAWSではAWSデータレイク「Andes」としてアーキテクチャや設計方針が出ており、本家の後を追うのがベストプラクティスではないか、ということでAWSのサポートも受けながら、一1からAWSを利用した構築を進めることにしました。
※AWS re:Invent2020セッションより（Amazon.comのAWSデータレイク「Andes」のアーキテクチャと設計方針）：https://dev.classmethod.jp/articles/reinvent-2020-ant311-summary-jp/
クロスロード誕生
今回構築したシステムは、データが行き交う交差点ということで「クロスロード」と名前を付けました。
英語表記にすると「XrosLoads」。頭文字を「X」にすることでデータの連携を連想させ、あえて「Loads」にすることでデータ量の負荷に耐えられることをイメージさせるようなシステム名にしました。
自分たちでシステムの名前を決めたり、ロゴを作成したりするのもシステム開発の楽しみのひとつです。ロゴなどのデザインにこだわるという点もエンタメ企業として意識したい点です。
システムとしては、ポータル画面を作成することで、容易にデータ連携定義を登録でき、一覧でデータ連携を管理することができるようにしました。 また、AWS GlueやAmazon ECSを利用することで、データベースからだけでなくファイルでのデータ連携にも対応できるようにしています。
アーキテクチャーの面でも、データの保存にAmazon S3、連携バッチにAWS LambdaとAmazon SQS、データ収集/配布にAWS GlueやAmazon ECSを使用し、サーバーレスでマネージドな構成を実現しました。
効果とこれからの展望
「クロスロード」により、画面での登録のみでシステム間のデータ連携が可能になったので、結果として各システム間の連携部分の開発コストを削減することができました。
また、LIFT後に発生する周辺システムとの影響確認を容易にし、人的負荷の削減にも貢献することが実績としても確認できています。
そのほかにも、データ連携の基準としてクロスロードが誕生したため、「連携」を実装する際の選択肢が絞られ、システム検討や調整にかかる時間の削減にもなっています。
データ連携基盤の存在意義は、データのスムーズな連携を実現することでビジネスの加速に貢献すること、そして、情報システム部門として管理すべきデータ連携の基盤がひとつに集約されることだと考えています。
これからもビジネスの展開を加速していくために、対応できていないAPIなどの連携方式への対応やポータルの操作性の向上など、AWSで１から開発しているからこそアジャイル的に継続した改善を実施していきたいと思います。
