AWS Solution Architect Associate 試験対策 ch2

AWS勉強メモ

出典: 


AWSにおける高可用アーキテクチャ

2-1 高可用性の定義

AWSでは、オンプレよりも低コストかつ多彩なレベルで可用性をシステムに組み込むことができる

一般的な可用性の定義

  • システムが正常に継続して動作し続ける能力
  • 稼働率とも
  • 冗長化によって高める
  • フェイルオーバー

    • 稼働中の系で障害が発生したら待機系に自動切り替え
稼働率(%) 年間停止時間
99 3d15h36m
99.9 8h46m
99.95 4h23m
99.99 52m34s
  • AWSのサービスが公表しているSLAは努力目標値

AWSにおける可用性向上策

  • 障害

    • システム全体が使用不能になること
    • システム動作結果の正しさを保証できなくなること
  • Design For Failure (障害発生を前提としたシステム構築)
  • SPOF: Single Point Of Failure (単一障害点)をなくせ

    • リソースを冗長化する

        • RDSをMaster/Slave構成にする
    • 地理的に離れた場所で冗長化する

        • RDSのマルチAZ機能使う
    • システムを疎結合で構成する

      • substitutable
      • 障害発生時、その部分だけ復旧させることができる
        • ELBとかSQSとか使って疎結合なアーキテクチャを作る
        • note: ELBやSQSは透過的に冗長化されており、SPOFにはならない

2-2 ネットワークにおける高可用性の実現

ネットワークサービス

  • VPC: Virtual Private Cloud

    • ネットワークACLやセキュリティグループを適宜利用する
    • 将来利用するIPアドレス数を見越してIPアドレス設計する
@startuml
class VPC
class AZ
class Subnet
class PublicSubnet
class PrivateSubnet

VPC o-- AZ
AZ o-- Subnet
Subnet <|-- PublicSubnet
Subnet <|-- PrivateSubnet
@enduml

関連

  • Direct Connect

    • 接続ポイントというロケーションを経由して、オンプレ環境とAWSと専用線で接続
    • 特徴

      • 高速
      • 安定
      • 相応のコストかかる
      • 開通に時間かかる
    • 責任共有モデル

      • AWSとの責任分界点を明確にして、双方で高可用性を実現する
      • オンプレ — 接続ポイント

        • ユーザ責任
        • この回線の可用性は通信キャリアの提供プランにより異なる
      • 接続ポイント自体

        • AWS責任
      • 接続ポイント — AWS

        • AWS責任
  • Route 53

    • DNSのマネージドサービス
    • 高可用性
    • ルーティングポリシーいろいろ
    • CNAMEにZone Apexは設定できない

      • ALIASレコード使え

        • AWS独自拡張。AレコードにALIASを前置
      • CloudFrontやELBを指したい先に使う
    • 各レコードにTTL: Time to Live設定可能
ルーティングポリシー 説明
simple 設定されたレコードの情報にしたがって
failover ヘルスチェック結果に基づいて、利用できるリソースへ
geolocation(位置情報) ユーザーの位置に基づいて地理的に近くへ(リージョンをまたいでも)
geoproximity(地理的近接性) リソースの位置に基づいて
latency レイテンシ最小(近くても遅いことはあるので)
multivalue answer(複数値回答) 正常なレコードから乱択(最大8)
weighted 指定した比率で複数のリソースへ

高可用ネットワークの構築

  • オンプレミス環境 - AWS間の接続

    • トレードオフ

      • Direct Connect
      • インターネットVPN
Direct Connect インターネットVPN
安定性
速度
安全性
コスト
即時利用 不可
開通に時間かかる
  • 冗長化方策

    • Direct Connect冗長化パターン

      • 接続ポイントを地理的に別拠点にすると、接続ポイントの障害にも対応できる
      • 高コスト
    • Direct Connect + インターネットVPN

      • Direct Connectをメインに使う
      • インターネットVPNにフェイルオーバーする
      • 低コスト
      • フェイルオーバー時に品質が変わる

        • アプリケーションが影響をうける恐れあり
  • VPC内通信

    • 責任共有モデル

      • AWS内の物理機器はAWS管理下で透過的に冗長化されている
    • 絶対に壊れない、とは言ってない
    • 有事の際にネットワークを守る方策

      • 地理的に離れているAZにサブネット構築する

        • デフォルトでルートテーブルにlocalの経路が定義されており、同一VPC内のサブネット間で相互通信可能
      • Route 53のDNSフェイルオーバー機能を利用して自動でDNSを切り替える
  • VPCピアリング

    • 異なるVPC同士の通信をAWS内部のネットワークで行える

      • 同一アカウント
      • アカウントまたぎ
      • リージョンまたぎ
    • プライベートIPアドレスで接続可能

2-3 コンピューティングにおける高可用性の実現

コンピューティングサービス

  • EC2: Elastic Cloud Computing

    • 高可用性のためにはマネージドサービスを使うのが普通

      • ELB
      • Auto Scaling
      • DNS
  • Auto Scaling

    • スケールアウト

      • 増やすやつ
      • 流れ

        1. スケーリングプランの設定値をトリガーに、
        2. Auto Scaling グループの設定値に従ってインスタンス数増加
      • AZが複数ある場合、AZ間でインスタンス数の均衡を保つように起動

        • cf. ELBの振り分けは標準でAZ内均一
    • スケールイン

      • 減らすやつ
      • 判定ロジック

        1. AZ間でインスタンス数の均衡を保つように

          • インスタンスが一番多いAZから乱択
        2. 同じなら、起動設定が新しくなるように

          • 最も古い起動設定を使用したEC2インスタンスを落とす
        3. 複数あれば、課金が最小になるように

          • 次の課金発生までの時間が最も短いインスタンスを落とす
        4. それでも複数あれば、乱択
    • クールダウン

      • しばらくスケールアウトしなくするやつ

        • 前に起動したインスタンスが完全に起動するまで
      • インスタンスの起動にはタイムラグがある
      • タイムラグ中に再びスケーリングプランのトリガー条件が満たされ、インスタンスが起動しすぎるのを防止
    • ライフサイクルフック

      • 用例

        • 起動時に特定のデータをロード
        • 終了時にログ出力
  • CloudFront

    • CDN
    • エッジロケーションからコンテンツ配信
    • これ自体の可用性を考慮する必要はない
  • Lambda

VPCリソースにおける高可用性コンピューティング

TODO:暇な時にお絵描きする

  • ELB: Elasting Load Balancing

    • こいつ自体はSPOFにならない
    • IP代わるので代わりにエンドポイント使う
  • 一般的なWebアプリケーションにおける構成例

    • ELB --> * EC2
    • 複数AZにEC2配置
    • EC2をAutoScalingグループでまとめる
  • 一般的なWebアプリケーションにおける障害発生時の挙動

    • ヘルスチェック正常なEC2にのみトラフィック振り分けられる
    • セッションは失うが稼働し続ける
  • データベースを持つWebアプリケーションにおける構成例

    • RDSのマルチAZ機能有効化
    • EC2上でDBMS動かし、サードパーティ製ソフトウェアでクラスタリング
  • RDSインスタンス障害発生時の挙動

    • シングルAZ

      • 自動再起動する
      • データは自分で復旧する

        • ポイントインタイムリカバリ
    • マルチAZ

      • 自動的にスレーブにフェイルオーバー

        • スレーブがマスターに昇格
        • エンドポイントは変わらない
        • 流れ

          1. スレーブがマスターに昇格
          2. マスターで利用していたDNSレコードをスレーブのDNSレコードへ切り替える
      • リカバリ不要(データ自動同期)
    • レコード破損

      • がんばる

        1. RDSのエンドポイント控える(*)
        2. エンドポイントを別のものに変更
        3. バックアップ(+トランザクションログ)から変更前のエンドポイント名(*)でリストア
        4. 旧インスタンス削除
  • インメモリデータベースを持つWebアプリケーションにおける構成例

    • セッション情報管理等
    • ElastiCache

      • マルチAZ機能利用可能なRedisエンジン前提で高可用性実現
    • RDSと同じような流れで自動フェイルオーバー

      • スレーブがマスターに昇格
      • エンドポイントは変わらない

グローバルサービスにおける高可用性コンピューティング

  • Route 53を利用したWebアプリケーションにおける構成例

    • DNSフェイルオーバーの例

      1. ELB以下EC2インスタンスが全滅した場合
      2. ELBのヘルスチェックはエラーとなる
      3. DNSのレコードをELBからS3に変え、sorryページを表示する
    • Route 53によるマルチAZの構成例

      • ELBの代わりにDNS使う感じ
      • EC2インスタンスにはEIP: Elastic IPを割り当てておく
      • DNSのAレコードでこれを指す
    • Route 53によるマルチリージョンの構成例

      • Route 53はエッジロケーションに存在

        • cf. ELBはリージョンサービスに見せかけたAZサービス

          • 実体はMulti-AZでAuto-Scalingなインスタンスらしい
      • リージョンを超えた可用性を実現可能
  • CloudFrontを利用したWebアプリケーションにおける構成例

    • ELBやAuto Scaliingで自動的にスケールすることは可能
    • が、アクセスが急増すると、スケールアウトが間に合わず、システムが過負荷になるおそれあり
    • キャッシュから応答することで予期できないアクセス集中にも対応できる
    • CloudFrontのオリジンは複数指定できる

      • L7でのルーティング

        • Route53 -> CloudFront -> ELB -> EC2 -> バックエンド
        • Route53 -> CloudFront -> S3

2-4 ストレージにおける高可用性の実現

ストレージサービス

  • EBS: Elastic Block Storage

    • 永続化可能なブロックストレージ
    • 単一AZ内で自動的に複製される

      • AZ障害時はデータ喪失
      • なのでスナップショットをとる
    • AZ単位で作成されるので、同一AZ内のEC2インスタンスにのみアタッチできる
  • インスタンスストア(=エフェメラルディスク)

    • ホストコンピュータ内の領域を利用
    • 揮発性

      • 停止・起動は駄目(Instance Store-Backed Instanceではできない)

        • 同一のホストコンピュータでの起動が担保されていない
      • 再起動は大丈夫
    • 無料・高パフォーマンス
  • EFS: Elastic File System

    • 共有ストレージ
    • 自動的に複数のAZで冗長化される

      • ユーザ側で可用性を考慮する必要なし
    • スナップショット取れない
  • S3

    • 耐久性イレブンナイン
    • 可用性は99.99%
  • S3 Glacier

    • アーカイブ用

Glacierのデータ取り出しオプション

オプション 取り出し時間
迅速(expedited) 1-5分
標準(standard) 3-5時間
大容量(bulk) 5-12時間

迅速(expedited)の実行タイプ

実行タイプ 説明
オンデマンド 成功する保証なし
プロビジョニング リクエストはすぐ処理されるが高価

コンピューティングサービスにおけるストレージの選択

  • EBS/EFS/インスタンスストア比較
EBS EFS インスタンスストア
インスタンスとの接続 N/W接続 N/W接続 ホストコンピュータ内
利用方法 ボリューム作成後にマウント ボリューム作成後にマウント インスタンス起動時にマウント
接続可能台数 1 複数 1
データ永続性 不揮発 不揮発 揮発
冗長化 単一AZ内冗長化 複数AZ 冗長化なし
拡張性 手動 自動 不可
パフォーマンス 非常に高
料金体系 従量課金(安) 従量課金(高) 無料
  • S3をコンピューティングサービスとして利用

    • 静的Webサイトホスティング
    • 特徴

      • スケールする必要がなく、アクセス集中に強い
      • 運用コスト低減
    • 動的コンテンツは含められない

各ストレージのバックアップ

  • EBSのバックアップとリストア

    • 単一AZ内冗長化なので、AZ障害時にはデータ喪失
    • スナップショットを取っておこう

      • S3に保存

        • 高耐久性
      • 増分バックアップ

        • やすい
      • リージョン間コピー可能

        • Disaster Recovery可能
    • 復旧の流れ

      1. 現EBSデタッチ
      2. スナップショットから新EBS作成
      3. 新EBSアタッチ
  • EC2のバックアップとリストア

    • AMI: Amazon Machine Image

      • EBSスナップショット
      • EC2の構成情報
    • AMIはリージョン間コピー可能
  • S3の機能

    • データは特定のリージョンの複数のAZに複製される
    • データ整合性に注意
保存方法 モデル 説明
PUT(新規追加) 書込後の読込整合性 HTTP 200 OK返却時点でデータ参照できる
PUT(更新) 結果整合性 更新直後に参照すると古いかも
DELETE 結果整合性 削除直後に参照すると削除前の見えるかも
  • S3のアクセス制御

    • IAMポリシー
    • バケットポリシー
    • ACL