Spanner Omni ライセンスのインストールと管理

このドキュメントでは、ライセンスキーの保存と処理、デプロイへのインストール、期限切れのキーの更新、すべてのノードでのインストールの確認を行う方法について説明します。

本番環境を実行するには、商用 Spanner Omni ライセンスキーをインストールする必要があります。非本番環境では、ライセンスキーなしで 4 個以下の vCPU のシングル サーバー構成で Spanner Omni をデプロイすることで、バックアップと復元機能を使用できます。ワーカー機能は、使用するサーバーや vCPU の数に関係なく、デフォルト ライセンスまたはデベロッパー ライセンスではサポートされていません。ワーカーを使用するための商用ライセンスを購入するには、Google にお問い合わせください。

利用可能なライセンスの種類、エディション、機能については、Spanner Omni エディションの概要をご覧ください。

ライセンスキーを保存する

Spanner Omni ライセンスキーは、機密性の高い認証情報として扱います。ライセンスキーが不正使用された場合、Google は今後の Spanner Omni リリースでそのキーを無効にします。鍵の漏洩を防ぐため、次のライフサイクル ガイドラインを実装します。鍵をプレーンテキストで永続ストレージに書き込むのではなく、自動化システムを使用して鍵を挿入することをおすすめします。以降のセクションでは、ライセンスキーの保存方法、自動デプロイ ファイルの保護方法、ランタイム送信の構成方法について説明します。

中央のシークレット マネージャーでのストレージ

ライセンスキーをソース管理に commit したり、構成ファイルにハードコードしたりしないでください。キーは常に次のような一元管理された認証情報ストアに保存します。

デプロイの自動化

Terraform や Ansible などの自動化ツールを使用してデプロイする場合は、ライセンスキーをプレーン テキストの構成変数として渡さないでください。

  • Terraform: データソースを使用して、デプロイの実行時にライセンスキーを動的に取得します。sensitive = true 属性を使用して変数をマークし、実行コンソール ログに鍵が表示されないようにします。
  • Ansible: 構成の実行中に、シークレット マネージャー プラグイン(google.cloud.gcp_secret_manager や community.hashicorp.vault など)を使用して鍵をメモリに保持するか、リポジトリに保存されている場合は Ansible Vault で鍵を暗号化します。

実行時にライセンスキーを送信する

次の方法を使用して、権限のないユーザーにライセンスキーを公開せずに、データベース プロセスにライセンスキーを渡します。

VM ベースのデプロイ(クラウドまたはオンプレミス)

  • Identity and Access Management(IAM)ベースの挿入: データベース VM をマネージド サービス アカウントまたは IAM ロールに関連付けます。起動時またはプロビジョニング時(Ansible など)に、この ID を使用して、シークレット マネージャーからメモリまたはアクセスが制限されたディレクトリにライセンスキーを取得します。
  • オペレーティング システムの権限: 鍵をディスクに書き込む場合は、Spanner Omni プロセスを実行しているユーザーのみがファイルを表示できるように、ファイル アクセスを制限します(chmod 400 /path/to/license など)。ホストマシンへの SSH アクセスを厳しく制限します。

Kubernetes Deployment

  • Secrets Store CSI ドライバを使用する: 標準の Secrets Store CSI ドライバを使用して、外部シークレット マネージャーから Spanner Omni Pod に一時メモリ ボリューム(tmpfs)としてライセンスキーを直接マウントします。認証情報はメモリにのみ存在し、Pod が終了すると消えます。
  • 組み込みの Kubernetes Secret を避ける: base64 エンコードのみを使用し、etcd に保持される組み込みの Kubernetes Secret を使用しないでください。

ライセンスキーをインストールする

ライセンスキーをインストールまたは更新するには、キーをローカルパス(/path/to/your/license など)として Spanner Omni サーバーからアクセスできるようにします。

ライセンスキーのパスをサーバーに渡すには、spanner start コマンドまたは spanner start-single-server コマンドの実行時に --license-file-path フラグまたは SPANNER_LICENSE_FILE_PATH 環境変数を使用します。

次に例を示します。

spanner start --root \
  --license-file-path=LICENSE_KEY_FILE_PATH \
  --server-address=RESOLVABLE_HOSTNAME \
  --zone=ZONE_NAME \
  --base-dir=SPANNER_BASE_DIR

または、環境変数を使用してライセンス パスを指定します。

SPANNER_LICENSE_FILE_PATH=LICENSE_KEY_FILE_PATH \
  spanner start --root \
    --server-address=RESOLVABLE_HOSTNAME \
    --zone=ZONE_NAME \
    --base-dir=SPANNER_BASE_DIR

次のように置き換えます。

  • LICENSE_KEY_FILE_PATH: ライセンス キー ファイルのローカルパス。
  • RESOLVABLE_HOSTNAME: 解決可能なノードサーバーのホスト名または IP アドレス。
  • ZONE_NAME: デプロイのゾーン名。
  • SPANNER_BASE_DIR: サーバー ファイルが保存されるベース ディレクトリ。

または、サーバーが想定するパス(BASE_DIR/license/license)にライセンス キーを配置することもできます。Kubernetes Deployment の場合、BASE_DIR のデフォルトは /spanner です。

期限切れが近づいているライセンスを更新する

有効なデプロイで期限切れの Developer エディション ライセンスを更新、延長、または更新するには、永続ライセンスをリクエストします。有効期限が切れる概念実証ライセンスを延長するか、商用ライセンスを購入するには、Google にお問い合わせください。新しいライセンスを受け取ったら、そのパスを指定して、Spanner Omni サーバーのローリング再起動を開始します。

  1. 新しいライセンス ファイルを各ノードからアクセスできるようにします。
  2. サーバーノードを 1 つずつ再起動して、ローリング再起動を実行します。
  3. ロールアウト中にデプロイの健全性をモニタリングします。ノードの再起動に失敗した場合やエラーが発生した場合は、以前に機能していた構成にロールバックし、サーバーログを調べて新しいライセンスが正しく提供されていることを確認します。

Helm(Kubernetes)を使用してライセンスキーをインストールする

Google 提供の Helm チャートを使用してデプロイする場合は、アップグレード中にライセンス ファイルのパスを動的に渡すことができます。

Helm の --set-file フラグにはディスク上の物理パスが必要なため、ライセンスキーを永続ファイルに保存しないでください。代わりに、シークレット マネージャーからエフェメラル一時ファイルまたはインメモリ パス(Linux の /dev/shm など)に鍵を取得します。このパスを Helm に渡し、その後すぐにファイルを削除またはシュレッドします。これにより、システムがディスクにプレーンテキストの認証情報を残さないようにし、ローカルに保存されたり、誤ってバージョン管理に commit されたりすることを防ぎます。

helm upgrade --install spanner-omni \
  --set-file licenseKey=LICENSE_KEY_FILE_PATH

次のように置き換えます。

  • LICENSE_KEY_FILE_PATH: ライセンス キー ファイルのローカルパス。

ライセンスのインストールを確認する

ライセンスキーはクラスタ内のすべてのアクティブなサーバーノードにインストールされるため、リクエストを処理するサーバーノードのステータスを調べてインストールを確認できます。エンドポイントに describe コマンドを使用します。

spanner deployment describe --deployment-endpoint=SERVER_ADDRESS

次のように置き換えます。

  • SERVER_ADDRESS: サーバーノードのアドレス。

クラスタ全体の監査を実行する

VM クラスタまたは Kubernetes StatefulSet のすべてのノードに正しいライセンスキーがインストールされていることを確認するには、クラスタ全体の監査コマンドを実行します。

spanner admin license check

クラスタ全体の監査では、データベース トポロジ内のすべてのサーバーが検査されます。そのため、このコマンドを実行する前に、すべてのノードサーバーがオンラインでネットワーク アクセス可能であることを確認してください。

監査結果を解釈する

次の表を使用して、クラスタ全体の監査の結果を理解します。

クラスタの状態 出力タイプ 説明と必要な対応
均一(予想) 単一ライセンス ID すべてのノードが同じライセンスキーとタイプを使用している。これ以上の対応は必要ありません。
混合(対応が必要) ライセンス識別子とサーバーのリスト ノード間で異なるライセンスキーが検出された(たとえば、ローリング アップデートの停止中)。リストに表示されたノードを調べて、新しいライセンス ファイルが正しく適用されていることを確認します。

商用ライセンスのコンプライアンスを維持する

Spanner Omni の商用ライセンスを使用する場合は、ライセンス契約を遵守する必要があります。コンプライアンスを維持すると、請求に関する紛争を防ぎ、クラスタ リソースの使用状況を Google に追跡して報告できます。Spanner Omni 商用ライセンス契約を遵守するには、次の手順を行います。

  1. 各請求期間の終了時に Spanner Omni 使用状況ツールを実行して、クラスタの vCPU 使用状況指標を収集します。

    spanner admin license report --row-format=CSV
    
  2. テクニカル アカウント マネージャー(TAM)または Google アカウント チームと連携して、組織の優先送信チャネルを確認します。

  3. 結果のペイロードを翌月の 5 日までに Google に送信します。

次のステップ