数百台のオンプレミスのサーバーをEKSに移行した話

2025/03/27【第1回】シナマケミートアップLT会 LT登壇資料
https://synergy-marketing.connpass.com/event/348190/

Transcript

1. 数百台のオンプレミスのサーバーをEKSに移行した話 シナジーマーケティング株式会社 寺岡 佑起 1
2. 2 自己紹介 寺岡 佑起 シナジーマーケティング株式会社 プロダクト開発部 部長 兼 テックリード 2011年入社の14年目。 バックエンドとインフラ領域が少しできる。 趣味は釣り、特技はTYPO。 好きな言語 Kotlin ・ Java(愛憎相半ば) 好きなOSS SpringBoot ・ Kubernetes
3. （数百台のサーバーで構成される主力SaaS） の基盤をオンプレミスからAWSに移行したい はじまりはじまり ある日CTOに会議室に呼び出されて与えられたミッション
4. ▏ミッション オンプレミスアプリケーションをAWSに移行させる ▏スケジュール 2020年1月よりスタートし、2022年5月に完了。準備に22ヶ月、移行は8ヶ月かけて少しずつ マイグレーションプロジェクト概要 マイグレーションの設計 2020/01 2021/10 2022/01 2022/05 START 2021/07 DB移行1 DB移行2 トラフィック 移行 オンプレKubernetes移行 COMPLETE
5. マイグレーションの大方針 ▏サービスのダウンタイムの最小化 お客様にできるだけ影響を与えない ダウンタイムのない作業はスケジュール調整も容易 ▏小さく、ロールバック可能にリリース 検証された切り戻し手順を常に用意 ビッグバンリリースを避ける タスクを細かく分解し徐々に移行 ▏アプリケーションコードに極力手を入れない 移行プロジェクトは長期化する メインラインの開発と並行して実装する 必要な改修は移行前の環境にもリリース マイグレーションの設計
6. ▏LB HA構成ハードウェアLB ▏App 数百台のVM群 ▏DB 水平分割 物理でHA構成 ▏Monitoring Sensu/Grafana/Nagios ▏CI/CD Jenkins/Gitlab CI/CD マイグレーションの設計 マイグレーション前の構成 各所に秘伝のタレが詰まっている
7. マイグレーションの設計 ▏LB Network Load Balancer (NLB) NGINX Ingress Controller ▏App Deployment or StatefulSet バッチは全てCronJob ▏DB Amazon EC2 でHA構成 ▏Monitoring Prometheus / Grafana / Amazon CloudWatch ▏CI/CD GitLab CI/CD マイグレーション後の構成 全アプリをAmazon Elastic Kubernetes Service (EKS)に移行
8. ▏VMをそのまま移行させるのは難しい コスト、リスク、保守性、どの観点でもNG ▏環境構築・構成管理をシンプルに標準化したい コンテナ化で基盤を共通化 ▏コンテナ化→AWS移行を段階的に実施したい オンプレミスで構築できるKubernetesを採用 マイグレーションの設計 コンテナ化・Kubernetes の採用 移行をスムーズにすすめるためKubernetesを採用
9. なぜ踏み切れたか。 数年前にAWS上にKubernetesを構築し、 新規サービスを構築・運用してきた実績があったため。 知見ゼロからでは勝算は持てない。 マイグレーションの設計 コンテナ化・Kubernetes の採用
10. 1. オンプレ Kubernetes移行 2. AWS DB移行1 3. AWS トラフィック移行 4. AWS DB移行2 マイグレーションの戦略 マイグレーションの戦略 イテレーティブに移行するため、大きく4つのフェーズに分けて移行
11. マイグレーションの戦略 1. オンプレ Kubernetes移行 オンプレミスにKubernetesを構築 / コンテナ化した各アプリを少しずつ移行 • 基盤構築の苦労（特にネットワーク関連） • DNS安定化のためNodeLocal DNSCache導入 • アプリビルド時にDockerイメージ生成タスクを追加 • 全アプリのk8sマニフェスト作成 • アプリのGraceful Shutdown対応 など
12. マイグレーションの戦略 2. AWS DB移行1 サービス停止時間短縮、ビッグバンリリースを避けるため、DBはまず半分をAWSに移行。オンプレ-AWS間通信のため にAWS Direct Connect (DX) を敷設。ただし、App - DB間でDX通信を行うとクエリと結果が往復するたびにレイテン シの影響を受け、パフォーマンスが大きく下がる。
13. マイグレーションの戦略 2. AWS DB移行1 EKS内に、オンプレミスと同一のAppを構築。 App前段にGatewayを設置。 Gatewayは、リクエストをDBの近くにある Appに振り分けるReverseProxyとして実装。 レイテンシの影響はHTTP通信1往復だけとなる。
14. マイグレーションの戦略 3. AWS トラフィック移行 GatewayをEKSにも用意し、 DNSをNLBに切り替えることで トラフィックを徐々に移行していく。
15. マイグレーションの戦略 3. AWS トラフィック移行 過渡期には、オンプレミスとAWSにほぼ同一のアプリケーションが構築され、調整を加えながら徐々にトラフィックを 移行させていった。
16. マイグレーションの戦略 4. AWS DB移行2 全てのトラフィック移行が終わった段階で、 残り半分のDBをAWSに移行。
17. マイグレーションの戦略 その他実施したこと • メール配信基盤の移行とWarm UP • オンプレNFSのAmazon Elastic File System(Amazon EFS)への移行 • ロギング・監視・運用フローの整備 • セキュリティ/ 法務面での社内調整 • お客様との告知調整
18. ▏計画どおりに完遂 ある程度のトラブルは発生したが、トラブルが起きるのは想定通り イテレーティブに移行を進めたことで、切り戻し、リスケジュール、タスクの組み換えなど発生したイシューに柔軟に 対応できた ▏属人力があってこそ完遂できた 過渡期の複雑に変化していく構成を全員が把握するのは難しい 顧客調整、DB、メール、基盤など、主担当を一人ずつ担ってもらった ▏ AWSからの手厚いサポートが後押し 定期的なMTGでのアーキテクチャレビューや悩み相談、SAによるKubernetesの勉強会の開催など マイグレーションを終えて マイグレーションを終えて
19. ▏リソース調達が容易に キャパシティに困ったらNodeを追加するだけ ▏可搬性の向上 コンテナ化により実行環境をパッケージングし、コンテナ実行基盤があれば稼働させられる ▏環境構築速度が向上 エンジニアがKubernetesのマニフェストを書くだけで新しいアプリケーションをデプロイできる マイグレーションを終えて マイグレーションで得られたこと
20. プロジェクトマネージャーとして意識したこと 20 メンバーが この調子でプロジェクトを続ければゴールにたどり着けそう！ と思える状態を作り、維持し続ける。
21. ▏ミッション オンプレミスアプリケーションをAWSに移行させる ▏スケジュール 未定 マイグレーションプロジェクト概要 プロジェクトマネージャーとして意識したこと プロジェクトの最初は誰もがゴールへの道のりをイメージできていない段階。 エンジニアとしては技術検証や設計を始めたくなるが、 仮置きでもよいので、まずは期日を決める
22. ▏ミッション オンプレミスアプリケーションをAWSに移行させる ▏スケジュール 2020年1月よりスタートし、2022年前半に完了させる。 マイグレーションプロジェクト概要 プロジェクトマネージャーとして意識したこと いきなり、2年後のゴールに向けて頑張りましょう！ と言ったところで、誰も走り出すこと気にはなれない。 取り組めそうな間隔でマイルストーンを置いて、そこに向けて走る
23. ▏ミッション オンプレミスアプリケーションをAWSに移行させる ▏スケジュール 2020年1月よりスタートし、2022年5月に完了。準備に22ヶ月、移行は8ヶ月かけて少しずつ マイグレーションプロジェクト概要 プロジェクトマネージャーとして意識したこと 2020/01 2022/前半 START オンプレk8s構築 COMPLETE 直近はある程度精緻に、後半は不安にならない程度に大雑把に。 プロジェクトは不確定要素の塊。 マイルストーンの節目などで都度アップデートしていく オンプレk8s/EKS 平行稼働 設計・見積 技術検証 オンプレk8s稼働・EKS構築
24. プロジェクトマネージャーとして意識したこと 24 まずは自分が、 そしてメンバーが この調子でプロジェクトを続ければゴールにたどり着けそう！ と思える状態を作り、維持し続ける。