現在、クライアントがファイルを FTP で送信し、inotify (Linux カーネル通知経由) がトリガーされて、それらのファイルに対してアクションを実行する解析がトリガーされるシステム設定になっています。現在、パーサーが 1 つの EC2 インスタンスの I/O 容量に達しており、ファイル ロードを分割するためにノードを追加したいという問題が発生しています。残念ながら、クライアントは FTP 経由でしかアップロードできません。そのため、ファイルがドロップされている EBS ボリュームを共有しない別のインスタンスでそのファイルを処理する方法がわかりません。
現在、FTP を使用するクライアントに影響を与えず (IP の変更は問題ありません)、複数の EC2 インスタンスがファイルシステムにアクセスできるようにする AWS ソリューションはありますか?
答え1
もちろん...
いずれかのタイプの複数のボリュームを接続してストライプ化することで、Amazon EC2 アプリケーションで利用できる I/O パフォーマンスを向上させることができます。
私が使用したことがあるのは、EBS ボリュームの RAID-10 ですが...、そのことについては既に考えたことがあると思います。
FTPサーバーをスケーリングするには、次のような方法をお勧めします。HAプロキシUbuntu にバンドルされているユーティリティ (FTP パケットを書き換えて、そのプロトコルに内在する不合理性の一部を修正できます) を使用することもredirできますが、FTP の扱いにくい複数接続の性質により、複雑な提案になる可能性があり、実際には望んでいるものではないかもしれません。
では、s3fs はどうでしょうか?
これを提案する前に、私はグーグルで次のようなものを見つけましたこの郵便受けこれは動作しない可能性があることを示唆していましたが、その後、その場合の OP は S3 とファイルシステムが実際にどのように動作するかについての理解が著しく不足しているようであり、inotify が外部原因 (ローカルファイルシステムをトラバースしていない) によって S3 でリモートで変更があったことを認識することを期待していたことに気付きました。もちろん、これは意味がありません。
しかし、テスト用のコードをいくつか書いてみたところ、s3fs は確かに inotify と正しくやり取りしているようです。FTP サーバーから EBS ボリュームの代わりにバケットをマウントして、クライアントが FTP 経由でファイルをアップロードすると、そのファイルは直接バケットにドロップされます。そして、inotify は従来のファイルシステムと同様にそのイベントをキャッチし、その時点で SQS または他のメカニズムを使用して、実行するジョブがあることをワーカー マシンに通知できます。その後、各マシンと S3 インフラストラクチャ間の利用可能な帯域幅によってのみ I/O が制限される状態で、ファイルを個別に取得して処理できます。
s3fs がまったく適さないものがいくつかあります。たとえば、同じ静的コンテンツを何度も提供するサーバーなどです。s3fs は、大量の冗長なリクエストが発生する可能性があり、ローカルにキャッシュする必要がある (キャッシュは可能ですが、意味がありません。必要な場合は、ファイルをローカルに保存するだけです) ため、このような場合に適したソリューションではありません。また、レスポンシブな Web サイトを提供しようとしながら、オンデマンドで個別にフェッチすることに伴う遅延が問題になる可能性があります...ただし、各ファイルがない何度もアクセスすることで、良い結果が得られました。
私は最近、クライアントのために小さなプロジェクトを行いました。クライアントは、公開ダウンロード可能なアセットをS3に保存したいと考えていましたが、おそらくあなたと同様の制約がありました。本当にFTP を使用してファイルをアップロードできるようにしたいと考えていました。 proftpd と、s3fs 経由で EC2 インスタンスにマウントされたバケットを組み合わせると、既存のシステムと互換性のある S3 への簡単な「ゲートウェイ」が提供されます... そのため、これが機能することはわかっています。また、同じ設定を inotify でテストしたところ、2 つの間に期待どおりの相互作用があるようです。
このように EC2 内から S3 を使用すると、ストレージ料金は基本的に EBS と同等になり、バケットがエンドポイントと同じリージョンにある場合は帯域幅の料金はかかりません。それぞれPUT(100 万リクエストあたり 5 ドル) とGET(100 万リクエストあたり 4 ドル) を支払うだけです (料金表の私の解釈です。私は S3 に何百万ものオブジェクトを保存していますが、請求額に驚くようなことは一度もありませんが、鵜呑みにしないでください)。s3fs は、疑似ファイルシステム エミュレーションの一環として、ファイル モードと所有権を S3 に保存するためにバックグラウンドで何らかの操作を行う必要があり、ディレクトリ リストを生成するためにオブジェクトを反復処理する必要があるため、ファイルとリクエストの相関関係は正確に 1:1 ではない可能性があります。そのため、リクエストについては状況によって異なりますが、実行可能なソリューションのように思えます。
S3 の機能と従来のファイルシステムの機能との間のインピーダンス不一致を適切に理解した上で取り組む限り、必要に応じてほぼ無限に拡張できない理由はわかりません。
もちろん、s3fs の一番気に入っている点は、スペースが不足することがないことです。:)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
答え2
クライアントが IP ではなく DNS で FTP にアクセスできる場合、最も簡単な解決策は、複数の FTP インスタンスの前に ELB を配置して水平方向にスケーリングできるようにすることです。
その後、処理が完了したときに FTP で転送されたすべてのファイルを 1 か所に集める必要がある場合は、S3 または任意の数のソリューションを使用して、処理されたファイルを 1 つの場所に永続的に保存できます。
答え3
inotify がヘッドノードに FTP で送信されている新しいファイルがあることを検出したときに、それらのファイルを他のノードに scp するスクリプトを用意することはできませんか?