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.

MicroServices & APIs

3,916 views

Published on

Cloud Next 2018 わいわい報告会の登壇資料

Published in: Software
  • Be the first to comment

MicroServices & APIs

  1. 1. Cloud Next 2018 MicroServices & APIs
  2. 2. 自己紹介 twitter pospome 読み方 ポスポメ 職種 サーバサイドエンジニア 興味 クラス設計全般, DDD   いわゆるアプリケーションアーキテクチャ ここら辺の技術に興味ある方は   フォローしてくださると嬉しいです
  3. 3. 今回は 実際に開発で役立ちそうな内容を中心に紹介 GCP成分は比較的少ない
  4. 4. 今回は以下の2つのセッションを取り上げる Microservices - Born and Raised (and Growing) on Gooble Cloud Designing Quality APIs
  5. 5. Microservices - Born and Raised (and Growing) on Gooble Cloud
  6. 6. 概要 Pizza Hut のマイクロサービス事例
  7. 7. Core Architecture ・Go ・Kubernetes ・GCP
  8. 8. Pizza Hut が考えるマイクロサービスの原則 ・サービス間の依存が少ない ・CI/CDを利用した自動デプロイ ・サービスディスカバリを利用したサービス間通信
  9. 9. Pizza Hut が考えるマイクロサービスの原則 ・サービス間の依存が少ない ・CI/CDを利用した自動デプロイ ・サービスディスカバリを利用したサービス間通信 ↑ マイクロサービスの目的を達成するために必須な原則
  10. 10. Pizza Hut が考えるマイクロサービスの原則 ・サービス間の依存が少ない ・CI/CDを利用した自動デプロイ ・サービスディスカバリを利用したサービス間通信 ↑ マイクロサービスのサービス境界がとても大事
  11. 11. Pizza Hut が考えるサービス境界の原則 ・可能な限り小さい、意味を持つ業務機能を提供する ・データと業務機能をカプセル化し、提供する
  12. 12. サービスがそれ単体で業務上の意味を持つ 最小のサービスにすべき
  13. 13. 通信 ・REST   多くの利用者をサポートすることができる   OpenAPI による通信規約が存在する ・gPRC   利用者によってはサポートが難しい   仕様して規約が存在する   
  14. 14. Pizza Hut では使い分けている REST … 外部通信 gRPC … 内部通信(サービス間通信)
  15. 15. API管理の課題 ・API Key, JWT などのセキュリティ ・使い方とパフォーマンスの可視化 ・OpenAPI への統合
  16. 16. Cloud Endpoints ・柔軟なセキュリティオプション ・CloudConsole 内のリッチなダッシュボード ・OpenAPI仕様に沿ってエンドポイントを提供できる
  17. 17. ESP によって REST API へのリクエストを Rest Server Container にプロキシする。 Rest Server Container はリクエストを gRPC に変換する。
  18. 18. 外部提供する gRPC のエンドポイントを Rest Server Container 経由で RestAPI として外部に提供できる
  19. 19. gRPC ↔ REST の変換は CloudEndpoints や gRPC- Gateway を利用せずに手作業でやっている。 ボイラーテンプレート気味なので改善していく予定。
  20. 20. UseCase: Store Location Service ・Cloud Datastore を採用 ・速い ・スケールする ・マルチリージョンによる高い可用性
  21. 21. Datastore に既存データをインポートする必要がある
  22. 22. インポートジョブを実行するコンテナを立てて対応
  23. 23. Kubernetes にも高い可用性をもたせたい ・Cloud Load Balancing(Ingress) ・マルチリージョンによる高い可用性 ・地理的に近いクラスターの提供 ・動かないサービスを自動的に除外
  24. 24. 既存の GEK の Service = LoadBalancer は そのまま残している トラフィックが残っている & テストで利用するため
  25. 25. Stackdriver が便利 ・分散システムでもリクエストトレーシングが可能 ・あらゆるメトリクスが取れる ・どこで何が起こっているのかを把握できる
  26. 26. Designing Quality APIs
  27. 27. 概要 API設計の Tips
  28. 28. APIが直面する問題 ・変更の難しさ  既存のレガシーなソフトウェアは複雑である  変更は困難である ・統合の難しさ  それぞれのAPIが独自の仕様を持つ  それらを統合して特定の目的を達成するのは難しい
  29. 29. 解決方法 ・アプリケーションをまたがって統一されたAPI ・統一されたモデルの関係性 ・free of implementation assumptions  実装仮定からの開放(?)  
  30. 30. これらを実現できれば 問題を解決することができる どのように実現する?
  31. 31. APIのスタイル ・Entity Oriented  いわゆるリソース指向な REST API  APIはエンティティを持ち、  それに対する CRUD 操作を提供する
  32. 32. ・DBのスキーマを学ぶのに似ている ・扱うEntityは違えど、APIに統一感がある
  33. 33. APIのスタイル ・Procedure Oriented  いわゆる RPC  APIは特定の操作を提供し、  クライアントはその操作を呼び出す
  34. 34. ・プログラミングのライブラリを学ぶのに似ている ・REST ほどAPIに統一感がある保証はない
  35. 35. 解決方法 ・アプリケーションをまたがって統一されたAPI ・統一されたモデルの関係性 ・free of implementation assumptions  実装仮定からの開放(?) ↑ Entity Oriented な API が適している  
  36. 36. Entity Oriented な API の問題 HTTP がベースなので、 HTTP Method による直感的な操作が可能である。 一方で “クエリ”, “バージョン” に関しては定義されてい ない。
  37. 37. クエリにおける失敗例と解決案
  38. 38. 例1 リソースの id = 12345 ということはわかるが、 どのように取得するのかは分からない。
  39. 39. 解決案 リソースの id にパスを含めることによって、 “どのように取得するのか?” を伝えることができる
  40. 40. 例2 ownerID は id = 12345 のリソースに対する親リソース である。 しかし、どのように owner リソースを取得するのかが分 からない
  41. 41. 解決案 ownerID ではなく、owner リソースに対する URL を指 定することによって解決できる。
  42. 42. 懸念 id のみ保存する場合はパスやURLをパースして取 得することになるのかな?
  43. 43. バージョン
  44. 44. バージョンの種類 1. Entity Versioning   エンティティのデータ構造が変わる   新エンティティ、旧エンティティが存在する 2. Format Versioning   フィールド名のリネーム   レスポンス構造の変更   エンティティ自体は1種類しかない 3. Historical Versioning   Entity Version, FormatVersion を統合したバージョン   特定バージョンへの undo, redo に利用することができる   *解釈が間違っているかもしれません
  45. 45. Format Version における失敗例と解決案
  46. 46. 例 id, owner のパスにバージョンを含めてしまう。
  47. 47. 例 レスポンスを受け取るクライアントが v1 を利用すると は限らない。 owner のみ v2 を利用したいかもしれない。
  48. 48. 例 owner には v2 が存在するが、 id のリソースには v2 が存在しないかもしれない。
  49. 49. 解決案???? かといって、バージョンを取り除いてしまうと情報が失 われてしまう。
  50. 50. 解決案 レスポンスリソースのバージョンのみ含める。 HTTP Header に含めた方が良いが、 プロパティに含めても問題はない。
  51. 51. 解決案 ・version-free な URI を用意する。 ・HTTP Header に “Accept-Version” を指定可能にす る。 ・オプションとして URL 内に version を含められるよ うにする。
  52. 52. gPRC vs REST ・gRPC  スループットが高い  コードを自動生成できるので楽  結合度の高いコンポーネント同士で利用する ・REST  将来的な変更に適用しやすい  システム統合に強い  顧客に提供するのであれば REST にすべき
  53. 53. おわり

×