【セッションレポート】「細かすぎて伝わらない！Spanner のユニークで実用的な機能や特徴」に参加しました

# はじめに
本記事はDB Tech Showcase 2024 の1日目(7/11)において Google Cloud の佐藤さんが講演された「細かすぎて伝わらない！Spanner のユニークで実用的な機能や特徴」のレポートです。

# 公式セッション紹介
> フルマネージドな分散 DB である Spanner は、原子時計の話など目立つ内部アーキテクチャの話ばかり知られていて、実際のアプリ開発や運用がどうなるのか、イメージが沸かない方も多いのではないでしょうか？本セッションでは、Spanner で実際の開発や運用を行う際に利用できる、「細かすぎて一般にあまり伝わってない」ユニークで実用的な機能や特徴について紹介したいと思います。これを聞けば Spanner を使うときのイメージが膨らむこと間違いなし！

# 発表資料
- 未公開(公開するという話をされていたような気がします)

# 概要／おすすめポイント

基本的なSpannerの話も少しだけされており、重要な点として以下二つを特徴として挙げられてました。
1. 高可用性の仕組み
    - Spannerはシングルリージョン構成で99.99%、マルチリージョン構成だと99.999%のSLAを持っており、その高可用性はログシッピング(トランザクションログの伝搬)で担っていること
1. スケーラビリティの仕組み
    - Spannerのスケーラビリティは内部のフルマネージドなシャーディングによって確保されていること

これだけだと何を言っているかわからないと思いますので、佐藤さんの記事([クラウドネイティブなデータベースとSpanner](https://gihyo.jp/article/2023/12/modern-app-development-on-google-cloud-04))を参照してみてください。。

本セッションでは、上記のサイトなどで紹介されているようなSpannerの特徴・・ではなく、あまり他では取り上げられていないが実用上・運用上楽になる点・助かる点を中心に紹介されてました。
なので、一応前提としては上記のサイトなどでSpannerの一般的なメリットは確認されておいた方が良いでしょう。

# セッション内容の紹介

Spannerの実用的なTIPSとして次を紹介されていました。

1. パラメータがない
    - Spannerはパラメータファイルを持ちません。例えばOracle Databaseだと初期化パラメータファイル、PostgreSQLだとpostgresql.confのように、メモリのサイズとかを設定するファイルを持ったりしますが、Spannerではそのようなパラメータファイルは持ちません。そのため、作成するときにはほぼ設計なしに作成することが可能となります。(もちろん、スキーマ設計などは必要になりますが。。)
1. 過去データがしばらく保持される
    - PostgreSQLのアーキテクチャをイメージするとわかりやすいかな、と思いますが、追記型のアーキテクチャとなるためデータ削除などが発生した場合にもデータはすぐに削除されません。そのため、というわけでもないですが過去のある時点の状態をクエリすることが可能です。Oracle Databaseだとフラッシュバッククエリ、BigQueryだとタイムトラベルとか呼ばれたりします
1. ダッシュボードが使いやすい
    - ダッシュボードからSQLに対してタグをつけたりすることで、本体側をいじらずに性能のトラックとかができるようになります
    - ロック待ちなどもダッシュボードから確認できるので、ビジュアライズにトラブルシュートとかを行えます。ちなみにSpannerは行単位ではなくセル単位でロックが確保されるそうです
1. バージョンアップがない
    - メジャーバージョンのような概念がないため、バージョンアップによる互換性が、、とか、古いバージョンがEOSLになるためバージョンアップしないと、、といったようなことがありません。この辺はクラウドネイティブなデータベースだと当然と言えば当然ですが(RedshiftやDynamoDBもない)、リレーショナルデータベースはクラウドネイティブなデータベースエンジン自体が少ないのでSpannerの特徴になるという事でしょう
1. シャーディングはSpannerが自動で実施してくれる
    - Spannerではテーブルの主キーで自動的にシャーディングが行われますが、Spanner自身が負荷集中などを検知して動的に分割を行うため、ユーザーが意識する必要はありません
1. ストレージを全く意識する必要がない
    - Spannerのストレージは Google CloudのColossusという[スケーラブルなストレージ](https://cloud.google.com/blog/ja/products/storage-data-transfer/a-peek-behind-colossus-googles-file-system)上に配置されており、ユーザーはストレージを意識する必要はなく、必要な分だけ利用することができます
1. アプリからの接続は単一のエンドポイント
    ‐ 読み取り専用 or 書き込み可能 などの分類はありますが、基本的には単一のエンドポイントへの接続で内部的な一貫性とかは保たれる仕組みになっています
    ‐ レプリカラグは発生するので、読み取り専用の場合にはいつ時点のデータを見せるのか、というような調整を行うことである程度見せるデータを制御することが可能となります。[ステイルリード(読み取り)](https://cloud.google.com/spanner/docs/reads?hl=ja#perform-stale-read)と呼ばれている仕組みになります
1. シングルリージョン構成とマルチリージョン構成
    ‐ Spannerはシングルリージョン構成とマルチリージョン構成をとることができます。マルチリージョン構成をとる場合、日本で実施する場合にはソウルリージョンにWitnessを持つ必要がありますが、東京か大阪が障害になっていなければ特にWitnessを待つ必要はないので～10msec程度のレイテンシになるようです。ソウルを待つ場合には～30msec程度が必要になるとのことでした
    - この発表の後ですが、[Dual Region構成](https://cloud.google.com/spanner/docs/instance-configurations#dual-region-configurations) も新しく発表されていました


# まとめ

元々はSpannerが出た当初は高可用性とかのメリットはあるけどちょっと高くて使いづらいもの、というイメージがあったように思いますが、数年前から [処理ユニット単位での課金](https://cloud.google.com/blog/ja/products/databases/get-more-out-of-spanner-with-granular-instance-sizing) が可能となっておりスモールスタートにも対応しています。
シャーディングを利用したリレーショナルデータベースは現時点でも一般的に利用されている状況とは言い難いですが、Spannerはお手軽に試せるのでスケーラビリティやマルチリージョン化だけでなく、上記のTIPSのどれかにも興味があるなら利用されてみてはいかがでしょうか？

2024/8/1～8/2の [Google Cloud Next Tokyo](https://cloudonair.withgoogle.com/events/next-tokyo-24)(パシフィコ横浜ですが)でもSpannerの話があるそうです。