Save 37% off PRO during our Black Friday Sale! »

(Go未経験チームで) Goで動画分析基盤を作った話し

(Go未経験チームで) Goで動画分析基盤を作った話し

1e40cedef9dffd10fdc0dc71717cdefd?s=128

Shinobu Noguchi

March 27, 2019
Tweet

Transcript

  1. (Go未経験のチームで) Goで動画分析基盤を作った話し 株式会社 WILL Grorp インキュベーション本部 テックリード 野口 忍

  2. ・これからGoやってみよう ・これからチームにGo導入しよう という方向けなので既にGoやってる方には退屈かもしれません このスライドについて 対象

  3. このスライドについて というわけで 飽きたら 寝てOK

  4. このスライドについて それでも 飽きたら イヤホンしてたらOK

  5. このスライドについて どうしても飽きても フラッシュモブはNG

  6. 野口 忍 株式会社 WILL Group インキュベーション本部 テックリード やってる事 ・インフラとかSRE的な事 AWS,GCP,Docker,CI/CDなどなど

    ・サーバーサイド開発 (PHP,Go) ・フロントエンド開発 (AngularJS,Vue.JS) ・マネージメント その他何でもやってます 自己紹介
  7. 自己紹介 副業やってます

  8. 個と組織をポジティブに変革するチェンジエージェント・グループ 知ってる方いらっしゃいますか? 弊社について

  9. 弊社について 従業員数 2,044名(連結、2018年3月末現在) グループ会社 35社(国内:14社、海外21社) 売上高 791億円(連結、2018年3月期) 事業内容 人材派遣、業務請負、人材紹介を主とする人材サービス事業を行うグループ会社の経 営計画・管理並びにそれに付帯する業務。

    東証一部上場 株式会社ウィルグループ
  10. 弊社について 従業員数 2,044名(連結、2018年3月末現在) グループ会社 35社(国内:14社、海外21社) 売上高 791億円(連結、2018年3月期) 事業内容 人材派遣、業務請負、人材紹介を主とする人材サービス事業を行うグループ会社の経 営計画・管理並びにそれに付帯する業務。

    東証一部上場 株式会社ウィルグループ
  11. 弊社について IT企業では無いです。 今まさにIT化に向けて舵を切っているそんな会社です。 株式会社ウィルグループ

  12. 弊社について

  13. 弊社について

  14. 弊社について

  15. 弊社について Goを使ってるプロダクト!

  16. Dooonutはどんなサービスか? 動画マーケティングツールを開発しています!

  17. Dooonutの動画配信アーキテクチャ (ざっくり) ユーザー 企業担当者 管理画面 EC2 S3 Elastic Transcoder エンコード

    RDS メタ情報書き込み メタ情報書取得 エンコード済み 動画取得 動画再生プレイヤー EC2 動画配信 再生情報 書き込み 動画アップ
  18. なぜGoを選んだのか? メンタル編 メンバーがPHPに飽きていた 新しいサービスでまたPHPはちょっと。。的な状態 モチベーション的な問題 キャリア形成的な問題 エンジニアマネージャー(当時)という役回り上2年目などの若手も居る状況で「サーバー サイドはPHPだけやってました!」という状態でいずれ訪れる転職市場に出すわけには いかない。

  19. なぜGoを選んだのか? 技術編 ・速い(コンパイルも実行も) 繰り返しますがマジで速いです ・並列処理が出来る 言語の特性 学習面 ・シンプルな言語なので初学者ばかりでも学びやすい ・言語としてはトレンドなので書籍、ネットと情報も結構あった 生産性

    優れた質の高いパッケージがGithubで多数あるので車輪の再発明をしないで良い。とい うか明らかに自分らで書くよりもハイレベルなパッケージを利用出来る
  20. なぜGoを選んだのか? 技術編 こういったシートをエンジニアで書いて選定しています

  21. なぜGoを選んだのか? 一番の理由 何かかっこいいじゃないですか!Go出来たら

  22. 導入時に悩んだ事 PHPならLaravel,PythonならDjangoとか各言語で一定のプレゼンスを確立しているフ レームワークがあるのですが、Goはまだまだフレームワーク戦国時代です フレームワークの選定 Revel Echo Gin Goji Beego

  23. 導入時に悩んだ事 色々検討しましたがEchoを選定しました。 ・REST APIを作るのに適していた API部分だけの実装なので、フルスタックのフレームワークは不要だった。 やりたい事とフレームワークが提供している機能がマッチしていました。 ・学習コスト シンプルなフレームワークなので個人的な見解ですがGoを学べばEchoの使い方の学 習コストはほとんど無いような感覚でした。 ・その他

    Githubのスターが良い感じに増え続けていた フレームワークの選定
  24. 導入時に悩んだ事 Goを始める時にたくさんの人が「GOTATH どこ」とかで検索する事案 結論→ここにしなさいと言った正解はありません。 要は決めの問題です。 自分の使う環境下で異なります。 GOPATHの場所に悩む

  25. 導入時に悩んだ事 これもフレームワーク同様に選択肢があって当時はglideを選択しました。 パッケージ管理 package: main import: - package: github.com/go-sql-driver/mysql -

    package: github.com/labstack/echo version: 3 - package: github.com/BurntSushi/toml - package: github.com/aws/aws-sdk-go version: 1.12.76 subpackages: - aws glide.yaml .yamlでインポートしたいパッケージを記載して glide installすればパッケージが 一括でインストールされます。glide up で一括アップデート!
  26. 導入時に悩んだ事 パッケージ管理 順調に利用していたglideでしたが、開発終了を検討しているらしくGoが公式に開発して いるdepへの移行が推奨されていいます。 しかし さらーーに!! Modulesが登場して1.11以降からGo言語でパッケージ管理がサポートされました。

  27. 導入時に悩んだ事 パッケージ管理 今からGoはじめるなら Modules 使って go mod しましょう!! とうわけで

  28. 開発環境について Visual Studio Code使ってます とりあえずまずGoやります!という場合Microsoft謹製のこのエクステンションがあればと りあえず間違い無いです! エディタ

  29. 開発環境について 開発環境全体イメージ

  30. 開発環境について 開発環境全体イメージ ココの部分のお話です。

  31. 開発環境について ネットにたくさん情報ありますし平成も終わろうとしてる今、Docker環境はわざわざ説明し ないで大丈夫かな?と思ってますので割愛させて頂きます。 2分でとりあえずGoやりたい方向け↓ docker pull golang docker run -it

    golang Docker
  32. 開発環境について 実際の私達の環境では docker pull golang だと少しDockerイメージのサイズが大きいと感じたのでAlpine LinuxをベースにGoイン ストールしてといったDockerfileを書いてそれでイメージを作っています。 ご存知な方も多いと思いますがDockerイメージは軽いが正義です! ・ディスクを圧迫しない

    ・ビルドも速い ・プッシュもプルも速い (などなどメリットしか無いです) Docker
  33. 開発環境について フレッシュです! Goは実行する為にはコンパイルが必要ですが、これはコードの変更を検知して自動でビル ドしてくれるツールです。 チームでAngularJSを利用していたので、 「Angularでコード変えた時のああいうの」 「ああ、アレね」 で導入時に通じました Fresh

  34. 開発環境について go get して go get github.com/pilu/fresh 開発しているアプリケーションのホームディレクトリに移動して cd /path/to/myapp

    fresh!! fresh Fresh
  35. Goの記法に慣れるまで 直近のプロダクトがPHPだった関係で滅多に無いですが注意しないとこんな事が起きる 可能性がありました。(実際ありました) 型 〜ありがたや $value = 1 $value =

    ‘1’ PHPあるある var value int value = “1” // 怒られる Goでは起こりえない
  36. Goの記法に慣れるまで REST APIの開発での恩恵は抜群でした! こういった形でJSONレスポンスをあらかじめ構造体で定義しておく事ができます。 ・テストが楽になる ・コードレビューもやりやすくなる 構造体 〜バンザイ! type videoSummaryByID

    struct { ID string `json:"id"` Title string `json:"title"` Video string `json:"videoData"` PlayCount int `json:"playCount"` PlayCountUnique int `json:"playCountUnique"` Status string `json:"status"` UpdatedAt string `json:"updatedAt"` }
  37. Goの記法に慣れるまで 正直はじめは戸惑いがありました。 Java,PHP経験者のメンバーが多く 「try」 「catch」 「finally」 とある種の例外処理固定観念を持っていました 例外処理が無い 〜意外と良いやん!

  38. Goの記法に慣れるまで try! catch! finally! こんな感じですよね。例外処理せねばエンジニアに非ず的な

  39. Goの記法に慣れるまで 例外処理は無いですがエラーハンドリングはあります。 エラーがあるか無いか? if err != nil{} で処理をハンドリングしています。 ちゃんとコードを書こうという意識が上がった ・try

    catch囲っておけばまあ。。ねえ。みたいな意識は無くなる 例外処理が無い 〜意外と良いやん! // ファイルをオープン f, err := os.Open("golang.txt") // エラーハンドリング if err != nil{ fmt.Println("error") }
  40. Goの記法に慣れるまで 〜短い変数名 // ファイルをオープン f, err := os.Open("golang.txt") 先程のエラー処理のところのファイルオープンの処理 //

    ファイルをオープン file, err := os.Open("golang.txt") 疑問:fileじゃだめなのか? 答え fileでもOKです。 ただし、Goではスコープが限られたローカル変数は短い変数名が推奨されています
  41. Goの記法に慣れるまで 〜短い変数名 // クリックとコンバージョンとクリックのユニーク値取得 clicks, err := dBHandler.clickData(ID) conversion, err

    := dBHandler.conversionData(ID) clicksUnique, err := dBHandler.clicksUniqueData(ID) 実際のところ (極端な例ですが) // クリックとコンバージョンとクリックのユニーク値取得 cl, err := dBHandler.clickData(ID) co, err := dBHandler.conversionData(ID) clu, err := dBHandler.clicksUniqueData(ID) 短くすると分かりにくい事もあるので短い事が良いだけでも無い C何とかが続いて頭が痛くなってくる 短くするのも「さじ加減」が大事 普通の命名規則同様によほど変じゃなければコードレビューは通す
  42. Goの記法に慣れるまで クラスとか継承が無い 親クラス 子クラス メンバーの大半がクラス作って継承します的な書き方が体に染み付いていた。 当初はもちろん慣れない、とまどいありました。 しかし結果ですが、可読性は格段に良いです!! 子クラスから親クラスを追ってあれ?共通クラスも。。みたいなコードリーディングが無くなり ました。 処理A

    処理A 処理B import
  43. 使ってみてどうだったか? こうすればOKみたいなスタンダードがよく分からない ・Go言語自体のアップデートだったり ・パッケージ管理の移り変わりの速さだったり ・フレームワークとかこれといったデザインパターンのスタンダードが無かったり Goをやるなら 良くも悪くも色んな変化や見極めがあるのでそこを楽しめるか? がとても大事だと思います。

  44. 使ってみてどうだったか? コードレビューのしやすさは上がりました。 ・型がある ・クラスも継承も無い どういう処理をして何の値を返すのか? がコードを見て明らかに理解しやすくなりました。 PHPプロダクト比でコードレビューがやりやすくなった

  45. 使ってみてどうだったか? 構造体のおかげでもあるのですが、フロントエンドからリクエストを投げて、レスポンスを 取得する際にGoのAPIのレスポンス構造を見ればフロントエンドでどういうデータを受け 取れるのかが分かりやすくなりました。 フロントエンドからのJSONリクエストをGoで受け取る場合も同様です。 フロントエンドとの連携がしやすくなった

  46. 使ってみてどうだったか? コンパイル様様です。 リリース後のバグがPHPプロダクト比で減 全体的に ・コードの可読性も上がり ・リリース後の不具合も比較的少なく ・コードのメンテナンスがしやすい といった良い印象ばかりです。 確実に生産性はあがりました!!!

  47. エンジニア絶賛募集中です!! フロントエンド ・AngularJS ・Vue.JS ・TypeScript 技術セット サーバーサイド ・Go ・PHP ・Python

    インフラ関連 ・AWS ・GCP ・Docker ・フロントエンドからインフラまでやりたい方 ・新規事業で開発したい方 ・英語使いたい方 求む!! 各種ツール ・Github ・Slack ・JIRA