クラウドネイティブ時代の機会と課題: DevOps で打開する方法

クラウドネイティブ時代において、国内外の多くのクラウドベンダーが強力な技術的配当をリリースしています。安定的かつ効率的でコスト効率の良いクラウド設備をどのように活用するかが、現在の主な課題です。

最近では、コンテナ技術、特にDockerとKubernetesの登場により、DevOpsの概念が普及し、実践的に急速に実装され、普及し始めています。

ご存知のとおり、コンテナはマイクロサービスの実行時環境全体をカプセル化できるため、マイクロサービスの構築、リリース、運用に自然に適しており、もともと動きが遅かった DevOps を急速に発展させることができます。オープンソース コミュニティでは、多くの優れたオープンソース製品も登場しています。これらのオープンソース製品を通じて、誰もが独自のアプリケーション用の継続的インテグレーション環境を迅速に構築できます。そのため、市場には多くの DevOps 関連製品が登場しています。

現在の DevOps 製品は、Docker と K8s を通じて、リソース管理、マイクロサービス環境の構築、継続的インテグレーションの複雑さと効率性の低さを解決するのに役立ちます。しかし、パブリッククラウドなどのインフラ基盤の急速な発展が続くと、アプリケーションの研究開発の効率性に対する要求が高まり、現段階にとどまっているDevOps製品では満足できなくなるでしょう。では、現在の DevOps バージョンに基づいて、R&D の効率と品質をさらに向上させるにはどうすればよいでしょうか?

今日のDevOpsの問題点

まず、DevOps はクラウド ネイティブ、ワークフロー、人員組織の統合に依存しており、コラボレーション、自動化、無駄のない、測定、共有、文化によって導かれることを理解する必要があります。価値を迅速に提供し、継続的に改善できる最新の IT 組織を構築することを目指しています。

現在、ほぼすべての企業が DevOps を実施していると主張していますが、期待されるビジネス価値を得ている企業はごくわずかです。その理由は、DevOps モデルを組織内に適切に実装するためにどこに焦点を当てるべきかを明確に理解しており、ビジネス価値が DevOps の最終的な目標であることも理解しているからです。

しかし、この段階では DevOps がまだ多くの問題に直面する必要があることは否定できません。

1. マルチクラウド リソースを一元管理し、クラウド ベンダーを統合するにはどうすればよいでしょうか?

パブリック クラウドやプライベート クラウドなどの多様化されたクラウド環境では、多くの場合、2 セット以上のクラウド リソースが手元にあります。これらの断片化されたクラウド リソースを統一的に管理するにはどうすればよいでしょうか?単一のプラットフォームに基づいて、アプリケーションをクラウド間で迅速に移行およびリリースするにはどうすればよいでしょうか?たとえば、プライベート クラウドでの開発とパブリック クラウドでの運用などです。これらの問題は、資源環境の多様化に伴い、ますます顕著になるでしょう。

2. 環境を迅速に構築し、複雑なマイクロサービスの組み合わせを継続的に統合するにはどうすればよいでしょうか?

現在、DevOps は基本的に単一のマイクロサービスに対する環境構築と継続的インテグレーションの問題を解決しています。しかし、エンタープライズ レベルのソフトウェア開発および配信チームにとって、複雑なマイクロサービスで構成されたプロジェクト向けに統合環境を構築、展開、配信する方法は、まだ完全に解決されていません。唯一の選択肢は、各アプリケーションの研究開発メンバーが構築と展開の全段階に参加できるようにすることです。上記の複雑なプロセスは問題を引き起こしやすいだけでなく、効率とコストの面でも大きな問題となります。

3. 研究開発の効率をさらに向上させるにはどうすればよいでしょうか?

現在主流の DevOps 製品では、コード、構築、展開の全プロセスを自動的にトリガーして実行する機能は基本的に十分に解決されています。しかし、R&D 管理の要件がますます高度化、高度化するにつれて、R&D で維持する必要があるデータの量も増加しています。プロジェクトデータの管理・保守を行うプロジェクトマネジメントの作業負荷も増大しており、効率とコストの間に矛盾が生じています。

クラウドネイティブ時代に DevOps はどのように突破できるでしょうか?

上記の 3 つの問題点に直面して、新世代の DevOps も解決策を模索しています。

まず、マルチクラウド管理のための DevOps は、単に K8s クラスターを通じてリソースのスケジュールと管理を実装することを意味するものではありません。単なる統一されたリソーススケジューリングであれば、それは K8s クラスター自体の特性です。

第二に、アプリケーション展開環境の構成を通じてクラスターを分離することで、環境間の分離と環境間の迅速な移行が可能になります。開発とテストはローカルのプライベート クラウド環境で実行され、プロデューサーは同じコード セットを使用してパブリック クラウドに迅速に公開できます。さらに、業務を 1 つのクラスターに配置し、データ処理を別のクラスターで実行できるため、業務とデータが分離され、互いに影響を及ぼしません。これらはすべて、クラスター管理を通じて実現できます。

さらに、DevOps 製品は基本的に単一アプリケーションの継続的な構築と展開についてコンセンサスに達しており、単一マイクロサービス アプリケーションの構築と展開の自動化レベルは比較的高くなっています。

しかし、エンタープライズ レベルのプロジェクトの研究開発プロセスでは、単一のアプリケーション内のさまざまなタスクには開発に複数のブランチが必要であることがわかりました。開発環境のリソースの制限により、さまざまなタスクの開発者は、コードをマージし、テストのために開発環境にリリースするために、オフラインで継続的に通信する必要があります。このプロセス中に、1 つのコード ブランチに問題が発生し、環境全体が使用できなくなる可能性があります。

プロジェクト レベルの共同デバッグとデプロイメントはさらに複雑になります。まず、プロジェクト レベルのパラメータ構成と、一般的なプロジェクト レベルのミドルウェアの準備と展開を含むプロジェクト環境を構成する必要があります。第二に、複雑なマイクロサービス オーケストレーション情報を維持する必要があります。これらの面倒なプロジェクトレベルの保守および管理アクションは、プロジェクトの共通ミドルウェアの準備のブロックなど、プロジェクトの展開プロセスにおけるさまざまなブロックにつながることがよくあります。アップストリーム サービスの展開と健全性は、ダウンストリーム サービスの展開とテストにも影響を与えたり、それらをブロックしたりします。これらの問題により、プロジェクトの展開がさらに困難になります。

DevOps の実践では、テストの自動化には適切なツールを選択することが重要であることがわかります。共有ツールを活用してコラボレーションを明確化および合理化し、ソフトウェア配信プロセス全体に対する共通理解を促進します。その結果、一貫性と自動化が促進され、DevOps 実践者は配信速度を向上させ、展開時や本番環境の障害回復時にアドホックなファイア アンド フォーゲット ソリューションに時間を費やすことがなくなります。

最後に

DevOps の概念はコンテナやマイクロサービスよりも早く登場しましたが、それらの出現とともに急速に発展しました。実は、DevOpsは自動化を実現するためのツールチェーンであるだけでなく、企業文化を構築することで開発と運用保守の連携を促進する手段でもあります。