SaaS においてマイクロサービス化は有用なのか ?
Author : 矢ヶ崎 哲宏
SaaS の特徴
SaaS とひとくちに言っても、いろいろな業種業態、また事業や会社ステージの SaaS があります。SaaS とはサービスモデル (提供形態) のことなので、その特徴ももちろん各社ごとに変わってきます。一方で共通する部分としては、サブスクリプションモデルに代表されるストック型のビジネスが多いということが言えるかと思います。これは、ソフトウェアの所有からソフトウェアの利用という形に変わり、また好きな時に使い始められ好きな止めることができるという意味が含まれています。
つまり、SaaS の事業者としてはいかに長く続けてご利用いただけるかというところがポイントになってきます。長く続けてご利用いただくために、顧客体験の向上・安定稼働・新機能のリリース速度・サービス価格というようなポイントが大切になってくる、ということが特徴と言えるかと思います。
SaaS 観点でのマイクロサービスの利点
では、SaaS の特徴を踏まえてマイクロサービスという手段がどのような利点になるかということを考えていきます。一般的に言われているマイクロサービスの利点としては、
- アプリケーションの理解、開発、テストがしやすくなる
- 各マイクロサービスが疎結合になることにより、小さな複数の開発チームが並列に開発し、CI/CD パイプラインを利用しいつでもデプロイできる
- 各マイクロサービスごとに自由に最適なアーキテクチャを検討することができる
というようなことがあげられます。これらは SaaS において、「リリース速度の向上」による「顧客体験の向上」というところに寄与でき、メリットとして大きいと考えられます。
SaaS 本番環境にマイクロサービスは本当に有用なのか？
SaaS 提供にマイクロサービスは本当に有用なのか ? 特に本番環境でメリットがあるのか？というようなお話を耳にすることが多く感じます。
開発環境でのコンテナ利用やマイクロサービス化については、とても有用なことが多いのは理解がしやすいと思います。前述の通り、各開発チームが依存のない形で作り方の裁量を持って進めていける、コード変更に対しての依存がわかりやすくなり影響範囲の把握がしやすい、テストがしやすい、その結果デプロイの速度も高速化でき、新しい顧客要求に素早く応えることができるように感じます。これは、開発者や新しい機能、改善という視点からはとても有用です。
しかし、開発環境においても、現実的なことを考えるとメリットばかりではありません。多数のマイクロサービスが複雑に関係しあうことにより複雑さを増し、結合テストを行う環境の構築も難易度があがります。また、サービスの数だけメモリフットプリントが増すことに開発用のテスト環境を作る難易度も上がります。
さらに、本番環境での運用を考えると各マイクロサービスごとに可用性やセキュリティなどの非機能要件も考えていく必要があります。そして、例えば認証・認可のような全体で使うマイクロサービスダウン時に、サービス全体にどのような影響があるのか？をきちんと考える必要が出てきます。開発視点では良いことの方が多く見え、すぐに導入したくなりますが、現実的にはなかなか難しく、本番環境に対してマイクロサービスは本当に有用なのか？という疑問が出てきます。
そして、既存のアプリケーションをマイクロサービス化する場合は、その分割の単位をどうするのか ? データをどう分けるのか？整合性はどうするのか？という考慮点が出てきます。新しくゼロから立ち上げる事業やサービスでは、まっさらな状態から設計できるので対応できるかもしれません。しかし、既存ですでにアクティブユーザがたくさんいる SaaS をマイクロサービス化するのは難易度が高く、目に見える部分が変わらないので、SaaS 利用者から見た時に改悪と思われる状態になることは絶対に避けなければなりません。お客様への価値提供が継続的にできなくなった時には、チャーンアウト (サービスの解約) というものが待っています。ストック型のビジネスにおいてこれはとても重要で、せっかく積み重ねてきたものを崩してしまいかねません。
では、SaaS 提供においては、マイクロサービスは向いていないのでしょうか？
SaaS でのマイクロサービス実例を紐解く
実際にマイクロサービスを活用した本番環境での SaaS 例をご紹介します。
「スモールビジネスを、世界の主役に。」をミッションに掲げ、ERP をはじめとするサービスを SaaS として提供されている freee株式会社様 (以下 freee 様) では、本番環境において現在 20 以上のマイクロサービスを活用しサービス提供を行われています。
SaaS においてはインフラコストを最適化するために、いかに共有のリソースを使い利用効率を上げていくかというマルチテナントという考え方があります。SaaS の利用者 (お客様) 間で共有のリソースを利用するマルチテナント、また SaaS 内の複数サービス間でも共有リソースを利用するマルチテナントという考え方もあります。
freee 様では、後者のサービス間のマルチテナントという意味において、マイクロサービス間においてはシングルテナントクラスタでの戦略を取られています。サービス単位にシングルテナントクラスタを払い出すことにより、クラスタごとに独立して開発・リリースできます。そのため、非機能部分におけるサービス間の依存関係も解消でき、またマイクロサービスが増えるごとに SRE の運用負荷も増えていく問題においても、開発チームへ権限が委譲でき、SRE の負荷も下がっていったようです。
これはマイクロサービスの文脈で語られることの多い「コンウェイの法則」が深く関係していると考えられます。マルチテナントクラスタはひとつの大きなクラスタになり、大きなクラスタを管理する大きなチームが必要になるという事象が起きがちです。これをマイクロサービス単位でのシングルテナントクラスタへ分割することにより、開発チームにインフラも含めて開発・リリースの権限を委譲できています。そして、マイクロサービスの実装にあたってはコンテナを活用しています。Amazon EKS を利用して、依存関係をコンテナに閉じ込め、かつデプロイフローも標準化することにより、開発チームへの権限委譲が行いやすくなっています。
また、マイクロサービスとして分割し、開発チームを疎結合に分けることが可能になったことにより、特定部分のイテレーションを高速に回したい時にはその部分に開発リソースを多く配分しての高速化がしやすくなっているようです。「人月の神話」でお馴染みですが、モノリシックなシステムでは急に開発リソースを増やしたところで開発速度は上がりません。これらはマイクロサービスを SaaS の特性に生かし、機能のリリース速度の向上、つまり開発アジリティの向上に寄与できるという例かと思います。
クリックすると拡大します
業務アプリケーションにとって、マイクロサービスへの分割という時に大きな課題となる例として、データの依存関係や整合性を保つのが難しくなるという点があげられます。freee 様では、マイクロサービス化にあたっては無理にデータ層まで分割しないというアプローチをとられています。データの結合度・要求される整合性や、機密性の高いデータを扱うサービスなどのセキュリティ要件に応じて、分離するデータ、しないデータを判断して、「データベースは一緒だけれど、サービスは分かれている」という特性を作り、開発における生産性を上げることをもされています。
マイクロサービスというと、データも完全にサービスごとに分離し疎結合にしないといけないと思われる場合もあるかと思いますが、多数のお客様がアクティブにご利用中の SaaS において、いきなり全て分離するのは現実的ではありません。データが分かれていない部分があるとしても、マイクロサービス化の恩恵を十分享受することは可能です。
一方でこれらの実現のためには、広いスキルを持ったエンジニアの採用・育成が不可欠です。また、マルチテナントクラスタやモノリシックのアプリケーションの方がハードウェアリソースを効率的に使える場合もあり、インフラや運用コストという部分においても課題が出てきます。しかし、SaaS においてはその課題を差し引いても、事業の成長スピードの方を重視するという場面が出てきます。
事業の変化の速度は、アーキテクチャの変化の速度よりもはるかに早いため、いかに事業の変化に素早く追従できるかというアーキテクチャを採用されています。100 名を超えるエンジニアにて開発されている SaaS にとって、「リリース速度の向上」による「顧客体験の向上」をし続けるためのマイクロサービスアーキテクチャという手段は、とても理にかなっているかと思います。
まとめ
freee 様の実例は、SaaS における本番環境でのマイクロサービス化の実例として、とても参考になるプラクティスが多分に含まれている例かと思います。
SaaS にとって重要なのは、「お客様に価値を提供し続けられる」ことなので、これを念頭において、マイクロサービスなどの手法やテクノロジーやうまく組み合わせて、価値の向上をしつづけて行きましょう !
プロフィール
矢ヶ崎 哲宏
アマゾン ウェブ サービス ジャパン合同会社
SaaS パートナーソリューションアーキテクト
幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者を従事。現在はパートナーソリューションアーキテクトとして、今までの経験から AWS の持つ多くのサービスを SaaS 提供のステージに合った形でのアーキテクティングを支援。
AWS を無料でお試しいただけます