そこには近年のIoTというキーワードの広まりとシステム構築ニーズの高まりに合わせて、IoTに適した特性を持つNoSQLに再び注目が集まり始めているという背景もあります。また、NoSQLはもはや新しい技術ではなく、こなれてきた技術に移行しつつあり、これに伴って各NoSQLソフトウェアそのものの技術論ではなく、実際にどのようにビジネスの現場で活用するのかということに関心も移りつつあります。
そこで本連載では、これまでにすでにたくさんの方が優れた研究をされてきた（技術仕様からの）NoSQLソフトウェア同士の比較を目的とはせず、今まさに仕事現場で活用するために「エンタープライズ」という視点からNoSQLを捉え、主なシステム想定をIoTとし、特に具体的な機能をベースに論じる必要がある場合にはCassandraを用いる、という点を特徴としていきます。
ビジネスにおける価値の理解を優先し、あえて個別の細かい事情については突っ込みません。扱う範囲としては一般論から始まり、システム提案側にいる方ならプレゼン資料作成に、情シスの方なら上司の説得に役立つ情報、さらにNoSQLの設計方針から運用・サポートの考え方、ベストプラクティスまでを予定しています。
対象読者
- NoSQLやCassandraを使ったシステムを顧客に提案する立場の方
- NoSQLやCassandraの特徴を生かしたシステム設計をお考えの方
- 上司にNoSQLを使って何か新しいことができるかの調査を命じられた方
NoSQLの変遷
クラウドの登場と機を同じくしてその名が語られ始めた「NoSQL」については、一度は調べたことがある方も多いのではないでしょうか。にもかかわらず、ほどなくして一時期の盛り上がりが去り、再び現場への活用という現在の状況になるまでには恵まれない時代も経験しています。これをハイプサイクルにおける「過度な期待」を過ぎたからだと言ってしまえばそのとおりなのですが、では何を機にいったん「幻滅期」に入ったのかを、より具体的に整理してみることで、今後のNoSQLやCassandraのビジネス展開において、何が要点となってくるのかをまずは探ってみたいと思います。
NoSQLの誕生
NoSQLと言えばご存知のとおり今では「Not + Only + SQL」の頭文字を取ったものを指していますが、元々NoSQLという言葉が出てきた頃は、文字そのままの「No + SQL」でした。つまり、SQLの否定形です。そしてここで言う「SQL」とはリレーショナルデータベース（以下RDB）のことを指しています。従来、ほぼすべてのシステムにRDBが使われていると言っても過言ではありませんでした。それはRDBが明確なデータ構造を定義し、SQL言語による優れた検索性能を持ち、強力なトランザクション機能を備えていたからです。ところがその反面、特にスケールアップ型であること、マスタスレーブ構造のため書き込み負荷が集中しやすく、耐障害性も上げにくいことなどの課題が、近年の高度情報化社会の副産物として徐々に表面化するようになってきました（ここは次回詳しく見ていきます）。
そこでRDB一本槍の状況に対するアンチテーゼとして「NoSQL」が登場します。ここでNoSQLとは分散KVS（あるいは分散ハッシュテーブル）を指しており、RDBの抱える課題を解決できるいくつかの特徴を持っています。それはスケールアウト型であること、書き込み負荷の分散が可能で、容易に耐障害性も高めることができるという点です。GoogleのBigTable（とGFS）の話題が世に出始めたのを契機として、マスタレスな分散KVSに注目が集まり、対応するソフトウェアやサービスが現れた頃からこのNoSQLが流行り始めたという経緯があります。
エンタープライズ活用する上で抱えていた3つの弱点
そして登場後は一挙に注目を集めることになったNoSQLですが、残念ながらほどなくしてブームは去ってしまいます。それはNoSQLもいくつかの欠点を抱えていたためです。人によって何に着目するかは違うと思いますが、エンタープライズという視点からすると以下の3つが挙げられます。
①トランザクション機能を持たなかったこと
背景に透けて見えるのは「CAP定理」の壁です。
②既存資産を生かせなかったこと
SQL言語はあらゆるビジネスアプリケーションに使われていました。
③代替手段が登場したこと
ハードウェアも進化を続けています。
それぞれをもう少し詳しく見てみましょう。
トランザクション機能がないことによる扱いにくさ
まずトランザクション機能について。NoSQLでこれを語る時に避けては通れないとても重要かつ本質的な話として「CAP定理」という頻出キーワードがあります。まずCAPとは「一貫性（Consistency）」「可用性（Availability）」「分断耐性（Partition-tolerance）」の頭文字を取ったものであり、CAP定理とは、例えばRDBにおけるマスタスレーブ構成のように複数のサーバから構成されるシステムにおいて「一貫性、可用性、分断耐性の3つを同時に満たすことはできない」というものです。
技術的な詳細については、すでに多くの情報が出ていますのでそちらに譲るとして、今回押さえておきたい点は、一般的に分散KVSは高いスケーラビリティと耐障害性を実現するために、CAPの中のAとP、つまり可用性と分断耐性に重きを置き、その帰結として一貫性を犠牲にしているという点です。この観点からすると、普段私達が使用しているRDBは分断耐性を犠牲にすることで一貫性と可用性を選択している訳ですが、この一貫性を選択しているおかげで、少なくともエンタープライズアプリケーションではなくてはならない非常に重要な機能であるトランザクション機能（コミットやロールバック）が使用でき、例えば商品の在庫管理やチケットの座席割り当てなどのビジネス上重要なデータを初めて正確に処理できるようになります。そうなると、当然この一貫性を犠牲にしている分散KVSではトランザクション機能がないということになり、これでは厳密性が求められるエンタープライズ・アプリケーションでは扱いにくいよね、という論調が強くなっていきました。当時はNoSQL不要論も出たくらいですが、「いやいや、すべてをNoSQLでする必要はない。NoSQLとRDBそれぞれの特徴を生かす形のハイブリッドスタイルでいい」というやや中庸的な意見に次第に落ち着きました。これが「Not + Only + SQL」の始まりです。
この辺りを意識している方は「No + SQL」をNoSQL、「Not + Only + SQL」をNOSQLと書き分けていることもあります。頭の片隅に置いておいていただくと何かの話の役に立つことがあるかもしれません。
既存資産を活用できないことによる追加コスト
次に既存資産を生かせなかったこと。当時NoSQLでは基本的にSQL言語が使えませんでした（またはJOINが使えないなどの制限が多く付いていました）。長らくSQLはデータベースアクセスに使うデファクトスタンダードであったため、BIツールや社内で蓄積してきたアプリケーションなど、ビジネスに重要な膨大な資産は当然大半がSQLを使う前提で作られており、そのままではNoSQLを活用できないという問題に直面してしまいます。NoSQLには興味を持っているにもかかわらずです（なんという機会損失でしょう！）。当然企業においてこれらのアプリケーションをNoSQLに対応させるなどという追加コストの話が素直に認められるはずもなく、次第にNoSQLへの過熱感が冷めていくきっかけの一つになったと考えています。NoSQLにアクセスするための新しい言語（昔のCassandraではThriftというものでした）を学習するためのコストも馬鹿にならなかったことも見逃せません。
代替手段による魅力の半減
上記2つほどの重要度はありませんが、最後は代替手段の登場。NoSQLはRDBの処理性能限界に対する答え、という面があったのですが、ちょうど当時はRDBのSQL構文のパース部分のチューニングによる高速化（中にはSQL自体を使わずにストレージエンジンに直接アクセスする話もありました）や、従来のハードディスクに替えてSSDやioDriveを使用した高速化の話題も活発で、NoSQLの魅力が相対的に半減してしまったことも遠因であったと考えています。さらに、この頃にはアプリケーションのメイン部分は従来通りRDBで構築し、NoSQLは補助的なキャッシュサーバとして使うやり方か、その耐久性を生かした形でストレージサービスの裏側として使うというのが典型例になっていましたが、既存ですでに高速なインメモリのキャッシュサーバがあるなど、少なくともビジネスにおいてNoSQL自体が強い存在価値を持つ機会はなかなかありませんでした。
