OSS Software Load Balancer(2) NGINX, Traefik, MetalLB

NGINX

概要:

NGINXは、高性能でスケーラブルなオープンソースのウェブサーバー、リバースプロキシ、ロードバランサー、及びHTTPキャッシュです。2004年に公開され、現在では、多くの高トラフィックなウェブサイトやアプリケーションで広く利用されています。

GitHub: https://github.com/nginx/nginx

主な特徴

高性能: 非同期イベント駆動モデルを採用しており、大量の同時接続を効率的に処理できます。これは、トラフィックが集中するウェブサイトやアプリケーションにおいて特に有効です。
リバースプロキシ: HTTP/HTTPS、TCP、UDP のプロトコルに対応し、リクエストを適切なバックエンドサーバーにルーティングすることができます。また、SSL/TLSターミネーションもサポートしており、セキュアな通信を実現します。
ロードバランシング: ラウンドロビン、最小接続数、IPハッシュなど、複数のロードバランシングアルゴリズムを提供します。ヘルスチェック機能により、バックエンドサーバーの状態を監視し、障害時に自動的にトラフィックを健全なサーバーにルーティングします。
リクエストのキャッシング: HTTPキャッシュ機能を持ち、バックエンドサーバーへの負荷を軽減します。キャッシュポリシーを細かく設定できるため、キャッシュの有効期間や条件を柔軟に管理できます。
モジュール性: 多数のモジュールが存在し、必要な機能を追加することでNGINXを拡張できます。例えば、LuaやPerlを使用したスクリプティング機能や、第三者によるモジュールの利用が可能です。

Traefik

概要

Traefik(トラフィック) は、クラウドネイティブなアプリケーションのために設計されたオープンソースのリバースプロキシおよびロードバランサーです。
動的なリバースプロキシとして機能し、さまざまなサービスディスカバリプロバイダ（Kubernetes、Docker、Consul、Etcd など）と連携して、リアルタイムでバックエンドサービスを検出し、ルーティングを自動的に更新します。これにより、手動での設定変更が不要になり、環境の変化に迅速に対応できます。
Let's Encrypt を使って HTTPS化が可能であり、SSL証明書は自動更新可能です。
GitHub: https://github.com/traefik/traefik

主な特徴

動的構成(設定): 動的にバックエンドサービスを検出して自動的にルーティング設定を更新します (前述の通り)
マルチプロトコルサポート: HTTP/HTTPS、TCP、UDP、HTTP/3 プロトコルをサポートし、多様なアプリケーションに対応します。
ロードバランシング: 複数のバックエンドサービスにトラフィックを分散させるロードバランシング機能を提供します。ラウンドロビン、重み付けラウンドロビンなどのアルゴリズムがサポートされています。
- Round Robin, Weighted Round Robin (HAProxyの項参照)
- Response Time: バックエンドサービスのレスポンスタイムを監視し、最もレスポンスの早いサービスにリクエストを送ります。
- セッション持続性 (Sticky Sessions): 同じクライアントのリクエストを常に同じバックエンドサービスに送ることで、セッションデータの一貫性を保つ機能です。

動的構成(設定):

Traefikがサービスディスカバリプロバイダ（Kubernetes、Docker、Consul、Etcdなど）と連携して、実行中のサービスやエンドポイントを自動的に検出し、それに基づいてルーティング設定を更新する仕組みです。この機能により、新しいサービスが追加されたり、既存のサービスが変更されたりすると、Traefikが自動的に対応します。

主要コンポーネント:

Providers: 複数のプロバイダと連携して動的構成を実現します。プロバイダは、Traefikがバックエンドサービスの情報を取得するソースとなります。
- Kubernetes: Ingressリソースを利用する
- Docker: コンテナのラベルや設定を利用する
- Etcd: KVSを使用してサービス情報を取得
Entrypoints: Traefikがトラフィックを受け入れるためのポートやプロトコルを定義します。
Routers: ルーターは、トラフィックを特定のバックエンドサービスにルーティングするためのルールを定義します。動的に生成されたルーターは、プロバイダから取得した情報に基づいています。
Services: 実際のバックエンドサービスを定義し、ロードバランシングの設定などを行います。動的に生成されたサービスは、プロバイダから取得した情報に基づいています。
Middlewares: トラフィックの処理や制御を行う機能を提供します。例として、認証、リトライ、レートリミットなどがあります。

MetalLB

概要

MetalLBは、Kubernetesクラスタ内でのロードバランシングを提供するためのオープンソースのロードバランサーです。
特に、オンプレミスのデータセンターやベアメタル環境での利用を念頭に置いて設計されています。
クラウドプロバイダーのロードバランサーとは異なり、MetalLBは物理ネットワーク上で動作し、クラスタ外部からのトラフィックを効果的に管理します。

主な特徴

BGPとARPモードのサポート

BGP (Border Gateway Protocol) モード: MetalLB は外部ルータにルートをアドバタイズし、サービスをクラスタの外部に知らせることができます。これにより、内部ネットワークと外部ネットワーク間の効率的なルーティングが可能になります。
ARP (Address Resolution Protocol) モード: MetalLB は ARP を使用して、ローカルネットワーク上でクラスター IP アドレスをアドバタイズします。この設定はよりシンプルで、要件が単純な小規模な環境やネットワークに適しています。

外部依存性の少なさ

MetalLBは外部のデバイスや追加ソフトウェアに依存せずに、Kubernetesクラスター内で完全に機能します。
外部ロードバランサーのコストや複雑性を避けることができます。

その他の特徴

高可用性:
- MetalLBは複数のインスタンスをデプロイすることで、高可用性を確保できます。
- 障害が発生した場合には、別のインスタンスが自動的にトラフィックを引き継ぎます。
スケーラビリティ:
- Kubernetesクラスタのサイズに応じて柔軟にスケールし、トラフィックの負荷を効率的に分散します。
監視とロギング:
- MetalLBはPrometheusと連携可能です。詳細なメトリクスを収集し、監視やアラート設定が可能です。
- ログを出力してトラブルシューティングに役立てることができます。

MetalLBは Controller と Speaker の2種類のモジュールで構成されており、 External IPの割り当てと、経路情報のアドバタイズは図のように実施されます。
外部からのアクセスがあった場合、設定された経路情報をもとに、ルータと ipvs が接続先を調整してくれます。

MetalLBを利用する時に気を付けるべきこと

ネットワーク設計の理解:

MetalLBを導入する前に、使用されるネットワークプロトコル(Layer 2 または BGP) とネットワークの設計について十分理解しておくことが重要です。Layer 2モードではネットワークのブロードキャストドメインが関連し、BGPモードではBGPピアリングとルーティングがキーポイントとなります。

Layer 2: OSI参照モデルの第２層における「データリンク層」のことを指しています。レイヤ２に位置するL2 スイッチは同じネットワーク内にある全ての機器・デバイスに接続しています。L2 スイッチによって、接続された機器・デバイスのMACアドレスが記憶され、ネットワーク内でのデータ通信が行わます。
BGP: 特定のIPネットワーク（プレフィックス）に到達するための最適な経路を選定し、それを隣接する自律システム（AS）に伝達することで、インターネット全体のルーティング情報を管理します。BGPを使用することで、ネットワークは冗長性、負荷分散、ルーティングポリシーの適用など、さまざまな戦略的な目的を達成できます。

IPアドレスの管理

MetalLBでは外部からアクセス可能なIPアドレスをサービスに割り当てます。使用するIPアドレス範囲を事前に計画し、IPアドレスが枯渇しないように管理することが必要です。

セキュリティ設定

特にBGPモードを使用する場合、不正なBGP更新からネットワークを保護するためのセキュリティ対策が必要です。適切な認証とフィルタリングを設定することで、セキュリティリスクを軽減できます。

ハードウェアとの互換性

MetalLBが正しく動作するためには、物理ネットワーク機器が適切に設定されている必要があります。特に、Layer 2モードではARPリクエストに対応できるように、ネットワーク機器の設定を確認する必要があります。

高可用性の設計

ロードバランサーはクラスタの入口点として非常に重要です。MetalLBの設定で高可用性を確保し、単一障害点を作らないようにするためには、複数ノードにわたる適切な冗長性の確保が求められます。

監視とロギング

MetalLBの動作を監視し、問題が発生した場合に迅速に対応できるようにするために、適切な監視ツールとログ収集の仕組みを設置することが重要です。Prometheusとの統合を利用して、メトリクスを収集し、問題の診断を行うことができます。

MetalLBの課題

限られたプロトコルサポート: MetalLBは主にLayer 2とBGPモードで動作しますが、これらのプロトコルは設定が複雑である場合があり、すべてのネットワーク環境での利用が適切とは限りません。特にBGPは、適切なネットワーク機器との連携や専門知識が必要です。
ネットワーク依存性: 特にLayer 2モードでは、同一のブロードキャストドメイン内にノードが存在する必要があります。これにより、物理的なネットワークの構成に依存することが増え、大規模または複雑なネットワーク環境では適用が難しい場合があります。
スケーラビリティの制限: Layer 2モードではIPアドレスのスケーラビリティが限られており、大規模なデプロイメントや多数のサービスが存在する環境ではIPアドレスの枯渇が問題になることがあります。
管理と運用の複雑さ: MetalLBの設定と管理にはKubernetesの理解に加えて、ネットワークプロトコルの知識が必要です。特にBGPの設定は複雑であり、適切な運用には専門的な知識と経験が求められます。