【ITニュース解説】🚀 Deploying a Node.js CRUD App on AWS with Terraform

今日のクラウド環境では、ウェブアプリケーションを公開する際に、サーバー構築やネットワーク設定を手作業で行うと、多くの手間がかかり、ミスが発生しやすくなるという課題がある。また、繰り返し同じ環境を構築する際に非効率的になることが避けられない。そこで、インフラを「コード」として定義し、自動的にプロビジョニングする「Infrastructure as Code（IaC）」という考え方が重要になる。この解説では、TerraformというIaCツールを使って、Node.jsで開発したウェブAPIを、Amazon Web Services（AWS）のクラウド環境にデプロイする具体的な方法について説明する。

今回構築するのは、Node.jsとExpressフレームワークを用いて作成された、基本的なTodoリストの操作（作成、読み取り、更新、削除、いわゆるCRUD操作）を行うAPIである。データの永続化にはMongoDBを利用する。このAPIアプリケーションは、まずDockerという技術を使ってコンテナ化される。Dockerは、アプリケーションとその実行に必要なすべての要素（コード、ランタイム、システムツール、ライブラリなど）を一つのパッケージにまとめる技術で、これにより「どこでも同じように動く」環境を簡単に実現できる。作成されたDockerイメージは、AWSが提供するコンテナイメージの保管場所であるAmazon Elastic Container Registry（ECR）に保存される。

デプロイ先となるAWSでは、Amazon Elastic Container Service（ECS）のFargate起動タイプを使用する。Fargateは、利用者がサーバー自体の管理（OSのパッチ適用やリソースのスケーリングなど）を意識することなく、アプリケーションのコンテナ運用に集中できる点が大きな利点だ。このECS Fargate上で動作するサービスは、AWSが提供する仮想ネットワーク環境であるVirtual Private Cloud（VPC）内に構築される。外部からのアクセスはApplication Load Balancer（ALB）が受け持ち、複数のECSコンテナにトラフィックを分散させることで、負荷を均等にし、安定したサービス提供を可能にする。また、MongoDBへの接続情報のような機密データは、AWS Secrets Managerというサービスに安全に保管され、アプリケーションから必要に応じて取得される。アプリケーションの実行中に発生するログは、AWS CloudWatch Logsに集約され、一元的に監視・管理できる。

これらのAWS上に構築されるインフラリソースはすべてTerraformというツールで「コード」として定義される。具体的には、VPCやサブネットといったネットワーク設定、ECSクラスターやサービス、ECRリポジトリ、そしてAWS Identity and Access Management（IAM）ロールやセキュリティグループといったアクセス権限やネットワークのセキュリティ設定、CloudWatch Logsの設定、Secrets Managerの設定などが、それぞれの.tfファイル（Terraformの設定ファイル）に記述される。これにより、同じインフラを何度でも、ミスなく、しかもコードとしてバージョン管理しながら構築・更新できるようになるのだ。

このシステム開発のプロセスはいくつかのステップに分かれる。まず、Node.jsとExpress、Mongoose（MongoDBのオブジェクトデータマッピングライブラリ）を使って、Todo APIのバックエンドを実装する。ここでは、server.jsがアプリケーションの開始点となり、一般的なウェブアプリケーションの構造であるcontrollers（ビジネスロジック）、models（データ構造）、routes（APIエンドポイント）といった構成でAPIが定義される。ローカル環境でAPIが正しく動作することを確認した後、次のステップとしてDockerファイルを作成し、アプリケーションをコンテナ化する。Dockerfileには、Node.jsのベースイメージを選び、依存関係をインストールし、アプリケーションコードをコンテナ内にコピーして、コンテナが起動したときに実行するコマンドを指定する。これにより、どの環境でも一貫してアプリケーションを実行できるようになる。

アプリケーションのコンテナ化が完了したら、次にAWSインフラのデプロイ準備に取り掛かる。まず、Terraformの初期化コマンドを実行し、AWSプロバイダーの設定を読み込む。次に、terraform apply -target=aws_ecr_repository.appというコマンドを使って、ECRリポジトリだけを先に作成する。これは、後で作成するDockerイメージをプッシュする場所を先に準備するためである。ECRリポジトリが用意できたら、ローカルでビルドしたDockerイメージにタグを付け、AWSアカウント認証情報を使ってECRにログインし、ECRリポジトリにイメージをプッシュする。これで、ECSがアプリケーションコンテナを起動するために必要なイメージがAWS上に準備されたことになる。

いよいよインフラのデプロイだ。terraform applyコマンドを実行することで、Terraformが.tfファイルに記述されたすべてのAWSリソース（VPC、ECS、ALB、IAM、Secrets Managerなど）を自動的にプロビジョニングする。このコマンドを実行すると、Terraformは計画（plan）を表示し、実際に何が作成・変更されるかを教えてくれるので、内容を確認して問題なければ承認してデプロイを実行する。デプロイが完了すると、ALBのDNS名が出力される。このDNS名を使って、ウェブブラウザやcurlコマンドでAPIエンドポイントにアクセスし、アプリケーションが正常に動作しているか確認できる。

アプリケーションの機能が追加されたり、バグが修正されたりした場合、更新をデプロイする必要がある。この場合、変更を加えたアプリケーションコードで新しいDockerイメージをビルドし、異なるタグ（例えばv2）を付けてECRにプッシュする。その後、Terraformの設定ファイルで参照するイメージタグをv2に更新して、再度terraform applyを実行する。すると、TerraformはECSサービスが新しいイメージを使うように設定を更新し、ECSは既存のサービスを停止させることなく、新しいバージョンのコンテナを順次起動し、古いバージョンと置き換えてくれる（ローリングアップデート）。これにより、サービスの停止時間を最小限に抑えながら、安全にアプリケーションを更新できるのだ。

デプロイ後も、システムの安定稼働のためには監視が欠かせない。アプリケーションが出力するログはすべてAWS CloudWatch Logsに集約されるため、問題が発生した際にはここを確認することで原因究明に役立つ。また、ALBは定期的にECSタスクのヘルスチェックを行い、異常のあるコンテナを自動的に交換することで、サービスの可用性を高める。

セキュリティも非常に重要な考慮事項だ。本番環境では、アプリケーションコンテナが稼働するサブネットをインターネットから直接アクセスできないプライベートサブネットに配置し、NAT Gatewayを介してのみ外部と通信させるべきである。Secrets ManagerのIAMロールは、特定のシークレットへのアクセスのみを許可する最小限の権限に制限する。Dockerイメージのタグ付けには、latestのような曖昧なタグではなく、v1、v2といった具体的なバージョン番号を使用し、デプロイされるイメージが一意であることを保証する。さらに、ALBでHTTPSを有効にし、AWS Certificate Manager（ACM）でSSL/TLS証明書を使用することで、クライアントとALB間の通信を暗号化し、セキュリティを向上させる必要がある。

このように、ほんの数個のTerraformファイルを使って、コンテナ化されたNode.js API、セキュアなAWSネットワーク、負荷分散されたECSサービス、機密情報の管理、そしてログ収集といった複雑なインフラを自動的にプロビジョニングできる。このアプローチは、より多くのマイクロサービスやCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインと組み合わせることで、さらに強力な開発・運用体制を構築できる。例えば、GitHub ActionsやGitLab CIといったCI/CDツールと連携させれば、コード変更がプッシュされるたびに自動的にDockerイメージのビルド、ECRへのプッシュ、そしてTerraformによるデプロイまでを自動化することが可能となり、開発者はアプリケーション開発に集中できる環境が手に入るだろう。