シナリオ
あなたはポリグロットなマイクロサービスプラットフォームを担当しています。トレース、メトリクス、ログは存在しますが、パフォーマンスの低下が発生した際には依然としてホストごとの手動プロファイリングが必要です。チームはOpenTelemetry Profilesを使用して、CPU、off-CPU、およびヒープのデータをOTLP経由でCollectorに送信し、トレースやスパンと相関付けることを望んでいます。このシグナルは2026年にPublic Alphaとなりました。評価、パイロット運用、データパス、およびロールバック計画を設計してください。
面接官が評価するポイント
- プロファイル、ログ、メトリクス、トレースによって答えられる問いを区別できているか。
- Alpha段階の成熟度、バックエンドの準備状況、言語固有の収集ギャップを認識しているか。
- サンプリングのオーバーヘッド、ストレージコスト、機密データ、およびアクセス権限を制御できているか。
- 測定可能なパイロット運用の判定基準（ゲート）、分離境界、およびロールバックを定義できているか。
明確化のための質問
対象となる問題がCPU、メモリ、ロック待機、テールレイテンシのいずれであるか、どの言語とランタイムを対象にする必要があるか、現在のプロファイラ、SLO、サンプリングバジェット、保持期間、コンプライアンス境界を確認します。バックエンドがOTLP Profilesをサポートしているか、障害発生時にpprof、JFR、または現在のAPMを維持できるかを尋ねます。
30秒での回答
パイロット運用を実施しますが、Alphaシグナルは重要なアラートからは除外します。少数のLinuxサービスを選択し、独立したCollectorを介して低頻度で収集を行い、ベースラインとしてpprof/JFRを維持します。原因特定までの時間（Time to Diagnosis）、CPUオーバーヘッド、サンプリングカバレッジ、GBあたりのコスト、トレース相関率、マスキングの不備を測定します。バックエンド、アクセス制御、ロールバックの訓練に合格した後にのみ導入を拡大します。フォーマットやCollectorの障害が発生した場合は、リクエストトラフィックに影響を与えることなくエクスポートを停止できるようにする必要があります。
段階的な考察
1. シグナルの境界を定義する
ログは個別のイベントを記述し、メトリクスはシステムレベルの数値を記述し、トレースはリクエストのパスを記述し、プロファイルはどのコードがリソースを消費しているかを記述します。プロファイルは他のシグナルを置き換えるのではなく補完するものです。根本原因分析を短縮するために、リソース、トレース、またはスパンの識別子を介してそれらを相関付けます。
2. 収集を設計する
サンプリングプロファイラは、継続的かつ低いオーバーヘッドでスタックを定期的に記録します。インストルメンテーションプロファイラは、メモリ割り当て、ロック、ガベージコレクションなどのランタイムイベントを記録できます。まずは隔離されたノード上のeBPFエージェントまたは言語ネイティブのツールから開始し、OTLPエクスポートの前にCollectorでデータのフィルタリング、レート制限、バッチ処理、およびルーティングを行います。
3. コストとプライバシーを制御する
サービス層ごとにサンプリングレートとCPUバジェットを設定し、99パーセンタイルレイテンシの異常があるサービスを優先します。シンボル、引数、機密パスデータを制限し、テナントを分離し、生プロファイルと集約プロファイルで個別の保持期間を使用します。ドロップ率、Collectorキュー、下り（egress）帯域幅、ストレージコストを監視します。
4. Alphaリスクに対処する
公式ドキュメントではProfilesをAlphaと位置付けており、アナウンスでは本番環境対応のバックエンドがまだ登場段階にある間は、重要な本番ワークロードに使用すべきではないとされています。機能フラグ（feature flag）、独立したリソースクォータ、既存ツールのベースライン、および設定変更のみによるロールバックを使用します。単に標準化のためだけにすべての言語やバックエンドを移行してはいけません。
高品質な回答例
既存のプロファイラを即座に置き換えるのではなく、パフォーマンス診断時間の短縮に向けて最適化します。フェーズ1では、GoとJVMの2つのLinuxサービスを選択し、pprof/JFR出力を維持したまま、ベースラインの診断時間とリソースコストを記録します。フェーズ2では、低頻度のCPUプロファイリングを行う隔離されたCollectorをデプロイし、SLOやCPUの異常時のみレートを引き上げます。Collectorは環境ごとにフィルタリングし、制限を適用し、フィールドをマスキングし、本番トラフィックとは別のキューを介してOTLPをルーティングします。フェーズ3では、トレース/スパンの相関付けを有効にし、低速なスパンから原因となっているスタックに到達できるかをテストします。ゲート（判定基準）は、制限されたCPUオーバーヘッド、十分なカバレッジ、P95診断時間の短縮、許容可能な月額コスト、および機密フィールドの漏洩ゼロです。ProfilesはAlpha段階であるため、現在のバックエンドとツールを維持します。Collectorが滞留した場合、バックエンドがデータを拒否した場合、またはアクセス境界に障害が発生した場合は、エクスポートを無効にします。ビジネスリクエストがこのパスに依存することはありません。
よくある間違い
- Alpha段階のProfilesを、安定した万能の代替手段として扱うこと。
- 相関関係を説明せずに、トレース、メトリクス、またはログをプロファイルに置き換えてしまうこと。
- コストや機密性への配慮を欠いたまま、すべての生のスタックやシンボルを無期限に保持すること。
- プロファイルのエクスポートとビジネスクリティカルなキューを共有し、障害によってリクエストを遅延させてしまうこと。
- サンプリングバジェット、バックエンドの互換性、またはキルスイッチを考慮せずに「eBPFを導入する」と発言すること。
フォローアップの質問と回答
「なぜpprofやJFRを維持するのですか？」
これらをベースラインおよびフォールバックとして保持するためです。Profilesは共通モデル、OTLPパイプライン、およびシグナル間の相関付けを追加します。移行が正当化されるのは、パイロット運用でこれらの利点が証明された場合のみです。
「トレースとプロファイルをどのように相関付けますか？」
プロファイルのサンプル上でリソースおよび利用可能なtrace_idまたはspan_idのメタデータを記録し、Collectorとバックエンドを通じてそれらのフィールドを保持します。すべてのサンプルがリクエストにマッピングできるわけではないことを許容します。
「パイロット運用をどのような場合に中止しますか？」
CPU、コスト、またはプライバシーリスクが閾値を超えた場合、あるいはバックエンドの安定性がロールバック期間を維持できない場合にエクスポートを無効化します。既存のツールを維持し、シグナルが成熟した後に再検討します。