X

An Oracle blog about Oracle Coherence

【技術コラム 第1回】 増え続けるデータに対処せよ! その1

Guest Author

データ処理を高速化する インメモリ・アーキテクチャ 大量データを高速に処理し、可用性/スケーラビリティを高める--コモディティ・サーバを活用したインメモリ・データ・グリッドの效用

最近、一部の企業において、データ・アクセスに関して従来とは異なる考え方/アーキテクチャを採用する動きが起きている。これは、見方によっては"プライベート・クラウド"ともとらえられる、インメモリ型のデータ管理層を取り入れたアーキテクチャだ。
本パートでは、この動きの背景にある課題や技術動向などにも触れながら、インメモリ型のデータ管理という新たなアーキテクチャ手法の概要や企業システムにおける使いどころなどを紹介する。

増え続けるデータに対処せよ!

大量のトランザクションを処理するために、大型のサーバが使われるケースは少なくない。確かに大型のサーバは高性能であるし、通常は障害対応の仕組みも搭載しており、そうした面では申し分のない存在だ。しかし、その分"高価"である。いくら高性能なサーバを導入したとしても、トランザクションが増え続ければ、いつかは処理性能が限界に達する。そして結局、追加のサーバを投入せざるをえなくなり、さらにコストがかさんでいくことになる----このような具合に、増え続けるトランザクションやデータへの対応に苦慮している企業は多い。この問題がやっかいな点は、最初に「アプリケーションのスローダウン」という現象として表面化してくることだ。そのため、「パフォーマンスを改善しなくては」という意識で対応しがちだが、問題の核心はチューニングにではなく(チューニングしても、性能の限界点を先延ばしにするだけである)、「妥当なコストでシステムを拡張していけるかどうか」ということにある。

データ処理のボトルネックがシステムの性能向上を妨げる

では、コストが問題だとしたら、近年、性能向上が著しいコモディティ・サーバを並べるスケールアウトのアーキテクチャを採用すればよいのだろか。確かに、それは有力な解の1つだが、それで問題の根本が解決するわけではない。これについて、ある企業のシステムを例にとって説明しよう。

この企業では、大量のトランザクション/リクエストをさばくために、複数のアプリケーション・サーバを並べて負荷分散するという一般的なアーキテクチャをとっていた。リクエストの増加に応じてアプリケーション・サーバを追加していたのだが、やがて追加台数に見合った性能が得られなくなってきた。
システムの性能向上が頭打ちになった理由はいくつか考えられる。まず複数のアプリケーション・サーバからのデータベースへのアクセスの集中がボトルネックになっていたり、データベースのロックを引き起こしていたりする可能性がある。また、耐障害性確保のために、アプリケーション・サーバ側でセッションのインメモリ・レプリケーションを設定していたが、サーバ台数の増加に伴ってその処理が追いつかなくなっている可能性もある。あるいは、インメモリではなく、データベースやファイル・ベースのレプリケーションを行っており、そのディスクI/Oの増加に性能が引きずられているのかもしれない----これらの何が原因であるにせよ、結局、データの処理がボトルネックとなり、ハードウェアへの投資に見合った性能向上を妨げているのである。

データ処理はどうあるべきか

上の事例のようなケースは今日よく見られるものだが、それらに共通しているのは、データ処理のボトルネックがシステムの性能向上を妨げ、ひいては投資対効果(ROI:Return On Investment)を低下させているということだ。今日のシステムにおいて、データ処理はボトルネックの代表格なのである。

アプリケーションが持つ4種類のデータ

もっとも、一口にデータ処理と言っても、これにはさまざまなものがある。ここで、昨今のアプリケーションが扱うデータにはどのような種類があり、その処理形態はどうあるのが望ましいのかを簡単に整理しておこう。
アプリケーションの内部では、主に次の4種類のデータが使われる。

  • 1)全体で共通に使われる参照情報(マスタ・データ、ユーザーの個人情報データなど)
  • 2)システム上で発生する入力情報(トランザクション・データや注文/申請データなど)
  • 3)ユーザーに固有のアプリケーション定義情報(アプリケーション固有のプロファイル情報や画面表示の設定情報など)
  • 4)アプリケーション上での一連の作業状態に関する情報(セッション情報)

このうち、(1)と(2)は業務履歴として保管する必要性があったり、後々の傾向分析などのために蓄積しておくべき情報だったりする。関係各所からの問い合わせに迅速に対応できるよう、これらはRDBMSで管理するのが望ましいだろう。
一方、(3)と(4)のデータは、特定のアプリケーションだけで必要となる情報であり、分析の必要性も低いので、必ずしもRDBMSで管理する必要はない。だが現実には、データの信頼性確保やレプリケーション負荷の軽減のために、RDBMSに格納しているケースが多い。
データ処理の性能やROIを高めるには、少なくとも(3)、(4)のデータを管理する方法を再検討するとともに、(1)、(2)のデータのうち、オンライン処理で使われる部分(オンタイムのスナップショット・データなど)を極力、高速なアクセスが可能な環境に置くことが望まれる。

"インメモリ"でデータ処理を高速化する

その「高速なアクセスが可能な環境」として近年注目を集め、技術開発が活発化しているのが「インメモリ」の領域である。本稿で扱うインメモリ型のデータ管理方式とは、従来RDBMS(ストレージ)内に置かれていたデータをメモリ上に配置することで、データ・アクセスの高速化を図るというアプローチだ。これを上記(3)、(4)の用途で使うには、次のような条件を満たすことが求められる。

  • メモリ/データの信頼性や耐障害性を確保する
  • メモリ上のデータのレプリケーションにかかる負荷を最適化する
  • 大量のデータを格納可能なメモリ容量を確保する

メモリ価格の低下などもあり、近年のインメモリ型データ管理方式はこれらの条件をクリアし、実用的なアプローチとして注目を集めつつあるのだ。

※本コラムは、ITアーキテクトVol.22の掲載記事「データ処理を高速化するインメモリ・アーキテクチャ」を、ITアーキテクト編集部の了承を得て掲載しています。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.

Recent Content