コンテナクラウドプラットフォームの運用・保守の考え方や手法を学ぶ

1. コンテナクラウドプラットフォームの運用・保守の範囲

コンテナクラウドプラットフォームの構築については、企業によって考え方や方法が異なる場合がありますが、運用保守担当者は、まず運用保守の範囲と内容を理解する必要があります。

（I）維持すべきものを整理する

運用および保守担当者の最も重要な責任は、あらゆる適切な方法を使用してシステムの正常な動作を確保し、それによってビジネスの正常な動作を確保することです。システムに問題が発生すると、ビジネスに影響を及ぼし、顧客にも影響を及ぼし、損失を引き起こす可能性があります。そのため、運用保守担当者は自身の運用保守内容を明確に理解している必要があります。そうして初めて、適切な展開アーキテクチャと運用および保守アーキテクチャを定義および設計できるようになります。

コンテナ クラウド プラットフォームの運用と保守には、サーバー、ストレージ、ネットワーク層、オペレーティング システムなどのインフラストラクチャ リソースの運用と保守だけでなく、コンテナ クラウド プラットフォーム自体の運用と保守、Docker、Kubernetes、イメージ リポジトリ、ポータル、データベース、ETCD、イングレスなどの運用と保守も含まれます。また、ログ、監視、アラーム、認証権限、構成なども含まれます。さらに重要なのは、アプリケーションの運用と保守をサポートすることです。アプリケーションの展開、移行、ヘルス ステータスのチェック、監視、アラーム リマインダー、容量拡張、エラスティック スケーリング、構成の更新、トラフィック分散制御、負荷分散、アクセス制御などはすべて、アプリケーションの運用と保守を提供するコンテナ クラウド プラットフォームの機能です。

（II）運用と保守のツールと手段を明確にする

ソフトウェアの操作とメンテナンスは素手では行えません。効率の面では、ツールの助けを借りた運用とメンテナンスの効率は数倍高くなります。そのため、運用・保守のツールや方法を習得し、使いこなす必要があります。

Google SRE は、実際には運用および保守ツールに特化したチームです。ツールの助けを借りて、運用と保守の効率が向上するだけでなく、システムの安定性と信頼性も向上します。自動化された運用・保守ツール、監視ツール、構成管理ツールなどは、日々の運用・保守プロセスに欠かせません。

（III）運用保守アーキテクチャの選択

システムの運用・保守方法や運用・保守アーキテクチャも異なります。コンテナ クラウド プラットフォームには、従来のシステムの運用や保守とは異なる独自の特性があります。運用・保守担当者にとって、最大の要件は確実性です。コンテナの弾力性、自己回復、自動移行機能は利便性をもたらしますが、不確実性ももたらします。特に巨大なクラウドコンピューティング環境ではそうです。不確実性は運用および保守担当者に大きなプレッシャーを与えます。したがって、運用および保守担当者は、不確実性と不安定性を回避するために適切なアーキテクチャを選択する必要があります。コンテナクラウドプラットフォームとAPIゲートウェイの特性を組み合わせて2層のサービスガバナンスシステムを形成することで、セキュリティと信頼性が向上するだけでなく、コンテナの軽量で弾力的な特性を最大限に活用できます。

4. 開発とテストと運用と保守の違いは何ですか?

運用・保守作業は開発・テスト作業とは異なることは誰もが知っています。開発では俊敏性とスピードを追求するため、近年DevOpsが普及しています。しかし、運用と保守は別の方向かもしれません。運用・保守では安定性と信頼性を追求します。すべての変更にはリスクが伴うため、可能な限り安定している必要があります。しかし、完全な安定性は不可能であり、運用と保守ではコンテナの弾力性と可搬性と非常に一致する動的安定性を実現する必要があります。

5. DevOps と SRE の本質は何ですか?

DevOpsは開発と運用の統合を追求しますが、中国ではDevOpsをどのように実装するかについて真剣に考えた人は多くありません。 Google SRE は非常に良いプラクティスだと思います。開発者が運用やメンテナンスを行う必要はありません。代わりに開発を行う運用保守担当者が多く、開発は運用保守ツールが中心となります。そのため、中国における DevOps の宣伝の多くは、実は非常に一方的なものであることがわかります。それは実用的な要約ではなく、概念の誇大宣伝に基づいています。クラウド コンピューティング環境における現在の運用と保守は、従来のアプリケーション システムの運用と保守とは異なります。現在のアプリケーション システムは、クラウド コンピューティングを基盤として、徐々に統合され、マイクロサービス指向になっています。クラウドは大きなコンテナのようなもので、Docker はこの大きなコンテナ内の小さなコンテナであり、マイクロサービス アプリケーションのアジャイルな展開と柔軟なスケーリング機能を実現します。

そのため、運用保守の焦点は依然としてシステムの安定性を確保することですが、運用保守の効率とシステムの安定性を向上させるために、自分に適した多数の運用保守ツールを採用または独自に開発することに重点が置かれています。

実際、よく考えてみてください。誰が開発し、誰が運用するのでしょうか? 1 人の開発者が開発できるサービスとアプリケーションの数はいくつですか?開発と運用の作業負荷は基本的に2:8です。そのため、開発者が運用・保守も行うと、運用・保守に囚われてしまい、効率性を発揮できなくなります。

2. 運用・保守アーキテクチャ設計

上記の考え方に基づいて、コンテナ クラウド プラットフォームの運用保守アーキテクチャをどのように設計すればよいでしょうか。まず、イメージリポジトリは神のような存在であり、イメージリポジトリをうまく活用することで多くの労力を節約できます。

（I）画像リポジトリの役割

イメージ リポジトリは、異なるクラスター、または異なるコンテナー クラウド プラットフォームに対して同時に構成できます。これらのクラスターとプラットフォームは同じイメージ リポジトリを共有できます。これらの考慮事項に基づいて、コンテナ クラウド プラットフォームのさまざまな環境間の媒体としてイメージ リポジトリを使用します。テスト イメージ ライブラリは開発とテストを分離し、本番イメージ ライブラリはテストと本番を分離します。イメージは、イメージ リポジトリ間で同期したり、ダウンロードおよびアップロードしたりできます。

ミラーリングにより、異なる環境に展開された環境の一貫性が確保されます。アプリケーション配信の標準化が実現しました。イメージを保存するイメージ リポジトリは、標準化された方法でアプリケーションを受信および配布するのに適した場所です。イメージ リポジトリは、開発、テスト、および本番環境を分離するためのトランジット接続ステーションとして使用できるため、セキュリティが向上すると同時に安定性も向上します。

2. SREを実践する

SRE では、開発者の運用能力よりも、運用担当者の開発能力を重視します。つまり、SRE は実際には万能な才能なのです。国内では運用・保守について誤解している人が多く、開発を理解していない人だけが運用・保守を行うべきだと考えています。運用・保守の効率をいかに向上させるかは、運用・保守担当者が留意すべき課題です。ツールの使用と自動化は、運用と保守に必要な手段です。専門スタッフがより専門的な業務を行えるように、リソースの運用と保守はアプリケーションの運用と保守から分離されています。

（III）運用と保守の階層化

運用保守の内容から、運用保守は、インフラストラクチャリソースからプラットフォームやアプリケーションの保守まで、運用保守担当者の業務内容であることがわかります。そのため、運用・保守担当者が膨大な量のコンテンツを維持するのは困難な場合が多くあります。したがって、運用と保守の内容を、インフラストラクチャ リソース、プラットフォーム、アプリケーションなどのさまざまなレベルに分割する方がよいアプローチです。これにより、運用・保守担当者は業務に集中でき、より良いサービスを提供できるようになります。

（IV）インターフェースの標準化

効率的にコラボレーションを行うには、標準化されたインターフェースを定義する必要があります。インフラストラクチャ リソース チームがインフラストラクチャ リソース サービスを提供するのと同様に、アジャイルな拡張や動的な容量拡張を実現するには、標準化された仮想マシン インターフェイス サービス (クラウド管理プラットフォームによって実装) が必要です。

(V) プロセス自動化

運用保守アーキテクチャにおいて運用保守の効率を向上させるためには、運用保守プロセスの自動化を検討し、人的関与や介入を減らすことが必要です。たとえば、仮想マシンを申請する場合は、承認ノードが多すぎないようにします。完全に自動化されています。 IP アドレスセグメント、仮想マシン構成、オペレーティングシステムパラメータ調整などは、仮想マシンの容量を拡張する前にすべて定義でき、さまざまなニーズに応じて自動的に作成および割り当てられます (ルール定義に従って自動的に作成されます)。

6. リソース操作とアプリケーション操作を分離する

リソースの運用と保守は比較的単純で、サーバー、ネットワーク、ストレージ、仮想化、ハイパーコンバージェンスなど、一般的に使用するインフラストラクチャ リソースを運用および保守するものです。これらのタスクのほとんどは比較的標準化されており、通常は自動化できます。開発作業量は多くなく、基本的に必要なのは監視と管理システムだけです。ただし、マルチクラウド リソース管理の需要が高まるにつれて、マルチクラウド リソース管理はより複雑になる可能性があります。

リソースの運用と保守には、ネットワーク、ストレージ、仮想化などのさまざまな専門職の人員も必要です。これらの人員は、インフラストラクチャ リソースの保守に重点を置き、コンテナ クラウド プラットフォームまたはコンテナ化された PaaS プラットフォームのリソース サービスを提供します。

（VII）アプリケーションの運用と保守が中核となる

私たちは常に、アプリケーションの運用と保守こそがコンテナ クラウド プラットフォームの中核であると信じてきました。最終的にはビジネス アプリケーションに役立つからです。アプリケーションの運用と保守は通常、R&D チームのサポートを受けて、プラットフォームが提供するアプリケーション管理機能を使用してビジネス アプリケーション ユーザー チームによって実行されます。コンテナ クラウド プラットフォームの機能が鍵となります。コンテナ クラウド プラットフォームが完全な展開、監視、柔軟な拡張、グレースケール、負荷戦略、アクセス制御、統計クエリなどの機能を提供できる場合、アプリケーションの運用および保守担当者にとって運用と保守の作業が非常に簡単になります。

8. アプリケーションの運用と保守のためのプラットフォームとコンポーネントのサポート

コンテナ クラウド プラットフォームの機能は、プラットフォームとその周辺コンポーネントによって実現される機能にあります。アプリケーションの運用と保守のニーズをより適切にサポートするには、プラットフォームとコンポーネントを継続的に改善し、最適化する必要があります。これがコンテナ クラウド プラットフォームの運用と保守の焦点であると考えます。コンテナ クラウド プラットフォームの運用および保守チームは、コンテナ クラウド プラットフォームの運用および保守を最適化するために、運用および保守ツール、プロセス、および方法を継続的に開発および構築する必要があります。

(IX) マイクロサービスアーキテクチャ: マイクロサービスのガバナンスは難しい

アプリケーションの運用と保守において、マイクロサービス アーキテクチャではサービス ガバナンスが難しい点となる場合があります。マイクロサービス アーキテクチャにより、サービスの運用と保守が複雑になります。サービスの展開、移行、弾力的なスケーリング、トラフィック分散、内部および外部の負荷分散、高可用性、安定性などの要件により、コンテナ クラウド プラットフォームでサポートされるアプリケーションの運用および保守機能に対する要求が高まります。どのようなマイクロサービス アーキテクチャを選択するか、マイクロサービスをより適切に管理および制御する方法は、コンテナ クラウド プラットフォームが考慮しなければならない重要な問題です。たとえば、springcloud 開発フレームワークを使用するなどして、登録検出がマイクロサービスに実装されている場合、一連のサービス ガバナンス メソッドがすでに存在します。コンテナ クラウド プラットフォームとどのように統合すればより良くなるでしょうか?開発されたマイクロサービスは、登録検出、トラフィック制御、サーキットブレーカー、およびデグラデーションのメカニズムを独自に実装する必要がありますか、それともコンテナ クラウド プラットフォーム上に簡単に実装できますか?

応答時間に基づいて容量を弾力的に拡張する必要があります。 CPU メモリは不正確なため、弾性スケーリングの指標として CPU メモリを使用しませんでした。 Java メモリ メカニズムはメモリ モードに適しておらず、CPU の変化が速すぎます。時間が長くなると、遅延やタイムアウトが大量に発生する可能性があります。したがって、容量拡張の指標としては、応答時間を使用する方が比較的適切です。次に、これをサービス ゲートウェイ、コンテナ クラウド プラットフォーム、または API ゲートウェイに実装する必要があります。サービス ゲートウェイは開発者自身が実装する必要があり、各チームがそのようなゲートウェイを展開する必要があるため、明らかに不適切です。このような機能をコンテナ クラウド プラットフォームに実装すれば、各サービスを直接利用できるようになります。標準化が形成されました。

そのため、コンテナ クラウド プラットフォーム上でサービス ガバナンス機能を強化でき、開発作業負荷を軽減できるだけでなく、運用保守の効率が向上し、運用保守の難易度も軽減されます。

（X）二層統治システム

サービス ガバナンスをコンテナ クラウド プラットフォーム層と API ゲートウェイ層に分割すると、仮想化展開と物理サーバー展開に対するアプリケーション サービス ガバナンスのニーズを維持しながら、コンテナの特性をより有効に活用できます。

従来の企業がクラウドに移行する過程では、コンテナ化に適さない、または現段階では完全にコンテナ化できないシステムがまだ多く存在します（安定性が最も重要です）。したがって、マイクロサービス アプリケーションをより適切に管理および保守するために、API ゲートウェイを使用して 2 層のマイクロサービス ガバナンス システムを実装することを検討できます。

一般的に、コンテナ クラウド プラットフォームとは、「イメージ リポジトリを媒体として開発、テスト、運用保守を分離し、アプリケーション管理を中核として、リソースの運用保守、プラットフォームの運用保守、アプリケーションの運用保守を分析し、コンテナの利点を生かすだけでなく、その弱点を可能な限り回避するコンテナ クラウド/API ゲートウェイの 2 つのサービス ガバナンス システムを実現するもの」と定義されます。