最新のOracle Databaseでストレージと賢く付き合う 第2回 Oracle Database 11g Release 2でSSDのメリットを最大限に生かす

多くのデータベース・システムにおいて、ストレージI/O性能がボトルネックとして顕在化している現在、これを改善し、大幅なパフォーマンス向上が期待できるデバイスとして大きな注目を集めている「SSD(Solid State Device/Drive)」。ただしSSDは、ある種のI/Oワークロードでは性能単価でHDDを凌ぐものの、その他のI/Oワークロードや容量単価ではHDDに遠く及びません。そのため、爆発的に増加を続ける大容量データのすべてをSSDに格納するのはコストが高く付きます。では、コストを抑えながらもSSDのメリットが最大限に得られるようにするにはどうしたらよいのでしょうか。今回は、SSDの特性を正しく理解したうえで、Oracle Databaseとともに賢く使いこなすためのポイントを紹介します。

語り手:
日本オラクル株式会社
テクノロジー製品事業統括本部
アライアンス技術本部
アライアンス技術部
エンジニア
岩本知博

■ストレージI/O性能のボトルネックとSSDへの期待

 ストレージを構成する外部記憶装置として現在広く使われているHDDの技術進歩は、デバイス当たりの大容量化が主であり、性能(rpm/回転速度)自体は数年前から向上していません。一方で、CPUのマルチコア化やメモリの大容量化、およびデータベース・サーバとストレージ間を接続するネットワークの広帯域化が急速に進んでおり、HDDの性能との格差が生まれています。この性能格差のため、現在のデータベース・システムではストレージI/O性能がボトルネックとなりがちなのです。

 このような背景の中、I/Oの高速化で注目を集めているのがSSDです。SSDは不揮発性のメモリであるフラッシュメモリを記録媒体として利用し、HDDのように可動部を持たないことから、HDDのI/O処理時間中の大部分を占めるシーク動作(磁気を読み取るためのヘッドを目的のトラックまで移動させる動作)が不要です。そのため、HDDに比べて高速にデータへアクセスできることが最大の魅力となっています。

 ただし、単純にHDDをSSDに置き換えれば速くなるというわけではありません。例えば皆さんは、次のような調子でSSDの使用を決めてはいないでしょうか。

マネージャー:「OLTPシステムのアプリケーションが遅いって文句が来ているぞ。最近はスマートフォンなどが普及したおかげで、いつでも、どこでもシステムにアクセスできるようになっているからな。利用者数が増えて、ハードウェアのリソース的に厳しくなっているのかもしれないなぁ。OLTPシステムのセオリーどおり、とりあえずメモリを追加しておくか。」

エンジニア:「現状の予算だと、これ以上のメモリ追加は厳しいですね。そもそも、今使っているサーバには、もうメモリの空きスロットがありませんし。あ、そうだ! 最近、SSDっていうのが流行っているみたいですよ。HDDと比べて圧倒的に高速で、システムの性能向上に最適だと言われています。」

マネージャー:「それだ! SSDの上にデータファイルを置いてみるか。早速、見積もりを出してもらってよ。もしかしたら、REDOログ・ファイルでも効果があるんじゃないか!?」

■Oracle DatabaseでSSDに効果があるのはどんな場合か?

 これまで、OLTPシステムの性能劣化には、データベース・サーバのメモリ増設が効果的でした。メモリを追加することで、Oracle Databaseのキャッシュ領域(データベース・バッファ・キャッシュ)に、より多くのデータをキャッシュでき、ストレージへのI/O量が削減され、OLTPシステムの性能向上が期待できるからです。しかし、メモリは大容量になり低価格化が進んだと言っても、いまだ容量当たりの単価が高いデバイスです。また、近年はユーザー数とデータ量の増加により、メモリ上で同時に処理する必要のあるデータ量も飛躍的に増加したため、それに合わせてメモリ・サイズを増加させると非常にコスト高となります。また、そもそもデータベース・サーバのメモリ・スロットに空きがなければ、それ以上メモリを追加することはできません。

 コスト的、もしくは物理的な制約からメモリ増強では対応できない場合、ストレージI/Oを高速化するというアプローチが有効となります。そこで注目されているのが、HDDを高速I/Oが可能なSSDに置き換えるという方法です。とは言え、SSDの特性から、すべてのI/OワークロードでHDDの性能を大きく凌ぐわけではありません。I/Oワークロードは通常、次のように大別されます。

●HDD上に配置されたデータに連続してI/Oする「シーケンシャル・リード/ライト」
●HDD上に配置されたデータにランダムにI/Oする「ランダム・リード/ライト」

 さらに、単位I/O当たりのデータ・サイズの違い(スモール/ランダム)によっても分類できます。そして、SSDが性能単価でHDDを凌ぐのは、スモール・ランダム・リード(HDD上に分散されて配置されているデータを、小さい単位で読み込む)のみとなります。その他のケースでは、より多くのHDDで負荷分散(ストライピング)を行うために、HDDを追加するほうが、コスト・パフォーマンスが高くなるのです。

 Oracle Databaseにおいても、スモール・ランダム・リードが発生するファイルをSSD上に配置するのが効果的なアプローチとなります。では、データベースでスモール・ランダム・リードが行われるのはどのような場合でしょうか? それは次の3つのケースです。

●OLTP処理
 データファイルへのI/Oはデータベース・ブロック単位で行われ、スモール・ランダム・リード/ライトになります。一般的なOLTPシステムでは、スモール・ランダム・リードが多くの割合を占める傾向にあり、SSDの効果が高いと言えます。

●リカバリ処理
 リカバリ処理では、データファイルからのスモール・ランダム・リードが発生します。そのため、SSDをうまく利用することで、リカバリ時間の短縮が期待できます。

●ディスク・ソート
 DWH/バッチ処理の場合、一時表領域を使用したディスク・ソート処理においてスモール・ランダム・リードが発生します。SSDは大規模な表の並び替えや結合などの処理において高い効果を発揮できるでしょう。

 I/Oのチューニングでよく話題になるREDOログ・ファイルは、ランダムではなくスモール・シーケンシャル・リード/ライトのため、SSDを利用するメリットはあまりありません。前述のように、HDDによるストライピングのほうがコスト・パフォーマンスは高く、効果的です。

■SSDの有効利用を実現するDatabase Smart Flash Cache

 SSDを利用すると性能は向上できますが、コストは高くなります。コストを抑えながら効率的にSSDを利用する方法はないでしょうか。コスト高になりがちなSSDを効果的に利用するアプローチが、よくアクセスするデータだけをSSD上に載せるという方法です。データファイルをすべてSSD上に配置すれば性能を高められますが、それだけのSSDを用意するには多くのコストがかかるためです。

 本連載の第1回でも紹介した「Oracle Partitioning」は、アクセス頻度や重要度に応じて最適なストレージにデータを配置する「ILM(Information Lifecycle Management)」の考え方に基づき、テーブルを時系列で分割する仕組みを提供します。アクセス頻度が高いデータだけをSSDに配置することで、SSDを効果的に利用できるわけです。
img_storage_110512_01.jpg
 ただしILMでは、アクセス頻度や重要度が高いデータを常にSSD上に配置しておくためのメンテナンス作業が必要になります。例えば、日常業務で増えていくトランザクション・データであれば、使用頻度が低くなった昨四半期のデータをSSDからFCのHDDに移し、使用頻度の高い今四半期のデータだけをSSD上に保持するといった作業が必要になるのです。

 では、ILMのようなメンテナンス工数をかけずに、アクセス頻度の高いデータをSSDに自動配置して効率的な性能向上を実現できないか?この課題を解決するためにOracle Database 11g Release 2のEnterprise Editionから標準搭載されたのが「Database Smart Flash Cache」です。

 Database Smart Flash Cacheでは、SSDをデータベースのキャッシュ領域、つまりメモリのように活用します。SSDは容量単価でHDDに遠く及びませんが、一方で同容量のメモリと比較すればはるかに低コストです。Database Smart Flash Cacheを利用することで、メモリを追加するよりもはるかに安く大容量のキャッシュ領域を確保でき、OLTPシステムの性能を高められるのです。
img_storage_110512_02.jpg
 Database Smart Flash Cacheの領域(SSD)には、データベース・バッファ・キャッシュからキャッシュ・アウトされたデータ・ブロックが自動的に配置されます。つまり、アクセス実績のあるデータがSSD上に配置されることになります。その結果、それまではアクセス頻度が高いのにもかかわらずメモリが不足しているためにHDDから読み込んでいたデータを、高速なSSDから読み取ることが可能になり、レスポンスタイムが大幅に改善できます。

 以下に示すグラフが、Database Smart Flash Cacheの効果を示す検証結果です。青いグラフは、データ量の増加に伴いキャッシュ・ヒット率が減少し、ストレージI/Oが多発して、それがボトルネックとなり性能が大きく劣化していることを示しています。また、赤のグラフは、Database Smart Flash Cacheを使用することで、その性能劣化を最小限に抑えられることを示しています。同じことはメモリの追加によっても実現できますが、より多くのコストがかかります。それにDatabase Smart Flash Cacheであれば、今後ますます増加していくデータ量に追随し、メモリでは物理的に実現できないサイズにまで拡張していくことが可能なのです。
img_storage_110512_03.jpg
 加えて、Database Smart Flash Cacheをデータ圧縮技術と組み合わせることで、さらに効果的に利用することができます。

 第1回でも紹介したとおり、Oracle Database 11g Release 1 Enterprise Editionから実装されたデータ圧縮機能「Oracle Advanced Compression」では、圧縮したデータを圧縮状態のままでキャッシュします。これにより、同じ容量のメモリ上に、より多くのデータをキャッシュすることが可能になります。Database Smart Flash Cacheの領域(SSD)についても同じことが言え、貴重なSSD上にさらに多くのデータを配置できるようになります。

 Database Smart Flash Cacheを使用している場合でも、データ量(レコード数)がDatabase Smart Flash Cacheの領域サイズを超えたら、ストレージへのI/Oが発生し、それによって性能が劣化することがあります(上の図の青のグラフ)。そこで、Oracle Advanced Compressionでデータを圧縮しておけば、より多くのレコードをDatabase Smart Flash Cacheの領域にキャッシュすることが可能になるというわけです。

 なお、「Oracle Exadata」にはExadata Smart Flash Cache機能が実装されており、Oracle Exadata Storage Serverに搭載する最大5.3TBのフラッシュメモリをストレージ・キャッシュとして利用することで、高いパフォーマンスを実現します。データベース・サーバとフラッシュメモリは40ギガビット/秒と高速なInfiniBandで接続されているため、フラッシュメモリの性能を最大限に活用できるのです。

Comments:

Post a Comment:
Comments are closed for this entry.
About

Twitter
Facebook

Search

Recent Posts
Archives
« 4月 2014
  
1
2
3
4
5
6
7
9
10
11
12
13
16
17
18
19
20
22
23
24
25
26
27
28
29
30
   
       
Today