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.

RakSulのInternal API開発で gRPCを導入した話

2,615 views

Published on

RakSulのInternal API開発で
gRPCを導入した話

Published in: Technology
  • Be the first to comment

  • Be the first to like this

RakSulのInternal API開発で gRPCを導入した話

  1. 1. © RakSul,Inc. All Rights Reserved. RakSulのInternal API開発で gRPCを導入した話 Omotesando.rb #45 Nobuhiro Nikushi 2019/04/03
  2. 2. © RakSul,Inc. All Rights Reserved. About me Nobuhiro Nikushi 二串 信弘   ● Works at RAKSUL INC. from 2017/3 ● Engineering Manager at Printing EC Team. ● Favorite Languages: Ruby, Golang, TypeScript, etc ● Private: English, Violin, 子育て Engineering Manager and Tech Lead at RAKSUL github: @nikushi twitter: @nikushi_jp
  3. 3. ファブレス型印刷/広告EC “ラクスル” 物流のUber “ハコベル” Our services 印刷や物流といった伝統的な産業で事業を展開
  4. 4. ● ラクスルのシステムのRebuild ○ 一枚岩なレガシーシステムを ラクスルではどのように Rebuildしているの か?https://www.slideshare.net/nixiesan/rebuild-124366117 ○ そうだ、ラクスルを作り直そう! | RakSul Tech Blog https://tech.raksul.com/2017/12/18/raksul-platform-project/ ● 商品カタログ機能のInternal API化 # 今日の話 What do I do?
  5. 5. 商品カタログAPI(MD API)の立ち上げにあたってgRPCを採用 その経緯を紹介します Today’s topic
  6. 6. © RakSul,Inc. All Rights Reserved. 印刷EC = raksul.com における商品カタログサービス。もともとモノリスアプリケーション 内に存在していた機能を別サービス化。 ユースケース ● ECサイトは商品仕様をAPI経由で参照できる ● カテゴリマネージャー向け(商品登録・更新、販売価格の更新など) What is MD API?
  7. 7. © RakSul,Inc. All Rights Reserved. 商品仕様の例: チラシ・フライヤー
  8. 8. © RakSul,Inc. All Rights Reserved. 商品仕様の例: 名刺
  9. 9. © RakSul,Inc. All Rights Reserved. 商品仕様の例: 冊子
  10. 10. © RakSul,Inc. All Rights Reserved. Components Monolithic App Monolithic App MD API GET https://raksul.com/flyer GET https://raksul.com/flyer gRPC over h2c server implemented by grpc gem, with Rails’ ecosystem. Still monolithic Rails app, but this layer acts like BFF. gRPC client stub, implemented by grpc gem
  11. 11. © RakSul,Inc. All Rights Reserved. 商品カタログの特性 ● raksul.com の商品カテゴリ数はN個(チラシ、名刺、冊子、etc..) ● 商品カテゴリ毎にデータスキーマは異なる 本プロジェクトでAPI仕様記述言語に求めること ● API仕様記述ファイルを商品カテゴリ毎に分けたい ● API仕様記述のエディタでの書きやすさを重視 We choose gRPC, Why?
  12. 12. © RakSul,Inc. All Rights Reserved. Protocol Buffers ● import によるファーストクラスのファ イル分割サポート ● エディタのサポートが強力 ○ 無論エディタによるが ○ JetBrains系エディタのproto plugin はとても良い ■ message間、ファイル間の コードジャンプ ■ syntax error feedback We choose gRPC, Why?
  13. 13. © RakSul,Inc. All Rights Reserved. RakSulではAPI開発にSwaggerを使ってきたが本案件では採用しなかった ● $ref を使うとファイル分割できるが ○ $ref: '../components/pet.yml' こういうの ● ローカルエディタでのコードジャンプは効くが、Swagger Editorは未対応 ○ (余談) 社内アンケートではSwagger Editor 派と ローカルエディタ派にそもそも分かれた ○ (余談) 私個人としては面倒だが Swagger Editor 使っていた ● Swagger UIや committee がresolveしてくれない ○ `$ref` を resolve し1ファイルに統合するスクリプトを作る ? ■ `$ref` の解決は Ruby ではなく別途 node を使うことになる ○ ファイル修正するたびにコマンド実行 ? or Guard で watchする? Swagger, why not?
  14. 14. © RakSul,Inc. All Rights Reserved. swagger-blocks という gem がある swagger記法をRuby の DSL で書ける 今回の要件も叶えれるが、本当に俺たちはRubyでSwaggerを書きたいか? 最終更新日が1 year ago 等々考えて見送った。
  15. 15. © RakSul,Inc. All Rights Reserved. ● JSON Schema より圧倒的に書きやすい(とおもった) ○ 記述量少ない && エディタサポートがいい感じなのでサクサク書ける ● REST制約(GET/POST/PUT/DELETE)に縛られないAPI設計ができること ○ 技術負債解消の文脈では関数単位で切り出しがしやすい! ● メンバーのモチベーションは高い、技術的な裾のが広がった ○ Protocol Buffersが便利だと気づく ○ 他案件でも採用 ● インフラ的チャレンジ(Sidecar Envoy, Service Discovery, Service Mesh, Container, etc) gRPCを採用後に感じた良かったこと
  16. 16. © RakSul,Inc. All Rights Reserved. gRPCを使ったサービスを本番運用に乗せるには考えることがたくさんある ● Infrastructure(monitoring, load balancing, graceful deploy, etc) ● Understanding gRPC protocol(status code, metadata, etc) ● Interceptor ● mock in unit tests ● mono git repository for proto files ● Understanding gRPC Server(Ruby and gRPC C-Core impl) ● etc ロングストーリー。これらの話はまたいつかの機会に話したい。 gRPC in Production
  17. 17. © RakSul,Inc. All Rights Reserved. We are hiring!
  18. 18. © RakSul,Inc. All Rights Reserved. Thank you!
  19. 19. © RakSul,Inc. All Rights Reserved. Appendix
  20. 20. © RakSul,Inc. All Rights Reserved. raksul-proto: mono repo for all systems’ proto files raksul-proto $ tree raksul/ raksul └── printmd └── v1 ├── businesscard.proto ├── b3flyer.proto ├── flyer.proto ├── price.proto …etc..
  21. 21. © RakSul,Inc. All Rights Reserved. フロントエンド向けのAPI戦略 ● フロント向けのAPIは引き続き RESTFul APIを採用 ● Swaggerを使う. gRPC-Web も考えたが見送り ○ PMやフロントエンドエンジニアの慣れ chorome developer tools ● しかしここでJSON Schemaを書いてしまっては裏側をgRPCにしたとしても意味が 無い protoc-gen-swaggerを使ってフロントエンド向けAPIの仕様もProtocol Buffers で書いて swagger.json 出力するようにした ref: スキーマ定義言語 Protocol Buffers と protoc-gen-swagger を使って Web API のスキマを埋めよう | VOYAGE GROUP techlog https://techlog.voyagegroup.com/entry/protoc-gen-swagger protoc-gen-swagger

×