こんにちは。skです。
本記事は、AWS Summit Japan 2022 のセッション
「AWS-16：公共システムに求められる耐障害性、大量同時アクセスに対応するアーキテクチャ」
のレポートです。

セッション概要

タイトル

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

スピーカー

アマゾン ウェブ サービス ジャパン合同会社
パブリックセクター技術統括本部 アソシエイトソリューションアーキテクト
原田 江海咲氏

概要

2021 年 9 月にデジタル庁が発足し、日本国民が使うシステムは今後も増えていくことが想定されます。国民に広く利用される公共システムでは、高い耐障害性が求められると同時に、様々な場面で発生する大量同時アクセスにも対応する必要があります。本セッションでは、そのような公共システムを実現するアーキテクチャや活用できるサービスについてご紹介します。

レポート

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

• 災害時に動作している必要がある
  • 気象・防災情報サイト、給付金システムなど
• ユーザー数が膨大
  • 住民情報管理、社会福祉関連システムなど
• 政策によってアクセスが集中する場合がある
  • ワクチン接種予約サイト、申請システムなど

→公共システムの特性に対応したシステムは『高い耐障害性』と『大量同時アクセスへの対応』が求められる

耐障害性を高めるアーキテクチャ

耐障害性の重要性

昨今、異常気象による台風や水害、巨大地震などの自然災害のリスクに対応するための意識が高まっている。
クラウドも障害は発生しうるため、”Design for Failure(障害を見据えた設計)”を考えなければならない。

AWSにおける冗長化の考え方

AWSのグローバルインフラストラクチャは世界中に 26 のリージョンが存在 (2022年1月時点)。それぞれのリージョンは、複数のアベイラビリティーゾーン(AZ)で構成され、AZは地理的に影響を受けない離れた場所に作られている。これらの選択を用いて地理的な災害が発生したとしても耐えれるシステムを設計することが可能。

• シングルAZ
  • ディスクは冗長化され、単一障害に耐えることが可能
• マルチAZ
  • 複数AZ間で冗長化し、AZ障害・中規模障害に耐えることが可能
• マルチリージョン
  • 複数のリージョン間で冗長化し、リージョン障害に耐えることが可能

耐障害性の高いアーキテクチャを構築するには?

RTO(復旧目標時間)とRPO(復旧目標時点)を定義することで、サービスの耐障害性を測る指標を明確にすることができる。具体的には、RPOは「データをどの時点まで戻せれば良いか」、RTOは「復旧にどのくらい時間をかけられるか」を決めることになる。これでいくつかの復旧シナリオが検討できる。

いくつかの復旧シナリオ

• バックアップ & リストア
  • 平常時にはバックアップを取得し、災害発生後にデータ復旧
• パイロットライト
  • コアサービスのみに限定したサイトを運用し、災害発生時にはリソースを起動しスケール
• ウォームスタンバイ
  • 平常時からメインサイトと同等機能をもち規模を縮小したサブサイトを運用し、災害時にはスケール
• マルチサイト アクティブ・アクティブ
  • 平常時からメインサイト同等の構成のサブサイトを運用

『災害等が発生してもサービス停止しない』構成とするならば、『マルチサイト アクティブ・アクティブ』が選択候補になる。

具体的な構成

• マルチサイト アクティブ・アクティブ構成
  • Route 53 で各リージョンのサイトに振り分け
  • 各リージョンではマルチAZ構成
  • DBはクロスリージョンレプリケーションで構成、更新はプライマリサイトのみで実施

AWS のディザスタリカバリ (DR) アーキテクチャ、パート IV: マルチサイトアクティブ/アクティブ | Amazon Web Services ブログ

AWS Resilience Hub

アプリケーションのRTOとRPOを測定し、耐障害性の定義、追跡、管理を支援するサービス

• AWS Well-Architected Framework に沿って潜在的な耐障害性の弱点を明らかにする
• RPO/RTOを満たすための構成・運用における推奨事項の提案
• Amazon CloudWatchやAWS Fault Injection Simulator(FIS)と連携し、耐障害性に関するアラートやインサイトを継続的に可視化

AWS Resilience Hub の概要

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

大量同時アクセスに対応する重要性

• 公共システム(ワクチン接種予約サイト、災害時の給付金など)では一定期間に集中アクセスが発生するケースが多い
• 自然災害に備えて耐障害性を高めても、大量同時アクセスによる負荷で耐えきれず、サービス供給が止まってしまう可能性がある

大量同時アクセスを処理する上での2つの考え方

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

負荷に応じてリソースをスケーリングさせる対策

• 静的コンテンツの処理をオフロードし負荷を軽減
  • 静的なコンテンツを Web サーバーから切り離す
    • S3 を検討
  • コンテンツをキャッシュする
    • CloudFront を検討
• リソースを増減
  • CloudWatch で需要をモニタリングしAuto Scalingでリソースを増減
• データベースの読み込み処理をスケーリング
  • Amazon Aurora リードレプリカで参照系のクエリをオフロードする。Amazon Aurora は3つのAZで最大15個のリードレプリカが昇格可能でAutoScalingによる自動増減が可能。

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

スケーリングには仮想サーバーが起動するまで数分かかる為、急激なスパイクには耐えきれない問題点がある。仮想サーバーの前のレイヤーでトラフィックを吸収し、大量アクセスからサーバーを保護する必要がある。

• エッジロケーションでトラフィックをフィルタリング
  • 軽量なJavaScriptコードをCloudFront エッジロケーションで実行
    • CloudFront Functions を用いて、バーチャル待合室なるURLを生成して誘導し、ユーザーのCookie情報や、初回アクセスからの経過時間などの条件を元にして、予約受付などのURLのページに書き換えることで、集中するシステムへのトラフィックを制御する
• キューを用いてバッファリングでバックエンドへ集中するトラフィックを制御
  • サーバレスアーキテクチャでバーチャル待合室を構築
    • Amazon SQSを用いてバッファリングし、バックエンド(Lambda)への流れるトラフィックを制御

AWS での Virtual Waiting Room

まとめ

• 耐障害性を高めるアーキテクチャ
  • 冗長構成の考え方(シングル AZ, マルチAZ, マルチリージョン)を取り入れる
  • RTOとRPOを定義し、耐久性の指標を明確にする
    • AWS Resilience Hub を活用する
  • マルチサイト アクティブ-アクティブ構成 によってサービス停止をさせない要件を達成する
• 大量アクセスを処理するアーキテクチャ
  • 状況に応じてリソースをスケールさせ、負荷増加に備える
    • CloudFront + S3, CloudWatch + Auto Scaling, Aurora リードレプリカ の利用を検討する
  • トラフィックを制御することで、バックエンドへの負荷を吸収する
    • CloudFront Functions, バーチャル待合室の設計を検討する

感想

今回のセッションでは、ロケーションにおける耐障害性であったり、大量同時アクセスに耐えうる構成であったりと学べるものがありました。

災害時にサービス停止しない構成とするときは、マルチリージョンを検討をすることであったり、大量同時アクセスの発生を検討する場合は、静的コンテンツの処理をオフロードすることで負荷を軽減しつつ、負荷をモニタリングしてスケールを行うことを検討するなどがありました。また、急激なスパイクに耐える方法として、バックエンドで受けるトラフィック量を制御する方法の紹介がありました。

災害対策を考慮した場合のマルチリージョンは、コストも多く発生する可能性があるので、RTOとRPOを定義することで耐障害性どうするかを検討することが重要であると理解しました。障害に耐えうる信頼性の高いシステムについては、必ず検討する事項になると思うのでとても有用な内容でした。