世の中の環境変化と将来の楽曲増加を見越して、
音楽配信プラットフォームを再構築

2002年に“着うた”、2004年に“着うたフル”の配信を開始したレコチョクは、2008年に世界で初めて携帯電話向けの高音質配信サービス“着うたフルプラス”をスタートさせた。いずれも楽曲を携帯端末にダウンロードして視聴するものだが、2013年には定額制の聴き放題サービスをリリース、ストリーミングによる楽曲提供も開始した。

同社 執行役員 兼 CTOの稲荷幹夫氏は、レコチョクの目指すサービスの方向性を次のように説明する。

「現在は基本的にダウンロードとストリーミングという形で大きくポートフォリオを切り分けていますが、今我々が注力している領域は大きく3つあります。1つめが音源の高品質化で、いわゆるハイレゾ音源の増曲です。2つめが商品ラインナップの拡充で、楽曲に加えて動画の提供数も増やしていく。そして3つめがデジタル化の付加価値促進で、1つの例が“プレイパス”というサービスで、買ったCDに付いているパスコードを入力するだけで、手元のスマートフォンですぐに楽曲を再生できる仕組みのものです。将来的には音源を軸に、さまざまサービスを掛け合わせることができるのではないかと考えています」。

しかし稲荷氏は「ただそのためには、まだまだ音源が足りない」と強調する。

「2010年当時、世の中ではガラケーからスマートフォンへのシフトが始まっており、楽曲データの構造変化やアルバム単位での楽曲提供など、ユーザのスマホ利用を前提とした楽曲データ管理システムの再構築が必要になっていました。また当時、我々が各レコード会社から提供を受けて保有していた楽曲データは約160万曲でしたが、海外では個人制作の楽曲も含めて約2000万曲があり、かつストリーミングでの提供も増えてくるだろうと予測していました。CDではなく既に“デジタルファースト”になっていたのです。日本でも数年先には当たり前になる。そのための準備をする必要がありました」。

そこでレコチョクは2010年、音楽配信プラットフォームの再構築に乗り出すことになる。

オートスケールを指向し、システム基盤としてAWSを採用

音楽配信プラットフォームの再構築に当たり、同社が求めた最大のシステム要件は、サーバキャパシティの増加にも自動で対応できるオートスケールの機能だ。

「2000万曲を目指すといっても、すぐにそれだけの数が集まるわけではありません。その際にシステム上、一番悩ましかったのは、どういうタイムスケジュールでキャパシティを増強していくかということです。過剰投資のリスクは避けたかったので、設備には極力コストをかけたくありませんでした。またハードウェアは買った瞬間から陳腐化が始まります。オンプレミスでは厳しいと思いました。そこでシステム基盤として採用したのが、クラウドサービスのAWSでした」。

同社はAWSを選択し、その上に 音楽配信用のアプリケーションを構築、2014年4月から運用を開始した。参考までに音楽配信用のアプリケーションとは、各レコード会社に楽曲を登録してもらい、それらの楽曲を管理することで、ユーザのリクエストに従って、楽曲を配信するものだ。

さらに稲荷氏はカットオーバーと同時に、再構築したAWSベースの音楽配信プラットフォームの運用監視を、外部のパートナー企業に委託することも決めていたという。

「我々はサービスの源泉となる新たなアプリケーションを開発したり、あるいは既存のアプリケーションを再定義したりしていく必要があります。システムの運用監視に24時間365日で人を張り付けることはできません。やはり餅は餅屋で、専業のサービスベンダに運用監視をお願いするのが一番効果的かつ経済的だと考えました」。

そこで同社は委託先の候補として、まず数社のサービスベンダをリストアップした。しかし当時、今ほどAWSの利用は広がっておらず、米国では障害が発生した事例もいくつか報告されていた。サービスベンダの選定には、慎重にならざるを得なかったという。

「世の中の環境変化や将来への準備を考えた時、AWSは我々にとって必要不可欠な選択でした。だから何かあっても運用でカバーしていくしかないだろうと。大きなチャレンジだったと言えます。運用監視をお願いするサービスベンダの実力が、我々の命運を握ることにもなると感じていました」。

AWSの運用ノウハウとコストの妥当性から、運用監視パートナーとしてJIG-SAWを選択

ここでAWSの運用監視の難しさについて、稲荷氏は「例えばオートスケールした後の監視」を挙げる。

「仮想サーバを立てる時には2つのポートが作られますが、1本はシステムへの接続用、もう1本は監視用で、オートスケールがかかると、監視用のポートはオートスケールそのものを監視するために取られてしまい、仮想サーバは監視対象から外れてしまいます。なのでAWSでは“上からの監視”、つまり仮想サーバのグループ全体を把握し、サーバ構成も含めて管理した上で監視する必要がある。具体的には、オートスケールした分だけをアマゾンの提供するモニタリングサービス Amazon CloudWatchで把握した上で監視する、という対応が必要になるのです。それを理解していたのは数社の候補の中でJIG-SAWだけでした。他のベンダはオートスケール後に監視用のポートが1本潰れるということさえ、知らなかったのです」

「自分たちと同じテーブルで話ができたのは、JIG-SAWだけだった」と語る稲荷氏。AWSの運用に関するJIG-SAWの豊富な経験とノウハウ・技術が高く評価された結果だ。

「JIG-SAWなら、AWSのオートスケール後の制約も含めて、どう監視すればいいかを考えてもらえるだろうと思いました」。

さらに稲荷氏は「JIG-SAWはサービスコストについても、適正だった」と続ける。

「いくらAWSを完璧に運用監視できるといっても、サービスコストが高ければ、我々の選定からは漏れていたと思います。でもJIG-SAWは、我々にとってはサービス品質に見合うコスト、つまりは適正な価格だったということです」。

JIG-SAWは重要なパートナー企業、これからも同じ目線で相談に乗ってもらいたい

レコチョクが再構築した音楽配信プラットフォームは、2014年4月の運用開始から現時点で2年以上が経過しているが、その間、特に何のトラブルも発生していないという。

「運用監視サービスについては、“特に何も問題が起きていない”という状態が一番の評価ポイントだと考えています」。

同社では現在、他の一部のサービスもAWSに移行し、Amazon　CloudWatchを使って自社で運用監視を行っているが、やはり24時間365日での監視体制を敷くことは難しい。今後はこうした部分もJIG-SAWにアウトソーシングしていくことを検討しているという。

運用監視サービスの稼働開始後には、札幌にあるJIG-SAWのオペレーションセンタ（Sapporo Control Center)にも度々足を運んだという稲荷氏。

「私は重要なパートナー企業には、今年レコチョクとして何をしようとしているのか、将来的にどんなことをしようと考えているのか、あるいは開発や運用を依頼しているシステムにインパクトを与えそうなトピックスとして、どんな出来事があるかなどを事前に伝えるようにしています。JIG-SAWは運用監視・フルマネージドの領域において、とても大切な協力パートナーだと認識しています。今後とも我々と同じ目線、同じ方向感覚で相談に乗っていただきたいと思います」