ネットワークの負荷分散を手軽に - OSC2015 Hokkaido
2 likes3,060 views
ネットワークロードバランシング（負荷分散）を手早く解説する． イベント（Open Source Conference 2015 Hokkaido）発表用スライド．
ネットワークの負荷分散を手軽に - OSC2015 Hokkaido
- 2. 商標について ? F5，F5 Networks，F5 のロゴ，および本文中に記載されている製品名は，米国および他 の国における F5 Networks, Inc の登録商標または商標です． ? Microsoft および Microsoft Azure は，米国 Microsoft Corporation の米国およびその他 の国における登録商標または商標です． ? CentOS の名称およびそのロゴは，CentOS ltd の登録商標または商標です． ? その他本文中に記載されている製品名および社名は，それぞれ各社の登録商標または商標 です． ? 本文中では ? および ? の表記は省略しています．
- 3. 本日のお話 ? ネットワークの負荷とは何か ? 負荷を分散するとはどういうことか ? どのようにして負荷を分散するのか ? 負荷分散装置を作ってみる 【前提】 Ethernet / IPv4 / TCP での通信を前提にお話します．
- 4. 自己紹介 ? 竹林 信哉 ? UltraMonkey-L7 の開発者（元?プロジェクトマネージャ） ? 某 SIer にて，開発プロジェクトに対する Java の技術支援を行っている． ? 入社当初（10 年前）は CGL（Carrier Grade Linux）の開発に従事． @chi9rin
- 5. ネットワークの負荷とは ? ネットワークの伝送路の混み具合 ? たくさんのデータが流れる → 「負荷が高い」 流量が少ない 【負荷が低い】 流量が多い 【負荷が高い】 レスポンスが遅い 処理が追いつかない 【負荷が高い】
- 6. 負荷が高くなる要因は様々 ? アクセスするクライアントが多い ? 変なプロトコルを使っている ? 途中のネットワーク機器が遅い ? 途中のネットワーク機器が故障して 迂回させられている ? ネットワークが細い ? ホストの処理能力が低い ? ??? どれか一つのみが 原因であることは少ない． 一つの原因が不具合を招き， それがさらに???というパタン．
- 7. 負荷が高くなる要因は様々 ? アクセスするクライアントが多い ? 変なプロトコルを使っている ? 途中のネットワーク機器が遅い ? 途中のネットワーク機器が故障して 迂回させられている ? ネットワークが細い ? ホストの処理能力が低い ? ??? 自分で何とか出来る 分散すればいい あきらめる
- 8. 負荷を分散するとは？ ? ネットワークが細い → アクセスラインを複数用意し，分散する ? Teaming（Bonding）の Link Aggregating ? CDN（ネットワーク的に近いところにアクセスさせる） ? ホストの処理能力が低い → 複数のホストで処理をする ? 同じ処理をするホストを複数並べ，リクエストごとに処理するホストを切り替える． ? 処理性能を上げるクラスタリングの一種．
- 10. 負荷分散のイメージ - ネットワークの負荷分散 ? 複数の物理配線を用いて，伝送路の混雑を低減する ? 一般に NIC Teaming（Linux では Bonding）と呼ばれる 本ページは Link Aggregation（IEEE 802.3ad）の例 ? 1000BASE-T を 3 本束ねて約 3Gbps のラインとして利用する，など ? 対応するネットワークスタック，スイッチが必要 まとめて一本に見せる
- 11. 負荷分散のイメージ - ホストの負荷分散 ? 負荷分散装置を利用し，通信パケットの振り分け，複数のホストで処理する ? クライアントは hoge.example.com に向かってアクセスするが，実際に到達するのは foo だったり bar だったり． ? クライアントからはひとつのホストに見える（負荷分散されていることがわかりにくい） http://hoge.example.com/ http://hoge.example.com/ http://hoge.example.com/ foo.example.com bar.example.com LB hoge.example.com まとめて一台に見せる
- 13. ホストの負荷分散に必要なもの 1. 負荷分散装置（下図 LB，ロードバランサ） 2. リクエストを処理するマシン 3. ネットワーク配線 http://hoge.example.com/ http://hoge.example.com/ http://hoge.example.com/ foo.example.com bar.example.com LB hoge.example.com (1) 負荷分散装置 (2) 処理するマシン (3) ネットワーク配線
- 14. ホストの負荷分散の仕組み（本例は NAT 構成※） 1. LB が代表して hoge.example.com 宛てのリクエストを受け付け，実際に処理するサーバ （リアルサーバと呼ばれる）を決定，パケットを転送する． 2. リアルサーバがリクエストを処理し，レスポンスを作成する． 3. LB が代表してレスポンスをクライアントに返却する． http://hoge.example.com/ http://hoge.example.com/ http://hoge.example.com/ foo.example.com bar.example.com LB hoge.example.com (1) 代わりに受け取り (2) 処理を割り振って (3) 代わりに返す ※ NAT の他に有名どころとして DSR 構成がある．DSR については後述．
- 16. ? Layer 4 Load Balancing ? 適している通信： POP3，IMAP など ? 宛先 IP アドレスとポート番号までを見る． ? TCP セッションの中でアプリケーションセッションが 完結する処理に向いている． ? Layer 7 Load Balancing ? 適している通信： HTTP，FTP PASV など ? 通信される電文の中身まで見て，負荷分散する． ? たとえば，HTTP のリクエスト文字列など． 負荷分散の方式 ? 大きく分けて二種類．何をもとに分散するかで選択． Application Presentation Session Transport Network Data Link PHY MAC Address … 1000BASE-T … IP Address … TCP / UDP Port … TCP Context … SSL Context … Request URL … Performance Flexibility
- 17. すごい Layer 7 Load Balancing ? たとえば HTTP リクエストに応じて，処理をするサーバを分けることが可能． ? WebAPI を公開していたり，静的なファイルのみ別のサーバに保管してある場合などに便利． ? Cookie に入っている認証情報を使って HTTP セッションを維持する機能をもつ製品もある． LB v1.api.example.com v2.api.example.com http://api.example.com/api/v2/friends api.example.com /api/v1/* は v1.api.～ へ /api/v2/* は v2.api.～ へ /api/v1/friends /api/v2/friends http://api.example.com/api/v1/friends
- 18. すごい Layer 4 Load Balancing ? アクセス元 IP アドレスやポート番号をベースに負荷分散するのが主流． アプリケーションで扱う電文やセッションは無視．機能面では L7 に見劣りするが??? ? L4 LB では，DSR（Direct Server Return）方式が利用可能で，ネットワーク負荷の低 減が可能 ? L7 の場合は IP パケットの解析が必要となるため，基本的には「クライアント - LB」「LB - リアルサー バ」の 2 コネクションが必要で，しかも通信の行きと帰りが同じルートになる（NAT 以外は難しい） そのため，LB がボトルネックになる可能性がある．
- 19. NAT の通信の流れ LB 192.168.0.102 AA:BB:CC:DD:EE:02 192.168.0.1 AA:BB:CC:DD:EE:00 192.168.0.101 AA:BB:CC:DD:EE:01 192.168.100.1 EE:DD:CC:BB:AA:00 SW 192.168.0.1 AA:BB:CC:DD:EE:00 192.168.0.101 AA:BB:CC:DD:EE:01 192.168.0.1 AA:BB:CC:AA:BB:01 192.168. 0.1 AA:BB:CC:AA:BB:00 AA:BB:CC:AA:BB:00 / AA:BB:CC:AA:BB:01 宛先 IP アドレス 宛先 MAC アドレス 192.168.100.1 EE:DD:CC:BB:AA:00 192.168.100.1 AA:BB:CC:AA:BB:01 TCP コネクションは 2 つ（緑線，紫線）
- 20. DSR とは ? LB，リアルサーバともに同じサブネットに，同じ IP アドレスを持っている（！） ? LB は Ethernet フレームにある宛先 MAC アドレスをリアルサーバの MAC アドレスに付けかえ て再度放流（！！） ? 指定された MAC アドレスをもつリアルサーバが放流されたパケットに食らいつき，レスポンスを 生成．（！！！） ? 帰りは通常のルーティングをして返す．．． ? TCP コネクションは，リアルサーバとクライアントの間で構築される ? LB は上り（クライアント→サーバ）パケットの MAC アドレスを付け替えて転送するだけ Direct に Server と Client がセッションを構築し，レスポンスが Return される．
- 21. DSR の通信の流れ LB 192.168.0.102 192.168.0.1 AA:BB:CC:DD:EE:02 192.168.0.1 AA:BB:CC:DD:EE:00 192.168.0.101 192.168.0.1 AA:BB:CC:DD:EE:01 192.168.100.1 EE:DD:CC:BB:AA:00 SW 192.168.0.1 AA:BB:CC:DD:EE:00 192.168.0.1 AA:BB:CC:DD:EE:01 192.168. 0.1 AA:BB:CC:AA:BB:00 AA:BB:CC:AA:BB:00 / AA:BB:CC:AA:BB:01 宛先 IP アドレス 宛先 MAC アドレス TCP コネクションは 1 つ（緑線） 192.168.100.1 EE:DD:CC:BB:AA:00 192.168.100.1 AA:BB:CC:AA:BB:01
- 23. いろいろな製品があります，OSS も． ? 有償プロダクト（アプライアンス含む） ? F5 Networks 「BIG-IP」 【ハードウェア／ソフトウェア】 ? FUJITSU 「IPCOM」 【ハードウェア】 ．．． ? オープンソースソフトウェア プロダクト※ ? Apache mod_proxy_balancer ? nginx ? UltraMonkey ．．． ※ OSS は無料と言われますが，お金がかからないというだけ．使い捨てられるのは気持ちよくありません． コミュニティへのフィードバックを是非お願いします．
- 24. でも难しいんでしょ？
- 25. LB を作ってみます ? 登壇者が UltraMonkey-L7 の開発者なので，今回は UltraMonkey-L7 を使います ? NAT 方式 ? Round Robin 方式（全ての利用可能なリアルサーバに，一様に負荷を分散する） ? Microsoft Azure 上の仮想マシンに作ります ? 基本的な環境ができあがっている CentOS にセットアップします ? リアルサーバは設定済みです
- 27. まとめ ? 負荷分散は簡単にできます ? ソフトウェアロードバランサのセットアップは簡単で，既存ネットワークの影響は大きくありません ? 用途に応じて，L4 または L7 を選ぶと良いです ? それぞれに特徴があり，また，既存のネットワーク構成によっては適用できる構成に制限が生じます
- 29. UltraMonkey-L7 の宣伝 ? Linux で動作するソフトウェアロードバランサ ? アクティブな開発者は 5 名ほど（すべて日本人） ? 某社の品質?性能試験をパスされたもののみリリースされる ? HA クラスタは Pacemaker を利用し，性能試験モデルは TPC-W ? 数千クライアントの同時接続を安定して高速に処理することを確認 ? ソースコードのほか，バイナリとして X86 向けに RPM?DEB パッケージをリリース ? Raspberry Pi でも動きます（野良 make 必須） ? ユーザと開発者を随時募集中 http://osdn.jp/projects/ultramonkey-l7/