この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、中山です。
6/2(木) 13:20 〜 14:00 に実施された「10 年オンプレで運用した mixi を AWS に移行した 10 の理由」というセッションを聴講したので、そのレポートを以下に記述します。
セッション情報
株式会社ミクシィの北村さまに発表していただきました。こちらのURLより概要を引用します。
2014 年 3 月に 10 周年を迎えた mixi。なぜ 10 年以上オンプレミス環境で継続運用して きたサービスを AWS に移管することを決めたのか。サービスの成長を支えると共に大規模 化・複雑化してしまったインフラを、どのようにして AWS に移管したのか。 当時のサービ スを取り巻く社内外の環境を踏まえ、どのように移管を計画し、実行したか。そして、実際 に AWS に移管してどう変わったのかを実体験を元にご紹介します。
セッション内容
AWS移行を計画した理由
- 理由1. ハードウェアからの開放
- 理由2. 人的な運用負担の軽減
- 理由3. 新サービスでAWSをすでに使っていた
- 理由4. アプリエンジニア中心の移行・運用ができる(追記: はてブコメントでご指摘いただきました。ありがとうございました。)
- 理由5. オンプレ環境と親和性の高さ
- 理由6. 柔軟なリソース取得と仮想ネットワーク設計
- 理由7. サービスとS3との親和性の高さ
- 理由8. オンプレからの移行を助ける多彩な機能
- 理由9. AWS環境を利用した開発スピードの向上
- 理由10. コスト面への意識
オンプレonly当時の課題
- インフラの老朽化
- 物理的なHWからの開放がしたい
- それによって運用負担の軽減が期待できる
- 運用コストの増加
- AWS移行によりアプリエンジニアを中心とした運用が可能になるのでは
当時のmixiインフラ
- Internet -> proxy -> app -> db/memcached/storage
- storageは主に画像データの保存に利用
- DBサーバはmasterだけで100台
- SNSというサービス上画像データが多い
- サービスとしても画像を投稿しやすいようにサイトに動線を貼っている
移行要件
- 短期間でより多くのサーバをAWSに移行させたい
- オンプレサーバが収容されているラックを効率よく縮小させたい
- 一時的にダブルコスト(オンプレ/AWS共存)が掛かることが予想されるので効率よく縮小したい
- 影響範囲/動作を検証しながらやる
AWS移行のための作戦を考えた
- AWS Direct Connect
- オンプレNWとAWSを専用線で接続
- 専用線を利用してオンプレ側からAWSへサーバを徐々に移行させる
- ただしDBはオンプレに残している
- DBの種類/数が多すぎで今回の計画で移動させるのは難しいと判断
- また、DBをオンプレ側に残しておくとAWSからの切り戻しが楽になるため
- DNSを初期段階でRoute53に移行
- オンプレ側と同等のインスタンスをAWS側に作成
- AWS側のインスタンスからオンプレ側のDBを参照
- Route53のWeightedラウンドロビンでAWS側にトラフィックを徐々に流す
- 動作検証が完了したらオンプレ側のサーバを撤去
DBレスポンスが劣化しないように工夫した
- AWS側から専用線を経由したDBへの接続でレスポンス低下させてはいけない
- memcachedをAWSに設置
- ElastiCacheを利用
- クエリをキャッシュさせることで高速化
- APサーバはAWS/オンプレのmemcachedへ同時に書き込む
- これによってキャッシュの内容を同じにする
- 参照クエリで同じキャッシュを参照できる
- AWS/オンプレどちらでも同じレスポンスを期待できる
AWS移行計画
- サーバ構成台数が多いシステムを優先して移行
- サーバ構成は極力変更しない
- AWS移行の機会に一緒に変更しようとすると検証作業に時間がかかるので後回し
- 欲を出さずにまずはオンプレ縮小を目指す
AWS移行の実施
- 約半年で当初計画分移行完了
- サービスダウンタイムなし
- 移行作業と同時にラック整理
- 移行メンバーとは別チームが実施
- 最終的にラックは約30%まで縮小
- 現在ほとんどDBサーバが収容されている
画像データをS3に移行
- AWS移行当時はSnowballなかったのでオンプレストーレジサーバからS3に転送
- 転送時間縮小のため並列で処理
- 検証/転送で約6ヶ月掛かった
- いくつかのバケットに画像データを集約させた
- オンプレ時代はサーバの物理的な配置を意識した実装をする必要があった
- が、S3に移行後はそういったことを考慮せずにシンプルに実装可能になった
アプリケーションサーバの移行で重宝したAWS機能
- AMI
- 必要なソフトウェアをインストールさせたAMIを使いまわせる
- Route53
- Weightedラウンドロビン
- AWS側に例えば5%だけ切り替えて、負荷状況確認、動作確認するという方法に使えた
- 大規模なトラフィックを持つプロキシサーバでもほぼ期待通りにトラフィック制御できた
最終的な状態
- memcachedのクラスタもAWSに完全に移行
- DBサーバ以外AWSに移行している
- EMRとかCloudFrontも使っている
AWSに移行してどう変わったか
- インフラの老朽化/人的な運用負担の軽減という当初の課題は解決
- アプリケーションエンジニア主体の運用という体制が整った
移行後インフラエンジニアが取り組んでいる課題
- AWSのマネージドサービスを取り入れたよりクラウドネイティブな構成の検証
- AutoScalingを利用してコストカット
- DBのAWS移行
- Aurora検討中
コスト面への意識
- AWSはコスト計算が難しい
- そのためコストを意識した実装を考えるようになった
- コストの見える化に取り組んでいる
- 料金情報をEMRに入れて細かく計算するということもやっている
- サービス品質を維持したままコスト下げることでモチベーションが上がる
最後にお金の話
- AWS移行後インフラコストは増えた
- 一方で単純にお金だけでは計算出来ない面でコスト削減できている
- 開発コスト削減
- アプリエンジニア中心の運用
- お金という意味でのコスト以上のメリットを感じている
まとめ
以上mixiさまの講演をレポートしました。
弊社でも多くのAWS移行案件を取り扱っているため、大変参考になる講演でした。特に、お金という意味でのインフラコストは増えたがそれ以上のメリット、人的コスト/開発コストなどの削減ができた、という点をどう評価するのかがAWS移行のキーポイントになってくるのではと感じております。
5
