環境アーキテクチャーの文書化

ベスト・プラクティスとして、アプリケーションのアーキテクチャー図を作成します。 これらのダイアグラムは、初期設計作業の一部として使用したり、新規チーム・メンバーをトレーニングしたり、新規および既存のチーム・メンバーを教育したりすることができます。 このようなダイアグラムを最新の状態に保つことで、問題を迅速に調査する必要がある場合に時間を節約できます。

アプリのアーキテクチャを文書化することで、自分やチームメンバーが、アーキテクチャ構成に含まれるすべてのコンポーネントを確実に理解できるようになります。

アーキテクチャー図は、初期環境計画の一部として作成することも、環境が稼働中になった後に作成することもできます。 ご使用の環境を文書化するには、以下の手順を確認してください。 提供されている例は、実際のアプリケーションに基づいています。

ステップ 1: アプリとアーキテクチャーについて

IBM Cloud Kubernetes Service クラスターでのアプリのトラブルシューティングは複雑になる可能性があります。特に、さまざまなクラスター、コンポーネント、ポッド、またはサービスにまたがるネットワーク・フローが問題に関係している場合は複雑になる可能性があります。 アプリ・アーキテクチャーを文書化すると、チームがセットアップ内のすべてのコンポーネントを完全に理解するのに役立ちます。

単純なネットワーク・フローを使用するアプリの場合、アーキテクチャーをテキストで説明できます。 より複雑なシナリオでは、トラブルシューティングに関与するさまざまなチームがフローを理解できるように、詳細なアーキテクチャー図が役立ちます。 また、セットアップが変更された場合に、ご使用のアーキテクチャーの資料が最新の状態に保たれるようにすることも重要です。

IBM Cloud Kubernetes Service クラスターでのアプリのトラブルシューティングは、特に以下の 1 つ以上が当てはまる場合には困難なことがあります。

  1. アプリが十分に理解されていないか、ロギングが良好ではありません。
  2. 問題は断続的であるか、または頻繁には発生しません。
  3. この問題には、さまざまなクラスター、コンポーネント、ポッド、またはサービスにわたるネットワーク・フローが関係しています。

以下のアーキテクチャー図の例は、実際のシナリオから取られています。 これらの例は、独自のアーキテクチャー図を作成する際のガイドとして使用できます。

例 1: 単一の OpenShift クラスターで実行される基本アプリ

この例では、アプリ全体が単一の OpenShift クラスター内で実行されています。 これは単純なアプリで、単一のクライアント・ポッドがクラスター内サービスに要求を出し、そのサービスが 3 つのポッドによって処理される etcd インスタンスに接続します。

Client                Application Service             Etcd Instance
                                             |------> [Etcd Pod 1]
                |---> [Application Pod 1] ---|
                |                            |
[Client pod] ---|                            |------> [Etcd Pod 2]
                |                            |
                |---> [Application Pod 2] ---|
                                             |------> [Etcd Pod 3]

例 2: グローバル・ロード・バランサーと Cloudant サービスを使用するマルチクラスター・アーキテクチャー

以下の図では、接続は、 eu-de 領域内のクラスター内の 3 つのクライアント・ポッドのいずれかによって開始されます。 クライアント・ポッドはグローバル・ロード・バランサー (GLB) に接続します。これにより、 eu-de と eu-gb の 2 つのパブリック VPC アプリケーション・ロード・バランサー (ALB) のいずれかに接続のロード・バランシングが行われます。

これらのVPC ALBはそれぞれ、それぞれのリージョンで独立したクラスタの一部である。 これらの ALB は、トラフィックを OpenShift ルーター・ポッドにルーティングし、そのトラフィックをクラスター内のバックエンド・ポッドに転送します。 これらのバックエンド・ポッドは、要求を処理するために Cloudant データベースに接続します。

これらの接続の一部はパブリック・ネットワーク経由であることに注意してください。 一部は同じ VPC 内のプライベート・ネットワークを経由しており、一部は VPC 内のコンポーネントと IBM Cloud内のサービスの間で IBM Cloud 内のプライベート・ネットワークを使用しています。

マルチ・クラスター図*マルチ
クラスター・アーキテクチャ
の例

例 3: 外部サービス・バックエンドを使用して VPC ネットワーク・ロード・バランサーに接続する VSI クライアント

以下の例では、クライアントは IBM Cloudのクラシック VSI です。 VSI は、プライベート・ネットワークを介して、VPC クラスター用に作成されたプライベート VPC ネットワーク・ロード・バランサー (NLB) に接続します。 この NLB は、クラスター・ロード・バランサー・サービスの NodePort を介して、3 つの VPC ワーカー・ノードのいずれかにトラフィックのバランスを取ります。 その後、クラスター・ロード・バランサー・サービスは、パブリック・ネットワークを介して IBM Cloud の外部クラウド・サービスに接続するアプリ・ポッドの 1 つにトラフィックを送信します。

外部サービス付きNLB* 外部" caption-side="bottom"}付き{: caption="* NLB with an external service

ステップ 2: ツールの選択

以下のいずれかのツールを使用して、アーキテクチャー図を作成できます。

多くのダイアグラミング・ツールを使用できます。 お客様に最適なツールを選択してください。

ステップ3：図を作成する

前述の例のいずれかを参照として使用することも、ダイアグラムを最初から作成することもできます。

リファレンス・アーキテクチャーについて詳しくは、 IBM アーキテクチャー を参照してください。

次のステップ

クラスターを作成するためにアカウントを準備します。