Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Go言語オーバービュー201507

4.982 visualizaciones

Publicado el

Go言語オーバービュー

Publicado en: Tecnología
  • Sé el primero en comentar

Go言語オーバービュー201507

  1. 1. 0 Go言語 オーバービュー エスキュービズム・テクノロジー エンジニア勉強会 July 17,2015 S-cubism Technology Inc.
  2. 2. そろそろPHP飽きた・・ 1
  3. 3. 2 いや、そんなことないです・・ けど何となく感じる新しい胎動 Yii2とかまだまだ面白いです!
  4. 4. 時代は Internet of Everything (IoE) 3
  5. 5. 4 例えば飲食店IoE
  6. 6. これまで 会計データがぽつぽつ 5 速くても1端末15秒に1回程度
  7. 7. これから・・ • 会計データ • 注文データ • 予約データ • 調理データ • 配膳データ • 在庫データ • 来店データ • チャットデータ 6 などがデータとして取得することができ、 リアルタイムで複雑に処理される時代になる
  8. 8. そこでGo言語です 7
  9. 9. “Go is a programming language designed by Google to help solve Google’s problems.” 8
  10. 10. 特徴 • 速い – C、C++には若干負けるもののPHP、Ruby、 Pythonと比較すると充分速い • 賢い – 利用しやすい並列処理機構をサポート • 綺麗 – 構文はシンプルで可読性を重視 • 軽い – フットプリントが小さい、コンパイルが速い – ポータビリティに優れている 9
  11. 11. デメリット • ウェブフレームワークなどはPHPやRubyのそれ ほど成熟したものがない – (新しい言語と比較するとライブラリは充実している) • 構文はシンプルだがやや特殊 – (PythonとCを足して2で割って既成概念を取っ払っ て独自に進化させた感じ) • バージョン管理の問題が取り上げられている – (改善の動きはある) 10
  12. 12. Go Trends 11 (golang)
  13. 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. 14. 13 Hello World
  15. 15. Goの構文 (特殊だと思うところを紹介) 14
  16. 16. :=と= 15 新規の変数宣言と途中の変数代入を明示的に分けている
  17. 17. ArrayとSliceとMap 16 配列は値、スライスは配列を抽象化したポインタ
  18. 18. StructとMethod 17 オブジェクト指向でよくあるClass構文は存在しない
  19. 19. Defer 18 関数が最後まで実行された時、defer文が逆順に実行される
  20. 20. Errors 19 error型はあるが例外は投げない
  21. 21. PanicとRecover 20 強制終了の意味で最後の手段として使う
  22. 22. 並列処理の構文 21
  23. 23. Goroutine 22 概念としてスレッドに近いがスレッドより軽量
  24. 24. Channel 23 非同期な関数間における同期的なデータのやり取りを仲介
  25. 25. Buffered Channel 24 メッセージキューとして振る舞う
  26. 26. Select 25
  27. 27. 並列処理のパタン 26
  28. 28. プロセス • メモリ分離モデル • メリット – 簡単 – OSが全てを処理 – 状態を持たない処理によい(Webリクエストなど) – メモリリークがない • デメリット – プロセス間通信は難しい – 利用メモリの増大 27 http://www.slideshare.net/ryanstout/concurrency-patterns-24110376
  29. 29. スレッド • 共有メモリモデル – 1プロセスに複数のスレッド • メリット – 利用メモリを節約できる • デメリット(生で利用する場合) – ロックの手動対応 – デッドロック – 非決定的 – デバッグが難しい 28 http://www.slideshare.net/ryanstout/concurrency-patterns-24110376
  30. 30. イベント駆動IO • Node.jsが従うモデル – イベントループで各タスクを直列的に処理 • メリット – 重たいIOタスクに最適 – スレッドのスイッチングコストを節約できる – OSレベルでサポートされている(epoll、kqueue) • デメリット – 長期で走る処理が全ての処理をブロックする – マルチコアを利用しない – デバッグが難しい場合がある 29 http://www.slideshare.net/ryanstout/concurrency-patterns-24110376
  31. 31. アクターモデルとCSP 30 (Communicating Sequential Processes) “Don’t communicate by sharing state; share state by communicating”
  32. 32. 31 http://arild.github.io/csp-presentation/#1 アクターモデル
  33. 33. アクターモデル • Erlangが従うモデル – 状態は各アクターの中で閉じる – アクターはメッセージを非同期に送信 – メッセージは”mailbox”にバッファされる • メリット – デッドロックは発生しない(ルールを守れば) – デバッグが容易 • デメリット – アクター同士を結び付けるのが難しい – エラーハンドリングは特殊 32 http://www.slideshare.net/ryanstout/concurrency-patterns-24110376
  34. 34. CSP 33 (Communicating Sequential Processes) http://arild.github.io/csp-presentation/#1
  35. 35. CSP • Goが従うモデル – 変数は常にスレッドローカル – 状態は特定の長さのチャネルで共有される – 関数は非同期な”goroutine”で処理される • メリット – 分散データ処理において比較的シンプルなモデル – デバッグが容易 • デメリット – 単純な同期処理ではコードが余計にかかる 34 (Communicating Sequential Processes) http://www.slideshare.net/ryanstout/concurrency-patterns-24110376
  36. 36. Parallel 35 Concurrent https://software.intel.com/en-us/blogs/2013/06/18/go-parallel
  37. 37. Worker Queueも Goだと比較的容易に実装できる 36 https://talks.golang.org/2012/waza.slide#56 (とはいえ説明に時間かかりそうなので詳細は省略)
  38. 38. マイクロサービスについて 37
  39. 39. マイクロサービスの9つの特徴 • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • スマートエンドポイント、ダムパイプ • 分散ガバナンス • 分散データ管理 • インフラストラクチャ自動化 • 障害設計 • 進化的設計 38
  40. 40. モノリシックサービス 39http://qiita.com/spesnova/items/d7c95cc13ca1caf389fb
  41. 41. マイクロサービス 40http://qiita.com/spesnova/items/d7c95cc13ca1caf389fb
  42. 42. マイクロサービスの行方 • メリット・デメリットは多数議論されている – (ここでは詳細は省く) • 経験的に良い結果が出ている事案が増えている • プロダクト初期においてマイクロサービスは時期 尚早の可能性が高い 41http://deeeet.com/writing/2014/09/10/microservices/
  43. 43. Dockerで高速・簡単にデプロイできるようになり マイクロサービスが実現しやすくなってきている 42 http://patg.net/containers,virtualization,docker/2014/06/05/docker-intro/
  44. 44. Goはマイクロサービスに向いている • 必要なのは静的な実行ファイルだけ – 外部依存ライブラリがない – クロスプラットフォーム – JITコンパイルも必要なし • マルチコアの最適な利用 • 小さいフットプリント • モダンなWEBパッケージが組み込まれてる – ネットワークの基礎ライブラリも充実 43 http://www.slideshare.net/giorrrgio/import-golang-struct-microservice
  45. 45. 以上です。ありがとうございました。 44

×