イントラ系なWebシステムしかやったことの無いSI屋が、コンシューマーWebサイトを開発する時に知っておくべき事
同じWebシステムと言っても、イントラでせいぜい数千PV/dayのシステムと、ユーザ数5〜6桁、10万PV/day以上なコンシューマー系サイトの構築では設計も違ってくるわけで。
前者しかやったことが無い人達が、後者をやる時に知っておくべき事についてチョコっと。
セキュリティは常識
今でこそ「動くんだから良いでしょう？」みたいな事を言う馬鹿もいなくなったし、発注者側も脆弱性診断サービスなんかを使うのが常識になってきていますが。
それでも、イントラなシステムしかやったことが無くて(致命的な攻撃を受けたことが無くて)、Webアプリケーションにおけるセキュリティの基礎知識が無かったり、正しい対処方法知らない人って言うのもまだまだ居るわけですが(´・ω・`)
開発者は、今はセキュアプログラミング入門みたいな研修もよくあるし、情処のSVなんかも情処の試験としては割とマシな方だと思うので、そういうのを受けたり取ったりしておくことデス。
あと、発注側はセキュア要件をちゃんと要件定義に盛り込んで、それが満たされなければお金を払わないようにすること(;´Д｀)
また、第三者の脆弱性診断サービスを申し込むこと。
セキュアなプログラミングっていうのはIn/Outの個々の項目のチェックまで必要になるわけで。
開発要員のスキルが期待できない場合、最悪、入力のフィルタリングを行って、危険な文字が入力されたら前段階でエラーにしてしまうなんてケースもあったりね。*1
複雑なSQL禁止
イントラでユーザ数が少ないシステムであれば、ちょっと思いSQLを書いて処理しても良いですが。
コンシューマー系のアクセスが多い(参照系の多い)サイトを作る場合、無駄にスループットを下げるような処理は致命的な事になりますにょ(・ω・)
同時接続ユーザ数、1画面を構成するのに必要な処理数なんかを考えた時に。
インデックスの使用とかに問題の無い、処理時間に0.01秒かかる処理があったとして。
それをテーブルの非正規化(主に集計値の事前計算等)によって、処理時間0.001秒にできるのであれば、そうするでJKなのがコンシューマWebサイトな世界です(・∀・)
SQLスキーやバッチ系をやっていた人はなんでもSQLで解決しようと考えがちですが、RDBをあまりリレーショナルな使い方をせず、アトミックな処理ができるデータストアの一種くらいに考える世界もあることは知っておいてくださいな。
ちなみに、他のデータストアとしては、検索エンジンとかキャッシュとかネ(・∀・)
キャッシュの利用
っというわけでキャッシュ。
データストアの一種として、キャッシュという概念を持っていない人がWebサイトを作ると、毎回DBに処理を行うような作りにしてしまうわけですが…(;´Д｀)
例えば、情報系ポータル画面とかで、画面を構成するいくつものパーツを表示するために何十もの参照処理が必要なケースがあったとして。
それをこの考えで作ってしまうと、糞重くてしかたが無いサイトになってしまいます(。∀ ﾟ)ｱﾋｬ!
複数人が同時にページを表示しただけで、秒間何百件ものSQLが発行さられる事になるわけですから当然ですね。
しかも、発行されるSQLはまったく同じものだったり、ユーザ単位でユニークなものだったりと、無駄な事この上ない話なわけで(;´Д｀)
こういうものをまともに作る場合は、SQLのチューニングがどうこうとか言い出すのではなく、そもそもの考え方を変えて、キャッシュを使うことが必須になります(・ω・)
ちなみに、キャッシュを使う場合には、キャッシュをInvalidにする条件、キャッシュで必要とする領域の見積もり、スケーラビリティ/レプリケーションをどうするかだとか、きちんと設計すべきことがあるのでそこをおろそかにしないようにネ(・∀・)
スケーラビリティ/水平分散を考えたアプリケーション設計
イントラなシステムの場合、スケーラビリティに対して垂直方向のスケールアップでどうにかしようとする傾向がありますが。
コンシューマー系サイトにおけるユーザ数の増加に対しては、スケールアップでの対応は直ぐに限界が来てしまうので、水平分散を考慮したアプリケーション設計をしておくのが常識かと思います。*2
まあ、単純なアプリケーションであれば、インフラがそれなりにしっかりしていれば、なにも考えなくても10万PV/dayくらいまでならなんとかなったりもしますが(´Д｀)
でも、それ以上のアクセス数を考慮する場合、水平分散を考慮したアプリケーション設計は必須になるかと思います。
っで、一番最初にネックになる＆分散が難しいのがデータストア(データベース)のあたりかと。
水平分散を考慮する場合、データ構造はアプリケーションが扱いやすい単純なものにして、アプリケーションレイヤで頑張るケースは普通にあると思っていた方が良いです(・ω・) *3
綺麗なURL、RESTFulな設計
SEOとかに詳しいわけではないですが、コンシューマ系サイトで、
http://.../xxx/yyyy.do?user=aaaa¶m=bbbb
みたいなURLを見ると、素人臭いと思うというか、ちょっと萎へ(´Д｀)っときたり。
こういうときはまあ、
http://...//xxx/aaaa/yyyy/bbbb/
でしょうねぇ、っと(・ω・)
例えば、PHPのフレームワークなんかは、mod_rewriteで全てのリクエストをフロントコントローラーに渡して、そこから個々のアクションへルーティングするような作りになっているものが多いですが。
Javaなんかでも、Filterで処理を入れることによってApacheを使わずにJava単体で綺麗なURLのアプリケーションは作れるので、今時なサイトを作るのであればこの辺も考えてくださいな、っと(・∀・)
そもそも、画面のフレームは作ってさんざん打ち合わせとかを繰り返す割には、URL設計/ユースケース分析はしていないっていう片手落ちな人達が大杉だったりネ!!( ﾟдﾟ)
URL設計っていうのは、最初期から行うべきとても重要な設計ですよ(・ω・)
