こんにちは。
2025 年 9 月にファインディに入社し、 Platform 開発チームで SRE を担当している富田(@Cooking_ENG)です。
この記事は、ファインディエンジニア #2 Advent Calendar 2025の 23 日目の記事になります。
今回は、ファインディのサービスの１つである「Findy Conference」のインフラ環境の運用トイルを改善した話を紹介します。
Findy Conference とは
Findy Conference とは、テックカンファレンスに特化したプラットフォームサービスです。
国内外のカンファレンスに関する情報・体験を一元化し、主催者・参加者・スポンサーをつなぐことで、テックカンファレンスの体験を最大化することを目指します。
参加者は関心のあるイベント情報や CFP（発表募集）、イベントのタイムテーブルを見逃さずに把握でき、主催者は集客や受付管理、データ活用といった運営にかかるコスト・工数を最小化できるようになります。
Findy Conference のトラフィックの特徴
Findy Conference のトラフィックには、一般的な Web サービスとは異なる、カンファレンス特有の瞬間的なスパイクが多く発生するという特徴があります。
特にスパイクが起こりやすいタイミングは次の 2 点でした。
- 受付が始まったタイミング
- セッションの始まりと終わりのタイミング
このうち、特に負荷が高かったのがセッションの始まりと終わりのタイミングです。
原因は次のような、オンライン配信におけるカンファレンス参加者の方々の動きによって起こるものでした。
セッション中は参加者の方々は配信セッションを視聴しているため、Findy Conference のポータルサイトなどにアクセスすることは少ない。
セッションが終了するタイミングで、次のセッションの配信場所やチャンネル切り替えを行うため、セッションを視聴していた方々が一斉に Findy Conference のポータルサイトにアクセス。
その結果、一気にアクセスが集中し、スパイクが発生！
この一連の流れにより、インフラに瞬間的な高負荷がかかっていました。
オートスケールが発動しない
Findy Conference の環境は Amazon ECS と AWS Fargate (以降 ECS/Fargate) を使って構築しています。
ECS/Fargate であれば、オートスケールが発動するのではないか？という疑問を持つ方もいらっしゃると思います。実際に、Findy Conference の環境でも、CPU 使用率が設定している閾値を超えたらオートスケールが発動するように設定していました。
しかし、実際の運用では CPU 使用率が設定している閾値を超えてもオートスケールが発動せず、高負荷時にユーザー体験を維持できないリスクが生じていました。
オートスケールが発動しなかった原因は「アクセス集中が瞬間的すぎる」という点にありました。
- 短時間の高トラフィック・スパイクにより、オートスケールが発動に必要な時間を満たせず、新しいコンテナが立ち上がる前に CPU 使用率が下がってしまう
- Fargate の起動が少し遅いという特性も影響
結果として、カンファレンス中に上記のような瞬間的な高負荷がかかっても、コンテナ数はスケールせず終わってしまうという状況でした。
（参考までに、こちらは過去のオブザーバビリティカンファレンスでの CPU グラフです。同時刻にオートスケールが発動していないことがわかります。）
これまでのカンファレンス開催時の SRE の対応
上記の問題を回避するため、以前は「カンファレンス開催前に、Platform 開発チーム SRE メンバー(以降、SRE チーム)が AWS の Production 環境に入り、手動でコンテナ数を増やし、カンファレンス終了後にコンテナ数を元に戻す」という対応をしていました。
スパイク時の対策としては、当時はコンテナ台数を増やす以外に現実的な選択肢がなく、人手によるスケール対応に頼らざるを得ない状況でした。
この手動オペレーションは、次のようなトイルを生み出していました。
カンファレンス運営の方との連携が必須： カンファレンスが開催される日程共有の段階でコミュニケーションミスが発生した場合、急いで対応する必要がある。
ペアオペ作業のため 2 人分の工数が発生する： Production 環境で作業をするセンシティブな作業のため、ペアオペが必須となり、2 人分の時間が取られる。
複数環境の調整： フロントエンドとバックエンドなど、複数の環境で調整が必要なため、作業量、作業時間が多くなる。
オペレーション・リスク： そもそも Production 環境を手作業で触るので、作業ミスが発生するリスクがある。
実際、最近開催されたアーキテクチャカンファレンスでは、関連する複数環境のコンテナ調整に 2 時間近く要してしまいました。 カンファレンスが開催されるたびに、この手動作業の負荷が大きいと考え、トイルを抜本的に改善する必要があると判断しました。
GitHub Actions の workflow と AWS CLI で自動化
このトイルを撲滅すべく SRE 以外でも素早くコンテナ調整をできるようにするために、今回は AWS CLI と GitHub Actions の workflow_dispatch を組み合わせて、Production のマネジメントコンソールに入らなくても GitHub 上からコンテナ数を調整できるようにしました。
これにより、必要な権限を持ったユーザーが、安全かつ簡単にコンテナ調整を行えるようになりました。
コードの全体像 以下が、コンテナ数をスケールさせるための GitHub Actions のワークフロー全体像です。
scale-containers.yml name: Scale Containers run-name: Conference Scale Containers to ${{ github.event.inputs.container_count }} in ${{ github.event.inputs.environment }} on: workflow_dispatch: inputs: environment: type: environment required: true default: staging container_count: description: "containers_count" type: choice required: true options: - xx - yy - zz permissions: id-token: write contents: read jobs: scale-containers: runs-on: ubuntu-slim environment: ${{ github.event.inputs.environment }} steps: - uses: actions/checkout@v5 with: fetch-depth: 0 token: ${{ secrets.GITHUB_TOKEN }} - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v5 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} aws-region: ap-northeast-1 - name: Scale Backend ECS containers run: | CLUSTER_NAME="backend-${{ github.event.inputs.environment }}" SERVICE_NAME="backend-${{ github.event.inputs.environment }}" echo "🔄 Scaling Backend containers to ${{ github.event.inputs.container_count }}" # 1. ECSサービスのDesired Countを更新 aws ecs update-service \ --cluster "$CLUSTER_NAME" \ --service "$SERVICE_NAME" \ --desired-count ${{ github.event.inputs.container_count }} # 2. オートスケールの最小キャパシティもワークフローでの設定値に合わせる aws application-autoscaling register-scalable-target \ --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id "service/$CLUSTER_NAME/$SERVICE_NAME" \ --min-capacity ${{ github.event.inputs.container_count }} \ --max-capacity [xx] echo "✅ Backend containers scaled successfully" - name: Scale Frontend ECS containers run: | CLUSTER_NAME="frontend-${{ github.event.inputs.environment }}" SERVICE_NAME="frontend-${{ github.event.inputs.environment }}" echo "🔄 Scaling Frontend containers to ${{ github.event.inputs.container_count }}" aws ecs update-service \ --cluster "$CLUSTER_NAME" \ --service "$SERVICE_NAME" \ --desired-count ${{ github.event.inputs.container_count }} aws application-autoscaling register-scalable-target \ --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id "service/$CLUSTER_NAME/$SERVICE_NAME" \ --min-capacity ${{ github.event.inputs.container_count }} \ --max-capacity [xx] echo "✅ Frontend containers scaled successfully"
※実際のワークフローの画面です。
ワークフローの実装ポイント
workflow_dispatch による手動実行
inputs で environment（環境名）と container_count（コンテナ数）を入力値として受け付けます。
container_countはchoiceにすることで、設定可能な値に制限を設け、誤入力を防いでいます。コンテナ数と同時に最小コンテナ数の設定値も合わせる
aws application-autoscaling register-scalable-targetを実行し、オートスケールの--min-capacityもワークフローでの設定値に合わせるようにしています。この設定はコンテナ数を増やしても、オートスケールが最小キャパシティまでコンテナ数を減らしてしまう可能性を防ぐためです。
本ワークフローの導入により、Findy Conference のコンテナ調整は、誰でも GitHub Actions の画面から数クリックで実行できるようになり、SRE チームの負荷が軽減されました。また、既にカンファレンス開催に関わる複数の環境全てに横展開を完了しています。
この改善によって、SRE チームが約 2 時間かけて行っていたペアオペ作業は解消されました。
加えて、手動オペレーションのリスクも排除され、必要な権限を持った開発者やカンファレンス担当者が安全にコンテナ調整を行える運用体制を整えることができました。
おわりに
今回は Findy Conference のスパイクの起こりやすいトラフィック課題に対して、GitHub Actions と AWS CLI を用いて運用オペレーションを自動化・トイル削減した事例をご紹介しました。
トイル削減は SRE の永遠のテーマですが、エンジニアが気持ちよく開発に取り組める環境づくりや、安心して運用できる体制に繋がるため、これからも積極的に進めていきたいと思います。
最後までお読みいただきありがとうございました！
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
