Fastly の認証局向けにモニタリングとアラート機能を強化

信頼できる CA は、サービス障害や環境内の疑わしいアクティビティを迅速に検出できるよう、常に包括的なログ機能とモニタリング機能を使用できる必要があります。これにより CA の完全性を強化できるだけでなく、インシデントに対応するのに必要なデータに運用チームがアクセスすることが可能になります。

私たちは常にトップクラスのリアルタイムログ機能と可観測性を提供し、リアルタイムデータを他のツールに統合できるようにすることに力を入れてきました。そのため、独自の CA の構築を開始した際にも、同様にする必要があることを認識していたのです。

冗長性が高く、目的に沿って設計されたアーキテクチャを採用している Certainly では、物理ホストやネットワークデバイス、カメラなど、多くの多様なシステムからのログやメトリクスが必要となります。また、このようなデータを取得できるだけでなく、データを統合して役に立つアラートシグナルに変換できなければなりません。この記事内の「アラート」は、待機しているエンジニアへのプッシュ通知をトリガーして緊急に注意を喚起するイベントを意味します。頻繁で実用的でないアラートは不要な呼び出しをトリガーし、スタッフを他の作業やプライベートな時間から引き離して疲労をもたらし、最終的にサービスの信頼性を低下させる可能性があります。この記事では、有意義なアラートを作成する課題と、Certainly でそれを解決するために採用したアプローチについてご説明します。

アラートを定義する前に、ログとメトリクスが適切な情報と一緒に確実に収集されるようにする必要があります。Certainly では Splunk (PagerDuty と統合) をモニタリングプラットフォームとして使用し、人気の高いオープンソースツールの rsyslog と Telegraf を使ってログとメトリクスを収集して標準化しました。このようなデータを収集し、Splunk で使用可能になった結果、Certainly チームはアラートやレポートを作成したり、インシデントを調査したりできるようになりました。 

まず私たちは、サービス障害のメッセージやサポートしているツールセットのエラーを対象に約60のアラートを構築することから始めました。最初にこれらのアラートをデプロイした際、多数の誤検知が発生しました。サービスまたはホストがリビルド (再構築) されるプロセスにあったためで、これは Certainly のエフェメラルな設計の性質上避けられません。しかしその後間もなくして誤検知が減少し、サポートスタッフがすぐに疲弊してサポートの信頼性が脅かされることがなくなりました。  私たちはアラートを改善する必要性を感じ、問題を修正するために以下のステップを実行しました。

各アラートについて、本当に必要かどうかを確認しました。以下は判断ポイントの例です。

• 修復失敗のアラートがあるのに、バックアップ失敗のアラートが必要か

• 2つの冗長 (高可用) サービスのうち、ひとつでのみ障害が発生した場合にアラートが必要か

可能な限りアラートを統合

• データセンターのケージゾーンは不要な動きを感知する多数のセンサーでモニタリングされていますが、振動による誤検知を排除するために2つのセンサーが作動した場合にのみアラートがトリガーされるようにしました。

一般的なシナリオを考慮してタイミングのしきい値を調整

• パッチのデプロイやホストのリビルドのため、サービスの各インスタンスをモニタリングすると、通常のオペレーションにおいて多くのアラートがトリガーされる可能性があるため、これを考慮して各アラートのタイミングのしきい値を調整しました。

必要に応じてアラートを一時的に無効化

• 許可を得たサイトへの訪問が行われる際に物理的なセキュリティ侵害のアラートは不要です。  このアラートを無効化することで、急いでアラートを確認して解決する手間が省けました。

以上のプロセスを実践したところ、アラート件数が大幅に減少したうえ、トリガーされたアラートは実際に役立つものばかりになりました。その結果、スタッフのモチベーションが向上し始め、「疲れ切った」表情を見る機会が少なくなりました。運用のサポートに費やす時間が減り、サービスの信頼性やそれを取り巻くインフラストラクチャの改善に、より多くの時間をかけられるようになったのです。

結果的に、アラートの調整に費やした労力と時間は有益でした。カスタマーベースが拡大するなか、Certainly はログとモニタリングの高まるニーズにこれまで以上に対応できるようになりました。