エブリーで小売業界向き合いの開発を行っている @kosukeohmura です。
昨年、エブリーではネットスーパーの事業を株式会社ベクトルワン様から引き継ぎました。引き継いだシステムを運用していく中で、ネットスーパーの各種サイトや API に使用している 20 個超の SSL 証明書の有効期限を切らさないように更新していく必要があり、そのために監視を導入したお話をします。
引き継ぎ作業の概観については以前公開しました ゼロからはじめるシステム引き継ぎ - every Tech Blog に書きましたので、合わせて御覧ください。
背景とモチベーション
システムを引き継いだ時点では SSL 証明書の更新の運用は素朴なものでした。具体的にはエンジニアが有効期限を切らさないようにたまにそれぞれのサイトの有効期限をチェックし、有効期限が近づいたものを発見次第手動で更新作業を行うというものです。抜け漏れが容易に起こり得ますし、更新が漏れた際はサービス停止せざるを得ないため、ミスの起こりづらい仕組みを導入する必要性を感じていました。そこでまずは有効期限に近づいたことを気付けるようにすることにしました。ゆくゆくは更新作業自体を自動化したいところですが、それを行ったとしても自動的に有効期限が近づいた際に検知する仕組みは依然として必要になると考えています。
お手軽に Google カレンダーやタスクツールへの手動登録・管理を考えましたが、タスクや予定の登録などの作業が面倒なのとオペレーションミスの可能性が許容できなそうだと思っていたところ、Datadog で有効期限を外形監視できることを知り、早速利用することとしました。
Datadog での SSL の監視にかかる料金
Datadog の SSL 監視機能は正しくは SSL Tests といい、Datadog の Synthetic Monitoring というプロダクトの中の API Tests というテスト群の 1 種として存在します。API Tests の料金 は 2024/02 現在月々 10,000 回のテスト実行ごとに $6.25 です。
SSL Tests はそう高頻度で実施しても意味が薄いので、比較的テスト回数が少なく済み、料金はお手頃になります。仮に 1 日毎の SSL Test 実行であればドメインごとに月々 30 テスト実行程度に収まるので、300 を超えるドメインを $6.25 で監視できることになります。一方 API Tests には SSL の他に HTTP や gRPC といったテストも存在しますが、こういった死活監視となると高頻度でテストを行うことになり料金が高くなります。仮に 1 分毎に 1 つの API のテストを行うとすると、月のテスト回数は 40,000 回を超えてくるため月々 $25 かかってきます。これは割高に感じました。
ちなみにエブリーでは Web サイトや API の死活監視に Pingdom の Uptime monitoring を使用していますが、そこでは月々 $10 で 10 個の URL / IP に対して 1 分毎の外形監視が可能です。
このように Datadog の API Tests ではテスト実行回数で価格が決まるので、行うテストの特性・頻度によって費用には大きく幅が出ます。
導入してみる
私自身こういった外形監視を一から設定することは初めてでしたが、ドキュメント を読むと特に迷うこと無く設定できました。主な設定値を次に記します:
- テスト元のロケーション
- 1 つ (Tokyo) のみ。複数ロケーションからリクエストする意義は少ないと感じたため
- 有効期限のアサート閾値
- 30 日。運用次第で調整するかもしれませんが、最初は余裕を持って
- 再通知間隔
- 3 日
- リトライ条件
- リトライを行わないように設定。証明書の有効期限が近づいている場合何度テストしても同じ結果となるため
- テスト頻度
- 1 日に 1 度
アラート時の通知先は Slack とし、メッセージは下記のような内容としました。
{{#is_alert}}
{{#is_renotify}}
引き続き、SSL 証明書の期限が 30 日以内もしくは SSL が正常でない状態が続いています。
SSL の状態を確認し、必要であればフローに沿って証明書の更新を進めてください。
- [SSL 証明書更新フロー](<社内ドキュメントへの URL>)
{{/is_renotify}}
{{^is_renotify}}
SSL 証明書の期限が 30 日以内もしくは SSL の状態が正常ではありません。
{{/is_renotify}}
{{/is_alert}}
{{#is_no_data}}
SSL のデータが取れていません。
{{/is_no_data}}
{{#is_recovery}}
SSL の状態が正常になりました。
{{/is_recovery}}
上記設定をそれぞれのドメインに対して繰り返した結果、下記のように今回の監視対象の 20 以上の SSL 証明書の期限を Datadog 上に一覧化できました！有効期限もひと目で分かり、30 日以内となったもののステータスは ALERT となっています。いい感じです。
Slack にも下記のように通知が届きます(ちょっと文言が変わっていますが)。
導入時に困ったこと
ひとたび把握・設定してしまえば簡単に SSL の監視が実現でき、しかも料金もお手頃で満足度は高いのですが、少し思うところもあったので挙げてみます。
有効期限切れまでの残日数をアラート時のメッセージに入れられない
Datadog には Template variables というアラート通知時のメッセージに現在のメトリクスを埋め込める機能がありますが、ドキュメント を見る限り SSL Tests で埋め込み可能なメトリクスはなさそうでした。理想的にはアラートメッセージに有効期限切れまでの残日数を含めて SSL 証明書の期限切れまで {{ value }} 日です。 のような形にすることでアラートを受けたエンジニアが Datadog へ飛ばずとも残日数を把握できるようなメッセージにしたかったのですが、今回は無理そうなので諦めました。
同一の SSL Test を参照する形で多数のドメインのテストを行えない
今回 20 個の SSL Tests を作成しましたが、そのために 1 つの SSL Test を Clone してドメイン名を書き換えるという作業を 20 回実施しました。設定を頻繁に書き換えることは現時点で想定していませんが、例えばメッセージのテンプレートを変えたくなった場合に、20 個の SSL Tests を更新して回らなければならないということになります。1 つの SSL Test を複数のドメインに対して適用するようなことができれば DRY になり設定変更作業も最低限で済むと思ったのですが、現時点では (Web からの作業では) 一度作った SSL Test を Clone するしか道はなさそうでした。
これについては Terraform Datadog provider を利用し Datadog の設定をコード化することで DRY 化を実現できるとは思いますが、今回は工数に余裕がなく見送りました。（ちょっと脱線しますが、）これに限らず私たちのチームでは Datadog の設定内容のコード化は行っていないのですが、サービスに直接影響はなくともコード化のメリットは享受できるところも多いと今回感じたため、今後コード化してみたいと思っています。
最後に
Datadog Synthetic Monitoring API Tests で 20 を超えるドメインの SSL を監視したお話でした。このように、エブリーではスーパーマーケットなどの小売業界へより良いソリューションを提供できるようにプロダクトの改善を進めておりますので、また何か紹介できればと思います。お読みいただきありがとうございました。
