社内 CDK/Cloudformation 勉強会 CDK 利用者からみる CDK 放地宏佳 システム本部技術開発室 株式会社ディー・エヌ・エー

注意事項 ● このスライドは社内勉強会で使った資料となります。 ● 文章多めになっていますが、参考になれば幸いです。 ● 対象者は今から CDK を始める人向けです。 2

自己紹介・IaC 歴 ● システム本部技術開発室 所属 ● IaC 歴 ○ 2018 本番リリース済みの一部プロダクト・管理コンポーネントを Cloudformation で構築 ○ 2018 本番リリース済みの一部管理コンポーネントを DeploymentsManager で構築 ○ 2019 本番リリース済みのインフラをすべて Cloudformation で構築 ○ 2020 副業先のインフラを CDK を用いて構築 (CDK 4ヶ月目) ■ 現状プロダクトが本番リリースをしていないため開発環境まで ○ Terraform は利用してない 3

目次 4 CDK 検討に際して CDK を使ってみてわかったこと・わかってないこと CDK のメリット・デメリット 1 2 3 CDK My Tips 4

CDK 検討に際して 5 ● 懸念点 ○ Cloudformation(定義)に対してCDK(プログラミング)であるため、IaC が複雑化するので はないか ○ 自由にかける＝人それぞれ実装に差が出てしまい読めないコードが量産されるのではない か 懸念点はあるものの、使ってみないとわからないと思い、やってみることに。

CDK を使ってみてわかったこと・わかってないところ ● わかったこと ○ しっかりとレイヤーを分けて、どこで何を書くかのルールを作っておけば複雑にはならない ○ インフラにおいてそこまで複雑なことを実現したいことがないのと、パフォーマンスを気にした コードを書く必要がないので、直感的なコードになる ● わかってないところ ○ 複数人でやってないので、実装差異についてはわからない。 ○ プログラムほどいっぱいのものを量産することはないので、コードレビューなどで結構防げる と思われる 6

CDK のメリット ① ● プログラミング言語におけるメリット ○ 文字列操作 ■ Cfn では文字列操作をできる関数すら存在しない ■ もし文字列操作をしたいようであれば Custom Lambda を書く必要があった。 ■ → CDK では通常のプログラミングが可能となるので、本質的ではない Custom Lambda を書く必要がなくなる。 ○ 環境ごとの定数宣言 ■ Cfn では Mapping 構文を用いて定数を宣言しなければいけなかった。 ■ その書き方にも癖があった。 ■ → CDK では通常のプログラミングが可能となることで、簡潔にかける ○ 条件分岐 ■ Cfn では If 構文を用いる必要があったが、あまり直感的ではなかった。 ■ → CDK では通常の(以下略 ○ 繰り返し記述 ■ コピペもしくはマクロという機能を使う必要があった (マクロは難しい) ■ → CDK では (以下略 7

CDK のメリット ② ● CDK 自体のメリット ○ Custom Resource (Custom Lambda) の宣言 ■ 最新のリソースなど、cdk, cfn でまだ定義されていないリソースであっても、REST API が存在すれば、 Custom Resource を定義することによって、簡単に cdk と統合可能 となっている。 ■ また、REST API 以上の独自の処理を行いたい際には Custom Lambda を書く必要 があるが、cdk 自体に lambda の asset を管理する機構があるため、簡単に書くこと ができる。 ○ 導入における楽さ ■ cloudformation や terraform を作る際には、その元となる定義をどこに置くのかな ど管理のことも一定考える必要があった。 ■ cdk では cdk bootstrap でそれらの必要なものが作られ、cdk deploy で自動的に 巻かれるので、ここの運用を考える必要がない(かつ独自でみんなバラバラなことをしな い)のが便利 8

CDK のメリット ③ ● CDK 自体のメリット ○ cdk diff ■ diff コマンドを打つだけで何がどう変更されるのかがわかるのが便利。 ■ テストコードを書かなくても、リファクタリング後に diff を打つことで、 インフラ構成が変わってないことを確認可能。 9

CDK のデメリット ● リソース定義ではなくライブラリであること ○ リソースが定義ではなくてライブラリ的であるため、バージョンアップにより中身が変わってし まう可能性がある ○ 最悪なケースとして、そのまま適用できない変更(リソースの置換)がはいり、ダウンタイムが 必要な構成変更がはいったり、そもそも適用できない可能性もある。 ● βリリースが多いこと ○ 上記とかぶるが、まだ安定版のリリースがなく、大きく変更されうる可能性が高い ● @aws-cdk/core への依存 ○ すべてのリソース定義のライブラリは @aws-cdk/core に依存しており、ある一部のリソー スライブラリのみのバージョンアップさせることができない。 ○ 要するに、1.19 の @aws-cdk/aws-rds を使っている場合、 1.20 の @aws-cdk/aws-s3 を使うことができない。 ○ 1.20 の @aws-cdk/aws-s3 を使う場合は @aws-cdk/aws-rds のライブラリも 1.20 にし なければならず、上記問題が発生する可能性がある。 10

結論 ● Cloudformation よりも便利 ● 複雑になりそうと思ったけど、そんなことはない ● @aws-cdk のバージョンを固定すれば問題ない ● バージョン上げる作業も diff でどう変更されるのかが明確なので、問題ない → 今後も使っていく予定です 11

CDK My Tips 12 CDK を反復実行するために CDK のディレクトリ階層 CDK の 第２引数 1 2 3 IaC におけるレイヤー定義 4

CDK My Tips 13 CDK を反復実行するために CDK のディレクトリ階層 CDK の 第２引数 1 2 3 IaC におけるレイヤー定義 4

CDK を反復実行するために 初めて CDK を利用するときには ● cdk deploy ● cdk destroy を繰り返し使うことになります。 AWS Resource には RemovalPolicy というものがあり、destroy する際にもリソースを削除せず に残すという機能があります。 例えば CW LogGroup, ECR などですが、RemovalPolicy = Retain だと、 destroy を実行して も、リソースが残り続けます。 そうなるとリソースが存在したままになり、次回 deploy が失敗します。 はじめは RemovalPolicy = Destroy としてリソースを作って反復実行するのをおすすめします。 14

CDK My Tips 15 CDK を反復実行するために CDK のディレクトリ階層 CDK の 第２引数 1 2 3 IaC におけるレイヤー定義 4

CDK のディレクトリ階層 ● 以下のように construct と stack を分けて定義するのをおすすめします。 ● bin 以下にそのまま書くことも可能ですが、長くなるとリソースの関連がわからなくなります。 ● プログラミング言語の変数スコープを用いることで、他リソースに依存するリソースなのか、依存 しないリソースなのかが明確になります。 16

CDK のディレクトリ階層 ● contruct もわざわざ定義する必要はありませんが、以下のような共通項目を定義できるメリット があります。 ○ CloudWatchLogs は保持期限を無制限にしたい ○ S3 は KMS 暗号化をする必要がある ● また、ecs では cluster / service / role の設定をする必要がありますが、そういったコンポーネ ントをまとめ上げて、他 Stack で再利用することが可能になります 17

CDK My Tips 18 CDK を反復実行するために CDK のディレクトリ階層 CDK の 第２引数 1 2 3 IaC におけるレイヤー定義 4

CDK の第２引数 https://github.com/hixi-hyi/cdk-sample/tree/master/lib/util のようなものを定義しておくと便利です。 サンプルではただの string で宣言するようになっていますが、階層構造が定義された class を使う こと以下のようなメリットがあります ● StackName を構造化でき、 cdk deploy ServiceDev* など特定の領域以下を deploy するこ とが簡単になります。 ● CfnOutput の命名規則もコード規約で制限できるので変な Export を作れなくできます ● リソースによって文字種の制限があり、その結果 CamelCase, snake_case を使うケースが出 てきますが、簡単に変換が可能になります 19

CDK My Tips 20 CDK を反復実行するために CDK のディレクトリ階層 CDK の 第２引数 1 2 3 IaC におけるレイヤー定義 4

IaC におけるレイヤー定義 21 例えばになりますが、僕は以下のようなレイヤー構造を考えて、それぞれの Stack を定義するように しています。 どこまでを量産するのか、どこまでを共通として使うのかなどを考えて Stack を作っていくのが良いで す。 AWS Account Layer AWS Account Stack Environment Layer Environment Stack Service Layer dev.hixi.jp Stacks qa.dev.hixi.jp Stacks route 53 ( dev.hixi.jp ) SNS (chatbot) common stack api 2 stack api 1 stack common stack api 2 stack api 1 stack ACM CDK Stack

IaC におけるレイヤー定義 22 この例でいうと、例えば DNS は Environment Layer 以下で一律。 Common Stack では Network や RDS を構築するんですが、要するに dev.hixi.jp と qa.dev.hixi.jp は別々の VPC や RDS を使うという感じになります。 AWS Account Layer AWS Account Stack Environment Layer Environment Stack Service Layer dev.hixi.jp Stacks qa.dev.hixi.jp Stacks route 53 ( dev.hixi.jp ) SNS (chatbot) common stack api 2 stack api 1 stack common stack api 2 stack api 1 stack ACM CDK Stack

Tips 適用後 https://github.com/hixi-hyi/cdk-sample 上記で話した Tips を適用したサンプルのレポジトリになります cdk deploy ServiceQa* とやることで Qa 環境の構築が可能になります。 23

Nested Stack について 24 CDK にも Nested Stack の概念はありますが、Nested Stack は ChangeSets を作れなくなるな ど、Cloudformation 自身でもあまり使うべきではないものにはなりますので、Stack 名で階層構造 を定義できるといいでしょう。 (e.g. ServiceDevApi / ServiceDevGui) なお、 cdk コマンドではワイルドカードを用いて deploy ができるので、 cdk deploy ServiceDev* とやれば ServiceDev に紐づく deploy が簡単にできます