NovelShaft Blog

NovelShaft のAWSインフラ構成

Written by

user

in

NovelShaft では、作品の執筆・配信プラットフォームをフルマネージドなクラウド環境で構築しています。以下のように複数ドメインで役割を分割し、Amazon CloudFront などのCDNサービスやAmazon ECS、Amazon RDS を中心に利用する構成になっています。

全体概要

  1. ドメイン単位の役割分割
    • novelshaft.com: ランディングページ (LP)
      • S3 + CloudFront を利用した静的サイトホスティング
    • app.creator.novelshaft.com: 執筆者向けのWebフロントエンド
      • S3 + CloudFront でBlazor WebAssemblyなどのSPAを配信
    • api.creator.novelshaft.com: バックエンドAPI
      • Amazon ECS (Fargate) でコンテナをホスティングし、ALB + CloudFront で配信。
      • 永続化に Aurora MySQL (RDS) を利用
    • auth.novelshaft.com: ユーザ認証基盤
      • Amazon Cognito の独自ドメインでホストしている
    • assets.novelshaft.com: 画像や静的ファイル配信
      • S3 + CloudFront で大容量アセットを配信
    • blog.novelshaft.com: ブログ
      • Amazon Lightsail 上のWordPressを利用（静的サイトと分離）
  2. VPC 内のネットワーク構成
    • パブリックサブネット(2AZ冗長)
      • ALB や NAT Gateway などインターネットから到達可能なリソース用
    • プライベートサブネット(2AZ冗長)
      • ECS(Fargate)や Aurora MySQL(RDS) など外部に直接公開しないリソース用
    • NAT Gateway
      • プライベートサブネットのリソースがインターネットアクセスする際に使用
    • VPCエンドポイント (ECR, S3, SSM等)
      • ECS タスクやバッチが AWS の各サービスにセキュアにアクセスするためのエンドポイント
  3. Terraformによる一元管理
    • Terraform のステートは S3 (Versioning + SSE暗号化) + DynamoDB (ロック管理)
    • バージョン管理やCI/CDとの連携がしやすく、インフラ構成をコードで再現可能

以下、主要コンポーネントごとに概要を説明します。

1. ランディングページ (LP) – novelshaft.com

  • AWS S3
    ランディングページの静的コンテンツを配置するバケット。Website Hosting は有効化せず、CloudFront Origin Access Identity (OAI) を利用して直接S3にアクセスさせないようにしています。
  • Amazon CloudFront
    グローバルCDNとして、S3 バケットをオリジンにしたディストリビューションを作成。
    Route53 の Alias レコードで novelshaft.com を CloudFront に紐づけており、HTTPS で安全に配信します。

メリット・考察

  • メリット: CloudFront を介することで、CDNキャッシュやHTTPS、WAF(必要に応じ)を簡単に導入可能。S3への直接アクセスが防げ、セキュリティ向上。
  • 考察: 小規模の場合はS3のウェブサイトホスティングで十分なケースもあるが、拡張性・セキュリティ・世界的な配信速度を重視してCloudFront経由を採用。

参考ドキュメント

2. Webアプリフロントエンド – app.creator.novelshaft.com

  • AWS S3 + CloudFront
    SPAビルド後の成果物を S3 に配置し、CloudFront 経由で配信する形は LP と同様です。
  • OAI (Origin Access Identity) でバケットポリシーを限定し、直接アクセス禁止を徹底。

メリット・考察

  • SPAではリソースの更新頻度が高いことがあるが、デプロイ時にS3の内容を差し替えて CloudFront キャッシュを無効化するだけで反映。CI/CDパイプラインと合わせると自動化が容易。
  • SPAはフロント側のルーティングがあるため、403や404を index.html にリダイレクトする custom_error_response を CloudFrontで設定している。

3. WebAPI (バックエンドAPI) – api.creator.novelshaft.com

構成要素

  1. Amazon ECS (Fargate)
    • コンテナオーケストレーション。スケーリングポリシーを設定し、自動的にコンテナ数を増減
    • ALB ターゲットグループでポート 56000 を公開 (Dockerコンテナ側でアプリが待ち受け)
  2. Amazon RDS (Aurora MySQL)
    • サーバーレスv2を利用し、アクセス負荷に応じて自動スケーリング
    • VPC のプライベートサブネットに配置
  3. ALB + CloudFront
    • ALBでHTTP(80)を受け、その上流にCloudFrontを配置
    • Route53 で api.creator.novelshaft.com のAliasレコード → CloudFront → ALB → ECS(Fargate)
  4. SecretsManager
    • DB接続情報やAPIキーを安全に保管

メリット・考察

  • Fargate によりEC2管理不要。大規模・小規模いずれにも対応しやすい。
  • Aurora MySQL Serverless v2 で、DBレイヤーのスケールや運用コストを最適化。
  • CloudFront を ALB の前段に置くと、キャッシュやWAFの導入、HTTPS終端などが柔軟になる一方、運用の複雑さが増えることも。

参考ドキュメント

4. Auth (認証基盤) – auth.novelshaft.com

  • Amazon Cognito
    • ユーザープールを利用し、メールアドレスによる認証を実装。
    • カスタムドメイン機能で auth.novelshaft.com を使い、ホワイトラベル感を実現。
    • Lambda カスタムメッセージ を連携し、認証コードやパスワードリセットのメールテンプレートを独自のHTMLにカスタマイズ。
  • Amazon SES
    • Cognito のメール認証時に利用。

メリット・考察

  • メリット: Amazon Cognito はユーザー管理やSNS連携などを簡単に実装できる。
  • 考察: 初期は小さな認証機構でも良いが、拡張性・MFAなどを考慮するとCognitoのメリット大。必要に応じてOpenID Connectなどにも対応可能。

参考ドキュメント

5. Assets (静的アセット配信) – assets.novelshaft.com

  • S3 バケット + CloudFront
    ユーザーがアップロードした画像やロゴなどを大容量かつ低レイテンシで配信するため、CloudFront オリジンとして S3 を設定。
  • OAI (Origin Access Identity) を使い、S3バケットに直接アクセスできないようバケットポリシーで制御。

6. Mail(SES)

  • SES で novelshaft.com ドメインを認証し、アウトバウンドメールを送信
  • DKIM, SPF, MX レコードを設定して、迷惑メール防止やドメイン認証を確実に行う

7. Batch (バッチ処理)

  • AWS Batch
    • ECS on Fargate ベースのコンピュート環境。
    • データ移行や定期的なジョブを Job Queue / Job Definition で管理。
    • 直接 RDS へアクセスする際は、Secrets Manager からDB接続情報を取得。
  • 定期実行には EventBridge (本Terraform外の設定) や CI/CDパイプライン等と組み合わせるケースが想定される。

メリット・考察

  • メリット: AWS Batch はECSタスクを使ったバッチ実行基盤としてスケールしやすい。
  • 考察: cron的な小規模タスクなら Lambda でも対応できるが、マイグレーション等リソースを要する処理は Batch の方が管理しやすい。

参考ドキュメント

8. Lightsail (WordPressブログ) – blog.novelshaft.com

  • Amazon Lightsail によるマネージドWordPress
    • インスタンス管理が簡易で、WordPressのテンプレート起動が容易。
    • Route53で Aレコードを設定し、カスタムドメインでアクセス。

メリット・考察

  • メリット: 既存WordPressプラグインやUIを即利用できる。
  • 考察: ECSやEC2でWordPressを動かすよりシンプルだが、運用で細かくチューニングしたい場合はEC2/ECSで構築した方が柔軟。

9. 共通インフラ (VPC, Subnet, NAT, Endpoint)

  • VPCを1つ 用意し、パブリックサブネットとプライベートサブネットを 2AZ 分散で構築。
  • NAT Gateway によってプライベートサブネットからインターネットへの送信を可能にしつつ、外部からの直接アクセスは遮断。
  • VPCエンドポイント で ECR、S3、SSM などのAWSサービスへプライベート経路でアクセス。

メリット・考察

  • 全てのコンポーネントが同じ VPC 内で相互通信できるため、ネットワーク構成がシンプルになる反面、利用リソースが膨大になりがち。Terraform管理を分割してモジュール化すると保守性向上。
  • NAT Gateway はAZごとに必要なのでコストがかかる。小規模プロジェクトでは1つに絞る案もあるが、冗長性確保のため2つ用意している。

10. Terraform ステート管理

  • S3 バケット + DynamoDB テーブル
    • Terraform のバックエンドとして利用。stateファイルはバージョニング有効化、SSE(AES256)で暗号化。
    • DynamoDB でロック管理し、並行実行による競合を防ぐ。

多角的な観点でのフィードバック

  1. スケーラビリティ
    • CloudFront + ALB + ECS(Fargate) + Aurora MySQL Serverless という構成は、高負荷時のオートスケールがしやすい。一方、サーバレス型Auroraのスケーリング反応時間が一定かかるので、瞬間的なスパイク対応は注意が必要です。
  2. コスト
    • NAT Gateway を AZ 冗長で2つ、Fargateタスク常時起動、Aurora Serverless v2 などは中長期的に見れば効率的だが、アクセスの少ない開発初期は割高になりやすい。削減策としては環境を最小構成に落とす、必要な時だけ立ち上げるなどがある。
  3. 運用の複雑さ
    • CloudFront → ALB → ECS と多段構成のため、デバッグ時に考慮するポイントが増える。WAFやログの流れなどを可視化しやすい仕組みを導入するとトラブルシュートが楽になる。
  4. セキュリティ
    • OAIを使ったS3アクセス制限やプライベートサブネットへのRDS配置など、基本的なセキュリティベストプラクティスはクリア。
    • 次のステップとしては、CloudFront + WAF でDDoS対策、AWS Config や Security Hub で継続的な監査などが挙げられる。
  5. Terraformの管理
    • すべてを1つのTerraformプロジェクトに入れると規模が大きくなるため、チーム体制やライフサイクルに応じてモノリシックからモジュール分割へ移行する方が長期的にはスムーズ。

まとめ

NovelShaft では、ランディングページや執筆アプリ、バックエンドAPI、認証基盤、アセット配信、バッチ処理などをそれぞれ独立したドメインとAWSサービスの組み合わせで構成しています。Terraform で一元管理しているため、将来的な拡張やリソース変更にも柔軟に対応可能です。
本構成は、サーバレスやコンテナ運用を組み合わせることで高い可用性とスケーラビリティを実現しつつ、CloudFront・S3のOAIなどを活用してセキュアな配信基盤を構築しています。

批判的な視点

  • コスト面や運用面でサービスが小規模な時期にはオーバーエンジニアリングに見える場合もあります。開発初期はもう少しシンプルな構成にして、ビジネス拡大時に段階的にスケールアップするのも有効です。
  • コンテナやサーバレスは便利ですが、モニタリングや障害対応の知識が不足するとトラブルシュートが難しい面もあります。専門人材の確保や監視基盤の設計が重要となります。

参考リンクまとめ

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

More posts