aws-recipe-user IT未経験、前職はトラック運転手として日々配達をしていたDreamです。
オンラインセミナーの受講する種類が多くなってきて今までわからなかった単語が理解できるようになってきました。
今回はAWSのオンラインセミナーでELBについて勉強した際のメモをまとめていきます！
はじめに
■Amazon ELB(Elastic Load Balancing）
・ELBとはAWSクラウド上のロードバランシングサービス
・バックエンドのシステムに対して負荷分散、AWSのサービスと連携してスケーラブルに対応できる
■ALB（Application Load Balancer）リリースと従来のELB
・レイヤー７のコンテントベースのロードバランサー
・URLのパスの部分をルーティングする仕組み
・コンテナベースのアプリケーションのサポート（ECSとか）
・WebSocketやHTTP/2もサポートされている
■ELBの位置づけとしては
・ALBが出るまで提供されていたものがELB
→レイヤー4および一部レイヤー7機能を提供するロードバランサー
・クッキーをみたりするものだったものがALB（Application Load Balancer）
・CLB（Classic Load Balancer）
→今までのELB
・この二つを総称する形でELBとなる（名称変更）
■ELBで実現できるシステム
・スケーラブル : 複数のEC2インスタンス/ECS Service に負荷分散
・高い可用性 : 複数のアベイラビリティゾーンにある複数のEC2インスタンスECS Service の中から正常なターゲットにのみ振り分け
■ELB自体の特徴
・スケーラブル : ELB自体も負荷に応じてキャパシティを自動増減
・安価な従量課金 : 従量課金で利用可能
・運用管理が楽 : マネージドサービスなので管理が不要
・豊富な連携機能 : Auto Scaling, Route 53, Cloud Formationなどと連携
■負荷分散してスケーラブルなシステム
・バックエンドのEC2インスタンスのリクエスト数やコネクション数が均等になるように負荷分散される
・接続の少ないインスタンスに対して新しい接続を振り分ける
■ELB自体もスケーラブル
・ELB自体も負荷の増減に応じて自動でスケールする（キャパシティが自動で増加する）
・ELBがスケールするときにはIPアドレスが変わる
・ユーザがサイジングする必要がない
■複数AZに分散（可用性）
・2段階で負荷分散される
① DNSラウンドロビンで各AZ内のELBに振り分けされる
②負荷が均等になるようにバックエンドのEC2に振り分けられる
・AZを複数にまたがって構築する場合をサポートする
・リクエストを各ELBに振り分けそれをEC2に振り分ける
■各EC2に対してのヘルスチェック
・ELBは指定した設定に基づきバックエンドのインスタンスのヘルスチェックを行う
（タイムアウト時間など）
・正常との判定が遅いと追加したインスタンスが使えるまでに時間がかかる
・逆に異常との判定が厳しすぎても過負荷時に処理できるインスタンスを減らしてしまう可能性がある
■料金
・時間当たりの利用料は複数AZ配置構成でも同じ
・ELBにリザーブドはなし
・処理量の課金単位は合計処理量（CLB）とLoad Balancer Capacity Units(LCU)（ALB）となる
LCUとは
①新規接続数：1秒あたりの新しく確立された接続数
② アクティブ接続数：1分あたりのアクティブ接続数
③ 帯域幅：ロードバランサで処理されたトラフィック量
の中で最も使用量が高いものが請求される
■ELBの機能
・独自ドメイン名での利用ができる
・Route53以外のDNSを使用する場合はCNAMEで登録できる
・Route53で使用する場合はRoute53エイリアスレコードで登録できる（CNAMEでの登録も可能）
■クライアントIPアドレスの取得方法
・バックエンドサーバへの接続はソースIPアドレスがELBのIPアドレスとなる
・クライアント≒ELB、ELB≒バックエンドの接続はそれぞれ独立していてアクセスログにはELBのIPアドレスが記録される
・クライアントのIPアドレスが必要な場合はHTTPヘッダ上のX-Forwarded-Forで参照可能
■AZとバックエンドキャパシティの関係
・リージョン内の複数のAZに負荷分散可能
・各EC2インスタンスのタイプは同じに
・AZごとのEC2インスタンス数はできれば均等にする
・クロスゾーン負荷分散（アベイラビリティゾーンをまたいで各サーバのセッションが均等になる）
・常にクロスゾーン負荷分散がELBでは有効になっている
・ALBは選択不可、CLBは選択可能
■ELBのコネクションタイムアウト
・バックエンドに割り当てているセッションのタイムアウトをさせることができる
・無通信状態が続くとそのコネクションを自動で切断
（デフォルトではタイムアウト値は60s、1-3600sの間で設定可能）
■ELB自体のスケーリング
・負荷によって自動でスケールアップ、アウトする
※ただし、ELBへの接続・リクエストが瞬間的に急増したためにELBのスケーリングが間に合わない場合は事前にPre-Warming（暖機運転）の申請を行っておく
・負荷が低い段階からELBのキャパを予約する
■VPCでの利用
・サブネットに対してELBが作成される
・配置するサブネットをAZごとに1つ指定
・サブネットは最小/27CIDRブロックで8個以上の空きIPが必要
■Internet-Facing ELB（インターネットに接続する場合）
・インターネットからアクセスできるELB
■Internal ELB（インターネットに接続しない場合）
・VPC内やオンプレミス環境からのみアクセスできればよいELBプライベートサブネットにも配置できる
■ELBとセキュリティーグループ
・ELBに任意のSecurity Groupを指定可能
・ICMP Echo Request/Replyを許可すれば、ELBがpingにも応答
・バックエンドのEC2インスタンスはELBからのみリクエストを受け付ける設定を推奨 ・ELBだけからバックエンドに接続することができるようにする設定が可能
■SSLサポート
・ELBでSSL Terminationできる
①・ ELBでSSL Terminationし、バックエンドとはSSLなしバックエンドのEC2インスタンスでSSL処理せずに済むため負荷をオフロードできる。
・クライアントとELBはSSLで接続し、ELBとバックエンドはSSLなしで通信することでバックエンドの負荷を下げることができる
②・ELBでSSL Terminationし、バックエンドとは別途SSL
・バックエンドとの通信SSLで接続可能
③・SSLをバイパスしてバックエンドにTCPで送信
・PCとバックエンドのインスタンスが直接通信する設定も可能（ALBでは使用不可）
■HTTPS/SSL利用時のサーバ証明書
・ELBにサーバ証明書をアップロード
・HTTPS/SSL利用にはサーバ証明書のアップロードが必須
・AWS Certificate Manager との統合
・複数ホスト名には別名・ワイルドカードか複数ELBで対応（SNI未対応）
・バックエンドとの通信にSSLを用いないなら証明書の管理が容易
・マネージメントコンソール or CLI or IAM APIで設定
・すでにもっている証明書をアップロードして簡単に利用可能
・AWSで作成したものでも簡単に利用可能
■SSLのセキュリティ
・TLSのサポート
・Perfect Forward Secrecy (PFS) のサポート
・Server Order Preference
■スティッキーセッション（stickness)
・同じユーザから来たリクエストを全て同じEC2インスタンスに送信
・デフォルトで無効、利用するためには有効に
・アプリケーションでのセッション情報、一時ファイルなどをEC2インスタンスが保持する構成の場合に必要
・HTTP/HTTPSでのみ利用可能
・ELBは独自のセッションCookieを挿入
・クッキーによる実装
（ELBが設定するクッキーを使ってセッションすることができる）
・有効期間は2種類
①Application Generated Cookie Stickiness（アプリケーション制御）
・アプリケーションが作成したCookieにあわせる
・アプリケーションが作成するCookie名を指定
・Cookieの有効パスもあわせる
②Load Balancer Generated Cookie Stickiness（期間ベース）
・セッション開始からの有効期間を指定してELBで制御
・秒単位で指定
・無期限にする事も可（無期限でもブラウザを閉じれば終了）
■Connection Draining
・バックエンドのEC2インスタンスをELBから登録解除したりヘルスチェックが失敗したときに新規割り振りは中止して処理中のリクエストは終わるまで一定期間まつ
・バックエンドのインスタンスがELBから登録解除された場合、サーバをロードバランサの配下から外した場合デフォで5分はそのサーバからのセッションのレスポンスが返るのを待つ
・すでにふられているリクエストが正しくかえるのを待つ
■アクセスログのS3保管
・ELBのアクセスログを設定したバケットに対して自動的に保管される
・簡単にログのS3保管が実現できる
・一般的なログの保管が可能
■CLB・ALBの機能
・CLBは基本的にL4のロードバランサなので、HTTP/HTTPSに加えてTCP/SSLによる負荷分散が可能になっている
・ELBとバックエンドのEC2インスタンス間でHTTPS/SSL使用時に特定の証明書を使用しているかどうかバックエンドを認証
・バックエンドインスタンスはすべて同一の機能を持ったインスタンスでないといけない
・従来はバックエンドのインスタンスに異なる機能を持たせる場合には手順が複雑化していた
・上記内容からALBがでてきた
・ALBは単一のロードバランサーで異なるアプリケーションへリクエストをルーティング可能
・URLのパス部分のパターンでどのターゲットグループに振り分けるかを判断している
・コンテナかされたアプリケーションは１つのサーバ上でアプリケーションごとに特定のポートを使う必要があった
・これまでのELBではコンテナ化されたアプリの利用に制限があった
・ポートを分けることで１つのEC2インスタンス上で同じアプリケーションを複数実行可能
・Ec2インスタンスをターゲットグループに割り当てる際に複数のポートを個別のターゲットとして登録できる
・１つのEc2インスタンスに対して複数ポートで負荷分散が可能
・あいているポートを自動的に探し、ターゲットグループに自動で登録
・WebSocket、HTTP/2に対応、メトリクスの改善（詳細なエラーコードなどが確認可能）
■ALBのリソース
【ロードバランサー】
・ALB自体を指し示す。従来CLBでは唯一のリソース
【リスナー】
・ロードバランサーがリスニングするポートとプロトコル
【ターゲットグループ】
・Ec2インスタンスなどのターゲットの集合
【ターゲット】
・ロードバランサーがトラフィックを転送するリソースなど
【ルール】
・どのターゲットグループにパスを転送するかというルールを決める
■CLBとALBの機能比較
■ELBと各種サービスの連携
・Auto Scalingとの連携（インスタンス増減時にELBへの追加・削除が可能）
・EC2 Container Service(ECS)のALB対応（ALBによりECSのコンテナをまたがった負荷分散が可能 ）
・AWS Certificate Manager との統合（証明書のリクエストと管理を容易に実施）
・CloudWatchとの連携（CloudWatchによりELBの以下のメトリクスを1分単位で監視可能）
・Route 53 DNSフェイルオーバ対応（Route 53のヘルスチェック機能とELBが連携）
・OpsWorksのELB対応（OpsWorksでELBをレイヤーにアタッチして、負荷分散が可能）
・AWS Trusted AdvisorによるELBのチェック（ELBのセキュリティとフォールトトレランスをチェック）
■ELB負荷テスト
・ELBのいくつかの特徴がテストシナリオに影響を与える可能性がある
①ELB のスケーリング
②ELB の初期キャパシティ
③アイドル時のコネクションタイムアウト
④バックエンドインスタンスのヘルスチェック
⑤Sticky セッション
など、利用状況に合わせたシナリオでテストが必要
・想定する最大負荷のテスト
・通常のトラフィック時のテスト（トラフィックの多い・少ない・変化がある時という形で）
・短い時間でトラフィックが大きく変化する場合のテスト
おわりに
今回はELBについてのメモを展開しました。
個人的な感想といてはロードバランサーとは負荷を分散させる装置という認識しかなかったので、AWSで提供されているELBの機能の充実さに驚きました。
今後も勉強した内容を記事にしていけたらと思います。
本記事が自分のようにこれからAWSの勉強を開始される方の参考に、また勉強している方の復習になれば何よりです。
次回もお楽しみに！
