JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

キャッシュ・チェック

キャッシュは、データのリクエストに応答するために高速のストレージを使用する。キャッシュの形態は、揮発性または不揮発性の半導体メモリー、あるいはディスクやテープの場合もある。一つのアプリケーションからデータがある場所までのデータパスには、たくさんの種類のキャッシュが存在していることがある。CPUには三種類のキャッシュがあり、ストレージかネットワークのホストバス・アダプター（HBA）にひとつ、ストレージシステムのRAIDコントローラーにひとつ、ストレージコントローラーに5、6個、そして場合によっては、ストレージに数段階の自動ティアリングまたはキャッシュがあり、さらにはストレージを構成する個々のディスクにもキャッシュが搭載されている、というわけだ。これらキャッシュの多くが自動的に設定されているので、一見ささいに思えるかもしれないが、アプリケーションとデータを最適化して、データがキャッシュから提供されるようにすると、アプリケーション全体の速度にとてつもなく大きな差が生まれる。例えば、RAIDコントローラーのRAMキャッシュのバッテリーバックアップがなくなると、一般的にRAIDコントローラーはデータをディスクのみから提供するセーフ・プロトコルにモードを落とす。停電が起きたらRAMキャッシュに保存されているデータは壊れてしまうかもしれないからだ。これによって、ストレージのリード／ライトの応答時間は10倍低下する。

データ・リクエストをキャッシュから提供するように、ストレージシステムをチューニングすることでも、非常に大きな差が生まれる。もしシステムで使用されるデータの量が、キャッシュにとって大きすぎる、あるいは読み書きされるデータが非常に不規則な場合、パフォーマンスは低下することが多い。

あなたのストレージシステムは、キャッシュから提供されるデータの割合を知らせる機能を持っているはずだ。もしその割合が90%以下であれば、ストレージコントローラーにRAMを追加するという単純な方法で問題は解決するかもしれない。ストレージコントローラーのRAMを32GBから倍の64GBにすれば、レイテンシが10倍改善することもある。

ネットワーク・チューニング

キャッシュ、使用するディスクの速度・種類以外に、ファイバチャネル、iSCSI、FCoE、のいずれであろうと、ネットワークがストレージのパフォーマンスを左右する第3の柱だ。パフォーマンスが落ち始めたら、ネットワークの速度を上げるのが定石だが、ネットワークをアップグレードするような極端なことを行う前に、ネットワークの飽和状態やスループットなどのパフォーマンス特性を調べるのが重要である。

例えば、ある大きなストレージシステムがあったとして、そのほとんどはハードディスク・ドライブ（HDD）で構成されており、近頃パフォーマンスが落ちてきていたとしよう。アドミニストレーターたちは、ネットワークを1Gbpsから10Gbpsにアップグレードした。しかし、アップグレード後もパフォーマンスはほとんど変わらない。そこで彼らは、HDDに替えて半導体ドライブ（SSD）を入れた。すると、パフォーマンスは大幅に向上した。10Gbpsネットワークが高速SSDのパワーを引き出したのだ。

もし、彼らが最初にHDDをSSDに替えていたとしても、おそらくパフォーマンスには同じような大きな差は生じなかっただろう。高速なSSDストレージのパフォーマンスが、1Gbps Ethernetのレイテンシとスループットによって相殺されてしまうからだ。この二つの領域がアップグレードされたら今度は、問題は三番目の領域へと移った。アプリケーションが稼働しているサーバーのデータ取り込み能力だ。ネットワークとドライブの交換によって、サーバー使用率が10%から70%近くまであがってしまった。これは次のボトルネック対策がおそらくはCPUとRAMのアップグレードであることを示している。アプリケーションの使用率は増え続けていたからだ。

VMとクラウド内のストレージ

クラウドストレージは当初、バックアップとオフラインストレージを主たるターゲットにしていた。しかし最近では、1台もしくは数台のプライマリ・ストレージをクラウド内に置く企業も出てきた。Amazon Web ServicesやMicrosoft Azureなどのクラウド内に置かれているVM用ストレージは、一般的に同じクラウド内にあることが多い。大手クラウドベンダーの大半は、他ベンダーと非常に高速かつ低レイテンシでつながっているため、あるクラウド内である部門が、あるアプリ専用のローカルストレージとして設置していたストレージが、別なクラウド内に設置されたアプリから接続されてしまう、などということも起こりうる。
中には、クラウド内にあるデータをあたかもローカルのデータセンターにあるかのように使うために、キャッシュ・アプライアンスを使う会社もある。このような使い方をすると、ただでさえVMが無秩序に分散されている状況（VMスプロール）に、さらに無秩序にデータを加えてしまうようなことが簡単に起こってしまう。

データが簡単に動き回れるようになると、その管理は困難になる。データ管理アプリはこれらの問題を解決するのを助けてはくれるが、最初に取るべき手段は技術的なものよりむしろ社内規則の徹底だろう。各部門が会社の規則を守らずに、勝手に自分たちのVMを設置して自分たちのアプリ開発をしていないかを、まずは確認することだ。
規則を文書にして施行すれば、管理者の仕事は大幅に軽減されるはずだ。

ストレージ・チューニング

パフォーマンス・ボトルネック回避のために、市場で入手可能な最速の全半導体ストレージシステムをドンと入れてみたい、という考えは魅力的に思えるかもしれない。しかし、これは必ずしもあらゆるストレージの問題を改善してくれるわけではない。そのうえ、この方法は大概非常に高くつく。

高速SSDのティアおよび正しく構成された大容量HDDのティアからなる、超高速RAMキャッシュ付ティアードストレージシステムの方が、全半導体ストレージシステムより高速かもしれない。おまけに物理容量の点から見れば、こちらの方がはるかに安くつくだろう。多くの全半導体ストレージシステムは、重複排除機能をONにした状態のデータストレージ容量に基づいて宣伝されている。この場合の圧縮率は一般的に2倍から3倍以上だ。

正しく設定されたRAMのキャッシュ・アルゴリズムと、適切にサイジングされたティア1のSSDであれば、90%以上（最高で99%）のリクエストがRAMキャッシュから提供され、キャッシュから提供されなかったリクエストの99%はSSDレイヤー（層）から提供されるようになるだろう。RAMキャッシュはSSDティアの10％程度、SSDティアはHDDティアの10%から20%程度だろうから、比較的少ないコストで非常に大きくパフォーマンスを増やすことができるわけだ。キャッシュとティア１から提供されるリクエストの割合を常に監視しておくことが大事だ。この割合が大きく低下したならば、システム全体のパフォーマンスはその何倍もの幅で低下する。各ティアの下位の層は上位の層より5倍から20倍遅いからだ。

著者略歴：Logan Harbaughは、フリーのレビュアー兼IT業界で25年以上のキャリアを持つITコンサルタント。