とある企業さんとのカジュアル面談時に、
面談相手のエンジニアへキャッチアップはどのようにしているかを聞いてみたら、
下記のシステム設計などをみたりしていると教えてもらったので、
その中から興味があった、負荷分散の項目を追ってみようと思う。

一般的な負荷分散アルゴリズム(ロードバランサーを使用した場合)

1. ラウンドロビン

ユーザーからのリクエストに対して、順番にサーバーへ送信される。
簡単な設計だが、サーバー側の負荷を考慮しないので、サーバーAが死んだ場合もリクエストが送られてしまう。

2. スティッキーラウンドロビン

ユーザーからのリクエストはずっと同じサーバーに送信するようにする。
セッションパーシステムを実現するためのアルゴリズム。
特にユーザーのセッション状態を維持してサービスを展開したいもの(ECサイトなどなど)に有効。
しかし、これも同じサーバーに接続し続けるのでサーバーが死んだらエラーになってしまい、負荷が均等に分散されない。

※ セッションパーシステム
特定のユーザーから来る一連のリクエストを同じサーバーに振り分けること。

下記でセッションを固定している
・IPアドレスベースでセッションを固定
・ユーザーにセッションIDを割り当てて固定
・Cookieを使用してセッション情報を保持して固定

3. 加重ラウンドロビン

各サービスに対して重みを設定する。
図だとServiceAに80%,その他に10%ずつ重みを設定している。
そうすると80%までのリクエストはServiceAに、81%〜90%はServiceB、90%〜100%はServiceCに割り振られる。
サーバーの能力に応じて重みを設定することが大事。

4. ハッシュ

受信トラフィックの送信元と送信先のIPアドレス、URLを組み合わせて、
数学的関数を使用しハッシュに変換。そのハッシュの値で指定したサーバーに割り振られる。 図だと、req1, req2のipアドレスやURLが0になると、ServiceAのインスタンスにルーティングされる。

5. 最小接続数

同時接続数が最も少ないサービスに送信される。 サーバー間の負荷を均等に分散できるため動的な環境に適している。

6. 最短応答時間

最もレスポンス時間が短いサーバーに送信される。
リアルタイムにサーバーのパフォーマンスを監視し、動的に負荷を分散している。

※ロードバランサーは、複数サーバー間でのトラフィックを効率的に分散する

まとめ

なんとなくで負荷分散している部分もあったので、 こういったアルゴリズムを取り入いれ品質を高めていこうと思う今日この頃。