このページでは、Spanner のコンピューティング容量と、それを数値化するために使用する 2 つの測定単位（ノードと処理単位）について説明します。
コンピューティング容量
コンピューティング容量は、インスタンス内のデータベースに使用可能なサーバーとストレージのリソースの量を定義します。インスタンスを作成するときは、そのコンピューティング容量を処理単位数またはノード数（1,000 処理単位が 1 ノードに相当します）として指定します。
コンピューティング容量が 1,000 処理単位（1 ノード）未満のインスタンスを作成している場合は、処理単位を使用してインスタンスのコンピューティング容量を指定する必要がありますが、それ以外ではどの測定単位を使用するかは重要ではありません。
インスタンスのコンピューティング容量を定義または変更するときは、処理単位を 100 の倍数（100、200、300 など）で指定します。処理単位数が 1,000 に達すると、1,000 処理単位の倍数（1,000、2,000、3,000 など）またはノード（1、2、3 など）として、より大きな量を指定できます。
処理単位が 1,000 未満のインスタンスは、より小さいデータサイズ、クエリ、ワークロード向けに作られています。コンピューティング リソースが制限されているため、一部のワークロードではスケーリングとパフォーマンスが非線形になり、レイテンシが断続的に増加する可能性があります。
データ ストレージの上限
割り当てと上限で詳しく説明されているように、高可用性とデータベース アクセスのレイテンシ低減のために、Spanner は次のガイドラインを使用して、インスタンスのコンピューティング容量に基づいてストレージの上限を定めます。
- 1 ノード（1,000 処理単位）未満のインスタンスの場合、Spanner ではデータベース内の 100 処理単位ごとに 409.6 GB のデータが割り当てられます。
- 1 ノード以上のインスタンスの場合、Spanner はノードごとに 4 TB のデータを割り当てます。 増加したストレージ容量（ノードあたり 10 TB）は、一部のリージョン、デュアルリージョン、マルチリージョンの Spanner インスタンス構成で利用できます。詳細については、パフォーマンスとストレージの改善をご覧ください。
たとえば、300 GB のデータベース用のインスタンスを作成する場合、そのコンピューティング容量を 100 処理単位に設定できます。このコンピューティング容量では、データベースが 409.6 GB を超えるまで、インスタンスは上限未満に保持されます。データベースがこのサイズを超過すると、データベースを拡大できるように、さらに 100 処理単位を追加する必要があります。そうしないと、Spanner がデータベースへの書き込みを拒否する可能性があります。詳細については、データベース ストレージ使用率の推奨事項をご覧ください。
Spanner では、合計ストレージ割り当てではなく、インスタンスが実際に使用したストレージに対して課金されます。
パフォーマンス
一定量のコンピューティング容量が与えるピーク読み取り / 書き込みスループット値は、インスタンス構成、スキーマ設計、データセットの特性によって異なります。詳細については、リージョン構成のパフォーマンスとマルチリージョン構成のパフォーマンスをご覧ください。
小規模なデータサイズ、クエリ、ワークロードには、1,000 処理単位未満のインスタンスを使用します。大規模なワークロードでは、コンピューティング リソースが制限されるため、スケーリングとパフォーマンスが非線形になり、断続的にレイテンシがに増加する可能性があります。
コンピューティング容量とインスタンス構成
リージョン、デュアルリージョン、マルチリージョン構成で説明するように、Spanner は 1 つ以上のリージョンのゾーン間でインスタンスを分散して、高いパフォーマンスと高可用性を実現します。したがって、インスタンスのコンピューティング容量で提供されるサーバー リソースも同様に分散されます。
これは、このサーバー リソースの分布を示す図です。
この図は、リージョン構成を備えた 2 つのインスタンスを示しています。
- Instance-A は、1,000 処理単位（1 ノード）のインスタンスで、3 つのゾーンのそれぞれでサーバー リソースを消費するコンピューティング容量の分散を示しています。
- Instance-B は、2,000 処理単位（2 ノード）のインスタンスで、3 つのゾーンのそれぞれでサーバー リソースを消費するコンピューティング容量の分散を示しています。
この図では、次の点に注意してください。
インスタンスごとに、リージョン構成の各ゾーンにサーバー リソースが割り当てられます。ゾーンごとのサーバー リソースは、それぞれのゾーン内のデータレプリカを使用します。インスタンス構成のデータレプリカについては、リージョン、デュアルリージョン、マルチリージョン構成をご覧ください。Spanner でこれらのデータレプリカを同期させる方法については、レプリケーションをご覧ください。
インスタンス A のサーバー リソースは 1 つのボックスで示され、インスタンス B のリソースは 2 つの部分に分割されたボックスで示されます。この違いは、Spanner がサイズの異なるインスタンスに対して異なるサーバー リソースを割り当てることを示しています。
- 1,000 処理単位（1 ノード）以下のインスタンスの場合、Spanner はゾーンごとに 1 つのサーバータスクでサーバー リソースを割り当てます。
- 1,000 処理単位（1 ノード）を超えるインスタンスの場合、Spanner はゾーンごとに複数のサーバータスクにサーバー リソースを割り当て、1,000 処理単位ごとに 1 つのタスクを割り当てます。ゾーンごとに複数のサーバータスクを使用すると、パフォーマンスが向上し、Spanner はデータベースのスプリットを作成し、さらにパフォーマンスを向上させることができます。
コンピューティング容量を変更する
インスタンスを作成した後で、そのコンピューティング容量を増やすことができます。ほとんどの場合、リクエストは数分で完了します。まれに、スケールアップが完了するまでに最大 1 時間かかることがあります。
たいてい、コンピューティング容量を減らすこともできます。コンピューティング容量を減らすことができないケースはわずかです。
- コンピューティング容量を削除するには、1,000 処理ユニット（1 ノード）あたり 4 TB を超えるデータをインスタンスに格納する必要があります。
- 過去の使用パターンに基づいて、Spanner はインスタンスのデータのスプリットを多数作成しました。まれにコンピューティング容量を削除した後はスプリットを管理できないことがあります。
後者の場合、Cloud Spanner でインスタンスのすべてのスプリットを管理するのに必要な最小容量が見つかるまで、コンピューティング容量を徐々に減らすことができます。使用パターンの変化により、インスタンスでそれほど多くのスプリットが必要なくなった場合、Cloud Spanner は最終的に一部のスプリットをマージし、1 ～ 2 週間後にインスタンスのコンピューティング容量を削減してみることができます。
コンピューティング容量を削除するときは、Cloud Monitoring で CPU 使用率とリクエスト レイテンシをモニタリングし、リージョンのインスタンスで CPU 使用率が 65% を下回り、マルチリージョンのインスタンスの各リージョンで 45% を下回るようにしてください。コンピューティング容量の削除中に、リクエストのレイテンシが一時的に増加する場合があります。
Spanner に一時停止モードはありません。Spanner のコンピューティング容量は専用のリソースであり、ワークロードが実行されていないときでも、Spanner はデータの最適化と保護のためにバックグランド処理を頻繁に実行しています。
コンピューティング容量を変更するには、Google Cloud コンソール、Google Cloud CLI、または Spanner クライアント ライブラリを使用します。詳細については、コンピューティング容量を変更するをご覧ください。
コンピューティング容量とレプリカ
インスタンスのサーバーとストレージのリソースをスケールアップする必要がある場合は、インスタンスのコンピューティング容量を増やします。コンピューティング容量を増やしても、レプリカの数は増加しません（レプリカ数は特定のインスタンス構成に対して固定です）が、インスタンス内でレプリカが使用できるリソースは増加します。コンピューティング容量を増やすと、各レプリカで使用可能な CPU と RAM が増えるため、レプリカのスループットが向上します（つまり、1 秒あたりの読み取りと書き込み数が増えます）。
次のステップ
- インスタンスの作成方法と管理方法を学習する。