デプロイメントモデル
VeloDB Cloudウェアハウスには、コンピュートクラスター、メタデータ、およびデータストレージが含まれます。組織は複数のウェアハウスを持つことができ、各ウェアハウスのリソースとデータは他から分離されています。
VeloDB Cloudは2つのデプロイメントモデルを提供します。開始するために1つを選択してください:
| モデル | 実行場所 | 開始方法 |
|---|---|---|
| SaaS | VeloDBのインフラストラクチャ | SaaSウェアハウスを作成 |
| BYOC | 独自のクラウドVPC | BYOCウェアハウスを作成 |
どちらが適しているかわからない場合は、どのモデルを選択すべきか?にお進みください。
SaaSウェアハウス
SaaSウェアハウスは、VeloDB Cloudが提供・運用するインフラストラクチャ上で完全に動作します。すぐに使用でき、管理するインフラストラクチャはありません。
無料トライアルでは、組織に30日間有効な300ドルのクレジットが提供されます。
注記
- トライアルウェアハウスが7日以上停止したままの場合、システムが自動的にクリーンアップします。その後も評価を続けるには、新しいウェアハウスを作成してください。
製品アーキテクチャ

SaaSウェアハウスは、VeloDB独自のVPC内で完全に動作します。プライベート接続または提供されるパブリックエンドポイント経由でアクセスできます。
作成方法については、SaaSウェアハウスの作成を参照してください。
BYOCウェアハウス
BYOC(Bring Your Own Cloud)ウェアハウスは、独自のクラウドアカウント内でVeloDB Cloudサービスを実行します。コンピュートクラスターを開始すると、仮想マシンがVPC(Virtual Private Cloud)内で起動し、クラウドプロバイダーから直接請求されます。また、VeloDBに使用量ベースのサービス料金を支払います。
製品アーキテクチャ

BYOCウェアハウスは、VPC内に制御Agent、およびモニタリングとログ記録コンポーネントをインストールします。Agentはプライベート接続(PrivateLink)を介してVeloDB Cloudからコマンドを取得し、クラスターの作成、スケーリング、およびアップグレードを実行します。
Agentのコードはオープンで監査可能なため、データがVPC内に留まり、外部に出ることがないことを確認できます。
AWSでは、BYOC全体がEC2上で実行されます。Kubernetesやコンテナプラットフォーム(EKSなど)は使用されません。デプロイメントは、接続ロードバランサー、高可用性設定で動作するコンピュートクラスターVM、EC2インスタンス上の制御Agent、およびVeloDB Cloudサービスへのプライベートアクセス用の**VPCインターフェースエンドポイント(PrivateLink)**で構成されます。このスタックをプロビジョニングするCloudFormationテンプレートはオープンで、独自のアカウントで実行されます。完全なリソースリストについては、Template Modeを参照してください。
作成方法については、BYOCウェアハウスの作成を参照してください。
並行比較
エンジンとマネージド体験は両方のモデルで同じです。モデルは、インフラストラクチャが実行される場所と、その場所が可能にすることで異なります:
| 項目 | SaaS | BYOC |
|---|---|---|
| インフラストラクチャとデータの場所 | VeloDBのクラウドアカウント | 独自のクラウドアカウントとVPC |
| ウェアハウス作成 | 数分 | より長時間、アカウント内でリソースをプロビジョニング |
| ウェアハウスへのクライアントアクセス | Public LinkまたはPrivateLink | VPCネットワーク |
| データソース(RDS、Kafka、自己管理データベース、外部カタログ)へのアクセス | PrivateLink経由(データ転送料金が適用)またはパブリックエンドポイント | VPC内で直接 |
| UDF(Java、Python) | — | ✓ |
| Arrow Flight SQL | VeloDBサポートへのリクエスト | ✓ 推奨 |
| Sparkコネクター | — | ✓ |
| 保存時暗号化 | TDE、顧客管理キー | TDEとEBS暗号化、独自のKMSキー |
| 課金 | 使用量ベース | クラウドコストとサービス料金 |
| リモートサポートアクセス | 標準運用アクセス | 時間制限、承認ゲート付き |
どのモデルを選択すべきか?
SaaSはBYOCよりも管理が簡単なため、ワークロードでBYOCが提供する機能が必要でない限り、SaaSから開始してください。
以下の場合はSaaSを選択してください:
- 完全マネージドサービスが必要で、インフラストラクチャ、リソース管理、権限に時間を費やしたくない場合
- クラウドプロバイダーからの割引がほとんどまたは全くない場合。その場合、SaaSは通常、総合的にコストが低くなります
以下の場合はBYOCを選択してください:
- コンプライアンスでデータを独自のクラウドアカウント内に保持する必要がある場合。両方のモデルとも業界コンプライアンス基準を満たしますが、BYOCのみがデータをアカウント内に保持します
- クラウドプロバイダーから大幅な割引を受けている場合。BYOCコンピューティングはプロバイダーから直接請求されます
- ワークロードがSparkコネクターやArrow Flight SQLに依存している場合
- VPC内のRDSやKafkaなどのデータソースとウェアハウス間で大量のデータを移動するワークロードがある場合。SaaSでは、これらのソースにはPrivateLink経由でアクセスし、データ転送料金が追加されます。S3経由でデータをステージングすることで料金を回避できますが、継続的な大量転送にはBYOCがより適しています
BYOCは独自の環境で実行されるため、ネットワーク計画やロードバランシングを含むクラウドの実用的な知識が必要です。