Technology Engineering

178inaba の技術ブログ

golang.tokyo #4に行ってきた。 #golang #golangtokyo

Go

inabaです。

golang.tokyo #4に補欠からの当日滑り込み繰り上がりという運の良さで参加してきました。
会場はペアーズの株式会社エウレカさん。

倍率が2倍ということもあり、狭き門という印象のgolang.tokyoですが、今回から動画撮影も始まったようです。
次回のgolang.tokyoの前あたりに公開されるそうです。
自分も#2,#3と2回補欠だったのでこれは助かりますね！！

また、@tenntennさんからブログ枠の紹介がありました。
毎回3名分のブログ枠が用意されていて、

  • 先着順なので参加確定
  • まとめることで頭の中の整理になる
  • connpassの資料のページに掲示されるので多くの人にブログを見てもらえる

のが主なメリットだそうです。

今回はConcurrency(コンカレンシー、並行性)がテーマでした。
今回はブログ枠で参加ではないですが、ブログ枠で参加するときのためにまとめてみます。

Concurrency for distributed Web crawlers

末田 卓巳さん (@puhitaku) / フラー株式会社

WebクローラーのためのGo言語の話です。

  • アプリのデータをストアからクローラーで24時間毎に取ってくる。
    • 単一のサイト(シングルドメイン)なので間隔が短いとBANされる可能性がある。
    • 10万以上のアプリのデータをクロールする。
    • 画像のダウンロードがあるので1回のクロール時間が異なってくる。
  • コマンダーとクローラーから構成されるクロールプログラム。
  • 1回のクロール時間が異なるので、例えば100回クロールする2個のクローラーがあっても直列で実行すると処理終了時間がまちまちになる。
    • Goroutineを使って時間をずらして並行に実行していくと実行時間が同じになる。

f:id:i178inaba:20170302021108p:plain

  • SlackBotとしても動いている。
    • クローラのステータスを通知させる目的。
    • 普通のSlackBotは1回コマンドを打つと1回返答が返ってくる。
      • これだと何回もコマンドを打たないとならなくて面倒。
    • クローラーに実装されているSlackBotはSlackの編集機能を使う。
      • コマンドを受けた最初の投稿は普通に。
      • 次の投稿から編集機能を使用し、最初の投稿を編集する。
    • 普通の投稿か編集かの判断をしてPostをするGoroutineと投稿する文字列を生成するGoroutineが分けてあり、chanで通信している。

f:id:i178inaba:20170302022728p:plain

  • 並行処理時のTCPコネクションの枯渇問題
    • DBからデータを吸い出すのも並行で行っている。
    • 何らかの理由でqueryが遅く、並行処理が重なってしまいTCPコネクションを使い果たしてエラーが出ることがある。
    • それを防ぐため、バッファサイズを指定したchan(make(chan int, 100))を使用して一度に処理する回数を制限する。
    • 制限中にGoroutineが1つ終了するとブロックされていたchanのブロックが解除され、次のGoroutineが動作する仕組み。

Slackの編集機能をBotに使わせるというアイデアには「その手があったか！」と目からウロコでした！

Goのスケジューラー実装とハマりポイント

井手 康貴さん (@niconegoto) / 株式会社メルカリ/株式会社ソウゾウ

https://talks.godoc.org/github.com/niconegoto/talks/concurrency.slide#1

参考記事: qiita.com

The Go scheduler - Morsing's blog

  • GoroutineはOSスレッドに対して多対多。
    • 1対1、多対1に比べて全てのコアを使えてコンテキストスイッチも高速でいいとこ取り。
    • ただし、スケジューラーへの追加が煩雑になる。
      • Goはこの煩雑さをラップしていて、簡単(go f()と書くだけ。)にGoroutineが使えるようになっている。
  • 用語(runtimeパッケージ以下を読む時に覚えておくと役に立つ。)
    • M(Machine): OSスレッド
    • G(Goroutine): ゴルーチン
    • P(Processor): プロセッサ。4コアなら4
  • Pは自分にスケジューリングされたGが無くなると、別のPからGを半分奪う。
    • これにより、全てのスレッドが最大パフォーマンスで動作できる。
  • runtime.GOMAXPROCS()が1でもGoは複数のスレッドで実行される。
  • ハマりどころ
    • ループしてGoroutine外の変数を参照する場合。
    • runtime.GOMAXPROCS()が大きいほど切り替わりやすくなる。

今までなんとなく使っていたgo f()の仕組みがとてもわかりやすく理解できました。

Ridge - A framework like GAE/Go on AWS

藤原 俊一郎さん (@fujiwara) / 株式会社カヤック

GAE/GoをAWSで動かすためのフレームワークの話です。

  • 下記を使用
    • APEX
      • 通常、LambdaでGoを実行することはできないが、APEXを経由させることにより実行できる。
    • AWS API Gateway
    • AWS Lambda
    • Go
  • API Gateway × Lambdaのデメリット
    • 独自オブジェクト
    • ルーティング・・・
    • テスト・・・
    • Goで書きたい！
  • Ridgeが行う事
    • API Gateway(JSON)とnet/http(Request, Response)の相互変換
    • Lambdaで動かさない時は通常と同じくサーバとして立ち上げられる。
  • 流れはリクエスト→API Gateway→AWS Lambda→APEX→Go(Ridge→Handler)
  • メリット
    • 独自オブジェクトではなく、いつも使っているRequest/Responseが使える
      • Request/Responseで書くからテストにhttptestが使える。
    • ルーティングもGo内で行える。
    • ローカルで動かせるからlocalhostを叩いて結果を受けるとかができる。
    • EC2でも普通に動かせる。
    • API Gateway × Lambdaのメリットが享受できる。
      • 高負荷時自動スケール
      • EC2の管理無し！
      • デプロイもコマンド一発。
      • つまりGAE/Go！
  • できないこと
    • 同一名クエリ(foo=a&foo=b)や同一名ヘッダが受け取れない。
    • バイナリ(画像等)が返せない。
    • Goroutineを動かし続ける
    • 1リクエスト10秒を超える処理
  • 向いていない事
    • 低レイテンシが要求されるような処理
  • 向いている事
    • 頻繁にアクセスが無い。
    • レイテンシ要求がシビアでない。
      • ChatBotやゲームの終了告知(POSTを受けてJSONを返す)等
  • ログはCloudWatch Logsに送られるが、それをLambdaに送ってRidgeでパースしている。

github.com

既存のWebアプリもちょこっといじってmux.HandleFuncを使うようにするだけでハンドラの中身を変えなくてもRidgeを使い始められるのがすごいですね！
制限はありますが、ChatBotくらいから試しに使ってみるのはいいかもしれません。

懇親会

途中、ピザとビールが出る懇親会がありました。

美味しかったです！ごちそうさまでした！！

Goを使ったtailコマンドの実装(ライブコーディング)

金子 慎太郎さん (@kaneshin0120) / 株式会社エウレカ

コード: https://gist.github.com/kaneshin/a398720b8e20722a83bc6903e4017435

発表予定だった牧さんが残念ながら都合がつかず来られなくなってしまったため、急遽かねしんさんがライブコーディングをすることに。
懇親会しながらも、みんなの目線はスクリーンに釘付けでした。
tenntennさんのツッコミも入りつつ、かなり盛り上がっていました。

嫁に怒られずにGoを書く技術

@teitei_tkさん / freee株式会社

嫁だけでなく、非エンジニアの友人駆動開発にも使えますね。
嫁が居ないのでそんなことを考えてました(泣)
質問の時、tenntennさんが
「質問無いですか？」
「嫁はどうやって作るんですかとかでもいいですよ。」
「ペアーズ使いましょう！」
と自分でツッコんで会場が沸いてましたｗｗｗ

Gogland

Sergey Ignatovさん (@sergey__ignatov) / JetBrains

JetBrains製のIDEの紹介です。

英語だったので必死に聞きましたが半分はツイッターの#golangtokyoを追っていました。
何件か気になるツイートを紹介します。

自分は、こういうのどうやって作るんだろうっていうのを考えながら見ていました。

まとめ

ブログを書くのは結構大変だけど、頭の中が整理できるのでおすすめです。
長めに書いてしまったのは反省点で、今後はもうちょっとまとめられるようにしていきたいと思います。

運営の皆さんご苦労様でした！！
また参加させて頂きます！！