ToBアプリケーションプライベート化配信技術の開発履歴と比較

データのプライバシーとネットワーク セキュリティの考慮事項により、toB シナリオのほとんどの顧客はプライベート アプリケーション配信を必要とします。つまり、アプリケーションを顧客の環境に配信する必要があります。このような顧客には、政府、金融、軍事産業、公安、大企業、特殊産業などが含まれます。これらのプライベートなシナリオには多くの制限があります。プライベートアプリケーション配信の効率をどのように向上させるかは難しい問題です。この記事では、プライベートアプリケーション配信にどのようなテクノロジーがあるのか​​紹介します。それぞれの特徴は何ですか？民営化されたアプリケーション配信の進化。

ToBアプリケーションのプライベート配信の難しさ

環境ネットワークの制限が配送効率に影響する

• 配信実装プロセス中に情報を見つけるのは便利ではありません。
• 納品プロセス中、納品担当者は会社の開発スタッフとコミュニケーションを取る必要があります。ネットワーク制限はコラボレーション ツールの使用に影響します。顧客環境によっては携帯電話の使用すら許可されていないところもあり、問題解決の効率に影響を及ぼします。環境が複雑になるほど、影響は大きくなります。
• オフライン環境では、インストール ソフトウェア パッケージを直接ダウンロードすることはできません。インストール ファイルまたは構成ファイルをオフライン パッケージにパッケージ化し、顧客環境にインポートする必要があります。業務の複雑さにより、大きな画像が多くなり、配送担当者はモバイル ハード ディスクを顧客サイトに持ち込んでインポートすることしかできず、オフライン パッケージのインポートに長い時間がかかります。環境によっては、データをインポートする唯一の方法は CD に書き込むことです。 CD 自体には大きなパッケージを保存できないため、複数の CD に書き込む必要があります。

顧客インフラの違いにより適応プロセスが必要

• 民営化のシナリオでは、顧客ごとにインストール環境が異なります。物理サーバーを使用するものもあれば、仮想マシンを使用するものもあり、仮想マシンの製造元によっても違いがあります。オペレーティングシステムも異なります。例えば、一般的なOSとしてはCentOS/Debian/Ubuntu/Redhatなどが挙げられますが、現在では国産OSも数多く存在します。 CPU アーキテクチャも X86、ARM など異なる可能性があります。
• リソースの準備サイクルは長く、承認プロセスが必要です。
• 配信されたアプリケーションは、社内または顧客のサイトで大規模な適応プロセスを必要とします。
• 環境の違いが大きいため、アプリケーションは配信後に徹底的にテストおよび検証する必要があり、多くの人的資源と時間の投資が必要になります。

配達員の技術的なハードルは高い

• 配信担当者は、基盤となるハードウェアとネットワークを理解する必要があります。
• デリバリー担当者は、オペレーティング システムとシステムの運用と保守、さらにサービス ガバナンス、高可用性、セキュリティ、パフォーマンス分析、バックアップとリカバリ、デリバリー開発などについて理解する必要があります。
• 配信担当者は配信されたアプリケーションの問題を独自にトラブルシューティングできる必要があり、そのためには強力な技術的基盤が必要です。

カスタマイズされた配信の反復効率が低い

• カスタマイズされた配信シナリオでは、顧客が開発プロセスに参加します。結果を確認し、問題があればフィードバックを提供する必要があります。製品は、顧客が満足するまで繰り返し改良され続け、その過程では頻繁な製品アップグレードが必要になります。
• 開発者が社内でカスタム開発を行う場合、アップグレードプロセスが複雑になり、コミュニケーションが非効率になります。
• 開発者が適切な開発ツールや環境を持たずに顧客サイトにいる場合、開発効率は低下し、人的投資は高くなります。

メンテナンス後の困難

• アプリケーション配信後は、アプリケーション動作の安定性を確保する必要があります。オフライン環境では遠隔操作や保守が不可能であり、アラームを発報できないため、運用や保守が困難になります。
• 製品にバグがあったり、何らかの変更や製品のアップグレードが予想される場合は、顧客サイトまで出向く必要があり、サポート コストが比較的高くなります。

従来のアプリケーション配信

従来のアプリケーション配信では、バイナリ実行可能ファイルまたはソフトウェア パッケージを直接配信します。

• バイナリ実行可能ファイル: Java Jar、Linux 実行可能ファイル、Windows exe など。
• ソフトウェア パッケージ: CentOS では RPM パッケージ、Debian では DEB パッケージ、Java Web では WAR パッケージが使用されます。

インストールするには、まず依存環境と基本ソフトウェアをインストールする必要があります。 YUM と DEB には依存関係を管理するための独自のソフトウェア ソースがありますが、オフライン環境では使用できません。顧客のオペレーティング システムが異なる場合は、別のソリューションを見つける必要があります。このようなサービスを実行するときに起動と自動再起動の問題を解決するには、systemd または supervisor を通じてそれらを管理する必要もあります。従来のアプリケーション配信方法は、モノリシック アプリケーションを配信するには依然として十分ですが、複雑なマイクロサービス アーキテクチャでは実現が困難になります。

従来のアプリケーション配信プロセスでは、これらのオペレーティング環境とオペレーティング システムの違いを管理することが問題点です。コンテナの出現によりこの問題は解決されます。

現在のクラウドネイティブテクノロジーアプリケーション配信

クラウドネイティブ アプリケーションの配信では、主にコンテナと Kubernetes 関連のテクノロジが使用されます。

Dockerイメージ配信

Docker は、ビジネス ライブラリと依存ライブラリをまとめて、すべての環境とアプリケーションを含む Docker イメージにパッケージ化します。こうすることで、1 か所にパッケージ化してどこでも使用できるようになります。 Docker をサポートする任意のオペレーティング システムでイメージを実行できます。 Docker の機能は開発、配信、その他の多くの問題を解決するため、Docker コンテナの概念は急速に普及しました。

マイクロサービス アーキテクチャ シナリオでは、複数のサービスまたはアプリケーションを一緒に配信する必要があり、サービス間に依存関係があり、構成が複雑になります。 Docker-Compose はこの問題を解決します。

Docker-Compose アプリケーション配信

Docker-compose は、YAML を使用して複数のサービスまたはアプリケーションを管理します。 docker-compose コマンドを使用してインストール、デプロイ、管理できます。マイクロサービス アーキテクチャを備えたアプリケーションの場合、docker-compose コマンドを使用して、任意のオペレーティング システムにワンクリックでインストールして実行できます。もちろん、前提条件として、Docker と docker-compose がインストールされている必要があります。

Docker-compose はスタンドアロンのシナリオに適用できます。ただし、アプリケーションに高可用性またはマルチノード分散デプロイメントが必要な場合、Docker-compose は適していません。 Kubernetes の登場により、コンテナの高可用性と分散スケジューリングの問題が解決されました。

Kubernetes YAML アプリケーション配信

Kubernetes でサービスをデプロイするには、Deployment Statefulset Service などのリソース タイプを定義する必要があります。レプリカを調整することで、Kubernetes は複数のノードに自動的にスケジュールを設定し、ビジネスの高可用性を実現します。配信時には、これらの YAML リソースとイメージをエクスポートし、顧客の Kubernetes 環境にデプロイして、顧客に配信するだけです。この配信方法では、顧客環境に Kubernetes が存在するか、顧客環境に Kubernetes がインストールされている必要があります。

多くの顧客に Kubernetes YAML を提供する場合、パラメータ設定、バージョン管理、簡単なインストールとアップグレードが必要です。 Helm は Kubernetes YAML に基づいて上記の問題を解決します。

Helm アプリケーション配信

Helm は Kubernetes リソース用のパッケージ マネージャーです。リソースのセットを Helm Chart テンプレートとして定義し、Helm Chart モジュールに基づいてインストールとアップグレードを提供し、インストール中にさまざまなパラメータを構成できます。 Helm は、Kubernetes 配信においてほとんどの人が選択するツールでもあります。

Helm の最大の問題は、開発者がコンテナと Kubernetes の技術スタック全体を学習する必要があり、顧客環境に Kubernetes が必須であるため、学習と使用のハードルが高すぎることです。抽象的なアプリケーション モデルが解決策です。

将来志向のクラウドネイティブアプリケーションモデル配信

アプリケーション モデルはアプリケーション中心の概念を重視しており、開発者はビジネスそのものに集中できます。基盤となる複雑なテクノロジーをアプリケーション レベルで抽象化してパッケージ化します。アプリケーション モデルは基盤となるインフラストラクチャから完全に分離されており、接続および配信されるさまざまなインフラストラクチャに応じて自動的に変換および適応されるため、どこでもワンタイム開発と自動展開が実現されます。

OAM に基づく KubeVela アプリケーション配信

OAM (Open Application Model) は、アプリケーションを記述するための標準仕様です。この仕様により、アプリケーションの説明を、アプリケーションを展開および管理するインフラストラクチャの詳細から完全に分離できます。アプリケーション定義をクラスターの運用および保守機能から分離することで、アプリケーション開発者は、「アプリケーションがデプロイされる場所」などの運用および保守の詳細ではなく、アプリケーション自体に集中できるようになります。 KubeVela は、OAM に基づいてクラウドや環境全体にわたるアプリケーションの継続的な配信を実現します。現在、KubeVela はオフライン シナリオでのアプリケーション配信のサポートが弱いです。

RAMベースのRainbondアプリケーション配信

Rainbond は、クラウドネイティブ アプリケーション向けのマルチクラウド管理プラットフォームです。 Rainbond は、アプリケーション中心という中核概念に従い、コンテナや Kubernetes などの複雑なテクノロジーを統合およびカプセル化し、Kubernetes リソースを RAM (Rainbond アプリケーション モデル) アプリケーション モデルに抽象化することで、ユーザーが Kubernetes を非常に簡単に使用できるようにし、ユーザーが使用するための敷居を下げ、ユーザーがアプリケーション開発、アプリケーション配信、アプリケーションの運用と保守に集中できるようにします。

オフライン配信シナリオでは、Rainbond は RAM に基づいて 3 種類のオフライン配信パッケージをエクスポートできます。

• Rainbond アプリケーション テンプレート パッケージには、複雑なマイクロサービス アーキテクチャを提供するためのすべての要素が含まれており、アップグレードとロールバックがサポートされていますが、顧客環境に Kubernetes と Rainbond がインストールされている必要があります。
• 非コンテナ ソフトウェアパッケージは、従来のアプリケーション配信方法に従ってパッケージ化されますが、より使いやすいものになります。パッケージには環境依存関係が含まれており、静的にコンパイルされ、ほとんどのオペレーティング システムに適しており、Systemd を使用して管理されます。
• Docker-Compose オフライン パッケージは、標準の Docker Compose 環境でのワンクリック起動と管理をサポートします。

総合的な比較

• アプリケーション配信に関しては、従来の配信方法のハードルが最も高くなります。 Docker、Docker-Compose、Kubernetes YAML、Helm、KubeVela は、コンテナと Kubernetes 関連のテクノロジーを学習する必要があるため、中程度のハードルがあります。 Rainbond は最も使いやすく、コンテナや Kubernetes を学習する必要がありません。
• マイクロサービス サポート: 従来のアプリケーション配信と Docker イメージに加えて、他の方法でもマイクロサービス オーケストレーションとパッケージ配信がサポートされます。
• マルチノード スケジューリングと自動運用および保守、Kubernetes YAML、Helm、KubeVela、Rainbond は、Kubernetes のマルチノード スケジューリングをサポートします。
• オフライン反復効率: 従来の配信方法は効率が最も低くなります。 Docker イメージにはバージョンがあり、1 つのコマンドでオフライン パッケージをエクスポートできるため、反復効率が高くなります。 Docker-Compose、Kubernetes YAML、Helm、KubeVela では、イメージのオフライン パッケージを 1 つずつ手動で入力する必要があります。複雑なアーキテクチャは非効率であり、手作業ではエラーが発生しやすくなります。 Rainbond は、オフライン パッケージの自動エクスポートとオフライン環境へのインポートをサポートしています。ワンクリックでアップグレードやロールバックが可能で、反復効率が非常に高いです。
• 顧客環境のサポート: 顧客ごとに動作環境が異なります。配信されるパッケージは、顧客環境に基づいて選択する必要があります。従来のアプリケーション配信方法は、コンテナをインストールして実行できない古いバージョンのオペレーティング システムを搭載した一部の古いインフラストラクチャに適しています。顧客環境に Kubernetes がなく、Kubernetes のインストールが許可されていない場合は、Docker イメージと Docker-Compose を選択できます。 Kubernetes YAML、Helm、KubeVela、Rainbond は、Kubernetes を使用した環境をサポートします。