ロードバランサーとは
個人開発でECSを使おうと思ってますが、周辺のリソースも含めて、理解が薄かったりした概念について再度復習します。
この記事ではロードバランサーがらみについてちょっとまとめ。
ざっくりとした簡単な概念から
主にWebサーバーの処理を分散させる仕組みで、リクエストの処理を複数のサーバーに振り分けることを指します。
通常の構成：リクエスト → Webサーバー
ロードバランサー導入後：リクエスト → ロードバランサー → Webサーバー（2台以上）
メリット・デメリット
メリット
負荷軽減
- 高負荷状態のシステムに対してサーバーを2台以上にすることで、1台あたりの負荷を軽減
可用性の向上
- 1台のサーバーがダウンしても、他のサーバーが生きていればシステムが継続稼働
- このような性質を可用性と呼ぶ
拡張性の向上
- サーバーを増やすことでシステムの規模拡張が容易
デメリット
コスト増加
- サーバー数分の費用とメンテナンス手数の増加
実装上の変更が必要
- セッション保存をサーバーではなくDBで管理
- 画像ファイルや動的生成ファイルを共通サーバーやS3などのクラウドサービスで管理
- Git反映時の同時反映スクリプトの実装
- 今はほとんどしませんが、サーバーにはいってデバックみたいな開発をしてたころとかは大変でした・・・
AWSのロードバランサー
ALB（Application Load Balancer）
HTTPやHTTPSなどのトラフィック負荷分散に特化したロードバランサー
ELB（Elastic Load Balancing）
AWSのロードバランサーの総称
本当はもっといろいろありますが・・・一旦は基本のロードバランサー=アプリケーションロードバランサーってことで。ELBはAWSのサービス名。
ELBの主要概念
リスナー
簡単にいうと窓口。80番のリクエストを受けるとかだと、とりあえずフロント部分に立つのがここになります。
- ELBのフロント部分に位置
- 外部からアクセスするプロトコルやポートの設定を行う
- 具体的なトラフィックの監視を担当
- 以下の情報を定義：
- ポート
- プロトコル（HTTP、TCPなど）
- 紐づくロードバランサー
- 転送先（ターゲットグループ）
リスナールール
窓口(リスナー)に来たリクエストをどのように振り分けるかのルール定義。
- リスナーのルール設定
- IPアドレスによって後述するアクションが決定される
アクション
リスナールールの種類。
- 固定レスポンスを返す
- リダイレクト
- 他の部分への転送（フォーワード）・・・なんらかのアプリ
- 認証処理
ターゲットグループ
後続の実際の処理(ターゲットの)窓口やヘルスチェックなど。
- フォーワード先として、ターゲットを取りまとめたもの
- リスナーから転送されたトラフィックの具体的な処理を担当
- ECSサービスの窓口となることが多い
- ヘルスチェックも定義（例：30秒ごとに特定のHTMLファイルを確認し、3回連続で200が返らないとエラー）
ターゲット
実際のリクエストが流れ着く先です。
- ターゲットグループに所属
- 具体的な処理を行うプロセス（EC2、Lambdaなど）
ECSとの連携
ECSの主要コンポーネント
クラスター
- ECSの最大グループ
- この中にサービスを入れて管理
サービス
- 実際のタスクの管理人的な位置づけ
- タスクのダウン時の復活などを管理
- 以下を定義：
- 紐づくロードバランサー（ターゲットグループ）← ロードバランサーはここに紐付けます。
- タスク実行数
- 実行コンテナの種類（EC2、Fargateなど）
タスク
- コンテナが実際に起動される部分
- JSON形式で以下を定義：
- コンテナイメージ
- ロール
- ポート
- ログ情報
実装例：Dockerを使用したロードバランサー
構成
.
├── balancer/
│ └── nginx.conf
├── docker/
│ ├── web1/
│ └── web2/
├── docker-compose.yml
├── web1/
│ └── index.html
└── web2/
└── index.html
Nginxによる負荷分散設定例
events {
worker_connections 16;
}
http {
upstream balancer.local {
server web1;
server web2;
}
server {
listen 80;
location / {
proxy_pass http://balancer.local;
}
}
}
参考リンク