IBM Cloud Metrics Routing のアーキテクチャーとワークロードの分離について

以下の IBM Cloud Metrics Routing のサンプル・アーキテクチャーを確認し、さまざまな分離レベルを詳しく知って、クラウドで実行するワークロードの要件に最も適合するソリューションを選択できるようにします。

IBM Cloud Metrics Routing のアーキテクチャー

IBM Cloud Metrics Routing は IBM Cloud で利用できるマルチテナント型のリージョンのサービスです。 IBM Cloud Metrics Routingを使用すると、アカウント内のメトリックの収集とルーティングを管理できます。

以下の図に、IBM Cloud Metrics Routingの高レベル・アーキテクチャを示します：

サンプルのIBM Cloud Metrics Routing IBM Cloud Metrics Routing } アーキテクチャを示す図。 — IBM Cloud Metrics Routingサンプルアーキテクチャ

IBM Cloud Metrics Routing は、リージョンごとにデプロイして管理します。サポート対象リージョンのリストを参照してください。各リージョンでは、可用性を確保するために、物理的に分離している 3 つのデータ・センターでこのサービスが実行されます。各サービス・デプロイメントのすべてのデータと構成は、そのデプロイメントをホストしているリージョン内に保存されます。

IBM Cloud Metrics Routingを使用できます。CLI、IBM Cloud Metrics RoutingAPIAPI、IBM Cloud Metrics Routingがあります。Terraformを使用して、アカウント内のサービスを管理します。

IBM Cloud Metrics Routing設定を構成して、アカウント内でメトリックをグローバルに管理する方法を定義できます。プライベートエンドポイントのみを使用するかどうか、サービスの実行に必要なメタデータの場所、運用するリージョンにルールを設定していない場合のデフォルトの宛先などを構成できます。

アカウント内のメトリックを管理する方法を定義するリソースを構成する前に、 Primary metadata region を定義する必要があります。 Primary metadata region アカウントとリソースに関するメタデータが保存される場所を定義します。オプションで Backup metadata region を設定できます。メタデータには、ルーティングルール、アカウント内のメトリックの管理方法を定義するアカウント設定、およびデータを送信先に送信するために必要な資格情報などのターゲットの詳細に関する情報が含まれます。設定定義は、メトリックを宛先にルーティングするためにIBM Cloud Metrics Routingサービスによって使用されるアカウント値を定義するグローバルリソースです。

プライマリメタデータリージョンを構成した後、1 つ以上のターゲットと 1 つ以上のルートを作成する必要があります。

ターゲットは、メトリックをルーティングし、さらに分析するために保存する宛先を定義します。ターゲットリソース定義はリージョンリソースです。ただし、運用上の目的で、ターゲットの詳細の一部はアカウントのプライマリメタデータとバックアップメタデータの場所に必要な場合があります。
ルートは、アカウント全体のメトリックを宛先 (ターゲット) にルーティングする方法に関するルールを定義します。ルートリソース定義は、スコープがリージョンを超える可能性があるルールを定義するグローバルリソースです。

アカウントでは、メトリクスを有効にするための追加設定が必要な一部のサービスを除き、アカウント内で実行されるIBM Cloudサービスからメトリクスが自動的に収集されます。メトリックを生成するサービスの詳細については、「クラウドサービス」を参照してください。

アカウントでIBM Cloud Metrics Routingを構成すると、メトリックは選択したターゲットにルーティングされます。ターゲットリソース内のメトリックを管理する責任があります。

IBM Cloud Metrics Routingサービスの展開に必要なすべてのデータと構成は、それがホストされているリージョン内に保持されます。

アカウント内のIBM Cloud Metrics Routingのメタデータは、プライマリメタデータの場所とバックアップメタデータの場所でホストされます。プライマリリージョンとバックアップリージョンを選択します。 IBM Cloud Metrics Routingが利用可能な場所であれば、任意の場所を選択できます。

1 つ以上の宛先にルーティングするメトリックは、構成によって同じリージョン内の宛先に送信される場合、生成された同じリージョンに留まります。ただし、他のリージョンからメトリックを収集する宛先や、別のIBM Cloudアカウントの宛先がある場合もあります。これらのシナリオでは、メトリックは複数の地域やアカウントにまたがって適用されます。 IBM Cloud Metrics Routingサービス構成では、メトリックデータがルーティングされる場所を定義します。

IBM Cloud Metrics Routing とその依存関係の間のすべてのお客様データのフローでは、プライベート・ネットワーク接続が使用されます。プライベート接続の詳細については、「サービスエンドポイントを使用しIBM Cloud Metrics Routingにプライベートに接続する」てを参照してください。

接続

プライベート・エンドポイントとパブリック・エンドポイントを使用して、アカウント内の IBM Cloud Metrics Routing リソースを構成することができます。

プライベート接続

プライベート・エンドポイントを無効にすることはできません。

パブリック接続

IBM Cloud Metrics Routingのパブリック・エンドポイントを無効にすることもできます。

詳細については、「プライベートエンドポイントを適用してリソースを構成するIBM Cloud Metrics Routing を参照してください。

さまざまな IBM Cloud サービスとの依存関係

IBM Cloud がパブリック接続またはプライベート接続を経由して接続する IBM Cloud Metrics Routing サービスについて確認します。

IBM Cloud Metrics Routingは他のIBM Cloudサービスに依存します。
最初の列はサービスです。 2 番目の列は、サービスの説明です。
サービス名	説明
IBM Cloud Internet Services	IBM Cloud Internet Servicesは、DNSとロードバランシング機能のプロバイダとして使用されます。
IBM Cloud Kubernetes Service	IBM Cloud Metrics Routing はサービス実行のために IBM Cloud Kubernetes Service を使用します。
IBM Cloud Monitoring	IBM Cloud Metrics Routing はプライベート接続を使用して Monitoring と統合し、プラットフォーム・メトリックを送信します。詳細については、IBM Cloud Metrics Routingのメトリクスを監視するを参照してください。
IBM Cloud プラットフォーム	サービスに対する要求を認証し、ユーザー・アクションを許可するため、IBM Cloud Metrics Routing は Cloud Identity and Access Management (IAM) でのプラットフォームとサービスのアクセス役割を実装します。サービスを扱うために必要な IAM アクセス許可について詳しくは、IBM Cloud Metrics Routing のアクセス管理を参照してください。 IBM Cloud Metrics Routing から IAM への接続はプライベート接続を使用しません。
IBM Cloud Databases for PostgreSQL	IBM Cloud Metrics Routingはメタデータを保存するためにIBM Cloud Databases for PostgreSQLを使用します。
Key Protect	IBM® Key Protect for IBM Cloud®サービスの操作に必要な暗号化されたキーを保存するために使用されます。これには Bring Your Own Key (BYOK) は含まれません。

ワークロードの分離

各リージョン・デプロイメントは、IBM Cloud のアカウント ID によって識別される複数のテナントを扱います。

リージョン内のユーザー・ワークロードの実行を担当するデプロイメントが、リージョンごとに 1 つあります。
そのデプロイメントは、リージョン内で可用性が高い仕様になっています。
収集されるデータは IBM Cloud のアカウント ID に関連付けられ、この関連付けによって他のユーザーには表示されなくなります。
すべてのテナントのデータは同じデータ・ストアに配置されますが、テナント固有の IBM Cloud アカウント ID によってセグメント化されるので、アクセス制御ポリシーの実施が可能になっています。
Cloud Identity and Access Management (IAM) を使用して、どのユーザーがリソースを表示、作成、使用、管理できるかを制御できます。