372-AWS SAP AWS 「理論・実践・一問道場」53→cloudfront→Health check

type

status

date

slug

summary

理論

1. Amazon Route 53とフェイルオーバー

Amazon Route 53は、クラウドベースのDNSサービスです。特に、フェイルオーバールーティングポリシーは、プライマリリージョンで障害が発生した場合にバックアップのDR（ディザスタリカバリ）リージョンにトラフィックを自動的にルーティングするために使用されます。

ヘルスチェックを使って、バックエンドサービスの健康状態を監視し、正常でない場合にトラフィックをバックアップリージョンに送ることができます。

TTL（Time to Live）: DNSキャッシュの有効期限を短く設定することで、フェイルオーバーが早く反映されますが、過度に短いTTLはDNSサーバーへの負荷が増加するため、適切な設定が必要です。

2. Amazon CloudFrontとオリジングループ

CloudFrontは、グローバルにコンテンツをキャッシュし、ユーザーに近い場所から提供するCDN（コンテンツデリバリーネットワーク）です。CloudFrontは、オリジン（バックエンドサーバ）からコンテンツを配信します。

オリジングループを使用すると、CloudFrontは複数のオリジンを設定し、障害発生時に自動で別のオリジンに切り替えることができます。これにより、バックエンドの障害が発生しても、ユーザーへのサービスが途切れることなく提供されます。

キャッシュビヘイビアは、CloudFrontがオリジンからコンテンツを取得する方法やキャッシュの設定を制御します。オリジンフェイルオーバーを設定することで、1つのオリジンが失敗した際に別のオリジンからコンテンツを取得することができます。

3. フェイルオーバーを最速で実現するための最適化

フェイルオーバーのスピードを向上させるためには、以下の点が重要です。

CloudFrontオリジングループの利用: 複数のバックエンドサービスをオリジングループとして設定し、キャッシュビヘイビアでオリジンフェイルオーバーを活用することで、フェイルオーバー時間を最小化できます。

Route 53 TTLの短縮: TTLの設定を短くすることで、DNSが迅速に新しいエンドポイントを反映し、ダウンタイムを減らせます。ただし、TTLを短くしすぎると、DNSのクエリ数が増加する可能性があるので、適切なバランスが必要です。

4. レイテンシールーティングとオリジンの選択

レイテンシールーティングポリシーを使うことで、最も近いリージョンのバックエンドにトラフィックをルーティングすることができます。これにより、パフォーマンスが向上しますが、フェイルオーバーの速度には影響を与えません。

まとめ

この問題に関連する知識として、CloudFrontのオリジングループやRoute 53のフェイルオーバーポリシーを利用することで、高速なフェイルオーバーを実現できます。具体的には、オリジンフェイルオーバーやキャッシュビヘイビアの設定を活用することが、最適な結果をもたらします。

実践

【やってみた】Sorryページを「CloudFront オリジンフェイルオーバー」で実装してみた - サーバーワークスエンジニアブログ

こんにちは。ES課研修中の田原です。前回Route53 フェイルオーバールーティングのSorryページ実装をご紹介したブログに続いて、もう一つの代表的なSorryページ構成の「CloudFront オリジンフェイルオーバー」での実装方式を本ブログでご紹介いたします。 ※2024/10時点の構築手順となります。アップデ…

https://blog.serverworks.co.jp/2024/10/09/162457

一問道場

問題 #372

ある会社が多くの訪問者を持つウェブサイトを運営しています。この会社は、ウェブサイトのバックエンドサービスを主要な AWS リージョンと災害復旧（DR）リージョンにデプロイしています。

会社はウェブサイト用に単一の Amazon CloudFront ディストリビューションを使用しています。会社は、主要リージョンのバックエンドサービスに対してヘルスチェックを行い、フェイルオーバールーティングポリシーを使って Amazon Route 53 のレコードセットを作成します。

そのレコードセットは CloudFront のオリジンとして設定されています。会社は、DR リージョンのバックエンドサービスのエンドポイントを指す別のレコードセットを作成し、これをセカンダリのフェイルオーバーレコードとして設定します。

両方のレコードセットの TTL（キャッシュの生存時間）は 60 秒に設定されています。

現在、フェイルオーバーに 1 分以上かかっています。ソリューションアーキテクトは、最速のフェイルオーバーを実現するための解決策を設計する必要があります。

どのソリューションが最適でしょうか？

A. 追加の CloudFront ディストリビューションをデプロイし、新しい Route 53 フェイルオーバーレコードセットを作成して、両方の CloudFront ディストリビューションにヘルスチェックを設定する。

B. 既存の Route 53 レコードセットの TTL を 4 秒に設定し、各リージョンのバックエンドサービスに適用する。

C. バックエンドサービス用に新しいレコードセットを作成し、遅延ルーティングポリシーを使用して、CloudFront ディストリビューションのオリジンとして設定する。

D. CloudFront オリジングループを作成し、2 つのオリジン（各バックエンドサービスリージョン用）を含め、CloudFront ディストリビューションのキャッシュビヘイビアとしてオリジンフェイルオーバーを設定する。

解説

詳細な解説：

このシナリオでは、CloudFrontディストリビューションとRoute 53を使用して、フェイルオーバーを最適化する必要があります。最速のフェイルオーバーを実現するためには、CloudFrontのオリジングループを使用して、複数のバックエンドサービス間で自動的にフェイルオーバーする設定が重要です。

選択肢の解説：

A: 新たにCloudFrontディストリビューションを作成して、Route 53のフェイルオーバーレコードセットを作成する方法です。これにより、冗長性は増しますが、既存のインフラに対する影響を大きくし、設定が複雑になります。既にCloudFrontが導入されているため、この方法は最適ではありません。

B: Route 53のTTLを4秒に設定する方法です。TTLを短くすることでDNSの反映速度は速くなりますが、これだけではCloudFrontディストリビューションがバックエンドをどのように選択するかに関する改善はありません。TTLを短くすることでの影響は限られた範囲にとどまります。

C: レイテンシールーティングポリシーを使用する方法です。この方法は、最適なバックエンドサービスを選択するのに役立ちますが、フェイルオーバーの速度には直接関与しません。フェイルオーバーが目的であるならば、CloudFront内でのオリジン選択の方が優れています。

D: CloudFrontオリジングループを作成し、2つのバックエンドサービス（主要リージョンとDRリージョン）をオリジンとして設定して、CloudFrontのキャッシュビヘイビアとしてオリジンフェイルオーバーを使用する方法です。この方法が最速のフェイルオーバーを実現します。CloudFrontは自動的に障害が発生したオリジンから別のオリジンにリクエストを切り替えるため、フェイルオーバーが即時に行われます。

まとめ：

Dが正解です。CloudFrontオリジングループとオリジンフェイルオーバーを利用することで、最速のフェイルオーバーを実現できます。この方法は、特にバックエンドサービスが複数のリージョンに分散している場合に有効です。

BやCも有効な手法ですが、フェイルオーバーのスピードを最速にするためには、Dの方法が最適です。