OCI Application Performance Monitoring (APM)

解決する課題

メトリクスやログが「個々のリソースの状態」を教えてくれるのに対し、APM は「1 つのリクエストがシステム全体をどう通り抜けたか」を教えてくれます。マイクロサービス構成では 1 回の API 呼び出しが多数のサービス・DB・外部 API にまたがるため、どこで遅延・失敗したかをログだけで突き止めるのは困難です。

• ユーザーから「画面が遅い」と言われたが、どのサービス・どの処理が遅延の原因かを切り分けたい
• マイクロサービスをまたぐ 1 リクエストの**呼び出し経路（誰が誰を呼んだか）**を可視化したい
• エラーがどのサービスのどの操作で発生し、上流にどう波及したかを追いたい
• 本番にアクセスが来る前から、外形監視（合成監視）でエンドポイントの可用性・応答時間を計測したい
• 計装を OpenTelemetry など標準規格で統一し、ベンダーロックインを避けたい

主要概念と用語

• トレース（Trace）: 1 つのエンドツーエンドのリクエスト全体を表す単位。複数のスパンで構成され、固有のトレース ID で識別される。AWS X-Ray の「トレース」に相当
• スパン（Span）: トレースを構成する個々の処理区間（例: HTTP リクエスト 1 回、DB クエリ 1 回）。開始時刻・所要時間・親子関係・属性を持つ。X-Ray の「セグメント／サブセグメント」に相当
• コンテキスト伝播（Context Propagation）: サービス間の呼び出しでトレース ID／スパン ID を HTTP ヘッダー等で受け渡す仕組み。これにより別々のサービスのスパンが 1 本のトレースに連結される
• スパン属性（Tag／Attribute）: スパンに付与するキー値情報（URL、ステータスコード、SQL の概要など）。絞り込みや分析に使う
• APM ドメイン（APM Domain）: トレース・メトリクス・モニターを格納する論理的な入れ物。データ取り込みのエンドポイントと**データキー（取り込み用／クエリ用）**を持つ
• エージェント／計装（Agent / Instrumentation）: アプリにトレースを生成させる仕組み。言語別の APM エージェント、または OpenTelemetry / Zipkin / Jaeger 互換のトレーサーで送信できる
• サービスマップ（Trace Explorer のトポロジー表示）: サービス間の呼び出し関係と各経路のレイテンシ・エラー率を図示したもの。X-Ray の「サービスマップ」に相当
• 合成監視（Synthetic Monitoring）: 実ユーザーを待たず、定期的に外部からエンドポイントへアクセスして可用性・応答時間を測る外形監視。スクリプト型ブラウザ監視や REST モニターがある
• ブラウザエージェント（Real User Monitoring 相当）: Web ページに埋め込み、実ユーザーのブラウザ側の表示性能・操作を計測する仕組み

仕様・制限・クォータ

• トレースデータには保持期間があるため、長期のトレンド分析が必要な指標は別途メトリクス化／エクスポートを検討する。保持期間や 1 ドメインあたりの取り込みレートにはサービス上限があり、必要に応じてサービスリクエストで引き上げる
• 取り込みは APM ドメイン単位。ドメインごとに取り込み用データキーとクエリ用データキーが分かれており、アプリ側には取り込み用キーのみを配布するのが原則
• 対応プロトコル: OCI 提供の APM エージェントに加え、OpenTelemetry・Zipkin・Jaeger 形式のトレース送信に対応する。標準規格で計装すれば移行性が高い
• サンプリング: 全リクエストを送ると量・コストが膨らむため、送信側／サーバー側でサンプリング率を制御する。重要トランザクションは確実に拾い、それ以外は間引く設計にする
• リージョン単位のサービス。APM ドメインはリージョンに属し、クロスリージョンのトレースを 1 画面に集約するには各リージョンでドメインを設けるなどの考慮が要る
• 具体的な保持日数・取り込みレート・スパン数上限などの数値は変動しうるため、最新値は公式ドキュメントで確認する

内部の仕組み

APM の中核は「分散トレースの収集 → 連結 → 可視化」です。各サービスのアプリは、自身が処理した区間をスパンとして生成し、APM ドメインの取り込みエンドポイントへ送信します。サービス間呼び出しの際にトレース ID とスパン ID を伝播することで、別プロセスで生成されたスパンが 1 本のトレースとして再構成されます。

• 計装の選択肢が複数ある点が重要です。
  • OCI 提供の言語別 APM エージェントを使う（自動計装でコード変更が少ない）
  • OpenTelemetry SDK / Collector で計装し、APM の OTLP 互換エンドポイントへ送る（ベンダー非依存）
  • 既存の Zipkin / Jaeger 計装からそのまま送信する
• 取り込まれたスパンは、トレース ID で束ねられてトレースになり、親子・呼び出し順から**サービスマップ（トポロジー）**が自動構築されます。各エッジにレイテンシとエラー率が集計されます。
• 合成監視は逆方向で、APM 側のスケジューラが世界各地（または指定地点）のVantage Pointから対象 URL へ定期アクセスし、応答時間・可用性・各リソースのウォーターフォールを記録します。実トラフィックがなくても劣化を先回りで検知できます。
• トレースから抽出した指標はメトリクスとして OCI Monitoring 側へ連携でき、しきい値超えでアラームを発火させられます。

設計パターン / ベストプラクティス

• 標準規格で計装する: 可能なら OpenTelemetry で計装し、送信先だけ APM の OTLP 互換エンドポイントにする。将来の移行性とエコシステムの広さを確保できる
• 意味のある属性を付ける: スパンにユーザー種別・テナント ID・機能名などのビジネス属性を載せ、Trace Explorer でビジネス軸の絞り込みができるようにする（個人情報は載せない）
• サンプリングを戦略的に: 全件送信せず、エラー時や遅延時は確実に拾う「テールベース寄り」の考え方で、コストと可観測性のバランスを取る
• 合成監視で SLO を裏取り: 重要 API・ログイン導線などは合成モニターを複数拠点に置き、ユーザー影響が出る前に劣化を検知する
• APM と Monitoring を連携: トレースから生成した遅延・エラー率メトリクスを Monitoring のアラームに繋ぎ、Notifications でオンコールへ通知する一気通貫の経路を作る
• 取り込みキーとクエリキーを分離運用: アプリには取り込み用キーのみ配布し、ダッシュボード／API 参照にはクエリ用キーを使う。キー漏洩時の影響範囲を限定する

運用・監視

• トレースが表示されない: アプリのエージェント設定（取り込み用データキー・エンドポイント URL）が正しいか、ネットワーク経路（プロキシ・送信先ポート）が通っているか、サンプリング率が 0 に近すぎないかを確認
• トレースが途中で切れる: サービス間でコンテキスト伝播ヘッダーが転送されていないことが多い。ロードバランサ・API Gateway・メッセージキューをまたぐ箇所でヘッダーが落ちていないか点検
• 量が多すぎる／コスト過大: サンプリング率を見直し、ヘルスチェックなど高頻度・低価値のリクエストを除外する
• 合成監視がエラーを返す: スクリプトの待機・セレクタ、対象側の WAF やレート制限による弾きを確認。監視元の Vantage Point からのアクセス許可も見る
• 時刻ずれ: スパンの開始時刻がずれていると親子関係や所要時間が乱れる。各ホストの NTP 同期を確認

コスト

OCI APM の課金は概ね、取り込んだトレース／スパンの量と、**合成監視の実行回数（イベント数）**に基づく従量制です。取り込み量はサンプリング率で大きく変わるため、コスト最適化の主役はサンプリング設計になります。合成監視は実行頻度と監視拠点数が増えるほど課金イベントが増えます。

セキュリティ

• 取り込みキーの最小配布: アプリには取り込み専用キーのみを渡し、参照系にはクエリ用キーを使う。キーは Vault などで安全に管理し、コードへ直書きしない
• 機微情報をスパンに載せない: URL のクエリ文字列・リクエストボディ・SQL のパラメータに個人情報や認証情報が混入しないよう、計装側でマスキング／除外を行う
• IAM ポリシーで権限分離: APM ドメインの管理（作成・キー再生成）と、トレース参照（読み取り）を別グループに分け、最小権限で付与する
• 経路の暗号化: エージェントから取り込みエンドポイントへの送信は TLS を前提にする。プロキシ経由でも経路全体が暗号化されていることを確認する
• 役割分担を明確に: 「リクエストがどう流れ何が遅いか」は APM、「誰がどの API を操作したか」は OCI Audit、「ログ本文」は OCI Logging が担う。これらを混同しない

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 分散トレースとサービスマップにより、障害の原因サービスを短時間で特定でき、MTTR を縮められる。合成監視でユーザー影響前に劣化を検知できる
• パフォーマンス効率（Performance Efficiency）: 各スパンの所要時間からボトルネック（遅い DB クエリ・外部 API）を定量化し、最適化の優先度を根拠を持って決められる。計装を標準規格に寄せることで将来の構成変更にも追従しやすい

試験で問われるポイント

関連サービス・比較

OCI の可観測性は、トレースは APM、メトリクスとアラームは Monitoring、ログは Logging、API 操作の監査は Audit と、役割ごとに分かれています。AWS では X-Ray（トレース）に加え CloudWatch Synthetics（合成監視）・CloudWatch RUM（実ユーザー監視）が分かれており、OCI APM はこれらを横断的にカバーします。

ハンズオン / CLI例

# 1) APM ドメインを作成（トレース・モニターの入れ物）
oci apm-control-plane apm-domain create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "prod-apm-domain" \
  --description "Production tracing domain" \
  --is-free-tier false

# 2) 作成した APM ドメインの一覧を確認し OCID を取得
oci apm-control-plane apm-domain list \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "prod-apm-domain"

# 3) データキー（取り込み用 / クエリ用）を取得
#    アプリのエージェントには「取り込み用（PRIVATE_DATA_KEY 等）」のみ配布する
oci apm-control-plane data-keys list \
  --apm-domain-id "$APM_DOMAIN_OCID"

# 4) Trace Explorer に対してトレースをクエリ（直近の遅いトレースを抽出）
#    query-text は APM のトレースクエリ言語。時間範囲を指定して検索する
oci apm-traces trace-explorer-query \
  --apm-domain-id "$APM_DOMAIN_OCID" \
  --time-span-started-greater-than-or-equal-to "2026-06-14T00:00:00Z" \
  --time-span-started-less-than "2026-06-14T01:00:00Z" \
  --query-text "show traces where TraceLatency > 1000"