- 実際のユーザー数が少ないにもかかわらず、不必要に複雑なシステム構成を使っている問題を指摘
- Redis、MongoDB、Kubernetes、マイクロサービス などさまざまな技術を無分別に組み合わせた事例を提示
- 単一の Postgres インスタンスとシンプルなサーバー構成 だけで十分な状況を強調
- 複雑さは美徳ではなく、必要性が証明されたときにだけ拡張すべきだと強調
- スタートアップや開発チームが 規模に見合ったシンプルな設計原則 を守るべきだと思い出させる内容
不必要な技術スタックの乱用
- Redis と MongoDB が同時に使われるなど、無作為に選ばれた技術の組み合わせを批判
- 「なぜ Redis が MongoDB とやり取りしているのか？」「なぜ MongoDB を使うのか？」という問いを提示
- 実際のユーザー数が 12 人（そのうち 6 人はテストアカウント）しかいないのに 分散システム を導入した点を指摘
- 単一の Postgres インスタンス で十分だったにもかかわらず、過剰な拡張を選んだ事例として言及
デプロイとインフラ構成の過剰
- 現在の構成: 15 個のマイクロサービス、8 個のデータベース、3 環境の Kubernetes クラスター、4 個のメッセージキュー、サービスメッシュ、2 時間かかる CI/CD パイプライン
- 必要な構成としては 単一サーバー、Postgres、キャッシュ用 Redis 程度のみを提示
- 実際の要件に対して インフラの複雑さが過剰 であることを明確に対比
システムの複雑さと説明可能性
- ジュニア開発者にシステムを説明するとき スパゲティのように絡み合ったダイアグラム が必要なら問題があると指摘
- 複雑さは美徳ではない という一文で中核メッセージを要約
- シンプルに始めて、必要性が証明されたときにだけ複雑さを追加 すべきだと強調
核心的な教訓
- 技術選定とシステム設計は 規模と実際の利用量に合わせてシンプルにする べき
- 無分別な拡張と過剰な技術スタック導入 は保守性と効率を損なう
- スタートアップや小規模チームが 「規模に見合ったシンプルさ」 を守ることが重要
1件のコメント
Hacker Newsの意見
こういう行動は、時には単なる 先延ばし(procrastination) のように見える
顧客や投資家、法務チームのような人たちと話したくないから、代わりにエンジニアとしての「面白い仕事」をやる
一見すると生産的に見えるが、実際には足踏みしているだけだ
毎日あえて不快な仕事をしないと、少しずつ退化していき、後になって避けられたはずの大きな問題にぶつかる
これはソフトウェアだけでなく、人生全般にも当てはまる
お金を稼ぐには、面白い仕事より 優先順位が正しい仕事 をしなければならないと学んだ
現実から乖離したCTOやVPEの 理想的なアーキテクチャへの執着 を満たすためではないかとも思う
以前、システムデザイン面接で モノリシック vs マイクロサービス をめぐって空気を読む勝負をした記憶がある
結局、権限を持つ人たちが望む方向は明確で、それに逆らうのは政治的資本を燃やすことになる
「自分はABCとXYZをつないだことがある」みたいに、技術スタック自慢を並べ立てる
履歴書を立派に見せたいという欲もある
実際にはほとんどのプロジェクトは1990年代の技術でも十分実現できるが、分散システム という言葉が入るだけでずっと「クール」に見える
業界の歪んだ採用文化のせいで、料理人が包丁をうまく使えることよりも「特定ブランドの包丁」を使うことが評価されるようなものだ
たとえばDuckDuckGoはアルゴリズムとデータ構造だけを求め、「ちなみにPerlを使っています」と明かすだけだ
StreamはGoを知らない応募者に10週間のコースを提供し、Jane StreetもOCaml経験を求めない
私が働く bevuta IT GmbH でも入社後に Clojure を学べるようにしてくれた
こうしたアプローチは、「Ruby on Rails 10年経験者」のような古臭い求人とはまったく違う
新しいものを試して比較してみたかったからだ
結局、数百人のユーザーのために 不要な複雑さ を語るのがこの業界の現実だ
「Redisでキャッシュ」という言い方はあまりにもありふれているが、実際にはPostgresでも十分だ
わざわざRedisを使おうとするのは、著者自身も オーバーエンジニアリング欲 に勝てなかったのだと思う
規模が小さいうちはキャッシュ自体が不要だし、一時データ を別システムに置くほうが魅力的だ
フレームワークのキャッシュ抽象化も大半はRedisを前提に設計されている
最初はインメモリキャッシュで始めて、必要になったらRedisを追加するのがよい
ただしRedis/Valkeyはやりすぎだ。memcached のほうがずっと単純で実用的だ
Redisのように状態を保存しないので、キャッシュ整合性に依存する 悪い設計パターン を避けられる
DBキャッシュはファイルシステムを経由しなければならないので遅い
クエリを効率的に書くことはまったく別の問題だ
Postgresを再び速くできればRedisを外せるかもしれないが、たいていはそのまま残る
AWS LambdaベースのWebアプリで毎秒1000リクエストを処理するとき、Postgresは厳しかったがRedisは余裕だった
単純さ のおかげで、例外的に使う価値がある
著者が「単純さ」を主張しながら、Tailwind + JSフレームワーク + バンドラー でページを作っているのが面白い
単純なHTMLでも作れたはずなのに
だから自分で作れるシンプルなWebフレームワーク MastroJS を紹介したい
実際には使ったユーティリティクラスだけをCSSとして生成する
元のツイートは Jeff Atwoodの2013年のツイート に由来する
今の私も似たような判断に悩んでいる
市場検証されていない製品なら、小さく素早く始めて ピボット可能なMVP を作るのが正しい
一方で投資家や大企業に スケーラブルな設計能力 を示さなければならないなら、最初からスケール可能な構造を選ぶべきだ
ビジネスモデルが単一DBでは耐えられないほど大きくならないと成立しないなら、初期から拡張型アーキテクチャ にするほうが長期的には得だ
インフラの悪夢の中で働く立場からすると、単純さは絵空事に聞こえるかもしれない
だが多くの複雑さは技術的というより 組織的問題の解決 のためのものだ
デプロイ自動化、障害対策の 冗長性、CIパイプライン、シークレット管理、キャッシュなどは、チームを守るための安全装置だ
こうしたものを無視するのは、チーム単位で働くときには危険だ
SQLiteも本番で十分使えるのに、「テスト用だけ」という偏見が広まっている
PaaSのデフォルト設定が不要に複雑なことも多い
チェックリストベースのビルドプロセス から始めて、それが安定したら自動化へ広げればよい
FAANG級でもないサービスで、マイクロサービスが本当に必要だった事例を見てみたい
考えるのが怖いから、みんな 標準技術スタック ばかり追いかける
Kafka、Mongo、Redisのようなものを無批判に使うのが問題だ
実際には必要な機能だけを自分で実装したほうがよく、最小構成要素を選ぶ能力 こそエンジニアの核心だ
Kafkaのようなものは無駄に金がかかるだけだ
「必要なときにだけ複雑さを追加せよ」というのは正しいが、後から追加しにくい場合もある
初期設計を間違えると 全面的な書き直し が必要になることもある
だから現実的には シンプルなk8s構成 のような折衷案が必要だ
最近の面接でも似た経験をした
この10年間、私は PMF(Product-Market Fit) の確立に集中していて、最初からスケーラビリティに執着してはいなかった
製品が市場に合えば、スケールの問題はお金で解決できる
だが面接で「Djangoサービスを1日1000万リクエストにスケールさせる方法」を聞かれ、
「サーバースペックを上げればいい」と答えたら、あまり満足されなかったようだ