AWS ALBのちょっとイイ話
- 2. 自己紹介
● 大越 雄太 (Yuta Okoshi)
● 最近の経歴:
2020年5月に留学資金集めのためにフリーランスとして転生
同時にハウテレビジョンにJOIN
● HowTVでの主なお仕事:
AWSのリソース整理など主にインフラ周り
● 趣味:
IoT × サバイバルゲームでいろいろ作ってます
チンチラと同居生活中
2
- 5. AWS ALBってなに?
● AWS Elastic Load Balancing(ELB)を2009年に発表
● その後、AWS Application Load Balancer(ALB)を2016年に発表
● 主な特徴
○ レイヤー7のLBとして動作する
○ HTTPとHTTPSのリクエストヘッダにアクセスし、
パスやドメイン、送信元IPなどを判別して負荷を分散できる
○ AWS WAFの利用によるセキュリティ強化
○ OpenID Connectによる認証機能がマネージドで利用できる
○ などなど。。。
細かいことはクラスメソッドさんの記事をドゾ
https://dev.classmethod.jp/articles/describe-elb-types/
5
- 6. ● 現状、AWSでは3種類のLoad Balancerが発表されています
○ Network Load Balancer(NLB)
○ Application Load Balancer(ALB)
○ Classic Load Balancer(CLB)
● Webアプリケーションは特別な理由がない限りApplication Load Balancerで必要十分です
● Classic Load Balancerは今後、利用しないようにしましょう
細かいことはクラスメソッドさんの記事をドゾ
https://dev.classmethod.jp/articles/describe-elb-types/
AWS ALBってなに?
6
- 8. AWS ALBってなに?
● AWS Elastic Load Balancing(ELB)を2009年に発表
● その後、AWS Application Load Balancer(ALB)を2016年に発表
● 主な特徴
○ レイヤー7のLBとして動作する
○ HTTPとHTTPSのリクエストヘッダにアクセスし、
パスやドメイン、送信元IPなどを判別して負荷を分散できる
○ AWS WAFの利用によるセキュリティ強化
○ OpenID Connectによる認証機能がマネージドで利用できる
○ などなど。。。
細かいことはクラスメソッドさんの記事をドゾ
https://dev.classmethod.jp/articles/describe-elb-types/
8
ALBでルーティングしちゃえば
各EC2インスタンス上のNginxっていらな
くね??
スクリプト言語だったとしてもNginxの設
定を数行に抑えられるんじゃね?
Editor's Notes
- 大越 雄太 (Yuta Okoshi)
最近の経歴:
2020年5月に留学資金集めのためにフリーランスとして転生し
同時にハウテレビジョンのSREチームとしてJOIN
HowTVでの主なお仕事:
AWSのリソース整理など主にインフラ周り
趣味:
IoT × サバイバルゲームでいろいろ作ってます
チンチラと同居生活中
チンチラ飼ってるよーとか、IoTガジェット作ってるって方はぜひお話させてください
-
Google OpenID Providerを使えるのでGoogleアカウントを利用したらアカウント管理業務が0に。。。。??
- ALBのちょっとイイ話をしていきます。
ところで先程のスライドの中で気になることがあったと思います。
- このリクエストヘッダにアクセスして負荷を分散させることができるということは
各インスタンス上でNginxの設定を全部取り除けるのでは???という考えが僕の中で生まれました。
それを実現するための方法を見つけてみたので次のスライドを紹介したいと思います。
- ALBにはポートごとにリスナーを用意し
各リスナーにはルールを定義することができます。
そのルールは上から順に評価され当てはまり次第ルール先のターゲットグループへルーティングされます。
ターゲットグループにはEC2やLambda、IPアドレス、API Gatewayなど様々なリソースの特定のポートに対してターゲットとして登録できるので大抵のことはできると思います。
- これら構成を踏まえた上でこの赤色の部分が今回のお話になります。
まずWebアプリといえば80ポートと443ポートが開いていますが、Nginxやアプリ側でhttpsへのリダイレクト設定などをやっていたりしますよね?
それらをALB上でやってしまいました。
こうすることで80ポートに来たリクエストはEC2にたどり着く前にhttpsとしてリダイレクトされるのでEC2側はhttpsかhttpなのかといったことを気にしないで良くなりました。
また、443ポートのリスナーを見るだけでどのTGにどんなリクエストが行くのかがひと目で分かるようになります。
443ポート側のルールにも工夫があります。
デフォルトの向き先を404にすることで意図しないリクエストをEC2が処理しないようにできます。
例えばIPアドレスによるアクセスや意図しないサブドメインでのアクセスなどを遮断できます。
アプリ側では特定のドメインでリクエストが届くことを前提にWebアプリの開発ができるようになります。
- それではこれら構成を今の現場でどのように適応したのかを次のスライドで説明していきたいと思います。
- まず。こちらが適応する前の開発環境の構成になります。
EC2から直接EC2を見ていたり、管理がかなり複雑になっていました。
- こちらを右の図のようにキレイにしてみました。
図を見るだけでもかなりわかりやすくなったと思います。
- 具体的な改善点としては