AuroraからTiDBへテンポよく移行　本番移行後のトラブルも“スケール対応”で乗り越えて刷新

「切り戻しはしない」覚悟──本番移行の裏側

　本番環境への移行は、通常のメンテナンス作業のために用意されている6時間以内に実施する必要があった。そこで時間を計測しながらリハーサルを繰り返し、6時間以内に収まる見通しが立った上で移行作業を実施。移行ツールとして、Amazon AuroraからのエクスポートにはTiDBの公式ツール「Dumpling」、TiDB CloudへのインポートにはTiDB Cloudコンソールのインポート機能、データの整合性チェックには（データとスキーマの差分を比較・検出する）「sync-diff-inspector」を採用している。

　当初は無停止移行のための「DM（Data Migration）」や切り戻しを想定した「TiCDC（Change Data Capture）」の利用も検討したが、十分なメンテナンス時間を確保できたこと、最終的に「Amazon Auroraへの切り戻しは行わない」方針としたため、これらの利用は見送られた。

　この「切り戻しは行わない」という方針は、「問題が生じても、その先の面倒は何があっても自分が見る」という、浦谷氏のTiDBへの信頼と経験に裏打ちされたものだ。

　もし、何かあった際に切り戻しをすることを前提とすれば、切り戻しのための準備が必要になるだけでなく、システム構成が複雑化することで移行の成功率も下げてしまうリスクがある。だからこそ浦谷氏は、シンプルに移行したほうが成功率は上がると考えた。

予測不能な「ドタバタ劇」とTiDBの柔軟性　緊急対応から得た教訓

　実際の本番移行は入念なリハーサルの成果もあり、スムーズに進んだものの移行直後に予測困難なトラブルが発生した。

　メンテナンス明けから10分後、社内から「エラーが多い」「アプリが重い」といった声が上がり、ユーザーからも通信エラーの問い合わせが殺到。すぐにメトリクスを確認すると、TiKVのCPUリソースが急激に消費されていることが確認できた。

　このときゲーム内のプレゼント機能におけるスキャン処理がボトルネックとなり、Amazon EBS（Elastic Block Store）のIOPS上限に張りついた状態となっていた。負荷試験時、本番よりも少ない件数で検証していたため、ボトルネックに気づけなかったのだ。

　そこで浦谷氏は、TiDBがノーメンテナンスでTiKVのスケールアウトができることを知っていたため、即座にスケールアウトを実行。これによりAmazon EBSの負荷が分散され、問題は即座に解決された。この経験を通じ、TiDBの柔軟なスケーリングがサービス継続の安心感を支えていることを再認識したという。

　TiDBの移行翌日にも、もう一つトラブルに遭遇している。それはコスト削減を追求するあまり、計画になかったTiKVのスケールイン操作を実施したことに起因するものだ。リソースが使われていない日中の時間帯に、「コストカットを図り、TiDBの性能を発揮しよう」と考えた浦谷氏は、午後にTiKVを9台から3台へ一気にスケールインする操作を実施した。

　しかし、スケールインの処理がユーザー流入前のピークタイムまでに完了しないことが判明。 リージョンの移動をともなうスケールインは時間が必要なため、一気に台数を減らしたことが裏目に出たのだ。この状況に直面した浦谷氏は「（あまりの焦りに）震えが止まらなかった」と振り返る。そこで浦谷氏がヘルプを要請したのは、PingCAPのサポートチームだ。

　PingCAPは、進行しているリージョンの移動をともなう、“スケールインの中断”という技術的に困難な対応を即座に実施。一時的にリバランスは不完全な状態となったものの、ユーザー流入のピークタイムを無事乗り切ることができた。

　浦谷氏は、このトラブルの発生から解決に至るまでの経験を通じて、ベンダーサポートの重要性をあらためて実感したという。緊急時に相談できる相手がいることは運用上のリスクを大きく減らす要素である。そして、PingCAPのレスポンスの速さと正確さは「極めて心強い」と評価する。

　なお、この経験は浦谷氏個人の教訓としても、「計画していないことを本番環境で実行しない」「必ずリハーサルで計測・確認した上で実施する」という基本を強く再認識する機会にもなったという。