AWS オブザーバビリティ入門 LambdaとECSで実践するベストプラクティス

2025-05-27 AWSランチセッション 第6回 AWS オブザーバビリティ入門 ―LambdaとECSで実践するベストプラクティス― 山崎 拓也

山崎 拓也 所属: SIer 仕事: • システム開発など • アプリとAWSインフラ両方 好き: 低レイヤ、SF、AWS AWS関連: • 2024 Japan AWS Top Engineer • 2022～2024 Japan AWS All Certifications Engineer

アジェンダ • オブザーバビリティとは • AWSにおける実践方法のベストプラクティス • Lambda • ECS • まとめ

オブザーバビリティとは

システムは様々な価値を提供している

蓋を開けると複雑

様々な問題が起こる レスポンスが遅い 処理が失敗する データが遅延する

ビジネスに直接的な影響を与える ユーザー離れ レスポンスが遅い 取り返しのつかない重大インシデント 処理が失敗する 安全性や品質の低下 データが遅延する

原因を調査したり、兆候をつかむには？ 全てのログやコードを追いかける？ ベテランの勘に頼る？ いつどこで何が起こってる？ 仮説を立ててデバッグする？ 今はどういう状態なの？

原因を調査したり、兆候をつかむには？ 全てのログやコードを追いかける？ ベテランの勘に頼る？ いつどこで何が起こってる？ 仮説を立ててデバッグする？ オブザーバビリティで解決・軽減できる 今はどういう状態なの？

オブザーバビリティとは • システムの状態を外側から理解することを可能にする能力 • トラブルシューティングや対処が容易になる • 結果として • 満足度や信頼性の向上 • 機会損失の回避 • 運用コストの最適化 • システムは外部へ状態を伝える必要がある • 意味のある実用的な情報のみを発することが重要

オブザーバビリティの3本柱 ログ • イベントやエラーなどの情報 メトリクス • リクエスト数やCPU使用率などの数値 トレース • 処理の流れや所要時間

AWSにおける実践方法のベストプラクティス

Lambdaを使用したアーキテクチャ • オブザーバビリティの3本柱を実践する

Lambda Powertools • Lambda関数でベストプラクティスを実装するための公式ツールキット • オブザーバビリティのベストプラクティスも実装できる • 様々な言語に対応 • Python • TypeScript • Java • .NET https://github.com/aws-powertools

• https://github.com/aws-powertools

Lambda関数にレイヤーとして追加することで使用可能

ログをデータとして扱う • 構造化されたログを出力することがベストプラクティス • PowertoolsのLoggerを使うだけでOK 構造化されていないログ 構造化されたログ

構造化によりクエリやプログラム処理が容易になる • CloudWatch Logs Insightsでのクエリ

CloudWatch EMFでメトリクスを送信（Embedded metric format） • 日本語では埋め込みログフォーマットと言う • CloudWatch Metricsではなく、 CloudWatch Logsへメトリクスを送信する • EMFでLogsへログ出力すると 自動でメトリクスとして抽出してくれる • メリット • 非同期実行のため処理をブロックしない • コストを抑えられる EMFフォーマットの例 それなりに複雑 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html https://aws.amazon.com/jp/blogs/mt/lowering-costs-and-focusing-on-our-customers-with-amazon-cloudwatch-embedded-custom-metrics/

• https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html
• https://aws.amazon.com/jp/blogs/mt/lowering-costs-and-focusing-on-our-customers-with-amazon-cloudwatch-embedded-custom-metrics/

PowertoolsのMetricsで簡単にEMF準拠のログを出力できる ※注意 デコレーターによりLambda関数 終了後にログ出力するため、 metrics.flush_metrics()にて エラーハンドリングする必要あり

X-Rayで処理全体をトレースする • Lambda関数の設定からX-Rayを有効化すると一気通貫のトレースが可能 • X-Rayと統合されているサービス • Lambda • API Gateway • SQS • SNS • ELB • DAOT • Elastic Beanstalk • EventBridge https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-services.html

• https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-services.html

X-Rayのトレース画面 SQSを挟んだLambda以降 の処理もトレースされる リクエスト全体で4.19秒 対応するLambda関数 のログも表示される

X-Ray SDKでさらに詳細にトレースできる • PowertoolsレイヤーにX-Ray SDKも含まれている • コード内の任意の区間をトレースできる • サポートされているライブラリの関数呼び出しは自動でトレースできる • botocore, boto3 • mysql-connector-python • psycopg2 • sqlite3 • などなど この区間をトレース 1秒スリープする https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-python-patching.html

• https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-python-patching.html

X-Ray SDKによる詳細なトレース SQSやDynamoDB のAPI呼び出しもトレース 独自関数f()には 1秒かかっている

正常応答したリクエストの後ろに潜む障害も一目瞭然 APIリクエストは正常 （200）に返っている 内部では障害が起こっている トレースのおかげで原因の リクエストをすぐに特定可能 DynamoDB呼び出しの後で エラーとなっている

（補足）Application Signalsについて • Application Signalsでもトレースできる • 考慮点 • X-Ray SDKと併用できない • 特定の関数を個別にトレースすることができない • MySQLやPostgreSQLなどのライブラリの関数がトレースできない 初回のみ「サービス検出を開始」が必要 各Lambdaの設定画面

ECSを使用したアーキテクチャ • ADOT Collectorをサイドカーとしてトレースとメトリクスを収集する

ADOT Collectorとは（AWS Distro for OpenTelemetry Collector） OpenTelemetry Collectorとは • オブザーバビリティのオープンな標準としてOpenTelemetry（OTel）がある • OTel Collectorは、ログ、メトリクス、トレースを収集・処理・送信を行うコンポーネント • テレメトリデータ配信プロトコルはOpenTelemetryプロトコル（OTLP） ADOT Collectorとは • AWS Distro for OpenTelemetry Collectorの略 • AWSに最適化されたOTel CollectorのAWS公式ディストリビューション • アプリにX-Rayなどの特別なコードが不要となる • CloudWatch Logs / Metrics / X-Rayへの送信を標準サポート • サードパーティ観測ツールとの連携も簡単になる • ECRにコンテナイメージが用意されている https://aws-observability.github.io/observability-best-practices/ja/patterns/otel https://opentelemetry.io/ja/docs/what-is-opentelemetry/

• https://aws-observability.github.io/observability-best-practices/ja/patterns/otel
• https://opentelemetry.io/ja/docs/what-is-opentelemetry/

OTel SDKでトレースをADOT Collectorへ送信できる この区間をトレース 3秒スリープする

AWS SDKのAPI呼び出しは自動でトレースできる • AWSからJava用のOTel自動計装エージェントが配布されている • コード変更なしにトレース生成してくれる Dockerfile https://aws.amazon.com/jp/blogs/news/new-for-aws-distro-for-opentelemetry-tracing-support-is-now-generally-available/ https://github.com/aws-observability/aws-otel-java-instrumentation https://aws-otel.github.io/docs/getting-started/java-sdk/auto-instr

• https://aws.amazon.com/jp/blogs/news/new-for-aws-distro-for-opentelemetry-tracing-support-is-now-generally-available/
• https://github.com/aws-observability/aws-otel-java-instrumentation
• https://aws-otel.github.io/docs/getting-started/java-sdk/auto-instr

X-Rayのトレース画面 DynamoDBのトレースが 自動で取得される リクエスト全体で5.85秒 3秒スリープ

AWSからオブザーバビリティのベストプラクティスが公開されている • AWS Observability Best Practices https://aws-observability.github.io/observability-best-practices/ja/

• https://aws-observability.github.io/observability-best-practices/ja/

トピックやサービスごとに大量のベストプラクティスがある

まとめ • オブザーバビリティにより、トラブルシューティングや対処が容易になる • Lambda Powertoolsにより、ベストプラクティスに沿った計装が簡単に 実現できる • ADOT CollectorによりアプリにAWS SDKを組み込まなくとも、X-Rayや CloudWatchなどAWSサービス、さらにサードパーティ観測ツールともス ムーズに連携できる

ご清聴ありがとうございました。