EC2の複製 3台目以降のエラーについて

Question

プログラミング初心者です。
質問内容に分かりにくい点があるかもしれませんので、足りない部分は聞いていただけると幸いです。

railsで作成したアプリをAWSにVPCを作成してEC2でデプロイしました。
（nginxとunicornを使用)
routes53で独自ドメインを取得しELBのALBを使い、elasticIPに紐づけています。
データべースはRDSインスタンスのmysqlを使用。

公開したアプリが順調だったが、アクセスが多く重くなることがあるため、サーバーの負荷分散を試みました。
イメージからEC2を複製し（同一AZ内）、ターゲットグループに追加したところ、複製元と複製後のインスタンスにアクセスが交互に振り分けられ、アプリも問題なく起動しました。

ところが、EC2をもう一台複製し（同一AZ内）ターゲットグループに追加したところ、トップページには問題なくいけるのですが、アプリの一部の機能が正常に作動しなくなりました（3台とも）

2台稼働の状態では間違いなく正常に動作しているのに、3台にすると動作しません、、、理由に検討がつかず困っています。

うまく動作しない部分は、非常にコードが長いので、一部抜粋しますと、
inputで送信された画像を、gemのminimagick処理した後、
image.write("public/user_images/#{@user.image}")で保存し、その画像を表示するという動作です。
3台体制にすると、ページ自体は遷移するのですが、その画像が表示されません。（2台体制の時は確実に表示されます、、、ちなみにストレージは使用していません。）

画像は一時的に表示されればよく、保存不要なので、ストレージは使用していないのですが、これが原因だったりするのでしょうか、、、
原因や改善方法について御回答いただけると幸いです。

---

【追記】ちなみにアプリの構成は３ページで
①http~.com
②http~.com/users/:id
③http~.com/users/:id/show

①でuserを新規作成し、②で画像を選択③で画像処理を行い、その画像を表示。
この際に、EC2３台体制にすると画像が表示されません、、、

Answer 1

インスタンス間の画像共有が必要ではない、ログインセッションの共有化も必要ない、
ということであれば、手っ取り早そうな解消法としては、TargetGroupの維持設定を有効化することで
同一のEC2に振り向けられるようになるのではないかと思いますが、いかがでしょうか？

Comments

[beer_mineral]

ご指摘のとおり、ログインセッションも画像の共有も必要ないです。本当にありがとうございました。

[beer_mineral]

ご回答ありがとうございました。正に私が求めているものでした。早速設定してみたところ無事に画像が表示されました。本当にありがとうございました。

[winterboum]

変更できるなら、こちらをベストアンサーにしてください

Answer 2

負荷分散はあまり経験がないのですが、書かれている内容を拝見すると２台でうまく行っているのが不思議です。50%確率で発生していたのが67%確率になって目立つようになった、ということでは？
各サーバ間で　Rails.rootを共有しているわけではないと思います（NFSでマウントしているとか)
ということは、public/user_images は各サーバのlocalにあるので、
1)サーバ１が 画像取込みのリクエストを受け、画像を取込み、 html を返す
2) その中に書かれている 画像へのURLへのリクエストがサーバ１以外に回される。そこにはない

これを避けるには

1. ストレージを使う
2. public/user_images をfile共有する
3. <img src= > という新たにリクエストを発行する方法でなく、インラインで画像データを送り出す（そういう方法があるのかどうか知りません）

辺りでしょうか

Comments

[beer_mineral]

ご回答いただきありがとうございます。
どうやら、2台体制の時は、【追記】部分の①→②→③のページ遷移の際に、2台のEC2間を行き来することがないのですが、3台にすると①→②→③の遷移の際にEC2間を行き来するようです、、、（何度も試しました）
これはALBの仕様でどうしようもないっといたところでしょうか？
（アプリとしては一時的に画像が見られればいいので、①→②→③が同一EC2で行われればいいのですが、、、）

ご指摘の通り、ストレージかEC2間のファイル共有をすれば解決しそうです。
（今から簡単に導入できるでしょうか、、、泣き）

【追記】2台体制でもEC2間行き来するんですかねやっぱ、、、（普通に考えればそうですよね）

[siruku6]

画像をバイナリ化してDBに保存することは可能です。
そうすれば、どのEC２からもその画像を出力することができます。

が！！画像枚数や総画像容量が大きくなる可能性があるのであれば、やはりS3にアップロードさせるのが妥当そうです。

もしS3に画像をアップロードするのであれば、carrierwave、refile などのgem で行うのが人気なようです。

---

初心者とは思えない手さばきだと感じているので、挑戦してみてもいいのではないかと思います。

[winterboum]

DBに格納して、表示したら削除　で良いのかも。

[KeisukeKoga]

ALBは二台でもちゃんとバランスするので、単に露見していなかっただけですね。

インフラ屋的に言えば、DBへのblobでの画像格納はDBの特性的に不向きなので、個人的にはパフォーマンスやコスト面から言えばS3が正解かと思います。
本件だと一時的なのでDBでもいいような気もしますが、削除系とその処理失敗時のリカバーとか考えるとめんどくさい気分になるのと、DBのテーブルスペースが無駄に肥大化しそう。

まじめにサービスとして作る、ということを考える場合、AWSにベンダーロックインしてしまって構わないなら、
・S3にアップロードする
・アップロードしたS3でPre Signed URLを発行する->URLをDBにでも格納しておく
・Pre Signed URLを用いて画像表示
・ファイル自体はS3のライフサイクルで削除
みたいな感じで済ませるのがストレージ利用の手数としては楽＆画像トラフィックをEC2が持たないので、パフォーマンスが上がる＆S3なのでコスト安い。
ImageMagickの処理をLambdaなどに逃がせばモダンアプリケーションっぽくなってきます。

内容によってはPre Signed URLまで使う必要もなく、S3をStatic Web Hostingで使ってしまい、ファイルをライフサイクルで消すだけでも良い気はしますが。
そのあたりはサービスに求められるセキュリティとの兼ね合いになるかと思います。

Answer 3

アプリはわかりませんが、事象を聞くとインフラレイヤーでは3台のEC2に分散されてサイトの表示は出来るけど、アプリの画像表示に不具合が生じるということですね。
一度、パケットキャプチャのTraffic Mirroringして確認しては如何でしょうか

Comments

[beer_mineral]

ご回答ありがとうございます。Traffic Mirroringについて調べてみます。