カジュアルなぼくの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つ

構成

感想

• カジュアルすぎるｗｗｗ • さてこれからどうするか(´・ω・｀)

• 各種冗長化 • 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入門』出すチャンス

終わり