ITA Issue Article
ソーシャルブックマークに登録 ：
ITA Issue 連載 : RDBMSへの過度な依存からの脱却を目指して
スケーラブルなO/Rマッピングの実現手法
第1回 現状のO/Rマッピング手法に潜む問題点
RDBMSは偉大な存在だ。エンジニアが無意識のうちに過度な“依存症”に陥るほどに――本連載では、RDBMSが現在担っている責務を見直し、オブジェクト指向による再利用を生かしたマッピング手法を用いてITシステムのTCOを抜本的に削減するためのアプローチを示してみたい。初回となる今回は、RDBMSへの過度な依存の中で生じてきた今日のO/Rマッピング技術の課題や潜在的な問題を明らかにし、次回以降の議論の足場を構築する。
2008年6月30日更新
既成の概念にとらわれず、最適解を探し求めて
今日のシステム開発において、だれもが当たり前だと考え、半ば自動的に結論を導いている“型”がある。本連載は、その“型”を外し、もう一度ゼロから思考の旅に出ることを目指したものだ。読み進めていくうちに、読者にとっての常識とは大きく異なる点が出てくるだろう。そのときには、1つ考えてみてほしい。自分の常識が何を土台にして形成されたものであったのかを。同じ課題でも、前提が変われば解法が変わる可能性がある。その可能性を完全に否定する前に、今一度、自身の問題領域を整理してみてほしい。解決領域とは切り離して……。
筆者は、ソフトウェアの進化の系統は、必ずしも1つに限らないと考えている。近年の進化や常識を土台にすることは、人材活用の観点からも望ましいことは承知しているつもりだ。プロジェクト単位で考えれば、今あるもの、一般的なものを最大限に活用し、組み合わせて作るのが、リスク管理の観点から言えば正解なのかもしれない。
しかし、保守や再構築など、システムの将来まで見据えたときにはどうだろうか。さらに、プロジェクトをまたがり、より広い範囲で最適解を求めた場合には、答えが変わる可能性がある。ここでポイントとなるのは「時間軸の設定」だ。本連載で解説する技術は、長期的な視野で最適解を考える「ソフトウェア・プロダクトライン（Software Productline）」を追求する中で、30年以上も昔の先人たちの叡智に思いを馳せながら蓄積してきたものである。
アプリケーション・サーバを有効活用してスケーラビリティを確保する
本連載では、今日一般的に行われている“RDBMS偏重”のアーキテクチャ設計により、システムの総所有コスト（TCO：Total Cost of Ownership）が上昇していることを課題として取り上げる。その解決策として、RDBMSで行わせる仕事を必要最小限にし、アプリケーション・サーバを有効に活用することでスケーラビリティを高め、リアルタイム処理能力を最大化するアーキテクチャを提示したい。そのアーキテクチャは、システム全体の構成をシンプルにするとともに、システムの投資対効果（ROI：Return On Investment）を高めるものでもある。
RDBMSへの処理負荷の集中は、RDBMSが担う「データの一元管理」という役割上、避けることはできない。そのため、ディスクI/Oがボトルネックになると、スケーラビリティを保てなくなる点が問題となる。ボトルネックを解消するために、メモリを追加したり、データの事前加工（バッチ）処理を施したりといったことをするわけだが、これらの施策がシステムのTCOを上昇させているのだ。
では、コストを抑えつつスケーラビリティを保つには、どうしたらよいのだろうか。その具体策として、本連載ではハードウェア（I/O）の性能に依存していた個所をソフトウェア的に処理する手法、つまりCPUパワーを有効に活用する手法を提示する。この手法の実現でポイントとなるのが、「どこのCPUを使うのか」ということである。負荷分散が可能なトランザクション単位の処理に、高い信頼性が要求されるRDBMSのCPUやメモリを使うのは不経済である。それらを使うのではなく、今日相対的に安価となったアプリケーション・サーバ・マシン（64ビットCPU、マルチコア、低価格な大容量メモリ）を最大限に生かしたソフトウェア・アーキテクチャが今、求められているのだ。
連載第1回目となる今回は、データ・インテンシブな大規模アプリケーションを開発／保守するうえで、現在普及しているオブジェクト／リレーショナル（O/R）マッピング手法では解決できない課題があることを指摘する。そして次回以降では、それらの課題を解決／軽減するためのアプローチを明らかにしていく。
