なぜRESTではなくFTPなのか

Joannes Vermorel

The Lokadプラットフォームはテラバイト級のデータ処理に対応し、予測 サプライチェーン最適化 を目指しています。しかし、データ処理を行うには、まずデータをインポートする必要があります。ほとんどのウェブアプリケーションはRESTスタイルのWeb APIを採用していますが、LokadはFTPSとSFTPを採用しており、これは驚くべきことに見えるかもしれません¹。この選択は偶然ではなく、データ転送パフォーマンスの要件によって決定されました。十年前に 以前の経験 に基づいて下された決定にもかかわらず、FTPを支持する理由は今なお非常に強力です。

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

The クライアント企業、またはそのソフトウェアベンダー、あるいはベンダーの統合業者は、関連するデータをLokadに確実に転送しなければなりません。実際、多くの場合、Lokadは生産システムへのITアクセスを一切得られません。これは、セキュリティ上、第三者の解析が生産システムに直接アクセスすべきではないため、理にかなっています。クライアント企業は、自社システムから流出するデータの門番として、その管理権を常に保持しなければなりません。さらに、この仕組みによって、Lokadのような第三者に必要とされない個人データをすべて除去することが可能になります。

理論上、RESTは無限に高いパフォーマンスを発揮できるはずです。しかし、実際にはそうはいきません。毎日100MBの細かいリレーショナルデータを確実に転送するためには、優秀なソフトウェアエンジニアリングチームが関与しなければ、必然的に莫大なパフォーマンスオーバーヘッドが発生します。特に、ネットワーク上の通信の多さと再試行の対処という二点を極めて慎重に管理する必要があります。どちらも現実には非常に困難です。

エンタープライズ領域では、ほとんどのソフトウェアベンダーでさえ、自社のAPIにおけるページングすら適切に実装できていません（詳細はこちら）。この、手早く雑なLokad統合の後に、突然卓越したソフトウェアエンジニアを投入するという仮定は、現実的ではありません。私のLokadでの経験から言えば、むしろ急ごしらえのIT案件こそが、Lokadにとって常態なのです。これは問題ではありません。IT分野には戦うべき山ほどの課題があります。実際、Lokadのデータ統合は、エリート部隊を動員するほどの唯一の戦いであるとは考えられていません。

実際、十分なパフォーマンスが求められると、Web APIはHTTP上でのフラットファイル転送へと退化します。この退化は、前述の通信の多さという問題に対処するためのものです。しかし、それでも再試行の問題は残ります。一度再試行の問題にも対処できれば、ついにAPIはファイル転送プロトコル（すなわちFTP）を再発明したことになるのです。

しかし、このアドホックなFTPは、本物ほど充実した機能を持っていません。FTPはすべての主要なオペレーティングシステムでサポートされ、広範なオープンソースツールの支援を受けています。関連する実装は何十年も前からプロダクショングレードで運用されてきました。確かに、多少の癖はありますし、もはや「流行」のプロトコルではありませんが、数時間以内に優秀なエンジニアを動員せずに仕事を終わらせるという点では、他の手法に到底かなわないのです。

このため、LokadはFTPを採用し、受信および送信のデータ転送の双方をサポートしています。さらに、10年以上にわたる運用実績が、この選択が正しかったことを裏付けています。実際、低スキルで低コストなアウトソーシングIT企業でさえ、FTPを利用することで大量のリレーショナルデータを迅速かつ確実にLokadへ転送することに成功しており、これはLokadがWeb APIを採用していたすべての期間において、一度も実現しなかった事例です。