Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
?
0 likes?3,037 views
メルカリ社の創業時以来から存在しているモノリスサービスの Kubernetes 移行に関する話
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
- 1. 1 Mercari JPのモノリスサービスをKubernetes に移行した話 PHP Conference 2022 Shin Ohno(@ganchiku)
- 2. 2 Engineering Manager? Mercari API Team, Mercari JP? ? ? Shin Ohno?
- 3. 3 Mercari-api チーム ストリームドアラインド & イネイブリングを兼ねているようなチーム チームとその領域
- 4. 4 なぜ Kubernetes 環境に移行をしたか トピック なにを Kubernetes 環境に移行したか どうやって Kubernetes 環境に移行したか チームトポロジー的な視点 02 03 04 01 既存アプリケーションの問題にどう対処したか 05 今後、どうなっていくか 06
- 6. 6 なぜ Kubernetes 環境に移行をしたか Cloud ならではの利点の享受 ● Reliability を向上させる ● インフラのコスト最適化させる 開発者体験を改善し、エンジニアの満足度の向上 ● Kubernetes, Terraform などの Platform 基盤の上に乗る ● 開発環境と本番環境の差を最小にする Platform チームが提供するMercari のマイクロサービスと同じ開発体験とするた め
- 7. 7 なぜ Kubernetes 環境に移行をしたか 移行前の開発環境 移行後の開発環境 開発環境の主なオーナー CI/CDチーム Mercari API チーム 本番環境と開発環境の差異 開発環境は、VM の Docker 環境で他のサービスと相乗り していた 本番と同じくコンテナイメージ を使用するようになった 開発環境のセットアップ Web UI から手動で VM を起 動していた GitHub PR が作られると、自 動的に開発クラスターに Deploy され、起動していた ログの確認 開発環境のコンテナ内のログ を参照 DataDog に流れるようになっ た 開発環境と本番環境の差を最小にする
- 12. 12 モノリスサービスの構成 見出し APIサーバー? Nginx+Apache? キューを処理するWorker ? Q4M with PHP? ● メール送信? ● SMS送信? ● プッシュ通知送信? ● 会計処理? など? ● マイクロサービス化されてい ないエンドポイント群 ? ● 購入、配送処理の一部 ? ● ユーザー管理の一部 ? など? ● 配送処理のバッチ? ● リマインド通知のバッチ ? ● 会計の月次処理のバッチ ? ● 一部ログ掃除などのバッチ ? など? ? ? Cron Job?
- 14. 14 どうやって Kubernetes 環境に移行したか ● Lift ○ 既存のシステムをそのままクラウド環境へ移行する ● Shift ○ クラウドへ移行したシステムを徐々にクラウド環境に最適化する Lift & Shift アプローチ
- 15. 15 どうやって Kubernetes 環境に移行したか ● PHPの Base Container を予め用意する ● アプリケーションを含んだContainer を Build & Release ● 1つずつ影響度の小さいものから移行していく。Kustomize 使用 影響の小さいものから少しずつ（Worker から） キューのDB は 同じなので、取 り合いに注意
- 16. 16 どうやって Kubernetes 環境に移行したか Worker の移行後、API サーバーも準備し、少しずつ Traf?c を移行していく 0%-0.01% -> 0.01%-1%-5% -> 5%-25%-42%-0% -> 0%-5% -> 5%-25%-50% -> 50%-0% -> 0%-50%-0% -> 0%-10% -> 10%-25% -> 25%-0%-50% -> 50%-100% 参考: What it’s like to work as an embedded microservices SRE
- 17. 17 どうやって Kubernetes 環境に移行したか Mercari API チームが先行事例を作り、ドキュメント作成後、各チームに委譲 ● ノウハウをドキュメント化し、各ドメインオーナーに伝え、支援する CronJob の数: 約40 CronJob に関しては、先行事例を最初に作って、各ドメインオーナーが実施 検索 取引 物流 クーポン 通知 ユーザー 価格 出品 ログイン コメント
- 19. 19 チームトポロジー的な視点 ● 初期（構想を練って、プロトタイプ化）? ○ タスクフォース的に、モノリスサービスの知見を持ったメンバーがリード ? ○ 先行して移行をしていたMercari USの知見を参考 ? ● 中期（Kubernetes 環境にリリース）? ○ マイクロサービスの知見を持ったメンバーがKubernetes の設定をリード ? ○ ミドルウェアの運用の知見を持ったSREにヒアリング ? ● 後期（運用改善）? ○ CronJobに関しては、各チームに委譲していく ? ○ オブザーバビリティ改善のため、Embedded SRE と共にサービス改善を行う ? ■ DataDog によるモニタリング、ログ等の組み込み ? ■ 最適なCPU, Memory の設定 ? フェーズによってチームメンバーが入れ替わり、チームのインタラクションモードも合 わせていった。
- 20. 20 チームトポロジー的な視点 移行タスクフォース: ストリームアラインドチーム ● 移行そののものをリード SRE: イネイブリングチーム ● 移行で困難なことやノウハウを伝授、教育 Platform: プラットフォームチーム ● マイクロサービス共通基盤などを提供 チームのタイプ
- 21. 21 チームトポロジー的な視点 ● タスクフォース的に、モノリスサービスの知見を 持ったメンバーがリード ? ● US の移行の知見のヒアリング ブロッカーになりそうな場所の整理 ● Log の集約をどうするか ● Credentials の管理をどうするか 大まかなマイルストーンとスケジュール ● Base となるコンテナイメージ の作成 ● Worker, APIServer, CronJob それぞれい つまでの移行完了を目指すか 初期（構想を練って、プロトタイプ化）(3ヶ月) 参考: 巨大モノリスをKubernetesに移行してシングルクラスタ 運用にするためにどうしたか
- 22. 22 チームトポロジー的な視点 ● マイクロサービスの知見を持ったメンバーが Kubernetes の設定をリード ? ● ミドルウェアの運用の知見を持ったSREにヒア リング 開発期（yamlがほとんど） ● Worker の Deployment 用意 ● GitHub PR merge でアプリケーションイ メージの作成 ● PubSub -> Spinnaker でデプロイ 中期（Kubernetes 環境にリリース）(5ヶ月)
- 23. 23 チームトポロジー的な視点 運用改善? ● オブザーバビリティ改善のため、SRE と共に サービス改善を行う ? ● DataDog によるモニタリング、ログ等の組み 込み CronJob 移行? ● 移行ドキュメントやスケジュールを管理し、各 チームに委譲、レビューや相談に乗る 後期（運用改善）(5ヶ月) 運用改善 CronJob 移行
- 25. 25 既存アプリケーションの問題にどう対処したか 時間の経過と共に Worker のメモリが溜まっていく ● 24時間に一度 Rollout して、Pod を入れ替える ? メモリリーク問題（Worker） メモリが上がってくるタイミングを想定して、 CronJob のスケジューラーで RollOut
- 26. 26 既存アプリケーションの問題にどう対処したか 処理中に落ちたりしてしまわないように、pcntl_signal 関数でシグナルを確認 OnPremiss環境 ● 複数の Worker を Supervisord で管理 Kubernetes 環境 ● 各Worker 毎に Deployment で管理 ● スケールインする際に、正しくジョブの実行が終わっていることをチェック ? グレースフルシャットダウン(Worker)
- 27. 27 既存アプリケーションの問題にどう対処したか GKE特有の問題、concurrencyPolicy: Replace でも並列稼働する可能性あり ● 重複実行をしても良い設計に（冪等性） ● それでも重複実行を許容できない処理においては、アプリケーションレベルで、 ロック機構を用いて対応 参考: https://engineering.mercari.com/blog/entry/k8s-cronjob-20200908/ ? CronJob 重複実行問題
- 28. 28 既存アプリケーションの問題にどう対処したか Kubernetes での接続先の Host の解決での DNS の問い合わせの数が増えてし まっていた ● Trailing dotがないとき ○ ドメインの解決候補の数(5回)+ フルドメイン(1回) ○ IPv4 + IPv6 の両方で問い合わせ ■ 6回x2回の問い合わせ -> 12回 ● Trailing dotがあるとき ○ Hostに trailing dot を付けて、厳密な問い合わせをするようにした ○ 1回x2回の問い合わせ -> 2回 PHP に限った話ではないが、PHP だと顕著にパフォーマンスに影響のあったDNS 解決問題
- 29. 29 ホストの指定改善前と改善後 DNSサーバーの RPS Host指定が多かったエンド ポイントの Latency 改善前 改善後 改善前 改善後
- 31. 31 今後どうなっていくか ● Log 基盤の最適化 ○ 今までログの一部に td-agent を使用していたが、Cloud Logging へ ● Traf?c のルートの最適化 ○ 今まで Gateway からの Traf?c を GCE の Proxy を経由していたが、直接 GKE のアプリケー ションへ ● Cloud Resource の最適化 ○ CPU, Monitor などを適宜ウォッチし、改善の余地がある場所を見つけ、改善 ● 柔軟なリリース ○ Canary Release を採用し、より安全なリリースへの改善 まだまだLift & Shift の Shift の最中
- 32. 32 まとめ メルカリ最古のモノリスサービスをKubernetes 環境に移行 ● なぜ、なにを、どうやって ● フェーズによってMercari-api チームだけでは解決できない問題 ○ SREチームとファシリテーションモード 、コラボレーションモード で関わりながら遂行 ○ ドメインオーナーが持つべき CronJob の移行は、Mercari-api チームがファシリテートして移 行 他のマイクロサービスと同じ Platform の上に乗ることができた ● チームが開発し、運用し、改善をすることがしやすくなった ● CPU, Memory の最適化の改善を考えた運用ができるようになった
- 33. 33 We are hiring Robust Foundation for Speed, Mercari