Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kyash TechTalk #1 Serverside
Search
Keiichi Hirobe
January 28, 2021
Programming
1
340
Kyash TechTalk #1 Serverside
Kyash TechTalk #1 Serverside
2021/1/29
Datadog Monitorを利用した
汎用的なCircuit Breakerを作った話
Keiichi Hirobe
January 28, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
8.7k
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
15
5.6k
Modern Angular with Signals and Signal Store:New Rules for Your Architecture @enterJS Advanced Angular Day 2025
manfredsteyer
PRO
0
270
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
300
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
170
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
0
120
ふつうの技術スタックでアート作品を作ってみる
akira888
1
1.3k
[SRE NEXT] 複雑なシステムにおけるUser Journey SLOの導入
yakenji
0
150
Deep Dive into ~/.claude/projects
hiragram
14
14k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
7.3k
Model Pollution
hschwentner
1
160
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
870
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1370
200k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
RailsConf 2023
tenderlove
30
1.1k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Fireside Chat
paigeccino
37
3.5k
Transcript
Datadog Monitorを利用した 汎用的なCircuit Breakerを作った話 Kyash TechTalk #1 Serverside 2021/1/29
2 • 名前:廣部圭一 • GitHub: KeiichiHirobe • 年齢: 31 •
2019/5/20入社 • TechLead @Fundsチーム • 興味あること:データベース実装 自己紹介
3 11.5 章において、マイクロサービスにおいて障害のサービ ス全体への影響を最小限にする方法として大きく3つ紹介さ れています。 • タイムアウト • 隔壁 •
Circuit Breaker そもそもCircuit Breakerって何?
4 • タイムアウトを指定することでプロセスが滞留する可能性をへらしま す • 基本的には7~9秒くらいのタイムアウトを指定していることが多い。特 に外部ベンダーのAPIを叩く場合には必須です 困ったことにベンダーのAPI仕様にはタイムアウト1分以上にすることが必 須といったことが仕様書に明記されている場合もあります。 タイムアウトを設定する
5 説明がふわっとしていたが、「被害が最小限になるよ うにサービス間に壁をもうけような仕組みや設定等」 ぽい Goなら、MaxConnsPerHostにてホストごとのクライアントの 接続上限を指定できます。デフォルトは0で無制限。 隔壁
6 隔壁の一種 まさにブレーカーと同じ Circuit Breaker
7 実はKyashではCircuit Breakerの仕組みを一部ではすでに利用していました。 • cronで数分ごとにjobを起動し、そのjobではNew Relic(監視ツール)の 特定のメトリクス(レスポンスタイムの90パーセンタイルといったメトリ クス)を参照 • 閾値をもとにCircuit
Breakerを発動するべきか判断し、フラグをRedis に保存。呼び出し側サービスではRedisを参照し、リクエストすべきか 判断 移行前
8 監視ツール移行にてこうしようとしていた
9 今後も様々な外部ベンダーと接続していく。新しいCircuit Breakerは継続 的に必要になっていくけど、このままメンテしていくのは辛そう メンテ辛そう
10 新規のCircuit Breakerを作る時に • Datadog Monitor設定 • SNS • Lambda
のセットが新規に必要になります。これは都度作成するのは明らかに大 変そうです。 SNS/Lambdaのセットを毎度作る?
11 • 新規のCircuit BreakerのためにLambdaにIAMを追加で付与する可能 性が高い(例えばRDSを参照して判断する必要が生じるなど) • ^の結果、Lambdaが様々なアクセス権限をもつことになり、好ましくな い • 様々なサービスのドメイン知識がLambdaに入り乱れる(そもそもドメ
イン知識がLambdaに漏れ出るのさえも避けたかったはず) 1つのLambda関数に追加していく?
12 DatadogMonitor -> SNS -> Lambdaの流れはそのまま踏襲するとして、 以下を満たしたい。でも無理では? • Lambdaは各マイクロサービスのRESTAPIを叩くだけ ◦
Lambdaはどこをたたけばいい( callbackのエンドポイント)かどうやって知るべき か ◦ イベントに付随する情報はどうやって取得すべきか ▪ 例えば、銀行チャージの場合、どの銀行かを把握するために銀行コード (銀行を一意にするコード)が必要。 ▪ ^を把握する処理をLambdaに書き始めると結局 Lambdaが汎用的でなくな るのでNG • あらゆるmonitor typeに対応したい 汎用的な仕組みを作ろう!!
13 Q: Lambdaはどこをたたけばいい(callbackのエンドポイント)かどうやっ て知るべきか? A: 適当なキーワード(以下の例ではcircuit-breaker-callback)にエンドポ イントを指定する {{#is_alert}} circuit-breaker-callback: https://serciceA/dd_circuit_breaker/callback
{{/is_alert}} {{#is_alert_recovery}} circuit-breaker-callback: https://serciceA/dd_circuit_breaker/callback {{/is_alert_recovery}} {{#is_warning}} circuit-breaker-callback: https://serciceA/dd_circuit_breaker/callback {{/is_warning}} @slack-tech-channel @sns-dd-circuit-breaker 汎用的な仕組みを作ろう!!
14 Q: イベントに付随する情報はどうやって取得すべきか。あらゆるmonitor typeに対応できるのか? A: Datadogが提供するREST APIを利用する CURL curl -X
GET "https://api.datadoghq.com/api/v1/events/${event_id}" \ -H "Content-Type: application/json" \ -H "DD-API-KEY: ${DD_CLIENT_API_KEY}" \ -H "DD-APPLICATION-KEY: ${DD_CLIENT_APP_KEY}" Goのクライアントライブラリ configuration := datadog.NewConfiguration() api_client := datadog.NewAPIClient(configuration) resp, r, err := api_client.EventsApi.GetEvent(context.Background(), eventId).Execute() 汎用的な仕組みを作ろう!!
15 何をもとにAPIを叩くか event_id/monitor_idはSNSのメッセージにデフォルトで含まれます。 Datadogが提供するREST API
16 • Eventが起きた対象の銀行コードは何か ◦ tagから取得 • Eventが起きた時刻はいつか • Eventはwarn/alert/recoveryなのか •
Monitorにおいてalert/warn状態の銀行コードは何か • おそらくDatadogのWebUIで確認できるものは全て取得可能 Datadogが提供するREST API APIで何が取得可能か
17 結果、こうなった
18 • SNSのmessageをもとに、event_id/monitor_idを判別 • Circuit-breaker-callbackが指定されていれば、event_id/monitor_id とともに叩く。なければ何もせず終了 • callbackのレスポンスが200以外であれば、エラー • 途中でエラーがおきればエラーを投げるだけで何もしない(slack通
知もしない) で、結局Lambdaは何をするのか
19 • 再送回数は2回(デフォルト)で0~2まで設定可能 • 初回リクエスト~再送1回目まで間隔は1分、再送1回目~再送1回目 の間隔は2分で変更不可 • デットレターキューを設定することで、再送上限にて失敗した時に enqueueされる ◦
deadletterqueueに対してdatadogmonitorで監視してslack通 知 • 再送間隔はexponential backoffで行われ、最大6時間試行される 再送、後処理はLambdaが全部面倒みてくれ ます
20 再掲
21 • Lambdaの改修は一切不要です • 必要な作業がサーバサイドエンジニア内で完結しています ◦ Lambdaから各サービスへのネットワーク到達性があれば無問 題 • 既にあるコード資源(レポジトリやドメイン実装など)を利用でき、マイ
クロサービス外へのドメイン知識の流出を防ぐことができます 結局、何がうれしいのか
22 • alert/recoveryの閾値の決めは難しい • よくよく考えると、「datadog monitorのイベントを各マイクロサービス でハンドリングする仕組み」なので、circuit-breakerの用途以外にも 使えるはず! • 話し切れない部分も多かったので、興味ある方は
https://qiita.com/behiron/items/6b1ae68bc338a1e16a74 最後
Thank you 23