T2T2’s diary

アウトプット

210115学習アウトプット　AWS：高可用性の定義【コンピューティングサービス】

 
  
◎高可用性の定義【コンピューティングサービス】
◯コンピューティングサービス
　・Aamzon EC2(EC2)
　　→EC2インスタンス＝仮想に構築されたオンプレミス環境
　
　・Auto Scaling
　　→複数のAZを利用してEC2をスケールアウト・スケールインする
　　　EC2はAutoScalingグループで指定したサブネットで動作する
　　　：スケールアウト…EC2インスタンスを増加させる（※アウトで増加に注意）
　　　：スケールイン　…EC2インスタンスを減少させる（※下記の優先順位）
　　　　　　　　　　　　　①EC2が一番多いAZからランダムにAZを選択
　　　　　　　　　　　　　②EC2が同じであれば、最も古いEC2のAZを選択
　　　　　　　　　　　　　③EC2が複数あれば、次の課金が発生するまでの時間が短いEC2を選択
　　　　　　　　　　　　　④次の課金が発生するEC2が複数あれば、ランダムに選択
 
　　※スケールインの設定だけでは意図できない動作に対して
　　　：クールダウン　　　　…増加させたEC2が完全に起動するまで、次のAuto scalingを実行させない機能
　　　：ライフサイクルフック…Auto scalingを一時的に待機させて、指定したアクションを実行させる
 
　・CloudFront
　　→エッジロケーションからコンテンツを配信するCDNサービス
 
　・AWS Lambda(Lambda)
　　→サーバーを起動することなくコードが実行できるサービス
　　　起動時間に対して料金が発生し、処理時間に限りがある（15分）ため、時間を要するサービスには不向き
 
 
◯VPCリソースにおける高可用性コンピューティング
　→さまざまなサービスをつなぎ合わせることにより可用性の高いシステムを構築できる
 
　・ELB
　　→EC2やAZ、特定のIPアドレスへの通信トラフィックを分散するロードバランシングサービス
　　　自動的にスケールされ、接続にはVPCエンドポイント（VPC内のサービスを繋げる方法）を利用
　　　VPCの中での利用なのでAZは跨げるも、リージョンを跨ぐことはできない
 
　　・RDSインスタンス障害発生時の挙動（AZの展開によって挙動が変化する）
　　　：シングルAZのRDSに障害が発生した場合…自動で再起動＋データ復元はユーザーでポイントインタイムリカバリ機能
 
　　　：マルチAZのRDSに障害が発生した場合　…自動でスレーブにフェイルオーバー（別のAZにあるスレーブと同期して切り替えられる、切り替えの際にダウンタイムが発生する）
　　　
　　　：データベース内のレコードが破損した場合（レコードが壊れているため自動復旧出来ない状態）
　　　　①破損したRDSのエンドポイント名を控えて、別のRDSを作成する
　　　　②バックアップから（S3のスナップショット）、新規RDSエンドポイントにリストアする
　　　　③破損したRDSを削除する（エンドポイント名を引き継がせる）
 
　　　：インメモリデータベースを（ElastiCache）持つWebアプリケーションにおける構成例
　　　　→Cacheという名前から、Webセッション情報や一時的な情報の領域
　　　　　RDS同様に自動的にスレーブフェイルオーバーをおこなう（エンドポイント名は同じ）
 
◯グローバルサービスにおける高可用性コンピューティング
　・Route53を利用したWebアプリケーションにおける構成例
　　：DNSフェイルオーバーの構成例
　　　→ELBのヘルスチェックを受けて、DNSレコードをELBからS3に変更して「Sorryページ」を表示する（名前解決）
　　
　　：Route53によるマルチAZの構成例
　　　→Route53＋EC2（Elastic IPを紐付け＝Aレコードで名前解決をする）の構成とする
　　　　1つのEC2とIPを紐づけて、AZごとに接続をする（AZごとダメになったら、もう一つのAZへ的な展開をする）
 
　　：Route53によるマルチリージョンの構成例
　　　→AZを超えて、リージョンごとにも可用性を実現できる
　　　　世界中へアクセスを分散させたりと、コストを考えなければ高い可用性を実現できる
 
　・CloudFrontを利用したWebアプリケーションにおける構成例
　　：CloudFrontにキャッシュ（静的Webサービス）しておき、必要な動的サービスのみオリジンとルーティングする
　　　→オリジンサーバーに負担を分散させるという意味で記述