（再アップロード）Microservices & APIs

Slide 1

Slide 1 text

Cloud Next 2018 MicroServices & APIs

Slide 2

Slide 2 text

自己紹介 twitter pospome 読み方ポスポメ職種サーバサイドエンジニア興味クラス設計全般, DDD 　いわゆるアプリケーションアーキテクチャここら辺の技術に興味ある方は　フォローしてくださると嬉しいです

Slide 3

Slide 3 text

今回は実際に開発で役立ちそうな内容を中心に紹介 GCP成分は比較的少ない

Slide 4

Slide 4 text

今回は以下の2つのセッションを取り上げる Microservices - Born and Raised (and Growing) on Gooble Cloud Designing Quality APIs

Slide 5

Slide 5 text

Microservices - Born and Raised (and Growing) on Gooble Cloud

Slide 6

Slide 6 text

概要 Pizza Hut のマイクロサービス事例

Slide 7

Slide 7 text

Core Architecture ・Go ・Kubernetes ・GCP

Slide 8

Slide 8 text

Pizza Hut が考えるマイクロサービスの原則・サービス間の依存が少ない・CI/CDを利用した自動デプロイ・サービスディスカバリを利用したサービス間通信

Slide 9

Slide 9 text

Pizza Hut が考えるマイクロサービスの原則・サービス間の依存が少ない・CI/CDを利用した自動デプロイ・サービスディスカバリを利用したサービス間通信 ↑ マイクロサービスの目的を達成するために必須な原則

Slide 10

Slide 10 text

Pizza Hut が考えるマイクロサービスの原則・サービス間の依存が少ない・CI/CDを利用した自動デプロイ・サービスディスカバリを利用したサービス間通信 ↑ マイクロサービスのサービス境界がとても大事

Slide 11

Slide 11 text

Pizza Hut が考えるサービス境界の原則・可能な限り小さい、意味を持つ業務機能を提供する・データと業務機能をカプセル化し、提供する

Slide 12

Slide 12 text

サービスがそれ単体で業務上の意味を持つ最小のサービスにすべき

Slide 13

Slide 13 text

通信・REST 　　多くの利用者をサポートすることができる　　OpenAPI による通信規約が存在する・gPRC 　　利用者によってはサポートが難しい　　仕様して規約が存在する　　

Slide 14

Slide 14 text

Pizza Hut では使い分けている REST … 外部通信 gRPC … 内部通信（サービス間通信）

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

API管理の課題・API Key, JWT などのセキュリティ・使い方とパフォーマンスの可視化・OpenAPI への統合

Slide 17

Slide 17 text

Cloud Endpoints ・柔軟なセキュリティオプション・CloudConsole 内のリッチなダッシュボード・OpenAPI仕様に沿ってエンドポイントを提供できる

Slide 18

Slide 18 text

ESP によって REST API へのリクエストを Rest Server Container にプロキシする。 Rest Server Container はリクエストを gRPC に変換する。

Slide 19

Slide 19 text

外部提供する gRPC のエンドポイントを Rest Server Container 経由で RestAPI として外部に提供できる

Slide 20

Slide 20 text

gRPC ↔ REST の変換は CloudEndpoints や gRPC- Gateway を利用せずに手作業でやっている。ボイラーテンプレート気味なので改善していく予定。

Slide 21

Slide 21 text

UseCase: Store Location Service ・Cloud Datastore を採用・速い・スケールする・マルチリージョンによる高い可用性

Slide 22

Slide 22 text

Datastore に既存データをインポートする必要がある

Slide 23

Slide 23 text

インポートジョブを実行するコンテナを立てて対応

Slide 24

Slide 24 text

Kubernetes にも高い可用性をもたせたい・Cloud Load Balancing（Ingress）・マルチリージョンによる高い可用性・地理的に近いクラスターの提供・動かないサービスを自動的に除外

Slide 25

Slide 25 text

既存の GEK の Service = LoadBalancer はそのまま残しているトラフィックが残っている & テストで利用するため

Slide 26

Slide 26 text

Stackdriver が便利・分散システムでもリクエストトレーシングが可能・あらゆるメトリクスが取れる・どこで何が起こっているのかを把握できる

Slide 27

Slide 27 text

Designing Quality APIs

Slide 28

Slide 28 text

概要 API設計の Tips

Slide 29

Slide 29 text

APIが直面する問題・変更の難しさ　既存のレガシーなソフトウェアは複雑である　変更は困難である・統合の難しさ　それぞれのAPIが独自の仕様を持つ　それらを統合して特定の目的を達成するのは難しい

Slide 30

Slide 30 text

解決方法・アプリケーションをまたがって統一されたAPI ・統一されたモデルの関係性・free of implementation assumptions 　実装仮定からの開放(?) 　

Slide 31

Slide 31 text

これらを実現できれば問題を解決することができるどのように実現する?

Slide 32

Slide 32 text

APIのスタイル・Entity Oriented 　いわゆるリソース指向な REST API 　APIはエンティティを持ち、　それに対する CRUD 操作を提供する

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

・DBのスキーマを学ぶのに似ている・扱うEntityは違えど、APIに統一感がある

Slide 35

Slide 35 text

APIのスタイル・Procedure Oriented 　いわゆる RPC 　APIは特定の操作を提供し、　クライアントはその操作を呼び出す

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

・プログラミングのライブラリを学ぶのに似ている・REST ほどAPIに統一感がある保証はない

Slide 38

Slide 38 text

解決方法・アプリケーションをまたがって統一されたAPI ・統一されたモデルの関係性・free of implementation assumptions 　実装仮定からの開放(?) ↑ Entity Oriented な API が適している　

Slide 39

Slide 39 text

Entity Oriented な API の問題 HTTP がベースなので、 HTTP Method による直感的な操作が可能である。一方で “クエリ”, “バージョン” に関しては定義されていない。

Slide 40

Slide 40 text

クエリにおける失敗例と解決案

Slide 41

Slide 41 text

例1 リソースの id = 12345 ということはわかるが、どのように取得するのかは分からない。

Slide 42

Slide 42 text

解決案リソースの id にパスを含めることによって、 “どのように取得するのか?” を伝えることができる

Slide 43

Slide 43 text

例2 ownerID は id = 12345 のリソースに対する親リソースである。しかし、どのように owner リソースを取得するのかが分からない

Slide 44

Slide 44 text

解決案 ownerID ではなく、owner リソースに対する URL を指定することによって解決できる。

Slide 45

Slide 45 text

懸念 id のみ保存する場合はパスやURLをパースして取得することになるのかな?

Slide 46

Slide 46 text

バージョン

Slide 47

Slide 47 text

バージョンの種類 1. Entity Versioning 　　エンティティのデータ構造が変わる　　新エンティティ、旧エンティティが存在する 2. Format Versioning 　　フィールド名のリネーム　　レスポンス構造の変更　　エンティティ自体は1種類しかない 3. Historical Versioning 　　Entity Version, FormatVersion を統合したバージョン　　特定バージョンへの undo, redo に利用することができる　　＊解釈が間違っているかもしれません

Slide 48

Slide 48 text

Format Version における失敗例と解決案

Slide 49

Slide 49 text

例 id, owner のパスにバージョンを含めてしまう。

Slide 50

Slide 50 text

例レスポンスを受け取るクライアントが v1 を利用するとは限らない。 owner のみ v2 を利用したいかもしれない。

Slide 51

Slide 51 text

例 owner には v2 が存在するが、 id のリソースには v2 が存在しないかもしれない。

Slide 52

Slide 52 text

解決案???? かといって、バージョンを取り除いてしまうと情報が失われてしまう。

Slide 53

Slide 53 text

解決案レスポンスリソースのバージョンのみ含める。 HTTP Header に含めた方が良いが、プロパティに含めても問題はない。

Slide 54

Slide 54 text

解決案・version-free な URI を用意する。・HTTP Header に “Accept-Version” を指定可能にする。・オプションとして URL 内に version を含められるようにする。

Slide 55

Slide 55 text

gPRC vs REST ・gRPC 　スループットが高い　コードを自動生成できるので楽　結合度の高いコンポーネント同士で利用する・REST 　将来的な変更に適用しやすい　システム統合に強い　顧客に提供するのであれば REST にすべき

Slide 56

Slide 56 text

おわり