【レポート】公共システムに求められる耐障害性、大量同時アクセスに対応するアーキテクチャ AWS-16 #AWSSummit

2022年5月25日(水)~2022年5月26日（木)開催のAWS Summit Online 2022に参加しています。
今回はオンラインセッション　AWS-16 公共システムに求められる耐障害性、大量同時アクセスに対応するアーキテクチャ についてレポートします。

セッション概要

このセッションの対象者は、公共機関（中央省庁、地方自治体、医療/ヘルスケア、教育事業者、非営利組織など）のIT担当の方および、公共機関におけるシステム開発に携わるシステムインテグレーターの方です。
2021年9月にデジタル庁が発足し、日本国民が使うシステムは今後も増えていくことが想定されます。国民に広く利用される公共システムでは、高い耐障害性が求められると同時に、様々な場面で発生する大量同時アクセスにも対応する必要があります。
本セッションでは、そのような公共システムを実現するアーキテクチャや活用できるサービスについてご紹介します。

スピーカー

AWS パブリックセクター技術統括本部 アソシエイトソリューション アーキテクト
原田 江海咲 氏
資料についてはこちらからダウンロードできます。
※AWS Summit Online 2022の無料登録が必要です。

セッションのゴール

AWSにおける耐障害性の考え方と、耐障害性を高めるアーキテクチャを理解する
大量同時アクセスに対処するアーキテクチャと、それを支えるサービスについて学ぶ

レポート

公共システムならではの特性

公共システムは災害時にこそ動かなければなりません。
例として下記システムがあげられます。

• 気象・防災情報を発信するサイト
• 給付金システム

他にも政策に基づいてアクセスが集中する特性があります。(ワクチン接種予約サイト等)
公共システムの特性に対応する為には、下記2点の対応が求められます。

• 高い耐障害性
• 大量同時アクセスへの対応

リージョンとアベイラビリティーゾーン

公共システムはサービスを止めてはいけない、という大前提があります。
クラウドでも実体は物理サーバー上で動いている以上、障害は発生しうるケースがあります。
AWSではリージョンという考え方があり、世界中に26のリージョンがあります。
日本でも東京・大阪の2つリージョンがある為、国内のみでデータを保持したいケースでもバックアップ体制を取ることができます。
それぞれのリージョンは複数のアベイラビリティーゾーン(AZ)で構成されており、それぞれのAZは地理的に影響を受けない離れた場所に設置されています。
冗長化の考え方として、可用性とコストに見合ったアーキテクチャを選ぶことが重要です。

RTOとRPO

耐障害性の高いアーキテクチャを構築するにはRTOとRPOを定義することで、サービスの耐障害性を測る指標が明確化します。
Recovery Point Objective (RPO)
各データをどの地点まで戻す必要があるかという考え方です。
バックアップ・リストアの運用やデータレプリケーションの技術選択に影響します。
Recovery Time Objective (RTO)
システムの復旧にどのくらい時間がかけられるかという考え方です。
1分以内なのか、1時間以内なのかといった指標になります。
データリストアやシステム再起動等の技術選択に影響します。

マルチサイト アクティブ-アクティブ

例としてRPO/RTOをほぼリアルタイムとしたアクティブ-アクティブの構成の紹介がありました。
Route53 - ELB - EC2(AutoScaling) - Auroraの構成を東京リージョンと大阪リージョンに設置します。
東京で災害があった時はRoute53のDNSヘルスチェックで大阪のELBに宛先を変更します。
大阪リージョンのAurora ReplicaをPrimaryに昇格することで復旧します。

RTO/RPOの計り方

現実のアプリケーションにおいてRTO/PROを満たせているか測定・管理する為のサービスがあります。
AWS Resilience Hub
アプリケーションのRTOとRPOを測定し、耐障害性(レジリエンス)の定義、追跡、管理を支援するサービスです。
AWS Well-Architected Frameworkに沿って耐障害性の弱点を発見します。
Amazon CloudWatchやAWS Fault Injection Simulator (FIS) と連携し、耐障害性に関するアラートやインサイトを継続的に可視化可能です。

大量同時アクセスを処理するアーキテクチャ

公共システムでは一定期間に集中アクセスが発生するケースが多いです。
耐障害性を高めても大量同時アクセスによる負荷でサービス提供が止まってしまう可能性があります。
大量同時アクセスを処理する上での方法は下記2パターンあります。

• 負荷に応じてリソースをスケーリング
• バックエンドで受けるトラフィックの量を制御

負荷に応じてリソースをスケーリング

負荷に応じてリソースをスケーリングするには下記方法があげられます。

• 静的コンテンツの処理をオフロード
• 仮想サーバを動的にスケーリング
• データベースの読み込み処理をスケーリング

静的コンテンツの処理をオフロード
静的コンテンツをWebサーバーと切り離してAmazon S3とAmazon CloudFrontに流す方法です。
Amazon CloudFrontでコンテンツをキャッシュしつつ、サーバーの負荷を軽減させます。
Amazon S3ではイレブンナインの高い耐久性と静的コンテンツをホストすることができます。

仮想サーバを動的にスケーリング
実際の需要をAmazon CloudWatchでモニタリングし、需要に合わせてAWS Auto Scalingでリソースを増減させる方法があります。
Amazon CloudWatchでメトリクスやログを収集しつつ、AWS Auto Scalingで定義したポリシーに従って仮想サーバーの台数を増減させます。
例：CPU使用率80%以上が5分間続いたらサーバを2台増やす

データベースの読み込み処理をスケーリング
Amazon Aurora のリードレプリカを利用することでデータベースの読み込み処理をスケーリングすることができます。

バックエンドで受けるトラフィックの量を制御

スケーリングをしても、スケーリングまで時間がかかり急激なスパイクに耐えきれないケースがあります。
その場合、下記方法が上げられます。

• エッジロケーションでのフィルタリング
• キューを用いたバッファリング

エッジロケーションでのフィルタリング
仮想サーバーの前のエッジロケーションでトラフィックをフィルタリングする方法があります。
CloudFront Functionsというサービスで軽量なJavaScriptコードをCloudFrontエッジロケーションで実行できる機能です。
Lambda@Edgeの1/6のコストでより低いレイテンシーで利用できます。
ユーザーのCookie情報や初回アクセスからの時間で条件分岐させることができます。
ワクチン接種のケースをあげると、待合室ページを静的なページで用意してS3に飛ばしつつ、予約受付のユーザーはWebサーバに飛ばすことができます。

キューを用いたバッファリング
例として、サーバレスアーキテクチャでバーチャル待合室を構築するケースをあげます。
Amazon API Gateway, Amazon SQS, AWS Lambda, Amazon Dynamo DBを利用することで、サーバレスで構築することができます。
こちらはAWSが実装ガイドを出しているのでぜひ試してみてください。

Next Action

ぜひやっていただきたいこととして、上にあげたRTO/RPOの定義を見直したり、AWS Hands-on for Begnnersで触ってみようと紹介がありました。
マルチリージョンアプリケーションアーキテクチャ
AWS Hands-on for Beginners 〜 スケーラブルウェブサイト構築編 〜
AWS Hands-on for Beginners Amazon EC2 Auto Scaling スケーリング基礎編

感想

耐障害性、大量同時アクセスに対するアーキテクチャについて基礎から学ぶことができました。
またAWS Resilience HubやCloudFront Functionsといった新しいサービスについても学ぶことができました。
大量同時アクセスのワードに惹かれて本セッションを視聴したのですが、たしかに公共系は全国民がアクセスする可能性があるのに加え、落ちてはいけないシステムの為、アーキテクチャを考えるのも楽しそうです。
実装ガイドやハンズオンの紹介もあったのでやってみようと思えるセッションでした。もしハンズオンをやったことない方がいましたら活用してみてください。

ではまた！コンサルティング部の洲崎でした。