【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummit

本記事はAWS Summit Online Japan 2021で5/11に行われたセッション「【【基本の AWS サービス】マルチリージョン、ちょっとその前に...-サービスの可用性について考える」のセッションレポートとなります。

最近大阪リージョンが開設されたため、マルチリージョンにしよう！と考えている方も多いのではないでしょうか？ぜひ一度本セッションからシステムに必要な可用性について考えてみてください。

セッション概要

スピーカー：アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ISV/SaaSソリューション本部 ソリューションアーキテクト 木村 公哉

• 日本でも大阪リージョンがフルリージョンとして拡張され、日本国内だけでいわゆる「マルチリージョン」構成を取ることができるようになりました。
• AWS グローバルインフラストラクチャを活用して首都圏の災害などにも備えて高い可用性を担保できるマルチリージョン構成ですが、データの整合性や切替方式など、重要な検討事項があることを忘れてはいけません。
• また、可用性を上げるためには様々なコストがかかるため、ビジネスニーズとコストのバランスを取ることも重要です。
• システムの可用性を高めるための選択肢が増えた今、改めてシステムの可用性について考えましょう。

• 想定視聴者
  • 可用性の高いサービスを作りたいと思っている方
  • 可用性の高いサービスを作るように依頼した・された方
  • 「マルチリージョン」という言葉が気になる方
• ゴール
  • 「ビジネスニーズにあった可用性」を理解する
  • AWS上で適切な可用性を持つサービスを構築する方法について理解する

セッションレポート

アジェンダ

• サービスの可用性について改めて考える
  • 用語の定義・可用性を定義して計算する
  • 可用性を高める方法とトレードオフについて考える
• 適切な可用性レベルを設定し、実装するための基礎知識
  • AWSが適用するインフラストラクチャ・AWSで実装する際の重要な考え方
• ビジネスニーズにあった可用性を実現するためのAWSサービス、機能、アーキテクチャを適切に選ぶ
  • なぜビジネスニーズを考慮する？可用性と災害対策
  • 単一リージョンのシナリオ、複数リージョンのシナリオ

サービスの可用性について改めて考える

• よくいただく相談
  • とにかく落ちないサービスを作りたいのですが、どうしたらいいでしょうか？
  • 開発したサービスの可用性を算出したいのですが、どのように計算したらよいのでしょうか？
• 「とにかく落ちない」とは具体的にどれくらいを目指しているのか
• この可用性は何のために算出したいのか
• 可用性についてまずは深掘りしてみる
  • 可用性の定義：規定時間における、ワークロードが使用可能な時間の割合。信頼性を定量的に測定するために使用されるメトリクス
    • 使用可能：必要なときに取り決めた機能を実行できること
    • ワークロード：リソースと、ビジネス価値をもたらすコードの集まり、実際にエンドユーザーから見える部分
  • ワークロードは複数のアプリケーションの集合と捉える
    • アプリケーション：コンポーネントの集合
    • 例)在庫管理アプリ、認可認証API
  • アプリケーションは複数のコンポーネントの集合と捉える
    • コンポーネント：ソフトウェア機能を提供する最小単位
    • 例)Webサーバー、DBサーバー、ストレージサーバー

• 可用性を定義して計算する
  • 可用性は、ワークロードが使用可能な時間を合計時間で割って求められる

• 強い依存関係を持つ場合の可用性の算出
  • アプリケーションを構成するコンポーネント同士に強い依存性がある場合を考える
  • 例)コンポーネントAが落ちるとアプリケーション全体が使用不可になる
  • アプリケーションの可用性=コンポーネントAの可用性A×B×C…

• 冗長化されている場合の可用性の算出
  • サービスが独立し、冗長化されたコンポーネントを使用する場合を考える
  • 例)コンポーネントAが即座にフェイルオーバーし、アプリケーションを継続して利用できる
  • アプリケーションの可用性=1-(1-コンポーネントAの可用性) 並列数(乗算)
  • 冗長化されている場合は、単一のコンポーネントよりも高い可用性を実現することが可能
• 可用性を高める方法とトレードオフについて考える
  • ワークロード全体の可用性を高めるためには、各コンポーネントの可用性、各アプリケーションの可用性を高める必要がある
  • 冗長化、並列処理、分散処理、疎結合なアーキテクチャによって全体の可用性を向上させることができる
  • 可用性を高めようとすると、コストは増加する
    • 可用性を高めるためには、コストと時間、高度なエンジニアリングが必要
    • これらは、金銭コスト、時間コスト、人的コストの投資が増加することを意味するため、実際のビジネス影響とリスクを考慮し、必要十分な可用性要件を定義することが重要
    • 特に24/365という可用性要件が提示されている場合は要注意
      • 多くの場合、ビジネス部門からの要求をそのまま受け入れているだけ
      • 現実に必要十分な可用性が検討・理解されていないことが多い
      • 明治されていない前提、想定を明確にする
    • 本当にコストをかけてその可用性を実現する必要があるのか？を再考
      • RTO(目標復旧時間)
      • RPO(目標復旧ポイント)
      • 障害時のビジネス損失はいくらか？
    • なぜ可用性を計算する?
      • ビジネスニーズにあった可用性が達成できているかを確認するため
      • RTO、RPO、および可用性を明確にして ビジネスにとって何が重要なのかを 明確にすることで、各ワークロードを評価できる
      • ビジネスサイドと協力して、 ワークロードの重要度、RTO、RPO、 および可用性を決めることが重要

適切な可用性レベルを設定し、実装するための基礎知識

• AWSが提供するインフラストラクチャ
  • 全てのリージョンは物理的に離れたAZで構成
  • アベイラビリティゾーンのデザイン
    • 1つ以上のデーターセンターで構成、低遅延な専用線で接続
    • 物理的に意味のある距離で分離
    • 冗長的な電力源

AWSで実装する際の重要な考え方

• すべては壊れるものとして考える
• 障害は起きるものとして「管理する」
  • 障害を管理してワークロードに影響を与えるのを防ぐためのベストプラクティス
    • データをバックアップする
    • 障害部分を切り離してワークロードを保護する
    • コンポーネントの障害に耐えられるようにワークロードを設計する
    • 信頼性をテストする
    • 災害対策(DR)を計画する
  • これらについて考慮することが重要
    • ビジネスニーズよっては実施しないという判断もあり

ビジネスニーズに合った可用性を 実現するためのサービス、機能、 アーキテクチャーを適切に選ぶ

なぜ、ビジネスニーズを考慮する?

• 可用性を高めるためにはコストがかかる - 金銭的コスト、時間的コスト、人的コスト
• ビジネスニーズに合った可用性を実現することで、コスト最適化でき、 ビジネスに投資できる
• お客様の体験に関わるビジネスの成長を起点に考えることが重要

• 可用性と災害対策(Disaster Recovery、DR)の補足
  • 高可用性 = DRではない
  • DRのフォーカス:ワークロード全体のコピー、災害発生からの復旧時間
  • 可用性のフォーカス:ワークロードのコンポーネント、ワークロードが使用可能な時間
  • →災害発生からの復旧時間に対するビジネスニーズによっては、 DRでは必ずしも可用性を考慮する必要はない

単一リージョンのシナリオ

• 可用性99%のシナリオ
  • 可用性99%、月間438分の停止を許容する
  1. アプリケーションサーバー、 DBサーバー共にバックアップを取得して、Amazon S3に保存
  2. AZ障害発生時は、 Amazon S3に保存しておいたバックアップから別AZに復旧
  3. Amazon CloudWatchを利用してモニタリング
  4. AWS CloudFormationを使用して インフラストラクチャをコードとし て定義し、特に障害発生時の再構築 をミスなく迅速に対応

• 可用性99.9%のシナリオ
  • 単一リージョンのシナリオ、可用性99.9%、月間43.8分の停止を許容する
  1. 2つのAZを利用、複数AZで動作するサービスを活用して構築することでAZ障害に耐えられるようにする(Multi-AZ構成)
  2. AamzonRDSマルチAZ配置を利用して、自動的にフェイルオーバー
  3. Auto Scalingを利用して、需要の変化に柔軟に対応
  4. 1. Amazon CloudWatchを利用してモニタリングし、サービス障害の 発生時にアラートを出す

• 可用性99.99%のシナリオ
  • 単一リージョンのシナリオ、可用性99.99% 、月間4.38分の停止を許容する
  1. 3つのAZを利用、複数AZで動作す るサービスを活用して構築することでAZ障害に耐えられるようにする(Multi-AZ構成)
  2. Amazon Auroraを利用して、3つ のAZすべてにリードレプリカを配置
  3. Amazon CloudFrontを利用してアプリケーションへのリクエストを削減し、コスト削減を検討
  4. Amazon CloudWatchを利用してモニタリングし、すべての障害で アラートを出すことで傾向分析や運用の見直しを行う

複数リージョンのシナリオ

• AWS アジアパシフィック(大阪) リージョン
  • 大阪ローカルリージョンを拡張して 2021年3月2日 開設
  • 3つのアベイラビリティーゾーン(AZ)を持つ 完全な AWS リージョンとして高い可用性を実現
  • 西日本地域のお客様が従来よりも 低いレイテンシーでサービスをご利用いただけるように
  • 東京リージョンとの組み合わせにより、マルチAZでは対応が難しいミッションクリティカルな用途にも利用可能

• バックアップ&リストア
  • バックアップデータを定期的にDRサイトにレプリケーション
  • 被災時にデータを確保することが可能
  • 最もDRにおける運用コストを抑えられる
    • 復旧にも最も時間がかかる
    • CFnを用いることでRTO短縮可能

• パイロットライト
  • 災害発生時に迅速にDRサイトに切り替えられるように準備
  • バックアップ&リストアよりも短時間での復旧が可能

• ウォームスタンバイ
  • 可用性が99.95%で、復旧時間が5~30分のシナリオ
  • データベース以外のコンポーネントも縮小規模で常時稼働
  • 本番と比較し同等のパフォーマンスはでないため、スケールが必要
  • パイロットライトと比べてより早い復旧が可能

• マルチサイト アクティブ-アクティブ
  • 可用性が99.999%で、復旧時間が1分未満のシナリオ
  • フェイルオーバーの準備が整っている本番サイトの完全な複製
  • 最もコストがかかる構成
  • 基幹業務のようなミッションクリティカルなシステムに有効
  • 常に複数リージョン稼働しているためRTOゼロ
  • Route53のヘルスチェックによりアクティブなリージョンのみにトラフィックを振り分けることも可能

• 複数リージョンのシナリオにおける考慮点
  • データストア、ネットワーク、それぞれのレイヤーで分散システムの特有の困難さを乗り越えていかなければならない
    • データの整合性、ルーティング要件など
  • 監視、ロギング、デプロイメント、テストなどの運用面でも考慮点は増える
  • 本当に多大なコストを払って 複数リージョンを利用する必要があるかを ビジネスサイドと検討することも重要

まとめ

• お持ち帰りいただきたいこと
  • 可用性を算出するのは、ビジネスニーズにあった可用性が達成できているかを確認するため
  • ビジネスサイドと協力して、ワークロードの重要度、RTO、RPOを 決めることが重要
  • AWSは耐障害性と高可用性を実現するインフラストラクチャを提供
  • すべては壊れるものとして考え、障害は起きるものとして管理することも重要
  • ビジネスニーズに合った可用性を実現するためのサービス、機能、アーキテクチャを適切に選ぶことが重要
  • AWSでは、 AWS Well-Architected Frameworkによってワークロードの可用性向上を支援

感想

可用性について具体的な数値とシナリオを用いていくつもパターンが紹介されている非常に学びが多いセッションでした。特に最近大阪リージョンが利用可能になったため、マルチリージョンによるDR構成を考えている人も多いかと思います。ただ闇雲に可用性が高ければよい、と構成を考えるのではなく、ビジネスニーズにあっているかどうか、コスト、RTO、RPOなどを含めた視点を忘れずにシステムに必要十分な可用性を考えていきたいですね。