Merpay Advent Calendar 2020 の21日目は、メルペイ SREチーム の @T がお送りします。
去年のAdvent Calendarでは、Terraform Moduleを使用したSLO（Service Level Objective）の定義と監視設定の定義を共通化し、マイクロサービス毎の1ヶ月毎のSLOを一覧表示出来るダッシュボードを開発していたことを紹介しました。あれから1年、この記事では、その後のSLO運用状況について紹介します。
SLO Dashboard
去年のAdvent Calendarでは、SLOの定義と監視設定の定義を共通化し、DatadogのDashboardやモニターの作成を自動化するため、Terraform Moduleを活用する仕組みを紹介しました。
この仕組みにより、DatadogのSLOのモニター、SLOリソース、SLOウィジェットをTerraform Moduleで自動で作成、管理し、作成されたSLOウィジェット利用してSLO Dashboardを作成しました。
しかし、SLO Dashboardを作成した目的は、Evernote社の事例のようなSLOを満たしているマイクロサービスが多いか少ないか、先月又は前クォーターに比べて上昇傾向にあるか下降傾向にあるかなど、メルペイのシステム全体の品質が今どういう状況なのか、SLOによって把握することを容易にすることです。
出典:The Site Reliability Workbook – SLO Engineering Case Studies
そのような要件を実現する為には、去年作成したDatadogのSLOウィジェットを使用したDashboardでは機能が不十分でした。
Improve SLO Dashboard
Save daily SLI value
DatadogにはTerraform Moduleで作成したSLOのモニター、SLOリソースによって、直近3ヶ月分の測定したSLI（Service Level Indicator）値が保存されています。その為、Datadog APIを利用し、測定したSLI値を取得すれば内製又は他のツールでSLO Dashboardが作成出来ると考え、まずDatadogが保存している測定したSLI値を最小分解能を1日分とし、Datadog APIを介して保存する機能を作成しました。
APIへのアクセスは、go-datadog-api を使用しました。当時、Datadogオフィシャルのクライアントライブラリであるdatadog-api-client-goは、SLO History API をサポートしていなかった為です。しかし、go-datadog-apiを使用した際、実際にSLO History APIからのJSONレスポンスとgo-datadog-apiクライアントライブラリのマッピングする構造体に差異があり(ドキュメントに記載されたレスポンス例とも差異がありました)、正しいレスポンスが受け取れませんでした。幸いgo-datadog-apiは、OSSでのContributeが可能だったので、PRを送り修正することができました。現在このライブラリは実質Archive状態の為、今後datadog-api-client-goに移行する予定です
(datadog-api-client-goは、openapi-generatorで生成されています。datadog-api-client-goにもSLO History APIのJSONレスポンスとライブラリのマッピングする構造体に差異があり、同様の問題がありますが、OpenAPIのSpecファイルが非公開の為、Contributeして修正することが出来ませんでした😢)。
Save SLO history
上記のDatadog APIを介して測定したSLI値を保存する際、SLOの履歴を保存する機能を追加しました。
SLOはSLA（Service Level Agreement）ではないので、合理的な理由があれば、柔軟に変更・削除していくべきです。SLOを利用した議論や意思決定をする際、短期ウィンドウのSLOだけでなく長期ウィンドウのSLOと比較して議論したい場合もあるでしょう。しかし、直近のSLOが過去のSLOと同じである保証はありません。長期ウィンドウのエラーバジェットが減少していた場合、実際にインシデントが発生していたのか、SLOを変更し高い目標値に変更した結果だったのか、それらを判断したい場合、過去のSLOが必要だと考えました。
Visualize in Looker
メルペイのシステム全体の品質が今どういう状況なのかSLOによって把握する上で、日々刻々と変わるシステムの状況を多角的視点で捉えられる様、Dashboardは柔軟かつ容易にグラフを描画し、分析出来ることが必要です。その上で、ROIの観点から内製ではなくBIツールが適していると考え、メルペイではBIツールとして以前から利用実績があるLookerを使用してSLO Dashboardを作成しました。
SpannerからBigQueryへのバッチパイプライン処理については、弊社のData Platformチームが運用しているバッチ基盤を利用しています。バッチ基盤については、メルペイにおける大規模バッチ処理をご覧ください。
Lookerで作成したSLO Dashboardには、マイクロサービス毎に下記の項目が表示されています。
直近7・30・90日毎のError Budgetの残り時間
月毎のSLI値(最大値、最小値、平均値、中央値)
日毎のSLI値の増減傾向
SLO Dashboardのペルソナは、マイクロサービスチーム、プロダクトマネージャーです。
これらの表・グラフは、メルペイSREチームがペルソナが欲しいであろう情報を仮説・検討し、作成しました。SLO Dashboardを運用していく中で、ペルソナからの要望を伺い、随時変更していきます。
次に、SLO Dashboardの改善と同時に、Terraform Module作成の改善も行いましたので紹介したいと思います。
Improve Terraform Module
SLOの定義と監視設定の定義を共通化し、DatadogのDashboardやMonitorの作成をTerraform Moduleを使用して自動化するメリットは、去年のAdvent Calendarで紹介しています。
Terraform Moduleを作成したことによるメリットの恩恵を得た反面、このTerraform Moduleを使用するには、Terraform Moduleの設計を理解し、Moduleの設計に沿って定義、作成する手間が発生してしまいました。マイクロサービスチームにはDatadogでSLOの設定を容易に定義出来る何かが必要でした。
Microservices Spec
メルカリ・メルペイでは、誰がマイクロサービスを管理しているのか、マイクロサービスのドキュメントがどこにあるのか、依存するマイクロサービスの仕様などを議論するのにどのSlack チャンネルが適しているのか、などを容易に探すことが出来るように、各マイクロサービスのメタ情報として定義されたSpecファイルがあります。
serviceId: demo-id
description: Microservices demo project
corporation: merpay
teamName: merpay-sre
contact:
issueTrackerUrl: "https://github.com/path/to/some-microservices/issues"
repositoryUrls:
- https://github.com/path/to/some-microservices
documentations:
- title: general
url: https://github.com/path/to/README.md
...Specファイルの例
SREチームでSLOを定義するTerraform Moduleを開発していた一方で、メルペイ ArchitectチームとMercari Microservices Platform チームでは、このSpecファイルにSLOを定義出来るようにするプロジェクトが進行していました。
...
service_level:
service_level_objectives:
- definition:
name: "99.99% availability"
time_window: WEEKLY
objective: "P99_99"
selector:
- labels:
- "availability"
...SLOの定義を入れたSpecファイルの例
Specファイルで定義されたSLOは、Protocol Buffersのカスタムオプションを利用してAPI毎にマッピングされます。
rpc SayHello(HelloRequest) returns (HelloResponse) {
option (labels) = "availability";
}SLOをProtocol Buffersにマッピングする例
メルペイSREチームもそのプロジェクトに参加し、協力を得ることでSpecファイルに定義されたSLOからTerraform Moduleを生成する機能を開発しました。マイクロサービスチームが、Terraform Moduleの設計を理解せずとも、SpecファイルにSLOを定義することで、自動でTerraform Moduleが作成され、Datadog上にSLO用のリソースを作成出来るようにしました。
また、これらの設定は、PRC（Production Readiness Checklist）の項目として追加し、新規にマイクロサービスをリリースする時や、定期的にPRCの見直しをするタイミングで、導入する機会を設けるようにしました。
PRCについては、Mercari Microservices Platformの進捗（2019年）、メルペイSREの @foostan が登壇した、Datadog Virtual Summit Japanのセッションをご覧ください。
最後に
メルペイSREチームの今年1年間のSLO運用状況について紹介しました。
各マイクロサービスのAPI毎のSLOの表示といったSLO Dashboardの拡充や、BurnRate Alertの設定など、やりたいことは尽きませんが、他チームと連携し協業したおかげで今年1年間でSLOの運用基盤は大方構築することが出来ました。
来年から本格的にSLOを利用していくフェーズです。マイクロサービスチームやプロダクトマネージャーがSLOを利用した議論や意思決定を容易に出来る環境を整えていくと同時に、SLOによって得られたReliabilityを維持し、お客さまの満足度向上に貢献出来る様、メルペイSREチームの Maintain SLO は引き続き継続していきます。
明日のMerpay Advent Calendar 2020 は、Frontend チーム Tech Lead兼Engineering Managerの @1000chさんより、Merpay Frontend のこれまでとこれから です。
引き続きお楽しみください。
