Deutsche Bank が Spanner を使用して高可用性とスケーラビリティを実現した方法

※この投稿は米国時間 2024 年 1 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Deutsche Bank はヨーロッパにルーツを持ち、グローバルに展開する、ドイツを代表する銀行です。大手企業や政府機関、機関投資家から中小企業や個人に至るまで、幅広く金融サービスを提供しています。

ドイツでのリテール バンキング事業のため、Deutsche Bank は 2 つに分かれていた IT システム（Deutsche Bank と Postbank）の統合をこのたび完了し、最新の IT プラットフォームを構築しました。Postbank のおよそ 1,900 万件の商品契約と 1,200 万人の顧客を Deutsche Bank の IT システムに移行するというこの作業は、欧州の銀行業界の歴史上最大級かつ最も複雑なテクノロジー移行プロジェクトのひとつでした。

このモダナイゼーションの一環として、Deutsche Bank はまったく新しいオンライン バンキング プラットフォームを設計することを選択し、従来のオンプレミス サーバーからクラウドへの移行において Google Cloud と連携しました。Postbank の顧客 500 万人を対象とした最初の本番環境インスタンスで明らかになったように、Google Cloud のフルマネージド データベース サービスである Spanner がこの移行作業を実現するうえで不可欠な機能となりました。高可用性、外部整合性および無限の水平方向のスケーラビリティを持つ Spanner は、このビジネス クリティカルなアプリケーションにとって理想的な選択肢でした。ここでは、Spanner への移行によって Deutsche Bank が実現したメリットと、確実かつ効率的にプラットフォームをスケーリングするために Deutsche Bank が編み出したベスト プラクティスをご紹介します。

高可用性環境でのスケーリング

高可用性環境でのスケーリングは困難な作業ですが、Deutsche Bank では手間のかかる作業はすべて Spanner がすべて行います。Spanner は無限にスケーリング可能なので、Deutsche Bank では小規模からスタートして、必要に応じて簡単にスケーリングすることができます。

従来のオンプレミスのプロジェクトでは、固定されたリソースがオンライン バンキング データベースに割り当てられ、ピークタイムでも顧客のリクエストに短時間で対応できるだけの規模でプロビジョニングされます。そのような設定では、オンライン バンキングの負荷プロファイルが時間帯（具体的には、所定の時間のオンライン ユーザーのトラフィック量）によって異なるため、ほとんどの時間そのリソースが使われないままになります。トラフィックは夜間は少なく、朝になると急激に増加して日中は高負荷状態が続き、夕刻になると再び低下します。Spanner では、アクティブなワークロードを一切中断することなく、随時追加や削除が可能なノードを基盤とした弾力的な水平方向スケーリングが可能です。

ノードの数は、Google Cloud コンソール、gcloud、REST API を使用して変更できます。自動処理を行う場合は、Google Cloud が提供する、完全に Google Cloud 上で動作するオープンソースの Autoscaler を利用できます。Deutsche Bank は、非本番環境を含むすべての環境で Autoscaler を利用して、シームレスなユーザー エクスペリエンスを提供できるよう適切な Spanner 容量をプロビジョニングしながら、費用対効果を最大限に高めています。

高可用性が必要となるコンポーネントは、その管理に使用されるオートスケーラーも高可用性である必要があります。ここからは、Deutsche Bank が Autoscaler を使用したことから得た学びと、オープンソース コミュニティにじき還元される予定の改善協力をいくつかご紹介します。

インスタンスのスケールアップの迅速化

デフォルトで、Autoscaler は 1 分に 1 回 Spanner インスタンスをチェックします。できるだけ早期にスケールアウトするためにこの間隔を短縮すると、Autoscaler が Cloud Monitoring API に対してクエリを実行する頻度が上がります。この変更に加え、適切なスケーリング方法を選択することで、Deutsche Bank はレイテンシに関するサービスレベル目標を達成できました。

マルチクラスタ デプロイ

高可用性 GKE クラスタを実行しているプロジェクトでは、Cloud Functions ではなく、GKE に Spanner の Autoscaler をデプロイすることをおすすめします。これは、この Autoscaler は複数のリージョンにデプロイ可能で、リージョンのサービス停止によって引き起こされる可能性のある問題が軽減されるためです。ポーラー Pod 間の競合状態を回避するには、単純なセマフォ ロジックを追加して、Spanner リソースを管理する Pod を常に 1 つのみにします。Autoscaler はすでに Firestore と Spanner のいずれかで状態が保持されているため、この作業は簡単です。

複雑なものを管理しやすく

Spanner Autoscaler をカスタマイズする際に、ロケット科学者のような専門知識は必要ありません。すべての変更は、Autoscaler のポーラーコアやスケーラーコアを直接操作することなく実行できます。セマフォ処理とモニタリングの統合は、カスタム ラッパー（ポーラーとスケーラーのファイルに Google Cloud がそれぞれ提供するラッパーなど）に実装できます。マルチクラスタ デプロイの場合は、模範の KPT ファイルを修正したり、カスタムの Helm チャートを追加したりして、自社のニーズに最適なオプションを選択することができます。

デプロイから構成を分離

Spanner インスタンスを複数のチームが操作している場合、スケーリングの構成が変わるたびに Autoscaler をデプロイするのが不便なことがあります。これを回避するため、Deutsche Bank ではイメージとデプロイの外部にあるソースからインスタンスの構成をフェッチします。

これには次の 2 つの方法があります。

1. インスタンスとは別の場所（Cloud Storage など）に構成を保存する
2. インスタンス自体に構成を追加する（Terraform 経由で適切な Spanner インスタンス ラベルを設定するなど）

インスタンスの構成を読み取ってポーラーの内部インスタンスの構成をその場で構築する場合、Spanner の Google API を使用すると、バケット内のファイルまたは Spanner インスタンス、およびそのメタデータ（ラベルなど）を簡単にリスト化してアクセスできます。

Terraform をお使いの場合は、Spanner インスタンスの作成後に Terraform の管理からインスタンス処理ユニットを除外することをおすすめします。そうしないと、terraform apply を実行したときに、自動スケーリングされた処理ユニットが Terraform の状態内で設定された固定値にリセットされます。Terraform では、ライフサイクルの ignore_changes メタ引数がこの処理を行ってくれます。

自由自在にスケーリング

ほとんどのユースケースでは、Autoscaler のデフォルトの指標が適切に機能します。異なるパラメータに基づいてスケーリングを行う必要があるような特殊なケースでは、インスタンス レベルでカスタム指標を構成することができます。

分離された構成があれば、カスタム指標を簡単に作成して事前にそれをテストできます。カスタム指標をコンパイルされたイメージの一部にすることで、インスタンス レベルでそのイメージを使ったときにエラーが発生しにくくなります。この手法を使えば、構成の変更中に指標の定義で生じた入力ミスが原因で、特定のインスタンスをスケーリングする際に誤停止が起こることがなくなります。

デフォルトでは、そのときのストレージ利用率、24 時間の CPU 負荷の変化、そのとき優先度の高い CPU 負荷に基づいて Autoscaler がスケーリングの判断を行います。スケーリングのパラメータがデフォルトと異なる（CPU 負荷の優先度が中程度である）場合は、1 分もあればカスタム指標を設定できます。

トラフィックの増減を見越したスケーリング

Autoscaler の小さな欠点のひとつは、突然負荷が急増した場合にリアルタイムで対応して補正できないことです。予測されるピークに対応して補正するには、処理ユニットの最小構成を一時的に増やすことをおすすめします。Autoscaler のインスタンス構成を Autoscaler のイメージから分離することで、ソリューションを簡単に実装できます。

構成の変更が不可能な場合は、スケーラーの指標のエンドポイントに POST リクエストを送信するか、Autoscaler の状態データベースにおける最後のスケーリング操作のタイムスタンプを更新する gcloud コマンドを記述して、インスタンスの処理ユニットを直接設定してください。最初の解決方法では、複数のスケーリング オペレーションが同時に発生する可能性があります。その際は、オートスケーラー内部のクールダウン設定に注意してください。デフォルトでは、スケールイン イベントの 30 分後とスケールアウト イベントの 5 分後に、インスタンスが再度スケールインされます。2 つ目の解決方法では、状態データベースのタイプスタンプを操作することで、n 分間、選択した任意の値に処理ユニットが固定されます。

まとめ

オープンソースの Autoscaler は、Spanner の使用時に費用管理とパフォーマンス ニーズのバランスを取るための便利なツールです。負荷に応じて Autoscaler がデータベース インスタンスを自動的にスケーリングするため、オーバープロビジョニングを回避して費用を節約することができます。

Autoscaler はセットアップが容易で、Google Cloud 上で動作します。Google では Autoscaler をオープンソースとして提供しているため、スケーリング ロジックの完全なカスタマイズが可能です。Deutsche Bank の中心的なプロジェクト チームは Google と緊密に連携することで、このツールの安定性を改善しました。近い将来、この機能強化をオープンソース コミュニティに公開する予定です。

Spanner 用のオープンソースの Autoscaler について詳しくは、公式ドキュメントをご覧ください。Deutsche Bank と Google Cloud のパートナーシップについて詳しくは、Deutsche Bank の公式プレスリリースをお読みください。

-Deutsche Bank AG、リード エンジニア Michael Otmar Kaiser 氏

-Google、エンジニアリング マネージャー Eike Falkenberg