【Mercari Tech Conf 2018 レポート】メルカリのマイクロサービスプラットフォームチームの取り組みについてのセッション『Microservices Platform at Mercari』#mtc18

Microservices Platform at Mercari

• Mercari Tech Conf 2018 - Microservices Platform at Mercari

Mercariではサービスと組織の拡大に合わせてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行を進めています．Microservices Platform TeamはこのMicroservicesのためのPlatformの構築を行っています．開発者のDeveloper Productivityを最大限に高め各チームがオーナーシップを持ち独立して高速にサービス開発サイクルを回せるようなPlatformを目指しています．本セッションではMicroservices Platform Teamの取り組みを紹介します

スライド

メルカリがマイクロサービスに舵を切った理由

• 将来的に 1000 人規模のエンジニアを目指している
• 開発サイクルのスピードを上げるため

Accelerate という本に記載されているデータ

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

• パフォーマンスの低い組織
  • エンジニアが増えるとデプロイが減る
• ハイパフォーマンスな組織
  • エンジニアが増えるとデプロイが増える

=> もっともパフォーマンスの出るチーム構成, 組織構成が大事

ソフトウェアのライフサイクル

• 開発 -> テスト -> デプロイ -> 運用

モノリス

• 専門性でチームを分ける
  • 自分の携わっている分野以外の知識しか得られない状況はよくない

マイクロサービス

• モノリスと同じことをやろうとするとサービスが増えるとどこかのチームがボトルネックになってしまったりする

• アーキテクチャのみの変更だとマイクロサービスの利点が失われる
  • サービスごとにチームを構成する
  • チームでライフサイクルを回す
  • 独立して意思決定を行う
  • ボトルネックがなくなる
  • チーム内でいろんな分野の知識共有ができる

課題

• 開発者が自分でデプロイ, 運用をする必要がある
• 開発者が SWE, SET, SRE としても行動する
  • なかなか難しい

マイクロサービスプラットフォームチーム

• メルカリではマイクロサービスプラットフォームチームを作り、開発者の支援をしている
• マイクロサービスための基礎アーキテクチャを整えたりした

API Gateway

• 内製
• クライアントからの全てのリクエストが API Gateway を通る
• モノリスのサービスとは独立してマイクロサービスの開発ができる
• 段階的にモノリスからマイクロサービスへの以降をできるようにする
• Kubernetes を使用
  • インフラのオペレーションコストを減らすことができた

gRPC

• マイクロサービス間の通信に使う
• マイクロサービス間でインタフェースの統一化
• 1 つのリポジトリでプロトコルバッファを一元管理し、CI でジェネレートしている

マイクロサービスのテンプレート

• モノリスでは PHP がメイン
• マイクロサービスでは Go がメイン
• スクラッチでマイクロサービスを開発するのは大変
  • 標準のパッケージ構成
  • モニタリング, エラーレポート, ヘルスチェック
  • Dockerfile
  • CI の設定
• などをテンプレートにした

開発者のインフラへのアクセス管理

• モノリスだと SRE か否かでアクセス管理していた
• マイクロサービスだと各チームが自分たちが管理しているインフラに自由にアクセスできる必要がある
• Kubernetes で全部やる
  • サービス専用のネームスペースを切る
  • サービスのチームをそのネームスペースの管理者として設定する
• マネージドサービスを使いたいときはサービスごとに GCP のプロジェクトを作る

DevOps 文化

• 開発者がプロビジョニングしたりデプロイできたりするように

プロビジョニング

• Infrastructure as Code を開発者に浸透させる
• Terraform を使っている
• Starter Kit をリポジトリで提供
  • マイクロサービスのために最低限必要なものは全部定義してある
• プラットフォームチームで Terraform のレビューをするとマイクロサービスが増えるとボトルネックになる
  • GitHub のコードオーナーを各サービスの担当者に設定
  • Terraform が書けるようになったチームは自分たちで PR を merge できるようにした

デプロイ

• デプロイも開発者がする
• Spinnaker を使ってる
• Kubernetes v2 provider を使って Infrastructure as Code を実現
• 開発者が Kubernetes の yaml を書く
• 開発者が自分たちのデプロイをカスタマイズできるように

メルカリの今後

• いかにマイクロサービス開発者がオペレーションできるようになるか

SLI/SLO

• 全てのマイクロサービスに SLI/SLO を適用する
• 基準を割ってしまったらサービスの開発を止めて改善をする
• SLI/SLO という文化を浸透させる

カオステスティング

• わざと障害を起こす
• すぐに障害に気づけるようになる
• モニタリングなどが正常に動いていることを確認する
• 開発者に障害対応の経験をさせる

サービスメッシュ

• サービス間通信のオブザーバビリティの改善
• セキュリティの向上など

最後に

メルカリさんのマイクロサービスプラットフォームチームの取り組みについてでした。マイクロサービスに舵を切ってからマイクロサービスを開発するための基盤作りや、開発者に文化を浸透させるために色々な取り組みをされていて、とても勉強になりました。

その他の『Mercari Tech Conf 2018 レポート』記事

【Mercari Tech Conf 2018 レポート】メルペイの進める決済処理のマイクロサービス化についてのセッション『どうして僕らは決済処理をマイクロサービス化しようとしているのか』#mtc18

【Mercari Tech Conf 2018 レポート】メルカリの出品機能のモノリスからマイクロサービスへの移行についてのセッション『Listing Service: モノリスからマイクロサービスへ』#mtc18

【Mercari Tech Conf 2018 レポート】メルカリ Web の新アーキテクチャについてのセッション『Web Application as a Microservice』#mtc18