モジュールおよびデプロイ可能なアーキテクチャーとは何ですか?
安全でコンプライアンスに準拠したスケーラブルなアプリケーション・インフラストラクチャーを作成することは、セットアップが難しく、保守にコストがかかる可能性があります。 準拠したインフラストラクチャー・アーキテクチャーを自分でアセンブルする方法を理解する代わりに、モジュールとデプロイ可能なアーキテクチャーを利用することができます。 モジュールおよびデプロイ可能なアーキテクチャーは、組織のアカウントでのリソースのデプロイ方法に関するフレームワークの作成に役立ちます。 これらの再使用可能な構成を処理することで、デプロイメントの標準を一度定義するだけで、組織のメンバーごとに容易に反復できるようにすることができます。
例えば、アパート団地を建設している建築家について考えてみましょう。 これらの設計は通常、モジュラー方式で実行されます。 標準的な 1-寝室、2-寝室、または 3-寝室のアパートのパターンがあります。 このビルダーは、それぞれが独自の方法で機能する標準的なアパートを、より大きく、より複雑な、しかし機能的な生活構造に結合させることができます。 IBM は、クラウドへのソリューションのデプロイと同じ類似点を適用しました。 IBM Cloudのよく設計されたパターンを使用することで、組織がサービスとソフトウェアを連携させる方法を数カ月費やすのではなく、サービスとソフトウェアを連携させる方法を理解することができます。 各パターンは、モジュールやデプロイ可能なアーキテクチャとして知られる、構成可能で自動化されたビルディング・ブロックとしてパッケージ化されている。
モジュールとは何ですか?
モジュールは、開発者が再利用し、大規模なシステムの一部として共有できる自動化コードのスタンドアロン単位です。 Node.js または Python パッケージと同様に、モジュールは関連リソースを管理する開発者にとって便利なものです。 モジュールを単独で使用することもできますが、モジュールを組み合わせてデプロイ可能なアーキテクチャーを構築すると、さらに強力になります。 IBM Cloud によって作成されたモジュールは、 IBM Terraform モジュールのパブリック GitHub 組織で使用可能になります。 例えば、 IBM Cloud 上の Red Hat® OpenShift® VPC クラスター・モジュール は、 IBM Cloudに Red Hat OpenShift クラスターをインストールして構成します。
デプロイ可能なアーキテクチャーとは何ですか?
デプロイ可能なアーキテクチャーは、1 つ以上のクラウド・リソースを組み合わせた共通のアーキテクチャー・パターンをデプロイするためのクラウド自動化です。 これは、ユーザーによるデプロイメントの簡素化、スケーラビリティー、およびモジュール性を提供するように設計されています。 デプロイ可能なアーキテクチャーには、1 つ以上のモジュールが組み込まれています。 デプロイ可能なアーキテクチャーは Terraform でコーディングされます。Terraform は、必要な動作を実現するために入力変数を使用して構成します。 より複雑なデプロイ可能なアーキテクチャを作成するために、Terraformのコードを編集することなく、デプロイ可能なアーキテクチャを積み重ねることができます。

デプロイ可能なアーキテクチャの例としては、 Secrets Manager のクラウド・オートメーションが ある。 この展開可能なアーキテクチャは、 IBM Cloud Secrets Manager インスタンスをモジュール式ソリューションとして提供する。 このアーキテクチャを使用して、 IBM Cloud アカウントで秘密を安全に管理することができます。 Secrets Manager、クラウド自動化の範囲は狭い。 展開可能なアーキテクチャは、 IBM Key Protect キーリングとデータを暗号化するキーが存在しない場合は、オプションで作成することもできるが、 Secrets Manager インスタンスを展開するだけである。
デプロイ可能なアーキテクチャは、次のように、より広い範囲に及ぶことができる。 VPC landing zone. VPC landing zone は、トランジット・ゲートウェイで接続されたハブ&スポーク・ネットワーク・パターンで、複数の仮想プライベート・クラウドを規定する。 これには、VPC 上で実行されるワークロードのモニターおよびセキュリティーに使用される多数のサポート・サービスが含まれます。
IBM Cloud で専門家によって作成および保守されるデプロイ可能なアーキテクチャーは、 IBM Cloud カタログで使用可能になります。 これらのデプロイ可能なアーキテクチャーの独自のバージョンを作成するか、最初からビルドすることを選択した場合は、デプロイ可能なアーキテクチャーをプライベート・カタログにオンボードし、カタログを介してすぐにデプロイできるソリューションを組織と共有することができます。
展開可能なアーキテクチャを積み重ねるとはどういうことか?
実験
より複雑なユースケースの場合、アーキテクチャを積み重ねることで、複雑なアプリケーションやインフラを展開するための完全なエンドツーエンドのソリューションを形成することができる。 特定の機能を提供する個別のモジュールや展開可能なアーキテクチャとは異なり、スタッキングは複数の展開可能なアーキテクチャを組み合わせて、簡単に展開・管理できる包括的なソリューションを形成する。 モジュールを組み合わせて展開可能なアーキテクチャを作ることができるように、展開可能なアーキテクチャを積み重ねて、より広範なソリューションを作ることができる。 スタッキングには、アーキテクチャを連結して複雑な展開可能アーキテクチャを作成することも含まれる。 このリンクは、展開可能な各アーキテクチャの入力に、参照記法を用いて参照を指定することで実現する。 Terraformのエキスパートでなくても、Terraformのコーディングスキルがなくても、アーキテクチャをスタックしてデプロイすることができる。
例として、 Secrets Manager のクラウド自動化を考えてみよう。 このデプロイ可能なアーキテクチャには、 Secrets Manager インスタンスを作成する Secrets Manager モジュールが含まれる。 Secrets Manager のインスタンスが必要なだけなら、このデプロイ可能なアーキテクチャが適している。 しかし、秘密を安全に管理することは、クラウドのセキュリティを維持するための1つの要素に過ぎない。 コンプライアンス・スキャンを実行することで、リソースの状態を常に把握できるようにするのはどうだろうか あるいは、 IBM Cloud アカウントで重要なイベントの通知を受信していますか? IBM Cloud Essential Security and Observability Services 配備可能なアーキテクチャは、 IBM Cloud のあらゆるセキュリティサービスを活用します。 これは、 Secrets Manager のクラウド・オートメーションと、 Security and Compliance Center や Event Notifications のような他の IBM Cloud サービスをプロビジョニングするデプロイ可能なアーキテクチャを積み重ねることによって生まれた。 この展開可能なアーキテクチャは、 Secrets Manager だけでは提供できない、より包括的なセキュリティ・ソリューションを提供する。
IBM Cloud、デプロイ可能なアーキテクチャをプロジェクト内でスタックし、余分な検証ステップを踏むことなく、それらをまとめてカタログに公開することができる。 あるいは、プライベート・カタログにソリューションを搭載する際に、アーキテクチャを積み重ねることもできる。 そこから、他の人と共有することで、自分で再構築する手間を省くことができる。
この複雑なソリューションは、そのコスト、コンプライアンス、サポート、品質保証の多くを、含まれる展開可能なアーキテクチャから得ている。 しかし、その複雑なソリューションには固有のバージョン、説明、アーキテクチャ図がある。 カタログ内の他のコンポーネントとスタックされている配置可能アーキテクチャにアップデートが行われた場合、そのコンポーネントの配置可能アーキテクチャの最新バージョンを使用するように、オンボーダーがソリューション全体をアップデートする必要があります。 ソリューション全体を新しいバージョンにアップデートすることで、単一のアーキテクチャに対する最新のアップデートが、より広範なソリューションの中で正しく機能するようになります。
しかし、デプロイ可能な各アーキテクチャは独立した構成状態を持ち、それぞれが独立してデプロイ、更新、またはアンデプロイされる。 例えば、 IBM Cloud Essential Security and Observability Servicesの展開可能なアーキテクチャには、Cloud automation for Secrets Manager の展開可能なアーキテクチャなどが含まれていることはすでにご存じだろう。 Secrets Manager のクラウドオートメーションが更新された場合、 IBM Cloud Essential Security and Observability Services を更新し、 Secrets Manager の最新バージョンを使用する必要があります。 しかし、 IBM Cloud Essential Security and Observability Servicesに含まれるすべてのアーキテクチャは、そのソリューションを利用するユーザーが再デプロイする必要はない。 ユーザーがプロジェクトをアップデートして最新バージョンを使用する場合、 Secrets Manager のみを再デプロイする必要がある。
展開可能なアーキテクチャには何が含まれるのか?
デプロイ可能なアーキテクチャーには、より複雑なソリューションを作成するために、バリエーションを含めたり、依存関係を含めたり、一緒にスタックしたりすることができます。
- バリエーション
-
バリエーションとは、さまざまな機能や複雑さを既存のデプロイ可能なアーキテクチャーに適用する、デプロイ可能なアーキテクチャーの一種です。 例えば、内部でテストするためのシンプルで低コストのデプロイメントの基本機能を備えた、デプロイ可能なアーキテクチャーに対するクイック・スタートのバリエーションがある場合があります。 また、実動で使用する準備ができている、もう少し複雑な標準バリエーションを使用することもできます。
- 必要なアーキテクチャ
-
デプロイ可能なアーキテクチャは、デプロイを成功させるために他のデプロイ可能なアーキテクチャからの出力を必要とする入力を含むことができる。 展開可能なアーキテクチャと、それが必要とする別のアーキテクチャとの間のこの関係は、一般に依存関係と呼ばれる。 ディプロイメント可能なアーキテクチャをスタックする方法と、ディプロイメント可能なアーキテクチャをプライベートカタログにオンボードし、他のアーキテクチャを含めるように拡張する方法です。
{: caption="なアーキテクチャ
- オプション・アーキテクチャ
-
デプロイ可能なアーキテクチャは柔軟に設計されているため、アーキテクチャを簡単に積み重ねて、より完全なソリューションを構築することができる。 しかし、一般的に有用なデプロイ可能なアーキテクチャには、複雑なユースケースに対応するために必要な特定のオプションが含まれていない場合がある。 例えば、 Java のアプリケーションにはどのデータベースを使うのか? イベント通知やメッセージキューなど、デフォルトでは含まれていないオプションのサービスが必要ですか? オプションの展開可能なアーキテクチャを、必要な展開可能なアーキテクチャと一緒に積み重ねることで、ユーザーのこのカスタマイズの問題を解決することができる。
- スワップ可能なアーキテクチャ
-
アーキテクチャが依存関係を満たすために必要なものであれ、アーキテクチャのオプション的な拡張として含まれるものであれ、ユーザーはより柔軟性を求めるかもしれない。 Java アプリケーションがオプションのデータベースで動作することはご存知かもしれません ユーザーがスワップ可能なアーキテクチャを指定することで、エンド・ツー・エンドのソリューションをカスタマイズし、特定のニーズを満たすことができる。 オプションまたは必須のアーキテクチャを一緒にスタックした後、アーキテクチャを互いにスワップ可能としてグループ化できます。 消費ユーザーは、依存関係を満たすために使用したい必須アーキテクチャを選択したり、ユースケースを拡張したい場合はオプションのアーキテクチャを選択したりすることができる。
展開可能なアーキテクチャをプライベート・カタログに搭載 すると、オプションでスワップ可能なアーキテクチャを追加できる。 現在、 プロジェクト内で配置可能なアーキテクチャを積み重ねても、オプションのアーキテクチャやスワップ可能なアーキテクチャはサポートされません。
プロジェクトとは何ですか? また、プロジェクトはデプロイ可能なアーキテクチャーでどのように機能しますか?
IBM Cloud プロジェクトは、組織内に存在する実世界のプロジェクトを編成し、可視性を提供するように設計された管理ツールです。 プロジェクトは、デプロイ可能なアーキテクチャーのすべての構成済みインスタンスと、それらがデプロイされた実際の理由に関連するリソースを管理します。 プロジェクトは、バージョン管理されたデプロイ可能なアーキテクチャー・インスタンスを保管し、それらのインスタンスとリソースを環境に編成して、開発ライフサイクルの可視性を向上させます。 環境は、デプロイメントを容易にするために値を共有する、関連するデプロイ可能なアーキテクチャー・インスタンスのグループです。 例えば、development、test、prod などです。
プロジェクトは、承認されたデプロイ可能アーキテクチャーのみをデプロイできるようにする責任があります。 さらに、作成したアーキテクチャーとリソースが最新のものであり、準拠しており、時間の経過とともにドリフトが発生しないようにすることもできます。 例えば、アカウント管理アプリケーション・プロジェクトがあるとします。 このプロジェクトは、アカウント管理アプリケーションが開発環境、テスト環境、または実稼働環境にデプロイする必要があるすべてのリソースを管理するように設計されています。 各環境には、同じ変数 (地域や接頭部など) がありますが、値は異なります。 デプロイ可能なアーキテクチャーがプロジェクトを介して環境に割り当てられる場合、それらの入力値は、同じ名前を持つ環境のプロパティーを自動的に参照できます。 IBM Cloud プロジェクトは簡単に作成および更新できますが、複製または共有用にテンプレート化または最適化されていません。
作成するソリューションを知るにはどうすればよいですか?
独自のソリューションを作成する予定の場合は、スコープ、カップリング、デプロイ可能かどうか、およびソリューションの目的をすべて考慮する必要があります。 ビルドする計画を決定するのに役立つガイダンスとユース・ケースについては、 アーキテクチャーを設計するための計画と調査 および 作成するコンポーネントの種類を決定するにはどうすればよいですか? を参照してください。
以下の表に、さまざまなコンポーネントを作成する理由の概要を示します。
目的 | 推奨方法 | なぜでしょうか? |
---|---|---|
共有可能な自動化コンポーネントのライブラリーの作成 | モジュールの作成 | モジュールは、デプロイ可能なアーキテクチャーを作成および構成しているユーザーのプロセスを高速化するために、再使用可能なキュレーションされた自動化を提供します。 |
組織のクラウド環境がセキュアで準拠していることの確認 | 展開可能なアーキテクチャを作成する | デプロイ可能なアーキテクチャーは、セキュアで準拠したデプロイメントを一度定義すれば、組織のすべてのメンバーが同じ方法でデプロイメントを繰り返すことができるようにパッケージ化されています。 |
独自のソリューションの設計 | 展開可能なアーキテクチャを積み重ねる | アーキテクチャーを組み合わせることで、組織にとってより複雑なエンドツーエンドのソリューションを作成できます。 |