この記事では、エンタープライズ レベルのアプリケーション コンテナー化の変換に関するすべての必要な理論的知識と、クラウド ネイティブな変換のパスを明確に計画する方法を理解し、コンテナー化の変換を適切に行う方法を説明します。
コンテナ化のターゲットとパス
ご存知のように、企業のデジタルトランスフォーメーションは主にビジネス価値を目的としています.各企業の独自性のため、参照用に完全に一致する経験を見つけることは通常困難です.アプリケーションアーキテクチャは大きな影響をもたらしました.多数の新しいアプリケーションの導入は、元のエンタープライズ アーキテクチャの断片化にもつながります.したがって、さまざまなアプリケーションの特性に応じて、アプリケーションは再編成され、異なる方法で処理されます.この問題を解決するために、新しい世代のデュアル-ダイナミックIT アーキテクチャは、時代の要請に応じて出現します。
2 状態の IT アーキテクチャには、主に 2 つの部分が含まれます。定常状態のビジネスと定常状態のビジネスです。機密性の高いビジネスは、ビジネスの収益性に直接関係することが多く、ユーザーのニーズに合わせて変化し続けるため、機敏性とスピードを重視して、ビジネスの急速な多様性を満たすことに注意を払います。定常業務は通常、CRM、ERP、OA など、正確性、信頼性、安定性を重視するサポート業務です。
同時に、ビジネス アプリケーションの継続的な進化をサポートすることも、コンテナ化の主要な目標の 1 つです。企業の基盤となるインフラも本来のネットワーク機器＋サーバから仮想化、さらにコンテナ化へと移行し、それが支える上位層の業務アプリケーションの形態もそれに合わせて変化し、従来のモノリシックなアプリケーションから徐々にモダナイゼーションの時代に RPC/SOA アプリケーションを仮想化し、クラウドネイティブ時代にマイクロサービス アプリケーションに変換します。仮想マシンの時代に多くの企業がマイクロサービスの変革を実行した可能性がありますが、そのメリットは明らかではありません。アプリケーションはすでに独立したエンティティですが、柔軟なスケーリングなどの非常に高い容量要件が依然としてあります.現時点では、コンテナーの助けを借りて実現する必要があります.2つの組み合わせにより、マイクロサービスの利点を真に引き出すことができます. DevOps プラットフォームと組み合わせることで、機密性の高いビジネスの拡大と生産効率の向上をよりよく実現できます。
さらに、コンテナ化のもう 1 つの利点は、システム化からプラットフォームへの進化を促進することです。クラウドネイティブ テクノロジーの高い学習コストにより、ますます多くの企業がすぐに使用できるものを採用しています。柔軟で制御可能なワンストップのフルスタック クラウドネイティブ プラットフォームにより、企業はもはやコンテナとマイクロサービス技術の詳細. 一連のプラットフォームは、運用と保守のための本番対応のマイクロサービス インフラストラクチャ、ガバナンス、運用、およびベスト プラクティス環境を提供します。
クラウドネイティブ申請書
クラウド ネイティブのアプリケーション フォームには、主に次のカテゴリが含まれます。
・ミドルウェアアプリ
MySQL、Redis、RabbitMQ、MongoDB、Kafka。このタイプのアプリケーションは、クラウド ネイティブ プラットフォームのアプリケーション フォームです. コンテナ プラットフォームにある場合もあれば、元の仮想マシン、他のパブリック クラウド、その他の従来のインフラストラクチャ リソースにある場合もあります. データ サービスと呼びます.アプリケーションに持続性サポートを提供するために使用されます。
· ワークロード
ワークロードとは、Deployment、StatefulSet、DaemonSet、CronJob などを含む、K8 でのワークロードを指します。
・抽象モデル
通常、アプリケーションのデプロイ時には、抽象化のカプセル化または定義が必要です。具体的には、アプリケーションは通常アプリケーション システムを指し、アプリケーション システムには独自のフロントエンド、バックエンド、ミドルウェア、構成ファイル、ネットワークなどがあります。もちろん、顧客環境が異なれば、定義も異なる場合があります.たとえば、マイクロサービス チームによって定義されたアプリケーションは、ワークロード、ガバナンス機能などをカバーするマイクロサービス アプリケーションです。上記の抽象モデルの定義により、OAM アプリケーション、マイクロサービス アプリケーション、およびネイティブ アプリケーションが派生します。
・管理区分と組織体制
1 つのプラットフォームが複数のアプリケーションをサポートし、1 つのアプリケーションが複数のクラスターをサポートし、クラスターは運用クラスター、テスト クラスター、災害復旧クラスターなどの異なる管理パーティションに分割されます。組織構造層のビジネス システムは、複数のクラスターにまたがり、さまざまなプロジェクトにリソース クォータを設定して割り当て、さまざまなプロジェクトの下で独立して開発および保守できます。
クラウドへの適用のクリティカル パス
企業がクラウドに移行するパスは、さまざまなアプリケーション資産の形態とクラウドに移行した後に予想される目標に基づいて包括的に分析および評価し、適切な変換モデルを決定してから、対応するソリューションと環境を採用する必要があります。クラウドへのアプリケーションには 6 つの変換モードがあります。
カプセル化:革新的なアプリケーションが呼び出す API を直接公開します. これは、すべてのアプリケーションに適用可能なモードでもあります. アプリケーションを移行するのではなく、古いアプリケーションの API のみを新しいアプリケーションに公開することに相当します.
再ホスト:変更なしでクラウドに移行します。ここには 2 つの状況があります. 1 つ目は、元のアプリケーションを変更する必要がない場合です. たとえば、元のアプリケーションはコンテナー化されたアプリケーションであり、クラウドに直接移行できる場合です. 2 つ目は、変更する時間がない場合です.多くのエンタープライズ プロジェクトでは、変革に時間がかかります. アーキテクチャの変革とマイクロサービスの分割の時間がない場合は、コンテナを仮想マシンとして直接使用できるため、コンテナ プラットフォームを DevOps に使用しやすくなります. 、企業の機敏な運用を加速し、その後の単一アプリケーションの変換を容易にします。ただ効果やメリットがはっきりしないだけで、クラウドの利便性を十分に享受することは困難です。
プラットフォームの再構築:クラウドの利点のいくつかを使用して、コンテナ化などの小さな変換を実行します. たとえば、企業は、コンテナを外部化または非表示にすることにより、コンテナによってもたらされる利点を実現できます. 並行ビジネスシナリオでの自動拡張と縮小により、システムの柔軟性が向上し、耐障害性。
リファクタリング:クラウドネイティブの利点を利用した部分的なリファクタリング。このパートでは、主にマイクロサービスの変換について説明し、ビジネス アプリケーションをどのように分割するかを検討します。
再構築:クラウドネイティブ アーキテクチャを使用してアプリケーションをリファクタリングします。アプリケーション自体のコンテナ化やマイクロサービス化を考えるだけでなく、クラウドネイティブなミドルウェアも総合的に考え、アーキテクチャ全体から再設計・構築する必要があります。
再構築:新しいクラウドネイティブ アプリケーションを構築します。包括的なクラウド ネイティブ化により、企業はクラウド ネイティブのコスト削減と効率の向上という技術的な利点をより早く享受できます。
全体として、多くのビジネス アプリケーションは、コードを変更することなく、スムーズなクラウド ネイティブな変換を実現できます。企業は、自身のビジネス ビジョン、入出力、アジャイル デリバリ、サービス レベル、変革サイクルなどの目標に基づいて、全体的な考慮と合理的な計画を立てる必要があります.最初にクラウドに移行し、次に徐々に変革することをお勧めします.クラウド ネイティブの利点を早期に活用し、企業により大きな価値をもたらします。
企業がクラウドネイティブに移行するための重要なステップ
最初のステップは、エンタープライズ レベルのコンテナー クラウド プラットフォームの構築を優先することです。従来のアプリケーションからマイクロサービス アプリケーションまで、すべてをホストするプラットフォームを提供します。アプリケーションのモダナイゼーションにより、既存のミドルウェアのコンテナー化が可能になります。
2 番目のステップは、クラウドネイティブ アプリケーション開発を革新することです. 新しい技術スタックを使用して新しいビジネスを直接開発することをお勧めします. 当初から、マイクロサービス、DevOps、API などのアジャイル テクノロジ フレームワークを使用して、クラウドネイティブ アプリケーションを構築します.歴史的な負担のないエンタープライズ レベルのクラウド プラットフォームで。
3 番目のステップは、既存のアプリケーションをクラウドに移行することです。分析と評価の後、元のシステム アプリケーションを分類し、段階的に移行します。
4 番目のステップは、マルチクラウド アプリケーション管理を実現することです。新旧のアプリケーションがすべてクラウド化された後、企業はマルチクラウド管理の問題に直面することになります.このとき、企業は運用と保守のレベルに焦点を当て、テクノロジーをビジネスから分離する必要があります. マルチクラウド アプリケーションの完全なライフサイクル管理を実装するには、アプリケーションを複数のクラウド環境で実行する必要があります。
クラウドへの移行に適したアプリケーションは?
全体として、すべてのアプリケーションをクラウドに移行できますが、企業は合理的な計画を立てるために、既存のアプリケーションをクラウドにアップグレードするコストと利点を包括的に検討する必要があります。クラウドへの適用の原則は、主に次の 3 つのカテゴリに分類できます。
最初のカテゴリー、優先クラウド
· コンテナ化されたアプリケーション
・ マイクロサービスアーキテクチャの適用
· ステートレス アプリケーション
2 番目のカテゴリは、クラウドに移行することをお勧めします
障害の自己修復、柔軟なスケーリング、迅速な反復機能を必要とするアプリケーション
· Tensoflow などの AI アプリケーション、GPU 集約型アプリケーションなど。
3 番目のカテゴリはさらに検討する必要があります
· テクニカル サポートのないメンテナンスされていないブラックボックス アプリケーション
・ ヘビーリソース申請
・ Uシールドなど特殊プラグイン用途あり
· オペレーティング システムに特別な要件があるアプリケーション
クラウド上で優先されるアプリケーションを判断するための基準はありますか?
コンテナ化された変換の実装における Lingqueyun の長年の実務経験に基づいて、優先クラウド アプリケーションの条件を次のようにまとめました。
· 明確で自動化されたコンパイルおよびビルド プロセスが確立されている
Maven、Gradle、Make、Shell などのツールを使用して、ビルドおよびコンパイルの手順を自動化すると、コンテナー プラットフォームでの自動コンパイルおよびビルドに便利です。
・アプリケーション設定パラメータの外部化を実現
アプリケーションでは、構成パラメーターが構成ファイルまたは環境変数に外部化されているため、アプリケーション コンテナーはさまざまな動作環境に適応できます。
・合理的で信頼性の高いヘルスチェックインターフェースが提供されています
コンテナー プラットフォームは、ヘルス チェック インターフェイスを通じてコンテナーの状態を判断し、アプリケーション サービスの状態を維持します。
・状態の外部化を実現し、ステートレスなアプリケーションインスタンスを実現
アプリケーションの状態情報は、データベースやキャッシュなどの外部システムに保存され、アプリケーション インスタンス自体はステートレスです。
基盤となるオペレーティング システムの依存関係や複雑なネットワーク通信メカニズムは関与しません。
アプリケーションは主にビジネスを扱い、移植性を向上させるために、基盤となるオペレーティング システムやマルチキャストなどのネットワーク通信メカニズムに強く依存していません。
· 展開の成果物は大きすぎてはならず、2G 以内にすることをお勧めします
軽量アプリケーションは、大規模なクラスターでの迅速な送信と配布を容易にします。これは、軽量で機敏なコンテナーの概念により近いものです。
・起動時間は長すぎず、5分以内がおすすめ
起動時間が長すぎると、コンテナーの機敏な機能を利用できなくなります。これらのアプリケーションは、重すぎるため、多くの場合、変更が必要になります。
コンテナ化への移行の準備はできていますか?
アプリケーション コンテナ化の変換についてさらに要件がある場合は、アプリケーション コンテナ化の変換のベスト プラクティスを計画し、私たちと話し合うことを歓迎します。