Google CloudでFTP/SFTPサーバーを立てるには — マネージドなしでの現実的な4構成

Google Cloudには、AWSの「AWS Transfer Family」のようなネイティブのマネージドFTP/SFTP/FTPSサービスは存在しない。「Cloud FTP」という名称の公式サービスもない。取引先からFTPやSFTPでファイルを受け取りたい、あるいは送りたいという要件がある場合は、標準機能を組み合わせて自前で構成するか、サードパーティ製品を使うか、FTPサーバーという形態自体を無くすか、という選択を迫られる。

現実的な選択肢は4パターンに整理できる。①Compute Engine＋gcsfuseの自前構成、②OSSのSFTPGoを使う構成、③GCP MarketplaceやSaaSのマネージドSFTPを使う構成、④FTPサーバー自体を無くしスクリプトやワークフローに置き換える構成である。以下、それぞれの仕組みと向き不向きを見ていく。

最も一般的なのが、Compute EngineのVM上にFTP/SFTPサーバーソフトを立て、gcsfuseでCloud Storageバケットをファイルシステムとしてマウントする構成である。gcsfuseはGoogle公式のFUSE実装で、バケットをあたかもローカルのディレクトリのようにOSにマウントできる。取引先がSFTPやFTPSでファイルをアップロードすると、サーバーソフトはマウントされたディレクトリに書き込むだけでよく、実体は自動的にバックエンドのCloud Storageバケットに保存される。

サーバーソフトは、SFTPならVMのOSに標準で入っているOpenSSHのSFTPサブシステムをそのまま使え、FTP/FTPSが必要ならvsftpdなどを別途導入する。取引先→SFTP/FTPS（ポート22または21/990）→gcsfuseマウント→Cloud Storageバケット→後段の変換・仕分け・バックアップ処理、という流れが基本構成になる。バケットに入った時点でCloud Functionsやライフサイクルルールにつなげやすいのが利点である。

注意点として、gcsfuseはPOSIXに完全準拠したファイルシステムではない。パーミッション変更やシンボリックリンク、複数クライアントからの同時書き込みは、ローカルディスクと同じ感覚では扱えない。大量の小ファイルを高頻度でやり取りする用途や厳密なファイルロックが必要な用途では、事前に制約を確認しておきたい。

ここまでの内容を含め、4つの構成パターンを比較すると次のようになる。構築のしやすさを優先するか、運用の手間を減らしたいか、取引先の要件がFTP・FTPS・SFTPのどれかによっても向き不向きが変わる。

SFTPGoはGo言語で書かれたOSSのSFTP/FTPS/WebDAVサーバーで、ストレージバックエンドにローカルディスクだけでなくCloud Storageを直接指定できる点が特徴である。Compute Engineの小型VMで動かすほか、コンテナ化してCloud Run等で小規模運用もできる。仮想ユーザーの作成やディレクトリ権限、容量クォータの管理機能がアプリケーション側にまとまっているため、取引先ごとにアカウントを発行し個別管理したいケースで扱いやすい。ライセンス費用はかからないが、導入・アップデート・障害対応は自前になる。

自前でサーバーを構築・保守する手間を避けたいなら、サードパーティ製品も選択肢になる。GCP Marketplaceには、Cloud Storageをバックエンドにしたゲートウェイ型のFTP/SFTPサーバー製品として、Thorn Technologies社のSFTP GatewayやFileMage Gatewayなどが公開されている。VMイメージとしてデプロイし、GUIで設定できる点が特徴である。また、SFTPCloudやCouchdropのように、Cloud Storageをバックエンドにしたマネージド型SFTPをSaaSで提供する製品もある。料金は製品ごとに異なるため、転送量やユーザー数に応じて個別に見積もる必要がある。

用途によっては、常時稼働するFTP/SFTPサーバー自体を持たない方が運用はシンプルになる。特に片方向の定期転送や、単純なファイルの受け渡しであれば、次のような代替手段が使える。

- Cloud Composer（Apache Airflow）のSFTPToGCSOperator: 取引先のSFTPサーバーから定期的にファイルを取得しCloud Storageへ転送するワークフローを組める公式プロバイダのオペレーター
- Cloud Functions＋Cloud Scheduler: 決まった時刻にスクリプトを実行し、取引先サーバーへ取りに行く／送りに行く処理を実装する構成
- Cloud Storageの署名付きURL: 単なるファイル共有なら、有効期限付きURLを発行して直接アップロード・ダウンロードしてもらうだけで済むこともある

どの構成を選ぶ場合でも、共通して押さえておきたい注意点がある。

- 素のFTP（21番・平文）は非推奨。SFTP（22番）またはFTPSを前提にする
- Compute Engineでの自前構築は、ファイアウォール・固定IP・鍵認証（パスワードより優先）・パッチ運用が自前の責任範囲になる
- Cloud Storage側はサービスアカウントとIAMで最小権限を徹底し、取引先ごとのアクセス範囲を分けることも検討する
- gcsfuseはPOSIXに完全準拠していないため、パーミッションや同時書き込みの制約を事前に確認しておく
- コストの目安は構成で大きく異なる。A/Bは小型VM＋保存料が中心で月数百円〜数千円程度から。Cは月額課金、Dは実行分のみが一般的で、構成や転送量による目安と捉えておく

AWSにはAWS Transfer Familyという、SFTP/FTPS/FTPをマネージドで提供しS3をバックエンドにできるサービスがある。Google Cloudにはこれに相当するネイティブサービスがないため、受け口自体をマネージドで持ちたいことが最優先なら、その一点でAWSを選ぶ判断もあり得る。一方、他のインフラがすでにGoogle Cloud中心なら、本記事の4構成のいずれかで受け口を作る方が全体をシンプルに保ちやすい。FTP受け口だけAWSに置くマルチクラウド構成もあり得るため、優先条件に応じて中立に比較したい。

印刷業の入稿、EDI、メディア納品など、取引先の指定でFTPやSFTPが今も残る業界は少なくない。自社の意思だけではプロトコルを変更できない場合、受け口はFTP/SFTPのまま残しつつ格納先だけをクラウドのオブジェクトストレージに寄せる、という発想が現実的な落とし所になりやすい。受信ファイルがCloud Storageに入れば、変換処理や仕分け、バックアップ、ライフサイクル管理（自動削除や低頻度アクセスストレージへの移行など）につなげやすい。取引先都合で残るレガシーなプロトコルを、後段の自動化のきっかけとして活用する考え方である。

Google CloudにはネイティブのマネージドFTP/SFTPサービスがない。受け口が必要なら、Compute Engine＋gcsfuse、SFTPGo、Marketplace製品やSaaS、FTPサーバー自体を無くす、という4つの選択肢から運用体制に合わせて選ぶことになる。詳しい比較はS3・R2・Azure Blob・GCSのオブジェクトストレージ比較も、基礎は中小企業のためのGoogle Cloud入門も参考にしてほしい。gcsfuseは公式ドキュメント、SFTPGoはGitHubリポジトリを参照。