この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2022 年 5 月 25 - 26 日の 2 日間AWS Summit Onlineが開催されました。本エントリは 26日に配信された「マイクロサービスアーキテクチャは SaaS 開発者を救うか」というセッションのレポートです。現在オンデマンド配信もされていますので、そちらもぜひチェックしてください。
セッション概要
多くの課題に直面する SaaS 開発者にとってマイクロサービスは救いの手となるのでしょうか？ 高速かつ大規模にビジネスをスケールさせていくことを目標とする SaaS においては、 日々変化する顧客のニーズを迅速に捉え、 継続的にプロダクトのアップデートを行っていく必要があります。 これを実現するためには、ユーザーエクスペリエンスの向上、開発/運用の効率化、アジリティの加速、コスト削減など様々な取り組みが必要となります。本セッションでは、SaaS 開発においてマイクロサービスアーキテクチャをどのように活用できるのか、サンプルとなる事例を交えながら解説します。
スピーカー
AWS パートナーアライアンス統括本部ISV パートナー本部 パートナーソリューションアーキテクト 櫻谷 広人 氏
セッションオンデマンド配信ページ
AWS Summitのポータルサイトへのユーザー登録とサインインが必要です。完了すると以下からセッションを聴講できます。
レポート
本セッションの対象者
- これからSaaSの開発に取り組む予定の人
- SaaSを本番運用している人
- 特にスケーラビリティや信頼性について課題を感じている人
- マイクロサービスアーキテクチャの導入に興味のある人
セッションのゴール
- マイクロサービスアーキテクチャと SaaS の親和性を理解する
- SaaS にマイクロサービスアーキテクチャを導入するにあたって設計の際に必要となる検討事項を知る
- → 自社の要件に合わせて設計を始める!
すべてのワークロードをマイクロサービス化することではない
ここから先はざっくりとしたレポートに留めます。詳細を知りたい方はSummitポータルサイトにユーザー登録してオンデマンド配信をご覧ください！
SaaS 開発におけるよくある課題
3つ紹介されています。
- 多様なペルソナのサポート
- 予測できないトラフィック
- サービスエクスペリエンスの継続的改善
また、SaaS開発の軸になるポイントをあらためて確認します。
SaaSという形態の特性は、様々かつ重要性の高い課題をシステムにもたらすなぁと再実感しました。
モノリシックな SaaS の場合
上記SaaS開発の課題、モノリスアーキテクチャを採用している場合以下のような観点から対応が難しくなることが多いです。ECサイトを例に挙げてそれぞれの点が説明されます。
- 非効率なスケーリング
- 関係者間調整のオーバーヘッド
- 変更による影響範囲の広さ
- テスト/ビルドに要する時間の⻑さ
- 利用可能な技術の制限
モノリスは、システムが小さいうちはその簡潔さによってメリットを生むと思いますが、大きく複雑になってくるとやはり辛くなってきますよね。
マイクロサービスな SaaS の場合
マイクロサービスアーキテクチャは、前述のモノリスアーキテクチャと比べると以下のような点でSaaSのアーキテクチャとして適していると言えます。Amazonも以前前述のような課題感を持っていて、20年ほど前にマイクロサービス化を行なったそうです。
- 柔軟なスケーリング
- 一つのことに集中できるチーム
- 影響範囲の局所化
- 高速なデプロイ
- 自由な技術選定
SaaS の目線で見るサービス境界
ただし、上記のようなマイクロサービスアーキテクチャのメリットは、適切な粒度や境界点でサービスを分割できた場合の話です。サービス境界を決める時どのように考えればよいでしょうか。ここでは4種の考慮点が紹介されていました。
- 可用性要件
- 耐障害性
- データ要件
- テナント分離モデルが与える影響
- サイロ・プール・ブリッジモデル
- マイクロサービスごとにモデルを選択する
- ノイジーネイバーのリスクを考慮する
- 各ティアに提供する価値から考える
感想
まずは「SaaSのアーキテクチャを考えるのは難しいなぁ」という小並感な感想を得ました。 「マイクロサービスアーキテクチャは SaaS 開発者を救うか」というセッションタイトルに対して、冒頭のセッションのゴールにあったとおり、必ずしもマイクロサービスがSaaSアーキテクチャの最適化になるとは限らないということがわかりました。またマイクロサービス化するにしてもどのようにサービスを分割していくかという判断・決断は非常に難しいだろうなと思います。実施したマイクロサービス化が必ずしもうまくいくとは限らないですし、またそもそも市場ニーズとかサービスの成長などなど色々な要因によって最適解は変化していくものです。故にアーキテクチャも何度も試行錯誤して作り変えていくこと、またそれが可能であることも重要なのではと感じました。そういう意味でもIaCとかCI/CDパイプラインなどなどといったようなアジリティを高める施策も当然求められるなと感じました。
こちらもあわせてどうぞ
去年のre:Invent2021でのSaaSのアーキテクチャについてのセッションがありました。こちらでも詳しくSaaSのアーキテクチャを検討する上での考慮点について説明されているので非常に有用だと思います。
また、以下の弊社とばちによるセッションでは、モノリスとマイクロサービスアーキテクチャそれぞれのメリット、デメリットを整理した上で、それぞれのいいとこ取りができる(かもしれない)モジュラモノリスアーキテクチャを紹介しています。そしてシステムを分割する・しないの判断の際のポイントも説明しています。