と aws snowball 利用 データ移行 - d1.awsstatic.com · 音楽配信プラットフォーム...
TRANSCRIPT
2017/5/31 2
プロフィール
配信ビジネス部 ソリューション課 課長
久慈道 晃史(くじみち てるふみ)
1979年 静岡県三島市に生まれる
2002年 商社系SIer ソリューション部門
2006年 ソニー
フェリカネットワークス おサイフケータイ関連事業
2010年 ソニーミュージック
レーベルゲートにて音楽配信事業
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 10
配信プラットフォームの概要
製品管理システム ストアシステム
配信システム
基幹システム
オーサリング処理前(製品マスター)
オーサリング処理後(配信コンテンツ)
製品管理配信情報管理
オーサリング処理
1
ストアサーバ 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 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 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 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へ移行した結果、管理・運用コストの削減も実現
2017/5/31 32
配信プラットフォームの概要
製品管理システム ストアシステム
配信システム
基幹システム
オーサリング処理前(製品マスター)
オーサリング処理後(配信コンテンツ)
製品管理配信情報管理
オーサリング処理
ストアサーバ AWSCloudFront
AWSCloudFront
SignedURL
試聴ダウンロード
決済サーバアカウント管理サーバ
配信制御サーバ
商品閲覧検索
音楽レーベルフロント側を変更することで対応
2017/5/31 33
LINE MUSICへの楽曲連携プラットフォーム
製品管理システム APIシステム
配信システム
オーサリング処理前(製品マスター)
オーサリング処理後(配信コンテンツ)
製品管理配信情報管理
オーサリング処理
AWSCloudFront
SignedURL
配信制御サーバ
配信情報連携カタログ管理 APIサーバ
新規開発
追加開発
音楽レーベル
ファイル送付
2017/5/31 35
2nd開発後のプラットフォーム
製品管理システム APIシステム
配信システム
オーサリング処理前(製品マスター)
オーサリング処理後(配信コンテンツ)
製品管理配信情報管理
オーサリング処理
AWSCloudFront
SignedURL
ファイル送付配信制御サーバ
配信情報連携カタログ管理 APIサーバ
海外音楽レーベル
音楽レーベル
2017/5/31 36
LINE MUSICへの楽曲連携で感じたAWSのメリット
セキュアで高速なダウンロードサービスの提供
毎日増加を続けるコンテンツを保存可能な信頼性の高いストレージサービス
稼働率と可用性の高さ、予測不能のアクセス数に対応可能
スモールスタートも柔軟なシステム構成変更も可能
設計/検証期間短縮、開発後のコスト削減の効果
+
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 42
プロフィール
配信ビジネス部 ソリューション課 係長
松本 信也(まつもと しんや)35歳
1981年 群馬県館林市に生まれる
2005年 独立系SIer入社 インフラ部門
2013年 金融系SIer入社
プライベートクラウド基盤部門へ配属
2016年 ソニーミュジック入社レーベルゲートで音楽配信事業へ配属
2017/5/31 46
マネージドサービスを積極的に使うワケ
短期・超短期開発
少数精鋭
コスト削減
設計時間、検討時間の削減
人依存の解消、見える化、運用コストの削減
スケーリング、運用コスト、管理コストの削減
2017/5/31 47
マネージドサービスを駆使した環境構想
Amazon EC2 AWSLambda
AmazonAurora
AmazonCloudWatchLogs
AWSCertificate Manager
AWSCloudFormation
(Amazon Linux)Amazon
S3
安い サーバレス化 WebsiteHosting
コスト削減
ファイル連携にも
高冗長化
安心
高速
ストレージ管理不要
見える化
管理からの開放
一括更新
無料の証明書
開発コスト削減
時間削減
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 59
マネージドサービスで作るサーバレスの構成
Redis(Multi-AZ)
AWSLambda
AWSLambda
API GatewayREST なインタフェース
AmazonCognito
S3 BucketWebsite Hosting
Amazon Kinesis