Q&A
> インスタンス1 ~ 3にあるrailsの内容はcssの一部以外全て同じです
なぜそのような状況になっているのでしょうか？
お世話になります。
EC2でrailsアプリをインスタンス3つでauto scalingしています。
アクセスすると以下のインスタンス1 ~ 3のうちどれかにつながるのですが
インスタンス1 > A.html.erb : A.css インスタンス2 > B.html.erb : B.css インスタンス3 > C.html.erb : C.css
1回のアクセスで、html.erbはAに、cssはBにつながる、という事は起こるのでしょうか？
(cssは /public/packs/css にあります)
補足：
インスタンス1でcssを編集し
$ rails assets:precompile をしました。
(インスタンス1 ~ 3にあるrailsの内容はcssの一部以外全て同じです)
アクセスするとたまにcssがnot foundでコンソールエラーが出ます。
(体感的に 1/3 の確率でA.html.erb、 2/3の確率で B または C.css => 5回に1回ぐらいnot foundエラー）
分かりにくかったですね、すみません。
・インスタンス1をオリジナルとして、これを元にAMIを作成
・そのAMIでauto scalingでインスタンス2,3を生成
・ロードバランサのターゲットにインスタンス1 ~ 3が登録
という状態です。
本番がすでに動いている為、またAWSをよく分かっていない為、1をロードバランサのターゲットから外すべきだと思うんですが怖くて実行していません。（本番は2ヶ月で終了し閉じる予定）
本番稼働後に先方から修正依頼があった場合（新規ページを作ってbasic認証掛けるなど、ユーザーがそのページへたどり着けないような作業）
この1を修正して本番にupしました。
その際、AMIを作り直して2 ~ 3に反映させればいいのですが、時間が掛かる為しませんでした（先方のOKが出たら全体に反映するつもりでした）
というのが経緯です。
回答2件
0
ベストアンサー
1回のアクセスで、html.erbはAに、cssはBにつながる、という事は起こるのでしょうか？
それは1回のアクセスではありません。HTTPリクエストはHTMLとCSSなど、ファイルごとに行われますので、HTMLとCSSが同じサーバに繋がるかは、全くの偶然です。
なお、Sticky sessionといって、1ユーザーが接続を続けている限りロードバランサーから同じサーバに振り続ける、という設定はあります（AWS公式）。
投稿2021/09/29 04:12
総合スコア146018
理解しました...
確かにファイルごとにリクエストされてますね、、
Sticky session <= 情報ありがとうございます。どうやるのか気になってました。
いつもありがとうございます。
0
html.erbとcssを同一のリクエストで取得しているなら普通そうはならないと思います。
ただ、それぞれを別のリクエストで取得しているなら起こりうるでしょう。
（この辺は実際にどのようなリクエストのやり取りがあるのかをきちんと見たわけではないので、どういう動きが正常なのかは自分からは何も言えません）
これはAutoScalingは関係なく、ELBがどのようにリクエストを振り分けるかというところに関係します。
ELBを使用している前提で書いているのでそうでなければごめんなさい。
not foundになる原因が振り分けのせいかはちょっとそれだけでは何とも言えません。
また、冗長構成の場合静的ファイルは各サーバ上に置かずS3に置いて読み込ませるのも常套手段として使われるので参考にしてみてください。
ちなみに、質問の意図とは恐らく異なるんでしょうが、逆に明示的にパスによってリクエストを振り分けたいのであれば、ALBを使っているならリスナールールで振り分けることができます。
投稿2021/09/28 10:22
総合スコア7588
あなたの回答
tips
プレビュー
