FAQ: 情報技術 (IT)

The Lokad appはSaaS（サービスとしてのソフトウェア）として提供されるウェブアプリです。Lokadの目的は、予測分析を提供し、サプライチェーン（より良い在庫管理、より良い価格設定など）の最適化を図ることにあります。Lokad appは、ERP、WMS、CRMなどの取引システムと並行して動作する分析レイヤーとして設計されています。通常、月額定額料金で提供され、アプリ本体とプロフェッショナルサービスがパッケージとなっています。これらのプロフェッショナルサービスは、Lokadのエンジニア（サプライチェーンサイエンティスト）によって提供され、この範囲におけるIT部門自体からの技術サポートの必要性をほぼ完全に軽減します。IT部門に期待される主な貢献は、SFTPまたはFTPSを用いてフラットファイルをLokadに送るデータパイプラインの設定と、生成された結果の再統合の可能性です.

対象読者: IT部門
最終更新日: 2023年11月30日

技術的概要

Lokad appはマルチテナントです。各テナント（すなわちクライアントアカウント）には専用のファイルシステムと専用のコードベースリポジトリが割り当てられています。このファイルシステムはFTPS、SFTP、及びウェブインターフェースを通じてアクセス可能です。ファイルシステムは、ファイルごとに最大100GBに及ぶ大容量のフラットファイルに対応しており、Gitのようなデータバージョン管理機能を備えています。コードベースリポジトリはEnvisionスクリプトのホストに使用されます。EnvisionはLokadが開発した専用DSL（ドメイン固有のプログラミング言語）であり、予測最適化のユースケースに特化しています。Envisionスクリプトは、機械学習アルゴリズムやソルバーを含む主要な数値解析を実行し、情報量豊富なダッシュボードを生成するために用いられます.

このアプリは火曜日の10:00から14:00（パリ時間）までに完全に再展開されます。ダウンタイムは通常5分未満に維持され、すべてのバージョン管理に関する問題はLokadが完全に管理します.

IT部門がLokadのスタックに関する特定のスキルを習得することは求められていません。しかし、興味がある場合は、完全な技術文書をご参照ください.

ITの貢献概要

IT部門には、SFTPまたはFTPSを使用して、関連するフラットファイル抽出をLokadに送信するデータパイプラインを設定していただくことを期待しています。抽出はERPなどの取引システム上で行われます。フィルタ、結合、変換を伴わない生のテーブル抽出が非常に好ましく、最小限の労力で済みます。ETLの観点からは、最もシンプルな「抽出(E)」、つまり単純なコピーのみが求められます。フォーマットに関して、Lokadは合理的なタブ状のフラットファイルすべてに対応しています.

データパイプラインは少なくとも毎日自動的に実行されることが想定されています。IT部門の作業量は、データ抽出の範囲（どのシステム、どのテーブルか）に依存しますが、一般的には大企業でも約15〜45人日程度の作業が必要です。一度パイプラインが整えば、IT部門による監視は月に1〜2人日程度で済むのが通常です.

セキュリティ概要

このアプリはEU内に位置するMicrosoft Azureのデータセンターでホストされています。運用上必要がないため、個人データは一切処理しません。データ抽出の範囲を設定する際、個人情報が含まれる可能性のある列やフィールドは除外されます.

認証にはSAMLを推奨しています。ユーザーには、Azure Active Directory、Office 365、またはGoogle Workspaceなどのフェデレーテッドアイデンティティを通じてLokadにアクセスすることを強くお勧めします。これにより、パスワードに関するすべての問題が解消されます.

ご要望に応じて、クライアント自身によるセキュリティ監査や侵入テストを実施することが可能です。詳細は契約内容に依存します.

詳しくは、Lokadのセキュリティをご参照ください.

タイムライン概要

定量的サプライチェーンは、その目的自体よりもプロセスの旅路に近いものです。しかし同時に、定量的サプライチェーンの取り組みに着手するサプライチェーンリーダーは、プロジェクトのタイムラインに対する可視性を必要とします。数か月でプラスの成果が得られることもありますが、定量的サプライチェーンの潜在能力を完全に引き出すには最大で2年かかることが一般的です。以下では、中規模企業における定量的サプライチェーンの取り組みに伴う代表的なタイムラインの概要を示します。大企業の場合は、タイムラインが倍程度になると予想されます.

プロジェクトキックオフ: 両当事者の代表が自己紹介を行い、週次ミーティングの日程を設定します。これらの週次ミーティングは、プロダクションフェーズに達するまで継続されます。サプライチェーンサイエンティストは、実施フェーズとクライアントが期待できる各種成果物を提示します。通話の残りの部分は、各種サプライチェーンの詳細や統合のIT特性の検討に充てられ、ミーティング後にはプロジェクトの組織的側面を文書化した概要が作成され、クライアントに送付されます.

データ仕様: キックオフミーティング直後に、サプライチェーンサイエンティストはプロジェクト実施に必要なデータ仕様書を作成します。これらの仕様はクライアントと共にレビューおよび検証されます。特に、本書はクライアントのITシステムから抽出されるデータを定義するものです。通常、抽出はクライアントのITシステムに存在する元データにできるだけ忠実であるべきです.

最初のデータアップロード: 仕様が確認された後、クライアントは最初のデータセットをLokadのサーバーにアップロードします。一般的に、この段階ではアップロードは自動化プロセスで行われず、データ仕様の細部で合意に達するまで複数回の試行が必要となります.

データの検証: サプライチェーンサイエンティストは、クライアントのデータセット内容を徹底的に調査します。特に、複数の指標に基づいたサニティチェックを導入し、データの品質を監視します。目的は、1) アップロードプロセスによってデータセットが適切に更新されること、2) データセットがビジネスの実態を正しく反映していること、3) サプライチェーン最適化に十分な一貫性と完全性を備えていることを確認することです.

このフェーズの成果物として、サプライチェーンサイエンティストはクライアントにデータの状態を評価する各種ダッシュボードを提供します。これらのダッシュボードは、定量的サプライチェーンの取り組みを超えた、内部のデータ品質保証プロセスなどにも利用可能です.

プロジェクト途中監査: キックオフから6週間後に、プロジェクトの進捗状況を評価するためのミーティングが設定されます。この「監査」の目的は、実施中に発生する可能性のある問題、特にプロダクションフェーズの遅延を引き起こす問題に早期に対処することです。Lokadでは、この「監査」は、キックオフ直後にサプライチェーンサイエンティストが事前にクライアントに共有するチェックリストに基づいた情報交換として実施されます.

アップロードの自動化: 両当事者がこれまでにアップロードされたデータセットの全体的な品質を確認すると、クライアントは自動化プロセスを実装し、定期的（理想的には毎日）にデータセットをLokadに転送します。同時に、Lokad側では複数のチェックを備えたデータ健康ロジックが、各アップロード後に更新されるようスケジュールされます.

最適化の設定: この時点から、サプライチェーンサイエンティストは、事前にクライアントと合意した意思決定の最適化を実施するために必要な全ての要素を揃えたことになります。したがって、運用上の購入提案や配送提案など、各種定量的成果を生成するスクリプトを実装します。これらのスクリプトによって生成される数値は、ダッシュボード形式で可視化されますが、現段階ではこれらのダッシュボードは最終版の予備的なものであり、クライアントと共に改訂する必要があります.

フィードバックと微調整: クライアントから各成果物に対する変更や「微調整」の要請は、通常、サプライチェーンサイエンティストが作成したスクリプトの微調整につながります。最適化されるサプライチェーンの特性と最適化ロジックを適切に一致させるためのパラメータや手法は多数存在し、手法自体がクライアントにとって戦略的に重要な場合は、両者で明示的に議論されます.

本番運用: いくつかの微調整と改訂を経て、クライアントはサプライチェーンサイエンティストによって実装されたロジックを信頼できる段階に達します。この時点で、クライアントはソフトウェアが元々算出したサプライチェーンの意思決定を直接実行する形で、本番運用を開始できます。クライアントがソリューションの本番適用を確認すると、サプライチェーンサイエンティストはソリューションの保守性を保証する文書を提供します.

サポートとメンテナンス: ソリューションは稼働状態にあり、サプライチェーンサイエンティストがデータパイプラインの円滑な日常実行を監視する中、クライアントによって運用されます。最適化が期待通りのサプライチェーンパフォーマンスを発揮しているかを確認するため、定期的にクライアントとサプライチェーンサイエンティスト間で通話が行われます。さらに、サプライチェーンは静的なものではないため、新しい倉庫、市場の変動、新プロセスなど、大小さまざまなビジネスあるいはITの変化が見直される必要があります。サプライチェーンサイエンティストは、これらの変化に対応するための適切な修正を提案し、チェックポイント通話を通常月次の頻度でスケジュールします.

よくある質問 (FAQ)

1. リリース管理

1.1 Lokadのリリースはどのように機能しますか？

Lokadは全てのリリースを内部で管理しており、クライアントに対して完全な透明性を確保しています。クライアントに影響を与える可能性のあるリリースは、事前にクライアントの技術チームを通じて調整されます。一般的に、Lokadはリリースに対して慎重なアプローチを採用しており、予定されたリリースがクライアントに十分な準備期間を提供できない場合、そのリリースは一時的に延期されます.

Lokadのリリースは非常に細分化されており、設計上、クライアントは全体のリリースから特定の技術要素を除外することが可能です。したがって、クライアントがまだ準備できていない要素の実装を延期しなければならない場合でも、その他の影響のない要素については全体のリリースが実施されます.

1.2 リリースの頻度はどのくらいですか？

Lokadは毎週火曜日に新しいバージョンをリリースしており、通常は現地時間11時頃（CET）です.

1.3 今後のリリースの計画は提供されますか？

はい、リリース管理 1.2を参照してください.

1.4 バージョン変更は再インストールを伴いますか、それともパッチのみですか？

Lokadは自社のソリューションを自動化された手段（スクリプト）を通じて再展開します。生産環境のシステムにパッチを適用することはありません。もし「セキュリティパッチ」を展開する必要がある場合は、通常の自動化手段を通じてソリューションを再展開します.

1.5 主要なリリースの適用にはどのくらいの時間がかかりますか？

自動化プロセスには約1時間かかります。Lokadのプラットフォームをリリース中も稼働・利用可能な状態に保つため、段階的なロールアウト（機器ごと）が実施されます。ロールアウト中の運用状況については、リリース管理 1.7で説明されています.

1.6 リリースの適切な実行には誰が責任を持っていますか？

リリースの適切な実行は、Lokadチームが全責任を負います.

1.7 リリース中にダウンタイムは発生しますか？

主にダウンタイムは発生しませんが、Lokadのソリューションは大規模な計算に特化した分散システムであるため、その影響はフロントエンドとバックエンドのシステムで異なります。ダッシュボードなど、クライアント向けのサブシステムはゼロダウンタイムで設計されています。一方、バッチジョブの実行を担当するバックエンドシステムは、数分間（一部のジョブでは少なくとも）の停止があり得ます。しかし、これらのバッチジョブはスケジュール可能なため、事前の計画によってリリース時間外に完了させることが可能です.

1.8 リリースにおけるテストプロセスまたは戦略は何ですか？

Lokadは、次回リリースの正確性を保証するための自動化されたテストプロセスを活用しています。これらのプロセスには、数千に及ぶ自動テストスイート（単体テスト、機能テスト、パフォーマンステストなど）が含まれます。また、Lokadプラットフォーム上で過去のジョブ実行シーケンス全体を再現する専用ツールも開発しており、Envisionスクリプトがリリース前後で全く同じ動作をするかどうかを確認できます。さらに、既存スクリプトのパフォーマンスプロファイルが、クライアントの定めたスケジュールの期待値に沿っているかも検証可能です.

1.9 複数の環境はありますか？

はい。しかし、生産環境以外のプラットフォームレベルの代替環境は通常、クライアント向けには提供されていません。生産環境および一時的な開発環境に加え、コードベースの最新の安定版に対応した「エバーグリーン」環境があります。これは、自動化テストプロセスの特定のサブセットを検証するためのものです。クライアントは、特定の次回リリースが期待通りに動作するかどうかを検証するために「エバーグリーン」環境にアクセスできる場合があります。この状況は、Lokadとクライアント間でIT統合がある際に生じることがありますが、実際には稀です.

もし目的が、複数の Envision スクリプトのバリアントを並行して実行できるようにすることであれば、1つの Lokad アカウントを複数の「環境」に分割することができます。もし目的が、あらゆる種類のテストを実施できるようにすることであれば、一時的なテスト用に2つ目の Lokad アカウントを提供できます。2番目のアプローチでは、本番用として使用される主要なクライアントアカウントをこれらのテストから分離します。

1.10 何種類のバージョンが共存可能ですか？

Lokad はマルチテナント型 SaaS であり、すべてのクライアントに対して同一のバージョンを実行しますが、クライアントの希望に応じて複数の異なるバージョンを運用する能力も備えています。

1.11 クライアントはリリースからオプトアウトできますか？

Lokad は全クライアントに対して同一のバージョンを実行するマルチテナント SaaS であるため、リリースからのオプトアウトは不可能です。しかし、ビジネスの観点からは、いかなる「変更」も Lokad ソリューション内での Envision スクリプトの実行を通じて実施されるため、実質的な問題とはなりません。

リリースが一時的に延期される状況については、Release Management 1.1 を参照してください。

1.12 リリースノートはありますか？また、それをクライアントに提供していますか？

はい。これらのノートは内部（当社のサプライチェーンサイエンティストチーム内）で共有されています。契約の一部として明示的に合意されていれば、これらのリリースノートはクライアントがアクセス可能になります。実際、Lokad プラットフォームのリリースノートは Envision コードを扱う人々にのみ関心があります。

1.13 クライアントがソリューションの進化を要求するプロセスはどのようなものですか？

ほとんどのクライアントは「ソフトウェア + エキスパート」提供の恩恵を受けており、Lokad のサプライチェーンサイエンティストチームがクライアントのサプライチェーンソリューションの実装と保守を担当します。これらは「サプライチェーン・アズ・ア・サービス」として知られています。この形態では、クライアントは定期的に1人または複数のサプライチェーンサイエンティストと連絡を取り合います。また、ほとんどのクライアントは、ソリューションの現状や希望する進化について話し合うための週次または月次の運営委員会の恩恵を受けています。Lokad はこの方法で、すべての進化要求を収集し、変更実施のためのロードマップを提案します。

1.14 アプリケーションのウェブサービスを管理し、そのパラメータを設定することは可能ですか？

はい。Lokad プラットフォームは本質的にプログラム可能なためです。Lokad の「分析」ロジックは Envision スクリプトの形を取り、Envision はサプライチェーンの予測最適化を目的として Lokad により設計されたドメイン固有言語 (DSL) です。

したがって、ある意味で、アカウント内の Envision スクリプトを活用することで、すべてのパラメータ構成が利用可能となります。

2. パフォーマンス

2.1 SLA（サービスレベルアグリーメント）は 99.xy% の稼働時間をカバーしていますか？

はい。SLA は当社のデフォルト契約に含まれています。ただし、サプライチェーンの予測最適化に専念する分散コンピュータシステムにおける稼働時間の概念は複雑です。以下のシナリオを考えてみてください： - Lokad がクライアントデータ（日次のステップ）を予定より2時間遅れて受信する場合、これにより通常のリソース割り当てのヒューリスティックが乱される可能性があります。その結果、Lokad のバッチジョブの実行時間（例えば通常の60分ではなく75分）が延長されるかもしれません。これを15分のダウンタイムと捉える人もいますが、それは当社の管理外です。

• Lokad がクライアントデータを予定通りに受信したものの、そのデータに大幅な在庫レベルの低下が見られる場合、これにより（Lokad 側の）バッチジョブが中断され、サプライチェーンサイエンティストに問題調査のアラートが発せられます。サプライチェーンサイエンティストは、自動補充注文がこれまでにない大きさであることに気付き、クライアントから直接の評価が必要だと判断します。翌日、クライアントは在庫データが破損しており、大規模な在庫減損を引き起こすところだったことを確認します。これを24時間のダウンタイムと見なす人もいますが、文脈的には実際的ではありません。

サプライチェーン最適化ソリューションにとって最大の危険は、わずかに遅れることではなく、全く誤った判断を下すことです。一旦サプライチェーンの決定が下され、例えば（誤って）生産バッチが起動された場合、その取り消しには途方もなく高いコストがかかります。私たちはクライアントに対し、個々の指標に無闇に固執しないよう奨励しています。なぜなら、そのような態度は、KPI（例えば x.y% の稼働時間）を満たすように見える限り、全体として質の低い成果を生み出すインセンティブとなる恐れがあるからです。

2.2 ユーザーリクエストに対して X 秒以内の応答時間を保証していますか？

はい、500ms以内ですが、条件付きです。

私たちはいわば「定常時間ダッシュボード」を設計しました。内部的には、ダッシュボードの表示はネットワーク経由の1回のリクエストで済み、バックエンドではすべてのダッシュボードデータを同一箇所に集約することで、ネットワークリクエストの数を低く保っています（通常は一桁です）。この設計は、ダッシュボード表示時の典型的なユーザーリクエストに対する低遅延を「保証」する大きな要因となっています。また、この設計選択により、各タイルごとに個別のネットワークリクエストが必要となることによるダッシュボードの過密化を防ぎ、全体としてのユーザー体験の低下を回避しています。

バッチジョブの実行時間に関しては、Envision を通じてバッチジョブが完了することを（コンパイル時に）保証できます。また、バッチジョブの実行完了時間がほぼ再現可能であることも保証できます。これらの保証は、静的解析と Envision 言語の綿密な設計により得られるもので、特定の種類の静的解析を可能にしています。このアプローチには限界がありますが、全く保証のない設計と比べればるかに優れています。

しかし、エンドツーエンドのレイテンシーは完全に当社の管理下にあるわけではありません。例えば、クライアントが使用するインターネット接続の品質は当社が管理しておらず、低帯域のネットワークでは Lokad の大きなスプレッドシートのダウンロードに時間がかかることがあります。

2.3 システムパフォーマンス監査ログはありますか？

はい。CPU、メモリ、ストレージ、帯域幅など、関与するすべてのコンピューティングリソースに対して非常に詳細なパフォーマンスログを収集しています。これらのログは、新たにリリースされていないプラットフォームのバージョンがパフォーマンス面で当社の期待に沿っているかを確認するためなどに使用され、これまでのバージョンとの比較を通じてテストを行います。

2.4 遅延応答や混雑を監視することは可能ですか？

はい。Lokad プラットフォームには、バッチジョブのタイムリーな実行を追跡できる内部スケジューラが搭載されています。Lokad の設計は、長時間実行される操作（バッチジョブとして扱われるもの）を除けば、すべてのリクエストに対して定常的な応答時間を実現するようになっています。

Lokad はマルチテナントプラットフォームであるため、プラットフォーム全体のパフォーマンス監視の大部分はクライアントが直接アクセスできるものではありませんが、当然ながら Lokad チームはプラットフォームのパフォーマンスを継続的に監視しています。

2.5 ロードバランサーはありますか？

はい。Lokad のロードバランサーは主にパフォーマンスよりも信頼性を目的としています。ネットワークレベルのロードバランシングは、当社が利用するクラウドコンピューティングプラットフォーム（Microsoft Azure）のネットワーク層によって実施されます。しかし、Lokad プラットフォームによる内部データ処理の負荷分散は、ロードバランサーではなく、コンパイラススタックに関連する自社開発のオーケストレーターによって管理されています。

2.6 DB接続、セッションなどのリソースのプーリングは行っていますか？

はい。しかし、Lokad プラットフォームはトランザクショナルデータベースに依存していないため、プールすべき DB 接続は存在しません。それにもかかわらず、パフォーマンスの観点から意味がある場合には、多くのその他のリソースについてはプールを行っています。

2.7 並列処理に対応していますか？

はい。Envision（当社の DSL）は自動並列実行の概念を中心に設計されています。Lokad プラットフォームは、CPU コアレベルにおける SIMD（Single Instruction/Multiple Data）操作、CPU レベルのマルチスレッド実行、さらにクラスター レベルでの分散コンピューティングといった複数のレベルで並列化を積極的に活用しています。並列処理が Envision の中核設計であるため、Lokad プラットフォームで実行されるワークロードのほぼ全てが、クライアントやサプライチェーンサイエンティストが特別な対策を講じることなく、デフォルトで広範な並列化の恩恵を受けています。

2.8 頻繁にアクセスされるデータのキャッシュをサポートしていますか？

はい。しかし、キャッシュは通常、トランザクショナルデータベースのパフォーマンス制限に対処するための回避策として導入されるものです。Lokad プラットフォームにはトランザクショナルデータベースが含まれていないため、この目的でのキャッシュは使用していません。

2.9 ネットワークトラフィックを削減するためにデータの圧縮を行っていますか？

はい、ほとんどのネットワークトラフィックを圧縮しています。しかし、すべてを圧縮することはできません。なぜなら、それは BREACH（Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext）と呼ばれるセキュリティ上の脆弱性を招くためです。BREACH は、次の3つの要因が組み合わさったときに発生します。

1. レスポンスが圧縮されている.

2. レスポンスに秘密が含まれている.

3. レスポンスに、攻撃者がリクエストを工夫することで収集可能な文字列が含まれている.

BREACH に対抗するため、Lokad は第三の条件が該当するすべてのレスポンスの圧縮を無効にしています。また、データ圧縮はネットワークトラフィックの削減以外にも、第一にデータストレージコストの低減、第二に計算遅延の削減を目的としています。

2.10 パフォーマンステストを実施していますか？

はい。Lokad には広範な自動パフォーマンス指向のインストゥルメンテーションレイヤーが備わっています。この一連のツールにより、各リリース前に、現在デプロイされているバージョンと比較して次期バージョンのパフォーマンス差を評価することが可能です。このツールは、本番環境で観測されるのと同様のワークロードを再現し、ウォールクロックタイムだけでなく、メモリ、帯域幅、I/O、CPU などの全ての関連コンピューティングリソースを考慮した上で、得られたパフォーマンスを監視します。

2.11 トランザクションレベルでパフォーマンスを監視していますか？

はい。しかし、Lokad プラットフォームはトランザクショナルデータベースを利用していないため、従来の意味での「トランザクション」を監視することはありません。最も近い概念は Envision スクリプトの実行であり、これらのスクリプトに対しては、トランザクショナルデータベースのクエリプラン実行の詳細を監視するのに近い、非常に細かいレベルでのパフォーマンス監視を行っています。

Lokad ソリューションにおける「トランザクション」の詳細については、当社の Security ドキュメント内の Authorization 3.6 および Logging and Monitoring 5.3 をご覧ください。

2.12 ソリューションにおいて同時利用するユーザーが存在する場合、パフォーマンスにどのような影響がありますか？

ほとんど影響はありません。Lokad の設計により、B2B基準においても多数のユーザーが利用している場合、ダッシュボードは定常時間内にサービスが提供されることが保証されています。このアプローチは、特にトランザクショナルデータベースやビジネスインテリジェンスキューブといった他の多くのアーキテクチャとは大きく異なります。

しかし、各ユーザーが（適切なシステム権限を有していれば）任意に大規模なワークロードを引き起こす可能性があるため、ソリューションのパフォーマンスにおいて、同時利用ユーザー数は多くても二次的な問題に過ぎません。サプライチェーンの予測最適化に関しては、主要な解析処理を行うバッチジョブが全ワークロードの99%以上を占め、残りの1%未満がユーザーリクエストの対応に充てられています。

2.13 システムは垂直および水平スケーリングに対応して設計されていますか？

はい。当社の見解では、垂直スケーリングと水平スケーリングは相補的なものであり、Lokad プラットフォームの設計では両者が活用されています。内部オーケストレーター（並列化を担当するもの）は通常、まず垂直スケーリングから始めます。なぜなら、垂直スケーリングはデータのコロケーションを大いに促進するからです。その後、ワークロードが十分に大きい場合、オーケストレーターは水平スケーリングを活用して、複数マシンでの実行の恩恵を享受します。

2.14 必要に応じてコンピュートおよびストレージを自動スケーリングしますか？

はい。Lokad プラットフォームはマルチテナントであり、その仕組みを通じて大規模かつ低レイテンシーのコンピュートリソース割り当てを実現しています。つまり、Lokad が提供するコンピュートの自動スケーリングは、クラウドコンピューティングプロバイダーから大規模な仮想マシンを立ち上げるよりも桁違いに高速です。ストレージの自動スケーリングは、基盤となるクラウドコンピューティングプラットフォーム（Microsoft Azure）が提供する永続的なキー・バリュー・ストアの自動スケーリング特性を活用することで主に実現されています。

2.15 アプリケーションは「ビッグデータ」の要件にどのように対処していますか？

Lokad プラットフォームは「ビッグデータ」処理向けに特別に設計されています。2023年1月時点で、Lokad プラットフォーム全体で全顧客基盤にわたる約1ペタバイトのデータを管理しています。当プラットフォームは、最大100GBの個別ファイルを処理でき、数十億行に及ぶテーブルも定期的に処理しています。Security of Lokad 4.10

この点は非常に技術的で、本ドキュメントの範疇を超えています。詳細な説明については、Victor Nicollet の Envision Virtual Machine の設計 に関する4部構成のシリーズをお勧めします。

2.16 Lokad のクラウドベースのソリューションは、帯域幅やレイテンシーの厳しい制約（クライアント側）の下で構成可能ですか？例として：帯域幅 = 3Mbps（ダウンロード）/ 1Mbps（アップロード）、レイテンシー = 600-800ms

はい。Lokad により設計されたウェブアプリは、帯域幅とレイテンシーの両面で接続が「不十分」なシナリオをサポートできるようエンジニアリングされています。これらの懸念は基本的な技術設計の選択によって主に対処されており、architectural design choices により、Lokad は主流の技術とは一線を画しています。帯域幅に関する懸念は、まず JavaScript のサードパーティコンポーネントを極力控え、初回に取得するアセットを1MB未満に抑えること、そしてダッシュボードに含めるデータ量を完全に制御できる点で対処されています。したがって、接続状況が悪い場合でも、ダッシュボードを適切に「軽量化」することが可能です。レイテンシーに関しては、すべての関連ダッシュボードデータを単一の HTTP リクエストにまとめるよう設計されているため、低レイテンシーのエンドユーザーによる摩擦を最小限に抑えています。

2.17 ソリューションの平均およびピークのデータスループット能力は、1（低性能）および5（高性能）メッセージ/秒のベンチマークと比べてどのようなものですか？

The Lokad プラットフォームはメッセージを使っていません。同様に、Lokad プラットフォームとのやりとりもメッセージを通じて行われるものではありません。しかし、大量のトランザクションデータを迅速に処理するためにはスループットが重要です。Lokad プラットフォームは、合計で1ペタバイトを超えるデータを管理しています。大規模な計算バッチの場合、毎分1テラバイト以上を定期的に処理しています.

非常に高いスループットは、機械学習や数理最適化の工程を含む複雑な計算で数十テラバイト規模の非常に大規模なデータセットを処理する際に、運用の遅延を避けるために重要です.

2.18 ソリューションはどのサイズのメッセージを扱えますか？最小値、最大値、および平均値の詳細を教えてください.

Lokad プラットフォームはメッセージを使ってはいません。一番近いのは “flat files” です。これらの “flat files” は Lokad に送信したり、Lokad から取得したりできます。Lokad プラットフォームは、個々のファイルサイズが最大100GBに達するファイルも処理可能です。しかし、これは通常扱いにくいため（Lokad 自体ではなく、大きなファイルを生成・利用するために外部ツールに慣れる必要があるクライアント向けの話です）.

3. インシデント

3.1 クライアントがインシデントを報告するプロセスはどのようなものですか？

当社の多くのクライアントは、サプライチェーンサイエンティストのチームへのアクセスを含むパッケージの恩恵を受けています。これらのサプライチェーンサイエンティストは、インシデント報告の最初の窓口となります。インシデント発生時には、問題が緊急の場合はサプライチェーンサイエンティストに直接電話するか、またはメールを送ることをお勧めします。サプライチェーンサイエンティストは、インシデント管理および Lokad 内でのエスカレーション対応を行います.

3.2 チケッティングシステムを提供していますか？

はい。Lokad はサードパーティのチケッティングシステムを活用しています。しかし、2023年1月現在、プラットフォーム全体と密に連携する内部ソリューションの開発を開始しています.

3.3 インシデントをサードパーティのツールへ報告することをサポートしていますか？

はい、専用の契約合意の下で可能です.

予測的サプライチェーン最適化の文脈では、「インシデント」は様々で定義が難しい場合があります。一般に、当社のクライアントは、わずかなダウンタイムなどのプラットフォームレベルの小さな出来事を「インシデント」とは考えていません。むしろ、クライアントアカウントに実装された Envision スクリプトに起因する可能性のある実際のサプライチェーンの異常が、より適切な対象となります。外部のIT部門がこれらのインシデントの解決に関与することは稀です.

3.4 どのように高い可用性を確保していますか？

Lokad は高い可用性を確保するために、2010年頃からクラウドコンピューティングプラットフォームの早期採用者となりました。インフラの冗長化（インシデント 3.5参照）に加え、Lokad のソリューション設計はシンプルさを強く重視しています。類似のエンタープライズソフトウェアソリューションと比較して、複雑な依存関係が格段に少なく（ほぼ一桁の差）、当社のソリューションにはトランザクショナルデータベースという大きな複雑さがありません。可動部品が少ないことで故障モードも大幅に減り、複数のタイムゾーンに跨るクライアントに対して高い可用性を維持するのに役立っています.

3.5 冗長なインフラストラクチャはありますか（ある場合、どのように実現していますか）？単一障害点を回避していますか？

はい。当社の重要なシステムは単一障害点を避けるために冗長化されています。冗長化されたシステムには、SFTP のようなステートフルプロトコルをサポートするサブシステムが含まれます。さらに、データストレージは冗長化されているだけでなく、地理的にも冗長化されています。この冗長性は、リリース中にアップタイムを維持するために活用されています.

3.6 ハードウェア障害からどのように回復しますか？

ほとんどのハードウェア障害からの回復は、Lokad が利用するクラウドコンピューティングプラットフォームによって透過的に実施されます。Lokad プラットフォームに組み込まれた冗長性により、一時的なハードウェア障害が発生しても、クラウドプラットフォームが新たな不良のないリソースを再割り当てする間、アップタイムに影響しません。永続的なデータストレージについては、Lokad は自身の冗長性レイヤーによってハードウェア障害から保護されたサービス（つまり、キー・バリュー・ストア）のみを利用しています.

3.7 バックアップはありますか？

はい。データセンターレベルのダウンタイムを超える大規模災害復旧シナリオ専用のバックアップ環境を用意しています。このバックアップ環境は本番環境から完全に隔離されています。バックアップ環境は本番環境から読み取りは可能ですが（書き込みは不可）、本番環境はバックアップ環境への読み書きが一切できません.

3.8 災害復旧計画はありますか？

はい。技術レベルでは、災害復旧計画は Lokad プラットフォームの完全な再構築を対象としています。この部分は、週次リリースのために採用している自動化プロセスを大いに活用しています。ビジネスレベルでは、災害復旧計画には、各クライアントと合意したプロセスに従い、全クライアントへの連絡が含まれます。多くのクライアントにとって、指定されたサプライチェーンサイエンティストが復旧期間中の主要な連絡窓口となります.

3.9 ソリューションは、データベース内外のデータに対して時点回復（PITR）をサポートしていますか？ソリューションのリカバリーポイント目標（RPO）は何ですか？

Lokad のソリューションは、イベントストアとコンテンツソースのライブインクリメンタルバックアップを通じた継続的なデータ保護設計を特徴としており、そのため、任意の時点（分単位まで）での PITR を実施できます.

データが侵害されていなければ、データセンターレベルの災害に対しては1分のRPOを実現しています。これは、永続的なキー・バリュー・ストアへの地理的に冗長な書き込みを活用することで達成されています。もしキー・バリュー・ストアが侵害された場合、Lokad は本番システムからできるだけ隔離された状態で、別の地理的ロケーションにホストされたバックアップストレージから回復します。この場合、RPOは12時間となります.

3.10 ソリューションは、データ整合性違反のアラートを生成できますか？また、必要に応じて整合性チェックを追加または拡張する機能はありますか？

はい。ただし、この種の問題は主にトランザクショナルデータベースに基づくソフトウェア設計を反映しています。Lokad のプラットフォームはトランザクショナルデータベースではなくイベントストアを使用しており、リレーショナル設計ではなくイベントソーシング設計を採用しています。これによりデータ整合性確保の必要性がなくなるわけではありませんが、その課題は別の方法で対処されています.

クライアントデータの処理に関して、Envision（Lokad の DSL）はデータ品質チェックのための幅広い機能を備えています。Envision を用いれば、整合性のチェックやアラートの生成が可能です。このロジックは、クライアントが適切と判断する方法で拡張または修正することができます.

3.11 バックアップは定期的に適切なデータ復元機能についてテストされていますか？

はい。Lokad のイベントソーシング設計とコンテンツアドレス可能なストアにより、バックアップおよびデータ復元機能のテストは、SQL などのリレーショナルデータベースを用いた主流の設計と比較して、はるかに容易になっています.

また、インシデント 3.7も参照してください.

3.12 災害復旧計画は定期的に適切な災害復旧機能についてテストされていますか？

はい。Lokad のデプロイ戦略は、エンドツーエンドの自動化スクリプトを活用し、意図的に人間の介入を極力排除しています（ただし、本番環境の完全な再展開をトリガーする機能は例外です）。この高度に自動化されたアプローチは、災害復旧機能のテストを容易にします.

また、インシデント 3.8も参照してください.

3.13 個々の顧客および/または顧客環境に対して回復を実施できますか？

はい。当社の内部ツールは、特定の顧客アカウントの復元（アカウント/環境を特定の時点に復元することを含む）をサポートしています。しかし、Lokad プラットフォーム自体が広範なバージョン管理機能（例：Envision スクリプトはバージョン管理され、過去のバージョンにアプリ内からアクセス可能）を備えているため、この機能はほとんど使用されません.

3.14 バックアップおよび災害復旧計画は、顧客ごとに定義され合意された RTO（復旧時間目標）、RPO（復旧ポイント目標）、および災害シナリオの要件を満たしていますか？

はい。復旧時間目標（RTO）とは、Lokad プラットフォームが理論上どれだけの時間停止しても顧客に大きな損害を与えず、また重大なインシデント発生後にプラットフォームとデータを復旧し通常運用に戻すのに要する時間を意味します.

RTO は、Lokad がサポートまたは提供する特定のプロセスの細部に大きく依存します。例えば、毎月の海外購買注文のスケジュール管理に Lokad を利用する顧客は RTO が1週間である可能性があります。一方、倉庫から複数店舗への日次在庫配送の最適化に Lokad を利用する顧客は RTO が1時間である可能性があります.

実際には、さまざまな技術的対策を講じることで RTO（すなわち理論上のダウンタイムの短縮）を大幅に改善することが可能です。例えば、_フェイルオーバーの判断_を事前に計算しておくことができ、Lokad プラットフォームが利用できなくなった場合に備えることができます。これらの判断は「通常」の最適化された判断と比較すると、定義上最新のデータを利用しないため、供給性能がやや低下する可能性があります.

当社管理下のアカウントに関しては、実際のインシデント発生時に最小限のビジネス影響を保証しつつ高い RTO を実現するプロセスを、クライアントのオペレーションチームと共同で策定する責任は、Lokad のサプライチェーンサイエンティストにあります。当社の見解では、この課題は何よりもまず IT の問題ではなくサプライチェーンの問題です.

また、インシデント 3.9も参照してください.

3.15 テスト環境で再現不可能な不具合の場合、Lokad はログや補助データから不具合の発生を検証し、サービスレベルアグリーメント（SLA）に従って不具合が修正されたことを保証できますか？

はい、不具合は当社の環境で再現可能です。すべてのデータ状態および計算の厳密な再現性は、Lokad プラットフォームおよびアーキテクチャの中核的な設計原則です。例えば、Lokad プラットフォーム内のファイルシステムは、この問題に対処するために完全にバージョン管理されています（Gitのように）.

なお、ログはサーバーダウンタイムなどの些細な問題のトラブルシューティングには有効ですが、テラバイト単位のデータを扱う大規模な環境での複雑な問題や不具合のトラブルシューティングにはしばしば不十分です.

したがって、Lokad は適宜ログを保持し参照しますが、不具合への対処やその修正の検証に_ログに依存しない_よう対応しています。むしろ、優れた設計選択を主に活用して、より高い洞察力、追跡性、再現性を提供しています.

これらの意図的な設計選択により、単にログに依存するだけでは不可能な方法で、不具合の特定、再現、および修正が可能になります.

一般的なソフトウェアの問題全般を回避するために採用している主要な設計選択の詳細については、Lokad のアーキテクチャをご参照ください.

3.16 クライアント企業によって行われたすべてのサービスリクエストおよびサービスコール（各コールのカテゴリーを含む）の記録を保持していますか？記録には、発信者と受信者の身元、報告されたエラー、問題またはインシデントの性質、Lokad の応答時間、サービスコールの処理状況、解決策、解決に要した時間、およびシステムの可用性が含まれていますか？

はい、Lokad のプラットフォームは、上記の詳細を提供するタスク/チケット/イシュー管理機能を備えています.

「解決策」について言えば、Lokad の定量的サプライチェーンの哲学（QSC）は、問題が発生した際に最も経済的に有利なトレードオフを見つけることに焦点を当てています。QSC は技術的には「問題の修正」アプローチではなく、サプライチェーンの問題は「修正」されるものではなく、経済的に合理的なトレードオフによって軽減されるものです.

要するに、Lokad はサーバーダウンタイムなどの「容易な問題」を迅速かつ明快に解決するためのツールとプロセスを備えています。一方で、小売在庫の配分や在庫補充問題のような、より大きく重要なサプライチェーンの問題については、投資収益率を最大化するためのトレードオフについて、クライアントとオープンかつ継続的な議論を行います.

4. アーキテクチャ

4.1 どのプログラミング言語を使用していますか？

Lokad プラットフォームは C#, F# および TypeScript で開発されています。また、プラットフォームには、クライアント固有のサプライチェーンソリューションを実装するために使用される Envision（Lokad の DSL）も搭載されています.

4.2 どの開発スイートを使用していますか？

Lokad のソフトウェアエンジニアリングチームは Microsoft Visual Studio を使用しています。サプライチェーンサイエンティストのチームは、独自の開発スイートを備えた Lokad プラットフォーム自体を使用しています.

4.3 どのオペレーティングシステムをサポートしていますか？

Lokad はウェブベースのプラットフォームであり、モダンなウェブブラウザ（例: Firefox）にアクセスできるすべてのオペレーティングシステムをサポートしています。内部的には、Lokad プラットフォームは Linux と Microsoft Windows の両方と互換性がありますが、すべての本番システムは Linux (Ubuntu) 上に展開されています.

4.4 どのデータベースシステムを使用またはサポートしていますか？

Lokad は、“flat files” のエクスポートが可能なすべてのデータベースシステムをサポートしています。これは、実質的に市場にあるすべてのデータベースシステム（旧型を含む）を網羅します。内部的には、Lokad はデータベースシステムではなくキー・バリュー・ストアを使用しており、執筆時点（2023年1月）では、Microsoft Azure が提供する Blob Storage を利用しています.

4.5 どのキャッシングシステムを使用していますか？

Lokad は C#/.NET で独自のキャッシングサブシステムを設計しました。これらのサブシステムはソリューションの他の部分と密接に統合されており、Lokad が持たないリレーショナルデータベースに起因するパフォーマンス問題を軽減するための従来型のキャッシングシステムとは異なります.

4.6 ソリューションは証明書をどのように扱いますか？

Lokad は自動証明書更新を通じて Let’s Encrypt を活用しています.

4.7 ソリューションを使用するための技術的前提条件は何ですか？

The main technical prerequisite is a transaction system that keeps track of one’s inventory. Additionally, it is helpful if the client has some experience extracting data (as flat files) from their transactional systems, but this is certainly not a prerequisite.

4.8 List any additional third-party licenses required to operate Lokad’s solution (e.g., OS, SQL,…).

N/A. Lokad does not require any 3rd party licence(s) to operate. A wide array of open-source tools exist to support the integration of Lokad (i.e., flat files transferred through FTPS or SFTP); hence, there is no 3rd party licence required, even indirectly, to benefit from the Lokad platform.

4.9 Does the service require any browser plug-ins or special software?

Lokad is a webapp. It does not require browser plug-ins or any special software.

4.10 What are the inbound and outbound interfaces of the application?

Lokad’s solution offers a web interface - accessible through HTTPS - and file protocols, namely SFTP and FTPS.

4.11 How do you ensure there are no data leaks between tenants?

Lokad’s solution segregates tenant data through its very design, which ensures that data leaks (even accidental ones) do not occur. Furthermore, all code shipped to production is peer-reviewed, thus providing an additional layer of protection. Finally, we direct security researchers (people performing pentests) to specifically investigate the possibility of data leaks. We give them access to multiple Lokad accounts - in a dedicated and fully isolated environment that mirrors the production one - so they can aggressively check this property of our platform.

4.12 Can the solution be containerized?

Yes, but there is little to no benefit for Lokad’s platform to be containerized. Containerization brings value when there are complex dependencies (e.g., a transactional database, an isolated caching system, etc.). We do not use containers in production or development, which improves our security by eliminating entire classes of vulnerabilities. Instead, we keep the solution simple enough so that deployment can be performed with even small shell scripts.

4.13 Can the GUI components be decoupled from the backend?

Yes, GUI components (in this case, web interfaces) are stand-alone. This design helps to achieve higher availability. End-users can access their Lokad account dashboards even if a sudden downtime affects one of the other subsystems.

4.14 Does the Lokad application support localization functions (such as changing language)?

Yes, the application supports localization functions. All the user interfaces produced by Lokad’s platform can be localized in any language. In particular, the whole technological stack adopts UTF-8, in order to accommodate all the charsets that exist beyond the Latin one. In particular, any user interface produced by Lokad’s platform can be re-localized - after delivery - into another language.

4.15 Is it possible for end-users to update or create new translations after delivery of post-processed data from Lokad?

Yes, see 4.14 above.

4.16 Does your system have a built-in Help? If yes, in which language(s)?

Yes, Lokad comes with very extensive public documentation (in English). However, using the Lokad platform entails the creation of bespoke user interfaces and our regular process involves at least two forms of documentation or help.

First, the dashboards crafted within the Lokad solution are intended to be contextually documented - right from the dashboard itself. In particular, we even have a Markdown tile dedicated to rich text documentation. Second, our deliverables include a “Joint Procedure Manual”. Overall, the manual provides detailed analysis of not only the mechanics of the solution, but also why each element was selected (and how it satisfies the client’s specific supply chain needs).

4.17 Is the webapp responsive?

The Lokad webapp, along with its supporting materials (like the technical documentation), has been designed to be responsive. However, some advanced capabilities, like editing code, are impractical for mobile and/or tablet devices. Thus, the design is intended to maximize responsiveness for the anticipated activities carried out on PCs and smaller devices, respectively.

4.18 If your system is a webapp, which browser and versions do you support? What is your minimum internet browser standard?

Lokad is a webapp and we support the major “evergreen” web browsers such as Chrome, Firefox and Safari. We do not attempt to support older browsers for security reasons, as supporting those browsers implicitly endangers our client(s). Simply put, a vulnerable browser can be leveraged by a malicious actor to exfiltrate data. That being said, we are also quite conservative when it comes to new browser capabilities. As a rule of thumb, we avoid supporting any browser capabilities that have not been adopted by all the major web browsers for at least 1 year.

4.19 For mobile and tablet applications, which OS (and versions) does Lokad support?

N/A. As Lokad is a web app served as SaaS, our clients are not concerned with the OS support. Internally, Lokad is developed under Windows, while all our production cloud-hosted environment is under Linux. Thus, we are quite confident in the broad portability of the Lokad solution. Although we do not feel any present need to change this setup, should valid evidence present itself we will adapt accordingly.

4.20 Can the Lokad webapp provide notifications for end-users? If yes, which technology/protocol is leveraged?

Yes, Lokad has the capability to send notifications through programmable HTTP hook notifications. These hooks can be leveraged to use a 3rd party system, frequently already in place in the client company, to send an email notification or any alternative type of notifications deemed appropriate. The hooks are also typically used to signal the availability of data to be retrieved from the Lokad platform through SFTP or FTPS.

4.21 Are there shared elements on the solution that are common to all customers (such as monitoring functions, backup- or patch management solutions, etc.)?

Yes, as Lokad is a multi-tenant app, the infrastructure-level capabilities are all shared between/across tenants, i.e., client accounts. This includes monitoring for uptime, performance and for security reasons, backup, patch management, upgrade, etc.

4.22 Does the solution allow for multiple-destination messaging functionality (i.e., the ability to send a message to more than one recipient or application)?

The Lokad platform does not operate with messages. However, we do provide HTTP-hook capabilities which can be used to generate arbitrarily complex message notifications, typically through low-cost third-party systems. Those notifications are sometimes used by supply chain teams to monitor the timely completion of mission-critical computation batches with the Lokad platform.

4.23 Do all the critical systems and components use the same time source (NTP) or synchronize their clocks in some other reliable way?

Yes. Lokad uses the default NTP service that comes with Ubuntu - ntp.ubuntu.com. More specifically, ntpd is run as the time-sync service, which synchronizes against an external NTP time source that is accessed over the network.

4.24 Is there an asset inventory list or configuration management database (CMDB)?

Yes, we have an IT asset management software to support our processes. This platform helps us maintain a comprehensive asset inventory list and acts as our configuration management database (CMDB). Through this system, we can efficiently track, manage, and allocate hardware and software assets across the organization. Our teams have the ability to quickly identify the status, location, and configuration of any asset, ensuring swift responses to changes, updates, or potential issues.

Furthermore, our tool provides functionalities that allow for detailed lifecycle management, ensuring that assets are accurately cataloged from procurement to end-of-life. Automated auditing capabilities, coupled with detailed reporting features, ensure that we maintain full visibility and control over our IT environment, facilitating compliance and efficient resource allocation.

4.25 Is every connection to an external network terminated at a firewall (e.g., the Internet, partner networks)?

No, we do not terminate every connection to an external network at a firewall, whether it’s the Internet or partner networks. Our decision is rooted in real-world concerns about the effectiveness and implications of such measures.

From our perspective, while firewalls are typically seen as a frontline defense, they can ironically expand the attack surface area. The more components and systems we integrate, the more potential weak points we introduce. Firewalls, due to their nature, operate as high-privilege processes. This means they become primary targets for cyber-attacks, and when they are compromised, the results can be devastating. An illustrative case is the SolarWinds attack, where the very systems intended to safeguard information were exploited, leading to significant breaches.

Moreover, the presence of strict firewalls can be counter-productive in a practical sense. Our experience has shown that such systems often incentivize employees to seek alternative means to access and share information. This typically involves bypassing the corporate network entirely (hence preventing any monitoring), using personal 4G or 5G connections from their own devices. Such practices inadvertently increase the risk of security breaches and data leaks.

Thus, while we are deeply committed to security, our approach is holistic and informed by practical concerns rather than relying solely on traditional measures.

4.26 Does the network have a DMZ environment that transmits, processes, or stores critical systems (like web servers, DNS, directory services, and remote access), as well as client data?

No, Lokad does not utilize a traditional DMZ environment within our network for transmitting, processing, or storing critical systems and client data. Instead, we have adopted a zero trust approach to network security.

This model does not rely on DMZs, but rather operates on the principle of “never trust, always verify.” Every access request is validated and authenticated, irrespective of its origin, be it from within or outside the organization.

This ensures a more robust and holistic security posture, as it does not depend on perimeter defenses like a DMZ but focuses instead on securing each individual access point and data transaction. We believe the zero trust approach offers superior protection for our critical systems and client data.