コンテナクラウドリソースデータの関連付けとデータ連携の難しさと解決策

コンテナ クラウドがますます多くのビジネスをカバーするようになるにつれて、コンテナ クラウドの日常的な手動メンテナンスと管理では技術的なニーズを満たすことができなくなり、自動化された運用およびメンテナンス ソリューションが重要になります。コンテナ クラウドの自動運用と保守では、さまざまな種類の IT 環境をカバーし、グローバル インフラストラクチャの完全な可視性とパフォーマンス制御を可能にする拡張性を備えている必要があります。コンテナ クラウドの自動化された運用と保守を実現する上での主な問題点としては、従来の運用と保守の考え方に制限され、自動化機能が弱くなることが挙げられます。自動化プラットフォームに関する経験不足オープンソース ツールが多すぎるため、オープンソースとオープンソース ガバナンスの方法を選択するのが困難です。

クラウドネイティブアプリケーションイノベーション実践アライアンスは、「コンテナクラウド自動運用保守」の方向における主題専門家グループの研究を通じて、コンテナクラウド自動運用保守システムの構築、コンテナクラウド監視システムの階層化と実装方法、コンテナクラウド運用保守と企業の運用保守プロセスの統合という3つの側面で、企業に意思決定の参考資料を提供することに重点を置いています。企業の運用保守担当者がコンテナ クラウドに関する理解を深め、運用保守の考え方をアップグレードできるように支援し、コンテナ クラウドの自動化された運用保守を構築するための方法論的な提案を提供します。

今回は、コンテナクラウド自動運用保守研究チームの中間研究成果「コンテナクラウドのリソースデータ連携・データ連携の課題と解決策」を紹介します。

導入

この記事では、コンテナ クラウド シナリオにおけるリソース データの管理について説明し、従来のアーキテクチャとクラウド ネイティブ アーキテクチャにおけるデータ管理の違いについて説明します。この記事では、データ リソースの範囲を定義し、データを管理した後の運用上の利点のシナリオについて説明します。クラウド ネイティブ変換プロセスにおいて、企業は動的なリソース認識の問題に直面することがよくあります。著者は実用的かつ効果的な解決策もいくつか提供しています。

序文

クラウドネイティブの文脈では、運用保守システムの構築と機能は大きな課題に直面しています。従来の運用および保守のシナリオでは、リソース管理方法とプロセス サポートが固定されています。同様に、ビジネスにおける運用・保守サポートも広範囲をカバーすることはできません。クラウド ネイティブまたは DevOps シナリオでは、運用保守エンジニアまたはクラウド ネイティブ エンジニアが運用保守シナリオの機能をアップグレードする必要があります。典型的な例としては、データとビジネス ドメインの両方をカバーするフルリンク サービス品質監視カバレッジなどがあります。インテリジェントかつ集中的な動的リソース スケジューリングおよびスケーリング メカニズム。障害警告と問題箇所を解決する機能を備えた最終状態監視システム。 「価値」提供プロセスのすべての段階で信頼できない要因から防御する能力。効率的なリソース配信と迅速なオンライン化を可能にするプロセス メカニズム。 IT 組織内でビジネスをクラウドに迅速に移行できる機能。

上記のすべての機能の中には、中核となる要素があることがわかります。それは、データが各クラウド ネイティブ シナリオまたは機能の中心にある必要があるということです。データ間の接続と連携を実現するには、リソースを調整および管理する必要があります。

1. リソースデータ管理方法

1. 従来のリソース管理方法

コンテナ クラウド リソース データの管理は、従来の CMDB とは根本的に異なります。多くの人の理解では、従来の CMDB は IT 機器の構成を管理するためのデータベースにすぎません。その機能は、下図に示すように、機器構成の収集と機器構成の保存、構成レポートやコストレポートなどの構成データの大まかな処理に限定されています。

2. 自動運用・保守のためのリソース管理

自動化された運用と保守の概念の普及と運用と保守技術の発展に伴い、リソース管理の方法や手法も静かに「アップグレード」されてきました。主な側面は、データセンター リソース管理とアプリケーション リソース管理の 2 つです。前者は IT 資産管理の機能を拡張し、後者はアプリケーション データのサポートを強化します。これら 2 つの側面の中核機能は、本質的に、自動化された運用と保守を促進または実装する上で重要なステップです。下図に示すように、問題診断、バッチリソース管理、自動検査、SLA保証、リソース使用率管理を通じて運用保守の効率を向上させ、自動データ収集、オープンAPI、ビジュアルビュー、リソース標準化、サービス管理を通じて運用保守の自動化をサポートします。

自動化された運用と保守を目的としたシナリオでは、リソース管理は、API 機能を通じて上位レベルのアプリケーションをサポートする基盤となる管理機能です。代表的な例としては、標準化された一貫したデータサポートや強化されたバリアフリープロセスサポートなどが挙げられます。

3. DevOpsのリソース管理

DevOps のリソース管理は、実際には DevOps と CMDB の統合です。著者の「DevOps 決定版ガイド」には詳細な説明が記載されており、ここではそれを要約します。

CMDB と DevOps の統合シナリオには、主にビジネス シナリオ、アーキテクチャ シナリオ、展開シナリオ、データ出力シナリオ、従来のインフラストラクチャ シナリオが含まれます。ビジネス シナリオの観点から、サービスはビジネス アクセス フローに基づいて視覚化されます。アーキテクチャ シナリオに関しては、アプリケーションはアーキテクチャ ビューに基づいて細かいレベルで統合され、完全なビジネスとビジネス パノラマ ビューが形成されます。展開シナリオに関しては、アプリケーションに対応するノードとコンポーネントが含まれ、アプリケーション展開ビューが形成されます。データ出力シナリオに関しては、CMDB が提供するデータの外部出力シナリオがすべて含まれており、このシナリオは主に他の統合シナリオとの一方向および双方向のデータ相互作用を実行します。従来のインフラストラクチャ シナリオは、基盤となるインフラストラクチャのビューの出力を参照し、収集、クエリ、ストレージ、および表示機能を提供します。

アプリケーションの面では、CMDB はビジネス シナリオを支援し、DevOps を通じてビジネス プロセスを推進します。価値提供パイプラインでは、CMDB は各ビジネス プロセスの正確な構成データを提供します。アーキテクチャ設計、キャパシティ管理、継続的デリバリー、ビジネス ドメイン保証のプロセス中に、ビジネス システムはデータのエンパワーメントを通じてビジネス プロセスを実装します。同時に、CMDB によって提供されるデータの高度な使用は、主に複数のシナリオでデータを関連付け、エンドツーエンドのビューを通じて監視フィールドで根本原因分析、障害箇所の特定、迅速な「自己修復」を実行する際に DevOps を支援することです。 DevOps の測定とフィードバックフェーズでは、CMDB が提供するデータをサービスとして運用し、業務運用分析やコスト検討、リソース容量の計画と管理を実現します。

2. コンテナクラウドリソースの管理方法

プライベート クラウド、パブリック クラウド、またはコンテナー クラウドのシナリオのいずれであっても、アプリケーション、データ、コンポーネントを含むクラウド ネイティブのリソース管理方法 (クラウド ネイティブ資産管理とも呼ばれます) に直面することになります。クラウドネイティブのリソース管理と従来のリソース管理には大きな違いがあります。クラウドネイティブ環境では、すべてのリソースが絶えず変化するため、サポートされるアプリケーションとシナリオも複雑で変化しやすくなります。同時に、クラウドネイティブアプリケーションの多くはマイクロサービスを使用しているため、管理する構成項目の数も飛躍的に増加しています。

この場合、コンテナ クラウド リソースの管理方法は、リソース データ管理とリソース シナリオ管理を組み合わせたものになる必要があります。リソース管理モデル、属性、および組み合わせ関係はリソース データを通じて定義する必要があり、リソースはリソース シナリオを通じて記述され、データ型は標準化される必要があります。次の図は、一般的なコンテナ クラウド リソース管理シナリオを示しています。

アプリケーション リソース管理には、アプリケーション トポロジ情報、パッケージ ディレクトリ、起動および停止スクリプトなどの基本的なアプリケーション情報、クラスター、環境、ホスト、プロセスなどのアプリケーション デプロイメント情報、アプリケーション間およびアプリケーションと基本リソース間の呼び出し情報が含まれます。

基本リソース管理、アプリケーションはさまざまな基本リソースで構成されており、さまざまな基本リソースの構成情報管理をサポートする必要があります。

アプリケーションアーティファクト管理。一般的に、リソース管理ではアーティファクトは管理されませんが、アーティファクトとアプリケーションの関係を管理するには、外部アーティファクト ライブラリとのドッキングをサポートする必要があります。

著者は読者が理解しやすいように典型的な例を挙げています。コンテナ クラウド リソース管理のプロセスでは、リソース管理モデルを定義する必要があります。このモデルは、コンピューティング リソース、ストレージ リソース、ネットワーク リソースなどのクラウド リソースの種類を表し、クラスター モデルと製品タイプも含まれます。モデルは、さまざまな側面からのリソースを属性の形で収集する必要があり、モデルの属性はシナリオに応じて自由に定義および拡張できます。たとえば、クラスター モデルの属性にはクラスター名、クラスター モードなどが含まれ、ホスト モデルの属性には IP、タイプ、リージョンなどが含まれます。従来のリソース管理方法との最大の違いは、ビジネスが成長し変化し続けるにつれて、クラスターとホストの情報も継続的に拡張する必要があることです。

3. コンテナクラウドリソースデータの関連付け

リソース データの関連付けには、リソースを抽象化して定義する方法、リソース データ間の関係を決定する方法、コンテナー クラウド シナリオでリソース リンクを追跡する方法という 3 つの主要な問題が関係します。

コンテナ クラウド リソース データには、コンテナ クラウド プラットフォーム自体のデータ、データ センター データ、信頼性保証のためのイベント データと変更データ、およびビジネス継続性のための監視データ、アプリケーション構成データ、ビジネス クラスター データが含まれます。著者は運用と保守の分野におけるデータ分析に重点を置いています。下の図に示すように、コンピュータ室、キャビネット、サーバー機器、ネットワーク機器、ストレージデバイスの関係が明確にわかります。アプリケーション、エンティティ、データベース、システム間の関係も確認できます。これは、IP アドレスに基づく一般的なデータ関連付け方法です。

上記のコンテナ クラウド リソース データの関連付けのシナリオでは、アプリケーション、データベース、負荷分散の 3 つのモデル間の関連付けは双方向であるのに対し、物理デバイス、ネットワーク デバイス、ストレージ デバイス間のデータの関連付けは単方向であることが明確にわかります。これはコンテナの特性によって発生します。いずれかのインスタンスがモデル化されると、別のモデルが PaaS レイヤー モデルに関連付けられます。各モデルには他のモデルが使用できる属性データがあり、巨大なデータ関連グラフが生成されます。したがって、属性データが変更されると、関連するデータの関連付けも変更され、データ リンクがトリガーされる可能性もあります。

著者は、コンテナ クラウド リソースのデータ関連付けを説明する簡単な例も示しています。運用保守チームがオブジェクトを監視し、監視指標の早期警告メッセージを受信すると、運用保守管理者はまず、ビジネスの継続性やサービスを持続的に提供する能力に影響があるかどうかに焦点を当てます。このオブジェクトを担当するエンジニアは、このオブジェクトの障害が下流コンポーネントによって引き起こされているかどうか、上流システムに問題を引き起こしているかどうか、このオブジェクトがアプリケーション サービス内のどの環境にあるか、高可用性を備えているかどうか、このオブジェクトが運ぶアプリケーションがどのチームに属しているか、最近変更があったかどうか、他のコンポーネントとの依存関係があるかどうか、コンテナ クラウド プラットフォーム自体が原因であるかどうかなど、このオブジェクトの上流と下流の関係を短時間でトラブルシューティングする必要があります。このとき、アプリケーション トポロジ、クラスター トポロジ、モジュール トポロジ、コンテナ クラウド リソース トポロジ、データ関連付けなど、コンテナ クラウド リソース データ関連付けのトポロジ マップの完全なセットが必要です。

リソース データの関連付けには、コンテナ クラウド プラットフォーム自体にデータの関連付け機能があることだけでなく、インターフェイス システム、アプリケーション監視システム、構成センター システム、組織構造システム、運用保守プロセス システムなどのサードパーティ システムに接続されていることも必要です。双方向システムの接続プロセスでは、任意の 2 つのモデルがデータの関連付けを通じて一方向または多方向の関係を形成する必要があります。

4. コンテナクラウドリソースデータの連携

コンテナ クラウド リソース データにデータの関連付け機能がある場合、特定のシナリオに合わせて調整し、データ リンクを実行する必要があります。通常、コンテナ クラウド環境では、運用保守チームはさまざまな環境やリソースに対する運用に直面します。コンテナ クラウド プラットフォームには独自のリソース データ連携機能がありますが、アプリケーションとの連携はまだ容易ではありません。そのため、コンテナクラウドプラットフォーム内のリソースオーケストレーション機能をベースに、オーケストレーションされたコンポーネントやプラグインを開発・カプセル化することで、データ連携による柔軟かつカスタマイズ性、管理性に優れたテンプレート化された運用・保守機能を提供する必要があります。これにより、事業継続管理プロセスにおける運用保守管理、承認、意思決定、実行のシナリオがカバーされ、最終的には運用保守の自動化とインテリジェンスが実現します。

コンテナ クラウド リソース データ連携は、インフラストラクチャ層、コンテナ サービス層、アプリケーション層の 3 つの層に分けられます。インフラストラクチャ層はクラウドリソース連携、コンテナサービス層はKubernetes連携、アプリケーション層は運用保守連携に該当します。次の図に示すように、IT 組織内の他の機能サブドメインのリンクにも対応できます。

​​​​

クラウド リソースの連携。連携対象は、コンピューティング リソース、ネットワーク リソース、ストレージ リソースなど、さまざまなクラウド リソースであり、主にコンテナ クラウド プラットフォーム内のオーケストレーション機能を通じて、基本リソースの柔軟なスケーリング機能を実現します。 Kubernetes リンク、リンク オブジェクトは Kubernetes クラスター リソース データであり、主に Helm または YAML を通じてオーケストレーションされます。運用保守連携は、主に運用保守保証、運用保守監視、運用保守プロセスシナリオを目的としており、自動化された運用保守またはインテリジェントな運用保守の機能を実現します。

一般に、運用および保守のシナリオでリソース データをリンクする方法には、運用および保守イベント管理、アプリケーション呼び出し管理、サービス展開管理、変更影響管理の 4 つが主に存在します。イベント管理では、コンテナクラウドプラットフォームとイベントシステムを接続し、アラームを分析したり、イベントデータとリリースデータの連携を実現したりできます。アプリケーション呼び出し管理の面では、コンテナ クラウド プラットフォームとアプリケーション リンク システムを接続して、障害のあるアプリケーションの上流および下流の呼び出しリンクを分析し、サービス異常の原因とアプリケーション リンク呼び出しの影響関係を照合することができます。サービス展開管理の観点では、コンテナ クラウド プラットフォーム独自のデータを通じて相関分析を実行し、変更とアラームの関係をタイムリーに特定できます。変更影響管理の観点では、コンテナクラウドプラットフォームと変更システムを接続して、さまざまな事業継続指標間の関係を確立し、データ連携を通じて変更の可能性のある影響範囲を明確にすることができます。