0
ソフトウェアベンダーが

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%
S3の採用
•
•
•
•
•
•

オブジェクト数上限:なし
ストレージ総容量制限:なし
オブジェクト容量制限: 5TBまで
可用性: 99.99%
三つ以上のデータセンターに分散
GBあたり単価: $0.10/GB
使いたかったから
無限に増加するデータを保存する
S3の課題: I/O性能

HTTPベースのAPI:単体でのアクセスは遅い
課題解決: I/O性能
S3のパフォーマンス

出典: Donald Kossmann, Tim Kraska, Simon Loesing.
An Evaluation of Alternative Architectures for Transaction Pro...
書き込み→並列化
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リ
クエスト課金を節約できる...
ここまでのまとめ
• S3 + SQS でたいていのことはできる
• 書き込み→並列化
• 読み込み→キャッシュで弱点克服
• 細かいデータをたくさん書く用途は、
従来型のシステムとのハイブリッド型
も選択肢の一つ
Glacier登場
2012/8 Glacierの発表
!
• ストレージコストはS3のおよそ1/8
• 100TB貯めても12万円/月
• 読み出しにはお金がかかる→バックアップ用
• 削除にはお金がかからない
使いたかったので

使いどころを必死で考えた
Glacierの活用
ここまでのまとめ
• Glacierは、取り出さない目算が高いデー
タを格納するのに有効
• AWSを基盤にすることで、AWSの競争力
を武器にできる
話は以上です
ありがとうございました
さいごに
ジョブシェアで人材募集中です!
https://job-share.net/jobs/3084
ありがとうございました!
小椋 一宏/Kazuhiro Ogura
CTO of HDE, Inc.
twitter.com/goura
fb.me/rgoura
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話
Upcoming SlideShare
Loading in...5
×

20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話

4,403

Published on

JAWSUG 東京 2013/12/13
ソフトウェアベンダーが
AWSを活用して
急にSaaSをはじめた話

Published in: Technology

Transcript of "20131213 jawsugソフトウェアベンダーがAWSを活用して
急にSaaSをはじめた話"

  1. 1. ソフトウェアベンダーが
 AWSを活用して
 急にSaaSをはじめた話 小椋 一宏/Kazuhiro Ogura CTO of HDE, Inc. @goura fb.me/rgoura
  2. 2. なぜSaaSを
 はじめたのか
  3. 3. はじめたかったから
  4. 4. 3.11以降、企業で変化が起きた
  5. 5. 3.11以降、HDEでも変化が起きた
  6. 6. HDEが提供するセキュリティサービス
  7. 7. HDEメールサービスとは
  8. 8. メールアーカイブツール市場シェア ※株式会社富士キメラ総研「富士マーケティング・レポート・BT"クラウド型コラボレーション系サービス及び周辺ビジネス市場動向"」(2013)
  9. 9. 約 550社 40万ユーザー
  10. 10. 処理通数:約3.0億通/月 保管通数:約1.0億通/月
  11. 11. 急激にデータ量が増加
  12. 12. アーカイブサービスについて
  13. 13. アーカイブ主要コンポーネント
  14. 14. ストレージについて
  15. 15. メインストレージには 何を使うか?
  16. 16. 要件 ・無限に増加するデータの安全な保管 ・現実的なパフォーマンスで検索可能にする (検索インデックスの作成) ・目標稼働率 99.99%
  17. 17. S3の採用 • • • • • • オブジェクト数上限:なし ストレージ総容量制限:なし オブジェクト容量制限: 5TBまで 可用性: 99.99% 三つ以上のデータセンターに分散 GBあたり単価: $0.10/GB
  18. 18. 使いたかったから
  19. 19. 無限に増加するデータを保存する
  20. 20. S3の課題: I/O性能 HTTPベースのAPI:単体でのアクセスは遅い
  21. 21. 課題解決: I/O性能
  22. 22. S3のパフォーマンス 出典: Donald Kossmann, Tim Kraska, Simon Loesing. An Evaluation of Alternative Architectures for Transaction Processing in the Cloud, 2010.
  23. 23. 書き込み→並列化
  24. 24. SMTPサーバーの並列化
  25. 25. 課題解決: I/O性能
  26. 26. 読み出しの高速化
  27. 27. 課題解決: I/O性能
  28. 28. S3でメインストレージを構築
  29. 29. 検索インデックスについて
  30. 30. アーカイブサービス画面
  31. 31. 全文検索エンジン ゼロから開発
  32. 32. 作りたかったから
  33. 33. 検索インデックス作成:SQSで分散 SQSでジョブをワーカーに分配
  34. 34. 何のグラフ?
  35. 35. 昼夜の流量差に応じた
 スポットインスタンスの起動 台数半分 ! 価格1/4 !
  36. 36. めでたしめでたし
 のようだが……
  37. 37. 克服できなかった弱点
  38. 38. S3の課金体系 PUTはGETの 約10倍
  39. 39. インデックス処理にかかる金額 • 当社の検索方式はN-gram風 • 全文検索インデックス処理では、メール1通につき 3000∼5000キーの更新が発生する ! • そのままS3に書き込んでしまうと、、
  40. 40. S3だとパケ死する
  41. 41. しょうがないので MongoDB
  42. 42. EBS+インスタンス構成でスタート
  43. 43. …増えつづけるDBサーバーに苦戦!
  44. 44. S3を使えなかった理由は
 更新・書き込みが多いから ! ならば ! 更新が終わったら
 S3に移せばいいかも
  45. 45. そうだ
 ついでに圧縮して 料金を節約しよう
  46. 46. 更新が無くなったインデックスを
 EMRでS3に移動
  47. 47. EMR
  48. 48. 使いたかったから
  49. 49. 工夫:S3上のZIP形式を直接読む • • • Range付きGETでCentral Directoryを読み 各ファイルのオフセットを取得してまた Range付GET 1000個のキーを書き込むときなど、PUTリ クエスト課金を節約できる http://en.wikipedia.org/wiki/File:ZIP-64_Internal_Layout.svg
  50. 50. ここまでのまとめ • S3 + SQS でたいていのことはできる • 書き込み→並列化 • 読み込み→キャッシュで弱点克服 • 細かいデータをたくさん書く用途は、 従来型のシステムとのハイブリッド型 も選択肢の一つ
  51. 51. Glacier登場 2012/8 Glacierの発表 ! • ストレージコストはS3のおよそ1/8 • 100TB貯めても12万円/月 • 読み出しにはお金がかかる→バックアップ用 • 削除にはお金がかからない
  52. 52. 使いたかったので
 使いどころを必死で考えた
  53. 53. Glacierの活用
  54. 54. ここまでのまとめ • Glacierは、取り出さない目算が高いデー タを格納するのに有効 • AWSを基盤にすることで、AWSの競争力 を武器にできる
  55. 55. 話は以上です ありがとうございました さいごに
  56. 56. ジョブシェアで人材募集中です! https://job-share.net/jobs/3084
  57. 57. ありがとうございました! 小椋 一宏/Kazuhiro Ogura CTO of HDE, Inc. twitter.com/goura fb.me/rgoura
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×