61
音楽配信プラットフォーム AWS Snowball利用したデータ移行 AWS Summit Tokyo 2017 2017.5.31 株式会社レーベルゲート

と AWS Snowball 利用 データ移行 - d1.awsstatic.com · 音楽配信プラットフォーム と AWS Snowballを利用したデータ移行 AWS Summit Tokyo 2017 2017.5.31 株式会社レーベルゲート

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

音楽配信プラットフォームと

AWS Snowballを利用したデータ移行

AWS Summit Tokyo 2017

2017.5.31

株式会社レーベルゲート

2017/5/31 2

プロフィール

配信ビジネス部 ソリューション課 課長

久慈道 晃史(くじみち てるふみ)

1979年 静岡県三島市に生まれる

2002年 商社系SIer ソリューション部門

2006年 ソニー

フェリカネットワークス おサイフケータイ関連事業

2010年 ソニーミュージック

レーベルゲートにて音楽配信事業

2017/5/31 3

とは?

4月 レコード会社の共同出資により設立

世界初のレコード会社が運営する音楽配信サービスmora を開始

Androidで国内初の音楽配信サービス mora touchを開始

4月

4月

2017/5/31 4

レーベルゲートとは?

著作権侵害増加を危惧し、株式会社ソニー・ミュージックエンタテインメントが中核となり音楽業界各社出資の下、株式会社レーベルゲート設立。

Windows Media Player®対応の音楽/動画配信サービスmora winを開始10月

2005年 レコード会社各社への音楽配信への楽曲提供・プラットフォーム提供

nonDRM配信を公式サービスとして日本で最初に開始

同時にAWSの利用を開始

10月

2000年

2004年

2010年

2012年

2017/5/31 5

ビデオ- MP4

AAC最高音質- AAC-LC 320kbps

無圧縮FLAC(FLAC-uncompressed)

- FLAC 44.1kHz~192kHz|24bit

DSD- DSD 2.8MHz~11.2MHz|1bit

国内最大級規模のハイレゾ音源を保有

2017/5/31 6

http://mora.jp/special/onebitious-records/

2017/5/31 7

音楽専門配信サイト2017年3月 初

キャリア決済

レーベルゲートの音楽配信プラットフォームのご紹介

2017/5/31 8

2017/5/31 9

配信プラットフォームの概要

製品管理システム ストアシステム

配信システム

基幹システム

音楽レーベル

moraユーザ

2017/5/31 10

配信プラットフォームの概要

製品管理システム ストアシステム

配信システム

基幹システム

オーサリング処理前(製品マスター)

オーサリング処理後(配信コンテンツ)

製品管理配信情報管理

オーサリング処理

ストアサーバ AWSCloudFront

AWSCloudFront

SignedURL

試聴ダウンロード

決済サーバアカウント管理サーバ

配信制御サーバ

2

4

5

3

商品閲覧検索

音楽レーベル

FY2016FY2012

10月FY2017FY2014 FY2015

2017/5/31 11

AWS:オンプレミス システム環境推移

グループ初コンシューマーサービスへのAWS利用

サーバ購入を停止

仮想環境AWS移行

AWS完全移行

2017/5/31 12

規模の変化

800GB

800TB

200TB

2PB

2012年10月

Amazon CloudFront

2Instances

100Instances

Amazon EC2Amazon S3

10Instances

20Instances

Amazon RDS

2017年 4月

×1000 ×10 ×10 ×10

2017/5/31 13

AWSの利用を拡大する理由

セキュアで高速なダウンロードサービスの提供

毎日増加を続けるコンテンツを保存可能な信頼性の高いストレージサービス

稼働率と可用性の高さ、予測不能のアクセス数に対応可能

スモールスタートも柔軟なシステム構成変更も可能

2017/5/31 14

順調に見えたAWS移行だったが、、、

2017/5/31 15

平均ファイルサイズ 4MB → 200MB

2013年10月

ハイレゾ音源の配信を開始。

2017/5/31 16

ストレージ使用量の推移

ストレージ消費が加速

1ヶ月で10TB増加

製品マスター300TB のS3移行を決意

Snowball導入プロセスと実績

2017/5/31 17

2017/5/31 18

検討と選択

準備期間:2日DC内のネットワーク:1Gbps

契約・準備期間:30日

DC内のネットワーク:1Gbpsは変わらないため、転送量は

Snowballとの差がないと想定

インターネットへの出口:200Mbps

実測転送速度:7MB/sサービス・業務のトラフィックも共用

Snowball 専用線

転送量: 10TB/日

必要日数: 32日

転送量: 0.5TB/日

必要日数: 600日

転送量: 10TB/日

必要日数: 60日

移行データ:300TB

費用: 費用: 追加なし 費用:

インターネット回線

2017/5/31 19

Snowballを選択

・継続的ではなく、1回の移行

・ストレージの消費ペース

<選択の理由>Snowball

・短期間移行へのチャレンジ

転送量: 10TB/日

必要日数: 32日

費用: 小

2017/5/31 20

参考:Snowballの費用

Snowball

転送量: 10TB/日

必要日数: 32日

費用: 小

Job毎の利用料

追加利用料

データ転送(S3インポート)

配送費用

$250 (80TB)

$200 (50TB)

$15 /日

$0(無料)

配送場所によって異なる

※プレビュー期間時点

ex: $250×台数

<Snowballの費用>

転送期間が10日を超えた日数

2017/5/31 21

Snowballの台数

1台

80TB

移行データ

300TB 5台

Snowball

実行領域:70TB

2017/5/31 22

Snowballの利用手順

事前準備端末の準備、Snowballクライアント設定データ転送速度の見積り(Snowballコマンド)

ジョブ作成Jobの作成(AWSコンソール)1ジョブ=1ノード

運搬~受領 配送先はDCに直接(配送先=設置先、日時指定ができないため注意)

データ転送

返送 付属の返送用伝票を使用

S3インポート SnowballのデータをS3へImport

※プレビュー期間時点

2017/5/31 23

Snowballを設置した際の環境概要

AWS SnowballStorage AWS S3Bucket

clientimport

スケールアウトNAS高スループット高IOPS

1GbE

CPU Memory Network I/F

16 Core 64 GB 10 GbE

24 Core 64 GB 1 GbE

推奨

今回使用

2台

1GbE

2017/5/31 24

机上では32日で移行が完了する予定だったが、、、

2017/5/31 25

実績

事前準備 4 日

ジョブ作成 30 分

運搬~受領 2 日

データ転送 39 日

返送 2 日

S3インポート 2 日

端末の準備、Snowballクライアント設定データ転送速度の見積り(Snowballコマンド)

Jobの作成(AWSコンソール)1ジョブ=1ノード

初回受領分の日数(並行処理分は未加算)

最終返送分の日数(並行処理分は未加算)

最終返送分のインポート日数(並行処理分は未加算)

10 10 10 9 日+ + +

※14日かかった1台は平行で転送していたため未加算

Total: 49 日

2017/5/31 26

転送完了までの流れと経過日数

70TB

40TB

60TB

60TB

発送 発送転送[10日]

発送 発送転送[14日]

発送 発送転送[10日]

転送[10日] 発送

発送 発送転送[9日]

0 10 20 30 406 16 26 36 49日46事前準備

70TB

4

2017/5/31 27

参考:1台でのデータ移行時の推定日数

Total: 20 日

事前準備端末の準備、Snowballクライアント設定データ転送速度の見積り(Snowballコマンド) 4 日

ジョブ作成Jobの作成(AWSコンソール)1ジョブ=1ノード 30 分

運搬~受領 受取先はDCに直接(日時指定ができないため注意) 2 日

データ転送データ量と、ファイル数によって異なる(1GbE,転送量10TB/日程度の想定) 7~10 日

返送 付属の返送用伝票を使用 2 日

S3インポート SnowballのデータをS3へImport 2 日

2017/5/31 28

まとめ

想定よりも日数はかかったものの、他の方法よりも短期間でのデータ移行を実現

準備、転送作業などがかんたん、作業者も1人で完了した

ワンポイントの大量データ移行に非常に向いている

S3へ移行した結果、管理・運用コストの削減も実現

LINE MUSICとのシステム連携概要プロジェクト概要

2017/5/31 29

2017/5/31 30

2017/5/31 31

開発スケジュール

要件定義API設計

システム開発

LINE MUSICへの

楽曲連携開始

1月 2月 3月 4月 5月 6月12月

開発期間5ヶ月

2014年 2015年

2017/5/31 32

配信プラットフォームの概要

製品管理システム ストアシステム

配信システム

基幹システム

オーサリング処理前(製品マスター)

オーサリング処理後(配信コンテンツ)

製品管理配信情報管理

オーサリング処理

ストアサーバ AWSCloudFront

AWSCloudFront

SignedURL

試聴ダウンロード

決済サーバアカウント管理サーバ

配信制御サーバ

商品閲覧検索

音楽レーベルフロント側を変更することで対応

2017/5/31 33

LINE MUSICへの楽曲連携プラットフォーム

製品管理システム APIシステム

配信システム

オーサリング処理前(製品マスター)

オーサリング処理後(配信コンテンツ)

製品管理配信情報管理

オーサリング処理

AWSCloudFront

SignedURL

配信制御サーバ

配信情報連携カタログ管理 APIサーバ

新規開発

追加開発

音楽レーベル

ファイル送付

2017/5/31 34

2nd開発(海外音源の大量増曲)

開発期間3ヶ月

API設計

システム開発

LINE MUSICへの楽曲連携開始

さらに短い開発期間

2017/5/31 35

2nd開発後のプラットフォーム

製品管理システム APIシステム

配信システム

オーサリング処理前(製品マスター)

オーサリング処理後(配信コンテンツ)

製品管理配信情報管理

オーサリング処理

AWSCloudFront

SignedURL

ファイル送付配信制御サーバ

配信情報連携カタログ管理 APIサーバ

海外音楽レーベル

音楽レーベル

2017/5/31 36

LINE MUSICへの楽曲連携で感じたAWSのメリット

セキュアで高速なダウンロードサービスの提供

毎日増加を続けるコンテンツを保存可能な信頼性の高いストレージサービス

稼働率と可用性の高さ、予測不能のアクセス数に対応可能

スモールスタートも柔軟なシステム構成変更も可能

設計/検証期間短縮、開発後のコスト削減の効果

2017/5/31 37

レーベルゲートのAPIをご紹介

2017/5/31 38

APIのご紹介

配信情報取得API

コンテンツ取得API

試聴API

mora購入履歴取得API

PIN認証API

コンテンツ情報取得API

moraダウンロードAPI

外部サービスへ提供

他社製プレイヤーへの提供

2017/5/31 39

APIのご紹介

NePLAYER2016年8月対応

iAudioGate2016年8月対応

KaiserTone2016年10月対応

Wireless Hi-Res Player~Stellanova~2016年11月対応

各社ハイレゾアプリ、

mora対応続々…

2017/5/31 40

APIのご紹介

九州電力様との

IoTとAIを活用した家庭向けサービス

ハイレゾ配信プラットフォームを共同検討

2017年 4月

2017/5/31 41

音楽を楽しむ環境を

創り出すパートナー様求む!

[email protected]

2017/5/31 42

プロフィール

配信ビジネス部 ソリューション課 係長

松本 信也(まつもと しんや)35歳

1981年 群馬県館林市に生まれる

2005年 独立系SIer入社 インフラ部門

2013年 金融系SIer入社

プライベートクラウド基盤部門へ配属

2016年 ソニーミュジック入社レーベルゲートで音楽配信事業へ配属

マネージドサービスを駆使した環境構想

2017/5/31 43

2017/5/31 44

現在

2017/5/31 45

現在

ストアシステム

APIシステム配信システム

製品管理システム

基幹システム

基幹システムの一部

2017/5/31 46

マネージドサービスを積極的に使うワケ

短期・超短期開発

少数精鋭

コスト削減

設計時間、検討時間の削減

人依存の解消、見える化、運用コストの削減

スケーリング、運用コスト、管理コストの削減

2017/5/31 47

マネージドサービスを駆使した環境構想

Amazon EC2 AWSLambda

AmazonAurora

AmazonCloudWatchLogs

AWSCertificate Manager

AWSCloudFormation

(Amazon Linux)Amazon

S3

安い サーバレス化 WebsiteHosting

コスト削減

ファイル連携にも

高冗長化

安心

高速

ストレージ管理不要

見える化

管理からの開放

一括更新

無料の証明書

開発コスト削減

時間削減

オンプレミス環境と

AWS環境構成

2017/5/31 48

2017/5/31 49

移行時に意識したこと・していること

単純移行ではなく

マネージドサービスを活用した移行

疎結合の環境構築

AWSを利用したシステム運用、開発効率へのアプローチ

2017/5/31 50

2017/5/31 51

2017/5/31 52

メンテナンス時間ゼロへの挑戦

メンテナンス時間

定期メンテナンス:月2時間

年間24時間のサービス停止

定期メンテナンス:隔月1時間

年間6時間のサービス停止

サービス停止時間を1/4に削減

年間稼働率

99.72%年間稼働率

99.93%

DBの性能向上も加えて実現

2012年10月 2017年4月

2017/5/31 53

メンテナンス時間ゼロへの挑戦

Elastic Load Balancing

Auto Scaling Group“Blue”

Auto Scaling Group“Green”

構成イメージ Blue/Green Deployment

ダウンタイムを0とするリリース方法

最新アプリケーションをデプロイしたインスタンスを用意し、ELBに組み込み、古いインスタンスを切り離す

現在はCodeDeployもBlue/Greenに対応

2017/5/31 54

メンテナンス時間ゼロへの挑戦

メインサイト

CloudFront

サイトA サイトB

mora.jp

/

/siteA

/siteB

メインサイト サイトA サイトB

mora.jp

siteA.mora.jp

siteB.mora.jp

SEO対策目的

2017/5/31 55

メンテナンス時間ゼロへの挑戦

マルチオリジン化 メンテナンス性の確保

- メンテナンスや改修・開発がやりやすい環境

- 巨大なサーバにしない

- メンテナンス性を損ない結果としてメンテナンス時間の増長にもつながる

- パス単位でのメンテナンス

- パス単位でリソース調整もメンテナンス作業も可能

2017/5/31 56

Road to 99.99%

2017/5/31 57

クラウド化の次のステップ

マネージドサービスの利用拡大とコスト削減

2017/5/31 58

2017/5/31 59

マネージドサービスで作るサーバレスの構成

Redis(Multi-AZ)

AWSLambda

AWSLambda

API GatewayREST なインタフェース

AmazonCognito

S3 BucketWebsite Hosting

Amazon Kinesis

2017/5/31 60

IoTとシステム運用

Amazon EC2

Amazon CloudFront

Start/Stop キャッシュクリア

Amazon EC2

Amazon EC2

環境切替

2017/5/31 61

ご清聴ありがとうございました。

レーベルゲートは

AWSを積極活用していきます!