![HATEOAS に習いクライアントサイドに必要な前提
条件を減らすことで、サーバサイドでURIを制御でき
るようになります。
HATEOAS (hypermedia as the engine of application state)
RESTful API を拡張したアーキテク
チャパターン。具体的には、レスポ
ンス値にリンクが付与される。よっ
て、クライアントサイドで次にする
事をリンクから選べるようになる。
{
"name": "DMM",
"links": [ {
"rel": "self",
"href": “http://www.dmm.com”
} ]
}
DMM.com ラボ マイクロサービスTIPS
15分
APIポリシー定義](https://image.slidesharecdn.com/rubygo-160218115830/75/Rubyxgo-38-2048.jpg)
![Ruby vs Go! ∼ コードの比較
数字の文字配列を2倍にしてカンマ区切りの文字列を表示
Ruby
1 p ["1","2","3","4","5"].map {|n| n.to_i * 2}.join(‘,')
> "2,4,6,8,10"](https://image.slidesharecdn.com/rubygo-160218115830/75/Rubyxgo-79-2048.jpg)
![Ruby vs Go! ∼ コードの比較
数字の文字配列を2倍にしてカンマ区切りの文字列を表示
Go
1 package main
2
3 import (
4 "fmt"
5 "strconv"
6 "strings"
7 )
8
9 func main() {
10 ary := [...]string{"1", "2", "3", "4", "5"}
11 nums := make([]string, len(ary))
12
13 for i, n := range ary {
14 if num, err := strconv.Atoi(n); err == nil {
15 nums[i] = strconv.Itoa(num * 2)
16 }
17 }
18
19 fmt.Printf("%+vn", strings.Join(nums, ","))
20 }](https://image.slidesharecdn.com/rubygo-160218115830/75/Rubyxgo-80-2048.jpg)
マイクロサービス時代の動画配信基Ruby×go=∞
- 2. DMMでは、動画配信基盤の刷新に取り組んでいます。モノリシックな システムをマイクロサービス化すべく、Ruby on Rails・AngularJS・ Go を利用しています。本セッションでは、それらのアーキテクトや 開発フローについて判りやすく説明します。
- 3. システム本部 デジタル配信開発部 グループ長 兼 チームリーダ 小嶋 聡史 2006年 ネットワークサービス事業者 2011年 ソーシャルゲーム事業者 2014年 ベンチャー企業 2015年 DMM.com ラボ 開発・運用・管理業務に携わり、2015年より DMM.com ラボへ参画していま す。DMM.comラボで、システムのアーキテクトや組織運営に従事しています。
- 4. システム本部 デジタル配信開発部 システムエンジニア 江藤 慎吾 20YY年 WEB 広告 2009年 コミュニティサイト・ソーシャルゲーム 2011年 ECサイト 2013年 DMM.com ラボ 課金基盤のプラットフォーム開発と運用に携わり、半年前よりデジタル配信開 発に参画しています。 アルゴリズムとサービスを考えることが好きで、最近では動画やVR技術を活 かしたコンテンツの自動生成などに興味をもっています。
- 8. 拠点 10以上 海外拠点拡大中 サービス数 40以上 トラフィック 140Gbps以上 1000億円以上売上 従業員数 1250人以上 会員数 1900万人以上
- 10. ニーズとシステムが大きく乖離
- 12. • 事業成長 • ニーズの多様化 • ニーズの変化の加速 独立した軽量なサービスを 小さなチームで作る。 結果、開発の短期化を実現し 事業スピードを高める。
- 15. 動画配信技術＃配信種別 動画配信には、VOD と LOD の２種類に分類できます。 今回は LOD について説明します。 VOD (Video On Demand) あらかじめ録画しておいた動画コンテンツを、 視聴提供するサービス。 LOD (Live On Demand) あらかじめ録画しておいたものではなく、撮った映像 を随時配信してリアルタイムに視聴提供するサービス。
- 18. 動画配信運用＃構成 利用者 配信機器 動画配信管理 動画配信者 カメラマン サーバ運用者 サービス運営者 動画配信監視者 お客様 ストリーミング サーバー （Origin) ストリーミング サーバー （Edge) CDN チャット サーバー ストレージサーバ （動画コンテンツ保管） チャンネルサービス 番組 ストリーム プレイヤー
- 22. １. サブシステム切り出し ２. API ポリシー定義 ３. 技術選定 15分 マイクロ サービス TIPS DMM.com ラボ
- 23. DMM.com ラボ マイクロサービスTIPS マイクロサービス化するために 巨大なモノリシックシステムから サブシステムを切り出します。 シンプルに RESTful API over HTTP(s) 等を 利用して機能提供することを前提とします。 15分 サブシステム切り出し＃階層化
- 25. ① 論理的な独立性を考慮する。 ② 物理的な独立性を考慮する。 DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化
- 26. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化 Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Job Handler サーバオペレーション
- 28. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化 Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Go Job Handler
- 29. 1 つの変更が他に波及すること ありませんか？ DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン
- 32. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン PLAYER <CORE SYSTEM> PLAYER Manager 字幕 <Plugin Module> 課金 <Plugin Module> サムネイル <Plugin Module> 広告 <Plugin Module>
- 33. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン プロトコルシーケンスはこんな感じです。 プレイヤー API プラグインA プラグインB 番組2を配信したい プラグインAとBを 利用して配信して 番組2に有効な プラグインを確認
- 34. Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Job Handler サーバオペレーション DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃PUB / SUB
- 35. PUB/SUB メッデージングモデルは、非同期メッセージ ングパラダイムの一種であり、メッセージの送信者（出 版側）が特定の受信者（購読側）を想定せずにメッセー ジを送るようプログラムされたものである 引用：https://ja.wikipedia.org/wiki/出版-購読型モデル DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃PUB / SUB
- 36. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃PUB / SUB Streaming Servers Publisher Wowza Streaming Servers Red5 Streaming Servers Wowza 社内DC社外DC Message Queue Subscriber Capistrano Subscriber Capistrano Enqueue Denqueue Cluster1から 動画配信 Subscriber Capistrano 設定投入
- 37. RESTful API over HTTP(s) で設計します。 今回は Twitter REST API を参考にしました。 DMM.com ラボ マイクロサービスTIPS 15分 APIポリシー定義 詳細は 「Web API The Good Parts」 でお願いします。
- 38. HATEOAS に習いクライアントサイドに必要な前提 条件を減らすことで、サーバサイドでURIを制御でき るようになります。 HATEOAS (hypermedia as the engine of application state) RESTful API を拡張したアーキテク チャパターン。具体的には、レスポ ンス値にリンクが付与される。よっ て、クライアントサイドで次にする 事をリンクから選べるようになる。 { "name": "DMM", "links": [ { "rel": "self", "href": “http://www.dmm.com” } ] } DMM.com ラボ マイクロサービスTIPS 15分 APIポリシー定義
- 39. ⑥ TraceID をつけてログ出力 ④ URL + TraceID ① URL ③ なければ TraceID を生成 トレース ID をつけることでデバッグしやくすなります。 DMM.com ラボ マイクロサービスTIPS 15分 APIポリシー定義 System ‘A’ System ‘B’ System ‘C’ ② X-DMM- TRACEIDが あるか ⑤ HTTP ヘッダー を 参照
- 41. 評 価 軸 名 説 明 開 発 コ ス ト 実 装 に 必 要 な コ ー ド 量 。 ツ ール （ イ ンス ト ール ・ 環 境 構 築 ・ デバ ッ グ 等 ） が 充 実 して い る か な ど 環 境 適 応 ブ ラ ウ ザ の 互 換 性 な ど 、 ユ ー ザ 環 境 が 絞 ら れ な い か 機 能 何 が で き る か 。 ど こ の レ イ ヤ ー ま で 網 羅 して い る か 拡 張 性 他 の ラ イ ブ ラ リ や フ レ ームワ ー ク と の 親 和 性 。 一 部 、 ラ イ ブ ラ リ を 変 え た と し た 時 の コ ス ト が 低 い か 将 来 性 メ ン テ ナ ンス さ れて い る か ＋ 今 後 も さ れ る か 。 技 術 が 古 く な い か 。 イ ン タ ー ネ ッ ト 上 で 話 題 に な って い る か 。 世 界 的 に 普 及 して い る か 学 習 コ ス ト 該 当 の 技 術 を 習 得 す る た め に 要 す る 時 間 ・ お 金 。 日 本 語 ド キ ュ メ ン ト ・ 難 易 度 な ど 信 頼 性 リ リ ース か ら ど れ ほ ど た って い る か 。 脆 弱 性 が な い か 。 利 用 実 績 レス ポ ンス 速 度 全 体 の サ イ ズ 。 レン ダ リ ン グ ・ ブ ラ ウ ザ の 動 作 レス ポ ンス ISO/IEC9126（JIS X 0129-1）ソフトウェア品質特性と副特性 から抜粋 DMM.com ラボ マイクロサービスTIPS 15分 技術選定
- 42. 評価軸名 言語１ 言語２ 言語３ 言語４ 言語５ 開発コスト 3 4 4 4 4 環境適応 4 5 3 4 5 機能 5 3 4 3 3 拡張性 4 3 2 4 2 将来性 3 4 3 4 4 学習コスト 6 6 8 8 10 信頼性 4 4 4 4 3 レスポンス速度 4 3 5 4 4 33 32 33 35 35 例 DMM.com ラボ マイクロサービスTIPS 15分 技術選定 ５点満点で、案件によっては評価軸のスコアを倍にし、その合計値で決定します。 将来性は、GoogleTrend や Qiitaトレンド、信頼性は ダウンロード数やメンテナンス 頻度で判断します。
- 43. 結果、Ruby + Go + AngularJS を採用しました。 DMM.com ラボ マイクロサービスTIPS 15分 技術選定 AngularJS {wrap} bootstrap Go Ruby + + RDOC JSON Hyper Schema
- 48. 技術選定 ∼ 管理系システム 配信情報やサーバー設定をするためのAPI + 管理Portal • 負荷は少ないと予想される • 柔軟なシステムであることが求められる • サービスとのビジネスロジックは分離する • 変更に即座に対応する • ライブラリを活用して柔軟性を持たせる
- 49. 技術選定 ∼ 管理系システム Ruby / Node.js / PHP7 などが候補にあがりましたが 今まではPHP中心でした。 しかし、あるメンバーの Railsやりたい! という 高いモチベーションにより…
- 51. 技術選定 ∼ バックエンドAPI プレイヤーに再生情報を返すためのAPI • 高負荷が予想される • 堅牢なシステムである必要がある • ビジネスロジックは分離し、変更は少なくする • プラグインアーキテクチャで柔軟性を持たせる
- 52. 技術選定 ∼ バックエンドAPI Java / Go / Erlang / Cなどが思いつきましたが、 いずれも業務で使ったコトがないのでよくわかりません。 (PHPやRubyでは無理そうです。。)
- 54. 楽しい言語選定 【必須条件2】 開発・保守しやすいこと ○ Go ○ Java ☓ C ☓ D ☓ Erlang ☓ Elixir ? node.js ▲ Scala
- 58. Go言語とは? • 2009年にGoogleが開発した言語 • 静的型付・コンパイル型 • ネットワークプログラミングに向いている • 標準ライブラリが充実 • Googleを始め国内でも採用実績多数 ※画像引用元 : https://github.com/golang-samples/gopher-vector
- 59. Go言語とは? ∼その独自の文化∼ シンプルかつ厳格なルール • 標準のコードフォーマット • 標準のコーディングスタイル • ファイル名やメソッド名の命名規則による意味付け • コンパイル時Warningという考え方はない。 • 未使用変数や無駄なインポートは許さない
- 61. gofmtが自動的にソースコードをフォーマットする。 (エディタで保存するたびに自動実行させましょう) Before 1 package main 2 import ("fmt"); func main() { 3 fmt.Printf("hello, worldn")//print 4 } Go言語とは? ∼その独自の文化∼
- 62. gofmtが自動的にソースコードをフォーマットする。 (エディタで保存するたびに自動実行させましょう) After 1 package main 2 3 import ( 4 "fmt" 5 ) 6 7 func main() { 8 fmt.Printf("hello, worldn") //print 9 } Go言語とは? ∼その独自の文化∼
- 63. goimportsが自動的にimportの過不足を修正する。 Before 1 package main 2 import ( 3 "fmt" 4 "reflect" // not used. error!!!!! 5 "strconv" 6 // "strings" // need!!!!! 7 ) 8 func main() { 9 ary := strings.Split("0120-123-456", "-") 10 fmt.Println(ary) 11 for _, num := range ary { 12 n, err := strconv.Atoi(num) 13 fmt.Println(n + 1) 14 } 15 } Go言語とは? ∼その独自の文化∼
- 64. goimportsが自動的にimportの過不足を修正する。 After 1 package main 2 import ( 3 "fmt" 4 "strconv" 5 "strings" // added 6 // "strings" // need!!!!!!! 7 ) 8 func main() { 9 ary := strings.Split("0120-123-456", "-") 10 fmt.Println(ary) 11 for _, num := range ary { 12 n, _ := strconv.Atoi(num) 13 fmt.Println(n + 1) 14 } 15 } Go言語とは? ∼その独自の文化∼
- 67. go get が依存ライブラリをダウンロードする go get と打つだけ! 設定ファイル不要! Go言語とは? ∼その独自の文化∼
- 68. go build がプログラムをビルドする。 go build と打つだけ! Makefileファイル不要! Go言語とは? ∼その独自の文化∼
- 69. go run がプログラムをすぐに実行する。 go run main.goと打つだけ! Go言語とは? ∼その独自の文化∼
- 70. go test がプログラムをテストする。 go test パッケージ名/.. と打つだけ! Go言語とは? ∼その独自の文化∼
- 71. go rename がソースをリファクタリングする。 gorename -from ‘変更前’ -to ‘変更後’ と打つだけ! Go言語とは? ∼その独自の文化∼
- 73. なぜGo言語なのか? PHPやRubyと逆の発想 - メリット • 実行速度が速い • 環境構築がものすごく楽!! • バージョン依存の問題が少ない! • バグになりそうなコードは除外される • アセンブリにコンパイルすることができる
- 74. なぜGo言語なのか? PHPやRubyと逆の発想 - デメリット • JSONなどの動的データの扱いは不向き • 戻り値によるエラーチェックが必須で冗長になりがち • ライブラリやノウハウが少ない • デバッガやロガー周りが充実していない
- 75. なぜGo言語なのか? 最終的な決定要素 • ハイパフォーマンスであること • システムコールまで追えること • 実用環境で十分な採用実績があること • 学習が容易で保守しやすいこと • ノウハウが資産になること • 今後もビジネスニーズがあること
- 76. Ruby vs Go! イメージ的な違い Ruby Go 富豪的プログラミング 動的スクリプト おもてなし オブジェクト指向 メソッドチェーン 豊富なライブラリ 大変なバージョン依存 環境構築でハマる シンプルさを追求 静的コンパイル 郷に入っては郷に従え 並行プログラミング C言語的 必要十分な標準ライブラリ 徹底した後方互換性 バイナリ一つ置くだけ
- 77. Ruby vs Go! フレームワーク Go Rails or Sinatra フレームワークのルールに従う フレームワークとgemで賄う 言語仕様のルールに従う いろいろ (revel, gorilla, goji, gin, gizmo, gocraft, go kit…) 必要なものを組み立てる Ruby
- 78. Ruby vs Go! 開発方法の比較 (なし) rails / runner / rake … bundle / gems / gulp … RSpec 便利だが覚えることが多い RCover Autodoc peek / New Relicなど go build go run hoge.go go get (バージョン管理不要) go test 普通のプログラム(assertなし) go test -cover go doc go test -pprof ビルド 実行 依存設定 単体テスト カバレッジ ドキュメント プロファイラ
- 79. Ruby vs Go! ∼ コードの比較 数字の文字配列を2倍にしてカンマ区切りの文字列を表示 Ruby 1 p ["1","2","3","4","5"].map {|n| n.to_i * 2}.join(‘,') > "2,4,6,8,10"
- 80. Ruby vs Go! ∼ コードの比較 数字の文字配列を2倍にしてカンマ区切りの文字列を表示 Go 1 package main 2 3 import ( 4 "fmt" 5 "strconv" 6 "strings" 7 ) 8 9 func main() { 10 ary := [...]string{"1", "2", "3", "4", "5"} 11 nums := make([]string, len(ary)) 12 13 for i, n := range ary { 14 if num, err := strconv.Atoi(n); err == nil { 15 nums[i] = strconv.Itoa(num * 2) 16 } 17 } 18 19 fmt.Printf("%+vn", strings.Join(nums, ",")) 20 }
- 82. Ruby vs Go! 言語に対する批判 Go 自由すぎるシンタックス 黒魔術メタプログラミング 突如襲い掛かる のエラー 言語として退化している ツール類はよく変わる デフォルト引数がない Ruby const引数がない Classがない 継承がない オーバーロードがない 三項演算子がない
- 84. 開発していて楽しい!
- 85. Goを活かしたアーキテクチャ KVSとしてAerospikeを採用 • JSONオブジェクトをmsgpackして利用 • 1ms程度の低レイテンシーを実現 • クラスタリングの運用が非常に楽 • Go言語用の公式ライブラリあり
- 86. Goのツボ ∼ configリロード configファイルの扱い 設定はconfigファイルにしておいて読み込みたい しかしファイルをリクエストごとに読み込むのは コストが高い。 Go言語は並行プログラミングに向いている そこでLinuxシグナルを利用したhot reloadを実装した。 参考 : http://openmymind.net/Golang-Hot-Configuration-Reload/
- 87. Goのツボ ∼ configリロード config hotリロードの手順 1. 初期化時にconfigを読み込み失敗したらプロセスを終了 2. シグナルを待ち受けるgoroutineを作成 3. シグナルが来たらロックをかけてconfigをリロード 4. 読み込みに失敗したら元のデータをそのまま使う
- 88. Goのツボ ∼ configリロード1/2 1 func init() { 2 loadConfigs(true) 3 4 s := make(chan os.Signal, 1) 5 signal.Notify(s, syscall.SIGHUP) 6 go func() { 7 defer handleRuntimeError() // point! 8 for { 9 <-s 10 loadConfigs(false) // 3 11 } 12 }() 13 } 14 15 func handleRuntimeError() { 16 if r := recover(); r != nil { 17 log.Printf("Error : Recover from error! ", r) 18 } 19 } ←1. 初期化時にconfig読み込み ←2.SIGHUPを待ち受ける ←エラー対策 ←3. configをリロード ←エラーはログを残して続行
- 89. Goのツボ ∼ configリロード2/2 1 func loadKVS(fail bool) { 2 3 temp = loadFile(fail, kvsFn) 4 if env.Env == env.Development { 5 tempHosts = temp.Development 6 } 7 8 client, err := as.Connection(nil, tempHosts...) 9 if err != nil { 10 if fail { 11 os.Exit(1) 12 } 13 return 14 } 15 kvsLock.Lock() 16 kvsHosts = tempHosts 27 kvsLock.Unlock() 18 } ←configファイル読み込み ←環境ごとに切り替え ←動作確認 ←初期化時エラーなら終了 ←リロード時エラーなら無視 ←ロックして更新
- 92. Goのツボ ∼ 環境変数 定数が最適化されるか試してみました! (何もしないコード) 1 package main 2 3 import "log" 4 5 const flag = false 6 7 func emptyFunc(msg string) { 8 if flag { // is false 9 log.Println(msg) 10 } 11 } 12 13 func main() { 14 emptyFunc("hello world!") // do nothing 15 } ←このコードは消えて欲しい
- 94. 素敵な開発フローお見せします
- 95. 素敵な開発フロー APIの開発方法はさまざまですが… • API仕様書を先に書く? • テストを先に書く? • モックアップサービスを使う?
- 96. 素敵な開発フロー LL系の開発などでこんな経験ありませんか? 1. APIのパラメータ名が変更になりました。 2. ドキュメントを修正します。 3. バリデーションファイルも忘れずに修正します。 4. プログラムのリクエストやレスポンスの整形部分も変え ます。 5. ロジックも変更しました。(が一部修正し忘れました) 6. テストが通りました。 7. いざ本番にデプロイすると、 Undefinedエラーが発生!
- 97. 素敵な開発フロー API定義を書くだけでよい自動変換ツールを取り入れました! 1. APIごとにJSON Hyper SchemaでYAMLを書く 2. ドキュメント(API仕様書)が自動的に生成される 3. バリデーション定義のJSONが自動的に生成される 4. Go言語の構造体定義が自動的に生成される 5. APIごとのバリデーションとハンドラ登録処理が自動的に 生成される 参考 : http://blog.wacul.co.jp/blog/2014/10/28/go-rest-api/
- 98. 素敵な開発フロー メタデータ API1.yml API2.yml API3.yml 開発者 API定義 手動管理 編集 パラメーター・レスポンス 構造体定義 バリデーション定義 API1 ハンドリング処理 API3 ハンドリング処理 API4 ハンドリング処理 API仕様書 API定義 ファイル API1 ロジック API2 ロジック API3 ロジック GOソース GOソース 手動管理 自動生成 パッチによる 自動変換 自動生成PRMDX により結合 JSON Hyper Achemaによる開発フロー
- 99. 素敵な開発フロー メリット • ロジックファイルの分離でバシバシ定義を修正できる • 構造体の生成と静的チェックでしっかり修正漏れを防げる 工夫したところ • バリデーションはAPI定義をJSON化しconfigと共にリロードできる!
- 100. JSON Hyper Schemaって素敵! お見せします! (WebAPIパラメータ名の変更) 1. API定義を修正 2. ツールを実行 3. ロジックを修正 4. コンパイルして修正漏れがないかチェック 5. 完成!
- 101. 詳しくは3月3日(木)の勉強会で!
- 102. 新しいプロジェクトが 続々と進行中!
- 104. 貴方の「やりたい!」をDMMで!!
- 105. ご静聴ありがとうございました。