2018/11/21 - 15:37

ファイルゲートウェイをgoofysに置き換えた話

:

:

:

こんにちは yurakawa です。

最近、AWS のファイルゲートウェイから goofys に移行したのでそのお話をします。

ファイルゲートウェイ ?

ファイルゲートウェイは、ネットワークファイルシェアとして表示される、ファイルベースのインターフェイスを Amazon S3 に提供します。これにより、ユーザーは標準のファイルストレージプロトコルを通して Amazon S3 オブジェクトの保存と取得を実行できます。ファイルゲートウェイにより、既存のファイルベースのアプリケーションやデバイスでは、変更を加えることなく安全で耐久性に優れたクラウドストレージを使用できます。ファイルゲートウェイの使用時には、設定した S3 バケットを Network File System (NFS) マウントポイントとして、あるいは Server Message Block (SMB) ファイルシェアとして使用できるようになります。アプリケーションは、ファイルサーバーとしてゲートウェイへのインターフェイスとなる NFS や SMB 上でファイルやディレクトリの読み書きを行います。同様にゲートウェイは、これらのファイル操作を、S3 バケットに対するオブジェクトリクエストに変換します。直近に使用されたデータは、低レイテンシーのアクセスのため、ゲートウェイ上にキャッシュされます。データセンターと AWS との間のデータ転送は、ゲートウェイによって完全に管理および最適化されます。S3 に到達したオブジェクトについては、直接アクセスすることも、S3 ライフサイクルポリシー、オブジェクトのバージョニング、クロスリージョンレプリケーションなどの機能を使用して管理することもできます。ファイルゲートウェイはオンプレミスまたは EC2 で実行できます。

https://aws.amazon.com/jp/storagegateway/faqs/

つまり、特定のS3バケットをNFSマウントポイントとして利用できるため、サーバーからS3オブジェクトを容易に操作・取得できます。 AWS の Storage Gatewayの一種。

goofys ?

https://github.com/kahing/goofys

ファイルゲートウェイと同じようなことができますが、内部的には FUSE を使って S3 バケットをファイルシステムとして扱っているようです。 Golang で書かれた s3fs的認識。

どうして置き換えたのか

もともと EBS に保持していた大量のファイルを S3 に移すためファイルゲートウェイを導入しましたが下の問題がありました。

  1. 冗長化できないため SPOF になる。
  2. ファイルゲートウェイがキャッシュ情報を保持するため、Read/Write どちらもファイルゲートウェイを経由する必要がある。
    • 大量書込読込に影響する。
    • 書き込みを他手段でおこなった場合、ファイルゲートウェイから見えなくなるためRefreshCache する必要があるが、オブジェクトが多いととても時間がかかる。
  3. 不定期にメンテナンスがある。(時間指定による自動メンテナンスは可能)

goofys が上記問題を解決してくれてかつ、意外に軽快かつ安定していたので移行の運びとなりました。

どんな感じ?

パフォーマンスは主に以下に依存します

  • ファイルゲートウェイ: ファイルゲートウェイ用に作成した EC2 インスタンスとマウント先の EC2 インスタンス
  • goofys: マウント先の EC2 インスタンス

なので完全に同じ条件では計測できていませんが、 転送速度はファイルゲートウェイが若干早いように思います。1.25-1.5倍程度。 ただ goofys にしたおかげで突発的な遅延や SPOF の不安から解放されました。

うちの用途上、ファイルゲートウェイのキャッシュストレージを有効活用できていなかったので良い改善活動だったように思います。 おまけでファイルゲートウェイのインスタンス費用が浮きました。

現場からは以上です。