Vultrロードバランサー

• ロードバランサーとは
• ロードバランサーのデプロイ
• 導入後

ロードバランサーとは

ロードバランサーはアプリケーションの前に配置され、アプリケーションの複数のインスタンスに着信トラフィックを分散します。たとえば、eコマースのウェブサイトがあるとします。あなたはあなたが牽引力を得て、あなたのアプリケーションにますます多くの顧客を引き付けていることに気づきます。このトラフィックに対応するために、eコマースストアの別のインスタンスをデプロイできます。ここで、ユーザーをストアのこれらのインスタンスの間に誘導するために、それらの前にロードバランサーをデプロイします。

ロードバランサーは、アプリケーションの2つのインスタンス間でトラフィックを分散します。これにより、より多くのインスタンスをデプロイし、それらをロードバランサーの背後に配置することで、アプリケーションをスケーリングして、処理できるトラフィック量を増やすことができます。これは、稼働時間の改善にも役立ちます。ロードバランサを使用すると、複数のインスタンスがあり、そのうちの1つが失敗またはオフラインになった場合、ロードバランサはトラフィックを正常な実行中のノードに転送します。

ロードバランサーのデプロイ

概観

これは完全に管理されたサービスです。ロードバランサーのインフラストラクチャを稼働させ続けることを心配する必要はありません。これにより、アプリケーションの構築と、必要に応じてそれらを拡張することに集中できます。ただし、アプリケーションがロードバランサーと連携するように正しく構成および設定されていることを確認する必要があることに注意してください。

転送ルール

ここでは、プロトコルを使用して、どのパブリックポ��トをどの内部ポートにマップするかを定義します。例：ロードバランサーを前面に配置するRuby on Railsアプリケーションがあり、アプリケーションがポートでリッスンしている1234が、ユーザーがポートを介してアプリケーションにアクセスできるよう80にするには、マッピングを次のように定義します。Load Balancer http 80 -> Instance HTTP 1234

プロトコルとしてHTTPSを選択した場合は、独自のSSL証明書をアップロードするように求められます。今後のリリースでは、Let's Encryptのサポートが追加される予定です。

ロードバランサーの構成

アルゴリズム

アルゴリズムには2つの使用可能なオプションがあります。

• Roundrobin-サーバーを順番に選択します。これがデフォルトのアルゴリズムです。

• Leastconn-接続数が最も少ないサーバーを選択します。これは、より長いセッションに推奨されます。同じバックエンド内のサーバーもラウンドロビン方式でローテーションされます。

スティッキーセッション

スティッキーセッションには、アプリケーション制御のセッション永続性を使用しています。

アプリケーションは、セッションスティッキの持続時間を決定するCookieを生成します。ロードバランサーは、その上に独自のセッションCookieを発行しますが、アプリケーションCookieの有効期間に従います。

これにより、スティッキーセッションがより効率的になり、ローカルセッションCookieの有効期限が切れた後にユーザーがサーバーにルーティングされることがなくなります。ただし、ロードバランサーとアプリケーションの間に追加の統合が必要になるため、実装はより複雑になります。

クッキー名を追加するように求められます。

ラベル

これはロードバランサーのラベルにすぎません。

HTTPをHTTPSに強制

これにより、HTTPがHTTPSにリダイレクトされます。これが正しく機能するには、有効なSSL証明書とHTTPSが構成されている必要があります。

健康診断

これらのヘルスチェックでは、接続されているアプリケーション/インスタンスが正常であり、適切にルーティングできることを確認します。インスタンスの1つがヘルスチェックに失敗すると、ロードバランサーはそのインスタンスへのトラフィックをカットします。

導入後

デプロイが完了すると（数分かかる場合があります）、ロードバランサーのパブリックIPであるIPV4アドレスとIPV6アドレスが与えられます。

これで、アプリケーション/インスタンスをロードバランサにアタッチ/デタッチでき、必要な設定変更も可能になります。

指標

ロードバランサーが数分間実行されると、メトリックが収集されます。ロードバランサーダッシュボードの[メトリック]タブからメトリックを表示できます。