マイクロサービス化スタートしました!(api-gateway + golang + gRPC)

こんにちは。開発グループ・エンジニアの阿部です。
社内では abemotion って呼ばれたりもします。

私は主にサーバーサイドを担当しているのですが、
「ココナラへもマイクロサービスを導入したい!」と下記書籍で去年勉強会を開きました。

『マイクロサービスアーキテクチャ』

f:id:abemotion:20180630133730j:plain

忙しい業務の合間を縫って、毎週朝の30分をコツコツ続け、
今年の5月にようやく「12章 まとめ」までを終えました。

さっそく会社に提案したところ...

f:id:abemotion:20180702120551p:plain

2018年6月〜マイクロサービス化がスタートしました!

(心の声:このスピード感、、、さすがベンチャーや...)

この早さには、提案した私の方がビックリしたくらいです笑

今日は、弊社へのマイクロサービス導入方法や使用技術をご紹介します。

Gateway パターン

現在のココナラの使用技術です。

フレームワーク
サーバーサイド CakePHP
API Rails

サーバーサイドは、CakePHP → Rails への移行が今も進行中なのですが、
その過程で APIシステムが肥大化している傾向にありました。

そこで Gateway パターンを用いることにしました。

これを...

f:id:abemotion:20180702120713p:plain

こうします!

f:id:abemotion:20180702120726p:plain

Gateway パターンを用い、徐々に既存のAPIシステムも、 移行(Stranglerパターン/絞め殺)していきます。

Go言語

apigatewayには、Go言語を採用しました!

採用理由・特徴としては、

  • 高速
  • 並行処理
  • シンプルな哲学

などなど様々ありますが、
個人的には、3つ目の「シンプルさを重視する」言語思想を大変気に入っています。

パッケージ名で例をあげると、Effective Go にもこう書かれています。

the package name should be good: short, concise, evocative.

「良いパッケージ名は、短く、簡潔で、明確・明瞭である」

言語仕様もシンプルなため習得が容易と言われていますし、
シンプルさという観点では扱いやすい言語だなと感じています。

「シンプル?それのどこがいいの?」

という方は、下記書籍もあわせて読むと、きっとこう変わると思います笑

『Think Simple』

f:id:abemotion:20180630134416j:plain

(心の声:シンプル最高、、、日本よ、これが Apple や...)

gRPC

apigatewayと各マイクロサービスの通信には、
Google が公開した Protocol Buffers を利用した RPC フレームワークである gRPC を採用しました。

gRPC を導入すると、サーバーサイド・フロントエンド・アプリ、全ての実装に影響が出ます。

そこで社内の Slack で質問してみたところ...

f:id:abemotion:20180630134521p:plain

各方面からの賛同をいただきました!

(心の声:なんて熱い先輩たちなんや、、、やっぱりベンチャーや...)

gRPCの特徴・メリット

  • .protoファイルでインターフェイス仕様を一元管理
  • サーバ側と異なる開発言語用のクライアントライブラリも自動生成
  • JSONやXMLと比べるとパフォーマンスが高速
  • コードの自動生成によって、本来時間をかけるべき機能実装に集中できる

今後、人・システムはさらに増えていくことが予想されるので、
一元管理できることや、様々な言語へのモデル自動生成もでき、マイクロサービス化にうってつけの技術だと思います。

最後に

現在も本プロジェクトは絶賛開発中です!!

フロントエンドでは、Nuxt.jsを使用していたり、GraphQLの採用も検討していたりしますので、またこのブログでご紹介できたらと思います。

f:id:abemotion:20180702122616p:plain

ココナラの行動理念「変化を楽しもう」に共感するような、チャレンジを賞賛できる仲間もお待ちしています!

www.wantedly.com

www.wantedly.com