https://www.ap-siken.com/kakomon/03_haru/pm05.html
設問3(1)について
回答とは直接関係ないのですが、指摘1.のように負荷分散装置経由でチャット機能へアクセスすると具体的にどのような問題があって、DNSラウンドロビン方式によってどのように解決されるかご教授いただけませんでしょうか？
よろしくお願いいたします。

この投稿は投稿者により削除されました。(2022.02.14 18:55)

WebSocketがコネクションを張り続けると、ロードバランサでのラウンドロビン方式の場合は、分散対象のサーバに通信が均等になるように順番にリクエストを振り分けるわけですけど、コネクション数を見ていないで振り分けるから、悲鳴を上げているところにも割り当てをしちゃう可能性があるってことです。ただ、ロードバランサの方式でどう使おうとしているのか本文に書いていないので、ただ単にラウンドロビンだったんじゃないか？という推測ですが。
DNSラウンドロビンのは解説に書いていたのでそれでいいんじゃないか？とは思いますが、WebSocket自体がロードバランサとは基本的に相性の悪い仕組みなので何ともな、というとこではあります。
ロードバランサでのリーストコネクション方式（最小コネクション）を選べば、負荷分散装置がコネクション数をチェックして、コネクション数が1番少ないサーバへリクエストを振り分けるから、そっちでもよかった気がしますが・・・。

>負荷分散装置経由でチャット機能へアクセスすると具体的にどのような問題

HTTPでアクセスした場合、ページの表示が完了した時点でコネクションが切断されます。
コネクション切断の後、再度アクセスをすれば、負荷分散装置が状況に応じAPサーバに割り振る役割を担います。

しかし、Websocketの場合、クライアント側が意図的に画面を閉じるなりして、アクションを起こさなければコネクションは維持され、同じAPサーバに接続することになります。
（顧客対応に追われる販売員が即時対応できるようチャット画面ならひらきっぱなしにするかもしれません。）
一度接続が確立されてしまうと、後続処理は、負荷分散の恩恵が受けられないため、本装置の経由の意味がなくなります。

また、コネクションが確立したままでは、負荷分散装置のクライアントから接続要求を受け付けるサーバに負荷がかかり、
本装置が原因で旅行販売システムの既存機能（旅行品の検索）の応答性が悪化する可能性があります。

>DNSラウンドロビン方式によってどのように解決されるか

Websocketの通信が負荷分散装置を経由しなくなるので、本装置の負荷は従来通りでボトルネックの可能性がなくなります。
ただし、Websocketのコネクション確立が維持される仕様は変わりありません。

>本装置の負荷は従来通りでボトルネックの可能性がなくなります。
通信自身のボトルネックが発生し得ないわけではなく、ロードバランサ自体がボトルネックの可能性がない（DNS側で参照するユーザがたくさんいるとそれはそれで偏りが発生する）という限定的なメリットです。
ただし、この偏りは現実世界のもので、IPAの試験的には気にしなくてもよいといえばよいです。

WebSocket on AWS 
Yuta Imai 
Solutions Architect, Amazon Data Services Japan, K.K.
d0.awsstatic.com/webinars/jp/pdf/services/20120921_WebSocket_on_AWS.pdf
ってプレゼンテーションかなにかの資料で、ロードバランサをそれでも使う際のタイミングとして、セッション確立時だけLBを使うというアドバイスがあるので、それも参考にしてください。

このサイトで解説されてますね。こちらの方がしっくりくると思います。
負荷分散装置は、性能の指標として同時接続できる最大コネクション数が決まっています。
コネクションの上限を超えたら、コネクション自体が成立しなくなり、何度もアクセスを
試みてようやく旅行商品の検索が表示されるような状況に陥ると思います。


＜解説＞
指摘1は、WebSocketではTCPコネクションを確立したままにするので、チャット機能の利用が多くなると負荷分散装置の同時接続数が一杯になり、旅行販売システムの既存機能へのアクセスができなくなってしまうという問題です。

GinSanaさん、陽射さん

返信が遅くなってしまい申し訳ありません。
お二人ともご丁寧なご解説ありがとうございました！

負荷分散装置が振り分け先のサーバーの混雑具合を見ないで振り分ける可能性があること、最大コネクション数があることなどとても勉強になりました。