ELBとAuto Scaling

このレッスンを終えると、負荷を「配る」仕組みと台数を「増減させる」仕組みが別物であることを説明でき、要件からどちらを答えるべきかを選べるようになります。

自分でやると、どこで詰まったか

オンプレミスで 1 台のサーバーを運用していると、アクセスが増えたときに二段階で困りました。

まず、2 台目を足しても通信が自動では割り振られません。DNS を書き換えるか、自分で nginx をリバースプロキシに仕立てて振り分け先を書き、片方が落ちたら手で設定から外す必要がありました。次に、そもそも何台必要かが事前に分からない。キャンペーンの日に合わせて多めに買えば普段は遊びますし、少なく買えば当日落ちます。

AWS はこの2つの困りごとを、別々のサービスとして用意しています。前者が ELB、後者が Auto Scaling です。

ELB は入口で配る

Elastic Load Balancing (ELB) は、受け取ったリクエストを複数のターゲットへ振り分けるマネージドな負荷分散装置です。振り分けだけでなくヘルスチェックを行い、応答しなくなったインスタンスを自動で振り分け先から外します。手で設定を書き換えていた作業が消えるということです。

ELB は複数のアベイラビリティゾーン (AZ) にまたがって配れます。片方の AZ が丸ごと落ちても、もう片方の AZ にあるインスタンスへ通信が流れ続けます。マルチ AZ 構成の高可用性は、ELB があって初めて成立すると考えてください。

種類は主に3つで、HTTP や HTTPS の中身を見て振り分ける Application Load Balancer、TCP や UDP を高速に流す Network Load Balancer、ネットワーク仮想アプライアンス向けの Gateway Load Balancer があります。CLF では「HTTP のパスやホスト名で振り分けるなら Application Load Balancer」まで分かれば十分です。

Auto Scaling は台数を合わせる

Amazon EC2 Auto Scaling は、インスタンスの台数を需要に合わせて自動で増減させる仕組みです。Auto Scaling グループに最小台数、希望台数、最大台数を決めておき、CloudWatch のメトリクス (CPU 使用率など) やスケジュールを条件に増減させます。

合わせて押さえたいのは、Auto Scaling が可用性にも効くという点です。ヘルスチェックに失敗したインスタンスを終了させ、代わりを起動して最小台数を保ちます。壊れた 1 台を夜中に手で入れ替えていた作業が自動化されます。

2つの関係は次の通りです。ELB が入口で配り、Auto Scaling が配られる先の台数を増減させ、増えた新しいインスタンスは自動的に ELB の振り分け先に加わります。どちらか一方では、伸縮する高可用な構成にはなりません。

試験ではこう出る

言い換えのパターンがはっきりしている分野です。

• 「トラフィックを複数のインスタンスに分散したい」「単一障害点をなくしたい」は ELB です
• 「需要の変動に応じて容量を自動で調整したい」「使わない時間帯のコストを下げたい」は Auto Scaling です
• 「弾力性 (Elasticity)」という語が出たら Auto Scaling を、「高可用性」で複数 AZ への分散を指していれば ELB を疑います
• 「障害が起きたインスタンスを自動で置き換えたい」は Auto Scaling です。ELB は振り分けから外すだけで、代わりを起動はしません。ここが最も紛らわしい線引きです

まとめ

• ELB は入口でリクエストを配り、ヘルスチェックで不健全なターゲットを振り分けから外します
• Auto Scaling は台数そのものを増減させ、最小台数を保って壊れた 1 台も置き換えます
• 高可用性と弾力性は、2つを組み合わせて初めて成り立ちます
• 外すだけが ELB、起動し直すのが Auto Scaling、と覚えると誤答を避けられます