API Gateway Authority API Service X API Service Y Google Cloud Load Balancer Service A Service B Google Kubernetes Engine Service C Web Service Z Cloud Spanner Project A Cloud Spanner Cloud Pub/Sub Project B Project GKE Project C Cloud Spanner アーキテクチャ Google Cloud Platform 3 1 2 マイクロサービス on Kubernetes レイヤーアーキテクチャ
マイクロサービスの階層構造 アプリ、加盟店等のパートナー様 全てのリクエストが を通る 共通処理とルーティング サービス クライアントからのリクエストとレスポンスの責任を持つ 裏側にある複数のマイクロサービスのアグリゲーション サービス 機能のロジックを実現する Backend Service API Gateway API Service Client
メルペイのEngineering組織 Product D Product C Product B Product A Product Engineering PM PM PM PM TL ... TL ... TL EM EM EM EM EM TL SRE Backend 1 Backend 2 iOS Frontend EM Android
マイクロサービスの運用体制 マイクロサービスでは各チームが担当マイクロサービスを運用 Google Kubernetes Engine Container A Container A Service A Cloud Spanner Project A Container A Container A Service B Cloud Spanner Project B Cloud Pub/Sub teamA teamB
QA: 品質保証のために、リリース前にさまざまな試験を行うプロセス メルペイにおけるQA ● QAのための専用環境: 本番環境に近い環境 ● 新規リリース前のサービスをデプロイしてQAを実施 Service A master Service B featureX サービスBの機能X のQAをしたい 開発における課題2 マイクロサービスのQAが難しい
課題: 複数の機能を同時にQAできない ● ServiceBで同時期に大きな機能を開発・QAを実施したい ● ServiceA→ServiceBの向き先を動的に切り替えられない ● 時間を決めて、この時間は機能XのQA、という運用 Service A master Service B featureX Service B featureY サービスBの機能Xと YのQAをしたい 開発における課題2 マイクロサービスのQAが難しい
MicroservicesのQAの並列化 Headerを見てリクエストを対象のPodに投げ分ける仕組みを導入 ● Custom Controller を使ってPull Requestごとにリソースを生成 ● Istioを使ってVertualServiceでリクエストのターゲットを指定 Service A master Service B PullReq-X Service B PullReq-Y Virtual Service 開発における課題2 マイクロサービスのQAが難しい header: service-b-pr-x
運用における課題1 障害の起きた箇所の特定が難しい 複数のマイクロサービスが連動して機能を提供 ● 表に近いマイクロサービスでエラー率があがった際に、 実際は裏側のサービスが原因ということがよくある ● 多くのサービスが依存するサービスで問題が起きると、 さまざまな箇所でエラーが増える ● インフラの問題で複数サービスに影響が出ることもある Service A Service B Service C LB
さまざまなところで問題が起きる ➔ マイクロサービスのSLOが、お客さまから見たときの信頼性と 一致していない SLOが正しく運用できていない ➔ 最初にSLO定義しただけのチームもある 運用における課題2 サービス全体の信頼性の実現が難しい Service A Service B Service C LB