バッチ処理をEKSからCodeBuildを使ったGitHub Self-hosted Runnerに変更した話

バッチ処理をEKSからCodeBuildを使ったGitHub Self-hosted Runnerに変更した話

Transcript

1. バッチ処理をEKSから CodeBuildを使った GitHub Self-hosted Runnerに 変更した話 2025/10/10 菊池聡規（@tttkkk215） クラウド事業本部 コンサルティング部
2. 自己紹介 名前: 菊池 聡規（とーち） 部署: クラウド事業本部 普段の業務: AWSのコンサルティングやピープルマネジメント どちらかと言えばインフラ寄りの領域を担当 Xアカウント: https://x.com/tttkkk215 ブログ: https://dev.classmethod.jp/author/tooti/ 好きな技術: コンテナ、Terraform、生成AI 2
3. プロキシ環境でEKSを使った バッチを動かしたかった
4. バッチ処理の要件 処理内容: ECRコンテナイメージの定期セキュリティスキャン 実行環境: EKS上でバッチ実行 ネットワーク: プロキシが存在する厳格な環境 やりたかったこと 4
5. 詳細は異なるがこんな感じの環境 プロキシ環境の構成 5
6. Sysdig Registry Scannerとは Sysdigが提供するECR等コンテナイメージの定期セキュリティスキャンツール コンテナイメージの脆弱性を継続的に監視・検出 Helmチャートで提供される https://charts.sysdig.com/charts/registry-scanner/ スキャン対象 ECR内の全リポジトリ 各リポジトリ内の全タグ付きイメージ 動かしたかったのはSysdig Registry Scanner 6
7. EKS上での構成 7
8. プロキシ環境下で起きた 数々のトラブル
9. エラー内容 Connection to 169.254.170.23 failed (110) Connection timed out 原因 Pod Identity Agent専用エンドポイント 169.254.170.23 が HTTP_PROXY 環境変数によりプロキ シ経由でアクセスされていた NO_PROXY に 169.254.0.0/16 を追加しても解決せず デバッグの困難さ Sysdig Registry Scanner Podのログ: 上記エラー以外の情報なし Pod Identity自体のログ: もしかしたらノード上にはログがあった？当時はそこまで思い至らな かったので調査に難航 トラブル1: Pod Identity認証の失敗 9
10. 暫定解決策 Pod Identity認証フローは以下の通りになってる Pod Identityを諦め、IAMアクセスキーで通信発生を回避 Kubernetes Secretsに直接認証情報を格納 暫定解決策 10
11. エラー内容 scan failed for image: scan execution failed for job 'registry-scanner-worker-j9l4n-5': unable to obtain job errors: no logs found: error getting logs from pod registry-scanner-worker-j9l4n-5-v7mrk: no errors found in logs 状況 ワーカーPod: スキャン処理は成功、 Completed ステータス オーケストレーターPod: ワーカーPodからログ取得失敗、 Error ステータス 結果: 実際のスキャンは成功しているのに、全体が失敗扱いに トラブル2: オーケストレーターとワーカーPod間の通信エラー 11
12. 原因分析: kubelet APIとの通信エラー トラブル2: オーケストレーターとワーカーPod間の通信エラー 12
13. 詳細調査の実施 1. RBAC権限の確認: ServiceAccountの pods/log 権限を検証 → 問題なし 2. デバッグPodでの検証: # プロキシ経由（失敗） curl "http://10.x.x.59:10250/..." → Connection timeout（Squidプロキシ経由になっている） # プロキシバイパス（成功） curl --noproxy '*' "http://10.x.x.59:10250/..." → 正常に応答 3. CIDR記法の検証結果: NO_PROXY: "10.0.0.0/8" → 認識されない NO_PROXY: "10.x.x.0/26,10.x.x.64/26" → 認識されない 最終判断: プロキシ環境でのトラブルシューティングが極めて困難。根本原因を特定できず解決 の目処が立たない → EKS環境を廃止し、CodeBuildへ移行を決定 トラブル2: オーケストレーターとワーカーPod間の通信エラー 13
14. 最終的にEKSを使った スキャンバッチを諦めた
15. 1. プロキシ環境での複雑性 本質的じゃないところで調査・設計・トラブルシューティングの時間が取られる 2. 運用の複雑さ 運用チームにおいてもK8sの知見が豊富というわけではなかった そもそもK8sを使わないのであればそれに越したことはない 3. コスト EKS Auto Modeのクラスター実行コスト 定期バッチのためだけにクラスターを維持 EKSを諦めた理由 15
16. 代替案の検討: Step Functions + EventBridge + CodeBuild
17. 構成の特徴 CodeBuildでスキャン実行、Step Functionsでオーケストレーション AWSサービスで完結するシンプルな構成 何よりもVPC上に置かなくて良い → プロキシを気にしなくて良い これも悪くないと思っていたが・・・ 当初検討したアーキテクチャ 17
18. CodeBuildで処理を動かすなら、 Step Functions + EventBridge Schedulerは GitHub Actionsで代替できるのでは？
19. GitHub Actions中心の最終アーキテクチャ 19
20. このプロジェクトでの判断理由 シンプルな構成: Step Functionsが不要 技術スタックの統一: GitHub Actionsは別の処理でも使用予定だったため、技術選択を統一 できる 通知機能の柔軟性: 脆弱性検知時にコンテナイメージ所有者への通知を考えていた。GitHub 機能を使えばメンション等で所有者に直接通知可能 なぜGitHub Actions中心に? 20
21. 実装の詳細
22. 1. Terraform実装 CodeBuildプロジェクト作成 2. GitHub Actions Workflow 全ECRイメージを動的に取得 matrix strategyで並列スキャン実行 実装 22
23. name: ECR Security Scan on: workflow_dispatch: # 手動実行を有効化 schedule: - cron: '0 2 * * *' # 定期実行 jobs: get_images: runs-on: - codebuild-test-cs-${{ vars.ENVIRONMENT }}-github-actions-runner-${{ github.run_id }}-${{ github.run_attempt }} outputs: matrix: ${{ steps.set_matrix.outputs.matrix }} steps: - name: Get all images and set matrix id: set_matrix run: | # ECRから全イメージタグを取得してJSON配列化 for REPO in "${REPOS_ARRAY[@]}"; do TAGS=$(aws ecr describe-images --repository-name "$REPO" --query 'imageDetails[?imageTags!=null].imageTags[]' --output text) for TAG in $TAGS; do echo "${ECR_REGISTRY}/${REPO}:${TAG}" >> "$IMAGE_LIST_FILE" done done IMAGE_JSON_ARRAY=$(cat "$IMAGE_LIST_FILE" | jq -R . | jq -s .) echo "matrix={\"image\":${IMAGE_JSON_ARRAY}}" >> $GITHUB_OUTPUT 23
24. sysdig_scan: needs: get_images runs-on: - codebuild-test-cs-${{ vars.ENVIRONMENT }}-github-actions-runner-${{ github.run_id }}-${{ github.run_attempt }} strategy: fail-fast: false max-parallel: 3 # 3個ずつ並列実行 matrix: ${{ fromJson(needs.get_images.outputs.matrix) }} steps: - name: Pull Docker image env: ECR_IMAGE: ${{ matrix.image }} run: docker pull ${ECR_IMAGE} - name: Scan Docker image # Sysdigスキャン実行 技術的工夫 動的マトリックス生成: ECRイメージリストを動的に配列化してmatrixに展開 並列処理: matrix strategyで3個並列実行（ max-parallel: 3 ） 24
25. GitHub Actions + CodeBuild vs Step Functions + EventBridge
26. ワークフロー定義 Step Functions: JSON/YAMLで状態マシン定義、独自の記法 + EventBridge設定 GitHub Actions + CodeBuild: 1つのYAMLファイルで完結 エコシステム Step Functions: AWS内のサービス統合に特化 GitHub Actions + CodeBuild: GitHubの機能統合（PR連携、Issue通知、コードレビュー 等） 、豊富なMarketplaceアクション 監視・メトリクス Step Functions: デフォルトで豊富なメトリクス、CloudWatchでアラート設定が容易 GitHub Actions + CodeBuild: メトリクス機能はあるが制約が多い（UIベースのみ、アラート 機能なし） 、CodeBuildのCloudWatch Metricsも活用可能 両者の違い 26
27. ワークフロー定義がシンプル - 1つのYAMLファイルで完結 GitHubに慣れたチームに最適 - GitHub UIでの確認・デバッグが可能 並列処理が簡単に実装できる - matrix strategyで宣言的に並列度調整 IAM OIDC IDプロバイダの設定が不要 - CodeBuild側のIAMロールで各AWSサービスにアク セス GitHub Actionsの実行時間課金を気にしなくていい - CodeBuildで実行するため、GitHub Actionsの実行時間枠を消費しない GitHub Actions + CodeBuildの良いところ 27
28. AWSサービスのみで統一できる - 組織のガバナンス要件でGitHubが使えない場合に最適 AWSサービスとの親和性が高い - Lambda、DynamoDB、SNS等との直接統合が容易 監視・アラート体制が充実 - デフォルトで豊富なメトリクス、CloudWatchで様々な指標で のアラート設定が容易 Step Functions + EventBridgeの良いところ 28
29. ライトなバッチ処理をさせたいときには、CodeBuildを使った GitHub Self-hosted Runnerもおすすめです！
30. 参考資料
31. AWS公式ドキュメント EKS Pod Identity Pod Identity認証の仕組みとProxy設定 Pod Identity Agent Setup Pod Identity Agentの詳細とエンドポイント情報 CodeBuild Self-hosted GitHub Actions runners CodeBuildでのセルフホステッドランナー構築方法 GitHub公式ドキュメント Viewing GitHub Actions metrics GitHub Actionsのメトリクス機能と制約 参考資料・リンク 31
32. ご清聴ありがとうございました！