クラウドネイティブ DevOps を実装するには?

[[376328]]

クラウドネイティブ DevOps とは何ですか? Alibaba ではどのように実践されていますか?企業はどのようにそれを実装できるでしょうか? Alibaba Cloud Cloud Effect の専門家チームは、クラウドネイティブ DevOps の実装に体系的な方法サポートを提供し、企業が段階的にクラウドネイティブ DevOps に移行できるように支援する次世代のリーン製品開発方法システムである ALPD を提案しました。この記事では、実際の事例を使用して、Alibaba Cloud Cloud Effect を通じてクラウドネイティブ DevOps を実装する 5 つの段階を紹介します。

クラウドネイティブ DevOps とは何ですか?

まず、簡単な例を使って、クラウド ネイティブ DevOps とは何か、そして DevOps とどう違うのかを理解しましょう。

[[376329]]

上の写真は屋台です。写真のシェフは、さまざまな珍味を切ったり、揚げたり、調理したり、販売したりするために一生懸命働いています。原材料の調達から加工、販売、アフターまで、全て1～2名で行っております。これは、チームがすべてをエンドツーエンドで処理する、非常に典型的な DevOps シナリオです。この場合、シェフのスキルが比較的高く、販売能力が比較的強い場合、高い効率と低い廃棄を実現できます。しかし問題は、規模を拡大することが難しいことです。工程が非標準であるため、シェフには高い個人能力が求められます。

[[376330]]

南京の屋台の写真を見てみましょう。名前に「屋台」という言葉がありますが、明らかに上で述べた屋台ではありません。南京のどの屋台に行っても、そこのシェフたちが顧客により良い料理を提供すること、新しい料理を開発してテストすること、そして少数のユーザーを通じて試食して宣伝することに集中できることがわかります。ユーザー数が増えても減っても、すぐに対応できます。店舗の拡大も迅速に行えます。これをクラウドネイティブ DevOps として理解することができます。

理解をさらに深めるために、次の短いビデオでは、Alibaba のシェフ 2 名を招き、クラウド ネイティブ DevOps とは何かを説明していただきました。

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

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

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

2 Alibaba Cloud ネイティブ DevOps アップグレード事例

まず、Alibaba チームのクラウドネイティブ DevOps への変革のケーススタディを見てみましょう。

事例の背景: Alibaba の海外電子商取引チームは、複数の海外市場サイト、高いサイト構築コスト、需要の急速な変化、遅い納品、高い運用・保守コストなどの課題に直面しています。これらの問題を解決し、ビジネス提供の効率を向上させるために、クラウドネイティブ DevOps にスムーズにアップグレードするにはどうすればよいでしょうか?これが私たちがやったことです。

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

最初のステップはアーキテクチャをアップグレードすることです。まず、サービス ガバナンス コードはアプリケーション外部のサイドカー部分に埋め込まれ、サービス メッシュは環境ルーティングなどの機能を運ぶために使用されます。上の図に示すように、各緑色の点はサービス アプリケーション コードを表し、各オレンジ色の点はサービス ガバナンス コードを表します。これらのコードは、セカンドパーティ パッケージの形式でこのコンテナー内に存在します。サービスガバナンスシステムの構築には、ログ収集、監視ポイント、運用保守介入など、多くのものが含まれます。このようなコンテナをリッチコンテナと呼びます。問題は明らかです。ログ収集をアップグレードまたは調整する場合でも、アプリケーションを再度アップグレード、ビルド、およびデプロイする必要があります。ただし、これは実際にはアプリケーション自体とは何の関係もありません。同時に、関心の分離が不十分なため、ログ収集のバグがアプリケーション自体に影響を及ぼします。

アプリケーションがアプリケーション自体にさらに集中できるようにするために、まず最初に、すべてのサービス ガバナンス コードをアプリケーション コンテナーから分離してサイドカーに配置し、サービス ガバナンス コードとアプリケーション コードが 2 つのコンテナーに格納されるようにしました。同時に、テスト ルーティングやリンク トラッキングなどの元のサービス ガバナンス タスクの一部を Mesh サイドカーに引き渡しました。この方法では、アプリケーションがスリム化され、アプリケーション コード自体にのみ集中する必要があります。

これを実行する利点は、サービス ガバナンスに依存せずに、ビジネス関連のアプリケーション コードに集中できることです。これは最初のステップであり、単一の移行にかかる高額なコストを心配することなく、サービス ガバナンスをサイドカーに徐々に移行できるため、スムーズです。

2 アーキテクチャのアップグレード - 構築デカップリング、リリースデカップリングから運用と保守のデカップリングまで

第2段階では、建設デカップリング、リリースデカップリング、運用・保守デカップリングの3つのレベルでデカップリングを実施しました。

マイクロサービスとサーバーレス アーキテクチャを理解している人は、ビジネスを独立して開発、テスト、リリース、運用できる場合にのみ、ビジネスをより迅速かつ効率的に実行できることを理解しているはずです。他の人との結合を最小限に抑えられるからです。

しかし、ビジネスがより複雑になり、アプリケーションが進化し続けるにつれて、アプリケーションに含まれるビジネス コードがますます増えていくこともわかっています。たとえば、下の図のアプリケーションには、特定のビジネスを対象としたコードがいくつかあります。たとえば、決済アプリケーションとしては、Hema の特定のニーズを対象としたもの、Tmall の特定のニーズを対象としたもの、そしてあらゆるビジネス シナリオを対象とした汎用コード、つまりプラットフォーム コードがあります。

当然のことながら、開発効率向上の観点からは、ビジネス側が自社の業務コードを修正することで、コミュニケーションコストを削減し、研究開発効率を向上させることができます。しかし、これによって新たな問題が発生します。ビジネス要件が変更されても、それが一般的なビジネス ロジックに関係しない場合は、アプリケーション全体のすべてのビジネスの包括的な回帰も必要になります。この期間中に他のビジネス変更があった場合は、それらを統合して一緒にリリースする必要があります。ビジネス上の変更が多数ある場合は、全員が統合のために順番待ちする必要があります。この場合、統合テストと通信調整のコ​​ストは非常に高くなります。

私たちの目標は、各事業が独立して開発、リリース、運営できるようになることです。この目標をスムーズに達成するために、まず最初に行う必要があるのは、構築段階でそれらを分離することです。例えば、比較的独立性の高い業務であれば、別途コンテナイメージとして構築し、オーケストレーションによって Pod の init Container に配置します。 Pod が起動すると、メイン アプリケーション コンテナのストレージ スペースにマウントされます。

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

アプリケーションの親密さは、おおよそ次の 3 つのカテゴリに分類できることがわかっています。

• 非常に親密で、同じプロセスで、関数呼び出しを通じて通信します。
• 同じ Pod 内の異なるコンテナは IPC を介して通信します。
• 同じネットワーク内に位置し、RPC 経由で通信します。

ビジネスの特性に応じて、一部のビジネス コードを RPC サービスまたは IPC サービスに段階的に分割し、独立して公開および保守できるようにします。

これまでに、アプリケーションコンテナの構築分離、リリース分離、運用保守分離が完了しました。

3 IaC と GitOps

3つ目のステップでは、開発と運用の状況を見てみましょう。多くの R&D シナリオでは、環境やビジネスによって構成がそれぞれ異なるという厄介な問題があります。リリース時や運用時には、状況に応じて適切な構成を変更したり選択したりする必要が生じることがよくあります。この構成とアプリケーション コード自体は、実際にはリリースの一部です。コンソールを介した従来のメンテナンス方法は、非常にコストがかかります。

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

4 つの BaaS リソース

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

アプリケーションでリソースがどのように使用されるか想像してみましょう。通常、対応するコンソールにアクセスしてリソース申請を送信し、必要なリソースの仕様と要件を記述し、承認後にリソース接続文字列と認証情報を取得します。アプリケーション構成にリソース構成を追加します。変更があった場合は、対応するコンソールに移動して操作し、コードリリースと合わせて確認してください。もちろん、このようなリソースの操作、保守、監視は通常、独立したコンソールで実行されます。

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

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

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

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

3つのクラウド効果がクラウドネイティブDevOpsの効率的な実装を推進

上記でご紹介したのは、アリババの社内R&DコラボレーションプラットフォームAoneを活用したアリババの社内実践です。 Aone のパブリック クラウド バージョンが Alibaba Cloud Effect です。 Alibaba Cloud Effect を通じてクラウドネイティブ DevOps を実装するにはどうすればよいでしょうか?

ALPD - クラウドネイティブ時代の新たな研究開発パラダイム

これまでの事例から、クラウドネイティブ DevOps の実装は体系的な方法とツール システムのサポートを必要とする体系的なプロジェクトであることがわかります。上の写真は、Alibaba Cloud Cloud Effect の専門家チームが提案する次世代リーン製品開発手法システム ALPD を示しています。 ALPD は、クラウドネイティブ DevOps の実装に対して体系的な方法サポートを提供していることがわかります (図のバスケットに示されているように)。

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

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

• テクニカル リーダーまたはアーキテクト。
• 開発、テスト、運用、保守などを担当するエンジニア。

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

まず、アジャイルR&Dを採用するか、リーンカンバンを採用するかなど、会社のR&Dコラボレーションモデルを定義します。次に、どのクラウド製品が必要か、それらのクラウド製品をどのように調整および管理するかなど、全体的な製品アーキテクチャを理解する必要があります。次に、チームの R&D モデルを決定します。R&D コラボレーションの実行方法、R&D 品質の管理方法などです。3 番目のステップでは、リリース戦略、グレースケール リリースとブルーグリーン デプロイメントのどちらを採用するか、グレースケール戦略とは何かなどを決定する必要があります。最後に、サービスの監視戦略があります。これには、サービスを接続する必要がある監視プラットフォーム、サービス ステータスの検出方法、グローバル監視構成などが含まれます。

最前線の開発、テスト、運用、保守エンジニアは、作業プロセスの円滑さと効率性に重点を置いています。 Yunxiao プロジェクトコラボレーションプラットフォームで要件またはタスクを受け取った後、Yunxiao を使用してそれをエンコード、送信、ビルド、統合、リリース、テストし、プレリリース環境と本番環境に展開して、管理者が設定した R&D モデルとリリース戦略を実際に実装できます。同時に、各環境は、人間による調整や操作を必要とせずに、自動的にトリガーされ、循環されます。

R&D プロセス全体で生成されるデータは有機的な全体であり、大量のデータ洞察を生成し、チームによる継続的な改善を推進することができます。チームが研究開発プロセス中にボトルネックや混乱に遭遇した場合、Yunxiao の専門家チームから専門的な診断アドバイスや研究開発ガイダンスを受けることもできます。

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

次に、具体的な事例を見てみましょう。

あるインターネット企業には、約 30 人の研究開発チームがあり、専任の運用保守担当者はいません。同社の製品には、20 を超えるマイクロサービスと数十のフロントエンド アプリケーション (Web、ミニプログラム、アプリなど) が含まれています。そのビジネスは急速に成長しました。急速に増加する顧客と高まる需要に直面し、Jenkins + ECS スクリプトに基づく元のデプロイメント方法は、特にゼロダウンタイムのデプロイメントとアップグレードの問題により、徐々に需要を満たせなくなっていました。そのため、私たちは Yunxiao に支援を求め始め、最終的に Yunxiao のクラウドネイティブ DevOps に完全に移行しました。

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

• 顧客数が多く、緊急のニーズも多数あります。
• フルタイムの運用・保守はなく、K8S などのクラウドネイティブテクノロジーは学習のハードルが高いです。
• IT インフラストラクチャのアーキテクチャは複雑であり、リリースには時間と労力がかかります。

これらの問題に対処するために、Yunxiao は基本機能、リリース機能、運用および保守機能の 3 つの側面から始めました。

まず、既存の ECS リソースの上にインフラストラクチャをアップグレードし、アプリケーションをコンテナに変換するために、Alibaba Cloud ACK が導入されました。サービス ガバナンスとアプリケーション アーキテクチャの面では、Spring Cloud ファミリ全体が SpringBoot に簡素化され、K8S 標準機能を通じてサービス検出とガバナンスをサポートします。

次に、クラウド効果パイプラインを通じてコン​​テナの自動展開を実現し、グレースケール展開戦略により、グレースケールの起動、自動容量拡張、障害発生時の自動再起動を実現します。同時に、クラウド効果パイプラインに基づいて、ゼロダウンタイムといかなるコストでも迅速なロールバックを実現できるため、マシンコストを節約できると同時に、企業が専任の運用・保守担当者を持たないという問題を解決できます。

3 つ目は、クラウド効果による自動化されたパイプラインとブランチ保護を通じて、コードレビュー、コード検出、テストチェックポイントなどの R&D モデルが標準化され、フィードバック効率とリリース品質が向上します。

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

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

クラウドネイティブ DevOps の実装は 5 つの段階に分かれています。

第一段階：完全に手動の配送と運用と保守

それは私たちの初期段階です。アプリケーション アーキテクチャはまだサービス指向に変換されておらず、クラウド インフラストラクチャが使用されていないか、IaaS のみが使用されています。継続的インテグレーションやテストの自動化はなく、手動によるデプロイメントとリリース、手動による運用と保守が使用されます。この段階に残っている企業は少ないと思います。

第2段階: ツールベースの配信と運用

最初に行うべきことは、サービス指向のアプリケーション アーキテクチャを構築し、マイクロサービス アーキテクチャを採用してサービス品質を向上させることです。 2 つ目は、いくつかの問題を解決するために、gitlab、jenkins、その他の独立したツールなどの R&D ツールを導入することです。同時に、単一モジュールの継続的インテグレーションの実装を開始しましたが、一般的に自動化された品質チェックポイントはまだ実現されておらず、リリースは自動化ツールによって支援されることがよくあります。

第3段階: 限定的な継続的デリバリーと自動化された運用

基礎能力をさらに向上させ、インフラをコンテナ化し、CaaS ベースで構築しました。一方、Yunxiao DevOpsなどのツールプラットフォームを使用してすべてのデータの完全な相互運用性を実現するなど、R＆Dデータを接続するための完全なツールチェーンの導入を開始しました。リリース機能に関しては、継続的なデプロイメントを実現できますが、一定の手動介入は依然として必要です。この時点では、自動テストが主流となり、サービス全体を監視でき、運用・保守もサービス指向かつ宣言的に行えるようになりました。

第4段階: 継続的デリバリーと人間による自動運用と保守

さらに、開発者はビジネス開発に集中できるようになります。まず、アプリケーションアーキテクチャにサーバーレスアーキテクチャを大規模に採用し、無人継続的デプロイメントを実現しました。リリースのグレースケールとロールバックは、介入なしに可能な限り自動化できます。観測能力をアプリケーションレベルからビジネスレベルにアップグレードし、ビジネス観測性を実現し、人による支援による部分的な自己運用・保守を可能にします。

第5段階：フルリンクの継続的デリバリーと自己運用・保守

これが私たちが追求している究極の目標です。この段階では、すべてのアプリケーションとインフラストラクチャはサーバーレス アーキテクチャを採用し、自動ロールバックやグレースケール リリースを含むエンドツーエンドの無人継続的デリバリーを実現します。技術施設とサービスは完全に自社で運営・保守されています。開発者が本当に気にする必要があるのは、ビジネス開発と反復だけです。

しかし、細部にこそ悪魔が潜んでいる。もちろん、実際に導入するにあたっては解決しなければならない問題がまだたくさんあります。 Yunxiao などのツール プラットフォームと ALPD の専門家によるコンサルティングの助けにより、迂回を避け、より早く目標を達成できます。