2017-01-26

golang.tokyo #3 にブログ枠で参加した #golangtokyo

Intro

すみません、超雑なメモ書きです

ぶっちゃけブログ枠が空いていたので無理やり参加した感じです🙇

訂正の必要がある箇所がありましたらお知らせいただけると幸いです

Accelerating real applications in Go

久保達彦(id: cubicdaiya) / 株式会社メルカリ

遅れてしまって久保さんのトークは後半しか聞けませんでした 🙇

Worker の数だけ gorutine を起動する
ブロッキングしないための工夫
- メトリックを取る
- channel の使用量は len() を使うと取れる
APNS
- Worker の数 + pusher pool の数だけ push を送れるようになった
モニタリング
- API 2つ
  - golang
  - gaurun

既存のアプリケーションに golang で proxy server を挟んで性能を出す。golang にはマッチしている

感想

gaurun は以前から mercari さんで production 投入されている push 基盤なので相当ノウハウが溜まっていそうです

PERFORMANCE OPTIMIZATIONS

Carlo Alberto Ferraris / 楽天株式会社

https://slides.com/cafxx/perf-opts-devops/live

performance / Optimization

Theory /= practice

価値を共有しよう

最適化には最初に計測

あなた (開発者) のコストはサーバーより高い

12factor.net 日本語もあるよ

冗長化すれば安定する

しかし冗長化は簡単じゃない

自動的にリカバーしよう

全部を自動化しようとは言わない

基本は挑戦すること

KISS (Keep It Simple, Stupid)

コードを読む時間は書く時間の10倍にもなる

可読性とメンテナンス性を最適化するべき

読みにくい早いコードより読みやすい遅いコードの方が良い。コンピューターリソースの方が開発者より安いのだから

単一の目的

循環参照はダメ

分離しよう

可視化しよう

メトリックス、ログを見る

アラートは最後の結果を出すべき

まとめ

シンプルに、すべてを計測し、問題を最適化する

Q: Slack が好きで使ってるんだけど、どんなインターフェースを推奨します？

A: 状態を監視するのにチャットを使ったりする (的な…？その後聞き取れませんでした…)

感想

golang に限らず全ての開発現場に当てはまるようなお話。back to basic な感じで身の引き締まる想いでした

LT

Streamの扱い方

Streamの扱い方: Slides

辻　純平 / AWA株式会社

一度 []bytes に変換して decode するコードをよく見かける
これは不要
Stream を使うメリット
- メモリの効率化
- 標準パッケージの多くがサポート
実際に計測してもメリットを表している
実装例
- json.Unmarshal -> json.NewDecorder
- io.Copy
- bytes.Buffer -> io.Pipe
- io.Reader

感想

実際の経験からの有用な Tips
deeeet さんの tweet も有用

なぜ io.Reader/io.Writerを使うべきかは Ben Johnsonの https://t.co/Td9WAB39ip がめちゃ詳しいです #golangtokyo
— Taichi Nakashima (@deeeet) 2017年1月26日

やってみるとわかるけどgo bench -benchmemでメモリのアローケーションを可視化しながらベンチしてるとアロケーション減らすだけで大きな改善が見られる．io.Reader/io.Streamとかはその一歩でどれだけ大事かわかると思う #golangtokyo
— Taichi Nakashima (@deeeet) 2017年1月26日

Database migration

speakerdeck.com

konboi カヤック

Github ランキング上位の db migration tool は Rails style

Rails 方式

メリット

アプリケーションと同じ言語

デメリット

DSL を覚えるコストコンフリクトしやすい

git-schemalex Schema lex を使った migration tool GitHub - soh335/git-schemalex: database migration tool for mysql schema is managed via git

差分を見て SQL を吐いてくれる。その際にハッシュ値が更新される

感想

某所 Slack にてこの話題を小耳に挟んでいたので、ちょっと聞き流してしまいました💦

database/sql と connecton

Database sql from 明高橋

www.slideshare.net

Talos208

database/sql

ドキュメントに connection を Close することは滅多にない、使いまわすというような事が書いてある

connection pool の話

接続数制限の API

現場で起こった問題
- connection が死んでいても気づけなかった
- 1.6 で導入された DB.SetConnMaxLifetime() で解決した

感想

この辺の問題でしょうかね？ github.com

懇親会

サイバーエージェント様ありがとうございました！ (dictav さんの tweet を拝借 🙏 )

遅くなってごめんなさい。
サイバーエージェントさん、ありがとうございました！#golangtokyo pic.twitter.com/RFsv2EzTTp
— PLEASE GIVE ME A JOB (@dictav) 2017年1月27日

2016-12-31

2016 年の振り返り

はじめに

今年はとても忙しい一年だった印象があります

そして新しいことにチャレンジ出来た一年でもありました

embulk, BigQuery, Java

今年は部署異動がありまして年始から分析基盤の業務を手伝っていました

自分の力不足もありご迷惑をおかけすることも多かったと思いますが、当たり前に OSS に pull request を出し、github 上で英語でコミュニケーションするのが普通になりました

以前 OSS に対して pull request を出した時には英語の壁を感じていて、説明しきれないからと途中であきらめてしまった事もありました

説得するために、拙いながらも必死で英語でコミュニケーションを取る機会を持てた事は本当に良かったです

プラグインを量産する優秀なお二人と、自分に不足している部分をきちんと指摘してくれたマネージャーには本当に感謝しております

イベントスタッフ

細かいものもありましたが、大きいもので言うと以下になります

7/2 〜 7/3 YAPC::Asia Hachioji 2016 mid in Shinagawa

9/3 HTML5 Conference 2016

9/8 〜 9/10 RubyKaigi 2016

11/12 〜 11/13 東京Node学園祭2016

いろいろと忙殺されて東京Node学園祭以外参加報告を書けませんでした…

関係者のみなさま本当に申し訳ございません

転職

優秀なエンジニアの圧倒的な生産性を目の当たりにし、圧倒的な経験値の差を感じた年でもありました

学ぶことも多く、違う環境に身を投じてスキルアップを目指すのか、踏みとどまりもっと多くを吸収すべきかを本当に真剣に悩みました

軽い気持ちから始めた転職活動でしたが、自分で思っているより評価していただき違う環境に身を投じる事にしました

何よりも僕の知っている優秀な人達は会社という枠に留まる事なく github という広い場所で切磋琢磨している印象が強く、今現在自分もそう有りたいと思っています

転職活動の時期が 8 〜 10 月とイベントスタッフとしての忙しさや、業務上の忙しさと重なってかなりきつかった

海外カンファレンス登壇

kysnm.hatenablog.com

以前から周りの人達が海外勢とコミュニケーションしているのを羨ましく感じており、自分でも一歩踏み出してみました

ダメ元で出した CFP が通ってしまって、正直言うと本当に逃げ出したくなりました

登壇後にいただいたフィードバックにより、もっと丁寧に前提を共有する時間が必要だった事を感じました。

おそらくそうする事で自分自身ももう少し落ち着いて発表できたのかもしれません

また普段から準備していないとやっぱりつらいなとも思いました

今後は意識的にいつそういう機会が来ても良いように材料を探しておきたいなとも感じました

まとめ

本年お世話になったみなさまありがとうございました

より深くコミュニティの恩恵を感じ、また多くの人とも出会えた一年でした

来年もよろしくお願いいたします

2016-12-31

東京Node学園祭を支える技術 2016

nodefest node.js

はじめに
ノベルティ
振り返り
まとめ

はじめに

nodefest.jp

毎度のことながらだいぶ経ってしまいました

とはいえあまり書くことはありませんw

とりあえず年内に書けたということで

ノベルティ

kysnm.hatenablog.com

利用した業者は去年とほぼ同じです

名札の中紙の印刷業者として名刺印刷 | THE PRINT by SuperPrint を利用したくらいです

印刷の通販@グラフィック｜ネットプリントで顧客満足度96％は昨年クレジット情報が漏洩するという事件があったので敬遠したかったのですが、入稿後 1 日で印刷してくれるので利用させていただきました

振り返り

昨年は @t32k さん、今年は @hiloki さんと甘えっぱなしで本当に申し訳なかったです

依頼が確定した段階で、作成物の確認、すり合わせ、入稿期限、入稿先、入稿テンプレートなどの確認をあらかじめしておくべきでした

まとめ

自分が東京 Node 学園祭に関わるようになってから早いものでもう 6 年経ってしまいました

自分自身もう少し関わり方を変えていきたいという思いもあり、またコミュニティの空気を入れ替える意味でも来年はこのエントリーを書くことはないと思います

今後もっと国際的になっていく中で違う形でお手伝い出来たらいいなーと思っています

2016-12-23

Node.js の HTTP/2 対応について

node.js http2

はじめに
nghttp2
build
Hello world を動かす
TODO List
Project の進め方
終わりに

はじめに

この記事は Node.js Advent Calendar 2016 - Qiita の 23 日目です。

東京 Node 学園祭 2016 からもう一ヶ月以上経ってしまったのですね。

ゲストスピーカーとして登壇してくださった @jasnell がさらっと紹介してくれていましたが、進捗についてもう一度振り返ってみたいと思います

この実装が Node.js の core に入るか、module として切り出すのかは現在のところ決まっていません

東京 Node 学園祭 2016 の動画はこちら

気がつけば忙しかったり疲れていたりで jasnell とまったく話せていなくて軽くショックでした 💦

nghttp2

登壇時にも言っていましたが

nghttp2 is without question the best HTTP/2 library implantation available.

と日本の二大 HTTP/2 実装のうちの一つ nghttp2 をべた褒めしているのは本当に嬉しいです

@tatsuhiro_t さんは HTTP/2 の RFC draft 初期の頃から reference 実装として ietf の workgroup を引っ張ってきた実績のある方なのです

(もう一つは @kazuho さんの h2o ですよ)

Node.js の HTTP/2 の実装はこの nghttp2 を library として bind しています

build

github.com

上記 Repository を clone して ./configure && make するだけです。Python が 2.6 か 2.7 という制限があったりするのでお気をつけください

詳細はこちら

Code And Learn に参加された方はご存知ですよね！

(ああ、Japan のディレクトリ作って参加者の方に自己紹介 pull-request してもらえばよかったのでは…？)

Hello world を動かす

gist.github.com

./node index.js とかで実行。HTTP/2 をサポートしたブラウザでアクセスすると HTTP/2 で通信してくれます。やったね！

Example には Server Push もありますが、まだこれは動かないようです

http2/http2-implementation-notes.md at master · nodejs/http2 · GitHub

まだまだ書きかけのドキュメントですが、これから実装されていくと思うとワクワクしますね！

TODO List

issue にありました

github.com

この issue の最後で言っている design doc は先ほど紹介したドキュメントなのかな？

Project の進め方

github.com

今現在は Round7 ですが、こまめに goal を決めて実装していっているようです

こういった進捗管理も参考になりますね

終わりに

www.youtube.com

Node Interactive NORTH AMERICA でも発表があったようです

まだまだやる事はありそうなので何か手伝えたら良いなと思っております

それではみなさん npm xmas !

2016-12-22

quic のはじめ方

quic

ご指摘をいただいたので追記 2016-12-23 20:55
追記 2016-12-25 22:50
はじめに
quic のはじめ方
goquic
server
client
おわりに

ご指摘をいただいたので追記 2016-12-23 20:55

@kysnm chromium の quic_client の方は、サーバ認証を無効化する --disable-certificate-verification オプションを動くようにしたので、認証局発行以外でも大丈夫ですよ。
— Shigeki Ohtsu (@jovi0608) December 22, 2016

手元で試してみましたが、たしかにつながりました 🙌

ただ以下にも書きましたが Chromium は fetch してくるのに時間がかかる上、compile もそれなりに時間がかかります

@kysnm https://t.co/iffonzVi6C だと気分小さくなってるけど、まぁでかい人にはでかいね。go-quicの方は verifierが自前で作っているからコード修正しないと対応できなさそう。
— Shigeki Ohtsu (@jovi0608) December 22, 2016

@kysnm proto-quicはGoogleがメンテしてるので随時最新にしているけどchromiumのソースを余分に入れてて移行を楽にしてる。libquicはdevsistersが必要なソースだけ移植しているので大きな変更が入ると追随できない。サイズだけ比較すると辛いね。
— Shigeki Ohtsu (@jovi0608) December 22, 2016

goquic の verifier はこの辺かな？

goquic/proof_verifier.go at master · devsisters/goquic · GitHub

prot-quic は Linux じゃないと動かないようです

少なくとも手元の Macbook Pro では compile に至りませんでした

Installing build deps and syncing with Chromium repository...
ERROR: lsb_release not found in $PATH
done.

github.com

追記 2016-12-25 22:50

prot-quic が Linux のみサポートである事は README に書いてありました

iOS がサポートされたら Mac でも compile できるようになるかな？

Currently, the only supported platform is Linux (and the only tested version is Google's Ubuntu clone) but Windows and iOS should be coming soon

proto-quic/README.md at master · google/proto-quic · GitHub

はじめに

この記事は http2 Advent Calendar 2016 - Qiita の 22 日目です。

quic のはじめ方

現時点では以下の 2 つがあるようです

chromium の standalone test server and client
goquic の example

お手軽なのは goquic の方なのでそちらを紹介します

chromium だとソースコードを取ってくる時点でだいぶ時間がかってしまいます

chromium にチャレンジしてみたい方はこの辺を見ると良いと思います

www.chromium.org

goquic

github.com

README.md の通りなんですが、以下の手順で build します

go get ではなく、git clone した場合は git submodule init && git submodule update が必要なのでご注意を

この辺で教えてくれるので実は忘れていても大丈夫

$ go get -u -d github.com/devsisters/goquic
$ cd $GOPATH/src/github.com/devsisters/goquic

$ ./build_libs.sh # (for debug build)
$ ## GOQUIC_BUILD=Release ./build_libs.sh # (for release build)

$ go build $GOPATH/src/github.com/devsisters/goquic/example/server.go
$ go build $GOPATH/src/github.com/devsisters/goquic/example/client.go

go build を実行したディレクトリ直下に server と client という実行ファイルができています

server

server をそのまま実行すると以下のようなエラーになります

./server
2016/12/22 02:03:37 QUIC doesn't support non-encrypted mode anymore. Please provide -cert and -key option!

help があるので確認してみましょう

./server --help
Usage of ./server:
  -addr string
        TCP/UDP listen address (default "0.0.0.0")
  -cert string
        Certificate file (PEM), will use encrypted QUIC and SSL when provided
  -key string
        Private key file (PEM), will use encrypted QUIC and SSL when provided
  -loglevel int
        Log level (default -1)
  -n int
        Number of concurrent quic dispatchers (default 1)
  -port int
        TCP/UDP port number to listen (default 8080)
  -quic_only
        Use QUIC Only
  -root string
        Root of path to serve under https://127.0.0.1/files/ (default "/tmp")
  -scfg string
        Server config JSON file. If not provided, new one will be generated
  -use_sslv3
        Use SSLv3 on HTTP 1.1. HTTP2 and QUIC are not affected.

cert と key はきちんと認証局から証明を得たものでないと client 側がエラーになってしまうようです (client default の http ではなく https にして確認)

[1222/020754:VERBOSE1:quic_crypto_client_stream.cc(407)] Reasons for rejection: 2048
2016/12/22 02:07:55 Verify failedx509: certificate signed by unknown authority

いろいろとやり方はあるようなんですが確認していません

必要がある方はこの辺を見るとよいと思います

github.com

www.chromium.org

client

client も help を見てみましょう

./client --help
Usage of ./client:
  -loglevel int
        Log level (default -1)
  -url string
        host to connect (default "http://127.0.0.1:8080/")

という訳で -url をつけると任意のサーバーに接続してくれるようです

Google はすでに QUIC を利用しているので以下のようにすれば QUIC での接続を確認できます