CDK v2 の導入でハピタスのインフラが進化！

こんにちは、開発ユニット(SRE) の卜部です。

ハピタスの基盤にはAmazon Web Services（以下AWSと記載）を使用しています。その基盤の運用にはAWS Cloud Development Kit（以下CDKと記載）を2023年1月から導入しました。今回は、CDK v2を使用している経験を共有し、どれだけ運用が向上したかについてお話しします。

メリット

TypeScriptとCDKの組み合わせを活用することで、プログラムの記述がスムーズに行え、VSCodeなどのエディタで補完機能が利用でき、関数の説明などが即座に確認できます。
単体テストが容易に実行でき、デグレーションのリスクが低減します。
既存のデプロイ済みリソースとの差分を手元で確認できるため、運用中のトラブルシューティングが効率的に行えます。
リソース間の依存関係や呼び出し関係を視覚的に理解しやすくなりました。

導入前の課題

導入前、手動でAWSコンソール上にリソースを作成する作業と、 CloudFormationテンプレートを使用してリソースの作成、更新、削除を行う作業が混在していました。

また、リソースの命名規則が統一されておらず、リソースの用途が明確でない状態でした。

これにより、どのリソースがどのような目的で構築されたのかを理解することが難しく、調査と運用に余計な時間がかかっていました。

導入のタイミングで行ったこと

言語の選定
- フロントエンドでReact + TypeScriptを使用していたため、静的型付け言語であり、エディタの補完機能が優れているTypeScriptを採用しました。
導入計画の策定
- 新しいリソースの作成にはCDKを使用し、既存のリソースのバージョンアップや変更時にCDKに移行する方針を採用しました。AWS Summit、AWS Dev Dayなどの外部イベントに参加し、AWSのソリューションアーキテクトからの意見も取り入れ、CDKの導入にメリットしか感じなかったため、他の選択肢を検討しなかったのです。

TypeScript + CDKの組み合わせ

TypeScriptはフロントエンドやサーバーサイドのエンジニアにとっても馴染み深い言語であり、リソースの状態を共有するのに適しています。

SREメンバーもTypeScriptやNode.jsに抵抗がないため、CDKの導入はスムーズに進行しました。

また、リソースの作成時に補完機能が利用でき、必要な定義が明確になるため、リソースの作成作業が迅速に進行できるようになりました。 CDK v2の導入により、ハピタスのインフラストラクチャが大幅に向上し、運用効率が飛躍的に向上しました。

Unit Test が使えるため、デグレの心配が減る

cdk 構築時にすぐ導入したのが Snapshot test です。これを使うことでリファクタリングを恐れず実施できることと、変更のあった差分がテスト失敗の差分になるので実装者にその差分であっているのか意識させることができる

既存のデプロイ済みのリソースと diff で手元で差分を確認できる

既存のリソースとの差分を確認できる機能はCloudFormationにも備わっていますが、 CDKの場合、ただ cdk diff と入力するだけで済みます。このわずかなコマンドだけで、AWSコンソールを開くことなく、手元で全体のリソースの差分を確認できるのです。

AWSコンソールで差分を確認する手順と手元での確認の速さとの間には圧倒的な差があり、これに感銘を受けました。

リソース間の依存関係を可視化しやすい

スタック管理、リソースの定義、ディレクトリ構造など、どのように整理すべきかを一度整理すれば、それに従ってリソースがどこで管理されているかが直感的に理解できます。

まとめ

運用を安全かつ安定的に行うために、CDKは非常に有用であることが確認されました。導入から1年経っていない状況ですが、社内ではCDKが不可欠なツールとなっています。

最終的にはCDKを使用して、あらゆるリソースをわかりやすく運用管理したいとの目標を掲げています。