見出し画像

AWS インフラ設計の基本を理解する

kasa

1.概要

本記事では、AWS初学者がAWSのインフラ設計を理解するために必要な基礎知識を解説します。

具体的には下記について解説していきます。

・AWSのコアコンセプト（枠となる概念）
・マルチAvailability Zone構成
・AWSの基本的なネットワーク構成

また、少し細かい話は補足として記載しています。

2. AWSのコアコンセプトを理解する

AWSの設計原則の１つに「Design for Failure」（障害が起きることを前提に設計せよ）というものがあります。

サーバーないしデータセンターが丸ごと動かなくなったとしても、システムが稼働し続けられるアーキテクチャを求められているわけです。

しかし、それを実現するにはもちろんコストがかかります。

つまり、AWS設計においては可用性とコストのトレードオフを常に意識しなければなりません。

その上で一つキーワードを上げるとするならば、

マルチAvailability Zone(AZ)構成

です。

下記の表を見てください（AZやリージョンについては後述します）。

AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ

取り敢えず、「マルチAZ」が低コストかつ高可用性を実現可能で、まず第一にこの構成で設計を考えるべきだということを頭に入れておいてください。

このように、ある結果を得るのに最も効率のよい手法を

ベストプラクティス

といいます。一般的なIT用語ですが、AWS界隈では特に耳にする用語なので覚えておきましょう。

2.1. AWSロケーションについて

それでは、「AZ」や「リージョン」といった用語について見ていきます。

AZ、リージョンはともにロケーションを表すAWSのコアコンセプトです。AWSロケーションは大きく下表の3つに分けられます。

あくまでコンセプト（概念）なので、実体はすべてデータセンターです。

AZが２つ以上のデータセンターで構成された単位のことで、それを地域でまとめたものがリージョンです（下図のイメージ）。

画像6

リージョンとAZを理解した今、マルチAZ構成がなぜベストプラクティスなのかは容易に想像できると思います。

リージョンが全滅するような事態は稀でしょうし、そんな状況下でも稼働し続けなければならないシステムはそうそうないはずです。
ただ、AZ単体での障害はこれまで発生してきているので、可用性を求められるシステムではマルチAZ構成は必須といえます。

補足：AWS障害情報

補足：AWS SLA（サービスレベルアグリーメント）

各サービス、各構成において保証されるサービスレベルを確認できます。シングルAZとマルチAZの場合を比較する資料として大変有益です。

2.2 AWSサービスについて

ロケーションの次は、それに対応するサービスを見ていきます。

図示するまでもないでしょうが、こんな感じ。

画像6

AZサービス

AZサービスはその名の通り、AZに配置されるサービスです。すなわち、高可用性を求める場合は我々ユーザー側でマルチAZ構成にする必要があるということです。

次章以降、マルチAZ構成の具体例を見ていきます。

リージョンサービス

では、リージョンサービスはどうでしょうか。2つの例を見てみましょう。

例１：Lambda (注1)

引用元：AWS Lambda の耐障害性
高可用性 – Lambda は、複数のアベイラビリティーゾーンで関数を実行し、1 つのゾーンでサービスの中断が発生した場合にも、関数をイベントの処理に使用できることを保証します。

例２：DynamoDB

引用元：Amazon DynamoDB とは
AWS リージョン内の複数のアベイラビリティーゾーン間で自動的にレプリケートするため、組み込みの高い可用性とデータ堅牢性が実現します。

つまり、リージョンサービスは勝手にマルチAZ構成となっていて、我々ユーザーは何も考えなくてよいということですね（ありがたい！）。

これは、リージョンとAZの概念が頭に入っていれば容易に想像できたと思います。

注1：LambdaはVPC内にも配置でき、その場合はマルチAZにすべきです

補足：グローバルサービス

グローバルサービスの冗長化については不要（不可能）、もしくはAWSの範囲に収まりません。

例えば、CloudFrontのSPOF(単一障害点)を解消するためには、障害発生時に別のCDNサービスに切り替えるような仕組みが必要です。

余談ですが、先日CDNサービスのFastlyに障害が発生した際、Amazonは即座にAkamaiやCloudFrontに切り替わり、一部エンジニア界隈で流石だと称賛されていました。

取り敢えず、高レベルなお話になってくるので、実務で求められることは少ないと思います。

3. AWSの基本的なネットワーク構成を理解する

インフラを設計する上でネットワークの知識は必須です。

AWSのネットワーク周りの専門用語と共にマルチAZで構成されるサンプルを見ていきましょう。

3.1. VPC

AWS上での仮想ネットワーク空間です。

IPアドレスの割り当てが行えるリソースは、VPCの中に構築していくことになります。また、VPCはリージョンサービスです。

よって、リージョンとAZの関係にVPCを加えると下図のようになります。

画像6

3.2. サブネット

サブネットはVPCのネットワークセグメントです。
AWSではこのセグメントをAZごとに配置します。
サーバーなどのリソースはサブネット上に配置していきます。

画像6

また、サブネットは下記の２つに分けられます。

3.2.1. パブリックサブネット

パブリックサブネットを追加すると下図の様になります。

画像6

新しく出てきたコンポーネントについてまとめます。

補足：ルートテーブル

・送信先：VPC CIDR
・ターゲット：local

はデフォルトで設定されるローカルルートです。例えば、VPC CIDRが「10.0.0.0/16」の場合、サブネット内で「10.0.x.x」のIPアドレスが指定されたときにVPC内の通信を可能にします。

・送信先：0.0.0.0/0
・ターゲット：IGW

「0.0.0.0/0」はデフォルトルートといいます。自分が知らない経路は、デフォルトルートに送信します。要するにこの場合、ルートテーブルに存在しない宛先へのパケットはすべてIGWに送信するということです。

3.2.2. プライベートサブネット

プライベートサブネットを考える上で、「NATゲートウェイ（NAT-GW）」というコンポーネントが重要になってきます。

インターネットからのインバウンドを拒否し、アウトバウンドだけを許可したい場合、、、簡単に言うと、インターネットからはアクセスされたくないけど、インターネットへはアクセスしたい場合、NAT-GWを使用します。

NAT-GWをパブリックサブネットに配置し、プライベートサブネットのルートテーブルにNAT-GWへのルーティングを追加します。

プライベートサブネットに配置したEC2からインターネットへアクセスしたい場合、下図のイメージになります。

画像7

IGWとNAT-GWはともにネットワークアドレス変換 (NAT) の役割を担うコンポーネントです。違いを比較して詳しく見てみましょう。

アドレス変換の違いがそれぞれの役割を決定づけている部分になります。
非常に分かりやすい記事を見つけたので、気になる方は下記をチェックしてみてください。

AZ障害の影響についてはここまでの内容を理解できていれば簡単ですね。先程の図を見てもらうと、IGWはAZ外です。AWS側でよろしくやってくれているわけですね。構成図にIGWが1つしかないので、SPOFになるのではないかと心配した人もいるかもしれませんが、無問題です。

料金については、NAT-GWは起動した時間分の料金が発生するので注意が必要です。

以上、IGWおよびNAT-GWへのルーティング有無でサブネットを分類すると、下表の様になります。

3.3. マルチAZ構成のサンプル

最後に、より実践的な構成図を載せて終了とします。ここまで読んできた内容で大体理解できるのではないでしょうか。

画像7

補足：ELB

リージョンサービスのイメージを持っている方が多いかもしれませんが、ELBはAZサービスです。ELB作成時にはアタッチするサブネット（AZ）を最低２つは指定する必要があるので、強制的にマルチAZ構成になります（構成図には1つだけ描くのが一般的です）。

2019年8月23日に発生した東京リージョン障害では、この「最低２つ」が仇となり、障害の発生した方のELBを切り離せなかったという報告もあります。

補足：RDSのマルチAZ構成

引用元：Amazon RDS マルチ AZ 配置
マルチ AZ DB インスタンスをプロビジョニングすると、Amazon RDS によってプライマリ DB インスタンスが自動的に作成されると同時に、異なるアベイラビリティーゾーン (AZ) のスタンバイインスタンスにデータが複製されます。各アベイラビリティーゾーンは、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼働しています。また高い信頼性を保つように設計されています。インフラストラクチャ障害の場合、Amazon RDS はスタンバイ (Amazon Aurora の場合はリードレプリカ) に自動的にフェイルオーバーするので、フェイルオーバーが完了するとすぐにデータベースの動作を再開できます。フェイルオーバー後も DB インスタンスのエンドポイントは変わらないため、お客様のアプリケーションは、手動で管理の介入を行うことなくデータベースオペレーションを再開できます。

4. まとめ

１．AWSのコアコンセプト（リージョン、AZ）を学びました。
２．高可用性のベストプラクティスであるマルチAZについて学びました。
３．インフラ設計に欠かせないAWSのネットワークについて学びました。

以上、「役に立ったよ！」という方は♡ボタンをクリックお願いします！

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