書籍「AWS認定ソリューションアーキテクトアソシエイト」

  • 著者　：大塚 康徳（日立インフォメーションアカデミー）

  • 単行本（ソフトカバー）: 168ページ

  • 出版社: リックテレコム (2016/8/17)
  • 言語: 日本語
  • ISBN-10: 486594043X
  • ISBN-13: 978-4865940435
  • 発売日： 2016/8/17

2018_12_aws_saa_blue

第1章 AWSと認定プログラム ーAWSクラウドとは何か、そして認定プログラムとは何か？ー

  • 割愛
    • 試験概要、AWSとはについて説明しているだけ

第2章 リージョン／アベイラビリティーゾーンとAWSサービス ーリージョンとAZ、そして各種サービスの提供レベルについてー

  • 試験のポイント！

    • サーバやデータはAZ間で冗長的に配置する

  • サービス種別

    • リージョンサービス
    • AZサービス
    • グローバルサービス

※サービスの中のコンテンツ毎に種別が違ったりして掘り下げるとややこしい
参考）https://stay-ko.be/aws/solutionarchitect-pro-aws-global-vs-resion-vs-az-resources

  • 章末問題
    • ELBはAZサービスでありリージョンをまたいで負荷分散できない！
    • 複数のAZにEC2を配置して、ELBで負荷分散するのが鉄則

第3章 責任分担セキュリティモデルとAWSにおける認証（IAM）

責任分担セキュリティモデル

  • 責任分担セキュリティモデル

    • 利用者とAWSが協力してセキュリティを高める考え方

  • サービス種別

    • インフラストラクチャサービス
      • ハードウェア部分までAWSが管理
      • EC2など
    • コンテナサービス
      • ハードウェア部分からミドルウェア部分までAWSが管理
      • RDSなど
    • アブストラクトサービス
      • ハードウェア部分からソフトウェア部分までAWSが管理
      • S3やDynamoDB

  • 試験のポイント！

    • インフラストラクチャサービス、コンテナサービス、アブストラクトサービスの各サービスについて、利用者の責任範囲を明確にする

AWSにおける認証とアクセス制御

  • 試験のポイント！

    • 日常の操作にはルートアカウントを使用せずに、IAMユーザを使用する

  • 試験のポイント！

    • 各IAMグループ、IAMユーザには、最小権限のアクセス権を与える。
    • IAMポリシーは最も厳しいポリシー（拒否）が優先される。
      • アクセス許可と拒否が相反する場合、拒否が優先

  • 試験のポイント！

    • EC2インスタンス上で実行されるプログラムの認証にはIAMロールを割り当てる
      • IAMロールを使用することでアクセスキーとシークレットアクセスキーがなくてもAWSサービスにアクセスできる
      • キーを使わないアクセスで、キーの流出を防ぐことが狙い

IDフェデレーション

  • 事例
    • 要求
      • 自社の従業員に各自の業務レポートを毎月月末にS3にアップロードさせるたい
    • 問題
      • S3バケットへのアクセス権を付与したいが、毎月１回だけのために全従業員分のIAMユーザを作成するのは非効率すぎて現実的ではない。
    • 解決策
      • AWS Security Token Service（STS）という一時的に認証情報を付与するサービスとIDブローカー（IDプロバイダー）を利用して、自社の認証基盤で認証が通ればS3バケットへのアップロードを一時的に許可することができる

→これを「IDフェデレーション」という！

  • 他にも以下がある

    • Security Assertion Markup Language(SAML)を使用したシングルサインオン
    • GoogleやFacebookといったウェブIDプロバイダーを使用したシングルサインオン

  • 試験のポイント！

    • AWSの使用頻度が低いユーザは、IDフェデレーションで社内の認証基盤とIAMを連携する

  • 章末問題

    • 利用者の責任で実施しなければならないセキュリティ対策は？
      • S3上のデータの暗号化
      • EC2インスタンス上のOSのセキュリティパッチの適用
    • AWSアカウント/認証情報の推奨される運用は？
      • S3バケットへのアップロードをEC2インスタンスで実行する場合は、S3バケットへのファイルアップロードが許可されたIAMロールをEC2インスタンスに割り当てる

第4章 AWSにおけるネットワーク（VPC）

VPCの機能と設定

  • VPC（Amazon Virtual Private Cloud）

    • 利用者毎にプライベートなネットワーク空間を提供するサービス

  • １．VPCの作成

  • ２．サブネットの作成

    • 重要！
      • サブネットはAZをまたがることはできない。サブネットを選択することはAZを選択することと同じ

  • ３．ゲートウェイの作成

    • インターネットゲートウェイ（IGW）をVPCにアタッチ
    • オンプレと通信するためのゲートウェイはバーチャルプライベートゲートウェイ（VGW）

  • ４．ルートテーブルの設定

    • 重要！
      • インターネットとのアクセスを許可するサブネット：パブリックサブネット
      • インターネットとのアクセスを許可しないサブネット：プライベートサブネット
    • パブリックかプライベートはサブネットに適用されているルートテーブルによってきまる
      • パブリック：デフォルトゲートウェイ（送信先：0.0.0.0/0）のターゲットとしてIGWが設定
      • プライベート：上記でない
    • VPCの内の通信はルートテーブルでは制御できないので、VPC内のサブネットであれば、通信が可能になっている
      • Webサーバ、DBサーバ、その他のサーバ、でサブネットを分けていても、相互通信可能な状態になっている

  • ５．NATインスタンスの作成

    • プライベートサブネット内のパッチ当て等
    • NATインスタンスの実態はEC2インスタンス（※注意※最新ではNATゲートウェイというAWSサービスが存在する！）
      • 送信元/送信先チェック：宛先が自身のIPアドレスでなければトラフィックを破棄する設定。EC2インスタンスはデフォルトでON
      • NATインスタンスはこの機能を無効化している

  • 試験のポイント！

    • プライベートサブネット内のインスタンスがインターネットにアクセスするための設定を押さえる！

EC2インスタンスのIPアドレス

  • IPアドレスの種類

    • Public IP
    • Elastic IP

  • EC2インスタンスのプライベートIPアドレスとグローバルIPアドレスの紐付けは、VPCの仮想ネットワークで行われているので、EC2インスタンスのOSにログインし、ipconfigコマンドやifconfigコマンドを実行しても、プライベートIPしか確認できない

セキュリティグループとネットワークACL

  • ファイアウォール機能
    • セキュリティグループ
    • ネットワークACL
セキュリティグループ ネットワークACL
適用単位 EC2やRDS、ELBなどインスタンス毎 サブネット単位
作成可能なルール 許可のみ 許可/拒否
デフォルトルール インバウンド：すべて拒否/アウトバウンド：すべて許可（ホワイトリスト方式） インバウンド：すべて許可/アウトバウンド：すべて許可（ブラックリスト方式）
特徴 ステートフル ステートレス
  • 試験のポイント！
    • セキュリティグループとネットワークACLの違いを抑えて、ファイアウォールによるトラブルシューティングに対応できるようにする

VPCピア接続

  • 使い所

    • 本番環境と開発環境で異なるVPCを構築したが、２つのVPCを接続して、プライベートIPで通信したい

  • 接続が確立されると、PCXというゲートウェイに相当するものが作成される

  • ルートテーブルの設定で送信先のターゲットとして、PCXを設定することで、各VPC内のサブネット間でのプライベートIPでの通信が可能になる

  • ピア接続の制約

    • 接続するVPCは同じリージョンに存在する必要がある
    • 接続するVPCのプライベートネットワークアドレス空間は重複していない
      • 接続する可能性があるならはじめから分けておく必要性を示唆している
    • １対１の接続
      • ここはAWS対策講座でも強調して説明されていた

  • 試験のポイント！

    • VPCピア接続の特徴/制約を押さえる

  • 章末問題

    • VPC内のすべてのサブネット間の通信はデフォルトのルーティングルールで許可されており、変更や削除はできない
    • セキュリティグループはステートフルのため戻りのトラフィックを確認する必要ない
    • VPCピア接続にあたってVPCが同一のリージョンに存在する必要がある点
    • VPCピア接続は１対１

第5章 AWSにおけるコンピューティング（EC2／AMI／EBS／インスタンスストア）

EC2の初回起動と設定

【作成ステップについて】

  1. Amazon Machine Image(AMI)の選択
  2. インスタンスタイプの選択
    1. インスタンスファミリー選択
  3. ネットワーク/IAMロール/ユーザデータなどの設定（インスタンスの詳細設定）
    1. ユーザデータ：シェルスクリプト
    2. メタデータ：インスタンス自身に関するデータ
  4. ストレージの設定
    1. EBS
    2. インスタンスストア：追加できるのはEC2インスタンスの初回起動時のみ
  5. タグ付け
    1. タグ付けができる。おおよそ、Nameをキーにサーバー名を値に設定したりする
  6. セキュリティグループの設定
    1. EC2には少なくとも１つのセキュリティグループを割り当てる必要がある
  7. 個々までの設定の確認
  8. キーペアの選択
  • 試験のポイント！
    • ユーザデータおよびメタデータの用途と、メタデータで参照できる主要なデータを押さえる

EC2インスタンスのライフサイクル

  • ステータスチェック

    • System Status Checks:インフラストラクチャ（HW、ハイパーバイザ）のチェック
    • Instance Status Checks：OSのチェック

  • EC2のインスタンスがrunningになった時点から料金が発生し、stopped,terminatedになるまで発生

EBSとインスタンスストア

  • Amazoon EBS(Elastic Block Store)
    • AZ内に作成されるネットワーク接続型のブロックストレージ
    • 不揮発性

  • インスタンスストア

    • EC2インスタンスの物理ホストの内蔵ストレージで、揮発性（一時的なデータボリューム）
    • 揮発性：EC2が停止すると保存されていたデータは削除される
    • EC2が停止して起動すると、物理ホストが変わるため、揮発性という特徴がある

  • 重要！

    • ブロックストレージにはEBSとインスタンスストアの２種類があり、不揮発性と揮発性という違いがある！

  • OSがどこにインストールされるかによる違い

    • EBS-backedインスタンス
      • EBSにOSがインストールされる
    • instance store-backedインスタンス
      • インスタンスストアにインストラクターされる

  • 試験のポイント！

    • EBS-backedインスタンスとinstance store-backedインスタンスの特徴を押さえる！

EBSのタイプ

  • EBSのタイプとして３種類言及しているが、情報として古いので、最新を確認したほうがよい

  • EBS最適化オプション（Black Beltより最新情報を記載）

    • ネットワークのIO帯域とEBSのIO帯域を分け、EBS専用帯域を確保するオプション

  • 試験のポイント！

    • EBSボリュームタイプの性能の違いとEBS最適化インスタンス(今はEBS最適化オプション？)の使い所を押さえる

EBSスナップショット

  • 試験のポイント！

    • EBSスナップショットの特徴を押さえる！

  • 試験のポイント！

    • EBSスナップショットを介したAZ/リージョン間のEBSボリュームの複製の流れを押さえる
    • リージョン-a/AZ-a → リージョン-a/S3 にスナップショット取得
    • リージョン-a/S3 → リージョン-a/AZ-b にスナップショット復元
    • リージョン-a/S3 → リージョン-b/S3 にスナップショットコピー
    • リージョン-b/S3 → リージョン-b/AZ-c にスナップショット復元
      • S3間はリージョンをまたいでスナップショットをコピーすることができる点

プレイスメントグループ

初めて聞いた…

  • 試験のポイント！
    • プレイスメントグループ内にEC2インスタンスを起動することで、EC2インスタンス間のネットワーク接続を高速化できる

Dedicatedインスタンス

  • ソフトウェア・ライセンスの、ハードウェア制約を解消するために、EC2インスタンスを起動する物理ホストに、別のEC2インスタンスが起動しないことを保証

  • Dedicatedホストという、物理ホストをアカウントに割り当てておき、その中にEC2インスタンスを起動していくサービスが利用できるようになった

  • AWS参考
    https://aws.amazon.com/jp/ec2/purchasing-options/dedicated-instances/

  • 章末問題

    • ユーザデータについて
    • EC2の停止は「EBS-backedインスタンス」しかできない（instance store-backedインスタンスはできない）
    • EC2の再起動は揮発性ボリュームデータを失わない
    • スナップショット取得の留意事項（アンマウント＋取得後すぐにIO可能）
    • EBSボリュームはAZ間コピーもリージョン間コピーもできない、S3にスナップショットを取得して適応する
    • プレイスメントグループについて
    • Dedicatedインスタンスについて

第6章 オブジェクトストレージ（S3／Glacier）

S3バケット／オブジェクトとストレージクラス

  • S3（Amazon Simple Storage Service）

    • スタンダード（標準）クラス
    • 低冗長化（Reduced Redundancy Storage;RRS）ストレージクラス

  • ※この本では言及してないが、Black Beltで最新は以下の４種類

ストレージクラス 特徴 耐久性
スタンダード 複数箇所にデータを複製。デフォルトのストレージクラス 99.999999999%(イレブン・ナイン)
STANDARD-IA（標準低頻度アクセスストレージ） スタンダードに比べ格納コストが安価。いつでもアクセス可能だが、データの読み出し容量に対して課金。IA（Infrequent Access） 99.999999999%(イレブン・ナイン)
Glacier（アーカイブ） 最も低コストだが、データの取り出しにコストと時間を要する。ライフサイクルマネジメントにて指定する 99.999999999%(イレブン・ナイン)
低冗長化ストレージ（RRS） RRSはReduced Redundancy Storageの略。Glacierから取り出したデータの置き場所として利用 99.99%
  • 試験のポイント！
    • S3のストレージクラスには、失われることが許されないデータを格納する用途に適したスタンダードクラスと、失われても再作成可能なデータを格納する用途に適した低冗長化クラスがある！

S3の整合性

S3はオンラインで頻繁に更新されるデータの格納先には向かない

格納されている静的データを何度も読み取るような用途に向いている

新規オブジェクトの追加は「完了」と表示されれば、画面上、lsコマンド上で確認できる

更新、削除は「完了」と表示されても、結果整合性をとるために、画面上、lsコマンド上で前のオブジェクトが表示されたり、削除できていなかったりする

  • 試験のポイント！
    • S3の各操作とデータ整合性について押さえ、整合性を考慮したS3の利用用途を押さえる！

S3のアクセス制限とセキュリティ

  • アクセス管理の方法

    • アクセスコントロールリスト（ACL）
    • バケットポリシー
    • IAM(ユーザ)ポリシー

  • その他

    • 署名（期限）付きURL
      • アクセス許可設定をしていない特定のオブジェクトを指定した期間に限定して公開
      • 用途）商品購入後、期間限定でURLに署名をつけて購入者に渡してダウンロードしてもらう際などに用いられる

オブエジェクトの暗号化とアクセスログ

  • 試験のポイント！
    • S3の暗号化やアクセスログの取得はデフォルトではなく、ユーザの責任の元に実施する！

S3の静的Webサイトホスティング機能

  • Webサイトホスティング機能

    • エンドポイント
      • バケット名.s3-website-リージョン名.amazonaws.com

  • 準備

    • Route53やDNSドメインサービスで名前解決する必要がある

S3のバージョニング機能

  • バージョニング機能

    • S3バケット単位で有効/無効にできる
    • 誤って上書き、削除した場合でも、操作前のオブジェクトを復元できる
    • 有効にした場合、キーの他にバージョンIDが付与される

  • 試験のポイント！

    • S3のバージョニング機能を利用すれば、誤操作などにより上書きや削除をしてしまっても、元のデータを復元できる！

S3のライフサイクル機能とGlacierへのアーカイブ

  • 普段アクセスしないものは、より安く運用できる「Glacier」へ移動

  • 格納方法

    • ライフサイクル機能
      • 指定日数が経過したら、Glacierに格納、削除といった操作ができる機能
    • SDKを利用して直接格納

  • 試験のポイント！

    • Glacierは参照する頻度の少ないデータを長期間保管するのに適している

  • 章末問題

第7章 データベース（RDS／ElastiCache／DynamoDB）

マネージド・サービス

  • マネージド・サービスとは

    • 利用者が自身でOSやミドルウェア/ソフトウェアをインストールすることなくサービスを利用でき、サービスの可用性や拡張性、バックアップやパッチ適用といった管理作業の多くをAWSが管理してくれるサービスのこと

  • RDSはマネージド・サービスで、他にもELBやSQSなどが存在する

マネージド型データベースサービス

  • AWSが提供するマネージド型データベースサービス
    • Amazon RDS：リレーショナルデータベースサービス
    • Amazon DynamoDB：NoSQLデータベースサービス
    • Amazon ElastiCache：インメモリキャッシュサービス
    • Amazon Redshift：データウェアハウスサービス

※最新では、Amazon Neptuneというサービスも存在する（フルマネージドのグラフデータベースサービス）

RDS

  • 種類

    • Amazon Aurora
      • MySQLとPostgreSQLとの互換性のあるエンジン
    • MySQL
    • MariaDB
      • MySQLから分岐（フォーク）して作成された
    • PostgreSQL
    • Oracle
    • Microsoft SQL Server

  • 特徴

    • １）マルチAZ配置
      • 複数のAZにRDSインスタンスを配置して可用性を高める機能（マスタ-スレーブ構成）
      • MySQL、MariaDB、PostgreSQL、Oracleでは同期物理レプリケーション、
      • SQL Server では同期論理レプリケーションを使用してマスタからスレーブにデータ同期
      • スレーブデータは完全にスタンバイ状態で、読み取りもできないので、読み取り性能を上げたい場合は、リードレプリカや、ElastiCacheを利用すること
      • マスタに障害や停止が発生した場合、フェイルオーバーが開始される。フェイルオーバーの過程で、RDSインスタンスのCNAMEがマスタースレーブに付け替えられます
      • AuroraのマルチAZ配置は、マスタ-スレーブ構成ではなく、３つのAZにまたがるクラスターボリュームが作成され、各AZにクラスターデータのコピーが格納される
    • 試験のポイント！
      • RDSのマルチAZ配置の特徴、フェイルオーバー時の挙動を押さえる！
    • ２）自動バックアップ機能
      • RDS標準機能で、１日１回自動的にデータのバックアップを取得する
      • 取得中は多少の読み書き遅延が発生する可能性があるので、利用者は、バックアップウィンドウと呼ばれる設定項目でバックアップが取得される時間帯を選択する
      • バックアップの保持期間はデフォルトで７日間。０～３５日間の間で指定する（０を選択するとバックアップが取得されない）
      • RDSはトランザクションログも自動的に取得しており、１日１回の自動バックアップとトランザクションログを利用して、設定している保存期間の特定時点のデータを持つRDSインスタンスを復元可能
      • トランザクションログは５分に１回永続ボリュームに書き込まれている
    • 試験のポイント！
      • RDSの自動バックアップ機能のメリットを押さえる！
    • ３）パッチ適用
      • 自動パッチ適用機能を有効にしておくと、メンテナンスウィンドウと呼ばれる設定項目で指定した曜日/時間帯にパッチが適用される。
      • パッチ適用時に数分のダウンタイムが生じることがあるが、RDSをマルチAZ配置にすることで、先にスタンバイにパッチがてきようされ、フェイルオーバーした後に旧マスタ-でパッチが適用されるため、その影響を軽減できる
      • 利用者がパッチ適用を有効/無効に設定できるが、重要なセキュリティ脆弱性が発生した場合は自動的に適用されることがある
    • ４）ストレージ
      • RDSのストレージも、EBSのストレージと同様に、種類がある
      • General Purpose SSD
      • Provisioned IOPS SSD
      • Magnetic（Black Beltに「下位互換のためサポート」と記載あり）
      • （具体的な数値についてはBlack Beltを見たほうがよいため割愛）

DynamoDB

  • マネージド型のNoSQLデータベースサービス

  • 特徴

    • ストレージ容量が必要に応じて自動的に拡張
    • 秒間あたりのI/O性能を指定できる
    • ストレージはSSDのみで安定したI/O性能を提供
    • データを３つのデータセンタに複製することで高可用性と高い耐久性を提供
    • 読み込み整合性の強弱を指定することで、性能と整合性のバランスを選択

  • 拡張性

  • 冗長性

  • 整合性（結果整合性）

  • ユースケース

    • セッションデータ
    • ゲームの点数
    • 買い物リスト（買い物かご）
    • センサーデータ

１つの項目の実データは最大400KBまで

１つ１つの項目に対応する実データサイズが大きくなる場合は、実データをS3に保管して、DynamoDBにはS3の格納先URLや格納日付といったメタデータを格納するということもできる

  • 試験のポイント！

    • DynamoDBのメリットとユースケースを押さえる！

  • DynamoDBはリージョンサービス

    • プライベートサブネットからのアクセスはNATインスタンスを経由する

  • 試験のポイント！

    • DynamoDBのアクセス制御はIAMで行い、EC2インスタンス上で実行されるプログラムの認証には、IAMロールを活用する

ElastiCache

  • 種類

    • Memcached
      • Key-Value Store形式
      • キャッシュクラスタ構成
    • Redis
      • Key-Value Store形式
      • マスタースレーブ構成

  • ElastiCacheはAZサービスでサブネットグループに配置

  • アクセス制御はセキュリティグループとサブネットのルーティングルール

  • 試験のポイント！

    • ElastiCacheのメリット/ユースケースを押さえる！

  • 章末問題

第8章 AWSにおける監視と通知（CloudWatch／SNS）

CloudWatchによるモニタリング

  • CloudWatchとは

    • モニタリングサービス

  • メトリックス（監視項目）

    • EC2インスタンスのCPU利用料
    • EBSのディスクI/O
    • S33の格納オブジェクト総数
    • RDSインスタンスのCPU利用率
    • RDSインスタンスのメモリ空き容量
    • RDSインスタンスのストレージ空き容量
    • DynamoDBに書き込まれたユニット数
    • など。。。

  • CloudWatchは各種AWSリソースから送られてきたモニタリングデータを保存し、メトリックス毎にグラフ化して表示することができる

  • 保持期間は２週間、それ以降のデータは破棄されてしまうため、月次のモニタリングレポート必要な場合は、保持期間内にCloudWatchからモニタリングデータをダウンロードしておく必要があります。

EC2のモニタリング

CloudWatchはあくまで、AWSリソースから送られてきたデータを保存/可視化するサービスであるため、CloudWatchにデータを送る仕組み/機能をEC2インスタンスや、RDSインスタンスなどのAWSリソース側で用意する必要がある

RDSはマネージドサービスであり、デフォルトで様様なモニタリングデータを収集して、CloudWatchに送信するエージェントがインスタンスに導入されている

EC2はマネージドサービスではないため、デフォルトではハイパーバイザが収集できるモニタリングデータのみを収集してCloudWatchに送っている

  • 標準（デフォルト）メトリックス：ハイパーバイザが取得してCloudWatchに送信するメトリックス
    • CPUクレジット利用数（CPUCreditUsage）
    • CPUクレジット累積数（CPUCreditBalance）
    • CPU利用率（CPUUtilization）
    • １秒あたりのDisk読み込み回数（DiskReadOps）
    • １秒あたりのDisk書き込み回数（DiskWriteOps）
    • インスタンスストレージの読み取りバイト数（DiskReadBytes）
    • インスタンスストレージの書き込みバイト数（DiskWriteBytes）
    • 受信したバイト数（NetworkIn）
    • 送信したバイト数（NetworkOut）
    • OS/インフラストラクチャステータスチェックの成功(0)/失敗(1)（StatusCheckFailed）
  • カスタムメトリックス：OSにインストールしたエージェントが取得して、CloudWatchに送信するメトリックス

参考）よくある質問「カスタムメトリックスとは」

https://aws.amazon.com/jp/cloudwatch/faqs/

カスタムメトリクスとは、Amazon CloudWatch でモニタリングするためにお客様自身が用意するメトリクスのことです。

カスタムメトリクスを使用してモニタリングできるものの例としては、ウェブページのロードに要する時間、リクエストエラー率、
インスタンス上のプロセスやスレッドの数、アプリケーションで実行された作業の量などがあります。

カスタムメトリクスを使用するには、PutMetricData API を使用します。Windows および Linux 向けのモニタリングスクリプトのサンプル、CloudWatch プラグイン集が用意されているほか、AWS パ>ートナーからも多数のアプリケーションやツールが提供されています。

  • 基本モニタリング
    • ３種類のステータスチェックは１分間隔、その他は５分間隔
  • 詳細モニタリング
    • 標準メトリックスをすべて１分間隔（ただし、追加料金が必要）
  • 試験のポイント！
    • EC2の標準メトリックスや基本/詳細モニタリングを押さえる！

アラームとアクション

  • CloudWatchの各メトリックスに対して、アラームを設定することができる

    • 閾値を超えた時に所定のアクションを呼び出す

  • アクション例

    • メールなどの通知（Simple Notification Service）
    • Auto Scalingポリシー（EC2インスタンス数の増減）
    • EC2アクション（停止/削除/再起動/復旧）

  • アラームの３つの状態

    • OK
    • アラーム（ALARM）
    • 不足（INSUFFICIENT_DATA）

  • 設定例

    • EC2インスタンスの１分間のCPU利用率の平均が閾値の７０％を３期連続（３分間連続）で上回っている場合に、EC2インスタンスを２台増やすAutoScalingポリシーのアクションを呼び出す
    • など。。。

  • 重要！

    • CloudWatchのアラームとアクションについて、特徴と代表的な利用の流れを押さえる

SNS

  • SNS(Amazon Simple Notification Service)

    • ユーザやアプリケーションにメッセージを送信できる
    • CloudWatchのアラームアクションとしてメッセージを通知することもできる

  • 押さえるべき３つの用語

    • メッセージ
      • 通知するメッセージ
    • サブスクライバ
      • 受信者を指し、サポートされているプロトコルは次の通り
        • Eメール
        • SMS
        • HTTP/HTTPS
        • SQS（Simple Queue Service）
        • Lambda（サーバ無しのプログラムコード実行サービス）
    • トピック
      • 単一/複数のサブスクライバをまとめたもの

  • 利用例

    • １．SampleTopicというシステムのアラートが通知されるトピックを作成し、運用管理者のEメールアドレス/メーリングリストをサブスクライバとしてSampleTopicに登録
    • ２．CloudWatchでシステムのEC2インスタンスをモニタリングし、１分間の平均CPU利用率が８０％を１回超えたというアラームが発生すると、SampleTopicにメッセージを通知するアクションを設定
    • ３．該当するEC2インスタンスのCPU利用率が８０％を超えてあアラームが発生すると、「CPU利用率が８０％を超えてアラームの状態がOKからALARMに遷移した」というメッセージをSampleTopicに送信
    • ４．SNSはSampleTopicに登録されている運用管理者のEメールアドレス/メーリングリスト（サブスクライバ）にメッセージを送信
  • 章末問題
    • WEbサーバとして利用しているEC2インスタンスの標準メトリックスとして正しいものは？
      • [誤]メモリ使用率
      • [誤]Webページへのロード時間
      • [誤]Webサーバのプロセス/スレッド数
      • [正]Network I/O

※デフォルトは、ハイパーバイザが取得できる値のみ。メモリの使用率は、OSで収集する必要があります。

第9章 AWSにおける拡張性と分散／並列処理（ELB／Auto Scaling／SQS／SWF）

密結合と疎結合

  • 通常のオンプレでWeb-AP-DBサーバーの3Tier構成を組むと、サーバー間が密結合担ってしまう。
  • AWSではサーバ間を疎結合にするために、負荷分散装置を用いて、WEBサーバ、APサーバのインスタンスが入れ替わっても問題ないように３Tier構成を組む

  • そのためのサービスをELB（Elastic Load Balancing）という（マネージドサービス）

  • 重要！

    • コンポーネント間を疎結合にして伸縮自在性を実装し、AWSのメリットを活かすシステム構成にする！

ELB

  • 機能

    • 複数のAZにまたがる負荷分散
    • EC2インスタンスのヘルスチェック
    • ELB自体の自動スケーリング
    • SSLのオフロード
    • Connection Draining
    • アクセスログ記録
    • スティッキーセクション

  • (1)複数のAZにまたがる負荷分散

  • (2)EC2インスタンスのヘルスチェック
    • 補足）EC2インスタンスを再起動した際、ELBのヘルスチェック間隔によってインスタンス異常と判定され、そのインスタンスのトラフィックが行われなくなり、再起動後もトラフィックの再開をしなかったが、2015/12にEC2インスタンスのELBへの自動再登録が可能になった

  • (3)ELB自体の自動スケーリング

    • ELBは、受信するトラフィックの流量に合わせて自動的にその実態を増減させる
    • ELBの実態はサブネットの中に作成される
    • 割り当てられるIPアドレスはサブネットの中から採番されるが、同時にDNS名が付与され、DNS名で通信される
    • 実態はサブネットの中にあるが、AZ間をまたいで通信されるため、AZの間にELBのアイコンを書くことがおおい

  • (4)SSLのオフロード

    • SSL証明書はEC2インスタンスに配置するのではなく、ELBに配置して一元管理する

  • (5)Connection Draining

    • ELBが配下のEC2インスタンスの登録解除をするときに、新規のリクエストについてはそのインスタンスへのトラフィックの送信を停止し、登録解除前にそのインスタンスで処理中だったリクエストについては完了まで待つようにする機能です。
  • (6)アクセスログ記録
    • ELBにはアクセスログ収集機能があり、S3バケットに保存することで、アクセスログを一元管理できる

  • (7)スティッキーセクション

    • ELBには、スティッキーセクションという、システムにアクセスしているクライアントを特定のEC2インスタンスに紐付けできる機能がある。
    • 例）ユーザ認証が必要な会員WebサイトをEC2インスタンス上に構築し、その前段にELBを配置するとする。クラアイアンとは会員Webサイトにアクセスした際に、ELBに割り振られたEC2インスタンスのWebサーバ上でユーザ認証手続きを行います。ユーザ認証に成功すると、Webサーバ側でセッション情報が保持されるため、クライアントが会員Webサイト内で別ページを閲覧して、再度Webサーバに要求が送られても、Webサーバはセッション情報を参照することで、認証済みであることが確認でき、改めてユーザ認証を行わずにすむ
    • →ただし、この方法は「伸縮自在性を実装」に影響を及ぼすので、注意が必要。
    • 「各コンポーネントが特定の状態を持たいない（ステートレス）」であることが重要。スティッキーセクションの代わりに、DynamoDBや、ElastiCacheを利用するほうが懸命

  • 試験のポイント！

    • ELBの機能/特徴を理解して、ELBによるシステムの可用性向上メリットを押さえる！

分散／並列処理

ある１台のEC2インスタンスでは性能が不足する場合の対処方法２つ

  • (1) スケールアップ：インスタンスタイプを変更し、より高スペックに

  • (2) スケールアウト：EC2インスタンスの台数を増やして分散処理させる

  • スケールアップの問題点

    • EC2インスタンスを一旦停止する必要があり、１台のインスタンスの場合は業務を停止する必要がある
    • 最終的にはスペックの限界がある
    • １台のインスタンスでは「故障に備えた設計で障害を回避」を実践できない構成になる
    • システム負荷が減少した際に、スケールアップしたインスタンスタイプではオーバースペックになる。スケールダウンするためには再度EC2インスタンスを一旦停止する必要がある

  • 試験のポイント！

    • 分散/並列処理できる処理は並列化して業務を効率化する！

Auto Scaling

  • Auto Scaling

    • EC2のインスタンスでAuto Scalingグループというグループを構成し、設定に従って自動的にEC2インスタンスの台数を増減させる
    • 負荷が現象した際は、スケールインすることでコストメリットを図れる
    • Auto Scalingの利用料金は無料で、起動したEC2インスタンスの利用料金のみ費用が発生する

  • ユースケース

    • 負荷に基づいた利用
    • スケジュールに基づいた利用
    • 正常なEC2インスタンスの台数を維持するための利用

  • Auto Scalingのコンポーネント

    • 起動設定（Launch Configration）
      • どんなEC2インスタンスを起動するのか？という設定
        • AMI
        • インスタンスタイプ
        • IAMロール
        • CloudWatch詳細モニタリング
        • ユーザデータ
        • IPアドレス
        • ストレージ（EBS、インスタンスストア）
        • セキュリティグループ
        • キーペア
        • など、、
    • Auto Scaling Group（Auto Scalingグループとは異なり、設定項目）
      • どこに、どんな規模のグループ？という設定です
      • EC2インスタンスが起動するサブネットや特定のELB配下など、どこに？の設定
      • 最小/最大台数などグループの規模を定める設定
        • スタートのグループサイズ（EC2インスタンス数）
        • サブネット（AZ）
        • ELB（ヘルスチェック設定も含む）
        • 最小/最大グループサイズ（EC2インスタンス数）
        • など、、
    • Auto Scaling ポリシー
      • いつ、何台増減させるか？という設定
      • 例えば、負荷に基づく設定であれば、CPU利用率のCloudWatchアラームを設定しておき、OKからアラームに状態遷移した際に、アクションとしてAuto Scalingポリシーを呼び出す
        • アラームXが発生した際
        • N台追加/削除
        • 猶予時間（インスタンスの増減後に、次の増減アクションが発生するまでのクールダウン時間）

  • 補足

    • 2015/7にAuto Scalingポリシーに「Step Scaliing」というタイプが追加され、それまでのポリシーは「Simple Scaling」というタイプになった
    • Step Scaling
      • 複数ステップでの増減が可能。まずこうなったら１台増やす、さらに何秒後までに、何％だったら、もう１台増やすのような設定
    • Simple Scaling
      • 条件が１つの設定

  • 試験のポイント！

    • Auto Scalingにおける３つの設定項目を押さえる！

  • Auto Scalingの２つの特徴

    • 正常なEC2インスタンスを希望する台数（Desired Capacity）維持するため、インスタンスのヘルスチェックをかけている
    • Auto Scalingグループが複数のAZにまたがるとき、AZ間でEC2インスタンス数を均等にする

  • Auto Scalingのシュミレーションが記載されている項目がある～

  • スケールアウト時のインスタンス削除ルール

    • １．起動している台数が最も多いAZのインスタンス（大原則）
    • ２．起動設定が最も古いインスタンス
    • ３．次の課金タイミングが最も近いインスタンス

  • 試験のポイント！

    • Auto Scalingにおける大原則を押さえ、EC2インスタンスの増減がどの様に発生するかを押さえる！

SQS (Amazon Simple Queue Service)

  • ELBと並んでコンポーネントを疎結合にする要素で、AWSで分散/並列処理を行う上で重要なサービス

  • 特徴

    • (1)Pull型（ポーリングされる必要がある）
      • アプリケーションにポーリングされる必要がある
    • (2)順序性の保証はしない（FirstInFirstOutが保証されない）
      • 順序性は保たれない
    • (3)最低１回配信保証
      • メッセージはあるアプリケーションによって取得されてもキューから削除されることはなく、アプリケーションがバッチ処理の最後で明示的に削除する必要がある
      • メッセージを取得したアプリケーションがバッチ処理の最中で停止しても、他のノード上のアプリケーションが再度同じメッセージを取得して処理できる
    • (4)可視性タイムアウト
      • あるメッセージを取得したアプリケーションがバッチ処理を実行中に、他のノード上のアプリケーションがキューに残っている同じメッセージを取得して島わあないように、可視性タイムアウトという機能が備わっている。デフォルトで３０秒、利用者による設定も可能
    • (5)メッセージサイズは最大256KB
      • サイズが大きい場合はS3に保存して、SQSにはデータの格納先の情報を格納する

  • SQSはリージョンサービスで、プライベートサブネットからキューのポーリングやメッセージの格納といった操作を行うにはNATインスタンスが必要

  • EC2上でSQSへのアクセスがあるアプリケーションを動作させる場合は、IAMポリシーが設定されたIAMロールをEC2インスタンスにアタッチすることで安全に利用できる

  • 試験のポイント！

    • 分散/並列処理におけるSQSのメリット/特徴を理解し、SQSのユースケースを押さえる！

SWF（Amazon Simple Workflow）

  • マネージド型のタスクコーディネータ

  • 重複が許されない、厳密に１回限りで順序性が求められる処理のコーディネータとしての利用に適している

  • 構成要素

    • ワークフロースターター
      • ワークフローを開始する
    • ディサイダー
      • ワークフロー中の各処理を調整する
    • アクティビティ・ワーカー
      • ワークフロー中の各処理を実行する

  • 試験のポイント！

    • 分散/並列処理における厳密に１回限りで順序性が求められる処理というSWFのユースケースを押さえる！

  • 章末問題

    • ELBのIPアドレスを直接指定してはいけない
    • 予測できない負荷にたいするテストに時間をかけるのではなく、負荷ベースのAuto Scalingを利用することで、負荷に対応する
    • １台のインスタンスを４０時間稼働させる利用料金と４０台のインスタンスを１時間可動させる利用料金は同じなので、可能な限り並列処理を実施する
    • 一時的にAuto Scaling設定がされているEC2インスタンスの台数を増やしたいときに変更するのは？
      • Auto Scaling Group設定
    • 動画トランスコード処理はSQSを利用するべき

第10章 DNSとコンテンツ配信（Route 53／CloudFront）

エッジロケーション

  • AWSにはリージョンとAZ以外に、エッジロケーションというデータセンタが世界に５０箇所以上あります。
  • エッジロケーションには、EC2やS3、RDSといったサービスでなく、Amazon Route 53のDNSサーバやAmazon Cloud Frontのキャッシュサーバが動作している

  • エッジロケーションは数が多いので、AWSインフラストラクチャページで確認する

  • 重要！

    • 世界５０箇所以上のエッジロケーションを利用して、DNSサービスやコンテンツ配信（CDN）サービスが提供されている！

Route 53

  • マネージド型のDNSサービス

  • DNSサービスが53番ポートを利用することからその名前がついている

  • Route53を使用してゾーン/ドメイン情報を登録すると、４箇所のエッジロケーションのDNSサーバにゾーン/ドメイン情報が格納される

  • Route53が管理しているドメインに対してクエリが発生すれば、その４箇所のうちエンドユーザに最も近いDNSサーバが応答する
  • ４箇所のDNSサーバが同時に停止する可能性は限りなく低いため、Route53のSLAは１００％として提供されている
  • 利用料金は、管理しているホストゾーン（従来のDNSゾーンファイル）の数とクエリ回数などの従量課金制となっており、低額から利用可能

  • Route53 レコードタイプ

    • A
    • AAAA(IPv6)
    • CNAME
    • MX
    • NS
    • PTR
    • SOA（Ｓtart Ｏf Ａuthority）
    • SPF
    • SRV
    • TXT
    • ALIAS(エイリアス：AWS独自レコード)

  • Zone Apex（ゾーンエイペックス）：ゾーンの頂点のこと

  • 試験のポイント！

    • Route53の独自レコードであるALIASレコードは、CNAMEレコードでは対応できないZone Apexの名前解決をサポートする！

  • レコードに行える設定

    • 荷重ラウンドロビン
    • レイテンシーベースルーティング
    • 位置情報ルーティング
    • ヘルスチェックとフェイルオーバー

  • 試験のポイント！

    • Route53の各種機能による、リージョンレベルのユースケースを押さえる！

CloudFront

  • CloudFrontはCDNサービス（Contents Delivery Network）
  • 全国５０箇所のエッジロケーションの中の地理的に近い場所からコンテンツをダウンロード
  • アクセス回数とデータ転送量による従量課金制、長期契約や最低利用料金はない

  • CloudFrontではエッジロケーションにキャッシュさせる時間を設定できる

    • 静的なコンテンツについてはキャッシュ時間を長く
    • 動的なコンテンツについてはキャッシュ時間を短く　といった具合

  • サービス提供側のメリット

    • 大量のアクセスが各地のエッジロケーションに分散され、オリジンサーバの負荷が大幅に減少
    • オリジンサーバのリソース削減
    • S3バケットに直接アクセスされるよりもAWSの利用料金を抑えることができる

  • 試験のポイント！

    • CloudFrontの特徴/メリットを理解し、ユースケースを押さえる！
  • CloudFrontを利用したコンテンツ配信においても、CloudFrontのSSL証明書、あるいは利用者独自のSSL証明書を利用した暗号化通信が可能

  • CloudFront経由でエンドユーザに、S3へアクセスさせる際は、バケットポリシーでCloudFrontからのアクセスだけ許可する設定（OAI:Original Accesss Identity）を作成し、OAIからのアクセスだけを許可

  • 試験のポイント！

    • CloudFrontを利用したコンテンツ配信におけるセキュリティ/アクセス制限を押さえる

  • 章末問題

第11章 AWSサービスのプロビジョニング／デプロイ／構成管理（CloudFormation／Elastic Beanstalk／OpsWorks）

CloudFormation

  • CloudFormation

    • プロビジョニングサービス。利用者が用意した定義にしたがってAWSリソースを自動的にプロビジョニングする
    • 自動化により、AWSリソースの構築/管理を効率化できる
    • インフラストラクチャをコード化して、インフラのバージョン管理が可能
    • 利用料は無料で、プロビジョニングされたリソースの利用料金のみ発生

  • 押さえておく用語

    • テンプレート
      • プロビジョニングするリソースを規定するJSON形式のテキストファイル
    • スタック
      • CloudFormationによってプロビジョニングされるリソースの集合/管理単位

  • 試験のポイント！

    • CloudFormationを利用したインフラストラクチャのバージョン管理イメージを押さえる！

  • テンプレートの作成について

    • AWSから提供されるサンプルテンプレートを元に利用者が編集したり、CloudFormerというツールを利用して作成することもできる

  • CloudFormer

    • 利用者のアカウントで現在作成されているAWSリソースを元にテンプレートを作成することができるツール

  • JSONの書き方について～

  • 試験のポイント！

    • CloudFormationで設定できる項目や、エラー発生時の動きなどを押さえる！

Elastic Beanstalk/ OpsWorks

  • Amazon Elastic Beanstalk
    • アプリケーションのデプロイツール
    • アプリケーションのバージョニング管理ができ、既存の環境を以前のバージョンに戻すことができる
    • CloudFormation同様、プロビジョニングされたリソースにたいする課金
  • OpsWorks
    • AWS上のアプリケーションサーバの構成管理ツール
    • ELBやEC2インスタンスを作成し、その後にChefのレシピを実行してソフトウェアのインストールや設定などを自動化できる
  • まとめると
    • CloudFormation
      • VPC以下の構成をプロビジョニング
      • Elastic BeanstalkとOpsWorksを呼び出して一気に設定できる
    • Elastic Beanstalk
      • アプリケーションのデプロイ関連（アプリケーションのバージョン管理）
    • OpsWorks
      • アプリの設定（chefのレシピを実行してソフトウェアのインストールや設定）
  • 章末問題

第12章 EC2の料金モデル（オンデマンドインスタンス／リザーブドインスタンス／スポットインスタンス）

オンデマンドインスタンス

  • デフォルトの課金形式
  • インスタンスが起動しているときに１時間単位で支払いが発生

  • 料金は次の３要素で決まる

    • リージョン
    • インスタンスタイプ
    • OS(Amazon Linux/RHEL/Windows Serverなど)

  • 使用用途

    • 開発/検証環境のサーバ
    • Auto Scalingグループで増減するサーバ
    • １年を通して常時稼働することが求められていないサーバ

リザーブドインスタンス

  • １年あるいは３年契約を結ぶことにより、オンデマンドインスタンスより割安にEC2インスタンスやRDSインスタンス、ElastiCacheノードやRedshiftノードを利用できる
  • RI(Reserved Instance)と略した名称で呼ばれることもある
  • DynamoDBやCloudFrontにも同様の割引方式がありますが、こちらはキャパシティを事前に予約するリザーブドキャパシティといいます
  • リザーブドインスタンスはEC2インスタンスの起動/停止にかかわらず、利用料金が発生

  • 支払い方式

    • 前払いなし
    • 一部前払い
    • 全額前払い

  • 使用用途

    • いつでも確実にインスタンスを立ち上げたい
    • 長期間継続的に利用することが決まっている

スポットインスタンス

  • 入札形式のEC2インスタンスの利用/支払い方式で、需要と供給のバランスによって決まるスポット価格（市場価格）を入札価格が上回ると、EC2インスタンスが利用できる

  • スポット価格の設定項目

    • アベイラビリティゾーン（AZ）
    • インスタンスタイプ
    • OS(Amazon Linux/SUSE Linux/ Windows Serverなど)

  • 入札価格をスポット価格が上回った時、インスタンスはターミネートされる

  • 計算クラスタノードの一部や、Auto Scalingの増加部分のインスタンスなど、突然削除されても問題ないところで利用します。
  • スポットインスタンス上のデータについては、頻繁にチェックポイントを設けて、S3やEBS、DynamoDBといった不揮発性のストレージに書き出す必要があります。
  • EC2インスタンスをターミネートする２分前に通知があるため、その通知をトリガーに外部ストレージに書き出す

  • 重要！

    • スポットインスタンスは、単独で使用するのではなく、オンデマンドやリザーブドインスタンスと組み合わせて利用する！

  • 試験のポイント！

    • 業務（提供サービス）の継続とEC2のコスト最適化の業法を考慮して、オンデマンド/リザーブド/スポットインスタンスそれぞれのユースケースを押さえる！