FAQ: 情報技術（IT）

LokadアプリはSaaS（Software as a Service）として提供されるWebアプリです。Lokadの目的は、予測分析を提供してサプライチェーンを最適化することです（在庫の改善、価格の改善など）。Lokadアプリは、トランザクションシステム（ERP、WMS、CRMなど）と並行して動作する分析レイヤーとして設計されています。通常、月額定額制のサブスクリプション料金には、アプリ自体とプロフェッショナルサービスがバンドルされています。これらのプロフェッショナルサービスは、Lokadのエンジニア（サプライチェーンサイエンティスト）によって提供され、この範囲ではIT部門自体からの技術サポートのほとんどを軽減します。IT部門から期待される主な貢献は、フラットファイルをLokadにプッシュするデータパイプラインの設定であり、生成された結果を再統合する可能性があります。

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

技術概要

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

アプリは毎週火曜日の10:00から14:00（パリ時間）の間に完全に再デプロイされます。ダウンタイムは通常5分以下に抑えられます。Lokadは、すべてのバージョン管理に関する問題に完全に責任を持ちます。

IT部門は、Lokadのスタックに特定の能力を持つことを期待されていません。ただし、興味がある場合は、完全な技術ドキュメントがあります。

ITへの貢献の概要

IT部門には、SFTPまたはFTPSを介してLokadに関連するフラットファイルの短いシリーズをプッシュするデータパイプラインの設定を行っていただきます。抽出はトランザクションシステム（例：ERP）上で実行されます。私たちは、最小限の労力で実現可能な生のテーブル抽出（フィルターなし、結合なし、変換なし）を強く推奨しています。ETLの観点からは、最も単純な形式（プレーンコピー）の「E」（抽出）のみが必要です。形式的には、Lokadは合理的な表形式のフラットファイルと互換性があります。

データパイプラインは、少なくとも毎日実行され、完全に自動化されることが期待されています。IT部門の作業量は、データ抽出の範囲（どのシステム？どのテーブル？）に依存します。ただし、一般的な目安として、データパイプラインの設定には通常、大企業でも約15〜45人日の作業が必要です。データパイプラインが設置されると、Lokadは通常、IT部門からの最小限のモニタリングのみを必要とし、通常は月に1〜2人日で行われます。

セキュリティ概要

アプリはEUにあるMicrosoft Azureデータセンターでホストされています。私たちは個人データを処理していないため、個人データを必要としません。データ抽出の範囲を確立する際には、個人データを含む列またはフィールドは除外します。

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

クライアントの要求に応じて、セキュリティ監査と侵入テストを実施することができます。詳細は、交渉によります。

詳細については、Lokadのセキュリティを参照してください。

タイムライン概要

量的サプライチェーンは、単なる目的ではなく、旅のようなものです。しかし、同時に、企業を量的サプライチェーンの取り組みに参加させるサプライチェーンリーダーシップは、プロジェクトのタイムラインに関しては可視性を必要とします。数ヶ月でプラスのリターンを得ることができますが、量的サプライチェーンのフルポテンシャルを引き出すには通常2年かかります。以下では、中堅企業の量的サプライチェーンイニシアチブに関連する典型的なタイムラインの概要を提供します。大企業の場合、タイムラインは2倍の期間が必要とされるでしょう。

プロジェクトのキックオフ: 両当事者の代表者がお互いに自己紹介し、週次ミーティングのスケジュールを組みます。これらの週次ミーティングは、プロダクションフェーズに到達するまで続きます。サプライチェーンサイエンティストは、実装のさまざまなフェーズとクライアントが期待できるさまざまな成果物を紹介します。その後の通話は、さまざまなサプライチェーンの詳細と統合のIT特性のレビューに費やされます。通話の後、プロジェクトの組織的な側面を文書化した要約が作成され、クライアントに送信されます。

データの仕様: キックオフミーティングの直後、サプライチェーンサイエンティストはプロジェクトの実装に必要なデータの仕様を作成します。これらの仕様は、クライアントと共にレビューおよび検証されます。特に、このドキュメントでは、クライアントのITシステムから抽出するデータを定義します。原則として、抽出はクライアントのITシステム内の元のデータにできるだけ近い形で行うべきです。

最初のデータのアップロード: 仕様を検証した後、最初のデータセットがクライアントによってロカッドのサーバーにアップロードされます。通常、この段階では、データの仕様の詳細について合意に達するために複数の試行が必要ですので、アップロードはまだ自動化されていません。

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

成果物に関しては、このフェーズでは、サプライチェーンサイエンティストがクライアントにデータの「健康状態」を評価するさまざまなダッシュボードを提供します。これらのダッシュボードは、クライアントが量的サプライチェーンイニシアチブ自体を超えて使用できるものであり、内部のデータ品質保証プロセスの一部として使用することもできます。

プロジェクトの中間監査: 初回のキックオフから6週間後、プロジェクトの完了状況を評価するためのミーティングが設定されます。この「監査」の目的は、実装中に発生する可能性のある問題、特にプロダクションフェーズの遅延を引き起こす可能性のある問題をできるだけ早く解決することです。ロカッドでは、この「監査」は、サプライチェーンサイエンティストとクライアントの間の交換を指し、サプライチェーンサイエンティストからクライアントに事前に伝えられるチェックリストに基づいて行われます。キックオフミーティングの直後です。

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

最適化の設定: この時点から、サプライチェーンサイエンティストは、以前にクライアントと合意した意思決定の最適化を実装するために必要なすべての要素を持っています。したがって、彼はさまざまな数量的な出力を生成するためのスクリプトを実装します：運用上の購入提案、配送提案など。これらのスクリプトによって生成された数値は、ダッシュボード形式で視覚化することができます。この段階では、これらのダッシュボードは最終的なダッシュボードの予備版であり、クライアントと一緒に見直す必要があります。

フィードバックと微調整: クライアントの要求によって、さまざまな出力を微調整する必要がある場合、サプライチェーンサイエンティストが書いたスクリプトを微調整することがあります。最適化ロジックと最適化されるサプライチェーンの特性を適切に整列させるために採用できる多くのパラメータと方法があります。方法論自体がクライアントにとって戦略的に重要な場合、これはクライアントとサプライチェーンサイエンティストの間で明示的に議論されます。

プロダクション: 数回の微調整と見直しの後、クライアントはサプライチェーンサイエンティストによって実装されたロジックを信頼する段階に達します。この時点で、クライアントはサービスを本番環境で使用できるようになります。つまり、ソフトウェアによって元々計算されたサプライチェーンの意思決定を直接実行できます。クライアントがソリューションが本番環境で使用できることを確認した場合、サプライチェーンサイエンティストはソリューションの保守性を確保するドキュメントを提供します。

サポートとメンテナンス: ソリューションは稼働しており、クライアントが使用しています。同時に、サプライチェーンサイエンティストはデータパイプラインのスムーズな日常の実行を監視しています。クライアントとサプライチェーンサイエンティストの間で定期的に通話が組織され、最適化が期待されるサプライチェーンのパフォーマンスを提供しているかどうかを確認します。さらに、サプライチェーンは静的ではないため、ビジネスやITの変更、大きなものでも小さなものでも、見直す必要があります。新しい倉庫、市場の変化、新しいプロセスなど。サプライチェーンサイエンティストは、これらの異なる変更に対応するための適切な修正を提案します。チェックポイントの通話は、通常、合意された頻度でスケジュールされます（通常は月次）。

よくある質問（FAQ）

1. リリース管理

1.1 ロカッドのリリースはどのように機能しますか？

ロカッドはすべてのリリースを内部で処理しており、これによりクライアントに完全な透明性が確保されます。クライアントに影響を与える可能性のあるリリースは、クライアントの技術チームを介して事前に調整されます。一般的に、ロカッドはリリースに慎重なアプローチを取っています。スケジュールされたリリースがクライアントに十分な準備時間を提供しない場合、リリースは一時的に延期されます。

ロカッドのリリースは非常に細かく、通常、クライアントが特定の技術要素をリリース全体から除外することができるように設計されています。したがって、クライアントがまだ準備ができていない要素の実装を延期する必要がある場合でも、他の影響を受けない要素の実装は行われます。

1.2 リリースはどのくらい頻繁に行われますか？

ロカッドは毎週火曜日に新しいバージョンをリリースします。通常は午前11時（CET）頃です。

1.3 次のリリースの計画を提供していますか？

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

1.4 バージョンの変更は再インストールが必要ですか、それともパッチだけですか？

ロカッドは、自社のソリューションを自動化された手段（スクリプト）を通じて再展開します。本番システムをパッチすることはありません。セキュリティパッチを展開する場合は、通常の自動化手段を介してソリューションを再展開します。

1.5 メジャーリリースの適用にはどのくらい時間がかかりますか？

自動化プロセスには約1時間かかります。ロカッドのプラットフォームを運用およびアクセス可能な状態に保つため、段階的な展開（マシンごと）が行われます。展開中の運用性については、リリース管理 1.7で説明されています。

1.6 リリースの正しい実行は誰の責任ですか？

ロカッドチームはリリースの正しい実行に完全な責任を持ちます。

1.7 リリース中にダウンタイムはありますか？

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

1.8 リリースのテストプロセスや戦略はありますか？

ロカッドは、次のリリースのテストと正確性を確保するために専用の自動化プロセスを利用しています。これらのプロセスには、数千の自動化テスト（単体テスト、機能テスト、パフォーマンステストなど）が含まれます。また、ロカッドプラットフォーム内で過去のジョブ実行の完全なシーケンスを再現することができる専用のツールも開発しています。これらのツールを使用して、次のリリース前後でEnvisionスクリプトの動作がまったく同じであることを確認することができます。さらに、既存のスクリプトのパフォーマンスプロファイルが、クライアントの定義によるスケジュールの期待値と一致しているかどうかも確認できます。

1.9 複数の環境を持っていますか？

はい、ただし、プロダクション環境以外の代替環境は通常、クライアントを対象としていません。プロダクション環境と一時的な開発環境に加えて、コードベースの最新安定版に対応する「エバーグリーン」環境があります。これにより、一部の自動化テストプロセスの特定のサブセットが検証されます。クライアントは、特定の次のリリースが期待どおりに動作するかを検証するために、「エバーグリーン」環境にアクセスすることができます。これは、ロカッドとクライアント間のIT統合がある場合に発生する可能性があります。実際には、このような状況はまれです。

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

1.10 異なるバージョンはいくつ同時に存在できますか？

ロカッドは、すべてのクライアントに対して同じ一意のバージョンを実行するマルチテナントのSaaSですが、クライアントの要求に応じて任意の数の異なるバージョンを運用することができます。

1.11 クライアントはリリースから除外することはできますか？

ロカッドは、すべてのクライアントに対して同じ一意のバージョンを実行するマルチテナントのSaaSですので、リリースから除外することはできません。ただし、ビジネス的な観点からは、これは無意味です。なぜなら、任意の「変更」は、ロカッドソリューション内でEnvisionスクリプトの実行によって実装されるからです。

リリースを一時的に延期する場合は、リリース管理 1.1を参照してください。

1.12 リリースノートはありますか？クライアントに提供されますか？

はい。これらのノートは内部で共有されます（サプライチェーンの科学者チームと共有）。契約の一部として明示的に合意された場合、これらのリリースノートはクライアントに提供されることがあります。実際には、ロカッドプラットフォームのリリースノートは、Envisionコードを使用する人々にのみ興味があります。

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

当社のほとんどのクライアントは、「ソフトウェア+エキスパート」の提供を受けています。ロカッドのサプライチェーンの科学者チームがクライアントのサプライチェーンソリューションの実装とメンテナンスを担当しています。これらの状況は「サプライチェーンサービス」として知られています。このような状況では、クライアントは定期的に1人以上のサプライチェーンの科学者と連携します。また、ほとんどのクライアントは、週次または月次のステアリング委員会を利用して、現在のソリューションの状態と希望する進化について議論します。ロカッドは、これらの進化要求を収集し、変更の実装のためのロードマップを提案するためにこの方法を使用しています。

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

はい、ロカッドプラットフォームはプログラム的な性質を持っています。ロカッドの「分析」ロジックは、サプライチェーンの予測最適化のためにロカッドによって設計されたDSL（ドメイン固有言語）であるEnvisionスクリプトの形式を取ります。

したがって、ある意味では、すべてのパラメータの設定は、アカウント内のEnvisionスクリプトを活用することで利用できます。

2. パフォーマンス

2.1 SLA（サービスレベル契約）は99.xy％の稼働時間をカバーしていますか？

はい。SLAはデフォルトの契約の一部です。ただし、サプライチェーンの予測最適化を目的とした分散コンピュータシステムの文脈での稼働時間の概念は複雑です。次のシナリオを考えてみてください。- ロカッドにクライアントデータが送信される（毎日のステップ）が予定より2時間遅れている。これは通常のリソース割り当てヒューリスティックスの効率を大幅に損なう可能性があります。これにより、ロカッドのバッチジョブの実行にかかる時間が通常の60分ではなく75分に延長される場合があります。これは15分のダウンタイムと見なされるかもしれませんが、それは私たちの制御を超えています。

• ロカッドは同じクライアントデータを時間通りに受け取りますが、データに在庫レベルの大幅な減少がある場合。これにより、バッチジョブ（ロカッド側）が中断され、サプライチェーンの科学者に問題の調査がアラートされます。サプライチェーンの科学者は、自動補充オーダーが異例に大きいことを確認します。サプライチェーンの科学者は、クライアントからの直接の評価が必要であると判断します。翌日、クライアントは在庫データが破損しており、大量の在庫の廃棄につながる可能性があることを確認します。これは24時間のダウンタイムと見なされるかもしれませんが、実際の文脈では実用的には鈍感です。

サプライチェーンの最適化ソリューションにとって最大の危険は、少し遅れることではありません。それは「非常に間違っている」ことです。サプライチェーンの意思決定が行われると、（誤って）生産バッチをトリガーするなど、それを元に戻すことは非常に高価になる場合があります。私たちは、クライアントが単独の指標に恣意的に執着しないようにお客様にお願いしています。このような態度は、KPI（たとえばx.y％の稼働時間を満たしているように見える）を満たしている限り、全体的な劣った仕事を提供することを奨励する可能性があります。

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

はい、500ms未満ですが、注意事項があります。

私たちは「定数時間のダッシュボード」に相当するものを設計しています。裏側では、ダッシュボードの表示にはネットワークを介した単一のリクエストが必要であり、バックエンドではダッシュボードデータをすべてコロケートしてネットワークリクエストの数を低く保つようにしています（通常は一桁で測定されます）。この設計は、ダッシュボードの表示における典型的なユーザリクエストの低遅延を「保証」するために大いに役立ちます。この設計の選択肢は、ダッシュボードがタイルで混雑するのを防ぎ、各タイルがネットワークリクエストを必要とするため、全体的なユーザエクスペリエンスを遅くすることも防ぎます。

バッチジョブの実行時間に関しては、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プラットフォームは、SIMD（Single Instruction/Multiple Data）操作を介したCPUコアレベルでの並列化、マルチスレッド実行を介したCPUレベルでの並列化、および分散コンピューティングを介したクラスタレベルでの並列化を積極的に活用しています。並列処理はEnvisionのコア設計要素であるため、Lokadプラットフォームで実行されるほとんどのワークロードは、クライアントやサプライチェーンの科学者に特別な努力を必要とせず、デフォルトで広範な並列化の恩恵を受けることができます。

2.8 頻繁にアクセスされるデータをキャッシュすることはできますか？

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

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

はい、ほとんどのネットワークトラフィックを圧縮しています。ただし、すべてを圧縮することはできません。なぜなら、それはBREACH（ブラウザリコネーサンスおよびハイパーテキストの適応的圧縮による情報の漏洩）というセキュリティ上の脆弱性を引き起こす可能性があるからです。BREACHは、3つの要素の組み合わせが存在する場合に発生します。

1. レスポンスが圧縮されています。

2. レスポンスには秘密が含まれています。

3. レスポンスには、攻撃者がリクエストを作成する際に収集できる文字列が含まれています。

BREACHに対抗するため、Lokadは第3の条件が真であるすべてのレスポンスで圧縮を無効にします。また、ネットワークトラフィックを削減する以外の理由でもデータを圧縮しています。まず、データストレージコストを削減するために、そして次に、計算の遅延を削減するためです。

2.10 パフォーマンステストを行っていますか？

はい。Lokadには包括的な自動化されたパフォーマンス指向のインストゥルメンテーションレイヤーがあります。このツールセットにより、リリース前に次のバージョンのパフォーマンスデルタを現行バージョンと比較して評価することができます。このツールにより、本番環境で観測される作業負荷と同じものを再現し、その結果のパフォーマンスを監視することができます。ウォールクロック時間だけでなく、すべての関連する計算リソース（メモリ、帯域幅、I/O、CPUなど）を考慮しています。

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

はい。ただし、Lokadプラットフォームはトランザクションデータベースを使用していないため、「トランザクション」を監視する必要はありません（従来の意味で）。最も近い相当物はEnvisionスクリプトの実行です。これらのスクリプトでは、クエリプランの実行の詳細を監視することができます（トランザクションデータベースの観点からは）。

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

2.12 ソリューションに同時ユーザーがいる場合のパフォーマンスへの影響は何ですか？

ほとんどありません。Lokadの設計により、ダッシュボードは大量のユーザー（B2B基準）でも一定の時間でサービスを提供できるようになっています。このアプローチは、トランザクションデータベースやビジネスインテリジェンスキューブなど、多くの代替アーキテクチャとは対照的です。

ただし、個々のユーザーが（適切なシステム権限を持っている場合）任意の大きなワークロードをトリガーする可能性があるため、同時ユーザーの数はソリューションのパフォーマンスにおいては二次的な懸念事項です。サプライチェーンの予測最適化に関しては、関心のある分析を実行するために使用されるバッチジョブがワークロードの99％以上を占めています。残りの1％未満はユーザーリクエストの処理に割り当てられています。

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

はい。Lokadの観点からは、垂直および水平方向のスケーリングは補完的なものであり、Lokadプラットフォームの設計は両方を活用しています。内部のオーケストレータ（並列化を担当するもの）は通常、データの共有を大幅に容易にするために垂直スケーリングから始めます。その後、ワークロードが十分に大きい場合には、オーケストレータは水平スケーリングを活用します。

2.14 必要に応じてコンピュートとストレージを自動スケールしますか？

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

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

Lokadプラットフォームは、「ビッグデータ」処理に特化して設計されています。2023年1月現在、Lokadプラットフォーム全体で約1ペタバイトのデータを管理しています。当社のプラットフォームは、個々のファイルを最大100GBまで処理でき、数十億行のテーブルを定期的に処理しています。Lokadのセキュリティ 4.10に移動

このポイントは特に技術的な内容であり、このドキュメントの範囲を超えています。詳しい説明については、Victor Nicollet氏の4部作の記事「Envision仮想マシンの設計」をご覧ください。

2.16 Lokadのクラウドベースのソリューションは、帯域幅とレイテンシの制約（クライアント側）に応じて設定できますか？ 例：帯域幅= 3Mbps（ダウンロード）/ 1Mbps（アップロード）、レイテンシ= 600-800ms

はい、Lokadが設計したWebアプリは、接続が「低速」（帯域幅とレイテンシの両方）のシナリオをサポートできるように設計されています。これらの懸念は、基本的な技術設計の選択によって主に対処されます。これらのアーキテクチャ設計の選択肢によって、Lokadは一般的なソリューションとは異なります。帯域幅の懸念については、JavaScriptのサードパーティコンポーネントについては節約的です。最初に取得するアセットは1MB未満です。また、プラットフォームは、任意の単一のダッシュボードに含めるデータ量を完全に制御できるため、接続が低速な場合でも、ダッシュボードを適切に「軽量化」することが可能です。レイテンシの懸念に関しては、当社のダッシュボードは、関連するすべてのダッシュボードデータを単一のHTTPリクエストにパッケージ化するように設計されています。これにより、低遅延のエンドユーザーによる摩擦が最小限に抑えられます。

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

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

機械学習や数理最適化のステップを含む複雑な計算を行う際には、非常に高いスループットが重要です。データセットが非常に大きい（数十テラバイト）場合でも、運用の遅延を回避するためです。

2.18 ソリューションはどのサイズのメッセージを処理できますか？ 最小、最大、および平均値に関する詳細を提供してください。

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のソリューションは、イベントストアとコンテンツソースの両方のライブ増分バックアップによる連続データ保護設計を特徴としています。したがって、任意の時点でのポイントインタイムリカバリ（分単位まで）が可能です。

データセンターレベルの災害では、データが侵害されていない場合、RPOは1分です。これは、持続的なキーバリューストアの地理的に冗長な書き込みを活用することで実現しています。キーバリューストアが侵害された場合、Lokadはバックアップストレージから回復します（製品システムからできるだけ隔離された場所に保管されています）。この場合、RPOは12時間です。

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

はい、ただし、このタイプの問題は主にトランザクションデータベースに基づくソフトウェア設計を反映しています。Lokadのプラットフォームはトランザクションデータベースではなくイベントストアを使用しており、リレーショナルデータベースではなくイベントソーシング設計を採用しています。これにより、データの整合性を強制する必要がなくなりますが、これらの懸念は代替の方法で対処されます。

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

3.11 バックアップは定期的にデータの復元機能のテストが行われていますか？

はい。Lokadのイベントソーシング設計とコンテンツアドレス可能なストアにより、バックアップとデータの復元機能のテストは、SQLなどのリレーショナルデータベースを利用する一般的な設計よりもはるかに簡単に行うことができます。

Incidents 3.7も参照してください。

3.12 ディザスタリカバリプランは定期的にディザスタリカバリ機能のテストが行われていますか？

はい。Lokadの展開戦略は、エンドツーエンドの自動化スクリプトを活用しており、人間の介入は非常に少なくなっています。ただし、完全な本番再デプロイをトリガーする能力を持っています。この高度に自動化されたアプローチにより、ディザスタリカバリ機能のテストが容易になっています。

Incidents 3.8も参照してください。

3.13 個々の顧客および/または顧客環境のリカバリを実行できますか？

はい。内部ツールは、選択した顧客のアカウントを復元する可能性をサポートしています（アカウント/環境を特定の時点に復元することも可能です）。ただし、Lokadプラットフォーム自体が幅広いバージョニング機能を備えているため（たとえば、Envisionスクリプトはバージョン管理され、以前のバージョンはアプリ内からアクセスできます）、この機能はほとんど使用されません。

3.14 バックアップおよびディザスタリカバリプランは、顧客のRTO（リカバリタイムオブジェクティブ）、RPO（リカバリポイントオブジェクティブ）、およびディザスタシナリオの要件（関連するクライアントと合意したもの）を満たしていますか？

はい。ここでのリカバリタイムオブジェクティブ（RTO）は、Lokadのプラットフォームが理論的にダウンしても顧客に重大な損害を与えない時間のことを指します。また、重大なインシデント後にプラットフォームとそのデータを復元して通常の運用を再開するために費やされる時間も含まれます。

RTOは、Lokadがサポート/提供する具体的なプロセスの詳細に非常に依存します。たとえば、Lokadに月次の海外調達注文のスケジュールを依存している顧客は、RTOが1週間になる場合があります。逆に、Lokadによる倉庫から複数の店舗への毎日の在庫配送を最適化することに依存している顧客は、RTOが1時間になる場合があります。

実際には、理論的なダウンタイムを短縮するためにさまざまな技術的な手段を講じることができます。たとえば、フェイルオーバーの決定を事前に計算することができます。これらの決定は、Lokadプラットフォームが利用できない場合に使用することができます。通常の最適化された決定と比較して、フェイルオーバーの決定はわずかに供給パフォーマンスが低下する場合がありますが、それは（定義上）最新のデータを活用しないためです。

管理されたアカウントの場合、実際のインシデントが発生した場合に高いRTOを提供するだけでなく、実際のインシデントの場合に最小限のビジネスへの影響を保証するために、Lokadのサプライチェーン科学者とクライアントの運用チームが共同でプロセスを作成する責任があります。私たちの視点からは、この課題はITの問題ではなく、まずサプライチェーンの問題です。

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

4.4 使用するまたはサポートするデータベースシステムは何ですか？

Lokadは、フラットファイルのエクスポートを生成できるすべてのデータベースシステムをサポートしています。これには、古いモデルを含むほとんどの市場のデータベースシステムが含まれます。内部的には、Lokadはデータベースシステムではなく、キーバリューストアを使用しています。執筆時点（2023年1月）では、Microsoft Azureが提供するBlob Storageを使用しています。

4.5 使用しているキャッシュシステムは何ですか？

Lokadは、C＃/.NETで独自のキャッシュサブシステムを開発しました。これらのサブシステムは、他のソリューションと緊密に統合されており、リレーショナルデータベースのパフォーマンス問題を緩和するために主に意図されている従来のキャッシュシステムとは異なります（Lokadはそれを持っていません）。

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

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

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

主な技術的な前提条件は、在庫を追跡するトランザクションシステムです。また、クライアントがトランザクションシステムからデータ（フラットファイルとして）を抽出する経験があると便利ですが、これは必須ではありません。

4.8 Lokadのソリューションを運用するために必要な追加のサードパーティライセンスをリストアップしてください（例：OS、SQL、…）。

N/A. Lokadの運用には、サードパーティのライセンスは必要ありません。Lokadの統合をサポートするためのさまざまなオープンソースツールが存在するため、Lokadプラットフォームの利点を享受するためには、間接的にもサードパーティのライセンスは必要ありません。

4.9 サービスはブラウザプラグインや特別なソフトウェアを必要としますか？

LokadはWebアプリです。ブラウザプラグインや特別なソフトウェアは必要ありません。

4.10 アプリケーションのインバウンドおよびアウトバウンドインターフェースは何ですか？

Lokadのソリューションは、HTTPSを介してアクセスできるWebインターフェースと、SFTPおよびFTPSというファイルプロトコルを提供しています。

4.11 テナント間のデータ漏洩をどのように防止していますか？

Lokadのソリューションは、その設計自体によってテナントデータを分離しており、データ漏洩（たとえば、誤って発生する場合でも）が発生しないようにしています。さらに、本番環境に出荷されるすべてのコードはピアレビューされており、追加の保護層を提供しています。最後に、セキュリティ研究者（ペンテストを実施する人々）には、データリークの可能性を特に調査するよう指示しています。彼らには、本番環境をミラーリングした専用かつ完全に分離された環境で、複数のLokadアカウントへのアクセスを提供し、積極的にプラットフォームのこの特性をチェックしてもらいます。

4.12 ソリューションをコンテナ化できますか？

はい、しかし、Lokadのプラットフォームをコンテナ化することにはほとんど利点がありません。コンテナ化は、複雑な依存関係（トランザクションデータベース、独立したキャッシュシステムなど）がある場合に価値をもたらします。私たちは本番や開発でコンテナを使用せず、シェルスクリプトですら展開できるようにソリューションをシンプルに保っています。

4.13 GUIコンポーネントをバックエンドから切り離すことはできますか？

はい、GUIコンポーネント（この場合、Webインターフェース）は独立しています。この設計により、高い可用性を実現することができます。エンドユーザーは、他のサブシステムに突然のダウンタイムが影響した場合でも、Lokadアカウントのダッシュボードにアクセスすることができます。

4.14 Lokadアプリケーションはローカライゼーション機能（言語の変更など）をサポートしていますか？

はい、アプリケーションはローカライゼーション機能をサポートしています。Lokadのプラットフォームで生成されるすべてのユーザーインターフェースは、任意の言語でローカライズすることができます。特に、技術スタック全体がUTF-8を採用しているため、ラテン語以外のすべての文字セットに対応しています。特に、Lokadのプラットフォームで生成される任意のユーザーインターフェースは、納品後に別の言語に再ローカライズすることができます。

4.15 Lokadからの事後処理データの納品後にエンドユーザーが翻訳を更新または作成することは可能ですか？

はい、4.14を参照してください。

4.16 システムには組み込みのヘルプがありますか？もしある場合、どの言語で提供されていますか？

はい、Lokadには非常に詳細な公開ドキュメント（英語）が付属しています。ただし、Lokadプラットフォームの使用には、少なくとも2つの形式のドキュメントやヘルプが必要です。

まず、Lokadソリューション内で作成されたダッシュボードは、ダッシュボード自体から文脈に基づいたドキュメントを提供することを意図しています。特に、リッチテキストドキュメントに専用のMarkdownタイルがあります。次に、私たちの納品物には「共同手順マニュアル」が含まれています。このマニュアルは、ソリューションのメカニクスだけでなく、なぜ各要素が選択されたのか（およびそれがクライアントの特定のサプライチェーンのニーズを満たす方法）についての詳細な分析を提供します。

4.17 ウェブアプリはレスポンシブですか？

Lokadウェブアプリは、技術ドキュメントなどのサポート資料とともに、レスポンシブに設計されています。ただし、コードの編集などの高度な機能は、モバイルやタブレットデバイスでは実用的ではありません。したがって、デザインはPCおよび小型デバイスで予想されるアクティビティのレスポンシブ性を最大化することを目的としています。

4.18 システムがウェブアプリの場合、どのブラウザとバージョンをサポートしていますか？最小のインターネットブラウザの標準は何ですか？

Lokadはウェブアプリであり、Chrome、Firefox、Safariなどの主要な「エバーグリーン」ウェブブラウザをサポートしています。セキュリティ上の理由から、古いブラウザのサポートは試みていません。なぜなら、それらのブラウザのサポートは暗黙的にクライアントを危険にさらすからです。単純に言えば、脆弱なブラウザは悪意のあるアクターによってデータを外部に持ち出される可能性があります。とはいえ、新しいブラウザの機能に関してはかなり保守的です。一般的な基準として、すべての主要なウェブブラウザが少なくとも1年間で採用していないブラウザの機能をサポートしないようにしています。

4.19 モバイルおよびタブレットアプリケーションでは、LokadはどのOS（およびバージョン）をサポートしていますか？

N/A. LokadはSaaSとして提供されるウェブアプリであり、クライアントはOSのサポートに関心を持ちません。内部的には、LokadはWindowsで開発されており、すべての本番クラウドホステッド環境はLinuxで実行されています。したがって、Lokadソリューションの広範な移植性にはかなりの自信があります。現在この設定を変更する必要性を感じていませんが、有効な証拠が提示されれば、適宜適応します。

4.20 Lokadウェブアプリはエンドユーザーに通知を提供できますか？もしそうなら、どの技術/プロトコルを利用していますか？

はい、LokadはプログラマブルなHTTPフック通知を介して通知を送信する機能を持っています。これらのフックは、クライアント企業で既に使用されている場合が多いサードパーティのシステムを利用して、電子メール通知や適切と思われる他のタイプの通知を送信するために利用することができます。これらのフックは、LokadプラットフォームからSFTPまたはFTPSを介してデータを取得するためのデータの利用可能性を示すためにも通常使用されます。

4.21 ソリューションには、すべての顧客に共通の共有要素（モニタリング機能、バックアップ管理ソリューション、パッチ管理ソリューションなど）がありますか？

はい、Lokadはマルチテナントアプリケーションであるため、インフラレベルの機能はすべてのテナント（つまり、クライアントアカウント）間で共有されます。これには、稼働時間、パフォーマンス、セキュリティの監視、バックアップ、パッチ管理、アップグレードなどが含まれます。

4.22 ソリューションは、複数の宛先へのメッセージング機能（つまり、1つ以上の受信者またはアプリケーションにメッセージを送信する機能）を提供しますか？

Lokadプラットフォームはメッセージを使用しません。ただし、低コストのサードパーティシステムを通じて通常は複雑なメッセージ通知を生成するために使用できるHTTPフックの機能を提供しています。これらの通知は、サプライチェーンチームがLokadプラットフォームでミッションクリティカルな計算バッチのタイムリーな完了を監視するために使用されることがあります。

4.23 すべての重要なシステムとコンポーネントは、同じ時間ソース（NTP）を使用するか、他の信頼性のある方法でクロックを同期しますか？

はい。LokadはUbuntuに付属しているデフォルトのNTPサービスであるntp.ubuntu.comを使用しています。具体的には、ネットワーク経由でアクセスされる外部NTPタイムソースに対して同期するためにntpdがタイム同期サービスとして実行されています。

4.24 資産の在庫リストまたは構成管理データベース（CMDB）はありますか？

はい、私たちはプロセスをサポートするためのIT資産管理ソフトウェアを持っています。このプラットフォームは包括的な資産の在庫リストを維持し、構成管理データベース（CMDB）として機能します。このシステムを通じて、組織全体でハードウェアおよびソフトウェア資産を効率的に追跡、管理、割り当てることができます。チームは、任意の資産のステータス、場所、構成を迅速に特定する能力を持っており、変更、更新、または潜在的な問題に対して迅速に対応することができます。

さらに、当社のツールは、調達から廃棄までの詳細なライフサイクル管理を可能にする機能を提供しており、資産が正確にカタログ化されることを保証しています。詳細なレポート機能と組み合わせた自動監査機能により、IT環境全体の完全な可視性と制御を維持し、コンプライアンスと効率的なリソース割り当てを容易にしています。

4.25 外部ネットワークへのすべての接続はファイアウォールで終了しますか（インターネット、パートナーネットワークなど）？

いいえ、私たちは外部ネットワークへのすべての接続をファイアウォールで終了させることはありません。これは、そのような対策の効果と影響に関する現実世界の懸念に基づいています。

私たちの観点からは、ファイアウォールは通常、最前線の防御と見なされますが、皮肉なことに攻撃面積を拡大する可能性があります。統合するコンポーネントとシステムが増えれば増えるほど、潜在的な弱点も増えます。ファイアウォールはその性質上、高特権プロセスとして動作します。これは、サイバー攻撃の主要なターゲットになり、侵害されると深刻な結果をもたらすことがあります。具体例としては、SolarWinds攻撃があります。情報を保護するために設計されたシステム自体が悪用され、重大な侵害が発生しました。

さらに、厳格なファイアウォールの存在は、実践的な意味でも逆効果になることがあります。私たちの経験から、このようなシステムは往々にして従業員が情報にアクセスし共有するための代替手段を求めることを促進します。これは通常、企業ネットワークを完全にバイパスする（したがって、監視を防止する）ことを意味し、個人のデバイスからの個人的な4Gまたは5G接続を使用します。このような慣行は、セキュリティ侵害やデータ漏洩のリスクを意図せずに増加させることになります。

したがって、私たちはセキュリティに深い関与を持っていますが、私たちのアプローチは従来の手法にのみ頼るのではなく、実践的な懸念に基づいてホリスティックなものです。

4.26 ネットワークには、ウェブサーバー、DNS、ディレクトリサービス、リモートアクセスなどの重要なシステムとクライアントデータを送信、処理、または保存するDMZ環境がありますか？

いいえ、Lokadはネットワーク内で重要なシステムとクライアントデータを送信、処理、または保存するための従来のDMZ環境を使用していません。代わりに、私たちはネットワークセキュリティにゼロトラストアプローチを採用しています。

このモデルはDMZに依存せず、「信頼しない、常に検証する」という原則に基づいて動作します。すべてのアクセスリクエストは、組織内外のどこからであっても、その起源に関係なく検証され、認証されます。

これにより、DMZのような周辺防御に依存せず、各個別のアクセスポイントとデータトランザクションのセキュリティを確保するため、より堅牢でホリスティックなセキュリティポジションが確保されます。私たちは、ゼロトラストアプローチが重要なシステムとクライアントデータの優れた保護を提供すると考えています。