SFTPで、データへのAPIが整備されていない複数の関係者間での安全なデータ共有が驚くほど簡単になります。本記事で詳しく見ていきましょう！
ETL（抽出、変換、格納）は、データを扱う組織にとって重要な役割を担っており、ETLのプロセスでは、さまざまなソースからデータを抽出してモデルやデータ構造へ変換し、その構造をデータベースに格納します。この、通常「データウェアハウス」と呼ばれるデータベースは、クエリやレポーティングのプロセスをより速く簡単にすることで、より良いビジネス上の意思決定をサポートします。
ETLという考え方は１９７０年代からずっと一般的であり、ETLプロセスのオーケストレーションに対応するツールやフレームワークが存在することは、何も驚くことではないでしょう。多くの組織では、既存の Informaticaや Fivetran 、 Xplentyといった新時代のクラウドソリューションのような商用ETL製品が活用されていますが、様々なプログラミング言語やフレームワークを使って独自のツールを構築する組織もあります。
かつて多くの企業では自社のデータ分析のためにETLを利用し、自社で保有するさまざまなデータソースからデータを単独のデータウェアハウスに集め、ビジネスをより明確に把握することができていました。そして多くの場合、それらはSQLを使ったデータベースからのデータ取得というものでした。
近年では、企業は社内のデータベースに存在するデータと、利用するサードパーティーのサービスによって集められるデータを組み合わせないといけません。例えば、SalesforceやPipedriveなどの CRM （顧客関係管理）を利用している組織では、このようなサービスから顧客に関するデータを取得する必要があり、Facebook広告や Google 広告をマーケティングキャンペーンに利用している組織は、キャンペーンの成功に関するデータをこのサービスから引き出す必要があります。
この作業は、さまざまな技術が絡んできますし、API（データへのインターフェース）もデータそのものも企業の所有物ではないため、はるかに複雑です。また、このようなサードパーティは、データのインターフェースやデータ構造を変更する可能性があり、ETLプロセスを壊す可能性があります。
では、分析したいデータへの APIを提供していないベンダーや顧客からデータを引き出すのはどうでしょうか？
そこで登場するのが SFTPです。SFTP（セキュアファイル転送プロトコル）は、２０年以上の歴史があり、ファイル転送のための標準的で安全なプロトコルであると広く考えられています。 そしてその普及により、SFTPは組織内や組織間で安全にファイルを共有するためのデファクトスタンダードとなっています。
SFTPは、その前身である FTP（ETLの概念と同じくらい古い）と同じくらいシンプルですが、セキュリティの面でも大きな進歩を誇っています。このことが、一般ユーザーによるSFTPサーバーへの接続も、IT担当者によるファイル移動の大まかな自動スクリプト作成もできるあらゆるOS上で、 SFTPがGUI（グラフィカルユーザーインターフェース）やCLI（コマンドラインインターフェース）ツールによって広くサポートされる所以です。さらに、SFTPサーバーへのスムーズな接続を可能にする、あらゆるプログラミング言語用のライブラリやSDK （ソフトウェア開発キット）も用意されています。
また、大企業との取引では、ファイルの安全な受け渡し先として SFTPを利用することがデフォルトとなっていることも、SFTPの普遍的な普及の一例です。SFTPは、認証やデータ転送を暗号化することで、企業に対して高い信頼性を提供しているのです。
加えて、長い歴史や信頼性の高さも、企業で広く使われている理由のひとつです。また、追加開発を必要としないため、他の方式に比べてセットアップにかかる時間が大幅に短いです。時間は貴重な資源ですからね。
なので、ETLプロセスにおいて、データの受信やベンダー、顧客、その他のサードパーティへの送信が必要な場合、SFTPは貴重なソリューションとなります。その信頼性、効率性、そして企業の間で頻繁に使用されていることから、データの転送方法として多くの人々に使われています。また、ソースとデスティネーション間のプロトコル、方法、中間ストレージとしてSFTPを選択する場合、データ構造にも合意する必要があります。
最近では、ファイルにはデータのスキーマも記述されているので、JSONや JSONL形式（JSON Linesや改行区切りの JSON）でデータをファイルに保存するのが一般的であり、後方互換性を保ちつつ、時間とともに進化する動的スキーマにも対応できます。
SFTP To GoのSFTPクラウドソリューションは、ETLやデータ処理プラットフォームで使用する場合、以下のように通常のSFTPよりも優れた機能が備わっています：
- マルチプロトコルに対応：ユーザーやアプリケーションは、データファイルの読み書きに必要なプロトコルを選択できる。SFTP がデフォルトのプロトコルである一方、FTPS も使うことができ、それが組織によってはより顕著である場合もある。また、Amazon S3も有効な選択肢であり、Amazon Athenaを通じて直接データを照会したり、Amazon EMR、Spark、Map/Reduceを使ってスケーラブルなデータ処理を実行することも可能。
- ファイルシステムの変更に関するWebフックの通知：多くの場合、ETLプロセスは時間ベースのスケジューラによってトリガーされ、スケジュールされたコマンドとして、例えば「顧客データを深夜に読み込む」のようなものがある。Webフック通知を使えば、SFTPストレージにファイルが落とされるたびに、プログラムによるトリガーを使ってETL処理を開始することができる。それにより、データ処理が随時可能になり、必要な処理能力を拡張できるようになる。（例：新しいファイルがないときはリソースを使わない、多くのファイルがアップロードされたときはリソースを多く使う、など）
- 容量無制限：どのストレージでも懸念されるのはディスク容量であり、中間ストレージやターゲットとなるデータウェアハウスのディスク容量が不足することによる ETL の破綻がよく起こる。対する SFTP To Go のストレージは事実上無制限であり、閾値を超えたら知らされることから、ディスク容量不足を心配する必要がない。
