AWS ネイティブな Amazon CloudWatch と AWS X-Ray を使用したサーバーレスモダンアプリケーションのオブザーバビリティ

はじめに

このブログ投稿では、AWS ネイティブのオブザーバビリティツールを使用してモダンサーバーレスアプリケーションの現在の状態を測定する方法と、それを最小限の労力で開始する方法について紹介します。Amazon CloudWatch や AWS X-Ray などのツールについて確認し、これらのサービスが、ログ、メトリクス、トレースの完全なオブザーバビリティに向けたアプリケーションのインストルメント化にどのように役立つかについて見ていきます。他の AWS サービスとのシームレスな統合についてや、カスタムダッシュボード、アラーム、異常検出などのアクセス可能な追加機能をどうすれば有効にできるかを学習できます。これらはすべて、コンプライアンスやセキュリティの要件を満たしながら実現されます。開始するにあたって必要な知識があることを確認するために、AWS オブザーバビリティツールを最大限に活用するためのトレーニングオプションについて説明します。

Using AWS observability with native tools while following best practices flywheel

図 1: ネイティブツールによる AWS オブザーバビリティのベストプラクティス

次のセクションでは、さまざまなメカニズムやベストプラクティスについて説明します。

コーディングなしで簡単に開始可能

AWS オブザーバビリティツールは、サーバーレスアプリケーションのオブザーバビリティを開始するための、最も速くかつ最も簡単なオプションを提供します。それらのツールは AWS のサービスと連携するように特別に設計されており、簡単にセットアップおよび設定することができます。CloudWatch ではログの集約、メトリクスの収集、アプリケーションのトレースマップの作成を行うことができます。

AWS Lambda を使用している場合は、Amazon CloudWatch Lambda Insights を使用して関数に関するメトリクスの取得を開始します。セットアップはすぐに終わり、追加のコーディングは不要です。必要になるのは、Lambda コンソールからもしくはプログラムから、各関数の [拡張モニタリング (Enhanced Monitoring)] を有効化することだけです。これにより、呼び出し率、所要時間、エラー数などの主要メトリクスが提供され、関数のパフォーマンスに関する洞察を得られます。さらに、CPU 時間、メモリ使用量、ネットワークパフォーマンスなどのシステムレベルのメトリクスも提供されます。これらのメトリクスを可視化するために、カスタムダッシュボードを作成してニーズに合わせてデータをさらに調整することができます。以下の画像は単一の Lambda 関数のメトリクスのダッシュボードを示しています。

CloudWatch Lambda Insights dashboard monitoring performance for a single Lambda funcion

図 2: CloudWatch Lambda Insights の単一の関数 (シングルファンクション) のパフォーマンスモニタリングダッシュボード

最新のイベントをより詳細に確認する必要がある場合は、ページ下部で最新の 1,000 回の呼び出しと最新の 1,000 個のアプリケーションログをすぐに確認できます。

CloudWatch Lambda Insights invocations view

図 3: CloudWatch Lambda Insights の呼び出しビュー

特に気になる呼び出しがあり、その関連するログを確認したい場合は、Amazon CloudWatch Logs Insights ページを表示します。CloudWatch Logs Insights では、ユーザーはクエリを実行してログデータの検索や分析を行うことができます。調査したい呼び出し結果を選択すると、CloudWatch Logs Insights は結果を迅速に分析するための事前構築済みクエリを自動的に表示します。また、すぐに利用可能なクエリのセットも用意されており、必要に応じてカスタマイズすることができます。CloudWatch Lambda Insights と CloudWatch Logs Insights を一緒に使用すると、問題の根本原因を検出するまでの平均時間を短縮できます。このツールが提供する可能性を広げるには、CloudWatch Lambda Insights の使い方に関するデモをご覧ください。

CloudWatch Logs Insights query results showing a Lambda function log histogram

図 4: Lambda 関数のログのヒストグラムを示す CloudWatch Logs Insights のクエリ結果

サーバーレスアプリケーションが AWS サーバーレスアプリケーションモデル (AWS SAM) で実行されている場合は、最小限の設定でメトリクスを有効化することができます。これにより、Amazon CloudWatch Application Insights を使用して、機械学習で生成されたダッシュボードを調べ、メトリクスの異常やログエラーの検出など、モニタリング対象のアプリケーションにある潜在的な問題を明らかにすることができます。CloudWatch Application Insights の紹介デモを見て、その利点について理解を深めることができます。以下のスナップショットは、CloudWatch Application Insights により検出された Step Functions アプリケーションでの問題を、根本原因分析、およびキャプチャされたエラーログと共に示しています。

CloudWatch Application Insights dashboard showing an automatically detected issue on Step Functions application with AWS SAM

図 5: AWS SAM を使用した Step Functions アプリケーションで自動的に検出された問題を示す CloudWatch Application Insights ダッシュボード

アプリケーションが Amazon Elastic Container Service (Amazon ECS) や AWS Fargate を使用したサーバーレスコンテナを実行している場合、Amazon CloudWatch Container Insights の有効化のみでメトリクスやログの使用を開始することができます。CloudWatch Container Insights ツールを使用すると、コンテナ化されたワークロードとその基盤となるインフラストラクチャのパフォーマンスや状態をリアルタイムで可視化することができます。タスクやサービス、クラスターのレベルのメトリクスを確認できます。CloudWatch Logs Insights と統合されているため、パフォーマンスログにアクセスして詳細を調べることができます。以下の図は、クラスターのパフォーマンスを示す CloudWatch Container Insights ダッシュボードです。

CloudWatch Container Insights dashboard for ECS Fargate cluster performance metrics

図 6: ECS Fargate クラスターのパフォーマンスメトリクスに関する CloudWatch Container Insights ダッシュボード

Fargate を使用して Amazon Elastic Kubernetes Service (Amazon EKS) でサーバーレスコンテナを実行している場合にも、CloudWatch Container Insights を活用することができます。この機能を設定するには、CloudWatch エージェントもしくは AWS Distro for OpenTelemetry エージェントをインストールおよび設定します。Distro for OpenTelemetry の詳細については公式ウェブサイトをご覧ください。

CloudWatch Container Insights dashboard for EKS Fargate cluster performance metrics

図 7: EKS Fargate クラスターのパフォーマンスメトリクスに関する CloudWatch Container Insights ダッシュボード

CloudWatch Container Insights には、コンテナクラスターの論理分布をグラフィカルに表示する [コンテナマップ (Container Map)] が用意されています。メモリや CPU の使用率の異常値をすばやく識別できるように、各ノードの色はヒートマップを表しています。以下の画像では、同じクラスターに属する複数の名前空間が示されています。クラスターノードは他のノードと比較してメモリ使用率が最も高いため、黄色に変わっています。

CloudWatch Container Insights Map View for EKS Fargate cluster

図 8: EKS Fargate クラスターの CloudWatch Container Insights マップ表示

さらに、CloudWatch Container Insights には、マップ表示からリスト表示に切り替えるためのリソースビューが用意されています。このビューはメトリクスやログとシームレスに統合されています。[ログを表示 (View logs)] や [ダッシュボードを表示 (View dashboard)] をクリックすると、それぞれログやメトリクスのチャートが表示されます。以下の画像は、EKS クラスターのリソースとその CPU 使用率およびメモリ使用率のリストを示しています。

EKS Cluster Resource view showing CPU and Memory Utilization

図 9: CPU およびメモリの使用率を示す EKS クラスターリソースビュー (緑色で強調表示されているのは [ログを表示 (View logs)] ボタンと [ダッシュボードを表示 (View dashboard)] ボタンで、CloudWatch Logs Insights と特定のログまたはメトリクスビューへさらに深く移動可能)

このブログ投稿のこのセクションで見てきたすべてのツールは、AWS サービスがデフォルトで CloudWatch に公開しているメトリクスやログを扱います。これにより、コーディングを必要とせずに、最小限の労力で、アプリケーションの重要なデータポイントの収集を迅速に開始することができます。

Summary of the CloudWatch vended metrics and logs options for each of the serverless services

図 10: CloudWatch が各サーバーレスサービスに提供するメトリクスとログのオプションの概要

次のセクションでは、カスタムメトリクス、カスタムログ、およびトレースを取得するようにアプリケーションをインストルメント化した場合に、そこから追加の洞察を得る方法について見ていきます。

ニーズに合わせたインストルメンテーションによるオブザーバビリティのカスタマイズ

アプリケーションのパフォーマンスモニタリング機能を拡張するにつれ、デフォルトのメトリクスとデフォルトのログが提供するものを超える洞察を得る必要が出てきます。AWS ネイティブのオブザーバビリティツールは、特別なニーズを満たし、カスタムメトリクスの作成やカスタムログの収集、分散トレーシングの設定を可能にします。オブザーバビリティを次のレベルに引き上げるためにアプリケーションをインストルメント化する方法を見ていきます。

AWS Lambda のインストルメント化

ログ

アプリケーションログのインストルメント化は、数行のコードを追加することで実現できます。たとえば、Node.js の場合、コンソールオブジェクトのメソッドの使用、もしくは stdout または stderr に書き込みを行う任意のロギングライブラリの使用というオプションがあります。Lambda は、追加の設定の必要なく、これらの関数ログを CloudWatch に自動的に送信します。

メトリクス

Lambda からカスタムメトリクスを収集するベストプラクティスは、EMF (Embedded Metric Format) を使用して CloudWatch Logs に非同期に公開を行うことです。EMF により、CloudWatch Logs が自動的にログからメトリクスを抽出し、アラームやダッシュボードを作成できるようになります。EMF を使用すると、実行時間を長くする PutMetricData API を Lambda 関数が呼び出す必要がなくなります。関数の実行時間を短縮することでランタイムコストが削減され、パフォーマンスが向上します。

Amazon では、EMF を簡単に使い始められるように、Node.js、Python、Java、および C# 用のオープンソースクライアントライブラリを提供しています。代わりに、定義済み JSON フォーマットに従って PutLogEvents API を使用することで、手動でログを生成することも可能です。

このLambda ロギングとカスタムメトリクスの操作に関するブログ投稿は、Lambda がデフォルトで提供する最も重要なメトリクスや、EMF を使用しカスタムメトリクスを活用してアプリケーション固有の情報を取得する方法を確認するのに役立ちます。アプリケーション固有の情報からは、ログやメトリクスを取得することで、パフォーマンス関連のデータのみに頼ることなく優れた洞察を得ることができます。

EMF の使用を開始するにあたり、AWS Serverless Observability Workshop では、Lambda での EMF によるロギングメトリクスの処理について詳しく学ぶためのハンズオンを提供しています。

トレース

Lambda での X-Ray トレースの開始は、[設定 (Configuration)] の [アクティブトレース (Active tracing)] ボタンを切り替えるか、プログラムでそれを実行するだけで行うことができます。その結果、Lambda 関数は自身をトレーシング用にインストルメント化します。トレースを下流の他の Lambda 関数や AWS サービスに伝搬させるには、コードを追加する必要があります。それには 2 つのオプションが利用可能です。

– Distro for OpenTelemetry による Lambda トレーシングの設定
– X-Ray SDK (Node.js, Python, Java など)

Powertools for AWS Lambda によるベストプラクティスの導入の簡素化および加速

開発チームには、Amazon のオープンソースプロジェクト Powertools for AWS Lambda を使用して、Lambda のオブザーバビリティのベストプラクティスを実装することをお勧めします。Powertools for AWS Lambda では、構造化ロギング、EMF メトリクス、分散トレーシング用のユーティリティが提供されているため、オブザーバビリティを実装するためのコードを簡単に記述し、ベストプラクティスを遵守することができます。

たとえば、アプリケーションログの相関 ID を実装する場合、Powertools を使うと関数のパフォーマンスに影響を与えずにそのプロセスが簡略化することができます。Powertools は Python、Java、TypeScript、.NET で利用可能です。

サーバーレスコンテナ (Fargate を使用した ECS/EKS) のインストルメント化

Amazon EKS は、Kubernetes コントロールプレーン用の CloudWatch エージェントをインストールすることなく CloudWatch Logs と統合しています。この Amazon EKS コントロールプレーンのロギングにより、監査 (audit) ログと診断 (diagnostic) ログが CloudWatch Logs に直接提供されるため、クラスターを実行する際のセキュリティを確保できます。

CloudWatch Container Insights を使用すると、Amazon ECS、Amazon EKS、AWS Fargate で実行されているコンテナ化されたアプリケーションのパフォーマンスを収集、分析、および可視化できます。Container Insights では Kubernetes podの CrashLoopBackOff エラーのような診断情報も提供されるため、問題をより迅速に切り分け、調査し、解決するのに役立ちます。

異なるソースからデータやログを収集し、それらを統合して CloudWatch Logs、Amazon S3、Amazon Relational Database Service (Amazon RDS) などの複数の宛先にルーティングするには、Fluent Bit をお勧めします。Fluent Bit は軽量のオープンソースマルチプラットフォームログプロセッサーで、Docker や Kubernetes と完全な互換性があります。また、パフォーマンスが大幅に向上するため、CloudWatch Container Insights のデフォルトソリューションとして Fluent Bit を使用することをお勧めします。

Amazon EKS 用 CloudWatch Container Insights における Fluent Bit 統合の詳細についてはこのブログ投稿をご覧ください。

次のセクションでは、ネイティブのオブザーバビリティツールを使用することですぐに利用可能なその他の機能について見ていきます。

すぐに使える高度な機能

AWS オブザーバビリティツールには、自動化されたカスタムダッシュボード、アラーム、異常検出、サードパーティツールとの統合など、すぐに使える高度な機能が搭載されています。

アプリケーションの運用における修正を行うには、アプリケーションのメトリクスに基づいて設定可能な閾値でトリガー可能な CloudWatch アラームを使用することをお勧めします。たとえば、CPU 使用率が 80% に達したら Amazon ECS クラスターをスケールアウトするようなアラームを作成することができます。

サーバーレスアプリケーションのボトルネックを特定するには、X-Ray を使用してトレース結果を視覚的に表現したトレースマップを生成することをお勧めします。それにより、エラーが発生しているノード、レイテンシーの大きなコネクション、もしくは失敗したリクエストなどを特定することができます。

以下の画像は X-Ray トレースマップ (訳注：2023 年 11 月に、X-Ray サービスマップと CloudWatch ServiceLens マップは CloudWatch コンソール上で統合され X-Ray トレースマップとなりました) の要素を示しています。このマップにより、アプリケーションの特定のノードにある問題を簡単に特定することができます。図のように Lambda 関数を選択すると、より詳細なメトリクスを取得できます。レイテンシー、リクエスト、障害のチャートが表示されます (もしくは特定のトレースの詳細やキャプチャされたログに移動するかもしれません)。これにより、マップ内で特定された問題とアプリケーションログを関連付けて、考えられる根本原因と是正方法を迅速に判断することができます。

CloudWatch ServiceLens Service Map showing the details of a Lambda function

図 11: Lambda 関数の詳細を示す X-Ray トレースマップ
(訳注：2023 年 11 月に、X-Ray サービスマップと CloudWatch ServiceLens マップは統合され X-Ray トレースマップとなりました)

特定のトレースを絞り込むには、[トレースを表示 (View traces)] に移動します。これにより、トレースのクエリとフィルタリングを行うことができる [トレース (Traces)] コンソールが表示されます。フィルタリングに応じて、一連のトレースがコンソール下部に表示されます。いずれかのトレース ID をクリックすると、選択したトレースに関するトレースマップ、セグメントタイムライン、およびログが表示されます。これは、トレース結果とログの関連付けを単一のビュー内で行い、調査中の問題の潜在的な根本原因を迅速に特定できる強力なツールです。

Trace details showing the segments time and logs in a single view for potential correlation

図 12: 単一のビューで潜在的な相関関係に対するセグメントタイムラインやログを示すトレースの詳細

この例と X-Ray トレースマップの設定方法の詳細については、Well-Architected サーバーレスアプリケーションに関するブログ投稿、もしくは One Observability WorkShop の ServiceLens セクションをご覧ください。

次のセクションでは、成果を達成する方法、コストを最適化する方法、および複数ある CloudWatch のツールの中でどこにどれだけの支出があるのか、詳細に把握する方法について詳細を把握する方法について説明します。

AWS ネイティブのオブザーバビリティツールによるコスト効率化

AWS ネイティブのオブザーバビリティツールは、長期的な契約やライセンスなしで使用を開始できる「従量課金 (pay-as-you-go)」の価格モデルを提供しています。これにより、予算にあわせてコストを柔軟に調整できます。メトリクス、ログ、トレースに対するコスト最適化オプションを見ていきましょう。

メトリクス

メトリクスを扱う際には、AWS 無料利用枠に含まれる基本的なモニタリングメトリクスがあります。Lambda の拡張モニタリングを有効にして CloudWatch Lambda Insights を使用し、ビジネスやアプリケーションのカスタムメトリクスを作成する場合には、作成されたメトリクスに関する料金が発生します。

カスタムメトリクスは時間ごとに案分計算されるため、Lambda 関数の呼び出し回数が 1 時間あたり 1 回未満の場合には、呼び出しが行われた時間に対してのみ請求が行われます。

メトリクスは設定した名前空間、メトリクス名、ディメンションセットごとに作成されます。新しい組み合わせはそれぞれ新しいメトリクスとして記録されるため、ディメンションをどの程度細かく定義するかに注意してください。

例えば、以下のプロパティを持つカスタムメトリクスを公開するとします:

Dimensions: Env=Prod, Geo=EMEA, Unit: Count, Timestamp: 2023-09-14T12:30:00Z, Value: 120
Dimensions: Env=Dev, Geo=AMER, Unit: Count, Timestamp: 2023-09-14T12:31:00Z, Value: 130
Dimensions: Env=Prod, Geo=LATAM, Unit: Count, Timestamp: 2023-09-14T12:32:00Z, Value: 93
Dimensions: Env=Staging, Geo=APAC, Unit: Count, Timestamp: 2023-09-14T12:33:00Z, Value: 91

これらはすべて一意のディメンションセットを持っているため、4 つの異なるメトリクスとしてカウントされます。

カーディナリティの高いシステムでは、カスタムメトリクスのコストを最適化するオプションの 1 つは、情報をディメンションセット以外のプロパティに保存することです。EMF (Embedded Metric Format) を使用すると、追加のプロパティをログに記録することができます。これにより、CloudWatch Logs Insights のクエリを通じてアクセス可能な、本来の高いカーディナリティのコンテキストが CloudWatch Logs に保存されます。

コスト削減のもう 1 つの機会は、定期的にはモニタリングされていないものの根本原因分析や個別のシナリオのためにはまだ必要となるようなメトリクスを特定することです。これらのメトリクスはログとしてのみ保存し、必要なときにのみクエリを実行するようにします。料金は取り込まれたログとオンデマンドで実行されたクエリに対してのみ発生し、メトリクスに対しては発生しません。あとでそれらのログのメトリクスを有効にする必要がある場合は、メトリクスフィルターを使用すればログデータからメトリクスを生成することができます。必要な時間だけこの機能を有効化してからそのあとでメトリクスフィルターを削除すれば、不要なカスタムメトリクスの使用やコストを回避できます。

ログ

CloudWatch ログのコストを最適化するには、ログ取り込み料金が最も高いロググループに注目します。これにより、ログレベルを評価し、必要に応じて調整することで料金を最適化することができます。この AWS ナレッジセンターの記事の手順に従って、コストの多いロググループを特定してください。

ログの保存ポリシーを最新に維持しておくことは、ログアーカイブの不要なコストの削減につながります。デフォルトでは、CloudWatch ログ保持ポリシーは「失効しない (Never expire)」に設定されているため、ログを無期限に保持する必要がない場合は、この設定を変更する必要があります。このブログ投稿は、ロググループの保持ポリシーを自動的に更新し続ける方法を紹介しています。

CloudWatch Logs Insights でクエリを実行すると、スキャンされるデータのサイズに応じて料金が発生します。そのため、分析コストを削減するには、クエリを短時間で実行するようにしてください。

トレース

AWS X-Ray トレースのコストを最適化するには、アプリケーションや環境ごとに適切なサンプリングルールを選択します。広範囲にわたるトレースでは月額コストが増加するため、サンプリングレートを引き上げるかどうかを判断するには、ユースケースごとに評価を行う必要があります。たとえば、開発環境のように一般的にはトラフィックが少ない環境では、潜在的な問題を捉えるためにサンプリングレートを高く設定することが費用対効果の高い選択肢となる可能性があります。トラフィックの多い環境では、サンプリングレートを低くしても、潜在的な問題を捉えるには十分なデータが得られます。

AWS 請求コンソールツール

請求サイクルの終了前にコストの急増や変化を認識しておくと、タイムリーな是正措置を講じることができます。CloudWatch と X-Ray の請求アラートを設定すると、料金が特定の目標予算を超えた場合にアラームが送られます。

コストが増加した場合、AWS では CloudWatch の料金を把握するためのコストと使用状況レポート (CUR) を提供しています。これにより、詳細を把握してコストの増加原因を特定し、必要に応じて調整を行うことができます。AWS ではコストと使用状況レポートを使い始めるための CUR ライブラリを提供しています。このライブラリには CloudWatch コストに対するクエリサンプルが含まれています。

次のセクションでは、CloudWatch ネイティブツールを活用して、さまざまな標準や要件への準拠を維持しながらセキュリティ体制を改善する方法について説明します。

コンプライアンス、セキュリティ、およびデータ保護

CloudWatch のコンプライアンスやセキュリティにおける重要な側面は、AWS のさまざまなコンテナ化されたマイクロサービスやサーバーレスアプリケーションからログとメトリクスを収集・集約・要約できることです。Container Insights は、Amazon ECS、Amazon EKS、Amazon Elastic Compute Cloud (Amazon EC2) 上の Kubernetes プラットフォーム、および Lambda 関数の CloudWatch ログで利用できます。このデータを一元管理することで、CloudWatch ダッシュボードを使用してインフラストラクチャやアプリケーションの包括的かつ統合されたビューを維持できるようになり、潜在的なセキュリティ脅威やコンプライアンス違反の検出や対応が容易になります。

ここで、お客様が他の AWS サーバーレスサービスと共に CloudWatch をどのように活用したかに関するケーススタディをいくつかご紹介します。

トムソン・ロイター: Amazon CloudWatch を使用してフェイルオーバー時間を 30 分から 3 分に短縮

Indusface: サイバーセキュリティプロバイダー Indusface は、AWS 上のビジネスクリティカルなアプリケーションに対して 99.99% のアプリケーションファイアウォール稼働時間を保証します

CloudWatch はまた、トラフィックの異常な急増やリソース使用率、コンプライアンス管理やセキュリティモニタリングのためのAPI 呼び出しパターンなど、特定の閾値や条件が満たされた場合に、リアルタイムの通知や自動応答を提供します。このプロアクティブなアプローチにより、潜在的なセキュリティリスクがより重大な問題に発展する前にそれを特定および是正することができます。さらに、CloudWatch は AWS リソースの設定を継続的にモニタリングし記録するサービスである AWS Config との統合をサポートしており、全体的なコンプライアンス体制を評価し、確立済みのベースラインからの逸脱を検出するために必要な可視性や洞察を提供します。

堅牢な分散トレーシングシステムである X-Ray は、リクエストとレスポンスに対するエンドツーエンドの可視性を提供することで、開発者がサーバーレスアプリケーションをリアルタイムに分析およびデバッグし、クラウドのコストとパフォーマンスの両方のメトリクスをモニタリングできるようにします。ただし、アプリケーションデータへのこのレベルのアクセスには、厳格なセキュリティ対策とコンプライアンス標準への遵守が必要です。

CloudWatch と X-Ray は、堅牢なアクセス制御メカニズムによる複数の保護レイヤーを実装することでデータのセキュリティを保護します。AWS Identity and Access Management (IAM) を使用すると、誰が CloudWatch や X-Ray のデータにアクセスして特定のアクション (アラームの作成や変更、メトリクスやトレースの表示、ログへのアクセスなど) を実行できるかを指定する詳細なアクセス許可やポリシーを定義できます。このきめ細かなアクセス制御により、権限のある人のみが機密データにアクセスできるように制御できるため、不正アクセスや潜在的なデータ侵害のリスクが軽減されます。

CloudWatch と X-Ray はいずれも、保存時と転送中の両方のデータの暗号化をサポートしており、AWS Key Management Service (AWS KMS) を活用して機密情報を不正アクセスから保護し、データセキュリティに関する業界のベストプラクティスを確実に遵守します。CloudWatch と X-Ray はまた、HIPAA、SOC、PCI などを含む複数の AWS コンプライアンスプログラムの一部でもあります。CloudWatch のコンプライアンスとセキュリティの使用についての詳細は、AWS 全般のリファレンスの Amazon CloudWatch のコンプライアンス検証、Amazon CloudWatch のセキュリティ、AWS X-Ray のコンプライアンス検証および AWS X-Ray でのセキュリティをご覧ください。

コンプライアンスとセキュリティの議論をする上では、データ保護についてもよくテーマに上がります。CloudWatch ログデータ保護は、パターンマッチングと機械学習モデルを使用して機密データを検出するのに役立ちます。CloudWatch Logs は、マネージドデータ識別子を使用することで、クレジットカード番号や金融、医療、AWS シークレットキー、デバイスの IP アドレスや MAC アドレス、特定の国や地域のパスポート番号などの PII や PHI のデータを検出できます。

CloudWatch ログ内の機密データを検出するには、データ保護ポリシーを作成する必要があります。ポリシーを設定すると、以下のように CloudWatch ロググループで機密データの検出とカウントを確認できるようになります。

Sensitive data detected in CloudWatch Logs

図 13: CloudWatch Logs で検出された機密データ

ここで、CloudWatch Logs Insights を使用してロググループにクエリを実行すると、以下の図にあるように機密データがマスクされていることがわかります。ここでは、顧客の氏名、電子メール、クレジットカードのみがデータ保護ポリシーで機密データとして設定されています。

CloudWatch Log Insights ‘Masked’ Sensitive data

図 14: CloudWatch Logs Insights の「マスクされた」機密データ

データ保護の実装の詳細については、CloudWatch Data Protection workshop をご覧ください。

最後のセクションでは、CloudWatch、X-Ray、および AWS ネイティブのオブザーバビリティについて詳しく学び、お客様とお客様のチームを次のレベルに引き上げるために利用できるさまざまなオプションについて説明します。

開始方法 – アクセス可能なトレーニングリソース

CloudWatch と X-Ray の学習をより簡単かつアクセスしやすいものにするために、AWS では以下のリソースを提供しています。

CloudWatch と X-Ray の公式ドキュメントは、非常に重要な出発点となります。このドキュメントには CloudWatch の包括的な概要、その機能、およびサービスの開始方法が記載されています。ドキュメントは最新の変更や改善を反映するように定期的に更新され、ユーザーが常に最も正確で最新の情報を得られるようにしています。

AWS Skill Builder の AWS Observability コースでは、モニタリングの核となる原則、CloudWatch を使用してアラームを生成する方法、およびメトリクスを可視化し分析する方法について掘り下げています。

よりソーシャルかつ協調的なアプローチを好む学習者には、AWS re:Invent、AWS Summit、AWSome Day などの AWS イベントに参加することは非常に有益です。これらのイベントは、CloudWatch、X-Ray、その他の AWS サービスの最新の進歩について学び、ワークショップに参加し、他の専門家とのネットワークを築く機会を提供します。さらに、AWS ユーザーグループに参加したり、AWS デベロッパーコミュニティなどのオンラインフォーラムに参加したりすることで、学習者は最新のトレンド、ベストプラクティス、実際のユースケースについて常に情報を得ることができます。

AWS トレーニングと認定は、開発者、アーキテクト、運用などの様々な役割にあわせた複数のコースを備えた有料のクラスルームトレーニングアプローチであり、学習者が自分の職務に関連する知識とスキルを確実に習得できるようにします。AWS トレーニングと認定のクラスはさまざまな言語で世界中で提供されており、トレーニングプログラムとサービスは AWS の専門家によって構築されています。

AWS トレーニングパートナー (ATP) は、既にトレーニングパートナーを配置している場合や、オンデマンドのクラスルームやデジタルサービスにトレーニングパートナーを組み込みたい場合の代替手段となるものです。ATP は AWS が作成したトレーニングを提供するために AWS により選ばれており、AWS にクラウドネイティブアプリケーションを移行もしくは構築するスキルの開発に役立ちます。

ハンズオン学習には、AWS ソリューションアーキテクト主導のものもセルフペースのものもあります。AWS One Observability Workshop や EKS Observability では、AWS リソースのデプロイやセットアップに関する包括的なステップバイステップガイドを取り扱っています。

ベストプラクティスや FAQ を確認するには、Practices FAQs – Amazon CloudWatch や AWS X-Ray – FAQ をご覧ください。

最後に、CloudWatch Quick Start は CloudWatch や X-Ray などのクラウドネイティブのオブザーバビリティツールがインフラストラクチャ、サーバーレス、アプリケーションモニタリングなどでどのように機能するかについてのすべての学習およびトレーニングリソースにアクセスするためのワンストップガイドになっています。

まとめ

AWS ネイティブのオブザーバビリティツールは、オブザーバビリティへの取り組みとベストプラクティスの採用に向けた最速かつ最も簡単な道筋を提供します。CloudWatch と X-Ray が提供する統合およびすぐに使用できる機能により、サーバーレスアプリケーションをゼロから理解するためのツールが手に入ります。ワークロードが成長するにつれて、AWS オブザーバビリティツールには、サーバーレスデプロイの複雑さを簡素化し、アプリケーションのさまざまな領域が望みどおりの結果をもたらしているかどうかを確認するためのカスタマイズに必要な機能が備わっています。これらはすべて、各業界セグメントのセキュリティや規制を遵守しながら実現されます。AWS オブザーバビリティツールを使い始めるために、リソースやオンラインコース、ブログ投稿、ハンズオンワークショップが豊富にあります。それらはチームが自信や知識を得てアプリケーションパフォーマンスやビジネス目標を改善するのに役立ちます。

著者について

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。

Amazon Web Services ブログ