挿入ポイントとしてのアプリケーション サーバー

前回の投稿では、 「挿入ポイント」という概念を使用して、変化するアプリ アーキテクチャにアプリ サービスを追加するという概念について説明しました。 まだ理解できていない方のために説明すると、挿入ポイントとは、コードから顧客データへのパスにおけるアーキテクチャ的に明確な場所であり、開発の範囲外であることが多い機能や、運用上より効率的な機能を追加するのに適切な場所です。 

強力な機能セットにより、今日のビジネス活動を表すアプリケーションが追加または強化されます。

挿入ポイントには、クライアント、インフラストラクチャ、アプリ自体が含まれます。 運用効率とコスト効率のバランスに関しては、それぞれの点に長所と短所があります。 たとえば、ネットワーク中心の DDoS アプリ サービスをクライアントまたはアプリに挿入することは、運用面でもコスト面でも効率的ではない可能性があります。これは、どちらの挿入ポイントもインフラストラクチャ オプションで利用可能なハードウェア アクセラレーション機能にアクセスできず、正確な判断を行うために必要な可視性もないためである。 

したがって、私たちが求めているのは、挿入時点で運用効率とコスト効率の両方に優れたアプリ サービスです。この場合、私たちはアプリ サーバー (プラットフォーム) 自体に重点を置いています。

挿入ポイントとしてのアプリプラットフォーム

最初は、この挿入ポイントは奇妙な選択のように思えるかもしれません。 アプリ サーバーはアプリ サービスではなく、アプリをホストして配信します。 しかし、 NGINXやその他のアプリケーション サーバーが現在果たしている役割を考慮すると、インフラストラクチャとサーバーの両方の役割を同時に果たしていることが多いことがわかります。 たとえば、一部のアプリケーション サーバーは SSL 終了ポイントとして機能します。 SSL ターミネーションはアプリ サービスであり、多くの場合、SSL オフロード (ハードウェア アクセラレーション) と組み合わせられます。 Web アプリ ファイアウォール サービスも、プラグインを介してアプリ サーバーに結合されることがよくあります。

アプリケーション サーバーを挿入ポイントとして使用することは、目新しいことでも珍しいことでもありません。 2020 年のアプリケーション サービスの現状に関する調査では、アプリ サービスを展開するためのこのオプションについて質問しました。 この挿入ポイントには関心があることがわかりました。 回答者の約 6% が、アプリ サービスに「プラグイン」を使用したいと考えています。 残りの 9% は、呼び出すためにコンパニオン コード (挿入または組み込まれたもの) を必要とする「サービスとして」を好みます。 少数の 4% は、ライブラリを使用してアプリ サービスを組み込むことを希望しています。 この最後のオプションは、サーバーレス (サービスとしての機能) アプリケーションに機能を挿入するためによく使用されるものです。

多くの場合、アプリ サービスをアプリ サーバーに展開することは、運用上理にかなっています。 これらのサービスは単一のアプリを提供するように構成されていることが多いため、同じチームによってパッケージ化および展開できます。 アプリケーション サーバーに関する専門知識により、エコシステムと展開パイプラインへの統合の信頼性が向上し、統合が容易になります。

場合によっては、単一のアプリ サーバーの同じインスタンスにアプリとアプリ サービスを一緒にデプロイすることが合理的です。 たとえば、アプリ固有のポリシーによるアプリ保護をプラグインし、リクエストとレスポンスの処理のステップとして実行できます。 この機能がサーバー内から呼び出されることは理にかなっており、検査がローカルで実行される場合、環境外でホストされているサービスによる余分なホップと処理を排除することでパフォーマンスを向上させることができます。 これにより、特にサービスに対して時間単位または呼び出し単位で料金を支払う場合、運用面でも財務面でも効率が向上します。  

アプリ サーバーがスタンドアロン アプリ サービスをホストするために使用されるか、アプリとアプリ サービスの両方のホストとして使用されるかに関係なく、アプリ サーバーは適切なアプリ サービスを挿入するのに適したポイントになります。