以前の記事では、「挿入ポイント」と呼ぶ概念を用いて、変化するアプリケーションアーキテクチャにアプリケーションサービスを追加するという考え方を取り上げました。これまでの記事をご覧になっていない方のために説明すると、挿入ポイントとは、コードから顧客データまでの経路上にある、アーキテクチャ上独立した場所です。開発の範囲外となることが多い機能や、運用効率を高める機能を追加するのに適しています。
充実した一連の機能により、今日のビジネス活動を支えるアプリケーションを追加または強化できます。
挿入ポイントには、クライアント、インフラストラクチャ、アプリ自体があります。運用効率とコスト効率のバランスを取るうえで、各ポイントにはそれぞれ長所と短所があります。たとえば、ネットワーク中心のDDoSアプリサービスをクライアントやアプリに挿入しても、運用面でもコスト面でも効率的ではない可能性があります。これは、どちらの挿入ポイントも、インフラストラクチャを選択した場合に利用できるハードウェアアクセラレーション機能を使用できず、正確な判断に必要な可視性も得られないためです。
そこで求められるのは、挿入ポイントにおいて運用面とコスト面の両方で効率的なアプリサービスです。ここでは、アプリサーバー（プラットフォーム）自体に焦点を当てます。
挿入ポイントとしてのアプリプラットフォーム
一見すると、この挿入ポイントは不自然な選択に思えるかもしれません。アプリサーバーがホストして配信するのはアプリであり、アプリサービスではありません。しかし、現在のNGINXやその他のアプリサーバーの役割を考えると、多くの場合、インフラストラクチャとサーバーの両方の役割を同時に担っていることがわかります。たとえば、一部のアプリサーバーはSSL終端ポイントとして機能できますし、実際にその役割を果たしています。SSL終端はアプリサービスの1つであり、多くの場合、SSLオフロード（ハードウェアアクセラレーション）と組み合わせて使用されます。Webアプリファイアウォールサービスも、多くの場合、プラグインを介してアプリサーバーと連携します。
アプリケーションサーバーを挿入ポイントとして使用することは、目新しいものでも、なじみのないものでもありません。F5の「2020年版アプリケーションサービスの現状」調査では、アプリケーションサービスを導入するための選択肢として、この方法について質問しました。その結果、この挿入ポイントに関心があることが分かりました。回答者の約6%は、アプリケーションサービスに「プラグイン」を使用したいと回答しています。また、9%は「サービスとして」の利用を希望しています。この方式では、呼び出し用の付随コードを挿入または組み込む必要があります。少数ながら4%は、ライブラリを使用してアプリケーションサービスを組み込みたいと回答しています。この最後の選択肢は、サーバーレス（Function as a Service）アプリケーションに機能を追加するためによく使用されています。
多くの場合、アプリサーバーにアプリサービスをデプロイすることは、運用面で合理的です。こうしたサービスは単一のアプリに対応するよう構成されることが多いため、同じチームでパッケージ化してデプロイできます。アプリサーバーに関する専門知識があれば、より確実かつ容易にエコシステムやデプロイパイプラインへ統合できます。
場合によっては、アプリとアプリサービスを単一のアプリサーバーの同じインスタンスにまとめてデプロイすることが合理的です。たとえば、アプリ固有のポリシーによるアプリ保護を組み込み、リクエストとレスポンスの処理手順の一部として実行できます。この機能をサーバー内から呼び出すことには合理性があり、検査をローカルで実行すれば、環境外でホストされているサービスへの余分な通信やそこでの処理をなくすことで、パフォーマンスを向上できる可能性があります。これにより、運用面とコスト面の両方で効率が向上する可能性があります。特に、サービス料金が時間単位または呼び出し単位で発生する場合に効果的です。
アプリサーバーをスタンドアロンのアプリサービスのホストとして使用する場合でも、アプリとアプリサービスの両方のホストとして使用する場合でも、適切なアプリサービスを組み込む場所として、アプリサーバーが有力な選択肢であることは確かです。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。