SaaSはIaaSに依存している

どうも、エンジニアのgamiです。

以前、こんなTweetをしたことがありました。

「SaaSとはIaaSやPaaSに付加価値をつけて売るビジネスモデルである」という側面あるな。小麦粉からパンを作るように、AWSからSlackを作る。顧客への価値は、エンジニアがいなくてもシステム構築できるとか、従量課金を共同負担してリスク軽減できるなど。
クラウドサービスのサプライチェーンだ。

— gami@noteマガジン連載中 (@jumpei_ikegami) July 24, 2021

僕はいまSaaS製品を提供しているプレイドという会社で働いています。SaaS製品開発の裏側を覗くと、SaaSとIaaSやPaaSとの関係が見えてきます。

世の中の多くの記事では、IaaS/PaaS/SaaSといったクラウドサービスは、並列で語られることが多いです。しかし実際には、その中にも依存関係があります。たとえばAWSが大規模障害を起こすと、世界中のSaaSが連鎖的に障害を起こしたりします。

今回はそんなクラウドサービスの依存関係について考えます。

KARTE DatahubとBigQuery

まずはわかりやすい事例を見てみましょう。

たとえば僕が働くプレイドではKARTE Datahubというプロダクトを提供しています。Datahubでは外部のシステムから集めたデータを保存、加工し、エンドユーザーへのアクションにつなげたりデータを可視化したりすることができます。データベースとしてGoogleのBigQueryというクラウドサービスを全面的に採用し、Datahubの管理画面上からBigQueryのテーブル作成やSQLの実行ができるようになっています。

BigQueryは、大量データを簡単に蓄積し高速に分析できる、世界中で支持されるデータベース製品です。フルマネージドサービスとして提供され、利用者はサーバー運用についてほとんど意識することなく、データの管理・分析に集中することができます。

一方で多くの企業にとって、BigQueryをそのまま自社の業務に活用するためにはそれなりのハードルがあります。BigQueryにデータを自動連携したりBigQuery内のデータをグラフで可視化したりするには、BigQuery単体の機能では不十分です。他のサービスと組み合わせて利用したり、連携部分の機能を独自に開発したりする必要があります。

Datahubでは、BigQueryの機能を活かしつつ、データのインポートやエクスポートのジョブをGUIで組む機能や、SQLで抽出した結果をグラフに描画する機能なども付け加えて提供しています。Datahubの利用者は、エンジニアではなくても簡単にBigQueryの強力なデータ分析機能を活用できるようになります。言い換えれば、DatahubはBigQueryに独自の付加価値をつけて売っているともいえます。

クラウドサービスにもレイヤーがある

以前、ITシステムを実現する技術要素には様々なレイヤーがあるということを紹介するnoteを書きました。

同じように各クラウドサービスにも、カバーする技術的レイヤーの違いがあります。「IaaS/PaaS/SaaS」というクラウドサービスの分類も、そのレイヤーの違いに注目したものです。

SaaSの利用者から見れば、使いたいアプリケーションをまさに提供してくれるSaaS製品をただ使っていればそれで満足です。そのとき、PaaSやIaaSについて意識することはほとんどありません。

しかし実際には、世の多くのSaaS製品が、裏側で別のPaaSやIaaSといったクラウドサービスに依存しています。たとえばKARTE DatahubはBigQueryに依存しているし、SlackはAWSに依存しています。SaaSの利用者からすれば、AWS、GCP、Azureといった大手クラウドベンダーのIaaS/PaaSを間接的に利用していることになります。

ちなみに、IaaS/PaaS/SaaSというよくあるクラウドサービス分類もあまり自明ではありません。たとえば前述のBigQueryは、PaaSとして紹介されるケースもSaaSと呼ばれることもあります。誰がどんな目的でサービスを利用するかによって、レイヤー感の表現が変わってしまうわけです。面倒なのでこのnoteでは主に依存する側をSaaS、依存される側をIaaSと呼ぶことにします。

IaaSベンダーとSaaSベンダーの協力関係

SaaSベンダーがAWSやGCPなどのIaaSを利用する理由は単純で、その方がコストを抑えつつ自社製品開発に集中できるからです。自社で独自にサーバーを抱えてしまうと、その安定運用のためにインフラエンジニアを採用しそれなりの運用コストを払う必要があります。大抵の場合は、IaaSを利用しAWSやGCPにその辺りの運用を共通的に担ってもらった方が、コスト面でも開発者体験の面でもメリットが大きいです。

他方IaaSベンダーとしても、ユーザーを急速に伸ばしていくSaaS製品に採用されることで大きな恩恵を受けることができます。SaaSがIaaS製品に依存している場合、SaaS利用者が支払った利用料の一部はそのSaaSが依存しているIaaSベンダーに支払われます。そのSaaSのユーザー規模が拡大すれば、その分IaaS側でのサーバー利用も多くなり、IaaSベンダーとしては売上が上がります。

IaaSベンダーとSaaSベンダーは、このような協力関係にあります。IaaSベンダーは自社インフラを利用する企業やシステムを増やしたい。SaaSベンダーは自分たちの世界観を実現するアプリケーション開発に集中したい。両者がそれぞれの得意なレイヤーを担い相互に協力することによって、世界では便利なSaaS製品が次々と生み出されています。

AWSが止まれば世界中のSaaSが止まる

一方で、SaaSがIaaSベンダーのプロダクトに依存していることには弊害もあります。

最もわかりやすいのは、障害の話です。たとえば、AWSやGCPの主要サービスでも定期的に大規模障害が起きています。こうしたニュースを見ると、SaaSを含め障害を起こしたIaaS製品を使っている世界中のサービスも、IaaS側の障害に連鎖するように障害を起こしていることがわかります。

AWSのS3で異例の大規模障害、多数のウェブサイトに影響--数時間後に復旧

　この障害により、特定のS3サーバに依存するウェブサイトは、AWSを利用して保存した情報の一部またはすべてにアクセスできなくなったり、少数のサイトでロードに時間がかかったり、まったくロードできなくなったりする場合があった。「Quara」「Imgur」「IFTTT」「Giphy」「Slack」などのサイトも、この障害の影響を受けた。

また、IaaS製品に依存するということは、自社でコントロールできない領域を抱え込むということでもあります。たとえば2021年の年初に起きたSlackの障害は、AWSのマネージドサービスであるAWS Transit Gatewayが十分に自動スケールしなかったことが原因とされています。

Slack、1月の障害の原因を説明　「AWS Transit Gateway」がトラフィックの急上昇に対応できず

　Slackの今回の障害は、Slack自身ではコントロールできないAWSのマネージドサービスにおける問題がきっかけでした。これは（規模は違えども）一般のAWSユーザーにおいても何らかの形で起こりうることでしょう。
　そうなればユーザー側にできることはそれほど多くありません。できるだけ迅速に問題を発見し解決を図るため、きめこまかなシステムのモニタリングと問題の切り分けなどが重要になるのではないでしょうか。

Slackのユーザーから見れば「Slackが障害を起こした！」とSlackを責めるしかない状況でも、Slack側から見れば「AWSが障害を起こしたから仕方ない」とか「AWSのマネージドサービスの中身までは弄れない」と言いたくなるような事情があったりします。もちろんAWSのサービスを使っているのもSlackの選択なので、難しいところではありますが。

障害の話以外にも、たとえばAWSやGCPが主要サービスの利用料金を一気に引き上げるようなことがあれば、それを利用するSaaS側のコストも一気に上がります。幸いにして、IaaS業界は寡占ではあるが独占とまでは言えない状況で、大規模な値上げが頻発するような事態にはなっていません。ただし、多くのSaaSベンダーが実質的にAmazonやGoogleに事業の生命線を握られているという状況をどうリスク評価するかについては、色々と議論がありそうです。

こうした障害や価格改定のリスクについては、たとえば複数ベンダーのIaaSを併用するマルチクラウド戦略によって軽減することができます。とはいえAWSとGCPで提供されるサービスに完全な互換性があるわけでもないので、「AWSの利用を止めてすぐにGCPで全く同じサービスを提供する」といったことが簡単にできるサービスも多くないでしょう。

SaaSベンダーはどこまでIaaSに依存するべきか？

ここまで書いてきたようなIaaS依存のメリットとデメリットは、SaaSベンダーに限らず全てのソフトウェア開発企業が意識すべきことです。他方、SaaSベンダーは多くの企業を顧客に持ち、サービスの障害発生時や料金改定時の説明責任をそれら顧客企業に果たす必要があります。自社製品の提供にあたってIaaSというコントローラブルではない領域を抱え込むことで、こうした顧客企業への説明が難しくなるという特殊なデメリットもあるといえます。

もちろん、IaaSへの依存度を低くするために独自にオンプレサーバーを立てることもできます。たとえばDropboxは2015年に顧客データの格納部分でAWSの利用をやめ自社データセンターに移行しています。

AWSをやめたDropbox、自社DCに移行した背景とメリットを語る

AWSのようなクラウドからあえて自社設計・運用に移行した理由について保坂氏は、「AWSはあくまで汎用性を重視したサービス。Dropboxは自社サービスに向けて専用にチューニングしたかった」と語る。

またSalesforceも、自社独自のデータセンターを構えていることで知られています。

セールスフォースが国内2カ所目のデータセンターを稼働、AI機能強化へ

一方で、DropboxやSalesforceのような一部の例外を除けば、大抵はIaaSに依存するデメリットよりもメリットの方が大きくなります。

たとえば自社でデータセンターを抱え込むためには、想像以上に様々なコストや時間がかかります。データセンターの建設コスト、インフラエンジニアの採用・育成コスト、サーバー運用ノウハウの蓄積などなど。こうしたコストを支払わなくても、AWSの管理画面からボタンをポチポチ押すだけで世界最高レベルのインフラが使えるとしたら、大抵はAWSを使う方がメリットが大きいです。また、障害に関しても、AWSやGCPを使わずに独自にシステム構築した方が頻度を抑えられるかというと非常に怪しいところです。

こうした状況の中で、新興SaaSベンダーがあえてIaaS依存を嫌って自前主義に走ったところで、大抵は開発スピードが落ちたりコストが大幅に嵩んだりして、IaaSを採用する競合に対する競争優位性を失ってしまいます。非エンジニアが想像する以上に、現在のシステム開発トレンドはAWSやGCPの利用を前提としたものになっています。

そもそもSaaSのIaaS依存の話に限らず、どんな事業も他社の何かのサービスに依存しています。結局は、自社の競争優位性につながらない部分では他社サービスにうまく依存しつつ、できる範囲で悪影響を抑えるしかありません。SaaSベンダーもSaaSユーザーも、こうした状況を踏まえることで初めて自社のシステム戦略についての建設的な議論ができるようになるんじゃないかなーと思います。