この記事は、"色んなデータストア触ってみる Advent Calendar 2019" の10日目の記事です。
https://qiita.com/advent-calendar/2019/datastores
Advent Calendarの主題である"触ってみる"という所からは、少しずれてしまうかもしれませんが、今回は、"触ってみる前に"読むと、とても良い、、というか、もっと早くこの本に出会いたかった、、！！ と思った「データ指向アプリケーションデザイン」について、
https://www.amazon.co.jp/dp/4873118700
私の経験や思いを絡めつつ、とめどなくあれこれと書いていきたいと思います。
データストレージと私
まずは、何でこんな事を書こうかと思ったかという所を、私の体験を踏まえて少々。
HBaseとの遭遇
３年ほど前に現職に転職するまで、永続的なストレージとしてはずっとRDBMSを利用したシステムに関わって来てたのですが、現職に転職するタイミングでHBaseの採用が決まっていました。それを聞いた時、私は反射的に「RDBのシャーディングじゃダメなのかな？」と思ったのでした。また、現職の話をすると、色んな人から聞かれるポイントでもありますし、そういう風に感じる人も多いのではないでしょうか？
そういう、ちょっとモヤモヤした思いを持ちながらも、もう決まったことだし、、ということでO'reillyのHBaseの馬が表紙のちょっと分厚い本を読み出したのですが、
http://shop.oreilly.com/product/0636920014348.do
その最初の方に、以下のような記述がありました。
問題は、(RDBMSの)リレーショナルな機能を、パフォーマンスのために犠牲にするのがよいことなのかどうかです。データモデルを非正規化して、不可避なロックを最小化することによって、ウェイトやデッドロックを避けることはできるでしょう。初めから組み込まれている、データが増大しても再パーティショニングを行う必要のない、水平型のスケーラビリティはどうなのでしょうか？ 最後に、スケーラビリティを実現するものと同じメカニズムを使った、フォールトトレランスとデータの可用性を得ようとすれば、そこに現れるのはNoSQLのソリューションです。
HBase: The Definitive Guide の 「1.3.2 スケーラビリティより抜粋
()内は私による文脈補足
この文章を読んで、これは確かに一理ありそうで、実は私は、新しいものをちゃんと知ろうともせずに、「パーティショニングでいいじゃん？」的なそれっぽい理由を添えて、未知のものを避けているだけなダメエンジニアになりつつあるのでは、、？ 仮に代替案を出すにあたっても、もっとちゃんと勉強しないとダメだな〜と感じたのが、一つの原体験としてあります。
（チームにMySQL強強な人が既にいる等、状況によってはRDBでのパーティショニングという選択肢が妥当な時もあると思いまし、何にでもNoSQLプロダクトがベターな訳では当然ないです。)
他の色んなデータストレージとの出会い
以後、HBaseを皮切りに、Kafka, AWSのDynamo DB, Elasticsearch などの様々な種類のデータストレージを本番で動かす / 動かすために検証する、という機会がありました。
直近は、Elasticsearchについてあれこれと学習する機会があったのですが、Key-Value storeなHBaseと、全文検索エンジンのElasticsearchという、全く違う使われ方をする２つのミドルウェアだけど、気がつくと脳内で、ElasticsearchのmergeはHBaseだとcompactionのことだな〜、とか、HBaseだとregion数はよろしく増えていってくれるのに対して、Elasticsearchだとpartition数を最初に固定しないといけないのは不便だな〜等々、全然違う用途のプロダクトなのに、結構似てて比較できるポイントも多いやん、、！ということに気づき始めたのでした。
そして、他のデータストレージでも、個別に比較すると色んなpros/consが存在していて、これまでは個別のデータストレージの仕組みをあれこれと学んでいたけど、これはもしかして、"(分散)データストレージ" として１つ抽象化のレイヤーを上げて理解することができれば、データストレージが持つ一般的なポイント毎に、各プロダクトの違いの理解を抑えればいいのでぐぐぐっと理解が早くなったり、大体良いことしか書かれていない公式ドキュメントや他プロダクトとの比較表なんかを見た時にも、その裏のトレードオフをさくっと見抜けるようになったりするんじゃないかな〜と思い始め、それを意識することで、段々と物の見方が変わって来たのです。
(注：この分野を専門的に勉強をしてきた人からすると当たり前すぎるポイントなのかもしれないけど、完全なるボトムアップで来た私にはこの発見は結構斬新だったのです💧)
昨今のデータストレージ事情
public cloudとかSaasとか
2019年の年末現在、public cloud / 関連Saasはガンガンに伸びて来ていて、その勢いはまだまだ続きそうですし、データストレージ関連のmanagedなserviceの種類も増加していく一方です(その中での廃り流行りはありますが)。
こういった環境を使えるシステムでは、既に相当に知見の溜まった強い運用チームを持っている場合を除いて、多くの場合はそういったmanaged serviceを使うことが合理的な状況になりつつあって、実際にデータストレージを運用している人ってのは段々と減って来てる(厳密にいうと、IaasやSaasとの役割分担が進んで、そのレイヤーの人が事業会社側からどんどん隠蔽されている)んじゃないかな〜と思います。
このため、細かな運用のノウハウ(バックアップどうするとか、failover/instance不調時の入れ替え作業の方法とか)は、知らなくても、大きな事故なく、色んなデータストレージを動かせるようになりました。
データストレージの選定とデータモデリング
この流れによって、データストレージに関して、何も知らなくてよくなったか、、？ というと、まだ、そこまでは来ていなくて、どのデータストレージを使って、どういうデータモデルにするか、という２点は今でも利用者側で決断をする必要があります。
（各public cloudのSolution Architectの人に聞いたら、多分それっぽい答えはもらえるけれども、最終的には「それは御社のサービスの想定されるトラフィックやワークロードの特性によります、、」的な、まあ、それはその通りなんだけど、我々が欲しいのは、ビシッとした答えなんだ、、！っていうパターンが時々発生）
スケールアップに限界のあるデータストレージ(主にRDBMS)を採用して、そこがボトルネックになり始めたら、ビジネス自体のボトルネック(相当にドキドキするやつ。。)になってしまうし、かといって、スケールアウトに強いデータストレージ(主にNoSQL系)はスケールアウトという特性と引き換えに、単純にRDBMSを使う場合と比べると色んな癖があって、その辺りの知見はRDBMSベースのシステムほどに一般的ではないし、eventual consistencyとかは人間の頭脳ではずっと意識することは難しくて、(マスタのみ)RDBMSを使っていれば遭遇しなかった厄介なバグに遭遇したりで、サービス規模がそんなに大きくない時は、単純にRDBMSを使うよりも逆にフットワークを重くしてしまうこともあると思います。
結局は「弊社のサービスのトラフィックとワークロードの特性による」、、ということになってはしまうんだけど、どんどん出てくる新しいモノも含めて、各データストレージの特性をちゃんと把握し、サービスの状況に合わせて適切なモノを選択出来るようになりつつ、かつ、変化に対応し続け、状況によっては移行計画も考える、、、的な所をエンジニアとして出来るようになっていかないとな〜というのが最近強く感じる所です。
データ指向アプリケーションデザイン
ここまでをまとめると、
- 色んなデータストレージを個別に学ぶのではなく、１つ抽象度を上げて効率的に学びつつ、新しく出てくるモノの特徴もしっかりと抑えれるようになりたい、という知識的な所での興味
- 様々な種類のデータストレージが出てくる中で、それを適切に選択し、データモデリングが出来ることは、まだまだエンジニアとしての重要なスキルになりそうという実利的な所での興味
という２点から、この辺りをしっかりと学べる方法ってないもんかな〜、、とモヤモヤしていたのですが、、
そんな時にに出会ったのが、「データ指向アプリケーションデザイン」で、この本ともっと早く出会いたかった〜と思う、私にとってはまさにドンピシャな１冊でした。
https://www.amazon.co.jp/dp/4873118700
少し長くなってきたので、今回はこれくらいにして、12/17に予定している、"その２"で、この本から具体的にどういう学びがあったのかを書いていきたいと思います。お楽しみに！！