AWS Casual2 LT

カジュアルなぼくのAWS経験と CloudSearchを触ってみた話 AWS Casual #2 LT @mikeda

自己紹介 • @mikeda • インフラエンジニア • イタンジ株式会社 • 不動産系サービス • 今月入社

今日は • はじめまして！ • 4/1からAWSメインの会社に転職しました • というわけで挨拶がてら • 数少ないAWS経験 • 最近検証中のCloudSearch • の話をします！

ぼくのAWS経験

最初の経験

六本木のソシャゲ系の会社 • 初の海外展開（USA） • 2012/?? ※今どうなってるかは知らないです！ • 国内は全て都内DCのｵﾝﾌﾟﾚ環境

構成

VPC構成

構成 • VPCを使ってオンプレと統一的な運用 •  DCとVPN接続。外部接続はELBｱｸｾｽとVPN経由のみ •  ELB以外はSecurityGroupはﾛｰｶﾙ全許可の1つだけ •  オンプレと同構成の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入門』出すチャンス

終わり

AWS Casual2 LT

by Tomohiro Ikeda, Working at Naviplus on Apr 18, 2014

Statistics

Views

Actions

0 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

AWS Casual2 LT Presentation Transcript