「どうやって作るか」「どうやって売るか」がないSaaSは、必ず破綻する　Azure実装のベストプラクティス「The Twelve-Factor App」

「Cloud Adoption Fram」と「Well-Architected Framework」をおさらい

小島淳氏：では、僕は「The Twelve-Factorで実践するSaaS開発」の話をしていこうと思います。

まず自己紹介です。株式会社オルターブースの代表をやっている小島と申します。よろしくお願いします。僕はMicrosoft MVPではなくて、Microsoft Regional Directorというものになっていて、Azureの啓蒙活動をしています。

先ほど他のメンバーからWell-Architected FrameworkやCloud Adoption Frameworkの話がありました。このフレームワークが何に使えるかというと、クラウドの導入やアプリケーションの設計に使えるわけですね。

ちょっとおさらいです。まずCloud Adoption Frameworkです。戦略、計画、準備完了、移行、こんなものがあって、ガバナンスと管理が全体的に動いていくフェーズが作られています。それぞれフレームワークやツールテンプレートが用意されているので、それらを使って中の計画を作って実践していくのがCloud Adoption Frameworkですね。

対象はどちらかというとエンジニアよりも、もう少しビジネス寄りの方が対象かなと思っています。

次に、Well-Architected Framework。これは5つのフレームワーク、5つの柱で成り立っています。コストの最適化、オペレーショナルエクセレンス、パフォーマンス効率、信頼性、セキュリティ。こんなものがあって、Azure自体のアーキテクチャのベストプラクティスが入っているわけですね。Well-Architected Frameworkは、エンジニアが車輪の再発明をしないようにするための設計の材料になると思っています。

これらがどういうところに使われるかについて話します。これはクラウド導入に対してのプロセスの一覧なんですが、まずCAF（Cloud Adoption Framework）については最初の部分ですね。クラウド導入するときに、データリストアの評価して、戦略を作って、どうやって移行するか、移行したあとはどうするか、そういったものを考える場なので、最初なんですよね。

解決提案には、我々のサービスである「KOSMISCH」を使ったりするんですが、新しい環境を考えるときは、このCAFの中から連動して、Well-Architected Frameworkに入っていって、設計して合理化をしていく。こんな流れが実際の流れだと思います。なので、CAFとWell-Architected Frameworkを同一で語るとちょっと混乱するので、分けたほうがいいと僕は思っています。

SaaS開発に重要なのは「どうやって作るか」「どうやって売るか」の2点

今日のテーマの1つのSaaS開発。未来のアーキテクトと言うと、かなり大きなことを言っているように見えるんですが、SaaS開発を始めたいという方もけっこういると思うんですよね。

初めてなんだけど、何からやろうか。もちろんアプリケーション設計・開発はやっているんですが、SaaSというのはクラウドサービスなので、それを実践するうえで必要な技術導入、設計の話など、どういうふうにやっていけばいいんだろうと。

さっきのCloud Adoption FrameworkだったりWell-Archi（Well-Architected Framework）を使ってもいいんですが、やっぱりかなり難しいですよね。いきなりこれらを使うのってなかなか難しいんですよ。誰と作るか？　何を作るか？　どうやって作るか？　どうやって売るか？　こんなフェーズがあるとすれば……SaaSにおいてはすべてが大事なんですよ。ただ、SaaSのアプリケーション設計においては、どうやって作るか、どうやって売るか、この2つが非常に重要になっています。

ここで先ほどのCAFやWell-Archi（Well-Architected Framework）をうまく採用して、この分を埋めていくんですが、もう少しミニマムに考えていきましょうか。例えば以下のようなアーキテクチャの場合、どのようなビジネスモデルを持っているか想像できますか？

これはデータベースが並んでいるだけですね。インフラ構成図です。昔はよくこんなのが作られて、語られたときが多かったと思うんですよね。もしかしたら、みなさんまだこういうインフラ構成図を持って「このサービスはこうでこうで」って説明されているかもしれないですが、はっきり言って「なんのこっちゃ？」です。この構成からは、どのサービスがどういうふうに影響を受けているのかがぜんぜんわかりませんよね。

「モノリス」って言っていますが、要はわからないんですよ。わからないものはわからないとしか言いようがなくて、サーバーだけ並べたってビジネスの変化に合わせづらいわけですね。

一方、これはどうですか？　こういったユースケースですね。これはたぶんなにかのユースケースフローだと思いますが、ここからどんなビジネスか想像できますか？

これはさっきとガラリと変わって、アプリケーションの中のユーザーの動きだけを模した図です。実際、こういうものもよく出てきますよね。「ユースケースがあるのでアプリケーションの動きわかるでしょ？」というパターン。わかるわけないですよね、そんなの。ねぇ。

「The Twelve-Factor」は当たり前のことをしっかり作っているガイドライン

結局アプリケーションアーキテクチャとしての絵、それとビジネスアーキテクチャとして絵、どちらも必要になってくる。これらの整合性を合わせて設計して導入するのがSaaSだと思います。

こういったものを無視したSaaSは必ず破綻します。必ず破綻するというとちょっと大げさですが、どっかで絶対つまずいちゃうんですよ。特にスタートアップの場合は、このつまずきが致命傷になる可能性が高いです。なので、SaaSを作っていくときは、ある程度ガイダンスを用意しておいたほうがいいんじゃないかと思っています。

そこで出てくるのがこれからお話しする「The Twelve-Factor App」です。「The Twelve-Factor App」はSaaS開発におけるベストプラクティスだと言われています。

今日は「ベストプラクティス」という言葉がやたら飛び交いますが、ベストプラクティスというのは、あくまでも事例です。なので、そこから先は自分で考えるべきだと僕は思います。そのまま真似したってうまくいきません。うまく真似するためのガイダンスだと思ってもらったほうがいいと思います。

The Twelve-Factor Appはもともと「Heroku」というクラウドのエンジニアの方たちが作った概念だと言われています。セットアップ自動化のための宣言的フォーマットを使って、プロジェクトに新しく加わった開発者が要する時間とコストを最小化します。開発環境そのものをテンプレートするわけですね。

あと、下層のOSへの依存関係を明確化して、実行環境間での移植性を最大化します。これはプラットフォームに依存しないためです。また、モダンなクラウドプラットフォーム上のデプロイに適していて、サーバー管理やシステム管理を不要なものにします。

それと開発環境と本番環境の差異を最小限にして、アジリティを最大化する継続的デプロイを可能にします。DevOpsを入れることで、ツール、アーキテクチャ、開発プラクティスを大幅に、変更することなくスケールアップします。これこそ、クラウドの目的ですよね。

当たり前のようなことなんですが、この当たり前のことをしっかりとガイドとして作られているのがTwelve-Factorです。なのでTwelve-Factorは、どのようなプログラミング言語で書かれたアプリケーションでも適用できます。そして、バックエンドサービス、データベース、メッセージキュー、メモリキャッシュ、さまざまなストアのサービスも含めて、どんな組み合わせを使っていても適用できるというのが特徴です。

どういうことを言いたいかというと、言葉としてメチャクチャ抽象化されているってことですね。Twelve-Factorの方法論はすごく抽象化されています。抽象化されているので、そこから実際に実装するという行為はけっこう難しいです。「どうやってAzureで実装するの？」というところを今日は話していこうと思います。

「Twelve-Factor」のざっくり概要

Twelve-Factorは、1～12までFactorがあって、それぞれカテゴリがあります。Azureのアイコンが入れ替わっていますが、AzureのPaaSのサービスやいろいろなサービスで実現できるところをバーって入れてあります。

実際にはもっと深いところにあって、Well-Archiなどを採用しながらTwelve-FactorのそれぞれのFactorを埋めていくというやり方がいいかなと思っています。

今日は全部を説明する時間がぜんぜん足りないので、かいつまんで説明していきたいと思います。その前に、このTwelve-Factor Appの超スーパーざっくり概要を話そうと思います。

みなさんの向かって右側にポスターがありますね。このポスターをちょっと見てもらいたいなと思います。ポスターのまず1、Buildから始まります。BuildのところにはCodebaseと書いてありますね。この場合、1、バージョン管理される1つのコードベースと複数のデプロイです。これが最初のFactorです。1つのコードベースを使いましょう。

そして2、依存関係を明示的に宣言して分離します。これが下の部分ですね。「Manifest」「Dependency」と書いてある部分です。そして環境変数を格納します。環境変数は別の部分に格納しましょうと明示的に言っています。

次にリリースです。バックエンドサービスをアタッチしたリソースとして扱うとか、ビルド・リリース・実行の3つのステージを厳密に分離するとか、アプリを1つまたは複数のステートレスなプロセスとして実行するとか、いろいろがここ書いてあります。

この12個のFactorをメチャクチャシンプルにまとめたのがこのポスターなんですが、このポスターだけを見ても、はっきり言ってわかりづらいです。ぶっちゃけ、このポスターだけを見てわかる人はぜんぜんいないと思います。なので、ここから先はそこらへんの話にゴーッと入っていこうと思います。

このポスターの話をしていくと、これだけで20分くらい使っちゃいそうなので、このへんにしておきます。この矢印見ておいてください。コードベースは1つの環境にする。1つのコードベースがたくさんの環境にあったらダメですよみたいなことを言っています。バックエンドサービスなどもそうですね。

では、実際にこのTwelve-FactorのFactorの中身の話をしていきましょう。Factorの中身の話はけっこうおもしろいですよ。

（次回へつづく）