Ch5. 新しいソリューションの設計
フロントエンドリスナー
Application Load Balancer 用の HTTPS リスナーを作成する - Elastic Load Balancing
リスナーとは接続リクエストをチェックするプロセスです。
アプリケーションロードバランサに紐付ける、接続を確認するためのプロセスをフロントエンドリスナーと呼ぶ。フロントエンドリスナーにSSL証明書を組み込むことでユーザーとALBの間をHTTPS通信とすることが出来る。
ALBにはホストベースルーティングという機能を使って、複数のドメインに対するアクセスを捌きそれぞれのドメインをホストするターゲットグループ(EC2のクラスタと思えばよい)に対してリクエストをルーティングすることが出来る。
AWS ALBのホストベースルーティング設定について - Clara Online's Blog
ACMの証明書はALBにセットできるが、具体的にはALBのフロントエンドリスナーにインポートするということのようだ。 因みにACMは
で利用できる。EC2には対応していないところに注意する必要がある。
AWS WAF/Sheild
AWS WAF
AWS WAF（ウェブアプリケーションファイアウォール）| AWS
AWS WAF は、CDN ソリューションの一部として Amazon CloudFront にデプロイでき、EC2 上で動作するウェブサーバーやオリジンサーバーの手前に配置した Application Load Balancer や、REST API を使用するための Amazon API Gateway、または GraphQL API 用の AWS AppSync にデプロイできます。
AWS WAFはALBとは連携できるが、NLBと連携することは出来ない。
AWS Shiled
Standardではトランスポートレイヤーしか保護されないことに注意する。
AWS Shield Standard を Amazon CloudFront や Amazon Route 53 とともに使用すると、インフラストラクチャ (レイヤー 3 および 4) を標的とするすべての既知の攻撃を総合的に保護できます。
一方Advancedであれば、
Standard に付属しているネットワークおよびトランスポートレイヤーの保護に加えて、AWS Shield Advanced は大規模で高度な DDoS 攻撃に対する追加の検出および緩和策と、ほぼリアルタイムの可視性を提供します。
アプリケーション層に対する攻撃(≒DDoS攻撃)からも守ってくれる。これらのサービスは基本的にCloudFrontに設定することで、アプリケーションを攻撃から守ってくれる。因みにCloudFrontは、一か所からの攻撃を全世界のCloudFrontエッジロケーションに負荷分散させることが出来るため、副次的な効果としてDDoSの緩和の役目も果たすことが出来る。
WAFにしてもShieldにしてもCloudFrontに設定するので、セキュリティの観点からも利用するのがベストプラクティスということか。
Multi-Region Architecture
Route53によるMulti-Region
CloudFrontというと静的コンテンツのキャッシュがメインと感じるが、CloudFrontの各エッジロケーションで捌いたアクセスをRoute53でルーティングし、各リージョン(AZではない)にロードバランシングすることが出来る。
このためCloudFrontの各エッジロケーションから、Route53を使って最も近い(≒遅延の少ない)リージョンにアクセスをルーティングすることが出来る。
例えば、ソウルとシドニーにマルチリージョンでインスタンスを配置したシステムを想定する。
CloudFrontのエッジロケーションは世界各地に大量に存在する。品川にいるユーザーが東京のAWSエッジロケーションにアクセスをルーティングされた際、東京リージョンにインスタンスが存在しないためRoute53によって最もレイテンシの小さいソウルにアクセスがルーティングされる。
こうしたマルチリージョンのアーキテクチャにおいても、各リージョンにおいてはマルチAZ構成が推奨される。マルチAZ×マルチリージョンの構成がBestPracticeとなる。
なお、リージョン障害が起こった場合のフェイルオーバーもRoute53で実現できる。フェイルオーバーというとALBを連想するが、Route53にEvaluate Target HealthさせることでRoute53から各リージョンに配置したインスタンスを監視できる。
RDSのCrossRegion-Repulication
EC2インスタンスをクロスリージョンにすると、DBをどうするのかという問題が発生する。
RDSのCRRはマルチAZ構成のリージョン版であり、一つのリージョンにソースDBを配置しリードレプリカを各リージョンに配置していく。
AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケーション - Amazon Aurora
クロスリージョンシナリオでは、AWS リージョン間のネットワークチャネルが長くなるため、ソース DB クラスターとリードレプリカ間のラグタイムが長くなります。
Read-Replica
ここで２つの異なるリードレプリカについておさらいする。
RDSのMultiAZは、データベースの障害時の影響を最小化するために同期レプリケーションを行っています。これは、マスターへの変更の後にスレーブを変更し確定してから応答します。
Amazon RDSによるレプリケーションについて理解する | DevelopersIO
Multi-AZで提供されるリードレプリカは、パフォーマンスをある程度犠牲にして読取一貫性のあるレプリカを作ってくれる。 これはこの場合のリードレプリカの存在意義が高パフォーマンスではなく、高可用性だからである。
一方で、パフォーマンスを得るために結果整合性のみを追い求めるようなリードレプリカは存在するのか。
RDSでは、非同期のレプリケーションとしてリードレプリカという機能を提供しています。これは、読み込み専用のデータベースとして利用することができます。(中略)ただし、非同期のレプリケーションですので、常に最新のデータが取れる訳ではありませんので注意してください。
読み取りのパフォーマンス向上のためのリードレプリカは非同期レプリケーションで結果整合性のみとなる。
このように、目的に応じてリードレプリカの性質は異なる。CRRのリードレプリカは云わば高可用性を求めるMulti-AZ構成の拡大版であり、読取一貫性を提供してくれると思っていた。
しかし、実際にはCRRのリードレプリカでは非同期レプリケーションしか提供していないように思える(はっきりと明記した資料が見つからない)。
クロスリージョンシナリオでは、AWS リージョン間のネットワークチャネルが長くなるため、ソース DB クラスターとリードレプリカ間のラグタイムが長くなります。
AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケーション - Amazon Aurora
少なくとも、AuroraのCRRでは非同期レプリケーションによる結果整合性しか実現されていないようだ。この点ではMulti-AZ構成としてのリードレプリカとの違いを意識する必要がある。
その他のデータベースサービスのMulti-Region
DynamoDB
DynamoDBはManaged Serviceである上に書き込みのパフォーマンスが非常に高いので、Multi-Regionにする必要はないように感じられる。しかし地理的要因によるレイテンシの発生は避けられず、これを回避するにはユーザーに最も近いDynamoDBにアクセスさせる必要がある。
マルチリージョンな構成でDynamoDBを利用したい場合、グローバルテーブルという機能が用意されている。 これは、各リージョン独立したDynamoDBに対する書き込みを同期させるための仕組みである。
またリージョンダウンに対するDRとしての側面も持ち合わせる。
いずれかの AWS リージョンが一時的に利用できない場合は、顧客は他のリージョンの同じ CustomerProfiles データにアクセスできます。
グローバルテーブル: DynamoDB を使用した複数リージョンレプリケーション - Amazon DynamoDB
Redshift
Redshiftは基本的にMulti-AZに対応しない。
よくある質問 - Amazon Redshift | AWS
現在、Amazon Redshift はシングル AZ 配置のみをサポートしています。データウェアハウスクラスターを複数のアベイラビリティーゾーンで運用するには、2 つの Amazon Redshift データウェアハウスクラスターをそれぞれ別のアベイラビリティーゾーンに配置し、同じ Amazon S3 入力ファイルセットからデータをロードします。
片方のAZ死んだ場合に備えて、もう片方にStandbyを置くような運用は出来ない。代わりに、手動で2つのAZにRedshiftを立ち上げて、同じデータを読み込ませてやる必要があった。
しかしこのような記事も見つけた。片方のAZが死んだ場合、データを他のAZに自動でレプリケーションして処理を続行する仕組みだ。比較的新しい去年の冬の記事なので、参考書では取り扱われていない。
Cross-Regionによる可用性も似たような方法で確保できる。RedshiftデータのスナップショットをS3を利用して他のリージョンのRedshiftに転送するクロスリージョンスナップショットという機能がある。
