問題点
ユーザーからファイルを安全に交換する方法を求める声がありました。本日、新しいオープンソースのファイルサーバーモジュールを発表することを誇りに思います。Psono のエコシステムの最新コンポーネントとして、次のような複数の問題を解決します：
- メールで共有されるファイルが大きくなりすぎる。通常は 20MB 以上は拒否されます。
- SFTP または GPG メールなどを使って他者にファイルをアップロードするのは、通常のユーザーにとっては複雑すぎる。
- Google ドライブや Dropbox を使用してファイルをアップロードすることは、機密データにとって問題となる場合がある。
- 内部社員 (例えば、ファイルサーバーの管理者) からの人事部や管理部の情報保護。
- ハッカーがファイルサーバーにアクセスするリスク。
- リモートオフィス環境での帯域幅の問題。すべての社員が小さなオフィスのファイルサーバーからファイルをダウンロードする際に発生します。
これらの問題を考慮して設計されたのが Psono です。非常に柔軟性があります。
ユーザビリティ
では、ユーザーにとってどのように見えるのでしょうか。簡単です。
- ユーザーはウェブクライアントにアクセスします。
- ファイルを選択します。
- 「アップロード」ボタンをクリックします。
- 必要であれば、右クリックで共有することもできます。
これなら十分にシンプルであることを願っています。
内部の仕組み
内部ではクライアントがいくつかのより複雑なステップを実行しますが、すべてユーザーには隠されています：
- クライアントはサーバーに利用可能なすべてのファイルサーバーを尋ねます。
- サーバーはリクエストを評価し、さまざまなユーザー属性 (許可、IP、アクセス権) に基づいて、適切なシャード (ファイルの場所) およびファイルサーバーを決定します。
- サーバーはファイルアップロードチケットを作成します。
- クライアントはファイルのサイズを読み取ります。
- クライアントはサーバーにファイルとシャードのアップロードを通知します。
- ファイルが大きすぎる場合、クライアントはファイルを最大 128MB のチャンクに分割します。
- クライアントはチャンクを暗号化します。
- クライアントはチャンクのチェックサムを計算します。
- クライアントはファイルアップロードチケットと共にチャンクをファイルサーバーにアップロードします。
- ファイルサーバーはアップロードチケットをサーバーに送信します。
- サーバーはチケットを検証します。
- ファイルサーバーはチャンクのアップロードを受け入れます。
- クライアントはすべてのチャンクを処理するまで次のチャンクに進みます。
- クライアントはデータストアを更新し、暗号化し、サーバーに送信します。
このメカニズムにより、ファイルがチャンクに分割されるため、任意のファイルサイズの問題を解決できます。単一のファイルであっても、アップロードを複数のサーバーに分散できます。すべてのファイルは (Psono のすべてのアイテムと同様に) クライアントを出る前に暗号化され、サーバーに送信されます。
典型的な Psono ファイルサーバーのセットアップ
上部は典型的なセットアップを示しています。リレーサーバー (シンプルなリバースプロキシ) がいくつかの静的ファイル (ウェブクライアント) を提供します。ウェブクライアントはブラウザに提供され、ブラウザはサーバー上の REST API エンドポイントを呼び出します。サーバーは永続的なデータを保存するために Postgres データベースを使用します。Psono ウェブクライアントおよび Psono サーバーはステートレスと見なされ、すべてのデータは Postgres データベースに保存されます。
ファイルサーバーを追加する場合、まずサーバー上でシャードおよびクラスター構成を作成し、それを使用して実際のファイルサーバーを構成します。ファイルサーバーが起動すると、自動的に登録され、10 秒ごとに可用性を通知し続けます。ファイルサーバーが停止した場合、サーバーはこれを認識し、クライアントを停止します。再起動すると、自動的に再登録され、クライアントのリクエストを再受信します。上の図では、すべてのチャンクをローカルストレージに保存し、リレーサーバー (小規模な環境では通常のサーバーと同じものを使用できます) を SSL オフロードのために使用しています。
ローカルストレージに加えて、さまざまなストレージバックエンドを使用し、それらを混在させることもできます。
さまざまなストレージバックエンドの混在
現在サポートされているのは (ローカルストレージに加えて) Amazon S3、GCP Cloud Storage、Azure Blob Storage です。
帯域幅の制限により、パフォーマンスの問題を解決するために複数のファイルサーバーを使用できます。例えば、リモートで作業している人が多く、オフィスのインターネット接続が非常に細い場合など。また、ローカルファイルをさらに保護し、以下を許可しない設定が可能です：
- 内部ファイルを外部ストレージにアップロードすることを許可しない。
- 外部から内部とのファイル共有を別のツールを使わずに可能にする。
パフォーマンス問題を解決し、より良い分離を提供するセットアップは次のようになります：
リモートロケーション
このセットアップは、「外部」シャードのすべてのトラフィックをサイト間で双方向に共有し、外部からファイルをアップロードして、その後社員がダウンロードでき、逆もできます。
一方、オンプレミスのシャードはリモートロケーションと同期されることはなく、より良い保護を維持します。「外部」シャードのファイルは変更時に一度だけ同期され、100 人の社員がこのシャードからファイルをアクセスしてもリモートロケーションから 100 回ダウンロードする必要はありません。同様に、ファイルをアップロードすれば、100 人の外部ユーザーとファイルを共有でき、100 回アップロードする必要はありません。
この帯域幅の利点を利用して、リモートロケーションを次のように接続することもできます：
2 つのリモートオフィス
このセットアップでは、各サイトにファイルサーバーがあり、すべてのファイルがサイト間で共有されます。書き込みは特定のシャードにのみ行われ、各シャードの一方向の同期が可能です。このセットアップにより、ニューヨークのスタッフが遅延なくファイルにアクセスできます。
次の大きなポイントは負荷分散です。これらのセットアップは 1000 人の社員が定期的にファイルサーバーにアクセスする場合でも帯域幅の制限を引き起こします。しかし、幸いなことに Psono はこれを処理できます。Psono のファイルサーバーには負荷分散のための 2 つのオプションがあります。
すでにロードバランサーを使用している場合、セットアップは次のようになります：
ロードバランサー付きの負荷分散ファイルサーバー
このセットアップでは、SSL オフロードのためにロードバランサーを使用します。背後にはリクエストを処理する 2 つのファイルサーバーがあり、両方とも同じシャードを知らせるので、シャードを同期するか共有ストレージを持つ必要があります。GlusterFS やシンプルな rsync を使用することができます。
もう一つのオプションは、クライアントがすべてを負荷分散し、セットアップやコストを節約することです。追加のロードバランサーなしのセットアップは次のようになります。
ロードバランサーなしの負荷分散ファイルサーバー
これらのセットアップはスタックでき、例えば、3 つのクラスターそれぞれに 2 つのサーバーを持つことができます。各クラスターは同じシャードをサーブし、基盤となるストレージは同期された (または共有された) 状態で運用されます。
Psono の新しい強力なファイルサーバーモジュールの機能について、良い印象を持っていただけたことを願っています。
