Kyash TechTalk #1 Serverside

Transcript

1. Datadog Monitorを利用した 汎用的なCircuit Breakerを作った話 Kyash TechTalk #1 Serverside 2021/1/29

2. 2 • 名前：廣部圭一 • GitHub: KeiichiHirobe • 年齢: 31 •

   2019/5/20入社 • TechLead @Fundsチーム • 興味あること：データベース実装 自己紹介

3. 3 11.5 章において、マイクロサービスにおいて障害のサービ ス全体への影響を最小限にする方法として大きく３つ紹介さ れています。 • タイムアウト • 隔壁 •

   Circuit Breaker そもそもCircuit Breakerって何？

4. 4 • タイムアウトを指定することでプロセスが滞留する可能性をへらしま す • 基本的には7~9秒くらいのタイムアウトを指定していることが多い。特 に外部ベンダーのAPIを叩く場合には必須です 困ったことにベンダーのAPI仕様にはタイムアウト１分以上にすることが必 須といったことが仕様書に明記されている場合もあります。 タイムアウトを設定する

5. 5 説明がふわっとしていたが、「被害が最小限になるよ うにサービス間に壁をもうけような仕組みや設定等」 ぽい Goなら、MaxConnsPerHostにてホストごとのクライアントの 接続上限を指定できます。デフォルトは０で無制限。 隔壁

6. 6 隔壁の一種 まさにブレーカーと同じ Circuit Breaker

7. 7 実はKyashではCircuit Breakerの仕組みを一部ではすでに利用していました。
 • cronで数分ごとにjobを起動し、そのjobではNew Relic(監視ツール)の 特定のメトリクス(レスポンスタイムの90パーセンタイルといったメトリ クス)を参照
 • 閾値をもとにCircuit

   Breakerを発動するべきか判断し、フラグをRedis に保存。呼び出し側サービスではRedisを参照し、リクエストすべきか 判断 移行前

8. 8 監視ツール移行にてこうしようとしていた

9. 9 今後も様々な外部ベンダーと接続していく。新しいCircuit Breakerは継続 的に必要になっていくけど、このままメンテしていくのは辛そう
 メンテ辛そう

10. 10 新規のCircuit Breakerを作る時に
 • Datadog Monitor設定
 • SNS
 • Lambda


    のセットが新規に必要になります。これは都度作成するのは明らかに大 変そうです。
 SNS/Lambdaのセットを毎度作る？

11. 11 • 新規のCircuit BreakerのためにLambdaにIAMを追加で付与する可能 性が高い(例えばRDSを参照して判断する必要が生じるなど)
 • ^の結果、Lambdaが様々なアクセス権限をもつことになり、好ましくな い
 • 様々なサービスのドメイン知識がLambdaに入り乱れる（そもそもドメ

    イン知識がLambdaに漏れ出るのさえも避けたかったはず）
 1つのLambda関数に追加していく？

12. 12 DatadogMonitor -> SNS -> Lambdaの流れはそのまま踏襲するとして、 以下を満たしたい。でも無理では？ • Lambdaは各マイクロサービスのRESTAPIを叩くだけ ◦

    Lambdaはどこをたたけばいい（ callbackのエンドポイント）かどうやって知るべき か ◦ イベントに付随する情報はどうやって取得すべきか ▪ 例えば、銀行チャージの場合、どの銀行かを把握するために銀行コード （銀行を一意にするコード）が必要。 ▪ ^を把握する処理をLambdaに書き始めると結局 Lambdaが汎用的でなくな るのでNG • あらゆるmonitor typeに対応したい 汎用的な仕組みを作ろう！！

13. 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. 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. 15 何をもとにAPIを叩くか event_id/monitor_idはSNSのメッセージにデフォルトで含まれます。 Datadogが提供するREST API

16. 16 • Eventが起きた対象の銀行コードは何か ◦ tagから取得 • Eventが起きた時刻はいつか • Eventはwarn/alert/recoveryなのか •

    Monitorにおいてalert/warn状態の銀行コードは何か • おそらくDatadogのWebUIで確認できるものは全て取得可能 Datadogが提供するREST API APIで何が取得可能か

17. 17 結果、こうなった

18. 18 • SNSのmessageをもとに、event_id/monitor_idを判別 • Circuit-breaker-callbackが指定されていれば、event_id/monitor_id とともに叩く。なければ何もせず終了 • callbackのレスポンスが200以外であれば、エラー • 途中でエラーがおきればエラーを投げるだけで何もしない（slack通

    知もしない） で、結局Lambdaは何をするのか

19. 19 • 再送回数は2回（デフォルト）で0~2まで設定可能 • 初回リクエスト~再送1回目まで間隔は1分、再送1回目~再送1回目 の間隔は2分で変更不可 • デットレターキューを設定することで、再送上限にて失敗した時に enqueueされる ◦

    deadletterqueueに対してdatadogmonitorで監視してslack通 知 • 再送間隔はexponential backoffで行われ、最大6時間試行される 再送、後処理はLambdaが全部面倒みてくれ ます

20. 20 再掲

21. 21 • Lambdaの改修は一切不要です
 • 必要な作業がサーバサイドエンジニア内で完結しています
 ◦ Lambdaから各サービスへのネットワーク到達性があれば無問 題
 • 既にあるコード資源（レポジトリやドメイン実装など）を利用でき、マイ

    クロサービス外へのドメイン知識の流出を防ぐことができます 結局、何がうれしいのか

22. 22 • alert/recoveryの閾値の決めは難しい • よくよく考えると、「datadog monitorのイベントを各マイクロサービス でハンドリングする仕組み」なので、circuit-breakerの用途以外にも 使えるはず！ • 話し切れない部分も多かったので、興味ある方は

    https://qiita.com/behiron/items/6b1ae68bc338a1e16a74 最後

23. Thank you 23