マルチテナントSaaSアーキテクチャの構築 ―原則、ベストプラクティス、AWSアーキテクチャパターン

はじめに

私が最初にSoftware-as-a-Service（SaaS）の分野を調べ始めたとき、既存のベストプラクティスの指針がたくさん見つかるだろうと期待していました。何しろ、SaaSは決して新しい概念ではなかったからです。成功したSaaS企業の例は複数あり、SaaSが多くの企業にとって望ましい提供形態としての地位を確立しつつあるという一般的な見解もありました。私にとっては、既存のパターンや戦略を取り入れ、それを実践するだけの仕事だと考えていました。しかし、驚いたことに、その通りにはいきませんでした。

顧客のソリューションに目を向けたり、指針を求めて業界を調べたりするうちに、SaaS環境を設計、構築、運用する意味について、いかに明確な指針が欠如しているかを痛感するようになりました。その一因は、あらゆる技術にレッテルを貼ることで生じる、自然な曖昧さがもたらした副産物だと思います。絶対的な基準がないため、SaaSのあるべき姿に関する定義や意見が対立する余地が多くありました。これにより、実装やアプローチが根本的に異なる企業でも、SaaSのブランドを名乗ることが許されています。実際、SaaSデリバリーモデルを採用することの意味について、まったく異なる、ずれた見解を持ってSaaSへの道のりを歩んでいる企業を今でも数多く見かけます。

これ自体は何も間違ったことではありません。SaaSとは何かの意味について、さまざまな考え方があるのは素晴らしいことです。しかし、あなたを「SaaSの専門家」として頼りにしている顧客と仕事をする必要がある場合、こうした考え方は大きな問題になります。専門家として、顧客が望むものを何でも構築すればよいというわけにはいきません。実証済みのベストプラクティスの戦略やパターンを教えてくれることをあなたに期待しているチームには、曖昧さは通用しません。自分の仕事をするためには、ベストプラクティスのSaaSアーキテクチャとビジネスを構築することの意味について、明確な見解を持って議論に臨まなければなりませんでした。また、マルチテナントアーキテクチャを直接形成するトレードオフやアーキテクチャパターン、運用上の考慮事項をチームが理解できるように、SaaSの全体像をより具体化する必要がありました。そのためには、幅広いドメイン、ワークロード、顧客属性などに対応できるSaaSの原則と戦略を体系化する必要がありました。これは多くの点で、SaaSソリューションとは何かという広く開かれた概念から意図的に離れ、組織が進むべき道のりを描くのに役立つ、より具体的な一連のガードレールを定義することでもありました。 ...