Skip to content
Latchkey

ロードバランサー層とは? インスタンス間でトラフィックを分散する

ロードバランサー層とは、受信リクエストをサービスインスタンスのプールに分散し、不健全なインスタンスからトラフィックを迂回させる層です。

サービスのインスタンスを多数動かすようになると、各リクエストをどのインスタンスが処理するかを何かが決めなければなりません。それがロードバランサー層です。トラフィックを分散し、health checkを実行し、安定したアドレスの背後でインスタンスを追加・削除できるようにします。horizontal scalingとゼロダウンタイムのデプロイを実際に機能させる部品です。

この層が行うこと

ロードバランサーはクライアントに単一のアドレスを提示し、round-robin や least-connections のようなアルゴリズムを使って各リクエストを複数のバックエンドインスタンスの1つに転送します。クライアントは背後にいくつインスタンスがあるかを知りませんし、気にする必要もありません。

なぜ不可欠なのか

  • 負荷を分散し、単一のインスタンスが過負荷にならないようにする。
  • health check が、障害中のインスタンスからトラフィックを迂回させる。
  • 安定したフロントにより、背後のインスタンスプールを入れ替えられる。
  • スケーリングと rolling deploy の入口となる。

health check が鍵となる機能

balancer はインスタンスを継続的にプローブし、失敗したインスタンスへのトラフィック送信を停止します。これがクラッシュしたインスタンスをユーザーから見えなくするものであり、デプロイが新しいインスタンスを追加する際に、それが提供準備できてから初めて組み入れるために頼る仕組みです。

安全なデプロイを可能にする

rolling デプロイと blue-green デプロイはロードバランサーに頼ります。インスタンスをドレインし、更新し、health check し、ローテーションに戻す、あるいは全トラフィックを一度に新しいプールへ切り替えます。この層がなければ、デプロイは目に見えるダウンタイムを意味します。

stateless であることがここで効く

どのインスタンスもどのリクエストを受け取る可能性があるため、バックエンドは stateless であるべきです。sticky session はクライアントを1つのインスタンスに固定し、均等な分散を損ない、デプロイを複雑にするため、状態を外部化すれば balancer はどこへでも自由にルーティングできます。

CI での health を意識したテスト

パイプラインはしばしば、デプロイを完了する前に、インスタンスが健全を報告し balancer が正しくルーティングすることを検証します。Latchkey のようなウォームな runner に助けられたこれらのチェックへの高速なフィードバックが、デプロイ検証を素早く保ちます。

重要なポイント

  • ロードバランサー層は、単一の安定したアドレスの背後でリクエストをインスタンス間に分散する。
  • その health check は障害を迂回し、デプロイ中に新しいインスタンスを段階的に組み入れる。
  • stateless なバックエンドにより、balancer はどのリクエストもどのインスタンスにもルーティングできる。

関連ガイド