Webアプリケーションのアーキテクチャを決定する際に考慮する、アプリケーションのパターン(大きく分けて2種類)について、諸々の雑談

この前、ASP.NET MVCとWeb Formsの用途について言ったことと関連したり、その前にもちょっと言っているんですが、僕チン、Webアプリケーションには2種類あると言っていて(・ω・)
どういう分類での話かと言うと、以下の様なカンジになりますが。

	タイプ1	タイプ2
例	昔ながらのクラサバアプリのWeb版	Web 2.0的なコンシューマWeb
対象	特定ユーザ向け、イントラ、B2B	不特定ユーザ向け、B2C
どちら側？	こちら側	あちら側
想定ユーザ数	Max 10,000くらい、社員数、B2Bにおける顧客数	Min 100,000は想定
URL	気にしない	気にする、綺麗なURL必須
XHTML	そんなものはシラネ、吐かれるHTMLはコンポーネント任せ	結構重要、デザイナとの協業とかも真面目(・∀・)？にやる
ステート	ステートフル	ステートレス
画面遷移の制御	フレームワーク任せ	PRGパターンが基本
データアクセス	CRUD、帳票	9割以上は(リソース)参照系
データストア	RDB 99%	RDB はある意味不揮発性のデータストア、データソースとしてはKVS、検索エンジンなんかの割合も大
スケール対策	HWスペック強化、多重化はパフォーマンスよりも対障害の意味合いが強い	水平分散を想定
トランザクション障害	致命的(#゜Д゜)	タイプ1ほどではない
モバイル対応	無し	むしろモバイルユーザの方が多いかも
向いてる設計方針	コンポーネント指向	リソース指向
ASP.NETでやる場合	Web Forms	ASP.NET MVC

この区分け自体は割と自明なものだと思いますが、逆に、あまり意識せずに話をしてしまい、すれ違うようなケースも多い気がします(´ω`)
たとえば、技術についての話をするときに、どちらを想定しているか明示しないで話を進めてしまい、話が食い違うとか、ありがちですよね。

(・∀・)「×××(Somthing newなフレームワーク)って良いな」
(^Д^)「ねぇーよｗ、○○○が△△△とか、あり得んｗ」

みたいな(´д｀;)
×××にはASP.NET MVCとかRailsとかJSFとかを入れて、○○○にはステートとかURLとかHTMLとかそういう言葉を入れてみてくださいな。

でも、アプリケーションのアーキテクチャを決定する際は、このパターンの違いを考慮することは必須だと思いますヨ( ﾟдﾟ)*1
考慮が出来ていれば、例えばECサイトのフロントエンドをタイプ2で、バックヤード(ECサイトの裏で動く物流システムとか)をタイプ1で、みたいな選択をするケースも普通になりますね(・∀・)*2

まあ、(アプリケーションの規模ではなく、ビジネスの規模が)小規模な場合、別にそんなのどっちだって良いよ、っという意見も無くはないですが(;´д｀)
でも、真面目にビジネス要件を考えた場合には、アーキテクチャの決定にここであげた要素を考慮することはmust…っと言うか、その要件も踏まえてのアーキテクチャだと思います(｀・ω・´)*3

っで、以下は、上であげた項目に対する、ちょっと補足(というか余談)デス(・∀・)

想定ユーザ数

コンシューマ向けWebサイトのユーザ数を想定するのは難しいですね(´д｀;)
想定する絶対値が小規模なら、イントラWebとと一緒でしょ、みたいな単純な話でもなく。

(・∀・)「想定会員数はどれくらいですか？」
(´∀｀)「Max 5,000人くらいですかね」

っと言っていたシステムの会員数が、1年で10,000人を超えて、その後も増加中とかありがちだしね(ﾟ∀ﾟ)

あと、この手のサイトは、(年間チョコレート消費量の2割はバレンタインデーに的な意味で)アクセスが特定時期に集中するという性質を持つものもあったりもして。
それも考慮して、インフラ、アプリケーション込みでのアーキテクチャの設計が必要になったりしますし(・ω・)

ちなみに、この本にはそういう話も出てくるので、興味がある人は読むとニヤニヤできますよ(・∀・)

Release It! 本番用ソフトウェア製品の設計とデプロイのために

タイトルで勘違いしそうだけど、コレ、いわゆるデプロイの話というより、そういう内容の本だよ(´д｀;)

URL

綺麗なURLの話なんかは、SEO的な意味でも重要ですが(´∀｀)
それ以前に、コンシューマ向けWebサイトでは、「お勧め商品のURLをコピペして、メールで知り合いの所に送る」っというような使い方も想定するので、URLの情報だけでページを再現できないというのは致命的な場合があります(´д｀;)
商品検索がPOSTとか、あり得ないし(#ﾟДﾟ)

データアクセス

イントラアプリの場合、(帳票やバッチを除いて)処理は基本的なCRUDだから簡単だよね〜(´∀｀)、みたいな誤解をしているケースがありますが。
それは勘違いであって。

端的な例としてマスタ管理をあげますが、「マスタ」を単純にCRUDしてしまって良いなどと言うことはそうはなくて。
「マスタ」CRUDの裏側には、深遠なビジネスロジックの世界が待ち構えているという罠(´д｀;)
それを単純な処理だと勘違いしているのは、「そういうケースは運用で対処します」みたいな事を言って、(見積もり価格を下げるために(´д｀;))処理を単純にしているだけのことで。
単純なマスタ管理アプリですYO〜*4、とか言っている案件で火を噴くのは、この隠れたビジネスロジックの罠を甘く見すぎているというか、上記の合意をちゃんと得られないまま仕事進めているから、なんていうケースがありがちデスね(´д｀;;)

データストア

データアクセスに関して、コンシューマWebの場合、処理内容は単純だけど、数という意味での負荷がかかってくるので、キャッシュだとか、スケールしやすいKVSと言うのは、まあ必然(・∀・)
なので、キャッシュの使用くらいをメンドクサイとか言わないこと(#ﾟДﾟ)
ただし、キャッシュはよく考えて使うこと(´д｀;)

ちなみに、キャッシュの使用とかって、DBのモデリングを重視する(その一方で性能要件をあまり重視しない)人ほど抵抗があるような気がしたり(?)。
とりあえず、「OTLPなのにSQLが重い」アンチパターンと「なんでもかんでもリアルタイム集計」アンチパターンも参照のこと(・∀・)

DB Magazine ( マガジン ) 2009年 05月号 [雑誌]

あと、データストアとはちょっと意味合いが違ってきますが、コンシューマWebの場合、リコメンデーションみたいなソーシャルな技術だとか、分散並列処理みたいな知識も武器になるので重要ですね(・∀・)

よく、SE(笑)にはテクノロジーの知識よりもドメイン知識の方が重要みたいな事を言うけどさ( ﾟДﾟ)
それを言うなら、コンシューマWeb屋にとってはソーシャル技術はドメイン知識みたいなもんだと思うよ(・∀・)

スケール対策

イントラWebの多重化は、パフォーマンスよりも対障害の意味合いが強いという点についての補足。
まあ、作っている人達には、この意識があまりなかったりすることもあるんだけれど…(´・ω・`)

結局、DBの処理が重くなっていて、スケール対策にはなっていないアプリケーション構成とかがありがちなケースで(´д｀;)
とりあえず負荷分散と言ってみて、箱物ロードバランサを買ってみて、Webサーバは分策しているけれど、リクエストに対して高負荷のDB処理が走っていて、分散の意味ねーよｗ、とか(´・ω・`)
スケール対策って言うのは、アプリケーションとインフラが独立して考えられるモノでもないでJK。

ASP.NETでやる場合(ではなくJavaの話になりますが)

コンシューマWebでWeb Formsのメリットが生かせないのとは逆のパターンで、無設定化とかRailsっぽい皮をかぶせてみても、Strutsをイントラで使うメリットって無いよね、っと今更な事を言ってみたりして(・ω・)
結局、イントラWebアプリの場合、グリッド＆フォームとデータバインドをどう効率よくやるかが最重要だったりするので。
ユースケース単位でコントローラを作ったり、URLとコントローラ、メソッドを関連づけるとかはどうでも良いと言うか。

そういう分野では、Web MVCなフレームワークよりも、コンポーネント指向の方がマッチすると思います。
なので、Java好きな人達でやる場合には、JSFはちょっとアレだとして、WicketやClickを選択するというのは全然ありだと思うし(・∀・)
なんでもかんでもStrutsだとか言うのは、所詮人の集めやすさの話でしかないわけで(´・ω・`)
どこでも内製とか言い出している昨今の状況では、むしろそういう選択をやりやすくなったりもして。

っで、この考えの行き着く先は、RIAで良いジャン(むしろRIAの方が良いジャン)、だったりもするんですけれど(´∀｀)
それを言い出すと、Webでなくて良いジャン、にもなっちゃうんだけど、今時なシステムがHTTPの重力から解き放たれる事は難しいので、それは言わないお約束(・∀・)

っで、ついでに、システムというか、そういうシステムをやっている人達の分類もしてみたり(・∀・)

	タイプ1	タイプ2
IT業界における就業人口の割合	大多数	絶対数としては少数
ネット上での声の大きさ	中	相対的に大
仕事の進め方	SI屋的で重量級(´д｀;)	Web屋的で軽量級(｀・ω・´)

で、同じく以下は余談。

就業人口の割合＆ネット上での声の大きさ

ネット上での発言が目立つのはWeb屋さんの方だけど、就業人口的にはそうでないシステムに関わっている人の方が多いわけですが(´ω`)
この反転しているところも、アーキテクチャやフレームワークの話をする際に、すれ違いや誤解を増やす要因かな、っと思ってみたりして。

ASP.NET MVCに対する「なぜ今更(Web)MVC？」みたいな意見も、自分の生きている世界こそが世界の全てだ、みたいな思い込みからくる所がある気もするし(´・ω・`)
逆に、ネット上での話を聞いて、最新のフレームワークを使ってみたけれどうまくいかないなんていうのも、その話がどういうコンテキストで語られたものかを無視しているからだったりして。

まあ、人の事例を単純に真似するのではなく、要件に合致するかどうかで判断せいっちゅ〜、基本的な話やで〜(・ω・)

あと、ネット上での声の大きさという意味だと、組み込み屋さんとかの声は相対的に小さく聞こえたりもしますが、そういう世界があることも忘れないでください(´ω`)

仕事の進め方

これはまあ、冗談半分だけど(´д｀;)*5

コンシューマ向けWebサイトの構築は、イントラなアプリケーションやシステムとは違うスピード感が要求されるし、それに慣れることができないなら、勝負で負けるっといのは、一般的にも認識されているようではありますが(・ω・)

ただ、SI屋がそこを認識していなかったり、SI屋としての「責務の範囲で対価を貰う」という部分を強く押し出しすぎて、免責、契約、フェーズゲート、上流工程で云々とか言い出して、SI屋の「責務の範囲で対価を貰う」という勝利条件は満たしても、顧客のビジネス上での勝利条件は満たせない結果に終わる…なんて言うことは、まだまだよくある話のようで(´д｀;)
まあ、それ以前にこの事を理解していて、変化に対応できる柔軟性と技術力を持ったコンペジがいる場合には、金額やスピードで勝負にならなかったりするわけですが。

ただ、たまに顧客の方が重量級の成果物を求めてくるケースもあったりしてネ(´д｀;)
柔軟性やスピードを生み出す土壌を理解せずに、スケジュール絶対だとか、ビジネスは変化するんだとしたり顔で力説されても、デスマ確定ですか？、そうですか(´・ω・`)

まあ、ドキュメントとかレビューの作業分は別途上乗せして見積もって、お金的には良かったとしても。
スケジュールのスコープは調整できない場合にどうするか( ﾟдﾟ)？

そういう状況ではもう開き直って、重量級な作業をする部隊とは別に、本質的な作業を進める部隊を作れば良いんじゃないかと思いますよ、僕は(´д｀)

重量級なドキュメントを求められた場合。
貴方がドキュメントを書いて、それを実装する人間を他に雇うのではなくて。
貴方はさっさと実装を進めて、それをドキュメントに落とす人間を別途雇いなさい。

…みたいなやり方を、これまで見てきたからかもしれないけど(・∀・)
それが正しいかどうかはともかく、結果は出せるし、リスク回避にはなると思っているんだよな〜(・ω・)

っと、とりとめもなく、思いつきのネタ話ですた(・∀・)*6

*1:あと、見積もりや仕事の進めかたなんかも、これを踏まえないとマゼルナ危険(´д｀;)

*2:今までだと、フロントをJavaでタイプ2、バックを.NETでタイプ1とかね

*3:たまに、「目的よりも手段上等!!」な自分ですら、「それは作り手の都合だろ(#ﾟДﾟ)つ」っという突っ込みを入れたくなるような発言を聞くこともあるしねぇ。

*4:営業やエロい人がこう言って仕事を持ってきたときは気をつけましょう(´・ω・`)

*5:基本、いつも冗談半分だけどな〜、つって(・∀・)

*6:最近ASP.NET MVCを弄っていたこともあって、Web Forms or ASP.NET MVCみたいな所からはじまって。一口にIT業界と言っても…っていうネタがあるけど、それなら一口にWebアプリケーションと言っても…、っというところから思いついたお話デスタ。