🚀

AWSサーバレスアプリの構成管理方法

2023/10/22に公開

AWS

JavaScript

AWS CDK

idea

※この記事はサーバレスなオンラインじゃんけんアプリを作ってみたのサブ記事です。

今回開発したオンラインじゃんけんアプリのAWS側の構成図はこんな感じになっており、Clientからのリクエストを受け付けるためにAPI Gatewayを使っており、バックエンドにはLambdaを使っています。

今回はこのAWS側の構成を管理するためにAWS CDKを使ったことと、そのメリットとデメリットを紹介したいと思います。

AWS CDKとは

AWSのIaCサービスとしてはCloudFormationがありますが、それをプログラミング言語で使えるようにしたものがAWS CDKです。Pythonやnodejs、goなどさまざまなプログラミング言語で提供されており、自分が慣れ親しんだプログラミング言語でIaCを行うことができるツールです。

AWSを使う時の悩み

通常はAWSでインフラを構築する時は、AWSコンソールから操作することが多いと思います。しかし、画面操作になるため手順書を記録しておかなければ環境を再現することはできないし、そもそも手順書なんて作るのは面倒です。しかも、バージョン管理も難しく１点ものの環境になりがちです。それを解決するのがIaCなのですがCloudFormationを使おうとするとCloudFormationテンプレートの記法を習得する必要があり、それが独特なため難しい（というかめんどくさい）という壁があります。
そこで、エンジニアが普段使っているプログラミング言語で環境を構築できたら、という思いを実現したのがAWS CDKということです。今回はこれを使って環境の管理を行いました。

AWS CDKでできること

AWS CDKでは、AWSにデプロイするリソースの定義を行い、PC上からコマンドを使ってデプロイすることができます。一度デプロイした後にも、コードを更新することがありますが、その時は更新分を再度デプロイすることができいます。
今回はLambdaを使っていますが、そのLambda関数のソースコードも一緒にデプロイすることができるので、サーバサイド側のリソースとソースコードをまとめて管理することもできます。

例えば次の例では、2行目のresources/game_functionフォルダに格納されたソースコードをLambda関数にデプロイする設定が書かれています。デプロイ後、このソースコードを更新して再デプロイすると更新されたソースコードがLambda関数にアップロードされます。
そのほかにもランタイム環境やメモリサイズ、環境変数なども設定することができます。今回は、テーブル名やキュー名を環境変数として外出ししており、他の部分で定義したDynamoDBのテーブルやSQSのキューの名前を設定しています。

    const gameFunc = new lambda.Function(this, 'Game-lambda', {
      code: lambda.Code.fromAsset("resources/game_function"),
      handler: "game.handler",
      // layers: [gameFuncLayer],
      runtime: lambda.Runtime.NODEJS_18_X,
      timeout: cdk.Duration.seconds(300),
      memorySize: 128,
      initialPolicy: [
        connectApiExecutePolicy
      ],
      environment: {
        "TABLE_NAME": gameTable.tableName,
        "QUEUE_URL": queue.queueUrl,
      }
    });

    gameTable.grantReadWriteData(gameFunc);
    queue.grantConsumeMessages(gameFunc);
    queue.grantSendMessages(gameFunc);

AWS CDKを使ってわかったメリット・デメリット

メリット

一番大きなメリットとして感じたのは、学習コストの低さです。私はPythonとjavascriptが得意なので今回はAWS SDK for JavaScriptを使ったのですが、CloudFormationを使ったことのない私でも、ドキュメントを見ながら1週間ほどで使えるようになりました。サンプルも多いので、自分が作りたいものに似たものからピックアップしてくることによって組み上げることができました。
もう一つは、デプロイや削除が非常に簡単にできることです。デプロイは先ほど説明したのですが、削除もコマンド一つで実行できます。特に節約のために平日はリソースを削除したいときにコマンド一つでデプロイや削除ができるのはとても助かりました。
またIaCの最大の魅力だと思うのですが、gitを使ってバージョン管理ができるというのは最大のメリットだと感じました。色々試してダメでもgitを使って戻せばいいので、気軽に変更を加えられるのはいいですね。コンソールを使っていると複製したり、変更を戻したりというのが簡単にできないので、ソースコードと同じように気軽に実験できるのはやりやすいですね。

デメリット

学習コストが低いとメリットで伝えたのですが、一方で細かい設定を加えたりやリソースごとの依存関係についてはちょっとややこしく難しかったです。例えば、S3のWebサイトホスティングもコンソール上の手順はわかるのですがCDKを使った書き方となるともう少しCDKの理解がないと難しそうです。もう一歩進んで、CloudFrontを使ってWebサイトを公開するということになると、さらに難しくなります。ただ、これは慣れていくしかないので使い始めの今は仕方ないことかもしれません。

まとめ

検証段階で構成があまり固まっていない時は、コンソールを使ってぽちぽちしていた方がやりやすいと思いますが、後から作り直したり複製したいということを考えると、やはりどこかの段階でIaC化する必要があると思います。CDKは最初は慣れが必要なものの、CloudFormationを1から習うよりも使いやすいのでおすすめします。
個人開発していても、半年前に作った環境のことは忘れてしまうため、IaCという形で構成が残っているというのは重要なことだと思います。そうやってコードが積み重なっていけば、CDKに対する理解もより深まっていくので学習履歴としても重要だと思います。仕事でも使えるように、今回使っていないサービス以外の構築の仕方なども学んでいって蓄積していきたいと思います。