00:13
よろしくお願いします。
はい、アサヒさん、よろしくお願いします。
今日はですね、前回お話ししたDDIA本の、実際に読んでみた回をやります。
なんと、自分もですね、本を早速買わせていただきまして、今回第1章、第2章を読んでみて、その内容について議論していくという感じですね。
僕が布教して買わさせた感じですよね。
確かに、宗教勧誘に、もしかしたらはめられているのかもしれないですけど。
結構、こういう風に本を読んで、実際に議論するっていうのは、大学生のゼミぶりなんで、すごい懐かしい気持ちになって、ちょっと緊張しますね。
公開読書会みたいな。
そうですね、公開読書会。ちなみに、臨読会は、けっこう、ケンさん、やられていましたか?
やってました、やってました。すごいやってました。
技術本だけじゃない。
いいけど、あ、学生の頃は技術本じゃないの、けっこう。なんか、朝みんなで集まって、あの、庭でやったりとか。
まあ、学生時代だけじゃなくて、社会人になってからも、技術本を同僚と読んだりとかしましたね。
その、前、前言ったかは分かんないけど、このD.D.I.A.本を教えてもらったのも、クックパッドの時に、他の人が開いてた臨読会の案内があって。
あ、言ってました、言ってました。はい。
そうそうそう、それで出会ったっていう感じですね。
なるほど。
いやー、いいですよね。やっぱそういう、今ちょっと実際に、僕初めてやるんですけど、やっぱり、ただ読むだけなのと、このアウトプットをするぞって思ってるのは、全然やっぱ違うなって、当たり前なんですけど。
意見を言うにも、やっぱり、自分の、なんか他に参照して、その証拠とかがないと、意見も言えないので、まあ、他のものをちょっと見てみたりみたいなのをする方が、すごいいいなっていうのは思いましたね。はい。
いやー、そうですよね。
はい。
僕も本が好きだからこそ、臨読会しなきゃいけないなと思ってて、やっぱり、本ばっか読んでると頭でっかちになってしまうんですよね。なんか自分が本で仕入れた知識が、なんか良さそうみたいな感じになっちゃうんだけど、なんか全然そんなことなくて、ちゃんとこう、クリティカルシンキングを保ってとか、他の人のね、意見を入れないと、まあ、本を読んで分かってきになっちゃうから。だから結構こういうの、いいなと思ってやってますね。
いやー、本当に、いい機会をありがとうございます。
じゃあ、公開、読書会やってきます。
はい。
読書会、早速やっていきましょうか。
うん。
はい。
で、じゃあ、そうですね。まずは、今回は第1章と、第2章ということで、第1章が、Reliable, Scalable, and Maintainable Applicationsっていうタイトルでして、一般的にデータベースを運用とかするときに、注意しなきゃいけないところ、運用とか設計ですね、3つの主な項目、Reliable、Reliability、Scalability、Maintainability、この3つについて、
03:09
まあ、語られているという、まあ、項目になります。
で、2つ目も一応紹介しておくと、2つ目は、Data Models and Queer Languagesってことで、まあ、データ、実際にどのデータモデルがあるか、まあ、SQLとか、あとは、Document Database、Graph Database、この3つがまあ、主に語られているんですけれども、まあ、その違いであるとか、どういうときにこれを使えばいいか、みたいな、えー、ところが、えー、主に述べられていますね。
はい。
そうですね。だから、まあ、第1章は本当にイントロって感じで、データベースを選択するとき、技術選定するときには、まあ、信頼性とスケール性と保守性を考えましょうね、みたいなところが軽く触れられているっていう感じですよね。
はい。軽くですね。で、まあ、第2章は結構具体例があるので、この2つを一緒に取り上げていくのが結構いいかなという感じがしました。
はい。
はい。
じゃあ、そうですね。
まず、データベースですけれども、まあ、データベースを、そうですね、この設計とかした経験って、けんさんはありますか?これを選ぼうとか、このデータベース使おうみたいな。
よく知ってましたね。
ああ、はい。
クックパッドのときは広告のサブシステムみたいなのを作ることが多かったので、僕が入ったときには、その偉大な先人が作った広告配信システムのコアはあったんですけど、
はい。
まあ、例えばそのサブシステムとして、ちょっとしたこう、まあ、ログシステム作ってみようとか、リアルタイムシステムを作ろうみたいなときに、まあ、ゼロから設計することもあったし、まあ、もともと動いてた、そのシステムのパフォーマンスのボトルネックを突破するために、データベースを、まあ、変えてみようかみたいな話のときに、まあ、議論したりだとか、ここで結構鍛えられたっていうのは1つありますね。
ああ、いいですね。楽しそう。
うん。すごい楽しかった。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
そうだね。
で、その後グラフデータベースの会社にも入ってるから。
はい。
うん。
確かに。
幅広い。
で、なんかその本でも触れられてましたけども、この要件にあったデータベースは、どの要件にもデータベースは存在しないみたいな話はあったと思ってて、それぞれの要件に合わせたデータベースを実際に選んでいくみたいな必要があるということですよね。
06:09
そうなんですよね。
やっぱり、なんかこれだみたいなやつはやっぱりないんですかね、計算的にも。
うん。
なんかこう、一つのデータベースだけを覚えれば、
すべてのシステムを作れたっていう時代はもうそんな時代ではない気がしていて。
はい。
多分その、まあ多分一番歴史が長いのがRDBMSじゃないですかね。
で、まあデファクトとしてはMySQLとかPosgreとかがあって、で、そのこのRDBMSでの正規化の、なんだろうね、ベストプラクティスとかもそうだし、クエリ言語としてもSQLってかなりいい意味で枯れてるじゃないですか。
SQL。
そうですね、はい。
っていうことなんで、それで大体。
システムは作れてきたけど、まあでも、なんだろう、こう、サービスがどんどん複雑になりにつれて、RDBMSだけでは突破できないパフォーマンスのボトルネックとか、
あとはこう、複雑なジョインではこう、数秒結果がかかるので、まあ、そもそもMySQLでは対応できないみたいな要件が出てきて、
そこで、ね、ノンシークエル、ドキュメント型が出てきたりとか、
はい。
アパチカフカみたいなストリームが出てきたりとか、まあグラフデータベースが。
出てきたりとかっていうことになったんで、本当に、なんだろ、いろんな武器を覚えて、使ってくっていう感じだと思います。
まあ、特にクラウドが来てからだよね、マネージドサービスで簡単にデータベース使えるようになったじゃないですか。
昔ってこう、例えばMySQLを動かすのにも、そのオペレーションの知識も必要だった。
自分たちでVMにこう、クラスター組んで、で、そこのツールも作りながら、オープンソースに貢献しながらみたいな感じだったけど、まあ今はボタンポチポチすればね、Amazonとかね、GCPとかでね、ポッて作れちゃうから。
ほぼオペレーションのコストがいらないので、より、なんか、レゴブロックというか、ピタゴラスイッチみたいな感じで、データパイプランを作りやすくなってきた、まあいい時代といえばいい時代なのかなとは思いますかね。
確かに。昔であれば、まあDBAっていう専門の方がいて、いないとデータベースの構築ができなかったっていうところで、まあクラウドがあるからこそ、よりこういうSREとか、まあアプリケーションエンジニアもデータベースの設計により関わっていけるみたいなところはあるのかもしれませんね。
うん、そうですよね。
はい。なんかその実際にじゃあ、チャプター1では、スケーラビリティ、リライアビリティ、メンテナビリティっていう3つの項目ありましたけれども、なんかその実際にじゃあ設計をする際に、どう選定していくかみたいなところで、一番重要なところというか、これは絶対に外せないみたいな部分って研鑽的にはあったりしますか。
あー、いい質問ですね。
そうですね。なんかこう、いろいろ設計してきて、まずすごい思ってるのは、リライアビリティとスケーラビリティって頑張りすぎなくていいかなと思ってます。
09:08
はい。
システムに求められる要件ってあるじゃないですか。
例えば、このカード決済システムを作るルールだったら、リライアビリティはこれぐらいにして、でもスケーラビリティこれぐらいでみたいなときに、
それ、
そこで、
そこの最低ラインさえ超えてれば、必要以上に頑張らなくていいかなと思ってるんですよね。
例えば、そのリライアビリティとか一つとっても、エラーレートをじゃあ、3-9で担保するのか、99.9%でやるのか、それとも99.8%で担保するのか、全然こう、難しさが違ってくるんですよね。
はい。
なので、なんかこう、
例えば、要件的にじゃあ99.9%でいいよって言うんだったら、まあそこさえ、
担保すればよくて、本当に一番重要なのは、まあここの3つであえて述べるなら、メンテナビリティじゃないかなと個人的に思ってます。
っていうのも、やっぱりこう、重要なのは、後から変更できること、まあ後からそのデータベースを撤退できること、まあマイグレーション、他のデータベースに切り替えられることなので、
ロックインされしすぎてしまったりすれば、まあリライアビリティとかスケーラビリティって後から頑張ればどうにかできるけど、
メンテナビリティが壊れてしまうと、まあ、
壊れちゃうと、例えば移行するのにも、その周辺のね、ツールを移行したり実装したりするのにすごい時間かかってしまって、
本来であれば半年で終わるプロジェクトも3年になりましたみたいな感じになってしまうから、
割とメンテナビリティは重要視した方がいいかなというのが個人的な意見ですかね。
確かに一番その後から変えづらいというか、このメンテナビリティができてないと、
まあとりあえずメンテナビリティ自体が変更するしやすさとかが含まれているので、
あとあと大変なリライアンスみたいなところはありそうですね。
ちゃんとできてないと。
そうかな。
はい。
実際にじゃあこの中身というかメンテナビリティって具体的にどういうものなのかみたいなのを見ていきますと、
一つがその運用性ですかね、オペラビリティというか、
えーと、まあいかに簡単に運用できるかというと、
パイプラインとかを実際に構築して、自動化、構成の自動化をするとかそういったところになりますかね。
あとはまあ単純さであるかどうか、単純さで、えっとこれはまあなるべく複雑にしないようにする。
なるべくシンプルにしていくことが重要っていうので、その中でシンプルにしていくためにはまあ抽象化をしっかりしていくことが大事だよみたいな話もありました。
はい。
シンプルな設計ってめちゃくちゃ難しいですよね。
いやーそうですね、本当に難しいと思いますね。
12:02
あと抽象化をするっていうところもどう抽象化していくかっていう、なんか抽象化するキーの選び方みたいなのも難しいと思うんで。
データベースにどこまで任せてアプリケーションレイヤーの席もどこまで落とせるかみたいなのが一つ。
はい。
アプリケーションレイヤーをシンプルにできる判断だよね。
はい。
だから割と最近のデータベース側の発展って高機能になってきて、まあどれも似たような感じになってきて。
うん。
で、なんか最低限求められるリライアビリティとかスケーラビリティでは、まあどこのデータベースも水平にもちろんスケールできるし、垂直にスケールさせるときもダウンタイムなるべく少ないようなツールとかも開発されてるのは、まあ合格ラインというか最低ラインで。
うん。
その上で、例えばこうユーザーエクスペリエンスというか、まあデベロッパーエクスペリエンス、例えばなんだろうね、メトリックスがすごい簡単に取れて、しかも簡単にパフォーマンスチューニングできますとか、なんかより高機能なものが作っていかないと差別化できないっていう感じなのかなっていうのは、割とデータベース作る会社の中に入って思ってたことかな。
ああ、確かにそのデータベースの状態とかは簡単に知れたら嬉しい。
嬉しいですし、まあなんか異常が大きい、典型的な異常とかは、まあ簡単に検知できたら嬉しいなっていうのは確かにありますね、そういうのが。
うん。
プロがいるとは限らないし、そこを採用するのってすごい時間もコストもかかるので、なるべくこう、なんだろう、モンゴDBならではの知識が事業を回すのに必要にならない状態にしたいと。
そうすると、例えばモンゴDBとかデータベースをクラウドとかSaaSで提供する側としては、本当にそのオペレーションのところと、
あとはその、それを使うという意味ですが、いかにシンプルにできるかという意味で、どんどんどんどんこのデベロッパーエクスペリエンスのところを高めていかざるを得ない。
まあそうしないとお客が取れない。
はい。
って言って、Neo4jとかもグラフデータベースを作ってて、まあぶっちゃけグラフデータベース単体インスタンスのパフォーマンスっていう意味で言うとどこも一緒なんですよね。
うん。
なんか、まあ、なんだろう、そこら辺の業界って、業界というか技術とかって、まあ研究、リサーチされ続けてるものでは、
あるものの、だいたい実装の難易度とか考えたときのベストプラクティスってどこも一緒なんですよ。
だからまあそれを、まあ僕らはNeo4jはJavaで実装して、他の競合はC++で、まあ実装してみたいな。
15:05
まあでも、アルゴリズムとしては一緒で、みたいな感じで、単体インスタンスとしてスケールできるところはだいたい一緒。
じゃあどこで差別化するかっていうと、例えばNeo4jの場合はアナリティクスとかグラフを操作できるような、
まあ、
かなりリッチなWebUIとか、MacのOSアプリケーションとか、まあツールを使ってたりとかして、
まあそこの周辺で競合と差別化していくっていう戦略を取っていたので。
いやー、じゃあそれこそスタートアップとか、まあ初めてグラフデータベースを使う企業でも、
結構簡単にセットアップしやすいような、なんか整ってるって感じですかね、UIとかもあって。
すごいシンプルに使えた。
なんかそのドラッグ&ドロップで、
まあ、ゴリゴリなんだろうね、まあグラフデータベースっていうのは、こう、
あの、えっと、エッジとノードっていう、まあエッジっていうのがまあ、ノードという点と点をつなぐ線ですね。
を、で、表現できる、まあグラフとして表現できるデータを保存するためのデータベースですけど、
まあそれをこういう、ユーザーインターフェースでゴリゴリこう、ドラッグ&ドロップで、なんだろうね、付け加えたりとか、新しいノード入れたりとかできちゃうから。
あの、初期のそのプロットフォーム、
プロットタイピングとかにも、もってこいのツールでしたし、
まあかといって、その、まあグラフに適したデータモデルであれば、かなり垂直に、あの、スケールするっていうのも分かってるので。
うん。
いやー、そこ使ってみたいですね、そう、あと。
そう。だから、かなりフロントエンジニアとか、プロダクト作るっていう人たちを、まあ積極的に採用してたね、僕がいた頃は。
ああ、そうなんですね、なるほど。
あの、
ちょっと脱線すると、なんか、
あの、Neo4jのこともちょっと書いてあって、この本に、第2章で、グラフデータベースの話ですね。
で、その中で、えっと、Cypherっていうクエリとかを使ってやるんですよね。
それが、結構思ったよりシンプルで、グラフデータベース、僕、触ったことなかったんで、あの、結構難解なのかなと思ったんですけども、クエリ自体は、そんなに厄介じゃないのかなっていう感じがして、使ってみたいなと思いました。
うん。
そうですね。
あと、この、Cypherとか、Neo4jっていうのが、マトリックスから来てるっていうのが本に書いてあって、ちょっと、そう、知らなかった。
そう、あの、マトリックスのね、Neo、なんかこう、作った創業者は結構、そういうの好きなんですよ、サイファイとかさ。
面白いですね。
うん。
新しい社内のプロジェクトとかも、あの、なんだっけ、その、映画から来てるとかね。
はい。
ちょうど僕がいたときに、マトリックスなんだっけ、レボリューション4、なんか新しいのが出たんですよね。
はい。
はいはい。
出てましたね、最近。
うん。
そう。
会社のエクスペンスで見に行くみたいなイベントとかも発生して。
えー、そうなんですか。
そう。
会社のカルチャー作ってるから大事だよ。
18:00
確かに。
そのまま名前ついても、そう、結構珍しいですよね。
面白い。
そうそうそう。
ね。
逆に言うと、マトリックスの映画も続編どんどん頑張ってもらわないと、なんか、ジンクスっぽいですよね。
確かに。
Neo4jも。
うん。
そうですね。
新しいサービスの名がなくなっちゃう。
そう。
ですね。
えー。
で、Cypherの話が出たので、このDDIA本のチャプター1をちょっと逆に批判的に読んでみると、メンテナビリティとリライアビリティとスケーラビリティと3つ挙げてたけど、じゃあ他にトピック、他の項目もないのかなってちょっと考えてみたときに、他に大事なのって、やっぱりそのデータベースを使うアプリケーションディベロッパーがデータモデルをどう使えるか、で、どうデータベースとやり取りをするかっていうところで、
まあ、これはチャプター1の話が出たので、
チャプター2に出てくるところなんだけど、まあ、クエリ言語ってめちゃくちゃ大事だと思うんですよね。
なんかこう、かなりこう、ローレベルでデータベースとやり取りしなきゃいけないってなったら、クライアントの実装も大変だし、そこを、なんだろうね、インピーダンスミスマッチって話も出てきた、キーワードもチャプター2出てきたと思うんですけど、
例えば、アプリケーションデベロッパーが達成したい、なんかシステムの要件があると。
それを、
データベースのAPI、データモデル、まあ、SQLとか、正規化とかなんでもいいですけど、データベースで表現するときに、そこでこう、抽象化させなきゃいけないじゃないですか。
はい。
そこでかなりこう、なんだろうね、現場のこう、メンタルモデルとデータベースで表現しなきゃいけないものが全く違っていると、かなりこう、実装も大変だし、ソフトウェアバグも発生しやすいので、
なるべくこう、メンタルモデル、
のまま表現できると嬉しいんですよね。
例えば、そのNeo4jのCypherが、まあ、グラフデータベースが、そこを売りにしてたのは、
例えば、その、エンジニアが設計するとき、まず何するかっていうと、
だいたいホワイトボードの前に集まって、
なんかホワイトボードの上で、こう、なので、ここにこう、じゃあユーザーデータが、モデルがあって、
まあ、ユーザーが、じゃあ、はずめにいて、なんかこれ持っていて、みたいな、
こう、ホワイトボードを、
こう、コーディングというか、ホワイトボードでモデリングすると思うんですけど、
グラフってのは、そのまま、ホワイトボードで書いたデータモデルを、そのままNeo4jのCypherを使って、
まあ、スキーマ定義できるよっていうところで、
なんだ、なんて言い方してたかな、
まあ、インピーダンス密マッチがなかなかないですよっていうのが一つ、
グラフデータベースというか、Neo4jの売りでもありましたね。
正規化しなきゃいけないじゃないですか。
あの、RDBMSの場合。
はい。
で、テーブルに、と、あとその、関連性に、こう、一回、考え方を、マインドセット、というか、メンタルモデルを変えなきゃいけない。
21:02
だけど、まあ、それが、Neo4jの場合はないよ、みたいな話はしてたね。
まあ、それも、
その、アプリケーションの、なんですかね、オブジェクトのまま表現できる、みたいなところがあるってことですかね。
そうそうそうそうそう。
Neo4jの、内部構造としては、もちろん、
その、ディスクに保存するときに、まあ、特定の、なんだろうね、バイナリーのエンコーディングの隙間があって、みたいな感じなんだけど、
使う、データベースを、インサートするっていうところまで、アプリケーションデベロッパーの観点で言うと、
正規化のこととか考えなくていいんで、
うん。
開発速度上がるよね、っていう。
なるほど。
じゃあ、その、DB、データベースの型設計みたいな、
うん。
とか、テーブル設計みたいなところに、あんまり時間を、使わずとも、開発を進められる、みたいな、
そう、そう。
ことがあるんですかね。
そう。
ですね。
うん。
まあ、それも、逆に批判的に言うなら、まあ、とはいえ、やっぱり、システムが、
育っていくと、やっぱり、ちゃんと、隙間設計しといた方が、将来の変更、
可能性に対して、こう、レジリエントだよね、みたいな話も、もちろんあるし、
はい。
あとは、言うて、RDBMSの正規化って、もう、だいぶ、やり尽くされてるから、
うん。
できる人多いし、ベストプラクティスもあるから、そこ、そんな困んないよね、みたいな話も、あったり、しますね。
うん。
なるほど。まあ、RDBのベストプラクティスみたいなの、出回ってるんで、難しい、その、線引きみたいなの、まあ、このまま行くのか、まあ、ノーSQLでも言えることだと思うんですけれども、
うん。
実際に、まあ、ノーSQLの場合も、結構、そのまま、オブジェクトを表現しやすいっていう、まあ、話が、第2章でありまして、
うん。
まあ、そのまま、ストア、そのまま、えっと、JSONの形、
うん。
ような形で、え、データを保持できるからこそ、まあ、使い勝手がいい一方で、まあ、型とか、まあ、データ型みたいなのが付いてなかったりとか、もしくは、その、他のテーブルとのジョイングが難しかったりみたいな、まあ、そういう課題はあるっていう話なんで、まあ、その辺、どう折り合いをつけていくか、まあ、っていう、先を見越しながら作らなきゃいけないのかなっていうのは、
うん。
思いましたね。
そうですよね。
はい。
うん。
だから、
うん。
はい。
だから、そうやって考えると、一つの、例えば、Neo4jみたいなデータベースにめちゃくちゃ詳しいっていう、それはそれで価値はあると思うんだけど、
はい。
なんだろう、そこに情熱を見いだせないっていうか、逆に、なんだ、もうちょっと事業に技術を手段として貢献したいみたいなタイプのエンジニアであれば、いろんなデータベースについて詳しくなっておくっていう方が、確実に社会に対して価値を出せるんだろうなっていうのを、
うん。
思ったっていうのが、一つ。
なるほど。
まあ、この技術を深めたいというわけでなければ、幅広く知っておいた方がいいよと、
24:01
そうそうそう。
いうところですね。
そう。
まあ、確かに。
だから、まああれですよね。宮本武蔵になるか、弁慶になるかみたいな。
ちょっと、それ、例えが、僕分かんないですね。
笑。
笑。
こう、剣豪、剣豪になるか、
はい。
弁慶の七つ道具って知りません?
あー。
はい。
弁慶って、いろんな武器を持ってたんですよ。
うんうん。
そう。
あの、牛は、
そう。
牛若丸を助けた弁慶ですけど、
剣、剣をひたすら磨いて、宮本武蔵みたいな、こう、歴史に名を残す剣豪になるか、
弁慶みたいに、いろんな武器を持って、
うんうん。
こう、牛若丸を助けていくかと。
はいはい。
どっちもかっこいいですけどね。
なるほど。
はい。
すいません、脱線しました。
いや、ちょっと、この話をまたやりたいですね。
そういう、この、その、武器をどう使っていくかみたいな話ですね。
はい。
はい。
この、チャプター1だっけ、2だっけ、
なんか、
具体例として、ツイッターの話が出てきましたよね。アーキテクチャーの。
あ、はい。出てきましたね。
うん。
その、ツイッターみたいなシステムを作るんだったら、君どうします?みたいな話が出てきましたよね。
ありましたね。これは、面白かったです。
まあ、主に、ですかね、その、ツイッターのホームページのフィードをどうやって表示するか、
まあ、フォローしてるユーザーのフィードをどう表示するかみたいなところの、アーキテクチャーの説明でしたね。
そうそうそう。
はい。
これで、まあ、最初のやり方が、単純にフォローしてるユーザーのデータを取っていくにしたっけ、一個ずつ。
うん。
それを、まとめて読み込むときに取っていくみたいなやり方と、もう一つが、ツイートされたときに逆にそれをフォロワーの球に溜め込んでいくみたいなやり方の、まあ、2種類があって、
5個目で始めたけど、それだと全然スケールしないので、2つ目に移行したみたいな話がありましたね。
確かに。
そうですね。
なんかそのツイート画面を訪れた時のそのビューをどのタイミングでレンダリングするかっていう話で、
うん。
数から
どんなツイートしたかっていうのを
持ってくるのにかなりのジョインが
発生するんですよね
ジョインってRDBMS的には
基本的に遅い操作なので
それを
そこのボトルネックを外すときに
非同期で
作っとけみたいのがまず第一段階
あったけど
それはそれでまた
次のボトルネックに当たって
確か有名人とか
有名人とか
何百万人の
フォロワーがいるみたいなときだと
それはそれでそうそう
ボトルネックに当たるから
そのときは条件分けするみたいな話でしたよね
27:00
有名人の場合は
何百万人のフォロワーがいるような場合は
元の方法を
使うみたいなやつでしたっけ確か
結局
どっちも取るっていうね
現場でよくあるの
綺麗なアーキテクチャで全て解決するわけじゃなくて
落とし所を探っていくという形になりましたよね
バランスが大事というか
それぞれ解決策を
考えた上で
その境界点を作って
対応したという感じですかね
規模が大きいほど
いろんな問題に
これ以外のいろんな問題にぶち当たりそうですね
自分たちが最初に
設計したシステムが
いろんなボトルネックに当たっていくと思うんですよ
サービスが成長してくれれば
成長しないで終わっちゃうときもあるけど
当たったときに
ちゃんとボトルネックを
理解して
そこを解決するために
どういう新しい設計にしなきゃいけないのか
どういうデータフローにしなきゃいけないのか
っていうのが一つエンジニアとしては
楽しいところかなと思ってます
そういうときにも
メンテナビリティとか
しっかり考えられていれば
変更しやすい状態になっているかもしれないし
っていうところで
メンテナビリティが重要
っていうのがありそうですね
うまくつながったね
チャプター2と
つながりましたね
このツイッターの例とか
アーキテクチャインタビューで聞かれるトピックでもあるかな
実際僕も転職活動してたときに
ツイッターみたいなのを作ったら
どういうシステム設計にするとか
あとはブックマーク
どうやって表現するとか
どんなデータベース使うみたいな話を
実際によくあって
最初は
データモデルで普通に
こういう風に正規化してやろうかな
でもそれだと
書き込みのワークロードが
ボトルネックになるよね
じゃあここだけ
ダイナモDBに外出ししようかな
そしたら今度
こっちのリードがボトルネックになるよね
じゃあそこは非同期にイベントシステム
使おうかなみたいな
ちょっとずつパッチを
当てていきながら
アーキテクチャを進化させていくみたいな
割とこの
外資のアーキテクチャインタビューでも
求められるというか
実際現場で求められるからね
知識が
そういう話でもあるかな
自分の場合はこれまで
会計システムと
暗号通貨の取引所なんで
RDBしか使ったことなくて
それ以外にも多少はあるんですけども
やっぱり
そういうのも知っておいた方が
他の会社定職したい場合とかも
特に生きるし
もしくは派生的なシステムとかを
作るときに
ちゃんと提案ができると思うので
30:00
やっぱりいろんなデータベースを
知っておくっていうのは
どんな会社でも強みになるなという風に
思いました
結構大手の金融とかで
アパチカフカ使ってる話とかよく聞きますよね
RDBMSももちろん
使うけど
確かにカフカはそうですよね
ストリームとしてはね
枯れてるから
SREとして求められる技術は何かっていうところ
言ってみますか
そうですね
せっかくSREとしてDDIMを読んでるんで
このDDIMで読んだところを
自分たちの業務に落とし込むなら
っていう話で
じゃあデータベースについて
読んでますと
じゃあそれってSREとして求められる技術とは何か
みたいに絡めたときに具体的にどういうこと?
なるのかなっていうのが一つ
面白いディスカッションポイントかなと思うんですけど
それぞれの特性を知っておくっていうのは
第一ですよね
あの
まあ
NoSQLとRDBの違いとか
分からないと提案もできないし
この時はこれを使おう
まあこれは多分データベースに関わらず
どのシステムでも一緒というか
Kubernetesと普通のコンテナを使うかみたいな話ですね
まあ
それ
そう
データベースいろんな種類があって
それぞれ
まあ大まかにどれがどう違うかみたいなところは
知っていた方がいいかなっていうのは
思ったんで
まあこの本をもっと読み進めていきたいなって思いますね
そうですよね
だからSREというプラクティスをこう実行していくにあたって
例えばアプリケーション側で障害が起こって
それは実は今のデータフローの設計から来る
なんだろう
ボトルネックでしたってなった時に
はい
SRE側から
まあなんだろう
例えばこう
スロークエリを直すとか
インデックスあるみたいな
そういう簡単な話だったらいいんですけど
はいはい
そもそも今のアーキテクチャとかデータモデルにしてるから限界があるよね
でもそれって実は
まあここのRDBMSでやってるところを外出しして
別のデータシステムを使うと
まあうまく使えるよっていう提案ができてるんですけど
データベースシステムを増やすと複雑性が一般的に増えるけど
今はクラウド化が進んでるし
この会社のこのサービスを使うと
オペレーションのコストもメンテナビリティもそこまで上げずに使えるよ
みたいなことが提案できたり
はい
あとは君たちのSLOはこれぐらいだけど
ここの部分はこうやって底出しにすることによって
逆に信頼性が上がるよねとか
そういったふうに交渉材料として
武器を持っておく
でそのメリデメを理解してるっていうのがあると
かなりこうアプリケーションデベロッパーとも
リレーションビルディングができるというか
それもでもまたいきなりやるっていうのが難しい
33:04
知識があっただけだとわからないことも多いじゃないですか
それをケンさんは結構その
そうですね
最初にやったときとかってどうやって
この提案みたいのをしていったっていうか
なんですかね
やったことないところとかも
領域も出てくると思うんですけど
そういうときにちょっと話が変わってきますけど
まあどう対応して
どう交渉するかみたいな
そうですね
はい交渉というか
どう折り合いをつけていくか
自分がわからないところも含めてみたいな
うん
そうですね
なんかもちろん僕一人で世の中全てのデータベースシステムを
知ってるわけじゃなくて
なんかこう
ここってこういう限界があるんじゃないみたいな指摘すると
まあ幸いにも他のなんだろう
他のデータベースシステムに詳しい人が出てきて
ツッコミくれたりするから
まあなんだろうね
まあでも
あくまでSREだっていうポジションは崩さないようにしていて
はい
はい
はい
,
それはどういうことかっていうと
例えばその
どのカラムにインデックスを張ろうかとか
Nプラス1をどうやって特定しようかとか
もちろん会社によるとは思うんですけど
あんまりそこまでいくと
それはアプリケーションデベロッパーの仕事だと思ってるんですね
はい
だから僕らがSREが
一つ一つのクエリをチューニングし始めると
それはスケールしないと思ってるんですよ
うん
一つ一つのカラムを見て
インデックス張ったりしたらスケールしないと思ってるので
あくまでSREとしては
プラクティスを進めるというところに集中するのであれば
どうやったらNプラス1を回避できますか
どうやったらスロークエリを分かりますかっていうツールとか
そのやり方を提供するにとどめて
具体的なものはアプリケーションデベロッパーに任す
そうすると僕らには
もっと全体像を
見晴らしの良いところから
データフロー全体を見れるようになる時間があるので
その時間を使って
例えば新しくFacebookから出してきた
オープンソースのデータベースについて調べつつ
それが導入できないかなって見てみたりとか
例えば自分が好きな
Apache Kafkaとか
Neo4jだったらメジャーのバージョンアップデートは
定期的にウォッチして
新しく出てきた機能が使えないかなとか
っていうのを
定期的にやっていく感じですかね
だからあんまり
折りすぎない
その側に折りすぎないというのを意識してる
あんまり領域を
領域侵犯しないというか
自分がやるべきところに集中していくっていうのは
大事そうですね
そうだからそういう
質問の答えに
36:00
振り返ると
どういう風に
入れていくかということに関して
アプリケーションにやってほしいこと
っていうのを明確にして
移情するというか
デリゲーションするというか
でまぁあとは
あれらの視点に立って話すことですよね
例えばリダイビリティもめっちゃ上がるし
スキャラビリティもめっちゃ上がるんだよ
って言っても
そのためにアプリケーション側の
普段の開発速度が
下がったりとか
例えばクエリ言語が
なんか枯れてなくてすごい
開発速度が下がっちゃったりとか
彼らにとってデメリットがあったら
嫌じゃないですか
アプリケーション側からしても
例えばオンコールの回数が減るよね
とか
こうやってNプラス1クエリが
どんどん減っていくよね
とかっていう感じで
彼らの目線で提案していくためにも
なんだろうね
アプリケーションを使うという観点でも
オペレーションをするという観点で
双方向からデータベースを理解するように
っていうのが必要なんだろうなって
まぁそういうことをやれると
全然時間なくなってくるんですけどね
いやぁ確かに
取捨選択が難しいですね
教会はきつつも
彼らの視点を理解しなきゃいけない
っていうところは
そうそう
あると思うので
その辺は
経験を積みながら
いい感じの勘どころを
鍛え上げていくという
感じになるんですかね
まぁ一人でSREやってるわけじゃないから
そこはあんまり困ったことは
困ったことはあるんだけど
なんか他の頼れる人に
頼ったりしてるかな
はい
いいですね
じゃあSREとして求められる
技術は何かということで
1個目が
複数のデータベースの
メリデメを理解してることでしたね
はい
はい
で次が
リライアビリティとか
スケーラビリティを
上げるための設計の
提案ができること
そうっすね
チャプター1と絡めてるけど
じゃあリライアビリティを
上げるために何ができるか
何をする必要があるかって
モニタリングの設計と
導入ができることでしょうね
多分SREとしては
はい
リライアビリティの
プラクティスって何?
ってなった時に
まず見える化できないと
意味がないので
例えば
MySQLだったら
MySQLにどういう
モニタリングツールがあって
それをどういう
プロセスを入れると
スクレープできるようになって
それがどういう
例えばグラファナで
見えるようにするのか
別のツールで
見れるようにするのか
それが最終的に
アプリケーションデベロッパーの
普段の業務に
どう絡めるのかっていう
どこまでの
エンドツーエンドの
導入ができる
っていうのは
SREに求められると思いますね
個人的には
はい
とは
やっぱり自分が思うのは
あの
アップデートとか
アップデートって結構
データベースは
難しいことが多いと思ってて
まあ
データを維持しながら
バージョン上げる時に
まあ
メンテナンスウィンドウとかが
設けられてれば
いいんですけども
ダウンタイムとかを
39:00
許可できない
ような
場合に
あの
そうですね
結構
まあ当然その
分散化されていれば
できることかもしれないですけど
えっと
その辺の
いかに一つずつ
アップグレードしていくか
みたいな
設計もできてる必要が
あるのかな
という風に思うんで
まあリライビリティとしては
その
アップグレードとか
まあ変更
データ移行とかの
しやすさみたいな
ところも
重要になってくるかな
という風に思います
そうですよね
うん
まあスケーラビリティに関しては
まあ例えば
ロードテスト
負荷テストってのの
計画と実行ができることとか
はい
あとは実際にこう
そこでボトルネックに
当たった時に
そのデータベースでは
どういうツールを
使うと
垂直または水平に
スケールできるのか
っていうのを
理解すること
それが
設定できること
かな
確かに
そういうテスト環境的なものが
ちゃんと
あって
そういうテストを
しっかり
できるような
状態を
準備しておくっていうのも
大事です
っていう感じですかね
うん
そうだよね
はいはい
でまああとは
メンテナビリティですよね
今アサイさんも
ちょっと
触れてたけど
ああそうか
ここでさっき言ってた
すいません
そうですね
まあそれ多分
どっちの観点でも
あると思うんだけど
例えばじゃあ
ダウンタイムなしに
リライビリティを
担保しつつ
はい
アップグレードする
ってなった時には
リライビリティを
理解するという観点も
もちろんそうだし
そういったツールを
実装したり
あと使ったり
調査したり
移行作業自体が
できるってことも
もちろん
必要となってくるかな
そうですね
うん
まあ難しいのは
それぞれを
じゃあ
SREとして
どこまでやっていくか
っていうのは
まあ本当に
会社ごとによるかな
と思ってて
会社によっては
SREの別に
データベース
リライビリティエンジニア
みたいな
DREっていう職種が
あったりとか
なかったりとかするから
そういった別のチームとの
兼ね合いとかも
あると思うし
そうですね
まあ結構
深掘りすれば
それほど
深くなるんで
うん
大きい会社ほど
分けてそうですね
ね
うん
逆にでも
データベースエンジニア
というか
データベース専門で
やっていきたかったら
比較的
まあ大きい会社
大きい会社に
行かないと
その専門職種みたいな
なかなか
見つけにくい
かなっていうところも
ありそうですね
そうですね
特定のデータベースとか
例えばRDMSについて
詳しくなるとかだったら
はい
うん
そんな印象かな
大きいとこ行かない
だ方が
チャンスはある気がする
はい
ということで
まあデータベース
領域で
そうですね
42:01
高みを目指していく
なんかこう
ぜひちょっと
チャプター1とチャプター2を読んだ
浅井さんに聞いてみたいものとしては
せっかく本を読んだんで
本を読んで
読んだ後の
なんか自分のアクションに何か
変わるものがあったかどうか
ああ
まあまだ全部読んでないから
ここの質問は早いかもしれないけど
もし現時点で
なんかヒントがあったら
なんか日々の業務とか
日々の勉強計画とかに
こういうの参考にしようかな
みたいな何か
果実が
もし
あれば
聞いてみたいですけど
そうですね
まあ
直接すぐにっていうものは
そんなにないんですけども
個人的に
いやすごい
読んでてよかったなあ
と思うのは
本当にそれぞれのデータベースの違いが
知れたっていうところと
あの
自分は
あの最初に
触った言語が
SQL
だったんですけども
サポートエンジニアとして
結構データをチェックしたり
みたいな
の分析とか
みたいなのをSQLでやってて
その時はそんなに
SQLのことが
好きじゃなかったっていうか
もっと
アプリケーションのコードを書きたいな
みたいなことを
思ってた
いたんですけれども
実際にこの本読んで
SQLがすごい
あの抽象化がうまくできていて
それこそ
どのデータベースでも
基本的な構文が動くみたいな
仕組みが
あるじゃないですか
まあ
それがやっぱりすごいなって
今改めて思いまして
当時のことを思えば
そんなにコードを書けない
自分であっても
触れる言語として
SQLっていうのが
あって
えー
ま
っていう
データエンジニアとか
であっても
使えるみたいな
そういう設計ができてる
SQLってすごいなっていうふうに
僕は改めて思いまして
結構そういう
意味で
そういったSQLみたいな
抽象化をしていけたら
いいなっていう風に
個人的に思いました
クエリ言語の
素晴らしさを知ったと
はい
そうですね
いいじゃないですか
本読んで
過去の
自分の経験とか
知識を
改めて言語化できるようになる
っていうのも
一つ本を読む
理由ですしね
そうですね
はい
けんさんは
改めて
喋ってみて
何か新しい発見は
ありましたか
ね
改めてこうやって
読んでみると
新しい発見が
確かに僕も
前回読んだのが
4、5年前で
その後ちょいちょい
チャプターごととか
セクションごとに
見直してみたけど
こうやって
改めて読んでみるのは
久しぶりなので
そうですね
でも読んだときは
僕グラフデータベースのこと
全くよく分かってなくて
読んだから
なるほど
当時は
Cypherって聞いても
何それ
おいしいのって
感じだったけど
今なら
分かる
というか
うん
今なら
グラフデータベースが
どういうとこ
こうやって
グラフデータベースが
どういうとこに
45:00
マッチして
はい
どういうとこに
マッチしないか
っていうのが
すごいよく分かるのと
あと当時は
どっちかというと
まだソフトウェア
デベロッパーの
視点だったんですよね
SREじゃなくて
うん
だからリレーアビリティ
スケーラビリティ
メンテナビリティ
と言われても
よくちょっと
分かんないくて
SQLを使って
とか
正規化とか
そこら辺で
やってた時期なので
そういう意味で言うと
SREになってから
確かに
データベースを
引用するっていうのは
こういった観点が
必要だなっていうのを
見直す機会に
なってますね
うん
自分見直して
新たな発見が
SREとしての
発見があったっていう
感じですかね
そうだね
うん
いいですね
いやー
ちょっと読めて
よかったです
まあまだまだ
チャプターに
読んだ
確かに
いっぱいあります
全然思ってなかった
はい
やっぱりその
引用とかも
すごい多いので
この辺
もうちょい
作る文献とかも
読んで
深掘りしてみたいな
とかも
思いますし
その先の
チャプターも
読み進めていきたいんで
いやそこは
時間がないですね
うん
もっと
うん
読んでいきたい
っていう感じです
次回もやる?
公開
次回も
やりますか
いいじゃん
チャプター3,4くらいで
はい
いいね
公開読書会
もしかしたら
一緒に読んでくれる
リスナーの方が
いるかもしれない
あー
はい
そういう
物好きな方がいたら
一緒にやりましょう
そうですね
ゲストとして
まだこの
こういうのを
聞いて
やってくれる方
出てきてないですよね
正直
あっ
ありました
ありました
ありましたっけ
このトピックじゃないんだけど
うん
これはじゃあ
ちょっと後で
共有します
はい
了解です
じゃあぜひ
お声掛けください
はい
今日は
こんなところかな
はい
こんなところですかね
ありがとうございました
はい
お疲れさま
お疲れさまです
