本ブログエントリーはPernixData社のプロダクトマネージャであるTodd Mace氏のブログ記事を翻訳しています。
本記事の原文はIn Memory Computing - A Walk Down Memory Laneで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
PernixDataの製品担当VPであるBala Narasimhanをゲストに迎えて記事をかけることを喜ばしく思います。彼はインフラストラクチャレベルのインメモリーコンピューティングについての新しい連載を始めようとしています。これは将来的にあなたの環境の考え方や設計を変えていくことになるでしょう。お楽しみに。
インメモリーコンピューティング(IMC)は近頃、再び脚光を浴びています。この記事ではメモリレーンを散策(特に深い意味はありません)し、IMCの進化について追求していきます。特に我々はストレージシステムとIMCの接合点をフォーカスしていきたいと思います。
以下はIMCの進化の簡単なタイムラインを表したものです。
IMCはもともとはオペレーティングシステムや各種データベースのバッファキャッシュと呼ばれていたものです。バッファキャッシュは今日でもこれらのソフトウェアシステムに統合されたパーツとして残っています。バッファキャッシュは直近でアクセスされたデータのReadキャッシュです。ディスクアクセスを避ける事ができるため、バッファキャッシュにヒットしたReadは高速になります。しかしながら、Writeはその下にあるデータストアと同期させる必要があります。これはつまり、バッファキャッシュはReadの助けにはなりますが、Writeの手助けにはまったくなりません。全てのデータをメモリ内に保持し、高速なクエリ処理を実現するインメモリデータベース(IMDB)が1990年台に登場しますが、さほど大きな進展はしませんでした。近年になってIMDBは再び脚光を浴びるようになり、データベースの業界において、大きな話題となっています。再び光を浴びている理由の一つにはサーバに搭載できるRAMの総量が劇的に大きくなったことが挙げられます。1台のサーバが1テラバイト以上ものRAMを保持できるのです。IMDBもバッファキャッシュと同様に、Readをうまく取り扱うことができますが、Writeについては永続的なメディアとの同期が必要という理由のため、パフォーマンスについてはペナルティを受けてしまいます。2000年台のはじめ、Memcachedのようなメモリキャッシングライブラリが登場します。これによってアプリケーションはアプリケーションのロジック内でメモリのパフォーマンスを活用できるようになりました。アプリケーションのオーナーはAPI経由でこれらのライブラリを利用し、よく利用するものをメモリを使ってキャッシュすることができるようになったのです。残念なことに、利用するメモリキャッシングライブラリ自身の変更や、アプリケーションへの変更はアプリケーションを完全に書き換えるということを意味していました。
これらのすべてのアプローチはメモリを不揮発性のキャッシュとして活用しようというアプローチでした。つまり、これらのすべてのアプローチはReadキャッシュのアプローチであり、アプリケーションの一部のみの高速化に過ぎないということです。更に重要なことは、これらのすべてのアプローチはインメモリーコンピューティングをアプリケーションの中に押しこむようなものだということです。これによって多くの不幸な副作用が起こります。
- アプリケーションは不必要なまでに複雑になります。複雑なキャッシングのロジックと後ろのデータストアとの一貫性の保証を維持していかなければなりません。
- どのようにIMCを活用するか考える責任はエンドユーザーに覆いかぶさります。バッファキャッシュの適切なサイズを決めたり、どのテーブルをRAMに配置するかなどの判断はオーナーが判断しなくてはなりません。
- アプリケーションのオーナーは必ずしもアプリケーションが展開されているインフラを管理できるとは限りません。むしろ、不幸なことに(サーバなどの)インフラストラクチャがどのように利用されていたり、拡張されていくかを知らないまま、どれだけのメモリをアプリケーションがキャッシュとして利用できるか決めなくてはなりません。さらに、アプリケーションのオーナーは同じサーバ上で他にどのようなアプリケーションが動作しているかを俯瞰的にみることもできません。
- メモリ管理についての革新を活用するということも非常に大きな困難です。NUMAはアプリケーションがNUMAに対して対応しなければその恩恵をうけることができないという意味で、非常に良いインフラストラクチャレベルの革新の例と言えるでしょう。
これら全てはRAMのデータレイヤとしての強みを完全に有効活用できているとはいえないということを意味しています。これは今日まではほとんどのサーバが32GBや64GBと言った、非常に少ない量のメモリしか搭載していなかったので問題ではありませんでしたが、急速に変わりつつあります。数テラバイトのメモリを搭載するサーバは今日、もはや稀ではなく、また、この傾向は続いていきます。IMCを根本から再度、考えなおすべき時が来ているのです。アプリケーションがよりよいReadキャッシングができるようにする改善や、責任をエンドユーザーに負い被せることは答えではありません。将来、このシリーズの記事の中では高性能、高拡張性をもつインフラ全域に渡るIMCをご紹介していきます。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
