カジュアルなぼくのAWS経験と
CloudSearchを触ってみた話	
AWS Casual #2 LT
@mikeda
自己紹介	
• @mikeda
• インフラエンジニア
• イタンジ株式会社
• 不動産系サービス
• 今月入社
今日は	
• はじめまして!
• 4/1からAWSメインの会社に転職しました
• というわけで挨拶がてら
• 数少ないAWS経験
• 最近検証中のCloudSearch
• の話をします!
ぼくのAWS経験
最初の経験
六本木のソシャゲ系の会社	
• 初の海外展開(USA)
• 2012/??
 ※今どうなってるかは知らないです!
• 国内は全て都内DCのオンプレ環境
構成
VPC構成
構成	
• VPCを使ってオンプレと統一的な運用
•  DCとVPN接続
•  外部接続はELBアクセスとVPN経由のみ
•  オンプレと同構成のCentOSのAMIを作成
•  サーバ起動後の手順は全てオンプレと同じ
• サービス系のみの最小構成リリース
•  運用/監視系:0台(オンプレの既存システムを使用)
•  EC2:5台(APP3、Memcach2)、RDS:2台
感想	
• 当時あまりVPC情報がなくてたいへんだった
• 運用面で課題
• 多セグメント化による複雑性
•  オンプレ的な発想?
•  CookpadさんはAZあたり1セグメント
• NATインスタンスの性能、冗長化
2度目の経験
とあるグルメ系サービス	
• 知り合いから新サービスのインフラ構築を頼まれる
•  副業ダメなので焼き肉オゴリで構築を受ける
•  週1作業で1ヶ月半
• 0ベースで構築するドキュメントとコードを納品
•  VPC、ELB、EC2、RDS、S3、CloudFront
•  SES、Route53、CloudWatch
•  Nginx、Unicorn、Rails、MySQL
•  Chef、Capistrano、Munin
構成
構成	
• NW構成はClassic的な構成
• 1VPC (RDSだけ冗長化のためMultiAZ化)
• EC2は全台EIPつける
感想	
•  『インフラもコード』を実感
•  1人でできちゃう
•  契約不要
•  DC
•  回線業者
•  各種HWベンダ(NW、サーバ、ストレージ)
•  メール配信業者
•  中小企業だとインフラ担当〜2人
 →長期的な技術レベルの維持が難しい
 →下に合わせる?
 →外部の個人に依頼するという選択が現実的に
3度目の経験
現職	
• 不動産系のサービスが2つ
構成
感想	
• カジュアルすぎるwww
• さてこれからどうするか(´・ω・`)
• 各種冗長化
• VPC
• ELB
• CloudFront導入
自宅環境
個人検証環境	
• AWSも試そうと思ってだいぶ前に構築
• しかし全部stopして放置。高い
• 自宅ViyattaとVPCのVPN接続だけ維持
→これだけで4000円/月とんでいる(´・ω・`)
• 作り直し予定
•  自宅サーバ&KVM仮想化をコスト勝ちする方法はある?
•  r3インスタンス + Reservice Instance + Dockerを調査予定
CloudSearch使ってみた
CloudSearchとは
CloudSearch	
• 全文検索エンジン的なもの
• SolrとかElasticSearchのAWS版
• 2012/4/12 ベータ版リリース
→でもその後あんまり話を聞かなかった
大幅アップデート @2014/03/25	
• 日本語対応&いろいろ機能追加
• えっ!?今までのCloudSearchってなんだったの?
 ってレベルの改善
検索ASPやってる知人が言ってた	
• これはヤバイ
興味ある	
• MySQLで検索つらい
• でも
• SolrとかElasticSearchを自分で運用するのダルい
• JVMよくわからん
というわけで使ってみました	
• 検索素人な自分でも使えるのか!?
• ヒマだったし(´・ω・`)
なにはともあれデモ
デモ環境	
• http://cs.mikeda.jp
• データ:賃貸情報80万件
EC2	
CloudSearch	
Apache+PHP	
MySQL	
①検索(ID取得)	
②データ取出
デモ環境のデータ	
• フィールド数20
•  text:物件名、住所、詳細
•  int:家賃、県ID、都市ID、階、階建、最寄り駅からの距離
•  double:面積、敷金、礼金、仲介手数料
•  Date:築年月、更新日
•  リテラル:方角、物件タイプ(マンション、...)
•  リテラル配列:こだわり条件
•  数字配列:近隣駅の駅ID
お試し手順	
•  CloudSearchにドメインを作る
•  fieldを定義する
•  データをJSON化して突っ込む
•  curl -X POST --upload-file test.json
XXX.cloudsearch.amazonaws.com/2013-01-01/documents/batch --
header "Content-Type:application/json”
•  検索してみる
•  curl 'https://XXX.cloudsearch.amazonaws.com/2013-01-01/search?
q=mikeda’
数時間で検索できた!	
• 基本的に
• ManagementConsole OR SDKで設定
• REST & JSON(OR XML)でドキュメント追加&検索
CloudSearchの詳細
構成と自動スケーリング	
•  勝手にインスタンスタイプと個数が変動する(指定もできる)
•  スケールアップ(small → large →...)
•  シャーディング(データ分散)
•  レプリケーション(参照分散)
すごいけど価格見積もりが辛い・・・	
• SIMPLE MONTHLY CALCULATORで見積もれる
※基準がイマイチよくわからない
インスタンスタイプと価格	
•  SIMPLE MONTHLY CALCULATORでなんとなく見積もり
•  デフォルトはsmallが1つ
•  1K、100万ドキュメントで190万クエリ/日まで増やすとレプリカ+1
•  さらにドキュメント数を210万まで増やすとsmall→large
•  ※ドキュメント数は公式サンプルの場合の想定
 →フィールド数11、1ドキュメントあたり1K
タイプ	
 ドキュメント数(※)	
東京価格/H	
 東京価格/月	
search.m1.small	
 200 万 $0.13 	
 ¥9,500	
search.m1.large	
 800 万 $0.51 	
 ¥37,500	
search.m2.xlarge	
 1,600 万 $0.71 	
 ¥52,000	
search.m2.2xlarge	
32,00 万 $1.42 	
 ¥104,000
その他の価格	
•  ドキュメントバッチのアップロード
•  1000回で$0.1 (バッチあたりの最大サイズは5M)
→1Kのドキュメントを3000個ずつなら、30万ドキュメントで10円!?
•  IndexDocuments リクエスト
•  フィールド定義変更時などに実行
•  保持データ1Gあたり$0.98(1Kを100万個で1Gくらいらしい)
•  データ転送
•  OUT:$0.201 /GB
 →平均10Mbps(5Kを毎秒250回)で65,000円/月
•  データ転送だけ注意?
 → returnとhighlight多用するとけっこういくかも
パフォーマンス	
• インデックス作成
• 3000件ずつ20万件で30分ぐらい
• 並列OKらしいのでもっと早くできるかも
• 更新の反映
• 1件更新→10秒で反映
• 参照性能
• 本格的な負荷検証は未実施
• 10msから数百ms程度?
 →今回のデモのログから集計予定
信頼性	
• 冗長化はよしなにやってくれる
• 状況が見づらいのが辛い?
• マルチAZオプションもある
サジェストもある	
• ボタンで1つで設定できる
• 細かい調査はこれから!
カスタマイズ	
• なんかいじれるらしいです
• Stopwords
• Stemming
• Synonyms
というわけで
まとめ	
• AWS詳しい人達と仲良くなりたい!
• CloudSearch使ってみた
• 普通に使えそう
• Solr的な魔改造とか細かい調整はできなそう
• スニペット取れなそうとか?
• 国内の事例、情報がまだほとんどないので辛い
→達人出版で『CloudSearch入門』出すチャンス
終わり

AWS Casual2 LT