re:Invent 2015のスライドをみたメモ その2
re:Invent 2015のスライドをみたメモ - すずけんメモ のつづき。
(BDT320) New! Streaming Data Flows with Amazon Kinesis Firehose
- KinesisのGMとPMの方の発表
- Kinesis Streamの最近のupdate
- Kinesis Firehose
- Redshiftへの適用
- COPYコマンドを発行できる
- Amazon Kinesis Agent
- Firehoseのためのagent
- ファイルをモニタリングしてDelivery Streamにおくったり、ファイルのローテーションおいかけたり、リトライしたりする
- Fluentdみたいなやつっぽいさがある
- Agentの状況はCloudWatchでみることができる
- AgentはFirehoseだけじゃなくてKinesis Streamにもつかえる
- Writing to a Delivery Stream with Amazon Kinesis Agents - Amazon Kinesis Firehose
- Firehoseは1GBあたり0.035ドル
- FirehoseはKinesis Streamとちがって、設定して突っ込めばs3とかRedshiftまで送ってくれるツール。Kinesis Streamはカスタムしたいユーザ向け。
- Firehoseの場合、特に管理しなくて良い。かつストリームに対して60秒以内にもろもろ仕事してくれるらしい
- consumer側を書かなくて良いのは楽だなぁ
- FirehoseをつかったS3への転送
- 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
- Anomaly Detectionの話題が
(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台
- Mesosのスケジューラを使って、600ワーカ立ててる
- s3からのartifactダウンロードに時間がかかるのでnginxでserveするようにしたらしい
- originはs3でfrontにnginxってことかな?
- autoscaleの計算も、必要なメモリの総量を見積もってから行っている
(ARC308) The Serverless Company: Using AWS Lambda
- Lambdaの人
- ビデオのtranscodeからaudioの抽出、サムネイル作成まで全部Lambdaでやってる事例面白いな
- 普通にexecでffmpegを実行していた。
- Lambdaのtips
(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のパフォーマンスモデル
(BDT318) How Netflix Handles Up To 8 Million Events Per Second
- Netflixの人、Event and Data Pipelines担当らしい
- Chukwa - Welcome to Apache Chukwa
- ああ、Kafkaの多段構成にかわったのかな
- frontのKafkaにd2.xlargeとな・・・
- routingにSamzaをつかっている
(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を選んでくれる
- WebSocketの場合、もし違うECS内のappに接続した場合にはcookieでIDを取得して、裏側のサービスへの問い合わせにつかっているっぽい
- サービスメトリクスは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から移行したのか
(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%分だけ起きてた
- シャードを増やしたら安定
- あと新しいLinux Kernelつかうとよくなったらしい(コンテキストスイッチの回数が減ったとのこと
- 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になるとのこと
- provisioned capacityが1200なら300秒間で3600CUが余力らしい
- 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の設定もできる