朝日ネットにおけるソフトウエア・ロードバランサーの導入

朝日ネットでのインフラ設計・構築を担当しているラピー・ステファンです。 今回は、ソフトウエア・ロードバランサーの技術紹介と導入活用事例について、説明したいと思います。

ソフトウエア・ロードバランサーとは

ロードバランス

その名の通り、ロードバランス（負荷分散）の機能を実現するために、専用ハードウエアを使わず、一般的なハードウエアでソフトウェアパッケージを使うということです。
負荷分散が実現可能なパッケージは様々あり、使い勝手と機能に応じて選ぶものも異なってきます。

例えば、今回は主にHTTP・HTTPSというプロトコルの負荷分散について話すので、使用可能なパッケージが自ずと定まります。
HTTPロードバランサーといいますと、まず下記を思い起こします：

• Apache
  • メリット：ウェブサーバーとして主流かつ汎用性に富んでいる（特に認証周り）
  • デメリット：「何でも屋」感があり、逆に重くなる場合もあり、主流かつ汎用型が故に脆弱性の的にされやすい。また、プロクシとして柔軟性に欠ける
• nginx
  • メリット：HTTPサーバーとして、軽量化されつつも高機能。アプリケーションのフロントプロクシとして使われる事が多い。
  • デメリット：Apacheと異なる設定形式で、「.htaccess」等が使えない
• HAproxy
  • メリット：プロクシ特化型のサーバーで、TCP・SSL・HTTP・HTTPSを扱い、柔軟な条件分岐が可能
  • デメリット：直接的にコンテンツを見せるためのものではない

HTTP以外の用途で、他にBSD系のOSのL4専用のrelaydがあります。
HAproxyでもそれに近い挙動にすることも可能です。

ロードバランス方式

負荷分散の目的はつまり、対外的に1箇所の通信先にアクセスしている様に見えても、その負荷分散装置の後ろにあるサーバーへ誘導し処理させることにあります。

ニーズに応じては、負荷分散が働くネットワークレイヤーを変える事も出来ます：

• L3/L4 （IPレベル）
  • メリット：高速処理に向いている（原則、パケットを左から右へと回すだけ）・ルーターと近い運用感覚・複数の装置間で状態の共有が容易
  • デメリット：トラフィックの内容に応じた高度な論理処理が出来ない
• L7 （アプリケーションレベル）
  • メリット：高度な工夫が可能（SSLセッションを終端する・データを追加・削除・変更する等）
  • デメリット：処理性能が求められる・高可用性構成下でも切り替えには瞬断が伴う

誘導の際、様々な要件を課す事も可能です：

• 現在セッション数（least-conn）：現在発生している接続に応じて、一番利用の低いサーバーに誘導する
• 重み付け（weight）：それを設定することにより、優先的に特定のサーバーに誘導する
• セッションの持続性（sticky）：一度処理したら、同じセッションを同じバックエンドサーバ−に誘導する
• アドレス・ハッシュ（ip-hash）：IPアドレスに対してハッシュ関数を適用し、その結果で適切なサーバーへ誘導する

高可用性の要件

バックエンドの高可用性

高可用性を実現するために、良く「ロードバランサーを導入する」等という言い方をしがちですが、
冗長化出来るかどうかが大きくアプリケーションの性質に依存するものであります。

負荷分散が出来るということは、アプリケーションがまず複数のノード（又は「バックエンドサーバー」とも言う）で動いていることが大前提になります。
ただ負荷分散するだけなら、２台のノードが在る構成の例を取って、ある条件を満たすクライアントをノード１に誘導し、そうでないものをノード２に誘導します。
負荷分散はこれにより実現出来ますが、効力が大きくその条件の精度に左右され、片方のノードが落ちた時、一部のクライアントだけサービスを受けられない状況を作りかねません。

つまり、「負荷分散の実現」イコール「高可用性の実現」ではありません。
高可用性を実現するには、どのノードが問い合わせを受け付けても、処理出来ることも大前提で、片方のノードが落ちても、もう片方が引き継げる必要があります。
そのために、負荷分散装置でも、ノードの死活監視を実施し、サービスとして頼れるかどうかを判断します。

フロントエンドの高可用性

負荷分散装置を導入し、高可用性を実現する柔軟な構成があっても、その装置自体が単一障害点（英：「Single point of failure」又はその略語「SPoF」）になってしまうので、元も子もありません。

そのために、負荷分散装置を２台構成にし、設定を共有させる必要があり、 下記いずれかの方法で実現します：

• マスター・スレーブ構成：２台の装置の間でVRRP/CARPを通わせて、仮想IPアドレスを立てて、それをサービスのエンドポイントとする
• 両方アクティブ構成：更に上位に冗長構成のL4分散装置を挟んで、誘導させる

CARP

CARPとは、フェールオーバーの冗長性（いわゆる「アクティブ・スタンドバイ」又は「マスター・スレーブ」）を確保するためのプロトコルであり、元々BSD系のOSに実装された機能であります。

その仕組みはL2で採用し、本来のインターフェースに存在し得ない専用のMACアドレス空間を用いることで 「マスターの役割を持つノード」の仮想IPアドレスをARP発表するため、MACアドレス等のL2レイヤーを管理する仮想基盤（たとえばVMware）において、 CARP通信が発生する環境で下記を有効にする必要があります：

• MACアドレス変更
• プロミスキャス・モード（無差別モード）
• 偽装転送

朝日ネットにおけるソフトウエア・ロードバランサーの運用について

採用したソリューション

朝日ネットで、社外向け接続サービスの大半は、pfSenseを2013年から採用しています。
理由として：

• 冗長化機能：CARP実装が先に存在したBSD系のOSであるFreeBSDがベースになっている
• 操作性：UIが提供されているので、手順を用意すればオペレーターが操作しやすい
• 一元管理：
  • pfSenseノード間の設定の簡単な共有機能（１台だけで設定すると、設定した相手にその状態が反映される）
  • SSL証明書の簡易管理機能
  • CARP設定の簡易管理機能
  • ファイヤーウオール（ https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html ）設定の簡易管理機能

朝日ネットでは、2013年のpfSense 2.1から現在のpfSense 2.4.4まで、６年間の稼働実績があります。

2013~2014年の実現内容

社外向けサービスの改善

pfSenseの仮想インスタンス2台の構成：

• NIC :
  • WAN : 対外接続インターフェース（CARP有り）
  • LAN : 管理セグメント
  • OPT1 : サーバーバックエンド（CARP有り）
• メモリ： 1GB
• 冗長方式： CARP
• 使用した負荷分散方式： relaydによるL4方式
• レートリミット：
  • pfによる、TCPレベルの過剰なアクセスの一時的ブロック
  • 過剰利用は監視で拾い、過剰利用者をファイヤーウオールのACLで登録し、制御

対応したアプリケーションは今まで、DNSラウンドロビンにより負荷分散をしていたが、高可用性の要件が出たため、下記のアクションを取りました：

• DNSラウンドロビンを止めて、対外的エンドポイントをWAN仮想IPアドレスに向けた
• ポート80のトラフィックを均等に分散する様に設定
• HTTPヘルスチェックを設定
• ポート443の管理画面については、1台のみしかその要件を満たせないため、1台のみバックエンドとして定義
• サーバー側でポリシールーティングを設定：バックエンドNICから入ったものをpfSenseのOPT1仮想IPのアドレスから返す
• pfSenseでOPT1からWANへとNATを設定

社内向けサービスの導入

pfSenseの仮想インスタンス2台の構成：

• NIC :
  • WAN : 対外接続インターフェース（CARP有り）
  • LAN : 管理セグメント
  • OPT1 : サーバーバックエンド
• メモリ： 2GB
• 冗長方式： CARP
• 使用した負荷分散方式： apacheによるL7方式
• レートリミット：
  • pfによる、TCPレベルの過剰なアクセスの一時的ブロック
  • 過剰利用は監視で拾い、過剰利用者をファイヤーウオールのACLで登録し、制御

要件は、社外からアクセスする際、いずれかの条件にマッチしたものを許可します：

• 許可された拠点のIPアドレス
• 社内の証明局のクライアント証明書を使っている

取ったアクション：

1. 当時はまだSNI対応が不十分だった疑いがあったため、社内サービス毎に1個のIPアドレスをCARPで定義し、違うフロントエンドを定義
2. Apache設定でカスタム設定を入れて、証明書を検証する設定を追加
3. IPアドレスは文字列として入れる事が出来たが、pfSenseで本来入れるべきAliasesの情報が参照出来ず、重複設定を導入
4. バックエンド側でmod_rpaf/mod_remoteipを入れて、X-Forwarded-Forヘッダーの情報をログで反映

2015~2016年の実現内容

社内向けサービスの更新

既存構成をアップグレードして、HAproxyがより細かく条件の分岐と精査が可能だと気づき、HAproxyによるL7方式へ移行しました：

• HAproxyは純粋に「ホスト名」や「パス」、「接続プロトコル」、その他の条件を個別の変数として捉えることが出来るおかげ、柔軟な条件定義が可能で、設定をApacheより明確に出来、設定の簡素化が可能になった。
• pfSenseのHAproxyパッケージはACLの条件定義でAliasesの定義の参照を可能にしているおかげで、運用の合理化に成功した。
• L7で処理しているおかげで、アプリケーションが必要とするヘッダーの付与・削除・操作がある程度出来る。
• 冗長化されたpfSense 2台構成とソース・ルーティングを使うことで、通常のハードウエア・アプライアンスの様にOSを安全にアップグレード出来る様になった。

2017~2019年の実現内容

社外向けサービスの更新

朝日ネットの全サービスのHTTPS化を進めるに当たり、完全にSSL機能をバックエンドから切り離して、pfSenseへの外出しに成功しました。
アプリケーションとSSLを切り離すことにより、裏のサーバーに影響を与えないSSL機能のみの整備が可能になり、アップグレード計画の難易度を下げることに成功しました。

アプリケーションによっては、監査要件が発生し、複雑な処理からデータを拾う必要があったが、標準機能で実装に成功しました：

• 簡単なヘッダー処理：HAproxyはbase64処理を標準機能として持っている
• 拡張LUAスクリプトによる文字列マッチでXML返答文から監査事項を確保
• ログ形式も自在に組み替えられるので、バックエンドサーバー1台ずつのログをみなくても、HAproxyのログをsyslogで一元管理し、必要な情報をすべてそこから拾う
  • アクセス統計、過剰利用：それに基づいて、より上位の場所から攻撃を防止する
  • TLSバージョンの利用統計：それに基づいて、機能レベルを変更する
• L7のレートリミット：sticky情報を取ることで、一定期間内の過剰利用を補足し、一時的にエラー４２９を返し、過剰利用を緩和
• 国別トラフィックのバックエンド誘導：日本国内とそうでないトラフィックを別々のサーバーに誘導する
• Let's Encryptという無償証明局と連動して、HTTPSサービスを提供

まとめ・次回予告

今回はソフトウエア・ロードバランサーを仮想基盤上で管理するに当たって、HTTPに基づいたアプリケーションの冗長構成の注意点・考慮事項、実現可能な事例をいくつかを紹介しました。 次回以降は、上げた事例の現在の形について、具体的な設定と構成について触れてみたいと思います。

採用情報

朝日ネットでは新卒採用・キャリア採用を行っております。

• 新卒採用 ｜株式会社朝日ネット
• キャリア採用｜株式会社朝日ネット