技術者ブログ

はじめに

私たちが運営しているSaaS型のWAFサービスであるScutum(スキュータム)では、2013年の7月の時点で、一日に約2.5GBほどのログファイルが溜まる状態となっています。ログファイルの内容は様々ですが、サービスの改良やトラブルシューティングに活かすため、今後もより積極的にたくさんの情報をログに出力し、それを解析してフィードバックするサイクルを回していきたいと考えています。

一日に2.5GBという量は大きなサービスを運営している方から見れば非常に少なく感じられるものだと思いますが、個人的には（サービス開始当初は数十MB程度だったため）非常に大きくなってきたな、と感じています。

今回のエントリでは、EC2上のサーバからS3にファイルを移動する際に使うことができる、『s3fs』と『jetS3t(ジェットセット)』という2つのソフトウェアについて検証を行った結果について、簡単にまとめたいと思います。

ログファイルはオンプレミスでなくS3に格納する

Scutumでは累積されているログの全体量もTBという単位が見え始めてきたため、ログをどのように集約・蓄積していくかについて見直しを行いました。これまではオンプレミスサーバ上で管理していましたが、これをすべてAmazon S3上での管理に切り替えることにしました。この理由は次のようなものです。

• HDDの故障やキャパシティプランニングなど、オンプレミスサーバの管理のコストが無駄である
• バックアップをどうするかという問題
• 溜まったログを活かすための仕組みが作りづらい

特に決定的だったのが3番目の理由です。データをS3に置いておくことで、HadoopアプリケーションをAmazon EMR(Elastic MapReduce)上で稼働させることが可能になり、数百GB、あるいはTBレベルのデータに対しても臆さずに解析を試みることが可能になります。私たちビットフォレストのような中小規模の企業ではオンプレミス環境にHadoopクラスタを構築することは効率的でないと考え、Hadoopクラスタを一切管理する必要がないAmazon EMRを積極的に使っていくことにしました。

EC2を経由する

Scutumの各WAFサーバで生成されるログは、一定期間毎にgzip圧縮して切り離されます。これらは直接S3に送るのではなく、一度EC2のサーバ上に移動させます。これは、S3への書き込みがやや遅いことと、ログが新しいうちは、何かとデバッグ等の理由で直接(grepなどで)ログファイルを読む機会が多いからです。一ヶ月程度前の少し古いログファイルになれば、直接見る必要は減るため、そのタイミングでS3に移動させることを考えています。また、前述したように現在サービスで生成されるログファイルのサイズはそれほど巨大ではないため、一度EC2サーバ上に溜めることが可能であるということも理由のひとつです。

EC2からS3へのファイルコピー

さて本題となるEC2上のファイルのS3へのコピーについてです。今回はS3に対してディレクトリ構造ごとアップロード・ダウンロードが可能なソフトウェアとして、s3fsとjetS3tの2つを検証しました。

s3fsはLinuxのファイルシステムとして透過的にS3をマウントすることができるソフトウェアです。利用するためにLinuxカーネルのバージョン等に依存がありますが、うまく設定できてしまえば、通常のファイルやディレクトリと同じ感覚でS3にアクセスすることができます。そのためfindやrsyncなどの使い慣れたコマンドや既存のシェルスクリプト等が利用できるという大きなメリットが存在します。

jetS3tはs3fsよりもやや無名のソフトウェアです。こちらは基本がJavaで書かれ、それをツールとして便利にまとめるためのシェルスクリプトから構成されるツール群です。Javaアプリケーションであるため、Windowsでも利用でき、s3fsのようにLinuxカーネルのバージョンなどを気にする必要はありません。jetS3tには『synchronize』と呼ばれるツール（スクリプト）が含まれており、これは指定したディレクトリを指定したS3のパスと同期させるもので、rsyncのように「既に同じファイルが転送先にある場合はコピーしない」という処理をしてくれます。今回ログファイルの移動のために使用を検討したのは、jetS3tに含まれるツールのうち、このsynchronizeになります。

余談となりますが、jetS3tのコードはHadoop内部でも使われており、HadoopがS3にアクセスするためのS3FileSystemクラスなどでは低レベルの処理でjetS3tを利用しています。そのためjetS3tのライブラリとしての信頼度は高いものと考えてよいでしょう。

速度の比較

20個程度のログファイルが含まれる、全体で約30GBほどのディレクトリを、EC2からS3にコピーしてみました。s3fsでは、マウントした状態でrsyncを使いました。また、jetS3tではsynchronizeスクリプトをそのまま利用しました。結果、s3fs+rsyncでは18分ほど、jetS3tでは7分ほどかかり、jetS3tが倍以上速いという結果になりました。スループットはs3fs+rsyncが2.9MB/sec程度、jetS3tは7.3MB/sec程度のようで、どちらも今時の転送速度としては遅く感じます。

ディレクトリ構造の認識についての互換性は無し

2つのツール間ではS3上にアップロードしたディレクトリ構造に対して微妙に異なる解釈をするようで、s3fs+rsyncでアップロードしたディレクトリに対してjetS3tで同期を行おうとすると、既に同じファイルが存在していてもそのようには解釈してくれずに、すべて上書きを行ってしまいます。jetS3tがアップロードしたディレクトリについてrsyncする場合も同様のようです。これはS3を抽象化するための方法に違いがあることが理由であり、仕方ないでしょう。

まとめ

今回は、EC2からS3にディレクトリ構造ごとコピー可能な2つのソフトウェア、s3fsとjetS3tについて速度を比較しました。結果jetS3tが倍以上速いことはわかりましたが、s3fsはrsyncを多用するユーザにとっては非常に使いやすいため、この程度の速度の差ならs3fsもアリかな...と思わされます。また、今後ソフトウェアが改善されて速度が上がる可能性も十分にあるでしょう。

一方でjetS3tはJavaのライブラリであるため、私のようなJavaプログラマには、いざ何か問題が起こった場合にソースを読んで解決できる可能性が残されており、その点で十分に魅力的です。もちろん転送速度が速いという点も見逃せません。どちらを使うのか決めるためにはもう少し時間がかかりそうです。

EC2とS3の同期について何かよい情報をお持ちでしたら、ぜひ@kinyukaまでお知らせください。