IaaS/PaaS/SaaS/BaaS の 3 つのクラウドコンピューティングモデルの比較: SaaS アーキテクチャ設計分析

SaaS - Software as a Service (Software as a Service) の出現により、従来のソフトウェアの使用がサービスの使用に変わりました。

SaaS と従来のソフトウェアの最大の違いは、前者はサービスのレンタル料を年間ベースで支払うのに対し、後者はサービスを 1 回だけ買い取ることです。これは単なる「見積り方法」の違いに見えますが、実はサービスモデル、販売モデル、企業価値などに根本的な影響を与える根本的な変化です。

従来のソフトウェアは実装の失敗率が高かったり、オンライン化後の土地が使いにくいなど、埋没費用に相当します。ソフトウェア会社の観点から見ると、契約を締結した時点で販売実績のタスクはすでに達成されているため、営業、さらにはプリセールスサポートコンサルタントでさえも「受注を獲得する」ことを目標とすることがよくあります。落とし穴はまったくありません。翌年以降の維持費はわずか 10 ～ 15% であり、メリットはあまりなく、良いものであれば回収するだけですが、そうでない場合は労力と多額の投資をする価値がありません。SaaS の年払いはこの状況を一変させました。ソフトウェア会社にとっては、販売の難易度と販売サイクルが短縮され、SaaS 製品の販売で年間数百万ドルの売上収益を達成できる可能性があります。SaaS企業の場合、2年目からの更新コストは非常に安く、カスタマーサクセス部門が手数料の20～40％を取り、残りの60～80％が粗利益となります。

したがって、クラウドコンピューティングの 3 つのモード (IaaS/PaaS/SaaS) の中で、SaaS が最も多くのユーザーに直面しています。C サイドと同様に、アプリケーションの更新や脆弱性修復操作はソフトウェアプロバイダーによって実装および処理されます。ソフトウェアサービスはインターネット経由で取得するため、テナントはアップグレードパッケージや修復パッチをダウンロードする必要がなく、すぐに最新のソフトウェア製品を入手できるサービス方法です。

SaaSとは

マクロの観点から見ると、SaaS は、ソフトウェアプロバイダーが 1 つ以上のソフトウェアアプリケーションを一元的にホストし、これらのソフトウェアアプリケーションをインターネット経由でテナントに使用するソフトウェアアプリケーション配信方法です。分類の観点から見ると、SaaS (Software as a Service) もクラウドコンピューティングの重要な部分です。

クラウドコンピューティングには 3 つの層があり、インフラストラクチャが最下位、プラットフォームが中間、ソフトウェアが最上位にあります。

サービスとしてのインフラストラクチャ (IaaS-サービスとしてのインフラストラクチャ) : IaaS 会社は、レンタル可能なオフサイトサーバー、ストレージ、およびネットワークハードウェアを提供します。メンテナンスコストとオフィススペースを節約できるため、企業はいつでもハードウェアを活用してアプリケーションを実行できます。
Platform-as-a-Service (PaaS-Platform as a Service) : PaaS 企業は、仮想サーバーやオペレーティングシステムなど、オンラインでアプリケーションを開発および配布するためのさまざまなソリューションを提供します。これにより、ハードウェアのコストが節約され、分散したスタジオ間のコラボレーションが容易になります。Webアプリケーション管理、アプリケーション設計、アプリケーション仮想ホスティング、ストレージ、セキュリティ、アプリケーション開発コラボレーションツールなど。

大手 PaaS プロバイダーには、Google App Engine、Microsoft Azure、Force.com、Heraku、Engine Yard などがあります。最近新興企業としては、AppFog、Mendix、Standing Cloud などがあります。
BaaS (Backend as a Service) では、同社はクラウドバックエンドを統合するエッジサービスをモバイルアプリケーション開発者に提供します。

バックエンドサービスは抽象化されており、ファイルストレージやデータストレージ、プッシュサービスなど実装が難しい機能を開発者に一律に提供することで、開発者がモバイルアプリケーションを迅速に開発できるように支援する。AVOS Cloud などの BaaS プロバイダー。
Software-as-a-Service (SaaS-Software as a Service) : ほとんどの場合、Web ブラウザーを通じてアクセスされます。リモートサーバー上のアプリケーションはすべて、ネットワーク (SaaS) 経由で実行できます。

ビジネスで使用される SaaS アプリケーションには、Citrix の Go To Meeting、Cisco の WebEx、Salesforce の CRM、ADP、Workday、SuccessFactors などがあります。

IaaSは巨大企業のテキサスホールデムとなり、PaaS市場は軍閥が世界を席巻する白熱の段階に入り、SaaS市場は百派閥が争う段階だが、この段階は長くは続かない長さ。

SaaSのメリット

ソフトウェアサービスの入手方法は非常にシンプルです。SaaS は、これまでのところソフトウェアを使用する最も簡単な方法の 1 つかもしれません。従来のソフトウェアの使用方法と比較して、テナントは研究開発、導入、運用保守などの一連の複雑なプロセスを節約し、ソフトウェアにかかる時間とコストが大幅に削減されます。
- SaaS ベースの製品は、インターネットを介してテナントにソフトウェアサービスを提供します。Web テクノロジー (jQuery、Node.js など) の進歩により、Web ページのインタラクティブなエクスペリエンスが大幅に向上し、対話がよりスムーズで人間味のあるものになりました。人間とコンピューターの相互作用の効果は、従来のデスクトップアプリケーションの効果とほぼ同じです。
- SaaS ソフトウェアは従来のソフトウェアに比べて互換性が高く、従来のソフトウェアのような複数バージョンのメンテナンスやオペレーティングシステムの互換性の問題がありません。SaaS型ソフトウェアでは、テナント利用者はソフトウェアの使用中にソフトウェアの変化をほとんど感じられません。テナントユーザーがシステムにログインすると、すでに最新バージョンのソフトウェアがインストールされています。
SaaS は、クロスリージョンおよびクロスプラットフォームのソフトウェアサービスを提供できます。同時に、ソフトウェアサービスプロバイダーはソフトウェアの統合バージョン管理を実行できるため、次のような利点がもたらされます (ただし、これらに限定されません)。
- 製品の発売時間の短縮: 複数端末への対応、統合バージョン、統合アップデート
- メンテナンスコストの削減: 複数のバージョンのソフトウェアインスタンスを同時にメンテナンスする必要がないため、運用とメンテナンスの負担が軽減されます。
- アップグレードが簡単: バージョンが効果的に管理されているため、1 回のアップグレードですべてのテナントをカバーできます。
SaaS 製品を使用する場合、データのセキュリティを心配する必要はなく、銀行にお金を預けるのと同じくらい安全です。企業内に展開されるソフトウェアシステムと比較して、SaaS 製品は、ソフトウェアプロバイダーがソフトウェアセキュリティ保護のためにより多くの技術的、人的、財務的リソースを持っているため、より高いセキュリティ保証機能を備えています。

SaaS には、任意のソフトウェア SaaS を含めることができます。参考までに、一般的な分類をいくつか示します。

オフィスオンラインオフィスSaaS製品
電子メールおよびインスタントメッセージングの SaaS 製品
ソーシャルメディアSaaS製品
サードパーティ API SaaS 製品
セキュリティとアクセス制御の SaaS 製品
機械学習SaaS製品
人工知能SaaS製品
位置情報サービス SaaS 製品
データストリーミングおよびデータ取得 SaaS 製品

エンタープライズ SaaS 市場では、近年、各セグメントで多数のプレーヤーが出現しています。技術的な観点から見ると、異なる分野や異なる SaaS 製品は同じアーキテクチャコアを持たなければなりません。その中で最も重要なのは、マルチテナント (マルチテナント) のサポートです。ほとんどの企業にとって、SaaS 製品の導入は本質的にインターネットサービスのリースであるため、マルチテナンシーは SaaS の自然な特性の 1 つであり、従来のインターネットアプリケーションアーキテクチャ設計との重要な違いの 1 つとなるはずです。

SaaS 向けのマルチテナント設計

古典的な分散サービスアーキテクチャは、インターネットアプリケーションの 3 つの高い問題 (高同時実行性、高パフォーマンス、高可用性) を自然に解決します。これらは、企業が SaaS 開発の中期以降の段階で直面する問題でもあります。

リソース共有の観点から見ると、何も共有しない状態からすべてを共有する状態まで、規模のどの時点でもマルチテナンシーをサポートできます。しかし、前にも述べたように、SaaS アーキテクチャの主な目標はシングルインスタンスであり、シングルインスタンスのみで可能な限りコストを削減し、製品のスケール効果を得ることができます。したがって、いわゆる共有と分離は、古典的なアーキテクチャの下では 1 つの点、つまりリソースレベルで異なるテナントを分離する方法に焦点を当てます。

SaaS システムの技術的性質は、分散ストレージと分散コンピューティングの統合であると考えることもできます。

マルチテナンシーの実装では、多くの場合、より重要なのはストレージリソースの処理です。コンピューティングリソースは、通常、必要な場合にのみ考慮されます。これは主にストレージの「ステートフルネス」に関係していると思います。

ストレージリソースの分離は、名前空間という一言で要約できます。データベースを例に挙げると、対応するテナントの ID を各テナントのレコードに書き留めるだけで済みます。データベースとテーブルのシャーディングを考慮せずに、すべてのテナントのデータを同じスキーマに論理的に保存します。

どのようなストレージであっても考え方は同じで、処理は比較的単純で大雑把です。この合意は、エンジニアリングレベルの基礎となる枠組みで統一されるべきであることが強調されます。たとえば、AOP テクノロジを使用して、マルチテナント関連のロジックを切り出し、統合処理を行うことができます。

SaaS アーキテクチャには次の層が含まれます。

SaaS アーキテクチャのプレゼンテーション層

SaaS アーキテクチャのプレゼンテーション層クライアントは、ブラウザーまたはローカルクライアントの場合があります。ブラウザの場合、HTM15 技術、CSS3 技術、Ajax 技術などの Web インターフェイス技術、インタラクティブ技術などが含まれます。ソフトウェアクライアントの場合は、リモートデスクトップテクノロジ、ソフトウェアインタラクションテクノロジなどが含まれます。
ジョブの作業環境が異なれば、適用できるアプリケーションテクノロジも異なります。

最前線の現場 (生産、製造、倉庫、物流、流通など) では、一般に POS または WeChat ミニプログラムを使用して QR コードをスキャンし、QR コードをスキャンした後、重要なビジネスポイントをいくつかの簡単なテキストに記録できます。オペレーション。
第一線の小売店のレジ担当者向けに、ほとんどの白人ブランドのタブレットアプリが利用できるようになりました
流通、チャネル、調達、監督の間を行ったり来たりする現場スタッフは、基本的にモバイルアプリを使って業務をこなしています。
バックエンドに位置する運用担当者、人事、法務、財務担当者は、基本的にデスクトップコンピュータのWebアプリケーションを使用して業務を処理します。

SaaS アーキテクチャのスケジューリング層

SaaS アーキテクチャのスケジューリング層は、各ユーザー要求を識別し、各要求に対して AAA 認証を実行し、バックエンドビジネス処理サーバーの負荷とそのビジネス特性に基づいて合理的なスケジューリングを実行する責任があります。このアーキテクチャにより、SaaS プラットフォームを水平方向に拡張できます。さらに、ストレージとキャッシュの点でプラットフォームの水平拡張要件を満たすために、この層は優れたスケーラビリティも備えている必要があります。

クライアントの立場、品質や能力レベル、ビジネスの重点、作業環境が異なるため、機能やユーザーエクスペリエンスも異なり、バックエンドサービス層のビジネスロジックも異なります。

この層はクライアントアクセスを伴うためAPIゲートウェイのミドルウェアが必要で、比較的軽量なため（共通のビジネスロジック処理層も存在するため）マイクロサービスミドルウェア（Spring Cloudなど）を利用し、これらの異なるマイクロサービスがパッケージ化されている。迅速かつ柔軟に拡張を開始するには、Docker を使用します。フロントには、トラフィックの分割、トラフィックの制限、トラフィックのルーティングを行うことができる API ゲートウェイミドルウェアがあり、このようにして、後でマイクロサービスコンテナーを拡張する方法がフロントエンドに対して透過的になります。

API ゲートウェイミドルウェアはこのレイヤーに属しますが、クライアントからのリクエストは最初にこのレイヤーを通過し、次にビジネスロジックマイクロサービスにルーティングされます。

ただし、これら 4 つのエンドアプリケーションで処理する必要があるビジネスロジックが常に存在するため、パブリックビジネスロジック処理層と呼ばれる層もあります。これらのパブリックビジネスロジック処理レイヤーも、機能的責任に応じてサービスに分割され、Docker コンテナーに配置され、Swarm または Kubernetes クラスターによって管理されます。

SaaS アーキテクチャのビジネス層

SaaS アーキテクチャのビジネススケジューリング層によって転送されたリクエストを受信し、実際のビジネスロジックを実行する責任を負います。一般に、ビジネスロジックがどれほど複雑であっても、サーバー上で再現できます。したがって、ビジネス層は実際にはピアサーバーの列で構成され、各サーバーは同じビジネスロジックを実行します。

SaaS アーキテクチャのデータ層

SaaS アーキテクチャのデータ層は、データベースクラスターを介して、高度なリレーショナル性と高いトランザクション要件を持つビジネスデータを処理および保存します。このタイプのデータは、NoSQL を使用して解決することが難しいことが多いため、現在は従来のデータベースを使用して解決する必要があります。クラスターテクノロジー、主にビジネス特性に基づいてデータ分割計画を策定します。同時に、分散データベースは、あまり関連性のない大量のデータを保存するために使用されます。

高速クエリの分散 Redis クラスターのために、一部のデータをメモリに保存する必要があります。
一部のデータはリレーショナルデータの永続化を必要とするため、MySQL リレーショナルデータベースを使用できます。
- 分散ストレージの場合、MyCAT サブデータベースとテーブル分散ミドルウェアを MySQL の前に配置できます。
- 読み取りと書き込みを分離してパフォーマンスを向上させるために、MyCAT の前に MySQLProxy の別の層を配置して、プライマリとバックアップの読み取りと書き込みを分離できます。
一部のデータはファイル形式であり、分散ファイルシステムやオブジェクトストレージシステム(画像、オーディオ、ビデオなど) を使用して保存できます。CDN テクノロジーを使用して、これらの静的ファイルの配布を高速化することもできます。
データの中には特殊なデータ構造を有するものもありますが、これらの特殊な構造へのデータアクセスを高速化するために、時系列データベース、グラフデータベース、文書データベースなどを利用することができます。時系列データ（IMメッセージは一般的にこのような特徴を持つ）、グラフデータ（ソーシャルネットワークは一般的にこのような特徴を持つ）、大規模なテキストデータ（レビューやコメントは一般的にこのような特徴を持つ）など、

レポート統計、履歴クエリ、包括的なクエリ、およびビジネス指標の比較分析については、これらのタスクをビッグデータスイートに入れて処理し、真に高速なビジネス処理システムから分離する必要があります。

コンピューティングリソースを分離するだけでなく、ストレージリソースも分離する必要があります。ビッグデータの場合、ストレージ容量が大きく（ただしストレージアクセス性能は必ずしも高い必要はない）、メモリも大きく（計算のために大量のデータを取得する必要がある）、CPU性能も高くなければならないため、高い (集中的な計算を実行する必要がある)。したがって、統計、クエリ、分析などの機能については、サーバーのクラウドホストとクラウドストレージをアプリケーションのビジネス処理から分離する必要があります。

分離後、アプリケーション業務処理システムからデータを抽出する必要があります。

したがって、データ抽出レイヤーについては、一連の ETL ツール、内部および外部の静的データをクロールするデータクローラーエンジン、IT リソースログとアプリケーションシステム操作ログを収集する Flume、Logstash、および Splunk を用意しています。

抽出されたデータはビッグデータウェアハウスに配置でき、Hadoop HDFS、Hbase、Hive などのオープンソースミドルウェアを使用できます。

コンピューティングと処理が必要な場合は、メモリコンピューティングとストリーミングコンピューティング用の YARN または MapRedurce コンピューティングスケジューリングフレームワークの下で Spark と Storm を使用できます。

presto を使用して処理されたデータをクエリすることも、ElasticSearch を使用して検索することもできます。

最後に、いくつかの視覚化ツールを使用して、結果をグラフ形式で出力します。

この技術アーキテクチャに従って構築した後、各顧客はそれをパブリッククラウド上に個別にデプロイし、DevOps ツールを使用していくつかの新しいサービスレイヤー Docker を開始する必要があります。パブリックビジネスロジックモデルも変更する必要がある場合は、いくつかの新しいサービスレイヤーを開始します。ビジネスロジックのDocker。結局のところ、ユーザーログイン認証ゲートウェイと API ゲートウェイが分散されているため、専用のパブリッククラウドデプロイメントでもプライベートクラウドデプロイメントでも問題ありません。

マスターデータ管理モジュールには、さらにUI層、ロジック層、データ層があるため、マスターデータの各層のコード、データ、ミドルウェアをデプロイ単位にパッケージ化し、セットで自動デプロイすることができます。特殊な DevOps ツールとスクリプト、構成の変更、アップグレード。

データ層については、KV 分散データベース、分散リレーショナルデータベース、アクティブおよびスタンバイの読み書き分離ミドルウェア、サブデータベースおよびサブテーブルミドルウェア、CDN 分散、時系列データベース/ドキュメントデータベース/グラフデータベースが必要です。 API ゲートウェイ内のルート同じレベルで、DevOps ツールとスクリプト、および集中構成ミドルウェア Puppet を使用して、デプロイメントの拡張、構成の変更、アップグレードを自動化します。このようにして、異なる企業は異なる分散データベースエンジンアドレスと分散データベースストレージボリュームを指します。これにより、専用のパブリッククラウド展開とプライベートクラウド展開の両方を行うのが便利になります。

SaaS 製品に固有の欠陥

ソフトウェア制御

企業によってオンプレミスで展開されるソフトウェアとは異なり、SaaS ソフトウェアはサービスプロバイダーの Web サーバーでホストされるため、テナントはすべてのソフトウェアアプリケーションを制御できません。SaaS ベースのソフトウェアは、企業自体によって展開されるソフトウェアよりも制御性が低くなります。テナントのカスタマイズは非常に限られています。コントロール。

パフォーマンスのボトルネック

アプリケーションを共有すると、コンピューティング速度、ネットワークリソース、I/O の読み書きなどのサーバーパフォーマンスの低下が避けられず、これらすべてが深刻な課題に直面します。パフォーマンスの点では、企業内に導入された「排他モード」アプリケーションは、SaaS ソフトウェアの「共有モード」よりもわずかに優れています。

秘密の質問

テナントが SaaS 製品を選択する場合、製品のセキュリティが最初に考慮されます。データの分離、機密データの暗号化、データアクセス制御、個人のプライバシー、その他の問題など。2018 年 5 月 25 日に GDPR (一般データ保護規則) が施行されて以来、ますます多くの人々がデータセキュリティの問題に注目し始めました。この入居者の不安を最大限に解消するには、サービス事業者自身の信用力を強化し、入居者の信頼を勝ち取る必要があります。

最も重要なことは、SaaS の複雑さは通常のチームの能力を超えているということです。PaaS がうまくできるかどうかの微視的な差は、主にソフトウェア設計者とソフトウェア開発者の能力に反映されます。ジョークがあります。米国ではソフトウェア開発者はエンジニアと呼ばれますが、中国では開発者はコーダーと呼ばれます。米国の優れたソフトウェアの多くは叔父によって設計、開発されているが、中国のプログラマーは35歳を超えると失業のリスクに直面している。中国にはハイエンドソフトウェアの人材が非常に不足しており、その理由は継続的な蓄積の欠如にあります。誰もが低レベルの反復作業を行っていますが、それは組み立てラインで働く労働者と本質的に変わりません。

参考記事：

アーキテクト向けの必須スキルのガイド: SaaS (Software as a Service) アーキテクチャ設計アーキテクト向けの必須スキルのガイド: SaaS (Software as a Service) アーキテクチャ設計 - Zhihu

エンタープライズレベルの SaaS のマルチテナント設計について説明するエンタープライズレベルの SaaS のマルチテナント設計について説明する - Zhihu

なぜ中国のSaaSは儲からないのでしょうか？なぜ中国のSaaSは儲からないのでしょうか？-huxiu.com

https://www.zhihu.com/question/21641778/answer/308674603

SaaSの本質とSaaS企業の落とし穴 https://zhuanlan.zhihu.com/p/67169367

記事「クラウドコンピューティングの 3 つのモードの比較 IaaS/PaaS/SaaS/BaaS: SaaS アーキテクチャ設計分析」を転載します。
出典を明記してください:クラウドコンピューティングの 3 つのモードの比較 IaaS/PaaS/SaaS/BaaS: SaaS アーキテクチャの設計分析 -フロントエンドアーキテクチャ設計 - Zhou Junjun の個人ウェブサイト