クラウドコンピューティングの登場から10年以上が経ち、必要なときにコンピューティングリソース(ストレージ、計算、ネットワーク)をほぼ任意のスケールで獲得することは、支払いをする覚悟がある限りは簡単になりました。ただし、選択したクラウドコンピューティングプラットフォームで大規模な計算を実行することは簡単であるということは、それがコストに見合う価値があるということを意味するわけではありません。

データの山々

Lokadでは、ストレージのGB単位やCPUの時間単位でクライアントに料金を請求することはありません。代わりに、プロフェッショナルサービスを選択した場合、価格設定の主な要素は、まず最初に対処する必要のあるサプライチェーンの課題の複雑さです。当然、クライアントにサービスを提供するために必要な計算リソースは価格に反映されますが、最終的には、Microsoft Azureに費やすすべてのユーロは、R&Dやアカウントの管理を担当するサプライチェーンサイエンティストに費やすことができないユーロです。

したがって、Lokadソフトウェアプラットフォームは、計算リソースに関してできるだけリーンであるべきという指針の下で設計されました1。課題は1TBのデータを処理することではなく、できるだけ安価に1TBのデータを処理することです。これにより、Lokadの設計中にいくつかの「異例の」決定が生まれました。

差分実行グラフ。 サプライチェーンサイエンティストは、他のデータサイエンティストと同様に、通常、データに対してコードを数百行書いてからコードをデータに対してテストします。このプロセスは通常、非常に段階的です。数行追加し、データを処理し、繰り返します。これらの反復は、データから得られる結果がデータサイエンティストが次に行う作業をガイドしているため必要です。しかし、ほとんどのデータサイエンスツール(例:NumPyR)は、スクリプトが再実行されるたびにすべてをゼロから再計算します。対照的に、Envisionは連続する実行グラフの差分を実行しています。従来の差分はファイル間の違いを見つけるのに対して、私たちの差分は計算グラフ間の違いを見つけます。差分は新しい計算ノードを特定し、まだ計算されていないノードを特定します。他のすべてのノードでは、結果はすでに計算されており、再利用されます。サプライチェーンサイエンティストにとって、実行グラフの差分を取ることは、テラバイト単位のデータが数秒で処理される超高速な実行のように見えます(ヒント:Lokadはテラバイトを数秒で処理しませんでした。次のスクリプトと異なる数百メガバイトのみが処理されました)。

ドメイン駆動型データ型。 確率的予測は、サプライチェーンにとってゲームチェンジングなアプローチです。確実に実現すると保証された1つの未来を選ぶのではなく、すべての可能な未来を考慮に入れましょう。残念ながら、確率分布を処理するには、非自明な計算を伴う分布の代数が必要です。したがって、私たちはこの代数を最適化するために多大な努力を払い、ランダム変数に関する大規模な操作を最小限のCPUコストで実行できるようにしました。特に、サプライチェーンでは、ほとんどのランダム変数が通常数十個の単位で確率を表すことを積極的に考慮しています2。科学計算などを対象とした一般的なアプローチと比較して、ドメイン固有のアプローチにより、計算速度が2桁向上しました。

防御的なスケーラビリティ。 大規模なデータ処理を目的としたほとんどのプログラミング言語(ScalaやJuliaなど)は、多くのノードに計算を分散するための非常に優れた機能を提供しています。しかし、これは書かれたコードの各行が任意の大量の計算リソースを消費する可能性があるということを意味します。アプリケーションに変更が加わると、アプリケーションのニーズが seemingly ever increasing に対抗するために、多くのエンジニアリングの規律が必要です。対照的に、Envisionは「防御的」な姿勢を取っています。言語は、スケーラビリティに非常に高いコストがかかるコードをサプライチェーンサイエンティストから遠ざけるために作成されました。そのため、Envisionにはループがないのです。なぜなら、言語に任意のループが含まれている場合、コンパイル時に予測可能なパフォーマンスを提供することはほぼ不可能だからです。

キーバリューストレージのみ。 Blobストレージ3は、クラウド上で提供される最もベアメタルでコスト効率の高いデータストレージアプローチであり、価格は1TBあたり月額約20ドルまで低下しています。LokadはBlobストレージ(キャッシュ用のローカルディスクを含む)を直接操作しており、リレーショナルデータベースやNoSQLは使用していません(ただし、Blobストレージの上に独自に構築したものはあります)。実際には、当社のストレージレイヤーは、Lokad内の量的サプライチェーン最適化に特化した言語であるEnvisionと深く統合されています。これにより、アプリケーションとそのデータアクセスレイヤーの交差点に伝統的に存在するオーバーヘッドのレイヤーを回避することができます。境界の摩擦を微調整する代わりに、私たちはそれらの境界を完全に取り除きました。

サプライチェーンのためのリーンでスケーラブルなデータ処理を実現することは、規模の大きなサプライチェーンにとっては「技術的な問題」のように思えるかもしれませんが、テラバイトのデータを処理するためのITオーバーヘッドは実際に存在します。システムが高すぎるか、遅すぎる場合があり、その摩擦が最初にシステムが生み出す意図された利益の大部分を食い尽くしてしまいます。クラウドコンピューティングのコストはまだ減少していますが、年間20%以上の削減は期待できません。したがって、データ駆動型のサプライチェーンをさらに10年以上遅らせるつもりでない限り、コンピューティングハードウェアの一般的な進歩に任せることは実際には選択肢ではありません。

Terabyte Scalability for Supply Chains で制作したLokad TVのエピソードもご覧いただけます。


  1. コンピューティングリソースを販売しているエンタープライズソフトウェアベンダーは、通常、逆のインセンティブを持っています。消費されるリソースが多ければ多いほど、彼らの収益も増えるのです。20年前、IBMはMIPS(1秒あたりの百万命令)の課金に悩まされていました。これは、IBMがエンタープライズシステムのパフォーマンスを微調整するインセンティブがほとんどなかったため、問題が頻繁に発生しました。この問題は、IBMが(ほとんど)MIPS価格設定から離れたことでほとんど解消しました。 ↩︎

  2. SKUが数百万あると、各SKUが数百万回の在庫移動に関連付けられているのは難しいです。数百万のSKUがある場合、その大部分は月に数ユニットしか動かさないスロームーバーです。逆に、1日に数百万のユニットを動かすSKUがある場合、そのSKUは100個以上ある可能性はほとんどありません。 ↩︎

  3. AzureのBlobストレージは、シンプルなキーバリューストレージです。ほぼすべてのクラウドベンダーが同様のサービスを提供しています。Amazonは、S3サービスでこのドメインを先駆けました。GoogleはこのサービスをCloud Storageと呼んでいます。 ↩︎