すずけんメモ

技術メモです

re:Invent 2015のスライドをみたメモ その2

re:Invent 2015のスライドをみたメモ - すずけんメモ のつづき。

(BDT320) New! Streaming Data Flows with Amazon Kinesis Firehose

  • KinesisGMとPMの方の発表
  • Kinesis Streamの最近のupdate
    • 500 records / 5MB payloadまでのPutRecords API
    • 1レコードの最大payloadが1MBまで拡張
    • KCL, Python / Node/ Rubyとかでてたらしい
    • Kinesis Producer Libraryなんてでてたのか
    • サーバサイドタイムスタンプをサポート
    • ストリームを7日間まで残せるよう
  • Kinesis Firehose
    • Kinesis Applicationかかなくてもs3, Redshiftなどに転送できる
    • Delivery Stream: Firehose用にstreamを新しく作成したり、シャードをプロビジョンしなくてよい
    • Records: Firehoseへはdata producerから1000KB単位のblobで送られてくる
    • Data Producers: Delivery Streamにむけてレコードを送る
  • Redshiftへの適用
    • COPYコマンドを発行できる
  • Amazon Kinesis Agent
  • Firehoseは1GBあたり0.035ドル
  • FirehoseはKinesis Streamとちがって、設定して突っ込めばs3とかRedshiftまで送ってくれるツールKinesis Streamはカスタムしたいユーザ向け。
    • Firehoseの場合、特に管理しなくて良い。かつストリームに対して60秒以内にもろもろ仕事してくれるらしい
    • consumer側を書かなくて良いのは楽だなぁ
  • FirehoseをつかったS3への転送
    • Bufferサイズとintervalの設定がある
      • buffer sizeは1MBから128MBまで
      • buffer intervalは60から900秒まで
    • Firehoseでは1個の大きいオブジェクトにrecordをまとめるらしい
    • gzip, zip, snappyそれぞれに圧縮したりもできる
    • Redshiftだとgzipのみ
    • S3に配置する場合、 YYYY/MM/DD/HH のpathになる
      • prefixは指定できる
    • s3に通じない場合、5秒ごとに再試行する
  • Amazon Kinesis Analytics
    • まだリリースはされてない
    • Kinesis StreamだけじゃなくてFirehoseのdelivery streamもつかえるらしい

(BDT303) Running Spark and Presto on the Netflix Big Data Platform

  • Netflixの中の人のプレゼン
  • 視聴時間、Quarterで100億時間とな・・会員も6500万人以上
  • s3に25PB, 1日5500億イベント
  • 相変わらずEMRつかってるらしい
  • ParquetサポートのPredicate pushdownってなんだろ
    • ああ、読むひつようのないrow groupをskipするってことかな
  • Sparkもつかってる。 on YARN
  • YARNのDynamic Allocationがだいぶ重宝されてる感じだ
  • Sparkでのs3のlistが遅い問題
    • s3のlistはそもそも遅いんだけども、Netflixだと1テーブルのpartitionが100万とかになったりするらしい
    • AmazonS3Clientを並列に実行してバルクでパーティションをリストするようにしたとのこと

(SPOT302) Availability: The New Kind of Innovator’s Dilemma

  • NetflixのPerformanceとReliabilityのDirectorの方
  • 3 regionでactive-activeはすごいな・・・
  • microservices構成、それぞれのserviceごとにASGがわかれている
    • 500以上のマイクロサービスがある
  • AsgardじゃなくてSpinnakerというのに移行しているらしい
  • ビデオでみたいセッションだ

(CMP407) Lambda as Cron: Scheduling Invocations in AWS Lambda

  • Sophosの人のセッション
  • あれ、これLambdaのscheduled events使うのじゃだめなのか?
  • ああ、Lambda functionでsignalの波形になるようなのつくって、CloudWatchにおくり、alartをSNSにhookして定期実行させてるのか・・
  • g-a-d/lambda-cron
    • ** NOTE ** Amazon have now announced native scheduled functions for Lambda. You are very much advised to use those as opposed to this! 切ない

(BDT207) Real-Time Analytics In Service Of Self-Healing Ecosystems

(ARC348) Seagull: How Yelp Built A System For Task Execution

  • Yelpの方。CIにおけるテスト高速化の話。
  • Seagull: 並列なタスク実行のための分散システム
    • テスト実行とかをしてるらしい
  • 1日に350 seagullが走ってる
    • 1 seagullごとに7万テストはしってる
    • 2日間終わらないこととかあった
  • 3000のテストを200台のクラスたで実行してる
    • 2日間かかってたのが14分で終わるようになった
    • artifactのダウンロードだけで1日に36TB...
      • というかなぜそんなにartifactをダウンロードする必要があるのだろう
    • 1日に150万Dockerコンテナつくってるらしい
  • 構成はJenkinsクラスタ、ジョブ実行のためにcontainerなどなど
    • Homepage - SignalFx を監視につかってるらしい
    • Jenkinsではartifactをs3にあげてる
      • artifactは数百MBになるらしい
    • Jenkinsでテストがあるか否かを見つけている
    • テストの優先順位付けをしている
      • それぞれのテストにかかった時間をDynamoDBにいれてる
      • Prioritizerでそれをみるだけで2500万レコード/日してるらしい・・・
        • とはいえ月に200ドルくらい
  • ピークタイムにテストが集中する
    • Mesosのスケジューラを使って、600ワーカ立ててる
      • r3.8xlarge 200台
  • s3からのartifactダウンロードに時間がかかるのでnginxでserveするようにしたらしい
    • originはs3でfrontにnginxってことかな?
  • autoscaleの計算も、必要なメモリの総量を見積もってから行っている

(ARC308) The Serverless Company: Using AWS Lambda

(STG401) Amazon S3 Deep Dive & Best Practices

  • デモが面白そうな感じ
  • というかほとんどデモだこれ

(STG306) EFS: How to store 8 Exabytes & look good doing it

  • amazon.comの人
  • df -H で9.3Eとかでててやばい
  • EFSのパフォーマンスモデル
    • バーストクレジットというのがある
      • 12時間単位でたまっている。GBあたり0.05MiB/s。
    • たとえば1TBのファイルシステムについては
      • 50MB/sをずっと出し続けるか、100MB/sを1日あたり12時間だけ出せる
    • 広いユースケースにつかえるようにデザインしている

(BDT318) How Netflix Handles Up To 8 Million Events Per Second

(DVO313) Building Next-Generation Applications with Amazon ECS

  • METEORの中の人
  • Meteor
    • JavaScriptでwebとモバイルアプリのビルドするプラットフォーム
    • ああ、それで実行環境を分離できるECSはうれしいってことなのかな
  • Mobileだとconnected clientなアーキテクチャになると
    • connection貼りっぱなしの状態だとデプロイとかtrackingとかも大変
  • requirements
    • 10000オーダーの同時接続がある
  • clientが接続してくる層と裏のserviceレイヤをわけているらしい
    • WebSocketの場合、もし違うECS内のappに接続した場合にはcookieでIDを取得して、裏側のサービスへの問い合わせにつかっているっぽい
      • 裏側のサービスはユーザごとになるべく同じものを利用するようにする方針ぽさ
      • もし裏側のサービスが落ちていたらproxyが別のappを選択するようにしている
    • サービスをデプロイする場合には、まずcontainerを配置してから古いcontainerを落とす
      • するとproxyが新しいcontainerを選んでくれる
  • サービスメトリクスはcontainerごとに取得している
    • Docker Remote APIでとれる

(ARC403) From One To Many: Evolving VPC Design

  • AWSのPrincipal Solutions Architectの人
  • 家で試しましょう!とな
  • Scalable, Available NAT
    • NATを使わずにpublic subnetsでやるという選択肢もあるけどね
    • HA NATをEC2 Auto RecoveryとAuto Rebootを使って実現しよう
  • Auto Recovery
    • c3, c4, m3, r3, t2ならつかえる
    • Status Checkがこけたときにhookできる
      • rebootしたりとかもできる
  • VPC Endpointについて
    • aws ec2 create-vpc-endpoint --vpc-id vpc-40f18d25 --service-name com.amazonaws.us-west-2.s3 --route-table-ids rtb-2ae6a24f rtb-61c78704
    • route tableについて VPCE なtargetを追加できる
      • Prefix list: ロジカルなdestination target
      • s3のip rangeが変わってもこれで勝手に対応される

(SPOT301) AWS Innovation at Scale

  • 見れなくなってる?

(NET307) Pinterest: The road from EC2-Classic To EC2-VPC

  • PinterestのVPCへの移行事例
  • 1億のpinする人、ピークで15万リクエスト/秒
  • 移行理由はNetworkパフォーマンス、あとはセキュリティか。
  • 先にDBから移行したのか
    • ClassicLink使ったうえで
    • VPCにreplica作成
    • 次にVPCにmasterも移行
    • あとはworkerを随時VPCに移行

(GAM402) Turbine: A Microservice Approach to 3 Billion Game Requests

  • Turbineというゲーム会社の発表
  • Scaling MongoDB?
  • Mobile game platformの構成、ごりごりのCoreOSインフラだ
    • Go, Docker, CoreOS.
    • microservice構成になっててConsulつかってdiscovery
    • containerつかってるけど全部1MB以下らしい
      • OS入ってないcontainer
  • MongoDB構成
    • r3.2xlarge, 1shardあたり3台, 2TBのGP2
    • 100GB/hでoplogがでる。
    • backupも日に数TB
  • r3.8xlargeとかにしてshard数減らしたりもしたけど、結局r3.2xlargeでシャード増やしたほうが安定したらしい
    • write lockが5%分だけ起きてた
    • シャードを増やしたら安定
    • failoverするとき、メモリが大きすぎると逆にcompactionに時間がかかって失敗していたらしい
      • failoverのためにmongodが詰まる

(STG403) Amazon EBS: Designing for Performance

  • 200万volume/日でつくられているらしい。
  • Kernel 3.8以上でIndirect grantsがつかえるらしい
    • queueごとに4096KBつかえる
  • Pre-warmingいらなくなった件について
    • もうpre-warmingはおすすめじゃなくなったらしい

(DVO209) JAWS: A Scalable Serverless Framework

(DVO202) DevOps at Amazon: A Look At Our Tools & Processes

  • AmazonでのDevOps話
  • 年間5000万回デプロイ

(CMP402) Amazon EC2 Instances Deep Dive

  • EC2のPrincipal PMの方
  • Partition周りについてもがっつり説明されている
    • paritionの計算方法変わるかも、って書いてるな
  • Burst capacityについても数字でてるな
    • provisioned capacityが1200なら300秒間で3600CUが余力らしい
      • それでも足りなかったらthrottled requestになる
      • hot keyとかhot partitionが多くてもthrottledになるとのこと
  • AdRollのテーブルはうちでやったモデリングとほぼ一緒だ
  • Messaging appのmodeling例面白い

(ARC346) Scaling To 25 Billion Daily Requests Within 3 Months On AWS

  • 250億リクエスト/day
  • Data Processing Engine
    • Riakだ。messagingはRabbit MQでやってるらしい。

(BDT209) Launch: Amazon Elasticsearch For Real-Time Data Analytics

  • Elasticsearchのたちあげをやるよ、というサービス
  • Action をIAMで制限できるのはよさそう
    • es:ESHttpGet のみ許可、とか
  • awslabs/logstash-output-amazon_es
  • ESのメトリクスもCloudWatchでみることができる
    • JVM Memory Pressureとか
  • restoreとsnapshotの設定もできる