-
高可用性
-
高可用性の非機能条件①
高可用性の非機能条件②
-
高可用性のトレードオフ
-
単一障害点の排除・基本はELBを利用したマルチAZまたはマルチVPCにより、単一 障害点を排除するアーキテクチャ設計を実施
・マルチAZでマスタースレーブ構成をとって自動フェイルオー バーで切替可能で、かつリードレプリカで負荷を軽減
・インスタンス障害に対してはElastic IPを設定して、同じパブ リックIPを持つ別のインスタンスにIPをフローティングする
-
ELB
-
ELBの主要機能
-
ELBのタイプALB,CLB,NLBの三種類がある
-
CLB(Classic Load Balancer )
-
ALB(Application Load Balancer )
-
CLBとALBの大きな違いCLBはドメインを変えないといけないがALBはパスを変えるだけで良い
-
NLB(Network Load Balancer)NLBは超低遅延で高スループットを維持しながら秒間何百万リ クエストを捌く様に設計された新しいロードバランサ―
高負荷が予想されるシステムに使う。
・L4ロードバランサー
・大規模アクセスが予測される際にCLBやALBで必要だったPre-warming申請が不要 -
Pre-warmingELBはアクセス数に応じて緩やかにスケールしますが、急激なアクセス増加の場合は、スケールアウトが追いつきません。そのため、急激なアクセス増加が見込まれる場合は、事前にELBをスケールアウトさせておく必要があります。
この事前スケールアウトのことを「暖気運転」と呼んでいます。「暖気運転」は「Pre-warming」と記載されていることもございます。 -
Auto Scaling複数のAZを利用してEC2インスタンスをスケールアウト・スケールインできる。
-
スケールインの際の順序
-
クールダウンAuto Scalingが連続で実行されないように待ち時間を設定する機能
→Auto ScalingによりEC2が増えてもすぐにELBにアタッチされないため、すぐにはCPU使用率が下がらないから
-
ライフサイクルフックAuto ScalingによるEC2インスタンスの起動または終了を一時的に待機させ、指定したアクションを実行させることができる。
→起動時に最新のデータをロードするや終了時にログを外部に出力する場合に使用する。 -
ステップスケーリングポリシーCloudWatchメトリクスから得られる値（CPU使用率やSQSキューサイズなど）の閾値を超えて発せられるアラームに対して、値ベースでスケーリングアクションを個別設定できる機能です。例えば、CPU使用率50%を閾値としてアラームが飛ぶとします。この時、報告されてくる値は、50%でも99%でも動作は同じでした。ですから、急激に上がる負荷に対してのんびりインスタンスを追加（クールダウンはデフォルトで300秒）するか、ちょっとだけCPU使用率上がってても沢山インスタンス追加するという、実際のビジネスにあまりフィットしないことがありました。そこで、50%なら1台追加、60%なら2台追加、70%なら3台追加といった具合に、閾値を超えてアラームから報告される値によってスケールする台数を指定できるようになりました。
-
スケジューリングポリシースケジュールされたスケーリングでは、独自のスケーリングスケジュールを設定できます。これは負荷が高まる期間がわかっている際に利用します。
-
Auto Scaling のスケーリングプランいつどのような条件でAutoScalingを実行するか定義する。
-
Auto Scalingの起動設定Auto Scaling実行時に起動するEC2インスタンスの情報を定義する。
使用するAMI, インスタンスタイプ, セキュリティグループ、キーペアなど -
Auto ScalingグループEC2インスタンスの最小・最大・希望数を定義する
-
Auto Scalingの最初の設定AMIの準備から行う。また、AMIを常に最新にしておくことが重要！
ログイン
オンライン単語帳
このページを利用するにはログインする必要があります。ログインするとAnkilotをより便利にご利用いただけます。