RSS DEV コミュニティ
フォロー
CloudWatchからOTelへ：オブザーバビリティブリッジパターンの解体
CloudWatchからOpenTelemetryへのブリッジパターンは、AWSメトリクスを統一されたオブザーバビリティバックエンドに統合する必要がある金融プラットフォームで一般的に使用されるソリューションです。その主な目的は、AWSサービスから外部システムにメトリクスを転送することで、断片化されたオブザーバビリティを解決することです。このパターンでは、通常、AWSサービスがCloudWatchにメトリクスを発行し、それがCloudWatch Metric Streamsによってキャプチャされるか、GetMetricData API経由で取得されます。これらのメトリクスは、Lambda関数またはOpenTelemetry CollectorによってOpenTelemetry形式に変換され、DatadogやGrafanaのようなオブザーバビリティバックエンドに送信されます。
しかし、この「明白な」ソリューションには隠れた複雑さが伴います。特に、メトリクスの鮮度とAPIコストが重要な高ボリュームの金融環境では顕著です。このパターンには2つの主要な取り込みパスがあります。Kinesis Firehoseを備えたCloudWatch Metric Streamsは、低レイテンシと予測可能なコストを提供しますが、GetMetricDataによるポーリングは、きめ細かな制御を提供しますが、APIレート制限に達するリスクがあり、高コストが発生する可能性があります。堅牢な変換Lambdaは、冪等性があり、外部エンドポイント用のサーキットブレーカーを含み、アラーム付きのデッドレターキューを備えている必要があります。
このパターンは、外部のOTLP対応バックエンドが必要な場合、メトリクス量がストリームコストに見合う場合、そして60秒以下のメトリクス鮮度SLOが必要な場合に適しています。また、オブザーバビリティをAWSから分離し、トレースとメトリクスの相関を可能にします。セキュリティは最重要であり、リソース条件付きの厳格なIAMポリシー、転送中のデータのKMS暗号化、および制御されたネットワークエグレスが必要です。避けるべきアンチパターンには、単純なポーリング、適切なエラー処理や予約済み同時実行機能を持たないLambda関数、およびこのメトリクス中心のブリッジを介してログやトレースを転送しようとすることなどが含まれます。適切に設計された実装は、ストリームレベルでのメトリクスのフィルタリングを優先し、効率的なバッファリングを使用し、ブリッジ自体をオブザーバビリティのために計装し、厳格なセキュリティ対策を採用します。
