サプライチェーンシステムの偶発的な複雑さについて
現代のコンピューティングハードウェアは非常に能力が高いです。控えめなスマートフォンでも、数十億のFLOPS（秒あたりの浮動小数点演算）を提供し、数百ギガバイトのデータを保存することができます。一つのスマートフォンは、非常に大規模な小売ネットワークのために予測的な在庫割り当てを_技術的に_実行することができます。適切な表現[^stream]が必要となり、データの解析側では、差分可能プログラミングのようなより効率的な技術を使用する必要があります。したがって、高性能なサプライチェーンシステムは当然のことです。企業は、自社のサプライチェーンを実行し最適化するために、スマートフォンよりも優れたものを手に入れる余裕があるはずです。しかし、Lokadのお客様のサプライチェーンシステムを見る限り、その逆の状況がほとんどです。これらのシステムはほとんど常に遅く、頻繁に_苦痛に_なります。
現在のサプライチェーンソフトウェアのリーダー（ERP、WMS、MRPなど）は、APIバックエンドで1秒あたりのリクエストを維持するのが難しい状況です。Lokadでは、私たちはデータの取得プロセスの最前線にいるため、そのようなひどいパフォーマンスを毎日痛感しています。数十のクライアントに対して、初期のデータの取得にはほぼ1か月かかりました[^incremental]。さまざまなAPIの遅さが問題の99.9%を占めています。データの抽出に1MB/秒を維持できるシステムは少なく、遠くにあります。私たちが同じデータを何度も不必要に再抽出することなく、最新の部分に到達するために必要なシステムはさらに少ないです。これらのシステムは、2つのディケード前と比較して、100以上のコンピューティングリソースを利用できるようになりましたが、基本的には速くなっていません[^faster]し、根本的には何も劇的に改善されていません。最も進歩的なベンダーの中には、小売ネットワークを扱うために数テラバイトのRAMが必要なものもありますが、これはそのリソースを使用する上で驚くほど大きな[^large]量のRAMです。
この多くの（ほとんどの？）サプライチェーンシステムの「偶発的な複雑さ」は、2つの根本的な原因に遡ることができます。第一に、コンピューティングハードウェア自体に関する誤った期待、第二に、解決策の内部設計への注意不足です。
コンピューティングハードウェアの進歩については、10年前まで、最初の_Mooreの法則_が（通常は誤って）何度も提案されなかった（大）企業はありませんでした。コンピュータが常に驚くほど速くなっているという感覚がありました。残念ながら、これは2000年代初頭以降、ほとんど「当然のこと」とは言えなくなりました。この無限の進歩に関する誤った見方は、サプライチェーンの世界を超えた多くのソフトウェア企業が大きな間違いを犯す原因となりました。Windows Vista（2006年リリース）に関連する多くの問題は、Microsoftのエンジニアが2001年にWindows XPがリリースされたときに、2006年までにCPUのクロックが6Ghzになるという最初の期待に遡ることができます。2020年も終わりに近づいていますが、ハイエンドのゲーミングCPUはわずかに5Ghzを超えることしかできません。コンピューティングハードウェアは進歩を止めませんでしたが、ソフトウェア企業にとっては、少なくとも「当然のこと」として進歩が止まったのです。
title: “1980年代と1990年代において、ソフトウェアが動作するとすぐに、リリース時点では多少遅いかもしれませんが、次の年には十分な速度になり、その次の年には優れた速度になるというのは当然のことでした。マイクロソフトのような積極的なソフトウェア企業は、このカードを非常にうまく切りました。彼らのエンジニアは（今でも）お金で買える最高のコンピューティングハードウェアを与えられ、ハードウェアがパフォーマンスの問題を解決するだろうということを知って、ソフトウェアのパフォーマンスを限界まで追求しました。Vistaの失敗を経て、マイクロソフトのエンジニアリングチームは問題の深刻さに気づき、やり方を変えました - Windows 7は大幅な改善でした。しかし、Windowsがパフォーマンス面で本当に回復するまでには10年かかりました。現在では、見通しはほぼ正反対です。最高のマイクロソフトのチームはもはや将来のハードウェアに頼ることなく、優れたソフトウェアによる即時の優れたパフォーマンスに集中しています[^softperf]。”
“しかし、エンタープライズソフトウェアの世界は、この問題に気づくのがはるかに遅く、2010年代には、過去に何度も起こったように、将来のコンピューティングハードウェアがすべての問題を解決する寸前でソフトウェアを構築し続けました。残念ながら、ほとんどのエンタープライズソフトウェアベンダーにとって、コンピューティングハードウェアはまだ進歩していますが、10年前には「些細な」方法で進歩が止まりました[^hardperf]。ソフトウェアは時間の経過とともに蓄積される傾向があります（機能の追加、オプションの追加、画面の追加など）。したがって、複雑なソフトウェアの自然な傾向は、時間の経過とともに遅くなることであり、改善することではありません - この点において強力な専用の取り組みがない限り。”
“残念ながら、販売の観点から見ると、パフォーマンスはほとんど問題ではありません。デモは、システムが本番で直面するデータワークロードのごく一部を含むおもちゃのアカウントで行われます。また、トップマネジメントに関連する画面は、企業の下っ端向けの画面と比べて非常に多くの手を加えられます。しかし、後者こそが1日に何千回も使用される画面であり、したがって最も注意を払うべき画面です。APIが非常に低速なパフォーマンスを提供しているかどうか、ほとんどの購入者が調査していないため、APIは頻繁にひどいパフォーマンスを提供します。ソフトウェアベンダーはこれを知っており、エンジニアリングの投資を調整しています。”
“これにより、パフォーマンスの問題の2番目の側面について言及します。それは、解決策の内部設計への注意の欠如です。現在、進行中のハードウェアの改善を活用するためには、戦略的なソフトウェア設計の決定が必要です。しかし、設計の決定は二律背反の剣です。それは権限を与えると同時に制限も与えます。ビジネス側と技術側の両方で設計の決定にコミットするには、強力なリーダーシップが必要です。迷いは簡単ですが、エンタープライズソフトウェアの大多数が示すように、パフォーマンス（およびUX全般）は大きく損なわれます。”
“現代のソフトウェア（エンタープライズソフトウェアに限らず）の落とし穴の1つは、_レイヤー_の過剰な存在です。データはソフトウェア内の数十の内部レイヤーを介してコピーされ、パイプされ、プールされ、同期されます。その結果、コンピューティングリソースの大部分が「内部の配管」と呼ばれるものに無駄に費やされ、付加価値を提供していません。設計の観点からは、解決策は概念的には簡単ですが、実行は困難です。第三者のコンポーネントを節約的に使用する必要があります。特に、ある種のレイヤーを伴うコンポーネントは避けるべきです[^layers]。ソフトウェアベンダーの観点からは、1つのレイヤーを追加することは、製品にさらに「クールな機能」を追加する最も迅速な方法であり、膨張を考慮していません。”
“Lokadでは、コンパイラコアを中心に当社のプラットフォーム全体を設計することで、包括的に統合されたスタックを選択しました。デメリットとしては、ランダムなオープンソースプロジェクトを簡単にデザインに組み込むオプションを失います。統合は可能ですが、通常はコンパイラ自体により深い変更が必要です。一方、エンタープライズソフトウェアに関しては、通常は「考えられない」とされる「ベアメタル」パフォーマンスを実現しています。全体として、オープンソースコンポーネントが悪化していることを考慮すると、このアプローチは過去10年間で特に効果的であることが証明されています[^maintenance]。”
“相互化されたマルチテナンシーは、少なくとも「コスト対効果」の観点から見ると、パフォーマンスに根本的な影響を与える設計の選択です。ほとんどのエンタープライズソフトウェア（サプライチェーンソフトウェアを含む）は、計算リソースの要件が非常に断続的です。たとえば、スペクトルの端に位置する予測数値レシピは、1日に1回（程度）しか実行されませんが、毎回全ての過去データを処理する必要があります[/ja/blog/2020/11/5/毎日-すべてを更新する/]。クライアントに専用の静的な計算リソース[^saas]を割り当てることは非常に非効率です。”
“再び、Lokadでは、完全に相互化されたインフラストラクチャを採用しています。このアプローチにより、クラウドの運用コストを削減しながら、経済的に実現不可能なパフォーマンスを提供しています（クラウドのコストがサプライチェーンの利益を上回る場合）。すべてのワークロードのスムーズな全体的なオーケストレーションを確保するために、私たちは自社の計算リソースの「予測可能性」を高めるように設計しました。LokadのDSL（ドメイン固有のプログラミング言語）であるEnvisionは、この取り組みをサポートするために設計されています。これが、任意のループなどのプログラミング構造のクラスがEnvisionに存在しない理由です。これらの構造は、サプライチェーンのデータ処理に必要な「高い予測可能性」の要件と互換性がありません。”
“結論として、もし供給チェーンシステムが既に適切でない場合、それがすぐに適切になることは期待しないでください。コンピューティングハードウェアはまだ進化し続けていますが、既に十分に高速です。システムが遅い場合、おそらくそれは基盤となるハードウェアと対立しているためであり、ハードウェアが不足しているためではありません。問題を修正することは可能ですが、それは主に「設計」の問題です。残念ながら、エンタープライズソフトウェアの設計段階を過ぎると、コアソフトウェアの設計を修正することはほとんど不可能なことが多いです。しかし、Microsoftのように実証されているように、回復することは可能ですが、それには10年かかるということをすべての企業（ベンダーとクライアントの両方）が負担できるわけではありません。”
“[^incremental]: システムが許可する場合、インクリメンタルなデータの取得を行おうとします。ただし、初期のデータの取得は通常、3〜5年前までさかのぼります。少しの歴史的な深さを持つことは、季節性分析において本当に役立ちます。”
“[^stream]: 2012年に、私はWalmartのトランザクション履歴をバスケットレベルで1年分保存することが可能であり、わずか数百行のコードで実現できることを示すために、小さなオープンソースプロジェクトであるReceiptStreamを公開しました。”
“[^faster]: コンソール端末は時代遅れに見えるかもしれませんが、それらのシステムが数十年も続いていることは、低レイテンシの応答など、かなりの魅力的な特性を持っていた可能性があります。クールでモダンなウェブインターフェースで、ページのリフレッシュに複数秒かかるのは非常にイライラすることです。”
“[^large]: サプライチェーンの最適化においてテラバイトのRAMが便利ではないと言っているわけではありません - ビル・ゲイツに誤って帰せられた「640Kは誰にとっても十分であるはず」という架空の引用を繰り返しています。私のポイントは、計算リソースの不合理な使用は、それらをより良い使い方するための機会の無駄です。2020年12月現在、いわゆる「インメモリ」コンピューティングパラダイムに関連する数値レシピの（洗練されていない）複雑さを考慮すると、そのようなメモリ量が必要な理由は見当たりません。”
“[^softperf]: .NET Core 1、.NET Core 2、.NET Core 3、および.NET 5によってもたらされるパフォーマンスの改善は、ほぼ完全にソフトウェアによるものです。一部の高速化はSIMD命令（単一命令、複数データ）に依存していますが、これらの命令は「将来」のハードウェアとは言い難く、過去10年間に販売されたほとんどのCPUはすでにこれらの機能を備えています。”
“[^hardperf]: Meltdownなどのハードウェアの脆弱性は、既存のコンピューティングハードウェアのパフォーマンスに悪影響を与えることが判明しました。将来的にも同様の問題が予想されます。”
“[^layers]: レイヤーはさまざまな形で存在します。Docker、HDFS、Python、NumPy、Pandas、TensorFlow、Postgres、Jupyterなどはすべて主要な関心事のコンポーネントですが、それぞれのコンポーネントは独自のソフトウェアレイヤーを導入します。”
“[^maintenance]: 2008年にLokadを立ち上げたとき、独自の予測エンジンを作ることにしました。しかし、当時はRが大流行していました。2012年にはHadoopでした。2014年にはPythonとSciPyでした。2016年にはScikitでした。2018年にはTensorFlowでした。2020年にはJuliaです。”
“[^saas]: あるSaaS（Software as a Service）が相互化されたマルチテナントアーキテクチャを利用しているかどうかを特定するための基準は、ある種の無料アカウントに登録できるかどうかを確認することです。ベンダーが無料アカウントを提供できない場合、ベンダーは単にASP（Application Service Provider）を行っているだけであり、SaaSではないとほぼ確実です。”
