MicroStrategy ONE

Platform Analytics のアーキテクチャ例

以下にいくつか例を示しますが、サポートされるアーキテクチャを包括的に示しているわけではありません。アーキテクチャに関するベスト プラクティスと留意事項で説明した、全般的な留意事項やベスト プラクティスに沿って例示します。

すべての Platform Analytics コンポーネントのシングル ノード

この構成では、すべての Platform Analytics コンポーネントが同じマシンにインストールされています。すべての Library および Intelligence Server 環境 (シングル ノードまたはクラスター) は、同じ Telemetry Server ノードでデータを生成するように構成されている必要があります。Platform Analytics Warehouse は、すぐに利用できる MicroStrategy Repository で表されます。

これは、Platform Analytics の最もシンプルな表現の 1 つで、すべてのコンポーネントが 1 台のマシン (上記の例ではマシン 4) にインストールされます。

リモート Platform Analytics Warehouse

このアーキテクチャでは、Platform Analytics Warehouse を除くすべての Platform Analytics コンポーネントが同じマシン上にあります。すぐに利用できる MicroStrategy Repository を選択することも、PostgreSQL の独自インスタンスをプロビジョニングすることも可能です。

このアーキテクチャが自分に合っているかどうかを評価する方法:

  • Amazon RDS を使用する場合  Platform Analytics データに対する重度の読み取りクエリの使用事例がある場合、読み取りアクセス用のレプリカを簡単に設定できます。

  • RDS では、データベースの成長に合わせて、将来的にシステム リソースを簡単に増やすことができるオプションが用意されています。

  • RDS または自己管理型の PostgreSQL を使用している場合、システム リソースの管理やキャパシティ プランニングが簡単になります。

高スループット/詳細アーキテクチャ

利点が大きい反面、構成や保守の要件も高いため、高スループット アーキテクチャは慎重に検討する必要があります。

通常、この方法は以下のような場合に検討します。

  1. Intelligence Server ノードが多く、テレメトリーが大量にある (オブジェクト数、ユーザー数、ジョブ数が多い)。

  2. アーキテクチャの高可用性が要求される。

高スループットのアーキテクチャでは、Telemetry Server ノードのクラスターの使用を推奨します。1 つの Telemetry Store は、1 つの Telemetry Server ノードまたは Telemetry Server クラスターからのデータを使用できます。これは、すべての Telemetry Server ノードが単一のクラスターにあることを意味します。

現在、Telemetry Server は Zookeeper コンポーネントと Kafka コンポーネントで表現されています。Telemetry Server はノードのサブセットにインストールできます。唯一の要件は、奇数個 (3 個、5 個など) の Telemetry Server ノードを維持することです。詳細は、Zookeeper のドキュメントを参照してください。複数の Telemetry Server クラスターはサポートされていません。

Intelligence Server ノードと同じマシンの Telemetry Server ノード

Intelligence Server ノードと同じマシンにない Telemetry Server ノード