SingtelのYugabyteDB移行とパフォーマンス検証
大手通信テクノロジー企業であるSingtelは、ビジネスの重要なアプリケーションをYugabyteDBに移行し、効率性、スケーラビリティ、レジリエンスの向上を実現しました。このブログ記事では、DSS Asia 2024におけるSingtelのAnjani Jha氏とKok Sin Yeoh氏の講演で共有された、既存のレガシー データベースと LDAPからYugabyteDBへの移行で学んだ教訓と移行戦略に関するベストプラクティスをご紹介します。
概念実証 (PoC)の流れ
Singtelはまず、YugabyteDBと他の分散型データベースシステム（CockroachDBやDistributed Postgresなど）を評価するための比較調査を行いました。評価基準として、高可用性、一貫性、スケーラビリティが重要視されました。すべてのプラットフォームでパフォーマンスはほぼ同等でしたが、YugabyteDBは導入フェーズでの現地サポートなどの非技術的な利点により、特に優れていました。
PoC成功基準
Singtelが移行を予定していたアプリケーションは、複数サービスにわたってユーザーの認証認可やユーザー登録などを行うIDプラットフォームでした。そのアプリケーションの要件から、PoCや移行に関する成功基準を定めました。ひとつは、業務の中断を最小限に抑えつつ既存のアプリケーションをYugabyteにシームレスに統合することです。データベースの変更はエンドユーザーにとって透過的でなければなりません。 次に、レガシー・データソースからYugabyte DBへ、データの損失なく、一貫性を保証しながら、すべてのデータを移動させることです。 そして最後に、将来のアプリケーションをスムーズに取り込むための標準的な手順を確立することを目指しました。
デプロイメント環境の選定
YugabyteDBは多様なデプロイメント環境が選択できるため、Singtelは、EC2、Kubernetes、およびオンプレミスのクラスターを比較評価しました。オンプレミスクラスターではクラウドで稼働するアプリケーションからの最低レイテンシを達成し、機密データはオンプレミスに保管するという社内ポリシーとも一致していました。そのため、まずはオンプレミスのクラスタから開始することに決定しました。将来的には、機密データを扱わないアプリケーション向けにEC2クラスターを展開する予定です。
システム運用エコシステムとの統合
Singtelでは自動化を重視し、様々なコンポーネントをパイプラインのコード化によってバージョン管理と保守性を向上しています。YugabyteDBのプロビジョニングもPuppetを使用して自動化することで、開発期間を大幅に短縮することができました。またオブザーバビリティに関しては、PrometheusとGrafanaによるカスタムのモニタリングを行っています。YugabyteDBはネイティブでPrometheusのメトリクスを取得できますが、Sintelでは社内のサポートシステムと統合してよりコントロールするために、カスタムのアラートを実装しています。
データ移行戦略
IDプラットフォームの移行には、2つの移行が含まれていました。一つは、レガシーのLDAPに保管された認証情報をYugabyteDB移行すること、もう一つは複数のサービスから共有されるIDプラットフォームのデータベースを移行することです。
LDAPの移行
レガシーLDAPシステムを運用する中で、LDAPがスケールしづらいことが課題となっていました。Singtelは、LDAPデータをYugabyteDBに一回限りで移行するためのクーロンジョブを開発し、システム間のデータ同期を維持するための置換サービスを作成しました。このアプローチにより、保守性と柔軟性、スケーラビリティ、およびパフォーマンスが向上し、PrometheusやGrafanaなどの優れた監視ツールを活用できるようになりました。
レガシーデータベースの移行
複数のサービスから共通利用されるレガシーデータベースの移行は、業務の中断を最小限に抑えることが必要でした。そのためLDAPの移行とは異なり、段階的なカットオーバーでの移行を選択しました。
そのため、移行戦略の中心となったのがルーター・サービスです。ルーター・サービスはアプリケーションとデータベースの中間層として、書き込みと読み込みのリクエストをルーティングする役割を担いました。書き込みに関しては、レガシーデータベースをプライマリ、YugabyteDBをセカンダリとして両方への書き込みを行います。そのため、何か新しいデータベースへの書き込みに障害が発生しても、アプリケーションへの影響を防ぐことができました。この実装は全体のカットオーバーが完了するまで継続され、アプリケーションの可用性を維持することに貢献しました。
読み取りについては、同じくルーターサービスがレガシーデータベースとYugabyteDBへの読み取りを振り分けるよう動作しました。当初はYugabyteDBへの読み取りリクエストは少なく設定され、徐々に割合を変えていくことでシームレスな移行を実現しました。
このように移行期間中、IDプラットフォームのアプリケーションには2つのデータベースが同時に稼動しています。 レガシーデータベース自体に接続されているサービスもあるため、ターゲットデータソースであるYugabyte DBとソースであるレガシーデータベースの間でデータの不整合が発生します。 この問題を解決するために、Singtelはcronジョブを定期的に実行させてデータを同期しました。
YugabyteDB Voyager
もう一つの移行戦略として、YugabyteDBが提供する移行ツールであるVoyagerを使用しました。Voyagerは、クラスターの準備、スキーマの移行、データの移行など、エンドツーエンドの移行を管理します。このツールの強力な機能により、データソースの準備、スキーマとデータのエクスポートおよびインポートを、最小限の修正で実行できました。
アプリチームが移行ステップをコントロールしやすいように、Voyagerの移行ステップを自動化するパイプラインを作成しました。途中でエラーが発生した時に、オンラインまたはオフラインで修正したり、移行対象のリストや非対象リストを編集したりすることで、YugabyteDBへのオンボーディング手順を確立することができました。
性能テスト
Singtelは、移行ステップの重要な一部として負荷テストを実施し、YugabyteDBの性能を評価しました。各テストでは、特定のクエリーパターンとシステム負荷をシミュレートし、パフォーマンスを測定しました。
これらのテスト結果に基づき、SingtelはYugabyteDBが高い性能を発揮することを確認しました。特に、複雑な結合操作や高頻度のトランザクション処理においても優れたパフォーマンスを示し、同時実行性の高い環境でも安定した応答性を維持しました 。
結論
SingtelのYugabyteDBへの移行は、徹底した評価、戦略的計画、堅牢な実装を重視して進められました。YugabyteDBの強みを活用することで、Singtelはビジネスの中断を最小限に抑え、パフォーマンスを向上させながら、重要なサービスを無事に移行することができました。この旅は、インフラの近代化だけでなく、将来の技術的進歩のための堅実な基盤を築くことにもつながりました。
