Recap Series
- セッション 02:TerraformによるAWSコンプライアンス
- セッション 03:初心者からビルダーへ――素晴らしいクラウドの旅
- セッション 04:LaravelとBrefによるチームファーストのサーバーレスエンジニアリング
- セッション 05:イベント開会式:AWS Community Day Hong Kong 2025
- セッション 06:Agent-to-Agent:AWS 上で相互運用可能な AI を構築する
- セッション 07:別のテレメトリデータを AI エージェントで活用し、改善を加速する
- セッション 08:バイブコーディングからの卒業:Kiro による仕様駆動開発
- セッション 09:MCP と AI エージェントを活用した自動テスト
- セッション 10:通信セキュリティのモダナイゼーション:機械学習を活用したアプローチ
- セッション 11:GenAIエージェントの再考:RAGとMCP
- セッション 12:TAKとAWSを活用した災害・緊急対応
- セッション 13:テストの観点からサーバーレスアプリケーションのワークフローを再考する
- セッション 14:クラウド成功のための実践的なAWS FinOps
プロファイリング入門
- プロファイラーの定義:プロファイラーはテレメトリの一種で、システムのパフォーマンス状況やシステムリソースの消費量に関する情報を提供します。
- プロファイリングの目的:プログラム内のリソース消費を調査し、一定期間における特定リソースの使用状況を統計情報として提供します。
- トレーシングとの違い:リソース消費を時系列で追跡するトレーシングとは異なり、プロファイリングは特定期間全体の統計情報を提供します。
- 代表的なプロファイリングツール:
- Java:Java Flight Recorder(JFR)
- Python:cProfile(標準ライブラリ)と line_profiler(サードパーティーツール)
- Linux:任意の実行ファイルに使用できる `perf` コマンド
パフォーマンス調査におけるプロファイリングの重要性
- 演習シナリオ:Web アプリケーションでレイテンシーの問題が発生し、クライアントから Web サーバーへのリクエストに対する応答が遅い状況を想定します。
- 目標:パフォーマンス問題の原因を特定して修正します。
- オブザーバビリティ:オブザーバビリティはログ、メトリクス、トレースと関連付けられることが多いものの、パフォーマンス問題の解決には、プロファイリングから得られる追加の知見が必要になる場合があります。
ログ、メトリクス、分散トレースの限界
- [ 1 ] メトリクス:
- 定義:メトリクスは最も一般的なテレメトリで、CPU 使用率やメモリ使用量などの情報を提供します。
- 限界:メトリクスが追跡するのは、インスタンスやサービス(Web サーバーを実行するコンテナなど)全体のリソース消費です。アプリケーション内のどの関数や実装がリソースを消費しているかは分かりません。たとえば、Web サーバーが CPU を大量に消費していることは分かっても、CPU 使用率を高めている関数までは特定できません。
- [ 2 ] 分散トレース:
- 定義:分散トレースは、システム内のレイテンシー問題に関する重要な情報を提供します。
- 限界:一般的な分散トレーシングのソリューションでは、システムやプログラムに計装が必要です。計装されていない関数については、レイテンシー情報を取得できません。すべての関数を計装するには時間がかかり、パフォーマンス問題を引き起こす可能性もあります。
- [ 3 ] ログ:
- 定義:ログは、特定の関数が特定の時刻に実行した処理に関する情報を提供します。
- 限界:ログに示されるのは、処理の正常終了やエラーメッセージだけです。関数がリクエストを正常に処理した場合、レイテンシー問題があっても成功メッセージしか記録されません。エラーが発生しない限り、ログからレイテンシー問題の原因は分かりません。
まとめ
- 問題点:ログ、メトリクス、分散トレースは有用ですが、レイテンシー問題の原因に関する完全な情報は得られません。リソース消費をより深く把握し、パフォーマンスのボトルネックを特定するにはプロファイリングが必要です。
現状と理想的な状態のまとめ
- [ 1 ] 目的:
- オブザーバビリティを活用する目的は、パフォーマンス問題の原因を特定して修正することです。
- [ 2 ] 現状:
- テレメトリの隔たり:レイテンシー問題、CPU またはメモリ使用量の急増、分散トレース全体でのレイテンシーの変化があり、ログ上では関数がリクエストを正常に処理していても、レイテンシー問題の正確な原因は特定できていません。
- [ 3 ] 理想的な状態:
- 正確な特定:パフォーマンス問題を引き起こすコード行を正確に特定し、的確に修正できることが理想です。
オブザーバビリティの定義
- 制御理論におけるオブザーバビリティ:システムの外部出力(テレメトリ)から内部状態をどの程度推測できるかを表す尺度と定義されます。
- 理想的なオブザーバビリティ:テレメトリだけで問題の正確な原因を特定できる状態が理想です。
プロファイリングの役割
- 隔たりを埋める:ログ、メトリクス、トレースでは埋められない隔たりを解消するには、プロファイリングが必要です。
- ラストワンマイルの情報:プロファイリングは、ログ、メトリクス、トレースが提供するデータからパフォーマンス問題の正確な原因へとたどり着くために必要な、最後の情報を提供します。
従来のプロファイリング利用法
- 計装:プロファイリングを利用するには、テレメトリデータを収集できるようプログラムを計装する必要があります。
- 分析:収集したテレメトリデータを分析し、パフォーマンス問題を特定して修正します。
プロファイリングのためのプログラム計装
Go
- 標準パッケージ:Go に含まれる `pprof` パッケージを使用します。
- 手順:
- `pprof` パッケージをインポートします。
- プロファイラーのインスタンスを作成します。
- プロファイラーを開始します。
- プロファイラーによる計測を停止する箇所を定義します。
Python
- ラインプロファイラー:`line_profiler` パッケージを使用します。
- 手順:
- `line_profiler` パッケージをインポートします。
- プロファイラーを有効にします。
- プロファイリング対象となる処理部分を記述します。
- プロファイラーを無効にします。
常時稼働システム向けの継続的プロファイリング
- [ 1 ] 違い:
- 単発プロファイラー:1 回の実行時間を計測します(タイマーを開始して停止します)。
- 継続的プロファイラー:設定した間隔(5 分間に 10 秒ごとなど)でプロファイルデータを定期的に取得し、外部(Amazon S3 など)に保存します。
- [ 2 ] ユースケース:
- デーモンや Web サーバーなどの常時稼働システム、特にトラフィックが急増した際の利用に適しています。
- [ 3 ] ソリューション:
- AWS:CodeGuru を使用するか、Pyroscope と組み合わせて Grafana を運用します。
- オープンソース:現在 Grafana ソリューションの一部となっている Pyroscope を使用します。
プロファイルデータの分析
- スクリーンショットの例:Pyroscope プラグインを導入した Amazon Managed Grafana で、スタックごとのリソース使用状況を統計的に表示します。
- 次のステップ:データ収集後は分析フェーズに進み、パフォーマンス問題を特定して修正します。
フレームグラフによるプロファイルデータの可視化
- フレームグラフ:プロファイルデータを可視化する代表的な方法です。
- 課題:フレームグラフの読み方を理解するには、ソースコード、可視化の意味、コンピューターサイエンスの基礎概念に関する知識が必要です。
フレームグラフの読み方
- [ 1 ] グラフの例:
- プログラムのスタック全体における CPU 使用率を可視化します。
- [ 2 ] 解釈:
- 長いバー:リソース消費量が多いことを示します。
- `sys.call.read`:読み取りを行うシステムコールで、多くの CPU を消費しています。
- `os.file.read`:物理ファイルを読み取る Go 標準ライブラリの関数で、適切かつ高性能に実装されていると考えられます。
- [ 3 ] 結論:問題は、カスタム関数(GNU Cut コマンドを模した `Cut` 関数)が `os.file.read` を非効率に呼び出している方法にある可能性があります。
関数実装の例
- `cut` 関数:GNU Cut コマンドの動作を模した関数です。
- 次のステップ:`Cut` 関数の実装を確認し、`os.file.read` の呼び出し方法に非効率な点がないかを特定します。
デモ
ファイル読み取りの非効率性
- 特定された問題:プログラムはファイルを 1 バイトずつ読み取っていました。1 バイトを読み取るたびにシステムコールが発生するため、非効率です。
- 必要な知識:これが非効率である理由を理解するには、ユーザーランドとカーネルランド、およびコンピューターサイエンスの原理に関する知識が必要です。
プロファイリングにおける AI アシスタントの役割
- AI による支援:AI アシスタント、特に大規模言語モデル(LLM)は、プロファイルデータの解釈に役立ちます。
- 運用との相性:運用では、問題の特定など出力が小さく決定性が高いうえ、システム仕様、テレメトリデータ、ログといった豊富なコンテキストを利用できるため、LLM は開発よりも運用に適しています。
- 開発と運用の違い:開発では、結果が不確定な大量のソースコードを生成する必要があるため、LLM との相性は運用ほど良くありません。
プロファイルデータと AI アシスタントの活用
- デモ:AWS の社員が AI アシスタントを使用してプロファイルデータとソースコードを分析し、パフォーマンス問題を特定します。
- プロセス:
- [ 1 ] AI アシスタントにプロファイルデータとソースコードの分析を依頼します。
- [ 2 ] アシスタントは、プロファイルデータを可視化するツールが必要だと判断します。
- [ 3 ] 承認を受けると、アシスタントは関数ごとの CPU 使用率を可視化し、問題の原因となっている関数を正確に特定します。
- [ 4 ] アシスタントはコード行ごとの CPU 使用率を示し、改善策を提案します。
まとめ
- プロファイルデータ:パフォーマンス問題を実際のコード改善につなげる鍵となります。
- 従来の分析:システムとコンピューターサイエンスに関する深い知識が必要です。
- AI による支援:プロファイルデータを活用してその利用方法をユーザーに説明し、開発を加速します。
