イラストで理解するMultiAZ
はじめに
今回はシンプルなMultiAZ構成での各サービスの役割を勉強していきます。
MultiAZ構成を理解することで、どのように障害や高負荷からシステムを保護しているのかが理解できます。
概要
今回はこのようなシンプルなMultiAZ構成で考えていきます。
今回は皆さんが普段使うショッピングサイトを例に見ていきます。
あなたはショッピングサイトの運営者になった気持ちで一緒に考えてみてください。
あなたが運営するショッピングサイトを障害や高負荷のかかる通信からどのように守ればいいでしょうか。
前提
多少webの通信技術についての理解があると読み進めやすいと思います。
ユーザーからALB
あなたはショッピングサイトをEC2に作成しました。
最小の構成であれば、このままでも運用は可能でしょう。
しかし、これでは障害も高負荷にも耐えられません。
どうしましょう。
簡単です、EC2を増やせばいいのです。
しかし、問題が発生しました。
この場合、ユーザーはどちらのEC2に通信すればよいのか分からなくなります。
ここで活躍するのがELB(Elastic Load Balancer)です。
ELBは通信を複数のEC2に振り分けることができるサービスです。
今回はそんなELBでも、HTTP通信に対応しているALB(Application Load Balancer)を使います。
リスナールール
このALBはいろいろな機能を持っています。
例えば、受ける通信を制限することができます。
これを「リスナールール」と言います。
このリスナールールは、HTTPやHTTPSの通信をどのポートで受け取るかを決めるルールです。
さらにこのルールで受け取った通信に対して特定のアクションを起こすことも可能です。
よくあるアクションはHTTPの通信をHTTPSにリダイレクトするというものがあります。
ALBにはAWSが生成したSSL証明書を持たせることができます。
これを利用してよりセキュアなHTTPS通信ができます。
ALBからEC2
ターゲットグループ
次に、ALBは受け取った通信を「ターゲットグループ」に振り分けます。
ターゲットグループはALBが通信を送る宛先です。
基本的にこの通信は均等に割り振られますが、設定によって重みを変えることも可能です。
通信はターゲットグループ内に登録されたターゲット(今回はEC2)に送信されます。
ちなみに、ターゲットグループには複数のEC2がターゲットとして登録されていることもあります。
上の図ではALBからEC2への通信がHTTPになっています。
ターゲットへの通信はHTTPで行うことが多いです。
ALBまでの通信をHTTPSにすることで、外からの通信は暗号化されています。
ALB以降の内側の通信ではHTTPを使うことで暗号化等の余計な処理による通信速度の低下が回避できます。
ヘルスチェック
さらに、ALBは定期的にターゲットへ通信を行い、ショッピングサイトが起動しているか？
ということを確認します。
これを「ヘルスチェック」と言います。
EC2が何らかのトラブルによりダウンして、ALBのヘルスチェックが通らないことがあります。
その場合、ALBは正常に動作しているEC2に通信を転送します。
AutoScalling
これでやっとユーザーはショッピングサイトが動いているEC2へ辿り着きました。
しかし、ここで問題が発生しました。
あなたのショッピングサイトでスーパー激安セールを行うことに決まりました。
セール時はどのくらいのユーザーがアクセスしてくるか予想できません。
2倍か、10倍か、はたまた100倍か。
さて、どうしましょう。
簡単です、EC2をたくさん用意しておけばいいのです。
しかし、これは非常に効率が悪いです。
EC2を増やす手間、セール後にEC2を終了させる手間、コスト。
面倒な作業がたくさんあります。
ここで、AutoScallingとうい便利な機能を使います。
そのまま読んで字のごとく、「自動でスケーリング」です。
この機能を使うことで、EC2のCPU使用率などのメトリクスに基づいたスケーリングや、予定した時間にスケーリングすることが可能になります。
もちろん使用率が低い時に最小数で稼働させることも可能です。
ALBとAutoScalling
AutoScallingはALBと組み合わせて使うことが多いです。
直前に配置しているALBのターゲットグループをAutoScalling Groupに向けることができます。
そのため、EC2が増減しても自動で通信を振り分けてくれます。
さらに、AutoScalling GroupはAZ(アベイラビリティゾーン)を跨いで設定することができます。
そのため、ALBとAutoScalling Groupを組み合わせることで、障害や高負荷に対応することができます。
先ほどALBの説明に出てきたヘルスチェックという機能がありました。
ALBがAutoScalling Group内のEC2がヘルスチェックで正常でないと判断した場合、
自動的に対象のEC2を終了して、新たにEC2を立ち上げることも可能です。
EC2からRDS
アプリケーションまでの障害対策、高負荷対策が分かりました。
次はショッピングサイトのデータです。
例えば商品情報です。
これはアプリケーションと同じEC2で管理することも可能です。
しかし、EC2はユーザーからのリクエストを処理したり、データの登録処理を行ったりと大忙しです。
サイトの規模が大きくなるにつれEC2だけでは処理するのが難しくなります。
そこで、データは別のデータベースシステムに登録しましょう。
今回はRDSというRDBMS(Relational Database Management System)を使います。
RDSは一般的なデータベースシステムであるMySqlやPosgreSQLなどをサポートしています。
さらに、MultiAZ構成に対応した対障害機能を持っています。
RDSには通常運転時にデータを登録する「Primary」と
Primaryに登録されたデータを同期的にレプリケートする「Standby」があります。
StandbyはPrimaryとは別のAZに配置します。
そうすることでPrimaryの障害時にStandbyに切り替えて運用することができます。
フェイルオーバー
では、もう少し詳しく障害時の切り替え(フェイルオーバー)を見ていきます。
まずは、通常運転時のデータ登録を理解します。
EC2からのデータはRDSのエンドポイントに向けて送られます。
このエンドポイントはAWSのDNSにより、RDSのIPアドレスと紐付けられています。
ということは、EC2から見たエンドポイントは一つということになります。
障害時は対応するIPアドレスのみを変更すれば良いということですね。
このDNSのIPアドレスの書き換えはRDSの障害時にAWSが自動で行ってくれます。
ショッピングサイトの運営者であるあなたは、特に意識することなく
自動でフェイルオーバーが実行されるということですね。
このようにして、販売する商品のデータや
登録されているユーザーのデータを障害から守る仕組みが整えられています。
まとめ
今回はMultiAZ構成全体のサービスの特徴を書きました。
これらの仕組みは、それぞれが独立しているわけではなく他のサービスと連携することで真価が発揮されるものが多いです。
システムの冗長性を確保するだけではなく、
手動で行なった場合に比べてコスト面でのメリットもあります。
今回学習をする中で、フェイルオーバーの条件など細かい仕様も勉強することができました。
細かい数字は忘れると思いますが、こういう制限があったな〜と思い出すきっかけにはなると思います。
Discussion