アプリケーション依存関係マッピングがクラウド移行に重要な理由

ソフトウェアの依存関係は、効果的なコンポーネントベースのプログラミングの重要な部分です。同時に、ソフトウェアアプリケーションの展開、更新、移行が困難になるため、ペースの速いアジャイル開発チームにとって障害となる可能性があります。多くのアプリケーションには数十または数百の依存関係があり、それぞれに独自の推移的な依存関係があるため、問題はさらに悪化します。

依存関係は、メインコンポーネントが依存する必要な機能を提供するコンポーネントです。これらは、npm や Maven などのパッケージマネージャー、GitHub などの Git ベースのコードリポジトリ、Docker Hub などのコンテナーイメージレジストリを使用してコードに組み込むことができます。

アプリケーション依存関係マッピングがクラウド移行に重要な理由

アプリケーション依存関係マッピングには、アプリケーションコンポーネント、その依存関係、および基盤となるインフラストラクチャ間の依存関係と相互作用を検出して識別することが含まれます。アプリケーション依存関係図を作成することは、複雑なアプリケーションの構造を理解し、それらをさまざまな環境に展開した場合の影響を理解する上で重要な部分です。

アプリケーションの依存関係がクラウド移行に重要な理由

アプリケーション依存関係マッピングにより、クラウドに移行する必要があるすべてのコンポーネントを特定できます。すべてのコンポーネントをクラウドに移行する必要はないかもしれませんが、すべての依存関係が識別され、一緒に移行されるようにする必要があります。そうしないと、重要な依存関係がローカルにまだ存在するため、アプリケーションでパフォーマンスの問題が発生する可能性があります。

たとえば、アプリケーションサーバーをクラウドに移行しても、アプリケーションのデータベースをオンプレミスに保持すると、アプリケーションのパフォーマンスが大幅に低下し、依存するアプリケーションが失敗する可能性もあります。依存関係が壊れると、依存するすべてのアプリケーションが影響を受けます。したがって、アプリケーションをクラウドに移行するときは、関連するすべての依存関係を含める必要があります。

アプリケーション依存性マッピングツールがどのように役立つか

アプリケーション依存関係マッピングは、アプリケーションのパフォーマンス低下やサービスの停止を回避するのに役立ちます。これは移行プロセスの重要な要素ですが、自動化ツールがなければ困難になることもあります。アプリケーション依存関係マッピングツールはアプリケーションを検査し、次の点に役立ちます。

すべてのサーバー間の関係をモデル化する
受信および送信接続の遅延を特定する
必要なTCPポートを決定する
実行中のプロセスの検出
時間の経過に伴うアプリケーションパフォーマンスの監視

クラウドベンダーは、自社の環境向けに開発された特定のアプリケーション依存関係マッピングツールを提供します。たとえば、Amazon Web Services (AWS)、Google Cloud、Microsoft Azure では、このプロセスの管理に役立つ独自のツールが提供されています。ただし、これらのツールは各プロバイダーに関連付けられているため、選択したターゲットクラウド環境に適したベンダーのツールを使用する必要があります。

あるいは、ベンダーに依存しない同様のサービスを提供するオープンソースツールを使用することもできます。単一のクラウドベンダー環境に固有ではない評価が必要な場合は、これらのツールを使用します。

クラウド移行に備えてアプリケーションの依存関係をマッピングする

アプリケーションは、依存する API とツールの階層で構成されます。階層はアプリケーションのインターフェースから始まり、プラットフォームツールへと下っていきます。依存関係管理は、関連するバージョンの組み合わせを識別するのに役立ち、変更が発生したときに開発チームが新しいアプリケーションの依存関係を識別できるようにします。

アプリケーションコンポーネントのバージョン管理

このプロセスの最初のステップでは、アプリケーションコンポーネントのバージョン管理を行います。特定のソフトウェアコンポーネントを個別に展開する場合は、各リビジョンにバージョン番号を割り当て、このバージョンの依存関係チェーンを追跡する必要があります。

この手法により、各アプリケーションバージョンに関連付けられている特定のプラットフォームツールのバージョンを把握できるようになります。ロールバックする必要がある場合は、バージョンの互換性を確保するためにロールバックする必要があるアドオンがわかります。

プラットフォームコンポーネントの変更

この手法では、ミドルウェアなどの一部のプラットフォームコンポーネントを変更する必要があり、各アプリケーションのプラットフォームバージョンの同期も必要になります。アプリケーションの依存関係チェーンの先頭から始める必要があります。

各アプリケーションは、特定のオペレーティングシステムとミドルウェアの機能を使用するように設計されており、ツールの「バージョン Y 以上」が必要です。したがって、指定されたバージョンの各ツールをツールの依存関係に対して検証し、依存関係チェーンの一番下に到達するまでこれらの各依存関係の検証を継続する必要があります。

ただし、一部のアプリケーションの依存関係は、他の依存関係ほど明白で明確ではありません。別のオリジンのハイパーバイザープラットフォーム上の仮想マシン (VM) でゲストオペレーティングシステムを実行する場合、問題が発生する可能性があります。

クラウドスタックバージョン (OpenStack など) で特定のスクリプト言語バージョンが必要な場合にも、問題が発生する可能性があります。この問題を軽減するには、各依存関係チェーンを標準のミドルウェアとオペレーティングシステムの組み合わせに対してテストし、すべての依存関係が識別されていることを確認します。

依存関係ツリーの再構築

クラウドに移行する準備ができたら、アプリケーションの依存関係ツリーを補足し、クラウドプロバイダーの API と機能へのすべての参照を含める必要があります。ツールや API の変更をプロバイダーに通知する方法を決定し、これらの変更によって作成される可能性のある新しい依存関係を検証する準備をしてください。

マルチクラウドまたはハイブリッド展開の場合、クラウドプラットフォームの境界外に移行する予定のすべてのコンポーネントとアプリケーションのクラウド依存関係ツリーを比較する必要があります。プロバイダーごとに異なる依存関係ツリーがあると、プロバイダープラットフォーム間でスケーリングまたはフェイルオーバーを行うときに問題が発生する可能性があることに注意してください。事前にコンポーネントを同期することでこれを回避できます。

ソフトウェアプラットフォームコンポーネントを変更するたびに、依存関係ツリーも再構築する必要があります。ベースアップデートにより、これまでに行ったすべてのマッピングと作業が元に戻る可能性があり、小さなミドルウェアコンポーネントへの変更を簡単に見落とす可能性があります。互換性のない要素が導入されたときに依存関係の問題が発生しないようにライフサイクル管理プロセスを設定することで、この問題を軽減できます。