Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
合格対策 AWS 認定ソリューションアーキテクトアソシエイト_読書メモ

AWS と認定プログラム

AWS 上にシステムを構築する上で、オンプレとは異なる 7 つのベストプラクティスがある

  • 故障に備えた設計で障害を回避
  • コンポーネント間を疎結合で柔軟に
  • 伸縮自在性を実装
  • すべての層でセキュリティを強化
  • 制約を恐れない(IT リソース量の制限などオンプレミスとは考え方を変える)
  • 処理の並列化を考慮
  • さまざまなストレージの選択肢を活用

リージョン・アベイラビリティゾーンと AWS サービス

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

  • アベイラビリティゾーン(AZ)・・・AWS が保有する物理的なデータセンタ群のこと
  • リージョン・・・複数の AZ が存在する世界 13 箇所の地域のこと

1つのリージョンの中に複数の AZ があり、それぞれの AZ は地理的にも電力的にも独立している
サーバやデータを AZ 間で冗長的に配置することで、可用性の高いシステムを構築することができる

AWS サービスとリージョン・AZ

AWS の各種サービスには、次の3つのサービスレベルがある

  • リージョンごとに作成・管理されるリージョンサービス
  • AZ ごとに作成・管理される AZ サービス
  • どこのリージョンからでも共通のサービスとして利用できるグローバルサービス

1つのリージョン内の AZ サービス間であればプライベート IP アドレスで接続できる
リージョンサービスの場合、基本的にはグローバル IP アドレスで接続しなければいけないので注意

責任分担セキュリティモデルと AWS における認証(IAM)

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

AWS 上のシステムを不正アクセスなどから保護するには、利用者と AWS が協力してセキュリティを高める必要がある
この考え方を AWS では責任分担(共有)セキュリティモデルと呼んでいる
利用者と AWS の間で、システムのどの階層まで責任を分担するかはサービスによって異なる

  • インフラストラクチャサービス・・・ハードウェア部分までを AWS が管理(例:EC2)
  • コンテナサービス・・・ハードウェア、OS、ミドルウェア部分までを AWS が管理(例:RDS)
  • アブストラクトサービス・・・ハードウェアからソフトウェア部分までを AWS が管理(例:S3、DynamoDB)

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

AWS 内のユーザ管理や AWS リソースに対するアクセス制御を行うためのサービスを AWS Identity and Access Management(IAM)という
AWS アカウントを取得したら、まず、IAM でグループ(IAM グループ)やユーザ(IAM ユーザ)を作成する
そして、IAM グループや IAM ユーザごとに AWS の各種リソースに対するアクセスの可否(IAM ポリシー)を設定する
日常の操作にはルートアカウントを使用せず、ユーザを使用すること

  • 各 IAM グループ・IAM ユーザには、最小権限のアクセス権を与える
  • IAM ポリシーは最も厳しいポリシー(拒否)が優先される

AWS サービスを利用する方法には下記の三種類があり、いずれも認証が必要

  • マネジメントコンソール:ユーザ名、パスワードで認証
  • AWS CLI(コマンド):アクセスキー、シークレットアクセスキーで認証
  • AWS SDK(プログラム):アクセスキー、シークレットアクセスキーで認証

SDK での認証には、IAM ロールの利用が推奨されている
IAM ロールは、EC2 インスタンスなどに割り当てることができる
IAM ロールを割り当てられた EC2 インスタンス上のプログラムは、アクセスキーとシークレットアクセスキーがなくとも IAM ロールに許可されている AWS のリソースにアクセスできる

ID フェデレーション

AWS には Security Token Service(STS)という一時的に認証情報を付与するサービスがある
STS と ID ブローカ(ID プロバイダ)を利用すると、以下のようなことができる(ID フェデレーション)

  • ユーザが社内の ID ブローカにアクセス
  • ID ブローカが社内の ID ストア(Active Directory など)でユーザ認証
  • ID ブローカが STS から一時的な認証情報を取得する
  • 一時的な認証情報を使ってユーザが S3 バケットにファイルをアップロード

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

AWS におけるネットワーク(VPC)

VPC の機能と設定

EC2 インスタンスに AWS 外からアクセスできるようにするには、以下が必要

  • EC2 インスタンスに IP アドレスを適切に割り振る
  • 外部ネットワークから EC2 インスタンスに到達できるよう適切にルーティングする

このようなネットワーク環境を提供しているサービスを Amazon Virtual Private Cloud(VPC)という
VPC 環境を構築するステップは以下の通り

  • VPC(プライベートネットワーク空間)の作成
  • サブネットの作成
  • ゲートウェイの作成
  • ルートテーブルの設定
  • NAT インスタンスの作成

VPC(プライベートネットワーク空間)の作成

リージョンを指定してプライベートネットワーク空間を作成する
プライベートネットワーク空間は /16 から /28 の CIDR ブロック範囲で作成できる

サブネットの作成

VPC の中にサブネットを作成する
サブネットは、その中に配置するサーバの役割(機能)に応じて作成するのが一般的
同じ役割のサブネットを複数の AZ に作成し、サーバを各 AZ に冗長的に配置するのが一般的

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

ゲートウェイの作成

VPC と外部ネットワークの間で通信を行うための出入り口となるゲートウェイを作成し、VPC にアタッチする

  • インターネットゲートウェイ(IGW)・・・インターネットとの出入り口になるゲートウェイ
  • バーチャルプライベートゲートウェイ(VGW)・・・オンプレミスと VPN や専用線で通信するための出入り口となるゲートウェイ

ルートテーブルの設定

  • パブリックサブネット・・・インターネットとのアクセスを許可するサブネット
  • プライベートサブネット・・・インターネットとのアクセスを許可しないサブネット

各サブネットがパブリックなのかプライベートなのかは、ルートテーブルによって決まる
デフォルトゲートウェイ(送信先:0.0.0.0/0)のターゲットとして IGW が設定されたルートテーブルがサブネットに適用されていれば、そのサブネットはパブリックサブネットである
デフォルトゲートウェイ(送信先:0.0.0.0/0)のターゲットとして IGW が設定されていないルートテーブルがサブネットに適用されていれば、そのサブネットはプライベートサブネットである

NAT インスタンスの作成

プライベートサブネット内からインターネットやリージョンサービスにアクセスさせるには、 NAT(Network Address Translation) インスタンスを利用する
NAT インスタンスは、プライベート IP アドレスを NAT インスタンスに割り振られたグローバル IP アドレスに変換し、インターネットへのアクセスを可能にする
EC2 インスタンスを NAT インスタンスとして利用するためには「送信元/送信先チェック」機能を無効にする必要がある(流れてきたトラフィックが自身の IP アドレスか否かをチェックする機能)

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

VPC のサブネット内に起動する EC2 インスタンスには、そのサブネット内のプライベート IP アドレスが割り振られる
EC2 インスタンスにインターネットからアクセスしたい場合、グローバル IP アドレスを割り振る必要がある
グローバル IP アドレスには以下の二種類がある

  • Public IP・・・EC2 インスタンスが起動した際にランダムに割り振られる動的なグローバル IP アドレス
  • Elastic IP・・・アカウントに割り当てられる固定のグローバルIPアドレス。EC2 インスタンスにアタッチ/でタッチが可能

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

セキュリティグループとは、EC2 や ELB、RDS などのインスタンスごとのファイアウォールのこと
受信(インバウンド)と送信(アウトバウンド)のアクセス制御ができる

  • インバウンド:送信元の IP アドレスと、アクセスを受け付けるポート番号へのアクセスを許可
  • アウトバウンド:送信先の IP アドレスと、アクセス先のポート番号へのアクセスを許可

ネットワーク ACL とは、サブネットごとのファイアウォールのこと
セキュリティグループ同様、インバウンドとアウトバウンドのアクセス制御ができる

セキュリティグループはステートフルなファイアウォール
アウトバウンドで許可されて送出したトラフィックの情報を保持しているため、その戻りのトラフィックはインバウンドで許可しなくとも受け付ける

ネットワーク ACL はステートレスなファイアウォール
戻りのトラフィックを通すには、インバウンド/アウトバウンドの設定で許可しておく必要がある

VPC ピア接続

VPC ピア接続とは、2つの VPC を接続する機能
2つの VPC 間で VPC ピア接続を確立すると、双方の VPC に PCX というゲートウェイに相当するものが作成される
ルートテーブルの設定で送信先のターゲットとして PCX を設定することにより、各 VPC 内のサブネット間でプライベート IP での通信が可能になる

VPC ピア接続には以下の制約がある

  • 接続する VPC は同じリージョンに存在する必要がある
  • 接続する VPC のプライベートネットワークアドレス空間が重複していない
  • 一対一の接続である

AWS におけるコンピューティング(EC2・AMI・EBS・インスタンスストア)

EC2 の初回起動と設定

Amazon Elastic Compute Cloud(EC2)とは、AWS に置ける仮想サーバ
EC2 は VPC のサブネット内で起動する AZ サービス

マネージメントコンソールから作成する手順は下記の通り

  • Amazon Machine Image(AMI)の選択
  • インスタンスタイプの選択
  • ネットワーク、IAMロール、ユーザデータなどの設定
  • ストレージの設定
  • タグ付け
  • セキュリティグループの設定
  • ここまでの設定の確認
  • キーペアの選択

AMI の選択

AMI は、EC2 インスタンスを作成する際に必要となる仮想マシンイメージ
AMI には以下のようなものがある

  • AWS が提供する Windows Server
  • AWS が提供する各種 Linux ディストリビューション
  • AWS Marketplace で購入できる各種ソフトウェアのインストール済みのイメージ
  • 利用者が作成したカスタム AMI

利用者は任意のタイミングで、現在利用している EC2 インスタンスのカスタム AMI を取得できる

インスタンスタイプの選択

インスタンスタイプは、EC2 インスタンスのマシンスペックを規定する仮想 CPU コア数やメモリ容量などの組み合わせのこと
そのバランスによってインスタンスファミリーと呼ばれるグループに分けられる

  • t や m などの後の数字・・・インスタンスタイプの世代
  • その後の文字・・・マシンスペックの規模

ネットワーク、IAMロール、ユーザデータなどの設定

ユーザデータは OS の起動スクリプトのようなもので、 EC2 インスタンスの作成時に実行したい処理を設定する
(Apache をインストールして Web サービスを起動しておく、など)

メタデータは、インスタンス ID や IP アドレス、ホスト名など EC2 インスタンス自身に関するデータのこと
実行中の EC2 インスタンスは、設定や管理のためにメタデータを利用することができる
メタデータには以下のようなものがある

  • ami-id・・・インスタンスの作成に使用された AMI ID
  • hostname・・・ホスト名
  • iam/security-credentials/role-name・・・IAM ロール名
  • instance-id・・・インスタンスの ID
  • local-ipv4・・・プライベート IP アドレス
  • public-ipv4・・・Public/Elastic IP アドレス

ストレージの設定

EC2 インスタンスに接続するストレージデバイスを設定する
ストレージデバイスには、EBS とインスタンスストアの二種類があり、これらを追加で接続することができる
EBS の追加は EC2 インスタンスの初回起動後でも可能だが、インスタンスストアの追加は EC2 インスタンスの作成時にしかできないので注意

キーペアの選択

AWS では、EC2 インスタンスにログインするためにデフォルトではキーペアを利用する
キーペアを作成すると、公開鍵と秘密鍵のペアの内、公開鍵は AWS 上に保管され、秘密鍵はローカルにダウンロードされる
EC2 インスタンスの作成時にキーペアを指定すると、公開鍵が EC2 インスタンスに埋め込まれ、秘密鍵を使って ssh 接続可能になる

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

EC2 インスタンスは、下記の通り7つの状態を遷移する

instance_lifecycle.png

EC2 インスタンスの起動時には以下の二種類のステータスチェックが走る

  • System Status Checks・・・インフラストラクチャ(HW、ハイパーバイザ)のチェック
  • Instance Status Checks・・・OS のチェック

この二つのチェックに通ると、「2/2 checks passed」となり、EC2 インスタンスが正常起動していることがわかる

EBS とインスタンスストア

EC2 インスタンスに接続できるブロックストレージには、以下の二種類がある

  • Amazon EBS
  • インスタンスストア

EBS は AZ 内に作成されるネットワーク接続型のブロックストレージで、不揮発性(EC2 を停止してもデータは消えない)
インスタンスストアは、EC2 インスタンスの物理ホストの内臓ストレージで、揮発性(EC2 を停止したらデータは消える)

また、EC2 インスタンスには以下の二つのタイプがある

  • EBS-backed インスタンス・・・OS がインストールされるルートボリュームが EBS
  • instance store-backed インスタンス・・・OS がインストールされるルートボリュームがインスタンスストア

EBS のタイプ

EBS には以下の三種類のタイプがある

  • Genral Purpose SSD:汎用的に使える EBS
  • Provisioned IOPS SSD:10,000 IOPS を超える性能が求められるアプリ・DB 向けの EBS
  • Magnetic:IO があまり発生せずコストが重視されるマシン向けの EBS

EC2 インスタンスを「EBS 最適化インスタンス」というタイプで起動すると、EBS のディスク I/O 専用の帯域が確保され、EBS のディスク I/O を安定化させることができる
Provisioned IOPS SSD では、EBS 最適化インスタンスとする設定が推奨されている

EBS スナップショット

EBS ボリュームは、任意のタイミングでスナップショットを作成することができる
スナップショットとは S3 に保存される EBS 内のデータのバックアップのこと

スナップショットを取得する際には、データの整合性を保つためにディスク I/O を停止する必要がある
Linux であれば対象の EBS ボリュームをアンマウントしてからスナップショットを取得することが推奨されている
スナップショットから EBS ボリュームを復元する際には、元となった EBS とは異なる AZ や EBS のタイプ、大きいディスクサイズを指定して復元することができる

EBS ボリュームは AZ サービスなので、AZ を跨いだ EBS ボリュームの接続は不可能
別の AZ やリージョンで、同じデータが格納されている EBS ボリュームを使用したい場合は、スナップショット経由でやる必要がある

プレイスメントグループ

プレイスメントグループ内に EC2 インスタンスを起動することで、 EC2 インスタンス間のネットワーク接続を高速化できる
ただし、ネットワーク接続を高速化するために冗長性を犠牲にしているので、使う際には注意が必要

Dedicated インスタンス

Dedicated インスタンスは、EC2 インスタンスを起動する物理ホストに、別のアカウントの EC2 インスタンスが起動しないことを保証する
以下のような要件の場合は Dedicated インスタンスの利用を検討すると良い

  • EC2 上で利用するソフトウェアのライセンスによっては、ソフトウェアをインストールするサーバのハードウェアを利用者が占有していることを求めている
  • コンプライアンス上、利用している EC2 インスタンスと他者の EC2 インスタンスが同じ物理ホストで共存することが許可されていない

EC2 インスタンスの利用料金に加えて、リージョンごとの占有料金が発生するので注意

オブジェクトストレージ

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

Amazon Sinple Storage Service(S3)は、安価で非常に耐久性があるオブジェクトストレージ

S3 にデータを保存するには、特定のリージョンにバケットと呼ばれる格納先を作成し、その中に Key-Value Store 形式でファイルをアップロードする
S3 バケットにファイルをアップロードすると、キーを付与したオブジェクトとして保存される
各オブジェクトには URL が付与され、適切なアクセス権限を設定することによって HTTPS に夜アクセスが可能になる

バケット名は AWS の全アカウント(全世界)で一意とする必要がある
すでに存在しているバケットと同じバケット名を用いて新たに作成することはできない

S3 には、格納したデータの利用用途ごとにストレージクラスがある

  • スタンダード(標準)クラス
    • オブジェクトの耐久性が極めて高い(99.999999999%)
      • バケットにオブジェクトがアップロードされると同じリージョン内の三ヶ所のデータセンタに複製されるため
    • 失うことが許されないデータを格納する
  • 低冗長化(Reduced Redundancy Storage:RRS)ストレージクラス
    • オブジェクトの耐久性はやや低い(99.99%)
    • 利用料金を低く抑えることができるメリットがある

S3 の整合性

S3 のデータの整合性は、データに対しどの操作を行うかによって異なる

  • 新しいオブジェクトの書き込み(PUT):書き込み後の読み取り整合性
  • 既存オブジェクトの上書き(PUT):結果整合性
  • オブジェクトの削除(DELETE):結果整合性

S3 はオンラインで頻繁に更新されるデータの格納先には向いておらず、格納されている静的なデータを何度も読み取るような用途に向いている

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

アクセス管理の方法には以下の3つがある

  • アクセスコントロールリスト・・・バケットとオブジェクトそれぞれに対して、読み取り・書き込みの許可を設定する
  • バケットポリシー・・・バケットごとにアクセス許可を設定する
  • IAM(ユーザ)ポリシー・・・IAM 側に S3 へのリソースのアクセス許可を設定する

また、アクセス許可をしていない特定のオブジェクトを指定した期間に限定して HTTPS アクセスで公開する「署名(期限)付き URL」という方法がある

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

S3 バケットに格納されているオブジェクトを暗号化して、データを保護することができる
暗号化の方法には下記の二種類がある

  • サーバサイド暗号化・・・AWS が管理する鍵やユーザが管理する鍵を使って S3 上で暗号化する
  • クライアントサイド暗号化・・・クライアントサイドで事前に暗号化したデータを S3 にアップロードする

S3 バケットへのアクセスログを同じ or 異なる S3 バケットに記録することもできる

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

S3 の Web サイトホスティング機能を利用することで、EC2 を利用するよりも運用の負荷やコストを抑えることができる
エンドポイントは mybucket.s3-website-ap-northeast-a.amazonaws.com みたいに作成される
このエンドポイントを所有しているドメインでアクセスさせるためには、Route53 などの DNS サービスにより名前解決する必要がある

S3 のバージョニング機能

バージョニング機能を有効にしたバケットでは、オブジェクトを誤って上書きしたり、削除した後でも、操作前のオブジェクトを復元することができる
バージョニング機能は、S3 バケット単位で有効・無効を設定できる

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

Amazon Glacier は S3 と同じ耐久性を持ちながら、より低価格で利用できるストレージサービス
削除はしたくないが、普段アクセスすることはほとんどない、というデータは Glacier への格納を検討する
Glacier にデータを格納する方法には以下の二種類がある

  • S3 のライフサイクル機能を使う
  • SDK を利用して直接格納する

Glacier からデータを取り出すには、データのサイズに寄らず 3〜5 時間程度かかるため、取り出しがほぼ必要ないケースに限定して使うのが良い

データベース(RDS・Elasticache・DynamoDB)

マネージドサービス

マネージドサービスを利用することには、以下のような利点がある

  • 利用者が自身で OS やミドルウェア・ソフトウェアをインストールすることなく利用できる
  • 各種管理作業(サービスの拡張、バックアップ、パッチ適用など)の多くを AWS が肩代わりしてくれる
  • サービスの差別化に繋がらない構築・管理作業は AWS に任せて、利用者はコアとなる作業に集中することができる

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

AWS が提供するマネージド型のデータベースサービスには、次の4種類がある

  • リレーショナルデータベースサービス・・・Amazon RDS
  • NoSQL データベースサービス・・・Amazon DynamoDB
  • インメモリキャッシュサービス・・・Amazon ElastiCache
  • データウェアハウスサービス・・・Amazon Redshift

RDS

リレーショナルデータベースのマネージドサービス
次の6種類のデータベース遠近を選択できる

  • Amazon Aurora
  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • Microsoft SQL Server

RDS の主要な機能、および特徴を以下に示す

  • マルチ AZ 配置
  • 自動バックアップ機能
  • パッチ適用
  • ストレージ

マルチ AZ 配置

マルチ AZ 配置は、複数の AZ に RDS インスタンスを配置して可用性を高める機能

マルチ AZ 配置の RDS インスタンスのマスタが停止あるいは障害が発生した場合は、自動的にスレーブへのフェイルオーバが開始される
フェイルオーバの過程で RDS インスタンスの CNAME がマスターからスレーブに付け替えられる
マスターからスレーブへのフェイルオーバのタイミングは以下の通り

  • マスターの障害時
  • パッチ適用などのメンテナンス時
  • 手動で RDS インスタンスを再起動した時

Aurora のマルチ AZ 配置は、マスター-スレーブ構成ではなく、3つの AZ にまたがるクラスタボリュームが作成され、各 AZ にクラスタデータのコピーが格納される

自動バックアップ機能

一日一回自動的にデータのバックアップ(スナップショット)を取る機能

利用者はバックアップウインドウと呼ばれる設定項目でバックアップが取得される時間帯を指定できる
自動バックアップの保持期間は、デフォルトで7日(0〜35の間で変更可能)

RDS では、一日一回の自動バックアップの他に、トランザクションログを自動的に取得しており、一日一回の自動バックアップとトランザクションログを利用して、設定している保存期間の特定時点のデータをもつ RDS インスタンスを復元することができる
トランザクションログは5分に一回永続ボリュームに書き込まれる仕組み

利用者が任意のタイミングでバックアップを取得することもでき、このバックアップは利用者が明示的に削除するまで保持される

パッチ適用

RDS には自動パッチ適用の機能がある
メンテナンスウィンドウと呼ばれる設定項目で指定された曜日・時間帯にパッチが適用される

自動パッチ適用は利用者が有効・無効を設定できるが、重要なセキュリティ脆弱性が発生した場合には、設定に寄らず自動的に適用されることがある

ストレージ

RDS のストレージも EC2 と同様、下記の3種類から選べる

  • General Purpose SSD
  • Provisioned IOPS SSD
  • Magnetic

RDS は AZ サービス
VPC のサブネット内に RDS インスタンスを起動し、セキュリティグループとサブネットのルーティングによってアクセスを制限する

DynamoDB

DynamoDB はマネージド型の NoSQL データベースサービス
主な特徴は次の通り

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

とはいえ、1つ1つの項目のサイズは 400KB を超えることができない、という制限もある
データサイズは小さいが項目数は多い、というものを保存するのに使うのが良い

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

ElastiCache

ElastiCache はインメモリキャッシュのマネージドサービス
Memcached と Redis の2つのキャッシュエンジンを選択して利用できる

ElastiCache の主なユースケースは以下の通り

  • RDS へのクエリ結果をキャッシュして RDS へのアクセス負荷を軽減
  • セッションデータの格納(DynamoDB と同様)

ElastiCache は AZ サービス
VPC のサブネットグループに配置し、セキュリティグループとサブネットのルーティングによってアクセスを制限する

AWS における監視と通知(CloudWatch・SNS)

CloudWatch によるモニタリング

AWS には Amazon CloudWatch というモニタリングサービスがある
CloudWatch のモニタリング結果から、EC2 インスタンスの増減アクションを発生させることができる

CloudWatch には以下のようなメトリクスがデフォルトで集計されている

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

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

EC2 のモニタリング

EC2 のメトリクスは次の二種類に大別できる

  • 標準メトリクス・・・ハイパーバイザが取得して CloudWatch に送信するメトリクス
  • カスタムメトリクス・・・OS にインストールしたエージェントが取得して CloudWatch に送信するメトリクス

EC2 の標準メトリクスは次の12種類

  • CPU クレジット利用数(CPUCreditUsage)
  • CPU クレジット累積数(COUCreditBalance)
  • CPU 利用率(CPUUtilication)
  • 1秒あたりの Disk 読み込み回数(DiskReadOps)
  • 1秒あたりの Disk 書き込み回数(DiskWriteOps)
  • インスタンスストレージの読み取りバイト数(DiskReadBytes)
  • インスタンスストレージの書き込みバイト数(DiskWriteBytes)
  • 受信したバイト数(NetworkIn)
  • 送信したバイト数(networkOut)
  • OS・インフラストラクチャステータスチェックの成功・失敗(StatusCheckFailed)
  • OSステータスチェックの成功・失敗(StatusCheckFailedInstance)
  • インフラステータスチェックの成功・失敗(StatusCheckFailedSystem)

EC2 では、次の二種類の間隔でデータを取得可能

  • 基本モニタリング・・・3種類のステータスチェックは1分間隔、その他は5分間隔
  • 詳細モニタリング・・・標準メトリクスを全て1分間隔(ただし追加料金が必要)

アラームとアクション

CloudWatch の各メトリクスに対して、アラームを設定することができる
アラームとは、事前に設定しておいた閾値を超えた時に、所定の動作を呼び出す状態遷移のこと
アラームを受けて、次のようなアクションを呼び出すことができる

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

アラームには次の3つの状態があり、利用者が設定した期間アラームが持続するとアクションが呼ばれる

  • OK
  • ALARM
  • INSUFFICIENT_DATA

SNS

AWS には Amazon Simple Notification Service という通知のサービスがある
これを使うことでユーザやアプリケーションにメッセージを送信できる

SNS を使う上で抑えるべき用語は以下の通り

  • メッセージ・・・通知するメッセージ
  • サブスクライバ・・・受信者のこと。サポートされているプロトコルは次の通り
    • Eメール
    • SMS
    • モバイルのプッシュ通知
    • HTTP/HTTPS
    • SQS(Simple Queue Service)
    • Lambda
  • トピック・・・単一、複数のサブスクライバをまとめたもの

AWS における拡張性と分散・並列処理(ELB・Auto Scaling・SQS・SWF)

密結合と疎結合

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

ELB

ELB(Elastic Load Balancer) はマネージド型の負荷分散サービス
受信したトラフィックと ELB の配下に配置された複数の EC2 インスタンスに分散する

ELB には次のような機能がある

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

複数の AZ にまたがる負荷分散

ELB では、受信したトラフィックを複数の AZ にまたがって負荷分散することができる

EC2 インスタンスのヘルスチェック

ELB は、配下に配置されている EC2 インスタンスのヘルスチェックを定期的に実行している
異常を検知するとそのインスタンスに対してはトラフィックの分散をやめ、残りの正常なインスタンスにのみトラフィックを分散する
(異常を検知したインスタンスの分析や復旧作業は行わない)

ELB 自体の自動スケーリング

ELB は受信するトラフィックの流量に合わせて、自動的にその実態を増減させる
ELB を作成すると example.ap-northeast-1.elb.amazonaws.com といった DNS 名が作られ、ELB の実態がもつ IP アドレスと関連付けされる
ELB の実態が増えれば、DNS 名と IP アドレスとの関連付けが行われ、実態が減れば関連付けが削除される

SSL のオフロード

クライアントと AWS 上のシステムの間で SSL 通信をしたい場合、ELBに配置して一元管理することができる
(各 EC2 インスタンスに配って回る必要はない)

Connection Draining

ELB が配下の EC2 インスタンスの登録解除をするときに、新規のリクエストについてはそのインスタンスへのトラフィックの送信を停止し、登録解除前にそのインスタンスで処理中だったリクエストについては完了まで待つようにする機能
有効にしておくと、クライアントのリクエスト処理が中断されてしまうことがなくなる

アクセスログ記録

ELB にはアクセスログ収集機能がある
ELB に送信されたアクセスログを S3 バケットに保存することで、アクセスログを一元管理することができる

スティッキーセッション

システムにアクセスしているクライアントを特定の EC2 インスタンスに紐付けできる機能
EC2 インスタンスに状態を持たせることになってしまうので、ベストプラクティス的には非推奨

分散・並列処理

性能が不足する場合の対処方法は、主に以下の二つ

  • スケールアップ・・・インスタンスタイプを変更し、よりスペックの優れた EC2 インスタンスに変更する
  • スケールアウト・・・既存の EC2 インスタンスはそのままに、同じ機能の EC2 インスタンスの台数を減らして分散処理させる

分散・並列化できる処理は並列化(スケールアウト)して、業務を効率化すること

Auto Scaling

Auto Scaling は、EC2 インスタンスで Auto Scaling グループというグループを構成し、設定にしたがって自動的に EC2 インスタンスの台数を増減させる
処理の負荷が増加するようであれば、負荷に応じてスケールアウト(サーバ台数を増やす)することで、並列処理が進む
負荷が減少した際はスケールイン(サーバ台数を減らす)することで、コストメリットを図れる

Auto Scaling には次のようなユースケースがある

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

Auto Scaling には、次の3つのコンポーネントが存在する

  • 起動設定・・・どんな EC2 インスタンスを起動するか?
  • Auto Scaling Group・・・どこに、どんな規模のグループを作るか?
  • Auto Scaling ポリシー・・・いつ、何台増減させるか?

起動設定

以下のような項目を設定できる

  • AMI
  • インスタンスタイプ
  • IAM ロール
  • CloudWatch 詳細モニタリング
  • ユーザデータ
  • IP アドレス
  • ストレージ(EBS、インスタンスストア)
  • セキュリティグループ
  • キーペア

Auto Scaling Group

以下のような項目を設定できる

  • スタートのグループサイズ(初期 EC2 インスタンス数)
  • サブネット(AZ)
  • ELB(ヘルスチェック設定も含む)
  • 最小・最大グループサイズ(EC2 インスタンス数)

Auto Scaling ポリシー

以下のような項目を設定できる

  • アラーム X が発生した際(OK からアラームに繊維した際)・指定した日時
  • N 台追加・削除
  • 猶予時間(インスタンスの増減後に、次の増減アクションが発生するまでのクールダウン時間)

Auto Scaling には次の2つの特徴(大原則)がある

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

SQS

Amazon Simple Queue Service はマネージド型のメッセージキューサービス

SQS には次のような特徴がある

  • Pull 型(ポーリングされる必要がある)
  • 順序性の保証はしない
  • 最低一回配信保証
  • 可視性タイムアウト
  • メッセージサイズは最大 256KB

SWF

Amazon Simple Workflow(SWF)は、マネージド型のタスクコーディネータ
重複が許されない、厳密に一回限りで順序性が求められる処理のコーディネータとしての利用に適している

SWF は次の3つの要素から構成される

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

DNS とコンテンツ配信(Route 53・CloudFront)

エッジロケーション

AWS には、リージョンと AZ 以外に エッジロケーションというデータセンタが世界に50箇所以上ある
エッジロケーションでは、Route 53 の DNS サーバや、CloudFront のキャッシュサーバ、AWS WAF のサーバが動作している

Route 53

Route 53 はマネージド型の DNS サービス
正・逆引きの名前解決(ゾーン管理)のほか、ドメインの登録ができる

Route 53 を利用してゾーン・ドメイン情報を登録すると、四箇所のエッジロケーションの DNS サーバにゾーン・ドメイン情報が登録される
Route 53 が管理しているドメインに対してクエリ(問い合わせ)が発生すれば、その四箇所のうち、ユーザにもっとも近い場所のサーバが応答する(四箇所が全部止まる可能性は限りなく低いため SLA は 100%)

Route 53 は次のレコードタイプをサポートしている

  • A
  • AAAA(IPv6)
  • CNAME
  • MX
  • NS
  • PTR
  • SOA
  • SPF
  • SRV
  • TXT
  • ALIAS

ALIAS レコードは CNAME と同じように機能するが、CNAME では対応できない Zone Apex の名前解決をサポートする
ELB の DNS 名や S3 のエンドポイント名を自ドメインの Zone Apex に関連付けたい場合には、CNAME ではなく、ALIAS レコードを利用すること

Route 53 では、各レコードに次のような設定を行える

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

加重ラウンドロビン

各レコードに重みづけをし、ある名前に対するクエリに指定された比率で異なる値を応答させることができる

名前 レコードタイプ 重みづけ
hitachi-ia.com A 123.123.123.123 70
hitachi-ia.com A 213.213.213.213 30

レイテンシベースルーティング

全世界展開しているようなサービスを複数のリージョンで提供している場合に有効な機能
クライアントへのレイテンシ(遅延)を小さくすることができる

名前 レコードタイプ
hitachi-ia.com ALIAS example.ap-northeast-1.elb.amazonaws.com
hitachi-ia.com ALIAS example.us-east-1.elb.amazonaws.com

位置情報ルーティング

クライアントの IP を元に地理的に近いレコードの値を返す機能
特定の地域にだけコンテンツを配信するような使い方もできる

ヘルスチェックとフェイルオーバ

名前解決している Web サーバなどが正常に動作しなくなった場合、その Web サーバに対するクエリが発生しても、Web サーバの IP アドレス・名前を返さなくなる
事前にフェイルオーバ先の設定をしておくと、フェイルオーバ先の IP アドレス・名前を返すようにできる

CloudFront

CloudFront は CDN(Contents Delivery Network) サービス
全世界に 50 箇所以上存在するエッジロケーションにコンテンツをキャッシュし、エンドユーザから地理的に近いエッジロケーションからコンテンツをダウンロードさせることができる

CloudFront 利用の流れは以下の通り

  • アクセスさせたいコンテンツをオリジンサーバ(S3 や EC2、あるいはオンプレのサーバ)に格納
  • CloudFront ディストリビューションを作成
  • CloudFront ディストリビューションにユーザがアクセス。地理的にもっとも近いエッジロケーションの IP アドレスを返却
  • エッジロケーションにアクセスし、コンテンツがキャッシュされていればそこからコンテンツをダウンロード

CloudFront を利用することで、大量のアクセスが各地のエッジロケーションに分散され、オリジンサーバの負荷が大幅に減少する

CloudFront を利用したコンテンツ配信においても、CloudFront の SSL 証明書、あるいは利用者独自の SSL 証明書を利用した暗号化通信が可能
S3 バケットのコンテンツに直接アクセスさせるのではなく、CloudFront を必ず経由するように制限することも可能
(S3 のバケットポリシーに Original Access Identity(OAI)を作成すれば OK)

AWS サービスのプロビジョニング・デプロイ・構成管理(CloudFormation・Elastic Beanstalk・OpsWorks)

CloudFormation

AWS CloudFormation はプロビジョニングサービス
利用者が用意した定義(コード)にしたがって AWS リソースを自動的にプロビジョニングする
自動化により、AWS リソースの構築・管理を効率化できる他、インフラストラクチャをコード化して、インフラのバージョン管理が可能になる

CloudFormation を利用する上で抑える用語は以下の2つ

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

テンプレートは CloudFormer というツールを利用して作成することもできる
スタックの途中で失敗した場合、デフォルトでロールバックする仕組み(そこまでに作成した全てのリソースを削除する)

Elastic Beanstalk・OpsWorks

AWS Elastic Beanstalk はアプリケーションのデプロイツール
EB で構築できる AWS リソースは次の通り

  • ELB
  • EC2 インスタンス(Auto Scaling Group)
  • S3 バケット
  • RDS(オプション)

などなど

AWS OpsWorks は、AWS 上のアプリケーションサーバの構成管理ツール
ELB や EC2 インスタンスを作成し、その後に Chef のレシピを実行してソフトウェアのインストールや設定などを自動化できる

EC2 の料金モデル(オンデマンドインスタンス・リザーブドインスタンス・スポットインスタンス)

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

オンデマンドインスタンスは、EC2 インスタンスのデフォルトの課金方式
EC2 インスタンスが起動している時間だけ、一時間単位で支払いが発生する

オンデマンドインスタンスの一時間あたりの料金は、次の3つの要素で決まる

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

オンデマンドインスタンスは、一年を通して常時稼働することが求められていない用途での利用が向いている

リザーブドインスタンス

リザーブドインスタンスは、一年あるいは三年契約を結ぶことにより、オンデマンドインスタンスよりも割安に EC2 インスタンスや RDS インスタンス、ElasticCache ノードや Redshift ノードを利用できる課金方式
RI(Reserved Instance)と略した名称で呼ばれることもある

リザーブドインスタンスでは、EC2 インスタンスの起動・停止に関わらず利用料金が発生する
料金の支払い方法と契約期間は次の通り

  • 全額前払い・・・契約期間は一年あるいは三年
  • 一部前払い・・・契約期間は一年あるいは三年
  • 前払いなし・・・契約期間は一年

一般に、年間稼働率が 70% を超えるようであれば、リザーブドインスタンスの方が料金を低く抑えることができる(と言われている)

スポットインスタンス

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

スポット価格は次の項目ごとに設定されている

  • アベイラビリティゾーン
  • インスタンスタイプ
  • OS(Amazon Linux、SUSE Linux、Widnows Server など)

スポットインスタンスは、入札価格をスポット価格が上回った場合、自動でターミネートされる
単独で利用するのではなく、オンデマンドやリザーブドインスタンスと組み合わせて利用するのが良い

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.