#techbrew_findy AWSで構築するCDパイプラインと その改善 株式会社スマートラウンド 山原 崇史(@shonansurvivors) 

自己紹介 株式会社スマートラウンド SRE/CorporateITグループ エンジニアリングマネージャー 山原 崇史 (やまはら たかし)　 経歴等 　・SIer → 銀行 → Web系ベンチャー数社 → 現職 　・2023 Japan AWS Top Engineers 　・AWS Startup Community Core Member 好きな技術領域 　AWS / Terraform / GitHub Actions shonansurvivors 

事業およびプロダクト紹介 ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる smartroundが実現する世界 　統一化・標準化されたデータ管理によって、スタートアップと投資家双方の業務を効率化 

本日のテーマ AWSで構築するCDパイプラインとその改善 AWS上で稼働させているプロダクトについて、その CDパイプラインもAWSのサービスで構築しました。 その背景や考え方のほか、CDの品質を高めるための改善についてお話しします。 想定聴講者 ● AWS CodePipelineやCodeBuildを知らない人 ● AWSは使っているが、CIもCDもGitHub Actionsで実施している人 

アジェンダ 1. CodePipelineの概要と選択の背景 2. CodeBuildの活用 3. CDの品質を高める工夫 4. まとめ 

1. CodePipelineの概要と 選択の背景 

CodePipelineとは AWSのCI/CDパイプラインサービス。 知らない人向けにごく簡潔に説明すると、 各種AWSサービスや外部サービスを直列・並列に組み合わせて パイプラインを構築できる。 

CI/CDの構成 ● CI ○ GitHub Actions ● CD ○ CodePipeline ● ブランチ戦略 ○ git-flow ■ 長命なブランチとして developとmainが存在 ■ 本番リリース時はdevelopからreleaseブランチを切ってstg環境にデプロイ ■ releaseブランチの検証に問題なければ mainにマージすることで本番デプロイ開始 

CDにCodePipelineを選択している背景 CDは、本番環境のWRITE権限という強力な権限 を持つことになる。 CIサービス側にCDも担わせると、CIの権限で、上記の強力な権限を使用 できる(※)。 CodePipelineはプロダクト初期より使用しているが、 エンタープライズの顧客も増え、セキュリティや統制の必要性が高まる中、 CDをCIサービス側に寄せず、 CIはGitHub Actions、CDはCodePipelineという構成を選択し続けている。 また、CodePipelineに承認機能があり、不正なデプロイへの多層防御が図れることも選定のポイント。 (これだけだと価値提供の速度を軽視しているように見えますが、そこは別の工夫で担保しています ) ※参考：CIOpsとGitOpsの話 (https://blog.inductor.me/entry/2021/09/24/015402) 

CodePipeline v1とv2のおもな違い 2023年登場のv2が多機能だが、料金の考え方が大きく異なる v1 v2 GitHub 連携時の 起動トリガー 事前に定めたブランチへの コミットプッシュのみ 以下の条件を組み合わせ可能 ● 任意のブランチ ● 任意のタグ ● コミットプッシュ ● タグプッシュ ● プルリクエスト ● 任意のファイルパス その他の 起動トリガー ● S3へのアップロード ● ECRへのイメージプッシュ 等 承認機能 あり 料金 固定 (1パイプラインあたり1USD/月) 処理時間に応じた従量制 (0.002USD/分) 

2. CodeBuildの活用 

CodeBuildについて ● GitHub Actionsのように、YAMLで処理を定義し実行できる ● CodeBuildという名前だが、処理さえ書けばテストでもデプロイでも何でも (※)できる ※ただし、キャッシュの取り回しなど、 GitHub Actionsと比べると見劣りする点は色々ある 

CodeBuildを使わないCodePipeline ● 要件次第ではCodeBuildを使わずに CDを実現できるケースもある (右はECR, S3, ECSとの連携のみを使用 ) ● ただし、自由に処理が書ける CodeBuildが 必要となる場面が多いはず 

CodeBuild on CodePipelineによるCD ● 当社のCodePipeline上ではCodeBuildにより以下を実施 ○ FlywayによるDBマイグレーションの実行 ○ ecspressoによるECSへのデプロイ ○ Serverless FrameworkによるLambdaやその周辺リソースのデプロイ 

CodeBuildでのGitHub Actionsの使用 GitHub Actionsのカスタムアクションを使用できる version: 0.2 phases: # 略 build: steps: - uses: kayac/ecspresso@v2 # ecspressoのインストールのみを行うアクション with: version: v2.3.2 - run: ecspresso deploy 

3. CDの品質を高める 

CI/CDの品質を考えてみる 一例 ● パフォーマンス(速度) ● 安定性 ● コスト効率 ● 柔軟性や拡張性 ● セキュリティ ● ユーザービリティ、開発者体験 ● オブザーバビリティ 

コスト効率・速度・安定性 各CodeBuildのスペックを処理の特性に応じて適正化 し、コスト効率を高めつつ、速度と安定性を確保 Source Kotlinイメージビルド nginxイメージビルド Flywayによる DBマイグレーション ECSデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ ・・・ ※Lambdaは多くが夜間バッチ処理のためデプロイ速度は不要だが、 Kotlinのビルドを安定させるために Mediumを選択 CodePipeline Large Large Small Medium Small 

その他 ● セキュリティ ○ CodePipeline、各CodeBuildのIAMロールに最小権限の原則を適用 ● ユーザービリティ、開発者体験 ○ 検証等の目的でCodeBuild単体で実行する場合をあらかじめ考慮 した設計 (パラメータを環境変数で注入可能にするなど ) 

4. まとめ 

まとめ ● CIとCDの責任分界を考えるのであれば CIにGitHub Actions、CDにCodePipeline、は1つの選択肢 ● CodePipelineにCodeBuildを組み込むことで、ある程度柔軟に多様な処理を実現可能 ● CI/CDの品質は様々考えられると思うので、それぞれ改善して 最適化に取り組んでいきましょう！ ○ パフォーマンス(速度) ○ 安定性 ○ コスト効率 ○ 柔軟性や拡張性 ○ セキュリティ ○ ユーザービリティ、開発者体験 ○ オブザーバビリティ 

スマートラウンドでは新しいメンバーを募集中です 私たちと一緒に、スタートアップが可能性を最大限に発揮できる世界をつくりませんか？ jobs.smartround.com