Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PHPerだってMicroservicesしたい!

9,895 views

Published on

at phpconf Tokyo 2016

Published in: Technology
  • Be the first to comment

PHPerだってMicroservicesしたい!

  1. 1. PHPerだって Microservices したい 2016.11.03@phpcon iret株式会社 cloudpack事業部 高橋 慎一
  2. 2. 時の流れは ―早い―
  3. 3. 2014年 ぼく
  4. 4. 2014年ぼく SPA?Vue.js? RESTful? AngularJS? ReactJS?API?
  5. 5. 2014年ぼく SPA?Vue.js? RESTful? AngularJS? ReactJS?API? なにそれ?
  6. 6. 2015年 ぼく
  7. 7. 2015年ぼく GCP?Lambda? GAE?AWS? Serverless? MicroServices?
  8. 8. 2015年ぼく GCP?Lambda? GAE?AWS? Serverless? MicroServices? なにそれ?
  9. 9. 2016年 ぼく
  10. 10. 2016年ぼく 2年かけて 時代を 理解した
  11. 11. 2016年ぼく なるほど WebAPIを叩いて フロント側で レンダーすれば いいのか
  12. 12. 2016年ぼく サーバがHTMLを 返す時代は ―終わった―
  13. 13. そんなある日
  14. 14. ある日のやり取り CTO < devicepackってのつくって . . . .
  15. 15. ある日のやり取り CTO < devicepackってのつくって なんすかそれ? > ぼく . . .
  16. 16. ある日のやり取り CTO < devicepackってのつくって なんすかそれ? > ぼく CTO < (サービス説明) . .
  17. 17. ある日のやり取り CTO < devicepackってのつくって なんすかそれ? > ぼく CTO < (サービス説明) コレ使えとかアレ使えとかあります? > ぼく .
  18. 18. ある日のやり取り CTO < devicepackってのつくって なんすかそれ? > ぼく CTO < (サービス説明) コレ使えとかアレ使えとかあります? > ぼく CTO < ない。好き勝手やっていいよ
  19. 19. 好き勝手 やっていいよ
  20. 20. つーわけで ってーのを つくりました
  21. 21. やること ☁devicepackってーのをつくる ☁納期は2ヶ月後 ☁開発担当:1人 / デザイナ:1人 / マークアップ:1人 ☁実装については自由 ☁PM:ぼく
  22. 22. 2014年 ぼくの設計
  23. 23. アーキテクチャ ver.2014 認証・認可 API通信 ビジネスモデル データストア Webサーバ リクエスト
  24. 24. 2016年 ぼくの設計
  25. 25. アーキテクチャ ver.2016 API通信 認証認可 API通信 ビジネスモデル データストア APIサーバ 認証サーバ Webサーバ リクエスト
  26. 26. アーキテクチャ ver.2016 API通信 認証認可 API通信 ビジネスモデル データストア APIサーバ 認証サーバ Webサーバ
  27. 27. 今日はなすこと(前半) API通信 認証認可 API通信 ビジネスモデル データストア APIサーバ 認証サーバ Webサーバ
  28. 28. 今日はなすこと(前半) ☁マイクロサービスのお話 – マイクロサービスってなに? – なにがうれしいの? – なにがかなしいの?
  29. 29. 今日はなすこと(後半) API通信 認証認可 API通信 ビジネスモデル データストア APIサーバ 認証サーバ Webサーバ
  30. 30. 今日はなすこと(後半) ☁技術選定のお話 – なぜLumenを選んだのか – なぜVue.jsを選んだのか
  31. 31. 各サービスの役割 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層
  32. 32. Microservices … ? ☁モノリシック(All in One)ではない ☁責務が単一な小さなサービス構成 ☁単位はドメインでもサービスでもリソースでもい い(と思ってる)
  33. 33. Microservices実現のためには? ☁サービス単位で構成をぶつぎりにする ☁I/Oの規約を決めておく – 利用する側からはサービスの中身に関心がない ☁サービス毎で影響範囲を閉じておく – 外部サービスに影響のある副作用を作らない
  34. 34. なにがうれしいか ☁サービスが疎結合 ☁部分変更に強い ☁スケーラビリティが高い
  35. 35. なにがうれしいか ☁サービスが疎結合 ☁部分変更に強い ☁スケーラビリティが高い
  36. 36. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層
  37. 37. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層 DynamoDBやだやだ>< RDSがいいもん><;
  38. 38. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層 DynamoDBやだやだ>< RDSがいいもん><; AWS < API変えたから Ver.upよろwww
  39. 39. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層 フロント層までの I/Oに影響がないよう 変更を加えればよい
  40. 40. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層 やってることは 認証・認可と API通信のみ
  41. 41. いともたやすく行われるえげつない仕様変更 ユーザ認証基盤データストア エントリーポイント サービス層 フロントエンドドメイン層 この層の変更のみで フロントから見た際の 動作を担保することが 可能に!
  42. 42. 後半戦に行く前に ちょっと水を飲みます
  43. 43. 今日はなすこと(後半) ☁技術選定のお話 – なぜLumenを選んだのか – なぜVue.jsを選んだのか
  44. 44. Lumen
  45. 45. Lumen The stunningly fast micro-framework by Laravel.
  46. 46. なぜLumenを選んだか ☁LaravelほどFatなものは不必要 – APIサーバとしてルーティングさえできればなんでもよかった ☁Symfony/Silex飽きた – 開発者なのに営業かけられたプロダクツで死ぬほどやった ☁流行ってる – 情報量が多い / 流行っている理由があるはず
  47. 47. なぜLumenを選んだか ☁LaravelほどFatなものは不必要 – APIサーバとしてルーティングさえできればなんでもよかった ☁Symfony/Silex飽きた – 開発者なのに営業かけられたプロダクツで死ぬほどやった ☁流行ってる – 情報量が多い / 流行っている理由があるはず 必要十分こそが正義! モチベ大事! 前ならえしてみる!
  48. 48. なぜLumenを選んだか ☁ARNとRoutingの相性がいい ☁Middlewareで認可 ☁AWS SDK で Device Farm と通信
  49. 49. ルーティング $app->group(['prefix' => 'project'], function () use ($app) { $app->get('/', ProjectController::class . '@all'); $app->get('/{project}', ProjectController::class . '@get'); $app->put('/', ProjectController::class . '@create'); $app->post('/{project}', ProjectController::class . '@update'); $app->delete('/{project}', ProjectController::class . '@delete'); });
  50. 50. if (!$request->headers->has($this->token)) { return response('Bad request.', 400, $headers); } try { if ($this->auth()) { $params = $next($request); if ($params->getStatusCode() >= 400) { throw new ¥Exception('It could not be processed.'); } $response = response()->json($params, 200, $headers); } else { $response = response()->json(['Unauthorized.'], 401, $headers); } } catch (Exception $e) { $response = response(‘[API ERROR]’ . $e->getCode(), $headers); } 認可
  51. 51. コントローラ public function get(Request $request, $project) { return $this->deviceFarmClient->getProject([ 'arn' => $project, ])->toArray(); }
  52. 52. Vue.js
  53. 53. Vue.js モダンなWebインター フェース向けのリアク ティブコンポーネント
  54. 54. なぜVue.jsを選んだか ☁スモールスタート – 学習コストが低く、はじめやすい ☁エコシステムが発達 – Router(vue-router) / API通信(vue-resource) – 公式サンプルも豊富 ☁シンプル – 周辺分野の知識が乏しくても戦える
  55. 55. なぜVue.jsを選んだか まず「やる」ことで 感覚つかみやすい! 必要なときにちょっと ずつ覚えていける! やりたいことだけ できる! ☁スモールスタート – 学習コストが低く、はじめやすい ☁エコシステムが発達 – Router(vue-router) / API通信(vue-resource) – 公式サンプルも豊富 ☁シンプル – 周辺分野の知識が乏しくても戦える
  56. 56. まとめ
  57. 57. Vue.js + Lumen ☁短期間(2ヶ月)で作るには最高の組み合わせ – やりたいことを覚えていくだけで出来上がった感覚 ☁モダンな感じに作ることができた – 特にLumen内部のMiddlewareには助けられた ☁わかりやすい形でMicroservicesをスタートできた – やりとり with 規約
  58. 58. モダンっぽい実装やってみて ☁Interfaceが決まってる <- 大事 –いつかくるver.upに耐えうる ☁I/O(JSON)だけ見てりゃいいからテスト楽ちん –ぶっちゃけSeleniumとかのテストしたくない ☁わからないことだらけで毎日疑問と格闘 –セキュリティどうする?テストどうする?
  59. 59. Microservicesでつくった感想 ☁Microservicesは前からあった(SOA的な) –既存概念に新しい名前がついた ☁単一サービスだとまだ早かった? –開発をすすめるにあたっては有用 ☁結構便利な言葉 –おっ!モダンなワードやん!って思われる(経験則)
  60. 60. 誰だったの? ☁高橋 慎一 – GitHub@shinichi-takahashi – Twitter@takapyyy ☁ iret株式会社 cloudpack事業部
  61. 61. 誰だったの?
  62. 62. 一緒に おもろいことを したい人を 募集しています! @東京 / @大阪 / @名古屋
  63. 63. ご清聴 ありがとう ございました

×