このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

第1章アーキテクチャと設計

Oracle Private Cloud Applianceへようこそ。この章では、独自のデータ・センター内にクラウド・サービスおよびアプリケーションを構築するためのOracleプラットフォームの概要について説明します。

1.1 Oracle Private Cloud Applianceの概要

Oracle Private Cloud Applianceは、オンプレミス・ネットワークのセキュアな環境内に包括的なクラウド・インフラ・サービス・スイートを提供するように設計されています。システムは、必要なすべてのハードウェアおよびソフトウェア・コンポーネントを統合し、Oracleエンジニアが最適なパフォーマンスを得るためにテスト、構成およびチューニングしています。基本的に、最も幅広いワークロードをサポートする、柔軟で汎用のIaaS (Infrastructure as a Service)ソリューションです。そのプラガブル・プラットフォームは、インフラストラクチャの上にPaaS (Platform as a Service)およびSaaS (Software as a Service)ソリューションをレイヤー化するための優れた基盤を提供します。

このリリースのOracle Private Cloud Applianceは、Oracleパブリック・クラウド・ソリューションOracle Cloud InfrastructureとのAPI互換性を提供します。 Oracle Cloud Infrastructureと同じメソッド、ツールおよびインタフェースを使用して、コアIaaSサービスにアクセスします。 Oracle Private Cloud Applianceのインストールは、顧客リージョンを表します。ワークロードはプライベート・クラウド環境とパブリック・クラウド環境間で移植可能ですが、プライベート・クラウドはOracle Cloud Infrastructureから切断されるため、互換性のあるサービスのセットをホストするために独自のコントロール・プレーン・コンポーネントを実行します。

Oracle Private Cloud Applianceは、エンジニアド・システムとして、最も高いビジネス継続性と保守性の要件に準拠しています。すべてのコンポーネントを監視し、潜在的な問題を検出し、アラートを送信し、サービス・リクエストを自動的に記録する機能があります。それ以降のトラブルシューティングおよび修復は、環境の稼働時間に影響を与えずに実行できます。

システムのアップグレードは、中断を最小限に抑え、可用性を最大化するためにも設計されています。ヘルス・チェックは、すべてのコンポーネントが許容可能な状態であることを確認するために、アップグレードの前に実行されます。アップグレード・プロセスはモジュール化されており、コンポーネントを使用できます - ファームウェア、オペレーティング・システム、コンテナ化されたサービス、システム・メイン・データベースなど - 個別にアップグレードするか、統合マルチ・コンポーネント・ワークフローとしてアップグレードします。

1.2 Oracle Cloud Infrastructureとの互換性

Oracle Private Cloud Applianceの主な目的は、独自のファイアウォールの背後にある独自のオンプレミス・ネットワークの安全性からコアOracle Cloud Infrastructureサービスを利用できるようにすることです。インフラストラクチャ・サービスは、PaaSおよびSaaSソリューションを構築するための基盤を提供します。デプロイされたワークロードは、最小限の変更または不要の変更で、パブリック・クラウド・インフラストラクチャとプライベート・クラウド・インフラストラクチャ間で移行できます。このため、Oracle Private Cloud Applianceは、Oracle Cloud InfrastructureとのAPI互換性を提供します。

ラック・スケール・システムとして、Oracle Private Cloud Applianceは、パブリック・クラウド設計の物理階層に沿った、Oracle Cloud Infrastructureの最小デプロイ可能ユニットとみなすことができます:

階層コンセプト	Oracle Cloud Infrastructure設計	Oracle Private Cloud Applianceマッピング
レルム	レルムは、リージョンのスーパーセットで、Oracleクラウドの最高の物理的下位区分です。レルム間フィーチャはありません。 Oracle Cloud Infrastructureは現在、商用リージョンのレルムとGovernment Cloudリージョンのレルムで構成されます。	レルムの概念はOracle Private Cloud Applianceにありますが、実用的な機能はありません。これにより、アプライアンスは任意のレルムに参加できます。
リージョン	リージョンは地理的な領域です。 Oracle Cloud Infrastructureリージョンは、少なくとも3つのアベイラビリティ・ドメインで構成されます。リージョン間でデータとリソースを移行またはレプリケートできます。	Oracle Private Cloud Applianceは、単一のリージョンとして設計されています。このプライベート・リージョンは他のシステムから切断されているため、実用的な機能はありません。かわりに、ドメイン構成で使用され、リージョンおよびレルムの値にマップされます。
可用性ドメイン	アベイラビリティ・ドメインは1つ以上のデータ・センターで構成されます。アベイラビリティ・ドメインは相互に分離され、独立した電力および冷却インフラストラクチャを持ち、内部ネットワーキングを分離しています。あるアベイラビリティ・ドメインでの障害が、他のドメインに影響する可能性が非常に低い。同じリージョン内のアベイラビリティ・ドメインは、暗号化されたネットワークを介して高帯域および低レイテンシで相互接続されます。これは、高可用性とディザスタ・リカバリを提供する際の重要なファクタです。	各Oracle Private Cloud Applianceは、可用性ドメインとして構成されます。複数のインストールが相互に独立している: 同じリージョン内のアベイラビリティ・ドメインとして機能しません。
フォルト・ドメイン	フォルト・ドメインは、アベイラビリティ・ドメイン内のインフラストラクチャ・コンポーネントをグループ化したものです。目的は、障害またはメンテナンスのためにダウンタイム・イベントを分離し、他のフォルト・ドメイン内のリソースが影響を受けないことを確認することです。各アベイラビリティ・ドメインに3つのフォルト・ドメインが含まれます。フォルト・ドメインはアンチ・アフィニティを提供: 同じ物理ハードウェアで実行されないようにインスタンスを分散する機能。	Oracle Private Cloud Applianceはパブリック・クラウド設計に準拠: 各アベイラビリティ・ドメインに3つのフォルト・ドメインが含まれます。フォルト・ドメインは、1つ以上の物理コンピュート・ノードに対応します。

Oracle Private Cloud Applianceは、Oracle Cloud Infrastructureの論理パーティション化とも一致します。アプライアンスのアンダー・レイ・ネットワークへのトンネリングとカプセル化によって相互に安全に分離される複数のテナンシをサポートします。テナンシは同じ物理ハードウェアでホストされますが、特定のテナンシに属するユーザーおよびリソースは、他のテナンシと対話できません。さらに、Compute Enclave - すべてのテナンシをまとめて参照し、その中に作成および管理されるクラウド・リソース - 、アプライアンス・インフラストラクチャが制御されるサービス・エンクレーブから論理的に分離されます。詳細は、第1.3項、「Enclaves and Interfaces」を参照してください。

Compute Enclaveインタフェースは、Oracle Cloud Infrastructureと同じ方法でアクセスできます。 CLIは同一ですが、ブラウザUIは実質的に同じユーザー・エクスペリエンスを提供します。 APIサポートも同一ですが、Oracle Private Cloud Applianceが提供するクラウド・サービスのサブセットに制限されます。

サポートされているAPIの一貫性は、パブリック・クラウド・プラットフォームとプライベート・クラウド・プラットフォーム間の互換性において重要なファクタです。これにより、コア・クラウド・サービスがリソースと構成も同様にサポートされます。具体的には、Oracle Private Cloud Applianceはネットワーキングとストレージに対して同じ論理構成をサポートし、同じ方法でユーザー・アイデンティティとアクセスを管理し、Oracle Cloud Infrastructureと同じコンピュート・シェイプとイメージをインスタンス・デプロイメントに提供します。そのため、プライベート・クラウド環境に設定されたワークロードはOracle Cloud Infrastructureに簡単に移植でき、その逆も同様です。ただし、プライベート・クラウド環境の切断された動作モードのため、ワークロードはオフラインで移行する必要があります。

1.3 エンクレーブとインタフェース

クラウド・ユーザーのパースペクティブから、Oracle Private Cloud Appliance Compute Enclaveは、Oracle Cloud Infrastructureに対して実質的に同じエクスペリエンスを提供します。ただし、アプライアンスでは、サービス・エンクレーブと呼ばれる独自の管理領域も実行されます。この項では、異なるユーザー・グループと、明確に異なるアクセス・プロファイルを持つ管理者を対象とした、エンクレーブとそのインタフェース間の境界について説明します。

1.3.1 囲み境界

「コンピュート・エンクレーブ」は、Oracle Cloud Infrastructureとの最大互換性のために意図的に設計されました。 Compute Enclaveのユーザーには、クラウド・リソースを作成および管理するための特定の権限があります。通常、これらの権限はグループ・メンバーシップに基づきます。 Compute Enclaveは、ワークロードが作成、構成およびホストされる場所です。ユーザーの処分における主要なビルディング・ブロックは、コンピュート・インスタンスと関連するネットワーク・リソースおよびストレージ・リソースです。

コンピュート・インスタンスは、事前構成済のオペレーティング・システムおよびオプションの追加ソフトウェアが含まれる「コンピュート・イメージ」から作成されます。コンピュート・インスタンスには、CPUやメモリーなどの仮想ハードウェア・リソースのテンプレートである特定の「シェイプ」があります。最小限の操作では、コンピュート・インスタンスにブート・ボリュームと仮想クラウド・ネットワーク(VCN)への接続が必要です。ワークロード用の仮想インフラストラクチャの構築を続けるにつれ、より多くのコンピュート・インスタンスの追加、プライベートおよびパブリック・ネットワーク・インタフェースの割当て、NFS共有またはオブジェクト・ストレージ・バケットの設定などを行うことができます。これらのリソースはすべて、Oracle Cloud Infrastructureと完全に互換性があり、プライベート・クラウド環境とパブリック・クラウド環境の間で移植できます。

「サービス・エンクレーブ」は、アプライアンス・インフラストラクチャが制御されるシステムの一部です。アクセスは厳密に監視され、特権管理者に制限されます。 3つの管理ノードのクラスタで実行されます。 Oracle Private Cloud Applianceは動作的にOracle Cloud Infrastructureから切断されているため、アプライアンスの設計およびスケールに固有の独自のコントロール・プレーンが必要です。 APIはOracle Private Cloud Applianceに固有であり、アクセスは厳密に制御されます。サービス・エンクレーブによって提供される機能には、ハードウェアおよび容量管理、サービス提供、サービスおよびサポート用のモニタリングおよびツールが含まれます。

両方のエンクレーブが互いに厳密に分離されています。各enclaveは、独自のインタフェース・セットを提供: web UI、CLI、およびエンクレーブごとのAPI。サービス・エンクレーブへのフル・アクセス権を持つ管理者アカウントには、Compute Enclaveでのすべての権限がありません。管理者は、初期アクセス用のプライマリ・ユーザー・アカウントを持つテナンシを作成しますが、テナンシのコンテンツおよびアクティビティに関する情報はありません。 Compute Enclaveのユーザーには、クラウド・リソースを使用、管理および作成する権限が付与されていますが、作業するテナンシや、仮想リソースが存在するハードウェアを制御することはできません。

1.3.2 アクセス・プロファイル

各エンクレーブには独自のインタフェースがあります。 Compute Enclaveにアクセスするには、Compute Web UIまたはOCI CLIを使用します。サービス・エンクレーブにアクセスするには、サービスWeb UIまたはサービスCLIのいずれかを使用します。アカウントのプロパティによって、実行が承認されている操作と、表示、管理または作成できるリソースが決まります。 web UIを使用する場合もCLIを使用する場合も、権限に関して違いはありません。すべての操作によって、エンクレーブの3番目の中央インタフェースへのリクエストが発生: API。サービスAPIまたはコンピュートAPIからの受信リクエストは、後でAPIサービスによって評価および認可または拒否されます。

ユーザーの様々なカテゴリが、異なる目的でアプライアンスと対話します。エンクレーブ・レベルでは、アプライアンス・インフラストラクチャの管理者と、一方の手のテナンシ内のクラウド・リソースを管理するユーザーを区別します。各エンクレーブには、異なる権限を提供する異なるアクセス・プロファイルが存在します。

サービス・エンクレーブでは、管理者の選択チームにのみフル・アクセス権を付与する必要があります。システムのモニタリング、容量計画、可用性、アップグレードなど、アクセスが制限されているその他の管理者ロールがあります。管理者ロールの詳細は、第3.1項、「管理者アクセス」を参照してください。サービスおよびサポート操作を実行するためにOracleがサービス・エンクレーブにアクセスするたびに、フル・アクセスを持つアカウントを使用する必要があります。

テナンシが作成されると、Compute Enclaveユーザー・アカウントが1つのみ含まれます: テナンシ管理者。テナンシ内のすべてのリソースへの完全なアクセス権を持ちます。実際には、テナンシへのアクセス権を持つすべての追加アカウントは、通常のCompute Enclaveユーザー・アカウントであり、グループ・メンバーシップおよびポリシー定義に応じて、より制限の少ない権限が与えられます。テナンシ管理者が、追加のユーザー・アカウントおよびユーザー・グループを設定し、リソース組織および管理戦略を定義し、その戦略を適用するポリシーを作成するタスクです。

リソース管理戦略が定義され、ユーザー、グループおよびコンパートメントの基本構成が存在すると、テナンシ管理者は、昇格された権限を持つ他のユーザーに責任を委任できます。管理者のグループが組織全体のリソースを管理できるようにする単純なポリシーを使用するか、より詳細なアプローチを使用するかを決定できます。たとえば、チームまたはプロジェクトごとにコンパートメント内のリソースを編成し、コンパートメント管理者がそのリソースを管理できるようにします。さらに、ネットワーク・リソースとストレージ・リソースをそれぞれネットワーク管理者とストレージ管理者によって制御される独自のコンパートメント内に格納しておくこともできます。 Identity and Access Managementサービスのポリシー・フレームワークには、リソースを編成し、リソースへのアクセスを制御するための様々なオプションが用意されています。詳細は、「Identity and Access Management概要」の章を参照してください。

APIと直接対話するスクリプトまたは自動化ツールを作成する場合は、開発者が認証および認可の原則と、完全分離を理解していることを確認してください。基本APIリファレンス・ドキュメントは、両方のエンクレーブで使用可能です。

API参照を表示するには、コンピュートWeb UIまたはサービスWeb UIのベースURLに/api-referenceを追加します。次に例を示します。

サービスWeb UIベースURL : https://adminconsole.myprivatecloud.example.com。

サービス・エンクレーブAPIリファレンス : https://adminconsole.myprivatecloud.example.com /api-reference。
コンピュートWeb UIベースURL : https://console.myprivatecloud.example.com。

Compute Enclave APIリファレンス : https://console.myprivatecloud.example.com /api-reference。

1.4 階層化されたアーキテクチャ

Oracle Private Cloud Applianceのアーキテクチャでは、階層化されたアプローチが使用されます。基本的には、コア・プラットフォームが構築されるハードウェア・コンポーネントです。これにより、異なるユーザー・グループに公開される管理および操作サービスのフレームワークが提供されます。レイヤーは統合されていますが、単体ではありません: これらは、互換性を維持しているかぎり、異なる速度でさらに開発できます。たとえば、新しいタイプのサーバー・ハードウェアをサポートしたり、ストレージ機能を拡張したりすることは、個別に適用したり、コントローラ・ソフトウェア・スタック全体を再デプロイしたりすることなく、拡張機能です。

1.4.1 ハードウェア層

ハードウェア層には、すべての物理システム・コンポーネントとそのファームウェアとオペレーティング・システムが含まれています。

3つの管理ノードは、コントローラ・ソフトウェアのベース環境を実行するクラスタを形成します。
コンピュート・ノードは、コンピュート・インスタンスをホストするための処理能力を提供します。
ストレージ・アプライアンスは、コンピュート・インスタンスによって使用されるストレージ・リソースのディスク領域を提供します。また、アプライアンスで内部的に操作するために必要なストレージ領域も提供されます。
ネットワーク・スイッチは、すべてのコンポーネントとアップリンク間の物理接続をパブリック(データセンター)ネットワークに提供します。

1.4.2 プラットフォーム・レイヤー

Oracle Private Cloud Applianceでは、サービス・ベースのデプロイメント・モデルを使用します。製品は、サービスとして実行される機能領域(それぞれ独自のコンテナ内)に分割されます。プラットフォームは、このモデルのベースを提供します。 Oracle Cloud Native Environmentの機能を活用して、管理ノード・クラスタは、イメージ・レジストリもホストするコンテナ化されたサービスのデプロイメントを編成します。

さらに、このプラットフォームは、他のすべてのサービスに必要な数多くの基本サービスを提供しています: メッセージ転送、シークレット管理、データベース・アクセス、ロギング、モニタリングなど。これらの基本的なサービスは、プラットフォーム上にデプロイされているすべてのサービスを同じ方法でそれらに接続できるように標準化されており、新しいサービス統合が簡単かつ高速になります。

また、このプラットフォームは、ハードウェア管理において中心的なロールを果たし、ハードウェア層とサービス間のデータ交換を管理します。ハードウェア・レイヤーに関する情報、およびそのレイヤーに加えた変更は、インベントリを最新の状態に保つためにサービス・レイヤーと通信する必要があります。サービス・レイヤーで操作を実行する場合は、コマンドをハードウェアに渡すためにインタフェースが必要です。この目的のために、プラットフォームには内部でのみ公開され、最高の権限を必要とする、緊密に保護されたAPIがあります。このAPIは、サーバーILOMやストレージ・コントローラなどの管理インタフェース、およびインベントリ・データベースやコンテナのオーケストレーション・ツールと対話します。

アプライアンス・アーキテクチャでのこのレイヤーの詳細は、第1.5項、「プラットフォーム・レイヤーの概要」を参照してください。

1.4.3 インフラストラクチャ・サービス・レイヤー

このレイヤーには、プラットフォーム上にデプロイされているすべてのサービスが含まれます。機能的に異なる2つのグループを形成: ユーザー・レベルのクラウド・サービスと管理サービス。

クラウド・サービスはクラウド環境のユーザーに機能を提供し、対応するOracle Cloud Infrastructureサービスへの操作によく似ています。 Compute Enclaveを構成しており、コンピュート・インスタンスおよび関連リソースを通じて顧客ワークロードをデプロイできます。クラウド・サービスには、コンピュートおよびストレージ・サービス、アイデンティティおよびアクセス管理、ネットワーキングが含まれます。

管理サービスは、アプライアンスの管理者に内部的に、または制限されています。これにより、クラウド・サービスの運用が可能になり、サポートが提供されます。サービス・エンクレーブを構成します。管理者操作には、システム初期化、コンピュート・ノードのプロビジョニング、容量拡張、テナンシ管理、アップグレードなどがあります。これらの操作は、Oracleがインフラストラクチャ管理者のロールを果たすOracle Cloud Infrastructureで外部化された同等のものではありません。

1.5 プラットフォーム・レイヤーの概要

Oracle Private Cloud Applianceアーキテクチャでは、プラットフォーム・レイヤーは、オンプレミス・クラウド・サービスの標準化されたインフラストラクチャを提供する部分です。ハードウェア・レイヤーを制御し、サービス・レイヤーを使用可能にし、セキュア・インタフェースを確立して、これらのレイヤーを統一的かつ一元的に操作できるようにします。インフラストラクチャ・サービス・レイヤーの共通コンポーネントと機能はプラットフォームに組み込まれているため、これらのマイクロサービスのデプロイメントを簡素化して迅速化できます。

1.5.1 基本的なサービス

オンプレミス・クラウド・サービスをデプロイするための基本インフラストラクチャの提供の中核的なロールを果たすために、プラットフォームは独自の基本的な内部サービスのセットに依存します。この項では、その機能について説明します。

1.5.1.1 ハードウェア管理

システムが初期化されると、低レベルのプラットフォーム・コンポーネントは、管理ノード・クラスタおよびコンピュート・ノードのプロビジョニングを編成します。このプロセス中に、ZFSストレージ・アプライアンスのコントローラを含むすべてのノードが、必要な管理ネットワークとデータ・ネットワークに接続されます。後の段階で追加のコンピュート・ノードをインストールすると、同じプロビジョニング・メカニズムによって新しいノードがグローバル・システム構成に統合されます。追加のディスク・トレイも、ストレージ・コントローラによって自動的に統合されます。

ハードウェアの管理の最初のステップは、ラック・コンポーネントのインベントリを作成することです。インベントリは、ラックに取り付けられているコンポーネントの仕様および構成の詳細を含む個別のデータベースです。システムに表示されたすべてのコンポーネントの履歴が保持され、アクティブなシステム・コンポーネントから取得された最新情報で継続的に更新されます。

サービス・レイヤーといくつかのシステム・コンポーネントには、ハードウェアと対話できるようにハードウェア・インベントリの詳細が必要です。たとえば、コンポーネント・アップグレードまたはサービス・デプロイメント・プロセスでは、指示をハードウェア・レイヤーに送信し、レスポンスを受信する必要があります。同様に、コンピュート・インスタンスを作成する場合、インスタンスおよび関連するネットワーク・リソースとストレージ・リソースを起動するために、コンピュート・ノード、ネットワーク・コンポーネントおよびストレージ・アプライアンスのレベルで一連の操作を実行する必要があります。

ハードウェア層を対象としたすべての手順は、ハードウェア管理サービスで一元化されています。ハードウェア層へのゲートウェイとして機能します。ハードウェア管理サービスでは、専用で高度に保護されたプラットフォームAPIを使用して、ハードウェア・コンポーネントに対して必要なコマンドを実行: サーバーのILOM、ZFSストレージ・コントローラなど。このAPIは、管理ノードのオペレーティング・システムで直接実行されます。マイクロサービスがデプロイされるコンテナ・オーケストレーション環境から分離されます。

1.5.1.2 サービス・デプロイメント

Oracle Private Cloud Applianceは、きめ細かなサービス・ベースの開発モデルに従います。機能は、アーキテクチャ・レイヤー全体に存在し、システムの垂直ビューを表す個別のマイクロサービスに論理的に分割されています。サービスには、内部および外部化された機能があり、様々なレイヤーで相互に作用します。

これらのマイクロサービスは、Kubernetesコンテナにデプロイされます。コンテナ・ランタイム環境およびレジストリは、3ノード管理クラスタでホストされます。 Oracle Cloud Native Environmentは、マイクロサービス・コンテナの自動デプロイメント、構成および起動を含むコンテナ・オーケストレーションの基礎を提供します。設計上、すべてのマイクロサービスは、様々なKubernetesノードおよびポッドに分散した複数のインスタンスで構成されます。 Kubernetes設計は、高可用性に加えて、各マイクロサービスのインスタンス間のロード・バランシングも提供します。

コンテナ化により、サービスのアップグレードと機能拡張が簡素化されます。サービスは緊密に統合されていますが単体ではないので、互換性要件が考慮された状態では個々のアップグレードが可能です。マイクロサービスの新しいバージョンはコンテナ・レジストリに公開され、Kubernetesノードおよびポッドに自動的に伝播されます。

1.5.2 共通サービス・コンポーネント

コンポーネントや運用メカニズムの一部は、多くまたはすべてのサービスで必要になるため、それらをプラットフォームに構築する方が効率的であり、プラットフォーム上にデプロイする際にサービスを利用できるようにします。これらの共通コンポーネントによって、プラットフォーム上に構築された各サービスに一連の重要な機能が追加されるため、サービスの開発とデプロイメントが簡素化されます。

メッセージ・トランスポート

すべてのコンポーネントおよびサービスは、共通トランスポート・レイヤーに接続されます。これは、コンポーネントが標準化された形式で書き込まれたメッセージの送受信を可能にするメッセージ・ブローカです。このメッセージ転送サービスは、高可用性およびスループットを実現するために3つのインスタンスのクラスタとしてデプロイされ、認証およびトラフィックの暗号化にTLSを使用します。
シークレット・サービス

ログイン資格証明や証明書など、システム全体でプログラムで使用されるシークレットは、シークレット・サービスによって集中管理されます。すべてのコンポーネントとサービスは、シークレット・サービスのクライアントです: 認証に成功すると、クライアントは実行を試みるすべての操作で使用するトークンを受け取ります。シークレット・サービス内で定義されたポリシーによって、クライアントが実行を許可されている操作が決まります。シークレットは静的な方法で格納されず、存続期間に制限があり、動的に作成および管理されます。

システムの初期化中、シークレット・サービスは保護解除され、使用できるように準備されます。これは、プラットフォーム・レイヤーのコンテナ内の管理ノードでアクティブ/スタンバイ・クラスタとしてデプロイされますが、Kubernetesマイクロサービス環境の外部にあります。これにより、シークレット・サービスは、マイクロサービスが使用可能になる前に、起動時にプラットフォーム・レイヤーに機能を提供できます。すべてのプラットフォーム・コンポーネントおよびマイクロサービスは、操作の実行を許可される前に、シークレット・サービスとの信頼関係を確立する必要があります。
ロギング

このプラットフォームは、システム全体で統合ロギングを提供します。このため、すべてのサービスおよびコンポーネントはFluentdデータ・コレクタと統合されます。 Fluentdは、事前構成されたログ・ファイルのセットからデータを収集し、中央のロケーションに格納します。ログはシステム・コンポーネント、プラットフォーム・レイヤーおよびマイクロサービス環境から取得され、トレーサビリティおよび分析のためにLokiログ集計システムを介して使用できます。
監視

モニタリングのために、プラットフォームはPrometheusを使用してメトリック・データを収集します。 PrometheusはKubernetes環境内にデプロイされるため、マイクロサービス・メトリックに直接アクセスできます。ハードウェア・コンポーネントやコンピュート・インスタンスなどのKubernetes以外のコンポーネントは、内部ネットワークおよびロード・バランサを介してメトリック・データをPrometheusに提供します。管理ノードおよびKubernetes自体は、Prometheusと直接通信できます。
分析

ロギングおよびモニタリング・データは、インフラストラクチャ管理者を対象としています。サービスWeb UIを介してデータを参照できます。ここでは、ダッシュボード上でヘルス・パラメータとパフォーマンス・パラメータに対する多数の組込み問合せがビジュアル化されます。適切な対策が取れるように、キーしきい値を超えるとアラートが送信されます。
データベース

すべてのサービスおよびコンポーネントは、共通の中央データベースにデータを格納します。 3つの管理ノードにデプロイされ、ベア・メタルで実行されているインスタンスを含むMySQLクラスタ・データベースです。可用性、ロード・バランシング、データ同期およびクラスタリングはすべて、MySQLクラスタの内部コンポーネントによって制御されます。最適なパフォーマンスを得るために、データ・ストレージは、各管理ノードに直接アタッチされているZFSストレージ・アプライアンス上のLUNによって提供されます。データベースへのアクセスは、シークレット・サービスによって厳密に制御されます。
ロード・バランシング

管理ノードは、3つのアクティブ・ノードのクラスタを形成します。つまり、すべてが同時にインバウンド接続を受信できます。イングレス・トラフィックは、フローティングIPアドレスをリスニングし、3つの管理ノードにトラフィックを分散する、静的に構成されたロード・バランサによって制御されます。ロード・バランサのインスタンスは、各管理ノードで実行されます。

同様に、すべてのコンテナ化されたマイクロサービスは、管理ノード・クラスタのコンテナ・オーケストレーション環境内で複数のポッドとして実行されます。 Kubernetesは、マイクロサービスへのイングレス・トラフィックのロード・バランシングを提供します。

第1章 アーキテクチャと設計