古き良き時代には、ビジネスでは戦略的に配置されたプロキシを利用してapplicationsのパフォーマンスを向上させることができました。 これは、従来のapplications(モノリスおよび 3 層アーキテクチャ) では、通常、クライアントとサーバーの間で単一のデータ パスが使用されていたためです。
簡単に言えば、静的か動的か、テキストベースか画像かを問わず、すべてのコンテンツに対して取られるルートは 1 つしかありませんでした。 つまり、application配信コントローラ (プロキシ) をそれらの間に配置し、適切なものを使用することでパフォーマンスを最適化できるということです。 ちなみに、これは、さまざまな IP、TCP、さらには HTTP のボタンやノブを調整することで実現されることが多く、現在でもそうなっています。 キャッシュ、圧縮、コンテンツ固有のアクセラレーション技術などのapplicationサービスの展開を通じて、これらの種類の技術の使用を確認できます。
しかし、現代のapplicationsはもはや自立的ではありません。 Sonatype によれば、現在、それらは主に (80~90%) サードパーティの (そしてますますオープンソースの) コンポーネントで構成されています。 これは、Webapplicationsで見つかるスクリプトやその他の挿入可能なコードの数からもわかります。 場合によっては、そのスクリプトがリモートで実行され、画像や広告、Web フォントやスプライトなどのその他のコンテンツが返されることがあります。 また、スクリプト自体が実行時に読み込まれ、jQuery のようにブラウザの範囲内で実行されることもあります。
これは、コンポーネント化、あるいはアトマイゼーションと呼ばれるものです。 applicationsを多くの小さな部分に分割することです。 これらは通常同じ空間で実行されるため、クライアント側のコンポーネントと呼ばれます。 サーバー側では、これらをマイクロサービスと呼び、コンテナにデプロイするケースが増えています。 どちらの場合も、影響は同様です。つまり、パフォーマンスに直接影響を与える予測できない数のデータ パスが発生します。
基本的に、applicationの 20% 程度を占める 1 つのデータ パスを制御できます。 つまり、パフォーマンスをほとんど制御できないため、ユーザー エクスペリエンスをほとんど制御できないことになります。
それはセキュリティにも当てはまります。気づいていただきありがとうございます。 実際のところ、私たちはセキュリティを向上させるためにクライアント側のコード技術を活用することを急速に学んでいます。 これはパフォーマンスの点ではうまく機能しません。ほとんどのアプリはモバイルか Web のいずれかであり、どちらもネットワーク スタックを操作する機会や能力をほとんど提供していないためです。
この問題に対処する方法の 1 つは、制御を取り戻すことです。 制御を取り戻すことの素晴らしい点は、セキュリティ上の副作用も得られることです。
アプリが外部サイトからコンポーネントを動的に読み込む習慣がある場合は、それを停止してください。 今すぐやめてください。 これはパフォーマンスの問題であると同時にセキュリティの問題でもあります。 暗黙的に、外部ソースのスクリプトにapplicationのコンテキスト内で実行する権限を与えることになります。 信じてください。セキュリティ侵害が発生した場合、ユーザーはコンポーネントと外部からロードされたコンポーネントを区別できなくなります。 最近のrunc コンテナの脆弱性をめぐるメルトダウンから学んだように、サードパーティのレジストリまたはサイトから読み込まれたリソースに悪意のあるコードを挿入すると、セキュリティ上のリスクが伴います。
スクリプトの場合は、独自のインフラストラクチャからクローンして提供する方が適切です。 制御を維持することでリスクを軽減し、ノブやボタンを微調整してユーザーのパフォーマンスを向上させることができるというメリットが得られます。 これには、applicationのパフォーマンスに最も大きな(多くの場合はマイナスの)影響を与えることが一貫して示されている DNS も含まれます。 外部サイトからコンポーネントを取得する場合、期待どおりのパフォーマンスを発揮するには、そのサイトの DNS インフラストラクチャに依存することになります。 独自のサイトからコンポーネントを取得すると、ユーザーのローカル DNS キャッシュが機能するため、影響を大幅に軽減できます。
独自のサイトからスクリプトをホストすると、TCP 最適化や SSL/TLS オフロード、または一般的なアプリ高速化テクニックを使用して、全体的なパフォーマンスを向上させることもできます。 また、スクリプトのセキュリティ スキャンを実行して、奥深くに予期せぬ問題が潜んでいないか確認することもできます。
コンポーネント化は開発に最適であり、価値実現までの時間を短縮するのに役立ちます。 しかし、パフォーマンスとセキュリティに悪影響を与える可能性があります。 セキュリティとユーザー満足度のリスクを認識し、それらに対抗するために何ができるかを把握してください。