- 既存のクラウド抽象化は、CPU・メモリ・ディスクを望む形で組み合わせて使いにくくし、VM と PaaS のどちらも一般的なコンピュータより多くの制約を生んでいる
- リモートブロックストレージと高い egress コストは、HDD 時代の前提に縛られた構造を維持したまま、SSD と現代のネットワーク環境において性能とコストの問題をさらに大きくしている
- Kubernetesは扱いづらいクラウド API を覆い隠してくれるが、誤った基本抽象化そのものは変えられず、VM・ディスク・ネットワークの限界をそのまま抱え込んでいる
- agentsによってソフトウェアと実行需要が増えるほど、私的な実行空間、簡単な共有、低い運用オーバーヘッドがより重要になり、既存クラウドの構造的ボトルネックもあわせて大きくなる
- exe.devは、まず CPU とメモリを確保し、その上で VM を直接実行できるようにし、TLS proxy・認証 proxy・ローカル NVMe・非同期レプリケーション・anycast ベースの配置を組み合わせて、実際に使いたいクラウドに近づこうとしている
なぜ新しいクラウドをもう一度作るのか
- 既存の クラウド抽象化がコンピュータを望む形で使いにくくしており、それが新しい会社を始めた直接の理由になった
- コンピュータ自体は素晴らしいが、今日のクラウドではほぼあらゆる製品で制約が繰り返されており、問題の核心も単なる UX や API 設計ミスというより 基本構成単位の形に近い
- VM は CPU とメモリに結びついた個別インスタンスとして提供されるが、望ましい形は CPU・メモリ・ディスク資源を先に確保し、その上に必要な数だけ VM を載せる構造に近い
- Linux VM は他の Linux の cgroup 内で動くプロセスであるにもかかわらず、現在のクラウドではこれを簡単に扱いにくい
- これを回避するには gVisor やネストされた仮想化を単一のクラウド VM 上に載せる必要があり、性能低下に加えて少なくとも reverse proxy の運用まで自分で背負うことになる
- PaaS もこの問題を解決できず、むしろ一般的なコンピュータより弱い ベンダーロックイン型の抽象化を強いる
- コンピュートプロバイダごとに新しい開発方式を学ばなければならない
- プロジェクトをある程度進めてから、一般的なコンピュータでは簡単な作業がプラットフォームの深い制約のためほとんど不可能だと判明することもある
- 何度も「今度こそできる」と思っても、中途半端に実装された抽象化に阻まれることが繰り返される
ディスクとネットワークに表れる構造的限界
- ディスクでは、クラウド事業者は リモートブロックストレージや、それ以上に制約が強く遅い S3 のような方式を好むが、これは HDD 時代にはある程度合理的だった
- リモートストレージは順次読み書きでは大きな不利がなく、HDD のランダムシークが 10ms 級だったため、イーサネット接続の 1ms RTT は受け入れられるコストだった
- プロバイダ側としては、標準インスタンスタイプから 1 軸を取り除けるため運用が容易になる
- しかし SSD への移行でこの前提は崩れた
- シーク時間は 10ms から 20 マイクロ秒へと短縮された
- リモートブロックシステムのネットワーク RTT は改善したものの、IOPS オーバーヘッドは HDD 時代の 10% 程度から SSD 時代には 10 倍以上に拡大した
- EC2 で 200k IOPS 構成を実現するには設定も複雑で、月 1 万ドルが必要だが、MacBook は 500k IOPS を提供する
- ネットワーク技術そのものは十分に優れているが、egress コストと事業構造が使いやすさを妨げる方向に働いている
- hyperscaler のネットワークは優秀だが、コストが非常に高く、他ベンダーとの相互接続も不便にしている
- クラウド事業者の egress 単価は、一般的なデータセンターにサーバーをラック搭載する場合より GB あたり 10 倍水準で提示される
- 使用量がある程度増えると、この倍率はさらに悪化する
- 月数千万ドルを使う顧客はより良い価格を得られるが、月数十ドルや数百ドル規模のプロジェクトには適していない
- この帯域では何を作っても 安価に運用しにくいように阻まれる
Kubernetes と API は問題を覆い隠すが解決はしない
- クラウド API は扱うのが苦痛で、Kubernetesはその上を覆ってエンジニアが受ける苦痛を減らす方向で登場した
- しかし VM はクラウドがネストされた仮想化を直接押しつける構造であり、Kubernetes の上でも依然として扱いにくい
- ディスクについても、Kubernetes 設計当時の Google 側には実用的なリモートブロックデバイスが事実上なく、今日の共通パターンにようやく合わせても、結局は遅いストレージに縛られやすい
- ネットワークも、簡単に開放すれば近隣のオープンなデータセンターの一部システムを private link で接続して クラウドコストの桁を 1 つ減らせるようになるため、簡単に作る動機が乏しい
- Kubernetes を単なる見せかけの仕事と片づけるのではなく、移植可能で usable なクラウドを作ろうとする不可能な問題に立ち向かった産物と見る
- 根本的に誤ったクラウド抽象化の上に新しい抽象化を載せるやり方では解決できず、Kubernetes を良くする取り組みにも結局は明確な限界がある
- こうした不便なクラウドと付き合ってきた時間は 15 年に達し、その間は不快なソフトウェアスタックの別部分のように我慢し、必要最小限だけ触れるやり方で耐えてきた
今こそ直すべき時点
- 今が転換点である理由は agents の登場だ
- Jevons paradox のように、コードを書くことが容易になるほどソフトウェア全体の量はさらに増え、仕事でも趣味でも各人がより多くのプログラムを使うようになる
- そのように増えるプログラムを動かすには、私的な実行空間、簡単な共有、小さな運用オーバーヘッドが必要になる
- ソフトウェア総量が増えるほど、以前は煩わしい程度だったクラウドの問題がはるかに大きなボトルネックへと膨らむ
- より多くのコンピュートが必要で、管理もしやすくならなければならない
- agents は AWS API を代わりに操作する助けにはなるが、認証情報を預ける必要があり、ときには本番 DB を削除してしまうこともあり得る
- 何より agents も既存クラウド抽象化の根本的限界では人間と同じ壁に突き当たる
- 必要以上に多くのトークンを使うことになり、結果も期待より悪くなる
- agent の context window が古典的なクラウドに無理やり適合させることに使われるほど、実際の問題解決に使える余地は減る
exe.dev が先に直し始めた部分
- exe.dev がまずリリースしたのは、VM の資源分離問題に対する解決策だ
- 個別 VM をプロビジョニングする代わりに、まず CPU とメモリを受け取り、その上で望む VM を自分で実行する構造を提供する
- 新しい VM をそのままインターネットに露出させたくないという前提の下で、TLS proxy と認証 proxy をあわせて処理する
- ディスクはローカル NVMe を使い、ブロックはマシン外へ非同期レプリケーションする
- 世界各地の複数リージョンにマシンを置けるようにし、近い場所で実行されるようにする
- マシンは anycast ネットワークの背後に配置され、世界中のユーザーに低遅延の入口を提供する
- この基盤の上で、まもなく新機能もさらに作れるよう設計している
- まだ作るべきものは多く残っている
- 静的 IP のような比較的明確な項目が残っている
- 自動生成される過去のディスクスナップショットにアクセスする UX のような課題も残っている
- 同時に、データセンターに直接コンピュータをラック搭載する段階へ戻り、ネットワーク接続方式まで含めた ソフトウェアスタックの全レイヤーを見直している
- 最終目標は、実際に使いたいクラウドを作ることにある
6件のコメント
今さらなぜ？と思ったけど..
作者がTailscaleの共同創業者だと知って、なんとなく応援したくなった。
うまく作ってください！
価格表があまりにも分かりにくくて、2コア8GB、VM 50台みたいな書き方になっているので。VMを1台もらって、コンテナを50個動かせると理解すればよさそうです。
クラウドが複雑なのには、それなりの理由があります
退会機能が見当たらないのですが、見つけた方はいますか？
ドラッグ＆ドロップだけでサービス同士を接続できるといいですね
Hacker Newsのコメント
Kubernetes は、最初はWebアプリのコンテナを数個動かすにはちょうどよさそうに見えても、すぐに SDN を載せて各種サービスがぶら下がり、手が付けられないほど肥大化しがち
クラスターを「最適化」し「ハードニング」するほど、クラウドコスト、障害、ダウンタイム、デバッグの手間まで全部2〜3倍に膨れ上がった
結局そうしたDevOps的な慣性を捨ててクラスターをなくし、Debian単一VM にファイアウォールを有効にしてKamalでDockerをデプロイしたところ、インフラの安定性と信頼性が最も高くなり、コストも大きく下がった
大半のビジネスアプリは数百〜数千ユーザー規模なので、大きめのVM1台で十分なことが多く、Googleのようなクラウドがハードウェア障害を処理してくれるから、必要なときだけ2台目のVMを立ててCloudflareでIPを切り替えればよい
あまりに小規模な環境にまでk8sを持ち込むことは珍しくなく、そういうケースではそもそもk8sが必要なスケールではない気がする
そのため、よくあるデプロイパターンを単純化する上位レイヤーが必要で、Knative はその一例
基盤のprimitiveをすべて露出させようとする解決策は、結局Kubernetesと同じくらい複雑にならざるを得ない
私が作った https://github.com/openrundev/openrun は、チーム向け内部Webアプリのデプロイを宣言的に扱い、SAML/OAuthとRBACも備え、Dockerの単一マシンとKubernetesの両方をサポートしている
過剰に複雑でデバッグしにくく、金もかかる考え方はVM上でもそのまま再現されうる
ただ、今は単一のDebian VMが彼らのポリシー監視レーダーの外にあるので自由なだけかもしれない
誰かが口を出し始めたら、HA、ロールアウト/ロールバック、3〜5台のVM、仮想ネットワークポリシー、セキュリティスキャナー4つ、ログプロセッサ2つ、watchdog、ネットワークモニタ、mTLS、トラフィック可視化装置まで次々に付けようとする可能性が高い
もう1台あると、アップグレードや変更作業中に障害が出ても不安が少ない
私が作っている https://github.com/psviderski/uncloud はKamalに着想を得て、マルチマシン構成を単一VM並みにシンプルにし、zero-configのWireGuardオーバーレイと標準のDocker Composeで複数VMへデプロイする
オーケストレータやcontrol planeの複雑さなしに1台から始められ、必要なときにクラウドVMとオンプレミスを混在させて拡張できる
本番で使ってみて終始すばらしかったし、コンピューティングそのものを再定義したレベルに見えた
なので、ここまで嫌う側の視点で自分が何を見落としているのか気になる
OPは Tailscale共同創業者 の1人なので、文脈的にさらに興味深い
伝統的なCloud 1.0企業がVMのデフォルトで3000 IOPS程度しか出さない一方で、ノートPCは50万IOPS出る現実を指摘したのは的確に思える
ビジョンは本当に良く、自分はまさにターゲット顧客にも見えるが、成功が大きくなるほど理想より収益圧力が前に出る、よくある道筋に進まないか心配でもある
クラウド価格はコストベースでないことが多く、特に顧客が深く縛られた後でだけ大きく増える bandwidth や NAT gateway のような項目で強く利益が出るよう設計されがち
OPもこうした構造を知らないはずはないと思う
ただし、そのストレージは基本的にephemeralで、冗長性も十分ではない
RAID1でハードウェア障害を減らすことはできるが、搭載できるNVMeの数が減り、ホストのRAM/CPUなど別の問題でVMを移さなければならないときにもきれいな手段がない
結局こうしたVMはほぼベアメタルのように扱う必要があり、データベース複製のような アプリケーションレイヤーの冗長化 が必要になる
Azureでは、向こうの都合でVMを移動しephemeralデータを消されうる前提で考える必要があるが、OpenStackでは必要時にVMを停止し、ローカルのブロックレベルマイグレーションでNVMeデータごと別ホストへコピーできた
それでもホストがクラッシュしたら、そのVMはホストが復旧するまで停止したままなので、アプリレベルでの二重化が前提だった
ただし99.9パーセンタイルの遅延はHetznerが約5ms、DOは約18msで、最大遅延はHetzner 7ms台に対してDO 85msと差がかなり大きい
シーケンシャル dd ではHetznerが1.9GB/s、DOが850MB/sだった
価格差も大きく、Hetznerは4ユーロだがDOのインスタンスは18ドルだった
記事を全部読む前に書いたのだが、ちょうどOPもその2つを正確に指摘していた
単純なサーバーでさえマシン内DBを使いにくくして、lock-inを誘導しているのかもしれない
ある物を作るのにXかかるから1.y*XでYという価格を決める、という発想は実際の市場価格設定とはかけ離れている
bottom-upよりtop-downの方が現実的だ
AI をめぐる議論が極端に割れるように、Kubernetes も同じく二極化しているように見える
数年間にわたりさまざまな規模のクラスターを運用してきたが、障害原因がk8sそのものだったことは一度もない
あるとき1時間に及ぶ全面停電級の障害があったが、k8s嫌いの側はみなあの「忌々しいk8sシステム」のせいにしたがった
実際の原因は、ある状況でサービスが一気に数万のポートを開いて 自己DOS を起こしたことだった
k8sが未来のすべてだとも、ゴミだとも思っておらず、本当に必要な場面では良いシステムだと考えている
1つは学ぶことが複雑すぎるのに自分の問題には不要で、従来のデプロイ方法で十分だというもの、もう1つはベアメタルより コスト/エネルギー効率 が低いというものだ
たいていこの2つはセットで現れる
ほどほどに中立、あるいは無関心な立場の方がむしろ珍しくなっていて、米国政治もすぐ思い浮かぶ
自分もk8sはよく分からず、staff engineerがpodやclusterの話をすると目が泳ぐが、チームには合っていて実際に動いている
金槌しか持たない人には何でも釘に見え、斧を持つ人には、なぜ皆が金槌で木を割ろうとするのか不思議に見える
しかも本当は斧が適役の仕事なのに、金槌を持った人に仕事を奪われる状況なら、金槌を嫌いになるのも無理はない
k8sでは多くのユースケースでbest practiceがある程度整理されているが、LLM の方は、何がbest practiceなのかすらまだよく分かっていない
VMがCPU/メモリに縛られた形なので、仕事ではなく時間に対して料金を払わされる という指摘には強く共感する
そこで安価なHetznerのオークションサーバーを1台買い、自作のself-hostable Firecracker orchestrator の上に載せて使っている
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
欲しかったのは、ハードウェアを買ってVMを好きなだけ細かく分けて使い、プロビジョニングやライフサイクルは意識しないで済むことだった
アイドル状態のVMはメモリ状態をディスクへスナップショットし、RAMをすべて返却するので、ハードウェアは自分のもの、VMはdisposableで、遊んでいる間のコストはほぼない
特に memory-state snapshot があると、すべてが再開可能になる点は思った以上に強力だった
ログイン済みのChromium状態をスナップショットしておけば、必要なときにそのセッションの複製を即座に起動できるし、エージェントはサンドボックス内で動き、preview環境用のdocker composeもそこで回す
何も動いていないとき、サーバーは事実上アイドルで、月100ドルの箱1台がこれを全部こなしている
詳細は https://shellbox.dev/blog/race-to-the-bottom.html にまとめてある
ドキュメントは充実していて有用だが、かなりの部分に AIが書いた感 があるので、もう少し簡潔だとよさそう
それでも「design decisions」セクションは特に良く、そこで新しく学んだこともあった
まだならShow HNにも投稿する価値がありそう
すでに使われていないソフトウェアがあふれているのに、なぜ コードをさらに量産すること に執着するのかよく分からない
App Storeを見るだけでも、誰にも使われていないソフトウェアが山ほどある
LLMのより明白な用途は、ソフトウェアをさらに増やすことではなく より良いソフトウェア を作ることのはずだ
コード生成一辺倒から離れて別の方向へ焦点が移ることを望むし、LLMがより良いコードを書く助けになる方法はたくさんある
精巧に作り、保守し、更新する決定論的システムという図式は今後も残るだろうが、AIはすでにユーザーのコンピュータとの関わり方を変えつつある
その結果、もっと 使い捨てに近いソフトウェア が生まれるように思う
今はまだ「AIはエンジニアのソフトウェア作成をどう助けるか」の段階だが、徐々に「エンジニアはAIがよりうまくソフトウェアを書くために何をすべきか」へ移行していると見ている
そうなると、ソフトウェアとは何か、コンピュータとの相互作用をどう作るべきかについて、まったく異なる視点を持つ新しいエンジニア集団が入ってくるだろう
App Storeに一度も載らないようなカスタムソフトウェアが非常に多くなる気がする
ソフトウェア生産単価が下がったにもかかわらず、需要増加が節約効果を上回って総支出が増える状況でなければ、Jevons paradoxとは言えない
この概念は価格変化に対して需要量が大きく反応する、つまり 需要の価格弾力性 が高い市場で成り立つ
ゲームを除けば、数百万〜数十億人が使う単一のソフトウェアを作るというやり方が、あとから振り返ればどれほど奇妙だったか分かるようになる気がする
これからは人々が、食い違う優先順位や歪んだ収益モデルに振り回されにくくなり、自分が本当に望むことを正確にこなすソフトウェアを作れるようになる
そうしたソフトウェアは定義上、より 高品質 だとも言える
そのため双方にとってコストと売上の予測がしやすくなったが、核心はできるだけ 最大限に汎用的 なソフトウェアを作ることにあった
その結果、一部のユーザーにとってだけ重要なUXや機能は切り捨てられ続けた
Vibe coding とLLMによる開発加速は、これをひっくり返せるかもしれない
いまや誰もが、自分のニーズや好みに合わせたカスタムソフトウェアを負担できるようになり、Salesforceの顧客15万人が同じCRMを使う代わりに、15万個のカスタムCRMを使う世界すら想像できる
ソフトウェアの拡張余地は今、とてつもなく大きい
ソフトウェア肥大化サイクル を理解していないと、同じ失敗を延々と繰り返すことになる
lean softwareから始まり、ユーザー要望の機能が積み重なり、徐々にbloated messになり、また小さめのリライトが必要になって、再びlean softwareへ戻るという流れだ
リブートはたいてい失敗するか、あるいは何か本質をきちんと突いて既存の強者を脅かすほど前進する
DevOps を履歴書の飾り、過度な複雑性の元凶のように見なす視線は、むしろスタートアップ的な発想に近いと感じる
小さな会社ではDevOps担当1人がインフラ全体を受け持つこともあるだろうが、特に金融業界では実際に方向を握っているのはプラットフォームエンジニアリングのMDたちであることが多い
彼らはソフトウェアエンジニアを無数の小グループに分割し、各チームが自分のrepo、自分のデプロイ、自分のあらゆるものを制御することを望み、microservices がその権限を与えると信じている
断言するが、DevOps側は複雑さを嫌っている
夜や週末に呼び出されるのは彼らであり、しかもいつも「インフラの問題」という前提から始まるからだ
デプロイログはログ集約システムにすべて入っているのに、当の開発者が自分のデプロイの問題をログを見て自力で解決することは稀で、すぐ Incident になる
そろそろマイクロサービスも過ぎ去った流行と見なすべきではないかと思う
exe.devは好意的に見ていて、LLM開発フロー を滑らかにしつつ、root権限付きLinuxマシンの柔軟性を提供する方向には間違いなく機会があると思う
ただ、「半分実装され半分しか考えられていない抽象化に何度も裏切られてきた」という一文を読むと、皮肉にもそれこそ自分が Tailscale で感じたことでもある
ネットワーキングを簡単にするという触れ込みなのに、なぜこんなにバッテリーを食うのか、なぜファイアウォールルールを他ツールと衝突するように変えるのか、なぜバグトラッカーは静かなままなのか、結局は内部実装をこちらが理解しなければならない状況になる
だから「No thank you」と言いたくなる
そのサービス自体は本当に良さそうだ
ルーターACLを組みたいのではなく、peer-to-peerなネットワーク層を構成したいので、その点が惜しい
私はただ Hetzner を使っている
クラウド会社の提供物はどれも高すぎるし、自分で運用するPostgres HAとバックアップは10年間無停止で動いてきたのに、RDSやCloudSQLの本番コストの 10分の1 ほどだった
Grafanaで集めたメトリクスを基に自分でインスタンスをオートスケールし、webhookベースのautoscalerも非常に単純ながら一度も問題を起こしていない
だからもう、なぜGCPやAWSを使う必要があるのかよく分からない
サービスはすべてHAで、バックアップも毎日しっかり取れている
当時の目標は、最も柔軟なdedicated server体験をそのまま安価に再現することで、UMLがそれを可能にしてくれた
しかし2010年代を通じて、自分は開発者の大半が、少しの利便性のためにスタックのすべての部品で従量課金される方式を選ぶことはないだろうと、完全に読み違えていた
今どき20代のソフトウェアエンジニアでも、eBayで買ったサーバーとルーターで 高トラフィックWebアプリのプラットフォーム を組めるのだろうかと気になる
自分は去年そうして50PiB超のデータストアを作ったし、中〜大規模プロジェクトでこうしたやり方がどの程度使われているのか本気で知りたい
Hetznerは物理的な煩わしさをかなり取り除きつつ、経済的メリットはほぼそのまま提供しているのに、なぜホスティング界の王者ではなく、2021年時点で売上3億6700万ユーロ規模にとどまっているのか不思議だ
dedicated server群を扱う知識が、それほどまでに専門化されていて、人々がこれほど大きな節約を見過ごすとは信じがたい
ただし適任者を確保できるなら、自前運用の方がずっと安くなるというのはその通りだ
毎分cronがdocker pullで最新イメージを取りに行き、新バージョンがあるときだけdocker up -dで置き換える
手前にはHTTPS用にcaddyを置き、これで何年も非常に安く安定して動いている
似た哲学を持つ英国ベースの業者に見え、まだ使ってはいないが、次のVPS候補としてアカウントは作っておいた
最初から5倍速いサーバーを持てるなら、オートスケーリング自体が不要な場面も多い
代替手段はすでに多くあり、私は https://shellbox.dev を作った
exeと違って 使った分だけ課金 で、scale-to-zeroが可能で、SSHで即座にVMを起動できる
普通のLinuxなのでVSCodeやZedのremoteもサポートし、nested virtualizationも使える
投資したいなら500万ドルでも歓迎だ
外部公開ポートはなく、すべてのWebフロントエンドはパスワード保護されている
公開するつもりはなく、テレビの裏にある個人用Raspberry Piで動かしている自分の 隔離開発環境 だ
コストも実質ほぼゼロ
サービスの成功を祈っている
実際の基盤インフラがどこにあるのか、どんなセキュリティ保証があるのかなどがはっきりせず、ワークロードを任せにくい