さくらの専用サーバ ロードバランサーサービスを使ってみる

公開日
更新日

さくらの専用サーバにおいてロードバランサーサービスがリリースされました。
検証利用でご利用いただけるため、サービス運用に組み込む前に検証したい、ロードバランサーで利用できる機能を確認したい、といった目的でも気軽にご利用いただけます。
そこで今回は、「そもそも、ロードバランサーとは何か？」について解説した後に、「さくらの専用サーバで提供するロードバランサー機能」について紹介していきます。

そもそも、ロードバランサーとは何か？

ロードバランサーの概要

ロードバランサー（Load Balancer：負荷分散装置）とは、その名の通り、負荷分散処理を専門で行ってくれる装置のことです。L4スイッチ、L7スイッチとも呼ばれています。最近では、アプリケーションデリバリーコントローラー（ADC：Application Delivery Controller）という言い方をする機器が増えてきています。

ロードバランサーを導入することにより、クライアントからのリクエストを複数のサーバーに分散させ、サーバーの負荷を低減できたり、障害・保守などによりサーバを停止する場合でも別のサーバーでサービスを継続できるようになります。

負荷分散アルゴリズム

負荷分散の手法の中で、主要なアルゴリズムを紹介します。

  1. ラウンドロビン
    最もシンプルなアルゴリズムで、クライアントからのリクエストを順番にサーバーに振り分けます。
    このアルゴリズムが適しているのは、サーバーのスペックが同等で、提供するwebページが静的なページの場合になります。
  2. 最小コネクション
    サーバーの中から最もクライアントとのコネクションが少ないサーバーに振り分けます。webアプリなどを処理している間はコネクションが張りっぱなしになるため、コネクションが多い=負荷がかかっていると判断でき、コネクション数が少ないサーバーにリクエストを振り分けます。
    このアルゴリズムが適しているのは、webアプリシステムなどの場合になります。
  3. 最速応答時間
    サーバーの中から最もリクエストの応答が早かったサーバーに振り分けます。応答速度はサーバーの負荷状況やトラフィック状況に左右されるため、最も応答が早いサーバーは負荷に余裕があると判断できます。
    このアルゴリズムが適しているのは、webアプリシステムになりますが、特にレスポンスタイムが重要となる携帯アプリ、ソーシャルアプリコンテンツを運営するシステムに適しています。

L4負荷分散とL7負荷分散

現在の多くのロードバランサーは、L4/L7どちらのモードでも動作することができます。バーチャルサーバー毎にL4/L7どちらのモードで負荷分散を行うか設定が可能です。
L4負荷分散とL7負荷分散の違いは、負荷分散を行うレイヤー（Layer）の違いとなります。

L4負荷分散は、レイヤー4、OSI参照モデルのトランスポート層、TCP/IPでいうTCP/UDPのレイヤーで負荷分散を行います。パケットの種別を、TCP/UDPのプロトコルと下層のIPアドレスとで判断します。

L4負荷分散を利用するメリットは、下記のようになります。

  • 負荷分散性能が高い
  • 同一IPからのリクエストは同じサーバーに転送するなどTCP/IPレベルでのセッション維持機能を利用することができる。

L7負荷分散は、レイヤー7、OSI参照モデルのアプリケーション層の情報を判断して負荷分散を行います。

L7負荷分散を利用するメリットは、下記のようになります。

  • アプリケーション層の情報を参照して判断するため、クライアントからのリクエストとしてURLに付加されているパラメーターを参照して、分散サーバーを固定化することができる
  • 上記と同様に、user-agentを参照できるため、PCからのアクセスはPC用サイト、携帯からのアクセスは携帯サイトを表示するという運用が可能

DSR構成と非DSR構成

ロードバランサーの運用形態として、DSR（Direct Server Return）構成と非DSR構成の２つの構成があります。パケットの転送方法の違いで、下記のようにそれぞれメリット・デメリットがあります。

  • DSR構成
    DSR構成のメリットとして、下記のようにサーバーからのレスポンスがロードバランサーを経由しないため、リクエスト量に対してロードバランサーのキャパシティが増えることになります。そのため、コンテンツ・ストリーミング配信などのシステムに適しています。L4負荷分散のみ利用可能で、サーバーにloopbackインターフェースの設定などが必要となります。

    DSR構成でのパケットフロー：
    1. クライアントからのリクエストをロードバランサーが受信
    2. ロードバランサーはバランシングを行い、サーバーにリクエストを転送する
    3. サーバーはダイレクトにレスポンスをクライアントに返す

DSR構成

  • 非DSR構成
    こちらの構成が一般に、ロードバランサーに持っているイメージになるかと思います。非DSR構成のメリットとして、L4/L7負荷分散両方ともに利用可能で、サーバーに特別な設定を行う必要がありません。サーバーからのレスポンスもロードバランサーを経由するため、ロードバランサー自体がボトルネックとなる場合があります。

    非DSR構成でのパケットフロー：
    1. クライアントからのリクエストをロードバランサーが受信
    2. ロードバランサーはバランシングを行い、サーバーにリクエストを転送する
    3. サーバーはレスポンスをロードバランサーに返す
    4. ロードバランサーは返ってきたレスポンスをクライアントに返す

非DSR構成

さくらの専用サーバで提供するロードバランサー機能

さくらの専用サーバ ロードバランサーサービスで利用可能な機能の紹介と、ロードバランサーの設定手順について説明していきます。ロードバランサーサービスをご利用いただくには、専用グローバルネットワークのお申し込みが必要になります。

主な仕様

提供されるロードバランサーサービスの主な仕様は次の通りです。

構成 DSR構成/非DSR構成 選択可能
負荷分散 L4・L7負荷分散 選択可能
※ DSR構成時は、L4負荷分散のみ利用可能
冗長化 Active/Standbyの冗長構成にて提供
バーチャルサーバー数 最大60程度
実サーバー数 最大120程度
利用目安 L4 CPS： 8,000cps
SSL CPS（1024bit）： 170cps
SSL CPS（2048bit）： 40cps
管理インターフェース 専用の管理インターフェースを提供

ご利用可能な負荷分散アルゴリズム

下記14アルゴリズムの中から、お客様のサービス・システムに合わせて負荷分散アルゴリズムを選択可能です。

Round Robin ラウンドロビン
Least Connection 最小コネクション
Service Least Connection 最小ポートコネクション
Weighted Round Robin 重み付けラウンドロビン
Weighted Least Connection 重み付け最小コネクション
Service Weighted Least Connection 重み付け最小ポートコネクション
Fastest Response Time 最速応答時間
Least Request 最小HTTP要求（HTTP負荷分散時のみ）
Round Robin Strict 静的ラウンドロビン
Stateless Source IP Hash 送信元IPアドレスとポートによる負荷分散
Stateless Destination IP Hash 宛先IPアドレスとポートよる負荷分散
Stateless Src and Dst IP Hash 送信元/宛先IPアドレスとポートによる負荷分散
Stateless Per-Packet Round Robin パケット単位のラウンドロビン
Stateless Source IP Only Hash 送信元IPアドレスによる負荷分散

構成例

構成例として、webサーバ2台での負荷分散を挙げてみます。

負荷分散構成例

ネットワーク情報は次の通りです。（以下のIPアドレスは、サンプルです。）

セグメント情報 203.0.113.0/24
ゲートウェイ 203.0.113.1
バーチャルサーバー 203.0.113.10
サーバー1 203.0.113.11
サーバー2 203.0.113.12

※ 上記アドレスの他にロードバランサー管理用としてIPアドレスが3つ必要になります。
※ 非DSR構成の場合は、IPソースNAT用のIPアドレスが必要になります。

設定手順

先に挙げた、構成例を元に設定手順を説明していきます。

DSR構成と非DSR構成で設定フローが異なります。

  • DSR構成
    DSR構成の設定のフローは以下のようになります。

    1. ヘルスモニタの作成： 実サーバーの監視方法の設定を行います。
    2. サーバーの作成： 実サーバーの設定を行います。
    3. サービスグループの作成： クラスタの設定を行います。
    4. バーチャルサーバーの作成： バーチャルサーバーの設定を行います。
    5. OSの設定： 実サーバーのネットワーク設定を行います。

  • 非DSR構成
    非DSR構成の設定のフローは以下のようになります。

    1. ヘルスモニタの作成： 実サーバーの監視方法の設定を行います。
    2. IPソースNATの作成： リクエストを転送するための設定を行います。
    3. サーバーの作成： 実サーバーの設定を行います。
    4. サービスグループの作成： クラスタの設定を行います。
    5. バーチャルサーバーの作成： バーチャルサーバーの設定を行います。

    非DSR構成の場合、実サーバーに到達したリクエストのソースIPアドレスは、2. IPソースNATの作成 で設定したIPアドレスになるためサーバーのアクセスログにはクライアントのIPアドレスは記録されません。

これらの設定手順は、さくらの専用サーバをご利用のお客様向けに用意している技術ドキュメントに記載されています。詳細については、ドキュメントを参照ください。

ヘルスモニタの作成

実サーバーの監視間隔、リトライ回数などの設定を行います。

ヘルスモニタの作成

IPソースNATの作成

非DSR構成において、リクエストを実サーバーに転送する際のソースIPを設定します。

IPソースNATの作成

サーバーの作成

クラスタ内で振り分けを受け付ける実サーバーの設定を行います。

サーバーの作成

サービスグループの作成

クラスタの設定、負荷分散アルゴリズムの設定を行います。

サービスグループの作成

バーチャルサーバーの作成

バーチャルサーバーの設定、サービスグループの登録を行います。DSR構成/非DSR構成の選択もここで設定します。

バーチャルサーバの作成

応用例：IPv6⇔IPv4変換バランシング設定

専用グローバルネットワークは標準でIPv6を提供しています。ロードバランサー機器もIPv6に対応済みとなっているため、IPv6アドレスでの負荷分散を行うことができます。

ロードバランサー機器を使った応用例として、サーバーはIPv4オンリーの環境においてIPv6⇔IPv4変換バランシングを行うことができます。

※ 非DSR構成でのみ可能です。

構成例

先に挙げた構成例に、ルーター、バーチャルサーバーのIPv6アドレスを追加したものになります。

変換バランシング構成例

ネットワーク情報は次の通りです。（以下のIPアドレスは、サンプルです。）

セグメント情報 203.0.113.0/24
2001:db8:1:1::/64
ゲートウェイ 203.0.113.1
2001:db8:1:1::1
バーチャルサーバー 203.0.113.10
2001:db8:1:1::10
サーバー1 203.0.113.11
サーバー2 203.0.113.12

※ 上記アドレスの他にロードバランサー管理用としてIPv4/IPv6それぞれIPアドレスが3つ必要になります。
※ IPソースNAT用のIPv4アドレスが必要になります。

設定手順

設定手順については、先に説明した手順とほぼ同じです。異なるのは、バーチャルサーバーの作成時にIPv6アドレスを設定する点のみです。

設定フローは下記のようになります。1. ヘルスモニタの作成 ～ 4. サービスグループの作成までは既に設定済みのものを流用することも可能です。

  1. ヘルスモニタの作成（IPv4アドレス）
  2. IPソースNATの作成（IPv4アドレス）
  3. サーバーの作成（IPv4アドレス）
  4. サービスグループの作成（IPv4アドレス）
  5. バーチャルサーバの作成（IPv6アドレス）

通信フロー

IPv6⇔IPv4変換バランシングを行う際の通信フローは下記のようになります。

クライアント ～ ロードバランサー（バーチャルサーバー）： IPv6での通信になります。
ロードバランサー ～ 実サーバー： IPv4での通信になります。

変換バランシング通信フロー

このような通信となるため、サーバー側でIPv6の設定等を行うことなく、webサイトをIPv6に対応させたりすることが可能となります。サーバーから見ると、IPv4でのアクセスとまったくかわりません。

※ サーバーのアクセスログに記録されるアドレスは、2. IPソースNATの作成 で設定したIPアドレスのためIPv4アドレスで記録されることになります。

ここまで、ロードバランサーを利用した際の簡単な構成と設定について説明してきましたが、ロードバランサーの重要な機能である、パーシステンス（セッション維持）、SSLオフロードももちろん利用することができます。興味を持たれた方は、一度試して頂けば幸いです。

おしらせ

banner_server