初めてのECS本番投入！個人のNuxt3アプリをECS on EC2で動かす
1. はじめに
こんにちは！個人開発でNuxt3を使ったライフスタイル管理アプリを開発しています。
突然ですが、皆さんは個人開発のインフラコスト、どうしていますか？「サービスを公開したいけど、月々の固定費はなるべく抑えたい…」というのは、多くの人にとって共通の悩みだと思います。
この記事では、そんなコスト問題と向き合いながら、AWSのECS (Elastic Container Service) を利用して、初めて本番環境へのデプロイを成功させた私の奮闘記です。個人開発のプロジェクトとして、まず達成したインフラ構成、その構築を通じて得られた学び、そしてこれから目指すアーキテクチャの展望について記録します。
2. スタート地点のインフラ構成
まず、本日稼働に成功したインフラの全体像がこちらです。
構成のポイント:
- 単一のEC2インスタンス: すべての処理を1台のEC2インスタンスに集約し、コストを最小化。
- 単一のECSタスク: Nginx、Nuxtアプリ、データベースの3つのコンテナを1つのECSタスクとして定義・管理。
- コンテナ化されたNginx: Nginxもコンテナとして稼働させ、SSL終端とリクエストの振り分けを担当。
- S3連携: ファイルアップロードはS3に保存。
この構成は、個人開発のスタート地点として、コストと管理のしやすさのバランスが取れた、現実的な選択肢だと考えています。
3. 技術選定の背景：なぜ「ECS on EC2」なのか
ECSには「Fargate」と「EC2」の2つの起動タイプがありますが、今回EC2を選択したのには、いくつかの理由があります。
- 一番の動機は、コスト効率！: 個人開発者にとって、月々の固定費は死活問題です。小規模なアプリの場合、Fargateよりも低スペックのEC2インスタンスを常時稼働させる方が、トータルコストを抑えられる可能性があります。
- 学習のため: EC2のネットワーク設定やインスタンス管理といった、AWSの基本的なコンポーネントに深く触れることは、インフラの知識を深める絶好の機会だと考えました。
4. 技術選定の背景：なぜ「ALB」ではなく「Nginx」なのか
そして、今回のコスト削減における主役が、ALB (Application Load Balancer) の代わりに採用したNginxです。これには、明確なメリットと、引き換えになるデメリットが存在します。
メリット：コスト削減と柔軟性
- コストの大幅な削減: ALBは稼働時間に応じた料金が発生するため、個人開発の小規模トラフィックでは割高になりがちです。EC2上のNginxであれば、追加のインフラコストはかかりません。月々数千円でも、個人開発にとっては大きな違いです。
- シンプルなSSL管理: Let's Encryptを使えば、SSL証明書の取得から自動更新までをEC2内で完結させることができます。
デメリット：管理の手間とスケーラビリティ
- 管理オーバーヘッドの増加: Nginx自体の設定やセキュリティパッチ適用、ログ管理などをすべて自己責任で行う必要があります。
- スケーラビリティの課題: トラフィックが急増した際、ALBのように自動でスケールはしてくれません。
- 可用性の低下: Nginxが稼働するEC2インスタンスが、システム全体の単一障害点（SPOF）になってしまいます。
これらのトレードオフを考慮した結果、**「個人開発の初期段階においては、管理の手間よりもコスト削減のメリットの方が大きい」**と判断し、今回の構成を選択しました。
5. 構築を通じて得られた学び
- Nginxの仕事の多さ: 単なるリクエスト転送だけでなく、SSL管理、セキュリティヘッダ付与、ログ管理など、Nginxが担う役割の多さと重要性を再認識しました。
- コンテナ間通信の理解: ECSタスク内で定義されたコンテナ同士が、Dockerネットワークを通じて互いに名前解決して通信する仕組みは、実際に動かしてみて初めて深く理解できました。
6. 今後の展望：フロントとAPIの分離アーキテクチャへ
現在の構成はシンプルで良い一方、将来の拡張性を考えると、改善の余地があります。そこで、次のステップとして、以下のようなフロントエンドとAPIを完全に分離したアーキテクチャを目指しています。
この構成では、API Gatewayを導入し、Nuxt3のビルド成果物を分離することで、以下のメリットが生まれます。
- パフォーマンス向上: 静的アセットをCloudFrontから配信することで、サイト表示を高速化します。
- セキュリティ強化: API GatewayがAPIの窓口となり、WAF連携やレート制限が可能になります。
- 責務の分離: フロントエンドとAPIのインフラが明確に分離され、より管理しやすく、スケールしやすい構成になります。
7. おわりに
まずは「ECS on EC2」でサービスを本番稼働させるという大きな一歩を踏み出せました。インフラは一度作って終わりではなく、サービスの成長に合わせて改善していくものだと実感しています。この記事が、同じようにインフラコストと戦う個人開発者仲間の一助となれば幸いです。
Discussion