このページの本文へ

事例に厚みが増したAWS Summit 2017レポート

インターネットで600日かかるデータ移行がSnowballならなんと!

ハイレゾ音源を含む300TBをAWS Snowballで移行したレーベルゲート

2017年06月01日 07時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

5月30日から開催されたAWS Summit 2017の2日目。事例セッションでは音楽配信サービス「mora」を展開するレーベルゲートの久慈道晃史氏が、プレビュー中の「AWS Snowball」を使った300TBものデータ移行プロジェクトについて披露した。

覚悟を決め、迷いを捨ててAWSへの移行を推進

 2000年に設立されたレーベルゲートは、レコード会社が運営する音楽配信サービス「mora(モーラ)」を2004年から展開している。2010年には国内初のAndroid向けサービス「mora touch」、2012年からは公式にnon DRM配信をスタート。2013年10月からは非圧縮・高音質なハイレゾ音源に注力しているほか、3月には音楽配信サービスとしては初となるAmazon Payへの対応を発表した。国内初・世界初を謳う最新技術へのこだわりが同社の大きな売りと言えるだろう。

レーベルゲート 配信ビジネス部 ソリューション課 課長の久慈道晃史氏

 レーベルゲートは2012年にAWSを導入し、2014年にはサーバーの購入自体を停止。オンプレミスからAWSへの移行を加速させており、2017年中には完全移行を見込んでいる。この背景には、AWSの稼働率や可用性の高さはもちろん、予想不能なアクセス数に対応できたり、セキュアで高速なダウンロードサービスが提供できる点が大きいという。また、クラウドならではのスモールスタートや柔軟な構成変更もメリット。久慈道晃史氏は、「覚悟を決めて、迷いも捨てて、移行を推進している」とアピールする。

 現在、レーベルゲートでは楽曲データと配信情報の2つのデータを各レーベルから受領しており、それぞれ異なるフローでユーザーに配信されている。楽曲データはマスターとオーサリング処理を施した配信コンテンツがそれぞれAmazon S3に保管され、配信制御サーバーとCloudFrontを介して、視聴やダウンロード用に提供されている。一方、配信情報はAmazon RDSの製品管理データベースに登録され、ストアサーバーとCloudFrontを介してユーザーに提供される。サービスとしてメインで利用しているのはAmazon S3、CloudFront、Amazon EC2、Amazon RDSなどだが、2012年の導入から5年を経て、容量や台数は約100倍~1000倍に拡大しているという。

5年を経て、約100~1000倍に容量や台数が拡大

インターネットだと600日かかる移行作業、Snowballなら32日?

 もちろん、AWSへの移行がすべて順調にいったわけではなく、ハイレゾ音源の移行は大きな課題だった。ハイレゾ音源はファイルサイズが巨大で、平均ファイルサイズが4MBから200MBと約50倍近くに膨らんでしまう。当然、製品マスターのストレージ容量も肥大化し、1ヶ月で10TB増加するという急増ぶりでデータセンターが逼迫。増加の仕方も予想不可能だったため、製品マスターの300TBをAmazon S3に移行することに決めたという。

ハイレゾ音源はファイルサイズが巨大

 とはいえ、容量が容量なだけに移行手段が問題。試算してみると、既設のインターネット回線だと0.5TB/日なので、なんと600日もかかる計算。10TB/日の専用線の場合も、回線の調達に30日のリードタイムがかかり、30日の転送時間をあわせて60日かかってしまうという。もう少し早くできないかということで検討したのが、現在国内でプレビュー中となっているAWS Snowballだ。アプライアンスによる物理的なデータ運搬で、移行のスピードを大幅に上げられないかと考えたわけだ。

インターネット回線だと600日!専用線でも60日だが、AWS Snowballだと32日?

 とにかく短期間の移行が必要で、1回移してしまえばOKということもあり、Snowballによる移行を試算。1台で80TBのAWS Snowballを5台使うことで、32日間で移行が完了することがわかった。コスト面では80TBのジョブで250ドル、追加利用料1日15ドルがかかる。とはいえ、S3インポートのデータ転送が無料だったこともあり、AWS Snowballでの移行を決定した。

机上で32日だった移行がなぜ49日かかったのか?

 利用手順としては、端末の準備やSnowballクライアントの設定、Snowballコマンドによる転送見積もりなど一連の事前準備、そしてAWSコンソールでのジョブ作成を経て、Snowballがデータセンターに運搬されてくる。あとは実際のAWS Snowballへのデータ転送を実施し、付属の返送伝票を使ってAWS側に返送すれば、S3にインポートされる。

 机上では32日間で移行できるはずだったが、実際は49日かかった。しかし、これにはいくつかの理由がある。久慈道氏が注意すべき点としてまず指摘したのは、データ転送の見積もりだ。「今回はファイルをある程度サンプリングして試算したのですが、ファイル形式や数に依存するので多くのファイルを用いて試算すべきだった」という。

実績としては49日かかった。時間がかかったのはやはり転送部分

 時間がかかった最大の理由は、ネットワークインターフェイスが推奨の10GbEではなく、1GbEだったこと。当初はストレージから複数のAWS Snowballへ転送していたが、一方が10日間で済んでも、もう一方は14日かかった。そのため、途中から1台ずつ転送し、発送の後に別の1台に転送という形に変えたため、トータルで49日になったわけだ。そのほか4台目のSnowballがうまくつながらない、転送ステータスがなかなか「完了」に変わらないといったハプニングを経たものの、AWSJの強力なサポートもあり、データ移行作業自体は無事に終了したという。

転送完了までの流れ

 AWS Snowballへの移行を振り返った久慈道氏は、「ほかの方法より短期間でデータ移行ができ、準備や転送作業も非常に簡単だった。作業も基本的には1人だけで完了した」と評価。特にワンポイントでのデータ移行にはSnowballが向いていると太鼓判を押した。

 その後、セッションではLINE MUSICへの楽曲連携における開発期間・コストの短縮、moraのAPIを用いたハイレゾアプリ、AWSへの全面移行に向けたメンテナンス時間ゼロへの取り組みなどが披露。2017年にはAWSへの全面移行を完了させるとアピールした。

■関連サイト

カテゴリートップへ

この連載の記事

ASCII.jp特設サイト

クラウド連載/すっきりわかった仮想化技術

ピックアップ