アプリケーション開発者とネットワークアーキテクトの世界はまったく異なります。唯一似ているとすれば、お互いの領域に対する見方かもしれません。
一般的に、ネットワークの観点から見たアプリケーションのデプロイは、次のようになります。
一方、「壁」の向こう側では、同じアプリケーションのデプロイも、開発者の視点からは次のように見えることがよくあります。
どちらもそれぞれの領域については間違いなく正確ですが、相手側の実際のアーキテクチャにはほとんど関心を払っていません。これは、アプリケーションを本番環境に移行する際に多くの問題が生じる理由をよく示しています。そして実際に、問題は発生しています。ある調査によると、2013年には「開発者の90%が、本番稼働中のアプリケーションで発生した緊急事態に対処するため、週末や祝日、休暇中も作業していると回答しました[1]」。こうした問題の多くはソフトウェアの不具合やエラーに関連していると考えられますが、環境間のさまざまな違いが原因となっているものも少なくありません。本番環境は開発環境ではなく、その逆も同様です。
今日のアプリケーションは、本番環境には存在するものの、開発環境やテスト環境にはほとんど存在しないさまざまなサービスを活用しています。たとえば、スケーラビリティを確保するロードバランサー、パフォーマンスを向上させるキャッシュ、セキュリティを確保するWebアプリファイアウォールなどです。これらのサービスは、ユーザーとアプリ間（またはアプリとAPI間）のネットワークを通過するすべてのリクエストとレスポンスを処理するだけでなく、場合によってはリクエストやレスポンスを変更します。その好例がユーザーのIPアドレスです。この値は各リクエストのHTTPヘッダーに含まれていますが、ロードバランシングプロキシを通過すると、クライアントではなくプロキシのIPアドレスになります。
こうした事態を想定していない開発者にとっては、アプリケーションが「動作しなくなる」原因となり、アプリケーションの修正に必要な時間に加えて、トラブルシューティングに何時間も費やすことになりかねません。環境の違いから生じるこの種の問題を背景に、2015年半ばに実施された調査[2]では、回答した開発者の28%が「適切なテスト環境があれば、本番環境で発生する問題の50%超を事前に発見して修正できた」と答えています。また、半数を超える52%が「本番環境で発生する問題の25%～50%を修正できた」と回答しています。
本番環境で発生する問題の多くは、アプリケーションの違いに直接起因しており、特にアジャイル手法で開発されたアプリケーションで顕著です。アジャイル手法ではコードが頻繁に変更されるため、このような不整合が本番環境で発生する可能性が高まります。
こうした課題の多くは、プログラマブルプロキシを使用することで解決できるようになっています。ただし、すべての課題を解決できるわけではありません。プログラマブルプロキシを使用すれば、すでに本番環境にあるコードを変更する必要がなくなり、アプリケーションの市場投入がさらに遅れるのを回避できます。前述の「IPアドレス」の問題は通常、実際のIPアドレスを含む新しいHTTPヘッダーを挿入するようプロキシに指示することで解決されるため、開発者は引き続きその情報にアクセスできます。また、レイヤー7ロードバランシングプロキシは、バージョン情報やAPIシグネチャなど、さまざまなデータに基づいてアプリケーションやAPIのリクエストを適切にルーティングできます。
ソフトウェアとネットワークの両方のエンジニアリング図で、頻繁に明示されるコンポーネントの1つがロードバランサーである点は注目に値します。このプロキシは従来、ネットワークチームが導入・管理してきましたが、アプリケーションアーキテクチャにとって非常に重要であるため、ほぼ必ずアプリケーションの一部として図に含まれています。同様に、現在では開発者もアプリケーションのスケーリングにおけるロードバランシングの重要性を認識しており、通常は図に含めています。
これは、開発者と運用担当者がスケーラビリティに責任を持ち、アプリケーションの負荷分散を自ら管理するケースが増えていることも示しています。これは望ましい傾向です。開発チームと運用チームが、特にテスト時に負荷分散（およびレイヤー7の優れた機能すべて）をCI/CDパイプラインに組み込めるようになり、実際に組み込んでいることが期待されるためです。これにより、潜在的な問題を迅速に発見し、本番環境へ移行する前に解決できます。負荷分散をCI/CDパイプラインの早い段階に移すことで、アプリケーションパッケージ（アーキテクチャ）全体をコードとして管理し、同時に更新するという、継続的デリバリーへのより包括的なアプローチも可能になります。その結果、従来はネットワークインフラストラクチャの領域とされてきた負荷分散を通じて、イミュータブルなアーキテクチャをネットワークインフラストラクチャで支えられます。このアーキテクチャでは、アプリケーション（そのアプローチを採用している場合はマイクロサービス）を単に更新するのではなく、新しい構成で完全に再デプロイします。これにより、課題や技術的負債を招きかねない、ソフトウェアに自然に生じるエントロピーを回避できます。
プロキシは多くの意味で、ソフトウェアとネットワークのエンジニアやアーキテクトを隔てる比喩的な溝（率直に言えば、溝というより壁です）を越えて、「ネットワーク」と「アプリケーション」をつなぐ橋渡し役です。組織が拡張性を確保し、最新のアーキテクチャがもたらす課題に対応するには、DevOpsでこの溝も埋める必要があります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。