ばたばたと走り回りましたが、何とか無事終了、おうちに帰るまでがサミットです。
今年は生成AI、LM周りがやたら分厚く、BedrockとAmazon Q推しがすごかったですね。いや、画期的なのはわかってるんですがｗ
もともとニューラルネットは大学のときからやっていることなので、あの（当時はマシンパワーの問題などで）クソみたいなことしかできなかったニューラルネットがこんな躍進するなんて思いもしませんでした。当時の先生方はきっと涙を流して喜んでいるんだろうなぁ。
直方体とか三角錐とかをカメラでとらえて、画像認識して、指示された模型をアームがつかむ、とかの研究やってました。要するにニューラルネット出始めの頃。あのままやってたら今頃生成AIの分野にどっぷりつかっていたかもしれません。
とはいえ、ニューラルネットはそれそのものがクソみたいに難しい話なので、現行のニューラルネットのシナプスノードの数を見ると吐き気がします。よく今の研究者の人、あれやれるよね、感心します。それでもまだまだ脳みそには程遠いのですが。
なんせこの分野、コンピューターだけじゃなくて脳内のニューロンシナプスネットワークの脳神経科学とかをちゃんとやらないと話にもならんので、基本的にデジタル世界だけじゃないんですよ。
攻殻機動隊の世界はいつ来るんでしょうね。
さて、そんなド外道みたいなニューラルネットワークの世界は正直手に負えないので、専門家に押し付けるとして、今年レガシーシステムにへばりついて生きているインフラ屋が感動したのは、Aurora Unlimitedです。思わずXで呟いちゃうくらいにビビった。
Auroraストレージシステムの名前がようやく（Re: Inventで）出てきて、Unlimitedもわずかばかり見えてきたところで、せっかくなのでDeep Diveへ。
さて。DBシステム。データベース。
これ、まあ、普通にWeb屋さんやってる人たちから見ればせいぜいがMulti AZなMySQLですわー。とかでだいたいが済んでしまうので、DeepDiveにもし参加していても途中から「なに言ってんだこいつ」ってなっていたかもしれません。というかそういう人は聞きに来ないかｗ
DBのDeep Dive、ちょっと人少なかった気がしますしｗ
それでも、今回の内容は濃かったです。Serverless v2のメカニズムとかはだいたい予想できた範疇でとどまっているんですよ。まあ、秒単位でLive Migrationするとかあたま大丈夫？とか言いたいところはあるものの、従来のクラスタ概念の延長線上にあるので理解は難しくないし、やってることがちょっとバカみたいな規模とスケールでやってるだけで。
が、ヤバいと思ったのはUnlimitedです。
まず、直感的にはわかりにくいかもしれませんが、DBというシステムはストレージに格納されたデータ量の増加に対してリニアに性能が低下するシステムです。これは皆さんわかっていることです。端的に言えばレコード数増えたら遅くなる。というアレです。
とはいえ、Web屋さんとかが主に取り扱ってるレベルのレコード数じゃそんなことは（あまり）おきません。
じゃあどんなことすると起きるか、という話ですが、エンドユーザーの行動を記録する、とかやりだすといきなりデータが爆発します。が、昨今の生成AIのために良質なデータを（教師として）得たい、と思ったらこれが必須です。
さて、その時に起きる爆発的なデータ増加を「どのように」「どこに」格納するのか、という話として出てくるのがAurora Unlimitedとかの話。まあS3にストアすれば足りるならそれでもいいです。Redshiftも同様にUnlimitedが出てくるようですが、これらはいわゆるデータレイクとかデータウェアハウスの話。
この膨大な量（基本的にペタバイト～エクサバイトクラス）になってくると、そもそもが単体DBサーバで処理するというのはどだい無理な話になります。当たり前だｗ かといって、リードレプリカ増やせば、とかそういう話でもないです。データが爆発的に増える、ということは当たり前ですが増やす書き込みが増えるんです。シングルマスタじゃもうお話しにならない。
ストレージ量がその分あれば足りる、とかそういう問題じゃないんですね。そもそも分散クラスタリングしないと話にならない。だから、今まではこれを「データベース」にはやらせていないんです。データレイクに落として、ETLなんか回して、バックエンドジョブでちまちま処理して、AIに回したいならベクトルにして、みたいな。
で、むりやりこれをデータベースでやる方法の一つがシャーディングですね。分割格納。小さい範囲だとテーブルシャーディング。データベースインスタンス単位のシャーディングとなるともうこれはアプリの設計依存でして、アプリがそのようにふるまえ、という前提が立ちます。結果として、アプリがACIDを守るかどうか、というアプリ側にクソめんどくさい話が発生するんですね。それはとりもなおさず、アプリにトランザクション管理を実装しろ、という話でもあります。アプリ側がトランザクション守らなきゃいけないなら。
Unlimitedはこのインスタンス単位のシャーディング実装を、オフロードしている。それ自体はまあできなくはないかな、とは思うんですよ、独自設計していいなら。ただ、これをAuroraが、という話になってくるとPostgreSQLやMySQLのコンパチビリティを守らないといけない。あ、めんどくさそ！とはおもってたので聞きに行ったわけです。
肝はやはりトランザクションで、トランザクションを誰が、どう管理するか。Auroraのストレージノード分離もなかなかインパクトがあってああ、その手があったな！って思わされたんですが、その比じゃない。
一貫性のある管理を維持しようとすると、どうしてもマスターという概念が生まれてしまいます。協調動作でなんとかしようとすれば、この協調動作がオーバーヘッドになってしまい、速度が落ちる。これをどう解決するんだ、という話になるんです。どうしたってこのシステムはマルチマスタノード構成なので、絶対に集約ノードが発生したらイケナイ。
加えてAurora Unlimitedのベース基盤はAurora Serverlessです。データ実態は常にストレージにあり、コンピュートノードはしょっちゅう移動したり落ちたり増えたり減ったりします。実装しなさいって言われたらたぶん私なら手近な何かをぶん投げて相手がよろめいてるすきに「ばーかばーか死ね！」って言いながら逃げます。
なのですごく興味がありました。
結論がすごかった。
・協調動作をしたらまともに成り立たないんだから、しない（おいこらちょっと待て
・トランザクションをマイクロ秒単位でNTPとジッタを考慮に入れたタイムスタンプ協調でそれぞれのノードが独自判断して破綻させない（は？
ちょっと何言ってるかわからない。マイクロ秒はCPUからすればすごい長い時間だけど、それでもネットワークからしたら一瞬以下です。あくまでメモリ速度領域であって、ネットワーク速度領域はミリ秒です。
マイクロ秒での動作管理…だと…。聞いてて吐きそうでした。
シャーディング自体は結構一般的なものなので、MySQLにもPostgreSQLにもPluginやExtensionがあります。ただ、ああ、これはMySQLにはできない、と思い知らされる。ざっくり言ってしまえば、おそらく、pgpoolをさらにクソ拡張したみたいな、超魔改造されたルーティングノードがトランザクション管理（に見せかけたタイムスタンプ管理）をしている。で、裏のコンピュートノードでシャーディングのExtension走らせてて、ここも魔改造されてる。pgpool相当のフロントも、原子時計と密にやるための専用魔改造。この辺のフロントエンドにあたるところはないわけじゃないけど弱い、というのが個人的にはMySQLに抱いている印象。
これでゴーストリードとシャドウリードを再現してる。なんだこれ、なんだこれ。
やりたいことはわかる。やってることもわかる。わかるんだけど、なんでそんな発想が出来るんだよ頭おかしい。それをマイクロ秒レイヤでやってるのか、どういう頭してんだおかしいおかしい（誉め言葉）。
いや、これはMySQLじゃ（少なくとも現状見えてるプラグインの魔改造程度じゃ）無理だ。pgpool IIってそれなりに優秀なフロントエンドでして、MySQLにこれ相当がないのが私的には制約になりまくるので好きじゃないんですが、世の中MySQLだらけなんで、ほんと嫌い。
大きなシステムを組む、という話のときにMySQL引っ張り出せないのは、MySQLの限界が以外と低いからです。わりとWeb屋さん領域ですら下手すればぶち当てられるかもしれません。ある一定のラインで、パワーをいくら与えても「もう僕無理」ってなるんですね。そこから先がない。というかOracleがOracle使えって言いに来る。
とはいえ、今回のUnlimitedはOracleもなんかちょっと霞むかな。OracleもDB2もアプリケーションユニットであって、「システム」としてのストレージノードの存在や、Auroraのもつコンピュートノード、という概念をフル活用してる。コンピュートノードの前にルーティングノード噛ませて、あたかもインスタンスノードがいないみたいな振る舞いに見せこむわけだ、これ。そしてそのルーティングノードもコンピュートノード同様ストレージに何もまともに持ち込んでない。
さて、トランザクション問題が解決しても、データは肥大化し続けます。この時生まれるのがシャーディングのスプリット問題。データが少ないときに作ったシャーディングを分割し、新しくもっと細かい粒度のシャーディングに分かれていかなければ、Unlimitedなんて名乗れません。まあ、これ自体はテーブルシャーディングでもやるんですが、まあ（本来は）Alterの出番です。悪名高き、何もかもロックしてシステムを止めることで有名ですね。
シャーディングスプリットって当たり前ですが本来システム止めないと出来ねぇんですよ。が、そこは分散ストレージシステムです。ストレージをバックエンドでコピーし続ければいい。だってルーティングノードもコンピュートノードもデータ持ってない。Alterに相当する行動は、「データベースが」ストレージをロックするんです。「ストレージが」データベースをロックしているわけじゃない。
そして、そのロックの理由はすべてトランザクションに集約されている。そのトランザクションが「各ノードが」「自律的に」「タイムスタンプベースで」「破綻しないように」「コミットまで」独立行動しているんだから、協調停止も要らない。最初から協調なんかしていないからだ。各ノードは自分のシャードの中身へのリファレンスしか持ってない。ルータノードはシャーディング領域のリファレンスしか持ち合わせていない。
協調しないでトランザクションコミットしてそれで破綻しないシャーディングって、聞いてるだけで異常すぎて吐き気が沸き起こる。しかし聞けば聞くほど、確かに破綻しないのがわかる。
そりゃあ粒度情報しか持ち合わせてねぇならちいさいテーブルでしかない。
バックエンドのストレージコピーが終わったら一瞬トランザクション止めて参照情報だけ書き換えればいい。止めるのだってスプリットするコンピュートノードとルーティングノードの参照テーブルだけだ。
いや言いたいことはわかる。わかるよ？ でもこれを実装するのか。生成AIだらけの中で、DBチームがめちゃめちゃ誇らしげに気炎上げてたのがめちゃめちゃ印象深かったけど、これは気炎上げるわ…。めちゃめちゃ自慢したくもなるわ…。
聞いてるだけで、どれほどの苦労があっただろうかと思いを馳せつつも、とんでもなさ過ぎてPostgreSQLに回帰したくなってきた。もうWeb屋さんにMySQL Compatibleでいいじゃんとかいうのやめよっかなー…。
あまりに感動しすぎて、思わずその辺の誰かとっつ構えて「今のすごくね！？」とか叫びそうになったわ、畜生。
