Movatterモバイル変換

1Mercari JPのモノリスサービスをKubernetesに移行した話PHP Conference 2022Shin Ohno(@ganchiku)

2Engineering Manager Mercari API Team, Mercari JP   Shin Ohno

3Mercari-api チームストリームドアラインド & イネイブリングを兼ねているようなチームチームとその領域

4なぜ Kubernetes 環境に移行をしたかトピックなにを Kubernetes 環境に移行したかどうやって Kubernetes 環境に移行したかチームトポロジー的な視点02030401既存アプリケーションの問題にどう対処したか05今後、どうなっていくか06

5なぜ Kubernetes 環境に移行をしたかWHY

6なぜ Kubernetes 環境に移行をしたかCloud ならではの利点の享受● Reliability を向上させる● インフラのコスト最適化させる開発者体験を改善し、エンジニアの満足度の向上● Kubernetes, Terraform などの Platform 基盤の上に乗る● 開発環境と本番環境の差を最小にするPlatform チームが提供するMercari のマイクロサービスと同じ開発体験とするため

7なぜ Kubernetes 環境に移行をしたか移行前の開発環境移行後の開発環境開発環境の主なオーナー CI/CDチーム Mercari API チーム本番環境と開発環境の差異開発環境は、VM の Docker環境で他のサービスと相乗りしていた本番と同じくコンテナイメージを使用するようになった開発環境のセットアップ Web UI から手動で VM を起動していたGitHub PR が作られると、自動的に開発クラスターにDeploy され、起動していたログの確認開発環境のコンテナ内のログを参照DataDog に流れるようになった開発環境と本番環境の差を最小にする

8サービスの概念図（簡略版）

9実際のインフラ構成図（簡略版）移行前

10実際のインフラ構成図（簡略版）

11なにを Kubernetes 環境に移行したかWHAT

12モノリスサービスの構成見出しAPIサーバー Nginx+Apache キューを処理するWorker  Q4M with PHP ● メール送信 ● SMS送信 ● プッシュ通知送信 ● 会計処理 など ● マイクロサービス化されていないエンドポイント群  ● 購入、配送処理の一部  ● ユーザー管理の一部  など ● 配送処理のバッチ ● リマインド通知のバッチ  ● 会計の月次処理のバッチ  ● 一部ログ掃除などのバッチ  など   Cron Job

13どうやって Kubernetes 環境に移行したかHOW

14どうやって Kubernetes 環境に移行したか● Lift○ 既存のシステムをそのままクラウド環境へ移行する● Shift○ クラウドへ移行したシステムを徐々にクラウド環境に最適化するLift & Shift アプローチ

15どうやって Kubernetes 環境に移行したか● PHPの Base Container を予め用意する● アプリケーションを含んだContainer を Build & Release● 1つずつ影響度の小さいものから移行していく。Kustomize 使用影響の小さいものから少しずつ（Worker から）キューのDB は同じなので、取り合いに注意

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どうやって Kubernetes 環境に移行したかMercari API チームが先行事例を作り、ドキュメント作成後、各チームに委譲● ノウハウをドキュメント化し、各ドメインオーナーに伝え、支援するCronJob の数: 約40CronJob に関しては、先行事例を最初に作って、各ドメインオーナーが実施検索取引物流クーポン通知ユーザー価格出品ログインコメント

18チームトポロジー的な視点Team Topologies Perspective

19チームトポロジー的な視点● 初期（構想を練って、プロトタイプ化） ○ タスクフォース的に、モノリスサービスの知見を持ったメンバーがリード  ○ 先行して移行をしていたMercari USの知見を参考  ● 中期（Kubernetes 環境にリリース） ○ マイクロサービスの知見を持ったメンバーがKubernetes の設定をリード  ○ ミドルウェアの運用の知見を持ったSREにヒアリング  ● 後期（運用改善） ○ CronJobに関しては、各チームに委譲していく  ○ オブザーバビリティ改善のため、Embedded SRE と共にサービス改善を行う  ■ DataDog によるモニタリング、ログ等の組み込み  ■ 最適なCPU, Memory の設定  フェーズによってチームメンバーが入れ替わり、チームのインタラクションモードも合わせていった。

20チームトポロジー的な視点移行タスクフォース: ストリームアラインドチーム● 移行そののものをリードSRE: イネイブリングチーム● 移行で困難なことやノウハウを伝授、教育Platform: プラットフォームチーム● マイクロサービス共通基盤などを提供チームのタイプ

21チームトポロジー的な視点● タスクフォース的に、モノリスサービスの知見を持ったメンバーがリード  ● US の移行の知見のヒアリングブロッカーになりそうな場所の整理● Log の集約をどうするか● Credentials の管理をどうするか大まかなマイルストーンとスケジュール● Base となるコンテナイメージの作成● Worker, APIServer, CronJob それぞれいつまでの移行完了を目指すか初期（構想を練って、プロトタイプ化）(3ヶ月)参考: 巨大モノリスをKubernetesに移行してシングルクラスタ運用にするためにどうしたか

22チームトポロジー的な視点● マイクロサービスの知見を持ったメンバーがKubernetes の設定をリード  ● ミドルウェアの運用の知見を持ったSREにヒアリング開発期（yamlがほとんど）● Worker の Deployment 用意● GitHub PR merge でアプリケーションイメージの作成● PubSub -> Spinnaker でデプロイ中期（Kubernetes 環境にリリース）(5ヶ月)

23チームトポロジー的な視点運用改善 ● オブザーバビリティ改善のため、SRE と共にサービス改善を行う  ● DataDog によるモニタリング、ログ等の組み込みCronJob 移行 ● 移行ドキュメントやスケジュールを管理し、各チームに委譲、レビューや相談に乗る後期（運用改善）(5ヶ月)運用改善CronJob移行

24既存アプリケーションの問題にどう対処したかApplication Speciﬁc issues

25既存アプリケーションの問題にどう対処したか時間の経過と共に Worker のメモリが溜まっていく● 24時間に一度 Rollout して、Pod を入れ替える メモリリーク問題（Worker）メモリが上がってくるタイミングを想定して、CronJob のスケジューラーで RollOut

26既存アプリケーションの問題にどう対処したか処理中に落ちたりしてしまわないように、pcntl_signal 関数でシグナルを確認OnPremiss環境● 複数の Worker を Supervisord で管理Kubernetes 環境● 各Worker 毎に Deployment で管理● スケールインする際に、正しくジョブの実行が終わっていることをチェック グレースフルシャットダウン(Worker)

27既存アプリケーションの問題にどう対処したかGKE特有の問題、concurrencyPolicy: Replace でも並列稼働する可能性あり● 重複実行をしても良い設計に（冪等性）● それでも重複実行を許容できない処理においては、アプリケーションレベルで、ロック機構を用いて対応参考: https://engineering.mercari.com/blog/entry/k8s-cronjob-20200908/ CronJob 重複実行問題

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ホストの指定改善前と改善後DNSサーバーの RPSHost指定が多かったエンドポイントの Latency改善前改善後改善前改善後

30今後、どうなっていくかNext?

31今後どうなっていくか● Log 基盤の最適化○ 今までログの一部に td-agent を使用していたが、Cloud Logging へ● Trafﬁc のルートの最適化○ 今まで Gateway からの Trafﬁc を GCE の Proxy を経由していたが、直接 GKE のアプリケーションへ● Cloud Resource の最適化○ CPU, Monitor などを適宜ウォッチし、改善の余地がある場所を見つけ、改善● 柔軟なリリース○ Canary Release を採用し、より安全なリリースへの改善まだまだLift & Shift の Shift の最中

32まとめメルカリ最古のモノリスサービスをKubernetes 環境に移行● なぜ、なにを、どうやって● フェーズによってMercari-api チームだけでは解決できない問題○ SREチームとファシリテーションモード、コラボレーションモードで関わりながら遂行○ ドメインオーナーが持つべき CronJob の移行は、Mercari-api チームがファシリテートして移行他のマイクロサービスと同じ Platform の上に乗ることができた● チームが開発し、運用し、改善をすることがしやすくなった● CPU, Memory の最適化の改善を考えた運用ができるようになった

33We are hiringRobust Foundation for Speed, Mercari

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

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

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