マイクロサービス時代の動画配信基Ruby×go=∞

マイクロサービス時代の動画配信基Ruby×go=∞

1. 1. マイクロサービス時代の 動画配信基盤 Ruby×Go=∞
2. 2. DMMでは、動画配信基盤の刷新に取り組んでいます。モノリシックな システムをマイクロサービス化すべく、Ruby on Rails・AngularJS・ Go を利用しています。本セッションでは、それらのアーキテクトや 開発フローについて判りやすく説明します。
3. 3. システム本部 デジタル配信開発部 グループ長 兼 チームリーダ 小嶋 聡史 2006年 ネットワークサービス事業者 2011年 ソーシャルゲーム事業者 2014年 ベンチャー企業 2015年 DMM.com ラボ 開発・運用・管理業務に携わり、2015年より DMM.com ラボへ参画していま す。DMM.comラボで、システムのアーキテクトや組織運営に従事しています。
4. 4. システム本部 デジタル配信開発部 システムエンジニア 江藤 慎吾 20YY年 WEB 広告 2009年 コミュニティサイト・ソーシャルゲーム 2011年 ECサイト 2013年 DMM.com ラボ 課金基盤のプラットフォーム開発と運用に携わり、半年前よりデジタル配信開 発に参画しています。 アルゴリズムとサービスを考えることが好きで、最近では動画やVR技術を活 かしたコンテンツの自動生成などに興味をもっています。
5. 5. §1 はじめに §2 マイクロサービス §3 動画配信基盤 §4 アーキテクチャ §5 技術選定 §6 実装詳細 §7 おわりに 動画配信基盤の マイクロサービス化への取り組み
6. 6. 独立した軽量なシステムをシンプルに連携し構成したアーキテクチャ マイクロサービスとは
7. 7. むかし、むかし、DMM は… 巨大な１システムでできていまし た。会員基盤・課金処理・各種サー ビス等の処理が密結合で１つの巨 大なリポジトリで運用していまし た。 MONOLITHIC ARCHITECTURE
8. 8. 拠点 10以上 海外拠点拡大中 サービス数 40以上 トラフィック 140Gbps以上 1000億円以上売上 従業員数 1250人以上 会員数 1900万人以上
9. 9. サービス大規模化 システム複雑化 組織巨大化 開発短期化
10. 10. ニーズとシステムが大きく乖離
11. 11. マイクロサービスに期待することは？
12. 12. • 事業成長 • ニーズの多様化 • ニーズの変化の加速 独立した軽量なサービスを 小さなチームで作る。 結果、開発の短期化を実現し 事業スピードを高める。
13. 13. 共通プラットフォーム開発 2015年 Message Hub 支払 売上 購入 決済 セキュ リティ 会員 電子 マネー OpenAPI BusinessAPI 商品情報 API アプリ用 API ブログ パーツ Markers -API Connect Gateway レジ ログイン DMMConnect OpenUI Cllent DMM.EVO
14. 14. 動画配信サービス PC ゲーム TV スマホ Player インターネット お客様
15. 15. 動画配信技術＃配信種別 動画配信には、VOD と LOD の２種類に分類できます。 今回は LOD について説明します。 VOD (Video On Demand) あらかじめ録画しておいた動画コンテンツを、 視聴提供するサービス。 LOD (Live On Demand) あらかじめ録画しておいたものではなく、撮った映像 を随時配信してリアルタイムに視聴提供するサービス。
16. 16. 動画配信サービス＃Yellの例        にて アイドル・有名人を ライブ配信します
17. 17. 動画配信技術＃LOD仕組み 動画配信者 カメラマン トランスレコーダー CDN ストリーミングサーバー サーバー運用者 プレイヤー プレイヤー プレイヤー お客様 動画配信監視者 サービス運営者 撮影現場 データセンター インターネット
18. 18. 動画配信運用＃構成 利用者 配信機器 動画配信管理 動画配信者 カメラマン サーバ運用者 サービス運営者 動画配信監視者 お客様 ストリーミング サーバー （Origin) ストリーミング サーバー （Edge) CDN チャット サーバー ストレージサーバ （動画コンテンツ保管） チャンネルサービス 番組 ストリーム プレイヤー
19. 19. 動画配信運用＃流れ 動画配信者 カメラマン トランスレコーダー サーバー運用者 プレイヤー プレイヤー 視聴者が 一万人です 番組の音と絵が ずれています 撮影現場 データセンター インターネット 動画配信監視者 明日 番組配信します 番組が 見れないです サーバー 構築します！ どのサーバーに 配信しますか？ サービス運営者 プレイヤー お客様 ストリーミングサーバー CDN サーバー 増設実施します
20. 20. サービス間の一貫性 API のオーバヘッド セキュリティへの配慮 デバッグのしにくさ 導入課題
21. 21. ポチッと押すと、動画配信できるシステム。 今までのレガシーシステムを改善し、 あらゆるサービスで動画配信リソースを即時に 提供可能なオープン化された BaaS。 15分 マイクロ サービス TIPS DMM.com ラボ
22. 22. １. サブシステム切り出し ２. API ポリシー定義 ３. 技術選定 15分 マイクロ サービス TIPS DMM.com ラボ
23. 23. DMM.com ラボ マイクロサービスTIPS マイクロサービス化するために 巨大なモノリシックシステムから サブシステムを切り出します。 シンプルに RESTful API over HTTP(s) 等を 利用して機能提供することを前提とします。 15分 サブシステム切り出し＃階層化
24. 24. どのように切り出すか？ DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化
25. 25. ① 論理的な独立性を考慮する。 ② 物理的な独立性を考慮する。 DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化
26. 26. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化 Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Job Handler サーバオペレーション
27. 27. どのように実装したか？ DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化
28. 28. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃階層化 Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Go Job Handler
29. 29. 1 つの変更が他に波及すること ありませんか？ DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン
30. 30. 字幕 課金 サムネイル 広告 PCプレイヤー 課金 サムネイル サービスA 携帯プレイヤー DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン サービスBサービスA PCプレイヤー モジュールモジュールモジュール
31. 31. 今後も変更が多そう。困った。 DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン
32. 32. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン PLAYER <CORE SYSTEM> PLAYER Manager 字幕 <Plugin Module> 課金 <Plugin Module> サムネイル <Plugin Module> 広告 <Plugin Module>
33. 33. DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃プラグイン プロトコルシーケンスはこんな感じです。 プレイヤー API プラグインA プラグインB 番組2を配信したい プラグインAとBを 利用して配信して 番組2に有効な プラグインを確認
34. 34. Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Job Handler サーバオペレーション DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃PUB / SUB
35. 35. PUB/SUB メッデージングモデルは、非同期メッセージ ングパラダイムの一種であり、メッセージの送信者（出 版側）が特定の受信者（購読側）を想定せずにメッセー ジを送るようプログラムされたものである 引用：https://ja.wikipedia.org/wiki/出版-購読型モデル DMM.com ラボ マイクロサービスTIPS 15分 サブシステム切り出し＃PUB / SUB
36. 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. 37. RESTful API over HTTP(s) で設計します。 今回は Twitter REST API を参考にしました。 DMM.com ラボ マイクロサービスTIPS 15分 APIポリシー定義 詳細は 「Web API The Good Parts」 でお願いします。
38. 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. 39. ⑥ TraceID をつけてログ出力 ④ URL + TraceID ① URL ③ なければ TraceID を生成 トレース ID をつけることでデバッグしやくすなります。 DMM.com ラボ マイクロサービスTIPS 15分 APIポリシー定義 System ‘A’ System ‘B’ System ‘C’ ② X-DMM- TRACEIDが あるか ⑤ HTTP ヘッダー を 参照
40. 40. 技術選定で、大事にしたいこと… DMM.com ラボ マイクロサービスTIPS 15分 技術選定 エンジニアに 習得できるか？ エンジニアを 確保できるか？ エンジニアが 成長できるか？
41. 41. 評 価 軸 名 説 明 開 発 コ ス ト 実 装 に 必 要 な コ ー ド 量 。 ツ ール （ イ ンス ト ール ・ 環 境 構 築 ・ デバ ッ グ 等 ） が 充 実 して い る か な ど 環 境 適 応 ブ ラ ウ ザ の 互 換 性 な ど 、 ユ ー ザ 環 境 が 絞 ら れ な い か 機 能 何 が で き る か 。 ど こ の レ イ ヤ ー ま で 網 羅 して い る か 拡 張 性 他 の ラ イ ブ ラ リ や フ レ ームワ ー ク と の 親 和 性 。 一 部 、 ラ イ ブ ラ リ を 変 え た と し た 時 の コ ス ト が 低 い か 将 来 性 メ ン テ ナ ンス さ れて い る か ＋ 今 後 も さ れ る か 。 技 術 が 古 く な い か 。 イ ン タ ー ネ ッ ト 上 で 話 題 に な って い る か 。 世 界 的 に 普 及 して い る か 学 習 コ ス ト 該 当 の 技 術 を 習 得 す る た め に 要 す る 時 間 ・ お 金 。 日 本 語 ド キ ュ メ ン ト ・ 難 易 度 な ど 信 頼 性 リ リ ース か ら ど れ ほ ど た って い る か 。 脆 弱 性 が な い か 。 利 用 実 績 レス ポ ンス 速 度 全 体 の サ イ ズ 。 レン ダ リ ン グ ・ ブ ラ ウ ザ の 動 作 レス ポ ンス  ISO/IEC9126（JIS X 0129-1）ソフトウェア品質特性と副特性 から抜粋 DMM.com ラボ マイクロサービスTIPS 15分 技術選定
42. 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. 43. 結果、Ruby + Go + AngularJS を採用しました。 DMM.com ラボ マイクロサービスTIPS 15分 技術選定 AngularJS {wrap} bootstrap Go Ruby + + RDOC JSON Hyper Schema
44. 44. 新たなプロジェクトへの参画 大規模で高負荷が予想される 新システムの設計に抜 されました!
45. 45. 新たなプロジェクトへの参画 大規模? 高負荷? 設計したことない… 一体何をすれば???
46. 46. 新たなプロジェクトへの参画 • DMM.comの重要サービスである  動画配信システムのリプレース • プレイヤーと動画を橋渡しするためのAPIと管理機能
47. 47. Streaming Servers Live Manager Master Controller Server Manager Player Manager PC ゲーム TV スマホ Job Handler 新たなプロジェクトへの参画
48. 48. 技術選定 ∼ 管理系システム 配信情報やサーバー設定をするためのAPI + 管理Portal • 負荷は少ないと予想される • 柔軟なシステムであることが求められる • サービスとのビジネスロジックは分離する • 変更に即座に対応する • ライブラリを活用して柔軟性を持たせる
49. 49. 技術選定 ∼ 管理系システム Ruby / Node.js / PHP7 などが候補にあがりましたが 今まではPHP中心でした。 しかし、あるメンバーの Railsやりたい! という 高いモチベーションにより…
50. 50. Ruby on Railsに決まりました!
51. 51. 技術選定 ∼ バックエンドAPI プレイヤーに再生情報を返すためのAPI • 高負荷が予想される • 堅牢なシステムである必要がある • ビジネスロジックは分離し、変更は少なくする • プラグインアーキテクチャで柔軟性を持たせる
52. 52. 技術選定 ∼ バックエンドAPI Java / Go / Erlang / Cなどが思いつきましたが、 いずれも業務で使ったコトがないのでよくわかりません。 (PHPやRubyでは無理そうです。。)
53. 53. 楽しい言語選定 【必須条件1】 容易に高負荷をさばけること（毎秒数千リクエスト以上） C D Erlang node.js Scala Elixir Go Java (vertex)
54. 54. 楽しい言語選定 【必須条件2】  開発・保守しやすいこと ○ Go ○ Java ☓ C ☓ D ☓ Erlang ☓ Elixir ? node.js ▲ Scala
55. 55. 楽しい言語選定 【条件3】 これから盛り上がりそうなこと
56. 56. 楽しい言語選定 Go言語がよさそう!
57. 57. 楽しい言語選定 さらに詳しく調べてみました。
58. 58. Go言語とは? • 2009年にGoogleが開発した言語 • 静的型付・コンパイル型 • ネットワークプログラミングに向いている • 標準ライブラリが充実 • Googleを始め国内でも採用実績多数 ※画像引用元 : https://github.com/golang-samples/gopher-vector
59. 59. Go言語とは? ∼その独自の文化∼ シンプルかつ厳格なルール • 標準のコードフォーマット • 標準のコーディングスタイル • ファイル名やメソッド名の命名規則による意味付け • コンパイル時Warningという考え方はない。 • 未使用変数や無駄なインポートは許さない
60. 60. Go言語とは? ∼その独自の文化∼ シンプルな文化を強いられますが ツールによるサポートがあります。
61. 61. gofmtが自動的にソースコードをフォーマットする。
 (エディタで保存するたびに自動実行させましょう) Before 1 package main 2 import ("fmt"); func main() { 3 fmt.Printf("hello, worldn")//print 4 } Go言語とは? ∼その独自の文化∼
62. 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. 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. 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言語とは? ∼その独自の文化∼
65. 65. golintがコーディング規約違反を指摘する。
 (コミット前に叩きましょう) Go言語とは? ∼その独自の文化∼
66. 66. 楽しい言語選定 実行ツール類もシンプルです!
67. 67. go get が依存ライブラリをダウンロードする go get と打つだけ! 設定ファイル不要! Go言語とは? ∼その独自の文化∼
68. 68. go build がプログラムをビルドする。 go build と打つだけ! Makefileファイル不要! Go言語とは? ∼その独自の文化∼
69. 69. go run がプログラムをすぐに実行する。 go run main.goと打つだけ! Go言語とは? ∼その独自の文化∼
70. 70. go test がプログラムをテストする。 go test パッケージ名/.. と打つだけ! Go言語とは? ∼その独自の文化∼
71. 71. go rename がソースをリファクタリングする。 gorename -from ‘変更前’ -to ‘変更後’ と打つだけ! Go言語とは? ∼その独自の文化∼
72. 72. 楽しい言語選定 良さそうです。 ではなぜGoが良いのか? まとめましょう。
73. 73. なぜGo言語なのか? PHPやRubyと逆の発想 - メリット • 実行速度が速い • 環境構築がものすごく楽!! • バージョン依存の問題が少ない! • バグになりそうなコードは除外される • アセンブリにコンパイルすることができる
74. 74. なぜGo言語なのか? PHPやRubyと逆の発想 - デメリット • JSONなどの動的データの扱いは不向き • 戻り値によるエラーチェックが必須で冗長になりがち • ライブラリやノウハウが少ない • デバッガやロガー周りが充実していない
75. 75. なぜGo言語なのか? 最終的な決定要素 • ハイパフォーマンスであること • システムコールまで追えること • 実用環境で十分な採用実績があること • 学習が容易で保守しやすいこと • ノウハウが資産になること • 今後もビジネスニーズがあること
76. 76. Ruby vs Go! イメージ的な違い Ruby Go 富豪的プログラミング 動的スクリプト おもてなし オブジェクト指向 メソッドチェーン 豊富なライブラリ 大変なバージョン依存 環境構築でハマる シンプルさを追求 静的コンパイル 郷に入っては郷に従え 並行プログラミング C言語的 必要十分な標準ライブラリ 徹底した後方互換性 バイナリ一つ置くだけ
77. 77. Ruby vs Go! フレームワーク Go Rails or Sinatra フレームワークのルールに従う フレームワークとgemで賄う 言語仕様のルールに従う いろいろ
 (revel, gorilla, goji, gin, gizmo, gocraft, go kit…) 必要なものを組み立てる Ruby
78. 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. 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. 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 }
81. 81. Ruby vs Go! 心配事 GoRuby バージョンアップについていけ るか? もっとベストプラクティスがあ るのでは? (疑心暗鬼)
82. 82. Ruby vs Go! 言語に対する批判 Go 自由すぎるシンタックス 黒魔術メタプログラミング 突如襲い掛かる のエラー 言語として退化している ツール類はよく変わる デフォルト引数がない Ruby const引数がない Classがない 継承がない オーバーロードがない 三項演算子がない
83. 83. そんな異なる二つの言語ですが 一つだけ共通点が…
84. 84. 開発していて楽しい!
85. 85. Goを活かしたアーキテクチャ KVSとしてAerospikeを採用 • JSONオブジェクトをmsgpackして利用 • 1ms程度の低レイテンシーを実現 • クラスタリングの運用が非常に楽 • Go言語用の公式ライブラリあり
86. 86. Goのツボ ∼ configリロード configファイルの扱い 設定はconfigファイルにしておいて読み込みたい しかしファイルをリクエストごとに読み込むのは コストが高い。 Go言語は並行プログラミングに向いている
 そこでLinuxシグナルを利用したhot reloadを実装した。 参考 : http://openmymind.net/Golang-Hot-Configuration-Reload/
87. 87. Goのツボ ∼ configリロード config hotリロードの手順 1. 初期化時にconfigを読み込み失敗したらプロセスを終了 2. シグナルを待ち受けるgoroutineを作成 3. シグナルが来たらロックをかけてconfigをリロード 4. 読み込みに失敗したら元のデータをそのまま使う
88. 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. 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ファイル読み込み ←環境ごとに切り替え ←動作確認 ←初期化時エラーなら終了 ←リロード時エラーなら無視 ←ロックして更新
90. 90. Goのツボ ∼ 悪魔のデーモン化 悪魔のデーモン化 Goは公式にはfork()できない。 そのためデーモン化は完全にはできない。 今回はfacebookgo/graceを使ってgracefulがしたい。 しかし、PIDが変わってしまいSupervisordが使えない! ベストプラクティスを探し求めて長い旅へ…
91. 91. Goのツボ ∼ 環境変数 環境変数の変え方 コンパイル時にタグを使う。 タグを使うとコンパイルするファイルを選択できる。 ファイルをわけておくと定数の定義を変えられる。 …しかし、実行コストが気になりませんか?
92. 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 } ←このコードは消えて欲しい
93. 93. Goのツボ ∼ 環境変数 最適化されました!(但し関数呼び出しは残ります。) 
94. 94. 素敵な開発フローお見せします
95. 95. 素敵な開発フロー APIの開発方法はさまざまですが… • API仕様書を先に書く? • テストを先に書く? • モックアップサービスを使う?
96. 96. 素敵な開発フロー LL系の開発などでこんな経験ありませんか? 1. APIのパラメータ名が変更になりました。 2. ドキュメントを修正します。 3. バリデーションファイルも忘れずに修正します。 4. プログラムのリクエストやレスポンスの整形部分も変え ます。 5. ロジックも変更しました。(が一部修正し忘れました) 6. テストが通りました。 7. いざ本番にデプロイすると、 Undefinedエラーが発生!
97. 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. 98. 素敵な開発フロー メタデータ API1.yml API2.yml API3.yml 開発者 API定義 手動管理 編集 パラメーター・レスポンス 構造体定義 バリデーション定義 API1 ハンドリング処理 API3 ハンドリング処理 API4 ハンドリング処理 API仕様書 API定義 ファイル API1 ロジック API2 ロジック API3 ロジック GOソース GOソース 手動管理 自動生成 パッチによる 自動変換 自動生成PRMDX により結合 JSON Hyper Achemaによる開発フロー
99. 99. 素敵な開発フロー メリット • ロジックファイルの分離でバシバシ定義を修正できる • 構造体の生成と静的チェックでしっかり修正漏れを防げる 工夫したところ • バリデーションはAPI定義をJSON化しconfigと共にリロードできる!
100. 100. JSON Hyper Schemaって素敵! お見せします! (WebAPIパラメータ名の変更) 1. API定義を修正 2. ツールを実行 3. ロジックを修正 4. コンパイルして修正漏れがないかチェック 5. 完成!
101. 101. 詳しくは3月3日(木)の勉強会で!
102. 102. 新しいプロジェクトが 続々と進行中!
103. 103. よりよいプロダクトを目指して。 さらなる開発効率を求めて。
104. 104. 貴方の「やりたい!」をDMMで!!
105. 105. ご静聴ありがとうございました。