すずけんメモ

技術メモです

Shibuya.go#1を開催しました。

今週の火曜日に Shibuya.go#1 - connpassを開催しました。ご来場していただいた皆様、発表者の皆様、どうもありがとうございました。

渋谷近辺、都内近郊でGoを書いている人ともっと会いたいなぁと思い、今回開催するにいたりました。私は普段から仕事でも仕事以外でもGoを使っているのですが、どうもあまりGoを書いている知り合いがあまりいないのでせっかくだし開催してみようと思ったのでした。人が集まるかなぁと思いつつ募集してみたら嬉しいことに多数の参加申し込みをいただき、抽選となってしまいました。参加できなかった方々申し訳ありません・・。

発表資料をまとめておきます。発表者のみなさま、どうもありがとうございました。

また発表後も飲みつつ、色々なお話をすることができました。Goの集まりでしたがPerl感があったとの噂です。また来月も開催予定ですので、是非また参加していただけると幸いです!


その翌日(おとといですね)は Go 1.6 Release Party - connpass に行ってきました。主催者のみなさん、会場を用意してくださったはてなさん、どうもありがとうございました。こちらも楽しい会で、残念ながらGo 1.6はパーティー前にはリリースされなかったのですが、Gopherのみなさんとお話できて楽しかったです。 Go 1.6 is released - The Go Blog にもあるとおり、Go 1.6はリリースされました。私もさっそく今日一部のサーバにGo 1.6でビルドしたものをデプロイしました。

Travis CIを利用した継続的な成果物の配置

こんにちは。 @suzu_v です。 Advent Calendar 2015 18日目 休載のお知らせ - VOYAGE GROUP techlog とのことだったので代打で書いてみます。*1

いま私が所属している fluct ではCIの一部にTravis CIを利用しています。用途としては、

  • 継続的なテスト
  • 継続的なビルド

というところを担当しています。今日は簡単に、

の紹介をします。

Travis Artifacts

f:id:suzu_v:20151218150020p:plain

travis-ci/artifactsTravis CIのアドオンとして利用されているもので、ビルド済みのartifactsを扱うことができます。私たちは一部のバッチやAPIサーバの実装について、Travis CIを利用したビルド及びs3への転送を行っています。

プロジェクト構成は概ね以下のようになっています。この場合Goのアプリです。

github.com/your-username/your-reponame
    .travis.yml
    Gomfile
    Gomfile.lock
    Makefile
    ci.mk
    cmd/myapp.go
    kuke.go
    kuke_test.go

.travis.yml には以下のように設定しています。

sudo: false

language: go

go:
  - 1.5.2

before_script:
  - export PATH=$HOME/gopath/bin:$PATH

install: make -f ci.mk deps

script:
  - make -f ci.mk test
  - make -f ci.mk build

addons:
  artifacts:
    paths:
      - $(git ls-files -o --exclude-standard | tr "\n" ":")
    debug: true
    bucket: your-bucket
    target-paths: artifacts/$TRAVIS_REPO_SLUG/$TRAVIS_BRANCH
  s3_region: "ap-northeast-1"

このようにすると s3://your-bucket/artifacts/your_user_name/your_repo_name/branch_name 以下にビルド物が展開されます。例えば github.com/suzuken/gs のmasterブランチのビルドに対しては s3://your-bucket/artifacts/suzuken/gs/master 以下に成果物(artifacts)が配置されます。Pull Requestを出した場合にも同様で、トピックブランチごとのartifactがs3に配置されます。テストをするサーバ側ではこのartifactを aws s3 cp などで取得し、利用することができます。ちなみにブランチ以外にもcommit hashやtagごとに出す、ということもできます。詳しくは travis-ci/artifacts をみてください。

git ls-files -o --exclude-standard | tr "\n" ":" というのはざっくりいうと「git管理下では無いファイル」をリストする、ということをしています。こうすることでビルドされたものだけs3へのアップロード対象にすることができます。

ci.mk というのはCI用のMakefileです。Makefile は開発用に、 ci.mk はCIで使うように、と分けています。実際にそれぞれやっていることはあまり変わりませんが、こうすることでプロジェクトごとのCI用のマクロを揃えておくということがやりやすくなります。例えばJavaのプロジェクトでもこの仕組をつかおうとしたときにでも、 make -f ci.mk install test build すれば成果物ができる、という取り決めにしておけばよいのです。

実際に ci.mk の中身は以下のようになっています。(プロジェクトによって若干異なりますが、Goのプロジェクトだと概ね以下のようになります。)

.PHONY: install build test deps

BRANCH := master
GOOS := linux
GOARCH := amd64

deps:
  go get github.com/mattn/gom
  gom install

test:
  gom test -v ./...

build: myapp.$(GOOS).$(GOARCH).gz
   -rm myapp.$(GOOS).$(GOARCH)

myapp.$(GOOS).$(GOARCH):
  GOOS=$(GOOS) GOARCH=$(GOARCH) gom build -ldflags "-X=main.version=$(shell git rev-parse HEAD)" cmd/myapp.go
  mv myapp $@

myapp.$(GOOS).$(GOARCH).gz: myapp.$(GOOS).$(GOARCH)
  gzip -f $<

clean:
   -rm -rf myapp.$(GOOS).$(GOARCH)
   -rm -rf myapp.$(GOOS).$(GOARCH).gz

依存の管理には mattn/gom を利用しています。Go版のBundlerのようなものです。s3への転送は myapp.linux.arm64.gz だけを配置する、ということにしたいので適当に整理しています。

Travis CIからS3への転送についてはcredentialが必要になります。これはTravis CIのプロジェクト設定で、環境変数から読み込ませることができます。 Uploading Artifacts on Travis CI - Travis CI に書いてあるとおり、リポジトリの設定から以下を設定します。

ARTIFACTS_KEY=(AWS access key id)
ARTIFACTS_SECRET=(AWS secret access key)
ARTIFACTS_BUCKET=(S3 bucket name)

Bucketについては .travis.yml に設定してもよいでしょう。Travis CI側ではtestが通らないとbuildが実行されないようにしているので、これでビルドが通ったもののみs3に配置される、ということになります。

以上、簡単ですが代打でした。明日は @qooh0 さんです。

小ネタ

f:id:suzu_v:20151218151850p:plain

*1:決してTravis CIのビルドが詰まっているので息抜きに書いているわけではありません。 Travis CI Status - Start delays on legacy precise infrastructure for travis-ci.com (private) builds

#ajiting Advent Calendar 1日目

#ajiting Advent Calendar 2015 - Adventar 1日目

明日は @brtriver です。

aws-cliのs3api put-objectでContent-MD5ヘッダをつける

put-object — AWS CLI 1.9.2 Command Reference をみると --content-md5 オプションがある。 PUT Object - Amazon Simple Storage Service にあるとおり、

To ensure that data is not corrupted traversing the network, use the Content-MD5 header. When you use this header, Amazon S3 checks the object against the provided MD5 value and, if they do not match, returns an error.

ということでオブジェクトの完全性をチェックするには Content-MD5 ヘッダをPutObjectリクエストにつけるとよい。

AWS Developer Forums: awscli put-object --content-md5 trouble ... でもハマっている人がいた。最初 md5 とか md5sum コマンドでやっていたのだが、これだとhexになったのが出てくる。 https://www.ietf.org/rfc/rfc1864.txt にもあるとおり、Content-MD5ヘッダに設定すべきは base64(md5) であり base64(hex(md5)) ではない。ということでこれをまとめて aws s3api put-object をつかって書くと以下の様にして実現できる。

# s3://your-bucket/your-key-prefix/obj に カレントディレクトリのobjをPutObjectする。
aws s3api put-object --bucket your-bucket --key your-key-prefix --content-md5 `openssl dgst -md5 -binary obj | openssl enc -base64` --body obj

APIを適当な言語で使っている場合にはmd5 sumのbinaryをPipeして組み立てればよいのだが、cliだとうっかりハマってしまった。ちなみにresponseのETagはPutしたObjectのmd5 checksumのhexが返ってくるので、これも合わせてチェックするとさらによいだろう。 レスポンスの例は以下のとおり。

{
    "ETag": "\"a41422711fcbb0982991580e0d4799f6\""
}

これは md5sum -q obj の結果と等しくなる。ただしMultipart Uploadの場合には必ずしもそうはならないので、留意すること。

vim-go-extraからvim-go に移った

ずっと vim-jp/vim-go-extra をつかっていたのだけど、oracleとかvetとかもろもろ扱いやすくしたいなと考えていたらもう fatih/vim-go でいいか、と考えてvim-goに移った。

前から dgryski/vim-godef を重宝していて、Godocをみるよりもソースに飛んでドキュメントとコード両方みる、みたいなことをしている。vim-goだとデフォルトの gd の挙動がカレントバッファにジャンプ先を表示してしまって使いづらかったのでaliasを足しておいた。

nmap gs <Plug>(go-def-split)

ということで gsgodef をつかうようにした(sleepさんごめんなさい・・)。ちなみにsplitでみるのは私の癖で、実装元のコードと実装しているコードを並べて見ながら書く癖があるためである。並んで表示されていないと、すぐ忘れて行ったり来たり・・というのを繰り返してしまうのである。

vim-goにして3週間ほど経つけど問題ないので、ひとまず使い続ける予定。

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の設定もできる

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

今年はre:Inventには参加せずオフィスで仕事しようと考えていたのですが、実は先週急遽入院していました。*1ちょうどre:Inventのスライドとビデオが公開されていたので、昨日今日とメモしたものをここに貼っておきます。

スライドしかみてないので、デモ中心のbreakout sessionはビデオをみたいところです。


ビデオはここ

Amazon Web Services - YouTube

スライドはこちら

Amazon Web Services’s slideshows on SlideShare


順序は適当です。

AWS Black Belt Tech シリーズ 2015 - re:Invent 2015 最新アップデート速報

  • 日本のSAの小林さんがまとめてくれている
  • AWS IoT
    • AWSサポートのデバイスもあるのか
  • Amazon QuickInsight
    • よさそう。10$ / ユーザ / 月。安い。
  • Kinesis, Amazon Kinesis Streamに名前変わったのか
    • 24時間から7日間に保持期間が変更に
      • ただし延長分は費用が必要
    • Amazon Kinesis Firehose
      • ストリーミングデータを直接s3やredshiftに格納
      • Kinesis Streamからのデータの取得もできる
      • 1分間隔で処理できる
      • 東京リージョンはまだ
    • Amazon Kinesis Analytics
      • Kinesisのストリーミングデータに対するSQLアクセス
      • 1秒以内のレイテンシ
  • AWS Inspector
    • セキュリティ診断サービス
      • 何を診断できるんだろう?
    • 一般的な脆弱性や情報漏えい、ネットワークセキュリティ、認証、OS、アプリケーションに関するそれぞれのベストプラクティスについて検査できる
    • PCI DSS 3.0のアセスメントもできる
  • AWS Import/Export Snowball
    • AWSから提供するハードウェアを用いてデータのインポートとエクスポートを可能に
    • 48TBを10Gbps or 1Gbpsでつなげる
      • DCのデータ移すのとかに使えるのか
  • AWS Database Migration Service
  • AWS Mobile Hub
    • AWSをつかったモバイルアプリの開発を簡単に
      • 認証周りとかのコードを提供
      • 関連サービスなどの設定構築を自動でやる
    • コンソール見るとテストしたりmetricsとったりとかもあるな
      • ああそういえばmobile analyticsみたいのもあったか
      • SNSでpush notirficationとかもできるし
      • あとCDN設定とかもっぽい
      • sign-inはCognitoか
  • Amazon EC2 Container Registry
    • Docker registry。IAMと連携したり、暗号化できたりする。
    • まだ使えない
    • 多分beanstalk用にDockerコンテナ使うときにregistry自前で立てなきゃいけなかったりとか、そのへんの対策なんだろうな
    • IAM連携できるの良さそう
  • Amazon RDS for MariaDB
    • よさそう。XtraDBやAriaをつかえる
    • バージョンは10.0.17
  • AWS Config Rules
    • AWS Configにルール機能を追加することができるようになった
    • Lambda functionとしてルールを作成できる
      • ということはかなり自由にルールを作成できるということでもある。Lambda as UDFという感じだ。
  • Cloudwatch Dashboard
    • 複数のCloudwatchメトリクスを貼り付けてダッシュボードつくれるらしい
    • 1ダッシュボードあたり50メトリクスまで。
      • 複数リージョンまたがったグラフも貼り付けられる。
  • AWS Lambda Updates
    • VPCサポート!
      • Lambdaファンクション自体をVPCサブネットやセキュリティグループに割り当てて配置できる
        • 中で動くEC2の配置環境を決められる、ってことかな
    • バージョニングとエイリアス
      • コードをアップロードすると勝手にバージョニングされるらしい。Dropboxみたいな感じか。
    • Python 2.7をサポート
    • timeoutを300秒まで延長可能に
    • Scheduled Events
      • スケジュール実行。intervalかcron形式で書けるらしい。
      • 最短インターバルは5分
      • コンソールからしか設定できない・・APIほしいな
  • Amazon ECS機能追加
    • CLIが出た。docker compose連携できる。
      • むしろいままでdocker compose連携できなかったのか
    • タスクスケジューリングがmulti-azになるようになった
  • EC2まわりのupdate

(DVO303) Scaling Infrastructure Operations with AWS

(CMP305) Deep Learning on AWS Made EasyCmp305

  • Datoの人のDeep Learning事例

(MBL308) Extending Alexa’s Built-in Skills. See How Capital One Did It

  • Amazonの中の人によるAlexaの活用事例
  • alexa = クラウドベースの音声サービス
    • Siriみたいなやつ
  • Amazon Echo = Alexaを使えるデバイス
  • 開発者がAlexaのサービスをつかって独自のスキルをつくることもできる

(MBL305) You Have Data from the Devices, Now What?: Getting the Value from the IoT

SAのMichaelさんのスライド

  • IoTにおけるデータの違いを学ぶ

(ISM402) Cost Optimization at Scale

  • 1000台くらいEC2があるときにどうやってRIを採用するか、というあたりの自動化のはなし
  • まあTableauのテンプレートとかでてきて便利かなって感じ

(DEV201) AWS SDK For Go: Gophers Get Going with AWS

(NET404) Making Every Packet Count

  • EC2のnetworkingまわりのsenior manager
  • RTTが2ms、帯域窓が100KBなら
    • 100KB x 8bits/byte x 1000ms/s / 2ms = 400Mbps
    • さくっと計算できたほうが良さそう
    • 同様にRTTが100msなら8Mbps
  • Receive window(RWIN) の設定は net.ipv4.tcp_rmem (最小、デフォルト、最大) で。
    • 最大域は net.core.rmem_max
  • Congestion window - Wikipedia, the free encyclopedia
    • 送信側が制御する
    • Windowは渋滞制御のアルゴリズムにより管理される
      • Window: 1送信あたりのかたまりのサイズのこと、っぽい
    • ip route list で確認できる
    • ip route change 10.16.16.0/24 dev eth0 proto kernel scope link initcwnd 16 とかで変更できる
    • TCP throughputのlossは netstat -s | grep retransmit で確認できる
  • Socket level diagnostic
    • ソケットの診断するには ss -ite をつかう
  • TCPでの再送をトレースする
  • Congestion control algorithms (in Linux)
    • 2.6.8以前はNew Reno
    • 2.6.8 - 2.6.18はBIC
    • 2.6.19以後はCUBIC
    • これはプラガブルで、アルゴリズムを切り替えることができる
      • sysctl net.ipv4.tcp_available_congestion_control
      • sysctl net.ipv4.tcp_available_congestion_control=illinois など
  • 再送のタイマーについて
    • congestion control algorithmはパケットの消失について考慮する
  • 現在のキューを観る
    • tc qdisc list
  • EC2におけるネットワーキング
    • Amazon EC2 enhanced networking
    • M4, C4, C3, R3, I2, D2で適用されている
    • re:Invent 2014のSDD419をみること
  • 後半、実験のやつおもしろいかも
    • 最後のhigh transactionの例はweb serverそのものという感じ

(ARC302) Running Lean Architectures: Optimizing for Cost Efficiency

Team Internetの人とAWSの中のひとのセッション

  • ECSつかってcontainerのusageをまるっと1 instanceにおさめてく最適化、理論ではわかるけどうまく動いてるのかなこれ
  • Spot Bid Advisor使うのは良さそう
  • DynamoDBに問い合わせるときにはRAMにキャッシュすると安上がり
  • over capacityな書き込みにはSQSをつかう

(STG406) Using S3 to Build and Scale an Unlimited Storage Service

  • Amazon Clod Driveの中のひとのセッション。熱いのでは。
  • Amazon Cloud Drive: Cloud Storage - Online Backup
  • 写真は年間12ドル、全部何でもなら年間60ドルで保存できる、安い
  • いろんなレベシェアのパートナーがいる。scanとか印刷会社とか。
  • 100万単位のユーザ、10億超えのファイル、無制限なストレージ
    • 写真、ビデオ、文章。メタデータ色々。
    • 様々にインデキシングやキューを出来るようにしたい
  • 9ページに構成。まあ予想通りというところ。ビデオのエンコーディングとかもやるのか。
    • リージョンごとにs3バケットは1つだけ。
    • s3のkeyはランダムに生成していて、key自体はDynamoDBに保存されている
      • hot keyをさけるため。list operationはしていない
      • s3ではAES256で暗号化
    • 3リージョンで800サーバ以上ある
    • ログはs3 -> EMR -> s3でRedshiftにCOPY
  • 機能を出しわけ出来る
    • 0 -> 100%のユーザに適用、とか
    • HTTP HEADで出し分けしている。設定ファイルはs3にある。
  • 6つのチャレンジ。まずファイルサイズが様々なこと。
    • 15MB以下だとPUTで。
    • それより大きいならmultipart upload APIで。
      • partは5MBで
      • ただpartは10000までしか分割できないので、ファイルサイズ50GBが限界
  • 早くアップロードすること
    • 同期と非同期のuploadをまぜる。
    • 画像: メタデータ抽出。
      • すぐおわる。ファイルサイズによる。これは同期。
    • ビデオの転送
      • 別のデバイスでも再生できるようにするため。
      • ビデオのサイズによって終わる時間ばらばら。
        • これは非同期。
    • 文章をPDFに変換する
  • 接続の中断
    • 特にモバイルデバイスだと接続の中断はよくあること
    • 1つのHTTP通信ででかいファイルを転送するのは大変
      • とはいえmultipart upload APIは複雑
    • なのでResumable uploadsにすることにした
    • 途中で転送が失敗したら、どこまでのバイトを転送したかを記録しておく
    • 再送時にはどこまで転送したかをクライアントから送る
      • 再送時にHTTP Content-Rangeヘッダを付ける
    • また、繋ぎ直すときに同じインスタンスに繋がるとは限らない
  • ダウンロードサイズもばらばら
    • リソースなくなるとでかいファイルのダウンロードが失敗する
    • サイズごとにダウンロードのロジックをわけた
    • 5MB以下の場合
      • 単一のGET
      • 失敗したら単純にリトライ
        • 全オブジェクトの90%がこの大きさ
    • でかいファイル
      • 並列にダウンロード
        • partは5MB
        • 他の操作に影響されないスレッドプールを容易
        • コネクションは再利用する
        • 一回だけリトライ、だめならtimeout
      • Apache HTTPClientをつかっている
  • でかいイメージのサムネイル
    • サムネイル取得に 3000req/s とかくる
    • 一時的なサムネイルの生成をしている
      • 48時間でexpire
      • keyは(customer id, image id, image version) のhash
  • でかいファイルの直接ダウンロード
    • 一次サインしたs3のURLにリダイレクトする

(DVO315) Log, Monitor and Analyze your IT with Amazon CloudWatch

  • デモみないとよくわからん

(NET302) Delivering a DBaaS Using Advanced AWS Networking

  • Instaclustrの人
  • 最初は顧客ごとにAWSアカウントわけてた
    • アクセスとか請求分かりやすいけど、管理しづらい
  • 全部Instaclustrのアカウントで管理するようにした
    • VPCはわけた
    • 管理はしやすくなったけどVPC増えすぎてやばい
  • どうやって顧客のクラスタからのアクセスを受け付けるようにするか
    • 静的なipやっぱり欲しいよねっていう話
    • VPC Peeringした。まあそうだよね。

(SEC403) Diving into AWS CloudTrail Events w/ Apache Spark on EMR

  • IAMのSenior Security Engineerのひと
  • あーSparkから単純にクエリするだけじゃなくて、Spark Streamingで異常検知もしよう、みたいな話か
    • alertにしようという。
  • Spark Streaming, 3秒ごとらしい

(BDT404) Large-Scale ETL Data Flows w/AWS Data Pipeline & Dataduct

  • Courseraの人
  • 1500万learner, 1300コース、おおいなー
  • RedshiftをDWとしてつかってる
    • 1200テーブル・・
    • 167人がRedshiftつかってる。3000万クエリ。やばい。
  • coursera/dataduct
    • courseraのつくったETLツール
    • AWS Data Pipelineのwrapper
    • YAMLで設定かけるのよさそう
  • 結構よさそう

(SEC324) NEW! Introducing Amazon Inspector

  • AWSのPrincipal Security Engineerの人の発表
  • InspectorはEC2にserviceとしてインストールして使うらしい
  • Demoあるのでvideoみたほうがよさそう

(MBL402) Mobile Identity Management & Data Sync Using Amazon Cognito

  • Cognito IdentityはIDあたえたりOpenID連携したりするやつ
  • Cognito Syncなんていうのがあるのか
    • データストアしたりデバイス間で同期したりする
    • Cognito EventsっていうのでLambdaにながしたり、Cognito StreamsでAmazon Kinesisにデータ流したりできる
  • CognitoのIDにはIAMのひも付けもできる
    • IAMというかRoleか
    • identifyされていてauthされているならtokenをもらえるようにできる
    • CognitoのtokenはJWTのフォーマットになってる
  • Unauthenticatedな場合にはSTSで一時的なcredentialを発行できる
    • OpenIDもらったらSTSでassume roleをもらう
    • もらったらSTSからCognitoにvalidateかける
    • そしたらcredentialもどってくるのでs3などにアクセスできる
  • Cognito Sync

(DVO312) Sony: Building At-Scale Services with AWS Elastic Beanstalk

  • Sonyのエンジニア。日本人2人の発表。
  • もともと自社?IaaSにのっててモノリシックな環境。
    • デプロイに半日・・設定管理manual。。。
  • fluentdのロゴが
  • beanstalkのsgとかどうしたんだろう
  • あーDockerイメージのdisk容量問題だ
  • appendix、実は大事なところだ。drawingのtimeoutとか。
  • 面白かった

(DEV301) Automating AWS with the AWS CLI

  • AWSの中の人?Jamesさん。
  • 1コマンド1パラメータの出力にするとよい
    • || errexit "err msg" とかでエラーハンドリングしやすくなる
  • 1コマンド複数出力のものをそれぞれ aws コマンドにわたしたい
    • for とか xargs -I {}
  • 実行するコマンドのパラメータをJSONに保存して実行したい場合
    • jmespath/jp をつかうとJMESPathについてとりだしやすくなる
      • Go製だった
      • JSONについてJMESPathインタフェースで問い合わせできる
        • 前にPython製のやつもあったけど、それよりシンプルで良くなった気がする
    • でもamiのidとかinstanceのidとかはparametarizeしたい、みたいなことがよくある
    • instance=$(aws run-instance --image-id ami-1234 -query Instance[0]) みたいにしてはめ込む
    • query()を用意しておく query() { jp -u "$2" <<<"$1" }
    • instance_id=$(query "$instance" InstanceId)とすればidだけとれて便利
    • 前は --output text とかやってsedしたりしてたけど、--output jsonjp つかうと便利だよ、とのこと
  • resource_exists() はまあそうなるよな、という感じ

(DAT205) NEW LAUNCH! Introduction to AWS Database Migration Service

(CMP403) AWS Lambda: Simplifying Big Data Workloads

  • FireEyeのMartinさんの発表。Lambda事例か。
  • What to Expect from the Session は今回の発表スライドのフォーマットに指定されているのかな
  • Cyber Security & Malware Protection | FireEye
  • ユーザのイベントを蓄積して、その中からevilなものをみつける、ということをしたい
    • オンラインでindexingしているものと、s3に保存しているcold dataがある
  • 入力: Questions, 出力: Answersと表現するの珍しいかも
    • Lambda driven search and analyticsが気になる
    • EMRでは異常検知をやってる
      • k-means, 線形回帰、geographic time-lining
    • Lambda
  • 大きさ: 5TB/dayくらい
    • 1イベント: 3KB, 20K events/s
  • Building Scalable and Responsive Big Data Interfaces with AWS Lambda - AWS Big Data Blog
    • Lambda functionの複数走らせるためにfrontにnode.jsのアプリをおいている。ジョブのキックはここから。
    • そこからLambda functionのprocessをspawnする。結果の集計をcascadeのアプリが担っている
      • インメモリでLambda functionのspawnをキューしている
    • cascadeではLambda functionでのcallbackをうけとって、集計して結果を返す。つまり、cascadeMapReduceにおけるReduceの役割もしているといってよい
    • ユーザに結果を返すにはnode.jsアプリからSSEで返している
    • Lambda functionの中からs3のデータを読んでいる。
      • 解凍、中見る、カウント、などなど。
      • s3からのデータ取得は並列にやるとよい。いつものパターン。
  • 面白い。

(NET403) Another Day, Another Billion Packets

  • AWS SecurityのEricさんのプレゼン
  • 割愛

(NET409) How Twilio Migrated Its Services from EC2-Classic to EC2-VPC

  • Twilioの @sumbry さんのプレゼン。EC2 ClassicからVPCへの移行話。
  • 2008年からAWSつかってて多くのサーバがEC2 Classicで動いてた
  • あーグローバル展開する段階でregionまたぐときにregion間通信のためのproxy、というかNATつくってたのか
  • あれ、VPCじゃないとHVMとかENIつかえないんだっけ
    • ENIはPublic / PrivateなEIPふれて、1つのインスタンスにENI複数つけることができて、Private EIPは複数ふれて、SGもENIに紐付けられる、っていう便利インタフェースである
    • HVMだと10GBまでのnetworkスピード出る。
  • Twillio Cloud: VPC基盤でのTwillio
  • マイグレーションの手順
    • そもそも旧環境とつながってないから全部移行しないといけない
    • VPCのClassicLinkでVPC環境にEC2をつなげる
    • VPC環境にも同等のEC2を用意、balancing環境下におく
    • Classic側のインスタンスを消す
  • 移行用のツール作った
    • IP Tunnel Manager / ClassicLink
      • ああ、もともと作ってたらClassicLinkでてきたからそっちつかった、みたいな話かな
    • Global Service Discovery
      • クラスタのなかのipを保持して、要求された時に返すagent
    • HAProxyで分散ロードバランサ
      • あーアプリからDBとか叩くときにはHAProxy経由にしているってことか
    • Config-Renderer
      • HAProxy Configsみたいなやつ
      • Global Service Discoveryの情報を取得して返す
  • 無事移行進んでる
  • 巨大なマイグレーションを一気にする必要はないんだよ、といういい話

(MBL317) NEW! Introducing AWS Mobile Hub

  • 新サービス、AWS Mobile Hubの発表
  • Demoみないとわからんという感じ

(ISM317) Amazon WorkMail: Corporate Email in Less Than 10 Minutes

  • Amazon WorkMail、っていつでたんだっけ・・

(GAM406) Glu Mobile: Real-time Analytics Processing og 10 MM+ Devices

  • Glu Mobileの解析エンジニアの人の発表
  • DAUが400~600万、全世界で累計10億以上のインストール
  • 要件など
    • 1日700万から2億イベントくらい。1イベント600バイト。1日1.2TBくらい。
    • データフォーマットはJSON, リアルタイム集計、なるべく落ちない、なるべくデータロスしない、アドホッククエリはなるべく速く
  • 最初はPythonのフロントアプリ -> s3 -> Redshiftな構成
  • 解析用のSDKつくって、必要なデータを集め始めた
    • Amazon Kinesisに流しこむようにした
    • Kinesisのproducer側は30秒ごとに
    • authはやっぱりAmazon Cognitoなのか〜
    • Kinesisのシャードは20くらい
  • リアルタイム集計にはStormを利用
    • Amazon Kinesis Storm Spoutを利用
    • 集計結果はRDSへ
    • Stormのクラスた運用について
      • なるべくでかいインスタンス、少ないワーカーで
      • 4台のc4.2xlargeでやってる
      • ZooKeeperは 2 x m3.large, Nimbusにm3.xlarge
  • Kinesis、マシンごとのシャードを増やそうとすると結果として小さいファイルがたくさんできてしまう
    • Hadoopにとってはこれはつかいづらいので、CombineFileInputFormatつかってまとめた
    • Mapフェーズに渡す前にapplication masterでまとめている。Hadoopではこのフェーズはやってないってことかな?
  • IPのないレコードがあった場合
    • デバイスにpingしてGeoDataを要求する
    • Kinesisにレコード流れて、ConsumerでGeoLookupしてた
    • ここをLambdaで置き換えたとのこと
      • かつ、AWS API Gatewayつかってクライアントとのやりとりをするように。なるほど。
  • Kinesis Streamのシャードのスケールには awslabs/amazon-kinesis-scaling-utils をつかう

(DAT207) Amazon Aurora: The New Amazon Relational Database Engine

  • AuroraのGMの人の発表
  • 去年Auroraの発表聴いたきり、ほとんどキャッチアップしてないなぁ

(DAT405) Amazon Aurora Deep Dive

  • Aurora, Redshift, EMRのVPの人の発表

(BDT323) Amazon EBS & Cassandra: 1 Million Writes Per Second

  • CrowdStrikeの中の人の発表。
  • CrowdStrike
    • endpoint protectionのビジネス。500000 event / sec.
  • 自明の理?
    • Never run Cassandra on Amazon EBS これはw
  • 要件
    • 数百万デバイスから1PBのイベント来る
    • バースト時は100万write / sec ...
    • 95%が書き込みで5%がread。すごい要件だ・・
  • 最初は Cassandra + Titanで
  • EBSつかったらc4.2xlargeだけ使うより安くなるっていう試算、なんともすごいな
  • Cassandra Summit 2015: Real World DTCS For Operators
    • これ、日にちの経ったデータほどcompaction効かせる、ってことかな?
  • 最初の立ち上げ: Cassandra 2.0.12, m3.2xlarge, 4TB EBS GP2 10000 IOPS
  • ベンチマークのwriterにc4.4xlarge 20台もつかうのか。
  • もろもろベンチとって達成
    • Ubuntu, HVM, XFS
    • Java8, G1GCか
  • ああそういえばEBSのpre-warm必要なくなったのか

(ARC401) Cloud First: New Architecture for New Infrastructure

(BDT305) Amazon EMR Deep Dive and Best Practices

  • AWSの人とFINRAの人の発表
  • EMR 4.1での話
    • Zeppelin これ知らなかった。Spark向けnotebookか。
    • OozieとかHueがすんなり使えるようになったのはいいよなぁ
  • EMRFS
    • DynamoDBつかってmetadataおくようにするとlistオペレーションが速くなる

(NET301) New Capabilities for Amazon Virtual Private Cloud

  • SAの人の発表
  • VPC Endpoints (VPCE)
    • s3についてまずはつかえるようになりましたと
    • publicなendpointに到達するために、Public IPアドレス, NAT/PAT, proxyがいらなくなる。
      • Internet GatewayがなくてもS3に接続できる
    • Publicな経路の場合とほとんど遜色ないパフォーマンスがでるのか
      • NATだと半分くらい
  • VPC Flow Logs
    • ENIからでるNetflowみたいなログ。
      • ちゃんとsgとかnetwork ACLでDENYできてるの?とかを見ることができる
    • CloudWatch Logsでみることができる
      • REJECTのログひろってそれをそのままalart設定したりするのよさそう

(DVO314) USA Today Uses Chef & AWS for Infrastructure Standardization

  • USA TodayのChef事例
    • 発表はGannettとChefの人
  • Gannettでは複数メディアを運用していて、社内PaaSみたいになっている

(DAT308) Yahoo! Analyzes Billions of Events a Day on Amazon Redshift

  • Yahoo!でのRedshift事例
  • HadoopクラスタもあるのにRedshiftつかうのか
  • Redshift
    • 21 dc1.8xlarge, 20億イベント / 日, 1200クエリ / 日, 27TB
    • Pigで加工してs3に置いたものをReshiftにロードしてる
    • airbnb/airflow つかってる
  • ETL
    • upstream
      • ClickstreamデータをOozieのhourly batchでHDFS
      • botoつかってs3へ
    • downstream
      • こっちはairflow
  • JOINをなるべく減らす工夫をしている
  • ETLをデフォルトのキューでやるな、っていうのはそうだよなというところ
    • Workload managementつかおうという話
  • ユーザのリテンション分析用に多次元テーブルを用意していた
    • 性別とかOSごととかにコホートだしていれておく
    • いわゆる中間テーブル

(DEV203) Amazon API Gateway & AWS Lambda to Build Secure APIs

(CMP301) AWS Lambda and the Serverless Cloud

  • AWS LambdaのGMの人の発表
  • Lambdaのresource Sizingについて
    • 23段階のpower levelがあるとのこと
  • Scheduled Functions
    • Lambda consoleから使える
    • cronの文法がつかえる
    • 例えばSQSのデータをpollingする、みたいなのが簡単に設定できる
    • 2015年中にcliとかSDKでもサポート
  • Versioning
    • uploadしたら勝手にバージョニングしてくれる
      • シンプルに1,2,3とincrementされるだけ
      • 名前もつけられるっぽい
        • alias
  • VPCアクセスが可能に
    • subnetとsecurity groupを指定するかたち
    • ElasticacheとかRDSとかVPC内のEC2とか・・
    • 年内に全部のregionで使えるようにするとのこと

(ARC309) Getting to Microservices: Cloud Architecture Patterns

  • gilt.com の事例
  • ブランドの商品を会員限定価格で提供してるサイト
    • 正午にセールしてる、スパイクする
  • 2007年ごろはRoRモノリス
  • 2011年にはJava
    • Voldemortつかってるのか
    • 各チームはそれぞれのビジネスラインにそって開発
  • 2015年(現在)
    • LOSA(lots of small apps) & microservicesに
    • microservicesのレイヤはScala
  • microserviceの構成
    • 各サービスはだいたいJVM環境 *監視はNewRelic
  • ZookKeeperをservice discoveryにつかってる
    • クライアントからZKに問い合わせ。サービス名でqueryしてURLをもらう形
    • LBを挟んでapiのnodeに問い合わせる
  • このあとDC -> VPCに移行
    • EC2インスタンスごとに1サービスだけいれる
    • サービス自体はDockerコンテナにいれてる
    • LBはELBに置き換えた
    • 1サービス辺り3,4ノードにデプロイされているのが多い
      • t2.microがほとんど
    • これ、2015年までにmicroservice移行しつつ、インフラもAWSに移したってことか。すごいな。
  • microservice
  • Dynamic Service Registry
    • microservice環境だとDNSTTL問題を避けたくなる
    • ZooKeeper, Eureka, Consul, SmartStack, とかいろいろある
  • サービスごとにデータストアも分割したらしい
    • こうすることでスキーマ変えた時のインパクトが少なくなる
    • かつ、スケーラビリティをそれぞれ独立にできる
    • 各チームごとにアプリ開発者もインフラもDevOpsもいる、という構成だからこそできるんだろうなという感じ
  • 1コンテナ / 1インスタンスについて複数のサービスを置くのはやめた
    • モニタリングしづらい, スケールしづらい、ownershipがよくわからなくなる、immutableなデプロイがしづらい
    • コンテナ、もしくはインスタンスごとに1サービスだけ置くようにしている
  • ユーザからのリクエストから複数のserviceに問い合わせるケース
    • 毎回問い合わせるのではなくてcacheをつかって問い合わせを減らす
  • リクエストのtrace
    • serviceをまたいでリクエストが多段になるときも、一貫したIDをつけておくこと
    • たとえば商品カタログはうまくでていても、決済が失敗してる、とかがわかるようになる

(NET405) Build a Remote Access VPN Solution on AWS

  • SAの人の発表
  • オンプレでもAWSでもいいけど、VPNの入り口をAWSにすればVPN経由のユーザについてのcapacityとかを柔軟にできるよ、という話
    • CloudFormationでぽちっとやればできると
  • VPCをたてる
    • DCにつなぐdownstreamのVPNをworkerノードからつなげる
    • clientサイドからはVPN用のインスタンスにまず接続する
    • autoscalingについては接続数や帯域をみてhookするようにする
  • この構成のスケール例
    • DynamoDBにnetworkのIDとAddr, instance id, regionなんかを保存しておく
    • DNS load balancingで各regionのVPCに問い合わせられるようにする
      • Route53のGeo Entriesをつかうと近いregionにつなげられる
    • autoscalingしたらroute53のapiつかってrecordを追加すれば良い

(MBL311) NEW! AWS IoT: Securely Building, Provisioning, & Using Things

  • AWS IoTのセッション
  • ビデオみたほうがわかりやすそう

(DVO305) Turbocharge YContinuous Deployment Pipeline with Containers

(CMP406) Amazon ECS at Coursera: A general-purpose microservice

  • CourseraのECS事例
  • batchでやってること
    • レポーティング
    • Gradeだしたり学習者のデモグラだしたりとか
    • レコメンドのemailつくったりもしてる
  • 2012年1月ごろにやっていたバッチ処理の方法
    • Cascade: PHPベースのジョブランナーをつかっていた
      • screenのセッションで走らせていた・・・
    • わりと最近: Saturnつかってた
      • Scalaベースのbatch job runner
      • 全てのジョブが同じJVMで動いているので干渉がおこっていた
  • バッチジョブについてほしいもの
    • 信頼性が高くて、デプロイしやすくて、開発が楽で、効率が良くてopsも楽でコスパのよいもの
  • いろいろ検討した
    • 自家製でバッチジョブ用の何か作る?
      • 調整とか同期まわりがめんどう
    • Mesos
      • 本番に入れるのが大変
    • kubernetes
      • opsは大変かも
  • ECS使いたい、がツールいろいろつくった
    • Iguazu
    • ジョブのデプロイはJenkinsで
      • パッケージをzip、Docker imageを作成、registryにpushしてECSのAPIで引っ張るだけ
    • ログ
      • /var/lib/docker/containers/* にある
      • Sumologicにおくってる
      • ジョブごとにnameとIDふってるのでそれで探せる
    • メトリクスはDatadogつかってる
  • 規模は65ジョブ、44のスケジュールジョブ、1000job / day
  • 別の話題、containerで危ないジョブを動かす
    • Courseraのプログラミングの課題がある、それをテストするのにコンテナをつかってる
    • 悪用されないように、課題を評価したい
  • GrIDというシステムを作った: Grading Inside Docker
    • ECS + Iguazu
    • AWSアカウントをわけて、GrID用のアカウントで評価する
      • GrID側でECSも動かす
      • networkアクセスを限定、実行時間やリソースを限定
        • VPCでinbound/outbound共に制限
      • coursera/amazon-ecs-agent
        • コンテナごとに独立したネットワークスタックになるようにagentを変更
        • root権限周り
        • DockerのsocketをDockerコンテナの中にいれるようにした
    • セキュリティのモニタリングThreat Stack
    • ペネトレーションテストSynack もつかっている

(DVO401) Deep Dive into Blue/Green Deployments on AWS

  • blue/greenのパターン
    • EC2だと
      • DNSでcutoverする
      • ASGを切り替える
      • launc configurationを切り替える
    • ECS
      • DNS
      • ELBで切り替え
      • task definitionで
  • DNSのcutoverだとやっぱりrollbackがなーというところ
  • ELB以下のASG切り替え
    • rollbackも簡単
    • ELBの暖気も、もともとあるのを使うから必要ない
  • launch configの切り替えによる方法
    • まあできるけど自分ならやらないかな

(CMP401) Elastic Load Balancing Deep Dive and Best Practices

(BDT319) New! Amazon QuickSight: Cloud-native Business Intelligence

  • Directorの方。Amazon QuickSightは今回リリースされたもの。
  • Amazon QuickSight - Fast Business Intelligence by AWS
  • 対応するデータ
    • RDBやNoSQLはもとより、EMR, S3, ファイル、streamingのデータソースもサポートするらしい
  • SPICE: Super-fast Parallel In-memory optimized Calculation Engine
    • columnarデータを2から4倍圧縮する
    • SQLっぽい文法で扱える
    • fully managed
  • デモあったっぽい。ビデオみるか。
  • やっぱりやすいなー
    • ただGB課金は結構でかいかも
    • Enterprise EditionだとAD連携とかアクセスコントロールができる。あと2倍速い。
  • あとでビデオみよう

(DVO308) Docker & ECS in Production: How We Migrated Our Infrastructure from Heroku to AWS

  • Remindの方
    • 先生のためのmessagingサービス
    • 3000万ユーザ。USのpublic schoolの半数くらいで使われている
    • 20億メッセージがやり取りされている
    • 従業員50人以下、エンジニアは30人以下
  • Herokuはいいけど
    • 全部のappがpublicにアクセス可能
      • DBさえも
    • 制御できるところも限定されてる
  • The Twelve-Factor App 初めて知った。webアプリが守るべき12の要素
  • お、Goで書いてるのかな
  • 最初はCoreOS + Fleetでやってたらしい
    • routerはnginx
  • Dockerコンテナのbuildは git push したら外部CIでやってる
  • Introducing Empire: A self-hosted PaaS built on Docker & Amazon ECS | Remind Empireっていうのはこれのことか
  • Dockerコンテナのログつかうのにlogspoutつかってる
    • gliderlabs/logspout
    • Dockerコンテナのためのlog router
    • logはSumologicにながしてる
  • Docker imageのビルドには remind101/conveyor をつかっている

*1:結局月曜日から土曜日まで入院していました。これでアメリカ出張中だったら、、と考えると・・。チームのメンバーには迷惑をかけてしまいました。