クラウドを構築しています

5時間前原文(crawshaw.io)

概要

exe.devを立ち上げた個人的な動機についての説明
現在のクラウドサービスへの不満と課題の指摘
新しいクラウドの理想像とその実現方法の提案
exe.devが解決を目指す技術的問題点の具体例
今後の展望と読者へのメッセージ

exe.devを作る理由

既存クラウドサービスへの根本的な不満
- 個々のVMごとの制約
- ディスクI/Oやネットワークコストの不合理
- APIや抽象化の複雑さ、使いにくさ
**「コンピュータが好き」**という純粋な動機
- 小型マイコンからサーバーまで、あらゆるコンピュータを楽しむ姿勢
- しかし、現代クラウドには「好き」になれない違和感
クラウド抽象化の「形の悪さ」
- VMがCPU/メモリに紐付いている仕組みの非効率
- 本来なら、好きなだけVMを走らせたいという理想
- 現状ではgVisorやネスト仮想化などで無理やり実現、オーバーヘッドや管理コスト増
PaaSやKubernetesの限界
- 各クラウドごとに異なる抽象化で学習コスト増
- 途中で発覚する仕様制限やパフォーマンス問題
- Kubernetesは「本質的な問題解決ではなく、上塗り」に過ぎないという認識
ストレージとネットワークの問題
- SSD時代なのにリモートブロックデバイスのI/O性能が極端に低い
- ネットワーク出口コストが高騰、ベンダーロックインが進行
- 真に使いやすいクラウドを求める声
これまでのクラウド利用の“我慢”からの脱却
- 15年以上続く「仕方なく使う」状況
- しかし、今こそ「直すべき時」だと確信

新しいクラウドの必要性とエージェントの登場

AIエージェントの普及が転機
- コーディングの容易化でソフトウェア量が激増
- 個人や小規模チームが「自分専用の実行環境」を必要とする時代
- Jevonsパラドックス的に、使いやすいクラウドの需要が拡大
従来クラウド抽象化の限界
- エージェントも従来クラウドの制約には苦戦
- APIや設計上の制約が、エージェントの利便性を阻害

exe.devが目指すものと実現方法

資源単位での提供
- VM単位ではなく、CPU・メモリ単位でリソースを提供
- ユーザー自身が好きなだけVMを起動可能
セキュリティと利便性の両立
- TLSプロキシ・認証プロキシを標準装備
- 新規VMが直接インターネットに晒されない設計
高性能なストレージとグローバル展開
- ローカルNVMeストレージ＋非同期レプリケーション
- 世界各地にリージョンを設置、Anycastネットワークで低遅延化
今後の開発予定
- 静的IPや自動スナップショットなどの機能強化
- データセンターでの物理サーバー設置からネットワーク設計まで再構築
「自分が本当に使いたいクラウド」の実現
- 自分自身がワクワクするクラウドサービスの構築
- その価値を多くの人に届けたいという思い

まとめとメッセージ

exe.devは「好き」になれるクラウドを目指す
- 技術者としての純粋な情熱
- 既存クラウドの不満を根本から解決する挑戦
- 皆さんにとっても役立つサービスとなることを願う

Hackerたちの意見

すごい背景ですね。OPはTailscaleの共同創業者の一人なんですね。 > 伝統的なクラウド1.0の企業は、デフォルトで3000 IOPSのVMを売ってるけど、あなたのノートPCは500k持ってる。デフォルトを正しく設定すること（そしてそのコストを正しくすること）は、スタック全体を慎重に考える必要がある。彼らにたくさんの幸運を祈るよ！ビジョンを尊敬してるし、確実にターゲット顧客なんだけど、いつも通りの道を辿るんじゃないかと心配してる。素晴らしい理想から始まっても、成功が増すにつれて利益も必要になるからね。クラウドベンダーの価格設定は、しばしばコストに基づいていない。損失を出しているサービスもあれば、利益を大きく得ているサービスもある。これらは慎重に選ばれていることが多い。顧客がしっかりコミットしたときにのみコストが上がるタイプのもの—帯域幅、NATゲートウェイなど。でも、OPはこれを知っていると思う。

└

多くのクラウドベンダーは、IOPSや帯域幅に対して高い料金を請求してくる。編集: これを読む前に投稿したけど、彼が指摘している2つは同じだね。

└

ちょっと気になったから、実際にテストしてみた。fioを使って、Hetzner（cx23, 2vCPU, 4 GB）で ~3900 IOPS（読み書き）で、平均レイテンシは ~2.1 ms、99.9パーセンタイルは ~5 ms、最大は ~7 ms。DigitalOcean（SFO1 / 2 GB RAM / 30 GB Disk）も ~3900 IOPS（同じ！）で、平均レイテンシは ~2.1 ms（同じ！）、99.9パーセンタイルは ~18 ms、最大は ~85 ms（！！）。シーケンシャルなddを使った場合、Hetznerは1.9 GB/s、DOは850 MB/s。どちらも低価格プランだけど、Hetznerは4ユーロで、DOのインスタンスは$18だよ。

└

> クラウドベンダーの価格設定は、しばしばコストに基づいていない。ビジネス101では、価格設定はコストに基づいていないと教えられる。トップダウンとボトムアップの価格設定と呼んでもいいけど、基本的な原則として「ウィジェットを作るのに$Xかかるから、1.y * $Xで製品を$Yで売る」というのは、実際の価格設定の仕組みではないんだ。

└

>3000 IOPS もしそれが本当なら、クラウドプロバイダーがユーザーをS3みたいな独自のクラウドストレージを使ったマイクロサービスアーキテクチャに押し込むための意図的な決定なのかなって思う。そうすると、シンプルなサーバーでもオンマシンDBができなくなるし。

すごい資金調達だね、おめでとう！私はDropboxのコメント担当者だってことが分かるよ。自分でexeが提供するものを持っていて、これらの抽象化が他の人にどれだけの価値を提供しているかに驚いてる！自分のハードウェアで一回限りのコンテナを立ち上げたり、下げたり、非同期エージェントを動かしたり、Tailscaleの認証を使ったり、チームが名前で簡単に共有したり接続したりできるんだ。

└

投資は人間関係や未来のビジョン、チームへの信頼、そして有料顧客の数といった成長指標によって行われるんだ。今の技術自体はあまり価値がないね。

私はただHetznerを使ってるだけ。クラウド企業が提供するものは本当に高すぎる。自分のPostgresをHAセットアップとバックアップで運用してるけど、これがRDSやCloudSQLのサービスの10分の1の価格で、10年間ダウンタイムなしで運用できてる。グラファナから収集したメトリクスを使ってインスタンスを自動スケールしてるし、私たちには問題なく動いてる。Webhookでオートスケーラーを設定してるから、すごくシンプルで、今まで失敗したこともない。もうGCPやAWSを使う理由が分からない。私のサービスはすべて完全にHAで、バックアップも毎日ちゃんと動いてる。

└

企業がクラウドサービスを利用するのは、社内サーバーの管理や運用を減らしたいからだよね。彼らにとっては、適切な人材を雇うのとトレードオフなんだ。でも、あなたが言う通り、適切な人を見つけられれば、自分でやる方がずっと安く済むこともあるよね。

└

同意するよ。昔は自分のソフトウェアにHerokuやRenderスタイルのプラットフォームを使ってたけど、今はただLinuxサーバーにDocker ComposeとCronジョブを使ってる。Cronジョブは毎分docker pull（最新のイメージをダウンロード）とdocker up -d（新しいバージョンがあれば切り替え）を実行してる。HTTPSのためにCaddyを前に置いてる。これが何年も安くて信頼できるんだ。

└

正直、ヘッツナーはすごく好きなんだけど、最近はかなり不安定なんだよね。https://status.hetzner.com/ このページでは、いつも同時にいくつかのインシデントが発生してる。彼らのサービスには感謝してるけど、もう少し安定してほしいな。

└

最近は、ベアメタルサーバーにSSHで接続して、ClaudeにPostgresを設定してもらうだけで済むんだ。仕事はこれで終わり。最初から5倍速いサーバーを使えるから、オートスケーリングなんて必要ないよ。

└

だって、もし何百万ものユーザーがいる政府のサービスを持っていたら、安いクソサーバーにダメにされたくないじゃん。従業員のコストは月に8千から5万くらいかかる。クソなVPSプロバイダーを使ってサーバー代を月200ドル節約するために従業員を雇うのは、全然お金を節約してないよ。

└

うちも両方やったよ。Hetznerの専用サーバーは本当に良かったけど、日曜日の朝にディスクがSMART警告を出し始めて、他のところで10倍払ってる理由を思い出した。たぶん、単純なコストの問題じゃなくて、どの週末を取り戻したいかってことだね。

いい投稿だね。exe.devは私が楽しんだクールなサービスだよ。LLM開発フローをスムーズにする機会があると思うし、Linuxマシンでのルートの柔軟性もいいよね。 > 何度も「これだ！」って言ってきたけど、結局は中途半端な抽象化に裏切られてきた。いらないよ。皮肉なことに、これが私のTailscaleの体験なんだ。やっとネットワークが簡単になった。ああ、なんでバッテリーの調子がこんなに悪いんだろう。ああ、ファイアウォールのルールが他のツールと互換性のない形で変更されて、バグトラッカーは沈黙してる。彼らの実装を理解しなきゃいけないのか、ああ、いやだな。いらないよ。

└

Tailscaleの設定が難しいんだよね。デバイスのアイデンティティに基づいたACLルールを全然サポートしてないみたいで、アドレス空間の一部だけで判断してる。ここでルーターを設定してるわけじゃなくて、ピアツーピアのネットワーキングレイヤーを設定してるはずなんだけど…少なくともそうするつもりだったのに。

> クラウドプロバイダーからの1GBのエグレスの標準価格は、普通のデータセンターでサーバーをラックするのに払う金額の10倍だ。ああ、それは優しい表現だね。もっと100倍から1000倍くらいだよ。生の帯域幅は安いからね。

> エージェントは、コードを書くのを簡単にすることで、もっとたくさんのソフトウェアが生まれることを意味する。経済学者はこれをジェボンズの逆説と呼ぶだろう。私たち一人一人が、楽しみや仕事のためにもっとプログラムを書くことになる。すでに使われていないソフトウェアがたくさんあるよ。アプリストアを見てみれば分かる。なんで私たちはもっと多くのソフトウェアを作ることにこだわるのか理解できない。LLMの明らかな使い道は、より良いソフトウェアを書くことだと思う。コード生成から他の何かに焦点が移ることを願ってる。LLMがより良いコードを書く手助けをする方法はたくさんあるからね。

└

両方ともある程度は起こるだろうね。平均的な品質については、はっきりしない。私の直感では、エージェントがある程度底上げするけど、同時に中程度の品質のソフトウェアがもっと生まれることになると思う。高品質のものが以前よりも高い割合で出てくるかもしれないけど。

└

残念ながら、19世紀中頃から品質から量にシフトしちゃったんだよね。

└

時には「より良い」というのは「私の特定のユースケースにカスタマイズされている」という意味だと思う。アプリストアには出てこないカスタムソフトウェアがたくさん出てくるんじゃないかな。

└

> コード生成から別のことに焦点が移るといいね。LLMがより良いコードを書く手助けをする方法はたくさんあると思う。実は私の意見は逆なんだけど。今のソフトウェアはペットじゃなくて家畜に属してる。使い捨てのものを使うべきだし、マイクロスケールのスニペットを使うべき。話し言葉がプログラミングと同じくらいの意味を持つべきだと思う。（夢物語かもしれないけどね）その意味では、exe.dev（とTailscale）はペット主導のプロジェクトみたいなものだね。

└

> なんでこんなにもっと作り出すことにこだわってるのか理解できない… LLMの明らかなユースケースは、より良いソフトウェアを書くことだと思う。正直、これが理想だと思う。ゲームは別として、いつか振り返って、何百万、何十億のユーザーのためにソフトウェアを作ったことがどれだけ狂っていたかを実感すると思う。人々は今、自分たちが望んでいたことを正確に実現するソフトウェアを、競合する優先事項や収益モデルに邪魔されることなく作れるようになった。こういうソフトウェアは、定義上、高品質だと言えるかもしれないね。

└

Microsoft® Excel、Google Sheets、LibreOfficeはそれぞれ1つずつしかないけど、他は誰も使わない死にかけの「Excelキラー」が何億もあるんだよね。

└

エンジニアとして、私たちは「ソフトウェア」が伝統的に何であったかに少し囚われていると思う。私たちは、慎重に構築し、維持し、更新するシステムを考える。コンピュータと対話するための決定論的なシステムね。こういう「伝統的」なシステムはまだ残ると思うけど、AIはすでにユーザーのコンピュータとの対話の仕方を変えてしまった。この新しい対話が、別のタイプのソフトウェアを生み出すだろう。もっと使い捨てなタイプのソフトウェアね。今は「AIがエンジニアにより良いソフトウェアを書く手助けをするにはどうすればいいか」という段階だけど、徐々に「エンジニアがAIにより良いソフトウェアを書く手助けをするにはどうすればいいか」にシフトしていると思う。これによって、ソフトウェアとは何か、コンピュータとのインタラクションをどう構築するかについて全く異なる視点を持つ新しいエンジニアの群れが登場するだろうね。

> Kubernetesを良くするのは本質的に不可能で、豚に（確かに高品質な）口紅を塗るプロジェクトみたいなものだ。まさにその通り、私のk8sに対する気持ちを的確に表現してる。最初はウェブアプリを動かすためにいくつかのコンテナを管理するだけで、すごくうまくいくんだけど、気づいたらDevOpsの人たちが無限に他のサービスやソフトウェア定義ネットワークを追加することに決めちゃう。たくさんの時間を「最適化」や「強化」に費やした結果、クラウドの支出が倍増したり三倍になったり。インシデントも倍増、ダウンタイムも増えた。デバッグにかかる手間も倍増した。結局、そのDevOpsの人たちにさよならを告げて、クラスタを破壊して、Debianで単一のVMを立ち上げて、ファイアウォールを有効にして、Kamalを使ってアプリをDockerでデプロイした。クラスタではなく単一のVMしかないのに、インフラの観点からはこれまでにないほど安定して信頼性が高い。コストも激減して、運用がすごく安くなった。デバッグもずっと簡単で楽しいし、はい、単一のVMで全然大丈夫。ビジネスアプリケーションには本当に大きなVMが必要で、私たちが運用しているようなアプリには十分だよ。ほとんどのビジネスアプリケーションは数百から数千のユーザーしかいないし、クラウドプロバイダー（私たちの場合はGoogle）がハードウェアの故障を管理してくれる。ダウンタイムが必要な場合は、隣に別のVMを立ち上げて、プロビジョニングして、CloudflareでIPアドレスを更新するだけでいい。ロードバランサーも必要ないしね。

└

k8sを単一のVM上の単一アプリに置き換えたら、結局、最初から行くべきだったところに、ハイプに満ちた遠回りをしただけだね。

└

「ウェブアプリを動かすためのいくつかのコンテナ」をKubernetesで立ち上げるなら、最初から何か間違ってると思うし、KubernetesにSDNを追加するってコメントとも関連してるね。人々はKubernetesを小さすぎることに使いすぎてるし、実際にKubernetesを運用するスケールがないんじゃない？

└

よく分からないんだけど、k8sはwin95以降で書かれた最高のソフトウェアだと思う。私の意見では、コンピューティングを再定義してる。プロダクションでk8sを使った経験があって、その瞬間がすごく楽しかった。何か見落としてるのかな。

└

何年か前にスタックオーバーフローのエンジニアリングブログでみんなが学んだことだと思ってた。限界に達するまで縦にスケールして、もし限界に達しても他の誰かに解決してもらうための十分なお金があるって。Dockerは開発ツールであって、プロダクションインフラじゃないよ。

└

DevOpsはオペレーターモデルで迷走してると思う。これが「THEパターン」として広まっていくのを見て、正直がっかりしたよ。オペレーターって、データベースみたいな複雑なサービスをyamlやカスタムのGoサービスの背後に完全に抽象化しちゃうんだよね。KubeConに行ったとき、ある人が「オペレーターをキャンディみたいに集めてる」って言ってたのが印象的だった。ライフサイクル管理や、常に変化するオペレーターの状況での大規模なアーキテクチャ変更についての答えは、ステージングや開発クラスターの一連で軽く流されちゃった。これって、すごくコストがかかるよね。根本的な問題は、抽象化が多すぎて「共有責任モデル」のDevOps側に完全に偏ってることだと思う。AWSやAzureからRDBMSを持ってくるのは、クラスター内でその責任を全部背負うよりもはるかに優れてる。ちなみに、ちょっとインフラ系のこだわりがあるから、家ではNixOSを使ってsystemd OCIコンテナを動かしてる。AIのおかげで、これが今までで一番メンテナンスしやすいよ。

└

このコメントと返信はKubernetesの問題をよく表してると思う。今、Kubernetesを選んでクビになることはないからね。君や僕、そして15分以内に反応した他の2人の技術系の人たちには、Kubernetesを使うべきじゃなかったってのは明らかだよ。でも、君は多分、技術系の人たちがいっぱいの会社で働いてて、結局Kubernetesを使うことになったんだよね。ここにはHNがあって、技術系の人たちが集まってるけど、99%のケースでk8sを使うべきじゃないってすぐに気づく。でも実際のプロの環境では、同じ技術系の人たちが99%のケースでk8sを使うことを許容したり、サポートしたり、結局それを使うべきだって考えたりするんだ。なんか「裸の王様」みたいな要素がある気がする。

└

明らかに、Kubernetesは君のケースには合ってなかったね。小規模なアーキテクチャに使うのはオーバーキルだと思う。でも、大規模なプロダクションプラットフォームには再現性と高可用性が必要だから、標準になってるのも事実だよ。今のところ、*本当に* viableな代替案はあまり見かけないし、正直言って見たこともない。

まだクラウドコンピューティングに不慣れなんだ。Linodeしか使ったことがない。これって何なの？記事を通して具体的なデザインがよくわからなかった。助けて！

恥ずかしながら宣伝: https://clawk.work/ `ssh you/repo/branch@box.clawk.work` → クローンしたリポジトリと認証情報を注入して、Claude Code（またはCodex）に直接ジャンプ。Firecracker VM、月19€。POC、優しくお願いします。

これは、ReadeckやCalibre-web、Immichみたいな軽いものをクラウドで「ホームラボ」として運用するのに素晴らしいプラットフォームに見える（いや、アイロニーは分かってるよ）。もしかしたら、Home Assistantも、mDNS/multicastトラフィックをトンネルする方法（Tailscale？）が見つかればできるかも。