この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
アノテーション テクニカルサポートの川崎です。
本記事は AWS re:Invent 2022 のセッションレポートとなります。
概要
アプリケーションの中断や運用上のインシデントに直面した場合、顧客に影響が及ぶ前に、できるだけ早く問題を解決することが重要です。 モダンなコンテナ化またはサーバーレス アプリケーションの場合、分散型の性質により、このチャレンジはさらに困難になります。 このセッションでは、モダンなアプリケーション アーキテクチャのオブザーバビリティのベストプラクティスを学びます。 AWS オブザーバビリティ サービスを使用して、アプリケーションの問題を迅速に特定、診断、修正する方法をご覧ください。
セッション動画
アジェンダ
- 1 なぜモダンなアプリケーションは観察が難しいのか?
- 2 インストルメンテーション(計測) オプションのナビゲート
- 3 高カーディナリティのコストの最適化
- 4 過剰アラームによる疲弊を緩和
- 5 宙ぶらりんトレースを回避
1. なぜモダンなアプリケーションは観察が難しいのか?
モダンなアプリケーションの複雑さ
- モノリシック アプリケーション
- サービス
- マイクロサービス
マイクロサービスは…
- どのように監視しますか?
- 疎結合
- 自立（ストレージあり）
- 独立して展開
- 水平方向にスケーリング
- さまざまな環境でホスト
- ポリグロット
- ステートレス
モダンなアプリケーションの複雑さ
- モノリシック アプリケーション
- マイクロサービス
ソフトウェアにおけるオブザーバビリティ
ソフトウェア システムでは、オブザーバビリティとは、プログラムの実行、モジュールの内部状態、およびコンポーネント間の通信に関するデータを収集、関連付け、分析する機能です。
オブザーバビリティが重要な理由
- 可視性
- リアルタイムのトラブルシューティング
- 顧客体験
- アプリケーション = $$
運用上の課題 → ビジネス課題
Everything fails all the time. (「全ては壊れる」ことを前提に)
Werner Vogels
VP and CTO, Amazon
モダンなアプリへの戦略的アプローチ
戦略的アプローチ
- AWS サーバーレス ファーストのアプローチ (AWS Lambda、AWS App Runner、Amazon ECS、AWS Fargate)
- 最初の選択肢として AWS マネージド サービスとツールを使用する
- お客様の多くは、プロビジョニング、DevOps、インフラストラクチャの自動化、セキュリティ、ネットワーキング、オブザーバビリティ/運用など、AWS に関する分野の開発に投資しています。
- 生産性と最小限の運用負担
- Lambda とコンテナを含む
- AWS 上の Kubernetes (+++) (AWS 上の Amazon EKS、Red Hat OpenShift)
- 主要なコンピューティング プラットフォーム インターフェイスとしての Kubernetes
- 多くのお客様が、Kubernetes を実行する主要な場所として AWS を選択しています
- 複数の Kubernetes クラスターとそれらのワークロードとツールの実行と管理に関する規律を採用する - GitOps などの高度なパターン
- 豊富なエコシステムとパートナー ツール
- 多くの Kubernetes のお客様は、マネージド AWS サービスや、特定のユース ケースでLambda などのその他のコンピューティング オプションを利用しています。
AWS オブザーバビリティオプション
ベストプラクティス
- インストルメンテーション(計測) オプションのナビゲート
- 高カーディナリティのコストの最適化
- 過剰アラームによる疲弊を緩和
- 宙ぶらりんトレースを回避
2. インストルメンテーション(計測) オプションのナビゲート
インストルメンテーションは責任共有です
- お客様
- カスタムメトリクス
- カスタムログ
- トレースインストルメンテーション
- AWS
- Vended metrics
- Vended logs
- Vended traces
Vended metrics
Vended metrics
Vended metrics
Vended logs
Vended traces
カスタム インストルメンテーション
- AWS Lambda
- Amazon Elastic Container Service (Amazon ECS)
- Amazon Elastic Kubernetes Service (Amazon EKS)
Lambda インストルメンテーション
LOGS
Lambda インストルメンテーション
METRICS
Lambda インストルメンテーション
TRACES
インストルメンテーション エージェント
- AWS Distro for OpenTelemetry
- CloudWatch agent
- X-Ray Daemon
- FireLens
- Fluent Bit
OpenTelemetry
- ホスト/VM/コンテナ
- OpenTelemetry コレクター
- バックエンド
インストルメンテーションの重要ポイント
SUMMARY
- 1 メトリクスとトレースに AWS Distro for OpenTelemetry (ADOT) を使用する
- 2 ロギング エージェント (CloudWatch または FireLens エージェント) を選択します。
- 3 OpenTelemetry 仕様
- トレース: GA
- メトリクス: GA
- ログ: Draft
- 4 将来的には、ログにも ADOT を使用していきます
ベストプラクティス
- インストルメンテーション(計測) オプションのナビゲート
- 高カーディナリティのコストの最適化
- 過剰アラームによる疲弊を緩和
- 宙ぶらりんトレースを回避
3. 高カーディナリティのコストの最適化
高カーディナリティ テレメトリ
高いカーディナリティの増加
高カーディナリティ テレメトリ
- VM 環境
- http_response
- 2 つの環境
- 10 サービス
- 5 つのステータス コード
- 10 インスタンス
- 1,000 の可能なメトリクス
- $300/月
- http_response
- クラウドネイティブ環境
- http_response
- 2 つの環境
- 100 サービス
- 5 つのステータス コード
- 10,000 タスク/ポッド
- 10,000,000 の可能なメトリクス
- $244,500/月
- http_response
高カーディナリティ テレメトリ
METRICS OR LOGS
- メトリクス
- クエリが速い
- アラームを駆動
- ログ
- 効率的なコスト
- 保存期間なし
- メトリクスとログのどちらかだけでなく
- 両方使用
- CloudWatch Embedded Metric Format を使用
高カーディナリティ テレメトリ
BEST OF BOTH WORLDS WITH LOGS AND METRICS
大幅なコスト削減につながる可能性
CloudWatch Embedded Metric Format のデモ
高カーディナリティ テレメトリ
SUMMARY
-
- 潜在的な高カーディナリティ ディメンションを特定する
-
- 最初にテレメトリをログとして取り込みます
-
- 次に、適切なディメンションを使用してメトリクスを作成します
-
- CloudWatch を使用している場合は、Embedded Metric Format を活用します
-
- OpenTelemetry には Embedded Metric Format エクスポーターがあります
ベストプラクティス
- インストルメンテーション(計測) オプションのナビゲート
- 高カーディナリティのコストの最適化
- 過剰アラームによる疲弊を緩和
- 宙ぶらりんトレースを回避
4. 過剰アラームによる疲弊を緩和
過剰アラームによる疲弊を緩和
METRICS OR LOGS
- メトリクス
- アラーム
高カーディナリティ テレメトリ
- VM 環境
- http_response
- 2 つの環境
- 10 サービス
- 5 つのステータス コード
- 10 インスタンス
- 1,000 の可能なメトリクス
- http_response
- クラウドネイティブ環境
- http_response
- 2 つの環境
- 100 サービス
- 5 つのステータス コード
- 10,000 タスク/ポッド
- 10,000,000 の可能なメトリクス
- http_response
過剰アラームによる疲弊を緩和
BEST PRACTICES
- 1 主要業績評価指標 (KPI) とワークロード メトリクスに関するアラーム
- 注文率
- 処理された注文数
- キューの深さ
- 2 ワークロードの結果が危険にさらされている場合に警告する
- 3 ワークロードの異常が検出された場合のアラート
- 4 イベントへの応答を自動化する
アラームを関連付ける
BEST PRACTICES
- 1 CPU 使用率が高いことは大きな警告ではありません
- 2 メモリ使用率は大きな警告ではありません
- 3 ただし、両方が同時に発生している場合は、良いアラームになる可能性があります
- 4 Microsoft IIS Web サーバーでは、これはアプリケーション プールがリサイクルされていることを意味します。
- 5 これにより、HTTP 要求の処理が一時停止され、ユーザーは気付くでしょう。
異常時のアラーム
BEST PRACTICES
- 1 統計および機械学習アルゴリズムを活用する
- 2 期待値の範囲を示す異常検出モデルを生成する
- 3 静的しきい値ではなく動的しきい値でのアラーム
- 4 メトリクスの急上昇や急降下には正当な理由がある場合があります。 誤検知は望ましくありません
CloudWatch Composite Alarms と CloudWatch Anomaly Detection のデモ
過剰アラームによる疲弊を緩和
SUMMARY
- 1 KPI とワークロード メトリクスに関するアラーム
- 2 ワークロードの結果が危険にさらされている場合に警告する
- CloudWatch Synthetic Canaries
- 3 アラームを相関させ、その相関が発生したときに人に通知する
- CloudWatch Composite Alarms
- 4 機械学習アルゴリズムを活用して異常を検出する
- CloudWatch Anomaly Detection
ベストプラクティス
- インストルメンテーション(計測) オプションのナビゲート
- 高カーディナリティのコストの最適化
- 過剰アラームによる疲弊を緩和
- 宙ぶらりんトレースを回避
5. 宙ぶらりんトレースを回避
トレースの伝播
WHAT IS A TRACEID?
トレースの伝播
HOW DOES PROPAGATION WORK?
トレースの伝播
HOW DOES PROPAGATION WORK?
トレースの伝播
HOW DOES PROPAGATION WORK?
トレースの開始
- コンテナ
- アプリケーションのインストルメンテーション
- クラウドネイティブ
- ケースによります
トレースの伝播
SERVICES THAT SUPPORT TRACING
- API Gateway
- App Mesh
- App Runner
- AWS AppSync
- Amazon EC2
- Elastic Load Balancing
- CloudWatch RUM
- EventBridge
- Lambda
- Amazon SNS
- Step Functions
- Amazon SQS
- Amazon S3
- CloudWatch Synthetics
AWS X-Ray と他の AWS のサービスの統合 - AWS X-Ray
Elastic Load Balancing
- アプリケーション ロード バランサーは、受信 HTTP 要求にトレース ID を追加します
- ロードバランサーは X-Ray にデータを送信せず、サービス マップにノードとして表示されません
Lambda
- X-Ray を有効にすると、Lambda がトレースを X-Ray に自動的に送信します
- ダウンストリーム呼び出しをキャプチャするには、Lambda 関数でインストルメンテーションが必要です
- X-Ray トレースは現在、Amazon MSK または Amazon MQ イベント ソース マッピングを使用する Lambda 関数ではサポートされていません
Amazon EventBridge
- X-Ray SDK でインストルメンテーションされたサービスがイベントを EventBridge に送信する場合、トレース コンテキストが伝達されます。
- EventBridge は、トレース コンテキストを渡した PutEvents 要求からイベントが発生した場合にのみ、イベントのトレース ヘッダーを渡すことができます。
AWS Step Functions
- ステート マシンで X-Ray を有効にすると、リクエストは Step Functions で実行されるときにトレースされます
- Amazon SNS、Amazon SQS、および AWS Lambda は、ネイティブ X-Ray サポートと統合されています
- Amazon ECS、AWS Batch、および AWS Fargate にはインストルメンテーションが必要です
トレースの伝播
HOW DOES PROPAGATION WORK?
トレース伝播のデモ
宙ぶらりんトレースを回避
SUMMARY
- 1 すべてのコードをインストルメンテーションする
- 2 トレースをサポートする AWS サービスと トレースする方法を理解する
- 3 サービスがトレースをサポートしていない場合
- サービス境界を越えてトレース コンテキストを渡す
- サービス境界の反対側でコンテキストを再開する
まとめ
- インストルメンテーション(計測) オプションのナビゲート
- インストルメンテーションの OpenTelemetry から始めます
- 高カーディナリティのコストの最適化
- メトリクスとログの両方を活用してカーディナリティを高めます
- 過剰アラームによる疲弊を緩和
- 高レベルのメトリクスの異常を関連付けて警告する
- 宙ぶらりんトレースを回避
- トレース コンテキストの伝播を確認する
7
