Lokadプラットフォームのアーキテクチャ

Lokadのプラットフォームは、マルチテナント対応のクラウドホスト型SaaSソリューションです。このページでは、プラットフォームのハイレベルなアーキテクチャを紹介します。このページはIT担当者向けに作成されていますが、技術に精通したサプライチェーンの実務家にとっても、サプライチェーンの予測最適化に対する当社の技術ビジョンを反映するこのアーキテクチャは興味深いものとなるでしょう。

アーキテクチャ概要

Lokadは、サプライチェーンの課題に対する予測最適化アプリケーションを開発・運用するための環境として位置付けられています。その中核には、Lokadが開発したEnvisionというドメイン固有言語（DSL）が存在します。Envisionはエンドユーザーにも利用可能であり、そのほとんどの機能がこの言語を通じて提供されます。Envisionがプログラミングを意味する一方、LokadはIT専門家やソフトウェアエンジニア向けではなく、サプライチェーンの専門家向けに設計されています。

The Lokad platform is multi-tenant: the same app serves all our clients and it includes a short series of services. The granularity of the split is primarily motivated by diverging requirements in terms of reliability, security, and performance of each service – rather than by a pure functional split. Indeed, the level of coupling that exists between these services is relatively high. These services share the same Git code repository, and they are frequently upgraded together as well.

当社のコードベースは、Microsoftが開発したオープンソースフレームワークである.NETを除き、F#、C#、TypeScriptで実装されており、サードパーティの依存関係はほとんどありません。さらに、.NET自体を除けば、依存関係は通常の約1桁少ない程度です。

このアーキテクチャは、エンタープライズアプリで見られる「通常」のアーキテクチャとは大きく異なっており、その理由は十分にあります。一般的なエンタープライズアプリは、重く広範な依存関係に依存しており、各依存関係は通常100万行以上のコード量を持ちます。しかし、Lokadは以下の分野においてサードパーティの依存関係がありません：

リレーショナルデータベース：その代わり、イベントストアとコンテンツアドレス化ストアを使用しています。
キャッシングシステム：その代わり、計算と一時ストレージを同居させています。
パイプラインマネージャー：その代わり、専用のスケジューラを導入しています（以下詳細）
分析エンジン：その代わり、EnvisionというDSLが分析機能を提供します。
機械学習ツールキット：その代わり、DSL自体が機械学習の機能を提供します。
データ可視化ツールキット：その代わり、DSLと緊密に統合された独自機能を展開しています。

なお、当社はプラットフォームの開発を大部分内製化している一方で、暗号アルゴリズムなどのすべてのセキュリティコンポーネントについては、意図的かつ排他的にサードパーティコンポーネントに依存していることに留意してください。

フロントエンド

フロントエンドとは、Lokadとの間でデータの送受信に使用される自動エージェントを含む、エンドユーザーがアクセス可能な要素を指します。これらのほとんどの操作はHTTPSを介したウェブブラウザ経由で行われますが、Lokadはファイル転送のためにFTPSおよびSFTPプロトコルもサポートしています。

go.lokad.com

このサービスは、シングルページアプリケーション（SPA）として実装されたLokadのウェブアプリのフロントエンドフレームワークであるReactをホストしています。このフロントエンドは、他のサービスが提供するAPI（アプリケーションプログラミングインターフェース）に依存しています。

このサービスは静的コンテンツ―主にJavaScript―のみを提供します。サーバーサイドに動的な部分はなく、特にデータ永続化も行いません。この設計は、稼働時間がこのサービスにとって最重要であるために意図されたものです。ウェブ経由でどのサービスにアクセスされても、go.lokad.comは常に利用可能でなければなりません。

ダッシュボード

名前が示す通り、ダッシュボードサービスは、Lokadが提供するウェブ分析ダッシュボードのレンダリングを担当します。

各ダッシュボードは、実行されたEnvisionスクリプトの結果として生成されます。ダッシュボードは大部分が事前計算されていますが、いくつかのインタラクティブな機能も提供されます。Envision自体の設計により、元のデータセットの大きさにかかわらず、クライアントサイドの操作は常に少量データの問題にとどまります。

クライアントサイドでは、ダッシュボードの最初のレンダリングに必要なすべてのデータが1回のHTTPSリクエストで取得されます。この単一リクエスト設計は、レイテンシのオーバーヘッドを最小限に抑えるためのものです。バイナリパックおよび圧縮により、帯域幅の使用量も最小化されます。

サーバーサイドでは、特定のダッシュボードに関連するデータがコンテンツストアによってパックされます。再度申し上げますが、パッキングはネットワークリクエストの総数を非常に低く抑えるために不可欠であり、通常はダッシュボードの複雑さに関係なく6リクエスト未満に留められます。

インタラクティブなダッシュボードは、エンドユーザーに対して、ブラウザで転送・表示可能な範囲を超える大規模なデータセットにアクセスする機能を提供します。ビュー間の切り替えは、クライアントサイドで最大1回（サーバーサイドではごくわずか）のリクエストで実現されます。

Lokad vs 主流

Lokadの一定のレンダリング時間設計は、主流のビジネスインテリジェンス（BI）やその他の分析ツールとは異なります。そのようなツールで見られるダッシュボードは、常にタイル（ブロックまたはウィジェットとも呼ばれる）のリストで構成されています。これらのタイルを処理する標準的な方法では、タイルごとに1回のクライアントサイドリクエストと、不特定で保証されない数のサーバーサイドリクエストが必要となります。残念ながら、この設計は各タイルごとに顕著な遅延を招き、すべてのダッシュボードタイルの表示完了に数秒を要することがしばしばあります。

Lokadは、Envisionコンパイラがダッシュボードのレンダリングに使用されるデータのパッキング戦略を生成することで、この問題を解消し、クライアントサイドでは一桁、サーバーサイドではさらに少ないリクエスト数を実現しています。我々の見解では、ダッシュボードのパフォーマンスは、ダッシュボードを支えるスクリプトのコンパイル時から始まります。

さらに、ほとんどの分析ツールは、計算の大部分をダッシュボード（またはレポートと呼ばれる場合もある）の要求まで遅延させます。残念ながら、この設計は、全エンドユーザーに対して共有されるサーバーサイドの計算リソースに避けがたい競合を生み、同時接続エンドユーザー数が増えるとパフォーマンスの問題を必然的に引き起こします。

Lokadは、ダッシュボードを事前計算することで、この問題を大幅に緩和しています。我々の設計は、エンドユーザーの要求に応じてダッシュボードを提供するために必要なサーバーサイドリソースを最小限に抑え、ダッシュボードデータの提供において主たる（意図された）ボトルネックとしてコンテンツストアを残しています。この設計により、非常に多くのエンドユーザーに対しても、パフォーマンスの低下を最小限に抑えながら同時にダッシュボードを提供することが可能となります。

プロジェクト

The projects service manages scripts and batch jobs (called sequences). This service features a hierarchy of projects. End-users, who have the proper access rights, can view, edit, and run projects. A bespoke predictive optimization app implemented by Lokad typically includes a list of projects.

イベントソーシングを利用してユーザーの入力を永続化し、ここで詳述するイベントストアを活用しています。サービスに対して発行されるすべてのコマンドやインタラクションは記録され、それに対応するイベントへと変換されます。ユーザーインターフェースは、すべてのイベントを集約して得られた状態を表示します。このアプローチはCQRS+ESパターンとして知られています。CQRSはCommand and Query Responsibility Segregationの略であり、ESはEvent Sourceの略です。

CQRS+ESパターンは、アプリケーションに導入されたすべての変更の完全な履歴管理を設計上提供します。Lokadの場合、アカウント内に存在するすべてのEnvisionスクリプトに対して、Gitのようなバージョン管理を実現しています。

Lokad vs 主流

UIおよびUXの面では、プロジェクトサービスは主流のアプローチに従っています。しかし、内部では、ほとんどのエンタープライズソフトウェアで採用されるCRUD（作成、読み取り、更新、削除）の代替としてCQRS+ESパターンが採用されています。このパターンは、リレーショナルデータベースをイベントストア（以下で説明）に置き換えます。

CQRS+ESアプローチは、CRUDパターンに比べて多くの利点を提供します。例えば、意味論の優位性、監査可能性の向上、そしてLokadの場合、Envisionソースコードの保存および取得に用いる永続化戦略を大幅にカスタマイズできるため、パフォーマンスの向上が見込まれます。実際、プロジェクトサービスで永続化されるデータの大部分はEnvisionソースコードで構成されています。

コード

コードサービスは、Envision言語専用のIDE（統合開発環境）を備えています。このウェブベースのIDEは、コードの強調表示、自動補完、変数名の変更など、最新の開発環境に期待されるあらゆる機能と利便性を、静的コード解析を通じて提供します。

コードサービスの複雑さの大部分は、各キーストロークごとに自動補完のヒント、エラー、またはコードアクションをリアルタイムで提供する言語サーバーバックエンドに起因します。特に、この機能において低レイテンシを維持することが主要な技術的課題であり、通常のキーボード操作の速度を考慮すると、遅延が非常に目立つ可能性があります。

ファイル

Lokadの各アカウントには、ファイル保存用の専用スペースが設けられています。ファイルサービスは、分散型のバージョン管理されたファイルシステムを備えており、ファイルの管理に使用されます。このファイルシステムは、ウェブインターフェースおよびSFTPやFTPSプロトコルを通じてアクセス可能です。概念的には、ギガバイトサイズのフラットファイルを対象とする点を除いて、Gitリポジトリに非常に似ています。

ファイルのバージョン管理は、ファイルシステム自体の進化を反映する一連の「コミット」の提示を補完するCQRS+ESパターンによって保証されます。ファイル内容の永続化は、コンテンツアドレス化ストア（以下で説明）によって実現されます。

コード（Envisionスクリプト）とデータの両方をバージョン管理することで、Lokadはプラットフォーム上に展開されたサプライチェーンアプリの過去の挙動を完全に再現可能にします。サプライチェーンの視点から、この機能は、サプライチェーンアプリによって生成されたあらゆる異常な結果のトラブルシュートにおいて重要です。

Lokad vs 主流

ファイルサービスは、Envision言語（正確性向上）、Envision IDE（生産性向上）、およびEnvisionランタイム（パフォーマンス向上）と密接に統合されています。これらの利点は、カーネルの補助として機能する汎用ファイルシステムでは到底実現が困難です。

さらに、ファイルサービスの多くの利点は、汎用ファイルシステムが持つ機能を抑制することで得られています。例えば、ファイルサービスでは、複数のプロセスによる同時更新が許可されません。このような機能は、サプライチェーンアプリの特定の文脈において、価値提供と引き換えにサプライチェーン実務家をIT中心の問題や複雑さに晒すだけです。

アカウント

アカウントサービスのアイデンティティおよびアクセス管理（IAM）は、Lokadの中でも最も主流な部分の一つです。Lokadのアカウント、ユーザー、認証（理想的には委任認証）、およびユーザーがLokadアカウント上で実行可能な操作を制御するACL（アクセス制御リスト）を管理します。

このサービスはCQRS+ESパターンも活用しており、IAMの性質上常にセキュリティ上敏感なすべての操作の完全な監査ログを提供します。イベントソースを監査ログとして使用することで、特定のイベントが記録されないことによる監査ログの危殆化など、セキュリティ上の問題も一括して排除されます。

永続化層

その名の通り、永続化層はLokadによって管理されるすべてのデータの永続性を保証します。これらのデータは大きく2種類に分かれます。1つは、クライアントがLokadにアップロードするか、またはEnvisionスクリプトによって生成されるファイル、もう1つは、ユーザー操作（ファイルアップロードスクリプトなど自動エージェントを含む）から生じるイベントです。Lokadは、Azure Blob Storageをキー・バリュー型ストアとして利用し、両方のデータタイプを永続化します。

イベントストア

イベントストアは、Lokadプラットフォームのすべてのサービスによって生成されたイベントを永続化します。このストアは、Lokadの状態遷移データベースを表しています。私たちは、イベントストアのソースコードをオープンソースとして公開しています。

このコンポーネントはシンプルで、基盤となる分散型キー・バリュー・ストア（Azure Blob Storage）を活用して、信頼性の高い方法でイベントを永続化し提供するだけです。イベントは小さいことが想定されており、上限は512kBですが、通常は1kB未満です。

ストリーミング分析やプロジェクション管理などの「スマート」な機能はありません。不要な機能を排除することで、Lokadは永続化層の持つ機能に起因するSQLインジェクション攻撃などの問題を初め、関連する多くの問題を排除しています。

コンテンツアドレス化ストア

コンテンツアドレス化ストア（CAS）は、Lokadプラットフォームにアップロードされた、またはEnvisionスクリプトによって生成されたファイルを永続化します。私たちは、コンテンツアドレス化ストレージのソースコードをオープンソースとして公開しています。

CASは、通常数MBの大容量ファイルをサポートし、最大100GBまで対応することを目的としています。CASは、列指向ストレージ戦略に基づいてシャーディングされたファイルまたはファイル断片を保存するために使用され、列指向ストレージは実行層のアクセスパターンに調和しています。

実行層

その名の通り、実行層はLokadプラットフォーム内でのEnvisionスクリプトの実行を保証し、一連のコンポーネントで構成されています。簡潔にするため、ここでは最も注目すべきもののみを列挙します。コンパイラはEnvisionスクリプトを分散仮想マシン向けの命令に変換します。スケジューラは、Envisionスクリプトの実行、スケジュール、およびシーケンスをトリガーするためのユーティリティサービスです。ThunksはEnvision仮想マシンのコードネームです。最後に、IonicはEnvision仮想マシンによって生成および使用される列指向ストレージ戦略の名称です。

コンパイラ

コンパイラは、Lokadプラットフォームの分散仮想マシン（以下「Thunks」と呼ばれる）向けのバイトコードにEnvisionスクリプトを変換します。このコンパイラのアーキテクチャは、パースから始まり、一連の内部表現間の変換を経て、最終的にバイトコードを生成するという、主流の設計手法に則っています。

言語サーバーバックエンドは、Envisionソースコードとのやり取り（上記のCodeサービス参照）を案内する役割を担っており、コンパイラの一部でもあります。言語サーバーは、コーディング中のEnvisionプログラマーに有意義なフィードバックやエラーメッセージを提供するために状態を保持しています。ほとんどのキー入力後はスクリプトがまだ有効なEnvisionスクリプトではありませんが、それでも言語サーバーの状態によって意味のあるフィードバックが提供されます。

スケジューラー

スケジューラーは、手動の介入なしにEnvisionスクリプトを実行するためのユーティリティサービスです。スケジューラーはEnvisionスクリプトの実行をトリガーし、スケジュールし、シーケンス化します。また、実行が予期されたタイムラインから逸脱した場合にはアラート機能も提供します。プラットフォームの他の部分との緊密な統合により、例えばファイル受信時にEnvisionスクリプトを起動するファイル変更トリガーや、シーケンス内のEnvisionスクリプトがコンパイルされなかった場合の早期故障検出など、一連の望ましい機能が実現されています。

Thunks

Thunksは、Lokadの分散仮想マシンのコードネームです。実際、Envisionスクリプトはネイティブに分散実行の恩恵を受けています。この点で、Envisionコンパイラは単一のマシンではなく、クラスタ全体を対象としています。この機能は、大規模なデータセットを迅速に処理するために極めて重要です。Envision言語は、自動並列処理のために特別に設計されており（これは一般的なプログラミング言語では実現が非常に難しい機能です）、なおかつ一台のマシンが応答しなくなった場合でも、クラスタ全体でスクリプト実行の信頼性を向上させます。

Thunks専用のマシンのクラスタは、すべてのアカウントでマルチテナント方式により共有されています。この機能は、コンピューティングコストを抑制する上で不可欠です。典型的なサプライチェーンのユースケースでは、1日に1回の実行バッチが行われ、通常は60分未満で完了します。マルチテナントによるリソースの共有により、通常24時間単位で課金される計算リソースのオーバーヘッドが大幅に軽減され、実際には1時間（あるいはそれ以下）しか利用されない状況に対応できます。

詳細な説明については、Envision仮想マシンに関するVictor Nicolletの全4回にわたるシリーズを参照してください。また、パフォーマンスに関する一般的なLokadの質問に対する回答として、Security FAQのセクション8をお勧めします。