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

Intro

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

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

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

Accelerating real applications in Go

Accelerating real applications in Go

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

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

  • Worker の数だけ gorutine を起動する

  • ブロッキングしないための工夫

    • メトリックを取る
    • channel の使用量は len() を使うと取れる

  • APNS

    • Worker の数 + pusher pool の数だけ push を送れるようになった

  • モニタリング

既存のアプリケーションに 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 も有用

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

www.slideshare.net

Talos208

database/sql

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

connection pool の話

接続数制限の API

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

感想

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

懇親会

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