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
310
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
Code Reviews
bkuhlmann
4
880
今、知っておきたい! 生成AIエージェントの世界
elith
3
340
Git Rebase
bkuhlmann
11
1.6k
Semantic search with Django and pgvector
pauloxnet
0
230
⼤規模⾔語モデルの拡張(RAG)が 終わったかも知れない件について
nearme_tech
22
15k
HUIT新歓2024「競技プログラミング、やってみませんか?」
slephy2784
1
250
スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた / Re-reading the Sprint Retrospective Section in the Scrum Guide
mackey0225
3
320
Blue/Greenデプロイの導入による 運用フローの改善
kudoas
1
350
スクラムチームと認知負荷 - ニフティのスクラムトーク Vol2. / NIFTY Tech Talk #18
niftycorp
PRO
1
120
SpringBoot+MyBatisで例外が出たときどこを見るか
syukai
0
110
Elm Form Validation
bkuhlmann
0
500
PHPの次期バージョンはこの時期どうなっているのか - Internalsの開発体制について - PHPカンファレンス小田原
youkidearitai
PRO
1
180
Featured
See All Featured
Building Effective Engineering Teams - LeadDev
addyosmani
27
1.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
273
13k
Git: the NoSQL Database
bkeepers
PRO
422
63k
Building a Modern Day E-commerce SEO Strategy
aleyda
16
6.3k
How to train your dragon (web standard)
notwaldorf
72
5.1k
Designing for Performance
lara
602
67k
BBQ
matthewcrist
80
8.7k
The Cult of Friendly URLs
andyhume
74
5.7k
Designing for humans not robots
tammielis
247
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
Fantastic passwords and where to find them - at NoRuKo
philnash
36
2.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