AoA_day2

day2
===

module5 分散環境
---

### 自己構築LBの要件
- 高可用性
- フェイルオーバー
- レプリケーションによる冗長化
- 複数のサーバ、複数のIPが必要

### ELB
- マネージド型負荷サービス
- EC2へのルーティングサポート
- HTTP/HTTPS, TCPプロトコル使用
- IPv4およびデュアルスタックDNS名がある

### LB vs ELB
- L7はサポートしていない
- 自動スケーリング
- 登録

### ELBを選択する理由
- ヘルスチェック
- クロスゾーン負荷分散
- Proxy Protocol
- スティッキーセッション
- Connection draining

### スティッキーセッション
- 機関ベースの維持
- アプリケーション制御によるセッション維持

### Connection draining
- LBは以下の場合にバックエンド院sぬ箪笥への新しいリクエスト送信を停止
  - インスタンス登録が解除されている:登録解除前のリクエストは処理
  - インスタンスが正常でなくなった:新規リクエストはルーティングされなくなるが、既存リクエストは猶予期間があたえられる

### ELBのユースケース
- インターネット接続ロードバランサ
- ELBはDNS名を指定するべき

### 注意事項
- ELBは同一リージョン内のAZでのみ利用

### Route53
- 複数リージョンで負荷分散する場合に利用する

### Route53
- SLA100%
- パブリックインターネット接続DNSサービス
  - 可用性に優れたスケーラブルなDNSサービス
  - 高可用性のためマルチリージョンの負荷分散で利用可能
- グローバル伝播
- DNSドメイン登録サービス

### Route53のサポートルーティング
- ルーティング
- 加重ラウンドロビン
- レイテンシによるルーティング
- ヘルスチェックとDNSフェイルオーバー
- 位置情報ルーティング

### Route53のサポートレコード
- 標準なもの
- エイリアスレコード
  -　CNAMEとは違い、一回でIPアドレスが取得できる
- Zone Apexのサポート
  - DNSは仕様上、a.com のようなリクエストに対してCNAMEは返せるが、

---
module6 データストアの選択

### DynamoDB
- 低レイテンシー
- ホットデータ格納に向いている
- 大規模かつシームレスなスケーラビリティ
- 利用者側でスループットをプロビジョニング
  - 必要な時にスループット容量を科k帳
  - スループットの縮小は１日４回まで(UTCカレンダー)
- 耐久性と可用性
- 完全マネージド型NoSQLデータベースサービ
- GlobalSecondaryIndex

### DynamoDBファイングレインアクセスコントロール
- テーブル、項目、属性レベルでアクセス権限を指定
- WEBIDフェデレーションにより認証を行えるため、プロキシサーバは不要

### DynamoDBのコスト
- インデックスストレージ
- スループット
- リザーブドキャパシティ

### ベストプラクティス
- 項目のサイズが大きくならないようにする
- メタデータはDynamoDB、コンテンツデータ
- 時系列データは日、月、週などの単位で\\
- 条件付き更新またはアプリケーション側でオプティミスティック同時実行制御(OCC)更新を利用する
- ホットキー、ホットパーティションを避ける

### Amazon RDS
- MySQL, Oracle, SQL Server, PostgreSQL, MariaDB, Aurolaが利用可能
- デプロイとスケーリングが用意
  - マルチAZデプロイをサポート
- 信頼性、費用効率が高い
- 運用管理コストの削減

### RDSセキュリティ
- セキュリティグループで制御
- IAMを利用してユーザに対して制御
- SSLを利用して暗号化
- SQLServer, OracleはTDEをサポート
- RDSインスタンスで発生する重要なイベント通知を受信可能
- EBSを利用しているのでボリューム単位で暗号化が可能

### RDSのベストプラクティス
- DBインスタンスクラスを注意して選択
- EBS最適化インスタンスを利用する
- 実稼働ワークロードにProvisionedIOPSを利用する
- 高可用性のためマルチAZを利用する
- 以下のためにリードレプリカを使用する
  - 読み取りのスケーリング
  - クロスリージョンレプリケーション
  - 追加の障害復旧

### ElastiCache
- リードトラフィックのオフロード(Memcached/Redis)
- レイテンシーの低減


module7 ウェブスケールのメディアホスティング設計
---

### 静的アセットをS3に保存する利用
- データ保護[高い耐久性]
  - 冗長化される
  - チェックサムでデータ整合性を確認
  - バー叙任具を使用すれば、あらゆるバージョンのオブジェクトをすべて、保存、取得、復元が可能
- データ整合性モデル
  - 新しいオブジェクトのPUTSに"書き込み後読み取り"整合性を提供尾
  - PUT/DELETEの上書きについては結果整合性
  - ※米国リージョンではすべてのリクエストに対して結果整合性が保障される

### S3の最大限に活用する場合
- リージョン
  - コンピューティングとほかのリソースを同じ場所に配置するとパフォーマンスに影響する
- 命名規則
  - 安定したパフォーマンス
  - 100TPSを定期的に超過可能なバケットが必要な場合
- BitTorrentを使用することも可能

### AmazonCloudFront
- CDNサービス

### CloudFrontを有効にする方法
- 静的コンテンツのCNAMEを分離する
  -
- CloudFrontにすべてのURLを置く
  - 管理が簡単
  - すべてのコンテンツがエッジロケーションを通る

### CloudFrountの機能
- キャッシュコントロールヘッダの利用
  - キャッシュコントロールヘッドセットで、静的、動的コンテンツを識別
- ファイルがエッジロケーションに維持される期間
  - オリジン内のファイルにあるコントロールヘッダで有効期限を設定

### コンテンツを失効させる方法
- 有効期限（TTL）
  - 固定期間
  - 独自設定
  - CloudFrontからOriginへはIf-Modified-Sinceヘッダを利用
- オブジェクト名変更
- オブジェクトの無効化（非効率だし、高価なサービス）

### CloudFrontのエコシステム
- CloudFrontはカスタムオリジンをサポート

### CloudFront カスタムSSLのサポート
- デフォルトでは"https://xxxx.cloudfront.net/[resource]"
- カスタムSSL証明書のサポート機能で独自ドメインと独自SSL証明書を利用できる
  - SNIカスタムSSL
  - 専用IPカスタムSSL

### HTTPSでの代替ドメイン名を使用する場合
- IAM証明書ストアに証明書をアップロード
- ELB/Cloudfront/S3などで利用

### コンテンツをプライベートにする方法
- S3バケット内のオブジェクトへのアクセスを制限
- 署名付きURLの髭右尾をユーザに要求
  - 信頼済みの証明者に対してCloudFrontキーペアを作成
  - 署名付きURLを作成し利用する

### アクセス制限のためのオリジンアクセスアイデンティティ（OAI）
- CloudFrontユーザを意味するOAIを作成して、S3コンテンツへのアクセスを制限


module8 イベント駆動型スケーリング
---

### CloudWatchによるリソースモニタリング
- 分散統計収集システム
- デフォルトでメトリクスはHVレベルで収集
- HVはシームレスに監視される(Hyper-V, Xenで項目に違いはない)
- 独自のアプリケーションおよびサービスにより生成されるカスタムメトリクス
- みれない情報
  - OSの状態、アプリの状態は見れないが

### CloudWatchによるアプリケーションログ格納とモニタリング
- OS,APLのログデータをCloudWatchに投入できる
- CloudWatch Logsと呼ばれている

### モニタリングとアクション
- CloudWatchアラーム
- アクションの種類
  - SNS(Pub/Sub)
  - AutoScalingポリシー
  - EC2アクション
    - 停止・起動・再起動・AutoRecovery

- 監視に関しては別途メインの3rdParty製の監視ソフトで監視を行い、CloudWatchにデータを入れてジョブを実行したりする

### CloudTrailを使用したイベント追跡
- CloudTrailで操作ログを取得できる
- CloudWatch Logs と連携も可能
- S3/SNSを利用するため

- セキュリティ分析
- AWSリソースの変更追跡
- 操作に関する問題の解決
- コンプライアンス対応

### オンデマンドスケーリング: AutoScaling
- Amazonの発想としては需要予測を行わず、柔軟性のあるシステムを構築することを推奨している

### AutoScalingの仕組み
1. 起動設定
  - 名前
  - AMI
  - 等々
2. AutoScalingグループ
  - 起動設定名
  - AZ or サブネット、ロードバランサ
3. アクション設定
  - スケジュールベース（CLIベースでの実施）
  - Metricsベース（CloudWatch）

### AutoScalingに関する考慮事項
- Auto Scalingのスラッシングは回避
  - スケールダウンは慎重にしたほうがよい
- DesiredCapacity パラメータは慎重に設定したほうがよい

### 備考
- CookpadなどではAWSを当初EC2で運用して、マネージドサービスを利用して、その後一部EC2に戻すといった状態で利用している
- AutoScalingでLaunchする場合, アプリの自動起動＋モニタリングシステムへ登録が必要
- Terminatesする場合はログ保存をどうするか考える必要がある

### AWSはAPI駆動型

### CloudFromation
- コードとしてのインフラストラクチャ
- JSON形式のテンプレートをソースコードとして扱う
-