すずけんメモ

技術メモです

AWS re:Invent breakout session 1日目

reinvent aws

re:Invent 2014 breakout session 1日目

個人的にメモっておきます。

Keynoteでは、AuroraがでたりConfigだったりCodeDeployだったりがでました。細かい機能の話は参照しておいて、所感中心で。

聴いたセッションは以下のとおり。

  • SDD406 -- Amazon EC2 Instances Deep Dive
  • SDD415 NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine
  • BDT403 - Netflix's Next Generation Big Data Platform
  • BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon Elastic MapReduce and Storm
  • APP402 -- Serving Billions of Web Requests Each Day with Elastic Beanstalk

新サービス類

Aurora

AWSのためにre-designされた、速くてスケールするMySQLです。*1 まだPreviewでusでのみ限定公開になります。

所感

  • 銀の弾丸ではない
  • ストレージとログのレイヤを既存のMySQLの構造から切り出してAWSのアーキテクチャにフィットさせているあたりかっこよい
  • キャッシュがDBのプロセスの外に出たのは嬉しい、restartしても残るわけだし
  • マルチマスターにしなくてよいほどにwriteが安定して速いといいなぁ（安直にマルチマスターの機能を追加するよりは、パフォーマンスをどんどん上げる方向に向いていって欲しいなぁと思った
  • 「MySQLよりパフォーマンスが5倍向上！」がひとり歩きして、まだリリースされていないのに大変だなと思った
  • つまるところ使ってみないとわからん

Code ManagementとDeployのツールいろいろ

所感

In the past 12 months alone, Apollo was used for 50M deployments to development, testing, and production hosts.

  • 実際にどれくらいのユーザが使うかはわからないけどCIサーバの運用しなくなるならいいなと思った
  • でもおそらくOpsWorksじゃないけど、全てのユーザがこれに乗っかるようなものではないだろうなあとも思う
  • そう、やはり使ってみないとわからん

セッション

SDD406 -- Amazon EC2 Instances Deep Dive

EC2 instanceの話。

  • EC2 instanceのProduct ManagerのJohnさんとKernelとかOS周りやってるAnthonyさんのセッション
  • とりあえずKernel 3.8以降使っとけって言ってた
  • t2.microのCPU burstなんかについて、どういう設計思想でつくったか、みたいな話もあった
  • PV-HVMがなぜPVより速いか、あたりについての解説

SDD415 NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine

機能周りは上に書いたのでQAのメモを貼っておく。立ち見でてた。

  • RDS: MySQL -> auroraのマイグレートは簡単に
    • バイナリフォーマットでコンバートできるように
  • MySQLのコンパティビリティを壊してはいないから、既存ツールも動くはず
  • Encryptionはサポート予定
  • 開発用のローカルバージョンは出さない予定
    • MySQL 5.6と変わらないからね
  • MySQLの新しいバージョンにも追従していく予定
  • Postgreサポートするか？
    • 今日はないよw
    • MySQLはユーザ多いからやった
    • 可能だけどどこに今後サポートとするかによるかな
  • スケーリングはシンプルに出来る
  • dedicatedインスタンスは今後の展開次第
  • network ioのコストは、殆どない。なぜならVPC内だから
  • multi-masterはどう？
    • それぞれのマスターノードしか用意出来てない
    • 顧客の要望があるならやるかも？
      • 現時点での見解としてはmulti-masterにする必要はないと思ってる

BDT403 - Netflix's Next Generation Big Data Platform

Netflixの解析基盤の話 in 2014。去年もごりごりいろんな発表合ったので、どんなupdateあるのかなと思いながらきいた。このセッションもほぼ満員だった

  • 2013年と比較すると、Prestoの採用とHadoop 2への移行, Parquet FFへの移行というのが大きい話
  • Parquet, Pig, Hive, Prestoにそれぞれcontributeした
    • column position based access, Data type coercion, Null paddingなどなど
  • Parquetへの移行の話
    • 全てのイベントテーブルを移行
    • 新しいパーティションをつくって、そっちはParquetに。
    • 元からあったパーティションはTTLつけておいて徐々に無効化されていった。
    • PrestoのデプロイはEMRのbootstrapでjarを配置するだけ。
  • 規模
    • NetflixのDW: 10+PBDW on s3, 1.2PB read daily 100TB written daily
    • NetflixのEMRクラスタ:
      • ETLやProduction: 2200+ m1.xlarge
        • 日中はボーナスクラスタとして、さらに3 * 150 m2.4xlarge追加してる
      • adhocな利用やtest用: 2000+ m1.xlarge
        • これに加えて Presto用のクラスタ: 250 m2.4xlarge
  • Hadoop 2への移行の作業について
    • パッチあてた
      • userのqueueを動的に階層化する
      • 動的に公正な共有を行うようにした
    • Genieからジョブをディスパッチする際に、Hadoop1と2を並行稼働させてそれぞれにジョブなげてた
    • 今は全体をHadoop 2系に移行した。EMRだからmigrationはわりと楽だった。
  • Prestoについて, アドホックな分析に利用してる。TBオーダでもインタラクティブに動く
    • NetflixのPrestoへのコントリビュート: S3 filesystem対応、Parquet対応、ODBC driver改善、map / array改善、などなど
  • Netflixがソフトウェアを選ぶ基準: ホワイトボックスであること
  • なぜEMRを使うのか

所感

  • 熱かった

BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon Elastic MapReduce and Storm

Yelpのなかの人のパフォーマンスモニタリング話

所感

  • EMRとStormの話はそんなに出てこなかった

APP402 -- Serving Billions of Web Requests Each Day with Elastic Beanstalk

ほんとはDataDogのDocker Containerのscaleとmonitoringに関するセッションにいこうと思ってたんだけど会場が満員で入れず・・・ということでこちらにきた。

ThinkNearというMobileのRTB事業者さんのセッション。

メモ

  • Elastic Beanstalkをばりばりつかってる
    • デプロイ簡単だし、revertも簡単だし、楽
    • だけどログ周りとかモニタリングとかは工夫しないとつらい
    • Tomcat, maxで150k req / sec
  • 構成
    • Apache + Tomcat + Beanstalk + ELB + DynamoDB + Elasticache + S3
    • メインのDBはElasticache
  • networkまわり
    • tomcatがだいたい1000-1200ファイルくらい常に開いてる
    • net.core.somaxconnあげておく。4096にしてる。バーストしたらまずこれが枯渇する。
    • net.ipv4.tcp_fin_timeout 大事。timeout大事。ELB側も合わせて調整すること。
    • ELBはConnection Drainingの設定しておく。timeoutしたときにスムーズに外せるように。
  • ログ周り
    • collectedで収集して、libratoに飛ばしてる
    • モニタリングの時、hostnameがBeanstalkだと重複したりするから、適当にUUID生成するようにしてる
    • Logrotateつかってる
    • cronつかってる。cronも失敗するときあるからモニタリングすること。
  • ディスク
    • EBS遅いからraid0してる
    • tomcatのログはephemeralに書いてる

というのを全部構成するための設定がGitHubに載ってる。Yeah!

ThinkNear/aws_templates

所感

  • Elastic Beanstalkでがんばるとかまじか・・・と思ったがまじだった
  • Hotkey問題、あるあるだった
    • Elasticacheは外部キャッシュとしてはやはり速い。そしてアプリケーションのキャッシュはさらに速い
  • ちょっと考えさせられた
    • try and errorいろいろあれど、beanstalkでそれなりにさばけるところまで持っていくの、それはそれで戦略だなと思った
  • それにしても俺得セッションだった

*1:かなり適当にまとめています