GitHubがオープンソースのソフトウェアロードバランサー「GLB Director」を公開

GitHubが、従来のソフトウェアロードバランサーに存在していた問題点を改善した、オープンソースのロードバランサー「GLB Director」を公開しました。

GLB: GitHub’s open source load balancer | GitHub Engineering
https://githubengineering.com/glb-director-open-source-load-balancer/

GitHub looses load-balancing open-source code on netops world • The Register
https://www.theregister.co.uk/2018/08/09/github_load_balancing_director/

「ロードバランサー(負荷分散装置)」とはサーバに対するリクエストを複数のサーバーに分散する仕組みです。YouTubeを始めとした数多くのサービスでは、同じ機能を持ったサーバーが複数台稼働しています。これは、サービス提供を1台のサーバーで賄うとアクセスの増加とともに負荷が大きくなり、システムがダウンしてしまったり、レスポンスが悪化したりして、ユーザーにとって快適なサービスを維持できなくなることがあるからです。しかし、ただサーバーを物理的に増やすだけでは、アクセスを均等に分散するものが存在しないため、負荷分散ができません。そこで、負荷を均等に分散する役割を持つロードバランサーが必要になってきます。

たとえば、以下の画像のように、一般的なネットワークルーターをロードバランサーとして使用し、2台のプロキシサーバーを負荷分散させるものとします。ここで、3台目のプロキシサーバー(右端)を負荷分散対象に加えようと、ルーターに設定を行うと……

即座に3台目のサーバーが負荷分散対象に追加されます。ルーターはサーバーとの通信ができてしまえば「サーバーが生きている」と認識します。このため、3台目のプロキシサーバーが仮に準備中でサービスを提供できる状態になかったとしても、ルーターは3台目に対して通信を割り当ててしまい、一部のアクセス(ここでは2つの通信)がエラーとなる事態が発生してしまいます。

ルーターではアプリケーションレベルの負荷分散をうまく行えません。そこで用いられるのがLVS(Linux Virtual Server)のようなソフトウェアロードバランサーです。以下はルーターの直下に3台のLVSを配置してを配置して、その下にある3台のプロキシサーバーを負荷分散するというものです。LVSはバックエンドサーバー(負荷分散対象のサーバー)のサービスの状態をチェックしているため、GitHubによれば「多くの場合において問題なく動作する」とのこと。以下のケースだと、3台のLVSとプロキシサーバーのうち、右端にある3台目のLVSとプロキシに障害が発生して停止中。この時点では、2台のLVSとプロキシサーバーでサービスが処理できているため、問題は発生しません。

ここで、障害復旧の対応として、3台目のLVSとプロキシサーバーを同時に起動したとします。通常、LVSはバックエンドサーバの状態をチェックしてから通信を割り当てます。しかし、3台目のLVSが障害発生前にきれいにプロセスダウンしなかった場合、再度立ち上げた時点で障害発生前の状態を持っていることがあります。このとき、3台目のプロキシサーバーが稼働中でサービスできない状態であっても、復旧直後の3台目のLVSが「障害前はサーバーが稼働していた事実」から通信を割り当ててしまうことがあり、一部のユーザーのアクセスがエラーになる問題が発生してしまいます。

そこで、GitHubが開発したGLB Directorはこの問題を解決するため、「通信の割り当てごとにプライマリとセカンダリのバックエンドサーバーを割り当てる」という方法を採用しています。ここで、上記と同じ問題が発生したとしても、即座にセカンダリに設定されたサーバーに通信が転送されるようになり、接続エラーが回避できるようになるというわけです。

GLB Directorは以下からダウンロードすることが可能です。

GitHub - github/glb-director: GitHub Load Balancer Director and supporting tooling.
https://github.com/github/glb-director