AWSを活用してサイト運営が楽になった話

Last updated at 2025-02-07Posted at 2025-02-07

今回は、社内サイトの運営についてお話しします。プロダクトの状況を時間軸で表示したい、ローデータを出力したいなど、さまざまな要望に応じるために、社内サイトが構築されました。

この社内サイトでは、社内限定で公開されるデータが多いため、正確性やセキュリティを重視する一方で、プロダクトとは異なり、運営コストを極力抑えたいという現実的な制約がありました。その結果、社内サイトの立ち上げ当初は構成が中途半端な状態となり、Amazon EC2 のみを利用し、画面表示やバッチ処理などをすべて1台のインスタンスで運用していました。

しかし、この運営環境には以下のような課題がありました。

初期運用で直面した課題

ソース更新都度にデプロイ作業が発生する
- 手動でのデプロイは手間がかかり、人的ミスのリスクも高い
スケールイン/アウトが簡単にできない
- アクセス負荷の増減に応じた柔軟な対応が困難
サイト表示とバッチ処理が同じEC2上にあり、互いに影響する
- バッチスケジュールを変更するだけで、必要ないdb:migrateやPuma再起動が実行される
- バッチプロセスはインスタンスのリソースを独占した場合、サイトのレスポンス速度が落ちる
ログ確認のたびにEC2へアクセスする必要がある
- アプリケーションログを確認するたびにSSMでEC2に接続必要があるため、効率悪い

AWSを活用した解決策

これらの課題を解決するために、AWSのマネージドサービスを活用しました。その結果、運営が格段に楽になり、効率が向上しました。

1. CodePipelineでデプロイ作業を自動化

AWS CodePipelineを利用してCI/CDパイプラインを構築しました。ソースコードはGitHubで管理しているため、以下のような流れでデプロイを自動化しました。

構成例:
1. GitHubリポジトリへのプッシュをトリガーに、CodePipelineが実行
2. CodeBuildでテストとビルドを実行し、ビルドしたイメージをECRにプッシュ
3. CodeDeployでイメージをECS（後述）に反映
メリット:
- 手動デプロイの手間がなくなり、作業効率が大幅に向上
- 本番環境への反映が安全かつ迅速に行える

CodePipeline とは

2. ECSでアプリケーションをコンテナ化

Amazon ECS（Elastic Container Service）を利用し、アプリケーションをコンテナ化しました。これにより、スケールの柔軟性が向上しました。

構成例:
- アプリケーションをDockerイメージ化し、ECSのFargateモードを利用
- Auto Scalingを設定し、アクセス負荷に応じてタスク数を動的に増減
メリット:
- サーバー管理の負担が軽減
- サイトのアクセス増減に応じたスケールイン/アウトが自動化

ECS とは

3. AWS Batchでバッチ処理を分離

EventBridgeのスケジュール機能と搭載し、バッチ処理をAWS Batchに移行することで、画面表示とバッチ処理を分離しました。

構成例:
- ジョブのスケジューリングをAWS Batchで管理
- 必要に応じてコンピューティングリソースを動的に確保
メリット:
- バッチ処理がサイト機能に影響を与えることがなくなり、安定性が向上
- バッチ専用のリソースを利用することで、リソースの効率的な利用が可能に

AWS Batch とは

4. CloudWatchにログ出力

ログをAmazon CloudWatch Logsに出力するように変更しました。

設定例:
- アプリケーションのログをCloudWatch Logsにストリーム
- Batchジョブが失敗した時のみ、Amazon SNSと統合してSlackに通知
- CloudWatchアラームでスケールイン/アウト時の通知を設定
メリット:
- EC2への直接アクセスが不要になり、運用が効率化
- ログが一元管理され、検索や分析が容易に
- リアル通知で迅速な対応につながる