Amazonエラスティックロードバランシング高可用性アーキテクチャ: あなたのサーバにトップレベルの「トラフィック交通警官」を提供します

インターネットの世界では、設計者と上司が最も眠れないのは、2つのことではない

1つは、突然のトラフィックが急増してサーバが崩壊したこと、2つは、あるサーバが突然「ダウン」して全駅が麻痺したことである。

あなたのバックエンドサーバクラスタを銀行の店員に例えると、お客さんが一人か二人しかいないとき、みんな無事です。しかし、双十一、黒五、または突発的なニュースが来ると、何千人もの顧客が瞬時に流入し、一人の店員だけで長い列を作るだけでなく店員は過労で直接クラッシュすることもあります。

どうやって破れたの?秩序を維持し、客先を空いている窓口に均等に分配するために、明敏で有能な「ロビーマネージャー」が必要です。アマゾンクラウドテクノロジー (AWS) の生態では、この役割は

ELB (エラスティックロードバランシング、エラスティックロードバランシング)

。

今日、私たちはあいまいなPPT用語ではなく、純粋な実戦派の視点で、ELBを利用して堅固な「高可用性負荷分散アーキテクチャ」を構築する方法を深く分解している。

一、コア選定: 三大ELBファミリーのメンバー、どちらを選ぶべきですか

AWSのELBは単一の製品ではなく、異なるビジネスシーンに対して、三つの主要な方向性を派生した。間違ったモデルを選ぶのは、スポーツカーで荷物を引き揚げたり、トラックで競走したりするようなもので、お金を浪費しても効果が得られない。

1. ALB (a p p a t i o n Load Balancer): 負荷分散器の適用

位置付け: HTTP/HTTPSトラフィック (つまり、ネットワークの7層プロトコルのアプリケーション層) に焦点を当てます。

絶命: 高度なルーティング機能。リクエストの内容がわかります。例えば、ユーザーアクセスコントローラードメイン名(Host)、Header、クエリ文字列に基づいてトラフィックを配布することもサポートしています。

適用シナリオ: ほとんどのWebアプリケーション、マイクロサービスアーキテクチャ、コンテナアプリケーション (ECS/EKS)。

2. NLB (ネットワーク・ロード・バランサー): ネットワーク・ロード・バランサー

位置付け: TCP/UDP/TLSトラフィック (ネットワーク4層プロトコルのトランスポート層) に焦点を当てます。

絶命: 究極の性能と超低遅延。NLBは毎秒数百万の突発的な要求を処理できる。さらに、静的ipアドレスをサポートしています。各利用可能エリアには固定された柔軟なIPがバインドされています。これは、ファイアウォールのホワイトリストを作成する必要がある企業レベルのドッキングには、まったく必要です。

適用シーン: ゲームサーバ、高周波金融取引システム、モノネットワーク (IoT) データ受信側。

3. GLB (Gateway Load Balancer)

-- ゲートウェイ負荷分散器

位置付け: サードパーティの仮想セキュリティデバイスを管理するために使用される (ファイアウォール、侵入検知システムなど)。

適用シーン: 大工場は全駅流量の安全監査と洗浄に使う。通常、中小規模ビジネスでは直接使用することはほとんどありません。

二、高可用性アーキテクチャ設計: ELBはどのように「故障自己治癒」を実現したのか?

多くの初心者は「私はELBにトラフィックを渡したが、もしELBが自分でハングアップしたらどうするのか?それは単点故障になったのではないか」と疑問を持っている。

AWSはとっくにこの点を考慮しています。ELBの名前の

エラスティック (弾性)

2つの意味を含む:

容量の弾力性

そして

アーキテクチャの柔軟性

。

1.使用可能ゾーン (Multi-AZ) で高可用性

ELBアーキテクチャを設計する際、最も核心的な原則は

卵をかごに入れないでください

。

AWSの各地理的地域 (Region) には、互いに独立した複数の利用可能な地域 (Availability Zone、略称AZ) が含まれています。各AZには独立した電力、ネットワーク、放熱システムがある。

ELBを作成すると、少なくとも2つの空き領域を選択するように強制されます。実際、ELBは、選択した使用可能なゾーンごとに、ロード・バランシングの「ノード (Node) 」を自動的に配置します。

ユーザーが要求を開始すると、DNSはトラフィックポーリングをこれらの異なる空きゾーンノードに配布します。

Aの利用可能な地域が豪雨に見舞われて停電が完全に麻痺すると、ELBのトップレベルのDNS解析は自動的にトラフィックを切り離し、すべてBの利用可能な地域のノードに流し込む。プロセス全体はユーザーには全く知覚されない。

2.ヘルスチェック: 「害群の馬」を正確に取り除く

ELBが高可用性を維持できるもう一つの大きな殺し方は

健康診断

。

ELBのルールを設定する必要があります

10秒ごとに、バックエンドサーバの/healthパスにHTTPリクエストを送信します。3回連続して200 OKを返すと、サーバが生きていることを示します2回連続して応答しなければ、そのサーバは「病気」と判定される。

あるサーバが不健康と判定されると、ELBはすぐにそれを

ブロックする

を選択します。これは「1台のサーバがパニックになったため、ユーザーの1/3がエラーにアクセスした」という惨劇を避けることに成功した。

三、実戦演習: 手でALB Multi-AZ高可用性Webアーキテクチャを構築する

次に、最も典型的なALBを例にして、生産環境の標準的な配置プロセスを行った。

ステップ1: バックエンドの「ターゲットグループ」を準備する

ロードバランサを配置する前に、「誰にトラフィックを送るか」を教えてください。AWで

Sでは、このバックエンドの集合をターゲットグループと呼びます。

EC2コンソールを開き、左側のナビゲーションバーでターゲットGroupsを見つけ、「Create Target group」をクリックします。

ターゲットタイプを選択し、通常はインスタ (インスタンス) を選択して、名前を入力します。

プロトコルとポート: HTTP:80 (またはアプリケーションが実行しているポート) を選択します。

Health checks (ヘルスチェック): チェックパスは、通常、サービス・ステータス・インタフェース (/または/status htmlなど) を記述します。詳細設定を展開し、「健康しきい値」を3、「不健康しきい値」を2、「タイムアウト時間」を5秒「間隔」を10秒に設定します。

「Next」をクリックして、AZ-AやAZ-Bなど、異なる空き領域で起動したWebサーバー・インスタンスをチェックし、「Create target group」をクリックします。

ステップ2: a p p a t i o n Load Balancerを作成する

左側のナビゲーションバーでLoad Balancersをクリックし、Create load balancerをクリックして、a p p a t i o n Load Balancerを選択します。

Scheme (シナリオ): Internet-facing (インターネット向け) を選択します。イントラネットマイクロサービスに負荷をかけている場合は、きみを選ぶ。

ネットワークマッピング: VPCを選択します。重要なステップ: us-east-1aやus-east-1bなど、少なくとも2つの空き領域をチェックし、各空き領域に対応するパブリックネットワーク・サブネットを選択します。💡構造避坑ガイドライン: ALB自身はパブリックネットワークのサブネットに存在しなければならず、パブリックネットワークのIPを入手してインターネットのトラフィックを受信することができない。しかし！ あなたのバックエンドWebサーバ (EC2) は可能で、 ** プライベート・サブネットに入れることを強くお勧めします。このように、外部には誰もipを介してあなたのサーバを攻撃することができず、すべてのセキュリティガードはフロントエンドのALBが担い、アーキテクチャのセキュリティは瞬時にいっぱいになった。

ステップ3: セキュリティグループとリスナーの構成

Security groups: ALBにセキュリティグループを関連付けるには、TCP 80(HTTP) とTCP 443(HTTPS) ポートを解放する必要があります。

Listeners and routing (リスナーとルート): デフォルトではHTTP:80のリスナーがあります。最初のステップで作成した「ターゲットグループ」を選択します。もし

SSL証明書がある場合は、「Add listener」をクリックしてHTTPS:443を追加し、ドメイン名証明書を設定します。

一番下のをクリック

Createロードバランサー

。約2分後、ALBの状態は

アクティブ

を選択すると、長いDNS名が取得されます (例:

My-alb-123456789.us-east-1.elb.amazonaws.com

）

四、高級: Auto Scaling (弾性伸縮) と合体して、究極の高可用性を達成する

ELBだけを使用している場合、トラフィックがバックエンド・サーバの総許容限界を本当に超えると、webサイトはまだ詰まっています。ELBはロビーのマネージャーで、より多くの店員を出すことはできません。

本当の「柔軟な自由」を実現するには

ELB

そして

Auto Scaling (自動弾性伸縮)

結びます。

[ユーザーリクエスト] -> [ELB] -> [トラフィックに応じてEC2数量を自動的に増減する (Auto Scaling Group)]

双十一零時が来ると、流量が急増する

クラウドウォッチ監視によると、バックエンドサーバの平均CPUは80% に上昇した。

Auto Scalingは信号を受信し、すぐに自動的にパッケージ化して新しいEC2サーバを5台作成します。

最も奇妙な点はここにあります。新しいサーバが起動すると、Auto Scalingは自動的にELBのターゲットグループに「レポートマネージャ、私は新しく来たキャビネット員で、準備ができています!」と報告します

ELBは通知を受けて、すぐに後続のトラフィックをこの5台の新しいサーバに分流し始めた。プロセス全体は、手動で構成を変更したり、デバイスを再起動したりする必要はない。

午前2時に流量が下がって、CPUが下がって、Auto Scalingはこの5台の機械を自動的に破棄してコストを節約し、ELBも優雅に切断します処理中の要求が正常に終了したことを確認してから、クラスタから移動します。

結語

現代のクラウド・ネイティブ・アーキテクチャでは、Amazon ELBは決して単純な「トラフィック・リピーター」ではなく、高可用性・アーキテクチャ全体である

指揮官

。

利用可能なゾーンにまたがるノードの導入によって物理レベルの災害を防ぎ、厳格なヘルスチェックによってシステム内部の障害を隔離したまた、Auto Scalingとの完璧な協力によって、業務が無限に広がる可能性を与えた。ELBの実行ロジックと配置の詳細を理解すると、高合併、ダウンタイムのない現代化サイトを構築する最も核心的な鍵を握っている。