なぜ REST ではなく FTP を選んだのか

Joannes Vermorel

Lokad プラットフォームはテラバイトスケールのデータ処理を対象としており、予測的なサプライチェーン最適化を目的としています。しかし、データを処理するためにはまずデータをインポートする必要があります。ほとんどのウェブアプリは REST スタイルのウェブ API を採用していますが、Lokad は FTPS と SFTP を採用しており、これは驚くかもしれません¹。この選択は偶然ではなく、データ転送のパフォーマンス要件によるものです。この選択は10年前に以前の経験に基づいて行われましたが、FTP の利点は今でも変わらず強力です。

Lokad のユースケースを明確にしましょう。典型的なクライアント企業は、10から100のデータベーステーブルの完全なコピーを、1つの Lokad アカウントに転送する必要があります。各テーブルには5から500のフィールドがあり、これらのデータは ERP、MRP、WMS、POS などの内容を表しています。時間の経過とともに、コピーは通常昨日の日付よりも新しいものでなければなりません。圧縮されていないフラットテキストファイル（CSV）を想定した場合、関与するデータの総量は、中規模企業では1GB、大規模企業では10TBに及びます。大きなテーブルに対しては増分データ転送を採用することで、1日あたりの転送量は通常100MBから10GBの範囲になります。

クライアント企業 - またはそのソフトウェアベンダー、またはベンダーの統合業者 - は、関連するデータを Lokad に正常に送信する必要があります。実際には、ほとんどの場合、Lokad はいかなる本番システムにも IT アクセスを取得しません。これは合理的なことです。セキュリティ上の理由から、サードパーティの分析ツールは本番システムへの直接アクセスを持つべきではありません。クライアント企業は、システムから流れ出るデータのゲートキーパーとして制御を保持する必要があります。さらに、これにより、Lokad のようなサードパーティが必要としない個人データのすべてのビットを削除することができます。

理論的には、REST は任意のパフォーマンスを実現することができます。しかし、実際にはそうではありません。REST を使用して、毎日100MBの細かい関係データを信頼性を持って転送すると、必ず大きなパフォーマンスのオーバーヘッドが発生します。これには、ネットワーク上の呼び出しの数に関連する「チャッティネス」と、一時的なネットワークの障害に対処するために必要な動作に関連する「リトライ」の2つの側面が最も注意深く扱われる必要があります。両方とも、実際には非常に困難です。

エンタープライズ空間では、ほとんどのソフトウェアベンダーは、自社の API についてさえも正しいページングを実現できません。同じベンダーが Lokad のクイックで手抜きの統合を展開する際に、突然トップクラスのソフトウェアエンジニアリングの人材を割り当てるという提案は合理的ではありません。Lokad での私の経験からは、むしろ急いで行われる IT ジョブが Lokad が期待できる最高のものです。これは問題ありません。IT の面で戦うべき課題はたくさんあります。現実的には、Lokad のデータ統合は、エリート部隊を投入する必要のある戦いではないと考えられます。

実際には、まともなパフォーマンスを得るための圧力がかかると、ウェブ API は HTTP を介したフラットファイルの転送に退化します。この退化は、上記で言及した「チャッティネス」の側面に対処します。ただし、「リトライ」の側面はまだ解決されていません。一度「リトライ」の側面も解決されれば、おめでとうございます、API はついにファイル転送プロトコル（FTP）を再発明しました。

ただし、この臨時のFTPは本物とは比べ物にならないほど計測されていません。FTPはすべての主要なオペレーティングシステムでサポートされています。両方とも大規模なオープンソースのツールサポートがあります。関連する実装は数十年にわたって本番グレードで使用されてきました。確かに、それらのプロトコルにはクセがあり、それらはもはや「流行」ではないかもしれませんが、数時間以内に仕事を完了させるという点では、ロックスターエンジニアを巻き込むことなく、比較にすらなりません。

これが、LokadがFTPを採用して受信および送信データの転送をサポートしている理由です。さらに、10年にわたる運用の結果、この選択が正しかったことが証明されています。低いスキルと低コストのアウトソーシングされたIT企業でも、FTPを介してLokadに大量の関係データを迅速かつ信頼性高く転送することに成功していますが、これは、ウェブAPIを提供していたすべての年の間に、一度も起こりませんでした。