運用担当者がロードバランシングについて知っておくべき 3 つのこと
負荷分散。 私たちがクラウドを必要とし、クラウドに依存し、クラウドをアプリケーションのスケールアップ（そしてできればスケールダウン）に毎日使用していることは、一般的に認められています。 これは、需要を満たすために拡張するだけでなく、生産性と利益の両方においてビジネスが依存するアプリケーションとサービスの継続的な可用性を確保する重要なインフラストラクチャになっています。
だからこそ、私たちはそれを再検討する必要があるのです。 なぜなら、ロード バランシングは、今ではこれらの魔法のようなサービスをプロビジョニング、構成、展開しなければならないことが多くなった運用担当者によってますます扱われるようになっているほど、戦術的であるべきではないからです。 負荷分散を戦略的に見ると、パフォーマンスが向上し、リスクが軽減され、アプリケーションの配信に必要なリソースをより効率的に使用できるようになります。 彼らは、しばしば負わされる「配管」という呼び名よりも賢く、いくつかの重要なポイントを理解することで、運用担当者は負荷分散を使用してアプリケーションをサポートする方法についてより深く考えるのに役立ちます。
では、これ以上長々と説明せずに、負荷分散について運用担当者が本当に知っておく必要がある 3 つのことを説明します。
1. アルゴリズムは相対的である
まず、ラウンドロビンは最後に言及すべきアルゴリズムだということを述べておきますが、それはすでにご存知ですよね? したがって、それをスキップして、最小接続数や最速応答時間などのよりインテリジェントなアルゴリズムに取り組みます。 もちろん、パフォーマンスとリソースの効率的な使用のバランスをとる方法を戦略化する場合には、これらははるかに優れた選択肢となります。 それぞれは、どのアプリケーション インスタンス (またはコンテナー) が次のリクエストを受信するかを決定する上で重要なアプリケーション特性 (または少なくともアプリケーションを配信するプラットフォームの特性) を考慮に入れます。 最小接続数は、インスタンスの接続数が少ないほど容量が多くなり、このリクエストをすぐに満たすことができることを意味します。 パフォーマンスよりも容量効率を選択します。
一方、最も速い応答時間は、パフォーマンスに基づいてリクエストの送信を選択することです。 インスタンスが高速であるほど、選択される頻度が高くなります。 運用上の原則は（負荷が増加するとパフォーマンスが低下する）であり、最終的には負荷の少ないサーバーの方が応答が速くなり、選択されることを意味します。 これは容量の効率性を重視していることを意味しますが、このアルゴリズムは常に容量よりもパフォーマンスを選択します。
しかし、ここでアルゴリズムの名前に注目してください。 最小かつ最速。 では、2匹のカメが歩道を走っているとします。2匹とも私たちが「遅い」速度と呼ぶ速度で走っているにもかかわらず、1匹の方が速いとします。 最小接続の場合も同様です。 99 と 100 のどちらかを選べと言われたら、間違いなく 99 の方が少ないです。
なぜそれが重要なのか
負荷分散がリクエストを管理する方法は、パフォーマンスと可用性に直接的かつ即時に影響を及ぼします。 どちらも、最終的には顧客エンゲージメントと従業員の生産性に影響を与える重要な特性です。 負荷分散を含むアーキテクチャを最適化すると、生産性と利益目標の向上を実現し、ビジネスの成功を確実にすることができます。
さらに詳しく:
2. すぐに失敗するのは（多くの場合）神話である
クラウドとソフトウェア定義データセンターの台頭により、弾力性がアプリケーションを拡張する方法となりました。 弾力性には、リソース (および予算) の使用を最適化する手段として、オンデマンドのスケールアップとスケールダウンが必要です。 オンデマンドでスケールアップできるのに、なぜ過剰にプロビジョニングするのでしょうか? 同様に、冗長性の原則に依存する高可用性 (HA) アーキテクチャもほぼ時代遅れになっています。 プライマリ アプリ インスタンスに障害が発生した場合 (可能性は低いですが)、スタンバイ状態のアイドル リソースが必要になるのはなぜですか? それは資本と運用予算の無駄です! 出て行け、出て行け、この忌々しいスタンバイ！
オンデマンドのフェイルアンドスケールは理論としては素晴らしいのですが、実際にはそれほど単純ではありません。 現実には、仮想サーバー (またはクラウド サーバー、あるいはどのような用語でも) でも起動には時間がかかります。 プライマリ サーバーが故障するか、容量がいっぱいになるまで待ってから別のサーバーを起動すると (または自動化システムが)、すでに手遅れになります。 クラウド環境での容量計画は、従来の環境で機能していたのと同じ計算に基づいて行うことはできません。 需要に応じてシームレスに拡張するには、容量しきい値に消費率と別のサーバーの起動にかかる時間を考慮する必要があります。
フェイルオーバーについても同様です。 プライマリが失敗した場合、代替品を起動するには時間がかかります。 人々が接続を失い、タイムアウトし、おそらく競合他社や最新の猫のビデオのためにあなたを放棄する時間です。 未使用のスペアパーツは（保険のように）無駄に思えるかもしれませんが、必要なときには、そこにあれば安心です。 特に、そのアプリが顧客エンゲージメントや収益に関係している場合、たとえ数分間のダウンタイム（およびそれに伴うコスト）のリスクでも、予備を用意しておくコストを十分に補うことができる可能性があります。
興味深いことに、コンテナは起動時間を非常に高速化することで、これらの問題に対処できる可能性があるようです。 可用性、パフォーマンス、コストがすべて同じように重要である場合は、3 つすべてをバランスさせるという観点からコンテナーがもたらす価値を検討し始める時期かもしれません。
なぜそれが重要なのか
ダウンタイムはコストがかかります。 ダウンタイムの原因は、そもそもそれを回避することほど重要ではありません。 障害が発生した場合でも適切なアーキテクチャとフェイルオーバー計画を確実に実施することは、ビジネスの成功に不可欠な継続的な可用性を維持するために不可欠です。
さらに詳しく:
3. クライアント IP は実際のクライアント IP ではありません。
アプリが開発から本番環境に移行するときに発生するすべての問題の中で、これはおそらく最も一般的であり、簡単に回避できます。 ご存知のとおり、ほとんどの負荷分散サービス (とにかく優れたものはすべて) はプロキシです。 つまり、クライアントはプロキシに接続し、プロキシはアプリに接続します。どちらも HTTP を転送するために TCP を使用しているため、ネットワークの法則に従う必要があります。 ソース IP (クライアント IP と思われるもの) は、実際にはプロキシの IP アドレスです。 IP アドレスに基づいてセキュリティや認証、計測を行っている場合、これは深刻な問題を引き起こします。 HTTP ヘッダーから取得した値は、必要な値ではありません。
業界では、HTTP カスタム ヘッダーを利用してこの問題に対処する方法がほぼ標準化されています。 おそらく、 X-Forwarded-Forヘッダーが実際に探しているものです。これは、プロキシがリクエストを転送するときに実際のクライアント IP アドレスを配置する場所です。 残念ながら、これは標準ではなく、事実上の「私たち全員が同意した」標準なので、確認する必要があります。
重要なのは、探しているクライアント IP アドレスが思っているものとは異なるため、その情報を必要とするアプリが本番環境に移行して突然動作しなくなる前に、開発者はそのことを考慮に入れる必要があるということです。
なぜそれがビジネスにとって重要なのか
運用環境での問題のトラブルシューティングは、開発環境やテスト環境よりもはるかにコストがかかります。 問題の発見と修正にかかる時間は、プロジェクトのタイムラインに悪影響を及ぼし、アプリケーションの世界における競争上の優位性とビジネスの成功にとって非常に重要な市場投入までの時間を妨げます。 この一般的な問題を認識し、開発段階またはテスト段階で対処することで、より迅速かつシームレスな本番環境および市場への展開が可能になります。
さらに詳しく: