Go言語オーバービュー

1. 0
Go言語
オーバービュー
エスキュービズム・テクノロジー
エンジニア勉強会
July 17,2015
S-cubism Technology Inc.

2. そろそろPHP飽きた・・
1

3. 2
いや、そんなことないです・・
けど何となく感じる新しい胎動
Yii2とかまだまだ面白いです！

4. 時代は
Internet of Everything (IoE)
3

5. 4
例えば飲食店IoE

6. これまで
会計データがぽつぽつ
5
速くても1端末15秒に1回程度

7. これから・・
• 会計データ
• 注文データ
• 予約データ
• 調理データ
• 配膳データ
• 在庫データ
• 来店データ
• チャットデータ
6
などがデータとして取得することができ、
リアルタイムで複雑に処理される時代になる

8. そこでGo言語です
7

9. “Go is a programming language
designed by Google to help
solve Google’s problems.” 8

10. 特徴
• 速い
– C、C++には若干負けるもののPHP、Ruby、
Pythonと比較すると充分速い
• 賢い
– 利用しやすい並列処理機構をサポート
• 綺麗
– 構文はシンプルで可読性を重視
• 軽い
– フットプリントが小さい、コンパイルが速い
– ポータビリティに優れている
9

11. デメリット
• ウェブフレームワークなどはPHPやRubyのそれ
ほど成熟したものがない
– （新しい言語と比較するとライブラリは充実している）
• 構文はシンプルだがやや特殊
– （PythonとCを足して2で割って既成概念を取っ払っ
て独自に進化させた感じ）
• バージョン管理の問題が取り上げられている
– （改善の動きはある）
10

12. Go Trends
11
(golang)

13. • “ParseがRubyからGoへ移行，信頼性が大き
く向上”
– http://www.infoq.com/jp/news/2015/07/parse-
moved-ruby-go
• “GunosyでのMicroservicesの現状とGoの使
いどころ”
– https://speakerdeck.com/ymatsuwitter/gunosy
defalsemicroservicesfalsexian-Zhuang-
togofalseshi-idokoro
• “High Performance Backend For Mercari”
• https://speakerdeck.com/cubicdaiya/high-
performance-backend-for-mercari
12

14. 13
Hello World

15. Goの構文
（特殊だと思うところを紹介）
14

16. :=と=
15
新規の変数宣言と途中の変数代入を明示的に分けている

17. ArrayとSliceとMap
16
配列は値、スライスは配列を抽象化したポインタ

18. StructとMethod
17
オブジェクト指向でよくあるClass構文は存在しない

19. Defer
18
関数が最後まで実行された時、defer文が逆順に実行される

20. Errors
19
error型はあるが例外は投げない

21. PanicとRecover
20
強制終了の意味で最後の手段として使う

22. 並列処理の構文
21

23. Goroutine
22
概念としてスレッドに近いがスレッドより軽量

24. Channel
23
非同期な関数間における同期的なデータのやり取りを仲介

25. Buffered Channel
24
メッセージキューとして振る舞う

26. Select
25

27. 並列処理のパタン
26

28. プロセス
• メモリ分離モデル
• メリット
– 簡単
– OSが全てを処理
– 状態を持たない処理によい（Webリクエストなど）
– メモリリークがない
• デメリット
– プロセス間通信は難しい
– 利用メモリの増大
27
http://www.slideshare.net/ryanstout/concurrency-patterns-24110376

29. スレッド
• 共有メモリモデル
– 1プロセスに複数のスレッド
• メリット
– 利用メモリを節約できる
• デメリット（生で利用する場合）
– ロックの手動対応
– デッドロック
– 非決定的
– デバッグが難しい
28
http://www.slideshare.net/ryanstout/concurrency-patterns-24110376

30. イベント駆動IO
• Node.jsが従うモデル
– イベントループで各タスクを直列的に処理
• メリット
– 重たいIOタスクに最適
– スレッドのスイッチングコストを節約できる
– OSレベルでサポートされている(epoll、kqueue)
• デメリット
– 長期で走る処理が全ての処理をブロックする
– マルチコアを利用しない
– デバッグが難しい場合がある
29
http://www.slideshare.net/ryanstout/concurrency-patterns-24110376

31. アクターモデルとCSP
30
(Communicating Sequential Processes)
“Don’t communicate by sharing state;
share state by communicating”

32. 31
http://arild.github.io/csp-presentation/#1
アクターモデル

33. アクターモデル
• Erlangが従うモデル
– 状態は各アクターの中で閉じる
– アクターはメッセージを非同期に送信
– メッセージは”mailbox”にバッファされる
• メリット
– デッドロックは発生しない（ルールを守れば）
– デバッグが容易
• デメリット
– アクター同士を結び付けるのが難しい
– エラーハンドリングは特殊
32
http://www.slideshare.net/ryanstout/concurrency-patterns-24110376

34. CSP
33
(Communicating Sequential Processes)
http://arild.github.io/csp-presentation/#1

35. CSP
• Goが従うモデル
– 変数は常にスレッドローカル
– 状態は特定の長さのチャネルで共有される
– 関数は非同期な”goroutine”で処理される
• メリット
– 分散データ処理において比較的シンプルなモデル
– デバッグが容易
• デメリット
– 単純な同期処理ではコードが余計にかかる
34
(Communicating Sequential Processes)
http://www.slideshare.net/ryanstout/concurrency-patterns-24110376

36. Parallel
35
Concurrent
https://software.intel.com/en-us/blogs/2013/06/18/go-parallel

37. Worker Queueも
Goだと比較的容易に実装できる
36
https://talks.golang.org/2012/waza.slide#56
（とはいえ説明に時間かかりそうなので詳細は省略）

38. マイクロサービスについて
37

39. マイクロサービスの９つの特徴
• サービスによるコンポーネント化
• ビジネスケイパビリティに基づく組織化
• プロジェクトではなくプロダクト
• スマートエンドポイント、ダムパイプ
• 分散ガバナンス
• 分散データ管理
• インフラストラクチャ自動化
• 障害設計
• 進化的設計 38

40. モノリシックサービス
39http://qiita.com/spesnova/items/d7c95cc13ca1caf389fb

41. マイクロサービス
40http://qiita.com/spesnova/items/d7c95cc13ca1caf389fb

42. マイクロサービスの行方
• メリット・デメリットは多数議論されている
– （ここでは詳細は省く）
• 経験的に良い結果が出ている事案が増えている
• プロダクト初期においてマイクロサービスは時期
尚早の可能性が高い
41http://deeeet.com/writing/2014/09/10/microservices/

43. Dockerで高速・簡単にデプロイできるようになり
マイクロサービスが実現しやすくなってきている
42
http://patg.net/containers,virtualization,docker/2014/06/05/docker-intro/

44. Goはマイクロサービスに向いている
• 必要なのは静的な実行ファイルだけ
– 外部依存ライブラリがない
– クロスプラットフォーム
– JITコンパイルも必要なし
• マルチコアの最適な利用
• 小さいフットプリント
• モダンなWEBパッケージが組み込まれてる
– ネットワークの基礎ライブラリも充実
43
http://www.slideshare.net/giorrrgio/import-golang-struct-microservice

45. 以上です。ありがとうございました。 44