JApan Network Operators' Group

ロードバランスを考える

概要

次の制約下におけるロードバランシングに関する悩みを議論します。(これはコンテンツ屋によくある制約だと思っています)

  • /24のサイズを超えるサーバ群にバランシングしたい
  • 複数セットのロードバランサを並列で運用したい
  • クライアントのIPをサーバで知りたい
  • SSLの通信が含まれる
  • もちろんコストは抑えたい

発表内容は次の流れを想定しています。

  • 今回前提としている制約のどこが難しいか
    • NATするとLBにパケットを返さないといけない
      • SNATもするとクライアントIPがわからない(暗号化されてなければ、x-forwarded-forの挿入もできる)
      • SNATしないとLBに返す工夫をしないといけない
    • NATしない場合
      • macアドレス書き換えの場合は同じセグメントに置かないといけない
        • linuxの場合、arp周り、もしくはiptablesの設定が必要
      • IPIP等でトンネルするとmssを設定する必要がある
      • L3DSRもある。
  • SSLが含まれる場合、SNATだと要件を満たせない
  • SSLをロードバランサに処理させてレイヤ7で使う手もある。(httpsならいいけど、それ以外のときはどうする?)

以上について発表で簡単な説明を行い、どのように考え、どんな実装をしているかパネラー・会場の皆様で議論できればと思います。

周りの人がどうロードバランシングしているかってなかなか知る機会がないと思うので、よい情報交換ができたらと思います。

発表者

吉野 純平 (株式会社ミクシィ)

田中 淳 (株式会社サイバーエージェント)


公開資料

資料: ロードバランスを考える (吉野)

資料: ロードバランスを考える (田中)

参考資料

【ロードバランサとは】

  • クライアントからのアクセスを一元的に受け付け、複数のサーバに転送する装置

loadbalancer

【DSR: Direct Server Return】

  • クライアントからのリクエストをロードバランサからサーバが受け取り、レスポンスをロードバランサを経由せずに、クライアントへ直接返す方式

DSR

【Layer4, Layer7 バランシングの違い】

  • L4 バランシングの特徴
    • L4 の情報を基にバランシング
    • 同一 IP からのリクエストは同じサーバに転送するなど、セッション維持機能を利用可
    • L4 までの情報を基にバランシングするため、LB の負荷が低い
  • L7 バランシングの特徴
    • L7 までの情報を基にバランシング
    • アプリケーション層の情報を参照することで、高度なバランシングが可能
    • L7 まで参照するため、高度なバランシングが可能だが、L4 バランシングに比べて負荷が高い

L4_L7_balancing

議論ログ
Q:会場からの質問
A:発表者からの回答/コメント
C:会場からのコメント

<ロードバランサの構成について>

Q: DSR を使わない理由はなんですか?

A: DSR だけでは SSL の終端ができないために利用していない。DSR を用いて SSL の終端を実現するには以下のような方法がある。

  • ロードバランサを2段構成にすることで SSL の終端を実現

Q: サーバが強力になっているが、LB は軽くしていきたいという思いはあるか?

A: SSL 処理はサーバにしてほしい。

Q: LB も仮想化を考える必要はあるか?

A: 各社仮想化された製品があるが、チューニングがポイントであり、環境によっては能力を出しきれないのでは?

C: 外部公開用途はアプライアンス、内部用用途は DSR 等用い、API により一元管理でトラヒックを分散している。

C: DSR + GSLB を組み合わせて構成している。

C: L3 DSRを使ってあげるとTunnelの問題を救える。ただしサーバに手を入れる必要がある。

C: 昔は分散を使っていたが、管理面で集約に倒してきている。でも、集約し過ぎるとキャパシティプランニングが難しい。集中よりの分散が最適ではないだろうか。

<ヘルスチェックについて>

Q: ロードバランサ - サーバ間に標準的なヘルスチェックはあるのか?

A: ポートチェック、ping チェック、コンテンツチェックなどの方法が一般的に利用されている。

Q: (監視とサービストラフィックの経路が違う問題に対して) ルータにログインしてチェックするのはあり?

A: サービス監視で、nagiosなどを使ってヘルスチェックしているが、内部 IP から内部 IP のチェックなので通ってしまう。ロードバランサから出てくるパケットでチェックできるようにしたい。

<ロードバランサのコミュニティについて>

Q: ロードバランサや、サーバの設計について話をしているコミュニティはあるのか?

A: コンテンツ事業者の飲み会程度ならある。要望があれば企画して行きたい (吉野さん)

C: ベンダーはトラブルの話はよく聞くが、正常に動作した話等、上手な使い方の情報は入ってこないので、そのような情報を共有したい。

<SPDY について>

Q: ロードバランサから見て SPDY はどうか?

A: セッションの数が減るのはいいことだが、ロードバランサから見ると処理が多くなり大変そう。圧縮の処理は負荷が大きい。

Q: SPDY に対してどのような対応をしていくのか?

A: 今は分からないが、これから検証してベストプラクティスを見つけて行きたい。

ソーシャルボタンを読み込み中か、 お使いのブラウザではソーシャルボタンをご利用いただけません。

→プログラムへ戻る

JANOG32 Meeting
JANOG32はさくらインターネット株式会社のホストにより開催しました。