Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSで構築するCDパイプラインとその改善
Search
shonansurvivors
February 19, 2024
Technology
4
3.3k
AWSで構築するCDパイプラインとその改善
TechBrew in 東京 〜CI/CDパイプライン改善の取り組み〜 (
https://findy.connpass.com/event/309537/
) 登壇資料
shonansurvivors
February 19, 2024
Tweet
Share
More Decks by shonansurvivors
See All by shonansurvivors
スタートアップがAWSパートナーになって得られたこと
shonansurvivors
3
780
Terraformでmoduleを使わずに複数環境を構築して感じた利点
shonansurvivors
4
3k
クロステナントアクセスを要件とするsmartroundのマルチテナントSaaSアーキテクチャ
shonansurvivors
0
340
CodeBuildで動かすecspresso
shonansurvivors
2
3.2k
GitHub ActionsのGitHub-hosted Larger Runnersと他サービスと
shonansurvivors
0
850
EC2からのECS移行においてIaCとCDをどう変えたか
shonansurvivors
22
6.8k
S3とCloudWatch Logsの見直しから始めるコスト削減 / Cost saving S3 and CloudWatch Logs
shonansurvivors
3
2.6k
プロダクトと組織の成長を見据えたスマートラウンドの AWSマルチアカウント戦略/AWS Multi Account Strategy
shonansurvivors
5
4.5k
信頼性の階層の一段目を積み上げる/Monitoring Dashboard
shonansurvivors
3
3k
Other Decks in Technology
See All in Technology
LLMに日本語テキストを学習させる意義
ksaito
13
3.6k
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
200
waitany と waitall を作った話
mrkn
0
110
脆弱星に導かれて
nishimunea
1
1.6k
Estrategias de escalabilidade para projetos web
jessilyneh
2
190
RAGHack: Kickoff and RAG 101
pamelafox
0
250
バックログを導入し やっぱやめた話
ota42y
0
180
MySQLユーザ会なにやってるの?とおさそいと / たいへんなのw
sakaik
1
110
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
170
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
160
技術力あげたい
hisaichi5518
2
2.9k
ビジネスとエンジニアリングを繋ぐプロダクトを中心とした組織づくりの実践
sansantech
PRO
1
120
Featured
See All Featured
From Idea to $5000 a Month in 5 Months
shpigford
378
46k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
A Philosophy of Restraint
colly
202
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
88
16k
GitHub's CSS Performance
jonrohan
1029
450k
KATA
mclloyd
27
13k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
Typedesign – Prime Four
hannesfritz
39
2.3k
Documentation Writing (for coders)
carmenintech
65
4.3k
Building Applications with DynamoDB
mza
89
5.9k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
Navigating Team Friction
lara
183
13k
Transcript
#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