primeNumber（プライムナンバー）
primeNumber、単一EC2にRedash一式が同居しキュー詰まりが頻発。構成管理不能な状態からECS on Fargate + RDS + ElastiCacheへ段階移行
データ分析基盤支援サービスを提供するprimeNumberは、社内で使うBIツールRedashをEC2上に自前構築していたが、Server・Worker・Scheduler・PostgreSQL・Redisがすべて1台のEC2インスタンスに同居し構成管理されておらず、効率的なスケーリングができずキュー詰まりが頻発していた。副業的に1日1〜2時間というリソース制約の中、PostgreSQLのバージョンアップからRDS移行、ElastiCache移行、ECSでのWorker・Scheduler・Server移行まで、各フェーズの変更差分を最小限に抑える方針で段階的に移行した。
課題
RedashのServer・Worker・Scheduler・DB・Redisが単一EC2に同居し構成管理不能、キュー詰まりも頻発
アプローチ
PostgreSQLバージョンアップ→RDS移行→ElastiCache移行→ECS(Worker→Scheduler→Server)の順で段階移行
効果
各フェーズの変更差分を最小化し、副業的なリソース制約下でも安全に移行を完了
背景
primeNumberはデータ分析基盤の構築・運用を支援するクラウドサービス「TROCCO」などを提供する企業で、社内向けのBIツールとしてRedashを利用していた。このRedashはEC2上に自前構築されており、Server・複数のWorker・Scheduler・PostgreSQL・Redisといった構成要素がすべて1台のEC2インスタンスに同居していた。構成管理がされていないためメンテナンス性が低く、単一インスタンスでは効率的なスケーリングもできず、キュー詰まりがたびたび発生するという課題を抱えていた。この状況を解消するため、担当者は副業的に1日1〜2時間というリソース制約の中で、ECS on Fargateと各種マネージドサービスへの移行を進めることにした。
移行のプロセス
「メンテナンスごとの変更差分を最小限にする」という方針のもと、以下の順序で段階的に移行を進めた。
- EC2内のPostgreSQLを9.6から16へアップグレードし、RDS移行に向けた互換性を確保
- バックアップ取得とリストアによりEC2内PostgreSQLをRDSへ移行（ダウンタイムあり）
- Redisをメンテナンスコスト削減のためElastiCacheへ移行
- ECS上にAdhoc Worker・Scheduled Worker・通常Workerの各サービスを立ち上げ、EC2側のWorkerを停止
- 複数起動できない制限があるSchedulerは、ECS側を0コンテナの状態で準備してからEC2を停止し、ECS側を起動する手順で切り替え（ダウンタイムあり）
- サブドメインを用意してHTTPS通信とGoogle認証の動作を事前検証
- 最後にServer(UI)をECSでサービスインし、既存ドメインへのアクセスをECS側へルーティング
移行前後の変化
| 指標 | Before | After | |
|---|---|---|---|
| Redash基盤 | 単一EC2（Server/Worker/Scheduler/PostgreSQL/Redis同居） | ECS on Fargate + RDS + ElastiCache | |
| PostgreSQL | 9.6（EC2内自前運用） | 16（RDS） | |
| Redis | EC2内自前運用 | ElastiCache |
結果
段階的な移行により、Redashを構成するServer・Worker・Scheduler・PostgreSQL・Redisをすべてマネージドサービス（RDS・ElastiCache）とECS on Fargate上のサービス群に置き換えた。各フェーズを単一の変更に限定したことで、問題発生時にも切り分けや復旧がしやすい設計となった。記事内に具体的なコスト削減額やパフォーマンス改善の数値は明記されていない。