Amazon Kinesis / S3 / SQS の導入を比較検討して分かったそれぞれの特徴 ｜ SiTest (サイテスト) ブログ

今回はヒートマップ解析を実現する為の大量トラフィックを捌く際に過去検討した、Amazon が提供している3つのサービスを比較した経緯をお話します。

1. 1. SiTest のトラッキングタグの概要
2. 2. 大量トラフィックとの戦い
3. 3. Amazon AWS の3つのサービスの概要
4. 4. 比較検討結果

SiTest の主な機能の一つにヒートマップを表示する機能があります。
訪問者がどのようにページを閲覧したかを解析・分析するために、
ページをどのように閲覧したかという操作履歴の一部を SiTest のサーバーにAjax通信で送信・保存しております。

タブを閉じたりリンクをクリックした瞬間にトラッキングタグのコントロールを失ってしまいますので、
定期的に SiTest のサーバーに操作履歴を保存する必要があります。

しかし、都度操作履歴を送信していると訪問者や SiTest のサーバーのコストが膨大になってしまいますので、
様々な操作を1挙動とし、いくつかの挙動をブラウザ上で溜めてから送信するという仕様となっています。

統計を取ってみると、1回のデータ送信用にまとめた操作履歴は約1KBのサイズでした。
トラッキングタグを設置したページの1PVにつき、平均10アクセス以上 SiTest と通信する必要があります。

2-1. 経緯

トラフィックのコストパフォーマンスを良くする為のプロジェクトが立ち上がりました。
トラフィック自体を捌く事自体は以下のような手段を駆使することで可能です。

• ・サーバーの台数を増やす
• ・サーバーをより上位のプランに変更する

Amazon EC2 はどちらも簡単に実現できますので特に問題視はしてませんが、
現在進行形で増え続けているコストを減らすためには別の手段を考える必要があります。

2-2. 現状分析

SiTest プロジェクト始動時は開発速度を重視するために、
設定より規約を重視するCakePHPというフレームワークを選択していました。

CakePHPの挙動は素直で開発しやすく不満はないのですが、高トラフィックを捌くことが苦手です。
そもそもサーバーサイドとして選択しているPHP自体の問題である程度までしか処理能力が出ません。

Web Framework Benchmarks Round 11

Amazon EC2 m1.large環境にて、CakePHPは秒間227リクエストを捌けるそうです。
実際に SiTest でm1.large環境で操作履歴を保存する場合の負荷検証を行ったところ、秒間40アクセス前後が限界でした。

上記のデータはデータベースからシンプルなデータを検索して結果を得るという条件ですので、
データベースへの書き込みに関してはパフォーマンスが大幅に落ち込んでしまった事が原因でしょう。

旧世代のインスタンス
m1.large環境の費用は1時間毎に$0.243ですので、
1カ月動作させると$175の費用です。（参考値）

2-2. AWSのサービスを利用するという選択肢

上記のベンチマークを見ると、CakePHPよりもっと速度の出る言語やフレームワークがあることが分かります。
(CakePHPは決して遅いフレームワークではありませんが、ベンチマークとして紹介されている中では最下位争いです…)
もっと高トラフィックを捌くのに適した手段を使えば100倍以上のアクセスを捌く事も可能かもしれません。
しかし、慣れない新しいフレームワークへの切り替えコストは大きいですし、
万が一不具合が出てしまったら私の休日が消える騒ぎでは済まない可能性もあります。

既成のサービスを有効活用することで、目的達成できるならそれに越したことはありません。
東急ハンズさんでも全国の売上データの集計を行う為に Amazon の様々なサービスを併用しているそうです。
SiTest でも高トラフィックを Amazon のサービスで捌けないか調査しました。

2-3. SiTest で Amazon のサービスを使う事はできるのか？

AWS SDK(ドキュメント)
ブラウザ上からでもhttps://sdk.amazonaws.com/js/aws-sdk-[Version番号].min.jsを読み込む事で、
ライブラリを操作するだけでAWSのサービスを強力に扱う事が可能です。

例えばクラウドストレージとして有名なS3に関しては、ファイルのアップロード・ダウンロードは当然できます。
普通のHDDではドライブに相当するバケットの作成や削除、ユーザーのアクセス権限設定までできてしまいます。

強力過ぎて恐ろしいですね。
しかし、IAM や Cognito というサービスを併用することで操作に制限のあるユーザーを簡単に作成できます。
権限はS3一つに関しても、1挙動単位(例えばアップロードのみ可能)で制限を掛ける事ができます。

SiTest の要件としては、操作履歴の情報を文字列としてAWS上に保存しておき。
後で一括でまとめて SiTest のデータベースへ保存したいと考えています。
下に使えそうなサービスをピックアップしました。

• ・Amazon S3
• ・Amazon Simple Queue Service (SQS)
• ・Amazon Kinesis

2-4. SiTest のトラフィック各種データ

詳細なPv数等のデータは出せませんでしたが、
とある1日から割り出した比率を公開します。
上記の負荷テストよりm1.large環境では秒間40アクセスまで捌けるので、この数値を基準としていきます。

• ・ピーク時の秒間受信ファイルサイズ: 27KB
• ・1日の合計受信ファイルサイズ: 1,030MB

Amazon S3

Amazon S3 は説明不要のクラウドストレージサービスです。
ファイルの更新(PUT)と新規作成(POST)はコストが一緒なので、
全ての操作履歴のアップロードに一意のファイル名を名付けて管理する想定です。

基本的にファイルサイズを意識する事が多いかと思いますが、
データベースへの登録が済んだら削除しますので無視します。

SiTest の使い方では多数の訪問者が一斉にPOSTしますので、POST回数がコストです。

• ・POST, PUT: $0.0047 / 1,000req * 1,600,000req * 30days = $225.60/mo
• ・GET: $0.0037 / 10,000req * 1,600,000req * 30days = $17.76/mo
• ・DELETE: 無料

当然ですがこの使い方では非常に高価になってしまいます。
しかし、安全にスケールできる安心感やバルクインサートによりデータベースサーバの負荷が減りますので、
既存のシステムと比べて必ずしも悪いという選択肢ではなさそうです。

Amazon Simple Queue Service (SQS)

Amazon SQS はメッセージキューサービスです。
簡単に例えるなら、バッチ版目安箱のような存在です。
届けられたメッセージは14日間、開封待ちの状態として保管され、何時でも取り出してメッセージを確認できます。

機能の一例を挙げますと、
一度読み込まれたメッセージはデフォルトで30秒だけ開封済状態となり、
その後、正常に処理できず放置されてしまった場合、30秒経ったら自動的に未開封状態に戻ります。

これにより将来的に複数のバッチが同時に同じメッセージを読み込んで2重に処理することも減りますし、
処理されてないメッセージが勝手に捨てられてしまう事態も防ぐことができます。

• ・POST: $0.476 / 1,000,000req * 1,600,000req * 30days = $22.85/mo
• ・GET: $0.476 / 1,000,000req * 1,600,000req * 30days = $22.85/mo
• ・DELETE: $0.476 / 1,000,000req * 1,600,000req * 30days = $22.85/mo
• ・なお100万操作までは無料

GETやDELETEは1リクエスト扱いで複数のメッセージを操作できればコストが大幅に下げられるかと思います。
ドキュメントからは読み取ることができませんでしたので、今回はPOSTと同じ回数を見積もっています。

全く意識せずに勝手にスケールするスケーラビリティと堅牢性が魅力的です。
それでいて、現行の環境1/3程度のコストで大量のリクエストを捌くことが可能です。

Amazon Kinesis

Amazon Kinesis は大量のデータを一時的に保管してくれるストリームサービスです。
近年、ビッグデータというワードがはやっており、時に億を超える大量のデータを解析・分析して
データの集合から新しい概念を探し見つける事が当たり前の時代になってきました。

それを支える技術として、途方もない多くのデータをネットワーク越しに移動させるニーズがあります。
Kinesis の登場でようやく大量の細かいデータを送信するということが低価格で実現できるようになりました。

• ・Shade: 1本当たり $0.0195 * 24hour * 30days = $14.04
• ・PUT: $0.0215 / 1,000,000req * 1,600,000req * 30days = $1.03

比較対象のデータは秒間40アクセス、秒間27KBです。
Shade1本(秒間1,000アクセス、秒間1MB)の制限に比べればなんでもありません。
なんと、当時の SiTest 20台相当のサーバーをたった$14の固定費だけでまかなえてしまいます。

但し大量のデータを一時的に保管するだけと説明したように、下記のような制限があります。
データの生存期間は24時間ですし、データの読み込み方法に様々な制限があり、
S3 や SQS と比べて登録済のデータを再度処理してしまうケースは常に意識しておく必要があります。

使い勝手で言えば SQS が圧倒的です。
SQS は100万アクセスまでは無料ですので、ユーザーが少ないスタートアップ時点では特にオススメできます。
また、Kinesis のデメリットが気になるケースでは選択する価値があるでしょう。

コスト面では Kinesis に敵う選択肢はないでしょう。
秒間20アクセスを超えてくると Kinesis を使いたくなってくるのではないでしょうか？

SiTest ではコスト面で強く惹かれましたのでその時点では Kinesis を選択しました。
次回は Kinesis で実際に簡単なシステムを作ってデータを送信していきたいと思います。