#分散システム

SQLite に別の仕組みを重ねて、1台が落ちてもデータを失わないようにする。そんな発想から始まった rqlite が、12年たって「distributed SQLite」という一つの分野になった、と作者の Philip O’Toole は振り返っています。この記事が面白いのは、単なる自作ソフトの回顧ではなく、後から次々に似た製品が現れた流れを、最初から見ていた当事者が並べ直している点です。流行の起点を2021年ごろに置きがちな語り方に、2014年からの記録で待ったをかけています。 O’Toole が rqlite を最初に公開したのは2014年9月だった。考え方は単純で、SQLite の前に Raft のログを置き、書き込みを必ずクラスタへ複製する。そうすれば、1台のノードが壊れてもデータは消えない。ソースコードはその週末に GitHub に置いたという。彼はこれが、SQLite と Raft を組み合わせた最初のオープンソース実装だったと見ている。 rqlite は、彼自身が働いていたクラスタ型システムで「小さな関係データをどのノードに持たせるべきか」という実務上の悩みから生まれた

LLMの性能向上は、単にモデルを大きくするだけでは進みません。いまは、コードリポジトリを読み、ツールを呼び出し、コマンドを実行し、外部サービスとやり取りするような「agentic training」が重要になってきています。今回のarXiv論文は、その学習と評価を支える基盤を、かなり本気で作り込んだ話です。DeepSeekが公開した「DSec」は、そうした用途に向いた実運用のサンドボックス基盤で、単なる実験用の仕組みではなく、かなり大規模な現場を前提に設計されています。 論文が最初に言っているのは、LLMの大規模なagentic trainingやevaluationでは、モデルが安全な隔離環境の中でリポジトリを見たり、ツールを呼んだり、コマンドを実行したり、専用サービスと対話したりする必要がある、ということだ。問題は、こうした作業が毎回似た形にはならない点にある。あるときは軽いFnCallで足りるが、別のときはcontainerが必要で、さらに重い隔離が必要ならmicroVMやfull-VMが要る。しかも長い対話のあいだ状態を保たなければならず、画像データも巨大なコーパスから必要な分

Issue tracker は本来、GitHub や GitLab のようなサービスの中で使うものだと思われがちだ。だが git-bug は、その前提をひっくり返している。Git リポジトリそのものにバグ管理を埋め込み、オフラインでも使え、必要なら他の tracker ともつながる。しかも「プロジェクトを汚さない」「ベンダーロックインを避ける」といった、開発者が地味に気にする点を正面から押し出しているのが面白い。今回は、このリポジトリが何を目指しているのかを整理しつつ、その設計がどこまで現実的かを見ていく。 元記事は、`git-bug` というオープンソースのプロジェクトを紹介する GitHub リポジトリの README だ。説明はかなりはっきりしていて、`git-bug` は「Distributed, offline-first bug tracker integrated in git」、つまり Git に統合された分散型・オフライン優先の bug tracker だと名乗っている。 README では、この仕組みの特徴をいくつか並べている。まず、バグ情報は Git リポジトリに

これを読んでまず思ったのは、ようやくプロトコルとアプリケーションの責任分界が少しまともになりそうだ、ということだった。 セッションを前提にした設計って、実装する側からすると地味に面倒なんですよね。sticky session だの session store だのを抱え込むと、スケールさせたいだけなのにインフラが妙に重くなる。MCP がそこを削って、「プロトコルは stateless、でもアプリは必要なら stateful でいい」と寄せたのは、かなり筋がいいと思う。 特に引っかかったのは、これで楽になる部分と、逆に後ろに押し出される責任がはっきりしたところです。セッション維持のための仕組みは減るけれど、その代わり retry、idempotency、observability は別レイヤーでちゃんと考えろ、という話になる。ここはかなり現実的だなと思う一方で、便利な抽象化が一つ消えたぶん、雑に作ると事故りやすくもなる。たとえば side effect を持つ tool call は、失敗時に二重実行されても困らないようにしておかないといけない。クラウド側が軽くなったから終わり、ではない

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

Cloudflareがまた、大規模インフラでは「小さな無駄」がどれほど高くつくかを示す話を出してきた。今回はPingoraを使う社内の負荷分散サービスで、あるアルゴリズムのメモリ使用量を見直し、全世界で100TBを超えるRAMを取り戻したという。派手な新機能の話ではないが、こういう改善こそクラウド事業者の現場では効く。しかも今回は、Rustと少しの数学が主役だ。 元記事が扱っているのは、Cloudflareの内部負荷分散サービス「Pingora Backend Router」、略してPBRだ。PBRは、キャッシュ可能なリクエストをどのサーバーに送るかを決める役割を持っていて、その判断には consistent hashing を使っている。consistent hashing は、サーバーの増減があっても割り当てが大きく崩れにくい方法で、分散システムではよく使われる。Cloudflareではこの仕組みを open-source の `pingora-ketama` ライブラリで実装していた。 話の発端は、Cloudflare内部のIvanが出したチケットだった。内容は「Pingora

分散システムは、ネットワーク越しに複数のコンピュータが協調して動く世界の話だ。ところが、この領域は「作るのが難しい」だけでなく、「何が本質的な難しさなのか」をつかむのも難しい。今回の元記事は、そうした分散システム研究を理解するための入口として、古典的で影響力の大きい論文を選んで並べた短いリストだ。新しい技術を追う記事ではないが、むしろ今読まれる意味がある。分散システムの流行は変わっても、土台にある問題はあまり変わらないからだ。 元記事「Distributed Systems Classics」は、Nicolae Vartolomei がまとめた選書で、分散システム分野を形作った「時代を超える」「影響力の大きい」論文を集めている。目的は、研究の問題空間をよりよく理解するための良い出発点にすることだと説明している。つまり、これは網羅的な文献一覧ではなく、最初に何を読むべきかを絞ったガイドに近い。 並んでいる論文は、分散システムの基本的な悩みを順番にたどれる構成になっている。最初に置かれているのは Leslie Lamport の 1978 年の「Time, clocks, and the

PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。 Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。 PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード