プロキシの力: 開発と本番のギャップを埋める

アプリケーション開発者とネットワーク アーキテクトの世界は、おそらく互いのドメインに対する見方の違いを除けば、これほどまでに異なるものはありません。

アプリケーション展開の典型的なネットワークの観点は、次のようになります。

一方、「壁」の反対側では、同じアプリケーションのデプロイメントに対する開発者の視点は次のようになります。

どちらもそれぞれの領域では間違いなく正確ですが、他方の実際のアーキテクチャに対しては非常に無関心です。 これは、アプリケーションが本番環境に移行するときに多くの問題が発生する理由を示しています。 そして彼らは立ち上がる。 調査によると、2013年には「開発者の90%が、週末、休日、休暇を、生産段階のアプリの緊急事態の修正に費やしていると答えた」という。 [1]”。 これらの多くは確かにソフトウェアの欠陥やエラーに関連していますが、他の多くの問題は環境のさまざまな違いによって発生していることは間違いありません。 生産は開発ではありませんし、その逆もまた同様です。

今日のアプリケーションは、スケーラビリティのためのロード バランサ、パフォーマンスを向上させるキャッシュ、セキュリティのための Web アプリケーション ファイアウォールなど、運用環境に存在し、開発環境やテスト環境にはほとんど存在しないさまざまなサービスを活用しています。 これらのサービスは、ユーザーとアプリ (またはアプリと API) 間のネットワークを通過するすべてのリクエストと応答に作用するだけでなく、場合によってはリクエストや応答を変更します。 良い例としては、ユーザーの IP アドレスが挙げられます。 この値はすべてのリクエストの HTTP ヘッダーにありますが、負荷分散プロキシを通過すると、クライアントではなくプロキシの IP アドレスになります。

何も知らない開発者にとっては、これがアプリケーションを「壊す」原因となり、アプリの修正に必要な時間に加えて、トラブルシューティングに何時間もかかることになります。環境の違いから生じるこのような問題は、調査に回答した開発者の28%が、 [2]は2015年半ばに「適切なテスト環境があれば、生産上の問題の50％以上を発見し、修正できたはずだ」と述べています。 また、半数以上（52%）が「生産上の問題の25%～50%が解決されただろう」と回答しました。

運用中に発生する問題の多くは、アプリケーションの違い、特にアジャイル手法を使用して開発されたアプリケーションの違いに直接起因します。 アジャイル手法では、コードの変更頻度が高いため、本番環境でこのような種類の競合が発生する可能性が高くなります。

プログラム可能なプロキシを使用することで、これらの課題の多くが解決されつつありますが、すべて解決されるわけではありません。これにより、すでに運用中のコードを変更する必要がなくなり、アプリケーションの市場への提供がさらに遅れることがなくなります。 前述の「IP アドレス」の問題は、通常、実際の IP アドレスを含む新しいHTTP ヘッダーを挿入するようにプロキシに指示することで解決されます。これにより、開発者は引き続きその情報にアクセスでき、レイヤー 7 ロード バランシング プロキシは、バージョン管理や API 署名などのさまざまなデータに基づいて、アプリケーションと API 要求をルーティングするのに適しています。

興味深いことに、ソフトウェア ダイアグラムとネットワーク エンジニアリング ダイアグラムの両方で頻繁に言及されるコンポーネントはロード バランサです。 このプロキシは従来、ネットワーク チームによって導入および管理されていますが、アプリケーション アーキテクチャにとって非常に重要であるため、ほとんどの場合、アプリケーションの一部として組み込まれます。 同様に、開発者は今日、アプリケーションのスケーリングにおける負荷分散の重要性を認識しており、通常はそれを図に含めています。

また、開発者と運用担当者がスケーラビリティの責任を引き受け、アプリケーションの負荷分散を制御する事例が増えていることも反映しています。  これは良いことです。なぜなら、開発と運用が、特にテスト中に、CI/CD パイプラインに負荷分散 (およびレイヤー 7 のすべての利点) を含めることができる (そして、そうすることを期待します) ため、本番環境に移行する前に潜在的な問題を迅速に発見して解決できるようになります。 負荷分散を CI/CD パイプラインにシフトすると、アプリケーション パッケージ (アーキテクチャ) 全体がコードとして管理され、同時に更新できる、継続的デリバリーに対するより総合的なアプローチも可能になります。 これにより、ネットワーク インフラストラクチャ (負荷分散の説明では従来これが該当します) は、アプリケーション (または、そのルートを使用する場合はマイクロサービス) が単純に更新されるのではなく、新しい構成で完全に再デプロイされる不変のアーキテクチャをサポートできるようになり、課題や技術的負債をもたらす可能性のある自然なソフトウェア エントロピーを回避できます。

プロキシは、多くの点で、ソフトウェア エンジニアとネットワーク エンジニアおよびアーキテクトを隔てる比喩的なギャップ (正直に言えば、壁に近い) を越えて「ネットワーク」を「アプリケーション」に接続する橋です。 これは、組織が現代のアーキテクチャの課題に対応できるように拡張できるようにするには、DevOps に含める必要があるギャップの 1 つです。

[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructor-survey-results/