朝日ネット 技術者ブログ

朝日ネットのエンジニアによるリレーブログ。今、自分が一番気になるテーマで書きます。

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

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

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

ロードバランス

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

例えば、今回は主に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アドレスに対してハッシュ関数を適用し、その結果で適切なサーバーへ誘導する

高可用性の要件

バックエンドの高可用性

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

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

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

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

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

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

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

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

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

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

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

採用したソリューション

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

  • 冗長化機能:CARP実装が先に存在したBSD系のOSであるFreeBSDがベースになっている
  • 操作性:UIが提供されているので、手順を用意すればオペレーターが操作しやすい
  • 一元管理:

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

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情報を取ることで、一定期間内の過剰利用を補足し、一時的にエラー429を返し、過剰利用を緩和
  • 国別トラフィックのバックエンド誘導:日本国内とそうでないトラフィックを別々のサーバーに誘導する
  • Let's Encryptという無償証明局と連動して、HTTPSサービスを提供

まとめ・次回予告

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

採用情報

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