Cloud Spanner の誤解を打ち破る

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

Cloud Spanner の概要

Cloud Spanner は、エンタープライズ クラスのグローバルな分散型外部整合性データベースであり、無制限のスケーラビリティと業界最高水準の 99.999% の可用性を提供します。メンテナンスの時間枠を必要とせず、使い慣れた PostgreSQL のインターフェースを提供します。リレーショナル データベースの利点と、非リレーショナル データベースの比類ないスケーラビリティと可用性を兼ね備えています。

企業が技術スタックをモダナイズし、簡素化する中で、Spanner は、新しいアプリケーションや顧客体験の構築の一環として、データベースに対する考え方や利用方法を変革するユニークな機会を提供します。

しかし、ワークロードに合わせてデータベースを選択するのは難しいことです。市場には非常に多くの選択肢があり、それぞれが異なるオンボーディングや運用経験を持っています。Google Cloud では、このような選択をすることが難しいことを理解しており、お客様をサポートします。このブログ投稿では、お客様が自信を持って決断できるように、Spanner について定期的に耳にする 7 つの最も一般的な誤解を紹介したいと思います。

誤解 1: 大量のワークロードを抱えている場合のみ Spanner を使う

Spanner は、YouTube、ドライブ、Gmail など、Google の最も人気が高く世界中で利用可能なプロダクトを支えており、Uber、Niantic、Sharechat など、多くの大規模な変革を可能にしてきました。また、Spanner はピーク時には 1 秒間に 10 億件以上のクエリを処理しています。

同時に、多くのお客様は、可用性とスケーラビリティの観点から、より小規模なワークロード（1 秒あたりのトランザクション数とストレージ サイズの両方）にも Spanner を使用しています。たとえば、Google パスワード マネージャー には、Spanner 上で動作する小規模なワークロードがあります。これらのお客様は、ダウンタイムを許容できず、アプリケーションを動かすために高可用性を必要とし、将来の成長シナリオに備えてスケール保証を求めています。

最高の可用性を備えた無限のスケーラビリティは、ゲームや小売などの多くの業種において非常に重要です。特に、新しく発売されたゲームがクチコミで評判になり一夜にして大成功を収めた場合や、ブラック フライデー / サイバー マンデーのセールによる急激なトラフィックの増加に対応しなければならない場合などが挙げられます。  

ワークロードの規模にかかわらず、クラウドへの移行を進めるすべてのお客様は、スケーラビリティと可用性のメリットを享受しつつ、パッチ適用やアップグレードなどのメンテナンスに伴う運用負荷やコストを削減したいと考えています。

誤解 2 Spanner は高価すぎる

実際のところ、データベースのコストを検討する際には、元の正規価格よりも総所有コスト（TCO）や提供する価値を考慮することをおすすめします。この価格から、可用性、コスト　パフォーマンス、運用コスト削減などの重要な価値をお客様にお届けします。

• 可用性: Spanner は、データのレプリカを同期的に作成することで、高い可用性と信頼性を提供します。障害復旧に関しては、リージョンのインスタンスの場合はゾーン障害、マルチリージョンのインスタンスの場合はリージョン障害に対して、Spanner は 0-RPO と 0-RTO を提供します。ダウンタイムを削減し、収益を向上させます。

• コスト パフォーマンス: Spanner は、業界屈指のコスト パフォーマンスを誇り、要求が厳しくパフォーマンスが重視されるアプリケーションを運用する場合に最適な選択肢となります。優れた顧客体験には、安定した最適なレイテンシが必要です。

• 運用コストの削減: Spanner では、お客様はダウンタイムなしでアップグレードやスキーマの変更ができ、メンテナンスの時間枠も発生しません。シャーディングは自動的に処理されるため、従来のデータベースのスケールアップに伴う課題は存在しません。革新に費やす時間が増加し、管理に費やす時間が減少します。

• セキュリティとコンプライアンス: Spanner は、デフォルトで、クライアント ライブラリを介した転送中のデータの暗号化と、Google が管理する暗号鍵を用いた保存中のデータの暗号化をすでに提供しています。CMEK の Spanner サポートの開始により、暗号鍵を完全に制御できるようになりました。また、Spanner は VPC Service Controls サポートも提供し、コンプライアンス認定と必要な承認を受けているため、ISO 27001、ISO 27017、ISO 27018、PCI DSS、SOC 1、SOC 2、SOC 3、HIPAA および FedRAMP を必要とするワークロードに使用できます。

Spanner を使えば、データのセキュリティ、可用性、信頼性が損なわれることはないので、安心して利用できます。

そして何よりも、きめ細やかなインスタンスのサイズ設定の導入により、月額 65 ドルという低価格で、Spanner が提供する圧倒的な価値を活用できるようになりました。

活用のヒント: オートスケーラー を使用して、Spanner のインスタンスのサイズを適正化します。TTL を活用して、保存するデータ量を減らします。

誤解 3 スケール、一貫性、レイテンシの間でトレードオフをしなければならない

実際には、ユースケースやインスタンスの構成によっては、一貫性、レイテンシ、スケールのいずれかを選択する必要がないように Spanner を使用できます。

強力なデータの一貫性を確保するために、Spanner はレプリカがすべての書き込みリクエストを承認する Paxos ベースの同期型レプリケーション方式を採用しています。書き込みの commit は、クォーラムと呼ばれるレプリカの過半数（3 つのうち 2 つなど）が書き込みの commit に同意したときに行われます。リージョンのインスタンスの場合は、レプリカがリージョン内にあるため、複数のリージョンに分散しているマルチリージョンのインスタンスの場合よりも書き込みが速くなります。後者の場合、書き込み時にクォーラムを形成すると、レイテンシが少し高くなります。とはいえ、Spanner のマルチリージョンは、レプリカが十分な速度で通信でき、書き込みのレイテンシが許容範囲内に収まるような地理的構成で慎重に設計されています。

読み取りには、（デフォルトでは）強力な読み取りまたはステイル読み取りがあります。「強力な読み取り」は、現在のタイムスタンプでの読み取りであり、この読み取りの開始時までに commit されたすべてのデータを確実に確認できます。ステイル読み取りとは、過去のタイムスタンプで実行された読み取りのことです。強力な読み取りの場合、サービスを提供するレプリカでは、読み取りの開始時までに commit されたすべてのデータを確実に確認できます。場合によっては、サービスを提供するレプリカがリーダーに連絡して、最新のデータを持っていることを確認しなければならないこともあります。マルチリージョンのインスタンスで、リーダーではないレプリカから読み取りが行われた場合、リーダー リージョンから読み取りが行われた場合に比べて、読み取りのレイテンシが少し高くなることがあります。ステイル読み取りは、過去のあるタイムスタンプで commit されたデータに対して実行されるため、タイムスタンプまでキャッチアップされた最も近いレプリカによって、非常に低いレイテンシでサービスを提供できます。レイテンシの影響を受けやすいアプリケーションの場合は、ステイル読み取りを使用するとよいでしょう。ステイル読み取りの値を 15 秒にすることをおすすめします。

誤解 4 Spanner には使い慣れたインターフェースがない

Spanner は、ANSI 2011 規格に基づいた SQL 言語や、パフォーマンスと使いやすさのために最適化された REST または gRPC API インターフェースを介して、データベースと柔軟にやり取りできます。Spanner のインターフェースに加えて、最近、Spanner 用の PostgreSQL Interface を導入しました。これは、PostgreSQL のユビキタス性を利用して、開発チームが慣れ親しんだインターフェースを使用することを目的としています。PostgreSQL Interface には、一般的なクエリ構文、関数、演算子など、オープンソースの PostgreSQL SQL 言語の豊富なサブセットが備わっています。オープンソース PostgreSQL のデータ型、DDL 構文、情報スキーマビューの中核となる要素もサポートされています。PostgreSQL の親しみやすさと、Spanner スケールでのリレーショナル セマンティクスを得ることができます。

PostgreSQL Interface の詳細についてはこちらをご覧ください。

誤解 5 Spanner コンソールを利用することがオブザーバビリティ データを取得する唯一の方法

Spanner のクライアント ライブラリは OpenCensus のトレースと指標をサポートしており、クライアントの内部を知ることができ、本番環境の問題をデバッグするのに役立ちます。たとえば、クライアントサイドのトレースや指標には、セッションやトランザクションに関する情報が含まれます。

Spanner は OpenTelemetery レシーバーもサポートしており、Cloud Spanner System のテーブルから指標を処理して可視化し、お好みのアプリケーション モニタリング（APM）ツールにエクスポートする簡単な方法を提供します。これは、Prometheus のような時系列データベースと Grafana ダッシュボードを組み合わせたオープンソースでも、Splunk、Datadog、Dynatrace、NewRelic、AppDynamics のような商用プロダクトでも構いません。参考となる Grafana ダッシュボードも公開しているため、「テール レイテンシが高いのはなぜか」「ワークロードが変わっていないのに CPU が急上昇したのはなぜか」など、最も一般的なユーザー ジャーニーをデバッグできます。ここでは、Cloud Spanner レシーバーが Prometheus エクスポータや Grafana ダッシュボードとどのように連携するかを示すサンプルの docker サービスを紹介します。

オープン スタンダードを採用し、パートナー エコシステムとのインテグレーションを続けています。また、お客様がどこにいても最高の体験ができるように、Google コンソールで提供されるオブザーバビリティ体験を進化させ続けています。

誤解 6 Spanner は複数のリージョンでのコピーを必要とするグローバルなワークロードにのみ適している

実は、Spanner ではマルチリージョンのインスタンス構成が可能ですが、GCP の各リージョンでのリージョン構成も可能です。各リージョンのノードはリージョン内の 3 つのゾーンに複製され、マルチリージョンのノードは複数のリージョンに少なくとも 5 回複製されます。リージョン構成により、99.99% の可用性とゾーンの障害に対する保護を実現します。

一般的には、アプリケーションが複数の地理的位置でワークロードを実行している場合や、ビジネスにおいて 99.999% の可用性とリージョンの障害からの保護が必要な場合に、マルチリージョンのインスタンス構成が提案されます。詳しくはこちらをご覧ください。

誤解 7 Spanner でのスキーマ変更には高価なロックが必要

実は、Spanner にはテーブルレベルのロックはありません。Spanner は、マルチバージョン同時実行制御アーキテクチャを使用して、スキーマとデータの同時バージョンを管理し、ダウンタイム、追加ツール、移行パイプライン、複雑なロールバック / バックアップ プランを必要としない、アドホックでオンラインの適格なスキーマ変更を可能にします。スキーマの更新を行う際には、テーブルの行数が 10 行であっても 100 億行であっても、Spanner が更新をバックフィルする間、データベースでの書き込みや読み取りを中断することなく続けることができます。

同じメカニズムをポイントインタイム リカバリ（PITR）やステイル読み取りを使用したスナップショット クエリでも使用することができ、最大で 7 日間まで、与えられたクエリ条件とタイムスタンプでスキーマとデータの状態の両方を復元できます。

Cloud Spanner の真実がわかったところで、ぜひ利用を開始してください。Google のウェブサイトをご覧ください。