ソフトウェアベンダーが AWSを活用して

急にSaaSをはじめた話小椋　一宏／Kazuhiro Ogura

CTO of HDE, Inc. @goura

fb.me/rgoura

なぜSaaSをはじめたのか

はじめたかったから

3.11以降、企業で変化が起きた

3.11以降、HDEでも変化が起きた

HDEが提供するセキュリティサービス

HDEメールサービスとは

メールアーカイブツール市場シェア

※株式会社富士キメラ総研「富士マーケティング・レポート・ＢＴ"クラウド型コラボレーション系サービス及び周辺ビジネス市場動向"」(2013)

約 550社

40万ユーザー

処理通数：約3.0億通／月 保管通数：約1.0億通／月

急激にデータ量が増加

アーカイブサービスについて

アーカイブ主要コンポーネント

ストレージについて

メインストレージには何を使うか？

・無限に増加するデータの安全な保管 ・現実的なパフォーマンスで検索可能にする （検索インデックスの作成） ・目標稼働率 99.99%

要件

• オブジェクト数上限：なし • ストレージ総容量制限：なし • オブジェクト容量制限: 5TBまで • 可用性: 99.99% • 三つ以上のデータセンターに分散 • GBあたり単価: $0.10/GB

S3の採用

使いたかったから

無限に増加するデータを保存する

S3の課題： I/O性能

HTTPベースのAPI：単体でのアクセスは遅い

課題解決： I/O性能

S３のパフォーマンス

出典： Donald Kossmann, Tim Kraska, Simon Loesing. An Evaluation of Alternative Architectures for Transaction Processing in the Cloud, 2010.

書き込み→並列化

SMTPサーバーの並列化

課題解決： I/O性能

読み出しの高速化

課題解決： I/O性能

S3でメインストレージを構築

検索インデックスについて

アーカイブサービス画面

全文検索エンジン ゼロから開発

作りたかったから

検索インデックス作成：SQSで分散

SQSでジョブをワーカーに分配

何のグラフ？

昼夜の流量差に応じたスポットインスタンスの起動

台数半分 !価格1/4 !

めでたしめでたしのようだが……

克服できなかった弱点

S3の課金体系PUTはGETの

約10倍

• 当社の検索方式はN-gram風 • 全文検索インデックス処理では、メール1通につき3000～5000キーの更新が発生する !

• そのままS3に書き込んでしまうと、、

インデックス処理にかかる金額

S3だとパケ死する

しょうがないので MongoDB

EBS+インスタンス構成でスタート

…増えつづけるDBサーバーに苦戦！

S3を使えなかった理由は 更新・書き込みが多いから

!

ならば !

更新が終わったら S3に移せばいいかも

そうだついでに圧縮して 料金を節約しよう

更新が無くなったインデックスをEMRでS3に移動

EMR

使いたかったから

工夫：S3上のZIP形式を直接読む• Range付きGETでCentral Directoryを読み • 各ファイルのオフセットを取得してまたRange付GET

• 1000個のキーを書き込むときなど、PUTリクエスト課金を節約できる

http://en.wikipedia.org/wiki/File:ZIP-64_Internal_Layout.svg

ここまでのまとめ

• S3 + SQS でたいていのことはできる • 書き込み→並列化 • 読み込み→キャッシュで弱点克服 • 細かいデータをたくさん書く用途は、従来型のシステムとのハイブリッド型も選択肢の一つ

Glacier登場

!

•ストレージコストはS3のおよそ1/8 •100TB貯めても12万円/月 •読み出しにはお金がかかる→バックアップ用 •削除にはお金がかからない

2012/8 Glacierの発表

使いたかったので使いどころを必死で考えた

Glacierの活用

ここまでのまとめ

•Glacierは、取り出さない目算が高いデータを格納するのに有効 •AWSを基盤にすることで、AWSの競争力を武器にできる

話は以上です ありがとうございました

さいごに

ジョブシェアで人材募集中です！https://job-share.net/jobs/3084

ありがとうございました！小椋　一宏／Kazuhiro Ogura

CTO of HDE, Inc. twitter.com/goura fb.me/rgoura