Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24

Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24

• 1.
  1 Mercari JPのモノリスサービスをKubernetes に移行した話 PHP Conference2022 Shin Ohno(@ganchiku)
• 2.
  2 Engineering Manager
 Mercari APITeam, Mercari JP
 
 
 Shin Ohno

• 3.
  3 Mercari-api チーム ストリームドアラインド &イネイブリングを兼ねているようなチーム チームとその領域
• 4.
  4 なぜ Kubernetes 環境に移行をしたか トピック なにをKubernetes 環境に移行したか どうやって Kubernetes 環境に移行したか チームトポロジー的な視点 02 03 04 01 既存アプリケーションの問題にどう対処したか 05 今後、どうなっていくか 06
• 5.
  5 なぜ Kubernetes 環境に移行をしたか WHY
• 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 に流れるようになっ た 開発環境と本番環境の差を最小にする
• 8.
  8 サービスの概念図（簡略版）
• 9.
  9 実際のインフラ構成図（簡略版）移行前
• 10.
  10 実際のインフラ構成図（簡略版）
• 11.
  11 なにを Kubernetes 環境に移行したか WHAT
• 12.
  12 モノリスサービスの構成 見出し APIサーバー
 Nginx+Apache
 キューを処理するWorker 
 Q4M withPHP
 ● メール送信
 ● SMS送信
 ● プッシュ通知送信
 ● 会計処理
 など
 ● マイクロサービス化されてい ないエンドポイント群 
 ● 購入、配送処理の一部 
 ● ユーザー管理の一部 
 など
 ● 配送処理のバッチ
 ● リマインド通知のバッチ 
 ● 会計の月次処理のバッチ 
 ● 一部ログ掃除などのバッチ 
 など
 
 
 Cron Job

• 13.
  13 どうやって Kubernetes 環境に移行したか HOW
• 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 サーバーも準備し、少しずつ Traffic を移行していく 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 環境に移行したか MercariAPI チームが先行事例を作り、ドキュメント作成後、各チームに委譲 ● ノウハウをドキュメント化し、各ドメインオーナーに伝え、支援する CronJob の数: 約40 CronJob に関しては、先行事例を最初に作って、各ドメインオーナーが実施 検索 取引 物流 クーポン 通知 ユーザー 価格 出品 ログイン コメント
• 18.
  18 チームトポロジー的な視点 Team Topologies Perspective
• 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 移行
• 24.
  24 既存アプリケーションの問題にどう対処したか Application Specific issues
• 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 改善前改善後 改善前 改善後
• 30.
  30 今後、どうなっていくか Next?
• 31.
  31 今後どうなっていくか ● Log 基盤の最適化 ○今までログの一部に td-agent を使用していたが、Cloud Logging へ ● Traffic のルートの最適化 ○ 今まで Gateway からの Traffic を 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 RobustFoundation for Speed, Mercari