『Software Design』12月号の萩原正義さんの記事
今頃になって、『Software Design』2009年12月号の特集「クラウドコンピューティングの技術で変わる開発方法」を読みました。
わからないことだらけなので、学んだこと、これから知りたいこと、疑問などをメモ。
データ、アプリケーション機能、トランザクションを分割する話
データの垂直分割のイメージはつかめた。でも、アプリケーション機能のボトルネックを見つけて、その部分のデータを「さらに適切にデータ分割」するというのは、どういうことなんだろう？
また、データ分割の手順も、実感がわかない。記事では、まず、保守のための論理的なデータ分割をして、次に、スケーラビリティのための物理的なデータ分割をするべし、とある。読むと、一見できそうに錯覚するけど、やっぱり、やってみないとピンとこない・・・。
データアクセス頻度、一貫性という耳慣れない要件の話
これまでのオンプレミスの開発でも、設計や実装で、システムやサービス全体に対する負荷については、考慮してきたと思う。でも、データを分割するという発想を持つと、個々のデータに対するアクセス頻度までをも、厳密に予想して、設計する必要がある。
一貫性についても同じ。記事では、一貫性の要求を分析する必要性が書かれていて、「アプリケーション機能の一貫性の要求のスペクトラム」という図も載っている。これまでは、一貫性が担保されることが前提のプラットフォームで開発してきたので、気にかけなくてよかった話だ。そこでの一貫性は、あるかないか、1か0かの話だった。でも、「一貫性をどれくらい厳密に確保したいか」を考える必要がある。なんだか未知の世界。
ところで、実際に、クラウドコンピューティングでサービスを構築したとき、定量的にどの程度、一貫性がないものなんだろう？ このあたりも、わかっていません。
コマンドとクエリ分離の話
UIとビジネスロジックの間にデータ層があるとか、データ一貫性は各層の中でのみ保証されるとか、概念でしかわからないよー。悲しい・・・。
特に、更新の窓口となるWeb roleと、観測するWorker role（←トランザクションの成功を監視する役割といってもいいのかな？）が、Queueを介して入力があったことを知る部分について、実装を知りたいです。
思ったこと
- ACIDトランザクションや低障害性といった従来のシステムの前提が、まるで弱者の論理のように思えてくる。弱者といっても、否定的な意味はなく、"巨大システムに対する相対的な弱者"くらいの意味で。
- 「従来の価値、つまり、データ一貫性や開発容易性を犠牲にしてでも、スケールと可用性をひたすら追求するのが、クラウドコンピューティング」と勝手に思っていたけど、ちがうみたい
思えば、去年から自分がこの分野について聞きかじってきたのは、BigTableやMapReduceといった実装寄りの話か、SaaSの進化系としてのクラウドがどうこうといったビジネス寄りの話だけでした。この記事のようなアーキテクチャの理論や開発手法の変化の話も、ちょっとずつ理解していきたいです。
『Googleを支える技術』、読んでみようかな。。。
