EmotionTechテックブログ

株式会社Emotion Techのプロダクト開発部のメンバーが、日々の取り組みや技術的なことを発信していくブログです。

モノリスからマイクロサービスへ OpenResty導入準備中

Emotion Tech Advent Calendar 2021 4日目

はじめに

はじめましてプロダクト開発部部長の吉田です。Advent Calendarの4日目を担当させていただきます。以前は建設機械関連、モビリティー関連、AI関連の会社のスタートアップなどの会社で働いていました。サービス開発においてCX/EXはとても重要と感じ、Emotion Techに4月にジョインしました。
 以前テックリードの門田見から「Rustでマイクロサービス開発はじめました」にて、マイクロサービス化とRustを紹介させていただきました。今回は、モノリスからマイクロサービスに切り替えるための話をしたいと思います。マイクロサービスを導入する際にはエンジニア組織と技術の両方の検討が大事ですが、今回は技術面の一部だけ紹介させていただきます。

エンジニア開発体験・顧客体験の向上を目指す

 以前の記事でマイクロサービス化の理由について説明していますが、新しい取り組みによってエンジニアの開発体験の向上だけではなく、サービスを使っていただいている顧客の体験を向上することも大事です。ただ、マイクロサービスの実施を決めても一度に全ての機能を新しいものに変更するのは難しいです。マイクロサービス化を目指す多くの開発組織は、この問題と遭遇すると思います。そこで弊社では、新しい機能に移行できていない(マイクロサービス化できていない)機能は、従来のシステムで処理させ、段階的に切り替えを目指すことを考えました。

ストラングラーパターン

 今回、段階的に切り替えていくアプローチとしてストラングラーパターンを採用しました。Martin Fowlerさんが言及したパターンです(StranglerFigApplication)。システムから徐々に新しいシステムへ移行することで、システムを丸ごと書換える際に発生するであろうリスクを低減できることが述べられています。このパターンの良さは、なにかの理由でマイクロサービス開発が止まっても顧客には影響がなく、移行の期日に追われることもなく、最悪戻ることを考えることもできます。

f:id:newapplesho:20211203172734j:plain

モノリスの分解の優先度決め

 検討をはじめる際には、モノリスなシステムの中のどこから分解するかをチームで認識し、優先順位付けを行いました。分解の優先順位の認識を揃えることで、既存システムの改善をしつつ、新しいものに誰もがはじめられることを目指しました。順位付けは「分解のしやすさ」、「分解による利益」の軸で整理をしていました。

f:id:newapplesho:20211203172852p:plain:w400

モノリスからマイクロサービスへ

 優先順位を決めたら移行に向けての技術検討です。ストラングラーパターンを導入したので、基本的にはフロントエンドの機能には極力影響なく機能改善していきたいと考えます。まず第一歩として、モノリスなシステムから特定の新しいシステムへリダイレクトできるプロキシ(ストラングラーファサードAPI Gateway)を検討しました。ここまで話が長かったですが、今回のタイトルのテーマであるOpenRestyの導入を決めました。

OpenRestyとは

 OpenRestyはNginxにngx_lua, LuaJITと様々なライブラリをパッケージインストールされたWebアプリケーションサーバーです。Nginxにlua-nginx-moduleを導入するとNginxでLuaを扱うことができますが、Nginxに外部モジュールなどを導入する作業は大変なので、特に理由がない限りOpenRestyを導入することがおすすめです。

NginxでLuaが使えると何がよいのか

Nginxはconfファイルで細かな制御が可能ですが、さらに高度な制御ができないかと考えたことはないでしょうか。 マイクロサービス化においては以下のようなメリットがあります。

  • OpenRestyに高度なルーティングやアクセス制御を任せられる
  • バージョンの切り替えがしやすくなる
  • 特定のユーザのみ最新のAPIを提供することが可能
  • それぞれの業務に特化したマイクロサービス設計、インフラ構成が可能になる
  • マイクロサービスを直接通信させない
  • 高度なルーティングを活用して各マイクロサービスの共通的な処理をまとめやすくもなる

f:id:newapplesho:20211203173222j:plain:w400
モノリス

f:id:newapplesho:20211203173300j:plain:w400
バージョンの切り替え
f:id:newapplesho:20211203173322j:plain:w400
業務に特化したマイクロサービス設計、インフラ構成

また、サービスによっては以下のパターンもあると思います。

  • APIごとに制限を設けたい
  • APIコール数で課金をしたい
  • APIの利用率、監視をしたい

このようなケースもOpenRestyを使うことで実現しやすくなります。 それぞれのマイクロサービスとの通信はlua-resty-httpを使い、制御のルールやAPIコール数の保存先としてRedisなどを使う場合、lua-nginx-moduleの情報を参考にしながら実装するとよいでしょう。

おわりに

 マイクロサービスと始める技術的なアプローチとして、ストラングラーパターンを採用し、弊社ではストラングラーファサード(API Gateway)としてOpenRestyを導入することを決めました。  今後、マイクロサービスの移行状況も紹介していきたいと考えています。また、マイクロサービス化を行う上での組織のありかたをどのように変更していくかについても紹介したいと思います。マイクロサービス化に向けてまだ始まったばかりで、検討すべきこと、設計すべき事項はたくさんあります。今年はマイクロサービス化だけではなく、データ基盤、Rustの導入等、色々な技術にアプローチすることをしながら顧客の課題を解決していくことを目指しています。
 現在、顧客企業のCX/EXの改善をするためのシステムを作っている開発者の体験も一緒に改善してくれるメンバーも募集中です。この記事や他の記事を見て少しでも弊社に興味をもっていただけましたら、カジュアル面談も行っていますのでご応募お待ちしております。

www.green-japan.com

www.green-japan.com

www.green-japan.com