AWS認定SAA試験対策いろいろ(拡張性、分散、並列処理)

以前取得した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に存在するのか。それともラウンドロビンか、遅延値か、等。

よっさん
  • よっさん
  • 当サイトの管理人。ニューヨークの大学を飛び級で卒業。その後某日系IT企業でグローバル案件に携わる。マレーシアに1.5年赴任した経験を持つ。バイリンガルITエンジニアとしていかに楽に稼ぐか日々考えている。

コメントする

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です