メルカリの Microservices Platform Team のメンバによる技術イベント Mercari Meetup for Microservices Platform #2 に参加してきました。
どの講演も非常に面白くて、参考になりました。特に @spesnova さんによるマイクロサービスとその監視の事例は、このレベルを目指して頑張りたいと思える内容でした。
今回は、個人的に興味深かった部分中心のメモです。プレゼン資料が公開されていない部分などは、多少ミスもあると思います。そこはご了承ください（訂正情報いただいたら直します）。
Introduction & Attention
（スライドは未公開。タイトルは Connpass ページに掲載のもの）
Microservices Platform Team の Engineering Manager @masartz さんによる導入。
- Mercari Microservices Platform Team の紹介
- マネージャ1名とエンジニア8名の計9名
- Mercari と Merpay 両方のサービスが乗るプラットフォームを作っている
- 新しい分野に対してチャレンジングな仕事をしている
- Observatoryといった数値を大事にして、いろいろな取り組みをしようとしている
- 自分たちで仕組みを改善していっている
- Merpay SRE の紹介
- マネージャ1名と SRE 3名の計4名
- Merpay の安定性と信頼性を支える
- Mercari はモノリスからマイクロサービスに置き換えるというチャレンジをしているが、Merpay は最初からマイクロサービスで作る、というまた別のチャレンジをしている
Kubernetes Cluster Monitoring
Microservices Platform Team の @spesnova さんによる、Kubernetes クラスタの監視についての講演。
Kubernetes クラスタの監視について非常に細かく解説されており、勉強になりました。
- Monitoring kubernetes cluster
- Microservices Platform Team はクラスタ自体の監視をする（その上のアプリ監視の話ではなくて）
- 何を持ってクラスタが正常かどうかを確認しているか？
- マイクロサービスの規模
- Kubernetes クラスタ上に、
- マイクロサービス 100+
- Pod 2K+
- コンテナ 2K+
- マイクロサービスを開発するエンジニア 200+
- 会社全体で Kubernetes クラスタは1個ではない
- Microservices Platform Team が見てないクラスタはまだたくさんある
- メルカリ全体ではコンテナ 13k くらい？
- Kubernetes クラスタ上に、
- Platform チームと developerの責任分界点（boundary）
- Pods より上は developer
- Pods より下は Platform チーム
- Kubernetes master は GKE の管理下
- Kubernetes nodes は GKE の管理下ではない。これはどこのクラウドでもそのはず
- メトリクスの設計
- RED and USE method
- これの別表現で Work and Resource という言い方があり、両方の言い方を使っている
- The Work (RED) metrics
- システムが動いているか壊れているかを教えてくれるメトリクス
- Throughput, Success, Error, Performance
- Work のほうの Error は、レスポンスのエラーレートとか
- The Resource (USE) metrics
- 内部のメトリクス。low-level healthを教えてくれる
- Utilization, Saturation, Errors, Availability
- 例：swapを使ってる＝どれくらい足りてないか＝Saturation
- Resource のほうの Errors は、バックエンドのサービスのエラーレートとか
- Kubernetes クラスタの生死をどうやって監視する？
- クラスタにとっての Work メトリクス＝orchestrating できてるかどうか
- Ready な Pod の数
- Unavailable な Pod の数
- Deployment ごとの Pods など、もっと細かい切り口でのメトリクス
- Unavailable な pod がない＝クラスタが orchestration の仕事をしている
- ただ、unavailable な pod があっても、クラスタのせいとは限らない（開発者の設定ミス、GKEの障害など）
- そのため、パーセンテージでアラートを出している。しきい値は緩めにしている
- オオカミ少年にならないように
- Master Components, Node Components, Addons の分類
- クラスタにとっての Work メトリクス＝orchestrating できてるかどうか
- 使っているツール
- Cluster-level monitoring = prometheus
- Cluster-level logging = fluentd とか
- Stackdriver と Datadog
- Work metrics の実例
- メトリクスは Datadog で可視化している。Datadog のスクリーンショットを使いながら解説
- GKE の障害は、僕らではどうしようもないので、神経質に見ない（というようなことをなにか別の表現をしていたけど忘れた）
- kubelet runtime error rate を見ている。しきい値は緩めに設定
- kube-proxy work metrics は可視化しているが、prometheusとの連携がうまくなくて？あまり使い物にならない。今後の課題
- Resource metrics の実例
- CPU, disk, memory, network など
- クラスタ単位、ノード単位のダッシュボードもある
- ダッシュボード
- SRE と application engineer の間で、監視の boundary を決める
- Work metrics と Resource metrics を意識してダッシュボードを作る（Work と Resource のダッシュボードは別）
- Kubernetes のクラスタは分散システムなので、1箇所だけ見れば良いということはなく、Work と Resource を区別していろいろなダッシュボードを作って監視する必要がある
Securing Microservices Continuous Delivery using Grafeas and Kritis
Microservices Platform Team の @vbanthia_ さんによる、CI/CD へのポリシーの強制方法についての講演。
- code > build > test > deploy といったワークフローの各段階で、ガバナンスを保ちたい
- この機能をデプロイしてよいか
- 脆弱性対応が済んでいるか（例：cpu.fail）
- ガバナンスを保つためには、従来はいろいろな CI/CD ツールを組み合わせてワークフローを実装する必要があった
- いろいろなツールを組み合わせると、各フェーズをまたぐときにメタデータが失われてしまう
- Grafeas（グラフィアス）は、中央集中型の汎用的なメタデータ管理サーバ
- オープンな artifact metadata API を通して、任意のツールからメタデータを登録できる
- Kritis はポリシーを強制するためのツール
- Platform チームでは GCP と Spinnaker を使っている
- 公式の Kritis はまだ early stage で、メルカリで必要な機能が未実装
- そのため、Kritis を fork して機能拡張したものを使っている
- QA → PM の順に承認を得て、承認を得た docker image だけが production cluster にデプロイされる
How We Structure Our Work At Mercari Microservices Platform Team
Microservices Platform Team の @deeeet さんによる講演。
Platform チームができてから2年位経つそうなのですが、そのなかでのプロジェクト管理方法の変遷についてのお話でした。
- Platform チームにおけるプロジェクトマネジメント
- 特殊なことをしているわけではない。一般的なWeb開発と変わらない
- チームとしてのアウトプットを最大化する＝開発者の生産性を最大化する＝よりよいプロダクトをMercariの顧客により早く提供する
- プロジェクトマネジメントのやり方を、チーム自身で継続的に改善している
- 歴史
- 最初は deeeet さん1人だった
- 5名までは "No project management"
- 8名までは (lightweight) Agile
- 9名になった現在は 6 Week Release Cycle を採用している。今日は主にこれを紹介する
- No project management
- 単純な四半期のマイルストーンしかなかった
- 各人が課題を見つけて取り組んでいた
- 基本的に個人プレイで、チームではなかった。個人でやりたいことやっていた
- マイルストーンにはやりたいことが詰まっていて、手元のタスクが進まなかった
- ドキュメント整備、自動化が進まなかった。開発者に対するサポート業務に時間が取られていた
- この経験からの学び：個人でできることには限界がある。チームとして動く必要がある
- (lightweight) Agile
- 2週間のスプリント、カンバン、スクラムマスター
- 採用したのは、業界のデファクトだから。プロジェクト管理を始めなきゃ、という課題意識から始めた
- 50%はプロアクティブなタスク、50%はリアクティブなタスクを取る、という取り組みを始めた（割合はGoogleを参考に）
- 良くなかった点
- ベロシティに集中してしまい、開発者に shipping しているという意識が遠のいた
- Platform チームの仕事には2週間で区切れない仕事が多かった
- 誰一人見積もりがうまくできなかった。見積もりが目的化する部分があった
- 根本的に問題があるのでは？
- アジャイルは仕様が決まることが前提で、ベロシティから作業量を予測する点が重要だと思う
- 実際は、最初は不確定なことから始まる。基盤系は特にそうではないか？
- アジャイルを極めるという選択肢もあったと思うが、自分たちは別の方向を模索し始めた
- 6 Week Release Cycle
- すでに2クォーター実施して、うまくいっている
- Basecamp 社が長い間実践している手法で、"REWORK" という本でも紹介されている
- これをメルカリ流にカスタマイズして使っている
ReWork: Change the Way You Work Forever
- 作者: David Heinemeier Hansson,Jason Fried
- 出版社/メーカー: Vermilion
- 発売日: 2010/03/18
- メディア: ペーパーバック
- 購入: 1人 クリック: 4回
- この商品を含むブログ (2件) を見る
- 6 Week Release Cycle の概要
- 1回のリリースを6週間で区切る
- この期間の長さは、だいたいどんな機能でも6週間あればリリースできる、というBasecampの経験則から
- この期間にリリースする 1個の bic epic と、2〜3個程度の small epic を決める
- 6週間すべて使うのが big epic
- 1日〜2週間使うものが small epic
- Big epic に 1 release team、small epic に 1 release team をアサインする
- 1チームは2〜3名
- 2つの原則
- Dedicated resource allocation
- Release team には与えられたエピックだけに集中してもらう
- Fixed budget and flexible scope
- 6 week + 2-3 membersというのは変えない
- スコープは変えていい
- Dedicated resource allocation
- 1回のリリースを6週間で区切る
- メルカリで追加した3番目の原則
- Dedicated On Support Team
- 開発者からのリクエストと、緊急の要件に対応するための、3番目の release team を作る
- 時間があるときは技術的負債に対応する
- Dedicated On Support Team
- ローテーション方法
- 試行錯誤した結果、9名を3チームに分けて、release team (big epic)、release team (small epic)、support team をローテーションする方法に落ち着いた
- daily や weekly のローテーションでは、release team にとっては開発期間として短く、support team にとっても開発者からのリクエストが完了しきらなかった
Merpay Microservices On Microservice Platform
メルペイ社にて Engineering Manager も担当している @tjun さんによる講演。メルペイ社のマイクロサービスの特徴と、その運用に関するお話でした。
メルペイ社のシステムは、メルカリのマイクロサービスとは傾向が違う部分が多少あるものの、共通の基盤に乗っているそうです。そのため、microservices-starter-kit や Datadog などの話は、メルカリにも共通する話、とのことでした。
- メルペイのマイクロサービス
- メルペイだけで40個以上のマイクロサービス
- メルペイのマイクロサービスの特徴（世間一般、および Mercari との違い）
- バッチ処理が多い（k8s上でバッチ処理をしている）
- 外部パートナー（銀行など）との接続が多い
- 開発者に対する権限を絞っている（セキュリティ、コンプラの関係上）
- microservices-starter-kit
- 新しくマイクロサービスを作るときは、Platform チームが作っている microserivces-starter-kit というものを使ってスタートする
- サービス名やオーナー、開発者を定義して実行すると、GCP から Kubernetes まで、必要なリソースとその権限設定が自動的に作られる
- Datadog のダッシュボードや PagerDuty のローテーションの設定まで、デフォルトのものが自動的に作られる（懇親会で聞いた話）
- SLO and Alerts
- 各開発チームに SLO を定義してもらっている
- SLO は PM も参加して決めてもらう、などのルールを決めている
- それぞれの SLO について Datadog monitor を設定している - RED metrics
- Datadog で、各チームに SLOboard というものを作ってもらおうとしている
- Datadog APM and Distributed Tracing with Go middlewares
- 新しい開発者でもどこが遅くなっているか、などを見やすくしている
- Incident handling
- Datadog と Sentry でのアラートを、Slack や PagerDuty に送っている
- 開発者が一次受けをしたあとで、アプリだけの問題ではない場合は SRE も一緒に問題を見る
- 再発防止のため、インシデントのたびにインシデントレポートを作成する
- メルペイの SRE の責任範囲
- アプリケーションをまたがるインフラリソース
- Ingress, CDN, キャパシティプランニング、セキュリティ
- Production releases and operations
- マイクロサービスの知見がないエンジニアも多いので、そこのサポート
- アプリケーションをまたがるインフラリソース
感想
プレゼンのあとで、1時間近く懇親会の時間があり、細かい話を直接伺うことができたのはとても良かったです。
講演と、懇親会での話を合わせて、僕自身は Platform チームについて次のように理解しました。
- Platform チームが見ている Kubernetes クラスタに関しては、かなりの部分がセルフサービス化されている（開発者だけでできるようになっている）
- セルフサービス化のために、今回の講演で出てきた話（microservices-starter-kit のような自動化、Grafias/Kritis を使ったポリシー管理、開発者自身による監視の一次受け）を組み合わせている上に、ドキュメントの整備なども進めている
- セルフサービス化が進んだことで、SRE がインフラ関係のコアな業務に集中できる状態になり、結果として Platform チームは9名という少人数で回っている
もちろん、現場ではいろいろ泥臭くて大変なことも多いとは思いますが、マイクロサービス化を推し進めた先の目指すべき理想形のイメージをつかめたような気がします。また同様のイベントがあったら是非参加してみたいです。
追記(2019-05-31)
Mercari Engineer Blog のなかで spesnova さんの資料も公開されていたので、リンク追加しました。
