ソフトウェアベンダーが AWSを活用して
急にSaaSをはじめた話小椋 一宏/Kazuhiro Ogura
CTO of HDE, Inc. @goura
fb.me/rgoura
なぜSaaSをはじめたのか
はじめたかったから
3.11以降、企業で変化が起きた
3.11以降、HDEでも変化が起きた
HDEが提供するセキュリティサービス
HDEメールサービスとは
メールアーカイブツール市場シェア
※株式会社富士キメラ総研「富士マーケティング・レポート・BT"クラウド型コラボレーション系サービス及び周辺ビジネス市場動向"」(2013)
約 550社
40万ユーザー
処理通数:約3.0億通/月 保管通数:約1.0億通/月
急激にデータ量が増加
アーカイブサービスについて
アーカイブ主要コンポーネント
ストレージについて
メインストレージには何を使うか?
・無限に増加するデータの安全な保管 ・現実的なパフォーマンスで検索可能にする (検索インデックスの作成) ・目標稼働率 99.99%
要件
• オブジェクト数上限:なし • ストレージ総容量制限:なし • オブジェクト容量制限: 5TBまで • 可用性: 99.99% • 三つ以上のデータセンターに分散 • GBあたり単価: $0.10/GB
S3の採用
使いたかったから
無限に増加するデータを保存する
S3の課題: I/O性能
HTTPベースのAPI:単体でのアクセスは遅い
課題解決: I/O性能
S3のパフォーマンス
出典: 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