マイクロサービスとインメモリデータグリッドについて再考してみる

マイクロサービス、やっていますか? マイクロサービス、作っていますか? 世間のみなさんはすっかり使いこなしているのでしょうかね、マイクロサービス。

かなり今更かもしれないけれど、インメモリデータグリッドと呼ばれるソフトウェア製品に関して、私自身の理解の確認も含め、少し書いてみようと思います。

「インメモリデータグリッド」と聞いて、どのようなソフトウェアが思い浮かびますか?ちなみに、インメモリデータグリッドという言葉にはあまり馴染みがなくても、おそらく、NoSQLだとかKVSという言い方ならイメージがつく人も多いかと思います。

私の場合、こういった言葉に初めて触れたのは、それはもうかなり昔の話。多分、2007年くらいにOracleCoherenceという製品を知ったことが最初だったかと思う。それが今はもう2020年、世の中には、多くのインメモリデータグリッド製品が生み出されました。

適当にネットを検索すると、いろんなものが出てきます。念のため、現時点で人気のありそうなものを並べてみましょう。(並び順に特に意味はありません)

このくらいはあるようです。多分、他にもまだあるような気がしますが。 この分野は、いわゆるJavaEEのような標準仕様がカチッと定義されているわけでもないようで、様々な特徴を持つ製品がニョキニョキと出てきているようです。

 さて、これらのインメモリデータグリッド製品ですが、どのようなユースケースを想定しますか?ポピュラーなところをあげると、以下のようなケースを良く聞きます。

  • Webの高速化
  • 分散処理機能を応用した、バッチ処理の高速化
  • RDBMSの前段に配置することで、RDBMS自体の負荷軽減

こんな感じですね。

 そして、最近では、巷で良く耳にする「マイクロサービス」との組み合わせということも注目されています。どういうことでしょうか?

 JavaEEをはじめ、多くのフレームワークでは、アプリケーションのステート(セッション)を管理する仕組みが用意されております。JavaEEで例をあげると、HttpSession のような仕組みです。これはこれで非常に便利で良くできていますが、複数のアプリケーションからステートを共有しようと思うと、色々と工夫することを求められます。

 例えば、よく行われてきた方法として、ステート情報をデータベース(RDBMS)に保存するようにして、それを複数のアプリケーションから参照するという方法です。これは多くの場合でうまく機能しました。

 では、マイクロサービスの集合体として作られるアプリケーションの場合どうでしょうか。

 もちろん、マイクロサービスの粒度だとか、アプリケーションに求められる性能要件によりますが、一般的に、マイクロサービスとはその名前が表すようにマイクロ=小さく、多くのソレが適切な独立性を維持しつつも協調動作するという形となるため、共有ステートの保存先であるデータベースに求められる性能要件も高いものが要求されるようになってくるでしょう。

 一般的にデータベース(RDBMS)に高性能を求めようとすると、スケールアウトすることが難しかったり、ソレができるものは非常に高価だったりすることが多く、結局スケールアップ(=ハードウェアの能力を上げる)に頼ることになりますが、どちらの場合でも、コスト高になる傾向があります。

 そこで、インメモリデータグリッド製品の価値が見直されることになるはずです。従来は、上述したような、Web高速化を代表とする使われかたが一般的でしたが、マイクロサービスでシステムを構築しようとしたときに、マイクロサービス間でのステート管理のために、インメモリデータグリッドの特性が生きてきます。

 一時的なステート管理のために大掛かりなRDBMSまでは不要ですし、パフォーマンスのことも考えると、やはりメモリだけで対応できる方が望ましいです。インメモリデータグリッド製品の多くは、簡単にスケールアウトができるように設計されていますから、サイジングもそこまでシビアになる必要もありません。必要になったら、そのときに追加すれば済みますから。

 ただ、私が不勉強なだけかもしれませんが、おそらく、現時点では、インメモリデータグリッドでステート管理を行うための標準的なフレームワークJavaEEでいうところのServletやHttpSessionのようなもの)は無いような気がするので、ここは自作するなりの工夫が必要となるでしょう。

 いずれにしても、インメモリデータグリッドはまた脚光を浴びる存在な気がしています。