最近blogosphereで浮上した興味深い議論は、スケーラビリティの設計には、前もってどれくらいの時間をかけるべきか、と言うものである。OnStartUps(サイト・英語)のDharmesh Shah氏が、"時期尚早なScalaculation(source)"の危険性について書いたことで、この議論は始まった。
新興企業における技術的なファウンダはしばしば、スケーラブルなシステムのアーキテクトである、というのを彼のスキルにおける名誉の印としています。チームのだれもが知っているような、劇的な成功を収める企業にとっては (スケーラビリティの確保は) 避けられないことであり、システム (ソフトウェアとインフラ) はそれに対処できる、と確認するために多くの時間とお金が費やされています。非常に多くの場合、それは間違いです。
この記事の前提には、貴重なリソースは、配管工事よりも、より緊急性の高いビジネスニーズに対して割かれるべきである、というものだ。
これらのリソースは、何が動作するはずのものなのかを解析するために割かれるべきであり、複雑なソフトウェアデザイン、コード最適化、そしてインフラのアップグレードなどに割かれるべきではありません。
これは、スケーラブルなシステムを設計するよりも、スケーラブルでないシステムを設計する方がより高価だと仮定しても妥当なのだろうか？(言い換えると、スケールしないシステムを設計する方が、コストを減らせるのだろうか？)
Todd Hoff氏はそうは考えていない(source)。
もし私がこれを以前信じていたとしても、全く以て今は信じていません。2005年以降も、世界は変わっているのです。
スケールの方法に関する多くの書籍や資料のおかげで、スケールに関する知識は、以前ほど不十分で高価なリソースではありません。それはもはや、専門家たちの秘密結社に固く守られた秘密、といったものではありません。ニコラスが突入してのぞき見るまでは、彼らの乾燥した指は固く握られていましたが。現在では、computerista の熟練技術者であれば誰でも、スケーラブルシステムの設計についてはちゃんとした仕事ができますよ。
Kevin Johnson氏(source)は、この問題は「スケーラビリティは"最適化の問題"である」であるという考えから来ており、その他のファクターも"時期尚早なコストは、いずれ痛い目となって跳ね返る"と言うカテゴリーで考えているせいだとしている。
スケーラビリティを最適化の問題だと捉える事が根本的に間違っています。スケーラビリティは、非機能要求として捉えられるべきものです。それは裏方 - セキュリティ、メンテナンシビリティ、ユーザビリティ、そしてその他すべての「*lity」 - として企業を支えています。非機能要求の一番厄介なところは、プロジェクトのアーキテクチャ・デザインフェーズの最初の方で考慮しなかった場合、それらは明らかな作業のやり直しというリスクを引き起こす傾向があることです。
公平を期すため、Sinclair Schuller氏(source)はDharmesh氏がコメントに追記した、更なる理論的根拠を指摘している。
一点、私が記事には書きませんでしたが、おそらく間違いないのは、スケーラビリティに関するトレードオフが発生するとき、あなたはいくつかのレベルで技術的負債をこうむる、と言うことです。負債は常に悪いことではありません -- あなたの成長になることもしばしばです。はっきりさせておきたい点は、その負債の"金利"が、トレードオフの利益に勝っていないことです。そして、スケーラビリティ上のトレードオフを構築するのは、システム全体を書き換える必要性を生じさせるようなものですが、それはおそらく価値がありません。しかし、それは"今Xを払うか、後で1.2Xを払うか"と言う単純な問題で、いくつかのケースでは単にあとで1.2Xを払う方がベターな場合もあるだろう、と言うことです。
Jamie Flournoy氏は"キャパシティ 対 スケーラビリティ(source)"という記事で、興味深いポイントを挙げている。その記事によると、性能要求をベースとしたスケーラビリティにフォーカスする事を当然と思うことに、おかしな点があると示唆している。
スケーラビリティは、性能と言うコンセプトとはかけ離れたものです。スケーラビリティはシステムにおけるtrue/falseと言ったプロパティではありません。スケーラビリティの度合いと言うものがあり、二次元のグラフで表すことのできるものです。そのグラフは、同時に受け付けることのできるリクエストを表しており、望ましいレスポンスタイム (X軸) と、それらのサービスをさばくのに必要とされるリソース (Y軸) からなります。このグラフの裏にあるy=f(x)と言う方程式における関数fは、あなたのアプリケーションがどれくらいスケーラブルか、を表しています。
もしそれが直線であれば、それは非常に良いことです。"リニアなスケーラビリティ"と言うことです。リクエストが増えても、リクエスト毎に発生するコストの額は一定で、あなたが現在処理しているリクエストと変わりません。顧客が倍になれば、あなたの純利益も倍になります。
もしそのカーブが直線を下回るなら、それはリニアなスケーラビリティよりも良いということになります。あなたは規模の経済に到達しており、リクエストの数が二倍に増えても、あなたが現在支払っている額の二倍を下回るコストしかかからないということです。
もしそのカーブが直線を上回っているなら、それはいけません。負荷が高くなると、リクエストあたりのコストが増えていくということを意味しています。新しい顧客が増えるごとに、あなたのお金は減り続けます。ついにはあなたは破産し、ビジネスの失敗というポイントに到達するでしょう。
そして続けて、
しかしより興味深い質問は、性能を向上させるために必要なコストはいくらか、そしてあなたがお金を得る/失い始める、確実なリクエスト数と言ったものはあるのか、と言うことです。
プロジェクトの立ち上げにおけるソフトウェア設計とアーキテクチャは、ビジネスと技術の深いレベルにおけるトレードオフを、数多くやりくりする必要を生じることもしばしばである。プラットフォーム、データベース、言語、ツールと言った様々な要素が関与する。プロジェクトをいくつか成功させているアーキテクチャにとっての挑戦は、彼らの経験と直感を使って、意思決定プロセスを導き、彼らの事情に適応させる手助けをすることだ。Ted Neward氏が言うように(source)、"スケーラブルなシステムのアーキテクトというスキル"は"名誉の印"ではあるが、それは"技術の詳細と同様に、顧客/ビジネスの価値にもフォーカスする"、と言うアーキテクトの役割を揺るがすものだ。
アーキテクトは、ビジネスに著しく影響するような技術上の決断を行うために、頼られる存在でいることができるのだろうか？「設計/アーキテクチャに、あらかじめどれくらいの時間を割くべきか」と言う計算を行う場合、あなたはどんなガイドラインを使っているのだろうか？