10年オンプレで運用したmixiをAWSに移行した10の理由

AWS Summit Tokyo 2016
B: Media & Entertainment Track ( 2016/06/02 )
http://aws.amazon.com/jp/summit2016-report/

Transcript

1. 株式会社ミクシィ オレンジスタジオ mixiシステム部 北村 聖児 AWS Summit Tokyo 2016 10年オンプレで運用したmixiを AWSに移行した10の理由
2. Copyright (C) mixi, Inc. All rights reserved. 2 自己紹介 ◦名前 ◦北村 聖児 ◦所属 ◦株式会社ミクシィ オレンジスタジオ mixiシステム部 ◦担当サービス ◦SNS mixi
3. ◦mixi をAWSに移行した話 ◦mixi ◦2004年3月3日にオフィシャルオープン したSNSサービス •2014年に10周年 • この間ずっとオンプレで運用 •2014年10月頃にAWSへの移行を 決める Copyright (C) mixi, Inc. All rights reserved. 3 今日話すこと
4. ◦オンプレとAWSのハイブリット構成 ◦インフラが全てAWSに移った訳ではない ◦サービス提供しているサーバのほとんどはAWSに移行済み Copyright (C) mixi, Inc. All rights reserved. 4 現状
5. AWS に移行した 10 の理由 Copyright (C) mixi, Inc. All rights reserved. 5 AWSに移行した10の理由
6. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 6 INDEX
7. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 7 INDEX
8. ◦当時の mixi のインフラ構成 ◦約1,000台の物理サーバで構成 ◦課金系ネットワークで AWS を利用していたがほぼオンプレ Copyright (C) mixi, Inc. All rights reserved. 8 mixi を取り巻いていた当時の状況 ２つの大きな課題
9. 課題. インフラの老朽化 ◦多くのサーバやネットワーク機器がリプレースの時期に ◦サポート期限切れが近づく Copyright (C) mixi, Inc. All rights reserved. 9 mixi を取り巻いていた当時の状況
10. 課題. 人的な運用負担軽減が急務 ◦モンスターストライクなどのサービスのヒット • インフラエンジニアの負担が激増 Copyright (C) mixi, Inc. All rights reserved. 10 mixi を取り巻いていた当時の状況
11. 当時の社内環境 ◦新規サービスで AWS の利用が進んでいた ◦多彩な AWS サービスを利用することにより開発速度を向上 ◦mixi のアプリエンジニアの中で「使いたい」という要望が高まる Copyright (C) mixi, Inc. All rights reserved. 11 mixi を取り巻いていた当時の状況
12. 仮に mixi を AWS に移行すると… 課題. インフラの老朽化 → AWSへの移管でインフラ刷新ができる 課題. 人的な運用負担軽減が急務 → 物理的なハードウェア管理からの開放 ◦AWSならば、アプリエンジニア中心の移行・運用が可能 Copyright (C) mixi, Inc. All rights reserved. 12 mixi を取り巻いていた当時の状況
13. ◦ mixi を取り巻いていた当時の状況 理由1. 物理的なハードウェア管理からの開放 理由2. 人的な運用負担軽減ができる 理由3. 新規サービスでAWSを利用していた社内背景 理由4. アプリエンジニア中心の移行・運用ができる ◦ AWS 移行の計画 ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 13 INDEX
14. ◦ mixi を取り巻いていた当時の状況 理由1. 物理的なハードウェア管理からの開放 理由2. 人的な運用負担軽減ができる 理由3. 新規サービスでAWSを利用していた社内背景 理由4. アプリエンジニア中心の移行・運用ができる ◦ AWS 移行の計画 ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 14 INDEX
15. ◦物理サーバ数 ◦約1,000台 ◦論理サーバ数 ◦約2,000台 ◦役割ごとに分類すると ◦100種類以上 ◦DBサーバ(Master数) ◦100種類以上 ◦画像用ストレージサーバ ◦画像100億以上 Copyright (C) mixi, Inc. All rights reserved. 15 当時の mixi のインフラ構成 Internet Application Proxy DB memcached Storage Data Center
16. ◦短期間に、より多くのサーバを AWS に移行したい ◦AWS化することで、より早く運用負担の軽減をしたい ◦オンプレのラックを効率よく縮小したい ◦サーバの種類が多いので、影響範囲・動作を検証しながら移行し たい Copyright (C) mixi, Inc. All rights reserved. 16 移行の要件
17. 方針1. AWS Direct Connect を利用した移行 Copyright (C) mixi, Inc. All rights reserved. 17 移行における３つの方針
18. ◦AWS Direct Connect ◦専用線の接続サービス ◦AWSとデータセンタなどの環境をプライベート接続できる Copyright (C) mixi, Inc. All rights reserved. 18 移行における３つの方針 AWS Direct Connect Data Center AWS cloud
19. 方針1. AWS Direct Connect を利用した移行 ◦プライベート接続することで、徐々にAWSに置き換えていく ◦一旦、データベースサーバはオンプレに残すと決める • データベースの種類が多い • アプリケーションサーバと比べると台数が少ない •AWSからオンプレへの切り戻しが楽 Copyright (C) mixi, Inc. All rights reserved. 19 移行における３つの方針
20. Internet Data Center Application Proxy DB AWS Direct Connect Amazon Route 53 (DNS) AWS cloud Proxy Application Amazon EC2 Copyright (C) mixi, Inc. All rights reserved. A A B B C C A A B B C C
21. ◦サービスのレスポンス速度への対応 ◦memcached を AWS 側にも設置 ◦サービスの特性上、memcached に格納しているキャッシュの ヒット率が高い ◦内部トラフィックも memcached への READ が圧倒的 Copyright (C) mixi, Inc. All rights reserved. 21 データベースをオンプレに残す懸念
22. Application Proxy DB memcached AWS Direct Connect Amazon ElastiCache Amazon Route 53 (DNS) Proxy Application memcached Amazon EC2 READ READ WRITE Copyright (C) mixi, Inc. All rights reserved. AWS cloud Data Center
23. 方針1. AWS Direct Connect を利用した移行 ◦プライベート接続することで、徐々にAWSに置き換えていく ◦一旦、データベースサーバはオンプレに残すと決める 方針2. サーバ構成台数が多いシステムを優先して移行していく 方針3. サーバ構成は極力変えない ◦検証コストは最小限にする Copyright (C) mixi, Inc. All rights reserved. 23 移行における３つの方針
24. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 理由5. オンプレ環境との親和性の高さ 理由6. 柔軟なリソース取得と仮想ネットワーク設計ができる ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 24 INDEX
25. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 理由5. オンプレ環境との親和性の高さ 理由6. 柔軟なリソース取得と仮想ネットワーク設計ができる ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 25 INDEX
26. 結果 ◦約半年で当初計画分の移行完了 ◦サービスのダウンタイムはなし ◦移行作業と同時にラック整理を並行して実施 ◦ラックは約30％に縮小 Copyright (C) mixi, Inc. All rights reserved. 26 AWS 移行の実施
27. ◦ストレージサーバの画像（100億以上）は Amazon S3 に転送 ◦転送用サーバをオンプレに用意し、並列転送 • 転送と検証に約6ヶ月を要した ◦複数ストレージサーバにまたがって格納されていた画像を集約 • 物理的な配置を意識していた実装を無くせる状態に Copyright (C) mixi, Inc. All rights reserved. 27 AWS 移行の実施 AWS cloud Data Center Storage Amazon S3
28. ◦アプリケーションサーバの移行で重宝したAWSの機能 ◦Amazon マシンイメージ （AMI） • サーバ構築における時間を大幅に削減 • 急激な負荷上昇に対する拡張も容易 Copyright (C) mixi, Inc. All rights reserved. 28 AWS 移行の実施 AMI ・・・・ Instances
29. ◦アプリケーションサーバの移行で重宝したAWSの機能 Copyright (C) mixi, Inc. All rights reserved. 29 AWS 移行の実施 Amazon Route 53 ◦Amazon Route 53 (DNSサービス) •weighted ラウンドロビン • ほぼ期待通りにトラフィック が制御できた • 大規模なトラフィックを持つ プロキシサーバの切替で利 用
30. Internet Data Center DB AWS Direct Connect Amazon ElastiCache Amazon Route 53 AWS cloud Proxy Application memcached Amazon EC2 Amazon S3 Image File Copyright (C) mixi, Inc. All rights reserved.
31. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 ◦ AWS 移行の実施 理由7. サービスと Amazon S3 との親和性の高さ 理由8. オンプレからの移行を助ける多彩な機能 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 31 INDEX
32. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 ◦ AWS 移行の実施 理由7. サービスと Amazon S3 との親和性の高さ 理由8. オンプレからの移行を助ける多彩な機能 ◦ AWS に移行してどう変わったのか Copyright (C) mixi, Inc. All rights reserved. 32 INDEX
33. ◦当初の課題は解決 ◦インフラの老朽化 ◦人的な運用負担軽減が急務 Copyright (C) mixi, Inc. All rights reserved. 33 AWS に移行してどう変わったのか
34. ◦移行後やっていること ◦AWSに最適な構造へのシフト • マネージドサービスへの切替 • インスタンス利用効率の向上 ◦パフォーマンスに大きく依存するデータベースのAWS移行 Copyright (C) mixi, Inc. All rights reserved. 34 AWS に移行してどう変わったのか AWS環境を利用した実装スピードの向上
35. ◦コスト面への意識の醸成 ◦コスト見える化 ◦費用対効果を強く意識したサービス設計ができるように Copyright (C) mixi, Inc. All rights reserved. 35 AWS に移行してどう変わったのか
36. Copyright (C) mixi, Inc. All rights reserved. 36 AWS に移行してどう変わったのか
37. ◦コスト面への意識の醸成 ◦コスト見える化 ◦費用対効果を強く意識したサービス設計ができるように Copyright (C) mixi, Inc. All rights reserved. 37 AWS に移行してどう変わったのか
38. ◦ mixi を取り巻いていた当時の状況 ◦ AWS 移行の計画 ◦ AWS 移行の実施 ◦ AWS に移行してどう変わったのか 理由9. AWS 環境を利用した開発スピードの向上 理由10. コスト面への意識の醸成 Copyright (C) mixi, Inc. All rights reserved. 38 INDEX
39. 理由1. 物理的なハードウェア管理からの開放 理由2. 人的な運用負担軽減ができる 理由3. 新規サービスで AWS を利用していた社内背景 理由4. アプリエンジニア中心の移行・運用ができる 理由5. オンプレ環境との親和性の高さ 理由6. 柔軟なリソース取得と仮想ネットワーク設計ができる 理由7. サービスと Amazon S3 との親和性の高さ 理由8. オンプレからの移行を助ける多彩な機能 理由9. AWS 環境を利用した開発スピードの向上 理由10. コスト面への意識の醸成 Copyright (C) mixi, Inc. All rights reserved. 39 AWS に移行した10の理由
40. 最後にお金の話 ◦結果的にはAWS移行することでインフラコストは増えた 一方で大きなコスト削減を実現できている ◦マネージドサービスによる開発スピード向上や管理コスト削減 ◦人的運用コスト削減により、アプリエンジニア中心の運用 Copyright (C) mixi, Inc. All rights reserved. 40 お金の話 AWSという環境を得られたことはコスト以上のメリット AWSをフル活用し、よりよいサービス開発、提供をしていく
41. Copyright (C) mixi, Inc. All rights reserved.