無印吉澤

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

SRE Lounge のスピンオフで、議論中心の新しい勉強会 "SRE Session" への誘い

f:id:muziyoshiz:20180927232609p:plain

SRE Session とは?

SRE Lounge のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。

sre-lounge.connpass.com

SRE Session は少人数かつ全員参加型で議論するタイプの勉強会です。当日は議論が盛り上がり、参加者の反応も良かったので、おそらく SRE Session #2 が6月頃に開催されそうです。そこで、だいぶ遅れましたけど(3週間近く経ってる……)軽く感想をメモしておきます。

SRE Lounge には何度か参加していて、SRE Session にもちょっと興味あるけど参加しようかどうしようか……という方の参考になればと思います。

イベントレポート

SRE Session #1 の内容については、すでに充実したレポートが書かれているので、こちらを読んでもらえると大体の雰囲気がわかると思います。

blog.chaspy.me

SRE Session の発起人 @chaspy_ さんのレポート。Session #1 の会場は Quipper Ltd. さまに提供いただいたのですが、こちらも chaspy さんにお世話いただきました。感謝しかない……。

qrunch.net

いつも SRE Lounge でお世話になっているスタッフの ktykogm (k-oguma) さんのレポート。Welcome talk の内容から、oguma さんが参加されたグループでの議論内容まで詳しくまとめてくださっています。

SRE Session のスタイル

ここから先は、主に SRE Session という勉強会のスタイルの紹介と、それに対する僕の感想です。一応、今回スタッフとして参加したのですが、椅子運びくらいしかしていないので、一参加者の感想として読んでもらえれば。

第1回はこういうスタイルでした(第2回以降で改善されて変わる可能性はあります)。

事前アンケート

connpass での申込時に、今回のテーマ(SLO と Monitoring)に関するアンケートを取りました。

  • SLOについて共有したい事例を記入してください
  • SLOについてディスカッションしてみたいテーマを記入してください
  • Monitoringについて共有したい事例を記入してください
  • Monitoringについてディスカッションしてみたいテーマを記入してください
  • その他この会に期待することを何でも教えてください

このアンケート結果は、スタッフが匿名化したうえで、事前に参加者全員に共有していました。今回、本編ではほとんど使わなかったですが、懇親会での話題のネタになっていました。

アンケートの記入は任意だったので、記入していたのは参加者の半分以下でした。ただ勉強会の性質上、議論のネタを持っている同士でないとつらいので、今後は記入必須になるかもです。

グループ分け

受付終了後に、いくつかのテーブルに散らばって座ってもらいました。

人数が少ないと議論が盛り上がりづらいため、3名のグループになってしまったところは他のグループに合流してもらい、最終的に4〜5名のグループを作りました。

f:id:muziyoshiz:20190429230359j:plain:w800

テーマごとのサイクル

SRE Session #1 は "SLO" と "Monitoring" の2テーマでした。このテーマごとに、以下の35分のサイクルを繰り返しました。

  • Welcome talk 10分
    • そのテーマに関する導入として、有識者の方のプレゼンを聞く
  • Discussion 20分
    • 軽く自己紹介をしてから、テーマについて思うことを話し合う
  • Sharing 5分
    • 各グループにマイクを回して、代表者1名が1〜2分で議論内容を紹介

Welcome talk

今回の Welcome talk は、Yahoo の tsuka さんと、メルカリの spesnova さんが担当してくれました。いずれも、このテーマだけで30分くらい話を聞きたいくらいの濃い内容でした。

こちらの welcome talk の詳しい内容について興味の湧いた方は、ぜひ上述のイベントレポートをご覧ください。

Discussion

Welcome talk のあとは議論の時間。

グループによって進め方はいろいろ違ったと思うのですが、僕たちのグループでは最初に自己紹介をしてから、welcome talk で出たキーワードを拾って、それぞれが興味あることを話した感じでした。

ちなみに、参加者全員が SRE だったわけではなく、例えば僕たちのグループの内訳はこんな感じ。

  • SRE 3名(自分含む)
    • ゲーム、アドテク、プロジェクト管理
  • バックエンド寄りの開発者 2名
    • うち1名の会社は、これから SRE を作ろうとしている段階

一言で SRE と言っても、サービスの種類や規模や、その人の組織内での SRE の立ち位置など、いろいろ違うところがあるので自己紹介は重要そう。

Sharing

最後に、司会が各グループにマイクを持って回って、グループの代表者が1〜2分で議論の内容を紹介しました。

内容のまとめ方は今回特に指定されなかったので、ホワイトボードを使うグループ、SRE Lounge の Slack に書いていくグループ、各人が手元にメモしていくグループ(僕のグループはこれでした)などいろいろでした。

懇親会

最後に、1時間ほど懇親会の時間がありました。

議論中心のイベントだけあって懇親会で帰る人はほとんどおらず、テーマに沿って話が盛り上がったあとだったので、普段の勉強会以上に議論が盛り上がったのではないかと思います(※個人の感想です)。

感想

普段、他社の SRE と深い議論をする機会ってあまり無いので、特定のテーマに沿ってじっくりと議論するのは楽しかったです。良い会だったと思います。

なお、chaspy さんが SRE Session のまとめ記事 に書いていますが、この会は Cloud Native Deep Dive というイベントのやり方にインスパイアされたものらしいです。今回の勉強会が楽しかったので、そちらにもいずれ参加してみたいです。

以下、次回以降どうするともっと盛り上がるかな……と考えたことのメモです。

時間の長さ

開催前は、2テーマは多すぎるのでは? 1テーマあたりの時間が短すぎないか?という議論もありました。

ただ、結果としては20分で少し足りないかちょうどよいくらいで、むしろこの倍の40分だったら場が保たずに辛かったかな、と思いました。

もう少し細かいテーマを設定すれば、もっと議論の時間が長くてもいいかもしれません。例えば、SLO のテーマであれば「組織内で SLO を決めるときに苦労していること」、「組織内で SLO をどのように、どれくらいの頻度で振り返るべきか」といったサブテーマをいくつか用意しておくとか……。

グループ分け

人数はこれくらいでよかったと思います。今回は5名上限でしたが、それ以上になると、1人あたりの話す時間が短くなりそうです。少なすぎても話に広がりがなくなるので、5〜6名がベスト?

あとは、参加者全員が SRE というわけではなかった(事前アンケートでそこまで聞いていなかったので当日気づいた)ので、グループ内に SRE の数が少ないと、その人の話を聞くだけになりそうです。

参加者が全員 SRE である必要はないと思いますけどね。個人的には、いずれ「SRE と開発者の関係」のようなテーマの回があってもいいんじゃないかと思っています。

とはいえ SRE の比率はある程度必要だと思うので、申込時に、SRE only 枠と自由枠で、募集枠を分けるとかしたほうがいいんでしょうか? そのうえで、各グループで SRE の比率が偏らないようにするとか?

議論のまとめ方

今回は特に指定がなかった部分ですが、これは事前に決めておいたほうがよかったかもしれません。

全グループの分だけホワイトボードを用意できる会場は多くないと思うので、ポストイットのイーゼルパッドを用意しておくとか。

あるいは HackMDCacoo のような(手前味噌ですみません)、リアルタイムに共同編集ができるサービスを使うようにお願いしておくとか決めておくと良いかも。議論の内容が電子的にまとまっていると、イベントレポートで共有したり、振り返るのも楽になりますしね。

参加者の総数

Sharing の時間は、元々5分の予定でしたが、実際は1グループあたり1分以上かかっていました。グループの数が多くなりすぎると、Sharing の時間が長くなってつらそうです。

そう考えると、参加者の総数としては6名×6グループ=36名くらいがちょうどいいあたりでしょうか?

参加者の総数をこれくらいに少なめに抑えておいたほうが、会場提供のハードルが下がっていいんじゃないか?と個人的には思っています。

SRE Lounge のほうはすっかり人気イベントになって参加希望者が多くなり、この規模の会場を提供できる会社さんは少なくなってきています。ちなみに、次回5月29日の SRE Lounge #9 は、募集開始から1日で150名の枠が埋まってしまいました(すごい!!)。

sre-lounge.connpass.com

SRE Session のほうは、それよりもっと小さい会場を転々とできるといいなあと。30名程度なら、議論に使える小さめの会議室いくつかと、Sharing の時間だけ集まるセミナールーム1室くらいでギリギリ開催できそうですし。具体的には、うちの会社の東京事務所でもギリギリ開催できそうですし。

SRE Lounge の Slack ワークスペースへのお誘い

SRE Lounge は特定のスポンサーとか特に付いていない、コミュニティベースの勉強会です。

イベント開催情報なども早めに展開されますので、もし SRE Session にご興味のある方はぜひ srelounge.slack.com にご参加ください! 特定のテーマで開催してほしい!もっとこういうスタイルで議論したい!という熱烈な希望があれば #sresession チャンネルでアピールしてもらえると採用されるかも?

SRE Lounge #8 の感想(取り入れたいと思った活動の話を中心に)

f:id:muziyoshiz:20180927232609p:plain

今週の水曜に、クックパッド社にて SRE Lounge #8 が開催されました。今回も参考になるお話が多かったです。

ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド!という感じでした。

ソラコムAPIの裏側で運用チームは何をやってきたのか

SORACOM の OpsDev Manager 五十嵐さん(インタビュー記事)による発表。

OpsDev というのは DevOps の書き間違いではありません。SORACOM では開発チームがメンテナンスと運用の両方に関わり、OpsDev チームは運用作業省力化のための開発をするチームとのことです。

OpsDev チームが開発したロングセラーツールとして、以下のものが紹介されていました。

  • 緊急時のみ SSH 接続を許可するための設定自動化
    • Slack に接続してきた開発者の IP アドレスを、Security Group に自動反映
    • CodeCommit に登録された公開鍵の、EC2 インスタンスへの自動配布
    • ログ取得(詳細は秘密でした)
  • PagerDuty に似た、電話での通知の仕組み
    • Slack で /tel ニックネーム とすると強制的に電話を鳴らす
  • 実際の移動体通信を監視するためのラズパイのタワー(ソラコム・サグラダ・ファミリア)

質疑応答の中で面白いと思ったのは、SORACOM の他の社員の方が「SORACOM ではエンジニアが開発、運用、サポートまで見るので、サポートが一人負けするようなシステムにはならない」と言っていたこと。開発と運用が一体なのは当たり前、という感じで、素直にうらやましいと思いました(個人的にはいつも悩んでいるところなので……)。ただ、基本的に開発者向けのサービスだからできる話かもしれません。

「開発チームの中に開発担当と運用担当ができてしまうのでは?」という鋭い質問もありましたが、「まだ、両者を分けられるほどエンジニアの人数がいない。開発した人が一番早く直せるというポリシーでやっている」とのことでした。

Cookpad Microservice Architecture Overview

クックパッドの技術部 SRE グループの吉川さん(@rrreeeyyy)による発表。

2013年頃からマイクロサービス化に取り組んできて、一進一退しつつ進んできたという話でした。開発者との恊働の話がいくつか出てきました。

例えば、今までは大統一 Terraform を作っていたが、これだと開発者にとってはプルリクを投げづらい。今後はチームごとにディレクトリを分けて、そのディレクトリ内の変更はチームの責任で実施できるようにしたいと思っている、など。

各サービスのチームを巻き込んだ SLI/SLO の導入はまだこれからで、今後の課題とのことでした。

最近、既存サービスのマイクロサービス化について悩んでいたので、懇親会でマイクロサービス化の良い進め方について相談しました。以下はそのときのメモです。

  • モノリシックなサービスの一部をマイクロサービスとして切り出したいとしても、最初は新しいサービスでマイクロサービスの作り方を確立して、開発者自身が自信を付けてからにするのがいい
  • データの切れ目でサービスを分割するといい。例えばクックパッドなら、レシピのデータとユーザのデータは別のもの(レシピの作成者としてユーザ ID が入る程度)なので、そこで分割するとか
  • 作業が SRE だけでほぼ完結するから、データベースの分割からやるのがやりやすいかもしれない。データベースをレプリケーションして、あるタイミングで writer をバタンと切り替える

ちなみに、マイクロサービス化は開発者のほうがモチベーションが高く、運用側から説き伏せて、みたいなことは全然なかったそうです。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

はてなの id:hokkai7go さんによる発表。プレゼン資料に加えて、以下のブログ記事で詳細が補足されていました。

blog.hokkai7go.jp

10名程度のはてな SREs(共通基盤)チームで実施中の活動で、以下のようにやっているそうです。

  • 割れ窓(技術的負債)を見つけたら issue を作成して記録
  • 取り組みやすそうな issue を「週刊割れ窓マガジン」という記事にリストアップ
  • 週に一度、1時間の作業時間を取る(2時間だとダレた。現在は1.5時間に伸ばす試みをしてる)
  • 振り返りやすいよう、終わった issue はスプレッドシートで一覧にしておく

僕は勝手に、開発者も入ってる活動なのかな……と思いながら聞いてたのですが、SRE だけでやっている活動とのこと。最低でもチームの半分くらいは集まって実施するそうです。

SRE の活動のなかで、SLO には現れないけど重要な、運用の品質とでも言うべきものはあると思っていて、最近こういうブログ記事を書いたりしてました。

muziyoshiz.hatenablog.com

はてなの他の取り組みで、PWG(Performance Working Group)という活動も以前聞いたことがあって、自社でも少し実施し始めています。この PWG と併せて、割れ窓タイムも導入してみたいと思いました。

次回の SRE Lounge

次回は5月に、サイバーエージェントで開催予定とのことです。

また、SRE Lounge とは違う、特定のテーマに沿ったディスカッションの場として「SRE Session」というイベントが新たに企画されています。初回は 4/10 で、テーマは SLO と Monitoring です。テーマに興味のある方はこちらも是非どうぞ。

sre-lounge.connpass.com

SRE はサービス品質に影響しない程度の異常をどう扱うべきか?

f:id:muziyoshiz:20180927232609p:plain

今回の記事は、最近考えていたことのメモです。

ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。

障害と異常の定義

話の前に、障害(failure)および異常(anomaly)という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。

  • 障害:サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント
  • 異常:サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント

この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。

これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった(例えば10秒以上になった)場合は障害です。

一方、サーバが1台だけダウンしたものの、ロードバランサのヘルスチェック機能によって、ダウンしたサーバは自動的に切り離されたとします。その結果、ユーザにはほとんどサーバダウンが気づかれなかったとしたら、それは異常です。

障害は計測しやすく、対応しやすい

障害は、その定義からして、明確なユーザ影響が出るため、測定しやすいです。

SRE は、障害の発生度合いを表すサービスレベル指標(SLI)を定義します。例えば、サービスのダウンタイムであったり、リクエストの成功率、応答時間の95パーセンタイルなど。

また、SLI を定義したら、最低限満たすべき SLI の目標値も設定します。例えば、サービスのダウンタイムは1ヶ月あたり3.6時間、など。その目標値はサービスレベル目標(SLO)と呼ばれます。

SLO に限らず、目標値というものは「ここまで頑張らないといけない」高い目標を示すものですが、逆に言うと「ここまでは手を抜いてもいい」下限と考えることもできます。

SLO を「開発・リリースの速度を上げるために、ここまでは手を抜いていいという下限」と捉えたものが、SRE 本で紹介されて有名になった「エラーバジェット」という考え方です。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2017/08/12
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る

障害は、もちろん良くないものですが、それだけに計測しやすいものです。また、エラーバジェットという考え方を導入することで、チームとしての対応を議論することができます。

異常は計測しにくい、対応しにくい

その一方で、異常はその種類が無数にあり、サービスへの影響度合いも分かりづらく、測定しにくいものです。

上で挙げたアプリケーションサーバの例でいうと、例えばこういうものが異常です。

  • OSやミドルウェアのメトリクスの異常な動き
    • 例:サーバの CPU 利用率が、よくわからないタイミングで 100% まで急上昇する。ロードバランサからすぐ切り離されるから、エラーになるリクエスト数は少ない。
  • 普段は出ないエラーログ、あるいは普段とは違うログ件数
    • 例:通常時は出ないログが、時々頻繁に出る。特定のユーザが入力を間違えたときに出るログのはずだが、なにかそれを引き起こす原因があるのかもしれない。
  • 普段とは違うサービスの利用状況
    • 例:アクセス数が普段よりも急激に増えている。ユーザの繁忙期で一時的に増えているだけかもしれないが、今後もこのまま増え続けることを想定したシステム増強が必要かもしれない。

もちろんこれらを SLO に含めることもできます。

とはいえ、SLO の数を増やしすぎると SRE にとってチェックしきれるものではなくなります。サービス影響に直結しないので、チームの方針を決めるためのエラーバジェットとしても説得力は得にくいでしょう。

異常の数が増えていくと、いずれ深刻な障害につながる(かも)

異常の原因調査に割く時間がないので、とりあえずサーバリソースを増やして時間稼ぎをする、という経験は自分にも何度かあります。

あるいは、エラーバジェットを導入している現場なら「障害にまで発展してから、エラーバジェットの範囲内で対応したら?」と考える人もいるかもしれません。

しかし、それぞれの異常がバラバラのタイミングで起きているときは良くても、それらの異常がいくつか同時に発生したタイミングで大きな障害につながる、という可能性を自分はどうしても心配してしまいます。例えば、サーバ1台が突然ダウンする問題があるなら、サーバ3台が同時にダウンすることもあり得るだろう、という心配です。

そういう、サービス品質に影響しない程度の異常については、どう扱うべきなのでしょうか?

あるいは、それが実態の伴わない不安だとして、なにか「エラーバジェット」のような仕組みでうまく解消できるものなのでしょうか?

もやもやと考えていること

最初に書いた通り、この疑問に対する結論はまだありません。ただ、現時点でなんとなく考えていることだけメモしておきます。

メトリクスやログを見て回って、人手で異常を探すのは難しい……というか費用対効果が悪すぎて時間を割けません。なので、原因調査をすべき異常があったときだけ、何らかのアラートが欲しい。

アラートを設定するにしても、

  • 何を監視すべきなのか
  • 閾値をどう設定すべきなのか

という問題があります。これは異常検出(anomaly detection)や傾向分析(performance prediction)と呼ばれる技術の領域です。機械学習で、完全に設定ゼロで導入できたりしたら素晴らしいですが、そこまで実現できている現場ってあるんでしょうか……?

ちなみに、「未知のログが一定数以上発生した場合だけ、日次でレポートを送信する」といった単純な異常検出であれば、ツールを自作すればできるのでいまの現場にも導入しています。実際に使ってみると、その程度でも意外と役に立つものです。ただ、やはり障害のアラートほど重要ではないので、忙しいときは無視されがちではあります。

あるいは、異常が多いと感じるなら、それは異常の数よりも、ソフトウェアメトリクスやテストの量など、コードの品質の方を見たらいいんでしょうか。そういう、遠回りに感じるものの、障害・異常とは別の観点で見るべき話なんでしょうか?

なにかもうちょっとまとまった話が書けそうになったら、そのうちまた書きます。