アプリエンジニアを救え！ 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✗ ○ 環境概念✗ / ├── README.md ├── bin │ └── .ts ├── cdk.json ├── jest.config.js ├── lib │ └── .ts ├── package.json ├── test │ └── .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