Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS Casual2 LT

9,650 views

Published on

Published in: Engineering
  • Sex in your area is here: ♥♥♥ http://bit.ly/2ZDZFYj ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ❤❤❤ http://bit.ly/2ZDZFYj ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

AWS Casual2 LT

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

×