こんにちは。モビルスで MOBI VOICE のバックエンドを担当している村中です。
５月にマイクロサービス関連のワークショップに出席しましたので、モノリスからマイクロサービスへの移行について書いてみたいと思います。なお、出席しましたワークショップの内容そのままではなく、私の理解となりますのでご了承ください。
なぜマイクロサービス化するのか
企業は成長するためにより良いサービスを速く提供し競争力を高めていく必要があります。このことを実現する開発手法の一つとして DevOps があります。DevOps では開発チームと運用チームが協力・連携することにより品質を担保しつつ高い頻度でリリースを行えることを目指します。DevOps の成熟度とパフォーマンスを評価するための指標として DevOps Research and Assessment(DORA)があります。ソフトウェアアーキテクチャをマイクロサービス化することにより DORA のパフォーマンスを改善できると言われています。
Google Cloud ブログより引用
https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora
モノリスの課題
マイクロサービスと比較されるソフトウェアアーキテクチャにモノリスがあります。モノリスはすべてが 1 つにまとまっているシステムです。１つにまとまっているため、デプロイによる影響範囲が大きくリリースまでに時間がかかってしまいます。
また、特定機能のみスケーリングすることができないです。なお、モノリスがよくない設計という訳ではなくソフトウェアの規模などによりモノリスが適していることもあります。内部構造として分割しているが、敢えて 1 つにまとめているモジュラーモノリスというものもあります。
マイクロサービスの利点
マイクロサービスとはサービスという単位に分割し、ネットワークを介し各サービス間でデータのやりとりをし１つのシステムを実現するものです。モノリスに比べサービスで分かれていることにより個々のコード量が少なくなり理解しやすくなります。サービス単位でのリリースが可能で、サービスごとにスケーラブルです。
なお、サービスごとにデータストアを持つためサービスを跨ぐ処理の場合に最終的にデータの一貫性を補償する結果整合性を担保することになります。また、サービス間で通信を行うためモノリスに比べ複雑になります。
マイクロサービスが適さないケース
マイクロサービスにデメリットがあるようにマイクロサービスが適さないケースもあります。以下はマイクロサービスが適さないケースの例です。
- マイクロサービス化によりコストが見合わない場合
- データに強い一貫性が必要な場合
- ドメインが単純な場合
- マイクロサービスにする理由がない場合
マイクロサービス化に向けたチーム設計
コンウェイの法則というものがあり、組織の構造がシステムの構造に反映されると言われています。システムをマイクロサービス化しても組織がサービスごとに分かれていない場合はサービスが疎結合とならず、期待したパフォーマンスを得られない可能性があります。そのため、マイクロサービス化を行うには組織の見直しも必要になります。
マイクロサービスへの分割方法
モノリスからマイクロサービスへ移行するにあたり、サービスへの分割が必要になります。サービスの分割には以下のようなアプローチがあります。
マイクロサービスへの移行方法
モノリスをいきなりマイクロサービスに置き換えてしまうと予期せぬ障害の発生などリスクがあります。そのため、ストラングラーパターンを適用するなどし徐々に移行することでリスクを軽減させます。ストラングラーパターンでは、既存のモノリスを徐々にマイクロサービスへの分割を進め最終的にマイクロサービスに置き換えます。
まとめ
簡単にですがモノリスからマイクロサービスの移行について書きました。マイクロサービスについては多くの書籍があり、今回の記事では概要の紹介ぐらいしか書けていないと思いますが何かのお役に立てれば幸いです。
私が担当している MOBI VOICE はご利用くださるお客様の増加に伴い最適なスケーリングが行えるよう構成の見直しを行うこともあります。現状マイクロサービスでなくマイクロサービス化という話も今のところないですが、リスクを軽減させて移行させるなどマイクロサービス以外でも役立つ考え方があるのではと思っています。
モビルスでは、一緒に働く仲間を募集中です！
興味のある方は、ぜひ採用情報のページをご覧ください！
