More Related Content
What's hot (8)
Recently uploaded (15)
AWS ALBのちょっとイイ話
- 2. 自己紹介 ● 大越 雄太 (Yuta Okoshi) ● 最近の経歴： 2020年5月に留学資金集めのためにフリーランスとして転生 同時にハウテレビジョンにJOIN ● HowTVでの主なお仕事： AWSのリソース整理など主にインフラ周り ● 趣味： IoT × サバイバルゲームでいろいろ作ってます チンチラと同居生活中 2
- 3. Agenda 1. AWS ALBってなに？ 2. ALBのちょっといい話 3. どんなところに利用した？ 3
- 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では３種類の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の設 定を数行に抑えられるんじゃね？
- 11. どんなところに 利用した？ 11
- 12. どんなところに利用した？ 12 既存環境の問題点 ● 1つのドメインに１つのLB ○ 料金がかさむ ● EC2から別のEC２をProxyしている場合もあった ○ ルーティング設定が至るところに点在 ● SSL証明書はもちろんEC2インスタンスに保存 ○ SSL証明書は未管理 ● CLBが利用されている箇所が多数あったり etc…
- 13. 13 どんなところに利用した？
- 14. 14 どんなところに利用した？ 改善点 ● ALBは外部向け、内部向けそれぞれ１つだけ ● 内部からのアクセスでも必ずLBを通す ● SSL証明書はACMで管理し必要に応じてALBで利用 ● ルーティング設定はALBに集約 ● EC2内部でのhttpsへのリダイレクト設定はすべて排除 ● Nginx側でルーティングを気にする必要がなくなった ● ALBによるブルー／グリーンデプロイメントの実施が 可能に
Editor's Notes
- #3: 大越 雄太 (Yuta Okoshi) 最近の経歴： 2020年5月に留学資金集めのためにフリーランスとして転生し 同時にハウテレビジョンのSREチームとしてJOIN HowTVでの主なお仕事： AWSのリソース整理など主にインフラ周り 趣味： IoT × サバイバルゲームでいろいろ作ってます チンチラと同居生活中 チンチラ飼ってるよーとか、IoTガジェット作ってるって方はぜひお話させてください
- #6: Google OpenID Providerを使えるのでGoogleアカウントを利用したらアカウント管理業務が０に。。。。？？
- #8: ALBのちょっとイイ話をしていきます。 ところで先程のスライドの中で気になることがあったと思います。
- #9: このリクエストヘッダにアクセスして負荷を分散させることができるということは 各インスタンス上でNginxの設定を全部取り除けるのでは？？？という考えが僕の中で生まれました。 それを実現するための方法を見つけてみたので次のスライドを紹介したいと思います。
- #10: ALBにはポートごとにリスナーを用意し 各リスナーにはルールを定義することができます。 そのルールは上から順に評価され当てはまり次第ルール先のターゲットグループへルーティングされます。 ターゲットグループにはEC2やLambda、IPアドレス、API Gatewayなど様々なリソースの特定のポートに対してターゲットとして登録できるので大抵のことはできると思います。
- #11: これら構成を踏まえた上でこの赤色の部分が今回のお話になります。 まずWebアプリといえば80ポートと443ポートが開いていますが、Nginxやアプリ側でhttpsへのリダイレクト設定などをやっていたりしますよね？ それらをALB上でやってしまいました。 こうすることで80ポートに来たリクエストはEC2にたどり着く前にhttpsとしてリダイレクトされるのでEC2側はhttpsかhttpなのかといったことを気にしないで良くなりました。 また、443ポートのリスナーを見るだけでどのTGにどんなリクエストが行くのかがひと目で分かるようになります。 443ポート側のルールにも工夫があります。 デフォルトの向き先を404にすることで意図しないリクエストをEC2が処理しないようにできます。 例えばIPアドレスによるアクセスや意図しないサブドメインでのアクセスなどを遮断できます。 アプリ側では特定のドメインでリクエストが届くことを前提にWebアプリの開発ができるようになります。
- #12: それではこれら构成を今の现场でどのように适応したのかを次のスライドで説明していきたいと思います。
- #13: まず。こちらが適応する前の開発環境の構成になります。 EC2から直接EC2を見ていたり、管理がかなり複雑になっていました。
- #14: こちらを右の図のようにキレイにしてみました。 図を見るだけでもかなりわかりやすくなったと思います。
- #15: 具体的な改善点としては