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

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

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

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



## 初期運用で直面した課題

1. **ソース更新都度にデプロイ作業が発生する**
   - 手動でのデプロイは手間がかかり、人的ミスのリスクも高い

2. **スケールイン/アウトが簡単にできない**
   - アクセス負荷の増減に応じた柔軟な対応が困難

3. **サイト表示とバッチ処理が同じEC2上にあり、互いに影響する**
   - バッチスケジュールを変更するだけで、必要ない`db:migrate`やPuma再起動が実行される
   - バッチプロセスはインスタンスのリソースを独占した場合、サイトのレスポンス速度が落ちる

4. **ログ確認のたびにEC2へアクセスする必要がある**
   - アプリケーションログを確認するたびにSSMでEC2に接続必要があるため、効率悪い

---

## AWSを活用した解決策

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

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

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

- **構成例**:
  1. GitHubリポジトリへのプッシュをトリガーに、CodePipelineが実行
  2. CodeBuildでテストとビルドを実行し、ビルドしたイメージをECRにプッシュ
  4. CodeDeployでイメージをECS（後述）に反映

- **メリット**:
  - 手動デプロイの手間がなくなり、作業効率が大幅に向上
  - 本番環境への反映が安全かつ迅速に行える

[CodePipeline とは](https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/welcome.html)

---

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

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

- **構成例**:
  - アプリケーションをDockerイメージ化し、ECSのFargateモードを利用
  - Auto Scalingを設定し、アクセス負荷に応じてタスク数を動的に増減

- **メリット**:
  - サーバー管理の負担が軽減
  - サイトのアクセス増減に応じたスケールイン/アウトが自動化

[ECS とは](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html)

---

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

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

- **構成例**:
  - ジョブのスケジューリングをAWS Batchで管理
  - 必要に応じてコンピューティングリソースを動的に確保

- **メリット**:
  - バッチ処理がサイト機能に影響を与えることがなくなり、安定性が向上
  - バッチ専用のリソースを利用することで、リソースの効率的な利用が可能に

[AWS Batch とは](https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/what-is-batch.html)

---

### **4. CloudWatchにログ出力**

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

- **設定例**:
  - アプリケーションのログをCloudWatch Logsにストリーム
  - Batchジョブが失敗した時のみ、Amazon SNSと統合してSlackに通知
  - CloudWatchアラームでスケールイン/アウト時の通知を設定

- **メリット**:
  - EC2への直接アクセスが不要になり、運用が効率化
  - ログが一元管理され、検索や分析が容易に
  - リアル通知で迅速な対応につながる

[CloudWatch Logs とは](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)

[CloudWatchアラーム とは](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)

---

### **その他の改善点**

#### **1. 環境変数をParameter Storeで管理**
- AWS Systems Manager Parameter Storeを利用して、環境変数を安全かつ簡単に管理
- Secrets Managerを組み合わせて、機密情報の管理も強化

[Parameter Store とは](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)

#### **2. Amazon SESでメール送信を簡略化**
- AWS管理ポリシーを付与することで Amazon SES を利用可能にし、メール送信を実現

[Amazon SES とは](https://docs.aws.amazon.com/ja_jp/ses/latest/dg/Welcome.html)

#### **3. CloudFormationで設定をドキュメント化**
- すべての AWS リソースを CloudFormation で管理することで IoC を実現し、設定の再現性を確保

[CloudFormation とは](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html)

#### **4. セキュリティグループでトラフィックを制限**
- セキュリティグループを利用して、VPNアクセス制限で社内のみ公開を実現

[セキュリティグループ とは](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)

---

## まとめ

AWSのサービスを活用することで、手動作業が減り、運営効率が大幅に向上しました。
- デプロイ作業の自動化
- アプリケーションとバッチ処理の分離
- ログの一元管理と通知設定
- 環境変数やメール送信の簡略化

これにより、サイト運営の負担が軽減され、本来のサービス開発に集中できる環境が整いました。

AWSを活用して課題を解決したい方にとって、少しでも参考になれば幸いです。