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
Testing Trophyは叫ばない
toms74209200
0
680
[FEConf 2025] 모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년
mmmaxkim
0
1.4k
AWS発のAIエディタKiroを使ってみた
iriikeita
1
160
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.1k
Protocol Buffersの型を超えて拡張性を得る / Beyond Protocol Buffers Types Achieving Extensibility
linyows
0
110
CSC305 Summer Lecture 12
javiergs
PRO
0
130
OSS開発者という働き方
andpad
5
1.7k
tool ディレクティブを導入してみた感想
sgash708
1
160
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
240
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
Kiroで始めるAI-DLC
kaonash
2
540
AIエージェント開発、DevOps and LLMOps
ymd65536
1
380
Featured
See All Featured
A Tale of Four Properties
chriscoyier
160
23k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
It's Worth the Effort
3n
187
28k
We Have a Design System, Now What?
morganepeng
53
7.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
How to Ace a Technical Interview
jacobian
279
23k
Side Projects
sachag
455
43k
Docker and Python
trallard
45
3.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
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