概要
この記事はDMMグループ Advent Calendar 2020 11日目の記事です。
DMM.comでサーバサイドエンジニアをやっているjuve534です。
現在は配信基盤のリプレイスプロジェクトにて、スクラムマスター兼デベロッパーとして業務しています。
今回はリリース時に導入した Deep Health Check について話していきます。
Deep Health Checkパターンとは
CDP:Deep Health Checkパターン - AWS-CloudDesignPatternで説明されており、ヘルスチェック用のエンドポイントで、関連するシステム（DBなど）の接続をチェックする仕組みになります。
こうすることで、よりサービスの健康を測れます。
O'Reilly Japan - 入門 監視では、ヘルスエンドポイントパターンとして記載されており、考え方は同じなのかなと思っています。
実装経緯
自分たちのプロジェクトではAmazon ECS上にAPIを配置し、オンプレのDBにアクセスしています。
オンプレのシステムは、専門のインフラチームで保守・運用を行っており、サービスイン前にリリース影響範囲を読み合わせたところ、オンプレのDBへアクセスする部分の監視について話が及びました。
弊社の他サービスで上記の通信経路（DirectConnect）をチェックする仕組みを設けており、弊チームでも導入を提案されました。
そこで、前述した Deep Health Check パターンを採用して、実装を行っていきました。
イメージ図
イメージ図はこんな感じです。ALBからのヘルスチェック時に、DBにアクセスします。もし繋がらない場合は、CloudWatchのカスタムメトリクスに飛ばします。
CloudWatchAramで、数秒間に何回値があったら、SNSへ飛ばすようにし、そこからメールとSlack通知を行います。
これで、問題が起きた際にインフラチームと協力して調査できる体制を取れるようにしました。
最後に
特に実装してしばらくは出番がなかったのですが、サービスメンテナンスを行った際に、DirectConnect越しにDBに繋がらないことを検知してくれました。
このように、ヘルスチェックを工夫しておくと、問題の検知が素早くできると思いました。
DMMグループ Advent Calendar 2020 11日目の記事でした。
明日の12日目はdaisukeodaさんです。よろしくお願いします！