AWS Auto Scaling
実機学習ではまるでふれることができなかったため理解がしにくい。
概要
コスト最適化や高可用性を実現するために、需要に応じてインスタンスを自動的に増減させるサービス機能。
「AWS Auto Scaling」の中に「Amazon EC2 Auto Scaling」が存在し、EC2のみを特別名称がつけられているようである。
★参考
AWS Auto Scaling（需要に合わせて複数のリソースをスケール）| AWS
Amazon EC2 Auto Scaling（需要に合わせてコンピューティング性能を拡張）| AWS
対象となるサービスは以下の通り。
・Amazon EC2 インスタンス（＋フリースポット）
・Amazon ECS タスク
・Amazon DynamoDB テーブルとインデックス
・Amazon Aurora レプリカ
RDSでは「Amazon Aurora」の場合のみ有効化できると。
Auto Scalingの仕組み
■起動設定
Auto Scaling グループで使用されるインスタンスの設定テンプレート。
EC2インスタンスの設定と同レベルの以下の設定を行う。
・AMI
・インスタンスタイプ
・ストレージ
・キーペア
・セキュリティグループ
・IAMロール
参考：起動設定 - Amazon EC2 Auto Scaling (日本語)
■Auto Scaling グループ
EC2インスタンスに対する論理的なグループをリージョン単位で設定する。アベイラビリティゾーンは跨ぐことはできるが、リージョンを跨ぐことはできない。
ヘルスチェックの置き換えやスケーリングポリシーもこの単位で設定する。
Auto Scaling グループは、インスタンスに異常が発生した場合でも、一定数のインスタンスを維持する。
つまり、起動したインスタンスはアベイラビリティゾーン間で均等になるように調整される。
■手動スケーリング
高負荷な処理が予定されている場合などに、Auto Scaling グループ内で最小、最大起動インスタンス数を設定する。
起動インスタンス数の範囲内で、インスタンスの起動、終了を手動で設定する。
■動的スケーリング
以下の３種のスケーリングポリシーを設定し、CloudWatchの監視によるメトリクスに基づき自動で行わせる。
・Target tracking scaling
特定のメトリクスの設定したターゲット値に基づいて、グループの現在の容量を増減させる。
・Simple scaling
1 つのスケーリング調整値に基づいて、グループの現在の容量を増減させます。
・Step scaling
アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値と呼ばれる) に基づいて、段階的にグループの現在の容量を増減させます。
参考：Amazon EC2 Auto Scaling の動的なスケーリング - Amazon EC2 Auto Scaling (日本語)
■スケジュールスケーリング
特定の時刻や時期にシステム負荷が集中する場合に設定する。
■ヘルスチェック
Auto Scaling のヘルスチェックはEC2かELBに対して設定する。
EC2が起動（running）以外の状態になった場合やELBのヘルスチェックが異常の場合に異常とみなす。
また、Auto Scalingにより管理されているEC2インスタンスを停止する場合、異常の誤検知を防ぐためにTerminate（削除）状態となる。
Amazon Route 53
こいつもまるで振れたことがない。DNSってぐらいしか知らない。
概要
AWSが提供する権威ドメインDNSサービス。
キャッシュDNSと権威DNSを区別した場合の権威DNSなので、ドメイン名からIPアドレスの変換するための情報を実際に保持する。
SLAを100％で定義している唯一のサービスでもある。
一般的なレコードはサポートしているようである。
・Aレコード
・AAAAレコード
・CNAMEレコード
・MXレコード
・NSレコード
・SOAレコード
・TXTレコード
などなど特徴的なものについては後述します。
参考（レコードの種類）：サポートされる DNS レコードタイプ - Amazon Route 53
参考：Amazon Route 53（スケーラブルなドメインネームシステム (DNS)）| AWS
エイリアスレコード
名前だけ見ると別名レコード。DNS関連が私と同じレベルの理解だとCNAMEレコードみたいなものか？？と思ってしまうところですが違いはなんでしょうか。
参考：エイリアスレコードと非エイリアスレコードの選択 - Amazon Route 53
【イメージ図】
以下はだらだらと説明（考察？）
まず前提として、AWSサービスは起動の度にIPアドレスが変わるもの（ELBとか）が存在し、通常のAレコードを設定しただけでは不都合だと。
※もちろん設定次第なものもあると思いますが
これに対して、CNAMEレコードかエイリアスレコードに登録を行う必要がでてくるが、その際の名前解決時にエイリアスレコードではより高速に対処できる。
エイリアスレコードだとクエリの発行を省くことができるらしい。
※らしいというのは実機で確認できていないから
挙動的にはCNAMEレコードの場合、問い合わせを行う別名のホスト名に対して、一度正規のホスト名をクライアントに返却し、クライアントから正規のホスト名で再度名前解決クエリを発行してやっとお目当てのIPアドレスにたどりつく。
エイリアスレコードの場合、別名のホスト名に対するクエリ一回でIPアドレスまでたどりつけるのだと。
だから比較した場合にレスポンスは高速化できる。
挙動的にはAレコードみたいなCNAMEレコードでいいのか（混乱してきた）
また、エイリアスレコードではドメインの最上位(Zone Apex)できる。
一回読んだだけでは？？？でした。
DNSの管理するドメインの範囲がゾーンで、「hatena.ne.jp」ドメインを取得した場合にそのDNSでの管理範囲は「*.hatena.ne.jp」となる。
その際の「hatena.ne.jp」がZone Apexに当たる。
CNAMEレコードにはZone Apexは登録できないが、エイリアスレコードには登録可能である。
なぜ登録できないかは自分の言葉でまとめるには力不足で妥協しました。以下が分かりやすかったと思います。
参考：CNAMEレコードにZone Apexをマッピングできない件について – サーバーワークスエンジニアブログ
実践的には、ELBの背後に存在するEC2に接続する際に、EC2のホスト名をELBに向ける場合とかに使用するんだとか。
試験的にも割と頻出パターンっぽい？
ルーティングポリシー
ほぼそのままなので引用です。
・シンプルルーティングポリシー
ドメインで特定の機能を実行する単一のリソースがある場合に使用する。・フェイルオーバールーティングポリシー
アクティブ/パッシブフェイルオーバーを構成する場合に使用します。・位置情報ルーティングポリシー
ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。・地理的近接性ルーティングポリシー
リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。・レイテンシールーティングポリシー
複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用します。・複数値回答ルーティングポリシー
ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。・加重ルーティングポリシー
定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。
使用するユースケースは思い浮かんだ方がいいけど、一読しただけでは難しそう。
演習しながら詰め込むしかないかなぁ。
DNS フェイルオーバー
DNSフェールオーバーを設定すると、異常なリソースが発生した際に正常なリソースへとトラフィックを変更する（クエリの応答可否を変更する）ことができる。
正常、異常の判断はヘルスチェックにより実施しており、「CloudWatch」によりステータス変更の通知を受け取ることもできる。
ヘルスチェック一つも正常なリソースが存在しない場合、全て正常なリソースと見なしてクエリに応答する。
マジですか？どうゆう想定の機能なんだろう？
参考：Amazon Route 53 ヘルスチェックの作成と DNS フェイルオーバーの設定 - Amazon Route 53
今週は12月になったらペースアップしたいけどどうでしょう。
