- Looker から Snowflake への OAuth 接続
- Looker (Google Cloud core) 30日間 フリートライアル設定
- AWS 落穂拾い (Security)
- AWS 落穂拾い (Storage)
- マイクロマウス
概要
負荷分散および耐障害性の向上などに利用される AWS ELB (Elastic Load Balancing) の設定例を記載します。リージョンは Tokyo です。
VPC 外部からのアクセスを振り分ける ELB
VPC 関連の設定
こちらを参考に以下のように設定します。EIP の設定は今回は不要です。ELB 経由でアクセスするためです。
VPC
- Name tag: myvpc
- CIDR block: 192.168.0.0/16
- Tenancy: Default
インターネットゲートウェイ
- Name tag: mygateway
サブネット二つ
- Name tag: mysubnet-000[1-2]
- VPC: myvpc
- AZ: ap-northeast-1[bc]
- CIDR block: 192.168.[1-2].0/24
ルーティング設定
- Destination: 0.0.0.0/0
- Target: igw-(mygatewayのid)
EC2 インスタンスの起動
- myinstance-0001 (private ip: 192.168.1.4, public ip: なし)
- myinstance-0002 (private ip: 192.168.2.4, public ip: なし)
ELB の作成を開始
myinstance-000[1-2] に対するアクセスを振り分ける ELB を用意します。EC2メニューの Load Balancers にある Create Load Balancer から作成します。以下のように設定します。
- Load Balancer name: myelb
- Create LB Inside: myvpc
- Create an internal load balancer: いいえ
- Listener Configuration: TCP 2222 => TCP 22
- Select Subnets: mysubnet-000[1-2]
今回の例では、VPC 外から ELB の TCP 2222 番へのアクセスを EC2 インスタンス TCP 22 番に割り振るように設定しています。
セキュリティグループの設定
外部から TCP 2222 へのアクセスが可能なものを選択します。必要であれば既存のものを編集または新規作成します。
ヘルスチェックの設定
EC2 インスタンス TCP 22 への Ping が実行される設定にします。自動入力された内容のままで問題ありません。
EC2 インスタンスの登録およびタグ付け => 完了
myinstance-000[1-2] を登録します。更に以下のようにタグ付けして完了です。
- Key: Name
- Value: ssh_servers
動作検証
ELB に割り当てられた DNS Name に対して VPC 外部から SSH 接続します。
$ ssh ec2-user@myelb-2137309337.ap-northeast-1.elb.amazonaws.com -i mykeypair.pem -p 2222 \
-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
数回繰り返すと 192.168.1.4 および 192.168.2.4 の両ホストにバランシングされていることが確認できます。ヘルスチェックが通らないと ELB はインスタンスを OutOfService と判断してパケットの転送を行わないことに注意します。今回の場合 22 番ポートで待ち受けている sshd を停止するとヘルスチェックに通らなくなり ELB はインスタンスを InService でないと判断して切り離します。
補足
ELB に視認性のよいドメインを与えるためには myelb-2137309337.ap-northeast-1.elb.amazonaws.com に対する CNAME を Route53 などの DNS に登録します。
VPC 内部のトラフィックを振り分ける ELB
「VPC 外部からのアクセスを振り分ける ELB」の手順で以下の項目にチェックを入れると内部 ELB が作成できます。
Create an internal load balancer: いいえ
注意
- VPC 外部からは内部 ELB にアクセスできない
- 内部 ELB は外部 ELB と同様にどのサブネットにも属さない
用途
- 冗長化できておらず同じ機能の仕組みが別に存在しない片系の運用を回避したい場合
- SES にリレーする SMTP サーバを二台用意して、内部 ELB で内部ホストから 25 番ポートへのリクエストを分散することで一方をメンテに入れやすくする。耐障害性も上がる
SSL 通信に対応した ELB
Listener Configuration の Load Balancer Protocol で HTTPS または SSL を選択すると証明書および秘密鍵のアップロードを求められます。ELB が SSL 通信に対応して証明書の配布や通信の暗号化/復号化を行える必要があるためです。バックエンドサーバに対して復号化した内容を HTTP で転送する場合は ELB が SSL アクセラレータとして機能することになります。バックエンドサーバは暗号化および復号化の処理を行う必要がなくなり負荷が軽減します。そうではなく、バックエンドサーバに対して HTTPS で転送することもできます。この場合、暗号化は ELB にアップロードされた秘密鍵で行うのではなくバックエンドサーバの証明書から取り出した公開鍵で行います。クライアントから ELB への通信を一旦復号化して、更にバックエンドサーバの証明書で暗号化するため低速になります。また、ELB で一旦復号化するためクライアントが ELB との通信で使用している証明書に対応した秘密鍵をバックエンドサーバにインストールする必要がない点にも注意します。バックエンドサーバー認証を行わない場合はバックエンドサーバはいわゆるオレオレ証明書でもよいということになります。
運用上の注意
ELB に接続されたインスタンスを再起動すると、自動的には ELB に再接続されません。明示的に再度接続する必要があります。
