いくらクラウド化していてもオンプレミスである限り、柔軟なインフラ拡張は難しい。そこでレコチョクは決断を下す。インフラをサービスとして必要な分だけ利用するパブリッククラウドへの移行である。プロバイダーには市場シェアや機能強化の早さから「Amazon Web Services」（AWS）を選んだ。

　計画が持ち上がった2012年当時、中核となる音楽配信システムのみAWSへ移行する予定だったが、「AWSの安定化、機能充実が予想以上に進んだ」（山川氏）ことから全面移行を検討している。レコチョクの事業システムは、各配信サービスの「Webアプリケーション」、それらを支える共通の「フロント系」、決済や検索、会員などの「バックエンド系」、「配信基盤」のレイヤーからなり、約40システムに及ぶ。

図1　レコチョクがクラウド移行するシステムは40にも及ぶ。これからAWSに移行するシステム（左）と、2014年4月からAWS上で先行稼働しているシステム（右）。レコメンドシステムは新規構築となる（出典：レコチョク）

　AWSの選択にはもう1つの理由があった。システム開発の内製化だ。今までのように外部ベンダーに頼っていては、市場の変化に応じた迅速なサービス開発はおぼつかない。せっかくパブリッククラウドで柔軟なインフラが手に入るのだから、システム開発を自分たちで完結させる。そのためにも、｢エンジニアの確保、キャリアパスを考え、標準的なAWSを選ばざるを得なかった」（山川氏）。つまり、レコチョクはITの在り方、作り方を根底から変える気なのだ。

Amazon S3へ乗り換えでストレージ費用60％削減

　レコチョクは全面移行に先駆け、2014年4月から3つのシステムをAWS上で先行稼働させている。既存の配信システムと音源管理システム、そして新規構築したレコメンドシステムだ。その中でも配信システムへの移行は大量の音源データの移動を伴う大掛かりなものだった。結局、AWSへ転送した音源・画像データはファイル数で約3000万、データ容量は約800Tバイトに及んだ。

　AWS上の配信システムは、主にストレージの「Amazon Simple Storage Service」（Amazon S3）と配信サーバ用の「Amazon Elastic Compute Cloud」（Amazon EC2）で構成される。山川氏は「システム展開はオンプレミスでの月単位の構築に比べたら一瞬で用意できた」と表現する。ただし、データ転送には3カ月ほどかかった。現在はオンプレミス側とAWS側を10Gbpsの専用線で結ぶ「AWS Direct Connect」を採用しているが、当時はVPN回線（1Gbps×4）を使っており、期待したほどのスループットが出なかった。加えて、アクセスの少ない夜中しか転送作業ができなかったことが、時間のかかった理由だ。

　移行には苦労したが、配信システムをAWS上で稼働させるメリットはかなり大きい。「テレビ番組の影響でスパイクアクセスが発生しても、今までのように回線のパンクを心配しなくてもよくなった」。従来、メイン回線が過負荷になるとCDN（Contents Delivery Network）にトラフィックを振り分けるなどの対処が必要だった。また、エンタープライズ級ストレージからAmazon S3に切り替えたことで、ストレージ費用は（従来機を撤廃した時点で）60％もの削減が見込めるようになった。それで以前より高いスケーラビリティーとイレブンナインの耐久性（99.999999999％）を持つストレージが使える。もちろん性能面でも遜色ない。

　まだ最適化の余地がある。「従来アーキテクチャを踏襲したため配信サーバが介在しているが、今後はAmazon S3からの直接配信や（AWSのCDNサービス）『Amazon CloudFront』からの配信も検討している」。また、楽曲の配信状況に応じて、Amazon S3とアーカイブ用の「Amazon Glacier」を使い分けることも選択肢にあるという。

厳しいデータベース要件をどうやってクリアするか

　レコチョクのAWS移行は緒に就いたばかりだ。今後1～2年かけて全システムを移行させる。現在はシステムごとにAWS移行の実行計画を立てているところだ。ポイントはデータベースの移行である。

　AWSのデータベースサービスは各システムの要件に応じて使い分ける。NoSQL型の「Amazon DynamoDB」、RDBMS製品が使える「Amazon RDS」、データウェアハウス（DWH）の「Amazon Redshift」だ。例えば、スケーラビリティーとOLTP（オンライントランザクション処理）が求められるフロント系、会員、API（フロント系とバックエンド系の仲介役）ではAmazon DynamoDBとAmazon RDSを使用する。特にAPIはパフォーマンスが重要なのでキャッシュサーバの「Amazon ElastiCache」、検索エンジンの「Amazon CloudSearch」を間に置く。2010年から会員の購入履歴分析などで運用するオンプレミスのDWHもAmazon Redshiftに移行する計画だ。

　一方、AWSでは簡単に要件を満たせないシステムもある。山川氏は「データベースにひときわ高い性能が必要な配信基盤と可用性がシビアに問われる決済システムではまだまだ検討すべき事項が多い」と明かす。

　配信基盤のデータベースはレコード会社から送られてくる楽曲情報を格納するもので、オンプレミスではPostgreSQLでデータベースサーバを構築している。I/O性能を高めるためPCI-Express接続の半導体ストレージを使い、冗長化のオーバーヘッド下で4600TPS（1秒当たりのトランザクション処理件数）を確保する。レコチョクがAWS環境で検証したところ、Amazon RDS上でPostgreSQLインスタンスを稼働させる「RDS for PostgreSQL」でも、Amazon EC2直付けストレージ「Amazon Elastic Block Store」（Amazon EBS）のプロビジョンドIOPSタイプ（100Gバイト／3000PIOSP）を6／8本連ねると4200／4900TPSに達し、性能面では肩を並べる。

　ただ、AWSでオンプレミスと同等の可用性、負荷分散の仕組みを作るのは難しい。オンプレミスではマスターデータベースをミラーリングソフトのDRBD（Distributed Replicated Block Device）で二重化し、さらにPostgreSQL標準の複製機能によってそれぞれの参照系レプリカを自動作成している。ところが、RDS for PostgreSQLは参照系レプリカの自動作成をサポートしていない（マルチアベイラビリティゾーン《AZ》構成により異なるAZに待機系レプリカは作成可能）。そのためPostgreSQLインスタンスを別途立て、DRBDでマスター／参照系間でデータ同期、クラスタソフトで自動フェイルオーバーする仕組みを作り込む必要がある。さらに可用性を高めるため、この構成のままマルチAZ構成にするとなると、「データベース単体で見るとコストが高くなる」（山川氏）。

図2　配信基盤システム。オンプレミス同等のサービスレベルを維持するのが難しい（出典：レコチョク）

人の変革こそAWS移行を成功させる鍵

　もう1つの決済システムでもAmazon DynamoDBとRDS for PostgreSQLを使う予定だが、可用性の要件が厳しい。オンプレミスの決済システムは複数のデータベースノードで1つのストレージを共有するシェアードエブリシング方式を採用しているため、ファイブナイン（99.999％）の可用性でダウンタイムも数十秒レベルである。Amazon RDSでもマルチAZ構成で可用性は高められるが、ダウンタイムは数分レベルになってしまう。

　決済システムなので可用性要件を緩和するのは難しい。山川氏は「AWS移行にはシステムのアーキテクチャ自体をシェアードナッシング方式に変える必要があるかもしれない。それにはトランザクション制御の仕組みを変えるなどアプリ開発者の協力が不可欠だ。これまでインフラ担当はインフラ、アプリ開発者はアプリのことだけ考えていればよかったが、その垣根をなくしていかないといけない」と話す。

　国内最大級の音楽配信システムを丸ごとAWSへ移行することを考えれば、一筋縄ではいかないのは当然である。これまでのAWSのサービス強化のスピードを考えると、向こう1～2年でソリューションの選択肢は確実に増えるだろう。それでも、AWS移行に伴うシステム開発の内製化やインフラ／アプリ担当の融合など人が絡む部分は変化に時間がかかるはずだ。レコチョクの挑戦はこれからが本番だ。