【AWS】AWSにおける拡張性と分散並列処理
オンプレミス環境でお互いのIPアドレスを登録するなど密接につながっている構成を密結合と呼ぶ
AWSでは機器に障害が起きた場合、即座に自動で危機を交換できる伸縮自在性を大事にしているので密結合はいろいろな面で不便である
なので、できるだけ疎結合になるように構成を行う
ELB
Elastic Load Nalancing
マネージド型の負荷分散サービス
受信したトラフィックを配下のEC2インスタンスに分散する役割を持つ
複数のAZにまたがって負荷分散できる
EC2インスタンスのヘルスチェックを行っており、異常を検知したEC2インスタンスにはトラフィックを送信しない
マネージド型サービスなので高負荷時は自動スケーリングする
自動スケーリングするので接続するときは基本的にはドメイン名でないとならない
SSLのオフロード→SSL通信をしたいとき、ELBに証明書を設置することで配下のEC2インスタンスすべてに接続できる
アクセスログ記録機能があり、S3バケットなどに送って記録する事が可能
Connection Draining→EC2インスタンスをELB配下から切り離すとき、新規のトラフィックは送信しないように、すでに処理中だったら終わるまで待機するようになる。
スティッキーセッション→接続認証ができたらそのクライアントとEC2インスタンスを紐づけるセッションを用意するこで、別EC2インスタンスに接続して再度認証手続きが発生するのを防ぐ
ただしスティッキーセッションを利用すると密結合化するため（認証が通ったEC2を覚えておかなければならないため）セッション情報を別な場所（ElastiChace等）に保存するなどしてEC2をステートレスな状態に保つ必要がある
負荷分散と並列処理
あるインスタンスの性能不足を場合、以下の方法をとることで解消できる
スケールアップ→PCの性能をアップ
スケールアウト→同じ性能のPCを用意して並列処理する
スケールアップはサーバーが1台しかない業務を一旦停止する必要がある
さらに、ハード性能の限界があるため頭打ちになることがある
ということで高負荷時の負荷分散としてスケールアウトしやすい構成をつくる
Auto Scaling
AWSのベストプラクティスとして伸縮自在な構成を組むのに必要
EC2でAutoScalingグループを作成して設定に従って自動的にEC2インスタンスの数を増減できる
CloudWatchのアラームなどをトリガーにして実行可能
→AutoScalingについてもうちょっと深堀が必要
SQS
Simple Queue Service
マネージド型のメッセージキューサービス
とあるパッチ処理を複数のEC2で並列で処理をする場合、EC2インスタンス同士がつながっていると密結合となり伸縮性がなくなってしまう
間にSQSを挟む事でこの問題を回避できる
SWF
Simple Workflow
マネージド型のタスクコーディネータ
商品の発注・請求処理のワークフローのような
重複が許されない厳密に1回限りで順序性が求められる処理のコーディネータとして利用する
