さくらのクラウド ネットワーク入門 7. ロードバランサーでWebサーバーを負荷分散してみよう
一般にロードバランサーとは、サーバーリソースの負荷分散を実現するネットワーク機器です。例えばアクセス過多なWebサービスに対し、Webサーバーやアプリケーションサーバーを複数起動して処理を振り分ける際に利用されます。本サイトの用語解説「負荷分散とは？」も参照してください。
ロードバランサーは構成や仕組みによっていくつか種類がありますが、さくらのクラウドでは3つのアプライアンスを提供しています。特徴を簡単にまとめると次の図のようになります。
| アプライアンス名 | 特徴 | 提供範囲 |
|---|---|---|
| ロードバランサ | L4（TCP）で動作し、スイッチ配下に設置するDSR方式 | 同一ゾーン内のみで有効 |
| エンハンスドロードバランサ | L7（HTTP）で動作し、グローバルネットワークに設置するプロキシー方式 | ゾーンをまたぐ運用が可能 |
| GSLB | DNSベースで動作し、広域負荷分散（GSLB）を提供 | リージョンやゾーンをまたぐ運用が可能 |
より詳細な比較については、商用アプライアンス製品を含めた4種類についてマニュアルの「よくある質問と回答」に掲載しています。
👉 4種類のロードバランサアプライアンスの違いは何ですか？ – よくある質問と回答 – アプライアンス
このネットワーク入門シリーズで、順番に1つずつ設定してみながら手順を紹介していきます。本記事では「ロードバランサ」アプライアンスを取り上げます。
- さくらの「ロードバランサ」はどんなロードバランサーか？
- DSR方式とは何か？
- ネットワークをどのように構成するか？
- Webサーバーを起動する
- ロードバランサーを起動して設定する
- VIPを設定する
- Webサーバーで必要なネットワーク設定
- 負荷分散されていることを確認する
- ソーリーページを設定しよう
- ロードバランサーでソーリーページを設定する
- ソーリーサーバーの設定
- Webサーバーを停止してテストする
- 付記・DSR方式によるアクセスログ
さくらの「ロードバランサ」はどんなロードバランサーか？
「ロードバランサ」は、TCPレイヤー（L4）での負荷分散を提供する仮想的なアプライアンス機器です。さくらのクラウドの同一ゾーンで構築されたネットワークに、コントロールパネル上の操作から手軽にロードバランサーを追加できます。設定方法の詳細などは次のマニュアルも参照してください。
処理性能により「標準プラン」と「ハイスペックプラン」があり、また冗長化の有無で「シングル構成」と「冗長構成」が選べるため、掛け合わせで都合4プランから選択できます。この冗長化は、複数のルーターで仮想IPを共有して障害時の自動切り替えを実現するVRRP（Virtual Router Redundancy Protocol）により実装されます。それぞれのプランの違いは、マニュアルの「仕様」を参照してください。
本記事では、マニュアルの「構成例」にある「ルータ＋スイッチを組み合わせたWebサーバの負荷分散」（下図）の「ロードバランサ2」がない「シングル構成」バージョンを作成してみます。
DSR方式とは何か？
さくらの「ロードバランサ」では、DSR（Direct Server Return）方式により通信が制御されます。DSR方式のロードバランサーはリクエストの転送のみを行い、レスポンスはサーバーが直接クライアントへ返します。これには次のようなメリットがあります。
- ロードバランサーをレスポンスの経路から外すことができるため、その負荷を軽減できる
- レスポンスはサーバーが直接返すため、ロードバランサーの仕様に縛られず自由に設計できる
- サーバーは直接クライアントと通信を確立するため、クライアントのIPアドレスを識別できる
一方、DSR方式ではサーバーとロードバランサーが同一ネットワーク上になければいけません。つまり、さくらのクラウドでは同じゾーンの同じスイッチにつながっている必要があります。
また注意点として、ロードバランサー配下のサーバーからゲートウェイに直接レスポンスが戻るため、通信のリクエスト元とレスポンス先が異なります。リクエスト経路とレスポンス経路が非対称になりますから、各サーバーでネットワーク設定の手間が発生します。
ネットワークをどのように構成するか？
前述した図のネットワークを構成するため、インターネットと接続するルーターと配下のスイッチをまとめて、ネットワーク入門シリーズの第5回で取り上げた「スイッチ＋ルータ」を起動します。
👉 さくらのクラウド ネットワーク入門 5. L3スイッチを「ルータ＋スイッチ」で実現する
このスイッチに2台のWebサーバーと1台のロードバランサーを接続しますが、それぞれに割り当てるIPアドレスを先に決めておきましょう。上記記事にあるように「スイッチ＋ルータ」ではIPv4のアドレスブロックが割り当てられます。ここでは仮に次のアドレスブロックだったとします。
133.125.233.208/28このネットワークでは 133.125.233.209 から 133.125.233.222 まで、14個のIPアドレスを機器に割り当てることができます。上記記事にもあるように「スイッチ＋ルータ」ではゲートウェイアドレスのほか2個を内部的に使用します。
また、後で説明しますが「ロードバランサ」では物理アドレスと仮想アドレス（VIP）が必要です。何台起動しても同一のVIPで認識されるため、冗長化された2台構成であれば合計3つ、1台構成でも2つのIPアドレスを消費します。
さらに記事の後半でソーリーサーバーを設定するため、まとめると今回は次の表のようにIPアドレスを使用することとします。読者の皆さんも自身の環境にあわせて割り当てるIPアドレスを決めておくとよいでしょう。
| 機器・用途 | IPアドレス |
|---|---|
| ゲートウェイ | 133.125.233.209 |
| （内部使用） | 133.125.233.210 |
| （内部使用） | 133.125.233.211 |
| Webサーバー A | 133.125.233.212 |
| Webサーバー B | 133.125.233.213 |
| ソーリーサーバー | 133.125.233.214 |
| ロードバランサー VIP | 133.125.233.216 |
| ロードバランサー 物理IP | 133.125.233.222 |
それでは順に起動していきましょう。
Webサーバーを起動する
これまでのネットワーク入門シリーズでは仮想デバイスによるネットワーク構成を扱ってきましたが、今回はWebの負荷分散のためWebサーバーを立ち上げます。さくらのクラウドで「サーバ」を起動して「スイッチ＋ルータ」に接続する方法は上記記事を参照してください。なお、OSのディスクイメージとしてはUbuntu Server 22系のLinuxディストリビューションを選択したものとします。
スイッチに接続した「サーバ」にSSHでログインし、以下のような手順でnginx（Webサーバー）をインストールして起動します。
$ sudo apt update
$ sudo apt install -y nginx
$ sudo systemctl start nginxWebサーバーそれぞれに割り当てたIPアドレスにWebブラウザでアクセスして、次のように表示されることを確認してください。
ここではAとBのどちらにアクセスしているか区別がつきやすいように、表示されるテキストを少し変更しています。次のようにHTMLファイルをエディタで開き、本文の h1 要素に「from ServerA」や「from ServerB」と追記しておくとよいでしょう。
$ sudo vi /var/www/html/index.nginx-debian.htmlWebサーバーAとWebサーバーBの両方を設定し終えたら、次にロードバランサーを設定します。
ロードバランサーを起動して設定する
次にロードバランサーを起動します。コントロールパネルの左メニューから「アプライアンス」を開いて「ロードバランサ」を選択します。
一覧画面で右上の「＋追加」をクリックし、ロードバランサーを起動します。ここでは「標準プラン」を選択し、また「冗長化」は「いいえ」でシンプルな1台構成としています。
このとき、前述の表にある物理IPの値を「IPv4アドレス」に入力します。前述のネットワークアドレスに沿って「ネットマスク」なども指定してください。また同一の「VRID」を設定された機器が、同じVRRPグループに登録されます。右下の「＋作成」をクリックします。
VIPを設定する
続けてロードバランサーとしてのVIP（仮想IPアドレス）を設定します。作成した「ロードバランサ」の詳細画面から「VIP設定」タブを開いて「＋追加」をクリックします。
前述の表にあるVIPを「VIPアドレス」に入力します。あわせて待ち受ける「ポート番号」なども指定してください。
次に「実サーバ」タブを開いて「＋追加」をクリックし、先ほど起動した2つのWebサーバーを追加します。
Webサーバーそれぞれの「IPアドレス」を設定します。また「監視方法」には「ping」を選びます。設定できたら「追加」をクリックします。
AとBの2つとも追加できたら、最後に画面右上の「反映」をクリックします。
しばらく待つとヘルスチェックが通り、Webサーバーにロードバランサー経由でアクセスできるようになります。それぞれの「ステータス」が「UP」になっていることを確認してください。
なお、ヘルスチェックが通らないサーバが存在する場合、ロードバランサーは自動でリクエストのルーティング先からそのサーバを一時的に除外します。
Webサーバーで必要なネットワーク設定
前述の通り、DSR方式ではWebサーバに対するリクエスト元のIPアドレス（ロードバランサー）と、レスポンス先のIPアドレス（ルーターのゲートウェイ）が異なります。このため2台のWebサーバでは、以下のようなネットワーク設定が必要になります。
まず /etc/sysctl.conf に以下の2行を追加します。
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2追記後、設定内容を反映します。
$ sudo sysctl -p次に /etc/netplan/01-netcfg.yaml を以下の内容に置き換えます。
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
dhcp6: no
nameservers:
addresses: [133.242.0.3, 133.242.0.4]
search: [localdomain]
addresses:
- 133.125.233.212/28
routes:
- to: default
via: 133.125.233.209
lo:
match:
name: lo
addresses:
- 133.125.233.216/32これは「ロードバランサ」のマニュアルにある「Ubuntu系の手順」の記載とは異なり、上記がUbuntu 22での書式となります。
編集が終われば、設定内容を反映させます。
$ sudo netplan applyもう1台のWebサーバでも同じように作業します。
負荷分散されていることを確認する
いよいよテストです。Webサーバーにブラウザからアクセスしてみましょう。先ほどはWebブラウザのIPアドレスに直接アクセスしましたが、今回はロードバランサーのVIPにアクセスします。先ほどと同じnginxの画面が表示されれば成功です。ここではWebサーバーAに振り分けられています。
もう一方のWebサーバーに接続されることも確認したいのですが、いったんコネクションが確立するとしばらく維持されるため、同じブラウザで連続的にアクセスしても同じWebサーバーに誘導され続けます。ブラウザを変えるなど複数の環境からアクセスしてみると、AとBが出し分けられていることが確認できるでしょう。
ソーリーページを設定しよう
ロードバランサーにはソーリーページ（sorry page）機能があります。メンテナンスや障害でWebサイトが表示できないときに、代替で「ただ今、つながりにくくなっています」などとユーザーに状況を伝えるページです。
事前に設定しておくことで、ターゲットとして登録されているWebサーバがすべて反応しないときや、メンテナンスなどで意図的にユーザーからのリクエストをシャットアウトしたいときに一時的なメッセージを表示させることができます。
ロードバランサーでソーリーページを設定する
ソーリーページを設定するには「ロードバランサ」の「VIP設定」画面を開きます。
詳細画面でソーリーサーバーのIPアドレスを入力します。指定できるソーリーサーバーは「スイッチ＋ルータ」が管理しているIPアドレス内になければなりません。ここでは前述の表にある値を「ソーリーサーバ」に設定しています。
ソーリーサーバーの設定
ソーリーサーバーは、Webサーバーがすべて接続できないときにメッセージを配信するため、別のWebサーバーを立ち上げておく必要があります。新たに「サーバ」を起動して先ほどと同様にnginxを設定します。起動時のIPアドレスは、先ほど「ロードバランサ」の詳細画面で設定した値と同じにします。
また、ソーリーサーバーもターゲットのWebサーバーと同様にDSR方式で通信がハンドリングされるため、非対称ルーティングとなります。前述のWebサーバーと同じネットワーク設定を書き込んでおいてください。
さらに index.nginx-debian.html を編集して、つながらない理由などが表示されるようにします。例えば h1 要素を「Sorry in maintenance」のように書き換えておくとよいでしょう。
Webサーバーを停止してテストする
ソーリーページが表示されるかテストしてみましょう。意図的にメンテナンス状態を作ります。コントロールパネルから2台のWebサーバーの電源を落としてください。
このようにWebサーバを停止させると、ロードバランサーのヘルスチェックもすべて失敗する（DOWN）ようになります。
この状態で、先ほどと同じようにロードバランサーのVIPにWebブラウザからアクセスします。次のようにソーリーサーバーで設定したHTMLドキュメントが返ってくることを確認してください。
内部的には、本来のWebサーバーが2台とも落ちているので、ソーリーサーバーとして設定されたWebサーバーからコンテンツが戻されているのです。
👉 ロードバランサにソーリーサーバを追加 | さくらのクラウド マニュアル
付記・DSR方式によるアクセスログ
記事の前半であげたDSR方式のメリットの1つに、Webサーバーが直接的にクライアントとセッションを確立するため、クライアント情報（IPアドレスやユーザーエージェントなど）が得られることがあります。実際には以下のようなアクセスログとして記録されます。
$ more /var/log/nginx/access.log
219.104.132.56 - - [25/Oct/2025:19:48:57 +0900] "GET / HTTP/1.1" 200 406 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36ここでは 219.104.132.56 がクライアントのIPアドレスになり、これをもとにアクセス制御などを行うことができます。
