Merpay Advent Calendar 2019 の14日目は、メルペイSREチームの@Tがお送りします。
本記事では、メルペイSREチームのSLO運用状況について、紹介いたします。
メルペイリリース前
去年のAdventCalendar 2018で、メルカリのWeb MicroservicesにおけるSLI/SLOについて紹介がありました。
メルペイでは新規のMicroserviceをリリースする前に、各MicroserviceチームがSLOを定義し、品質保持の一指標を決めるルールがあります。
メルペイSREチームでは、Microserviceチームと一緒にSLOを考え、各MicroserviceにSLOを定義していますが、一からSLOを定義するのはとても難しいです。
幸いなことにGoogle社からSLOの説明や定義方法などSREに関する素晴らしい記事がたくさん共有されており、SLOを定義する際、大変参考にさせて頂きました。
The Art of SLOs
cloud.google.com
cloud.google.com
cloud.google.com
cloud.google.com
www.youtube.com
メルペイSREチームでは、上記Google社の記事をサマリー化したドキュメントを作成しただけでなく、各MicroserviceチームのSLOを記載するドキュメントのテンプレートを用意し、作成されたSLOは、統一されたフォーマットで記載出来るようにしました。
下記、そのフォーマット例です。
- API Endpoint: /path/to/endpoint
- Availability
- 1時間測定して、99.99%のリクエストが、正常な結果(Status: 2xx, 3xx, 4xx)`を返す
- Latency
- 1時間測定して、 99%のリクエストが 100msec以内に返る
- Quality
- Sentryなどで10分測定して、想定外のエラーが0.1%以下
- Availability
また、各Microserviceチームが容易にSLOを可視化出来るように、DatadogのSLOのダッシュボードのテンプレートも作成しました。
メルペイリリース後
各Microserviceチームが日々システムを運用していく中で、新規開発や機能改修などでシステムが変化するのと同時に、SLOも変化してきました。
一例として、Availabilityに対するSLOの再設定が挙げられます。
ネットワークの遅延による瞬間的なスパイクや、他の環境に作用されるノイズが多いメトリクスなど、リリース前に予測することは困難であり、厳しすぎるSLOを設定してしまいました。
対応として、SLOを見直し、Datadog Monitorのパラメータを調整し(Alert windowの調整、計測値を99percentileから95percentileにしたりするなど)、過度にアラートがならない様にしました(Monitorの調整は他にも実施しましたが、知見が貯まりましたら、別記事でシェアする予定です)。
そのような調整をしていく中で、実際にDatadogで設定しているパラメータと、リリース前に記載したSLOドキュメントのパラメータとの差異が発生するようになりました。
ドキュメントを運用するのは、どんなチームでもToilになりやすいものだと思います。
また、メルペイSREチームでリリース後に発生するであろうSLO運用ルールが作成されていなかった点が原因でもあります 🙇♂️
サービスの品質を今まで以上に向上させる為には、SLOのクオリティの維持は必須です。
各MicroserviceチームがSLOを運用するのはあるべき姿ですが、適切にSLOを設定・運用し、サービス品質を高い水準で揃えるため、最近メルペイSREチームでは、共通のSLO運用ルールを作成することにしました。
これを元に、メルペイ全体で一定の水準でSLOを設定・運用出来るようにするのが目標です。
SLO運用ルール
下記に運用ルールの一部を紹介いたします。
- SLOを変更した際にはメルペイSREチームがレビュー&承認をする
- SLOのtime windowを30日間にする
- SLOは最低でも3ヶ月毎に見直す(見直しがない場合、リリースができなくなるPolicyをOPAで表現している)
SLOの定義と監視設定の定義を共通化し、DatadogのDashboardやMonitorの作成を自動化するため、Terraformを活用する仕組みを作りました。
下記はTerraform Moduleの一例です。
module "merpay-slo" {
source = "git::https://github.com/mercari-demo/terraform-module-slo.git?ref=0.1"
datadog_api_key = var.datadog_api_key # Datadog API KEY
datadog_app_key = var.datadog_app_key # Datadog APP KEY
# Datadog APM名
service_name = "merpay-example"
# SLOs
slos = {
"example1" = {
availability_threshold_percentage = 99.9 # Availabilityを指定
latency_threshold_ms = 3000 # Latencyを指定
tags = [ # Datadogのタグを指定
"grpc_service:merpay-example-service",
"grpc_method:example1",
]
},
...
}
# 前回の承認日(YYYY-MM-DD)、CI上で参照し、3ヶ月過ぎていたらKubernetesに対するApplyをBlockする。
approval_date = "2019-11-06"
}
上記のようなTerraform Moduleを使用して、自動化することにより、下記のメリットが期待できます。
- 各マイクロサービスでSLOや監視の設定を一定の水準に揃えることができる
- SLOの設定がそのまま監視設定になるため、SLOが正しくメンテナンス・運用される
- 今までの知見を活かした、瞬間的なスパイクや、ノイズが多いメトリクスなどに耐えうるモニターを強制的に作成することが可能になる
- CIにて、前回の承認日に対するPolicyを組み込むことで、3ヶ月毎にSLOをreviewする運用を強制できるようになる
また、共通化したSLOを定義したことにより、Evernote社の事例のような各Microservice毎の1ヶ月毎のSLOを一覧表示出来るダッシュボードも現在開発中です。
このようなダッシュボードを作成することにより、SLOを満たしているMicroserviceが多いか少ないか、先月又は前クォーターに比べて上昇傾向にあるか下降傾向にあるかなど、メルペイのシステム全体の品質が今どういう状況なのか、把握することが容易になるでしょう。
最後に
メルペイSREチームのSLO運用状況について、紹介しました。
メルペイはSRE文化が根付いた環境です。
リリース当初からMicroservice化され、SLOもMicroserviceチームがリリース時から運用され続けておりますが、Error Budget Policyの設定など、まだまだやらなければいけないタスクが盛り沢山です。
SREという職種の事例は、Google社のSREチームの尽力により(谢谢)、Google社の素晴らしいSRE事例を無料で拝見することが出来る反面、その他の会社事例を目にする機会はまだ少ないと感じています。
そんな中、来年開催されるSRE NEXT 2020では、メルペイSREの@tkuchikiが登壇し、メルペイのSREのオンボーディングの事例を紹介する予定です。
今回ご紹介したSLOの運用事例以外で、「うちのSLOはこうしている！」「もっとうまい運用のやり方があるのでは？？」といったご意見がありましたら、カジュアルにシェアしましょう👇👇👇
明日のMerpay Advent Calendar 執筆担当はBackendエンジニアのrobertjeさんです。引き続きお楽しみください。
