AWSアマゾンクラウドディーラー: AWSマルチ空きエリア (マルチ空きエリア) と地域間の自動災害準備アーキテクチャの設定を教えてくれます。

技術をしている友人は「すべて失敗するのは時間の問題だ」という言葉を聞いたことがあるはずだ

クラウドアーキテクチャでは、すべての卵を一つのかごに入れることが最大のタブーである。多くのチームは、ビジネスをAWS (アマゾンクラウドテクノロジー) に移すと万事順調になったと思っていた。その結果、ある利用可能エリア (AZ) の光ケーブルが切れたり、極端な天気で地域全体が切れたりしたサービスが一瞬ダウンしました。この時、「高可用性」とは、正しく配置されていない枠組みの前で冗談であることがわかりました。

今日私たちは虚しい概念を話さず、公式文書を暗記しない。あなたのAWSアカウントを用意して、私たちは直接ハードコアのドライ商品に乗って、ハンドルを持ってあなたを配置します

「同地域の複数利用可能エリア (Multi-AZ) の高可用性」と「クロス地域間の自動災害対策」を両立するインターネットの黄金構造

。

第一段階: 同地域の多くの利用可能な地域 (Multi-AZ): 単点故障の炎を絞めて消す

「利用可能ゾーン」はAWSの中核概念である。ある地域 (オレゴンなど)

Us-ウェスト-2

) には、複数の使用可能なゾーン (例:

Us-west-2a

、

Us-west-2b

) 、各使用可能エリア間の物理的な隔離 (独立した電力供給、冷却、ネットワーク) がありますが、それらの間には超高速の光ファイバ相互接続があります。

私たちの最初の目標は

いずれかの利用可能エリアが完全に麻痺していても、残りの利用可能エリアは秒レベルで業務を引き継ぐことができ、ユーザーは全く感じられない。

1. VPCとサブネットの微細化設計

これは土台です。すべてのサーバをサブネットに投げ込むことはできません。

標準操作: あなたのVPCで、少なくとも2つの異なる空きエリア (AZ-AやAZ-Bなど) を選択します。

各使用可能エリアには、それぞれパブリックサブネット (ロードバランサ) とプライベートサブネット (EC2ビジネスサーバとデータベース) が構築されています。このようにして、あなたは4つのサブネットを持って、自然に交差防御を形成した。

2.計算層: ALB負荷分散Auto Scaling (自動伸縮グループ)

ユーザーアプリケーションにEC2のパブリックネットワークIPを直接バインドしないでください。

A p p a t i o n Load Balancer (ALB) を作成し、2つの空き領域のパブリックサブネットにマウントします。ALBはゲートになり、トラフィックが入ってくると、バックエンドのサーバに要求を均等に配布します。

Auto Scalingグループ (ASG) を作成します。テンプレートを起動してビジネス・ミラーを選択します。重要な構成: ネットワーク選択時に、2つの使用可能なゾーンのプライベートサブネットをすべてチェックします。設定に必要な容量は2です (普段は2台の機械が走っていることを意味します)。基本的なロジック: AWSは、AZ-AとAZ-BでEC2を1台ずつ起動します。ある日突然故障しAZ-A機器がハングアップした場合

ASGはすぐに感知して、健康なAZ-Bに自動的に新しい機械を引き上げて補充して、ALBに協力して自動的に死んだ機械を取り除いて、全過程自動化します。

3.データ層: RDSデータベースのワンキーMulti-AZ

サーバーがハングアップしたら勝手に再起動できます。データがハングアップしたり、混乱したりしたら、会社は直接出席します。

AWS RDS (MySQLなど) を作成するときに、「マルチゾーン導入」というゴールドスイッチがあり、ためらうことなくチェックします。

運用内部者: AWSは、プライマリ・可用性エリア (AZ-A) にプライマリ・ライブラリを作成すると同時に、プライマリ・可用性エリア (AZ-B) に完全に同期されたミラー・ライブラリを作成します。マスターライブラリに書き込まれたすべてのデータは、ブロックレベルでリアルタイムでバックアップライブラリに同期されます。

AZ-A災害が発生すると、RDSは自動的にフェイルオーバーを開始し、バックアップをメインライブラリにし、データベースの接続ドメイン名(Endpoint) を新しいメインライブラリに自動的に解析します。あなたのバックエンドコードはipアドレスの行を変更する必要はなく、通常は30秒以内に自動的に復活します。

第二段階: クロスゾーン災害準備 -- 千里の外で敵を防御する

多くの利用可能な地域を完成して、あなたのシステムはすでに99% の日常的な物理的障害を免疫できるようになった。しかし、地域全体のネットワーク麻痺、政策コンプライアンス騒動などの大地震レベルの災害に遭遇したら?導入が必要です

クロスゾーン自動災害対策

。

次のことを仮定します

生産地域は東京 (ap-northeast-1) にあり、災害復旧地域はシンガポール (ap-southeast-1) にある。

1.データの地域間レプリケーション

東京のデータをリアルタイムでシンガポールに同期しなければならない。

データベースレベル: 東京のRDSメインライブラリで、「操作」-> 「地域間の読み取り専用コピーを作成」をクリックし、地域がシンガポールを選択します。AWSはその世界的なバックボーンネットワークを利用して、東京のデータをシンガポールに非同期的にコピーする。

ファイルストレージレベル: S3バケットにユーザーの画像やファイルを保存している場合は、バケットの「地域間レプリケーション (CRR、クロス・地域間レプリケーション) 」機能をオンにします東京バレルの書類を自動的にシンガポールバレルに飛ばします。

2.災害準備地域 (シンガポール) のインフラ設備

シンガポール地域では、VPC、ALB、Auto Scalingグループも導入されています。

お金を節約する奥の手: 普段はお金を節約するためにシンガポールのAuto Scalingグループの「最小容量」と「希望容量」を0に設定できます。この時、シンガポールは多額のEC2計算費用を発生していない

安価なストレージ料金とデータベース同期料金しかありません。

3.魂指揮官: ルート53インテリジェントルートとフェイルオーバー

どうやって災害発生時に、世界中のユーザーのトラフィックを東京からワンクリックでシンガポールに切り替えるのか?AWSのDNSサービスが必要です

ルート53

。

ルート53で、あなたのサイトのドメイン名 (api.yourcompany.comなど) に「フェイルオーバルーティングポリシー」を設定します。

2つの記録を設定します。主記録 (きみ): 東京へのALB負荷分散器。副記録: シンガポールのALB負荷分散器を指す。

ヘルスチェック: 東京のALBにルート53ヘルスチェックをつけて、AWSルートが10秒ごとに東京のホームページを探知するようにします。

災害演習ロジック: 東京のRegion全体が爆発すれば、ルート53の健康診断は何度も失敗した後に赤信号を点灯する。それは瞬時に溶断メカニズムを起動して、直接ドメイン名の解析をシンガポールのALBに切ります。

第三段階: 災害発生時の実際の現場復活プロセス

東京Regionが本当に連絡を失ったと、Route 53は自動的にシンガポールに流量を持ってきた。この時、運送業者は最後の2段階の「権利を引き出す」動作を実行するだけで、システムは完全に生産を再開できる

データベースの権利を高める: シンガポールのAWSコンソールにログインし、東京から同期された読み取り専用コピーを選択し、「スタンドアロンデータベースに昇格」をクリックします。数分以内に東京との同期リンクを切断し、読み取り可能な標準的なメインライブラリになります。

計算層がワンクリックで目覚めた: シンガポールのAuto Scalingグループの期待容量を0から必要な生産数量 (例えば10) に変更する。数分以内に、大量のEC2サーバがシンガポールのその場で立ち上がって、アップグレードされた新しいデータベースを自動的に読み取る。

トラフィックが入ってきて、サーバーが接続できて、データベースが読み書きできる。これは普通の会社を破産させるのに十分な地域レベルの災害で、あなたの正確な枠組みの下でクライアントのわずか数十秒のロード遅延にしかなっていません。

第四段階: 高可用性アーキテクチャのコストとピット血涙歴

利用可能な地域間のトラフィック料金 (Data Transfer Fee):AWSは、同じVPC内の利用可能な地域間でデータを転送するには料金がかかると規定しています (安いですが)。そのため、フロントエンドEC2とバックエンドのイントラネットサービスを同じAZ内で対話させるようにしてください。データベース同期、または分散クラスタノード同期を行う場合にのみ、AZトラフィックにまたがる。

RPOとRTOのトレードオフ: RPO (データがどの時点に回復できるか): 地域間データベースが「異なる」からです

「ステップコピー」は、東京が倒れた瞬間、一、二秒のデータがシンガポールに届いていない可能性があり、この部分のデータは一時的に滞在する。企業はデータ帳簿の準備をしなければならない。RTO (回復にどれくらいの時間がかかるか): 本稿の枠組みを利用して、微量の人工介入を自動化し、RTOを5分から15分以内にコントロールできる。

定期的に破壊する (カオス工事):高可用性構造は「配合が終わったらそこに置いて灰を食べる」ことを最も嫌う。多くの会社は地域を越えた災害準備をしていて、3年も動いていない。4年目に事故が起きた時、シンガポールの鏡像はとっくに期限が切れていないことを発見した。半年ごとに週末の朝を選んで、ルート53を災害準備地域に手動でカットして、本当のネット切断訓練をすることをお勧めします。

まとめ

ゼロ単点故障は運ではなく、科学的な枠組みで設計されている。

同地域の多くの利用可能な地域で解決したのは「高可用性 (HA) 」で、日常的に中断しないことを保証している地域間の自動災害復旧は「災害復旧 (DR) 」である極端な状況で会社が生きられることを保証する。

この2つの防御線をあなたのAWSアカウントに溶接して死んで、それ以来、外部のインターネットの風波がどんなに大きくても、あなたはコンピューターの前に座って、泰山のように安定している。