PythonでgRPC入門 ~web chatを実装してみるハンズオン~ Yoshikatsu Nishida 2022.01.22

プロローグ - 本日話すこと、話さないこと -

プロローグ -本日話すこと、話さないこと - 「gRPC何もわからん...」状態の人が、「gRPCチョットワカル」ようになる！ 　❌ 厳密な定義説明 　❌microservices VS monorepo 　❌本番環境でのgRPCの運用方針

アジェンダ 1. プロローグ 2. 従来のREST APIの世界 3. gRPC入門 4. gRPC ✖ pythonでweb chatを実装してみるハンズ オン

自己紹介 nishida / Yoshikatsu Nishida ・起業準備中の学生エンジニア（B4） ・3E株式会社 R&Dユニット/インターン ・Code for Yamaguchi創設者, CivicTechForum 2021登壇, 山口県コロナサイト立ち上げ ・NHK高専ロボコンOB ・全日本珠算技能競技大会（そろばん）元島根県代表 ・Next.js, Nest.js, React Native, Firebase, GCP, RoR, Python ・趣味はゲーム（スマブラSP）、旅行 @nsd244 nishidayoshikatsu

従来のREST APIの世界 ・REST APIとは ・REST APIで開発者達が享受したもの ・REST APIで開発者達が抱えている課題 ・REST API開発における便利ツール

REST APIとは REST API（RESTful API）は、基本的に「RESTの原則」に従って設計されている APIのこと ・アドレス可能性: すべての情報が一意な URIで表現されるようにすること ・ステートレス性: すべてのHTTPリクエストが完全に分離している性質であること ・接続性: ある情報に「別の情報へのリンク」を含めることができること ・統一インターフェース : すべてHTTPメソッドを利用すること（ GET, POST, PUT, DELETE）

REST APIで開発者達が享受したもの ・ネイティブアプリケーションへの対応が容易 ・サーバー / クライアント間が疎結合になるため、スケーラビリティが向上する などなど...

REST APIで開発者達が抱えている課題 ・設計の自由度が高い反面、実装ルールの統一性がない →理解しないまま作ると統一性のない APIが生まれてしまう ・仕様や定義に関する要素がない →ドキュメントとの乖離が発生しやすい

REST API開発における便利ツール ・design（設計）: postman, stoplight, swagger ・documentation（ドキュメント管理）: postman, stoplight, swagger ・build, debug api: postman, stoplight, swagger ・mock server: prism, MSW ※auto generate（自動生成） 　code→document: ORM（prisma等）が生成, フレームワーク（django等）が生成 　document→code: postman等のdocumentation toolが生成

gRPC入門 ・そもそもRPCって何？ ・gRPCとは ・採用事例 ・gRPCの特徴 　・ Protocol Buffersによる実装 　・HTTP/2による高速な通信 　・複数のストリーミング通信形式を選択できる ・gRPCで開発者達が抱えている課題

そもそもRPCって何？ RPC = Remote Procedure Call（遠隔手続き呼び出し） ・あるプログラムが別のネットワーク上のプログラムを呼び出して実行すること （補足）2つのシステム間の通信パターン（Enterprise Integration Patternsより引用） 1. File Transfer: ファイル転送でのデータ連携 2. Shared Database: データベース共有でのデータ連携 3. Remote Procedure Invocation: 別名Remote Procedure Call（RPC） 4. Messaging: 非同期を前提としたフレームワークを介してデータ連携する, Pub/Subパターン

gRPCとは Googleが2015年2月に公開した、HTTP/2を利用したRPCフレームワーク ・Microservicesに適した高いパフォーマンスを実現する通信プロトコルを目指す ・Stubbyという、Googleが自社DCで活用していたRPCフレームワークがベースになっている マスコットキャラのパンケーキくん （Golden RetrieverのPanCakes）

採用事例 Googleはもとより、国内外にかかわらず多くの採用事例がある ・Google ・Netflix ・Docker ・merukari ・cookpad

gRPCの特徴 ・Protocol Buffersによる実装 ・HTTP/2による高速な通信 ・複数のストリーミング通信形式を選択できる

gRPCの特徴 - Protocol Buffersによる実装 - ・Googleが開発したシリアライズフォーマット ・IDL（インターフェース記述言語）により、任意の言語のクライアント / サーバー用のコードを生成 ・型安全なスキーマ ・JSONなど他のシリアライズフォーマットと比べ、通信量が少なく高速

gRPCの特徴 - HTTP/2による高速な通信 - - HTTP/1.1のパフォーマンス的な課題を解決するために開発された ・gRPCはHTTP/2の上で動作 ・従来通りのRequest/Response形式だけでなく、Streamingを用いた双方向通信も可能 ・データ転送量の圧縮

gRPCの特徴 - 複数のストリーミング通信形式を選択できる - - Unary RPC: 1つのrequestに対して1つのresponse Client Streaming RPC: 複数のrequestに対して1つのresponse Server Streaming RPC: 1つのrequestに対して複数のresponse Bi-directional Streaming RPC: 複数のrequestに対して複数のresponse 双方向ストリーム？　 👀Websocket

gRPCの特徴 - 複数のストリーミング通信形式を選択できる - - gRPCは、ClientとServerがある ・Client 　・requestを送信し、responseを受け取る 　・内部的にServerのStub（生成されたコード）を保持している ・Server 　・requestを受け、responseを返却する

gRPCで開発者達が抱えている課題 - ・HTTP/1との下位互換性がない →システム内でHTTP/2未対応のものがある場合に利用できない →ブラウザ側はgRPCが使えるように対応されていない（ gRPC Web, gRPC Web Proxyを利用すれば解決） ・responseの中身を確認するのに専用のクライアントツールが必要 →curlで簡単に確認できる RESTとの差になる

REST APIで開発者達が抱えていた課題 ・設計の自由度が高い反面、実装ルールの統一性がない →理解しないまま作ると統一性のない APIが生まれてしまう→解決 ・仕様や定義に関する要素がない →ドキュメントとの乖離が発生しやすい →解決

gRPC ✖ pythonでweb chatを実装してみるハンズオン ・まずは完成品のデモ ・手元での動かし方 ・コード作成の流れ ・コード解説

まずは完成品のデモ

手元での動かし方 https://github.com/nishidayoshikatsu/pycon_kyushu_2022_kumamoto_grpc_handson

コード作成の流れ 1. .protoファイルを作成（プロトコルの定義） 2. codegen.pyを実行して.protoファイルからコードを自動生成する （protocol bufferへの変換） 3. gRPC ClientとgRPC Serverをかく 生成！

コード解説 ① = の後に書かれているのは初期値やデフォルト値ではなく、「タグ」という背番号。 ②ChatStream⇦Server Streaming RPC, SendNote ⇦Unary RPC ① ②

コード解説 ChatStream: 新しいメッセージを送信するために使用されるストリーム SendNote: クライアントがサーバーにチャットを送信するときに使用

まとめ - gRPCの想定利用シーン - ・高速な通信（HTTP/2 + protobuf） ・スキーマファーストな開発が可能 ・さまざまな通信方式に対応 よって、 ・Microservices間の通信をする場合 ・ネイティブアプリの開発 ・パフォーマンスが求められる場合 ・Microservicesで色々な言語を使いたい場合