Cloud Spanner設計入門｜グローバル分散NewSQLのスキーマ設計・課金体系・移行戦略を現場視点で徹底解説

Cloud Spannerとは何か｜分散NewSQLの位置付けとRDB/NoSQLとの違い

Cloud Spannerの定義と登場背景

Cloud Spannerは、Googleが2017年に一般公開したフルマネージド型の分散リレーショナルデータベースです。従来のRDBMS（MySQL、PostgreSQLなど）が単一リージョン内での強い整合性を提供する一方で、グローバル規模での水平スケーリングには限界がありました。NoSQL（DynamoDB、Cassandraなど）は水平スケーリングに優れるものの、トランザクション保証やSQL互換性を犠牲にする設計が一般的でした。

Cloud Spannerは「NewSQL」と呼ばれるカテゴリに属し、RDBMSの厳密なACID保証とNoSQLのスケーラビリティを両立させた設計思想を持ちます。2026年5月時点で、グローバル展開するSaaS企業や金融機関を中心に、月間10億件以上のトランザクションを処理する事例が複数報告されています。

RDBMSとの違い｜単一障害点の排除と自動シャーディング

従来のRDBMSでは、プライマリ・レプリカ構成を取ることでHA（高可用性）を実現しますが、プライマリノードは単一障害点（SPOF）となり得ます。Cloud Spannerは、内部的にPaxosベースの分散合意アルゴリズムを採用し、データを複数のノード（Split）に自動分散します。各Splitは最低3つのレプリカを持ち、過半数の合意によって書き込みがコミットされるため、特定ノードの障害が発生しても透過的にフェイルオーバーが実行されます。

・自動シャーディング: テーブルのデータは主キーの範囲に基づいて自動的にSplitに分割され、各Splitが独立してスケールします。オペレータが手動でシャード境界を設計する必要がありません。
・グローバル整合性: マルチリージョン構成でも外部一貫性（Externally Consistent）を保証し、クライアントが異なるリージョンから読み書きしても常に最新のコミット結果が反映されます。
・ゼロダウンタイムでのスキーマ変更: オンラインDDL機能により、テーブル構造の変更中もトランザクション処理を継続できます。

NoSQLとの違い｜強い整合性とSQL標準準拠

DynamoDB Global TablesやCassandraは結果整合性（Eventual Consistency）を採用し、書き込み直後の読み取りで最新データが保証されない場合があります。Cloud Spannerは、すべての読み取りが強い整合性（Strong Consistency）を持ち、金融取引や在庫管理など厳密な整合性が求められるワークロードに適しています。

また、SQL標準に準拠したクエリ言語（GoogleSQL、PostgreSQL互換の2つの方言をサポート）を提供し、既存のRDBMS資産を活用できます。JOINやサブクエリ、ウィンドウ関数など高度なSQL機能をサポートしており、NoSQLへの移行時に発生しがちなアプリケーションロジックの大幅な書き換えを回避できます。

Cloud Spannerと他DB（Aurora Global・DynamoDB Global Tables・CockroachDB）の比較

主要グローバル分散DBの機能・料金・整合性モデルの比較

どのDBを選ぶべきか｜ワークロード別の選定基準

・Cloud Spanner: 複数リージョンで同時書き込みが必要で、かつ厳密なトランザクション保証が求められる場合。初期コストは高いものの、グローバル展開時の運用工数を大幅に削減できます。
・Aurora Global: 単一リージョンでの書き込み集中型ワークロードで、他リージョンは読み取り専用で十分な場合。MySQL/PostgreSQLからの移行パスが最も短い選択肢です。
・DynamoDB Global Tables: 結果整合性を許容でき、スパイクするトラフィックに対してオンデマンドスケールが必要な場合。キーバリューアクセスが中心のアプリケーションに最適です。
・CockroachDB: オンプレミスとクラウドのハイブリッド構成が必要で、ベンダーロックインを回避したい場合。PostgreSQLエコシステムの資産を最大限活用できます。

スキーマ設計の基本（インターリーブテーブル・主キー設計・ホットスポット回避）

インターリーブテーブルによる親子関係の物理配置最適化

Cloud Spannerの最大の特徴の一つが、インターリーブテーブル（Interleaved Tables）です。従来のRDBMSでは、親テーブル（例: Users）と子テーブル（例: Orders）は物理的に別の領域に格納され、JOIN時にディスクI/Oが発生します。インターリーブテーブルでは、親レコードと関連する子レコードを物理的に隣接して配置することで、1回のディスク読み取りで親子データをまとめて取得できます。

CREATE TABLE Users (
  user_id STRING(36) NOT NULL,
  email STRING(256),
  created_at TIMESTAMP,
) PRIMARY KEY (user_id);

CREATE TABLE Orders (
  user_id STRING(36) NOT NULL,
  order_id STRING(36) NOT NULL,
  amount NUMERIC,
  order_date TIMESTAMP,
) PRIMARY KEY (user_id, order_id),
  INTERLEAVE IN PARENT Users ON DELETE CASCADE;

この例では、Ordersテーブルの主キーにuser_idを含めることで、特定ユーザーの全注文データが物理的に連続して格納されます。JOIN不要でユーザー情報と注文一覧を同時取得でき、レイテンシが従来比で30～50%削減されるケースが多数報告されています。

主キー設計とホットスポット回避の鉄則

Cloud Spannerは主キーの範囲に基づいてデータをSplitに分散するため、主キーの設計がパフォーマンスに直結します。最も避けるべきパターンは、単調増加するキー（連番ID、タイムスタンプ）を主キーの先頭に配置することです。新しいデータが常に最後のSplitに集中し、書き込み負荷が特定ノードに偏る「ホットスポット」が発生します。

・悪い例: PRIMARY KEY (timestamp, user_id) → 最新タイムスタンプの書き込みが特定Splitに集中
・良い例: PRIMARY KEY (user_id, timestamp) → user_idが分散しているため、書き込みが複数Splitに均等分散
・UUIDの採用: user_idにUUIDv4を使用することで、主キー空間全体にデータが均等に広がります。ただしUUIDv1（タイムスタンプベース）はホットスポットを引き起こすため注意が必要です。

2026年5月時点のベンチマークでは、単調増加キーを使用した場合の書き込みスループットは約5,000 QPS/ノードが上限でしたが、UUIDベースの主キーに変更することで同一ノード数で15,000 QPS以上を達成した事例が報告されています。

セカンダリインデックスの設計と読み取りパフォーマンス

セカンダリインデックスは別のSplitに格納されるため、インデックスを経由した読み取りは「インデックスSplit → データSplit」の2段階アクセスが発生します。頻繁にアクセスするカラムは、STORING句を使ってインデックスに含めることで、2段階アクセスを回避できます。

CREATE INDEX OrdersByDate
ON Orders (order_date)
STORING (amount, status);

この設計により、order_dateでフィルタしてamountとstatusを取得するクエリは、インデックスだけで完結し、レイテンシが約40%削減されます。ただしSTORING句で追加するカラムが多いほどインデックスサイズが増大し、書き込み時のオーバーヘッドも増加するため、カラム選定は慎重に行う必要があります。

トランザクションとレプリケーション設計（マルチリージョン・読み取り専用レプリカ）

TrueTime APIとグローバルトランザクションの仕組み

Cloud Spannerがグローバル規模で強い整合性を実現できる理由は、GoogleのインフラストラクチャであるTrueTime APIにあります。TrueTimeは、原子時計とGPSを組み合わせた高精度な時刻同期システムで、各データセンターの時刻誤差を7ms以内に収めます。この誤差範囲を利用して、Cloud Spannerは「どのトランザクションがより後に発生したか」を全リージョンで一意に決定できます。

・Commit Wait: トランザクションのコミット時、TrueTimeの誤差分だけ意図的に待機することで、他リージョンから見ても「この時刻以降にコミットされた」と保証します。平均待機時間は5～10ms程度です。
・外部一貫性: クライアントAが書き込みを完了した後、クライアントBが読み取りを開始した場合、必ずAの書き込み結果が反映されます。これは単一リージョンRDBMSでは自明ですが、地理的に分散したシステムで実現するのは非常に困難です。

マルチリージョン構成の設計パターン

Cloud Spannerは、リージョン構成に応じて3つの展開モデルを提供します。

・リージョナル構成: 単一GCPリージョン内の複数ゾーンにレプリカを配置。レイテンシは1桁ms台で、リージョン内障害に対して99.99%の可用性を提供します。コストは最も低く、リージョン間通信費用が発生しません。
・マルチリージョン構成: 3つ以上のリージョンにレプリカを配置し、Paxos合意に必要な過半数を複数リージョンで確保。99.999%の可用性（年間ダウンタイム5分未満）が保証されます。書き込みレイテンシは数百ms（東京～大阪～シンガポール構成で平均150ms）です。
・デュアルリージョン構成: 2つのリージョンにレプリカを配置し、第3のWitnessリージョンで合意投票のみを行う設計。コストと可用性のバランスが良く、日本国内での展開（東京・大阪＋台湾Witness）に適しています。

読み取り専用レプリカと読み取り一貫性オプション

読み取り専用レプリカ（Read-only Replicas）は、書き込みには関与せず読み取り負荷を分散するためのレプリカです。通常のレプリカと異なり、Paxos合意に参加しないためコストが約30%削減されます。

また、読み取りクエリには3つの一貫性オプションがあります。

・Strong Read: 最新のコミット結果を保証。レイテンシは高いが、金融取引など厳密な整合性が必要な場合に使用します。
・Stale Read: 指定した時刻（例: 10秒前）のスナップショットを読み取り。レイテンシが低く、レポート生成やバッチ処理に適しています。
・Exact Staleness Read: 特定のタイムスタンプのデータを読み取り。複数クエリで同じタイムスタンプを指定することで、一貫したスナップショットを取得できます。

課金体系の徹底解説（コンピュート/ストレージ/ネットワーク・課金単位の落とし穴）

ノード課金とProcessing Units（PU）の仕組み

Cloud Spannerの課金は、ノード時間またはProcessing Units（PU）時間を基準とします。1ノードは1,000 PUに相当し、最小構成は100 PU（0.1ノード）から開始できます。2026年5月時点の東京リージョンでの料金は以下の通りです。

・リージョナル構成: 1ノード（1,000 PU）あたり約$0.90/時間、月額約$648
・マルチリージョン構成: 1ノードあたり約$3.00/時間、月額約$2,160
・最小構成（100 PU）: 月額約$65から開始可能ですが、本番環境では最低300 PU（スループット約1,500 QPS）が推奨されます。

ノード数は動的にスケールでき、自動スケーリング機能を有効にすることで、CPU使用率65%を閾値に自動でノードが追加・削減されます。ただしスケールダウンには約15分のクールダウン期間があり、急激なトラフィック変動には追従しきれない点に注意が必要です。

ストレージ課金とバックアップコスト

ストレージ課金は、実際に使用しているデータ量とバックアップ保持量に基づいて計算されます。

・アクティブストレージ: リージョナル構成で$0.30/GB/月、マルチリージョン構成で$0.50/GB/月。インデックスもストレージ容量に含まれるため、不要なインデックスは削減すべきです。
・バックアップストレージ: 自動バックアップは過去7日間保持され、$0.11/GB/月で課金されます。手動バックアップは保持期間を指定でき、最大365日まで保存可能です。
・リストアコスト: バックアップからのリストアは無料ですが、リストア後のノード時間課金が発生するため、リストアテストは短時間で完了させる設計が重要です。

ネットワーク転送とレプリケーションコストの落とし穴

マルチリージョン構成では、リージョン間のレプリケーショントラフィックに課金が発生します。書き込みデータは全リージョンに同期されるため、1MBの書き込みが3リージョン構成で約3MBのネットワーク転送を引き起こします。

・リージョン間転送: アジア内の転送で約$0.08/GB、異大陸間（例: 東京～フランクフルト）で約$0.12/GBです。
・エグレス課金: Cloud Spannerからアプリケーションへのデータ転送は、同一リージョン内であれば無料ですが、異なるリージョンのGKEクラスタからアクセスする場合は課金対象です。
・コスト最適化: 読み取り専用レプリカを各リージョンに配置し、読み取りクエリを最寄りのレプリカに向けることで、クロスリージョン転送を最小化できます。

既存DB（MySQL/PostgreSQL/Oracle）からの移行戦略

アセスメントとスキーマ変換の事前準備

Cloud Spannerへの移行は、単なるリフト&シフトではなく、分散データベースの特性に合わせた再設計が必要です。GoogleはHarbourBridgeというオープンソースツールを提供しており、PostgreSQLやMySQLのスキーマをCloud Spanner互換形式に変換できます。ただし自動変換では最適化されないため、以下の点を手動で調整する必要があります。

・主キー再設計: AUTO_INCREMENTカラムはホットスポットを引き起こすため、UUIDまたはハッシュベースのキーに変更します。
・外部キー制約: Cloud Spannerは外部キーをサポートしますが、インターリーブテーブル構造への変換を検討すべきです。
・トリガーとストアドプロシージャ: Cloud Spannerにはトリガーとストアドプロシージャがないため、アプリケーションロジックへの移行が必要です。

データ移行の実行パターン｜Dataflow & Database Migration Service

Googleは2つの主要な移行ツールを提供しています。

・Database Migration Service（DMS）: PostgreSQL/MySQLから継続的レプリケーションを行い、ダウンタイムを最小化します。初期ロード→継続同期→カットオーバーの3段階で移行を実行し、カットオーバー時のダウンタイムは数分以内に抑えられます。2026年5月時点で、100GBのPostgreSQLデータベースの初期ロードは約2～3時間で完了します。
・Dataflow テンプレート: バッチ移行に適しており、BigQueryやCloud Storage経由でのデータ投入が可能です。1TBのデータを100ノードのDataflowパイプラインで移行した場合、約4～6時間で完了します。

アプリケーション改修とトランザクション境界の再設計

Cloud Spannerは分散トランザクションのため、トランザクション境界を小さく保つことがパフォーマンスの鍵です。従来のRDBMSでは長時間トランザクションが許容されるケースがありましたが、Cloud Spannerでは以下のベストプラクティスを守る必要があります。

・トランザクション実行時間を10秒以内に: 10秒を超えるトランザクションはタイムアウトし、ロックの保持時間が長くなると他トランザクションのブロッキングを引き起こします。
・楽観的ロックの採用: SELECT FOR UPDATEによる悲観的ロックは、分散環境ではデッドロックのリスクが高まります。バージョンカラムを使った楽観的ロックを推奨します。
・リトライロジックの実装: Aborted（競合によるトランザクション中断）は正常な挙動であり、アプリケーション側で自動リトライを実装する必要があります。Googleのクライアントライブラリは自動リトライ機能を提供しています。

パフォーマンスチューニング（インデックス・クエリプラン・スキャン削減）

クエリプランの読み方とボトルネックの特定

Cloud Spannerの管理コンソールでは、各クエリの実行プランを可視化できます。EXPLAINコマンドを使用することで、どのインデックスが使用され、どれだけのデータがスキャンされたかを確認できます。

EXPLAIN SELECT * FROM Orders
WHERE user_id = 'abc-123'
AND order_date BETWEEN '2026-01-01' AND '2026-12-31';

実行プランで注目すべき指標は以下の通りです。

・Rows Scanned: スキャンされた行数。返される行数の10倍以上であれば、インデックスの追加を検討すべきです。
・Execution Time: クエリの実行時間。100ms以上の場合、インデックス不足またはJOINの最適化が必要です。
・Distribution Skew: 特定のSplitに負荷が集中している場合、主キー設計の見直しが必要です。

バッチ書き込みとMutation上限の最適化

Cloud Spannerは単一トランザクション内で最大20,000件のMutation（挿入・更新・削除）を許可します。1件のINSERTは1 Mutationですが、10カラムをUPDATEした場合は10 Mutationとしてカウントされます。大量データの投入時は、以下の戦略が有効です。

・Mutation Batching: 10,000件ごとにトランザクションを分割し、並列で複数トランザクションを実行します。Dataflowテンプレートは自動的にバッチ分割を行います。
・Commit Timestamp自動設定: allow_commit_timestamp=true オプションを使用することで、コミット時刻を自動で設定でき、アプリケーション側のタイムスタンプ生成が不要になります。

Query Insightsによる自動最適化提案

2025年にリリースされたQuery Insights機能は、実行されたクエリを分析し、インデックス追加の推奨やクエリ書き換え提案を自動で行います。過去7日間のクエリログを解析し、CPU使用率を5%以上削減できるインデックスを提案します。

・自動インデックス推奨: 頻繁に実行されるクエリで、テーブルスキャンが発生している場合、最適なインデックス定義を提案します。
・クエリ書き換え提案: サブクエリをJOINに変換する、ORをUNIONに分割するなど、実行プランを改善する書き換え案を提示します。
・コスト影響予測: 推奨インデックスを追加した場合のストレージコスト増加と、削減されるCPU使用率をシミュレーションします。

よくあるトラブル（ホットスポット・コミット遅延・スキーマ更新衝突）

ホットスポット検出と対策｜Key Visualizerの活用

ホットスポットは、特定のSplitに書き込みが集中し、CPU使用率が90%を超える状態です。Key Visualizerは、主キー範囲ごとの負荷をヒートマップで可視化し、どのキー範囲がホットスポットになっているかを一目で確認できます。

・タイムスタンプを主キー先頭に配置: 最も一般的な原因で、最新データの書き込みが最後のSplitに集中します。主キーの順序を入れ替える（例: user_id, timestamp → timestamp, user_id）ことで負荷が分散します。
・特定ユーザーへの集中書き込み: 1ユーザーに対して秒間1,000回以上の書き込みが発生すると、そのユーザーのデータが格納されたSplitがホットスポットになります。ユーザーIDにシャーディングキー（例: user_id_shardを0～9でランダム付与）を追加し、負荷を複数Splitに分散します。

コミット遅延の原因と診断手法

マルチリージョン構成では、コミットに数百msかかることが正常ですが、1秒以上の遅延が頻発する場合は以下を確認します。

・リージョン間レイテンシの測定: 東京～シンガポール間のネットワークレイテンシが100msであれば、最低でも200ms（往復）のコミット時間が発生します。gcping.comなどでリージョン間レイテンシを測定し、構成を見直します。
・Paxos Leaderの配置: 書き込みトラフィックの多いリージョンにPaxos Leaderを配置することで、コミットレイテンシを削減できます。デフォルトでは自動配置されますが、明示的に指定することも可能です。
・トランザクション競合: 同一レコードへの同時更新が多発すると、Abortとリトライが繰り返され、実効スループットが低下します。競合が多いカラムは別テーブルに分離する設計が有効です。

スキーマ更新衝突とオンラインDDLの制約

Cloud SpannerのオンラインDDLは、ほとんどの変更をダウンタイムなしで実行できますが、以下の制約があります。

・同時DDL実行の制限: 単一データベースで同時に実行できるDDLは1つのみです。複数のCREATE INDEX文を並列実行しようとするとエラーになります。
・インデックス作成時間: 100GBのテーブルにインデックスを追加する場合、約15～30分かかります。この間、読み取り・書き込みトランザクションは継続できますが、CPU使用率が一時的に上昇します。
・NOT NULL制約追加の注意: 既存テーブルにNOT NULL制約を追加する場合、全行をスキャンして制約違反がないか検証します。大規模テーブルでは数時間かかることがあり、事前にデータクレンジングを完了させる必要があります。

よくある質問

Cloud Spannerはいくらからスタートできますか？

2026年5月時点で、リージョナル構成の最小構成（100 PU）は月額約$65から開始できます。ただし本番環境では、最低300 PU（月額約$195）を推奨します。開発環境では100 PUで十分ですが、スループットは約500 QPSが上限です。無料枠は提供されておらず、エミュレータ（ローカル環境）で開発テストを行うことでコストを抑えられます。

既存のMySQL/PostgreSQLアプリケーションをどれだけ書き換える必要がありますか？

HarbourBridgeを使用したスキーマ変換で80～90%は自動変換されますが、以下の部分は手動改修が必要です。トリガーとストアドプロシージャはCloud Spannerに存在しないため、アプリケーションロジックへ移行します。AUTO_INCREMENTキーはUUID生成ロジックに変更し、悲観的ロックは楽観的ロックまたはトランザクション再試行に書き換えます。通常、中規模アプリケーション（10万行程度）で2～4週間の改修期間を見込むケースが多いです。

ダウンタイムなしで移行できますか？

Database Migration Service（DMS）を使用することで、ダウンタイムを数分以内に抑えた移行が可能です。初期データロード中も既存データベースは稼働し続け、継続的レプリケーションで差分を同期します。カットオーバー時のみ、アプリケーションの接続先を切り替えるための短時間停止が必要です。100GB規模のデータベースで、ダウンタイム5分以内での移行実績が多数報告されています。

AWSやAzureからもCloud Spannerを使えますか？

技術的には可能ですが、推奨されません。Cloud SpannerはGCP外からもパブリックIPでアクセス可能ですが、クロスクラウドのネットワークレイテンシ（50～100ms追加）とエグレス課金が発生します。AWSでグローバル分散が必要な場合はAurora GlobalまたはDynamoDB Global Tablesを、Azureでは現在Cosmos DB for PostgreSQLが類似の選択肢となります。

Cloud SpannerとFirestoreの使い分けはどうすべきですか？

Cloud Spannerは複雑なトランザクションとJOINが必要なワークロード（ECサイトの注文処理、金融取引など）に適しています。Firestoreはドキュメント指向のデータモデルで、モバイルアプリのリアルタイム同期やユーザープロファイル管理に最適です。Firestoreは従量課金（読み取り10万回=$0.06）でスパイクに強く、Cloud Spannerはノード時間課金で安定したスループットが必要な場合に選びます。両者を併用し、トランザクション処理をSpanner、リアルタイム通知をFirestoreで分担する設計も一般的です。

導入前チェックリスト

・主キー設計の確認: 単調増加キー（AUTO_INCREMENT、連番タイムスタンプ）を主キー先頭に配置していないか検証する
・トランザクション境界の測定: 既存アプリケーションで10秒を超えるトランザクションが存在しないか調査する
・Mutationカウントの試算: バッチ処理で単一トランザクション内のMutationが20,000件を超えないか確認する
・リージョン構成の選定: 必要な可用性とレイテンシ要件から、リージョナル/デュアルリージョン/マルチリージョンを決定する
・コスト試算: ピークスループット（QPS）を測定し、必要なノード数と月額コストを試算する（1ノード=約2,000 QPS目安）
・インターリーブテーブル設計の検討: 頻繁にJOINされる親子テーブルをインターリーブ構造に変更できるか評価する
・セカンダリインデックスの棚卸し: 既存DBのインデックスをリストアップし、STORING句による最適化を計画する
・トリガー・ストアドプロシージャの移行計画: 既存ロジックをアプリケーション層に移行する工数を見積もる
・エミュレータ環境の構築: ローカル開発環境でCloud Spannerエミュレータを起動し、接続テストを実施する
・HarbourBridgeによるスキーマ変換: 既存スキーマをCloud Spanner形式に変換し、変換率と手動修正箇所を特定する
・リトライロジックの実装: Abortedエラーに対する自動リトライをアプリケーションに組み込む
・監視・アラート設定: Cloud MonitoringでCPU使用率（閾値65%）、ストレージ使用率（閾値80%）のアラートを設定する
・バックアップ・リストアテスト: 本番投入前に手動バックアップを取得し、別インスタンスへのリストアを検証する
・移行計画書の作成: 初期ロード時間、継続同期期間、カットオーバー手順、ロールバック手順を文書化する
・パフォーマンステスト: 負荷テストツール（JMeter、Locustなど）で想定ピーク負荷の150%を再現し、レイテンシとスループットを測定する

本記事のまとめ

Cloud Spannerは、グローバル規模での強い整合性と水平スケーラビリティを両立した分散NewSQLデータベースです。TrueTime APIによる高精度な時刻同期と、Paxosベースの分散合意により、複数リージョンにまたがるトランザクションを数百ms以内で完了できます。

スキーマ設計では、インターリーブテーブルによる親子データの物理配置最適化と、ホットスポットを回避する主キー設計が成功の鍵となります。単調増加キーを避け、UUIDやハッシュベースのキーを採用することで、書き込みスループットを3倍以上向上させた事例も報告されています。

課金体系は、ノード時間・ストレージ・ネットワーク転送の3要素で構成され、マルチリージョン構成では特にレプリケーションコストが増大します。読み取り専用レプリカや、読み取り一貫性オプション（Stale Read）を活用することで、コストとパフォーマンスのバランスを最適化できます。

既存データベースからの移行では、Database Migration Serviceによる継続的レプリケーションを活用し、ダウンタイムを最小化できます。ただしトリガー・ストアドプロシージャの移行や、トランザクション境界の再設計には十分な準備期間を確保する必要があります。

2026年5月時点で、Cloud Spannerは金融・ECサイト・グローバルSaaSなど、厳密なトランザクション保証とグローバル展開が求められる領域で採用が進んでいます。オンプレミスの経験を活かしながら、クラウドネイティブな分散システムへの移行を検討する上で、有力な選択肢となります。