「ステートレス至上主義」でシステムが壊れた話

昔、途中から入ってきたインフラエンジニアに、システムを引っ掻き回されたことがある。

結論から言うと、 「ステートレスにこだわりすぎて、システムが破綻した」話。

■ ある日「Airflow使いましょう」が始まった

プロジェクトの途中から、インフラ寄りのエンジニアが参画してきた。

彼の提案はシンプルだった。

• Airflowで全体をオーケストレーションする
• 各サブシステムはマイクロサービス化
• 全てステートレスなREST APIにする

一見、正しい。むしろモダン。

この時点では誰も反対しない。

■ 「理想の設計」が現場を壊す

問題はここから。

彼は「理想の構成」をベースに、既存システムへ修正を要求してきた。

• サブシステム間のやり取りをAPI化
• 状態を持つ処理を排除
• 全てAirflowから制御

結果どうなったか。

👉 Airflowに全責務が集中した

■ Airflowがモンスター化した

本来、Airflowは「ワークフロー管理ツール」。

なのに、こうなった。

• データの整合性チェック → Airflow
• 状態管理 → Airflow
• リトライ制御 → Airflow
• ビジネスロジックの一部 → Airflow

そして当然こうなる。

👉 DAGが巨大化 👉 依存関係がカオス 👉 デバッグ不能 👉 変更すると全部壊れる

完全に詰み。

■ そもそも最初の設計は何だったか

元々の設計はこうだった。

• サブシステムごとに責務を分離
• 必要な状態は各システム内部で保持
• お互いは疎結合とし、意味のある単位でカプセル化

つまり、

👉 「適切な粒度で状態を持つ」設計

だった。

それを

👉 「ステートレスにしろ」

で全部壊した。

■ ステートレスは万能じゃない

ここが今回の本質。

ステートレスは良い設計原則だけど、

👉 「どの粒度で状態を持つか」 👉 「どこまでを1つの責務にするか」

を無視すると、ただの思想ゴリ押しになる。

■ 今回の失敗の本質

問題は技術ではない。

👉 情報のカプセル化の設計が破綻していた

具体的には：

• サブシステムで持つべき状態を外に出した
• APIを細かくしすぎた（粒度が小さすぎた）
• 結果としてAirflowが状態管理装置になった

つまり、

👉 分散したつもりで、中央集権化している

■ よくある勘違い

マイクロサービス = ステートレス

これは半分正解で、半分間違い。

正しくは：

👉 「サービス単位では状態を持っていい」 👉 「サービス間のインターフェースをシンプルにする」

■ 学び

今回の学びはシンプル。

• ステートレスにこだわりすぎるな
• Airflowは「制御」であって「処理」ではない
• カプセル化の粒度を間違えると全て壊れる

そして一番重要なのはこれ。

👉 インフラの知識 ≠ システム設計力

■ まとめ

「正しい技術」を使っても、

👉 使い方を間違えると普通に壊れる

むしろ、ちゃんと動いていたものを壊すこともある。

設計で一番大事なのは、

👉 思想じゃなくて、責務と粒度

■ おまけ（個人的な反省）

今回一番ダメだったのは、

👉 途中で止められなかったこと

正論っぽい設計は止めづらい。

でも、

👉 「それ本当に動く？」

を言い続けるのは大事。

こういう「理想で壊れるパターン」は現場あるあるなので、 同じ失敗をする人が減ればいいなと思う。