360°パノラマVR「スペースリー」WebアプリケーションのECS移行

ツール導入前の課題

Rails アプリケーションを EC2 上で運用していたため、高負荷時にスケールアウトが必要な場合は手動対応が必要でした。
その結果、作業に手間がかかり、対応に時間を要することがありました。
また、Ruby のバージョンアップや各種ライブラリのインストールの度に、AMI の更新と EC2 への Ansible の適用が必要で運用コストが大きい状況でした。

どのような状態を目指していたか

負荷に応じた自動的なスケーリングを実現し、柔軟なリソース管理を行うこと。
Ruby のバージョンアップや各種ライブラリのインストールが、Dockerfile の変更のみで完結し、運用の手間を最小限にすること。

• Amazon Elastic Kubernetes Service

• 運用のしやすさ
  • 学習コストの低さ
  • マネージドサービスとして提供される範囲の広さ

既に画像処理バッチの実行環境として ECS を利用していたため、社内に知見があり、スムーズな導入と運用が期待できたことから ECS を選定しました。

改善したかった課題はどれくらい解決されたか

手動で行っていたスケールイン・スケールアウトの作業は、ECS のオートスケーリング導入により自動化されました。
スケジュールベースのスケーリングにより、夜間の余剰リソースを削減することができました。
また、Ruby のバージョンアップや各種ライブラリのインストールは、Dockerfile の更新とコンテナイメージのビルドのみで完結できるようになり、AMI の更新や Ansible の適用作業が不要になりました。
これにより、運用負荷が大幅に軽減され、環境の変更にも迅速に対応できるようになりました。

どのような成果が得られたか

EC2 時代と比較して、1日あたり約 $17 のコスト削減が実現できました。
Datadog 上でもスケーリングによるタスク数の変化を確認できるようにして、効果を定量的に把握できています。

Sidekiq コンテナのスケーリングに適した標準メトリクスがなかったため、Redis のキューサイズを AWS Lambda で取得し、CloudWatch のカスタムメトリクスとして登録する仕組みを構築する必要がありました。

Fargate Spot を導入し、さらにコスト効率の良い構成にしていきたいと考えています。