サービスのアーキテクチャを考える上で、スケーラビリティを考えることは必須となります。いつも参考にさせて貰っているのが中島聡さんのアーキテクチャ論。まだ自分が作る上で実践出来ていない部分も多いですが、今後も取り入れていこうと思います。自分用のメモも兼ねて、読み返しやすいようにピックアップしました。
Life is beautiful: マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２
そう考えると、私にはCreate/Update/Deleteのリクエストに対して、クライアントを待たせながら（つまり、HTTP Requestの処理に必要なスレッド・プロセスを保持したまま）データベースに変更をかけることが根本的に間違っているように思える。
そうではなくて、Create/Update/Deleteのリクエストに関しては、そのリクエストをキューにしまい、クライアントにはすぐにレスポンスを返した上で（つまり、HTTP Requestの処理に必要なスレッド・プロセスはすぐに解放して）、別プロセス（それもシングルプロセス）でキューにたまったリクエストを順繰りに非同期で処理すべきだ。
Life is beautiful: スケーラビリティとユーザービリティの話
また、通常ピーク時に３秒で処理出来ているところに、通常の倍のトラフィックが来てしまった時に、それを倍の６秒で処理出来るように作ってあるか、倍以上の９秒かかってしまうように設計してあるか、というのが「リニアにスケールするかどうか」という部分である。HTTP Requestに対するレスポンスが遅くなると、それに応じて同時アクセス数が増えてしまい、ペンディング中のスレッドが増えてしまう、そのためにさらにレスポンスタイムが遅くなる、という悪循環は、マルチスレッド型のHTTPを使ったアーキテクチャの根本的な弱点。安易にマルチスレッドに頼ったプログラミングは良くない理由はこの辺りにもある。
Life is beautiful: 「RESTful MVC」なアーキテクチャの話
もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。
Life is beautiful: HTML5時代の「運営しやすいアーキテクチャ」の話
まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS, HTML, JS, Media Filesはすべてスタティック・ファイル）。
「戦略的OS」の開発がことごとく失敗している点に関する一考察
「日の丸OS」だったはずのB-Tronもどこかに行ってしまったし、そもそも「戦略的OS」を意図的に作るってことにかなり無理があるんじゃないかと思える。結局のところ、ソフトウェア作りはアートに近くて、大企業が資金力にまかせて優秀なエンジニアを集めても無理があって、少人数で作ったものが市場原理で自然淘汰されてこそ良いものができると思うんだがどうだろう。
身も蓋もないけど、ソフトウェア業界って多産多死型がよいのかもしれませんね。試してみて駄目だったらさっさと撤退して、次の成功に備えるとか。
