分散アプリケーションに依存関係管理が必要なのはなぜですか?

序文

分散型クラウド アプリケーション (マイクロサービスとも呼ばれる) の人気が高まっていますが、アプリケーション自体の設計と運用も非常に複雑になっています。過去、モノリシック サービスの時代では、この複雑さはサービス自体の中に隠すことができましたが、マイクロサービスの時代では、この複雑さは数百または数千の「疎結合」サービスに広がっています。各マイクロサービスは異なる言語を使用して構築でき、迅速にスケールアウトできますが、全体として分散型であるため、モノリシック サービスと比較して、計画、展開、セキュリティの課題が生じることがよくあります。

これらの問題は、クラウドネイティブ アプリケーションの管理と開発にも課題をもたらします。クラウドネイティブ アプリケーションの継続的な健全性を確保する方法、本質を抽出して不要な部分を取り除く方法、開発および保守コストを増やさずにサービス指向設計の利点を維持する方法について考えずにはいられません。

幸いなことに、マイクロサービス以前にも同様の問題に遭遇していました。数十年にわたる蓄積を経て、開発者は、複雑なコンポーネント関係のネットワークを管理する方法についての一連の共通ソリューション、つまり依存関係管理を改良してきました。

実際、私たちは依存関係マネージャーによって提供されるパブリックまたはプライベートのソフトウェア パッケージを毎日使用し、これらのパッケージに基づいて独自の機能を追加し、最終的に後で使用するために標準形式に慎重にパッケージ化します。著者は、依存関係の管理が分散アプリケーションの強力な機能を発揮するための鍵であると考えています。今こそ、クラウド ネイティブ テクノロジーの開発を促進するために依存関係管理メカニズムを導入する時です。具体的には5つの理由があります。

1. 開発者間のコラボレーション

NPM、Pip、Maven などの依存関係マネージャーの最も重要な機能の 1 つは、開発者間のコラボレーションを促進することです。依存関係マネージャーは、統一されたパッケージ管理メカニズムを提供することで、コードを他のチームが使用したり拡張したりできるようにします。さらに、依存関係管理は、企業内のチーム間だけでなく、オープンソース コミュニティでのコラボレーションを促進するために広く使用されていることもわかります。ツールの一貫性と広範な使用により、誰もが使用して構築できる強力でアクセスしやすいソフトウェア ライブラリを作成することもできます。

このレベルのコラボレーションは、JavaScript の NPM や Python の Pip など、さまざまな言語コミュニティで実現されていますが、クラウド ネイティブ コミュニティには成熟した実装計画がありません。 Docker はクラウド サービスのパッケージ化の仕様を定義していますが、さまざまなコンテナー ソリューションには、サービス間の依存関係を解析および拡張するための十分な情報がまだ不足しています。マイクロサービスでこのようなコラボレーションを実現したい場合は、各言語がソフトウェア ライブラリで行っているのと同じように、各ターミナル サービス間の関係を取得して処理できる適切な依存関係管理メカニズムを追加することが非常に重要です。

2. セルフサービス環境

依存関係マネージャーの共同効果は真空中で発生するのではなく、統一された依存関係の解決によって恩恵を受けます。統合された依存関係解決が強力なのは、主に世界中の開発者が同じコマンドと手順を使用して結果を再現できるためです。再現性は依存関係マネージャーの重要な要素です。この要素がないと、開発者は複雑な起動ロジックをカスタマイズせずに、他者が作成したライブラリやパッケージを簡単にダウンロードして操作することができず、開発コストが増加し、大規模な導入や配布の大きな障害となります。

この点では、マイクロサービスと各種言語ライブラリの間に大きな違いはありません。他の人の作業を拡張できるかどうかは、必要なサービスやアプリケーションを実行したり呼び出したりする能力によって決まります。現時点では、サンドボックス環境と集中型 QA を通じてタスクを完了できますが、環境を完全に再現することができず、一連の問題が発生します。他者が提供するサービスを簡単に提供できないため、開発者は独自の開発環境を完全に制御できず、他の人のアプリケーションをローカルまたはリモートで実行するために独自のスクリプトを記述する必要があります。同時に、各チームはネットワークとセキュリティの問題を独自に解決するための実稼働レベルのツールを開発する必要があります。

統合された依存関係管理ソリューションを使用すると、各チームはサービスのネットワーク依存関係を宣言するだけで済みます。これにより、組織内のすべての人が同じ方法でテクノロジー スタック内のサービスを実行し、同時にサービスの依存関係を準備できるため、各開発者が環境を制御できるようになります。

3. 自動化

セルフサービスの利点は、開発者が独自の環境を制御できるだけでなく、プログラムの自動化を通じて開発環境を提供および改良できることも意味します。たった 1 つのコマンドまたはプログラムで、依存関係を解決し、ネットワークを強化し、セキュリティを自動的に確保することができます。これは、CI/CD パイプラインへの統合の鍵となります。

各サービスが統一されたメカニズム (コンテナ プラットフォームの使用など) を使用して実行され、独自の依存関係を認識できる場合、各 Git マージ リクエストは新しい環境セットを提供し、プレプロダクション環境とプロダクション環境にシームレスにリリースできます。つまり、各チームは、各メンバーおよびアプリケーションに追加された各新しいサービスに対して、非常に柔軟な Git ベースの自動運用デプロイメント (GitOps) を提供できます。

4. セキュリティ

マイクロサービス アーキテクチャのセキュリティ リスクの 1 つは、各サービスが関数呼び出しを提供するために API インターフェイスを公開する必要があることです。これらのサービスは個別のプロセスとして存在するため、ネットワーク経由で通信することが、サービスが相互に接続して処理要求を受信する唯一の方法です。つまり、すべての新しいサービスは、他のサービスからアクセスできるインターフェースを公開しており、開発者が注意しないと、アクセスが許可されていないサービスに誤ってインターフェースを公開してしまう可能性があります。

ネットワーク インターフェイスの偶発的な公開を防ぐことは、依存関係管理が非常に役立つもう 1 つの領域です。ネットワーク依存関係を持つ構造化インデックスを通じて、サービス間の依存関係を自動的に解決できるだけでなく、環境構成を強化し、対応するネットワーク ポリシーを生成して、インターフェイスへの正当なアクセスを確保し、相互に依存するサービスのみが相互にアクセスできるようにします。この構造化されたアプローチにより、開発者がネットワーク セキュリティ ツールを理解する必要性が大幅に軽減され、新しいサービスを作成する自由度が高まります。

5. 柔軟性

マイクロサービスまたは分散アプリケーションの依存関係管理のもう 1 つの利点は柔軟性です。開発者が依存関係を識別し、それをサービスに関連付けると、リゾルバ自体が、展開された各環境で一意の関係ネットワークを構築できるようになります。別の API ゲートウェイまたはサービス メッシュを試してみませんか?各サービスの入口トラフィックと出口トラフィックを通じてリンク トラッキングを実行したいですか?依存関係リゾルバーの自動分析により、開発者は既存のコードの変更に注意を向けることなく、新しいツールや構成を自由に試すことができます。

では、なぜ分散アプリケーションの依存関係管理はまだ登場していないのでしょうか?

依存関係の解決は、開発者が共同作業を行い、クラウド ネイティブ アプリケーションに貢献できるようにする非常に強力なソリューションとなるため、既存のパッケージ マネージャーを使用してこれを支援できるでしょうか?既存のツールを使用することも可能かもしれませんが、Web アプリケーションの依存関係の解決とバイナリ ライブラリの解決には大きな違いがあります。

依存バイナリ ライブラリ ファイルは、メイン ライブラリ ファイルがコンパイルおよびビルドされるときにダウンロードされますが、マイクロサービスは単一のバイナリ ファイルにバンドルされません。これらは独立したサービスとして実行され、ネットワーク接続を介して相互作用して完全なアプリケーションを形成する必要があります。つまり、解析には追加の手順があり、バイナリ ライブラリとはライフサイクルのまったく異なる段階で実行されます。分散アプリケーションの依存関係を正しく解決できる最も早い時期は、デプロイメント フェーズであることが判明しました。展開時には、テクノロジー スタック内のすべてのサービス間の関係と、サービスを適切に構成して接続するために必要なツールとターゲット環境の詳細の両方がわかります。

結論

要約すると、ネットワーク依存関係を解決するための大規模なリゾルバを作成することは現時点では困難ですが、そうすることでエンジニアリング チームとクラウド コミュニティ全体に大きなメリットがもたらされます。クラウド ネイティブ ツールの開発を正しい方向に導くには、過去の依存関係管理の実践から学ぶ必要があります。

翻訳者について

51CTO コミュニティ エディターの Li Tenghui 氏は現在、東南アジアのインターネット金融ユニコーン企業でシニア Java エンジニアとして働いており、金融融資プラットフォームのアーキテクチャ設計とコア構築を担当しています。彼はインターネット金融アーキテクチャとマイクロサービス システムについて深い研究を行っており、インターネット金融の分野での研究をさらに深めていきたいと考えています。

原題:分散アプリケーションに依存関係管理が必要な理由、著者: David Thor