JJUG CCC 2019 Spring で登壇してきました

Java gRPC JJUG

5/18 に行われた JJUG CCC 2019 Spring に「初めてのgRPC」 という内容で発表してきました。

www.java-users.jp

発表資料はこちらです。

speakerdeck.com

全体の資料もこちらでまとまっています。

github.com

今回は、登壇者兼ボランティアスタッフとして申し込みしました。 ボランティアスタッフは2回目だし慣れてるだろうから、部屋の進行と発表同時にやっちゃえということで、 スタッフからの注意事項の説明の後、そのまま発表するというちょっと面白い流れになりました。

会社の人からもいい感じのツッコミをいただきました。

技術イベントの登壇はいつかやってみたいことの一つでした、なので夢が一つ叶いました。

なかなか大変でしたけど、発表したテーマに興味を持って頂けた方が何名かいらっしゃったので、発表してみて良かったです。

発表テーマ gRPC について

gRPC については2,3 年ほど前から採用事例を聞くようになってきました。 また最近だと、国内・海外のマイクロサービスを主導している会社で gRPC + サービスメッシュの採用事例を聞くようになってきていたので gRPC について調べ出しました。

その過程で、4種類ある RPC のプログラムの書き方が結構違ったり、そもそも gRPC Java に関する情報があまりない( Go が多い) ということに気づきました。 ちょうどいいタイミングで CCC の CFP 応募が始まったので、良い機会だということで申し込んでみました。

幸いにも、同じタイミングで 社内でも gRPC を検討するタイミングがあったので、 チーム内勉強会を開くノリで発表資料をまとめられたのは良かったかなと思います。

スライドが70枚と多く、後半は飛ばし気味になりましたが時間内で言いたいことは言えたので良かったです。 わかりづらい点などありましたら、コメントや Twitter で質問いただけると幸いです。

gRPC は個人的に筋の良い技術だと思っていますが、ライブラリやミドルウェアを含めた運用の知見がまだ足りてないです。 さらに今までの Web アプリケーションフレームワークの手法が使えないです。 ( とは言え、Webアプリケーションフレームワークの仕事の大半は、不確実なHTTP ボディの解析とURLのルーティングで、gRPC はそのどちらも割と高いレベルで解消しているのだけど) なので、まだまだ発展の余地はあるし、色々貢献できそうだと思いました。 社内でも草の根的に gRPC やってるチームがあるということもあとで聞きましたので、やっておいて損はないと思います。

またパgRPC についてフォーマンスよりも気に入っているのは、IDL としての Protocol Bufferes の良さです。 DDD の文脈では公開されたインターフェースという、そのサービスが提供する API をサービス自らが提供するパターンがあります。 proto ファイルはまさに公開されたインターフェースのフォーマットとして最適だと思います。

今後チームで gRPC をやってみて、実際どうだったかをお知らせする機会があればやってみようと思います。

いただいた質問について

  • 分散トレースはできるの? Netty 以外も使えるの?

  • Protocol Bufferes の message を ビジネスロジックに持ち込まないなら、DTOを自分で作ってコピーしないといけないのでは?

  • Reactive-gRPC を使うと、RxJava や Spring WebFlux とかと接続できるの?

    • WebFlux との接続は確認しました。そのため gRPC-gateway を使わなくても、Spring WebFlux->Reactive gRPC で REST-gRPC変換はできなくもないです。
    • R2DBC が登場したら、 gRPC とDB をシームレスでリアクティブに扱えるので面白いなと思っています。
    • 色々な Reactive なもの(外部のWebApi とか、別の gRPC の呼び出しとか)を逐次・並列に接続したい場合に、Reactive-gRPC は良い選択肢だと思います。

  • 何か困ったことは?

    • 時刻型と十進数型は ProtocolBufferes には無いので、自作する必要があること。
    • 自作した場合、Javaの LocalDate や BigDecimal とのマッピングコードが必要なので、どうやって実現するかは検討の余地がある。
      • go だとこの場合 インターフェースで後からメソッドが追加できるから楽なんだろうなとか思った。
      • Java だとどうしようもないが、 Kotlinだと拡張メソッドで　Protocol Buffersの型とJavaの型それぞれに相互変換のメソッドを追加できるので、Kotlin やるならありかなと思います。

  • Kotlin でできるの?

    • できます。gRPC-Kotlin プラグインもありますが、普通に生成した gRPC Service, Stub のJavaコードもKotlin から使えます。
    • gRPC-Kotlin のコードは コルーチンを使うためか、MDC,分散トーレシングのためにCoroutien Context の上書きが必須だったので、もう少し見守ろうと思いました。（サンプルコードを参照)

所属について

2019年のはじめに転職しました。 今回、試用期間が空けたこともあり、所属について隠すことはやめました。

懇親会 LT でもほぼ同時期に入試された方が、働いてみてどうだったかを語っていました。 私もチームは違いますが、大規模なサービスの開発に携われるというのはプレッシャーもありますが、とても面白いです。 エンジニアリングに集中できる環境があり、チームメンバーみんなが生き生きとしているので働いて楽しいなと感じています。

DevRel チームの方々はフットワークも軽く、知識もあり、今回の発表にあたり色々とアドバイスいただけました。 発表内容については、機密や誹謗中傷がないかをチェックされるだけで、 内容については発表者の意思を尊重いただけたので感謝しかありません。 内容についての拙い点はわかりづらい点は全て私のスキルによるものです。

JJUG CCC について

ボランティアスタッフとして

今回は人員が2倍くらいに増えました。 色々な人が参加していて楽しかったし、一人当たりの負荷も前回に比べて減りました。 また総会には参加できませんでしが、運営の方式も変わりますので CCC はより良いものになっていくと思います。 みんなもやりましょう。

参加者として

自分の発表以外は、割と自由にその辺をうろついていました。 その辺で久しぶりの方々と身の回りの話や、今後の技術動向などについて話をしていることが多かったかな。 セッション聞くのも面白いですけど、ここでしか会えない人たちと話すのも楽しいし、刺激になる。

特にアンカンファレンスは、今回は Java Champion や JDK ソムリエ、他に Java 界隈の強い人ばかりの豪華メンバーでした。

貴重な実体験や知識を聞くことができました。

まとめ

皆さまお疲れ様でした。

こんなに貴重な技術イベントは他にはないと思う。

次も頑張るぞ。