ベストプラクティスの概要

オブザーバビリティは、成熟したツール群を持つ幅広いトピックです。しかし、すべてのツールがすべてのソリューションに適しているわけではありません。

オブザーバビリティの要件、設定、最終的なデプロイメントを進めていく上で、オブザーバビリティ戦略に関する意思決定プロセスの参考となる 5 つの重要なベストプラクティスをまとめました。

重要なものをモニタリングする

オブザーバビリティで最も重要な考慮事項は、サーバー、ネットワーク、アプリケーション、顧客ではありません。それは、あなた、ビジネス、プロジェクト、またはユーザーにとって重要なものです。

まずは成功基準から始めましょう。例えば、e コマースアプリケーションを運営している場合、成功の指標は過去 1 時間の購入数かもしれません。非営利団体の場合は、月間目標に対する寄付金額かもしれません。決済プロセッサーは取引処理時間を監視し、大学は学生の出席率を測定したいかもしれません。

ヒント

成功の指標は誰にとっても異なります！ここでは e コマースアプリケーションを例として使用していますが、あなたのプロジェクトは全く異なる測定基準を持つかもしれません。しかし、アドバイスは同じです：良い 状態がどのようなものかを知り、それを測定してください。

アプリケーションの種類に関係なく、まずは主要な指標を特定することから始める必要があります。そして、そこから Working Backwards¹ して、アプリケーションやインフラストラクチャの観点からどのような影響があるかを確認します。例えば、Web サーバーの CPU 使用率が高くなることで顧客満足度が危険にさらされ、結果として売上に影響を与えるのであれば、CPU 使用率のモニタリングは重要です！

目標を理解し、測定しましょう！

重要なトップレベルの KPI を特定したら、次はそれらを追跡・測定する自動化された方法を持つことです。 ワークロードの運用を監視するのと同じシステムでこれを行うことが、成功の重要な要因となります。 e コマースワークロードの例では、以下のようになります：

• 売上データを時系列として公開する
• 同じシステムでユーザー登録を追跡する
• ユーザーの Web ページ滞在時間を測定し、（同様に）このデータを時系列にプッシュする

ほとんどの顧客は既にこのデータを持っていますが、オブザーバビリティの観点からは必ずしも適切な場所に配置されているわけではありません。 売上データやユーザー登録データは、通常、リレーショナルデータベースやビジネスインテリジェンスのレポーティングシステムで見つけることができます。 また、訪問時間のデータは、ログやReal User Monitoringから抽出できます。

メトリクスデータの元の場所やフォーマットに関係なく、時系列として維持する必要があります。 ビジネス、個人、学術、その他の目的に関わらず、最も重要なすべての主要メトリクスは、他のオブザーバビリティデータ（シグナルやテレメトリとも呼ばれる）と相関付けるために、時系列形式である必要があります。

図 1: 時系列の例

コンテキスト伝播とツールの選択

ツールの選択は重要で、問題の運用と修復方法に大きな違いをもたらします。 しかし、最適とは言えないツールを選択することよりも、基本的なシグナルタイプすべてに対してツールを選ぶことの方が重要です。 例えば、ワークロードから基本的なログを収集しているものの、トランザクショントレースが欠けている場合、そこにギャップが生じます。 その結果、アプリケーション体験全体の一貫した視点が失われます。 最新のオブザーバビリティのアプローチは、すべてアプリケーショントレースによって「点と点を結ぶ」ことに依存しています。

システムの健全性と運用の全体像を把握するには、ログ、メトリクス、トレースを収集し、相関分析、異常検知、ダッシュボード、アラームなどを実行するツールが必要です。

備考

オブザーバビリティソリューションの中には、上記のすべての機能を含まないものもありますが、それらは既存のシステムを補完、拡張、または付加価値を提供することを目的としています。 いずれの場合も、オブザーバビリティプロジェクトを開始する際には、ツールの相互運用性と拡張性が重要な考慮事項となります。

すべてのワークロードは異なりますが、共通のツールを使用することで迅速な結果が得られます

すべてのワークロードで共通のツールセットを使用することには、運用上の摩擦やトレーニングを減らすなどの利点があり、一般的にツールやベンダーの数を減らすよう努めるべきです。 そうすることで、既存のオブザーバビリティソリューションを新しい環境やワークロードに迅速にデプロイでき、問題が発生した際の解決時間も短縮できます。

ツールは、基本的なインフラストラクチャ、アプリケーション、Web サイト、およびその間のすべてのレイヤーを観察できるほど広範なものである必要があります。 単一のツールでは対応できない場合、オープンスタンダードでオープンソースのツールを使用することがベストプラクティスです。これにより、最も広範なクロスプラットフォーム統合の可能性が得られます。

既存のツールとプロセスとの統合

一から作り直す必要はありません！「円」は既に素晴らしい形であり、データサイロではなく、常に協調的でオープンなシステムを構築すべきです。

• 既存の ID プロバイダー (Active Directory や SAML ベースの IdP など) と統合します。
• 既存の IT トラブルトラッキングシステム (JIRA や ServiceNow など) がある場合は、それと統合して問題が発生した際に迅速に対応できるようにします。
• 既存のワークロード管理やエスカレーションツール (PagerDuty や OpsGenie など) がある場合は、それらを活用してください！
• Ansible、SaltStack、CloudFormation、TerraForm、CDK などの Infrastructure as Code (IaC) ツールは、すべて優れたツールです。これらを使用してオブザーバビリティを他のすべてのものと同様に管理し、現在使用している Infrastructure as Code ツールと同じものでオブザーバビリティソリューションを構築してください (Day One からオブザーバビリティを含める を参照)。

自動化と機械学習の活用

コンピュータはパターンを見つけることが得意で、データがパターンに従っていない場合も見つけることができます！ 監視するデータポイントが数百、数千、あるいは数百万にもなる場合、それぞれの正常なしきい値を理解することは不可能です。 しかし、多くのオブザーバビリティソリューションには、データのベースラインを設定する手間のかかる作業を管理する異常検知と機械学習の機能が備わっています。

これを「正常な状態を知る」と呼んでいます。 ワークロードを徹底的に負荷テストしている場合は、これらの正常なパフォーマンスメトリクスをすでに把握しているかもしれません。 しかし、複雑な分散アプリケーションでは、すべてのメトリクスのベースラインを作成することは扱いにくい場合があります。 ここで、異常検知、自動化、機械学習が非常に重要になります。

アプリケーションの健全性のベースライン設定とアラートを代行して管理するツールを活用することで、目標に集中し、重要なものを監視することができます。

ワークロードのすべての階層からテレメトリを収集する

アプリケーションは単独で存在しているわけではありません。ネットワークインフラストラクチャ、クラウドプロバイダー、インターネットサービスプロバイダー、SaaS パートナー、そしてあなたの管理下にある、またはない他のコンポーネントとの相互作用は、すべてあなたの成果に影響を与える可能性があります。

ワークロード全体を包括的に把握することが重要です。

統合に焦点を当てる

計装する領域を 1 つ選ぶとすれば、それは間違いなくコンポーネント間の統合になります。これは、オブザーバビリティの力が最も顕著に表れる部分です。原則として、あるコンポーネントやサービスが別のコンポーネントやサービスを呼び出す際には、少なくとも以下のデータポイントを測定する必要があります：

1. リクエストとレスポンスの所要時間
2. レスポンスのステータス

そして、オブザーバビリティが必要とする一貫性のある全体的なビューを作成するために、収集されるシグナルには、リクエストチェーン全体の単一の一意な識別子を含める必要があります。

エンドユーザーエクスペリエンスを忘れずに

ワークロードの完全な把握には、エンドユーザーの体験を含むすべての層での理解が必要です。 空きディスク容量や CPU 使用率の監視と同様に（あるいはそれ以上に）重要なのは、ユーザーエクスペリエンスの低下によってサービス目標が危険にさらされる可能性を測定、定量化、理解することです。

Web サイトやモバイルアプリケーションなど、エンドユーザーと直接やり取りするワークロードの場合、Real User Monitoring は、ユーザーへの「ラストマイル」配信だけでなく、実際のアプリケーション体験も監視します。 結局のところ、ユーザーがサービスを実際に利用できなければ、オブザーバビリティの取り組みは意味をなしません。

データは力なりですが、細かいことは気にしすぎないようにしましょう

アプリケーションの規模によっては、シグナルを収集すべきコンポーネントが非常に多くなる可能性があります。 シグナルの収集は重要で有用ですが、その労力に見合わない場合もあります。 そのため、ベストプラクティスとしては、重要なものをモニタリングする ことから始め、これを重要な統合やクリティカルなコンポーネントのマッピングに活用し、適切な詳細に焦点を当てることです。

Day One からオブザーバビリティを組み込む

セキュリティと同様に、オブザーバビリティは開発やオペレーションの後付けであってはいけません。 ベストプラクティスは、セキュリティと同様にオブザーバビリティを計画の早い段階で組み込むことです。 これにより、人々が作業するためのモデルが作成され、アプリケーションの不透明な部分が減少します。 主要な開発作業が完了した後にトランザクショントレースを追加するには、自動計装を使用しても時間がかかります。 その労力は大きな見返りをもたらします！ しかし、開発サイクルの後半でこれを行うと、手戻りが発生する可能性があります。

オブザーバビリティをワークロードに後から組み込むのではなく、作業を 加速 するために活用してください。 適切なログ、メトリクス、トレースの収集により、アプリケーション開発が迅速化され、優れたプラクティスが促進され、将来の迅速な問題解決の基盤が築かれます。

Footnotes

1. Amazon では、お客様とその成果に対する徹底的なこだわりを持つ方法として、Working Backwards プロセスを広範に使用しており、オブザーバビリティソリューションに取り組む誰もが同じ方法で自身の目標から逆算して作業することを強くお勧めします。Working Backwards の詳細については、Werner Vogels のブログをご覧ください。 ↩