さくらのクラウド やってみたシリーズ(13) ロードバランサーによるウェブサーバのロードバランシング
今日はロードバランサーを触っていきます。
さくらのクラウドには3つのロードバランサーが提供されています。

ロードバランサ:TCPで動作します。同じゾーンの中でのみ有効です。
エンハンスドロードバランサ:HTTP(S)に特化しています。さくらのグローバルネットワーク上で動作するためゾーンをまたいで有効です。
GSLB:グローバルサーバロードバランサ。DNSベースで動作しリージョンやゾーンをまたいだ負荷分散目的で使用します。
順番に1個づつ触りながら設定手順を纏めていきたいと思います。
今日はロードバランサーから。
ロードバランサーの概要
仮想的なアプライアンス機器として動作するロードバランサを提供するサービスです。2x2の全部で4種種類のプランで提供されます。
通常プラン or ハイスペックプラン:以下の性能目安が設定されています。

シングルプラン or 冗長化プラン:複数のルータで仮想IPを共有し、障害時に自動で切り替えて冗長化を実現するVRRP(Virtual Router Redundancy Protocol)により実装されます。
DSR 方式
ロードバランサーは以下の様な構成となり、DSR(Direct Server Return)方式 により通信が制御されます。

DSR方式 とは、ロードバランサがリクエストの転送のみを行い、レスポンスはサーバが直接クライアントへ返す方式を指します。これによりレスポンスの経路からロードバランサを外すことができるため、ロードバランサの負荷を大幅に軽減することができます。またサーバが直接レスポンスを戻すため、ロードバランサの仕様に縛られずレスポンスを自由に設計できる、というメリットがあります。またこの際サーバ側とクライアント側の通信が直接確立するためクライアント側のIPをサーバ側は識別することが可能となります。
一方このDSR方式では、サーバとロードバランサが同一ネットワーク上にある必要があるため、同じスイッチに所属している必要があります。
注意点ですが、ロードバランサ配下のサーバが直接ゲートウェイにレスポンスを戻すため通信のリクエスト元とレスポンス先が異なるIPとなり、リクエスト経路とレスポンス経路が非対称になります。このため各サーバにネットワーク経路を書き込んでいく手間が発生します。
さっそくやってみる
今回はドキュメントの以下の構成を、ロードバランサのシングル構成で作成していきます。

1. スイッチ+ルータ の作成
まずは以下の記事でまとめたスイッチ+ルータの起動を行います。

2. 2台のウェブサーバの起動
IPアドレスの上2つを使ってウェブサーバを2台起動します。
以下の手順でnginxを起動します。
sudo apt update
sudo apt install -y nginx
sudo systemctl start nginx
AとBへのアクセスの区別がつきやすいように、sudo vi /var/www/html/index.nginx-debian.htmlでどこかに from ServerA / from ServerB と記載しておきます。
それぞれIPアドレスでブラウザからアクセスしてnginxが起動していることを確認します。

今までの手順でIPアドレスはこうなっています。

3. ロードバランサの起動
つぎにロードバランサーを起動します。

とりあえずシンプルな1台構成で起動します。

前述の通りロードバランサはVRRPにより冗長化され仮想的な一つのIPアドレスとして認識されます。物理的には仮想的な一つのIPアドレスの他にそれぞれの筐体ごとに一つの物理IPを持つため、冗長化された2台構成でれば合計3つ、1台構成のロードバランサであれば合計2つのIPを消費します。
同じVRIDを持つものが同じVRRPグループに登録されます。
起動時に物理IPを指定する必要がありますが、IPアドレス表の一番下のIPを指定して起動します。

4. VIPの設定
起動が完了したらロードバランサ詳細画面からVIP設定タブを開いて、追加をクリックします。

適当な空欄のIPを使用します。


次に実サーバタブから2つのウェブサーバを追加します。

監視方法はpingを選びます。

最後に画面右上の反映をクリックします。

しばらく待つとヘルスチェックが通りサーバがロードバランサ経由でアクセス可能となります。

ヘルスチェックが通らないサーバが存在する場合、ロードバランサは自動でリクエストのルーティング先からそのサーバを一時的に除外します。
5. 2台のウェブサーバの設定
前述の通りDSR方式では、ウェブサーバに対するリクエスト元IP(ロードバランサ)とレスポンス先IP(ルータのゲートウェイ)が異なります。このため各2台のサーバで以下のコマンドを実行して、適切なルートを書きます。
/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を以下に置換します。
の記載と異なっていますがUbuntu22では書式が異なっておりドキュメントの記載だとエラーとなるためです。
# 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
編集が終わればsudo netplan applyを実行して反映させます。
同じようにもう一台のウェブサーバでも作業します。
6. テスト
いよいよテストです。VIPにブラウザでアクセスします。nginxの画面が表示されれば成功です。一度確立したコネクションはしばらく維持されるため、同じブラウザで連続的にアクセスを行っても同じウェブサーバへ誘導されます。
ブラウザを変えて複数環境からアクセスするとAとBが出し分けられていることがわかります。

Discussion