事前に決めたルール vs 臨機応変！？負荷分散方式の話
はい、こんにちは！松井真也です。シリーズ「私ばかりに仕事が振られる…をなくす技術！？サーバ負荷分散SLBの話」第3回でございます！
前回は、「アプリケーションスイッチング」について、ご紹介しましたね。例えば、HTTPリクエストの内容（言語やデバイスのタイプ）を確認して、それにマッチするサービスを提供するサーバに適切に振り分けるのでした。負荷分散装置は、そんな機能まで持っているのですね！
さて、今回は、負荷分散方式の違いに関するお話しでございます。アプリケーションスイッチングはL7レベルでの振り分けであって、負荷分散装置本来の振り分けは、今回ご紹介する方式が中心です。
一体何を基準に、「君が処理してね！いや、そっちのあなた！よろしく！」と振り分けているのでしょうか？この方法には、大きく「静的」と「動的」の2種類があります。
早速見てみましょう！
事前に決めた通りの「静的」負荷分散
静的負荷分散は、その名の通り、事前に定められたルールに基づき負荷を分散します。そういえば、IPアドレスやルーティングでもそうでしたよね！
この静的な方式のもっともシンプルな形態が、「ラウンドロビン方式」です。
ラウンド・ロビンというこの用語は、「持ち回り」「輪番」という意味です。ITの文脈では、コードレビューを順番に行うときや、CPU使用権の割り当てなんかでも登場します。なお、Robinで画像検索するとかわいい鳥がヒットしますが、鳥の話ではなくフランス語の「リボン」がなまった用語らしいです。
さておき、サーバ負荷分散（SLB）におけるラウンドロビンは、接続要求が来るたびに順番にサーバに割り当てる方法です。かように、各サーバへの負荷が均等になるように設計されています。
たとえば、サーバA、B、Cがある場合、1つ目の要求はサーバAに、2つ目はBに、3つ目はCに割り当てられ、そしてまたAに戻ります。うん、シンプル、というか単純ですな。
次に、重み付けラウンドロビン方式があります。これは、サーバーの性能や負荷状態に応じて、事前に各サーバに割り当てるリクエストの「比率」を調整する方式です。
例えば、性能の高いサーバにはより多くのリクエストを、低いサーバにはより少ないリクエストを割り当てます。これにより、サーバーの能力に応じた効率的な負荷分散が行えます！リソースを有効活用できますね。
サーバが自分で判断「動的」負荷分散
一方、「動的」負荷分散は、一定の基準に基づきサーバに振り分け先を判断させます。
現在のサーバの負荷状態などをリアルタイムで確認して処理を割り当てます。これにもいくつか方式があります。
その筆頭格が、「最小コネクション数方式」です。その名の通り、現在接続数が最少のサーバに新たなリクエストを割り当てる方式です。
たとえば、あるサーバが他よりも負荷が低い場合、新しい接続は自動的にそのサーバに割り当てられ、負荷の均一化が図られます。これにより、全体として均等な負荷分散を実現し、リソースの過不足を防ぐことができます。いぇい。
また、「最短応答時間方式」では、現在最も応答が速いサーバーにリクエストを割り当てます。この方式では、サーバのパフォーマンスがリアルタイムで評価され、ユーザーに対して最も速いサービスを提供するサーバが選ばれます。
これは、特に応答速度が重要なアプリで効果を発揮します。しかし、一般に、サーバのパフォーマンスが向上した関係で、期待通りに分散できないこともあり、この方式があまり選択さなくなったようです。
負荷分散方式の選択基準
では、静的負荷分散と動的負荷分散、どちらを選ぶのがいいのでしょうか？実際のところ、システムの要件や目的によって異なります。
「静的方式」は設定がなにせシンプルです。どんなリクエストがどれくらいの頻度で来るか予測でき安定しているときに適しますが、実際のサーバの負荷状態やパフォーマンスの変動には柔軟に対応できません。
対して、「動的方式」はサーバの現在の状態を考慮して最適なサーバを選択できるため、刻刻と変動する負荷に対して効率的に対応可能です。
したがって、安定したトラフィックが予測される環境では静的方式が、不規則な負荷変動がある環境では動的方式が適しているというのが、無難な結論ですね。
さらには、最終的には、システムの可用性、スケーラビリティ、および運用コストを考慮して、最も適した負荷分散方式を選択します。うん、結論がうまくまとまったｗ。
はい、本日はここまで！今回は負荷分散方式について、静的と動的に分けて解説しました。「私の上司もロードバランサに置き換わればいいのに…」と思った方、声が漏れないようにご注意くださいｗ。
これで、今回の負荷分散シリーズはおしまいです。
次回は、、、SDN（Software Defined Network）あたりにしようかな。
ではまた！