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.

【JAWS UG 山形】ランサーズでのAWS活用事例

1,125 views

Published on

JAWS UG 山形で発表させて頂きました、ランサーズでのAWS活用事例です。

米沢で初めての開催で、母校の山形大学工学部で発表させていただきました。
AWS入門ということで、活用しているサービスを一通り紹介させていただきました。
大学の講義で出てくるテーマも一部織り交ぜています。

Published in: Engineering
  • Be the first to comment

【JAWS UG 山形】ランサーズでのAWS活用事例

  1. 1. ランサーズでのAWS活用事例 http://www.lancers.jp/ 「時間と場所にとらわれない、新しい働き方を創る」 [2016/11/12 JAWS UG 山形] ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki]
  2. 2. © 2016 for LANCERS, inc All Rights Reserved 自己紹介 • 氏名:金澤 裕毅 • 出身:宮城県仙台市 • 学歴:山形大学大学院理工学研究科 • 平中研究室(ネットワーク専攻) • 職歴: • 第一期(2002年~2010年) • Windowsパッケージ開発 • ASP開発、インフラ担当 • 札幌に2年間転勤 • 第二期(2010年~2013年11月) • 不動産ポータル、地域SNS • 第三期(2013年11月~現在) • ランサーズ株式会社 インフラエンジニア • 所属:JAWS-UG 山形支部
  3. 3. © 2016 for LANCERS, inc All Rights Reserved 本日お話しさせていただく内容 ランサーズ(株)のご紹介 AWS移行とVPC設計 ランサーズのEC2運用 MySQLのRDS化 CloudFrontでCDN化 CloudSearchで全文検索化
  4. 4. © 2016 for LANCERS, inc All Rights Reserved ランサーズ(株)のご紹介 ランサーズのEC2運用 MySQLのRDS化 CloudFrontでCDN化 CloudSearchで全文検索化 AWS移行とVPC設計
  5. 5. © 2016 for LANCERS, inc All Rights Reserved 会社概要 従業員 約 150 名 資本金 12 億 4904 万 4254 円 ( 資本準備金を含む ) 株主 創業者、KDDI、インテリジェンス、グロービス・ キャピタル・パートナーズ、GMO VenturePartners、グリーグループ、コロプラ、 オ プト 本社所在地 会社名 ランサーズ株式会社 (LANCERS,INC.) 所在地 〒150-0002 東京都渋谷区渋谷 3-10-13 渋谷 R TOKYU REIT 渋谷Rビル 9F 設立 2008 年 4 月 事業 クラウドソーシング事業 http://www.lancers.jp/
  6. 6. ランサーズが提供する「クラウドソーシング」 Crowd(群衆) Sourcing(外注) Web上で個人等に 業務委託 ※エスクロー決済 ※プラットフォーム Fee 受託者 (ワーカー) 発注者 (クライアント) 発注 作業 納品 「時間と場所にとらわれない働き方」 141のカテゴリ
  7. 7. 国内市場における仕事受給の流れ 1000億円以上の仕事流通 依頼額の54%が 東京の企業 受注額の75%が 地方の個人 3.2% 3.5% 5.0% 8.5% 12.0% 13.6% 54.3% 5.0% 7.8% 11.2% 11.5% 19.6% 20.2% 24.7% 東京 中部 関西 東京以外の関東 東京 関西 東京以外の関東 中部 九州 北海道、東北中四国 九州 中四国北海道、東北 東京 54.3% 東京以外 75.3%
  8. 8. 7 仕事の依頼例(一部のカテゴリを抜粋) • コンペ方式 • プロジェクト方式 • タスク方式
  9. 9. ランサーからもスキル商品を出品可能 自分のスキルや得意を商品に見立てて出品、逆にできないことはお願いする スキルサービスECを4月より開始しました
  10. 10. スキルはもちろん「得意なこと」も 詳しくは「ランサーズストア」で検索 チラシ、ライティング、SEOコンサル、似顔絵作成、wordpress構築など 個人が持つ多種多様な「スキルや得意」を相互に売り買いしています
  11. 11. © 2016 for LANCERS, inc All Rights Reserved 10 AWS移行とVPC設計 ランサーズのEC2運用 MySQLのRDS化 CloudFrontでCDN化 CloudSearchで全文検索化 ランサーズ(株)のご紹介
  12. 12. © 2016 for LANCERS, inc All Rights Reserved ランサーズの稼働環境 • App:EC2 • Apache + PHP • WebSocket:EC2 • メッセージサービス • node.js • DB:MySQL 5.6(Aurora) • MultiAZ配置 • HAProxyで負荷分散 • Memcahed(ErastiCache) • セッション情報 • Redis(ErastiCache) • PubSubでWebSocketと連動 • 全文検索:CloudSearch • SQSで連動 • ストレージ:S3 • アップロードファイル保存用 • CDN:CloudFront • サムネイルや静的ファイルをキャッシュ • OriginはEC2(Appサーバー) EC2 App S3 Aurora Reader ELB CloudFront SQS Cloud Search Route53 EC2 instance WebSocket ErastiCache Memcached ErastiCache Redis Aurora Writer
  13. 13. © 2016 for LANCERS, inc All Rights Reserved なぜAWSに移行しようと思ったのか 12  HDD圧迫(大容量プランにするか???)  Appサーバメモリ逼迫(4GBだったため、不足。。。)  スケールしない(AP2台 DB2台の構成 DNSラウンドロビンだった) ⇒契約したプラン上、1台だけ増やす、HDD増量が出来ない 移行を考え出した「きっかけ」  2012年からサービス拡大期へ  TV紹介も狙い出す AWS移行前の「問題例」 どれぐらいアクセス が増えるのか? TV効果は一時的?
  14. 14. © 2016 for LANCERS, inc All Rights Reserved AWS移行後のシステム構成(2012/5) S3 Bucket Elastic Load Balancer EC2 WebServer Elastic Load Balancer EC2 DB Slave EC2 DB Slave EC2 DB Master ap-northeast-1a 移行後 App App 移行前 DB Master DB Slave Internet Internet Data Center DNSラウンド ロビン
  15. 15. © 2016 for LANCERS, inc All Rights Reserved AZを分散して冗長化(2014/5)
  16. 16. © 2016 for LANCERS, inc All Rights Reserved AppとDBを2つのAZに分散する意味 RDS Master RDS Read Replica App ap-northeast-1a EC2 instance ELB App EC2 instance App EC2 instance RDS Multi AZ RDS Read Replica App ap-northeast-1c EC2 instance ELB App EC2 instance App EC2 instance AZ間の通信遅延は 数ミリ〜数十ミリ secレベル • AZレベルの障害を想定 Route53
  17. 17. © 2016 for LANCERS, inc All Rights Reserved RDS Multi AZ AppとDBを2つのAZに分散する意味 RDS MasterRDS Read Replica App ap-northeast-1a EC2 instance ELB App EC2 instance App EC2 instance RDS Read Replica App ap-northeast-1c EC2 instance ELB App EC2 instance App EC2 instance • AZレベルの障害を想定 Route53
  18. 18. © 2016 for LANCERS, inc All Rights Reserved ランサーズのEC2運用 AWS移行とVPC設計 MySQLのRDS化 CloudFrontでCDN化 CloudSearchで全文検索化 ランサーズ(株)のご紹介
  19. 19. © 2016 for LANCERS, inc All Rights Reserved コストパフォーマンスの高いインスタンスを探す • AWS Price List API から価格データを取得 • 月額日本円に換算
  20. 20. © 2016 for LANCERS, inc All Rights Reserved コストパフォーマンスの高いインスタンスを探す オンデマンド月額 CPU数 メモリ t2.nano 約770円 1 0.5GB t2.micro 約1540円 1 1GB t2.small 約3080円 1 2GB t2.medium 約6160円 2 4GB t2.large 約12320円 2 8GB 価格は2倍 単位で上昇 1コアで一番お得 2コアで一番お得 • t2系インスタンスの場合 • t2.nanoがCPU的に一番お得 • t2.micro x 1 と t2.nano x 2は同じ費用 • t2.mediumもお得 • 2コアのインスタンスでCPU的に一番安い • ※CPUクレジット数は違うので注意
  21. 21. © 2016 for LANCERS, inc All Rights Reserved コストパフォーマンスの高いインスタンスを探す オンデマンド月額 CPU数 ECU(CPU力) メモリ m1.medium 約9350円 1 2 3.75GB m1.large 約18700円 2 4 7.5GB m3.large 約14900円 2 6.5 7.5GB m4.large 約13400円 2 6.5 8GB c3.large 約9850円 2 7 3.75GB c4.large 約10230円 2 8 3.75GB r3.large 約15400円 2 6.5 15.25GB • コストパフォーマンスはm1 < m3 < m4 の順に高い • 新しいインスタンスの方が高くなる傾向にある • m系よりもc系、r系の方がコストパフォーマンスが高め • 全体的にCPUよりもメモリのほうが割高 CPU最適化 メモリ最適化 現行世代 旧世代
  22. 22. © 2016 for LANCERS, inc All Rights Reserved メモリを節約するテクニック • ELBのSSL Terminate機能を利用 • EC2内ではhttpのみで通信する • Apacheのmod_sslをやめるとメモリ使用量が半減 • プロセスをこまめに切る • Apacheのmod_phpのGCをアテにしない • 早めに切ってメモリを確保 • プロセスの起動回数が増えるのでCPU消費は増える • プロセスモデルではなくスレッドモデルを採用する • Apacheならpreforkではなくworker等の利用を検討 EC2 ELB https://www.lancers.jp/ http://www.lancers.jp/ SSL Terminate
  23. 23. © 2016 for LANCERS, inc All Rights Reserved Appをm1.medium→c3.largeに移行(2014/5) • c3.largeに合わせてチューニング • CPUはm1.mediumの3.5倍 • 2CPU • メモリはm1.mediumと同じ • 3.75GB •CPUを利用してメモリを節約 •結果 • レスポンス時間が1/3に短縮 • サーバー台数を4台削減 • 費用も削減 <IfModule prefork.c> StartServers 10 MinSpareServers 10 MaxSpareServers 20 ServerLimit 190 MaxClients 190 MaxRequestsPerChild 50 </IfModule> プロセスをこまめに削 除してメモリを確保 移行前 移行後
  24. 24. © 2016 for LANCERS, inc All Rights Reserved EC2インスタンスの料金体系 • オンデマンドインスタンス • 時間単位 • リザーブドインスタンス • 1年、または3年単位でまとめ買い • No Upfront (前払い無し) • Partial Upfront (一部前払い) • All Upfront (全額前払い) • →50%~75%の割引 • スポットインスタンス • 入札方式のインスタンス • 入札価格より高くなると削除される • →最大90%割引 • ※t2系はサポートしていない
  25. 25. © 2016 for LANCERS, inc All Rights Reserved リザーブドインスタンスの損益分岐点(c4.large) オンデマンド リザーブド3年 一括払い リザーブド1年 一括払い スポット(目安) リザーブド1年 損益分岐点(8ヶ月) リザーブド3年 損益分岐点(17ヶ月)
  26. 26. © 2016 for LANCERS, inc All Rights Reserved スポットインスタンスの活用 • t1.microの料金 • オンデマンドインスタンス • $0.026/h(¥1,935/月) • スポットインスタンス(時価目安) • 約$0.0031/h(約¥231/月) • スポットインスタンスのPricing History • c系インスタンスは競争が激しい • t1.microは平和な傾向 時々高騰して削除される
  27. 27. © 2016 for LANCERS, inc All Rights Reserved Amazon Linux • AWSがCentOS 6をベースに独自にチューニングしたLinux • 最新のカーネルとAWS独自のパッケージを用意 • AWS用に最適化 • すべてのインスタンスクラスに対応 • インスタンスクラスに応じてパラメータを自動チューニング • RDSのParamater Groupと同様 • AWS SDKインストール済 • cloud-init機能 • EC2インスタンス起動時に様々なパラメータを渡したり、ソフト ウェアをインストールしたりできる • セキュリティ脆弱性への対応が早い • 大事! Red Hat LinuxのクローンOS
  28. 28. © 2016 for LANCERS, inc All Rights Reserved Amazon LinuxとCentOSの違い CentOS 6.8 CentOS 7.2 Amazon Linux 2016.09 カーネル 2.6.32-642.6.1 3.10.0-327.36.3 4.4.19-29.55 glibc 2.12-1.192 2.17-106 2.17-106 Apache 2.2.15-54 2.4.6-40 2.2.31-1.8 2.4.23-1.66 Nginx 1.10.1-1.28 MySQL 5.1.73-7 mariadb 5.5.50-1 5.5-1.6 5.6.33-1.21 PostgreSQL 8.4.20-6 9.2.15-1 9.2.18-1.59 PHP 5.3.3-48 5.4.16-36 5.3.29-1.8 5.4.45-1.75 5.5.38-2.118 5.6.26-1.128 OpenSSL 1.0.1e-48 1.0.1e-51 1.0.1k-15.96 nkf 2.0.8b-6.2 Git 1.7.1-4 1.8.3.1-6 2.7.4-1.47 ImageMagick 6.7.2.7-5 6.7.8.9-15 6.7.8.9-15.2
  29. 29. © 2016 for LANCERS, inc All Rights Reserved MySQLのRDS化 ランサーズのEC2運用 AWS移行とVPC設計 CloudFrontでCDN化 CloudSearchで全文検索化 ランサーズ(株)のご紹介
  30. 30. © 2016 for LANCERS, inc All Rights Reserved 29 RDS化後のシステム構成(2013/12) S3 Bucket Elastic Load Balancer EC2 WebServer Elastic Load Balancer EC2 DB Slave EC2 DB Slave EC2 DB Master ap-northeast-1a S3 Bucket Elastic Load Balancer EC2 WebServer ap-northeast-1a RDS Master RDS Read Replica RDS Multi AZ ap-northeast-1c RDS化前 RDS化後
  31. 31. © 2016 for LANCERS, inc All Rights Reserved 30 RDS(MySQL)のメリット • Multi AZ配置 • マスタDBと異なるAZにスタンバイを用意 • 障害時に自動フェイルオーバー • 停止時間は2分~7分(計測値) S3 Bucket Elastic Load Balancer EC2 WebServer ap-northeast-1a RDS Master RDS Read Replica RDS Multi AZ ap-northeast-1c db-master.xxxxx.ap-northeast-1.rds.amazonaws.com
  32. 32. © 2016 for LANCERS, inc All Rights Reserved RDS(MySQL)のメリット • リードレプリカ(参照専用スレーブ)を手軽に作成できる • メニューから選択するだけ
  33. 33. © 2016 for LANCERS, inc All Rights Reserved 32 RDS(MySQL)のメリット • ポイントタイムリカバリ • 任意の時間にDBを戻すことが可能 • 35日前まで保管可能(要設定)
  34. 34. © 2016 for LANCERS, inc All Rights Reserved RDS(MySQL)のメリット • ClowdWatch • EC2よりも豊富(空きメモリ、空きHDDも確認可)
  35. 35. © 2016 for LANCERS, inc All Rights Reserved 34 RDS(MySQL)のメリット • スナップショット機能 • Manual Snapshot • 手動スナップショット • インスタンス削除時に取得するか訊かれる • Automated Snapshot • 毎日自動的に取得される差分スナップショット • 35日間まで取得可能 • マスターDBが消えると削除される
  36. 36. © 2016 for LANCERS, inc All Rights Reserved 35 RDS(MySQL)のデメリット • EC2に比べて割高 • r3.large:$0.2/h(東京リージョン) • db.r3.large:$0.285/h(東京リージョン) • MultiAZスタンバイ機は使えない • でも料金は2台分 S3 Bucket Elastic Load Balancer EC2 WebServer ap-northeast-1a RDS Master RDS Read Replica RDS Multi AZ ap-northeast-1c バックアップ専用 利用不可
  37. 37. © 2016 for LANCERS, inc All Rights Reserved 36 RDS(MySQL)のデメリット • SSHログインできない • RDS接続用のEC2サーバーを用意 • mysqldumpのエクスポート結果もここに格納 MySQL Client EC2 RDS db-master.xxx.ap-northeast-1.rds.amazonaws.com $ mysql -h db-master.xxx.ap-northeast-1.rds.amazonaws.com -u mysqluser –p
  38. 38. © 2016 for LANCERS, inc All Rights Reserved 37 RDS(MySQL)のデメリット • Tritonn、Mroongaが使えない • 日本語全文検索ができるMySQLパッケージ • RDSを選択したら全文検索は自前で構築する必要がある • Groongaとか • Solrとか • ErasticSearchとか mysql> SELECT * FROM timetable WHERE MATCH(title) AGAINST("クラウド"); +----+-----------------------------------------------------+---------------------+ | id | title | start | +----+-----------------------------------------------------+---------------------+ | 35 | 「クラウドソーシングLancers」を支えるRDS for MySQL | 2014-03-15 17:00:00 | +----+-----------------------------------------------------+---------------------+ 1 row in set (0.00 sec)
  39. 39. © 2016 for LANCERS, inc All Rights Reserved SSH Tunnelingで外部からMySQL接続 EC2 Aurora Reader SSH Tunneling サーバー • SSH Tunnelingサーバー経由でPrivate VPCの参照用MySQLに接続 • エンジニア以外の社員もSQLでデータ取得 ・SQLクライアント ・接続先:社内サーバー ・接続ポート:8025(任意に設定) $ ssh -N -f -p 22 -i /home/mysqluser/.ssh/ec2.id_rsa ec2- user@EC2のIPアドレス -g -L 8025:lancers001.xxx.ap- northeast-1.rds.amazonaws.com:3306 Lancers EC2 instance
  40. 40. © 2016 for LANCERS, inc All Rights Reserved Auroraの登場 • クラウドを前提にMySQLを再構築 • 2014/11に発表 • 2015/10 より東京リージョンでも利用可能に • →ランサーズでは、2016/1にAuroraに移行
  41. 41. © 2016 for LANCERS, inc All Rights Reserved Auroraのメリット:パフォーマンス • レプリケーションの効率化 • Log structured Storage • 他多数… RDS Aurora MasterとReplicaのストレージが共有されている
  42. 42. © 2016 for LANCERS, inc All Rights Reserved Auroraのメリット:レプリカ遅延の解消 • Auroraでメンテナンスなしでカラム追加可能に • MySQL 5.6はオンラインDDL機能がサポートされている • →RDSではリードレプリカのReplica Lagが大きく、 稼働中のALTER TABLEができなかった RDS Aurora 大きな Replica Lag が発生 Replica Lagは msレベル mysql> ALTER TABLE t1 ADD COLUMN c1 tynyint(1) NOT NULL DEFAULT 0; mysql> ALTER TABLE t1 ADD COLUMN c1 tynyint(1) NOT NULL DEFAULT 0; MasterとReplicaのストレージが共有されている
  43. 43. © 2016 for LANCERS, inc All Rights Reserved Aurora移行後のReplica Lag RDS Aurora • Auroraはほぼ30ms以下
  44. 44. © 2016 for LANCERS, inc All Rights Reserved カラム追加時のReplica Lag 24.5GB、1000万件のテーブルにカラム追加したときの計測結果 インスタンスタイプ 処理時間 Replica Lagの時間 CPU使用率 RDS: r3.xlarge 4時間32分 最大15000秒 Master:約10% Slave: 約1% Aurora:r3.xlarge 2時間12分 最大2秒 Writer:約47% Reader: 約17% RDS Aurora • 大きなテーブルでも遅延は2秒以下 • メンテナンスなしのカラム追加が可能に
  45. 45. © 2016 for LANCERS, inc All Rights Reserved Auroraのメリット:RRが15台まで可能 • RDS • 1マスターにつき5台まで • TV放映用に予備2台分確保 • 作成時間:約10~40分 • リードレプリカの上限値が増加 • Aurora • 1マスターにつき15台まで • TV放映用に13台確保できる • 作成時間:約5分 データ取得用 1台 App用 2台 TV放映用 2台(予備) 多層構成にすれば 2台以上可能だが Replica Lagが 大きくなる データ取得用 1台 App用 2台 TV放映用 13台
  46. 46. © 2016 for LANCERS, inc All Rights Reserved Auroraのメリット:MultiAZ費用の削減 • RDSのMulti AZ 1台分費用削減できる • Auroraは障害時にReaderの1台がWriterに昇格する仕組み 45 WebServer ap-northeast-1a Master Read Replica Multi AZ ap-northeast-1c EC2 instance Read ReplicaRead Replica RDS WebServer ap-northeast-1a Reader ap-northeast-1c ReaderReader Aurora Writer EC2 instance EC2 instance MultiAZ分の 費用がかから ない
  47. 47. © 2016 for LANCERS, inc All Rights Reserved インスタンスタイプ • インスタンスクラスはdb.r3.large以上(2016/11/5現在) • t2系のインスタンスが今後サポートされる予定
  48. 48. © 2016 for LANCERS, inc All Rights Reserved CloudFrontでCDN化 ランサーズのEC2運用 MySQLのRDS化 CloudSearchで全文検索化 AWS移行とVPC設計 ランサーズ(株)のご紹介
  49. 49. © 2016 for LANCERS, inc All Rights Reserved CDN(Content Delivery Network)とは • Web配信のために最適化されたネットワーク • 世界の各地にキャッシュサーバ(エッジロケーション)を配置 • 一番近いエッジロケーションがキャッシュしたコンテンツを返す CDNなし CDNあり エッジロケーション
  50. 50. © 2016 for LANCERS, inc All Rights Reserved CloudFrontの導入前の画像アクセスフロー EC2 instance EC2 App User S3 NFS Route531.サムネイル要求 2.サムネイル存在チェック →なし 3.元画像を要求4.サムネイル作成 1回目 2回目 EC2 instance EC2 App User S3 NFS Route531.サムネイル要求 2.サムネイル存在チェック →あり 4.NFSのキャッシュ を返す 5. NFSに保存 NFSのHDDが 逼迫 img.lancers.jp img.lancers.jp img.lancers.jp img.lancers.jp
  51. 51. © 2016 for LANCERS, inc All Rights Reserved CloudFrontの導入後の画像アクセスフロー EC2 App User S3 Route531.サムネイル要求 2. Edge Locationの キャッシュを返す 1回目 2回目 EC2 App User S3 Route53 1.サムネイル要求 2.元画像を要求 3.サムネイル作成 &Edge Locationに保存 2.キャッシュチェック →なし 2.キャッシュチェック →あり EC2 instance EC2 instance NFS NFS img.lancers.jp img-origin.lancers.jp img-origin.lancers.jp img.lancers.jp img.lancers.jp img.lancers.jp
  52. 52. © 2016 for LANCERS, inc All Rights Reserved CloudFrontの適用 • Distributionの設定 • Route53でDNSのレコードを変更 • Webサーバーの設定変更 <VirtualHost *:80> - ServerName img.lancers.jp + ServerName img-origin.lancers.jp
  53. 53. © 2016 for LANCERS, inc All Rights Reserved CloudSearchで全文検索化 ランサーズのEC2運用 MySQLのRDS化 CloudFrontでCDN化 AWS移行とVPC設計 ランサーズ(株)のご紹介
  54. 54. © 2016 for LANCERS, inc All Rights Reserved 全文検索とは • SQLのLIKEは前方一致しかインデックスが効かない SELECT * FROM users WHERE user_name LIKE '金澤%' -- 前方一致インデックスで検索可能 SELECT * FROM users WHERE user_name LIKE '%金澤%' -- 中間一致、後方一致はインデックス不可
  55. 55. © 2016 for LANCERS, inc All Rights Reserved 全文検索エンジン • Namazu • 日本で古くから普及していた全文検索エンジン • Lucene系 • Lucene • Java実装の全文検索ライブラリ • Solr • Luceneで構築された全文検索エンジン • AWS CloudSearchで採用 • Erasticsearch • Lucene基盤の分散検索エンジン • AWS Erastisearch Serviceで採用 • Senna系 • Senna • Tritton(MySQLバインディング) • Groonga • Sennaの後継検索エンジン • Mroonga(MySQLバインディング) SQLのMATCH〜AGEINST 構文で検索可能 RDSでは未サポート ログ分析のプラット フォームとして主に 利用されている Amazon CloudSearch Amazon Elasticsearch Service
  56. 56. © 2016 for LANCERS, inc All Rights Reserved 日本語の形態素解析器 • JUMAN • 形態素解析器の先駆け • 京大で開発 • Kakashi • Namazuで主に採用 • Chasen • JUMANから派生した • Namazuで主に採用 • Mecab • C++実装(各言語の派生バージョンあり) • Namazu、Lucene、Solr等で幅広く採用 • MySQL 5.7ではMecabプラグインをサポート • Kuromoji • Java実装 • Solr、Erasticsearchで主に採用 SQLのMATCH〜AGEINST 構文で検索可能 RDSでは未サポート
  57. 57. © 2016 for LANCERS, inc All Rights Reserved CloudSearchのメリット • EC2でSolrを構築するのに比べて • インストール作業不要 • Dashboardから新規ドメインを作成 • 自動スケールアウト • 自動スケールアップ • Multi AZ機能をサポート • 冗長性を確保可能 スケールの設定 MultiAZの設定 Indexの設定
  58. 58. ご清聴ありがとうございました! ランサーズ株式会社 インフラエンジニア 金澤 裕毅 [Kanazawa Yuki] 「時間と場所にとらわれない、新しい働き方を創る」 [2016/11/12 JAWS UG 山形] http://www.lancers.jp/

×