AWS CDKを使って開発環境を構築してみた

こんにちは。
ユニバーサルゲーム事業部でサーバーエンジニアをしているコスキです。
(これまで名古屋、東京、それぞれの拠点に置かれていた名古屋スタジオ、東京スタジオのスタジオ制を廃止し、9月1日付でユニバーサルゲーム事業部・グローバルマーケティング&クリエイティブ事業部を新設しました。)

自分はサーバーエンジニアとして所属しているので、普段はバックエンドのロジックを書いてアプリで使用するAPIを作成しています。また、運営メンバーが使うツールの作成・改修も行なっているのでバックエンドだけでなくフロントエンドをさわったりもしています。
これは弊社のプロジェクトの多くでは「広くいろいろな事ができるようになろう」というスタンスが取られているためです。希望をすれば業務内でサーバーやフロントやインフラの業務を経験できます。
このスタンスは勉強会にも現れていて、例えばUnityの勉強会にもサーバーエンジニアの自分が参加できたりしていました。

そのような会社ですので、サーバーエンジニアの自分でもインフラのタスクとして新しい開発環境の構築のタスクを行う機会がありました。
その際にCDKというIaC(Infrastructure as Code)の手段を使ったので、このブログではCDKの紹介をしていきます。

CDKとはなにか

そもそもCDKとは何なのでしょうか。
CDKはAWS Cloud Development Kitの略で、プログラミング言語を使用してAWSのクラウドリソースを定義・管理するIaCの手段の1つです。
TypeScript及びPythonなどの一般的なプログラミング言語を使用して、どんなAWSのサービスをどんなスペックで用意するのかというリソースを定義してAWS上でのインフラを構築できます。

同じようなもので主流なところとしてはTerraformというのがありますね。
今回のプロジェクトでCDKを使った理由としては以下の点が挙げられると考えています。
社内のインフラを基本的には全てAWSで構築している点、社内にCloudFormationの知見があった点、AWS側のサポートを受けられた点、などです。

AWS上でのリソースとの関連付けについて

CDKで定義したAWSリソースは最終的にはCloudFormationでスタックごとに管理されます。
スタックとは、単一のユニットとして管理できるAWSリソースの集合です。つまり、スタックを作成・更新・削除することで、AWSリソースを作成・更新・削除できます。
同じ名前のスタック名で新しい環境を作ることができないことや、RDSをコンソール上から削除するように直接変更を加えると管理している状況と実態が異なることなどにも注意が必要そうです。

CDKでインフラ構築する流れ

CDKのコマンドをインストールする

CDKを使うためには、そのツールキット(AWS CDK CLI)をインストールする必要があります。
AWS CDK CLIはNode Package Managerからインストール可能です。

npm install -g aws-cdk

認証を通す

MFA認証を有効にしている場合、手元のターミナルでCDKコマンドを実行するにはAWSと疎通するので認証を通すためにmfaのProfileを設定する必要があります。
mfaはPythonのパッケージ管理システムのpipからインストール可能です。

pip3 install aws-mfa
vi ~/.aws/credentials
vi ~/.aws/config
aws-mfa --profile [profile名] --device arn:aws:iam::XXXXXXXXXXXX:mfa/<ユーザー名>

.aws/credentialsの中身は以下のように設定します。

[del-long-term]
aws_access_key_id = AKIXXXXXX
aws_secret_access_key = xxxxxxxxxx

.aws/configの中身は以下のように設定します。

[profile del-long-term]
region = us-east-1

CDKでリソース定義する

一例として、AWSのCDK入門ガイドにあるVPCの作成コードから抜粋すると、以下のようなJavaScriptの10行程度のコードでVPCの定義ができてしまいます。

const vpc = new Vpc(this, 'MainVpc',{
    maxAzs: 2,
    subnetConfiguration:  [{
        cidrMask: 24,
        name: 'public-subnet',
        subnetType: SubnetType.PUBLIC
    },]
});

ビルドする

CDKでリソース定義をしたコードは最終的にCloudFormationテンプレートに出力する必要があります。
そのためのビルドコマンドがcdk synthesize（cdk synth）です。

cdk synth

また、特定のスタックのみを指定してビルドもできます。

cdk synth [stack名]

AWSにデプロイする

ビルドしたテンプレートをAWSにアップロードしてCloudFormationを使用して実行すると共に、定義したリソース内容をCloudFormationで管理するためのコマンドです。
手元のPCからAWSへ疎通するために、予めaws-mfaを使って認証を通しておいたprofileを指定します。

cdk deploy [stack名] --profile [profile名]

変更をしたい場合

構築ができた後でもリソースの追加や変更したい場合があります。
その場合は、手作業で直接変更するのではなくCDKを修正してビルドしてデプロイし直す方法を取ります。
その際に現状のCloudFormation上で定義されているリソースと、修正後のCDKで定義するリソースとの差分確認をするコマンドがあります。

cdk diff [stack名] --profile [Profile名]

差分が正しければ、deployコマンドで変更を反映します。

感想

最後に、サーバーエンジニアとしてCDKを使ってインフラ構築するメリット・デメリットを感じたので、それぞれまとめて締めたいと思います。

メリット

まずは「サーバーエンジニアでもインフラを理解・構築しやすい」という点がメリットとしてあります。
独自の言語ではなく、TypeScript及びPythonなど一般的なプログラミング言語でコードを書いてリソースの定義ができます。
そのため「どんなサービスを、どんなスペックで、どう連携させているのか」といったリソース定義は読みやすいです。
また、一般的なプログラミング言語を使用するメリットとして、以下のような点が挙げられます。

制御構文に加えて、クラスや継承などの抽象化に役立つ機能が利用できる
エディタによる型チェック、コード補完、APIドキュメントの参照が可能

複数の環境を作成する場合、環境ごとの差分をうまく扱う必要がありますが、その際に制御構文や抽象化の機能が役立ちます。
構築についてはCDKの実行コマンドを行うだけですからね。

また、CDKだけのメリットではないですがIaCのメリットとして、コードがあれば同じような環境を複数用意できる事、CDKの実行のみであれば人によらず誰でもインフラ環境を構築できる事もメリットです。
特にこのプロジェクトは開発環境だけでも9個くらいの環境が存在していたので、1つのCDKのコードから環境の構成を複製できるのは、時間や手間やミスの危険性としてもかなり減らせたのだと感じます。

デメリット

一般的なプログラミング言語の機能を使える影響でコードが属人化していく可能性があります。
例えば条件分岐・繰り返し処理・クラス化・ファイル分割などが人によって書き方やまとめ方が変わってくるので、人によって違いが現れ、それが大きくなれば属人化したコードになっていきます。

また、手動で作ったほうが楽という問題もあると思います。
構築する回数や内容が少なければ、CDKのコードでリソース定義・ビルド・デプロイするよりも、AWSコンソールから手作業で作ったほうが楽で早いという状況はありそうです。

あとCDKはAWS専用という点でしょうか。
例えば同じIaCのTerraformはAWSだけでなくGCPやAzureなど他クラウドサービスにも対応しています。AWSを使ってないプロジェクトに配属された時など経験を活かしづらいケースはありえそうです。
また、AWS内で完結するのではなく複数のサービスを連携する場合などは、すべてをIaCでまとめようとするとCDKではできないので手作業での連携作業がでてくるかと考えられれます。

しかし、2022年8月にGAを迎えたCDK for Terraformを使用した場合、Terraformの仕組みを使いつつ一般的なプログラミング言語で設定ができるようです。
こういった機能も選択肢の1つになりそうです。

インフラ状況をコードで管理できるIaC自体はすごく良さそうだと感じました。
CDKはいくつかあるIaCの手段の1つなので、所属しているプロジェクトの状況やメリット・デメリットを比較して使っていけると良さそうですね。