[レポート] DBS209  Cloud Spanner Data Boost で影響のないアドホッククエリとデータエクスポートを実行 #GoogleCloudNext

[レポート] DBS209 Cloud Spanner Data Boost で影響のないアドホッククエリとデータエクスポートを実行 #GoogleCloudNext

Google Cloud Next で Cloud Spanner Data Boost のセッションに参加してきました。
Clock Icon2023.09.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。

アメリカ サンフランシスコで開催された Google Cloud Next '23 に現地で参加してきました。Cloud Spanner の Data Boost に関するセッションを見てきたのでレポートします。

Run impact-less ad hoc queries and data exports on Cloud Spanner

セッション概要

ビジネス クリティカルなアプリケーションに影響を与えることなく、アドホックなバッチ クエリを実行したり、Cloud Spanner データベースからオンデマンドでテラバイト規模のデータをエクスポートしたりする方法を学びます。 このセッションでは、世界的に有名なドイツ銀行が Google と提携して顧客に世界クラスの体験を提供する方法と、将来の課題を解決するためにどのような体制を整えたかを紹介します。 次に、Spanner の最新のイノベーションにより、トランザクションと分析のワークロードを安全に混在させ、制約のないデータ共有を可能にする方法について深く掘り下げます。最後に、著名な業界アナリストから、組織の将来性を確保するためにデータ管理プラットフォームに何を要求すべきかを学びます。

登壇者

  • Joe Yong
    • Product Manager
    • Google Cloud
  • Neera Mital
    • Software Engineering Manager
    • Google Cloud
  • Markus Leimbach
    • Chief Technologist & IT-Lead (Cloud) Online Banking
    • Deutsche Bank AG
  • Merv Adrian
    • Principal
    • IT Market Strategy

古典的な問題に対するドイツ銀行のモダンソリューション(Markus Leimbach 氏)

ドイツ銀行は、日常的な銀行業務を行うポストパンクと複雑な金融商品アドバイザリー業務を行うドイツ銀行があります。2020年までポスト銀行とドイツ銀行が完全に分離されており、それぞれ独自のデータセンターを運営していました。2020年に Google とパートナーシップを結び、クラウドネイティブでゼロから第三のプラットフォームを構築して、顧客へサービスを提供します。今日我々は50以上の Google Cloud ネイティブサービスを活用して、完全にクラウドネイティブなプラットフォームでお客様へサービスを提供しています。

オンラインバンキングはモバイルアプリ、サードパーティのアカウント集計、ウェブページなどを一つのプラットフォームで提供しています。小規模なリテール顧客、個人口座、法人口座などあらゆる顧客に対応しています。現在1日1600万件のトランザクションを行っており、今まで四半期ごとにリリースが隔週のサイクルになり、リリースは300回を超えています。プラットフォームには可用性、正確なデータが必要です。またヨーロッパではインスタントペイメントと呼ばれるサービスがあり、数ミリ秒で完了します。銀行における重要なワークロードであるため Spanner を採用しています。

Spanner が実現した最も重要な点に焦点を当てます。可用性について Spanner をマルチリージョン構成で運用していて 99.999% の可用性が実現できています。2番めにパフォーマンスについてです。1600万トランザクションについて言及しましたが、一部の顧客では1階に300,000件のトランザクションを処理していることです。そして絶え間ない機能強化についてプロダクトオーナーが取り組んで協力的でした。

スケーラビリティ、正確にはオート スケーリングについてです。いくつかのデータベースでは、短期間で必要な規模の13倍に達しました。今では手動でのスケーリングは限られています。Google のエンジニアがオープンソースで作成して、Google と PoC を実施しました。Github にあるので我々が本番環境で行っているオートスケーリングを実行できます。

混在ワークロードへのより良いアプローチ(Joe Yong 氏)

最も重要なレイテンシーセンシティブなトランザクションシステムと AI トレーニングなどの分析ワークロードが必要です。従来のアプローチでは ETL を使って別システムへ移動しますが、システムにとって高負荷になります。レプリカも作成できますが、追加コストが必要です。

そこで Data Boost の出番です。セキュリティコントロール側の IAM 権限を付与して、接続文字列に1つのパラメータを追加するだけです。Spanner は2つの条件を満たしたクエリが Google に管理された完全に分離されたコンピュート リソースを自動的にリルートします。常にホットな状態で常にクエリを待っています。クエリが来たら待ち時間無しで Colossus ストレージにアクセスします。オリジナルの Spanner と同じディスクのブロックを参照するので、レプリカではなくコピーもありません。Spanner インスタンスでクイックチェックを行い、メモリ上に引き継ぐべきものがないことを確認してクライアントへ戻します。大きなテーブルで大きなジョインを実行しても Spanner 側に影響しません。そのため過剰なプロビジョニングは不要になります。

権限を付与して接続文字列のパラメータを有効にしただけで CPU 利用率が安定しました。パフォーマンスも8倍の性能向上が見られました。ただしワークロードや実行するワークロードの種類により効果は異なります。

デモ(Neera Mital 氏)

このデモはオンライン マルチプレイ ゲームのシナリオです。ゲーマーは商品を交換して、アイテムを取得して、セッション中にアイテムを獲得し、仮想通貨を使用してアイテムを購入します。これには水平スケールでトランザクションの一貫性を備えた低レイテンシーの体験が必要であるため、Cloud Spanner をバックエンドに使用します。一方このデータを分析するゲームアナリストもいます。一般的な方法ではリアルタイムトランザクションワークロードへの影響を避けるため、運用データベースを過剰にプロビジョニングするか、読み取り専用レプリカにデータをコピーするか、運用データベースからデータウェアハウスへデータを移動するかのいずれかでした。Cloud Spanner の Data Boost を利用して、トランザクションワークロードへの影響の少ない大規模分析を可能にします。

分析クエリのCPU 使用率が 40% 以上ありました。

Data Boost を有効化することで運用データベースの CPU 使用率が 0.6% となり、ほとんど影響がなくなります。

全体像(Merv Adrian 氏)

データ管理は、クラウドへ移行するとデータとコンピューティングが無制限になると考えているが、実際にはコストの発生するため上限があり、過剰なプロビジョニングに注意が必要です。セキュリティの問題や意味の混乱を避けるため、データを統一的に管理する必要があります。

次世代のクラウドデータ管理では、インテリジェント、可観測性、ガバナンス、自律性がすべて統合されている必要があります。そして運用システムが最適化されていることです。

次世代のクラウドデータ管理では、様々な選択肢があります。

  • インスタンスの種類
  • データフォーマット
  • キャパシティ
  • セキュリティ要件の拡張
  • データのインポート/エクスポート/複製/更新/アーカイブ/"温度"のコスト
  • 混在ワークロードの影響

まとめ(Joe Yong 氏)

  • 重要で大規模なデータベース移行のための Spanner は規制業界で実行済みのアプローチです。
  • トランザクションワークロードに影響を与えずにいつでも最新トランザクションデータへバッチや分析クエリを実行できます。
  • キャパシティ管理/予算編成ではなくビジネスに焦点を当てます:実際の利用に支払います。
  • データの散乱を減らし、データガバナンスの負担を減らします。
  • 安心のデータ共有

質疑応答

質問者:現在 BigQuery で Spanner を実行しており Federated Query を使用していますが、Federated Query でアドホック分析を実行すると処理速度が CPU だけでなくスキーマレベルでも大幅に低下します。そのためデータを BigQuery に取り込む際にパーティション分割してクラスタリングを行います。将来的になにか変わることはありますか?

Joe Yong 氏:Cloud Spanner からデータを取り出そうとしても隙間がクエリに最適化されていないため、上手く実行されない可能性があります。Spanner にはインタリーブで親子テーブルを同じブロック内で隣り合わせで配置する概念があります。しかし分析クエリは予測不可能で必要な場所からデータを取得する可能性があります。多くのリソースを消費しなくなれば本番システムに対して改善されるかもしれませんが、スキーマが細礫化されていないという問題は解決されません。将来的に検討する可能性があります。

Merv Adrian 氏:私は分析ワークロードの設計をしてきましたが、 マテリアライズド・ビューが有用かもしれません。トランザクションシステムの実行中にシステムに影響を与えることなく、マテリアライズド・ビューに接続するコンピュートノードを立ち上げるシナリオを想像してください、

質問者:現在変更データストリームを使っています。そうやってすべてをストリーミングしています。早くから導入してきましたが高価なんです。

Joe Yong 氏:ここで私達と話してみてください。お付き合い頂きありがとうございました。

さいごに

ドイツ銀行という大規模な規制業界での Cloud Spanner の導入事例は参考になりました。オートスケーリングに言及していましたが、ドイツ銀行のGithub アカウントを確認すると cloudspannerecosystem/autoscaler をベースにしているようでした。また Data Boost によりトランザクションワークロードに影響を与えずに分析クエリも実行できるので、様々な場面で活用ができそうです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.