AWSで構築するCDパイプラインとその改善

TechBrew in 東京 〜CI/CDパイプライン改善の取り組み〜 ( https://findy.connpass.com/event/309537/) 登壇資料

Transcript

1. #techbrew_findy AWSで構築するCDパイプラインと その改善 株式会社スマートラウンド 山原 崇史(@shonansurvivors)
2. 自己紹介 株式会社スマートラウンド SRE/CorporateITグループ エンジニアリングマネージャー 山原 崇史 (やまはら たかし)　 経歴等 　・SIer → 銀行 → Web系ベンチャー数社 → 現職 　・2023 Japan AWS Top Engineers 　・AWS Startup Community Core Member 好きな技術領域 　AWS / Terraform / GitHub Actions shonansurvivors
3. 事業およびプロダクト紹介 ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる smartroundが実現する世界 　統一化・標準化されたデータ管理によって、スタートアップと投資家双方の業務を効率化
4. 本日のテーマ AWSで構築するCDパイプラインとその改善 AWS上で稼働させているプロダクトについて、その CDパイプラインもAWSのサービスで構築しました。 その背景や考え方のほか、CDの品質を高めるための改善についてお話しします。 想定聴講者 • AWS CodePipelineやCodeBuildを知らない人 • AWSは使っているが、CIもCDもGitHub Actionsで実施している人
5. アジェンダ 1. CodePipelineの概要と選択の背景 2. CodeBuildの活用 3. CDの品質を高める工夫 4. まとめ
6. 1. CodePipelineの概要と 選択の背景
7. CodePipelineとは AWSのCI/CDパイプラインサービス。 知らない人向けにごく簡潔に説明すると、 各種AWSサービスや外部サービスを直列・並列に組み合わせて パイプラインを構築できる。
8. CI/CDの構成 • CI ◦ GitHub Actions • CD ◦ CodePipeline • ブランチ戦略 ◦ git-flow ▪ 長命なブランチとして developとmainが存在 ▪ 本番リリース時はdevelopからreleaseブランチを切ってstg環境にデプロイ ▪ releaseブランチの検証に問題なければ mainにマージすることで本番デプロイ開始
9. 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)
10. CodePipeline v1とv2のおもな違い 2023年登場のv2が多機能だが、料金の考え方が大きく異なる v1 v2 GitHub 連携時の 起動トリガー 事前に定めたブランチへの コミットプッシュのみ 以下の条件を組み合わせ可能 • 任意のブランチ • 任意のタグ • コミットプッシュ • タグプッシュ • プルリクエスト • 任意のファイルパス その他の 起動トリガー • S3へのアップロード • ECRへのイメージプッシュ 等 承認機能 あり 料金 固定 (1パイプラインあたり1USD/月) 処理時間に応じた従量制 (0.002USD/分)
11. 2. CodeBuildの活用
12. CodeBuildについて • GitHub Actionsのように、YAMLで処理を定義し実行できる • CodeBuildという名前だが、処理さえ書けばテストでもデプロイでも何でも (※)できる ※ただし、キャッシュの取り回しなど、 GitHub Actionsと比べると見劣りする点は色々ある
13. CodeBuildを使わないCodePipeline • 要件次第ではCodeBuildを使わずに CDを実現できるケースもある (右はECR, S3, ECSとの連携のみを使用 ) • ただし、自由に処理が書ける CodeBuildが 必要となる場面が多いはず
14. CodeBuild on CodePipelineによるCD • 当社のCodePipeline上ではCodeBuildにより以下を実施 ◦ FlywayによるDBマイグレーションの実行 ◦ ecspressoによるECSへのデプロイ ◦ Serverless FrameworkによるLambdaやその周辺リソースのデプロイ
15. CodeBuildでのGitHub Actionsの使用 GitHub Actionsのカスタムアクションを使用できる version: 0.2 phases: # 略 build: steps: - uses: kayac/ecspresso@v2 # ecspressoのインストールのみを行うアクション with: version: v2.3.2 - run: ecspresso deploy
16. 3. CDの品質を高める
17. CI/CDの品質を考えてみる 一例 • パフォーマンス(速度) • 安定性 • コスト効率 • 柔軟性や拡張性 • セキュリティ • ユーザービリティ、開発者体験 • オブザーバビリティ
18. コスト効率・速度・安定性 各CodeBuildのスペックを処理の特性に応じて適正化 し、コスト効率を高めつつ、速度と安定性を確保 Source Kotlinイメージビルド nginxイメージビルド Flywayによる DBマイグレーション ECSデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ Kotlinビルド& Lambdaデプロイ ・・・ ※Lambdaは多くが夜間バッチ処理のためデプロイ速度は不要だが、 Kotlinのビルドを安定させるために Mediumを選択 CodePipeline Large Large Small Medium Small
19. その他 • セキュリティ ◦ CodePipeline、各CodeBuildのIAMロールに最小権限の原則を適用 • ユーザービリティ、開発者体験 ◦ 検証等の目的でCodeBuild単体で実行する場合をあらかじめ考慮 した設計 (パラメータを環境変数で注入可能にするなど )
20. 4. まとめ
21. まとめ • CIとCDの責任分界を考えるのであれば CIにGitHub Actions、CDにCodePipeline、は1つの選択肢 • CodePipelineにCodeBuildを組み込むことで、ある程度柔軟に多様な処理を実現可能 • CI/CDの品質は様々考えられると思うので、それぞれ改善して 最適化に取り組んでいきましょう！ ◦ パフォーマンス(速度) ◦ 安定性 ◦ コスト効率 ◦ 柔軟性や拡張性 ◦ セキュリティ ◦ ユーザービリティ、開発者体験 ◦ オブザーバビリティ
22. スマートラウンドでは新しいメンバーを募集中です 私たちと一緒に、スタートアップが可能性を最大限に発揮できる世界をつくりませんか？ jobs.smartround.com