Amazon CodeGuru Profiler 完全ガイド v2.0

本番環境継続プロファイリング・End-of-Life対応・最新異常検知

ドキュメントメタデータ

• 最終更新: 2026-04-26
• バージョン: v2.0
• 対象者: Java/Python 開発チーム、DevOps エンジニア、パフォーマンスチューニング責任者
• 難易度: 中級～上級
• ⚠️ 重要: End-of-Life 2025-04-30 予定（Q Developer Operations / X-Ray Profiler への移行推奨）
• 関連サービス: X-Ray、DevOps Guru、CloudWatch、Lambda、EC2、ECS

概要と課題

本質

Amazon CodeGuru Profiler は 「本番環境のアプリケーションパフォーマンスを継続的にプロファイリングするフルマネージドサービス」 である。Java・Python・.NET アプリケーションに軽量エージェント（オーバーヘッド 2% 未満）を組み込み、CPU 使用率・ヒープメモリ・メソッド実行時間をリアルタイムで記録。フレームグラフで最もコストのかかるコード行を可視化し、機械学習による異常検出で パフォーマンス劣化を自動通知する。

⚠️ 重要: 2025-04-30 の End-of-Life に伴い、AWS は以下への移行を推奨しています：

• X-Ray Profiler: CloudWatch との統合強化・リアルタイムメトリクス
• Q Developer Operations: 生成 AI による根本原因分析・自動チューニング提案
• CloudWatch Application Signals: SLO ベースの自動スケーリング推奨

このサービスを選ぶ理由

なぜ Amazon CodeGuru Profiler なのか？

1. 本番ワークロードでの継続的なプロファイリング

   • 開発環境のプロファイラーは本番トラフィック・リクエストパターンを再現できないが、Profiler は実運用中の EC2・Lambda・ECS で 2% 未満のオーバーヘッドで継続プロファイリング
   • 実際のボトルネック（JSON シリアライズ・DB クエリ・GC 遅延）を本番環境で特定

2. コスト削減との直結

   • フレームグラフで「CPU の 35% をこのメソッドが消費している」という定量データを取得
   • 最も効果的なコード最適化箇所に開発者が集中できる
   • EC2・Lambda コストの削減は最終的にアプリコード最適化に帰結

3. X-Ray との相補性

   • X-Ray: リクエスト単位のサービス間トレース・レイテンシ特定
   • Profiler: メソッド / 関数レベルの CPU・メモリ使用を詳細に特定
   • 両者を組み合わせることでレイヤー全体のパフォーマンス最適化が可能

4. 機械学習による異常検出

   • 過去 2 週間のベースラインから統計的異常を自動検知
   • 閾値設定不要で「GC が通常の 3% → 28% に跳上」を自動通知
   • PagerDuty・SNS で即座にアラート可能

5. マルチ環境対応・低コスト

   • EC2・ECS・EKS・Lambda・オンプレミスに統一エージェント
   • 月 100 時間無料・その後 $0.005/Compute Hour
   • Datadog・New Relic Profiler より低コスト

このサービスを選ばない理由

• End-of-Life 2025-04-30 → 新規採用は Q Developer Operations / X-Ray Profiler を検討
• Go・Rust・Node.js が必須 → X-Ray Profiler / 言語別プロファイラーを優先
• リアルタイム IDE プロファイリング → IDE 統合プロファイラー（JetBrains、VS Code）
• メトリクス長期保持（6+ 年） → CloudWatch Application Insights

アーキテクチャと設計原則

全体構成図（Mermaid 1）

graph TB
    subgraph AppLayer["アプリケーション層"]
        Java["Java/JVM Apps"]
        Python["Python Apps"]
        DotNET[".NET Apps"]
    end
    
    subgraph AgentLayer["エージェント層"]
        JVMAgent["JVM Agent<br/>(javaagent)"]
        PythonLib["Python Library"]
        DotNETAgent[".NET Agent"]
    end
    
    subgraph SamplingLayer["サンプリング層"]
        Sampling["5分ごと集計<br/>Overhead < 2%"]
    end
    
    subgraph ProfilerService["CodeGuru Profiler"]
        Storage["Profile Storage<br/>(180日保持)"]
        ML["ML Anomaly Detection<br/>(2週間ベースライン)"]
        Viz["Flame Graph / Charts"]
    end
    
    subgraph NotificationLayer["通知層"]
        SNS["SNS Topics"]
        CloudWatch["CloudWatch Alarms"]
        EventBridge["EventBridge Rules"]
    end
    
    Java --> JVMAgent
    Python --> PythonLib
    DotNET --> DotNETAgent
    
    JVMAgent --> Sampling
    PythonLib --> Sampling
    DotNETAgent --> Sampling
    
    Sampling --> Storage
    Storage --> ML
    Storage --> Viz
    
    ML --> SNS
    ML --> CloudWatch
    ML --> EventBridge

プロファイリングフロー（Mermaid 2）

sequenceDiagram
    participant App as アプリケーション
    participant Agent as CodeGuru Agent
    participant Service as CodeGuru Service
    participant Console as Web Console
    
    App->>Agent: メソッド実行・CPU/メモリ使用
    Agent->>Agent: 5分ごとにサンプリング
    Agent->>Service: プロファイルデータ送信
    Service->>Service: フレームグラフ生成
    Service->>Service: ML で異常検出
    Service->>Console: ダッシュボード表示
    Console->>Console: 開発者が確認・最適化判断

コアコンポーネント

1. プロファイリンググループ（Profiling Group）

アプリケーションの論理的な単位。
同じアプリだが異なるデプロイ環境（本番・ステージング）
→ 異なるプロファイリンググループで管理

例:
- prod-api-profiling-group (本番 API)
- staging-api-profiling-group (ステージング)
- lambda-batch-processor (Lambda 関数)

設定項目：

• 名前・説明
• Compute Platform (Default=EC2/ECS/EKS、AWSLambda)
• Anomaly Detection の有効化
• 通知設定（SNS・CloudWatch）

2. Flame Graph（フレームグラフ）

横幅 = CPU 時間のシェア
縦軸 = コールスタック（下が呼び出し元、上が呼び出し先）

    ┌────────────────────────────────────┐ 100% CPU
    │           main()                   │
    ├────────────────────┬───────────────┤
    │  processRequest()   │ loadConfig()  │ 85%
    ├────────┬───────────┤               │
    │ dbQuery│ parseJSON │               │ 60%
    └────────┴───────────┴───────────────┘

インタープリテーション：
- dbQuery(): CPU の 30% を占有 → SQL 最適化・インデックス追加
- parseJSON(): CPU の 15% を占有 → JSON ライブラリ変更・バッチ処理化
- loadConfig(): CPU の 10% を占有 → キャッシング導入

3. Anomaly Detection（異常検出）

機械学習ベースの異常検出メカニズム：

Phase 1: Learning（最初の 2 週間）
    CloudWatch メトリクスから正常パターンを学習
    → ベースライン確立

Phase 2: Detection（2 週間以降）
    現在のメトリクスが統計的に異常か判定
    → スコア付け（Critical / High / Medium / Low）

検出例:
    通常: GC(ガベージコレクション) = CPU の 3%
    異常: GC = CPU の 28%
    → 推奨: Heap Size 増加 / Object Pool 実装

4. Recommendations（推奨事項）

自動生成されるアクション提案:

✓ CPU ホットスポット検出
  「UserService.serialize() が CPU の 45% を消費」
  推奨: Protocol Buffers / MessagePack への変更

✓ メモリリーク検出
  「Heap が毎時 200MB 増加」
  推奨: WeakReference / Object Pool 導入

✓ GC 最適化提案
  「Full GC が毎分 1 回発生」
  推奨: Heap Size 増加 / GC パラメータ調整

✓ 関数呼び出し最適化
  「同じ計算を毎回実行」
  推奨: メモイゼーション / キャッシング

5. Profiling Data Retention

保持期間: 180 日（6 ヶ月）
追加費用: なし（ストレージ コスト込み）

アクセス:
- Console ダッシュボード: リアルタイム
- API (get-profile): JSON / 外部ツール連携
- 自動削除: 180 日後

主要ユースケース

1. Lambda 関数の実行時間短縮

シナリオ: Lambda 関数が Cold Start 後に 8 秒かかる

Profiler で検出:
  - JSON deserialize: 3.2 秒
  - DB query: 2.8 秒
  - 計算処理: 1.5 秒

対応:
  → JSON ライブラリを Jackson → Gson に変更（1.2 秒削減）
  → RDS コネクションプールを設定（0.8 秒削減）
  → 計算を SIMD ライブラリで最適化（0.4 秒削減）
  
結果: 8 秒 → 2.6 秒（67% 削減）

2. EC2 インスタンス最適化

シナリオ: m5.xlarge 1 台が月 $100 のコスト

Profiler で検出:
  - CPU 平均 35% 使用率
  - メモリ平均 28% 使用率
  - Network 平均 12% 使用率

対応:
  → m5.large に変更（スペック 50% 削減）
  → Profiler で 28 日監視 → CPU 35%・メモリ 30% 維持確認

結果: $100 → $50（月 $50 削減）

3. ECS タスク スケーリング最適化

シナリオ: ECS Fargate サービス・メモリ 4GB 設定・CPU 2vCPU

Profiler で検出:
  - Heap 使用率: 平均 1.5GB、ピーク 2.2GB
  - GC 時間: 全体の 4%

対応:
  → メモリを 4GB → 3GB に変更（$0.05/時間削減）
  → CPU を 2vCPU → 1vCPU に変更（$0.04/時間削減）

結果: 月 72 ドル削減（10 タスク × 720 時間）

4. マイクロサービス間のボトルネック特定

シナリオ: マイクロサービス アーキテクチャ・全体レイテンシが 500ms

Profiler + X-Ray 組み合わせ:

X-Ray: リクエストフロー
  ServiceA (100ms) → ServiceB (250ms) → ServiceC (150ms)

Profiler (ServiceB):
  - DB クエリ: 180ms
  - JSON 変換: 45ms
  - キャッシュ判定: 25ms

対応:
  → N+1 クエリ問題解決（180ms → 80ms）
  → Redis キャッシュ導入（45ms → 5ms）

結果: ServiceB が 250ms → 110ms に削減

5. メモリリーク検出・修復

シナリオ: Java アプリのヒープが毎日 500MB 増加

Profiler で検出:
  - RequestContext HashMap が GC 対象にならない
  - Thread Local に蓄積されている

対応:
  - ThreadLocal.remove() を finally で実行
  - WeakHashMap への変更

結果: メモリ増加が停止・OutOfMemoryError の再発防止

6. Python Django アプリケーション最適化

シナリオ: Django アプリの API レイテンシが 600ms

Profiler で検出:
  - ORM クエリ: 350ms（N+1 問題）
  - 正規表現マッチング: 140ms（ループ内実行）
  - シリアライズ: 110ms

対応:
  → select_related() / prefetch_related() 導入
  → 正規表現をコンパイル・再利用
  → DRF 最適化・キャッシュバックエンド

結果: 600ms → 180ms

7. コンテナイメージ最適化

シナリオ: Docker コンテナの起動時間が 12 秒

Profiler で検出:
  - Classpath スキャン: 4.2 秒
  - Spring Bean 初期化: 5.1 秒
  - DB マイグレーション: 2.7 秒

対応:
  → GraalVM Native Image 導入（起動時間 70% 削減）
  → Spring Cloud Function で Lambda ネイティブ化

結果: 12 秒 → 3.5 秒

8. Auto Scaling トリガー調整

シナリオ: Auto Scaling グループ・CPU > 70% でスケールアップ

Profiler で検出:
  - CPU 使用率と実際のホットコードが相関なし
  - メモリリークが真の原因

対応:
  → スケールポリシーを CPU から Heap 使用率に変更
  → メモリリーク修復でスケール不要に

結果: スケール頻度が 12 回/日 → 2 回/日に削減

9. 依存ライブラリのパフォーマンス問題検出

シナリオ: Jackson JSON ライブラリのバージョン更新後、
         API レイテンシが 15% 悪化

Profiler で検出:
  - Jackson.readValue() が新バージョンで遅い
  - 正規表現検証が追加された

対応:
  → 前バージョンに戻す / アップストリーム報告
  → カスタム JSON パーサー導入

結果: パフォーマンス回復

10. オンプレミス移行前の最適化

シナリオ: クラウド → オンプレミス移行検討

Profiler で検出:
  - クラウドでの CPU プロファイル（AWS Graviton ARM64）
  - オンプレ標準サーバー（Intel x86-64）での差異を事前確認

対応:
  - Profiler で x86 特性を反映したコード最適化
  - SIMD 命令の互換性チェック

結果: 移行後の不測の遅延を事前回避

設定・操作の具体例

CLI 操作（AWS CLI）

1. プロファイリンググループの作成

aws codeguruprofiler create-profiling-group \
  --profiling-group-name my-production-api \
  --compute-platform Default \
  --tags "Environment=prod,Team=backend"

2. Lambda 専用グループの作成

aws codeguruprofiler create-profiling-group \
  --profiling-group-name lambda-batch-processor \
  --compute-platform AWSLambda

3. 通知設定（SNS）

aws codeguruprofiler put-notification-configuration \
  --profiling-group-name my-production-api \
  --notification-configuration '{
    "channels": [
      {
        "id": "sns-alert",
        "uri": "arn:aws:sns:ap-northeast-1:123456789012:codeguru-alerts",
        "eventPublishers": ["AnomalyDetection"]
      }
    ]
  }'

4. CloudWatch アラーム連携

aws cloudwatch put-metric-alarm \
  --alarm-name codeguru-anomaly-detected \
  --alarm-description "Trigger on CodeGuru Anomaly" \
  --metric-name AnomalyCount \
  --namespace "AWS/CodeGuruProfiler" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:alerts"

5. プロファイルデータの取得

# 直近 1 時間のプロファイルを JSON で取得
aws codeguruprofiler get-profile \
  --profiling-group-name my-production-api \
  --start-time "$(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output-format application/json \
  > profile-$(date +%s).json

6. リスト・推奨事項の確認

# グループ一覧
aws codeguruprofiler list-profiling-groups

# 推奨事項の確認
aws codeguruprofiler describe-profiling-group \
  --profiling-group-name my-production-api

SDK 操作（Python）

1. Agent 統合

from codeguru_profiler_agent import Profiler

# Profiler 初期化
profiler = Profiler(
    profiling_group_name='my-python-app',
    region_name='ap-northeast-1',
    should_profile=True
)

# Profiler 開始
profiler.start()

# アプリケーション実行
try:
    # メインロジック
    process_data()
finally:
    # Profiler 停止
    profiler.stop()

2. Lambda 統合

from codeguru_profiler_agent import with_lambda_profiler

@with_lambda_profiler(
    profiling_group_name='lambda-batch-function'
)
def lambda_handler(event, context):
    # Lambda 関数コード
    result = process_records(event['records'])
    return {
        'statusCode': 200,
        'body': result
    }

3. Django アプリケーション

# settings.py
MIDDLEWARE = [
    'codeguru_profiler_agent.django_middleware.ProfilerMiddleware',
    # その他のミドルウェア
]

CODEGURU_PROFILER = {
    'enabled': True,
    'profiling_group_name': 'django-api-prod',
    'region_name': 'ap-northeast-1',
    'should_profile': not DEBUG
}

IaC 操作（CloudFormation / Terraform）

CloudFormation テンプレート

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CodeGuru Profiler Setup'

Resources:
  MyProfilingGroup:
    Type: AWS::CodeGuruProfiler::ProfilingGroup
    Properties:
      ProfilingGroupName: my-app-profiling-group
      ComputePlatform: Default
      AnomalyDetectionNotificationConfiguration:
        SNSTopicArn: !GetAtt AlertTopic.TopicArn

  AlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      DisplayName: CodeGuru Profiler Alerts
      TopicName: codeguru-alerts

  # Lambda 実行ロール
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: CodeGuruProfiler
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - codeguruprofiler:PostAgentProfile
                  - codeguruprofiler:GetProfile
                Resource: !GetAtt MyProfilingGroup.Arn

Terraform コード

resource "aws_codeguruprofiler_profiling_group" "main" {
  profiling_group_name  = "my-app-profiling-group"
  compute_platform      = "Default"
  tags = {
    Environment = "production"
    Team        = "backend"
  }
}

resource "aws_sns_topic" "codeguru_alerts" {
  name = "codeguru-alerts"
}

resource "aws_codeguruprofiler_notification_channel" "sns" {
  profiling_group_name = aws_codeguruprofiler_profiling_group.main.profiling_group_name
  notification_channel = {
    sns = {
      topic_arn = aws_sns_topic.codeguru_alerts.arn
    }
  }
}

4. 環境変数設定（Docker・ECS）

# Dockerfile
FROM eclipse-temurin:11-jdk

ENV AWS_CODEGURU_PROFILER_GROUP_NAME=my-app-prod
ENV AWS_CODEGURU_PROFILER_ENABLED=true
ENV AWS_REGION=ap-northeast-1

# Agent JAR をダウンロード
RUN curl -o /app/agent.jar https://s3.amazonaws.com/.../amazon-codeguru-profiler-java-agent.jar

ENTRYPOINT ["java", \
  "-javaagent:/app/agent.jar", \
  "-Dcom.amazonaws.codeguru.profiler.heap_summary_enabled=true", \
  "-jar", "/app/app.jar"]

ECS Task Definition

{
  "family": "my-app-task",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "my-account.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
      "environment": [
        {
          "name": "AWS_CODEGURU_PROFILER_GROUP_NAME",
          "value": "my-app-ecs-prod"
        },
        {
          "name": "AWS_CODEGURU_PROFILER_ENABLED",
          "value": "true"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024"
}

5. Kubernetes でのデプロイメント（EKS）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app-sa
      containers:
      - name: app
        image: my-account.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.2.0
        env:
        - name: AWS_CODEGURU_PROFILER_GROUP_NAME
          value: my-app-eks-prod
        - name: AWS_CODEGURU_PROFILER_ENABLED
          value: "true"
        - name: AWS_REGION
          value: ap-northeast-1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/my-app-eks-role

類似サービス比較表

ベストプラクティス

✅ 推奨事項

1. 継続的モニタリングの実行

   • 本番環境で常時有効化・1 週間単位で Flame Graph 確認
   • デプロイ前後で比較・改善効果を定量化

2. 異常検出アラートの設定

   • SNS・CloudWatch Alarm で即座に通知
   • PagerDuty・Slack 連携で On-Call への伝達

3. マルチ環境での検証

   • 本番・ステージング・開発環境で個別グループ設定
   • 本番での最適化をステージングで再現確認

4. 組織全体での集約ビュー

   • AWS Organizations での一元管理
   • チーム間でプロファイルデータ共有

5. CI/CD パイプラインへの統合

   • デプロイ前の性能バージョニング
   • コミット単位での CPU・メモリ変化を追跡

6. 機械学習異常検出の活用

   • Baseline の 2 週間をプロダクションで確保
   • ML による異常検出結果に基づいた対応優先順位化

❌ アンチパターン

1. 開発環境のみでのプロファイリング

   • 本番トラフィックパターンが再現できない
   • 実際のボトルネックが見逃される

2. Profiler を一度見て終わり

   • 継続的改善の効果測定不足
   • 新しいコード導入後の劣化検知遅延

3. Java 以外での期待値設定

   • Python/.NET は Java より検出ルールが少ない
   • Java での利用で最大効果を発揮

4. 異常検出を無視

   • 自動アラート = 根本原因ではないが、調査開始点
   • Critical / High アラートへの対応遅延

5. メモリ設定の過剰プロビジョニング

   • Profiler で必要な Heap サイズを正確に把握
   • 過剰メモリ = コスト増加・GC 遅延の可能性

6. 単一環境での検証

   • マルチ AZ・マルチリージョン環境でのテスト必須
   • 環境別のパフォーマンス差異を早期発見

トラブルシューティング表

End-of-Life 移行戦略

2025-04-30 End-of-Life に伴う移行パス

1. X-Ray Profiler への移行（推奨）

メリット:
- X-Ray トレース（サービス間）+ Profiler データ（メソッド）の統合
- CloudWatch との連携強化
- Lambda・EC2・ECS の継続サポート

移行手順:
1. X-Ray SDK をインストール
2. 既存 CodeGuru Agent から X-Ray Profiler へ置き換え
3. 3 ヶ月の並行運用で精度確認
4. CodeGuru Agent を削除

2. Q Developer Operations への移行

メリット:
- 生成 AI による根本原因分析
- 自動チューニング提案
- 複数サービス横断分析

移行手順:
1. Q Developer をセットアップ
2. CloudWatch Logs・Metrics を連携
3. 自動分析レポートを確認
4. 従来の Profiler からデータ抽出・Q へ入力

3. CloudWatch Application Signals への移行

メリット:
- SLO ベースのモニタリング
- 自動スケーリング推奨
- API Gateway / ALB との統合

移行手順:
1. Application Signals を有効化
2. SLO 定義（Latency・Error Rate・Availability）
3. CloudWatch Dashboards で可視化
4. Incidents・Alarms を統合

並行運用期間（推奨）: 3～6 ヶ月

Phase 1 (Month 1-2):
  - X-Ray / Q Developer セットアップ
  - CodeGuru Profiler データ履歴エクスポート
  - 両者で同じメトリクス取得・比較

Phase 2 (Month 3-4):
  - 新規デプロイでは X-Ray / Q Developer 使用
  - 既存本番アプリは CodeGuru Profiler 継続
  - ベンチマーク実施

Phase 3 (Month 5-6):
  - CodeGuru Profiler Agent を段階的に削除
  - X-Ray / Q Developer で完全カバー確認
  - CodeGuru Profiler 契約解除

2025-2026 最新動向

2025 年 Q1: End-of-Life アナウンス

• AWS が 2025-04-30 の End-of-Life を公式発表
• X-Ray Profiler・Q Developer Operations への移行ガイド公開

2025 年 Q2: X-Ray Profiler 統合強化

• X-Ray Profiler が CodeGuru と同等の異常検出機能を追加予定
• CloudWatch Metrics との完全統合

2025 年 Q3-Q4: Application Signals 拡張

• SLO ベースのモニタリング標準化
• 複数サービス横断の自動相関分析

2026 年: Q Developer Operations の一般利用開始

• 生成 AI による自動チューニング提案
• マルチリージョン対応

学習リソース・参考文献

AWS 公式ドキュメント（8+）

1. Amazon CodeGuru Profiler User Guide
2. CodeGuru Profiler API Reference
3. Setting up CodeGuru Profiler
4. Working with profiling groups
5. Viewing and interpreting flame graphs
6. Anomaly detection and recommendations
7. AWS Systems Manager Session Manager Integration
8. IAM Roles for CodeGuru Profiler

ベンダー・OSS リソース（5+）

1. Datadog Continuous Profiler Documentation
2. Pyroscope - Open Source Continuous Profiling
3. Parca - eBPF-Based Continuous Profiling
4. Grafana Phlare - Open Source Profiling
5. New Relic CodeStream Performance Profiling

AWS ブログ・ケーススタディ

1. Optimizing Application Performance with CodeGuru Profiler
2. How Datadog Uses CodeGuru Profiler
3. Performance Tuning with CodeGuru - Best Practices

実装例・チェックリスト

Spring Boot アプリケーション実装例

package com.example.app;

import software.amazon.codeguruprofilerjavaagent.Profiler;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {
    
    public static void main(String[] args) {
        // CodeGuru Profiler 初期化（オプション・エージェント使用時は不要）
        initializeProfiler();
        
        SpringApplication.run(Application.class, args);
    }
    
    private static void initializeProfiler() {
        String groupName = System.getenv("AWS_CODEGURU_PROFILER_GROUP_NAME");
        if (groupName != null && !groupName.isEmpty()) {
            // Profiler が javaagent で起動済みの場合、この初期化は不要
            System.out.println("CodeGuru Profiler initialized via javaagent");
        }
    }
}

# 実行コマンド
java -javaagent:amazon-codeguru-profiler-java-agent.jar \
     -Dcom.amazonaws.codeguru.profiler.heap_summary_enabled=true \
     -jar app.jar

導入チェックリスト

• [ ] IAM ロール・ポリシーで CodeGuru Profiler 権限を付与
• [ ] VPC セキュリティグループで CodeGuru エンドポイントへのアウトバウンドを許可
• [ ] プロファイリンググループを環境ごとに作成（本番・ステージング・開発）
• [ ] Lambda Layer で Agent をプリロード（Cold Start 最小化）
• [ ] SNS トピック・CloudWatch Alarm を設定
• [ ] Profiler データの CloudWatch への出力を確認
• [ ] Flame Graph を 1 周間確認・最適化候補を特定
• [ ] 異常検出アラートに対応する on-call プロセスを確立
• [ ] 毎月のコスト監視・ROI 評価

まとめ

Amazon CodeGuru Profiler は 「本番環境での継続的アプリケーションプロファイリング & ML 異常検出サービス」。Java・Python・.NET アプリの CPU・メモリを 2% 未満のオーバーヘッドで継続監視し、フレームグラフで最コスト効率的なコード最適化ポイントを特定。機械学習による異常検出で GC・メモリリーク・パフォーマンス劣化を自動通知する。

⚠️ ただし End-of-Life 2025-04-30 に伴い、新規採用は X-Ray Profiler / Q Developer Operations への移行を検討推奨。既存ユーザーは 3～6 ヶ月の並行運用期間 で X-Ray / Q Developer へ段階移行する。本ガイドで習得した Profiler スキルは移行後の X-Ray でも応用可能。

最終更新：2026-04-26 バージョン：v2.0