Azure HorizonDB (プレビュー) とは

Azure HorizonDB は、PostgreSQL 上に構築されたクラウド ネイティブのフル マネージドの AI 対応データベース サービスです。 分離されたコンピューティングおよびストレージ アーキテクチャとログとしてのデータベース設計を組み合わせて、予測可能なパフォーマンス、エンタープライズ レベルのセキュリティ、高可用性、ミッション クリティカルなワークロードのシームレスなスケーラビリティを実現します。

Azure HorizonDB を使用すると、開発者はベクター埋め込みと Azure AI Foundry Tools との統合のネイティブ サポートを通じてインテリジェントな AI を利用したアプリケーションを構築でき、既存のアプリケーションが Azure HorizonDB に簡単に移行できるように、PostgreSQL の完全な互換性を維持できます。

Azure HorizonDB のユース ケース

Azure HorizonDB は、自己管理 PostgreSQL に代わるクラウド ネイティブのスケーラブルな代替手段であり、以下に限定されず、以下を含むミッション クリティカルなワークロード向けに設計されています。

  • トランザクション ワークロード (OLTP) - 基幹業務アプリケーション、eコマース プラットフォーム、SaaS バックエンドの予測可能なパフォーマンスを備えた、高スループットで待機時間の短いトランザクション処理。
  • AI とインテリジェント なアプリケーション - ネイティブ ベクター検索と埋め込みのサポートにより、取得拡張生成 (RAG) パイプライン、レコメンデーション エンジン、セマンティック検索をデータベース レイヤー内に直接構築できます。 AI モデル管理と AI パイプラインにより、データベース内でのインテリジェントなアプリケーションの構築がさらに簡略化されます。
  • 大量の読み取りスケールアウト - 共有ゾーンの回復性のあるデータを使用して読み取りスケールアウトを利用できるアプリケーション。
  • ハイブリッド アプリケーション - Azure エコシステムとの統合、トランザクション データの Fabric OneLake へのミラーリング、他の分析データとの統合。

Azure HorizonDB のアーキテクチャ

Azure HorizonDB は、コンピューティングとストレージの分離と、ログとしてのデータベース設計という 2 つの基本的なアーキテクチャ原則に基づいて構築されています。

Azure HorizonDB アーキテクチャを示すDiagram.

非集計コンピューティングとストレージ

アーキテクチャでは、コンピューティング レイヤーとストレージ レイヤーが完全に分離されます。

  • Compute layer - Azure HorizonDB でのコンピューティングはステートレスです。 コンピューティング リソース (仮想コアとメモリ) は、ストレージに影響を与えずに個別にスケーリングでき、その逆も可能です。 HorizonDB クラスターにレプリカを追加することで、読み取りを水平方向にスケールアウトできます。
  • Storage レイヤー - ストレージ層は、2 つの専用ストレージ フリートを使用します。1 つは WAL 専用、もう 1 つはデータ専用です。両方とも、Azure ストレージによって支えられた持続性を持っています。 既定では、すべてのストレージはゾーン回復性があります。 ストレージは、プロビジョニングされたコンピューティング レベルとは関係なく、データの増加に合わせて自動的にスケーリングされます。

コンピューティングとストレージの分離には、いくつかの利点があります。

  • ワークロードの需要に基づいてコンピューティングとストレージを個別にスケーリングします。
  • 基盤となるストレージを共有し、データのレプリケーションが不要なため、読み取りレプリカを迅速にプロビジョニングできます。
  • 共有の永続的なWALストレージによりログの巻き戻し処理が不要になるため、高可用性を実現する高速なフェールオーバー。

ログとしてのデータベース アーキテクチャ

Azure HorizonDB はログとしてのデータベース アーキテクチャを採用しています。WAL (先に書き込むログ) のみがコンピューティングからストレージ レイヤーに書き込まれます。 データ ページは、コンピューティング レプリカからストレージ レイヤーに書き込まれません。 WALは、システムを通じて信頼できる真理の源です。

  • すべての書き込み (先に書き込むログ) は、クライアントに確認される前に永続的なログ サービスに追加されます。 WAL サービスは、トランザクション ログのセマンティクス用に最適化され、低待機時間用に最適化されています。
  • フィルター選択された WAL は、変更が属しているストレージ ノードにのみ送信されます。
  • ストレージ ノードは、WAL を適用してページの状態を再構築し、従来のチェックポイント I/O ボトルネックを排除します。
  • この方法により、書き込み増幅が減少し、データベース サイズに関係なく、一貫性のある予測可能な書き込み待機時間が実現されます。

これらの 2 つの原則を組み合わせることで、Azure HorizonDB は、ACID の完全な保証を維持しながら、高スループット、低待機時間、効率的なリソース使用率を実現できます。

クラスター

プロビジョニングされたAzure HorizonDB リソースはクラスターです。 Azure HorizonDB クラスターには次の内容があります。

  • 1 つ以上のコンピューティング レプリカ。1 つは書き込み可能なプライマリであり、残りは読み取り可能なスタンバイ レプリカです。
  • クラスター内のすべてのレプリカによって共有されるゾーン回復性ストレージ内のデータの 1 つのコピー。
  • 常にプライマリ レプリカを指す読み取り/書き込みエンドポイント。
  • 読み取り可能なすべてのレプリカへの接続を負荷分散する読み取り専用エンドポイント。

レプリカのコンピューティング

Azure HorizonDB コンピューティング レプリカは、プライマリ (書き込み可能) または読み取り可能なスタンバイ レプリカのいずれかですが、フェールオーバーの候補でもあります。 コンピューティング レプリカは、PostgreSQL リレーショナル エンジンが存在し、言語、クエリ、トランザクション処理が行われる場所です。 Azure HorizonDB クラスターとの対話はすべて、コンピューティング レプリカを介して行われます。 ゾーンの回復性を確保するには、クラスター上に少なくとも 2 つのレプリカが必要です。 ワークロードで必要に応じて、Azure HorizonDB クラスターにレプリカを追加または削除できます。

コンピューティング レプリカには、プロビジョニングされたコアあたり 8 GB のメモリが付属しています。 コンピューティング レプリカには、ローカル SSD キャッシュもあります。 このキャッシュは、ホット ページをキャッシュし、リモート ストレージ 層からデータをフェッチする必要性を最小限に抑える、待機時間の短い NVMe キャッシュです。 キャッシュは、すべてのレプリカ、プライマリ、スタンバイに存在します。

コンピューティング レプリカは、持続性と高可用性に関連するタスクをストレージ 層にオフロードする場合に効率的に使用されます。 このオフロードにより、データベース上でアプリケーションのビジネス ロジックを実行するための CPU、ディスク、ネットワークが増えます。 次のタスクは、コンピューティング レプリカからストレージ レイヤーにオフロードされます。

Task PostgreSQL プロセス リソースの節約
レプリカからの WAL 送信 walsender ディスク IO、ネットワーク IO
Blob ストレージへの WAL アーカイブ アーカイバー ディスク IO、ネットワーク IO
ダーティページの書き込み バックグラウンド ライター ディスク IO
チェックポイント機能 チェックポインター ディスク IO
Backups pg_dump、pg_basebackup、pg_backup_start、pg_backup_stop ディスク IO
ページ全体への書き込み WAL への書き込みを行うバックエンド ディスク IO
PostgreSQL WAL リカバリ 起動回復中 ディスク IO
PostgreSQL 読み取りレプリカの redo 起動回復中 ディスク IO

Storage

Azure HorizonDB は、Azure BLOB ストレージによってサポートされる 2 つのストレージ フリートを実行します。 ストレージ スタックのすべてのレイヤーは、既定でゾーン回復性があります。

WAL ストレージ

WAL サービスは、プライマリ コンピューティング レプリカから WAL を受け入れる専用のサービスであり、低待機時間と WAL 書き込みパターン用に最適化されています。 プライマリ レプリカでデータ変更 (挿入/更新/削除) が行われると、WAL サービスに WAL が書き込まれ、トランザクションが確認されます。 その後、最新の変更を反映するために、WAL がデータストレージ群上の各データシャードに非同期に適用されます。 さらに、WAL はセカンダリ コンピューティング レプリカに送信され、レプリカ上のメモリ内にあるページへの変更をやり直します。 その後、WAL は Azure Blob Storage にアーカイブされ、設定された短期保持期間だけ保持されます。

データ ストレージ

データ ストレージ フリートは、Azure HorizonDB クラスター内のすべてのコンピューティング レプリカにデータを提供する、データベース内のすべてのデータのキャッシュです。 ストレージは、ストレージ サイズや IOPS を構成する必要なく、データベースのサイズが増えるにつれて動的に割り当てられます。 postgres リレーションからのデータは、スケーラビリティを向上させるために、フリート内の複数のストレージ ノード間でシャード化されます。 耐障害性を確保するために、同じデータシャードの複数のコピーが複数のゾーンにまたがって保存されています。 WAL がストレージ フリートでリプレイされる際に、ストレージ フリートのダーティ ページは Azure Blob Storage に書き込まれます。

Azure Blob ストレージ

Azure Blob Storage は、データベース データの持続性を提供し、WAL アーカイブのデータ ストアとしても機能します。 データはゾーン冗長ストレージ アカウントに格納されます。 データベース バックアップは、BLOB のスナップショットとして実装されます。

価格

Azure HorizonDB では現在、次の料金が発生します。

  • プロビジョニング済みコンピューティング(コア時間)
  • 使用されたデータベース ストレージ (GB/月)、および
  • 短期間の保有期間にバックアップ ストレージを使用しました。

価格の詳細については、価格ページを参照してください

制限事項

HorizonDB Azureは現在、previewにあります。 次の機能はまだ使用できません。これらの機能に積極的に取り組んでいます。

特徴 地位 メモ
構成可能なバックアップ保有期間 まだ利用できません 現在、バックアップリテンション期間は 7 日間です。 1 ~ 35 日間のバックアップリテンション期間の有効化に取り組んでいます
リージョン間の読み取りレプリカ まだ利用できません ディザスター リカバリーのリージョン間レプリケーションはまだサポートされていません。
暗号化用のカスタマー マネージド キー (CMK) 該当なし 保存時の暗号化では、現在、サービスマネージド キーのみが使用されます。
構成可能なメンテナンス期間 まだ利用できません 現在、アップグレードはシステム管理メンテナンス期間に行われます。 カスタム メンテナンス期間を構成する機能はまだ使用できません
接続プール (PgBouncer) まだ利用できません サービスへのコネクションプーリング対応を進めている間は、外部のコネクションプーラーを使用できます。
長期保有 (LTR) 該当なし 現在、バックアップリテンション期間は 7 日間です。
インデックス チューニング まだ利用できません インデックスのチューニングは近日提供予定です。
仮想ネットワーク インジェクション 該当なし 現在、プライベート リンクがサポートされています。 仮想ネットワーク統合はまだサポートされていません

Note

この一覧にはサービスの現在の状態が反映されており、新機能がリリースされると変更される可能性があります。 最新の更新プログラムについては、 リリース ノート を確認してください。

Azureリージョン

Azure HorizonDB は現在、次のAzure リージョンで使用できます。

Geography リージョン
南北アメリカ カナダ中部、米国中部、米国東部、米国西部 2、米国西部 3
ヨーロッパ ドイツ中西部、スウェーデン中部
アジア太平洋 オーストラリア東部

Note

リージョンの可用性は変更される可能性があり、近日中にリージョンを追加する予定です。 一部のリージョンでは、新しいデプロイに制限がある場合があります。 最新のリージョンの可用性については、Azure ポータルを参照するか、Azure サポートにお問い合わせください。

フィードバックとサポート

Azure HorizonDB に関する質問や提案がある場合は、次のチャネルを通じてヘルプとサポートを受けることができます。