仕事の分割
シンプルと感じているのは自分だけの可能性 - 計算機と戯れる日々を読み直してたら最近思い当たることがある。
人が「できない」と考えるのは自分の経験に基づいて判断している。集団で開発プロジェクトを動かす際にも誰に何をさせるかを決めなければならない。上位組織が完全に下位組織の動きを把握できるわけでは無いのだから、そのアルゴリズムは必ず分割統治を行うしかない。＞分割統治法 - Wikipedia
構造化、クラス化、モジュール化いろんな言い方があるがつまりは分割統治で「これ以上細かいことはそれ以下のモジュールに任す」しか方法が無い。もし把握できるのならばその人一人でできることを意味するが通常はそんな時間が無いつまり一人ではできないため多数でプロジェクトを形成している。このため任意モジュール正しさはモジュールの入力と出力をもって行うしか方法が無い。
エクストリーム・プログラミング - Wikipediaに代表されるテスト駆動開発 - Wikipediaは他人に任せるための一手法として捕えることができる。
一方、失敗を織り込み済みでタスクの分割ポイントを探る手もあるのかもしれない。つまり、タスクの分割ポイント自身をトライ＆エラーで探るということだ。
しかし、多くの場合、そのような分割は開発プロジェクトの迷走ととられてしまう。トライ＆エラーの部分的な失敗を全体的な進捗ミスとして指摘する人間は必ずいる。おそらくこのタイプの人間はミスをあらかじめ計算できないのであろう。もしくはミスの指摘をもって己れの成果としている可能性もある。もともとエラーを内包するプロジェクトは研究なのかもしれない。もしかすると分割されたモジュール内におけるトライ＆エラーは表に出ないので許されているだけかもしれない。
またモジュールの分割で悩ましいのがハードウェアを何台用いるかという点である。
開発プロジェクトは決められたハードウェアで行うため、ハードウェアはプロジェクト開発時には決定されている必要がある。もちろんハードウェアのスペックの詳細は必要ではないが、ハードウェアの分割によりハードウェア自身の代金、接地面積、電力等のトレードオフが存在し、ハードウェアの台数決定とソフトウェアのモジュール分割の関係が鶏と卵になっている。
そこでオラクル／ＩＢＭ（ＤＢ２）に代表されるリレーショナルデータベースベンダはすべてのデータスプールを一台に見せかけるようにデータベースをチューニングさせる。
ところがこの行動は主に客の発注による適当なテーブルの正規化により生成された複数テーブルのジョインを導いてしまう。まあ小規模データではこれで充分なのだが数万以上の大規模データではすぐに破綻する。
これを回避するために以下の方法が現時点でとられている。
１．インデックスを張る
予めジョインされるテーブルのフィールド（カラム）にインデックスをはりジョインの速度向上を目指すことが行われているが、実はこの行動はインデックスをはっているが故にインデックスのカラムの更新速度が遅くなるという問題点をもつ、また、常にジョインするフィールドを先行で予測する必要があり、規定外のアクセス（ジョイン）が行われた際にデータベースそのものが遅くなるというリスクもある。（まあ、時間の割り当てで回避している例も見たことあるけど）
２．テーブルを一つにする
ＲＤＢを捨てるという選択肢をとってしまっている。いわゆるkey-value型のデータベースはテーブルを一つにし、検索対象のフィールドを一つに限定したものだといえる。
テーブルを単体にするという発想をもつデータベースはまだ探せていない。
また全文検索 - Wikipediaは一つの文書をレコードとするワンテーブルデータベースということもできる。
以上の理由により、１．つまりＲＤＢには未来が無い。いやまあ超並列計算機があれば未来はあるんだけど…まだできそうにないよね?
そうするとワンテーブルのデータベースでどのようにレコードを分割して保持するかというmap-reduce型しか現時点で大規模データを扱う解がないことになる。
map層でテーブル内のレコードを分割保持し、reduce層で集計する。まあ、reduce層がボスワーカーモデルのボスになってしまうが、ボス自身を複数にして並列化すれば問題は生じない。
ここで問題になってくるのが、レコードを単体にすることの難しさだ。レコード内に更新トランザクションを内包するため更新ロックの範囲が難しい。それによりすべての更新履歴を繰返項目として持つためレコード内の検索には全文検索並もしくはそれ以上の検索言語が必要になるだろう。そうでなければ任意レコードロック中に対象レコードが検索対象外となりデータベースの完全性を満たすことができない。
まあ、データベースの話でもわかるようにどのようなマシンの台数と接続形態を採用するかによってシステム全体のアーキティクチャは全く異なる。
もちろんデータベースへの問い合わせ及び返り値を用いるアプリケーションの作りも全く異なる。この辺を開発プロジェクトをスタートする前に作ってしまうのは無理なんじゃないだろうか。
なぜかというと並列性を考慮した形でモジュール分割を設計するためには、以下の問題を考慮し分割しなければならない。
* 2.1 アムダールの法則とグスタフソンの法則
* 2.2 データ従属性
* 2.3 競合状態、相互排他、同期、並列スローダウン
* 2.4 細粒度並列性、粗粒度並列性、自明な並列性
* 2.5 一貫性モデル
* 2.6 フリンの分類
また、現在の自分が目にする開発ではベストエフォート - Wikipediaという概念をSLAに組み込んでいるとは言い難い。
極論だがたとえサーバにリクエストを出したとき返答が無ければ人間がリロードボタンを押せば良い場合もあるはずだ。なんでも１００％に組んでしまう考え方はシステムの高コスト化を招く。
並列性の観点で同期のポイントをなるべく減らすようなスキルは現時点でモジュールの分割者はもっていない。もちろん並列性を考慮しないシングルタスクのプログラムは余裕でできる。
彼らがモジュールを設計するとどのようなことになるかというとＲＤＢに排他制御を行わせるスケーラビリティーの無いシステムになるという罠がそこかしこにはられている。
そして「プラチナマスターしかテーブルは設計できません」「プラチナマスターしかテーブルの最適化はできません」「プラチナマスターが…」 なんというパラノイア (TRPG) - Wikipedia
どうかオラクル税、ＤＢ２税を払わない世の中になりますように…
＃最近はmysql税になってるという説もある。
原因は実際に経験していないことにあると思われる。というかEC2/S3とかのサービスを使って高可用性／高並列性のあるシステムを組んでいけばスキルはたまっていくのだろうか。
これらシステムが社内の秘匿性の観点で企業に納入されるのが先か、(S|P)aaS等のサービスを企業が使うようになるのか。IaaSが勝つのか？
まあ、@IT等を読んでると情報処理部門を子会社化している会社が多いように思えるので(S|P|I)aaSに抵抗はなさそうだな。
セキュリティーの考え方を整理しなきゃいけないけど。
となると問題はtwitterのように個人がIaaSでサービスを立ち上げて大会社化するか、企業が(S|P|I)aaSを使えるようになるかということか。
まあ、前半で述べたとおり企業が(S|P|I)aaSを使えるようになるのは程遠い気がするけど。たぶん必要性も理解できないような…
お後がよろしいようで。
