ロードバランサ（負荷分散装置）入門1
Introduction to LoadBalancer vol.1
(菅野 明洋 : FPTS Field Researcher)
(Akihiro Sugeno : FPTS Field Researcher)
本資料は会合後にディスカッションされた内容をふまえ記載しています。他の会合の状況を踏まえ、多少ブラッシュアップを行っていく予定です。
Comment
■はじめに
■Introduction
この資料では、「映像制作パイプラインとアーティストのテクニック 6」に参加する映像系やゲーム系の参加者間のディスカッションのために、様々なロードバランサーの役割やインフラ構築上のポイントを紹介したいと思います。
また、ロードバランサの仕組みを軽く知ることで設計やトラブルシュートの助けになったら幸いです。
under construction...
■概要
■Overview
他のコンピュータからアクセスされるサーバは、クライアントからのアクセスが集中した際には大きな負荷がかかります。
アクセス集中したサーバの負荷を軽減し、システム全体の処理量を増やすためには同じ役割を持つサーバを複数用意し、アクセスを分散させる仕組みが必要になります。
一例として、Webサーバなどの負荷分散の方法は、Webサーバを複数用意しロードバランサを用いて外部からのアクセスを各Webサーバに転送します。
本項目では、ロードバランサの概要について説明しております。構築方法については、「ロードバランサ(負荷分散装置)入門2」にて説明します。
under construction...
■オンラインサービスの要求
■Requirements of load balancer in online service
サーバへのアクセスがサーバのキャパシティを超えた場合、応答が遅くなることや接続しにくくなるなどの問題が発生しサービスの質が低下してしまいます。
この状態が継続した場合、ユーザへの不満が倦厭されてしまいます。
また、インターネットの普及によりネットワークインフラやWebサイト、オンラインコンテンツ等のオンラインサービスは電気、ガス、水道などのライフラインと同様に日常生活に不可欠なものになりました。
オンラインサービスは24時間365日の稼働が期待されており、障害や保守などによるサービス停止は日常生活へ大きく影響するようになりました。
これらの背景により、オンラインサービスは下記のような能力が求められています。
- スケーラビリティ(拡張性)：
- サーバの処理能力が不足した場合、容易に拡張できること
- アベイラビリティ(可用性)：
- 故障が発生してもサービス継続ができること
- サービスを止めずに保守や修理ができること
※すべてのシステムが24時間365日の稼働を期待する必要はありませんが、ユーザの利便性をあげる場合は無停止を前提とすることが多いです。
- サーバの処理能力が不足した場合、容易に拡張できること
- 故障が発生してもサービス継続ができること
- サービスを止めずに保守や修理ができること
under construction...
■アプリケーションサーバの抽象化
■Application server abstraction
ロードバランサは他のコンピュータからのリクエストを受け付け、ロードバランサの配下のアプリケーションサーバ(例：Webサーバ)にリクエストを受け渡します。
このため、他のコンピュータから見るとアプリケーションサーバは1台に見えます。
また、このような構成にすることで、ロードバランサの配下にあるサーバで起きた事象の対処をロードバランサで決定することができます。
たとえば、ロードバランサの配下にあるサーバで障害が起きた場合、正常なサーバのみ処理させることが出来ます。
これらのように対処することで、障害が発生した場合でも他のコンピュータにサービスを提供し続けることが出来ます。
under construction...
■スケーラビリティ(拡張性)について
■Scalability of load balancing
システムにおいてのスケーラビリティとは、使用可能なハードウェア資源(リソース)に応じて単位時間あたりの処理能力が向上させる能力や用途の拡大などに応じた機能拡張できるかを指します。
本項目においては、システムの負荷の増大に応じて処理性能を強化できるかという点を指しています。
実際にシステムの処理性能を拡張する方法として、主に二つの考え方があります。
一つ目は、性能や機能の高い機器やシステムに交換することで規模を拡張する「スケールアップ」があります。
二つ目は、機器やシステムを増やすことで1台あたりの負荷を軽減する「スケールアウト」があります。
ロードバランサはスケールアウトしたサーバへのリクエストの割り当てを行い、台あたりの処理負荷を均等化する処理を行います。
under construction...
■アベイラビリティ(可用性)
■Availability of load balancing
アベイラビリティとは、コンピュータやシステムの壊れにくさ等、サービスを継続して提供できる能力です。
ロードバランサは、故障が発生してもサービスを継続して提供することやサービスを止めずに保守や修理が出来ることが求められています。
サービスを継続して提供するためにロードバランサは配下のサーバの状態や送信されたリクエストを管理し、状況に応じて処理を決定します。
例えば障害が発生した場合、障害が発生したサーバへの処理を別のサーバへ引き継いだり、障害があったサーバに処理が割り当てられないようにします。
また、保守や修理などでは、サービスを継続したまま交換対象のサーバへの処理割り当てを止め、新たなサーバと交換することが出来ます。
under construction...
■ロードバランサの負荷分散の種類
■Types of load balancing for load balancers
ロードバランサが受信したパケット転送先を決定する方法にはいくつか種類があります。
負荷分散方式は代表例は下記の通りになります。
- ラウンドロビン(均等負荷分散)
リクエストを各サーバへ均等に転送します。
この方式では各サーバで処理するリクエストの数が均等になるため、ロードバランサ配下のサーバの処理性能は同じである必要があります。
また、リクエストごとに処理負荷が違う場合は、サーバの負荷に偏りが発生することがあります。
- 重み付けラウンドロビン(重み付け均等負荷分散)
サーバに優先順位をつけ転送します。
この方式では、ロードバランサ配下のサーバの処理能力に応じてリクエストの分散比率を指定することが出来ます。
ロードバランサ配下の各サーバの処理能力に違いがある場合等で使用されます。
- リーストコネクション(最小接続数)
この方式では、各サーバが通信するクライアントの数が均等になるようにリクエストを転送します。
ロードバランサはリクエストの送信元IPアドレスやセッション数に基づいて各サーバの接続中のクライアント数をカウントし、接続数が最も低いサーバにリクエストを転送します。
- リーストトラフィック(最小データ通信量)
この方式では、ロードバランサ配下のサーバが転送するデータ量が均等になるようにリクエストを転送します。
ロードバランサが各サーバが転倒したデータ量を計測し、転送したデータ量が最も少ないサーバにリクエストを転送します。
コネクションあたりのデータ通信量が多い環境で有効な方法です。
- ファーストアンサー(最小応答時間)
この方式では、応答時間が最も短いサーバにリクエストを転送します。
ロードバランサは各サーバへリクエストを送信し、最も応答が早かったサーバに優先的にリクエストを転送します。
計測値に基づきリクエストを調整するため、サーバの処理性能に差がある環境で有効です。
- リーストプロセッシング(最小サーバ負荷)
この方式では、ロードバランサ配下のサーバの負荷状況(CPUやDISK IO等)を元にリクエストを転送します。
各サーバのハードウェアの負荷に基づくため、各サーバの運用や処理性能に違いがある環境でも有効です。
- L7分散
この方式では、HTTPリクエストのヘッダ情報やURL等を基にリクエストを転送します。
他の方式は、OSI参照モデルの第4層(トランスポート層)で処理されているのに対し、この方式は第7層(アプリケーション層)で処理されています。
第7層で処理を行うことで、より高度な転送ルールを設定することが出来ます。
処理自体は第7層としての処理ではありますが、この機能自体はL4スイッチに実装されていることもあります。
一般的にWebサーバの場合はラウンドロビン等が使用されますが、Webアプリケーションの処理特性によっては他の方法を使用する場合があります。
例えば、Disk IOや通信量などが大きい場合は、最小サーバ負荷や最小データ通信量による転送先が選ばれることがあります。
最近は、L7分散を用いた負荷分散の採用事例も増えています。
under construction...
■L4とL7ロードバランサについて
■Difference between L4 and L7 load balancer
ロードバランサは大まかにL4ロードバランサとL7ロードバランサと呼ばれる物があります。
L4ロードバランサは、OSI参照モデルの第3層(ネットワーク層)と第4層(トランスポート層)にて解析し処理を行います。
つまり「IPアドレス」、「ポート番号」を基に処理を行います。
それに対し、L7ロードバランサはL4ロードバランサの機能の他にOSI参照モデルの第7層(アプリケーション層)で処理を行うため、高度な分散ルールを定めることが出来ます。
具体的にはURLやHTTPの情報等を用いた負荷分散が出来るようになります。詳細は後述の「L7ロードバランサの機能」にて説明します。
最近では、クラウドサービスでも当たり前のようにL7ロードバランサを選択できるようになりました。
L7ロードバランサ相当になると、ヘルスチェックもサーバの死活やポートへの応答だけで無くサービス(アプリケーション)の状態を識別し転送先を決定することが出来ます。
例えば、Webサーバのプログラムが稼働していてもDBへの接続が出来ないというような状態(アプリケーション上での障害)も認識し転送先リストから除外するということが可能になります。
他にはL7ロードバランサにSSLアクセラレータの機能を持たせることが出来るため、SSL の暗号化/復号化処理機能をロードバランサに一任しサーバの負荷を軽減させることができます。
under construction...
■L7ロードバランサの機能
■L7 load balancer
L7ロードバランサの機能は主に下記の通りになります。
- URIスイッチ
サービスやコンテンツごとに異なるURIと転送ルールを定義することでリクエストを特定のサーバへ転送が可能な機能です。
URIと転送ルールを定義することでリクエストを特定のサーバへ転送する機能です。
つまり機能単位(サービス/コンテンツ)毎に処理を行うサーバを指定することが出来ます。
- SSLオフロード
複数のWebサーを運用する場合、各サーバにてSSL証明書の設置と管理を行う必要がありました。
この機能は、ロードバランサが代理でSSLによる通信の暗号化を行うことができ、運用コスト低減等有用です。
ロードバランサが集中管理することでWebサーバの処理負荷を大幅に低減することができます。
under construction...
■パーシステンス
■Load balancing with persistence
パーシステンスとは、特定のユーザからのリクエストを特定のサーバに転送し続ける機能のことを指します。
HTTPリクエストの様な比較的短い時間で接続を切ってしまうため、クライアントが常に同じサーバに接続されているとは限りません。
この機能は同一クライアントからのリクエストを常に同じサーバへ転送する必要があるWebシステムにて使用されます。
例として、サーバ上に格納されたキャッシュデータやセッションデータ等の一時的なデータなどサーバ毎に差異が発生している場合は同じサーバで処理し続けることが望ましいと言えます。
また、パーシステンスの方式は代表例を挙げると下記の通りになります。
- 送信元IPアドレス/送信先IPアドレス
送信元や送信先のIPアドレスを元にサーバの接続先を決定します。
一度接続が行われたクライアントとサーバの情報をロードバランサ側で保持し、二度目の接続時に情報を用いることでクライアントは同じサーバに接続させます。
- Cookieパーシステンス
HTTP/HTTPSで接続する環境にて、ロードバランサから発行されたCookieを基にサーバの接続先を決定する方式です。
- SSLセッションID
SSLプロトコルでは、接続に対してSSLセッションIDが付与されます。
このセッションIDを基にクライアントを識別し、転送先サーバを決定します。
- Contentベース
同じIPアドレスのアクセスに対して、ホスト名やURIを基に転送先サーバを決定します。
一つのIPアドレスやドメインに対して、複数の転送パターンを作成したい時に有意です。
under construction...
■ロードバランサのヘルスチェック
■Health check of load balancer
ロードバランサがサーバへリクエストを転送する際に、障害により停止しているサーバへリクエストを転送すると無駄が発生します。
そのためロードバランサはロードバランサ配下のサーバが応答可能か定期的にチェックを行います。
主なヘルスチェック機能は下記の通りになります。
- PING(L3)
ロードバランサ配下のWebサーバにICMP echoリクエストが正常に受信されているか検証を行います。
- TCP/UDP(L4)
ロードバランサ配下のサーバにTCPコネクションを確立します。
TCP/UDPが期待する応対かどうかも検証します。
- HTTP(L7)
ロードバランサ配下のWebサーバにHTTPリクエストを送信し、正常なレスポンスが返ってくるか確認を行います。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
最近ではL3、L4に限らずL7ヘルスチェックを使用する例が増えたり、実装を容易にするライブラリも公開されております。
これらの機能を正しく利用することでサービス稼働率が向上し、ユーザの満足度も向上すると思います。
under construction...
under construction...
■スケーラビリティ(拡張性)について
■Scalability of load balancing
システムにおいてのスケーラビリティとは、使用可能なハードウェア資源(リソース)に応じて単位時間あたりの処理能力が向上させる能力や用途の拡大などに応じた機能拡張できるかを指します。
本項目においては、システムの負荷の増大に応じて処理性能を強化できるかという点を指しています。
実際にシステムの処理性能を拡張する方法として、主に二つの考え方があります。
一つ目は、性能や機能の高い機器やシステムに交換することで規模を拡張する「スケールアップ」があります。
二つ目は、機器やシステムを増やすことで1台あたりの負荷を軽減する「スケールアウト」があります。
ロードバランサはスケールアウトしたサーバへのリクエストの割り当てを行い、台あたりの処理負荷を均等化する処理を行います。
under construction...
■アベイラビリティ(可用性)
■Availability of load balancing
アベイラビリティとは、コンピュータやシステムの壊れにくさ等、サービスを継続して提供できる能力です。
ロードバランサは、故障が発生してもサービスを継続して提供することやサービスを止めずに保守や修理が出来ることが求められています。
サービスを継続して提供するためにロードバランサは配下のサーバの状態や送信されたリクエストを管理し、状況に応じて処理を決定します。
例えば障害が発生した場合、障害が発生したサーバへの処理を別のサーバへ引き継いだり、障害があったサーバに処理が割り当てられないようにします。
また、保守や修理などでは、サービスを継続したまま交換対象のサーバへの処理割り当てを止め、新たなサーバと交換することが出来ます。
under construction...
■ロードバランサの負荷分散の種類
■Types of load balancing for load balancers
ロードバランサが受信したパケット転送先を決定する方法にはいくつか種類があります。
負荷分散方式は代表例は下記の通りになります。
- ラウンドロビン(均等負荷分散)
リクエストを各サーバへ均等に転送します。
この方式では各サーバで処理するリクエストの数が均等になるため、ロードバランサ配下のサーバの処理性能は同じである必要があります。
また、リクエストごとに処理負荷が違う場合は、サーバの負荷に偏りが発生することがあります。
- 重み付けラウンドロビン(重み付け均等負荷分散)
サーバに優先順位をつけ転送します。
この方式では、ロードバランサ配下のサーバの処理能力に応じてリクエストの分散比率を指定することが出来ます。
ロードバランサ配下の各サーバの処理能力に違いがある場合等で使用されます。
- リーストコネクション(最小接続数)
この方式では、各サーバが通信するクライアントの数が均等になるようにリクエストを転送します。
ロードバランサはリクエストの送信元IPアドレスやセッション数に基づいて各サーバの接続中のクライアント数をカウントし、接続数が最も低いサーバにリクエストを転送します。
- リーストトラフィック(最小データ通信量)
この方式では、ロードバランサ配下のサーバが転送するデータ量が均等になるようにリクエストを転送します。
ロードバランサが各サーバが転倒したデータ量を計測し、転送したデータ量が最も少ないサーバにリクエストを転送します。
コネクションあたりのデータ通信量が多い環境で有効な方法です。
- ファーストアンサー(最小応答時間)
この方式では、応答時間が最も短いサーバにリクエストを転送します。
ロードバランサは各サーバへリクエストを送信し、最も応答が早かったサーバに優先的にリクエストを転送します。
計測値に基づきリクエストを調整するため、サーバの処理性能に差がある環境で有効です。
- リーストプロセッシング(最小サーバ負荷)
この方式では、ロードバランサ配下のサーバの負荷状況(CPUやDISK IO等)を元にリクエストを転送します。
各サーバのハードウェアの負荷に基づくため、各サーバの運用や処理性能に違いがある環境でも有効です。
- L7分散
この方式では、HTTPリクエストのヘッダ情報やURL等を基にリクエストを転送します。
他の方式は、OSI参照モデルの第4層(トランスポート層)で処理されているのに対し、この方式は第7層(アプリケーション層)で処理されています。
第7層で処理を行うことで、より高度な転送ルールを設定することが出来ます。
処理自体は第7層としての処理ではありますが、この機能自体はL4スイッチに実装されていることもあります。
一般的にWebサーバの場合はラウンドロビン等が使用されますが、Webアプリケーションの処理特性によっては他の方法を使用する場合があります。
例えば、Disk IOや通信量などが大きい場合は、最小サーバ負荷や最小データ通信量による転送先が選ばれることがあります。
最近は、L7分散を用いた負荷分散の採用事例も増えています。
under construction...
■L4とL7ロードバランサについて
■Difference between L4 and L7 load balancer
ロードバランサは大まかにL4ロードバランサとL7ロードバランサと呼ばれる物があります。
L4ロードバランサは、OSI参照モデルの第3層(ネットワーク層)と第4層(トランスポート層)にて解析し処理を行います。
つまり「IPアドレス」、「ポート番号」を基に処理を行います。
それに対し、L7ロードバランサはL4ロードバランサの機能の他にOSI参照モデルの第7層(アプリケーション層)で処理を行うため、高度な分散ルールを定めることが出来ます。
具体的にはURLやHTTPの情報等を用いた負荷分散が出来るようになります。詳細は後述の「L7ロードバランサの機能」にて説明します。
最近では、クラウドサービスでも当たり前のようにL7ロードバランサを選択できるようになりました。
L7ロードバランサ相当になると、ヘルスチェックもサーバの死活やポートへの応答だけで無くサービス(アプリケーション)の状態を識別し転送先を決定することが出来ます。
例えば、Webサーバのプログラムが稼働していてもDBへの接続が出来ないというような状態(アプリケーション上での障害)も認識し転送先リストから除外するということが可能になります。
他にはL7ロードバランサにSSLアクセラレータの機能を持たせることが出来るため、SSL の暗号化/復号化処理機能をロードバランサに一任しサーバの負荷を軽減させることができます。
under construction...
■L7ロードバランサの機能
■L7 load balancer
L7ロードバランサの機能は主に下記の通りになります。
- URIスイッチ
サービスやコンテンツごとに異なるURIと転送ルールを定義することでリクエストを特定のサーバへ転送が可能な機能です。
URIと転送ルールを定義することでリクエストを特定のサーバへ転送する機能です。
つまり機能単位(サービス/コンテンツ)毎に処理を行うサーバを指定することが出来ます。
- SSLオフロード
複数のWebサーを運用する場合、各サーバにてSSL証明書の設置と管理を行う必要がありました。
この機能は、ロードバランサが代理でSSLによる通信の暗号化を行うことができ、運用コスト低減等有用です。
ロードバランサが集中管理することでWebサーバの処理負荷を大幅に低減することができます。
under construction...
■パーシステンス
■Load balancing with persistence
パーシステンスとは、特定のユーザからのリクエストを特定のサーバに転送し続ける機能のことを指します。
HTTPリクエストの様な比較的短い時間で接続を切ってしまうため、クライアントが常に同じサーバに接続されているとは限りません。
この機能は同一クライアントからのリクエストを常に同じサーバへ転送する必要があるWebシステムにて使用されます。
例として、サーバ上に格納されたキャッシュデータやセッションデータ等の一時的なデータなどサーバ毎に差異が発生している場合は同じサーバで処理し続けることが望ましいと言えます。
また、パーシステンスの方式は代表例を挙げると下記の通りになります。
- 送信元IPアドレス/送信先IPアドレス
送信元や送信先のIPアドレスを元にサーバの接続先を決定します。
一度接続が行われたクライアントとサーバの情報をロードバランサ側で保持し、二度目の接続時に情報を用いることでクライアントは同じサーバに接続させます。
- Cookieパーシステンス
HTTP/HTTPSで接続する環境にて、ロードバランサから発行されたCookieを基にサーバの接続先を決定する方式です。
- SSLセッションID
SSLプロトコルでは、接続に対してSSLセッションIDが付与されます。
このセッションIDを基にクライアントを識別し、転送先サーバを決定します。
- Contentベース
同じIPアドレスのアクセスに対して、ホスト名やURIを基に転送先サーバを決定します。
一つのIPアドレスやドメインに対して、複数の転送パターンを作成したい時に有意です。
under construction...
■ロードバランサのヘルスチェック
■Health check of load balancer
ロードバランサがサーバへリクエストを転送する際に、障害により停止しているサーバへリクエストを転送すると無駄が発生します。
そのためロードバランサはロードバランサ配下のサーバが応答可能か定期的にチェックを行います。
主なヘルスチェック機能は下記の通りになります。
- PING(L3)
ロードバランサ配下のWebサーバにICMP echoリクエストが正常に受信されているか検証を行います。
- TCP/UDP(L4)
ロードバランサ配下のサーバにTCPコネクションを確立します。
TCP/UDPが期待する応対かどうかも検証します。
- HTTP(L7)
ロードバランサ配下のWebサーバにHTTPリクエストを送信し、正常なレスポンスが返ってくるか確認を行います。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
最近ではL3、L4に限らずL7ヘルスチェックを使用する例が増えたり、実装を容易にするライブラリも公開されております。
これらの機能を正しく利用することでサービス稼働率が向上し、ユーザの満足度も向上すると思います。
under construction...
under construction...
アベイラビリティとは、コンピュータやシステムの壊れにくさ等、サービスを継続して提供できる能力です。
ロードバランサは、故障が発生してもサービスを継続して提供することやサービスを止めずに保守や修理が出来ることが求められています。
サービスを継続して提供するためにロードバランサは配下のサーバの状態や送信されたリクエストを管理し、状況に応じて処理を決定します。
例えば障害が発生した場合、障害が発生したサーバへの処理を別のサーバへ引き継いだり、障害があったサーバに処理が割り当てられないようにします。
また、保守や修理などでは、サービスを継続したまま交換対象のサーバへの処理割り当てを止め、新たなサーバと交換することが出来ます。
under construction...
■ロードバランサの負荷分散の種類
■Types of load balancing for load balancers
ロードバランサが受信したパケット転送先を決定する方法にはいくつか種類があります。
負荷分散方式は代表例は下記の通りになります。
- ラウンドロビン(均等負荷分散)
リクエストを各サーバへ均等に転送します。
この方式では各サーバで処理するリクエストの数が均等になるため、ロードバランサ配下のサーバの処理性能は同じである必要があります。
また、リクエストごとに処理負荷が違う場合は、サーバの負荷に偏りが発生することがあります。
- 重み付けラウンドロビン(重み付け均等負荷分散)
サーバに優先順位をつけ転送します。
この方式では、ロードバランサ配下のサーバの処理能力に応じてリクエストの分散比率を指定することが出来ます。
ロードバランサ配下の各サーバの処理能力に違いがある場合等で使用されます。
- リーストコネクション(最小接続数)
この方式では、各サーバが通信するクライアントの数が均等になるようにリクエストを転送します。
ロードバランサはリクエストの送信元IPアドレスやセッション数に基づいて各サーバの接続中のクライアント数をカウントし、接続数が最も低いサーバにリクエストを転送します。
- リーストトラフィック(最小データ通信量)
この方式では、ロードバランサ配下のサーバが転送するデータ量が均等になるようにリクエストを転送します。
ロードバランサが各サーバが転倒したデータ量を計測し、転送したデータ量が最も少ないサーバにリクエストを転送します。
コネクションあたりのデータ通信量が多い環境で有効な方法です。
- ファーストアンサー(最小応答時間)
この方式では、応答時間が最も短いサーバにリクエストを転送します。
ロードバランサは各サーバへリクエストを送信し、最も応答が早かったサーバに優先的にリクエストを転送します。
計測値に基づきリクエストを調整するため、サーバの処理性能に差がある環境で有効です。
- リーストプロセッシング(最小サーバ負荷)
この方式では、ロードバランサ配下のサーバの負荷状況(CPUやDISK IO等)を元にリクエストを転送します。
各サーバのハードウェアの負荷に基づくため、各サーバの運用や処理性能に違いがある環境でも有効です。
- L7分散
この方式では、HTTPリクエストのヘッダ情報やURL等を基にリクエストを転送します。
他の方式は、OSI参照モデルの第4層(トランスポート層)で処理されているのに対し、この方式は第7層(アプリケーション層)で処理されています。
第7層で処理を行うことで、より高度な転送ルールを設定することが出来ます。
処理自体は第7層としての処理ではありますが、この機能自体はL4スイッチに実装されていることもあります。
一般的にWebサーバの場合はラウンドロビン等が使用されますが、Webアプリケーションの処理特性によっては他の方法を使用する場合があります。
例えば、Disk IOや通信量などが大きい場合は、最小サーバ負荷や最小データ通信量による転送先が選ばれることがあります。
最近は、L7分散を用いた負荷分散の採用事例も増えています。
under construction...
■L4とL7ロードバランサについて
■Difference between L4 and L7 load balancer
ロードバランサは大まかにL4ロードバランサとL7ロードバランサと呼ばれる物があります。
L4ロードバランサは、OSI参照モデルの第3層(ネットワーク層)と第4層(トランスポート層)にて解析し処理を行います。
つまり「IPアドレス」、「ポート番号」を基に処理を行います。
それに対し、L7ロードバランサはL4ロードバランサの機能の他にOSI参照モデルの第7層(アプリケーション層)で処理を行うため、高度な分散ルールを定めることが出来ます。
具体的にはURLやHTTPの情報等を用いた負荷分散が出来るようになります。詳細は後述の「L7ロードバランサの機能」にて説明します。
最近では、クラウドサービスでも当たり前のようにL7ロードバランサを選択できるようになりました。
L7ロードバランサ相当になると、ヘルスチェックもサーバの死活やポートへの応答だけで無くサービス(アプリケーション)の状態を識別し転送先を決定することが出来ます。
例えば、Webサーバのプログラムが稼働していてもDBへの接続が出来ないというような状態(アプリケーション上での障害)も認識し転送先リストから除外するということが可能になります。
他にはL7ロードバランサにSSLアクセラレータの機能を持たせることが出来るため、SSL の暗号化/復号化処理機能をロードバランサに一任しサーバの負荷を軽減させることができます。
under construction...
■L7ロードバランサの機能
■L7 load balancer
L7ロードバランサの機能は主に下記の通りになります。
- URIスイッチ
サービスやコンテンツごとに異なるURIと転送ルールを定義することでリクエストを特定のサーバへ転送が可能な機能です。
URIと転送ルールを定義することでリクエストを特定のサーバへ転送する機能です。
つまり機能単位(サービス/コンテンツ)毎に処理を行うサーバを指定することが出来ます。
- SSLオフロード
複数のWebサーを運用する場合、各サーバにてSSL証明書の設置と管理を行う必要がありました。
この機能は、ロードバランサが代理でSSLによる通信の暗号化を行うことができ、運用コスト低減等有用です。
ロードバランサが集中管理することでWebサーバの処理負荷を大幅に低減することができます。
under construction...
■パーシステンス
■Load balancing with persistence
パーシステンスとは、特定のユーザからのリクエストを特定のサーバに転送し続ける機能のことを指します。
HTTPリクエストの様な比較的短い時間で接続を切ってしまうため、クライアントが常に同じサーバに接続されているとは限りません。
この機能は同一クライアントからのリクエストを常に同じサーバへ転送する必要があるWebシステムにて使用されます。
例として、サーバ上に格納されたキャッシュデータやセッションデータ等の一時的なデータなどサーバ毎に差異が発生している場合は同じサーバで処理し続けることが望ましいと言えます。
また、パーシステンスの方式は代表例を挙げると下記の通りになります。
- 送信元IPアドレス/送信先IPアドレス
送信元や送信先のIPアドレスを元にサーバの接続先を決定します。
一度接続が行われたクライアントとサーバの情報をロードバランサ側で保持し、二度目の接続時に情報を用いることでクライアントは同じサーバに接続させます。
- Cookieパーシステンス
HTTP/HTTPSで接続する環境にて、ロードバランサから発行されたCookieを基にサーバの接続先を決定する方式です。
- SSLセッションID
SSLプロトコルでは、接続に対してSSLセッションIDが付与されます。
このセッションIDを基にクライアントを識別し、転送先サーバを決定します。
- Contentベース
同じIPアドレスのアクセスに対して、ホスト名やURIを基に転送先サーバを決定します。
一つのIPアドレスやドメインに対して、複数の転送パターンを作成したい時に有意です。
under construction...
■ロードバランサのヘルスチェック
■Health check of load balancer
ロードバランサがサーバへリクエストを転送する際に、障害により停止しているサーバへリクエストを転送すると無駄が発生します。
そのためロードバランサはロードバランサ配下のサーバが応答可能か定期的にチェックを行います。
主なヘルスチェック機能は下記の通りになります。
- PING(L3)
ロードバランサ配下のWebサーバにICMP echoリクエストが正常に受信されているか検証を行います。
- TCP/UDP(L4)
ロードバランサ配下のサーバにTCPコネクションを確立します。
TCP/UDPが期待する応対かどうかも検証します。
- HTTP(L7)
ロードバランサ配下のWebサーバにHTTPリクエストを送信し、正常なレスポンスが返ってくるか確認を行います。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
最近ではL3、L4に限らずL7ヘルスチェックを使用する例が増えたり、実装を容易にするライブラリも公開されております。
これらの機能を正しく利用することでサービス稼働率が向上し、ユーザの満足度も向上すると思います。
under construction...
under construction...
ロードバランサは大まかにL4ロードバランサとL7ロードバランサと呼ばれる物があります。
L4ロードバランサは、OSI参照モデルの第3層(ネットワーク層)と第4層(トランスポート層)にて解析し処理を行います。
つまり「IPアドレス」、「ポート番号」を基に処理を行います。
それに対し、L7ロードバランサはL4ロードバランサの機能の他にOSI参照モデルの第7層(アプリケーション層)で処理を行うため、高度な分散ルールを定めることが出来ます。
具体的にはURLやHTTPの情報等を用いた負荷分散が出来るようになります。詳細は後述の「L7ロードバランサの機能」にて説明します。
最近では、クラウドサービスでも当たり前のようにL7ロードバランサを選択できるようになりました。
L7ロードバランサ相当になると、ヘルスチェックもサーバの死活やポートへの応答だけで無くサービス(アプリケーション)の状態を識別し転送先を決定することが出来ます。
例えば、Webサーバのプログラムが稼働していてもDBへの接続が出来ないというような状態(アプリケーション上での障害)も認識し転送先リストから除外するということが可能になります。
他にはL7ロードバランサにSSLアクセラレータの機能を持たせることが出来るため、SSL の暗号化/復号化処理機能をロードバランサに一任しサーバの負荷を軽減させることができます。
under construction...
■L7ロードバランサの機能
■L7 load balancer
L7ロードバランサの機能は主に下記の通りになります。
- URIスイッチ
サービスやコンテンツごとに異なるURIと転送ルールを定義することでリクエストを特定のサーバへ転送が可能な機能です。
URIと転送ルールを定義することでリクエストを特定のサーバへ転送する機能です。
つまり機能単位(サービス/コンテンツ)毎に処理を行うサーバを指定することが出来ます。
- SSLオフロード
複数のWebサーを運用する場合、各サーバにてSSL証明書の設置と管理を行う必要がありました。
この機能は、ロードバランサが代理でSSLによる通信の暗号化を行うことができ、運用コスト低減等有用です。
ロードバランサが集中管理することでWebサーバの処理負荷を大幅に低減することができます。
under construction...
■パーシステンス
■Load balancing with persistence
パーシステンスとは、特定のユーザからのリクエストを特定のサーバに転送し続ける機能のことを指します。
HTTPリクエストの様な比較的短い時間で接続を切ってしまうため、クライアントが常に同じサーバに接続されているとは限りません。
この機能は同一クライアントからのリクエストを常に同じサーバへ転送する必要があるWebシステムにて使用されます。
例として、サーバ上に格納されたキャッシュデータやセッションデータ等の一時的なデータなどサーバ毎に差異が発生している場合は同じサーバで処理し続けることが望ましいと言えます。
また、パーシステンスの方式は代表例を挙げると下記の通りになります。
- 送信元IPアドレス/送信先IPアドレス
送信元や送信先のIPアドレスを元にサーバの接続先を決定します。
一度接続が行われたクライアントとサーバの情報をロードバランサ側で保持し、二度目の接続時に情報を用いることでクライアントは同じサーバに接続させます。
- Cookieパーシステンス
HTTP/HTTPSで接続する環境にて、ロードバランサから発行されたCookieを基にサーバの接続先を決定する方式です。
- SSLセッションID
SSLプロトコルでは、接続に対してSSLセッションIDが付与されます。
このセッションIDを基にクライアントを識別し、転送先サーバを決定します。
- Contentベース
同じIPアドレスのアクセスに対して、ホスト名やURIを基に転送先サーバを決定します。
一つのIPアドレスやドメインに対して、複数の転送パターンを作成したい時に有意です。
under construction...
■ロードバランサのヘルスチェック
■Health check of load balancer
ロードバランサがサーバへリクエストを転送する際に、障害により停止しているサーバへリクエストを転送すると無駄が発生します。
そのためロードバランサはロードバランサ配下のサーバが応答可能か定期的にチェックを行います。
主なヘルスチェック機能は下記の通りになります。
- PING(L3)
ロードバランサ配下のWebサーバにICMP echoリクエストが正常に受信されているか検証を行います。
- TCP/UDP(L4)
ロードバランサ配下のサーバにTCPコネクションを確立します。
TCP/UDPが期待する応対かどうかも検証します。
- HTTP(L7)
ロードバランサ配下のWebサーバにHTTPリクエストを送信し、正常なレスポンスが返ってくるか確認を行います。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
最近ではL3、L4に限らずL7ヘルスチェックを使用する例が増えたり、実装を容易にするライブラリも公開されております。
これらの機能を正しく利用することでサービス稼働率が向上し、ユーザの満足度も向上すると思います。
under construction...
URIと転送ルールを定義することでリクエストを特定のサーバへ転送する機能です。
つまり機能単位(サービス/コンテンツ)毎に処理を行うサーバを指定することが出来ます。
この機能は、ロードバランサが代理でSSLによる通信の暗号化を行うことができ、運用コスト低減等有用です。
ロードバランサが集中管理することでWebサーバの処理負荷を大幅に低減することができます。
under construction...
パーシステンスとは、特定のユーザからのリクエストを特定のサーバに転送し続ける機能のことを指します。
HTTPリクエストの様な比較的短い時間で接続を切ってしまうため、クライアントが常に同じサーバに接続されているとは限りません。
この機能は同一クライアントからのリクエストを常に同じサーバへ転送する必要があるWebシステムにて使用されます。
例として、サーバ上に格納されたキャッシュデータやセッションデータ等の一時的なデータなどサーバ毎に差異が発生している場合は同じサーバで処理し続けることが望ましいと言えます。
また、パーシステンスの方式は代表例を挙げると下記の通りになります。
- 送信元IPアドレス/送信先IPアドレス 送信元や送信先のIPアドレスを元にサーバの接続先を決定します。
- Cookieパーシステンス HTTP/HTTPSで接続する環境にて、ロードバランサから発行されたCookieを基にサーバの接続先を決定する方式です。
- SSLセッションID SSLプロトコルでは、接続に対してSSLセッションIDが付与されます。
- Contentベース 同じIPアドレスのアクセスに対して、ホスト名やURIを基に転送先サーバを決定します。
一度接続が行われたクライアントとサーバの情報をロードバランサ側で保持し、二度目の接続時に情報を用いることでクライアントは同じサーバに接続させます。
このセッションIDを基にクライアントを識別し、転送先サーバを決定します。
一つのIPアドレスやドメインに対して、複数の転送パターンを作成したい時に有意です。
under construction...
■ロードバランサのヘルスチェック
■Health check of load balancer
ロードバランサがサーバへリクエストを転送する際に、障害により停止しているサーバへリクエストを転送すると無駄が発生します。
そのためロードバランサはロードバランサ配下のサーバが応答可能か定期的にチェックを行います。
主なヘルスチェック機能は下記の通りになります。
- PING(L3)
ロードバランサ配下のWebサーバにICMP echoリクエストが正常に受信されているか検証を行います。
- TCP/UDP(L4)
ロードバランサ配下のサーバにTCPコネクションを確立します。
TCP/UDPが期待する応対かどうかも検証します。
- HTTP(L7)
ロードバランサ配下のWebサーバにHTTPリクエストを送信し、正常なレスポンスが返ってくるか確認を行います。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
最近ではL3、L4に限らずL7ヘルスチェックを使用する例が増えたり、実装を容易にするライブラリも公開されております。
これらの機能を正しく利用することでサービス稼働率が向上し、ユーザの満足度も向上すると思います。
under construction...
TCP/UDPが期待する応対かどうかも検証します。
L7ヘルスチェック機能に関しては、サービス運営側で定義し実装することが出来ます。
under construction...