Server-to-Server のコミュニケーションプロトコルと技術的結合度

2023-10-31 吉祥寺.pm34

Introduction

自己紹介
- qsona
- SHE株式会社 (2023-07 ~)
  
  【SHE Engineer PdM Interview #6】決め手は"SHEの目指す世界への共感" エンジニアリングの力で未知の領域に挑む。｜SHE
- ex. スタディサプリ
今回のテーマ: 「コミュニケーションとプロトコル」
今日の話
- Server-to-Server のコミュニケーションプロトコルと技術的結合度
余談: 登壇という形式のコミュニケーションとプロトコルについて

 https://twitter.com/ohbarye/status/1718432963648778676
- 技術系の発表のときに、「プレゼンテーション資料」を使うプロトコルが適切なのかはいまだによくわかっていない
  - 特にオンラインでの発表
- 一方で、「箇条書き」というプロトコルは好き
  - 通常の文書よりも、発表を聞いている最中も見ていて認識しやすいし、何なら登壇関係なく単なる資料としてもわかりやすい説
    - 日本においては、登壇が終わった後のプレゼン資料がSNSなどで拡散されることがよくあるが、要因の一つはこれだと思う
  - https://scrapbox.io/shokai/箇条書き
- というわけで、試しに今日はこんなスタイルでやってみます

Server-to-Server API Protocol の話

複数のサービスを連携 (統合) させるために、API を利用する
RPC (gRPC, Thrift, …), REST, …?
プロトコルは何のために必要か
- プロトコルが規定・標準化されていることで、コミュニケーションに参加しやすくなる
プロトコルと技術の結合度
- マイクロサービスアーキテクチャ(第2版)より
- ある技術選択をした結果、その技術選択がどんなものと結合して、将来的に問題になりうるのか、という洞察をすることが重要
最近よくみるアンチパターン: 技術異質性を失うプロトコル選択
- 完全に失うわけではなくても、ちょっと制約がかかったりする
- ありていに言ってしまえば… JSON (XML) over HTTP 以外のプロトコルを、あまり深く考えずに採用しがちだと思う
JSON (XML) over HTTP 以外のプロトコルの例
- これらを選択することそのものがアンチパターンではない (当然)
  - が、特定の技術に強く結合していないか? という観点をもったほうがよい
  - 結合する何かがある場合、そのデメリットと、得たいメリットを天秤にかける
- gRPC (+ Protocol Buffers)
- twirp https://github.com/twitchtv/twirp
- tRPC
- (もうちょっと広義に言えば) Cloud Firestore (firebase のデータストア) を利用した開発
再掲: ある技術選択をした結果、その技術選択がどんなものと結合して、将来的に問題になりうるのか、という洞察をすることが重要

Server-to-Server GraphQL API

SHE では GraphQL を活用しています
- Server-to-Server でも利用している

SHEとGraphQL：プランニングからリリースまで

Server-to-Server で GraphQL を利用する理由
- 4年前に発表したときから、あまり考えは変わっていない
GraphQL for service-to-service communication protocol
- メリット
  - 信頼できる API ドキュメントが常に存在する
    - ドキュメントと実装が乖離することが起き得ない
  - 自分が必要なデータだけを、選択して取得できる
    - パフォーマンス観点 … Server-to-Server の場合、パフォーマンス観点でのうまみはそこまで大きくないが、依然として存在する
    - 実装観点 … REST API の場合、1つのエンドポイントで様々な欲求に同時に対応しようとすると、いわゆるネ申 API になり、運用が難しくなる
  - GraphQL Gateway を簡単に作ることができる
  実質無料で GraphQL Gateway を手に入れる / low-cost GraphQL Gateway
  - 「契約」の概念を持ち込むことができる ⇒ Provider 側のサービスの発展がしやすい
    - Trusted Documents (もともと Persisted Queries と呼ばれていたもの)
    GraphQL Trusted Documents
    - Provider は、このクエリ群に適切に対応しつづけられればよく、互換性を保つべき部分が明確である
- デメリット?
  - モニタリング難しい?
    - Trusted Documents の利用
    - APM との適切なインテグレーション (あれば)
      - 例 (graphql-ruby と New Relic の integration) https://graphql-ruby.org/queries/tracing#new-relic
  - N+1 問題が発生しやすい?
本題: Server-to-Server で GraphQL を利用すると、どんな技術的結合度が高まるのか?
- あまり結合しないところ
  - プログラミング言語の種類
    - メジャーどころは網羅されている
  - クライアント (ライブラリ選択など)
    - ほぼ RESTful API を叩くのと同じようなものと考えてよく、特別なライブラリは必ずしも必要ない
      - GraphQL のクエリは手で書いて定義する
      - あとは普通に HTTP リクエストを送るだけ
    - 静的型付け言語の場合、クエリから型を生成すると非常に捗る
- では、何と結合するのだろうか…? (以下、フリートーク)
  - 個人的に思っている2つの結合
    - API の設計思想と、サーバーサイドの実装
      
      GraphQL で変わったこと・変わらなかったこと / graphql changing and unchanging
      
      RESTful API との比較で GraphQL API を作ることの難しさ｜qsona
      - use-case ベースの設計はほぼ不可能、という話
    - GraphQL に関するスキル習得が必須
      - 例えば gRPC だったら、gRPC のことをよくわかっていなくても API の実装や利用はできると思う
      - GraphQL は、多分 GraphQL を理解していないと API もクライアントも絶対に実装できない

Introduction

余談: 登壇という形式のコミュニケーションとプロトコルについて

Server-to-Server API Protocol の話

Server-to-Server GraphQL API

N+1 問題が発生しやすい?

最後に一句