サプライチェーン向けのリーンでスケーラブルな処理

Joannes Vermorel

約10年以上前にクラウドコンピューティングが登場して以来、必要な時に必要なだけ（ストレージ、計算、ネットワークなど）のコンピューティングリソースをオンデマンドで取得することが容易になりました ― 支払いを厭わなければの話ですが。しかし、好きなクラウドコンピューティングプラットフォーム上で大規模な計算を行うことが容易であっても、そのコストに見合うかどうかは別問題です。

Lokadでは、クライアントに対してストレージ1GBあたりやCPU1時間あたりの料金を請求することはありません。むしろ、プロフェッショナルサービスを選択する際の価格設定の主な要因は、そもそも対処すべきサプライチェーン課題の複雑さにあります。当然、クライアントにサービスを提供するために必要なコンピューティングリソースも価格に反映させていますが、最終的には、Microsoft Azureに支出する1ユーロ ― 経費上、我々は「本物の」エンタープライズクライアントになったとも言えますが ― は、研究開発やアカウントを担当するサプライチェーン-サイエンティストに回すことができないユーロなのです。

したがって、Lokadのソフトウェアプラットフォームは、コンピューティングリソースの使用を可能な限り抑えるという基本理念¹のもとに設計されています。問題は1TBのデータを処理すること自体ではなく、1TBのデータをできるだけ低コストで処理することにあります。この方針に基づき、Lokadの設計においていくつかのやや「異例」の決断が下されました。

実行グラフの差分計算。 サプライチェーン・サイエンティストは、他のデータサイエンティストと同様に、まずはデータに対してコードを検証するために何百行ものコードを一度に書くことはほとんどありません。通常のプロセスは非常に漸進的であり、数行を追加してはデータを処理し、そのサイクルを繰り返します。これらの反復は、データから得られる結果が次に行うべき処理を導くために必要です。しかしながら、ほとんどのデータサイエンスツール（例：NumPy や R）は、スクリプトが再実行されるたびに全てをゼロから再計算します。対照的に、Envisionは連続する実行グラフ間での差分を計算します。従来のdiffがファイル間の違いを見つけるのに対し、我々のdiffは計算グラフ間の違いを見つけ出し、新たに計算が必要なノードを特定します。他の全てのノードについては、既に計算済みの結果が「再利用」されます。サプライチェーン・サイエンティストにとって、実行グラフの差分計算は、数テラバイトのデータが数秒で処理される超高速な実行のように見えます（補足：実際、Lokadが数テラバイトを数秒で処理したのではなく、スクリプトごとに異なった数百メガバイト程度のデータのみが処理されたにすぎません）。

ドメイン駆動のデータ型。 確率的-予測-定義は、サプライチェーンに革命をもたらすアプローチです ― 一つの未来が必ず実現するかのように一つの未来を選ぶのではなく、あらゆる可能な未来を考慮に入れます。残念ながら、確率分布を処理するには、非自明な計算を伴う分布代数が必要となります。そこで、ランダム変数に対する大規模な演算を最小限のCPUコストで実行するために、この代数の最適化に大きな労力を投じました。特に、サプライチェーンにおいてほとんどのランダム変数は、通常は数十単位程度のごく小さい確率を表すという事実を積極的に考慮しています²。一般的な科学計算向けの手法と比べ、ドメイン固有のアプローチは計算速度を2桁向上させます。

ディフェンシブなスケーラビリティ。 大規模データ処理向けに設計された多くのプログラミング言語（例：ScalaやJulia）は、多数のノードに計算を分散する驚異的な機能を提供します。しかし、これは書かれるコードの各行が、任意に大きなコンピューティングリソースを消費する可能性を秘めていることも意味します。アプリケーションに対する要求が変更と共に増大していく中で、その需要に対抗するためには高度なエンジニアリングの規律が必要です。対照的に、Envisionは_ディフェンシブ_な立場を取っています。つまり、スケールアップに極めて高いコストがかかるコードをサプライチェーン・サイエンティストが書くのを防ぐように言語設計されています。このため、Envisionにはループが存在しないのです ― 言語に任意のループが含まれる場合、コンパイル時に予測可能なパフォーマンスを提供することはほぼ不可能だからです。

キー・バリュー型ストレージのみ。 Blob Storage³は、クラウド上で提供される最もベアメタルに近いコスト効率の良いデータストレージ手法であり、1TBあたり月約20ドル程度という低価格が実現可能です。LokadはBlob Storage（キャッシュ用のローカルディスクも含む）を直接操作しており、リレーショナルデータベースやNoSQLは使用していません ― 自社でBlob Storage上に構築したものを除いて。実際、当社のストレージ層は、Lokad内での最適化専用の言語であるEnvisionと、量的-供給-チェーン-マニフェストと深く統合されています。これにより、アプリケーションとデータアクセス層の境界に従来存在していたオーバーヘッドの層を回避することが可能となりました。境界での摩擦を微細に最適化する代わりに、これらの境界を完全に取り除いたのです。

大規模なサプライチェーンにおいては、リーンでスケーラブルなデータ処理の実現は「些細な問題」に見えるかもしれませんが、テラバイト単位のデータ処理に伴うITオーバーヘッドは現実の問題です。システムが高価すぎたり遅すぎたりすることは頻繁にあり、その結果、本来享受すべき利益の大部分が摩擦として失われてしまいます。クラウドコンピューティングのコストは依然として低下傾向にありますが、年間20%を大きく超える低下は期待しにくいため、コンピューティングハードウェアの一般的な進歩に任せるのは、データ駆動型のサプライチェーンの実現をさらに10年遅らせる覚悟がなければ現実的な選択肢とは言えません。

また、Lokad TVで制作したサプライチェーンのためのテラバイトスケーラビリティに関するエピソードもご覧いただけます。