弊社のクラウドセキュリティサービスHDE Oneには様々なコンポーネントがありますが、今回はメールアーカイバについて紹介します。
月間1億6000万件のメールをアーカイブして、検索可能にする
HDE Oneはおかげさまで多くの企業様にご採用いただき、現在では月に1億6000万件のメールをアーカイブするような規模にまで成長しました。最初は月に100万件程度だったものが、どんどん増えていって急成長しています。近いうちに月間2億件を突破する見込みです。
メールデータの増加量もかなり多く、現在では1日1TBペースで増えています。
この大量のメールをアーカイブ・検索できるシステムの提供・運用を行っています。
サーバはAWSを活用
サーバはAWSを活用しています。急激な成長スピードに対応するには、クラウドサービスの利用が必要不可欠です。中でも機能的に優れているAWSを積極的に採用しています。
HDEでは全社的にAWSを採用しており、トータルでの1000インスタンスほど運用しています。AWSでもAdvanced Technology Partnerとしてお付き合いさせていただいてます。
アーカイブ検索システムの構成
メールのアーカイブ検索システムの構成は次の図の様な構成になっています。
大まかに分けて次のようなシステムに分かれています。
AWSのサービスでは、下記のものを利用しています。
- CloudFormation
- DynamoDB
- EC2
- ElastiCache (Redisのほう)
- Elastic MapReduce (EMR)
- Route53
- S3
- SQS
簡単に各システムについての概要を説明します。
アーカイバ
アーカイバはSMTPでメールを受け取り、S3上にメールを保存します。メールを保存したら、メールの情報をSQSのキューに登録します。アーカイバの仕事はメールを保存するところまでです。
インデクサ
アーカイブされたメールを検索可能なデータに変換・登録するのがインデクサの役割です。インデクサはさらにトークナイザとフラッシャーに分かれます。
トークナイザとフラッシャーに分かれているのは、トークナイザは主にCPUバウンドの処理で、フラッシャーが主にI/Oバウンドの処理になっているので、効率良く処理するために分けています。
トークナイザ
インデックスに格納されるデータ次の2つになります
- メールヘッダ
- メールボディのトークン(N-gram)
クライアントに素早くメールの情報を表示できるようしたいため、メールヘッダの情報は、トークナイザから直接MongoDBに格納します。メールヘッダはデータ量もそれほど多くないので、書き込みにもそれほど時間はかかりません。
メールボディはN-gramで分割したトークン情報を、一旦S3上にファイルとして保存します。トークン情報は、書き込むのにそれなりの時間がかかるので、MongoDBへの書き込みはフラッシャーに任せて、必要な情報をSQSでキューに登録します。
フラッシャー
フラッシャーは、トークナイザが生成したトークン情報をMongoDBに書き込みます。書き込みには少し時間がかかるため、トークナイザと処理を分けています。
メールヘッダはトークナイザの段階ですぐに書き込まれているので、すぐに表示されるようになりますが、トークン情報の書き込みには少し時間がかかるため、全文検索できるようになるまでにはタイムラグがあります。
データベース(MongoDB)
インデクサとフラッシャーによって、MongoDBにメールヘッダと全文検索用のインデックスの情報が書き込まれます。月間1億6000万件ともなると、かなり大量のデータが格納されるようになるのですが、いろいろと細かい努力を積み重ねています。。。
インデックスアーカイバ
メールデータはどんどんたまっていくので、全てのデータをMongoDBに入れると(金銭的に)大変な事になります。 過去のメールに関しては、検索需要はどんどん低くなっていくので、定期的にS3上にインデックスデータをアーカイブしています。
S3上にあるデータを検索できるようにするために、これまたいろいろと細かい努力を積み重ねています。。。
UIサーバ
クライアント様がメールのデータの操作・検索をするためのサーバです。 MongoDBにあるデータを参照して、クライアント様に(検索を含む)様々な機能を提供しています。
続く
今回は、メールアーカイブシステムの概要について紹介しました。内部では月間1億6000万件のメールを処理するために、様々な工夫をしています。 次回以降は、個別のシステムがどのように実装されているかを具体的に紹介していきたいと思います。
