コンテナ・サーバーレスの本番運用で失敗しないための監視・オブザーバビリティ（可観測性）設計

コンテナの「環境を問わず同じように動く」安心感と、サーバーレスの「インフラを意識せずコードを書くだけでいい」身軽さ。これらはモダンなシステム開発において、開発やリリースのスピードを飛躍的に向上させる武器となります。

しかし、これらのメリットに意識が向く一方で、監視や運用設計が後回しにされてしまうと、本番運用の障害発生時に重大な課題に直面するケースが懸念されます。

コンテナはローカル環境で動作できても、本番環境においては動的なリソース管理やネットワークの運用設計が必要となります。またサーバーレスは、コードは書きやすいものの、非同期処理の連鎖による分散環境での状態把握が難しいという、構築時のメリットとは別の次元の難所が存在するためです。

本記事では、AWSの代表的サービスであるAmazon Elastic Container Service (Amazon ECS)（コンテナ）とAWS Lambda（サーバーレス）を例に挙げながら、プラットフォームを問わず通用する監視の設計思想と、オブザーバビリティを「後付けの運用対処」ではなく「システム設計の不可欠な一部」と再定義し、本番環境で安定稼働させるための実践的なアプローチを解説します。

この記事を読んで判断できるようになること

1. コンテナ・サーバーレス環境に適した「ログ」「メトリクス」「トレース」の設計
2. 「意味のあるアラート」と「単なるノイズ」を設計段階で区別する方法
3. 非同期処理を含むサービス間でリクエストを横断的に追跡する仕組みの設計

なぜ運用設計が重要か

よくある3つの失敗パターン

本番運用において、監視・運用設計が不十分なままリリースされたシステムでは、以下のような3つの課題に陥りがちです。

• ログの氾濫とノイズ化: 収集基盤に大量のデバッグログや構造化されていないテキストログが出力され、障害時に検索を実行しても、ノイズに埋もれて肝心の原因が見つかりにくい。
• 障害の原因箇所が特定できない: システムエラーの発生自体は検知できるものの、それがどのコンポーネントで起きたのか、関連性を追跡する術がない。
• 監視アラートの形骸化: 閾値設定や監視項目の吟味が甘く、一時的なスパイク（急激な負荷上昇）や低優先度の警告アラートが日常的に発生する。「またいつものアラートか」と運用メンバーに見過ごされるようになり、重大な障害の予兆を見逃す原因となってしまう。

よくある失敗が起きる背景

こうした問題が生じる背景には、いくつかの共通した傾向が見受けられます。

プロジェクトのライフサイクルにおいて、開発フェーズと運用フェーズで担当者やチームが分かれるケースでは、運用要件が初期設計の段階で十分に議論されないことがあります。また、開発スケジュールが逼迫している局面では、「監視設計」の優先度が相対的に下がりやすい傾向もあります。

加えて、コンテナやサーバーレスがもたらすインフラの抽象化により、従来の仮想マシン運用で培った「ホスト単位での静的なリソース監視」の感覚がそのまま適用しにくくなっていることも、設計の見直しが必要になる一因として挙げられます。

設計の起点：「何を検知したいか」から逆算する

可観測性を支える三本柱の役割分担

オブザーバビリティ（可観測性）を高め、システムの状態を正しく把握するには、「ログ」「メトリクス」「トレース」の三本柱の特性を理解し、役割を分担させることが欠かせません。

これらは個別のツールとして機能させるのではなく、1つの障害事象に対して「メトリクスで異常の規模を検知し、トレースでボトルネックの場所を特定し、ログで詳細な発生原因を裏付ける」という相乗効果を生むように設計することで、本番運用において初めて意味のある監視となります。

特定のベンダーに縛られない標準規格の重要性

現代の運用設計では、特定の監視ベンダーの仕様に依存しない「OpenTelemetry」のような業界標準のフレームワークが広く採用されています。ログ・メトリクス・トレースを統一的な仕様で収集することで、将来的なプラットフォームの移行やツールの変更にも柔軟に対応できる強固なシステム基盤を構築できます。

「何を検知したいか」を先に決める

監視設計において、「目的」を考えずに、監視ツールのダッシュボード構築やエージェントの導入といった「手段」から入ると、「とりあえず全データを取得する」設定になりがちです。これはインフラコストの急増やアラートノイズの温床となります。

設計の正しい順序は、ビジネス要件からの逆算です。

1. 検知したい状態を定義する: サービス品質の評価基準となる指標（SLO）や目標値（SLI）としてビジネス影響（例：「注文APIのエラー率が1%を超えている」「決済APIのレスポンスタイムが3秒を超えている」）を定義します。
2. 必要なシグナルを決める: その状態を検知するために、どの定量指標を監視し、どのログやトレースで詳細を追跡するかを決定します。
3. 収集・集約方法を決める: 必要なシグナルをどのように収集・集約するかを決定し、構成定義として落とし込みます。

【重要】初期フェーズでのスコープとコストコントロール 

新規サービスの場合、ログ・メトリクス・トレースのすべてを最初から最大出力で有効化する必要はありません。特に詳細なコンテナメトリクスや分散トレースは、データ転送量やアクティブトレース数に応じてインフラコストが増大しやすく、全体のコストに大きな影響を与えます。

• 初期フェーズ（ローンチ直後）: ビジネス影響に直結する主要な定量メトリクスと、構造化されたアプリケーションログの収集に絞ることで、コストを最適化しながら運用の軸を確立します。
• 成長フェーズ（トラフィック増加・機能拡張期）: サービス間の連携が複雑化し、ボトルネックが不透明になった段階で、トレースや詳細メトリクスを段階的に有効化していきます。

この段階的なアプローチを取ることで、無駄な監視コストの発生を防ぎつつ、運用状況に最適化されたオブザーバビリティを手に入れることができます。

AWSサービスを使った運用設計

ここからは、AWSの代表的サービスであるAmazon ECSとAWS Lambdaを例に、前半で示した設計思想を具体化します。

Amazon ECSはDockerコンテナをマネージドなクラスター上で実行するサービス、AWS LambdaはイベントドリブンなFaaS（Function as a Service）プラットフォームであり、現代のクラウドアーキテクチャにおいてコンテナ・サーバレス運用を支える強力な組み合わせです。

前述したオブザーバビリティの三本柱をAWSで実現する際の対応サービスは次のとおりです。

これらのサービスを適切に設定し、本番環境に耐えうる統合的な監視設計を構築するためのポイントを解説します。

コストと品質のトレードオフ

オブザーバビリティの向上は運用上のメリットが大きい反面、設計を誤るとインフラコストの急増を招きます。特にログ収集やリクエストの追跡はデータ流量に応じた従量課金モデルであるため、コストと品質のトレードオフを意識した設計が重要になります。

• ログ取り込みの最適化：念のためすべてのデバッグログを常時転送するという設計は、高トラフィック環境においてはインフラコストの中で無視できない割合を占めるようになります。
• トレースサンプリングの制御：サンプリングレートも設定を間違えると高トラフィック環境では膨大なデータ量を生成し、コストを引き上げる原因となります。仮に月間1億リクエストを超えるような環境でX-Rayのフルサンプリング（100%）を有効にすると、数百ドル規模の追加コストが毎月発生することになります。

【重要】サンプリングと保存期間の最適化

開発環境と本番環境でサンプリングルール（データを抽出する割合）を明確に分けます。また、ログの保存期間はデフォルトの「無期限」ではなく、システム監査要件やトラブルシュートに必要な期間（例: 本番環境は30日間、開発環境は7日間）に絞り、自動で制限することが推奨されます。

Amazon ECS（コンテナ）

Amazon ECSを用いたシステムでは、コンテナがホストの詳細から抽象化される一方、複数のタスクが同一基盤上で実行されるため、障害発生時にタスク（コンテナ）単位でログとリソース消費を分離して追跡できる設計が重要になります。

ログルーティング思想：価値と鮮度による仕分け

本番運用においては、すべてのログを一律に共通のログ基盤（CloudWatch Logs）へ流すのではなく、ログの「鮮度」と「用途」によって送信先を仕分ける高度な設計が必要です。

専用のログ配信の仕組み（AWS FireLensなど）を活用することで、以下のような最適化を実現できます。

• エラー・警告ログ: リアルタイムな通知や迅速なトラブルシュートが必要なため、即時性に優れた保管先にルーティングし、アラート検知の対象とします。
• 正常ログ（情報・アクセスログなど）: リアルタイム性は不要ですが、後日の分析や法的証跡として必要なログは、より安価なストレージへ直接配信します。これにより、運用効率を落とさずにデータ管理コストを大幅に削減できます。
  （例.CloudWatch LogsをバイパスしてAmazon Kinesis Data Firehose経由でAmazon S3へ直接配信）

リソース監視のベースライン設計

Amazon ECSタスクのCPUやメモリを監視する際、絶対値で閾値を設定すると、パフォーマンスチューニングや負荷対策でコンテナの予約値を変更するたびに閾値の見直しが必要になり、運用が複雑になります（例: 「使用メモリが2GBを超えたらアラート」）。

したがって、監視は予約値に対する「使用率」をベースに設計します。相対的な割合（%）に対して静的閾値アラートを設定することで、タスクサイズが変更されても監視定義を修正しなくて済む、柔軟な運用体制を実現できます（例: 「使用メモリ80%超が5分継続したらアラート」）。

【重要】アラート設計の標準化

サービス数が数十・数百と増えていくと、各チームがその都度独自に閾値を決めてしまい、同じビジネス重要度のサービスでも監視の粒度がバラバラになりがちです。これは障害対応にあたる運用担当者の認知負荷を高め、アラート疲れ（Alert Fatigue）や検知漏れの温床になるため、サービスごとに個別の閾値を設定するのではなく、ビジネス影響度に応じた共通の閾値基準を定め、IaCでコード化して統一的に適用することが重要です。

AWS Lambda（サーバーレス）

AWS Lambdaのようなサーバーレス（FaaS）環境ではサーバーが存在しないため、従来の「サーバーの死活監視」という概念はそのまま適用しにくくなります。AWS Lambdaの実行環境は最長15分と短命であり、ミリ秒単位で起動と破棄が繰り返されるためです。

短命な実行環境における「健全性」の定義

常時実行環境が起動していないAWS Lambdaでは「動いていないこと」を直接検知するのが難しいため、以下の指標を中心に健全性を定義します。

• 呼び出し回数とスロットリング（過負荷による実行制限）: エラーの有無だけでなく、「期待通りにイベントを処理できているか」を重視します。たとえば、前段のキューにデータが滞留しているにもかかわらず呼び出し回数がゼロである場合、トリガー自体の設定ミスや権限不足（データの読み込みエラー）を即座に疑うことができます。
• エラー率: 単一のエラー数ではなく、呼び出し総数に対するエラーの「割合」で監視を行うことで、一時的なスパイクによる過検知を防ます。

ビジネス要件から逆算した「遅延許容値」の設計

サーバーレス環境における最大の懸念点の一つが、初回起動時の遅延（コールドスタート）です。しかし、すべての環境でこれを完全に排除するために事前プロビジョニング（あらかじめ実行環境を起動しておく設定）を行うと、常時起動のECSコンテナと同等以上の追加コストが発生してしまいます。

ここでの意思決定の軸は、「ユーザー体験を損なわない境界線はどこか」という判断です。

• ユーザー対面API: 遅延の許容値が極めて低いため、アクセスの大半（例えば全体の99%：P99レイテンシー）が許容時間内に収まっているかを監視し、必要最小限の同時実行数をプロビジョニングします。
• 非同期のバッチ・キュー処理: コールドスタートに伴う数秒の遅延がビジネス上問題にならないため、過剰な対策は不要とし、実行時間の平均値の推移を緩やかに監視するに留めます。

【重要】コールドスタート対策のROI

AWS Lambdaで事前に環境を確保して待機させるProvisioned Concurrencyは時間課金であるため、インフラ予算に与える影響が大きくなります。レイテンシ感度が低いバックエンド処理についてはコールドスタートを許容し、その代わりに関数の実行時間の異常な長期化（タイムアウト間近）を検知するアラート設計にリソースを割くことが効果的です。

統合監視：サービス境界を越える「責任」の設計

「点」の監視から「線」の追跡へ

コンテナとサーバーレスが混在するシステムにおいて、障害調査を困難にするのは「サービス境界でのコンテキスト（文脈）の分断」です。

たとえば、Amazon ECS上のWebアプリケーションがリクエストを受け取り、メッセージキューを経由して非同期にAWS Lambdaが後続処理を実行する構成を考えてみましょう。

Amazon ECSとAWS Lambdaはそれぞれ独立したコンピューティング環境であり、何も対策を講じなければ、ログやメトリクスは単なる独立した「点」の監視情報に終始します。

この「点」を「線」として繋ぐ手段が、サービス間で追跡用の識別子（トレースID）を伝播させる分散トレースです。サービスが独立していてもユーザーのリクエストは一つであるため、通信の境界において「誰が識別子を引き継ぐ責任を持つか」を設計段階で明確にする必要があります。

【重要】非同期境界での追跡識別子の伝播 

メッセージキューなどの非同期通信を介してサービス間で文脈を繋げるには、送信側で業界標準の追跡識別子（トレースコンテキスト）をメッセージの属性情報に含め、受信側でそれを読み取るという共通の実装ルールが必要です。これにより、システムがどれだけ複雑に分散しても、一本のつながった「線」として処理を追跡可能になります。
（トレースコンテキストとして、W3C Trace Context準拠の traceparent、またはX-Ray形式の x-amzn-trace-idを使用）

具体例：処理のバトンを渡す仕組み（SQSを介したコンテキスト伝播）

インフラとアプリケーションコードの協調によって境界を跨ぐ追跡を実現します。

バックエンドの追跡基盤と連携させる場合、Amazon ECS側のアプリケーションからメッセージを送信する際、現在の処理の識別子を一意のデータとしてメッセージの属性情報（メタデータ）に埋め込んで送信します。

受信側のAWS Lambdaは、この属性情報から識別子を取り出し、自身の処理の親情報として設定します。これにより、Amazon ECSとAWS Lambdaが同一のトレースIDを共有し、境界を越えた正確な追跡が可能となります。監視ツールの画面上でも、処理の流れが一本の視覚的なマップ（システム全体のつながり）として表示されるようになります。

運用者のためのコンテキスト設計

本番運用において障害が発生した際、運用者がコンテナのログとサーバーレスのメトリクス、処理追跡ツールの間を何度も往復するのは極めて非効率です。これを解決するのが、トレースIDをすべての監視データ（ログ、数値指標、処理追跡）の「共通言語」とするコンテキスト設計です。

JSON形式で構造化されたログフォーマットの中に一意の識別子を含めることで、ログ検索基盤において1つの識別子を軸にAmazon ECSとAWS Lambdaのログを横断検索し、そこから該当リクエストの全体トレースをシームレスに引き当てられるようになります。複数のツールを行き来する無駄な時間を削減し、原因究明に集中できる環境を整えることこそが、優れた監視設計の価値と言えます。

設計の「形骸化」を防ぐために

なぜ「設計」を早期に言語化すべきか

ログフォーマットやトレースIDの伝播といった監視設計は、開発フェーズの後期やリリース直前に「とりあえず設定する」ものとして扱われがちです。しかし、実装が進んでからログ出力処理やエラーハンドリングを書き直すコストは、初期段階で設計するのに比べて指数関数的に増大します。

明確な設計を持たない監視は、開発メンバーの増減や時間経過に伴い、「不安だからとりあえず全部出力する」「念のためすべてのアラートを即時通知する」といった無秩序な状態を招きます。結果として、本当に重要な「システムが正常に動作しているか」というシグナルが埋もれ、監視機能そのものが形骸化してしまいます。そのため、開発の初期段階で「何を監視し、何を捨て、どう通知するか」の設計を言語化し、共通認識にしておくことが不可欠です。

アーキテクチャレビューに組み込むべき「合意形成」リスト

コンテナ、サーバーレスを跨いだ監視設計を実効性のあるものにするため、アーキテクチャレビューの段階で以下の4点について合意を形成しておくことを強く推奨します。

• 共通言語の必須化：サービス間を跨いでリクエストを追跡するための必須ログフィールド（識別子など）の名称とデータ型の標準化。
• データのライフサイクル基準（コストと鮮度のバランス）：トラブルシューティングに必要な直近ログ（例：30日間）は高鮮度・高機能な保管先に配置し、監査や長期分析用のログは速やかに安価なストレージへアーカイブする仕分けルールを定義します。
• 通信境界における責任の明確化：各通信境界（API Gateway、Amazon ECS、キュー、AWS Lambdaなど）において、どのコンポーネントが識別子を生成し、どのコンポーネントがそれを伝播させるかの責任を定義します。
• 「健全」のビジネス基準定義：CPUやメモリの閾値といった単純なシステムメトリクスではなく、ビジネスKPI（エラー率、レスポンスタイム）に基づき、緊急対応が必要な「要即時対応」から、翌営業日の確認でよい「情報アラート」までのアラート優先度を定義します。

インフラ定義（IaC）を「設計思想のガードレール」にする

設計思想を合意しても、手動でアラームやダッシュボードを設定していては、時間の経過とともに設定が乖離し、属人化してしまいます。監視設計における意思決定は、インフラの構成をコードで管理する仕組み（IaC）のプロセスそのものに組み込む必要があります。

アラームの閾値やログの保持期間を設定する際、単に数値をコード化するだけでなく、「なぜその値なのか」という設計思想（根拠）をコードの定義と密結合させることが重要です。

具体的には、アラームをトリガーする評価期間の設定において、「瞬間的なスパイクによる誤検知（アラート疲れ）を防ぐため、複数回連続で閾値を超えた場合のみとする」といった運用上の意図や、閾値そのものの算出根拠を、インフラの設定コード内にコメントや定義として明確に残しておきます。

このように、閾値設定の背景にある運用判断や設計思想をコード自体と一体化させることで、設定の意図がドキュメントとして担保されます。結果として、後任の担当者が意図を正確に理解した上で、システムの成長に合わせた安全な設定変更を行えるようになり、運用の属人化を防ぐ確実な仕組みとなります。

安定運用の起点は正しい設計思想

Amazon ECSやAWS Lambdaといったマネージドサービスは、インフラ運用の手離れを良くし、開発者を身軽にしてくれます。しかし、それらのサービス境界が複雑に絡み合う本番運用において、システムをブラックボックス化させないための「可観測性（オブザーバビリティ）」を担保する責任は、テックリードやアーキテクトが引き受けるべき領域です。

オブザーバビリティは後付けの運用対処ではなく、アプリケーションとインフラが本来持つべき「システム自体の状態を自ら説明できる能力」として、設計の初期段階から組み込むことが、安定した本番運用を実現する確実なアプローチです。

本文で論じた意思決定を振り返ると、すべての判断に共通する軸が浮かび上がります。

まずは「トラブル発生時、何が見えないと自分たちは困るか」というシンプルな問いから始めてみてください。

最初から完璧な仕組みを目指す必要はありません。運用に合わせて「意味のあるシグナル」を段階的に積み上げていくアプローチこそが、結果として最も堅牢で持続可能なシステム構築への近道となります。

クラウドネイティブなシステムのご相談はNCDCへ

NCDCは、AWS Lambdaのパートナー認定を取得しており、製造業から金融機関まで数多くのエンタープライズ企業に向けて、コンテナやサーバーレスを用いたシステムを構築した実績を有しています。AWSサービスを活用した先進的なソリューションを提供してきた経験と知見を活かし、クラウドネイティブなアーキテクチャ設計から、本番運用の設計・整備までを一貫してご支援可能です。

「ECSやLambdaを導入してみたものの、本番運用の監視体制や運用フローに不安がある」「オブザーバビリティ設計を体系的に導入したいが、自社リソースだけでは考慮漏れが心配」という課題をお持ちの方は、ぜひお気軽にお問い合わせください。

お客さまのシステム特性に最適な監視・オブザーバビリティの設計から実装までサポートいたします。