AWS認定ソリューリョンアーキテクト アソシエイトの資格取得のために勉強した内容をまとめます。
リージョン、AZ
- サービスレベルが3段階
- リージョンごと
- AZごと
- EBSはAZサービスなので、同じAZ内のEC2のみアタッチすることができる
- どこのリージョンからも利用可能
- ELBはAZサービスなので、リージョン間をまたいで負荷分散はできない
責任分担セキュリティモデル、認証
- 初めに登録したメールがルートアカウント
- なんでもできてしまうのでアカウント内にIAMユーザを作成するのがペスプラ
- IAMポリシーはサービスのアクセス可否設定
- 最も厳しいポリシーが適用されるため、間違えて可と否が登録されていた場合、否の方が反映される
- STS(Security Token Service)
- 一時的に認証情報を付与するサービス
- 利用者の責任におけるセキュリティ対策
- EC2では、OS以上
- 物理ホスト上のハイパーバイザは対象外
- ハイパーバイザとは、物理ホストの上ホストOS無しで置くソフトウェアのこと
- EC2では、OS以上
ネットワーク VPC
- サブネットはAZを跨げない
- ネットワークACLはサブネットに適用し、ステートレス
- セキュリティグループはインスタンスなどに適用し、ステートフル
- ステートレスとステートフルの違いは、ステートレスは、状態を持ってないので、アウトバウンド通信をしても、その戻りについては知らないので拒否される。ステートフルの場合、状態を持っているので、戻りの通信は許可される。
- VPCペア接続はリージョンをまたげない
EC2
- ルートボリュームとは、EC2インスタンスのOSが格納されているボリュームのこと
- AMIには、ルートボリュームのテンプレートやルートボリューム以外のマッピング情報などが含まれている
- インスタンスファミリーとは、インスタンスタイプのグループ群のこと。例えば、汎用、コンピューティング最適化とか
- インスタンスタイプの理解
- https://www.bit-drive.ne.jp/managed-cloud/column/column_22.html
- 通常のEC2インスタンスでは、業務ネットワークの帯域とEBSディスクIOの帯域が競合した状態
- ユーザデータとはOSの起動スクリプト
- EC2がrunning状態になっても、下記の二つのチェックが完了するまでアクセスできない
- System Status Check インフラのチェック
- Instance Status Checks OSのチェック
- インスタンスストアはEC2インスタンスの物理ホストの内臓ストレージで揮発性。よって停止すると消える
- EC2インスタンスには下記二つのタイプが存在
- EBS backedインスタンス ルートボリュームがEBS
- instance store backed インスタンス ルートボリュームがインスタンスストア
- 停止ができない
- s3-backed インスタンスとも言われる
EBS
- EC2インスタンスにアタッチして使用するブロックストレージ
- OS、アプリ、データの置き場所などの用途に利用される
- スナップショット機能によるS3へのバックアップ、ディスクの暗号化機能を提供
- AZ サービスなので、同一AZインスタンスからのも利用可能
- EC2インスタンスに複数のEBSを接続することはできるが、EBSを複数のインスタンスで共有することはできない
- 共有したい場合はEFSなど
- ブロックストレージの種類
- SSD
- 汎用SSD: 負荷が読めないシステム、小規模なDB向け
- プロビジョンドIOPS; 汎用では処理しきれないIO性能を要求。大規模なDD向け。必要なIOPS値を指定可能
- HDD (起動ボリュームには利用できない)
- スループット最適化HDD
- シーケンシャルアクセス時に高い性能を発揮するタイプ。高いスループットを要求するビッグデータ処理に最適
- シーケンシャルアクセスとは、記憶媒体の先頭から順に連続してデータにアクセスすること。よって、後ろに記録されたデータにたどり着くために時間がかかる
- DWH、大規模なETL処理などに利用。サイズは500GiB~
- シーケンシャルアクセス時に高い性能を発揮するタイプ。高いスループットを要求するビッグデータ処理に最適
- コールドHDD
- ログデータ保管、アーカイブ利用。サイズは500GiB~
- スループット最適化HDD
- SSD
- EBSボリュームのデータは AZ 内で複数の HWにレプリケートされており、一般的にはさらなる冗長化のためのRAID構成は不要
- Provisioned IOPS SSDは、EBSのディスク性能を高めるが、ネットワークがボトルネックになるため、EBS最適化インスタンスを使うことが推奨される
- IOPSとはストレージが1秒あたりに処理できるI/Oアクセスの数
- EBS最適化とは、EC2-EBS間の通信を専用のものでつなぐこと。そうすることで、他の通信に邪魔されずにディスク IO性能の安定化につながる
- 旧世代インスタンスを除いてデフォルトでオンになっている
- EBSスナップショットはS3に保存される差分バックアップ
- EC2インスタンス間のネットワーク接続を高速化するための単一AZに作成するグループのこと
- その代わりに単一AZなので冗長性は失われる
- ハイパーバイザとは、コンピュータを仮想化し、1台の物理サーバ上で複数の仮想的なコンピュータを動かせるようにする、制御ソフトウェア
- EC2条で利用するSWのライセンスによってはハードウェアを占有することを求めることもある。また、コンプラ上、同じ物理ホストでEC2を共存しないようにしたい場合がある。こういったときにDedicatedインスタンスを利用する
- 物理ホストに別のアカウントのインスタンスが起動しないことを保証する
- EBSにはリージョン間コピーという機能はないので、別リージョンのEC2にアタッチしたい場合は、スナップショットをとってリージョン間コピーをしてEBSボリュームを復元する
- EBSのスナップショットを取得するときは、データの整合性を保つためにディスクIOを停止する必要があるのでEC2からアンマウントする
- スナップショット取得開始時点のEBSボリューム内のデータを全てキャプチャしてそれ以降の書き込みはキャプチャ対象外となるのでスナップショット取得開始後は取得完了を待たずに再びマウントして使用してもいい
S3
- s3にはストレージクラスがあり、スタンダードはイレブンナインの耐久性
- 同じリージョン内の３箇所のデータセンタに複製されるため
- 低冗長化RRS(Reduced Redundancy Storage)は99.99%の耐久性で少し安い
- 複数のデータセンタに複製されるので、その分データの整合性については注意が必要
- 頻繁に更新される(書き込み、上書き、削除)データの格納先にはs3は向いていない
- put(新規書き込み)の場合、s3から完了が返されると、ちゃんと表示される
- put(上書き)の場合、s3から完了が返されても古いデータが返されることがある
- delの場合、s3から完了が返されても古いデータが残っていることがある
- 読み取りを頻繁に行うのは問題ない
- 機械学習モデルをs3に置いて、それを頻繁に読みに行くのは向いているっぽい
- 頻繁に更新される(書き込み、上書き、削除)データの格納先にはs3は向いていない
- s3のセキュリティ
- ACL
- バケットとオブジェクトそれぞれについて、読み取り書き込みの許可を他のAWSアカウントに与えることができる
- オブジェクトのURLにHTTPSアクセスの許可を与えることができる
- バケットポリシー
- バケットごとに自アカウント内のIAMユーザやグループ、他アカウントのユーザに対してアクセス許可を与えることができる
- 条件付きアクセス許可を与えることもできる
- IAM
- ACL
- s3は署名つきURLを発行して、時間に制限をかけてs3バケット内のオブジェクトにアクセスできるようにできる
- オブジェクトの暗号化
- クライアント側で暗号化してアップロード
- サーバサイド側でaws管理の鍵orユーザ管理の鍵で暗号化
- バージョニングが可能。オブジェクトにバージョンIDが付与される。誤操作で削除しても復元可能
- Glacier
- ほとんどアクセスしないデータを格納する
- ライフサイクル機能を使ってGlacierに格納。一定期間後に削除も可
- SDKを使ってGlacierに格納する
- Vault Lockという機能があり、Glacierに保存されたオブジェクトの書き換えや削除をAWSの機能として禁止させることができ、その期間も自由にポリシー設定することができる。
Lambda
- デフォルトの実行ロールには CloudWatch の CreateLog, PutLog が付与される
RDS
- RDSとはリレーショナルデータベースのマネージドサービス
- RDSのエンジン
- AWS Aurora: MySQLと互換性
- MySQL
- MarinaDB: MySQLからフォークしたOSS
- PostgreSQL
- Oracle
- Microsoft SQL Server
- マルチAZ配置(Aurora以外)
- 複数のAZにRDSインスタンスを配置して可用性を高める
- インスタンスのマスタとスレーブを別々のAZに配置する
- 同期・非同期レプリケーション
- 同期とはマスターへの変更の後にスレーブを変更し確定してから応答
- 非同期とはスレーブへの書き込み完了を待たずに応答
- 論理・物理レプリケーション http://www.intellilink.co.jp/article/column/oss-postgres03.html
- 論理
- データの論理的な変更情報（○○テーブルのUSERID=100の行を□□に変更する、など）をスレーブに送信
- 物理
- データ変更時に生成されるトランザクションログをスレーブへ送信
- トランザクションログにはデータの物理的な変更情報が含まれているのでスレーブに適用することでバイナリレベルで同じ状態にできる
- 論理
- AuroraのマルチAZ
- マスタ - スレーブ構成でなく、3つのAZにまたがるクラスタボリュームを作成し、各AZにクラスタデータのコピーが格納される
- RDSのフェイルオーバ
- RDSインスタンスのCNAMEがマスタからスレーブに自動的に付け替えられるため、利用者側で特に操作は必要ない
- RDSの自動バックアップ機能
- 一日一回自動的にデータのバックアップを取得
- 取得中は読み書き遅延が発生する場合あり
- バックアップウインドウで時間を指定可
- トランザクションログも自動的に取得している
- トランザクションログは5分に一回永続ボリュームに書き込まれる
- RDSのバッチ適用
- メンテナンスウインドウにバッチが適用される
- RDSのストレージ
- EBSと同様にGeneral Purpose SSD, Provisioned IOPS SSD、Magneticの３タイプがある
- RDSはAZサービス
- VPCのサブネット内にインスタンスを起動して、SGやサブネットのルーティングルールによってアクセスを制限する
DynamoDB
- マネージド型のNoSQLデータベースサービス
- NoSQLの特徴としては、RDBでは難しい拡張性が挙げられる
- 一つの項目のサイズが400KBまでなので、大きな実データ自体はs3に保存して、DynamoDBにはそのメタデータを保存するという用途が適している
- リージョンサービスなので、アクセス制御はSGではなく、IAMで行う
ElasticCache
- インメモリキャッシュのマネージドサービス
- AZサービス
- ユースケースとしては、RDSへのクエリ結果をキャッシングしてRDSへのアクセス負荷を軽減することによる読み書き性能向上
Redshift
- 高速、スケーラブルで費用対効果の高いDWHおよびデータレイク分析マネージドサービス
- 拡張された VPC ルーティング
- これが有効でない場合、Amazon Redshift は AWS ネットワークにおけるその他のサービスへのトラフィックを含むトラフィックをインターネット経由でルーティングします。
CloudWatch
- モニタリングサービス
- メトリクスとは監視項目のこと
- EC2は、標準ではハイパーバイザが取得したメトリクスのみCWに送信
- メモリはハイパーバイザでは取得できない
- 標準外のメトリクスを取得させたい場合は、エージェントをインストールする必要あり
- アラームで状態遷移が起こった時にアクションを起こすことができる
- 例として、CPU利用率が70%を超えた時に通知を送るなど
SNS
- サブスクライバとは受信者
- トピックとはサブスクライバをまとめたもの
拡張性、分散、並列処理
- AWSの可用性の考え方は、一台一台のサーバの可用性を高めるのではなく、構成全体として可用性を高めるようにすることを考える
- 負荷増大によるサーバ増加も、各層が直接繋がっていると難しくなるので、ロードバランサをはさむ
- これを疎結合という
ELB
- マネージド型の負荷分散サービス
- ELB配下のインスタンスにトラフィックを分散
- ELBの機能
- 異なるAZにまたがる負荷分散
- 可用性を高める
- インスタンスへのヘルスチェック
- 異常のあるインスタンスへはトラフィックを送らなくなる
- ELBのスケーリング
- ELBにはDNS名を持っており、ELBが増えるたびにIPアドレスと関連づけがされ、減るたびに関連づけが削除される
- SSLのオフロード
- たとえば社内システムとAWSのシステム間でSSL通信をしたいときは、ELBにSSL証明書を配置して、そこにアクセスしてインスタンスにトラフィックを流すようにすれば、一元的に管理できる。これをしないと各EC2にSSL証明書を配置する必要が出て面倒
- Connection Draining
- ELB配下のインスタンスの登録解除をするとき、新規のリクエストに関してはそのインスタンスへのトラフィック送信を停止、登録解除前のリクエストについては完了まで待つ機能
- アクセスログ機能
- アクセスログをS3に保存する機能がある
- スティッキーセッション機能
- クライアントを特定のインスタンスに紐づけることで、認証後に別のインスタンスに振り分けられないようにする
- その代わりに負荷分散がうまく機能しなくなるので注意
- ベストプラクティスでは、各コンポーネントはステートレスの状態であることが重要と言っている
- インスタンスでのセッション情報の保持はステートフルなので、ElasticCacheやDynamoDB等で管理するのが理想
- 異なるAZにまたがる負荷分散
分散並列処理
- スケールアップとは、インスタンスタイプの変更をしてよりスペックの高いインスタンスに変更すること
- 停止する必要がある
- インスタンスタイプにも限界がある
- 可用性が上がるわけではない
- 負荷が減った時に無駄になる
- スケールアウトとはインスタンス数を増やすこと
- 分散、並列化できる処理はスケールアップではなく、スケールアウトをして効率化する方がいい
Auto Scaling
- 自動的にインスタンスの台数を増減させる機能
- 負荷が減少した時はスケールイン(インスタンスの台数を減らす)
- Auto Scaling自体の利用料金は無料
- CloudWatchアラームでCPU使用率などのメトリクスをトリガーにAuto Scalingを発動させることができる
- Auto Scalingの設定項目
- 起動設定 どんなインスタンスを起動するか
- Auto Scaling Group どこにどんな規模のグループを起動するか
- Auto Scaling Policy いつ、何台増減されるか
- Auto Scalingの大原則
- 正常なインスタンス数を維持するためにヘルスチェックをかけている
- 複数のAZにまたがりAuto Scalingグループが作られている時は、AZ間のインスタンス数を均等にする
- ライフサイクルフック
- ライフサイクルフックを使用すると、Auto Scaling グループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行できる
- ライフサイクルフックによってインスタンスが終了される前に一時停止されます。インスタンスが待機状態の間に、たとえば、インスタンスに接続して、インスタンスが完全に終了される前にログやその他のデータをダウンロードできる
SQS
- マネージドメッセージキューサービス
- リージョンサービス
- 疎結合にするためのサービス
- 特徴
- プル型なので、ポーリングされる必要がある
- FFOではない 順序は保障されない
- メッセージサイズの最大は256KB
- メッセージは取得されてもキューから削除されるわけではなく、明示的に削除する必要がある
- 可視性タイムアウト
- あるアプリがメッセージを取得してバッチ処理を流している時に別のアプリがキューにある同じメッセージを取得して同じ処理をできない時間を設定できる
DNSとコンテンツ配信
エッジロケーション
- リージョンやAZ以外の50以上のデータセンタのこと
- Route53のDNSサーバやCloudFrontのキャッシュサーバ、WAFのサーバが動作している
Route 53
- マネージドDNSサービス
- DNSサービスが53ポートを利用するからこういう名前になった
- ゾーン、ドメイン情報を登録すると、4箇所のエッジロケーションのDNSサーバに格納される
- エンドユーザに近いDNSサーバが応答
- Aレコード、CNAMEレコードをサポート
- ドメイン名： IPアドレス = 1 : N の関係
- IPアドレス；ドメイン名 = 1 : N の関係
- Aレコード
- ドメイン名と対応するIPアドレスをドメイン名：IPアドレス = 1 : N で定義する、同じIPと別ドメイン名を並べて定義すればIPアドレス；ドメイン名 = 1 : N の関係も可能
- CNAMEレコード
- すでにAレコードで定義されているドメイン名と別名を定義する
- つまり、Aレコードとは本来のドメイン名とIPの関係を定義、CNAMEはドメイン名と別ドメイン名をつけることができる
- ELBやS3などの自ドメイン(Zone Aphex)はALIASレコードでエンドポイントを指定する
- 加重ラウンドロビン
- 各レコードに重み付けをして、ある名前に対するクエリに指定された比率で異なる値を応答する
- レイテンシーベースルーティング
- クライアントがURLにアクセスした時に、レイテンシが小さくなるリージョンのELBのDNS名が返される - ヘルスチェック機能があり、名前解決しているサーバなどが動作しなくなったらそのIPを返さなくなる
CloudFront
- コンテンツネットワークデリバリーサービス
- 50カ所以上存在するエッジロケーションにコンテンツをキャッシュし、コンテンツにアクセスするエンドユーザは地理的に近いエッジロケーションからコンテンツをDLすることで高速なDLが可能になる
- コンテンツが格納されているs3、インスタンスをオリジンサーバという
- オリジンサーバとしてオンプレもあり
- 地理的に近いエッジにオリジンサーバからコンテンツをDLしてユーザに返す
- Original Access Identity(OAI)はCloudFrontユーザ
プロビジョニング・デプロイ・構成管理
CloudFormation
- プロビジョニング(提供)サービス
- テンプレート：リソースを規定するテキストファイル
- スタック：プロビジョニングされるリソースの集合
- CloudFormerはリソースをもとにテンプレートを作成できるサービス
- 並列して作成できるリソースは並列に作成される
- CloudFormationテンプレートで作成した資源が、コンソール等(テンプレート以外の変更方法)で変更された場合、変更を検知する機能(ドリフト)がある。
- 明示的に設定されたプロパティ値のドリフトのみを検知するため、ソースプロパティのデフォルト値は含まれない。
Elastic Beanstalk
- アプリのデプロイツール
- ELB, EC2, S3, RDS
OpsWorks
- 定番構成の構築・アプリデプロイの自動化サービス
- ELBやEC2インスタンスを作成し、その後にChefのレシピを実行してSWのインストールや設定などを自動化できる
AWSの料金モデル
- オンデマンドインスタンス
- 時間課金
- リージョン
- インスタンスタイプ
- OS によって価格が異なる
- リザーブドインスタンス
- 起動時間にかかわらず、一定額事前に払う
- スポットインスタンス
- 入札形式
- AZ
- インスタンスタイプ
- OSによって価格が異なる
- 入札価格がスポット価格を上回ればインスタンスが起動する。逆に入札価格をスポット価格が上回ればターミネートされる
- インスタンスのターミネート2分前にインスタンスのメタデータに通知されるため、それをトリガーに外部ストレージに書き出す