Q&A
ご回答ありがとうございます。
他の回答者様が仰るように、Laravelなどのフレームワークを使っていれば、開発環境でローカルPC上に静的コンテンツを保存していたとしても、本番環境ではソースコードの変更なしでS3を利用することは可能だったのでしょうか？(composer.json?などの)AWS用の様々な設定の変更は必要だと思いますが。
ご回答頂ければ幸いです。
前提・実現したいこと
文書と画像の投稿や削除が可能なブログのようなポートフォリオ(LAMP環境、PHPのフレームワークは未使用)をローカル開発環境(docker-composeを利用)で作成完了しました。これから、本番環境のAWS(ECS on Fargate)でphp-apacheコンテナを起動して、RDSでMySQLを利用してデプロイする予定です。投稿画像がwebサーバ(ECS?)内に保存され続けると、webサーバのストレージなどの負担が大きくなるため、webサーバとは分離した「Amazon S3」というストレージサービスに、画像などの静的コンテンツを保存させるべきということが分かりました。
ローカル開発環境では、ホスト(Mac)の「wwwフォルダ」を、php-apacheコンテナ内の「/var/www」にマウントして、「www/html/assets/images/<image名>」や「www/html/assets/css/<css名>」のように、全てのファイルはMac本体に階層構造(ファイルストレージ?)で保存場所をPHPで指定しています。
AWSストレージサービスの利用に関して腑に落ちない点など私の考え・調べたこと
オブジェクトストレージであるS3と、ローカル開発環境のファイルの階層構造とは、互換性がないように思いました。調べるとファイルストレージの「Amazon EFS」を使えば、ローカル環境と本番環境での差異が少なくなりそうだと思いました。
本番環境とローカル開発環境とのPHPのアプリのコードの差異は最小限にしたいです。(できる限り、ローカル開発環境のアプリのコードを書き換えたくありません。)
S3やEFSについて数日調べましたが、「ローカル開発環境では、ローカルPCであるアプリの静的コンテンツの保存場所を、本番環境では、(EC2やECSとは分離された)S3などのAWSストレージにする」ような記事は見つけることができませんでした。
質問
①ローカル開発環境ではPHPで画像やCSSのパスを指定していましたが、本番環境ではPHPのコードを、S3などのAWSのストレージサービス用のパスに変更する必要があるのか？
②もし、ローカル開発環境のPHPのコードを変更せずに、本番環境でS3などのAWSのストレージサービスに静的コンテンツを保存や利用できる場合、画像投稿時にECS内にも「/var/www/html/assets/images/<image名>」のように保存されてしまわないか？(webサーバにも画像が保存され、webサーバのストレージに負担が掛かり、本末転倒のような気がします。)
③私のアプリやローカル開発環境の状況では、AWSストレージサービスは、S3やEFSなど、どれが適していますか？
④アプリに投稿削除機能があるが、S3やEFSなどAWSストレージサービスを利用した際にも、指定された投稿画像がAWSストレージサービスから削除されるか？
⑤上記のことを実現するためのアドバイス、おすすめのサイトや教材などがあれば教えて頂ければ、幸いです。
投げやりな質問になり、大変恐縮です。この件に関して、自分だけでは手も足も出ない状態ですので、ご教授頂ければ幸いです。よろしくお願い致します。
補足情報（FW/ツールのバージョンなど）
ローカル開発環境は、以下の3つのコンテナイメージをdocker-composeを使い、作成しました。
・php:7.2-apache
・mysql:5.7
・phpmyadmin/phpmyadmin:latest
回答6件
0
ベストアンサー
まずはあまり難しいことを考えずに普通にEBSを使うのがいいと思いますよ。S3は使い方にコツがいると思います。フレームワーク（たとえばPHPならLaravelとか）をかますとわりと使いやすいですけどね。EFSは使ってみると分かりますが、あまりアクセスが発生しないファイルで使用すべきで、普通の感じで使うとめちゃくちゃ重たかったり、余計に費用が発生したりします。Dockerからめると別のベストプラクティスがありそうですが、その辺はもう少しDocker力とAWS力を付けてからでいいかと思います。
投稿2021/04/22 04:15
編集2021/04/22 04:16
総合スコア4820
0
オブジェクトストレージであるS3と、ローカル開発環境のファイルの階層構造とは、互換性がないように思いました。
そのとおりです。自分で実装しているのであればコードは書き直す必要があります。
投稿2021/04/22 03:48
総合スコア145930
そうですね、ファイル保存用のライブラリによっては設定変更だけで対応可能なものもあるかと思います。
ご回答ありがとうございます。
バックエンド言語のフレームワークはとても便利ですね！
ポートフォリオ作成を急ぎ、Laravelを学ぶ前に、インフラ関係に手を付けたことを反省します。
全体を俯瞰して学ぶことが苦手ですが、そのことをより意識して取り組みたいと思います。
0
やってることがちぐはぐすぎる。
誰に教えられてこんな意味不明なことしてるのか。
フレームワークも使ってない初心者がDockerやAWSを使うのは早い。
Webサーバーの負担なんて気にする段階じゃない。
ネットの情報に騙されすぎ。
本題のローカルとS3での切り替えはフレームワークの機能として用意されてるので簡単にできる。
投稿2021/04/22 03:10
退会済みユーザー
総合スコア0
ご回答ありがとうございます。
初めてのwebアプリ開発で、分からないことだらけです。
kawaxさんの仰る「フレームワーク」とは、バックエンド言語のフレームワークのことでしょうか？また、そうであれば、ローカルと本番環境(S3)での静的コンテンツの保存先の切り替えは、PHPのみ(バックエンド言語のフレームワークなし)では、不可能ということでしょうか？
不可能ではないですがこの質問をされる方の技術レベルでは筋が悪いものになると思います
0
localstackとは、ローカル開発環境に擬似的なAWS環境を作り、LambdaやS3、DynamoDB等をローカル開発環境にて利用できるようにするツールだと認識しました。
その通りです。
localstack には、AWS で提供されるサービスの集合体です。（すべてのサービスを網羅しているわけではありませんが）
ちなみに、s3 だけなら探せば他にもローカルで動作する s3 互換の OSS がいくつか存在します。
hidoriさんが仰るのは、「localstackを使うことで、ローカル開発環境でも s3 を使用可能になる (ローカル開発環境で s3 を使用するためには、localstackが必須)」という僕の認識で合っていますでしょうか？
違います。
- localstack は、ローカル
開発環境で実行・利用可能な AWS 互換サービスの集合体である - AWS s3 は、ローカル開発環境でも
使用接続・利用することが出来る
はそれぞれ別の話です。
前者は、前述のとおりです。
後者は、例えば「事業所のネットワークから AWS s3 に接続、使用することが可能である」ということです。
投稿2021/04/27 11:57
編集2021/04/28 08:59
総合スコア403
ご回答ありがとうございます。
次回新しくアプリを作る際は、ストレージに、localstackを使ったS3または AWSのS3に接続 または ローカルPC という選択肢を持って、適したサービスを選びたいと思います。
有益な情報ありがとうございます。
0
docker-compose を使っているなら、localstack の利用を検討してみてはいかがでしょうか。
https://hub.docker.com/r/localstack/localstack
また、あるいは、セキュリティや性能面で問題なければ、ローカルの開発環境から AWS s3 に接続して使用することも可能です。
投稿2021/04/27 00:25
編集2021/04/28 09:01総合スコア403
ご回答ありがとうございます。
現時点ではAWS本番環境は、「コンテナなしのEC2上で動かせたら、EBSストレージを利用(アタッチ？)」という構成で進めていこうと思っています。
しかし、hidoriさんのご回答が貴重でとても興味がございますので、もし差し支えなければ、ご教授頂ければ幸いです。
「localstack」というワードを初めて知りました。
localstackとは、ローカル開発環境に擬似的なAWS環境を作り、LambdaやS3、DynamoDB等をローカル開発環境にて利用できるようにするツールだと認識しました。
「ローカルの開発環境から s3 を使用可能」ということは、以前調べたときに気になっていました。
hidoriさんが仰るのは、「localstackを使うことで、ローカル開発環境でも s3 を使用可能になる (ローカル開発環境で s3 を使用するためには、localstackが必須)」という僕の認識で合っていますでしょうか？
0
環境ごとに保存先を分けるのは大抵フレームワークで設定を分けられるのでそのようにやってください。
フレームワークを使わないで自前実装すると地獄を見るのでおすすめしません。
①ローカル開発環境ではPHPで画像やCSSのパスを指定していましたが、本番環境ではPHPのコードを、S3などのAWSのストレージサービス用のパスに変更する必要があるのか？
少なくとも相対パス指定ではできなくなるのでURLを指定する必要があります。
ただ、アップロードを自前で実装したり、表示されるページの画像の指定を直書きでやったりとかしていなければ、そこはフレームワークなりパッケージなりがうまく解決してくれるはずです。
そもそもの話ですが、ローカルでアップロードした画像を本番で参照しない、逆に本番でアップロードした画像をローカルで参照にしないようにすれば何も気にする必要はないのではないでしょうか。
②もし、ローカル開発環境のPHPのコードを変更せずに、本番環境でS3などのAWSのストレージサービスに静的コンテンツを保存や利用できる場合、画像投稿時にECS内にも「/var/www/html/assets/images/<image名>」のように保存されてしまわないか？(webサーバにも画像が保存され、webサーバのストレージに負担が掛かり、本末転倒のような気がします。)
フレームワークや画像保存に使うパッケージ次第なので絶対とは言えないですが、普通はそんなふうにはなりません。
③私のアプリやローカル開発環境の状況では、AWSストレージサービスは、S3やEFSなど、どれが適していますか？
S3とEFSはユースケースが全然違うので並べていることに違和感があります。
個人的な経験としてはEFSは性能問題に引っかかることが多く、アクセスが多く発生するケースでの使用には懐疑的です。
今回のケースだと素直にS3に保存させればいいんじゃないでしょうか。
④アプリに投稿削除機能があるが、S3やEFSなどAWSストレージサービスを利用した際にも、指定された投稿画像がAWSストレージサービスから削除されるか？
アプリやフレームワークの実装次第なのでわかりません。
本来は実装した自分が一番わかっているはずです。
⑤上記のことを実現するためのアドバイス、おすすめのサイトや教材などがあれば教えて頂ければ、幸いです
まずは公式ドキュメントなり、AWS Blackbeltの資料なりを見てサービスの概要を把握してください。
ただ公式ドキュメントがちょっと読みづらいのも事実なので、クラスメソッドのブログもおすすめします。
とりあえず2019,2020に書かれた入門記事の一覧を貼っておきます。
AWS再入門2019
AWS再入門2020
AWSを扱ってるならこのブログを見たことない人はまずいません。
もっともAWS云々より、まずローカルできちんと動かすのが一番最初だと思いますけどね。
投稿2021/04/22 08:44
総合スコア7586
丁寧なご回答ありがとうございます。ご紹介頂いた記事は、以前少し拝見したとき、私には高度な内容のはずですが、とても丁寧な説明で飲み込みやすいと感じました。サーバー、ネットワーク、ストレージ、コンテナ関係の記事はしっかり目を通しておきます。
私の誤解と無知により、どれだけ馬鹿げた設計で開発していたのが、分かりました。PHPフレームワークは学習、使用はしておりません。また、できる限り、ローカル開発環境と本番環境とのソースコードを同じにしておきたいと思っています。まずはPHPフレームワークなしの現状で、AWSへのポートフォリオのデプロイをさせることを目標にしています。
①ローカル開発環境ではPHPで画像やCSSのパスを指定していましたが、本番環境ではPHPのコードを、S3などのAWSのストレージサービス用のパスに変更する必要があるのか？
[yu_1985さんのご回答]
少なくとも相対パス指定ではできなくなるのでURLを指定する必要があります。
ただ、アップロードを自前で実装したり、表示されるページの画像の指定を直書きでやったりとかしていなければ、そこはフレームワークなりパッケージなりがうまく解決してくれるはずです。
そもそもの話ですが、ローカルでアップロードした画像を本番で参照しない、逆に本番でアップロードした画像をローカルで参照にしないようにすれば何も気にする必要はないのではないでしょうか。
[私の返答]
PHPのみ(PHPフレームワークなし)で開発しています。
画像のアップロードは、「/var/www/html/assets/images/hdfxdx.png」のように、PHPの定数(パス)+任意の文字列(画像名)のようにして作って、画像自体をPC保存、画像名はDBに保存しています。画像の参照は、PHPの定数(パス)+DBから取得(画像名)で行っております。おそらく、アップロードを自前で実装したことになりますよね？
PHPフレームワークなしでの開発で本番環境でS3と使う場合、ローカル環境と本番環境では、ソースコードの変更が必要というご意見も頂きました。
他のご回答者様(TakashiAbeさん)のご意見を踏まえ、本番環境のストレージにEBSを利用し、ECS on Fargateでコンテナを利用すれば、エフェメラルストレージ（揮発性）によりEBSの保存データが消えるリスクやローカル環境と本番環境でのソースコードの変更の必要が無くなりそうだと思いました。
私の想定の様になるのであれば、コンテナ利用のECS on Fargateで、ストレージにEBS。想定の様にならなければ、コンテナなしのEC2で、ストレージにEBSを順に検討しています。
yu_1985さんのご意見をお聞かせ頂ければ幸いです。
質問:
本番環境のwebサーバと静的コンテンツの保存場所に以下の選択肢を考えておりますが、現状の私におすすめですか？
①「コンテナ利用のECS on Fargate」と「EBS」
②「コンテナなしのEC2」と「EBS」
③「コンテナ利用のEC2」と「EBS」
④「コンテナ利用のECS on Fargate」と「S3」(ソースコード書き換え？)
⑤「コンテナ利用のECS on Fargate」と「S3」(Laravelを学んでから、適したポートフォリオを作り直す)
⑥その他
ご回答頂ければ幸いです。
※エンジニア未経験での転職のためのポートフォリオとして、作っております。自社開発、受託開発の順で希望しております。
AWSは以下で初歩的なネットワークを中心に学習しました。
https://www.udemy.com/course/aws-and-infra/
Dockerは以下で開発環境構築は自分でできる程度の学習はしました。
https://www.udemy.com/course/aidocker/
フレームワークや何らかのツールなしでやるとかはちょっと考えたくもありません。
何を使うかに完全に依存しますが、全てを環境において変える必要が出てきます。
そのあたりを自前実装するくらいなら何かを使ったほうが絶対にいいです。
本番運用する気なら複雑な仕組みを自前実装する選択自体がすでにかなり厳しいです。
独自仕様によるバグと負債の温床になることが容易に想像できますし、実際そういったケースを散々見てきています。
> 、本番環境のストレージにEBSを利用し、ECS on Fargateでコンテナを利用すれば、エフェメラルストレージ（揮発性）によりEBSの保存データが消えるリスクやローカル環境と本番環境でのソースコードの変更の必要が無くなりそうだと思いました。
残念ながら、その選択は不可能です。EBSは基本的にEC2インスタンスにしかアタッチできませんが、Fargateはコンテナを動かすサーバの部分を抽象化したサービスです。
ECS on EC2ならできるでしょうけど。
Fargateで永続的に保存可能なボリュームをマウントするならEFSしか選択肢がありませんが、EFSには書いたとおり性能問題があります。
> ※エンジニア未経験での転職のためのポートフォリオとして、作っております。
厳しいことをいいますが、だったら四の五の言わずにまずは動くものを作るほうが先ではないでしょうか？
スキルとして何をアピールしたいんですか？
ローカルで動かすか、一旦ECSのことは忘れてEC2上で動かすかどっちかをまずやるべきです。
あと、フレームワークを使えばやってくれる部分を自前実装するという選択肢は基本的に捨ててください。コストがでかすぎます。
まずはそれで慣れて、フレームワークを使っていて不便だなと思ったところは別の選択肢を取るなりツールを作って公開するなりすればよいのではないですか。
また、ECSはそれ自体にハマりどころが多いのでその他の理解が薄いうちにいきなり手を出すのはおすすめしません。
EC2でちゃんと動かせることが確認できてからでも十分でしょう。
ご回答ありがとうございます。
画像のアップロードは、開発者がPHPの関数で保存場所(パス)を指定するコードを書き、実装するものだと思っていました。
フレームワークであれば、画像のアップロードが保存先も含めて機能として使えて、複数環境の違いにも対応しやすくなっているという認識で合っているでしょうか？
ポートフォリオについて
私がスクール出身で、フレームワークなしの状態で卒業制作物をレンタルサーバにデプロイしました。(デプロイはほとんど講師の方のおかげ)
しかし、スクールの卒業制作物をポートフォリオとして自社開発企業や受託開発企業へ転職するのは難しいことを知りました。また、AWSやDockerなどの開発現場でよく使われている技術も取り入れるべきだという情報とフレームワークなしでweb上に公開できた経験で、Laravelは必ずしも必要ないと勘違いして、学習をすっ飛ばして、今回のポートフォリオを開発し始めてしまいました。
このような経緯でLaravelを学習しておりません。長期に渡り勿体ない時間の使い方をしたことを理解しました。
ローカル環境では問題なく動くので、ひとまず、コンテナなしのEC2上で動かせたら、EBSストレージを利用(アタッチ？)するという流れで進めていこうと思います。
> 画像のアップロードは、開発者がPHPの関数で保存場所(パス)を指定するコードを書き、実装するものだと思っていました。
フレームワークであれば、画像のアップロードが保存先も含めて機能として使えて、複数環境の違いにも対応しやすくなっているという認識で合っているでしょうか？
いずれもそのフレームワークの仕様次第としか言えませんが、環境ごとに設定を変えるのはほとんどどのフレームワークでもできます。
画像アップロードについても、フレームワーク標準で対応していたり、あるいはそれとセットでよく使われるツールが大抵どの言語のフレームワークにもあります。
詳しくは自分で作って確かめてみてください。
> しかし、スクールの卒業制作物をポートフォリオとして自社開発企業や受託開発企業へ転職するのは難しいことを知りました
なぜそうなっているのかをもうちょっと考えて欲しいです。
自分が思うのは問題なのはポートフォリオがどうこうではなく、ただものを作っているだけでそこに意図がないからです。
> フレームワークなしでweb上に公開できた経験で、Laravelは必ずしも必要ないと勘違いして
この思考過程が最大の問題です。そりゃ、公開するだけだったらできますよ。
なぜみんなフレームワークを使うと思いますか？既に出来上がっている機能を再開発するのは多くの場合無駄だからです。
学習という観点であればもちろん別ですが。
Laravelに限らず、今のWEBの開発ではフレームワークが切っても切り離せません。
もちろん使うべきでないケースも存在するのですが、思考停止で使う使わないを決めないためにも使い方を知っておく必要があります。
フレームワークの機能がイケてないからそこの部分は自分で実装しました、だったら理解はできます。
> AWSやDockerなどの開発現場でよく使われている技術も取り入れるべきだという情報
こういう情報は参考にするのに、なぜ多くの企業では開発時にフレームワークを使っているという情報は見なかったんでしょうか。
インフラ周りを先に固めたいというのならAWSやDockerを使った環境構築に先に手を出すのは理解できます。
自分の目指す方向を考えた上で優先順位を決めてください。
ご回答ありがとうございます。
私が自分の意思がなく思考停止で開発を進めていたことを具体的に深堀りして頂き、ありがとうございます。
おっしゃる通りです。yu_1985さんからのご指摘は痛いほど刺さります。
使用技術の選定に関して、開発現場でよく使われているということ以外、なぜ使うかを全く考えておりませんでした。
ブログのようなポートフォリオの選定は、私が気になる機能(投稿記事の画像と文章の順番をユーザーが自由に決められる)を自分で実装してみたかったという理由があります。
現状、バックエンドでの転職を考えていますが、インフラ、フロントエンドそれぞれにも面白みを感じています。そうなると今更ですが、フレームワーク(Laravel)は必須ですよね。
早く現在のポートフォリオを公開して、Laravelの最低限学習をして、転職活動をしつつ、Laravelを深く学習しようと思います。
やってしまったことはどうしようもないので、前を向いて進めていこうと思います。
赤の他人にも関わらず、本題のご回答以外にも、私の思考やキャリアについて、親身にご対応頂き、感謝致します。本当にありがとうございます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2021/04/22 09:16
2021/04/22 11:32 編集
2021/04/22 13:35 編集