ヘッドpicture.png

クラウドネイティブDevOpsとは

クリックしてビデオを表示：https://v.qq.com/x/page/u3220cutt7v.html

まず、上記の短いビデオと次の2つの写真を使用して、クラウドネイティブのDevOpsとは何か、およびDevOpsとの違いを理解しましょう。

上の写真は屋台です。写真のシェフは、カット、フライ、各種フードの製作、販売に一生懸命取り組んでいます。原材料の購入から加工、販売、アフターセールスまで、1〜2名で完了します。これは非常に典型的なDevOpsシナリオであり、チームはすべてをエンドツーエンドで処理します。この場合、シェフのレベルが比較的高く、販売能力が高い場合、高効率、低廃棄物を実現できます。しかし、問題はスケーリングが難しいということです。そのプロセスは非標準であるため、シェフには強い個人的な能力が必要です。

上の南京屋台の写真を見てみましょう。名前には屋台がありますが、それは明らかに上記の屋台ではありません。南京の屋台に足を踏み入れると、南京の屋台のシェフは、顧客により良い料理を提供し、新しい料理を開発してテストし、少数のユーザーを通じてそれらを宣伝することに集中できることがわかります。ユーザー数が増減しても、すぐに適応できます。ショップの拡大も迅速に行うことができます。これは、クラウドネイティブのDevOpsとして理解できます。

では、クラウドネイティブのDevOpsとは正確には何ですか？クラウドネイティブのDevOpsは、マイクロサービス/ノーサービスアーキテクチャシステムとオープンソース標準に基づいて、言語やフレームワークに依存せず、継続的な配信とインテリジェントな自己運用および保守機能を備えたクラウドネイティブインフラストラクチャを最大限に活用して、従来のDevOpsよりも高いレベルを実現すると考えています。サービス品質と開発および運用コストの削減により、R＆Dは迅速なビジネスの反復に集中できます。

上の図に示すように、クラウドネイティブのDevOpsは、オープンスタンダードへの準拠、言語とフレームワークの独立性、2つの基盤：マイクロサービス/ノーサービスアーキテクチャ、サーバーレスインフラストラクチャBaaS / FaaS、2つの機能：インテリジェントな自己運用と保守の2つの原則に基づいています。、連続配信。

2つの原則：オープンスタンダードへの準拠、言語、フレームワークは何の関係もありません。特定の言語および特定のフレームワークと比較して、テクノロジーのアップグレードまたは反復時に、より高い柔軟性、より優れた開発および活力を持ち、より優れたエコロジーを形成することができます。
2つの基盤：マイクロサービスとノーサービスアーキテクチャに基づいて、DevOpsを可能にすることができます。サーバーレスベースのインフラストラクチャは、リソース指向と需要指向であり、柔軟性が向上します。
これらの2つの原則と2つの基盤に基づいて、継続的な配信とインテリジェントな自己運用および保守という2つの機能が実現されます。

アリババクラウドネイティブDevOpsアップグレードケース

まず、AlibabaチームのクラウドネイティブのDevOps変換のケースを見てみましょう。事例の背景：アリの海外eコマースチームは、多くのサイト、高いサイト建設コスト、迅速な需要の変化、遅い配信、高い運用および保守コストなど、海外市場で多くの課題に直面しています。これらの問題を解決し、ビジネス配信効率を向上させるために、クラウドネイティブのDevOpsにスムーズにアップグレードする方法何？これが私たちの仕事です。

1.アーキテクチャのアップグレード-サービスガバナンスのサイドカーとメッシュ

最初のステップは、アーキテクチャをアップグレードすることです。最初に、サービスガバナンスコードをアプリケーションの外部のサイドカー部分に沈め、同時に、サービスグリッドを使用して環境ルーティングなどの機能を実行します。上の図に示すように、緑色の点はサービスアプリケーションコードを表し、オレンジ色の点はサービス管理コードを表します。これらのコードは、2者間パッケージの形式でこのコンテナに格納されます。サービスガバナンスシステムの構築に伴い、ログの収集、埋設ポイントの監視、運用と保守の介入など、多くのことが含まれています。この種のコンテナリッチコンテナと呼ばれます。問題は明らかです。ログ収集のアップグレードまたは調整であっても、アプリケーションを再度アップグレード、ビルド、およびデプロイする必要があります。ただし、これはアプリケーション自体とは何の関係もありません。同時に、懸念事項が分離されていないため、ログ収集のバグがアプリケーション自体に影響を与えます。

アプリケーションがアプリケーション自体にさらに集中できるようにするために、最初に行ったのは、すべてのサービスガバナンスコードをアプリケーションコンテナから分離してサイドカーに配置し、2つのサービスガバナンスコードとアプリケーションコードがあるようにすることでした。コンテナ内。同時に、テストルーティングやリンクトラッキングなど、元のサービス管理タスクの一部をメッシュサイドカーに引き渡しました。このように、アプリケーションはスリムであり、アプリケーションはアプリケーションコード自体を気にするだけで済みます。

これの利点は、サービスガバナンスに依存することなく、ビジネスがビジネス関連のアプリケーションコードに集中できることです。

これは最初のステップであり、1回の移行のコストを気にすることなく、サービスガバナンスをサイドカーに徐々に移行できるため、このステップはスムーズです。

2.アーキテクチャのアップグレード-構造のデカップリング、リリースのデカップリングから運用および保守のデカップリングへ

2番目のステップでは、3つのレベルのデカップリングを実行しました。構築デカップリング、リリースデカップリング、および運用と保守のデカップリングです。

マイクロサービスとサービスレスアーキテクチャを理解している人は、ビジネスを独立して開発、テスト、リリース、および運用できる場合にのみ、ビジネスをより速く、より良く実行できることを知っておく必要があります。これは他の人との結合を最小限に抑えるためです。しかし、サービスがますます複雑になり、アプリケーションが進化し続けるにつれて、アプリケーションに含まれるビジネスコードが増えることもわかっています。たとえば、次の図のアプリケーションでは、その中の一部のコードは特定のビジネス用です。たとえば、支払いアプリケーションとして、一部はHemaの特定のニーズ用、一部はTmallの特定のニーズ用、一部は一般的なコードです。、またはプラットフォームコードは、すべてのビジネスシナリオに対応しています。

もちろん、開発効率の向上という観点から、ビジネスパーティは関連するビジネスコードを変更して、通信コストを削減し、R＆D効率を向上させることができます。しかし、これは新しい問題を引き起こします。特定のビジネスに変更が必要であるが、一般的なビジネスロジックが含まれていない場合は、アプリケーション全体のすべてのビジネスに完全に戻る必要もあります。この期間中に他のビジネスの変更がある場合は、彼らは一緒に統合して公開する必要があります。ビジネスに多くの変更がある場合は、統合のために全員が列に並ぶ必要があります。この場合、統合テストと通信および調整のコストは非常に高くなります。

私たちの目標は、各事業を独立して開発、リリース、運営できるようにすることです。この目標をスムーズに達成するために、私たちが最初に行う必要があるのは、建設段階でそれらを切り離すことです。たとえば、比較的独立したビジネスの場合、コンテナイメージとして個別に作成し、オーケストレーションによってポッドの初期コンテナに配置します。ポッドが起動すると、メインアプリケーションコンテナのストレージスペースにマウントされます。

しかし、現時点では、アプリケーションのリリースと運用および保守はまだ一緒であるため、それらを分離する必要があります。

アプリの親密さは、大きく3つのカテゴリに分類できることがわかっています。

同じプロセスで、関数呼び出しを介した通信が非常に近くなります。
同じポッドにある異なるコンテナは、IPCを介して通信します。
それらは同じネットワーク内にあり、RPCを介して通信します。

一部のビジネスコードは、ビジネスの特性に応じてRPCサービスまたはIPCサービスに段階的に分割できるため、独立してリリースおよび運用できます。

これまでに、アプリケーションコンテナの構築デカップリング、リリースデカップリング、および操作とメンテナンスのデカップリングを完了しました。

3.IACとGitOps

3番目のステップでは、開発、運用、および保守のステータスを確認します。多くのR＆Dシナリオでは、厄介な問題は次のとおりです。さまざまな環境やビジネスには独自の構成が多数あります。リリース、運用、および保守中に、状況に応じて正しい構成を変更および選択する必要があります。この構成とアプリケーションコードこれは実際にはリリース自体の一部であり、コンソールを介した従来のメンテナンスのコストは非常に高くなります。

クラウドネイティブのコンテキストでは、IaC（コードとしてのインフラストラクチャ）とGitOpsがより良い選択であると考えています。各アプリケーションのコードベースに加えて、IaCリポジトリもあります。このリポジトリには、アプリケーションのイメージバージョンと関連するすべての構成情報が含まれます。コードの変更をリリースする必要がある場合、または構成の変更が必要な場合、それらはすべてコードプッシュの形式でIaCウェアハウスにプッシュされます。GitOpsエンジンは、IaCの変更を自動的に検出し、それらをOAM仕様に準拠する構成に自動的に変換してから、OAMモデルに基づいて対応する環境に変更を適用できます。開発であろうと運用と保守であろうと、IaCコードバージョンを通じてシステムにどのような変更が発生したかを知ることができ、各リリースは完了しています。

4.リソースのBaaS化

最後のステップは、リソースのBaaS化です。

アプリケーションでリソースを使用する方法を想像してみましょう。通常、最初に対応するコンソールに移動してリソースアプリケーションを送信し、必要なリソースの仕様と要件を記述し、承認に合格した後、リソースの接続文字列と認証情報を取得します。アプリケーションの構成にリソース構成を追加します。その後に変更があった場合は、対応するコンソールに移動して操作し、コードリリースに協力して承認を受けます。もちろん、そのようなリソースの操作、保守、および監視は、通常、独立したコンソールで実行されます。

リソースの種類が増えると、特に新しいサイトを構築する場合、運用と保守のコストが非常に高くなります。

リソースを宣言的に記述し、オンデマンドで使用するという原則に基づいて、これらのリソースをIaCで定義し、すべてのアプリケーションによるリソースの使用を簡素化します。すべてのリソースは宣言的な方法で記述され、インテリジェントな管理とリソースのオンデマンド使用を可能にします。同時に、すべてのリソースがクラウド上の共通のリソースと標準プロトコルを使用するため、移行コストが大幅に削減されます。このようにして、ビジネスチームをクラウドネイティブインフラストラクチャに徐々に移行します。

したがって、リソースBaaS化の2つの重要なポイントは次のとおりです。

リソース要件を宣言的に記述し、インテリジェントに管理し、オンデマンドで使用します。
クラウド上の共通のリソースを使用して、標準プロトコルを調整します。

クラウドの効率化により、クラウドネイティブのDevOpsの効率的な実装が促進されます

上記で共有したのは、Aliの内部プラクティスであり、Aliの内部R＆DコラボレーションプラットフォームAoneに依存しています。AoneのパブリッククラウドバージョンはAlibabaCloudCloudです。アリババクラウドクラウドエフェクトを介してクラウドネイティブのDevOpsを実装するにはどうすればよいですか？

前のケースから、クラウドネイティブのDevOpsの実装は、メソッド、アーキテクチャ、コラボレーション、エンジニアリングを含む体系的なプロジェクトであることがわかります。その中で、クラウドネイティブのDevOpsの実装は、リーンデリバリーのカテゴリに属します。

上の図は、クラウド効果のクラウドネイティブDevOpsソリューション図です。

ここでは、ユーザーを2つの役割に分けます。

テクニカルリードまたはアーキテクト。
開発、テスト、運用、保守などを含むエンジニア。

テクニカルディレクターまたはアーキテクトとして、彼は企業全体のR＆D動作を定義および制御する必要があります。広い観点から、R＆Dプロセスには、操作可能、監視可能、管理可能、および変更可能の4つの側面が含まれます。

まず、機敏なR＆Dを採用するか、無駄のないかんばんを採用するかなど、同社のR＆Dコラボレーションモデルを定義します。次に、使用する必要のあるクラウド製品や、これらのクラウド製品の調整方法や管理方法など、製品アーキテクチャ全体を習得する必要があります。次に、チームのR＆Dモデルを決定します。R＆Dコラボレーションの方法、R＆D品質の制御方法などです。3番目のステップでは、リリース戦略、グレースケールリリースとブルーグリーン展開のどちらを使用するか、グレースケール戦略とは何かなどを決定する必要があります。最後に、サービスがアクセスする必要のある監視プラットフォーム、サービスステータスの検出方法、グローバル監視構成など、サービスの監視戦略です。

最前線の開発、テスト、運用および保守のエンジニアは、作業プロセスの円滑さと効率に重点を置いています。クラウドエフェクトプロジェクトコラボレーションプラットフォームが要件またはタスクを受け取った後、クラウドエフェクトを介してコーディング、送信、構築、統合、リリース、およびテストし、プレリリースおよび本番環境にデプロイし、管理者がR＆Dモードとリリースを構成できます。戦略は本当に上陸しました。同時に、人間の調整やプルなしで、各環境が自動的にトリガーされ、フローされます。

R＆Dプロセス全体で生成されるデータは有機的な全体であり、大量のデータインサイトを生成し、チームを継続的な改善に駆り立てることができます。チームがR＆Dプロセスでボトルネックや混乱に遭遇した場合、クラウド効率の専門家チームから専門的な診断アドバイスやR＆Dガイダンスを得ることができます。

要約すると、Cloud EfficacyのクラウドネイティブDevOpsソリューションは、専門家が推奨するベストプラクティスに基づいて、ALPD手法によって導かれ、完全なDevOpsツールチェーンに深く統合されて、企業がクラウドネイティブDevOpsに徐々に移行できるようにします。

次に、特定のケースを見ていきます。

インターネット会社には約30人のR＆Dチームがあり、専任の運用および保守担当者はいません。その製品には、20を超えるマイクロサービスと数十のフロントエンドアプリケーション（Web、Applet、アプリなど）が含まれています。そのビジネスは非常に急速に成長しています。急速に成長する顧客と増大する需要に直面して、Jenkins + ECSに基づく元のスクリプトベースの展開方法は、需要、特にゼロダウンタイム展開アップグレードの問題を徐々に満たすことができませんでした。。その結果、私はクラウド効率の助けを必要とし始め、最終的にクラウド効率クラウドネイティブDevOpsに完全に移行しました。

このR＆Dチームは、次の3つの大きな問題に直面しています。

多数のお客様と多くの緊急のニーズ。
フルタイムの運用と保守はなく、K8などのクラウドネイティブテクノロジーには高い学習しきい値があります。
ITインフラストラクチャは複雑で、リリースに時間がかかり、手間がかかります。

これらの問題に対応して、クラウドの効率はから始まる：三つの側面の基本的な機能、解除機能、および運用・保守機能。

まず、Alibaba Cloud ACKを導入して、既存のECSリソースの上にインフラストラクチャをアップグレードし、アプリケーションをコンテナ化に変換します。サービスガバナンスとアプリケーションアーキテクチャに関しては、Spring CloudファミリバケットはSpringBootに単純化されており、サービスの検出とガバナンスはK8の標準機能によってサポートされています。

第二に、自動コンテナ展開はクラウド効果パイプラインを通じて実現され、グレースケール展開戦略を使用して、グレースケールオンライン、自動拡張、および障害発生時の自動再起動を実現できます。同時に、クラウド効率パイプラインに基づいて、ダウンタイムをゼロにし、コストを迅速にロールバックして、マシンコストを節約できます。同時に、企業内に常勤の運用・保守要員がいないという問題も解決されます。

第三に、クラウド効率の自動化された組立ラインとブランチ保護の標準的な研究開発モデル（コードレビュー、コード検査、テストカードポイントなど）を通じて、フィードバック効率とリリース品質を向上させます。

次の図は、ソリューション全体のアーキテクチャ図です。

クラウドネイティブDevOpsアップグレードパス

クラウドネイティブDevOpsの実装を5つの段階に分けます。

最初の段階：すべての手動配信と操作および保守。これは私たちの初期段階です。アプリケーションアーキテクチャはまだサービスの変革を受けておらず、クラウドインフラストラクチャやIaaSのみを使用していません。継続的な統合、テストの自動化、手動による展開、リリース、手動による操作と保守はありません。この段階にとどまっている企業は少ないと思います。

第2段階：ツールベースの配信と操作および保守。最初に行うことは、アプリケーションアーキテクチャを提供し、マイクロサービスアーキテクチャを使用してサービス品質を向上させることです。次に、gitlab、jenkins、その他のアイランドスタイルツールなどのR＆Dツールを導入して、いくつかの問題を解決します。同時に、単一モジュールの継続的な統合の実装を開始しましたが、通常、自動化された品質の行き詰まりはなく、リリースは自動化されたツールによって支援されることがよくあります。

第3段階：限定された継続的な配信と自動化された操作とメンテナンス。基本機能をさらに改善し、インフラストラクチャをCaaSベースのコンテナに変換しました。一方、クラウドエフェクトDevOpsなどのツールプラットフォームを使用してすべてのデータの完全な相互運用性を実現するなど、研究開発データを開くための完全なツールチェーンの導入を開始しました。リリース機能の観点からは継続的な展開を実現できますが、ある程度の手動介入が必要です。現時点では、自動テストが主流になり、サービス全体を監視でき、運用と保守はサービス指向で宣言的である可能性があります。

第4段階：継続的な配送と手動の操作とメンテナンス。さらに、開発学生にビジネス開発に集中してもらいます。まず、アプリケーションアーキテクチャに多数のサービスレスアーキテクチャを採用し始め、無人の継続的な展開を実現しました。リリースのグレースケールとロールバックは、介入によって可能な限り自動化できます。。観察能力は、アプリケーションレベルからビジネスレベルにアップグレードされ、ビジネスの観察可能性を実現し、手動の支援で自己運用と保守の一部を実行できるようになります。

第5段階：リンクを介した継続的な配信と自己運用および保守。これが私たちが求める究極の目標です。この段階では、すべてのアプリケーションとインフラストラクチャがサービスレスアーキテクチャを採用し、リリースロールバックやグレースケールを含むエンドツーエンドの無人連続配信も自動化されています。技術的な設備とサービスは完全に自己運用され、維持されています。。開発者は、実際にはビジネスの開発と反復についてのみ気にする必要があります。

しかし、詳細には悪魔がいます。もちろん、実際に着陸するときに解決しなければならない問題はまだたくさんあります。CloudEffectなどのツールプラットフォームとALPDの専門家による相談の助けを借りて、迂回を回避し、目標をより早く達成できます。。

クラウドネイティブDevOpsの5ステップのアップグレードパス