アプリエンジニアのためのAWS入門 ALB編
前回までのあらすじ
今回の教材
概要
前回まででウェブアプリをホストするためのEC2インスタンスと、それを管理するためのVPCを作成した。ただしゲートウェイは自分のIPアドレスからのSSHに対してしか開放していないため、現時点ではHTTPでEC2インスタンスに接続することはできない。
今回はALB(Application Load Balancer)を作成しVPCに紐付けることで、EC2インスタンスへのHTTP接続を可能にする。なおALBは2016年に新しく追加されたサービスで、それ以前はELB(Elastic Load Balancer)が同様のサービスを提供していたが、ALBの登場によってCLB(Classic Load Balancer)と名称が変更された。
ALBとELB(CLB)の違いについては以下の記事が詳しい。 dev.classmethod.jp
ALBを作成する
これからロードバランサーを作成していくが、教材にしているQiitaの元記事が執筆された時点ではALBは存在していなかったため、以降の手順は元記事と異なる部分があるので注意してほしい。
まずはServicesタブからEC2を選択しEC2ダッシュボードを表示する。サイドメニューのLoad BalancingからLoad Balancersを選択すると以下の画面が表示されるので、Create Load Balancerボタンをクリックする。
ロードバランサーの種類の選択画面が表示されるので、左側のALB(Application Load Balancer)を選択する。ALBとCLB違いについては概要で触れた参考ページを参照してほしいが、ここで覚えておきたいのはALBは複数のサブネットをTarget groupという単位でひとかたまりごとに管理するのに対し、CLBではEC2インスタンスをロードバランサーに直接紐付ける形で管理するという点である。
基本設定
ロードバランサーのタイプを選んだら以下の通り基本設定を行っていく。
項目 | 設定値 |
---|---|
Name | test-web |
Scheme | internet-facing |
IP address type | ipv4 |
Nameは前回までに作成してきたVPCなどと合わせるためtest-webとした。Schemeをinternet-facingとすることでインターネットからの接続が許可できる。internalにするとプライベートネットワーク専用のロードバランサーとして設定できるようである。IP address typeはデフォルトのままipv4にしておく。
ListenersにHTTPを指定することでHTTPリクエストをロードバランサーで処理できる。必要であればHTTPSをここに追加することでHTTPSページも運用する事ができる。
画面をスクロールするとAvailability Zonesの設定が表示される。VPCでこのロードバランサーを紐付けるVPCを設定し、サブネットのリストから実際にトラフィックを振り分けるサブネットを選択する。ALBでは最低でも2つ以上のサブネットを選択する必要があるので、アプリエンジニアのためのAWS入門 VPC編 - 2:00am, Writing codeで作成した2つのサブネットを選択する。
セキュリティ設定
基本設定でHTTPしか設定しないと「ロードバランサへのトラフィックをセキュアにする必要がある場合はHTTPSを設定しろ」と警告が表示される。今回は不要なので無視して先に進める。
セキュリティグループ設定
次にロードバランサーに対してのセキュリティグループを設定する。前回はEC2インスタンスに対してセキュリティグループを作成したが、その時はSSHは自IPでのみ許可、HTTPとHTTPSはVPCからのアクセスのみ許可とした。
今回はロードバランサーに対して「全てのHTTPアクセスを許可」とすることで、ALB経由でEC2インスタンスへトラフィックが流されるようにする。ラジオボタンでCreate a new security groupを選択し、以下のように設定する。Nameはなんでもいいがひと目で分かるものにする。ここではtest-web-albとした。
type | Protocol | Port range | Source |
---|---|---|---|
HTTP | TCP | 80 | 0.0.0.0/0, ::0/0 |
ターゲットグループ&ヘルスチェック設定
次にターゲットグループとヘルスチェックの設定を行う。ターゲットグループはALBで導入された概念で、トラフィックを流す先をグループごとにひとまとまりにして管理する機能である。新規作成時はName以外に設定を変更する必要はない。Nameはtest-target-groupとしておく。
ヘルスチェックはトラフィック振り分け先インスタンスの死活管理をする機能である。Protocolで指定された方法でPathにアクセスし、異常なレスポンスが返ってきた場合にロードバランサーの振り分け先からそのインスタンスを切り離すことで、正常なインスタンスのみにトラフィックを処理させることができる。
Advanced health check settingsではヘルスチェックの詳細を設定できる。今回は全てデフォルトのままにしておく。各項目の意味は以下の通り。
項目 | 意味 |
---|---|
Port | 各インスタンスがヘルスチェックを受け付けるポート。traffic portなら通常のリクエストを処理するポートで受け付ける。overrideで特定のポートを指定できる |
Healthy threshold | 正常と判定するためのチェック成功回数。5なら5回連続でヘルスチェックが成功した時にインスタンスが正常とみなす |
Unhealthy threshold | 異常と判定するためのチェック失敗回数。2なら2回連続でヘルスチェックが失敗したらインスタンスが異常とみなす |
Timeout | タイムアウト時間(秒) |
Interval | ヘルスチェックの実行間隔(秒) |
Success codes | ヘルスチェック成功時のレスポンスコード |
ターゲットグループへEC2インスタンスを登録
先程作成したターゲットグループにEC2インスタンスを登録する。最初は何も登録されていない状態なので、画面下部のリストから登録したいEC2インスタンスを選択しAdd to registeredボタンをクリックする。無事に登録されると画面上部のリストに先程選択したEC2インスタンスが表示される。
確認
ここまでの設定が終わると下記の確認画面が表示される。各設定を確認し問題なければCreateボタンをクリックする。
ALBが作成されたらLoad Balancersメニューを選択する。ロードバランサー一覧に作成したロードバランサーが表示されていれば無事に作業完了である。
動作確認
Load Balancersで追加したロードバランサーを選択すると、そのロードバランサーの詳細情報が表示される。詳細情報のDNS nameにブラウザでアクセスして、前回同様以下のようにnginxのデフォルト画面が表示されれば無事に設定完了である。
ついでに前回のようにEC2インスタンスのIPアドレスに直接アクセスしてもアクセスできなくなっていれば、EC2インスタンスのセキュリティグループによるアクセス制限が効いていることが確認できる。