序章

DigitalOceanロードバランサーを使用すると、着信トラフィックを複数のバックエンドサーバー間で分割できます。 多くの場合、これは、全体的な容量を増やすために、アプリケーションサーバーのグループ間でHTTP要求を分散するために使用されます。 これは、アプリケーションをスケーリングするための一般的な方法です。

ロードバランサーは、他のユースケースも提供します。 たとえば、サイトの信頼性を高めたり、展開とテストのプロセスを改善したりできます。 このチュートリアルでは、5つのロードバランサーのユースケースを確認します。

始める前に、チュートリアル DigitalOceanロードバランサーの概要を読んで、DigitalOceanのロードバランサーの基本を理解しておく必要があります。

1. スケールの負荷分散

上記のように、トラフィックのスケーリングはロードバランサーの最も一般的なユースケースです。 多くの場合、スケーリングは垂直および水平の用語で説明されています。 垂直スケーリングとは、基本的に、アプリケーションをより強力なサーバーに移動して、増大するパフォーマンス要求に対応することです。 水平スケーリングとは、トラフィックを複数のサーバーに分散して負荷を共有することです。 ロードバランサーは、水平方向のスケーリングを容易にします。

Load Balancer scaling diagram

DigitalOceanロードバランサーを使用すると、ラウンドロビンと最小接続の2つの異なるアルゴリズムを介して負荷を分散できます。 ラウンドロビンは、使用可能な各バックエンドサーバーに順番に要求を送信しますが、接続が最も少ないサーバーには、接続が最も少ないサーバーに要求が送信されます。 ラウンドロビンは、負荷分散に最も頻繁に使用されるスキームですが、接続を長時間開いたままにするアプリケーションがある場合は、接続を少なくすることで、1台のサーバーが過負荷になるのを防ぐことができます。

ロードバランサーを使用した水平スケーリングの副次的な利点は、サービスの信頼性を向上させるチャンスです。 次にそれについて話します。

関連チュートリアル:

2. 高可用性

高可用性とは、ダウンタイムを減らし、システムの信頼性を高めるための取り組みを表す用語です。 これは多くの場合、パフォーマンスを改善し、単一障害点を排除することで対処されます。

ロードバランサーは、バックエンドサーバーでヘルスチェックを繰り返し実行し、障害が発生したサーバーをプールから自動的に削除することで、可用性を向上させることができます。

Load Balancer high availability diagram

ヘルスチェックは、ロードバランサーコントロールパネルの設定領域でカスタマイズできます。

Load Balancer health checks interface

デフォルトでは、ロードバランサーはサーバーが正しく応答していることを確認するために10秒ごとにWebページをフェッチします。 これが3回続けて失敗した場合、問題が解決するまでサーバーは削除されます。

関連チュートリアル:

3. ブルー/グリーン展開

青/緑の展開とは、新しいソフトウェアを本番インフラストラクチャに展開し、徹底的にテストしてから、すべてが期待どおりに機能していることを確認した後でのみ、トラフィックをそのソフトウェアに切り替える手法を指します。 デプロイが新しい予期しない方法で失敗した場合は、ロードバランサーを古いバージョンに戻すことで簡単に回復できます。

Load Balancer blue/green deployment diagram

DigitalOceanロードバランサーは、ドロップレットタグ付け機能を使用することで、青/緑の展開を簡単にします。 ロードバランサーは、タグに基づいてサーバーのグループにトラフィックを送信できるため、1セットのドロップレットにと他ののタグを付けることができます。 切り詰めるときは、ロードバランサーのコントロールパネルまたはAPIを使用してタグを切り替えます。

Load Balancer add Droplets via tag interface

変更を保存すると、トラフィックはすぐに新しいドロップレットのセットに切り替わります。

関連チュートリアル:

4. カナリアの展開

Canaryデプロイメントは、アプリケーションサーバーのプール全体を更新する前に、ユーザーのサブセットでアプリケーションの新しいバージョンをテストする方法です。 DigitalOceanロードバランサーを使用すると、たとえば、ロードバランサーのプールにカナリアサーバーを1つだけ追加することでこれを行うことができます。 ロギングおよびモニタリングインフラストラクチャを通じてエラーの増加やその他の望ましくない結果が見られない場合は、プールの残りの部分への更新の展開に進むことができます。

このユースケースでは、スティッキーセッションをオンにして、ロードバランサーを介して新しい接続を確立するときにユーザーがアプリケーションの異なるバージョン間でバウンスされないようにする必要があります。

Load Balancer sticky sessions interface

スティッキーセッションはCookieを使用して、特定のブラウザからの今後の接続が引き続き同じサーバーにルーティングされるようにします。 この機能には、ロードバランサーのコントロールパネルの詳細設定領域からアクセスできます。

5. A/B展開

A / B展開はカナリア展開と機能的に似ていますが、目的は異なります。 A / B展開では、マーケティングと開発の取り組みに役立つ情報を収集するために、一部のユーザーで新機能をテストします。 意味のある結果を返すには、既存の監視およびロギングインフラストラクチャと組み合わせてこれを行う必要があります。

サーバー側では、1つ以上のBサーバーをAサーバーの既存のプールに追加します。 十分なデータを収集するために複数のBサーバーを起動する必要がある場合は、青/緑の展開の場合と同様に、タグを使用してこれを整理できます。

結論

ロードバランサーは、スケールが必要な場合に最もよく考慮されますが、さまざまなバックエンドサーバー間でトラフィックを分散またはシャッフルする機能があると便利な場合が他にもたくさんあることを示しました。 高可用性のためであろうと、さまざまな展開手法を活用するためであろうと、ロードバランサーは本番インフラストラクチャの柔軟で強力なツールです。

DigitalOceanロードバランサーのより詳細で専門的な情報については、次のチュートリアルをご覧ください。