AWS -ELBとAuto-Scaling-

  今回はAWSのELBとAuto-Scalingについて書いていこうと思います。
まずはEBLから書いていきます。

ELBとは

 EBLとは、マーネージド型のロードバランシングサービスで、EC2インスタンスの処理を分散する際に標準的に利用するもので、基本的には単一障害点を排除する際に、サーバーの負荷を下げる時にこのELBを使った構成を作っていくことが標準的なアーキテクチャ設計になっています。

 そしてEBLの特徴が以下になります。

【特徴】
 ・インスタンス間の負荷分散をする。
 ・異常なインスタンスを認識して対応する。(停止しているインスタンスがあればトラフィックを回さないようにすることができる)。
 ・パブリック、プライベートどちらでも使用可能。
 ・ELB自体も負荷に応じてキャパシティを自動増減するスケーリングを実施。(スケーリング自体もAWS側でやってくれる)
 ・従量課金で利用可能。
 ・マネージドサービスなので管理が不要。
 ・Auto-Scaling, Route53, Cloud Formationなどと連携して使用する。

ELBの主要機能

 ELBの主要な機能について記述していきます。

◯ ヘルスチェック
 ・EC2インスタンスが正常か異常かを確認し、利用するインスタンスの振り分けを行う。(通常時は均等にトラフィックの振り分けを行い、異常なインスタンスを確認したらそのインスタンスへのトラフィックを停止する)

◯ 負荷分散
 ・配下のEC2の負荷に応じて、複数AZに跨がるインスタンスの負荷分散を行う。

◯ SSLサポート
 ・ELBでSSL Terminationできる。

◯ Connection Draining
 ・インスタンスが登録解除されるか、異常が発生した場合にそのバックエンドインスタンスへの新規リクエスト送信を中止する。

◯ S3へのログ保持
 ・ELBのアクセスログを、指定したS3に自動保管。

◯ スケーラビリティの確保
 ・スケーラビリティの確保として、EC2で負荷分散をしてトラフィックの量を分散させることができます。インスタンスAとインスタンスBで負荷分散を実施した場合に、インスタンスAにはトラフィック30、インスタンスBにはトラフィック70というようにトラフィックを分散させることができる。

◯ 高可用性
 ・複数のAZにある複数のEC2インスタンスECS Serviceの中から正常なターゲットにのみ振り分けができる。

ELBのタイプ

 現在利用できるロードバランサーは3つのタイプで用途に応じて使い分けることができます。

◯ CLB(Classic Load Balancer)
 初期に提供されたELBであり、標準なレイヤー4/レイヤー7におけるロードバランシングが可能だが、複雑な設定はできない。

・HTTP/HTTPSとTCP/SSLプロトコルのレイヤー4とレイヤー7に対応。
・Proxyプロトコルによる発信元IPアドレス識別。
・ELBとバックエンドのEC2インスタンス間でHTTP/SSL使用時にサーバー証明書認証を実施。
・CLB配下のインスタンスは、全て同一の機能を持ったインスタンスが必要。
・異なる機能に対してコンテナベースルーティングはできない。

◯ ALB(Application Load Balancer)
 レイヤー7の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能。

・URLのパスに基づいてルーティングが可能なパスベースルーティングが可能。
・WebSocketとHTTP/2のリクエストを受付。
・1インスタンスに複数ポートを登録可能。
・EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、ポートを利用するコンテナをロードバランシング可能。
・ターゲットグループでのヘルスチェックが可能。
・アクセスログの情報追加。
・EC2と同様に削除保護が可能。
・ALB自体が自動的にキャパシティを増減。

◯ NLB(Network Load Balancer)
 NLBは、超低遅延で高スループットを維持しながら秒間何百万リクエストを捌くように設計された新しいロードバランサーで、かなり大量処理が要求される場合にこちらのロードバランサーを使用することになり、基本的にALBを使用することの方が一般的ですが、高性能が必要であればNLBを検討するようにします。

・開放型システム間相互接続(OSI)モデルの固定IPアドレスを持つレイヤー4のロードバランサー。
・揮発的なワークロードを処理し、毎秒数百万のリクエストに対応できる能力。
・VPC外のターゲットを含めたIPアドレスや静的IPアドレスでの登録可能。
・複数のポートで各インスタンスまたはIPアドレスを同ターゲットグループに登録可能。
・大規模アクセスが予想される際にCLBやALBで必要だったPre-Warming申請が不要。
・ALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断していたが、NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、パケットからアクセス元が判断可能。
・NLBはフォルトトレランス機能を内蔵したコネクション処理をもち、数ヶ月から数年のオープンなコネクションを処理できる。
・コンテナ化されたアプリケーションのサポート。
・各サービスの個別のヘルスステータスのモニタリングのサポート。

ここからはAuto-Scalingについて記述していきます。

Auto-Scaling

 Auto-Scalingは、リクエストの増加やアクセスが増えた場合にトラフィック量が処理できなくなる前に、設定に基づきインスタンスを自動的に起動や終了します。

スケーリングタイプ

 スケーリングタイプには2種類あり、Auto-Scalingは水平スケーリングになります。

◯ 垂直スケーリング
 【拡張方法】
   スケールアップ:メモリやCPUの追加・増強。
 【低減方法】
   スケールダウン:メモリやCPUの削減・低性能化。

◯ 水平スケーリング
 【拡張方法】
   スケールアウト:処理する機器 / サーバー台数を増加。
 【低減方法】
   スケールイン:処理する機器 / サーバー台数を低減する。

垂直スケーリングは、サーバー内の機能をよくしたりサーバーの機能を落としたりするときに使用し、水平スケーリングはサーバー自体を増やしたり、サーバー自体を減らしたりする際に使用します。

Auto-Scalingの要素

Auto-Scalingは主に3つの要素で構成されています。

◯  Auto-Scalingグループ
 スケールするインスタンスの最大数などの基本情報を設定する。

・起動インスタンスの最大数と最小数を設定する。
・今時点で必要な最適なインスタンス数(Desired Capacity)の数量になるようにインスタンスを起動 / 終了を調整。
・起動台数をAZ間でバランシングする。
・AZ障害時は障害のない別のAZにその分のインスタンスを起動する。

◯ Auto-Scaling configuration : 起動設定
 スケールアウトの際に起動するインスタンス内容を設定する。

【主要な設定項目】
・AMI
・インスタンスタイプ
・セキュリティグループ
・キーペア
・IAMロール

◯ Auto-Scaling Plan
どのようにスケールするかの方法を定義する

・Auto-Scaling Groupサイズの維持
  現在のAuto-Scaling Groupのインスタンス最小限台数を維持する設定をする。

・手動スケーリング
  設定外で予期せぬスケーリングが必要となった場合に手動でスケーリングを実施。

・スケジュールベース
  予測された需要増加時期に合わせたスケーリングスケジュールを設定。

・動的スケーリング
  予測不可能なケースにスケーリングポリシーにスケール方針を設定して、動的にスケールアウトを実施。

ヘルスチェック

 Auto-Scaling配下のEC2のヘルスチェックにはEC2のステータス情報またはELBのヘルスチェックのどちらかを利用する。

 ・EC2ステータス:インスタンスのステータスがrunning以外の状態を異常と判断。
 ・ELB:ELBのヘルスチェック機能を活用する。

ターミネーションポリシー

 需要減に基づくスケールインの際に、どのインスタンスから終了するかを設定。種類は以下の4つあります。

⓵ OldestInstance/NewestInstance
 ・最も古いインスタンスや新しい起動時刻のインスタンスなどの順から終了。

⓶ OldestLaunch Configuration
 ・最も古い起動設定により起動しているインスタンスから終了。

⓷ ClosestTo NextInstanceHour
 ・次の課金が始まるタイミングが最も近いインスタンスから終了。

⓸ デフォルト設定
 ・⓶、⓷の順に運用する。その後複数インスタンスが残った場合はランダムに終了する。

Auto-Scalingの設定プロセス

1. ALBの作成
2. ターゲットグループの設定
3. 起動するインスタンス設定
4. Auto-Scalingグループ作成
5. Auto-Scalingポリシー / スケジュール設定

Auto-Scalingの設定ポイント

・インスタンスの最大値 / 最小値の設定は慎重に設定する。
・ステートフルなアプリケーションへの設定には、Auto-Scaling Groupでの自動設定は必要。
・ライフサイクルフック(起動時または削除時にインスタンスを一時停止してカスタムアクションを実行)を使用。
・Auto-Scalingスラッシング(急なスケールインによる影響)を避ける。



この記事が気に入ったらサポートをしてみませんか?