新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

IBM Developer Blog

IBM Developer サイトで最新の出来事をフォローし、情報を入手しましょう。

複数ベンダーのクラウドからなるインフラストラクチャーを自動化して管理する。


この記事は「Architecture Center: Multicloud management」の翻訳です。

自信を持ってマルチクラウド環境を管理する

多くの組織が幅広いクラウド・ベンダーからの IT インフラストラクチャーとソリューションを導入している中、ハイブリッドのマルチクラウド・ソリューションが急速に新しい標準になりつつあります。例えばコンテナーと Kubernetes の組み合わせは、クラウド導入における戦略的基盤になっています。

オンプレミス上と、IBM Cloud™、Amazon Web Services (AWS)、Azure などのパブリック・クラウド内に複数の Kubernetes クラスターをデプロイしている企業は少なくありません。複数の Kubernetes リリースを使用しているとしたら、IBM Cloud™ Private、Red Hat® OpenShift®、IBM Cloud Kubernetes Service、Amazon EKS、Azure AKS など、リリースによってサポートしているベンダーが異なっていることに気付く場合もあるでしょう。クラウド・プロバイダーまたは Kubernetes ソリューションではそれぞれ独自のツールと処理を使用していることから、マルチクラウド Kubernetes 環境を管理するのは手に負えない作業になりがちです。

「マルチクラウドの現状を見ると、8 割の企業がマルチクラウドに取り組んでいて、そのうちの 71% は 3 社以上のクラウド・プロバイダーを利用しています。マルチクラウドの採用は、終局と言えるでしょう。IBM Multicloud Manager は、Kubernetes を対象としたエンタープライズ対応のマルチクラウド管理ソリューションです。」 – Gang Chen、STSM

マルチクラウド管理手法の利点

マルチクラウドという新時代における企業向けハイブリッド・マルチクラウド・プラットフォームは、以下の図に示すようになると見込まれています。

企業向けハイブリッド・マルチクラウド・プラットフォームの図

企業向けハイブリッド・マルチクラウド・プラットフォームの展望を実現するために、IBM は世界初となるマルチクラウド管理テクノロジーを導入しました。それが、IBM Multicloud Manager です。

Multicloud Manager の図

このソフトウェア定義型マルチクラウド管理手法には次の利点があります。

  • 自動化とオーケストレーションによる可視性。自動化とオーケストレーションを中央のダッシュボード内でリンクすることで可視性がもたらされます。このダッシュボードで回復力を管理し、目標とするリカバリー時間を短縮できます。
  • 分析情報に基づくプロアクティブな管理診断、予測、主要な脅威に関するデータが統合され、この統合データに基づいてプロアクティブに、より有効な意思決定を行うことができます。
  • 一元的なビュー。1 つのインターフェースで一連のツールを使用して、レプリケーションとリカバリーのプロセスをすべて管理できます。
  • 柔軟性。ビジネスや法規制の条件は変わるものです。こうした変化に伴って、データ保護ポリシーも変更しなければならなくなる場合があります。ソフトウェア定義型の手法であれば、変化に適応できます。

Multicloud Manager がマルチクラウドの課題を解決する仕組み

マルチクラウド管理リファレンス・アーキテクチャーの一部として、Multicloud Manager はマルチクラウド環境に共通する次の課題を克服できるようサポートします。

  • クラスター全体にわたる可視性
  • ワークロードのデプロイメントと配置
  • コンプライアンスとセキュリティー

お客様の事例

上述の課題を説明するために、さまざまなお客様の実際のシナリオと要件を代表する事例を紹介します。acmeAir という架空の航空会社では、次の特徴を備えたクラウドを導入しようとしています。

  • オンプレミス、IBM Cloud、AWS、Azure からなるマルチクラウド
  • Kubernetes ベースのコンテナー・ランタイム
  • 自動 DevOps
  • セキュリティー (最優先事項)

acmeAir では、開発チームと事業部門 (LOB) ごとに専用の Kubernetes クラスターを割り当てています。例えば、同社が IBM Cloud Private 上で運営している acmeair.com の顧客向け Web サイトとモバイル・サイトは、オンプレミスのデータ・センターと AWS の両方にデプロイされています。航空券の予約 API サービスは、IBM Cloud Kubernetes Service と AWS 上の IBM Cloud Private で稼働しています。

予約 API 内でさえも、複数の Kubernetes クラスター (IBM Cloud Kubernetes Service のクラスターと IBM Cloud Private のクラスター) で、Dev 環境と QA 環境をステージング環境および本番環境から分離しています。高可用性と障害復旧を目的に、acmeAir は複数のクラウド・プロバイダー (領域) で本番環境クラスターをデプロイすることにしました。acmeAir が各種のプロジェクトをサポートするために使用しているクラスターは合計で 12 を超えています。他の LoB を合わせると、この数はさらに増えます。

acmeAir はここまでの数のクラスターをどのように扱っているのでしょう?現状のプロセス (Multicloud Manager を使用していないプロセス) には、次の特徴があります。

  • 社内 Ops チームは、すべてのクラスターを 1 つに統合したビューを使用しています。
  • Dev チームは、多数のクラスターとコンポーネントのパッチ適用およびアップグレードを行わなければなりません。
  • 1 つの DevOps パイプラインでマイクロサービス・アプリケーションをビルドしてデプロイし、Dev 環境から QA 環境、ステージング環境、本番環境へとアプリケーションをプロモートします。
  • 30 日ごとに、すべての環境でシークレット内に格納されたアクセス・トークンをローテーションし、CI/CD ビルド・ツールで更新します。
  • Ops または DevOps のエンジニアが、すべてのクラスター内でシークレットと ConfigMaps の同期を実施します。
  • acmeair.com サイト用のクラスター内にある顧客のペイメント・カード業界 (PCI) データは、ステージング環境用クラスターと本番環境用クラスター内でのコンプライアンス標準を満たしていなければなりません。
  • 予約 API エンジンは、ワークロードの急増に対処するために、パブリック・クラウド IaaS 上で自動プロビジョニングされる新しい IBM Cloud Private クラスターをスケールアップする必要があります。
  • Ops チームは複数のクラスターを一元管理できるツールを探しています。チームが必要としているのは、ダッシュボード、コマンドとコントロール、デプロイメントに対応するツールです。
  • Ops チームは、オブジェクトの作成と更新を一度で済むようにするために、クラスター全体でオブジェクトが同期された状態に維持しなければなりません。これには、チーム間の同期とチームが使用する Helm カタログの同期も含まれます。
  • Ops チームと DevOps チームは、1 つのコンソールから 1 つのアクションを実行すると一連のクラスターに適用されるようにしたいと思っています。

複数の Kubernetes クラスターを扱っている場合、acmeAir が直面しているクラスター全体にわたる可視性、ワークロードのデプロイメント、セキュリティーという主要な課題に対処するには、Multicloud Manager が役立ちます。

クラスター全体にわたる可視性

マルチクラウド環境で問題が発生したとき、問題があるコンポーネントがどこにあるのかわからない可能性があります。同様に、アプリケーション・サービスがどこで実行されているのかを把握するのが困難な場合や、クラスターやクラウドにまたがるアプリケーションを監視する方法が簡単にはわからない場合があります。こうした状況では、これらのクラスターやクラウドがあたかも 1 つの一貫した環境であるかのようにクラスターを管理して、クラウド全体で使用状況を監視したいかもしれませんが、どこから始めればよいのでしょう?

お客様のニーズ:

より多くのお客様が複数のクラウドを使用する戦略を採用しています。そこではオンプレミスも含め、複数のクラウド IaaS 環境で複数の Kubernetes クラスターをホスト、運用しています。運用担当者は、これらすべてのクラスターをセキュア・アクセスによって管理するための単一の管理インターフェースとユーティリティーを必要としており、すべての管理対象クラスターのヘルス・ステータス (全体のヘルス・コンディション、リソース使用状況を含む) を簡単に表示させられる必要があります。こうした情報は UI および CLI のユーティリティーを通じて提供されなければなりません。また運用担当者は管理対象クラスターのラベルを容易に追加、削除、更新できるようでなければなりません。

Multicloud Manager によってもたらされるもの:

Multicloud Manager によってすべてのKubernetes 環境間での可視性が高まり、それぞれのチームで必要とする情報がより適切に可視化されるようになります。開発チームは、デプロイメント、Pods、Helm のリリースを見ることができます。運用チームは、クラスターやノードを見ることができます。セキュリティー・チームは、単一のユーザー・インターフェースを使用して、どの機能に誰がアクセスしているかを見ることができます。もはやチームは環境内で何が起こっているかを調べるために手作業でそれぞれのクラスターをチェックする必要はありません。代わりに、Multicloud Manager のダッシュボードを見ればよいのです。

Multicloud Manager はクラスター・インベントリー内に以下の機能を提供します。

  • 一元的な場所からすべての管理対象クラスターを見る
  • クラスター・ラベルに基づき、クラスターや Kubernetes リソースに対して問い合わせや検索を行う
  • あるリジョン内にあるすべてのクラスターのヘルスを見る
  • 全クラスターの中でダウンしているノードの数を把握する
  • すべての開発クラスターにおいて、ある名前空間内の Pods を見る
  • これらのクラスター内で実行されている Pods、ノード、永続ボリューム、アプリケーションのヘルス・ステータスを見る (読み取り専用)

ワークロードのデプロイメントと配置

環境をまたがって、アプリケーションをデプロイする方法およびワークロードを移動させる方法をご存知ですか?マルチクラウド環境でのバックアップおよび災害復旧についてはどうでしょう?

お客様のニーズ:

acmeAir の開発者および運用担当者は、クラウド・ネイティブなアプリや、アプリのモダナイゼーション・パッケージといったワークロードを複数のクラスターにデプロイしたいと考えています。例えば、ある開発者や DevOps エンジニアがアプリケーションの Helm チャートを Dev クラスター環境にデプロイし、後ほど単一カタログの UI または CLI ユーティリティーを使用して、その Helm チャートを QA 環境へと発展させたいと思っているかもしれません。運用担当者がワークロードを複数のクラスターにデプロイすることはよくあることですが、acmeAir の例では運用担当者は本番ワークロードを 2 つのクラウド・プロバイダー・クラスターにデプロイし、アプリケーションの一貫性を確保しなければなりません。

DevOps チームは、マルチクラスター・サポート機能を既存の CI/CD パイプラインに組み込みたいと考えています。そうすることで、クラスターごとに異なるエンドポイント、アクセス・トークン、アーティファクト・リポジトリー (Helm リポジトリー) を管理および更新する必要がなくなります。

場合によっては、開発者や運用担当者はワークロードをより抽象性の高いフォーマットでデプロイおよび管理する必要があります。こうしたフォーマットでは、いくつかのモジュールや Helm チャートが単一のデプロイメント・ユニットとして、既に組み込まれている依存関係およびその他の関係とともにグループ化されます。依存関係コンポーネントの一部が異なるクラスターにデプロイされる場合には、複数のクラスターにまたがる抽象アプリケーション・コンポーネントを持てる機能があると役に立ちます。

Multicloud Manager によってもたらされるもの

Multicloud Manager は、ワークロード管理を目的とした以下の機能を提供します。

  • クラスターにまたがる共通リソースの代表を定義する抽象アプリケーション・コンポーネント (Kubernetes Federation V2 機能と似ています)。Multicloud Manager では視覚的なトポロジー・フォーマットを使用して関係を反映させます。
  • コンポーネントの配置。Multicloud Manager は概して、セレクターと基準の組み合わせに基づき、別々のクラスターまたは名前空間上にワークロードを配置することができます。複数のクラスターを使用するシナリオでは、コンポーネントの配置は強力なものになり得ます。
  • Multicloud Manager CLI と CI/CD パイプラインとの統合
  • クラスターにまたがる管理対象 Helm リポジトリー
  • マルチクラスター・カタログまたは CLI を通じたローカルまたはリモートでの Helm チャートのデプロイメント

コンプライアンスとセキュリティー

マルチクラウド環境では、環境全体で一貫したセキュリティー・ポリシーを設定すること、そしてどのクラスターがそれに準拠しているかを判断することは困難です。ポリシーへの準拠の問題が存在する場合、その問題を解決する方法は定かでないかもしれません。もうひとつの課題として、大規模な環境全体で構成を管理するというものがあります。みなさんはキャパシティーまたはポリシーに基づいてワークロードを配置する方法をご存知ですか?

お客様のニーズ

運用担当者はさまざまなリソースの現在の構成を、目標とする状態と比較することにより、クラスターが適切に動作していることを確実にする必要があります。さらにポリシー・テンプレートのセットを通じてクラスター内でロールを施行したり、Pod オブジェクトを配置したりする必要もあります。

この例では、acmeair.com サイトを IBM Cloud と AWS の両方にデプロイしています。しかし IBM Cloud のみが PCI 準拠として企業から認定されています。これは顧客の支払情報がシステムに保管されるためです。このように、IBM Cloud 内にホストされている Kubernetes クラスター上でのみ支払サービスが動作可能であるよう、ポリシーによって強制しなければなりません。

もうひとつの例はワークロードのデプロイメントに関係するものです。acmeair.com では新しい機能の投入を計画していますが、さまざまなテストを実行できるよう、最初は Dev 環境および QA 環境内にデプロイすることを考えています。そのため、デプロイメントを実施するには Dev 環境および QA 環境のクレデンシャルを使用して手作業で CI/CD パイプラインを構成しなければなりません。

Multicloud Manager によってもたらされるもの:

Multicloud Manager はチームが一貫した構成およびセキュリティー・ポリシーで環境を管理できるようにするので、クラスターの数が増えても変更が生じません。これらのポリシーは、対象のクラスターで施行され、たとえ管理システムへ接続できない場合でも、有効に動作することが可能です。Multicloud Manager はセキュリティーおよびポリシー準拠のために以下の機能を提供します。

  • セキュリティー、アプリケーション、インフラストラクチャーを対象としたポリシーを設定して施行する (クラスター・レベルで自動施行)
  • デプロイメントのパラメーター、構成、ポリシーに対して準拠していることをチェックする
  • アプリケーション配置ポリシー (クラスター・セレクター・ラベル) を提供する。DevOps エンジニアは、対象クラスター用のクラスター・セレクター・ラベルでポリシーを更新します。Multicloud Manager は提供されるラベルに基づき、対象となる環境を見つけて、機能をこれらのクラスターにデプロイします。

次のステップ