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 CDKで実現するインフラCI・CD
Search
bbrfkr
July 27, 2020
Technology
2
1.2k
アプリエンジニアを救え! AWS CDKで実現するインフラCI・CD
cndjp #15で発表させていただいた内容です。AWS CDKのお話。
bbrfkr
July 27, 2020
Tweet
Share
More Decks by bbrfkr
See All by bbrfkr
有志で組織横串に挑む - GitLab CI Runnerカイゼン -
bbrfkr
0
210
[July Tech Festa 2019] Kubernetes on OpenStack におけるハマりどころ
bbrfkr
5
1.3k
OpenShiftでKubeVirtを試してみた
bbrfkr
1
1k
Kubernetes x スマートスピーカ ~ Kubernetesで実現するFaaS ~
bbrfkr
1
240
Virtual Kubelet + Fargate + EKSでノードレス Kubernetes を夢見た話
bbrfkr
5
2.2k
怖くない!コンテナ初心者に送るやさしいKubernetes入門
bbrfkr
20
5.8k
Other Decks in Technology
See All in Technology
なぜCodeceptJSを選んだか
goataka
0
160
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
5
210
Turing × atmaCup #18 - 1st Place Solution
hakubishin3
0
490
WACATE2024冬セッション資料(ユーザビリティ)
scarletplover
0
210
統計データで2024年の クラウド・インフラ動向を眺める
ysknsid25
2
850
宇宙ベンチャーにおける最近の情シス取り組みについて
axelmizu
0
110
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
330
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
540
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
170
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
560
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
150
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1366
200k
Become a Pro
speakerdeck
PRO
26
5k
Six Lessons from altMBA
skipperchong
27
3.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Agile that works and the tools we love
rasmusluckow
328
21k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
The World Runs on Bad Software
bkeepers
PRO
65
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
BBQ
matthewcrist
85
9.4k
Transcript
アプリエンジニアを救え! AWS CDKで実現するインフラCI・CD 株式会社アイリッジ 斎藤辰徳
斎藤辰徳 (HN: bbrfkr) Hello! 2 所属:株式会社アイリッジ ミッション • OMOモバイルアプリ実行基盤開発 ◦
バックエンド ◦ クラウドインフラ (主にAWS)
3 クラウドもいいけど、オンプレもね。。。
4
? ◉ 事業 ◦ OMO(Online Merges with Offline)ソリューション開発 ◦ OMOアプリの企画・開発
◉ 技術 ◦ インフラ開発・運用 → AWS × コンテナ がメイン ◦ Managed Serviceを積極活用したCloud Architecture ◦ ECS CLI v1 の国内トップレベルでの利用 AWS Fargate 5 Amazon ECS Amazon ECR Amazon Aurora Amazon Cognito AWS Lambda
Agenda 6 ◉ アプリエンジニアのお悩み事情 ◉ CDK & CloudFormation ◉ コードリポジトリ構成例
◉ インフラCI・CD実現事例 ◉ まとめ
アプリエンジニアのお悩み事情 7
非機能要件への興味 8 ◉ コード中心の考え方 ◦ アプリの動作に直結する部分では、ある ▪ コードの非機能要件 ◦ そうでない部分では、あまりない
▪ インフラの非機能要件
インフラへの想い 9 ◉ やりたいことの本筋ではない! ◦ 難しく、面倒で、専任に任せたい。。。 ◦ でもインフラエンジニアがいない。。。 ◦ 大部分をクラウドにオフロードしたい!
◦ Kubernetesはオーバーテクノロジー ▪ 使う必要性がないなら使いたくない
コンソールぽちぽち問題 10 ◉ クラウドコンソールをぽちぽちしたくない! ◦ これも不本意かつ時間の無駄。。。 ◦ ナレッジ不足によるコード化タイムロス。。。 ◦ インフラコード化/CI・CDは後回し。。。
CDKでここに寄与したお話
CDK & CloudFormation 11
AWS CDKとは ? 12 ◉ 高級言語でCloudFormation(CFn)の内容を記述
AWS CFnとは ? 13 ◉ YAMLやJSONで宣言的にリソース管理 https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-whatis-howdoesitwork.html
CDKとCFnのイメージ 14 const mybucket = new s3.Bucket(this, 'MyBucket', { removalPolicy:
cdk.RemovalPolicy.DESTROY, }); new cloudFront.CloudFrontWebDistribution(this, 'MyDistribution', { originConfigs: [ { s3OriginSource: { s3BucketSource: mybucket }, behaviors: [{isDefaultBehavior: true}] } ] }); S3の定義 CloudFront の定義 CDK
CDKとCFnのイメージ 15 Resources: MyBucketF68F3FF0: Type: AWS::S3::Bucket UpdateReplacePolicy: Delete DeletionPolicy: Delete
MyDistributionCFDistributionDE147309: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: DefaultCacheBehavior: AllowedMethods: - GET - HEAD CachedMethods: - GET - HEAD Compress: true ForwardedValues: Cookies: Forward: none QueryString: false TargetOriginId: origin1 ViewerProtocolPolicy: redirect-to-https DefaultRootObject: index.html Enabled: true HttpVersion: http2 IPV6Enabled: true Origins: - ConnectionAttempts: 3 ConnectionTimeout: 10 DomainName: Fn::GetAtt: - MyBucketF68F3FF0 - RegionalDomainName Id: origin1 S3OriginConfig: {} PriceClass: PriceClass_100 ViewerCertificate: CloudFrontDefaultCertificate: true S3の定義 CloudFront の定義 CloudFront の定義 CFn
CDKの優位性 16 ◉ YAML/JSONでは難しい 開発ノウハウ適用 ◦ 制御構造:if文、forループ ◦ 静的型付け ◦
静的解析ツール ◦ Snapshotテスト・Fine-Grainedテスト
静的型付け 17 ◉ リソースに与える引数一式を予め決定 ◉ 静的解析ツールでバグを拾いやすく! codeS3Bucket -> String codeS3Key
-> String codeHandler -> String codeRuntime -> lambda.Runtime apiMethod -> String myApiStackVar "MyApiFnBucket" "codes/apiFn.zip" "my_api.handler" PYTHON_3_8 "POST" MyApiStackProps MyApiStack
◉ yamllintよりもリッチな静的解析 静的解析ツール 18 const mybucket = new s3.Bucket(this, 'MyBucket',
{ removalPolicy: cdk.RemovalPolicy.DESTROY, }); new cloudFront.CloudFrontWebDistribution(this, 'MyDistribution', { originConfigs: [ { s3OriginSource: {}, behaviors: [{isDefaultBehavior: "true"}] } ] }); 2行目、インデント多すぎ! s3OriginSourceのパラメータが足りない! isDefaultBehaviorの値はboolでないと✗!
Snapshotテスト 19 ◉ 生成されるCFnのGolden Imageによるテスト ◉ 現状、TypeScriptのみサポート Snapshot Template =?
≠??
Fine-Grainedテスト 20 ◉ 生成テンプレートの設定値テスト ◉ 現状、TypeScriptのみサポート Runtime == PYTHON_3_8 ?
S3Origin.domainName == myS3DomainName ? ApiGateway Resource does exist ?
コードリポジトリ構成例 21
cdk init直後の状態 22 ◉ あくまでサンプル ◦ 設定値YAML✗ ◦ 環境概念✗ <project名>/
├── README.md ├── bin │ └── <project名>.ts ├── cdk.json ├── jest.config.js ├── lib │ └── <project名>.ts ├── package.json ├── test │ └── <project名>.test.ts └── tsconfig.json
実際の構成例 23 ├── Gemfile ├── Gemfile.lock ├── README.md ├── Rakefile
├── bin │ └── cdkTsTemplate.ts ├── cdk.context.json ├── cdk.json ├── jest.config.js ├── lib │ ├── core │ │ ├── abstractStack.ts │ │ └── stackCreator.ts │ └── util │ ├── error.ts │ └── util.ts ├── package.json ├── tsconfig.json └── types └── index.ts project/ ├── config ← 環境設定ディレクトリ │ ├── dev │ │ └── <リソース名>.yaml │ ├── global.yaml │ ├── prod │ │ └── <リソース名>.yaml │ └── stg │ └── <リソース名>.yaml ├── src ← ソースコードディレクトリ │ ├── <リソース名>.ts │ ├── types │ │ └── index.ts │ └── util.ts ├── test ← テストコードディレクトリ │ └── <リソース名> │ ├── __snapshots__ │ │ └── snapshot.test.ts.snap │ ├── awspec_spec.rb │ ├── fineGrained.test.ts │ └── snapshot.test.ts ユーザ コントロール部 フレームワーク部
インフラCI・CD実現事例 24
CI・CD 不安の種 25 ◉ 意図しないリソース変更・削除 ◦ 特にステートフルなもの
Check! Check! Check! 26 ◉ Snapshot・Fine-Grainedテスト ◦ PR時に修正でSnapshotがどう変化するかCheck! ◦ Gitの歴史にSnapshotの変化履歴を残して
◦ Fine-Grainedテストは肝要な所に絞って ◦ もちろんCIにも組み込む
Check! Check! Check! 27 ◉ cdk diff ◦ 実際にデプロイ済みのテンプレートとの差分Check! ◦
replace & destroyがないことを機械的に確認 ▪ もしくは許容する対象であることを確認
Check! Check! Check! 28 ◉ awspec ◦ デプロイ後の実リソースパラメータCheck! ◦ 実パラメータテストの蓄積は品質向上を促進
▪ k1LoWさん、いつもお世話になってます
CI・CDプロセス 29 ◉ CI test stage 静的解析 Snapshotテスト Fine-Grainedテスト diff
stage cdk diff PR時に 影響確認可能
CI・CDプロセス 30 ◉ CD diff stage cdk diff >> >>
deploy stage cdk deploy awspec stage rake spec ここでデプロイ 承認
CI・CDプロセス 31 ◉ デイリーテスト ◦ cdkはリリース頻度が高い ◦ 毎日最新パッケージでテスト ▪ コードの陳腐化検出
daily_test stage 静的解析 Snapshotテスト Fine-Grainedテスト
アプリエンジニアの声 32 ◉ インフラの状態確認が容易になった! ◦ コンソールを見なくても現状確認できる ◉ インフラも過去の状態に遡れるようになった! ◦ 変更履歴がソースとして残るため
◉ リソース間依存関係がわかりやすくなった! ◦ 依存関係把握に各サービスを行ったり来たりせずに済む ◉ デフォルト値と指定値の違いが明確! ◦ どのパラメータに興味がある・あったのかがわかる ◉ ソースコードの記述量が意外と少ない! ◦ 記述の抽象度が高いため ◉ 新規環境作成時に過不足が軽減された! ◦ 新規環境用の設定値さえ用意できれば、同じものを複製可能 ◉ 違う観点での複数テストで安心感がある! ◦ 安心ポイントが複数 (デプロイ前、直前、後 ) ◉ 既存環境の適用はやっぱり怖い … ◉ インフラのナレッジはやっぱり必要 … ◉ CFnのナレッジもあるに越したことなし … ◉ Versionが頻繁に上がるので少し不安 …
まとめ 33
まとめ 34 ◉ アプリエンジニアに対して何を提供できる? ◦ クラウドインフラエンジニアの命題の一つ ▪ 安心して、開発に専念できる環境の提供 ◦ k8s利用推進やクラスタ提供であってもOK
▪ ただし、アプリエンジニアが望んでいれば ◦ CDKによるIaC推進もその一つかなと
ご質問はお気軽にどうぞ ! ◉ twitter: bbrfkr ◉ mail:
[email protected]
Thanks! 35