Cloud migration of the essential service

Transcript

1. 止められないサービスの クラウド移行 〜 2000年創業エムスリーが挑む 大規模クラウド移行の舞台裏 〜 2020/09/23　高島 亮祐
2. 自己紹介 • 高島 亮祐（@rst76） • エムスリー 基盤開発チーム ◦ 共通サービスの開発運用 ◦ 他チーム支援 • マイブーム：メダカの飼育 ◦ 当初の 10 匹が半年で 80 匹に ◦ メダカが増える → 水槽を増やす → メダカを移す ◦ プライベートでも移行作業・・・
3. 今回クラウド移行したサービス • m3.com サイトの認証基盤 • 100 個ほどのマイクロサービス向けに認証 API を提供 • 会員情報や権限も管理している→リアルタイムで頻繁に呼ばれる • ニュース、ストア、講演会などのサービスとバッチ処理に加え て、グループ会社や顧客のサービスから呼ばれる ◦ 認証基盤の停止 ≒ m3.com サイトや顧客サービスの停止 となるため、 無停止での移行が必須
4. アーキテクチャ（旧） • 一般的な Web ３層アーキテクチャ +α オンプレミス その他の サービス ロード バランサ Web サーバ apache AP サーバ tomcat DB サーバ postgresql バッチ サーバ 監視ダッシュ ボード kibana ログ連携 サーバ fluentd
5. • 移行を機に docker 化し、 AWS のサービスを最大限に活用 オンプレミス AWS 共通 インフラ アーキテクチャ（新） AWS その他の サービス Web サーバ AP サーバ DB サーバ バッチ サーバ 監視ダッシュ ボード Transit Gateway Direct Connect ALB ECS ECS Aurora S3 CloudWatch Logs Lambda Elasticsearch Firehose
6. 移行チームの体制 • AP サーバ ・ Web サーバ： H さん（入社 3 ヶ月） • DB サーバ： S さん（入社 0 ヶ月） • サポート： 高島（入社 1 年 3 ヶ月） ◦ 今回 terraform を 1 行も書いていない エムスリー のエンジニア強い・・・
7. 移行の流れ（計画） • 難易度が低い AP サーバから段階的に移行 ◦ ① AP サーバ → ② DB サーバ → ③ Web サーバ・ロードバランサ ◦ Web サーバ移行は利用元サービスへの影響が大きい ◦ DB サーバ移行は一部の機能停止をともなう • 一時的に右図のような通信経路となる ◦ 通信量・応答時間は増えるが、安全性を優先 ◦ 通信量の見積・応答時間の検証を事前に実施 オンプレミス AWS Web サーバ AP サーバ DB サーバ ロード バランサ その他の サービス
8. 移行の流れ（実際） • オンプレのロードバランサが性能限界に達して急遽移行が必要に • ロードバランサ・ Web サーバ・ AP サーバをまとめて移行 ◦ ① ロードバランサ・Web サーバ・ AP サーバ → ② DB サーバ • 問題は発生したが、早期に解決できた ◦ Firehose によるログ連携 ◦ 一部の API 呼び出しでタイムアウト • DB サーバの移行では問題なし ◦ 段階的移行は有効 オンプレミス
 AWS
 Web
 サーバ
 AP
 サーバ
 DB サーバ その他の
 サービス

9. 移行方式（Web・AP） • あらかじめ新環境を構築し、DNS 設定変更により切り替え ◦ 利用元サービスが多いので、利用元での接続先変更は困難 ◦ ダウンタイムはない ◦ 事前に新環境の接続確認・動作検証ができる • ログ連携など +α の機能の移行方式検討に手間と時間がかかった ◦ 周辺機能は忘れられやすいので要注意 ◦ 古い仕組みの連携をどう置き換えるか ◦ CloudWatch 〜 Lambda の連携はテンプレートが用意されていたり、 実装は難しくない
10. 移行方式（DB） • 移行元の PostgreSQL が 9.1 で各種レプリケーション手法が 使えず、ダンプ&リストアが必要 • 止められない機能と止められる機能を分ける ◦ 認証 ▪ 可用性を優先して止めない ▪ データの同期が不完全であるため再ログインが発生するが、許容する ▪ リストア後に差分データを追加移行してできるだけ差分を減らす ◦ 会員情報更新 ▪ 一貫性を優先して移行中は止める
11. 発生したトラブル • 切り替え時に SSL 証明書が変わり、一部クライアントでエラー • 個別に名前解決しているクライアントが存在 • AP サーバに直接アクセスするクライアントが存在 ◦ ステージング環境のみ • DB がフェールオーバーしても AP の接続先が切り替わらない ◦ コネクションプールの設定変更が必要だった
12. クラウド移行のメリット • クラウド移行 ◦ スケールアウト・スケールインが容易に ▪ 軽い処理でアクセスが多いので、CPU を減らしてコンテナ数を増やした ▪ オートスケールは、講演会開始時などにアクセス数が急増するため保留 ◦ DB のバックアップ・リストアやマイナーバージョンアップも簡単に ▪ せっかく最新バージョンに上げたのに不具合で非推奨に・・・ • 仮想化（docker 化） ◦ 均質でイミュータブルな稼働環境の確立 ◦ トラブル時の切り戻しが容易に（タグを指定してタスクを更新） • コード化 ◦ ansible → terraform で、より統合的な管理が可能に （リソースの依存関係など）
13. まとめ • サービスごとの移行要件を明確に • 問題を分割して、できることから一つずつ • クラウド移行は正義