サプライチェーンシステムの偶発的な複雑性

Joannes Vermorel

現代の computing hardware は非常に高性能です。控えめなスマートフォンでも、数十億のFLOPS（1秒あたりの浮動小数点演算）を実行し、数百ギガバイトのデータを記憶できます。1台のスマートフォンで、非常に大規模な小売ネットワークのための予測的な inventory allocation を技術的には実行可能です。過去のデータは適切な表現¹を必要とし、データ解析側では differentiable programming のようなより効率的な技法が用いられるはずです。したがって、高性能なサプライチェーンシステムは当然のこととして存在すべきです。もちろん、企業はサプライチェーンの運用と最適化のために、スマートフォンよりも一段上のものを導入できるはずです。しかしながら、Lokadで顧客のサプライチェーンシステムをざっと観察すると、その実態はまったく逆であり、これらのシステムはほぼ常に遅く、しばしば torturously と言えるほど遅いのです。

現代の supply chain software のリーダー企業（ERP、WMS、MRP など）は、APIバックエンドで1秒あたり1リクエストを維持するのすら困難です。Lokadでは、data retrieval プロセスの最前線にいるため、そのような酷いパフォーマンスを日々痛感しています。約十数社の顧客に対して、初回のデータ取得にほぼ1ヶ月かかりました²。様々なAPIの鈍さが問題の99.9%を占めています。1MB/秒での data extraction が可能なシステムは極めて稀です。同じデータを何度も無駄に再抽出する必要がなく、最新の部分にたどり着けるシステムはなおさら稀です。これらのシステムは、通常20年前と比べて100倍以上の計算資源が利用可能でありながら、根本的に速くなっているわけでもなく³、また画期的に改善されているわけでもありません。in-memory computing を活用する最先端のベンダーの中には、小売ネットワークに対応するために数テラバイトのRAMを必要とするものもあり、これはそれらの資源で行われる処理内容を考えると非常に莫大な量です⁴。

多く（もしくはほとんど）のサプライチェーンシステムに見られるこの「偶発的複雑性」は、二つの根本原因に起因します。第一に、計算ハードウェア自体の進歩に対する誤った期待、第二に、ソリューション内部の設計に対する配慮の欠如です。

計算ハードウェアの進歩について言えば、10年前までは、最初の Moore’s law すら多くの（大手の）企業で何十回も（たいていは誤った形で）唱えられていました。常にコンピュータは途方もなく速くなっているという感覚がありました。残念ながら、2000年代初頭以降、これはもはや 単純に 真実ではなくなりました。この無限の進歩に対する誤った認識は、サプライチェーンの分野を超えて多くのソフトウェア企業に大きな過ちを犯させました。2006年にリリースされたWindows Vistaに関連する多くの問題は、2001年にWindows XPがリリースされた当時、MicrosoftのエンジニアがCPUが2006年までに6GHzで動作するだろうと期待していたことに起因します。2020年末が近づく今、高性能ゲーミングCPUはほとんど5GHzに届いていません。計算ハードウェアの進歩は止まっていませんが、ソフトウェア企業にとっては、進歩が 単純に 進むという状況が止まってしまったのです。

1980年代や1990年代には、ソフトウェアが動作すれば、たとえリリース当時はやや遅くても、翌年にはその速度がまずまずになり、その翌年には非常に高速になることが当然視されていました。Microsoft のような攻めの姿勢を持つソフトウェア企業はこのカードを見事に活用していました。彼らのエンジニアは（現在もなお）金で買える最高の計算ハードウェアを与えられ、ハードウェアが1、2年以内にパフォーマンスの問題を本質的に解決してくれるという認識のもと、ソフトウェアの性能を許容範囲の限界まで体系的に追求していました。Vista騒動の後、Microsoftのエンジニアリングチームは問題の深刻さに気づき、手法を一新しました―Windows 7は大幅な改善をもたらしました。しかし、Windowsがパフォーマンス面で真に回復するまでには10年かかりました。今日では、状況はほぼ正反対となり、Microsoftの最優秀チームはもはや将来のハードウェアに依存せず、ほぼ専ら優れたソフトウェアによって即時に卓越したパフォーマンスを提供することに注力しています⁵。

しかし、エンタープライズソフトウェアの世界はこの問題に気づくのが非常に遅れ、過去になに度も見られたように、将来の計算ハードウェアがすべての問題を解決するかのように2010年代にソフトウェアを開発し続けました。残念ながら、ほとんどのエンタープライズソフトウェアベンダーにとって、計算ハードウェアは依然進歩しているものの、10年前には、ハードウェアが 些細な 形で進歩するのをただ待つだけでは済まなくなっていました⁶。ソフトウェアは時間とともに不要な機能（クルフト）を蓄積しがちです（機能、オプション、画面などが増える）。そのため、複雑なソフトウェアは、特別な集中対策がなければ、改善されるどころか時間とともに遅くなるのが自然な傾向です。

残念ながら、営業面から見るとパフォーマンスはほとんど問題になりません。デモは、実際の運用環境でシステムが直面するデータ負荷の極めて僅かな部分しか含まないおもちゃのアカウントで行われます。また、経営陣が注目する画面は、一般従業員向けの画面に比して過剰に磨き上げられます。しかし、後者の画面こそが1日に何千回も利用されるため、最も注意を払うべきなのです。私は、買い手がAPIが本来の目的に沿ったパフォーマンスを実際に発揮しているかどうかを調査しないため、APIがしばしば酷いパフォーマンスを示すのだと考えています。ソフトウェアベンダーはこれを熟知しており、それに応じてエンジニアリング投資を行っています。

ここでパフォーマンス問題の第2の側面、すなわちソリューション内部の設計に対する配慮の欠如に触れます。現状では、進行中のハードウェアの向上の大部分を活用するには、戦略的な software design decisions が必要です。しかし、設計上の決定は両刃の剣であり、能力を引き出すと同時に制限ももたらします。ビジネス面と技術面の双方で、その決定にコミットするには強いリーダーシップが必要です。優柔不断であることは容易ですが、その反面、大多数のエンタープライズソフトウェアが示すように、パフォーマンス（およびUX全般）が大きく損なわれます。

現代のソフトウェア（エンタープライズ向けに限らず）の落とし穴の一つは、layers の過剰な存在です。データはソフトウェア内部の何十ものレイヤーを通じて、コピーされ、パイプされ、プールされ、同期される…その結果、計算資源の大部分が、実際には何の付加価値も生み出さない「内部配管」の処理に浪費されます。設計という観点では、解決策は考案するのは簡単ですが実行するのは困難です。特にレイヤーを伴う第三者コンポーネントの使用は控えめにすべきです⁷。ソフトウェアベンダーの視点では、もう一層追加するのが、製品に「クールな機能」を追加する最速の方法なのです（冗長性は別として）。

Lokadでは、コンパイラーコアを中心にプラットフォーム全体を設計することで、徹底した統合スタックを採用しています。その反面、ランダムなオープンソースプロジェクトを容易に自社設計に組み込む選択肢を失っています。統合は可能ですが、通常はコンパイラー自体により深い変更が必要となります。しかし、そのおかげで、エンタープライズソフトウェアとしては unthinkable と言われるほどの「ベアメタル」パフォーマンスを実現しています。全体として、オープンソースコンポーネントの老朽化を考慮すると、このアプローチは過去10年間で特に効果的であることが証明されています⁸。

共用のマルチテナンシーは、少なくとも「費用対効果」の観点から、パフォーマンスに劇的な影響を与えるもう一つの設計選択です。ほとんどのエンタープライズソフトウェア―サプライチェーンソフトウェアもその一つ―は、計算資源の需要が極めて断続的です。例えば、スペクトルの極端な例として、予測の numerical recipe が挙げられます。これは一日に一度（またはその程度）しか実行されませんが、毎回、全ての過去データを処理しなければなりません。クライアントに専用の静的な計算資源を割り当てるのは非常に非効率です⁹.

再び、Lokadでは完全に共用されたインフラストラクチャを採用しています。このアプローチにより、クラウド運用コストを削減しつつ、さもなければ経済的に実現不可能なパフォーマンス（クラウドコストがサプライチェーンの利益を上回る状況）を実現できます。すべてのワークロードの円滑なオーケストレーションを確保するために、私たちは自社の計算資源消費に対して高い「予測可能性」を実現するよう設計しました。LokadのDSL（ドメイン固有プログラミング言語）であるEnvisionは、この取り組みを支援するために設計されています。これが、Envisionにおいて任意のループなどのプログラミング構造が存在しない理由です―それらの構造は、サプライチェーンのデータ解析が要求する「高い予測可能性」と両立しないためです。

結論として、もしすでに効率的でなければ、肥大化したサプライチェーンシステムがすぐに効率的になるとは期待しないでください。計算ハードウェアは依然進歩していますが、すでに十分高速です。システムが遅い場合、その原因はハードウェア自体が不足しているのではなく、むしろハードウェアと相反する動作をしているからです。問題の解決は可能ですが、主に design（設計）の問題です。残念ながら、エンタープライズソフトウェアでは、製品の設計段階を過ぎるとコアなソフトウェア設計がほぼ修正不可能になりがちです。Microsoftが示したように回復は可能ですが、すべての企業（ベンダー、クライアント双方）がその10年を費やす余裕があるわけではありません。