すずけんメモ

技術メモです

Shibuya.go#2を開催します！

golang shibuyago

Shibuya.goの2回目を開催します！

Shibuya.go#2 - connpass

前回 Shibuya.go#1を開催しました。 - すずけんメモ に引き続き、弊社オフィスにて開催します！前回も盛りだくさんで、懇親会もだいぶ色々な話ができて楽しかったので今回もまた色々なお話ができれば嬉しいです。

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

shibuyago golang

今週の火曜日に 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を利用した継続的な成果物の配置

travisci golang

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

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

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

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

の紹介をします。

Travis Artifacts

f:id:suzu_v:20151218150020p:plain

travis-ci/artifacts はTravis 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

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

aws s3

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 golang

ずっと 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)

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

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

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

reinvent aws

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

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

  • KinesisのGMと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の設定もできる