こんにちは。開発グループ・エンジニアの阿部です。
社内では abemotion って呼ばれたりもします。
私は主にサーバーサイドを担当しているのですが、
「ココナラへもマイクロサービスを導入したい！」と下記書籍で去年勉強会を開きました。
『マイクロサービスアーキテクチャ』
忙しい業務の合間を縫って、毎週朝の30分をコツコツ続け、
今年の5月にようやく「12章 まとめ」までを終えました。
さっそく会社に提案したところ...
2018年6月〜マイクロサービス化がスタートしました！
（心の声：このスピード感、、、さすがベンチャーや...）
この早さには、提案した私の方がビックリしたくらいです笑
今日は、弊社へのマイクロサービス導入方法や使用技術をご紹介します。
Gateway パターン
現在のココナラの使用技術です。
| フレームワーク | |
|---|---|
| サーバーサイド | CakePHP |
| API | Rails |
サーバーサイドは、CakePHP → Rails への移行が今も進行中なのですが、
その過程で APIシステムが肥大化している傾向にありました。
そこで Gateway パターンを用いることにしました。
これを...
こうします！
Gateway パターンを用い、徐々に既存のAPIシステムも、 移行（Stranglerパターン/絞め殺）していきます。
Go言語
apigatewayには、Go言語を採用しました！
採用理由・特徴としては、
- 高速
- 並行処理
- シンプルな哲学
などなど様々ありますが、
個人的には、3つ目の「シンプルさを重視する」言語思想を大変気に入っています。
パッケージ名で例をあげると、Effective Go にもこう書かれています。
the package name should be good: short, concise, evocative. 「良いパッケージ名は、短く、簡潔で、明確・明瞭である」
言語仕様もシンプルなため習得が容易と言われていますし、
シンプルさという観点では扱いやすい言語だなと感じています。
「シンプル？それのどこがいいの？」
という方は、下記書籍もあわせて読むと、きっとこう変わると思います笑
『Think Simple』
（心の声：シンプル最高、、、日本よ、これが Apple や...）
gRPC
apigatewayと各マイクロサービスの通信には、
Google が公開した Protocol Buffers を利用した RPC フレームワークである gRPC を採用しました。
gRPC を導入すると、サーバーサイド・フロントエンド・アプリ、全ての実装に影響が出ます。
そこで社内の Slack で質問してみたところ...
各方面からの賛同をいただきました！
（心の声：なんて熱い先輩たちなんや、、、やっぱりベンチャーや...）
gRPCの特徴・メリット
- .protoファイルでインターフェイス仕様を一元管理
- サーバ側と異なる開発言語用のクライアントライブラリも自動生成
- JSONやXMLと比べるとパフォーマンスが高速
- コードの自動生成によって、本来時間をかけるべき機能実装に集中できる
今後、人・システムはさらに増えていくことが予想されるので、
一元管理できることや、様々な言語へのモデル自動生成もでき、マイクロサービス化にうってつけの技術だと思います。
最後に
現在も本プロジェクトは絶賛開発中です！！
フロントエンドでは、Nuxt.jsを使用していたり、GraphQLの採用も検討していたりしますので、またこのブログでご紹介できたらと思います。
ココナラの行動理念「変化を楽しもう」に共感するような、チャレンジを賞賛できる仲間もお待ちしています！