こんにちは。

テクノデジタル（以下、TD）でインフラ構築などを担当しています。Mです。

6月21日にAWS Summit Japan（2日目）に現地を見てきたので、今回はその感想と今後TDに取り入れていきたいと個人的に思った開発環境（AWSToolkitForVSCode）について取り上げてみようと思います。

先に断っておきます。今回自分が参加したセッションの話はしません。もちろん、「たまごっち　Uniのアップデート配信システムの構築」の話や、「大規模オンラインゲームサーバの構築方法」など、面白いセッションは盛りだくさんだったのですが、それはアーカイブが残っているのでそちらを見てもらった方がいいとおもいまして、何より展示ブースの方が100倍有意義だったな……と感じたためです。

さて、前置きはこれくらいにして。質問です。

皆さんは開発環境と聞くと何を連想するでしょうか。

IDEですか？

最近だとDevContainerというのもありますね。（あ、TDでも絶賛布教中です。）

しかし、アプリケーションの話でインフラには関係ないよな。クラウドリソースもWebコンソールでぽちぽち作るのが当たり前だしと思ったそこのあなた！

ちょっと考え直してください。

AWSを使ってきたならCloudFormationを触ってみたことはあるでしょう。Infrastructures as CodeそうYamlやらJsonやらでVPCから様々なサーバーレスサービスまで構築できるし、ボタン一つでまとめて削除できる便利なやつです。

もし触ったことないなら触ってみてください。作っただけではお金がかからないサーバーレス系のサービスで使ってみるのがおすすめです。

このCloudFormation、条件分岐や数値のマッピング、EC2が対象だったらリテラルとしてシェルを仕込んだり（やろうと思えば）いろいろできるのですがリソース設定をYamlかJsonで書いていくのがいけていません。

なぜって？

ドキュメントを見てみると、こいつら（リソース）設定値にはしっかり型指定があるんですね。

私はIaCが好きです。

しかし、テキスト準拠のフォーマットでコードを書くのは大嫌いです。

嫌いになった原因は一年前に参加していたプロジェクトでした。CloudFormationを使用してECSのクラスターなどをデプロイしていたのですが、設定値の型エラーでかなりの試行錯誤を強いられたのです。あれは非常につらかった。

そもそも、JSOMもYamlもコードフォーマットではなくドキュメントフォーマットなんですね。それ自体はメタデータの符号を持たない、テキストの延長です。そんな代物で無理やり条件分岐などのロジックを表現しようとするから大変なわけです。我々はもうIDEの支援（レコメンテーション）がないプログラミングの時代には戻れない体になっています。

おっと、話がそれました。

ここから今回の記事の要旨です。

AWS CDKというツールがあるのはご存じでしょうか？

Cloud Development Kit、その名の通りクラウドを開発するためのオープンソースフレームワークです。

「クラウドを開発って、そんなの使う側のインフラには関係ないだろ！」

そう思った方、古いです！

知識ではなく、クラウド時代のインフラエンジニアの仕事に対する観点が古いと思います。

クラウドは抽象度の高いサービスです。すべての機能はAPIを通して提供されています。今更ですが、コンポーネントを使用しているのです。これがクラウドの利点だということを改めて思い出しましょう。

アプリケーション開発とクラウド開発は以下のように対応します。

ライブラリ　≒　各クラウド（AWS、GCP、Asure……）

クラス、コンポーネント　≒　各サービス（EC2,VPC、Route53、ECS、Fargate……）

つまり

SDK　＝　CDK

クラウドとは、アプリケーションの従量課金制ライブラリなわけです。

そう考えると、これまでのインフラの観点から考えるのは、無理があるということがわかりますね？

さあ、ようやく開発環境に話は戻ってきます。

AWS Summit japanでのAWSの最推しはAmazonQ Developer（開発者向け生成AIサービス）のリファレンスによるコーディングの高速化、という感じでした。その中でもVSCodeのAWSToolkit拡張機能とCDKによるインフラの可視化デモを見たとき、正直思いました。

「ああ、あの案件の開発中に、これが欲しかった！」

AWSコンソールのいいところはサーバーなどの情報が可視化されているところです。コンソールの方でリソースの依存関係も適切にハンドリングしてくれます。「ぽちぽち」していればある程度問題なくリソースが作れてしまうわけです。

対してIaCの場合は、真っ黒な画面につらつらと書かれた極彩色のコードだけ。十分な知識がなければコードを見てどのようなシステムが構築されているのかを理解するのはとても困難です。イメージ的な優位性はコンソールにあるでしょう。

わかりずらい？

たとえるなら、AWSコンソールでぽちぽちリソースを作成するのは、簡単な脱出パズルゲームに似ています。適切な知識があれば、パズルを間違うことなく（まあ、知識が無くて間違っていても続ければ）、脱出することができます。一方で、IaCはストラテジーゲームです。前提を理解し目的を達成するための構造や連結を熟考して、組み立て。実行は機械任せで課題があればそれを解決するように構造を変えていきます。どちらが複雑で柔軟なシステムが構築可能かは、詳しく説明しなくてもわかるでしょう。これまでIaCツールはコンピューター黎明期のコマンドラインゲームのような、不便なインターフェースしか存在しなかったのに、ツールの成熟によってGUIが実装されたわけですね。

ほら、だいぶCDKがとっつきやすくなってきたと思いませんか？

(表示の仕方はここでは長くなるので、割愛します。「AWS　CDK　リアルタイム　プレビュー」で検索してみてください）

「でも、これまでインフラばっかりやってきたから、せいぜいシェルが書けるだけで、TypeScriptとかJavaとかのプログラミング言語はわからないよ！」

ここまで読んでそう嘆いたあなたに朗報です。

CDKにおいて複雑な処理は必要ありません。AWSのマニュアル通りにCDKをプロジェクトにインポートしたら、サービスに対応したそれに最近はChatGPTなどが優秀でCDKコードのほとんどを書いてくれます。あとは要件に合わせて細かいところ（リソース名とか）をいじっていくだけ。ついでにTypeScriptの勉強もできます。AWSCDKはTypeScriptで開発されているので、使用する際に参考になる記事も多いです。

テクノデジタルでもこれからCDKを使ったアプリケーションとクラウドの統合を推し進めていきたいと思います。

最後に。

AWSSummitに行く前はCDKに苦手意識があったのですが、あのような大きなイベントに参加してみると、これまでの認識を切り替えることができました。それだけの熱量がある場所に赴くのはいい影響がありますね。来年のAWS Summitにも参加したいなと思います。