Q&A
ここで言っている「公開領域」とはパブリックサブネットのことではなくWEBページのサーバのことを指していますでしょうか？
いつもお世話になっております。
現在メルカリのようなサービスを作成中でして、環境構築の部分でのインフラ構成で迷いが出てきてしまいお聞きしたいことがございます。
サーバーはAWSを利用する予定です。
今後サービスを公開する上で考えているインフラ構成が以下になります。
今分からなくなっているのは「管理画面」の居場所です。
「Webページ」で公開されるところにLaravelで構築したサービスを乗っける想定で、管理画面を別のEC2インスタンスに設置しようと安易に考えておりました。
理由はWebサービス内に管理画面を置くことをAWSの無料相談を受けた時にセキュリティ的に推奨されなかったのと、その話を聞いた上で公開側と管理側を分けるのは視認性が高いと思ったからです。。
ただ、この場合管理画面をLaravelで作るとした時に同じDBを見るにしてもモデルなど公開側のLaravelと合わせないと整合性保てない気がしておりまして、二重管理になってしまい運用が大変な気がしております。
やはり一つのアプリケーション内で管理画面も作ってしまった方がいいのか、
別サーバーに管理画面を置くとして整合性を保つ良き方法があるのか何かご意見いただけないでしょうか？
プログラミングは地味に長くやっているのですが、インフラ周りは必要にかられ勉強しだしたレベルでして助言をいただけると助かります。
ちなみに開発環境は勉強も兼ねて、別でEC2インスタンスを立てELBを使わない形で構築してみています。
何卒よろしくお願いいたします。
回答3件
0
ベストアンサー
管理画面で何を管理しようとしていますでしょうか。
同じDBを見ているならそれほど気にすることもないと思うのですが、気にされている整合性とは具体的に何を指してますか？
DBマイグレーションにおける整合性であれば、ユーザからアクセスさせた際に動くソースだけWEBサーバに置いて、DBマイグレーションについてはやり方をきちんと管理できていれば問題ないのでは、と思っています。
管理画面をWEBサーバと分けることは賛成で、そうすべきだと思います。
投稿2019/11/20 10:44
総合スコア7588
説明足らずですみません。
今回作っているサービスは、新規会員登録したエンドユーザーが商品を登録し、その商品を査定する業者がいるCtoBのサービスになります。
そのためエンドユーザー用のアカウントと、業者のアカウント2種類あり、このサービスを利用したい業者は問合せフォームからアカウント利用の打診を行います。その後運用側で業者の審査を行う想定で、その時に運営側は管理画面で業者情報の登録や、業者に対してログインアイパスの発行などを行います。
双方で使う商品に紐づくカテゴリーの生成など細かい登録ものも結構ある、というのが管理画面のざっくりした仕様になります。
整合性についてですが、公開側のLaravelと、管理画面側のLaravelの中身が別だった場合、モデルなどのリレーションの紐付けなどが運用していくとどんどん追加されていったりして、基本的にはどちらも同じ紐付けを維持しなければならないのでは、だとすると公開ページ側でのタスクに合わせて管理画面側も合わせて調整を入れていく必要が結構あるんじゃ無いか、と懸念しているという感じです。
そうなるとLaravel1プロジェクト内で完結させた方が楽なんじゃないかと思ったり。
マイグレーションなどをうまく管理していけば公開側のLaravelと、管理画面側のLaravelの中身が違うものでもさほど問題ないでしょうか？
ちょうど管理画面を作り始めようとしているタイミングでして、まだローカル環境ですが新しくプロジェクトを作るか、公開用に作っているLaravelの中に入れて管理画面をサブドメインで切るとか。管理画面の置き場所に悩んでしまった感じです。
うーん、ちょっとインフラの構成とは話がずれていっているような気がします。それは結局アプリをどう構成するかのような。
実現可能なら1プロジェクトでも分けてもどちらでもいいかなと個人的には思います。
データアクセスのさせ方を同じにするならたしかにそれをもう一度定義するのは面倒そうなので使いまわしたいかもしれませんね。
たとえ1プロジェクトでやったとしてもWEBサーバでは管理画面にアクセスさせなければいいだけかなと。（管理画面以外のところをデプロイするとか、そこだけアクセスを絞るとか）
大変参考になりました！
アプリ側の構成になりますが作りたい方法も見えてきました！
>管理画面以外のところをデプロイするとか、そこだけアクセスを絞るとか
この方法で1プロジェクトで作ることに決めました！
インフラ構成に関してはまだまだ勉強が必要と痛感しましたが取り急ぎ手は動かせそうです！
大変助かりました！
0
> DBを見るにしてもモデルなど公開側のLaravelと合わせないと整合性保てない気がしておりまして、二重管理になってしまい運用が大変な気がしております。
これに関してはデプロイツールを使った上で、environmentで管理機能を有効化する、無効化する等の対処をすれば良いのではないでしょうか。
別サーバーに管理画面を置くとして整合性を保つ良き方法があるのか何かご意見いただけないでしょうか？
デプロイツールを使えば良いかと思います。（AWSならebでしょうけど、というかEB使わないならAWSのメリットほぼ皆無な気がします。）
投稿2019/11/20 10:35
総合スコア5036
ご回答いただきありがとうございます。
私の知識が乏しくて大変申し訳ないのですが、例えばenvironmentで本番環境では404ページなどにし、別サーバの環境で管理画面を見れるようにする。Laravelプロジェクトはあくまで一つ。
という解釈で合っていますでしょうか？
それとEBというのは、
https://aws.amazon.com/jp/elasticbeanstalk/
Elastic Beanstalkというサービスでしょうか？
恥ずかしながら初めて知りました。。
何ができるか見てみます。ありがとうございます！
EC2 はただのVPSみたいな物なのです。
EBではアップデートの自動化やオートスケール、自動デプロイなどの恩恵を受けれます。
通常、ELBとEC2 、RDSで管理するならEBで構築するのが楽です
ご回答いただきありがとうございます！
大変参考になります！
一度UdemyのAWS構築を見ながら環境構築してみただけなのでまだまだ分からない部分が多いのですが、デプロイ方法など何が一番良いのか今後検討する上で非常に参考になります！
EBの理解を進めます、ありがとうございました！
0
インフラというより、アプリ設計に近いところな感じですね。
アプリ的な解法はすでにいくつか出てきているので、インフラ構成的な解法を。
EC2を全部プライベートサブネットに回して、EC2のインターネット接続が要るならNATゲートウェイかNATインスタンス、あるいはBastionを兼任したProxyをパブリックサブネットに立てる。
ALBをフロントにして、ターゲットグループのルーティングでフロントWebと管理画面へのアクセスをL7で分離します。
例えば/adminのアクセスをすべて管理インスタンスに回すなら/admin条件で管理インスタンスにルーティングし、管理用インスタンスがダウン中の時のために、同じルーティング条件でS3の静的ページのSorryページにでもRedirectを仕込んでおいて、残りのアクセスを全部Web側にルーティングさせます。
EC2をプライベートサブネットに回すのは、hostsなどに直接書かれてアクセスされるのを防ぐため。
これで単一アプリで管理画面用インスタンスとフロントWeb用のインスタンスに分離できるかなと思います。Webインスタンス側には管理画面機能があってもアクセスが発生しない、ということになります。
ターゲットグループに設定する条件によっては混在させても動きますが、セキュリティ的には多少低下しますね。
EFSでの共有化ができるので、AutoScalingを仕込みやすい、という感じになります。
sshとかはBastionやNATインスタンス立てるならそこ経由、NATゲートウェイならClient VPNあたりでやります。
投稿2019/11/20 13:16
総合スコア125
ご回答いただきありがとうございます！
>EC2をプライベートサブネットに回す
これについてはAWSの無料相談でも同じニュアンスのことを言われ「？？」となりアプリ制作落ち着いてきたらがっつりやらないと。。と思っておりました。
ご教示いただいた内容は今の私ではわからない部分もまだまだ多いのですが、アプリ側で1プロジェクトで管理しつつ環境で振り分けるという方法と、インフラで上記の形ができれば理想的と感じました！
ありがとうございます！
あなたの回答
tips
プレビュー
