イベント¶
イベントとは何を意味しているのでしょうか¶
現在、多くのアーキテクチャがイベント駆動型です。イベント駆動型アーキテクチャでは、イベントは異なるシステムからの信号であり、これをキャプチャして他のシステムに渡します。イベントは通常、状態の変化や更新を表します。
例えば、eコマースシステムでは、アイテムがカートに追加されたときにイベントが発生する場合があります。このイベントはキャプチャされ、システムのショッピングカート部分に渡され、アイテムの詳細とともに、カート内のアイテム数とコストが更新されます。
Info
一部のお客様にとって、イベントは購入の完了などの「マイルストーン」である可能性があります。ワークフローの結論をまとめてイベントとして扱うことには一理あるでしょうが、今回の目的では、マイルストーン自体をイベントとは考えません。
イベントが役立つ理由¶
イベントがオブザーバビリティソリューションで役立つ主な2つの方法があります。1つは他のデータとのコンテキストでイベントを視覚化すること、もう1つはイベントに基づいてアクションを実行できることです。
Success
イベントは、ワークロードの変更やアクションについて、人やマシンのいずれかに価値のある情報を提供することを目的としています。
イベントの可視化¶
アプリケーションから直接発生しているものではないが、アプリケーションのパフォーマンスに影響を与えたり、根本原因の洞察を提供したりする可能性のある多くのイベントシグナルがあります。ダッシュボードはイベントを可視化するための最も一般的なメカニズムですが、分析やビジネスインテリジェンスのツールでもこのコンテキストで機能します。電子メールやインスタントメッセージングアプリケーションでも可視化を容易に受信できます。
たとえば、Web フロントエンドで注文を処理する時間など、アプリケーションのパフォーマンスの時系列を考えてみましょう。時系列から、応答時間が数日前に大きく変化したことがわかります。最近のデプロイがあったかどうかを知ることが役立つかもしれません。最近のデプロイの時系列を並べて表示したり、同じチャートに重ねて表示したりできると便利です。
Tip
より広いコンテキストを理解するのに役立つイベントを考えてみてください。コードのデプロイ、インフラストラクチャの変更イベント、新しいデータの追加(新しい商品の公開やユーザーの一括追加など)、機能の変更や追加(カートに商品を追加する方法の変更など)など、自分にとって重要なイベントがあるかもしれません。
Success
他の重要なメトリクスデータとともにイベントを可視化することで、イベントと運用メトリクスを相関付けることができます。
イベントへの対応¶
オブザーバビリティの世界では、アラームの発報は一般的なイベントです。このイベントには、通常、アラームの識別子、アラームの状態(IN ALARM や OK など)、発報のトリガーとなった詳細が含まれます。多くの場合、このアラームイベントが検知され、E メール通知が送信されます。これは、アラームへのアクションの例です。
アラーム通知は、オブザーバビリティにとって極めて重要です。これは、問題が発生したことを適切な人に知らせる方法なのです。しかし、イベントへの対応がオブザーバビリティソリューションで成熟するにつれ、人為的な介入なしに問題を自動的に修復できるようになります。
どのようなアクションを取るべきか?¶
まず問題の緩和に役立つアクションを理解することなく、アクションを自動化することはできません。 Observability の旅の始まりでは、これがしばしば明白でない場合があります。 ただし、問題の修復経験が豊富になるほど、既知のアクションがある領域をキャッチするようアラームを微調整できるようになります。 使用しているアラームサービスに組み込みのアクションがある場合もあれば、アラームイベントを自分でキャプチャして解決策をスクリプト化する必要がある場合もあります。
Info
水平 Pod オートスケーリングなどの自動スケーリングシステムは、この原則の実装です。Kubernetes はこの自動化を抽象化しているだけです。
アラームの頻度と解決に関するデータへのアクセスは、自動化の可能性を判断するのに役立ちます。 問題の兆候に基づく広い範囲のアラームは問題のキャプチャには優れていますが、自動修復にリンクするためにはより具体的な基準が必要になることがあります。
これを行う際は、インシデント管理/チケット/ITSM ツールとの統合を検討してください。 多くの組織では、インシデントと、関連する解決策や平均修復時間 (MTTR) などのメトリクスを追跡しています。 これを行っている場合は、自動化された 解決策も同様の方法でキャプチャすることを検討してください。 これにより、自動的に修復された問題の種類と割合を理解できるだけでなく、基礎となるパターンと問題を探すこともできます。
Tip
誰かが手動で問題を修正する必要がなかったからといって、根本原因を調べる必要がないわけではありません。
たとえば、サーバーが応答しなくなったときに再起動する場合を考えてみましょう。 再起動によりシステムの機能が維持されますが、応答不能の原因は何でしょうか。 これがどのくらいの頻度で発生するか、パターンがあるかどうか(たとえば、レポート生成や高負荷時、システムバックアップと一致するなど)を調べることで、根本原因の理解と修正に注力する優先順位とリソースが決まります。
Success
key performance indicator に関連するイベントをメッセージバスにすべて配信することを検討してください。
明示的な構成要件なしにこれを透過的に行う Observability ソリューションもあることに注意してください。
オブザーバビリティプラットフォームへのイベントの取り込み¶
重要なイベントを特定したら、次にそれらをオブザーバビリティプラットフォームに取り込む最適な方法を検討する必要があります。 プラットフォームにはイベントをキャプチャする特定の方法がある場合があります。それ以外の場合は、ログやメトリクスデータとして取り込む必要があります。
Note
シンプルな取り込み方法の 1 つは、イベントをログファイルに書き込み、他のログイベントと同じ方法でインジェストすることです。
これらのイベントをどのように視覚化できるかを調べてください。アプリケーションに関連するイベントを特定できますか? データを 1 つのチャートに組み合わせることができますか? 特定のものがなくても、少なくとも他のデータと時間軸を合わせたタイムチャートを作成し、視覚的に相関付けることができるはずです。時間軸は同じに保ち、簡単に比較できるように垂直に重ねてプロットすることを検討してください。
