1. はじめに
こんにちは。株式会社ペライチ インフラチームの澤居です。今日は「見えないものがいちばん不安という話」というお話をさせてもらいます。
2. Redshift 導入
ペライチでは目下モノリスからマイクロサービスへ移行を進めていますが、プログラムと同時にデータベースが切り離されることで横断的にデータを集約・参照できる基盤が必要とされています。各 RDS (MySQL) から DMS を使って別途集約用の RDS (MySQL) へ統合する仕組みは既にあるのですが、DMSの使い方としては推奨されているものではありません。分析クエリを投げると度々落ちることがありましたし、よりスケールする BI 環境を念頭に Redshift を導入することになりました。
3. Aurora 移行
Redshift に対しては「ゼロ ETL」という機能でデータを同期させるのですが、この機能は2023年末に一般公開された比較的新しい機能です。
S3 などを介さずに Aurora と Redshift を直接接続してデータをストリーム処理できるのが大きな特徴で、ETL パイプラインの構築・運用コストを大幅に削減でき、運用中のサービスに極力影響を与えずにデータ分析環境を整えることが可能になります。ただこの機能は Aurora でないと使えないため、まず、既存の各 RDS を Aurora へ移行するというタスクに着手しました。
まとめるとこうです。
これを
こうする
ゼロ ETL の構築と Redshift へ同期させる部分はまた後日でもいいので、取り急ぎは無事に全 DB を Aurora 移行させることが最大の焦点でした。
4. 不安の正体
ステージングの移行検証は特に問題なく終わりました。
移行といっても MySQL から MySQL への移行ですから、アプリケーションの修正は不要ですし影響も限定的でした。作業自体はとてもシンプルで、画面からリードレプリカを作成し昇格させると独立した Aurora クラスターが作成されます。「作成」と「昇格」ボタンを2回押すだけです。「昇格」のタイミングで書き込み先のエンドポイントを変えるため、その時だけアプリケーション止めておけば大丈夫だなと簡単に考えていました。
ただ一緒に作業をやってくれた CTO からこれは大変だぞという雰囲気を感じて、率直にあまりピンと来てない旨を伝えました。今考えると「そうだよね」なのですが、
その時だけ止めて
停止範囲がどこなのか？はっきりしたものがないため、この範囲の洗い出し、つまり作業全体の可視化が大変の正体でした。切り離し済みの RDS 分移行作業が必要なのも億劫でしたし、リザーブドインスタンスを買う時期が目前だったため、それまでに作業を済ませないといけないことにも気を揉みました。
5. 不安を減らす必要な準備
この頃になると頭の中が錯綜し、作業が思ったように進まないことがありました。
「困難は分割せよ」
移行がうまくいくか煮詰まっていく不安は他所に、一旦シンプルに考えようと思い立ちます。そもそも今回のケースでは以下が不安です。
不可逆であること
- 何かを壊したり失敗した時の影響が大きい
不可視であること
- どういう作業工程になるのか具体的な計画がみえていない
ではどういう準備をすべきなのか？
シンプルに考えます。データの入れ物の交換です。Web アプリですからデータの出し入れは画面かバッチから行われます。つまり停止の範囲は画面一覧とバッチ一覧によって決まります。そして考慮漏れ、検討漏れを防ぐために客観的な正しさ、つまり事実をベースにした一覧を作成します。
6. 作業へ向けて計画に落とし込む
今回のケースではこうなりました。
| 一覧 | 参照元 |
|---|---|
| バッチ一覧 | ECSのスケジュールされたタスク |
| RDS 一覧 | aws コンソールのデータベース一覧 |
| インフラ一覧 | aws コンソールの各種一覧, Mackerelの監視対象一覧 |
| 画面一覧 | 知見者へヒアリングして作成(※) |
※ 即使えるような客観的なものが用意できず、後の課題としました
作業に対応する一覧を用意して、これを工程分繰り返して手順書を作っていきます。はっきりとした作業に集中すると不安は消えていきます。一通りできたらレビューをもらって、タイムテーブルを作ってリハーサルへと進みました。
7. さいごに
幸い手順書は想定より膨らんだものの、移行作業と Redshift の構築は計画通り終わり現在は QuickSight の実装へ入っています。不安が大きい時ほど、準備を手厚くやっておくに越したことはないと、改めて思いました。
Discussion