Andrew Tanによる
着地しなかったデモ
layline.ioの開発を始めて18か月が経過した頃、初めての本格的なエンタープライズ顧客が現れました。あるフォーチュン500の物流企業です。彼らのデータチームは私たちのアーキテクチャをレビューし、バッチとストリーミングを組み合わせたアプローチを気に入り、深く掘り下げるための一日ワークショップを予定しました。
私たちは数週間をかけて準備しました。複雑なイベント処理、自動バックプレッシャー処理、スキーマ進化など、すべてを披露するデモを構築しました。それは、教科書通りのベストプラクティスアーキテクチャでした。分散型で、Fault Toleranceがあり、水平スケーリングが可能です。会議でホワイトボードに描くようなシステムです。
ワークショップは順調に進みました。エンジニアたちは良い質問をしました。そして、最後の30分で、シニアアーキテクトが椅子に寄りかかり、忘れられないことを言いました：「これは印象的です。しかし、私たちはすべてを単一のサーバーでcronジョブを使って運用しており、それでうまくいっています。この複雑さから実際に何を得られるのでしょうか？」
私は100の答えを用意していました。Scalability、レジリエンス、将来への備え。しかし、彼の顔を見て、彼が技術比較を求めているのではないとわかりました。彼は、彼の現在の現実—退屈で、シンプルで、機能している—がなぜ不十分なのかを正当化するよう求めていたのです。
私はできませんでした。正直に言えば。
削除したアーキテクチャ
3か月後、私は別の顧客と別の部屋にいました。今回は中規模のフィンテック企業です。彼らは2年間Kafkaベースのストリーミングパイプラインを運用していました。それは常に崩壊していました。彼らはコンサルタントを雇い、ハードウェアをアップグレードし、コンシューマロジックを2回書き直しました。システムは、すべての分散システムの教科書に従って「正しい」ものでした。しかし、それは運用するのが悪夢でした。
会議で、彼らのリードエンジニアがアーキテクチャ図を見せてくれました。それは美しいものでした。12のマイクロサービス、3つの異なる永続化レイヤー、状態管理のためのカスタム運用データストア。彼らはConfluentのブログやMartin Kleppmannの本からすべてのパターンを取り入れていました。
「もし、」と私は尋ねました。「イベントをファイルに書き込んでバッチで処理するだけだったら？」
彼は私を見つめました。「それは...ストリーミングではありません。」
「そうですね」と私は同意しました。「しかし、あなたは下流システムがリアルタイムの更新を処理できないため、毎時イベントを処理しています。バッチセマンティクスを達成するためにストリーミングアーキテクチャの運用コストを支払っています。」
その日はlayline.ioを購入しませんでした。しかし、6週間後、私はメールを受け取りました。彼らはアーキテクチャ全体を削除しました。ファイルを読み込み、データベースに書き込む単一のプロセスに置き換えました。基本的にはcronジョブです。彼らのp99レイテンシーは200msから5分に増加しましたが、ビジネスプロセスが日次であるため問題ありませんでした。運用上のインシデントは週3回からゼロになりました。彼らのエンジニアリングチームは火消しから機能の出荷に移行しました。
「間違った」アーキテクチャは、彼らの実際の制約に合っていたため、より良かったのです。
ベストプラクティスの罠
25年間のデータインフラストラクチャの構築と販売から学んだことは、ベストプラクティスは定義上コンテキスト依存であるが、普遍的な真実としてマーケティングされているということです。
Netflixが必要とするストリーミングファーストのアーキテクチャは、50人のSaaS企業が必要とするものではありません。Amazonが1日に10,000回デプロイするためのマイクロサービスアプローチは、4人のエンジニアのチームが必要とするものではありません。5000万ドルのVC資金を調達したAIエージェントフレームワークは、cronベースのETLが必要とするものではありません。
しかし、業界コンテンツを読むとそれがわかりません。すべてのベンダーブログ投稿、すべての会議講演、すべてのアーキテクチャブループリントは同じ進行を示しています：シンプルに始め、成長するにつれて複雑さに「卒業」する。暗黙のメッセージは明確です：シンプルは初心者向け、複雑さは真剣な実践者向け。
これは逆です。複雑さは、喜んで追求すべき名誉のバッジではなく、慎重に追加すべき負債です。
「私たちにとっての成功」が実際にどのように見えるか
私は顧客との初期の会話で異なる質問をするようになりました：「あなたの実際のワークロードに対して、最もシンプルなもので機能するものは何ですか？」 3年後の予測ワークロードではなく、CEOが一度言及した理想的なリアルタイムユースケースでもなく、今日の実際のワークロードです。
答えは一貫して驚くべきものです：
- ある医療会社は、毎日100万件の患者記録を処理するのに、毎晩4時間かけて実行されるシングルスレッドのPythonスクリプトを使用しています。それは6年間変更なしで動作しています。なぜなら、記録は午前2時にFTPで到着し、医師は午前8時までダッシュボードを見ないからです。
- ある小売会社は、2,000店舗からの販売時点データを処理するのに3ノードのKafkaクラスターを使用しています。スループットが必要だからではなく、1日のイベントを1つのファイルに収めることができるからです。しかし、既存のチームがKafkaを知っていて、最も忙しいシーズン中に新しいことを学ぶ時間がなかったからです。
- ある物流会社は、コンテナ船をリアルタイムで追跡するのに...スプレッドシートを使用しています。運用チームが手動で更新しています。自動化されたパイプラインを2回構築しようとしました。どちらも、自動化されたシステムがスプレッドシートよりもデバッグが難しい方法で失敗しました。スプレッドシートは「間違っている」点が12ありますが、それは検査可能な間違いです。エラーを見ることができます。
これらはどれも「ベストプラクティス」ではありません。しかし、すべてがそのコンテキストに正しいものです。
AIエージェントのハイプサイクル
ベストプラクティスの罠を最も積極的な形で見るには、データエンジニアリング業界が現在AIエージェントにどのように対応しているかを見てください。
最近読んだ競合他社のブログ—Airbyte、Confluent、Kestra—は、製品を「AIエージェント対応」と位置付けています。Model Context Protocol、エージェントのためのオントロジー、コンテキストウィンドウ管理に関する詳細な説明があります。暗黙のメッセージはこうです：今AIエージェントのためにアーキテクチャを設計していないなら、遅れをとっています。
先週、ある顧客にデータパイプラインにAIエージェントを検討しているか尋ねました。「LLMを使ってSQLを生成しようと6か月を費やしました」と彼は言いました。「単純なクエリでは70%の正確さ、複雑なクエリでは30%の正確さでした。30%は微妙で、CEOがボードデッキで間違った数字を見つけるまで気づきませんでした。私たちはエンジニアがSQLを書く方法に戻りました。」
これはAIに反対する議論ではありません。これは、現在のベストプラクティスだからといってAIをデフォルトで使用することに反対する議論です。今日AIエージェントから利益を得ているチームは特定の特徴を持っています：高いクエリボリューム、比較的単純なスキーマ、時折のエラーに対する許容度、出力を検証するためのエンジニアリングリソース。それがあなたの状況を説明していないなら、AIエージェントはまだあなたの解決策ではありません—どれだけ多くのベンダーブログ投稿がそれを示唆していても。
技術を実際に評価する方法
では、「ベストプラクティス」が信頼できるガイドでない場合、何が信頼できるのでしょうか？
私が今使用しているフレームワークはこれです。自分のアーキテクチャの決定にも、顧客にアドバイスする際にも：
まず、実際の制約から始めます。どれだけのデータ？到着パターンは？レイテンシー要件は？チームの規模と専門知識は？運用の予算は？これらの質問への回答は、「業界標準」のアーキテクチャの90%を即座に排除します。
デバッグのために最適化し、エレガンスのために最適化しないでください。クリーンな図を生成するアーキテクチャは、午前2時にデバッグするのが最も難しいものです。3つの異なる抽象レイヤーを横断せずに、ソースからデスティネーションまで単一のレコードをトレースできるシステムを優先します。
運用コストをインフラストラクチャのドルだけでなく、チームの注意で測定します。分散システムが自動で動作するが、シニアエンジニアがオンコールである必要がある場合、それはジュニアの採用者が管理できるが時折再起動が必要な単一サーバーよりも高価です。
実際に行う移行を計画し、行うべき移行を計画しないでください。すべてのチームには、決して退役しないレガシーシステムがあります。古い技術との優雅な共存を設計し、それを革命的に置き換えるのではなく。
迷ったときは、退屈なものから始めてください。複雑さを追加することは常に可能です。削除するのははるかに難しいです。成功しているチームは、シンプルなアプローチが尽きたことを明確に証明してから、技術を追加することに慎重です。
私がしていない反論
私が言っていないことを明確にしたいと思います。私は技術的保守主義を支持しているわけでも、新しいことを試すことに反対しているわけでもありません。ある問題は本当に複雑で、分散型のリアルタイムアーキテクチャを必要とします。大規模で支払いを処理している場合、正確なセマンティクスが必要です。サブ100msのレイテンシーでML機能を提供している場合、ストリーミングが必要です。Netflixであるなら、Netflixが必要とするものが必要です。
しかし、ほとんどの企業はNetflixではありません。ほとんどのデータパイプラインは1秒あたり10,000のイベントを処理する必要はありません。ほとんどのチームは「現代の」データインフラストラクチャの運用負担を管理するプラットフォームエンジニアリンググループを持っていません。
不快な真実は、業界が「成功したテック企業が行うこと」と「あなたが行うべきこと」を混同しているということです。成功したテック企業は無限のエンジニアリングリソースを持ち、運用の痛みに対する高い許容度を持ち、リアルタイムのすべてを必要とするビジネスモデルを持っています。あなたの会社はおそらくそうではありません。あなたのアーキテクチャはそれを装うべきではありません。
layline.ioが適している場所（そして適していない場所）
最後に、驚くかもしれないことをお伝えします：layline.ioはすべてのデータ統合問題に対して適切な選択ではありません。
いくつかのバッチジョブがスケジュール通りに安定して実行されており、チームが現在のセットアップに満足している場合、おそらく私たちは必要ありません。本当に。現在の現実が安定して理解されているなら、新しいプラットフォームを学ぶための運用上のオーバーヘッドは価値がありません。
私たちが価値を提供するのは、シンプルなアプローチを超えたが、複数の専門ツールをつなぎ合わせる複雑さの税金を避けたいときです。バッチとストリーミングの両方を同じシステムで必要とするとき。別々のオーケストレーション、変換、モニタリングレイヤーを維持することに疲れたとき。3つの異なるツール間の調整シームを管理するのではなく、1つのモデルに統合したいときです。
それでも、私は1日のデータを処理する概念実証から始めることをお勧めします。複雑なアプローチにコミットする前に、シンプルなアプローチが実際のワークロードに対して機能することを証明してください。
ベストプラクティスは、あなたにとって機能するものです。それ以外はすべてマーケティングに過ぎません。
データインフラストラクチャを評価しており、特定の状況に対して実際に追加する価値のある複雑さについて正直な評価を望む場合は、お問い合わせください。私たちが必要かどうか、またはcronジョブを維持すべきかをお伝えします。
Andrew Tanは、バッチとリアルタイムのワークロードをスケールで処理するエンタープライズデータ処理インフラストラクチャを構築しているlayline.ioの創設者であり、連続起業家です。
