こんにちは。クラウドリードチームのフクナガです。
2022年5月25日から26日にかけて開催されたAWS Summit Japan 2022で「マイクロサービスアーキテクチャは SaaS 開発者を救うか」というセッションを視聴しました。
このセッションを視聴して得られた知見などをレポートします。

セッション概要

タイトル

マイクロサービスアーキテクチャは SaaS 開発者を救うか(AWS-34)

スピーカー

AWS パートナーアライアンス統括本部ISV
パートナー本部 パートナーソリューションアーキテクト
櫻谷 広人さん

概要

多くの課題に直面する SaaS 開発者にとってマイクロサービスは救いの手となるのでしょうか？高速かつ大規模にビジネスをスケールさせていくことを目標とする SaaS においては、日々変化する顧客のニーズを迅速に捉え、継続的にプロダクトのアップデートを行っていく必要があります。これを実現するためには、ユーザーエクスペリエンスの向上、開発/運用の効率化、アジリティの加速、コスト削減など様々な取り組みが必要となります。本セッションでは、SaaS 開発においてマイクロサービスアーキテクチャをどのように活用できるのか、サンプルとなる事例を交えながら解説します。
出典：マイクロサービスアーキテクチャは SaaS 開発者を救うか

レポート

今回の、セッションではマイクロサービス/SaaSサービスの特長や課題について説明いただき、SaaSサービスを展開していくうえでマイクロサービスがどういうメリットをもたらすのか、というテーマでお話しいただきました。
マイクロサービスを採用することによるメリットを享受するためには、特長を理解し適切に利用することが必要です。
今回の記事では、セッションの内容に触れながらマイクロサービスを採用することによるメリットを解説していきたいと思います。
※この記事の中では、マイクロサービスとは？みたいな部分は解説いたしません。以下書籍を読むことで包括的にマイクロサービスのメリット/検討すべきポイントが学習できるのでおすすめです。
絵で見てわかるマイクロサービスの仕組み

SaaSとは

セッションの中で、SaaSについて以下のように説明されていました。
・プロダクトではなくサービス
・どんな体験を提供できるか
・リリースして終わりではなく、運用し続けることが必要
・契約が取れたら終わりではない、サポートし続けなければならない
・市場、顧客のビジネスの変化に適応し続けなければならない

『どうすれば継続的に安全にスケーラブルに運用負荷をかけずユーザーが望む体験に改善し続けられるのか？』という課題をマイクロサービスを用いて解決していこうという方向性で話を進められていました。

モノリスにおける課題/マイクロサービスがもたらすメリット

セッションの中で、モノリス（密結合型のアーキテクチャ）を用いると以下のような課題があると紹介がありました。

[モノリスにおける課題]

・非効率なスケーリング
・関係者間調整のオーバーヘッド
・変更による影響範囲の広さ
・テスト/ビルドに要する時間の長さ
・利用可能な技術の制限

SaaS以外でも自社サービスなどをホストしていると「リリースに社内調整が必要で実施に時間がかかる」「小さな変更のためにアプリ全体を停止させる必要がある」「とある機能がサーバのリソースを食い尽くしてしまいシステムが止まった」なんていう経験はありませんか？
マイクロサービス（疎結合なアーキテクチャ）にすることで、モノリスにおける課題を解決することができます。
マイクロサービスがもたらすメリットは以下のように説明されていました。

[マイクロサービスがもたらすメリット]

・柔軟なスケーリング
・一つのことに集中できるチーム
・影響範囲の局所化
・高速なデプロイ
・自由な技術選定

マイクロサービスを適切に適用していくことで、各機能ごとの依存関係を減らすことができ、積極的なデプロイが可能になります。
顧客からのフィードバックを素早くプロダクト/サービスに反映することができるのはメリットかと思います。
また、柔軟なスケーリングですがSQSなどを用いたリクエスト数に応じたスケーリングなども実現可能です。
Amazon SQS に基づくスケーリング
上記をモノリスにおいて実現した場合、関係のない機能も含めてスケーリングしてしまうためコスト観点でも無駄が多くなってしまいます。

上記のメリットには記載がありませんでしたが、「新機能の追加が容易」というメリットも大きいです。
モノリスの場合、新機能が原因のエラーが発生した場合システム全体が止まってしまいます。
マイクロサービスの場合は、上記リスクを低減できるため機能追加のサイクルを上げることもできます。

サービス境界をどう区切るのか

個人的には、ここがマイクロサービスを活用するうえで一番難しいポイントだと思います。
マイクロサービスの最小単位を適切にデザインできるかどうかが、マイクロサービス活用のポイントです。
今回のセッションで紹介されていたポイントは以下です。

1. 可用性要件を考慮に入れる
   「注文機能」と「注文履歴閲覧機能」だと「注文機能」が止まった方がビジネス的に影響がありますよね？そのため、機能として区切って「注文機能」のみ可用性を高めるためマルチリージョン構成にしましょう。
   というような思想です。
   大は小を兼ねるということで、モノリスで全部可用性最大の構成にすることも選択肢としてなしではありません。
   ただ、マルチリージョン/マルチAZはリソースを複数配置するためコストがかなりかかります。
   対象のリソースを絞ることでコスト最適につながるかもしれません。

2. 耐障害性を考慮に入れる
   モノリスの場合、1つの機能へのアクセスが集中する場合、同サーバ内の別の機能へも影響がでてしまいます。
   爆発半径（Blast Radius）という表現もありますが、システム停止が許容できない機能を分けて、爆発に巻き込まれないようにするというのも設計思想として大事です。

3. データ要件を考慮に入れる
   接続先のDBやデータ要件（暗号化など）によって分けるという観点です。
   各サービスごとで、DBとして利用するサービスを変えることも可能なのでデータの性質に合わせた設計も可能です。

4. テナント分離モデル
   SaaSを利用するテナントごとに扱いを分けるモデルです。
   利用量が多い顧客は分けて他は共通のサービスを見に行くなどの設計が例として挙げられます。
   また、提供する契約形態によって分けるケースも考えられます。
   例：ビジネスプラン、エンタープライズプラン、プロフェッショナルプランなど

まとめ

今回のセッションは、SaaS開発者にとってマイクロサービスがどのようにメリットをもたらすのかという内容でご説明いただきました。
個人的には、サービス境界の区切り方についていくつかの設計例をご紹介いただけたのがとても勉強になりました。