OpenStore は、Alibaba Cloud Elasticsearch チームがログ分析シナリオ向けに開発した、弾力性が高く、効率的でコスト効率に優れたログストレージエンジンです。実際のデータ使用量に基づく従量課金のサーバーレスストレージを提供し、事前にストレージ容量をプロビジョニングする必要がありません。OpenStore は従来のホット/コールドデータ分離を超え、データインジェストを簡素化し、大規模なクラウドデータのストレージコストをさらに削減します。
この機能は、中国 (香港) を含む特定のリージョンで利用できます。
背景情報
ログ分析やオブザーバビリティシナリオでは、ビジネス要件や規制要件により、アーカイブや監査のために長期間のデータ保持が求められることがよくあります。オープンソースの Elasticsearch では、通常、ホット/コールドデータ分離が行われます。30 日を超えるデータは、クラスターのスナップショットを使用して OSS などの他のストレージメディアに移動されることが一般的です。このアプローチは長期アーカイブには有効ですが、アーカイブされたデータを直接クエリすることはできません。クエリを実行するには、まずスナップショットをクラスターに復元し、インデックスの初期化を待つ必要があり、これは複雑なうえ、長期的なストレージコストを増加させます。
OpenStore は、Alibaba Cloud Elasticsearch 7.10 カーネル強化版の主要機能です。マネージド型のインデックスサービスと組み合わせることで、ログ分析のための低コストで高同時実行性の書き込みと長期データ保持をサポートします。7.10 カーネル強化版クラスターをオンデマンドで作成し、OpenStore 機能を有効にすることができます。
-
クラスターの 基本情報 ページの ノード可視化 セクションで、OpenStore が有効になっているかどうかを確認し、そのストレージ情報を表示できます。詳細については、「クラスターのステータスとノード情報を表示する」をご参照ください。
-
OpenStore とインデックスサービスが有効になっているクラスターの場合、基盤のストレージサービスが高いデータ可用性を保証します。そのため、自動スナップショット機能はサポートされていません。
利点
-
大容量ストレージ:OpenStore は、従量課金のサーバーレスストレージモデルを採用しており、事前の容量計画が不要です。実際の使用量に基づいて時間単位で課金され、ストレージ使用率 100% を実現します。
-
低コスト:データはリアルタイムで変更および更新できます。自動データ階層化により、複雑なインデックスライフサイクル設定が不要になり、初期セットアップが簡素化されます。ストレージコストは、ローカル SATA ディスクと比較して最大 60%、Ultra ディスクと比較して約 60% 削減されます。
-
高可用性:コンピューティングとストレージの分離アーキテクチャにより、複数のレプリカが追加コストなしで単一のデータコピーを共有できます。基盤のストレージサービスは高いデータ可用性を保証し、最大 99.9999999999% (12 ナイン) の耐久性を提供します。
-
クエリパフォーマンスの向上:一般的なログ分析のクエリおよび分析タスクにおいて、パフォーマンスはローカル SATA ディスクと比較して 100% 向上し、Ultra ディスクや PL0 ESSD に匹敵します。
制限事項
OpenStore の購入および使用時には、以下の制限事項が適用されます。
|
カテゴリ |
説明 |
|
リージョン |
OpenStore は、以下のリージョンでのみ利用できます:実際に利用可能なリージョンは、購入ページに表示されます。
|
|
クラスターバージョン |
Elasticsearch 7.10 カーネル強化版クラスターのみが OpenStore をサポートします。 |
|
クラスター仕様 |
OpenStore では、以下のストレージ最適化仕様のみサポートされます:8 コア 64 GB および 16 コア 64 GB。 |
|
クラスターストレージ容量 |
ノードあたりの最大ストレージ容量は 30 TB です。 説明
ノードあたりのストレージ容量を増やす必要がある場合は、チケットを送信して、最大 50 TB まで申請できます。 |
|
シャードレプリカの数 |
OpenStore を有効にする場合、シャードあたり少なくとも 1 つのレプリカを設定する必要があります。 警告
複数のレプリカは、追加のストレージコストなしで単一のデータコピーを共有します。レプリカは、ローカルストレージの書き込み高速化の信頼性を保証します。レプリカを設定しない場合、最近書き込まれたデータが失われ、復元できない可能性があります。 |
|
インデックステンプレート |
説明
OpenStore インデックスを手動で削除するには、インデックスとそれに対応するエイリアスの両方を削除する必要があります。 |
|
インデックスライフサイクル設定 |
インデックスライフサイクルでの |
|
クエリ制限 |
|
|
クラスターシャード制限 |
クラスターあたり 80,000 シャード未満を推奨します。 |
|
ノードシャード制限 |
ノードあたり 3,000 シャード未満を推奨します。 |
|
シャードあたりのサイズ |
シャードあたり 40 GB 未満を推奨します。 |
|
データディスク書き込みスループット |
データディスク使用率が 85% 未満の場合は 300 MB/s。 データディスク使用率が 85% 以上の場合は 100 MB/s。 |
ユースケース
OpenStore は、ログ検索やメトリクス分析など、大量のデータを長期間書き込んで保存する必要があるシナリオに最適です。クエリ QPS が低く、クエリレイテンシーに対する許容度が高いワークロードに最も適しています。
インテリジェントハイブリッドストレージエンジンは、厳密なホット/コールドデータ分離を必要とせず、リアルタイムのデータ更新が必要なビジネスシナリオにも適しています。
ハイブリッドストレージアーキテクチャ

このアーキテクチャには、以下の利点があります。
-
コンピューティングとストレージの分離:従来のホット/コールドデータ分離アーキテクチャとは異なり、この設計ではコンピューティングリソースとストレージリソースがさらに分離されています。ストレージ容量を管理する必要がなくなります。このアーキテクチャは、弾力性のある従量課金ストレージを提供し、クラウドネイティブの原則を活用してクラスターのスケーラビリティを向上させます。インデックスの移行と復元を大幅に高速化し、大規模データシナリオに最適です。
-
使いやすさ:完全に自動化されたインデックスライフサイクル管理により、シンプルなライフサイクルポリシーを設定するだけで済みます。エンジンがホット/コールドデータ分離を管理し、データを OpenStore に自動的に移行します。
-
データ整合性:OpenStore は、Raft ベースのコンセンサスプロトコルを使用して、ストレージメディア間のデータ整合性を保証します。ユーザーの介入なしにデータ階層化とキャッシュアクセラレーションを自動的に処理し、リアルタイムのデータ更新をサポートします。
パフォーマンステスト
-
テスト環境
-
データセット:一般的なログ分析シナリオのデータセット。
-
クラスター仕様:比較に使用したクラスターは同じ構成で、ログ分析用に最適化されています。
-
ノード数:10
-
シャード数:108
-
-
クエリ条件:
-
クエリタイプ:sort
-
ドキュメント数:3,800,000,000
-
-
-
テスト結果
ストレージタイプ
クエリ時間
ローカル SATA ディスク
30 秒超
Ultra ディスク
12.229 秒
OpenStore
15.841 秒
-
テストの結論
同じクラスター構成において、OpenStore でのログデータのクエリレイテンシーは、ローカル SATA ディスクと比較して大幅に低く、Ultra ディスクに匹敵します。OpenStore は、Ultra ディスクと比較して単位あたり約 60% 安価で、従量課金を採用しているため、事前の容量購入が不要です。
関連メトリクス
|
メトリクス |
値 |
|
アクセスレイテンシー (ローカルキャッシュヒット) |
0.2 ms |
|
アクセスレイテンシー (ローカルキャッシュミス) |
50 ms ~ 400 ms |
|
アクセススループット (ローカルキャッシュヒット) |
1 GB/s |
|
アクセススループット (ローカルキャッシュミス) |
750 MB/s |
|
ユースケース |
監視ログ、履歴注文、アーカイブデータなど、アクセス頻度の低いデータ |