アマゾンクラウド国際駅の高可用性アーキテクチャ設計: 可用性ゾーン (AZ) を越えた災害とELB負荷のバランス
クラウドコンピューティング時代には、「高可用性 (High Availability、HA) 」はほとんど様々な設計者に口にされた言葉である。多くの人は、システムをアマゾンクラウド (AWS) に移し、EC2を購入し、負荷バランスを実現すれば、高可用性が自然に実現できると考えている。
しかし、本当の生産環境は往々にしてこのような盲目的な楽観に大きな耳を傾けます。
AWS使用可能ゾーン (avaibzone、AZ) が、基礎となる光ケーブルが切断されたり、電力が故障したり、ソフトウェア定義ネットワーク (SDN) が異常になったりして麻痺した場合あなたのサービスは自動的にシームレスに切り替わるのですか、それとも一緒にダウンしたり、コールが爆発したりしますか?
本当の
高可用性アーキテクチャは購入されたものではなく、設計されたものです
。本文は複雑なPPT黒話を徹底的に捨てて、最もわかりやすい「大口語」でアマゾンのクラウド国際駅で最も核心的な二つの高利用命題を解体する
利用可能エリア (クロス-AZ) を越えた災害復旧
と
ELBロードバランシング
。
一、「高可用性」を再定義する: RegionとAZの基礎的な真実
ペンでアーキテクチャを設計する前に、AWSの基礎となる物理インフラを認識しなければなりません。これはすべての高可用性設計の基礎である。
地域 (Region): 地理的に完全に隔離された地域 (東京、バージニア、アイルランドなど)。地域間の距離は極めて遠く、地政学的な災害が発生しない限り、ある地域の停電は決して別の地域に影響を与えない。
使用可能ゾーン (AZ): 1つのゾーンに複数の使用可能ゾーンが含まれています。AZはデータセンターと同じではないことに注意してください。1つのAZは、互いに近いが、電力とネットワークが完全に独立したデータセンターグループで構成されている可能性がある。
💡核心的なペインポイント: なぜシングルAZアーキテクチャが必死なのか?多くの海外企業はお金を節約するために、Webサーバとデータベースをすべて同じAZ (例えばap-northeast-1a) に落としている。これは、すべての卵を「防弾チョッキ」と呼ばれているが、雨漏りの可能性があるかごに入れることに相当する。このzがバックボーンネットワークの障害を起こすと、あなたの業務は一瞬にして失敗します。
そのため、AZ(Multi-AZ) アーキテクチャは「高度なオプション」ではなく、本番環境の
ハードボトムライン
。
二、流量の交通警官: ELB (弾性負荷バランス) の正しい開き方
AZを越えた災害を実現するには、最初のステップに「トラフィック警官」が必要で、世界中のユーザーからの要求を均一に、スマートに異なる利用可能な地域のサーバに配布しなければならない。AWSでは、この役割は
ELB (エラスティックロードバランシング)
担当
AWSはいくつかのロードバランサーを提供していますが、現代のWebアーキテクチャでは主に
ALB (アプリロードバランサー)
そして
NLB (ネットワークロードバランサー)
。
1. ALB vs NLB: 選択しないでください
武器を間違えた
特性
ALB (負荷分散装置の適用)
NLB (ネットワーク負荷分散器)
作業OSIレベル
レイヤ7 (アプリケーション層: HTTP/HTTPS)
レイヤ4 (トランスポート層: TCP/UDP/TLS)
コアな強み
賢い。URLパス、Cookie、HTTPヘッダーを識別して高度なルーティングを行うことができます。SSL証明書のオフロードをサポートします。
非常に速いです。超低遅延で、毎秒数千万級の同時要求を処理でき、固定IPをサポートします。
適用シーン
ほとんどのWebアプリケーション、マイクロサービスAPI、電気商サイト。
ゲームゲートウェイ、モノネットワーク (IoT) 受信側、非HTTPプロトコルのオリジナルTCPサービス。
ほとんどの海外企業に対して
アルブ
一番おすすめの選択肢です。
2.利用可能なゾーン間の負荷分散
これはELB設計の中で最も穴を踏みやすいところです。
デフォルトでは、ALBの空き領域間の負荷分散は
開始する
のですが、NLBはデフォルトで
閉じる
の。これにはどんな違いがありますか
シャットダウン状態: DNSがトラフィックの50% をAZ-Aの負荷分散ノードに割り当て、50% をAZ-Bの負荷分散ノードに割り当てます。AZ-Aにサーバが1台しかなくても、AZ-Bにサーバが4台あっても、AZ-Aのサーバは50% のトラフィックで疲れている。
オンの状態では、トラフィックが先にどのAZの負荷分散ノードに到達しても、ELBは要求を背後にあるすべてのAZのすべてのバックエンド・インスタンスに均等に割り当てます。
結論:
非常に厳しい遅延要求 (マイクロ秒レベル) がない限り
使用可能なゾーン間で負荷分散をオンにすることを強くお勧めします
を選択します。
三、AZにまたがって災害を許す鉄三角: 計算、ネットワークとストレージ
ELBという警官がいるとまだ足りない。バックエンドの車線 (計算) 、ネットワーク (ネットワーク) 、倉庫 (ストレージ) にもAZを越えた能力が必要だあるAZが暴発した時に「無感切り替え」を実現することができます。
1.計算層: Auto Scaling (自動拡張グループ) は唯一の正しい姿勢です
2台のマシンを手動で作成して2つのzを入れないでください。使うべきです
AWS Auto Scaling Group (ASG)
。
起動テンプレートを1つだけ設定して、ASGに「最低でも2台のマシンが必要で、最大で10台必要です。
Ap-northeast-1a
そして
Ap-northeast-1b
この2つのzのうち。」と言いました
ヘルスチェック: ELBにEC2が開いているかどうかだけをチェックさせないでください。ELBを設定して、コード内の特定のインタフェース (/healthなど) を要求します。このインタフェースが500を返すか、データベース接続に失敗した場合、ELBは
このインスタンスの「不健康」を判断し、トラフィックの送信を停止します。
自己治癒能力: あるアズがハングアップすると、そのアズ内の機械はすべて連絡が取れなくなり、ASGはすぐに警報を発動し、別の健康なアズの中で自動的に新しい機械を開いてギャップを埋める。
2.ネットワーク層: サブネットとルーティングの黄金法則
プライベートネットワーク (VPC) の設計では、多くの人が構造が混乱している。標準的な高可用性ネットワークアーキテクチャは「対になって出現し、絶対的に隔離する」という原則に従うべきである。
パブリックサブネット: Internet Gateway、ELB、NATゲートウェイを配置します。AZごとに1つずつ。
プライベートサブネット: 実際のEC2アプリケーションサーバを配置します。これらの機器はパブリックネットワークのIPを必要とせず、絶対に直接インターネットに暴露してはならない。AZごとに1つずつ。
高可用性NATゲートウェイトラップ: 多くのチームはお金を節約するために、VPC全体にNATゲートウェイを1つだけ建設してAZ-Aに置き、AZ-BのプライベートEC2もAZを越えてインターネットに接続している。AZ-Aがハングアップすると、AZ-Bのサーバは生きているが、インターネットに接続できない (外部APIにアクセスできない、依存をダウンロードできない) ために廃棄された。正しいやり方: 各AZはそれぞれ独立したNATゲートウェイを持っています。
3.ストレージとデータベース層: シングルポイントに別れを告げ、Multi-AZを抱きしめる
計算ノードは無状態で、死んでいつでも再開できる。しかし
データは状態があるので、データは決して失われてはならない。
リレーショナルデータベース (RDS / Aurora): Multi-AZ導入を強くオンにします。AWSは、別のAZで完全に同期されたスタンバイインスタンスを自動的に作成します。メインライブラリがあるAZが故障すると、RDSは自動的にDNSドリフトを行い、数sから数十s以内にスペアライブラリをメインライブラリにアップグレードしますアプリケーションコードは、接続文字列 (Endpoint) を変更する必要さえありません。
ファイルストレージ (EFS vs EBS):EBS (クラウドハードドライブ): 特定のAZにバインドされています。これは、AZ-AのEC2がハングアップしたことを意味し、EBSをAZ-BのEC2に直接マウントすることはできません。EFS (柔軟なファイルシステム): ネイティブはAZ間をサポートしています。複数のAZのEC2は、同じEFSを同時に読み書きできます。あなたのビジネスが共有ファイルストレージ (例えばWordpressのピクチャーアップロードディレクトリ) を必要とするならば、ためらうことなくEFSを选んでください。
四、究極の実戦: 標準的なマルチAZ高可用性アーキテクチャ演習
より直感的な感覚を得るために、AWSがAZの高可用性アーキテクチャを越えて、標準的なユーザー要求がどのように流れているかをシミュレーションします。
シナリオ: ユーザーがecサイトにアクセスする [https: // example.com]
ドメイン名解決: ユーザーが要求を開始し、AWSルート53 (スマートDNS) がドメイン名を解決する。設定のため
遅延またはポーリングポリシーを使用すると、ルート53はパブリックサブネットに配置されたALBにトラフィックをポイントします。
トラフィック配布: ALBはHTTPS要求を受信し、ローカルでSSL証明書の復号化 (オフロード圧力) を完了し、空き領域間の負荷分散ポリシーに基づいてAZ-AまたはAZ-BのプライベートサブネットにあるEC2インスタンスにリクエストを転送します。
業務処理とデータ読み書き: EC2上のアプリケーション処理業務。データベースを読み書きする必要がある場合は、RDSメインライブラリ (AZ-A) に接続します。この時点で、RDSは自動的にデータ同期をRDSバックアップライブラリ (AZ-B) にコピーします。
災害発生 (模擬AZ-Aが完全にネットワークを切断する):ELB反応: ALBがAZ-A内のEC2インスタンスの心拍停止を発見したか、ヘルスチェックが連続して失敗した場合、すぐにAZ-Aを転送リストから除外します。100% のトラフィックが瞬時にAZ-BのEC2に導入されます。RDS自己治癒: AWSはRDSマスターライブラリの失敗を監視し、自動的にフェイルオーバーを開始する。AZ-Bのスペアライブラリは30秒以内に新しいメインライブラリにアップグレードされ、ルート53は自動的にRDSの内部Endpointを更新します。AZ-BのEC2が一時的にエラーになった後、正常な読み書きを再開した。ASG拡張: Auto Scaling Groupは、現在生存しているマシンの数が設定された最小期待値より少ないことを発見し、すぐに健康なAZ-Bに新しいEC2をポップアップし、ALBの背後に自動的に登録します。
結果:
プロセス全体では、切り替えの瞬間に要求を開始したユーザーが、再試行 (502/504) に遭遇する可能性があることを除いて99% のユーザーは、バックグラウンドが「生死の時速」の機械室レベルの災害を経験したことを全く感じていない。
五、ピット回避ガイド: 設計者がよく犯している三つの致命的なミス
実際にこの枠組みを着地したとき、大量の転覆事例に基づいて、私は以下の三つの最も無視されやすい暗礁をまとめた
1.AZを越えた伝送料金
AWSのインバウンドトラフィック (インターネットから入ってきた) は無料ですが、同じRegion内では
トラフィックが異なるAZを越えて伝送するには料金がかかります
(通常は $0.01/GB)。
もしあなたのマイクロサービスが壊れすぎて、サービスA(AZ-A) が頻繁にRPCを介してサービスB(AZ-B) を呼び出し、月末になると、非常に恐ろしいインターネット請求書を受け取ります。
最適化案: できるだけトラフィックを同じAZ内でイントラネットの閉ループを完成させ、災害復旧時にのみAZにまたがる。
2.データベース「脳裂」と同期遅延
RDS Multi-AZは同期レプリケーションで、パフォーマンスは非常に優れていますが、自分で構築した自己構築データベースクラスタ (例えば、自分のハードコア魔改のMySQL MHA) であればAZネットワークを越えてジッタすると、両方のノードが自分がメインライブラリだと思っている「脳みそ」現象が起こりやすく、データの書き込みが乱れてしまう。
最適化案: 専門的なことは専門的な道具に任せ、生産環境が強い
RDSまたはオーロラを優先的に使用して、基本的な分散整合性の問題をAWSに任せて解決することをお勧めします。
3.テストを忘れた: 紙の高さは高さではない
多くのチームは完璧に設計されていますが、オンラインでは3年間、災害対策の練習をしたことがありません。結果が実際に故障したとき、コードにデータベースIPが書かれていないか、セキュリティグループが別のAZのネットワークセグメントを解放するのを忘れていることがわかった。
最適化案:定期的にチャオス・エンジニアリングを実行する。低ピーク期には、RDSコンソールに手動で「フェイバーバー」をクリックするか、意図的に1つのAZのすべてのEC2をオフにして、システムが予想通りに自己治癒できるかどうかを見てみましょう。
結語
雲の原生時代には
災害を許すのは高価で面倒な体力活動ではなく、設計直感であるべきだ。
を介して
ELBのスマート配布
、
Auto Scalingの無状態自己治癒
および
RDSのAZ間同期レプリケーション
結合して、我々はいくつかの標準的なアマゾンクラウド国際駅サービスだけで、機械室レベルの災害を防ぐのに十分な鉄鋼構造を構築した。
高可用性の最高の境地は、故障が決して起こらないことを守るのではないことを覚えておいてください故障が予定通りに到着したとき、あなたのシステムは軽く揺れただけで、風雨の中で着実に進んでいる。