AWS Sysops Administratorを取ってきたのでお勉強メモを晒す02

前回から時間が空いてしまったが、メモのバージョン2をさらします。

Serverにログインできるサービス

以下の4つのみサーバーにログインできる * Elastic Beanstalk * Elastic MapReduce * OpsWork * EC2

Elastic Load Balancer Configurations

Sticky session types

2種類のスティッキーセッションタイプがある。 スティッキーセッションはCookieを用いて行うが、そのCookieを誰が管理するかが これらのオプションの違いになる。

Duration Based Session Stickiness

ELBがCookieを払い出す方式。 リクエストに対してまずELBがCookieの有無を確認する。 Cookieがなければ既存のELBの振り分けアルゴリズムに従ってロードバランシングする。 その後、clientにCookieを渡す。このCookieには処理を行ったインスタンスを特定する何かが含まれる。 Cookeiがあれば、そのCookieに基づいて以前処理を行ったインスタンスに処理を流す。

Cookieが有効である限りStickyセッションは継続される。 Cookieの有効期間はStickiness Policyの設定によってコントロールされる。 また、処理するサーバーに問題があった場合もCookieがなかった場合と同様に処理が委譲される。

Application-Controlled Session Stickiness

アプリケーションが指定したCookieを使う。 Cookie名をELB側に教えてあげる必要がある

有効時間が来るまでは、AutoScalingしてインスタンスを増やしても すでに確立されたセッションに従って処理を振り分けるので、 有効時間が長いとなかなかスケールしない問題があるので注意。

ELBでバランシングしているASGroup内部のEC2インスタンスが、処理メトリクスを超えたので スケーリングが走って、EC2が正しくプロビジョニングされても、新しく作成したEC2に負荷が分散されない場合は スティッキーセッションを疑いましょう。 ちなみに、EC2がプロビジョニングされずに落ちている場合はEC2のコンフィグ設定が正しいか？プロビジョニングされ切る前に ヘルスチェックに引っかかってないか？を疑ってみてください。

僕はEBS最適化をサポートされてEC2インスタンスにつけようとしてEC2が永遠に立ち上がらなかったことがあります。

今日はここまで