MicroStrategy ONE

Platform Analytics のアーキテクチャ例

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

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

この構成では、すべての Platform Analytics コンポーネントが同じマシンにインストールされています。すべての Library および Intelligence Server 環境 (シングル ノードまたはクラスター) は、同じ Telemetry Server ノードでデータを生成するように構成されている必要があります。プラットフォームアナリティクスウェアハウスは、すぐに使えるMicroStrategy リポジトリ。

これは、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 ノード

テレメトリ サーバー ノードないインテリジェンス サーバー ノードと同じマシン上