FTP、CIFS連携排他制御におけるファイル排他制御

送信側と受信側のサーバー間で、ファイルをやり取りする方法にはいくつかあり、有償のソフトで有名なものでは「HULFT」などがある。ただし、よほどシビアな要件でもない限り、FTP や CIFS、最近では REST 通信などの無償で作れる仕組でファイル連携を実現するシステムが多いだろう。

上で挙げた無償の仕組みで実装する場合、配慮しなければいけないのがファイルの排他制御である。例えば送信側がファイルを送信中の状態で受信側がファイルを読み始めると、中途半端な状態のデータを読むことになりデータの不整合が発生する。

このような問題に対処するため、多くのシステムではファイルの排他制御を行い、送信側がファイルを送信し終わるまで、受信側がファイルを読み始めないように制御している。この記事では、これまで筆者が実際に体験したファイル連携時の排他制御の方式について、いくつか紹介する。

送信終了を通知するファイルを最後に送る

システム開発者の界隈では「END ファイル」または「トリガーファイル」と呼ばれている仕組みで、送信側がメインのファイルを送り終わった後に、同じファイル名の拡張子が「.end」のファイルを置いて、送信終了を受信側に伝える方式である。

例えば「data.dat」という名前のファイルを送信する場合、対象の「data.dat」を受信側に送った後に、「data.end」という名前で中身が空（０バイト）のファイルを受信側に続けて送信する。そして受信側は、拡張子が「.end」のファイルを定期的に監視して、検知したら拡張子を除いたファイル名が同じ「data.dat」の読み込み処理を始める。

シーケンス図で表すと、次のような流れになる。（逆にわかりにくいかも…）

補足しておくと、送信終了のトリガとなるファイルの拡張子「.end」は決められたものではないため、別にどんな拡張子でもよい。送信側、受信側の取り決めさえしておけばよい。

一時的な拡張子で送信中する

上の END ファイル方式と似ているが、送信中は対象のファイルの拡張子を「.tmp」などの一時的なものにし、送信完了後に正規の拡張子に変更する方法でも排他制御が実現可能である。この場合、受信側は拡張子が「.tmp」以外のファイルを監視することで、送信中のファイルに対して誤って受信側がアクセスすることが無くなる。

例えば「data.dat」という名前のファイルを送信する場合、一旦「data.tmp」というファイル名で相手システムに送信し、送信完了に拡張子を本来の名前（data.data）に戻す。受信側としては、拡張子が「.tmp」以外のファイルを監視して処理を行う。

これもシーケンス図で表してみる。

そもそもFTPでファイル連携するべき？

ちゃぶ台返しとなるが、インターネットの意見を見ると「そもそも FTP や CIFS でファイル連携を実現すべきでない！」と言う意見が多い。確かに FTP の歴史は長く、単純なファイル転送のプロトコルであるため、セキュリティや、ポートの問題などもあり、重要な情報を扱うシステム間のデータ連携には不向きともいえる。

今だったら、REST で API を作る方法や、Redis などのキューの仕組みを使った方式の方が、順序性やセキュリティも担保できる。ただ、FTP の手軽さに比べると、これらの方式はサーバーの準備や、実装も少し手間な部分もある。

最もつらいのが、受信側のシステムを新規に作る時、送信元のシステムが FTPにしか対応していない場合、せっかくの新規構築なのに FTP 連携するハメになり、それが負のスパイラルのように続いていくことである。