読者です 読者をやめる 読者になる 読者になる

よしだのブログ

サブタイトルはありません。

勉強会メモ - 第21回 AWS User Group - Japan 東京勉強会

IT、プログラミング AWS、クラウド、IaaS

f:id:yoshi0309:20140411201645p:plain

どうも!JAWS の勉強会に参加してきましたのでメモを公開します。

今回のテーマは「Startup CTO AWS Battle」。これだけの数のスタートアップの話を、5分とはいえ、一度に聞けるのはかなり貴重でした。登壇者のCTOの皆様、ありがとうございました。あと、かなり当たり前なのですが、AWS含むクラウドやサービスを使う目的は、インフラ運用を出来だけ省力化して、本来やるべきところにリソースを割くためであるという点については、いずれの方についても共通で、再度考えなおすきっかけとなりました。

また、やっぱりというかなんというか、Elasticsearch の人気はかなりのものでした。検索そのものももちろんですが、kibana でログ分析という用途でも使われているとのことです。ChatWork さんにいたっては、CloudSearch の大規模導入を控えているそうで、AWS Summit Tokyo の事例発表が楽しみです。

オープニング

  • アマゾンデータサービスの秦さん登場、スタートアップ担当。US からの担当者も来ている。お名前の漢字を間違えていたらすいません。
  • アマゾンはスタートアップに力を入れている。
  • 「かんぴょう」ってなんだっけ?w

特別登壇伊藤 直也さん

https://speakerdeck.com/naoya/sukerusurukai-fa-zu-zhi-falsezuo-rifang-number-jawsug

  • スケールする開発組織の作り方もしくは暗黙知を作らない組織運営の仕方
  • AWS でも手作業では昔と同じではないか?インフラをソフトウェア的に扱うことでコードで表現するという対策。暗黙知から形式知へ。
  • 作業時間の効率化が重要ではないか
  • 手作業でやっていては、クラウドの利点を無に返しているのでは
  • インフラ運用は、暗黙知がたまりやすい
  • 単にコード化すれば良いわけではない。
  • 開発の業務フローが変わることが最も大事。
  • github で pull request 開発をして、ちゃんとレビューができる。変更履歴の可視化も可能。また、情報共有にもなる。
  • 自動化そのものはあまり重要ではない。 分からないから保守的になる。暗黙知が保守的な意思決定を促してしまう。
  • スタートアップは、暗黙知が少ないから機動力がある。動ける範囲を自律的に見定めることができる。暗黙知の圧力に負けて保守的になる。
  • The Twelve-Factor App http://twelve-factor-ja.herokuapp.com/
  • ひと通り回ってくると、チーム間の情報共有が必要になる。フロー情報の共有として、Quiita:Team を使っている。Twitter のようなゆるさで、気軽に書けるツールが必要。wiki はストック型なので、なかなか書かれない。
  • メンタルモデルのコードへの反映
  • コード化しても「なぜ」が暗黙知化する点については意識する必要がある。

Wantedly株式会社 川崎 禎紀さん

https://speakerdeck.com/kawasy/how-wantedly-in-directly-uses-aws

  • Wantedly ではどう AWS を使っているか?
  • Heroku をメインで使っている。裏では、AWS を使っている Elasticsearch も。
  • Heroku を使うと開発のアジリティーが高まる、平日1日5回。気軽にスケール。
  • github + wercker + heroku
  • 流行っているテクノロジーを使うことを目的にしない!

Sansan株式会社 宍倉 功一さん

  • サービス開発に集中するために、AWSを使い倒す方針。
  • Eight KPI 、開発のPDCAサイクルの中で効果測定と検証で使う
  • 事業で見ている指標、User Growth Team で見ている指標、施策ごとで見ている指標
  • 分析結果を迅速に共有、関係者に共有、詳細な結果を簡単に共有
  • 日時分析の速報はメールで共有、主要な指標は Dashbordで、柔軟な分析のできるツール
  • FlyData で Redshift に放り込む。バッチでデイリーで分析し、SES で通知
  • DUCKSBOARD でダッシュボードのUIを表示。掲示ディスプレイで常に見えるように。
  • slash-7 で柔軟な分析を実現。

株式会社スマートエデュケーション 谷川裕之さん

  • 世界向けの発信には、S3 + CloudFront は必須。
  • ピークタイム(土曜日の朝)がはっきりしている。CLI で EC2 のインスタンスを増やす、デプロイするなど、事前準備がやりやすい。CLI は使わないと AWS の恩恵はない。
  • インフラもアプリも手間を少なくし、本来やるべきところに時間を使う。

ChatWork株式会社 山本 正喜さん

  • ビジネス向けチャット + タスク管理 + ビデオ通話
  • 検索には mroonga on EC2
  • アップロードしたドキュメントは直接 S3 に放り込んでいる。
  • 平時と休日にはっきりトラフィックの差がある、Auto Scaling を導入して、コストが下がる
  • mroonga は 1億レコード突っ込むと壊れるので、Elasticsearch に移行したい。の、タイミングで Amazon CloudSearch が登場。CloudSearch に乗り換え、検証済み。未本番導入。AWS Summit Tokyo の事例で話す予定。
  • Scala に全置き換え

株式会社nanapi 和田 修一さん

  • サービスごとに使用しているインフラが異なる。
  • アンサーは、読モやニコ生主が登場するとアクセスが急に増えることがある
  • chef でインフラ管理。オンプレも Vagrant も AWS の全部 chef の cookbook で
  • fluentd でログの集約。s3 に保管する他、elastic search + kibana でログ分析。
  • New Relic で SQL のパフォーなんす分析。

BASE株式会社 渡邉 涼一さん

  • ネタがなかったので、ネタ作りにセッション管理を Redis に移行してみた。
  • 安くなった!

ランサーズ株式会社 田邊 賢司 さん

  • ANSIBLE / docker / SEARVERSPEC も今後使いたい
  • プレ環境にスポットインスタンで24時間稼働している。2月に高騰することが多いようなので特に注意!
  • CLI で起動。余裕を持って入札価格を設定。
  • Appサーバーのスケールアップ。m3.large / c3.large を合わせて検討。c3.large に合わせてチューニング。メモリを増やさずに、CPU を活用することで節約。
  • 新インスタンスの情報を watch していると得することがある。

株式会社アカツキ 田中 勇輔さん

  • cloudformation + chef + capislano
  • git のタグを元にデプロイ内容を決定している。デプロイ先は AWS のタグで決定。
  • AWS のタグは役割の分類に最適。
  • RDS 、CM を打つと CPU リソースが枯渇することが予想された。
  • Commit 時の REDO ログと binlog の fsync() をやめて節約。障害時は最大1秒のオフライン時間が発生するが、CPU使用率が 30% から 5% に低下。あまりおすすめはしない。
  • 監視 cloudwatch-to-hipchat、cloudwatch のアラートをチャットに流す。

Kaizen platform Inc. 石橋 利真さん

  • 暗黙知の時代から、見える化の時代へ - 痛みがある。 ec2 keypair がなくなっていた・・ / RAILS_ENV はどこで設定されてんだ
  • chef / serverspec に以降
  • GitHub 時代のデプロイ戦略
  • 開発プロセスの改善

株式会社ビズリーチ 竹内 真さん

  • ルクサのことを話します、高級なタイムセールサイト
  • メール配信数が、一億通/月 !!
  • 大量メール配信システムは金額的に厳しいので使っていない。SES も高いので使っていない。自前で作っている。
  • SDK をキックして配信用のEC2サーバーを増減。配信する時間は決まっているので、時間単位でコントロール。EIP は予め確保 (Floating IP パターン)。
  • 最大15台までスケール。1時間よりちょっと短い時間になるように、台数を調整している。台数を多くし過ぎると、お金が勿体ない。

イベントレジスト株式会社 池田 大輔さん

  • 5ヶ国語で対応。インドネシア、ルピアでもOK.
  • Transifex 翻訳用のwebサービス
  • 最大の実績は CEATEC JAPAN 10万人超、申し込みの半数以上が会期中に集中する傾向
  • 構成は変わらないが、オートスケールの最小数を通常の5倍に設定し、トラブル無し。
  • インフラエンジニアでもコード書いて自動化出来ないと厳しいのでは。書けるようになると一人でも数十万人のアクセスでもさばける環境がある。

以上です!