HDEのCTO兼社長
ソフトウェアベンダー
なぜSaaSを始めたのか
はじめたかったから 2011.3.11
オンプレミスからクラウドへ (データを外にだすのはあぶない→会社においたままにするほうがあぶない)
地震で大ダメージ
これからはクラウドをやっておくべきじゃね?
Google Apps オフィス365 Gmail
どこでもアクセスできるし落ちないけどセキュリティ的にどうなの? いつどこでアクセスしたかが分からない
HDEが提供するセキュリティサービス
メッセージセキュリティ
メールの内容を暗号化 誤送信のアラート
メールアーカイブツール市場シェア 第一位 Google AppsとOffice 365 (大手中堅いろいろな会社で採用されてる)
550社40万ユーザー
処理通数 3億通 / 月 保管通数 1億通 / 月
どういう苦労をしたのか
2013から急激にデータ量が増加→AWSを採用
アーカイブサービスについて
アーカイブサービス 本当に届いているの?
主要コンポーネント
メインストレージ 検索インデックス(かなりの量のメールが来るので、メールを検索できるようにしたい)
メインストレージをAWSで。
メインストレージには何をつかうか
比較検証の結果
データの安全な保管(3年間ー永久) 現実的なパフォーマンスで検索可能にする(検索インデックスの作成) 目標稼働率99.9%
→S3の採用
オブジェクト数の上限 なし ストレージ総容量制限 なし オブジェクト容量制限 5TB
いろいろ考えたけど、やっぱり使いたかったから
無限に増加するデータを保存する
S3の課題
I/O性能 HTTPベースのAPI: 単体でのアクセスは遅い
課題解決→書き込みを並列化し、読み出しはキャッシュで
S3のパフォーマンス 非常にスケーラブルである。
1MG 300ms 10MG 300ms(並列化の効果)
→SMTPサーバーを並列化 (1ヶ月に1億なら全然問題ないレベル)
読み出しはキャッシュ
ElastiCache Amazon ElastiCache （キャッシュ管理・操作サービス）| アマゾン ウェブ サービス（AWS 日本語）
パスワードなどはキャッシュしないオペレーション メールは長めのキャッシュ期間
検索インデックスについて
全文検索エンジンはゼロから開発 作りたかったから。
SQSでジョブをワーカーに分配 Amazon Simple Queue Service ( キュー管理サービス Amazon SQS) | アマゾン ウェブ サービス（AWS 日本語）
人間のメールは周期的。 昼夜の流量差に応じたスポットインスタンスの起動
めでたしめでたし…?
課題
ストレージの書き込み PUTはGETの約10倍(油断するとすごいお金がかかる)
全文検索インデックス処理では3000-5000のキーが発生する 1通2円→パケ死
EBS+インスタンス構成(MongoDB) シャーディングにシャーディングを重ねる
S3が使えないのは更新と書き込みが多いから ならば 更新が終わったらS3に移せばいい
圧縮して料金を節約する
更新がなくなったインデックスをEMRでS3に移動
なぜEMR→つかいたかったから
S3上でZIP形式を直接読む
S3とSQSでたいていのことは出来る 従来型システムとのハイブリッド
Glacier
ストレージコストはS3のおよそ1/8 100TBで12万(呼び出しにはお金がかかるから、あまりアクセスしないデータに突っ込む)
統計的に頻繁にアクセスするメールは1年以内 そのあたりをうまく使いこなせばより安くサービスを提供できるので、 他ベンダーの追随を許さない価格を実現できた
取り出さないデータを運用するのにGlacierは有効 AWSを基盤にすることでAWSの競争力を武器にできる
