これは CDK Advent Calendar 2021 の 18 日目の記事です。
みなさん、こんにちは。初めてアドベントカレンダーに参加するため、Qiita でのやり方や趣旨とあっているのか、少し不安を感じていますが書いてみたいと思います。
当初は AWS CDK に関して小ネタを書こうと思っていたのですが、12/3 に発表された The CDK Book を購入し、その導入に書いてある内容が、自分は他で聞いたことがなかったことと、非常にワクワクするような内容だったこと、現時点(2021年12月18日 時点) では英語のみの出版のため英語が得意ではない方々にもこのワクワクを!と思いこの内容にしました。
ちなみに、私はこの本の執筆・売上に何の関係性もありません。
The CDK Book ( https://thecdkbook.com/ )とは
Community Hero の人達が中心に書き 2021/12/3 に発売された本で、英語で読むことができます。初心者から上級者までをターゲットとして謳っていて、CDKのコンセプトの概念的な説明から始まり、開発へ導入する際の実践的なガイドまでカバーしています。
内容を 8 割程度読んだ時点の個人的な感想は下記の通りです。
- CDK の成り立ちと発展の方向性に関する記載が興味深い (この記事の本題)
- v1 のコンテンツが多い中、CDK v2 を例に書かれている。
- v2 から v1 への移行にそこまでハードルはないという感覚ですが、本としての対応は現時点で最も早いと思います。
- Typescript で CDK Construct を作成し、環境の管理には projen を利用、 jsii で多言語対応をしてから Construct Hub へとあげる流れが記載されている。
- 最近公開された Construct Hub が紹介されているあたり、新しいリソースへ読者を導いてくれ、次のステップへ進みやすくなっていると感じます。projen の使い方などの流れに関して、大まかな流れとしては Qiita の中だとこの記事が参考になると思います。(projen ではじめる快適 AWS CDK Construct Library 開発生活)
- 複数人で開発する際の細かい運用時における Tips が多い。
- この点は特に参考になりました。例: 設定項目の管理における選択肢と良し悪し。社内へ CDK を普及させるための訴求方法。社内で共通利用する Construct を使い回す際の運用方法例。Custom Resource を作成する際の選択肢。ブランチ戦略など。
- snippet が多く、エンドツーエンドで利用できる example がまだ少ない。
- ここは唯一のマイナス点でした。Github にサンプルはありますが、これから増えていくものと予想しています。例を求める場合は、CDK のドキュメントは非常によく書かれていると思っていますが、Construct Hub、AWS Solutions Contructs、AWS CDK Patterns、CDK workshop、Awesome CDK、AWS CDK examples、CDK Construction Zoneなどのオンラインリソースや、実践 AWS CDKなどの書籍がおすすめです。
それではここから、本題に入ります。
CDK の成り立ち
The CDK Book のまえがきを AWS の Principal Software Engineer である Elad Ben-Israel さんが書いており、Amazon 社内における CDK の成り立ちに関する記載がありました。
Elad さんは 2016 年当時 Amazon における製品の検索を担当するチームにいて、リアルタイムで膨大な検索データをストリーミング処理する機能を AWS Lambda, Amazon Kinesis, Amazon DynamoDB で開発されていたようです。そしてこの機能を開発、ステージング、本番環境に対してデプロイするために、AWS CloudFormation を利用していたところ、少しずつ課題が出てきたというのが始まりだったと記載がありました。CloudFormation はクラウドにおけるリソースの状態を yaml で宣言的に記述できるというメリットがある一方、デプロイ前のテストが困難であったり、論理的な単位とそれぞれの関係性を表現し、何度も再利用したいアーキテクチャパターンを取り扱うという観点では課題があったと述べられています。
通常のコードであれば、OOP の考え方や、条件分岐、loop が利用でき(CDK ではやりすぎ注意ですが)、使いまわしたいコードはライブラリにしておいてパッケージマネージャで管理できます。そのため、コードのように開発でき、クラウドのリソースは宣言的にデプロイ・アップデートしてくれるようなツールが欲しいというのが CDK の発想だったと述べています。自分の場合も、Security Group の設定や一般的な Web 三層のテンプレートを何回もコピペしていた時代の記憶が蘇ってきて、非常に共感できました。
Troposphere や GoFormation の利用も検討されたものの、Composability が欠けていて再利用性が低かったのと、アプリケーションの開発言語とインフラ用の言語を統一したいという観点から自分たちで開発することにしたそうです。特に AWS Lambda のようなサーバレスな環境において、インフラとアプリケーションコードが同じ言語で開発されていれば、インフラとアプリを一緒に開発・テスト・リリースしやすくなることからこれが重要視されていたと述べられています。
そして、通常の開発言語で利用可能で、Construct の概念をもった「Cloudstruct」が作成されたという流れです。社内のみで数ヶ月本番利用したのち、Press release を作成して社内へ提案し、予算獲得と CDK としての公開に至ったということでした。
Press release を書くというのは Amazon のプロダクト開発においてよく知られている手法で、実際にこれをやっている点や、CloudFormation を利用していた時と似たような悩みどころを、Amazon のエンジニアも抱えていたことがわかり、非常に興味深いポイントでした。
CDK の発展の方向性について
Elad Ben-Israel さんの視点から CDK の発展について Up、Down、Left、Right の 4 つの方向性が記載されています。
Up (上方向)
「上」とは、抽象化の方向、つまり L3 Construct がさらに増えていくことが予見されています。これまでの CDK の発展としては、利用者が AWS やインフラの知識を持ち、それを意識して利用することを想定した L2 Construct や L1 Construct がメインとなっていました。しかしながら、例えば、静的ウェブサイトをホスティングすることを考えたときに、そのインフラがどんなサービスで構成されているのかを意識しなくていい方が、学習コストがかからない分、良いとしています。S3 バケットへ html や css を置き、CloudFront のディストリビューションを設定して、API には API Gateway と Lambda を用意するといったところを意識しなくていいと、さらなる効率化に繋がるはずです。
今後出てくるであろう L3 Construct の例として、マイクロサービスのフレームワーク、ビッグデータの分析環境、コンプライアンスや規制に準拠するためのパターン、事業 (Line-of-business)でよく利用されるアプリケーションの構成、機械学習のパイプラインや ML Ops 的な構成などがあげられていました。
自分が一番はじめに CDK を利用しはじめたときは、AWS をすでに知ってしまっており、CloudFormation を利用していたため、CDK は最初抽象化されすぎていて使いずらいと感じた経験がありました。しかし、L1 Construct を利用し始めて、「これはいい」となった経験があるので、L3 Construct が有効ではない場面は多くあると個人的に思っています。しかしながら、全てのプロジェクトで同じレベルのコントロールを求めるかというとそうではないのと、色々なものを早く開発できる便利ツールが増えていくことは楽しみですし、裾野が広がるきっかけになりそうだなと思っています。
Down (下方向)
現在は CDK の Construct とインフラをプロビジョニングする仕組み (主に CloudFormation) が密結合になっていますが、CloudFormation との疎結合化を進め、CDK for Terraform や、CDK for Kubernetes などのような仕組みがさらに発展していくだろうと述べています。こうなれば、CloudFormation が取り扱える領域に縛られず、さまざまな環境で CDK を利用できるようになり、さらに便利になる将来が来るかもしれないことを示唆しています。
現在は Terraform と Kubernetes のみですが、さらに選択肢が増え、抽象度の高い Construct をさまざまな環境(例えばオンプレミスとのハイブリッドクラウド環境や、Fog computing 環境など)でも活用できるようになると嬉しいですね。
Left (左方向)
これはProjenの発展についてです。Projen は CDK で利用されている Construct のプログラミングモデルを利用して開発されており、開発環境の管理を効率化するために利用するものです。
CDK の考え方は CloudFormation テンプレートのようなインフラの設定ファイルを生成・管理するツールにとどまらず、コンパイラやテストの設定・依存関係に関する設定ファイルの管理、ワークフローの定義やエディタの設定などに利用できるようになってきています。CDK を IDE の補助ツール ("meta-IDE"と表現されていました) として利用し、インフラだけでなくアプリケーションも含めた形で統一的に管理できるツールが発展してくることが見込まれています。
ツールや言語によって、IDE やプラグインで管理できるところもあれば、そうでもないことがあり、あー設定変更を忘れてた!となることもあるので、projen で全ての依存関係などを一括管理ができると、確かに楽になりそうだなとは思っています。リリースから1年ちょっとたっているものの、個人的にはそこまで使ったことがなかったツールですが、便利そうなので、今後試してみたいと思いました。
Right (右方向)
現在のCDKでは、インフラ開発でコードを書いている時には Construct の抽象化が働いてくれる一方で、デプロイされたあとのインフラを運用する観点から考えたときは、それぞれのリソースを強く意識した運用が必要となってきます。いわゆるLeaky abstractionがある状態だと表現されていました。
例えば、開発者が AWS 上に L3 Construct で静的ウェブサイトをデプロイしたとしても、別の運用者が展開されたリソースをみて運用をしたいとき、見えるのは S3 Bucket や CloudFront Distribution、CloudFormation の画面となってしまう状況のことを指しています。Construct のツリー構造や抽象化された状態をデプロイされた後でも保持でき、同じ抽象化を保ったまま運用時でもより簡単に CDK を利用できるようにする方法が検討されているそうです。
IaC を利用した運用において、自分自身はたびたび聞いたことがあるトピックで、全員がCloudFormation や CDK を理解していれば問題ないですが、そうではない場合はリリースポータルなどを自作しているケースなども知っています。ここが解決してくると CDK の採用をさらに推進するモチベーションにつながると思い、とても楽しみなところです。
おわりに
CDK の成り立ちとその発展の方向性について、現時点で CDK の人が考えていることを The CDK Book の記載内容をもとにまとめました。こういった波に乗れれば、みなさんもCDKの先駆者になることもできるんじゃないでしょうか？また、このあたりの便利ツールをすでに自作していれば、contribute をしていく口実にもなるのかなと思います。
それではまた。