以前取得したAWS認定ソリューションアーキテクトアソシエイトの有効期限が切れそうで、再認定のための勉強をはじめました。

試験でポイントになりそうなことを、どんどん列挙してこうと思います。都度更新していきます。

では、早速書いていきます。

いろいろ

• AWSでは密結合よりも疎結合が推奨される。簡単に言うと、密結合とはシステム内の各サーバやアプリが密接に関係しているような状態で、1つ故障すると他の2,3つに影響してしまうような構成を言う。
• この「疎結合にすべき」という考え方は、7つのベストプラクティスである「故障に備えた設計で障害を回避」と「コンポーネント間を疎結合で柔軟に」に紐づいてくる。
• 密結合を疎結合にする方法として負荷分散装置（ELB等）の活用が挙げられる。

ELB（Elastic Load Balance）

• マネージド型の負荷分散サービスであり、受信トラフィックを配下の複数のEC2に分散する。
• 負荷に応じて自動的に拡張する。

• 複数のAZに跨って負荷分散ができる。
• EC2インスタンスの正常性確認（ヘルスチェック）ができる。これは負荷分散装置（ロードバランサー）としては当然の機能である。死んでいるサーバにトラフィックを送るわけにはいかない。
• 例えば、AZ-AとAZ-Bに跨るELBを作成しようとすると、共通で使われるDNSが作成される。ELBの実体はAZ-AとAZ-Bにそれぞれ存在し、ELBを経由するアクセスについては、DNSで名前解決されたELBのIPアドレスによって振り分けられる。

• クライアントとAWS上のシステムの間でSSLが利用される場合に、SSLの証明書をEC2インスタンスの代わりにELBに配置することができる。これをSSLのオフロードと呼ぶ。これはプロキシサーバに似ている気がする。ロードバランサもある意味プロキシサーバなので、同様のことが可能と理解した。

• ELB配下のEC2が削除や登録解除された場合に、新規のリクエストについてはそのEC2へ送信をしないようにし、一方でEC2で処理中のトラフィックについては、その処理の完了を待つ機能がある。これをConnection Drainingと呼ぶ。

• システムにアクセスしているクライアントを特定のEC2インスタンスに紐づける機能があり、これをスティッキーセッションと呼ぶ。
• このスティッキーセッションは、例えばとあるクライアントがEC2-Aでログイン（認証）を済ませている場合に、ELBにEC2-Bに割り振られると、そのログイン情報が消えてしまう（ログアウト状態になる）。このような事象を防ぐことができる機能で、ELBがセッション情報を管理することにより、その特定のクライアントについては常に同じEC2へアクセスさせることができる。
• このスティッキーセッションという機能は、呼び名はともあれ、L7ロードバランサには良くある機能である。
• 注意点として、スティッキーセッションは、特定のユーザを特定のEC2と紐づけてしまうため、例えばAuto Scalingで追加されたEC2へトラフィックが分散されなくなる等の可能性がある。つまり、7つのベストプラクティスである「伸縮自在性を実装」するためには、このようにEC2に特定の状態を持たせない状態（ステートレスな状態）とすることが必要である。
• 上記のケースであれば、セッション情報をElastiCacheやDynamoDBを利用する等して、ELBにセッション情報を持たせないようにすれば、回避できる。

スケールアップ vs. スケールアウト

• 結論から言うと、AWSにおいては、既存サーバのスペックを上げるスケールアップよりも、台数を増やすスケールアウトの方が推奨される。
• 理由の1つとして、スケールアップおよびダウンの際には、毎回EC2を停止させる必要がある。
• また、EC2が1台では処理の同時進行は難しいが、EC2が3台あれば並列で処理ができる。例えば、3時間かかる処理があったとして、1台だと3時間だが、3台あれば1時間で終わるかも知れない。
• オンプレミスと異なり、AWSでは無数にEC2の台数を増やすことができるため、このメリットを活かさない理由がなく、また上記の理由により、スケールアウトの方が推奨される。
• これにより7つのベストプラクティスである「処理の並列化を考慮」が達成される。

SQS（Simple Queue Service）

• ELB同様に疎結合な構成にできる要素である。
• 以降、バッチ処理サーバを例に記載する。
• 例えば、とあるフロントサーバからバッチ処理サーバ群にバッチ処理を依頼するとする。その時、フロントサーバとそれぞれのバッチ処理サーバが密に結合していると、バッチ処理サーバの伸縮性が失われる。一方で、フロントサーバとバッチ処理サーバ群の間にSQSを挟むことで、バッチ処理サーバに伸縮性を持たせることができる。
• SQSの特徴として、PULL型というものがある。これは、バッチ処理サーバからポーリングされる必要がある。違う言い方をすると、バッチ処理サーバからSQSに働きかけることで動作するが、SQS自らバッチ処理サーバに処理依頼を送ったりしない。
• SQSは順序性の保証はなく、例えばA,B,Cの順でSQSに処理依頼を送っても、A,B,Cの順で処理されるとは限らない。これはSQSが冗長化されて複数のストレージにメッセージが保存されているからである。
• SQNは最低1回の配信保障がある。バッチ処理サーバにポーリングされたメッセージは、バッチ処理サーバの削除操作が行われるまでキューから削除されない。そのため、バッチ処理中にバッチ処理サーバが故障しても、他のバッチ処理サーバが再度同じメッセージを取得してバッチ処理を実行できる。
• SQSには可視性タイムアウトという機能があり、とあるバッチ処理サーバが処理中のメッセージを他のバッチ処理サーバが処理開始しないようにするもので、デフォルトでは30秒となっており、利用者による設定変更も可能である。
• SQSに格納できるメッセージは256KBが最大である。このサイズ以上のメッセージを格納したい場合には、例えば処理対象をS3等の外部ストレージに保管して、そのデータへのパスを格納する方法もある。そうすれば、バッチ処理の過程でS3から必要なデータをダウンロードしてくれる。

• SQSはリージョンサービスであるため、プライベートサブネット内からのアクセスにはNATインスタンスが必要となる。
• SQSへアクセスするEC2等には、SQSへのアクセスを許可するIAMポリシーを、SQSアクセス用のIAMロールに設定し、そのIAMロールをEC2に割り当てることで、安全に制御ができる。

SWF（Simple Workflow）

• マネージド型のタスクコーディネータである。
• SWFは厳密に1回限りの実行で且つ順序性が求められる処理に使われる。
• SWFは、ワークフロースタータ、ディサイダー、アクティビティワーカの3つの要素で構成され、ワークフロースタータによりワークフローが開始され、ディサイダーによって各処理の調整を実施し、アクティビティワーカが各処理を実行する。

疑問点等

• DNSによるELBへの振り分けの仕組みが知りたい。おそらくAWSの試験範囲には入ってこないが、ELB作成によって作成されるDNSはどのように（どんなルール・規則で）各ELBにトラフィックを割り振っているのか。名前解決先のIPをELB-AとELB-Bで振り分けているのは分かるが、例えば「今はELB-Aにトラフィックを送るべきだ」等と言った判断機構はこのDNSに存在するのか。それともラウンドロビンか、遅延値か、等。