Webアプリを作り始める前の頭の中の想像のお話し
2008/08/31 22:40:57
想像でWebアプリを最初から最後まで作っている時に、「う〜ん、これどうしようっかなぁ〜？」といくつかの選択肢で迷うことはよくある話ですが、そのひとつにまっさきに悩むのが（というほどでもないですが）サーバ構成＆Webアプリ構成ではないでしょうか？みなさんはどうでしょうか？
以下、経験上の構成例を少し紹介。
なお、下記の紹介例は
・サーバをいちからセットアップできる
・複数台のリンクなど比較的自由にできる
・サブドメインの設定は制限なくできる
など、かなり色々自由にできるという前提なのであしからず。
■パターン１ - 1台ですべてをまかなう
予算的にサーバが1台しか用意できないとか、1台で十分対応可能なWebアプリの規模の場合とかに選択されるパターンです。
ユーザに提供される感じとしては、
ただこのケースは一般に公開されるWEBの配下にそのサイト運営を管理するWEBがぶらさがっているので、何気に「.com/master/」という感じでアドレスをたたかれてしまったりしたら、という「う〜んそれってどうやろう？」ということがあります。もちろんログイン画面を設けたりBASIC認証を設けたりするのでセキュリティ的に問題ないようにすることは必然なのですが、「おっここに何かあるみたいやなぁ〜」というのは隠せませんし、一般公開のWEBで「master」「admin」「member」など管理で使ってしまっているフォルダ名が使えないですし、そうなるとどれが一般WEBでどれが管理WEBのものかというのが後々になってこんがらがってきてすっきりしないという状況を生み出したりもします。
で、そんなことを回避するために、WEBはWEB、管理は管理とわけるためにサブドメインで切り分けて、
これなら一般WEBは一般WEBのコンテンツのみで構成され、他のWEBもしかりですから非常にすっきりし、管理も運営もしやすくなることうけあいです。
例えば、一般WEBをさわるデザイナーと、重点的に管理者WEBをさわるプログラマーとのFTPも分かれることになり、プログラマのわからないデザイナーにまちがって管理WEBの方を壊されるという心配もなくなるでしょう。それから先ほど「う〜んそれってどうやろう？」って気になった一般WEBからいろいろな情報が推測される心配もなくなってハッピーです。だっていきなり「http://master.hogehoge.com/」とか「http://admin.hogehoge.com/」とか思いついてアドレスをたたかないでしょう？なかなか・・・
こういう風にWEBアプリって箱ものを用意した後はデータの流れをどういう風にしてやるかと考えていきます。後って言っても同時に考えるもんなんですが･･･
WEBアプリのデータとは単純に考えて、
としていいと思います。
一般的なWEBアプリでは「テキストデータ」はデータベースあるいはテキストファイル（CSVファイル）、画像データは直接フォルダに画像ファイルとして保存するのが普通。
データベースが何らかの理由で使えないなどがない限りデータをテキストファイル（CSVファイル）で扱うのはほとんどメリットがないように思いますので、MySQLやPostgreSQLなどのデータベースを使用します。
画像は画像ファイルとして直接所定のフォルダに保存するのですが、所定をどこにするかで迷う場合があります。まぁWEBアプリで扱う画像データはほぼ公開するのが目的であると思いますので、管理WEBでアップロードしたものを一般WEB配下のどこかに保存するという形をとることになるでしょう。ただしここでも先にでてきた管理上の問題があって、一般WEBをさわっているデザイナーが管理でアップされた画像フォルダを変更してしまう危険性があります。それを回避するために画像は管理WEB配下に保存しておき、一般WEBから絶対パスで画像を表示するというやり方をする場合もあります。（ただし管理WEB全体をBASIC認証している場合は注意が必要です。画像を表示するにID・パスワードを求められますのでこのやり方は選択できなくなります）
1台のサーバで事足りるというのは、サーバの保守、サイトの保守からして非常にやりやすいですね。
バックアップを考えた場合に、たった1台でやっているので、そのままもう1台そっくりそのままオリジナルと同じ環境をつくってデータを同期しておくと、オリジナルサーバがダウンして復旧に時間がかかる場合には（まぁかかんなくてもですけど）、バックアップサーバのIPアドレスを変えればそのままサービスをすぐに提供できます。でその後に少し余裕をもって元のオリジナルをバックアップとして構築すればいいでしょう。
■パターン２ - 2台に分け一般公開WEBだけ別
■パターン３ - 2台に分けデータベースだけ別
パターン２、３はサーバを2台用意して、負荷の高いサービス部分だけを別の1台に分離するやり方です。
パターン２の場合は、一般公開WEBが比較的アクセスが多くて一度に大量のクライアントに対応しなければならないことが考えられる場合のパターンです。
見ている人は多いが、そのサイトを管理している人は少ないといった場合となります。
パターン３の場合は、見る人も管理する人もそれなりだが大量のデータを扱うこと（＝データベースに高負荷がかかる）が考えられる場合のパターンです。
それぞれどんなサイトに最適なのかということは一概には言えませんが、サイト構築前から分かる場合を除くと、パターン１を運営していて状況によってパターン２、パターン３に移行するケースが多いですね。データが日々増加してApacheの負荷はかわらないが、PosgreSQLやMySQLの負荷が高くなってきたなぁ~といった時に「う~ん」といいながら予算と手間を考えながら判断していきます。
さてこの場合のバックアップですが、パターン１の時のように全く同じ構成のものを用意できれば楽ですが、2台ですのでもう2台用意すると計4台になりますのでサーバ代だけでもかなり「ヽ( ~д~)ﾉ」となること請け合いですので悩みますねぇ~。
予算も限られていますので、2台同時にサーバはお逝きにならないと信じて、ここは少々面倒ですが、2台でお互いをバックアップしあうことにします。2台どちらも設定は同じにしておいて、お互いのデータを同期バックアップし、いつでも相手のサービスを提供できるようにしておきます。例えばパターン３でデータベースのサーバがダウンした場合、「LIMUXサーバA」のデータベースを動かし一般WEBや管理WEBからは自サーバのデータベースを見に行くようにします。一時的に1台でどこまで負荷に耐えられるかは時の運次第ですが、ただちにハングアップすることはないと思います（多分）。とにかくサービスは停止せずに提供し続けることができますので、この「LIMUXサーバA」が耐えている間「LIMUXサーバB」を直ちに復旧し元の状態に戻します。
■パターン４ - サービス毎にサーバを分ける
非常に贅沢な使い方。
かなり規模の大きいサービス。
収益のあるサイト。でなければ採算度外視。
大人の事情でこのような構成になることはままある。
だが、WEB屋にとってはこういった構成はかなり面倒なことが多い。
パターン２で付け加え忘れたが、データの流れでサーバが分かれると少し仕掛けが必要である。
データベースに格納するデータは簡単で、受け入れの設定さえされていればデータベースはグローバルIPでの接続ができるのでサーバが離れていてもデータは出し入れ可能。しかし実画像は簡単にはいかない。プログラムでFTP接続して画像を送るようにしてもいいが、面倒なので私はよくNFS＝ネットワークファイルシステムというファイル共有システムを使うことが多い。NFSを使うと離れた場所にあるサーバのファイルを、あたかも自サーバにあるファイルのように操作することができるのでプログラムで保存するのが最も楽になる。ただこれをしようとするとサーバ同士で共有の設定をあらかじめしておかなければならないが、いったんしておけばいいので簡単である。（経験値が少なくめったにない障害時の復旧の際によくこの設定を忘れて画像がアップされずにあせるけどね）
■パターン５ - 管理WEBにWindowsサーバを使う
■パターン６ - 管理WEBにWindowsサーバを使う
パターン５、６は管理WEBにWindowsサーバを使うというものだ。
パターン２~４と基本的な考え方は変わらないが、違う点は管理WEBの言語が「ASP」になってサーバ同士のファイルのやり取りがNFSではなく「SAMBA」を使うという点である。
LINUXサーバの方でSAMBAを動かしWindowsサーバのIPからのアクセスを許可していれば、Windowsサーバからは「\\IPアドレス」または「\\共有名」でアクセスできるのでこれも簡単である。だが今度はWindowsサーバからLINUXサーバのデータベースにアクセスする場合は少々やっかいだが、私はODBCデータソースで接続している。
で疑問になると思うが、何故わざわざWindowsサーバを導入する意味があるのか？
たしかに言語も別のものが必要になるし（PHPも動くけど）、サーバの運用方法も違うし設定も違う。運用コストもあがる。
あんまりいいことなさそうですが、経験上からいうとWindowsサーバでのASP言語による管理WEBの運用はLinuxサーバでPHP言語によるそれとは比較的負荷が少なく安定しているように思えます。
もちろん好みの問題もありますし、Windowsサーバ？ASP？なんて場合は端からないパターンなのですが、そういうケースもあるということで。
予算があって贅沢に何台も使えたりする場合や、逆に予算がなくて１台しか用意できない場合など様々なケースがあったり、構築するWebアプリの規模からいって妥当なサーバスペック、サーバ台数が必要なのに、色々な制約によりそれが用意できなくて限られた範囲の中で格闘しなければならない等、他にも大人の事情や理由にもならないような状況というのもありますが、なかなか一筋縄にはいかないようなことばかりです。
以上、いろいろパターンを見てきましたが、Webアプリを作る時や運営中に問題が出てきた時に主に頭の中で想像することばかりです。
WEB屋が腕を組んで「う~ん」と考えている時はさぼっているのではなく、こんなことを考えているんですよ。これもお仕事なんです(ﾟДﾟ)
・サーバをいちからセットアップできる
・複数台のリンクなど比較的自由にできる
・サブドメインの設定は制限なくできる
など、かなり色々自由にできるという前提なのであしからず。
■パターン１ - 1台ですべてをまかなう
予算的にサーバが1台しか用意できないとか、1台で十分対応可能なWebアプリの規模の場合とかに選択されるパターンです。
ユーザに提供される感じとしては、
http://www.hogehoge.com/など、1つのドメインでやる場合はこうして「.com/」以下にそれぞれの役割で切り分けて提供したりする。
→一般に公開されるWEB
http://www.hogehoge.com/master/
→管理者がサイトの管理を行うためのWEB
http://www.hogehoge.com/admin/
→例えばサイトに掲載する広告主が自身の領域の広告を管理するためのWEB
http://www.hogehoge.com/member/
→例えばユーザーが会員になってマイページをみるためのWEB
ただこのケースは一般に公開されるWEBの配下にそのサイト運営を管理するWEBがぶらさがっているので、何気に「.com/master/」という感じでアドレスをたたかれてしまったりしたら、という「う〜んそれってどうやろう？」ということがあります。もちろんログイン画面を設けたりBASIC認証を設けたりするのでセキュリティ的に問題ないようにすることは必然なのですが、「おっここに何かあるみたいやなぁ〜」というのは隠せませんし、一般公開のWEBで「master」「admin」「member」など管理で使ってしまっているフォルダ名が使えないですし、そうなるとどれが一般WEBでどれが管理WEBのものかというのが後々になってこんがらがってきてすっきりしないという状況を生み出したりもします。
で、そんなことを回避するために、WEBはWEB、管理は管理とわけるためにサブドメインで切り分けて、
http://www.hogehoge.com/という感じにします。
→一般に公開されるWEB
http://master.hogehoge.com/
→管理者がサイトの管理を行うためのWEB
http://admin.hogehoge.com/
→例えばサイトに掲載する広告主が自身の領域の広告を管理するためのWEB
http://member.hogehoge.com/
→例えばユーザーが会員になってマイページをみるためのWEB
これなら一般WEBは一般WEBのコンテンツのみで構成され、他のWEBもしかりですから非常にすっきりし、管理も運営もしやすくなることうけあいです。
例えば、一般WEBをさわるデザイナーと、重点的に管理者WEBをさわるプログラマーとのFTPも分かれることになり、プログラマのわからないデザイナーにまちがって管理WEBの方を壊されるという心配もなくなるでしょう。それから先ほど「う〜んそれってどうやろう？」って気になった一般WEBからいろいろな情報が推測される心配もなくなってハッピーです。だっていきなり「http://master.hogehoge.com/」とか「http://admin.hogehoge.com/」とか思いついてアドレスをたたかないでしょう？なかなか・・・
こういう風にWEBアプリって箱ものを用意した後はデータの流れをどういう風にしてやるかと考えていきます。後って言っても同時に考えるもんなんですが･･･
WEBアプリのデータとは単純に考えて、
・テキストデータ
・画像データ
としていいと思います。
一般的なWEBアプリでは「テキストデータ」はデータベースあるいはテキストファイル（CSVファイル）、画像データは直接フォルダに画像ファイルとして保存するのが普通。
データベースが何らかの理由で使えないなどがない限りデータをテキストファイル（CSVファイル）で扱うのはほとんどメリットがないように思いますので、MySQLやPostgreSQLなどのデータベースを使用します。
画像は画像ファイルとして直接所定のフォルダに保存するのですが、所定をどこにするかで迷う場合があります。まぁWEBアプリで扱う画像データはほぼ公開するのが目的であると思いますので、管理WEBでアップロードしたものを一般WEB配下のどこかに保存するという形をとることになるでしょう。ただしここでも先にでてきた管理上の問題があって、一般WEBをさわっているデザイナーが管理でアップされた画像フォルダを変更してしまう危険性があります。それを回避するために画像は管理WEB配下に保存しておき、一般WEBから絶対パスで画像を表示するというやり方をする場合もあります。（ただし管理WEB全体をBASIC認証している場合は注意が必要です。画像を表示するにID・パスワードを求められますのでこのやり方は選択できなくなります）
1台のサーバで事足りるというのは、サーバの保守、サイトの保守からして非常にやりやすいですね。
バックアップを考えた場合に、たった1台でやっているので、そのままもう1台そっくりそのままオリジナルと同じ環境をつくってデータを同期しておくと、オリジナルサーバがダウンして復旧に時間がかかる場合には（まぁかかんなくてもですけど）、バックアップサーバのIPアドレスを変えればそのままサービスをすぐに提供できます。でその後に少し余裕をもって元のオリジナルをバックアップとして構築すればいいでしょう。
■パターン２ - 2台に分け一般公開WEBだけ別
■パターン３ - 2台に分けデータベースだけ別
パターン２、３はサーバを2台用意して、負荷の高いサービス部分だけを別の1台に分離するやり方です。
パターン２の場合は、一般公開WEBが比較的アクセスが多くて一度に大量のクライアントに対応しなければならないことが考えられる場合のパターンです。
見ている人は多いが、そのサイトを管理している人は少ないといった場合となります。
パターン３の場合は、見る人も管理する人もそれなりだが大量のデータを扱うこと（＝データベースに高負荷がかかる）が考えられる場合のパターンです。
それぞれどんなサイトに最適なのかということは一概には言えませんが、サイト構築前から分かる場合を除くと、パターン１を運営していて状況によってパターン２、パターン３に移行するケースが多いですね。データが日々増加してApacheの負荷はかわらないが、PosgreSQLやMySQLの負荷が高くなってきたなぁ~といった時に「う~ん」といいながら予算と手間を考えながら判断していきます。
さてこの場合のバックアップですが、パターン１の時のように全く同じ構成のものを用意できれば楽ですが、2台ですのでもう2台用意すると計4台になりますのでサーバ代だけでもかなり「ヽ( ~д~)ﾉ」となること請け合いですので悩みますねぇ~。
予算も限られていますので、2台同時にサーバはお逝きにならないと信じて、ここは少々面倒ですが、2台でお互いをバックアップしあうことにします。2台どちらも設定は同じにしておいて、お互いのデータを同期バックアップし、いつでも相手のサービスを提供できるようにしておきます。例えばパターン３でデータベースのサーバがダウンした場合、「LIMUXサーバA」のデータベースを動かし一般WEBや管理WEBからは自サーバのデータベースを見に行くようにします。一時的に1台でどこまで負荷に耐えられるかは時の運次第ですが、ただちにハングアップすることはないと思います（多分）。とにかくサービスは停止せずに提供し続けることができますので、この「LIMUXサーバA」が耐えている間「LIMUXサーバB」を直ちに復旧し元の状態に戻します。
■パターン４ - サービス毎にサーバを分ける
非常に贅沢な使い方。
かなり規模の大きいサービス。
収益のあるサイト。でなければ採算度外視。
大人の事情でこのような構成になることはままある。
だが、WEB屋にとってはこういった構成はかなり面倒なことが多い。
パターン２で付け加え忘れたが、データの流れでサーバが分かれると少し仕掛けが必要である。
データベースに格納するデータは簡単で、受け入れの設定さえされていればデータベースはグローバルIPでの接続ができるのでサーバが離れていてもデータは出し入れ可能。しかし実画像は簡単にはいかない。プログラムでFTP接続して画像を送るようにしてもいいが、面倒なので私はよくNFS＝ネットワークファイルシステムというファイル共有システムを使うことが多い。NFSを使うと離れた場所にあるサーバのファイルを、あたかも自サーバにあるファイルのように操作することができるのでプログラムで保存するのが最も楽になる。ただこれをしようとするとサーバ同士で共有の設定をあらかじめしておかなければならないが、いったんしておけばいいので簡単である。（経験値が少なくめったにない障害時の復旧の際によくこの設定を忘れて画像がアップされずにあせるけどね）
■パターン５ - 管理WEBにWindowsサーバを使う
■パターン６ - 管理WEBにWindowsサーバを使う
パターン５、６は管理WEBにWindowsサーバを使うというものだ。
パターン２~４と基本的な考え方は変わらないが、違う点は管理WEBの言語が「ASP」になってサーバ同士のファイルのやり取りがNFSではなく「SAMBA」を使うという点である。
LINUXサーバの方でSAMBAを動かしWindowsサーバのIPからのアクセスを許可していれば、Windowsサーバからは「\\IPアドレス」または「\\共有名」でアクセスできるのでこれも簡単である。だが今度はWindowsサーバからLINUXサーバのデータベースにアクセスする場合は少々やっかいだが、私はODBCデータソースで接続している。
で疑問になると思うが、何故わざわざWindowsサーバを導入する意味があるのか？
たしかに言語も別のものが必要になるし（PHPも動くけど）、サーバの運用方法も違うし設定も違う。運用コストもあがる。
あんまりいいことなさそうですが、経験上からいうとWindowsサーバでのASP言語による管理WEBの運用はLinuxサーバでPHP言語によるそれとは比較的負荷が少なく安定しているように思えます。
もちろん好みの問題もありますし、Windowsサーバ？ASP？なんて場合は端からないパターンなのですが、そういうケースもあるということで。
予算があって贅沢に何台も使えたりする場合や、逆に予算がなくて１台しか用意できない場合など様々なケースがあったり、構築するWebアプリの規模からいって妥当なサーバスペック、サーバ台数が必要なのに、色々な制約によりそれが用意できなくて限られた範囲の中で格闘しなければならない等、他にも大人の事情や理由にもならないような状況というのもありますが、なかなか一筋縄にはいかないようなことばかりです。
以上、いろいろパターンを見てきましたが、Webアプリを作る時や運営中に問題が出てきた時に主に頭の中で想像することばかりです。
WEB屋が腕を組んで「う~ん」と考えている時はさぼっているのではなく、こんなことを考えているんですよ。これもお仕事なんです(ﾟДﾟ)
