Anti-patterns and common pitfalls

スタートアップ企業は、厳しい時間と予算の制約の中で可観測性を導入することが多く、その時点では適切に感じられるパターンに陥りやすいものの、時間の経過とともにコストがかかり脆弱になることがあります。

これらのアンチパターンは、スタートアップに焦点を当てた経験と顧客インサイトから導き出されたものですが、あらゆる規模の企業に広く適用できます。

オブザーバビリティを一度限りの取り組みとして扱う

オブザーバビリティを明確な終了日を持つ有限のプロジェクトとして位置付けると、古くなったダッシュボード、ずれたアラームやサイレントアラーム、新しいサービス、環境、AWS アカウントが導入されるにつれて不完全なカバレッジにつながります。オブザーバビリティは、アーキテクチャの進化、デプロイメントパターン、変化するビジネス要件とコンプライアンス要件に結びついた定期的なレビューと反復的な改善を伴う、永続的な機能として管理する必要があります。

段階的なクロール・ウォーク・ラン アプローチに従わない

初期段階で非常に複雑な可観測性スタックを設計すること、たとえばマルチリージョン、マルチテナントのテレメトリパイプラインに広範なカスタムエンリッチメントとルーティングを組み込むことは、ビジネス価値が証明されていない状態で、大きな運用オーバーヘッドと認知的負荷をもたらします。スタートアップは、まずメトリクス、ログ、トレース、サービスレベルアラートの最小限かつ堅牢なベースラインを確立し、その後、ワークロードの複雑さとトラフィックが追加投資を正当化するにつれて、段階的に高度な機能を導入する必要があります。 

明確な目的なしに大量のテレメトリを収集する

スタートアップは、明確なオブザーバビリティの目標を定義し、テレメトリ収集をその目標に限定し、サンプリング、集約、フィルタリング戦略を適用して、監視の深さとパフォーマンスおよびコストのバランスを取る必要があります。

定義された可観測性のユースケースなしに、すべてのログ、メトリクス、トレースを完全な忠実度で取り込むと、過度なカーディナリティ、クエリパフォーマンスの低下、高いストレージおよび取り込みコストが発生します。特に高スループットの AWS ワークロードではその傾向が顕著です。たとえば、不要なラベル (詳細なリクエスト ID や動的なユーザー識別子など) を削減またはフィルタリングすることで、カーディナリティを制御できます。これにより、取り込みとストレージの費用が削減されるだけでなく、クエリが高速化され、ダッシュボードが簡素化されるため、システムの規模拡大に伴ってより持続可能な可観測性が実現されます。

単一のオブザーバビリティベンダーへの早期なロックイン

初期段階でインストルメンテーションライブラリ、データスキーマ、ランブックを単一のオブザーバビリティベンダーに結合すると、移行リスクが増加します。また、データ量が増加するにつれて、コストとアーキテクチャの柔軟性が制限されます。

技術的および経済的な選択肢を維持するために、スタートアップは、インストルメンテーションとデータ転送に OpenTelemetry のようなオープン標準に従うマネージドサービスの使用を開始する必要があります。ポータブルなテレメトリスキーマを採用し、複数または代替のバックエンドにデータを送信するオプションを維持する必要があります。この柔軟性により、早期にコスト効率の高いオプションへの簡単な移行が可能になり、規模と予算の変化に応じて、オブザーバビリティツールの再設計、階層化、または多様化が容易になります。

OpenTelemetry SDK とエクスポーターを使用してメトリクス、ログ、トレースを送信することで、サービスは同じテレメトリストリームを現在は Amazon CloudWatch または Application Signals に送信でき、必要に応じて、アプリケーションコードではなくコレクターまたはエクスポーターの設定を変更することで、後で別のバックエンドに送信できます。たとえば、OpenTelemetry でインストルメント化されたチェックアウトサービスは、OpenTelemetry データを AWS Distro for Open Telemetry コレクターに送信し、日常的な運用のために CloudWatch に、また Amazon S3 のような特殊な長期ストレージ用の代替エンドポイントに展開できます。これにより、スタートアップ企業はベンダー API やテクノロジーにロックインされることなく、また大規模な再インストルメンテーション作業を行うことなく、オブザーバビリティアーキテクチャを進化させることができます。

ツール中心ではなくカルチャー中心の可観測性モデルの採用

Amazon CloudWatch、AWS X-Ray、またはサードパーティの APM (Application Performance Monitoring) 統合などのサービスや機能を単に有効にするだけでは、エンジニアリングチームがコードパスを積極的に計装し、ワークフローでテレメトリを使用しない限り、効果的なオブザーバビリティは得られません。エンジニアリングチームは、オブザーバビリティを開発および運用プラクティスに組み込む必要があります。これには、ヘルスシグナルの定義と所有、ダッシュボードとアラートのインシデント対応とランブックへの組み込み、テレメトリを使用した設計、キャパシティプランニング、インシデント後のレビューへの情報提供が含まれます。 

テレメトリとメタデータ標準のガバナンスの欠如

各チームが独立してメトリクス名、ラベルセット、ログフォーマット、トレース属性を定義することを許可すると、サービスや環境をまたいで結合、クエリ、相関付けが困難な断片化されたデータセットが生成されます。組織は、標準化された命名規則、必須のディメンション (サービス、環境、リージョン、テナントなど)、共通ライブラリとテンプレートを介して実装される共有スキーマを含む、テレメトリガバナンスを確立し、実施する必要があります。

顧客中心およびユーザーエクスペリエンス指標の軽視

CPU、メモリ、ディスクメトリクスなどのインフラストラクチャレベルのシグナルに主に焦点を当て、ユーザー中心のビジネス KPI を省略すると、インシデントの実際の顧客への影響が不明瞭になります。たとえば、API はホストレベルでは正常に見えても、e コマースアプリケーションのチェックアウトやオンボーディングなどの主要なフローでレイテンシーの上昇、タイムアウト、エラー率の増加により、顧客は劣化したジャーニーを経験する可能性があります。これらのシグナルは、ユーザーエクスペリエンスに関連付けられた、ファーストクラスのサービスレベルおよびビジネスレベルの SLO としてモデル化する必要があります。

定義されたデータ保持および階層化ポリシーの欠如

ログとメトリクスのデフォルトまたは無制限の保持期間に依存すると、ストレージと分析のコストが制御不能に増大し、時間の経過とともにクエリとダッシュボードのパフォーマンスが低下する可能性があります。スタートアップは、テレメトリクラスごとに段階的な保持ポリシーを定義する必要があります。たとえば、インシデント対応用の短期的な高解像度データ、長期的なトレンド分析用のダウンサンプリングまたは集約されたメトリクス、規制、運用、コスト要件に沿って古いデータをアーカイブまたは削除するライフサイクルルールなどです。