メインコンテンツまでスキップ
メインコンテンツまでスキップ

新しいプランへの移行

新しいプランの選択​

新しく作成された組織は古い（レガシー）プランでサービスを開始できますか？​

いいえ、新しく作成された組織は発表後に古いプランへのアクセスを持ちません。

ユーザーは新しい価格プランにセルフサービスで移行できますか？​

はい、以下にセルフサービス移行のガイダンスがあります：

現行プラン新プランセルフサービス移行
開発基本組織内のすべてのサービスが開発をサポートしている場合にサポート
開発スケール（2レプリカ以上）✅
開発エンタープライズ（2レプリカ以上）✅
本番スケール（3レプリカ以上）✅
本番エンタープライズ（3レプリカ以上）✅
専用サポートにお問い合わせください

開発および本番サービスを試用中のユーザーはどのような体験をしますか？​

ユーザーは試用中にアップグレードし、新しいサービス階層とそれがサポートする機能を評価するために試用クレジットを引き続き使用できます。ただし、同じ開発および本番サービスを引き続き使用することを選択した場合、PAYGにアップグレードできます。2025年7月23日前に移行する必要があります。

ユーザーは階層をアップグレードできますか？たとえば、基本 → スケール、スケール → エンタープライズなど？​

はい、ユーザーはセルフサービスでアップグレードでき、アップグレード後の価格は階層の選択を反映します。

ユーザーは高コスト階層から低コスト階層に移動できますか？たとえば、エンタープライズ → スケール、スケール → 基本、エンタープライズ → 基本のセルフサービスなど？​

いいえ、階層のダウングレードは許可されていません。

組織内に開発サービスのみがあるユーザーは基本階層に移行できますか？​

はい、これは許可されます。ユーザーには過去の使用に基づいて推奨が与えられ、基本 1x8GiB または 1x12GiB を選択できます。

同じ組織内に開発と本番サービスがあるユーザーは基本階層に移動できますか？​

いいえ、ユーザーが同じ組織に開発と本番サービスの両方を持っている場合、セルフサービスでスケールまたはエンタープライズ階層にのみ移行できます。基本に移行したい場合、すべての既存の本番サービスを削除する必要があります。

我々は、コンピュートレプリカ用の新しい垂直スケーリングメカニズムを導入します。これを「Make Before Break」（MBB）と呼びます。このアプローチでは、古いレプリカを削除する前に新しいサイズのレプリカを1つ以上追加し、スケーリング操作中に容量の損失を防ぎます。既存のレプリカの削除と新しいレプリカの追加の間のギャップを解消することで、MBBはよりシームレスで中断の少ないスケーリングプロセスを実現します。リソースの高い使用率が追加の容量を必要とするスケールアップシナリオでは、レプリカを前もって削除することはリソース制約を悪化させるだけなので、特に有益です。

この変更の一環として、過去のシステムテーブルデータはスケーリングイベントの一部として最大30日間保持されます。さらに、AWSまたはGCPでのサービスに関しては2024年12月19日以前のシステムテーブルデータ、Azureでのサービスに関しては2025年1月14日以前のデータは新しい組織階層への移行の一部として保持されません。

コストの推定​

ユーザーは移行中にどのようにガイドされ、自分のニーズに最適な階層を理解しますか？​

コンソールは、サービスがある場合に過去の使用に基づいて各サービスの推奨オプションを提示します。新しいユーザーは、詳細に記載された機能と機能を確認し、自分のニーズに最適な階層を決定できます。

ユーザーは新しい価格で「ウェアハウス」をどのようにサイズ設定し、コストを推定しますか？​

Pricing ページにある価格計算機を参照してください。これにより、ワークロードのサイズと階層選択に基づいてコストを推定できます。

移行の実施​

移行を実施するためのサービスバージョンの前提条件は何ですか？​

サービスはバージョン24.8以降であり、SharedMergeTreeに移行されている必要があります。

現行の開発および本番サービスのユーザーの移行体験はどのようなものですか？ユーザーはサービスが利用できないメンテナンスウィンドウを計画する必要がありますか？​

開発および本番サービスを新しい価格階層に移行する際、サーバーの再起動がトリガーされる可能性があります。専用サービスを移行するには、サポートにお問い合わせください。

移行後、ユーザーが取るべき他のアクションは何ですか？​

APIアクセスパターンは異なります。

新しいサービスを作成するためにOpenAPIを使用するユーザーは、サービス作成のPOSTリクエストからtierフィールドを削除する必要があります。

tierフィールドはサービスオブジェクトから削除され、もはやサービス階層は存在しません。
これはPOST、GET、およびPATCHサービスリクエストによって返されるオブジェクトに影響を及ぼします。したがって、これらのAPIを消費するコードは、これらの変更を処理するように調整する必要があります。

各サービスは、スケールおよびエンタープライズ階層でのデフォルトのレプリカ数は3、基本階層では1です。
スケールおよびエンタープライズ階層では、サービス作成リクエストでnumReplicasフィールドを渡すことにより調整できます。
ウェアハウス内の最初のサービスのnumReplicasフィールドの値は2から20の範囲内である必要があります。既存のウェアハウス内で作成されたサービスは、最低1のレプリカ数を持つことができます。

自動化のために既存のTerraformプロバイダーを使用している場合、ユーザーはどのような変更を行う必要がありますか？​

組織が新しいプランのいずれかに移行した後、ユーザーはTerraformプロバイダーのバージョン2.0.0以上を使用する必要があります。

新しいTerraformプロバイダーは、サービスのtier属性の変更を処理するために必要です。

移行後、tierフィールドは受け付けられなくなりますので、これへの参照は削除する必要があります。

ユーザーはサービスリソースのプロパティとしてnum_replicasフィールドを指定できるようになります。

各サービスは、スケールおよびエンタープライズ階層でのデフォルトのレプリカ数は3、基本階層では1です。
スケールおよびエンタープライズ階層では、サービス作成リクエストでnumReplicasフィールドを渡すことで調整できます。
ウェアハウス内の最初のサービスのnum_replicasフィールドの値は2から20の範囲内である必要があります。既存のウェアハウス内で作成されたサービスは、最低1のレプリカ数を持つことができます。

ユーザーはデータベースアクセスに変更を加える必要がありますか？​

いいえ、データベースのユーザー名/パスワードは以前と同じように機能します。

ユーザーはプライベートネットワーキング機能を再構成する必要がありますか？​

いいえ、ユーザーは本番サービスをスケールまたはエンタープライズに移動した後、既存のプライベートネットワーキング（プライベートリンク、PSCなど）構成を使用できます。