WATARU
今回の記事はこんな方におすすめです。
お悩みさん
・AWSで冗長化ってどうすればいいの？
という悩みがあったので調査した内容をこのブログに記事として残しておきます。
私と同じようにAWSの冗長化というキーワードで悩んでいる方がいれば、参考になると思いますので是非読んで行ってください。
<この記事をざっくり解説！>
この記事はワタルの備忘録です。AWSの冗長化について記事を書いていきます。
この記事を信頼してもいい理由
記事を書いている人が・・・
・現役のAWSエンジニア
・冗長化を意識したシステム構成のデザイン経験あり
今回解説する内容
・冗長化とは
・AWSでの冗長化とは
・様々な冗長化の種類
この記事を読んでいる方の中には
・AWSはあんまり触ったことが無いが冗長化を意識したシステム構成の依頼を受けた
・障害対策について調査依頼を受けた
という方もいるのではないでしょうか。
この記事はAWSを使っているエンジニアが備忘録として書いていることを前提としてご自身の悩みの解決にお役立ていただければと思います。
結論：Availability Zone間での冗長化がお手頃でおすすめです。
結論として最低限「Availability Zone（以降、AZ）間での冗長化」をしておくことをおすすめします。
AZは同じリージョン内にある別々の施設のことを指します。
そのため東京リージョンのAZ-AとAZ-Cで冗長化ということであれば、東京近辺にあるAWSの別々の施設間で冗長化で実現することが可能です。
AWSシステムを冗長化する方法としては「マルチクラウド」「マルチリージョン」「マルチAZ」という方式があるので、システムの規模や要件によって対策方法を検討した方が良いと思います。
ただし、冒頭にも申し上げた通り、最低限AZ間での冗長化をおすすめいたします。
冗長化とは
冗長化（じょうちょうか）とは一体なに？と思っている方もこの記事を読んでいただいている方の中にいるのではないでしょうか。
ということで、この章では「冗長化とは」ということをテーマに解説していきます。
冗長化とは
冗長化とは「システム障害に備え、障害が発生し時にもシステムが稼働し続けされるようにしておくこと」を言います。
冗長化とは、機器やシステムの構成要素について、同じ機能や役割の要素をあらかじめ複数用意しておき、異状が発生した時に肩代わりできるよう待機させておくこと。一部の機能が損なわれてもシステム全体が停止することを防ぎ、運用を継続することができる。
引用：e-Words
一般的には「バックアップ」や「予備機」などという方がイメージが付きやすいかも入れません。
冗長化をすることで、システムの負荷分散を実現できたり、障害発生時にシステム障害時の機会損失を最小限にすることが可能です。
なぜ必要なのか
冗長化はシステムによるサービスを提供している企業の企業活動の停止を防ぐために必要不可欠です、また負荷分散の観点でも有効に働きます。
システムが冗長化されていない場合、機器のトラブルや地震や火災などの自然災害などによる事業活動の停止が発生する可能性があります、その可能性（リスク）に備えるためにも冗長化は必要なのです。
上記に記載した機器のトラブルと自然災害に対する対策として、冗長化構成の場合、機器は物理的に離れた位置にある必要があります。
一つのサーバは東日本、一つは西日本、合計二つのサーバでシステムを運営していき東日本で災害があった場合は西日本のサーバが稼働し続けサービスを提供し続けることが可能です。
サービスの提供が継続的に可能である場合、企業は企業活動を続けることができますし、大手になればなるほどサービスが停止した時の機会損失は大きいですから、なるべく停止しないシステム構成、すなわち冗長化を意識する必要があるのです。
冗長化の構成
冗長化の構成は以下であるケースが多いです。
・アクティブ・スタンバイ構成
・アクティブ・アクティブ構成
アクティブ・スタンバイ構成は、アクティブなサーバ（稼働系）が常に処理をしていて、有事の際にスタンバイしているサーバ（待機系）に切替を実施し、企業活動を継続する構成。
アクティブ・アクティブ構成は、全てのサーバが常に稼働しており、有事の際には停止していないサーバがサービスを提供し続けている構成、障害対策の他にも負荷分散としても有効な構成。
AWSでは基本的にアクティブ・アクティブ構成になることが多いです。
AWSにおける冗長化とは
冗長化というものがどういったことなのかはなんとなく理解できたところで、冗長化をAWSで行うとどういうことになるのかをこの章では解説していきます。
リージョンで冗長化
AWSは別リージョンでシステムを冗長化することが可能です。
一般的には複数リージョンでシステムを構成していることを「マルチリージョン構成」と言います。
「リージョン」とはAWSのデータセンター施設がある地域（都市）のことを指します。
具体的には、東京リージョンやバージニア北部リージョンなど大規模な分類になります。
AWSのデータセンター施設にまたがってシステムを構成することで、片方の施設が何等かの被害にあった時にもシステムを稼働させ続けることが可能です。
しかし、複数リージョンでシステムを構成すると、単一リージョンで構成するよりも多くの費用が掛かるため、相当な大規模システムではない限りこの構成にすることは無いと思います。
アベイラビリティゾーンで冗長化
AWSは複数のアベイラビリティゾーン（以降AZ）でシステムを冗長化することが可能です。
一般的には複数のAZでシステムを構成している状態を「マルチAZ構成」と言います。
「AZ」とはリージョンより小さな区分で構成されている独立したデータセンターのことを指します。
具体的には東京リージョンの「AZ-A」「AZ-C」などと表現されています。
独立したデータセンターではありますがアベイラビリティゾーンよりかは物理的な距離が短いため通信のコストやレイテンシを抑えることが可能です。
一般的なシステムで冗長化構成をとる場合はこのAZで冗長化を実現するのが一般的だと思います。
様々な冗長化
ここからは具体的にAWSで冗長化をしていく場合はどのような構成になるのかを解説していきます。
マルチリージョン（リージョンで冗長化）
マルチリージョンはRoute53のヘルスチェック機能を使用することで実現が可能です。
具体的には、Route53のヘルスチェック機能を使用しプライマリシステム（メインで使用している方）のシステム用ヘルスチェック用パスを監視します。
対象のプライマリシステムがヘルスチェックが失敗した場合にプライマリシステムへの通信を辞め、セカンダリシステム（別リージョンで作っている待機系）に通信先を自動変更します。
Route53のヘルスチェック機能を使用することで別リージョンを使用しての冗長化を組むことができます。
肝となるキーワードは「Route53,ヘルスチェック機能,マルチリージョン」といったところでしょうか。
マルチAZ（AZで冗長化）
マルチAZは各AZで作成したSubnetに対してELB（Elastic Load Balancing）による振り分けを行うことで実現が可能です。
具体的にはELBのターゲットに各AZに存在するエンドポイント（終端となる機器）を指定し継続的なヘルスチェックによる死活監視を行います。
一方のターゲットのエンドポイントに異常が発生した場合に、正常に戻るまではヘルスチェックに成功しているAZのエンドポイントにしか通信を送らないようにすることが可能です。
マルチAZによるシステムの冗長化を実現するためには、各AZでSubnetの作成およびサーバ（またはコンテナ）を用意しておく必要があります。
肝となるキーワードは「マルチAZ,ELB,ヘルスチェック」といったところでしょうか。
ELBには、HTTP/HTTPS リクエストの負荷分散が可能なALBとTCP/UDPトラフィックの負荷分散が可能なNLBが存在しますので、用途に合ったELBを選択するようにしましょう。
マルチクラウド（Cloudサービスで冗長化）
マルチクラウドは別のクラウドシステムとVPNの機能を使用して連携することでフェイルオーバーが可能です。
具体的には、AWSのVPN connectionというサービスを使用することでオンプレミスおよび別のパブリッククラウドサービス（GCPやAzure）と連携をします。
お互いのシステムを連携するにはAWS及び別のパブリッククラウドサービスのパブリックIP（グローバルIP）が必要です。
注意点としては、単純な設定で連携ができるようですが、注意すべき詳細な設定があるためネットワーク関連の知見がある方の意見を聞きつつ対応を進めた方が良いでしょう。
※ちなみに僕は全然理解できてません（笑）
まとめ：最低限AZ間での冗長化はしておく
今回も最後まで読んでいただきありがとうございました。
備忘録としてまとめてみましたが、やはり「最低限AZ間での冗長化をしておく」方がよいと思いました。
勘違いされがちですが、クラウドは復旧や障害対策についてかなり優秀ですがシステム自体が壊れないというわけではありません。
しっかりとした障害対策（AWS の冗長化）を構成として取り入れておくべきでしょう。
今回の話が全然理解できなかったという方はUdemyでの学習をおすすめします。
是非以下の記事を参考にしてみてくださいね。
【現役エンジニアが解説】Udemyのおすすめ AWS講座 5選
ではまた別の記事でお会いしましょう
