無印吉澤

Site Reliability Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

Mercari Meetup for Microservices Platform #2 参加レポート

f:id:muziyoshiz:20190527230059p:plain

メルカリの Microservices Platform Team のメンバによる技術イベント Mercari Meetup for Microservices Platform #2 に参加してきました。

connpass.com

どの講演も非常に面白くて、参考になりました。特に @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 くらい?
  • 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 の分類
  • 使っているツール
    • 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週間で区切れない仕事が多かった
      • 誰一人見積もりがうまくできなかった。見積もりが目的化する部分があった
    • 根本的に問題があるのでは?
      • アジャイルは仕様が決まることが前提で、ベロシティから作業量を予測する点が重要だと思う
      • 実際は、最初は不確定なことから始まる。基盤系は特にそうではないか?
    • アジャイルを極めるという選択肢もあったと思うが、自分たちは別の方向を模索し始めた

f:id:muziyoshiz:20190527230529p:plain
スライド中で出てきて面白かった図。不確定なうちは規模感がわからない

ReWork: Change the Way You Work Forever

ReWork: Change the Way You Work Forever

  • 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というのは変えない
        • スコープは変えていい

f:id:muziyoshiz:20190527231011p:plain
6 Week Release Cycle

  • メルカリで追加した3番目の原則
    • Dedicated On Support Team
      • 開発者からのリクエストと、緊急の要件に対応するための、3番目の release 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 さんの資料も公開されていたので、リンク追加しました。

tech.mercari.com