はじめに
primeNumber では Redash を以下の用途で利用しています。
社内の業務に欠かせないツールとなっていますが、これまで構成管理されておらずメンテナビリティが低い状態でした。
また、PostgreSQL や Redis を含めた Redash 関連のコンポーネントが全て EC2 の1インスタンスで稼働していたため効率的なスケールを行うことができず、たびたびキュー詰まりが発生していました。
上記の課題を解消するため、Redash を EC2 から ECS on Fargate に移行しました。
一部のシステム監視に利用されていることから、そこが不能になり得る時間を最小にするべく、段階的な移行を実施しました。
本稿では、どのように移行していったのかを説明します。
最終構成
最終構成は以下です。
※ https://redash.pn.com は架空のアドレスです。
ECS on Fargate に Redash のための ECS クラスタを1つ作成しました。
効率的なスケールを可能にするため、Redash のコンポーネントごとに ECS サービスを作成しています。
簡単のために Worker と記載していますが、実際には Adhoc Worker、Scheduled Worker、Worker の3種類があり、それぞれ ECS サービスを作成しています。
段階的な移行
初期構成
初期構成は以下です。
前述の通り、Redash 関連のコンポーネントが全て EC2 の1インスタンスで稼働しています。
EC2 Redash の PostgreSQL をバージョンアップ
移行開始時、EC2 インスタンスで稼働している Redash の PostgreSQL のバージョンは 9.6 でした。
RDS(PostgreSQL) では PostgreSQL 9.6 はサポートされていなかったため、まず先にインスタンス内で稼働している PostgreSQL をバージョンアップすることにしました。
EC2 インスタンス内に DB のデータが保存されているため、事前にデータベースのリストアは不要です。
アップデート方法は docker-compose.yml の postgres サービスが利用するイメージを pgautoupgrade/pgautoupgrade:16-alpine3.19 に書き換えてコンテナを作り直すだけです。
EC2 Redash から RDS(PostgreSQL) を利用
最終的に ECS で Redash を稼働させるため、データが揮発しない環境に移行する必要があります。
前の手順で PostgreSQL のバージョンアップに問題はないとわかったため、次は RDS(PostgreSQL) に移行していきます。
このメンテナンスの差分は PostgreSQL の実行環境のみということになります。
メンテナンス開始直後に EC2 の PostgreSQL のバックアップを取得し、RDS(PostgreSQL) にリストアします。
その後、EC2 の Redash の DB の向き先や、docker-compose.yml から postgres サービスを除外して、コンテナを作り直して起動します。
このステップ完了後は以下の構成になります。
EC2 Redash から ElastiCache を利用
Redis のデータは揮発しても構わないため、ElastiCache への移行はマストではないのですが、以下の理由から移行を決定しました。
- 移行後の Redash 関連のメンテナンスコストを減らしたい
- 公式のドキュメント: Redash on ECS Fargate — Restack でも ElastiCache を利用した方法が紹介されていた
ElastiCache に Redash のための DB を作成しておき、EC2 の Redash の Redis の向き先をそこに向き変えます。
docker-compose.yml から redis サービスを除外して、コンテナを作り直して起動します。
このステップ完了後は以下の構成になります。
ECS Redash を構築
データストアの移行は完了したため、次は Redash のコンポーネントを ECS に移行していきます。
Worker からではなく Server から移行を始めることも可能かと思いますが、一番不確実性の高いところから始めて、何かあったらすぐ引き返せるようにしました。
上述の最終構成でも記述した通り、スケールアウトを考慮して Redash のコンポーネントごとに ECS サービスを作成していきます。
それぞれサービスやタスクの定義の詳細は割愛しますが、以下の手順で移行を進めていきました。
Worker だけサービスイン
Adhoc Worker、Scheduled Worker、Worker、それぞれの ECS サービスを作成しています。
※ 上述した通り、簡単のために Worker とのみ記載します。
ECS サービスが正常に移動したことを確認したあと、EC2 の Redash の Worker を停止します。
このステップ完了後は以下の構成になります。
Scheduler をサービスイン
ECS に Scheduler の ECS サービスを作成し、コンテナ数を0にしておきます。
その後、EC2 の Scheduler を停止し、ECS の Scheduler のコンテナ数を1に変更して起動します。
このステップ完了後は以下の構成になります。
HTTPS リクエストでリクエストを受けるための準備
ECS の Redash Server が HTTPS リクエストを受けられるか、Google の認証が可能かどうかサービスインする前に確認しておきます。
※ Google Auth Client の callback URI は localhost を除いては https しか指定できません。
一時的にサブドメインを用意し、そのドメインで HTTPS リクエストを受けるように設定します。
以下の構成にして確かめました。
Server のサービスイン
最後に既存のドメインで ECS の Redash Server にアクセスが到達するようにします。
Worker の時と同様に、ECS に Server の ECS サービスを作成し、EC2 の Server を停止します。
このステップ完了後は以下の構成になります。
最後に
EC2 で稼働していた Redash を段階的に ECS に移行した話を紹介しました。
私は副業で1日1-2h程度の稼働しかできず、何かあった時のリカバリ作業にすぐ取り掛かれるわけではないので、メンテナンスごとの差分が極力小さくなる手順を心がけました。
移行作業にあたり、いくつかの記事を参考にしましたが、いずれも一度に全てのコンポーネントを移行する方法のものでした。
本記事が段階的に移行したいと考えている方の参考になれば幸いです。
Discussion