🎉

オフラインイベント(1000人規模)のインフラをワンオペで完遂した話

に公開
テーマ「2025年の最も大きなチャレンジ」
AWS
Terraform
インフラ
イベント運営
tech

参画先の企業で来場者1000人規模のイベントを開催することになり

  • インフラ
  • CI/CD
  • セキュリティ
  • 監視設計

をまるっと任せていただいたのでどういう考えで構成し、どう対処したのかを振り返ります。

背景と要件

今回は以下のような前提でスタートしました。

  • ミッション
    1日限りの大規模イベントに向けたインフラ構築。
    インフラだけでなく、CI/CDパイプラインやセキュリティ設計や監視まで一貫して担当しました。

  • スケジュール
    納期は約3ヶ月と余裕がありましたが、実際には1ヶ月もかけずに構築を完了させました。
    早めに環境をアプリ担当者へ引き渡すことで、アプリ開発やテストに十分な時間を割けました。

  • 構成管理
    Terraformを使用。
    modules/xxx といったモジュールディレクトリと、環境別ディレクトリ（dev/stg/prd）に分割して管理しました。

設計コンセプト

設計時に意識したのは、以下の4点です。

  • モノレポ × 環境別ブランチ戦略
    アプリ担当者の案で develop / staging / main をそれぞれの環境に紐付け、Terraformもアプリもブランチへのプッシュをトリガーに自動適用されるようにしました。
    レビューが必要な変更とスピード優先の変更を明確に分けられ、アプリ担当者とお互い余計な負担をかけない運用を目指しました。

  • 再利用性の高いモジュール化
    ALB、WAF、ECS Fargate、RDS、ECR、ログ周りなどの共通リソースをモジュールに集約しました。
    環境ごとの差異（スケールやアクセス制御など）だけを変数として渡す構造にし、コードの重複を極力減らしています。

  • セキュリティと可観測性の「先出し」
    WAFの標準ルールやレート制限、Security Groupの分離、Secrets Manager / Parameter Storeによる秘匿情報の管理を最初から組み込みました。
    また、CloudWatch Logsとサブスクリプションフィルタも導入し、後から「ログが見えない」「セキュリティが穴だらけ」と慌てるリスクを潰しました。

  • 段階的なスケーリング
    開発・検証環境は最小構成かつ閉域アクセスにしてコストを抑制。
    本番環境はオートスケールとマルチAZを有効化してキャパシティを確保しました。コストと安心感のバランスを常に見極めながら調整しています。

インフラ構成

全体像は以下の通りです。

構成のポイント

  • ネットワーク
    ALBにWAFをアタッチしてTLSを終端。ALBのアクセスログはS3に集約し、保管コスト削減のためライフサイクルを短めに設定しました。

  • アプリ実行基盤
    ECS Fargateを採用。アプリ用・Web用・運用クライアント用のコンテナを稼働させています。
    SSM Execによるコンテナへのログインも可能にして保守性を確保しました。

  • データ層
    MySQLはプライベートサブネットに配置。
    本番はマルチAZとリードレプリカで可用性を高め、非本番はシングルAZで軽量化しました。資格情報はランダム生成してSecrets Managerで管理しました。

  • CI/CDパイプライン
    GitHub Actionsを採用。
    Terraformの apply はもちろん、アプリ側も ECRビルド → タスク定義更新 → DBマイグレーション → サービス更新 までを自動化しています。

スケジュールと進め方

3ヶ月の納期に対し、実質1ヶ月未満でインフラ全ての構築を終えました。

  1. 最初の3週間：爆速構築
    Terraformモジュールの作成から、各環境の立ち上げ、WAF/SG周りのセキュリティ設定までを一気に完了。
    CI/CDパイプラインもこの期間に整備し、開始から1ヶ月経たずして「いつでもデプロイできる状態」を整えました。

  2. 残り2ヶ月：品質向上とリハーサル
    インフラが早々に完成したため、残りの期間はアプリ開発の伴走や負荷試験や監視試験に充てられ、余裕を持ってイベント当日を迎えられました。

よかったこと

  • 環境別ブランチ戦略がハマった
    モノレポだがアプリ担当者とお互いに干渉せず開発を進められました。
    特にレビューの要否やデプロイのタイミングを環境ごとにコントロールできたのは、開発体験の向上に繋がったと感じます。

  • トラブルゼロの達成感
    定番構成をTerraformで堅実に組んだおかげか、イベント当日はインフラ起因の障害がゼロでした。
    休日に自宅待機をしていましたが、平和に終わりエンジニアとして静かな達成感がありました。

  • スピード感への評価
    設計への物言いがほぼなく「構築まで一直線で早かった」と評価をいただけました。
    3ヶ月の納期に対して1ヶ月弱で仕上げたことで、プロジェクト全体に余裕を作れたのが最大の貢献だったかもしれません。

  • 構成が次回の標準になった
    「次回以降のイベントもこの構成ベースで行きたい」と言っていただけました。
    後続の標準を作れた誇らしさと、「下手なものは残せないな」という少しの緊張感が入り混じっています。

反省点

  • DBのスケーラビリティ
    トラフィックが読みきれないイベントだったので、Aurora Serverless v2 などの選択肢もありだったと思います。
    最終的には「枕を高くして寝たい」という理由でインスタンスクラスをスケールアップして対処しましたが、コスト効率と柔軟性の面でまだ工夫できた点は反省点です。

  • 現地に行かなかったこと
    これが一番の後悔です。
    自宅待機を選んでしまったのですが、後日「現場の熱量がすごかった。自分が作ったシステムが動いているところを見せたかった」とお客さんから言われて行けばよかったと後悔しました。
    次は必ず現地に足を運び、システムの向こう側にいるユーザーの熱を感じたいと思います。

まとめ

モジュール化と環境別ブランチの組み合わせにより、1000人規模の単発イベントインフラを1ヶ月程度で構築し、安全かつスピーディに仕上げられました。

技術的な手応えは十分でしたが、次回はDBの選択肢を広げること、そして何より現場に行こうと思いました。

GitHubで編集を提案

Discussion