The Twelve Factorで実践するSaaS開発

The Twelve-Factorで実践するSaaS開発

代表プロフィール
Copyright © Alterbooth Inc. All Rights Reserved. 2
株式会社オルターブース
代表取締役
小島淳（Atsushi Kojima）
1976年千葉県柏市出身。 10代から20代前半までハードコアパンクに没頭し
全国をツアーするバンドマンとして活躍。
バンド解散後、IT業界に転身しレガシーシステム開発に従事し、2007年に都
内大手MSPへ転職。技術部門、プリセールス部門、コンサルティング部門の
責任者として多くのWebシステムを担当。
2012年福岡へ移住しクラウドコンサルタントとして活動、2015年に株式会
社オルターブースを創業し、「つまらない世界からもっと刺激のある世界へ
変化させよう︕」をスローガンにフルスタック開発を展開している。

Cloud Adoption Framework
Well-Architected Framework

CAFのライフサイクル
戦略
業務上の正当な理由と
導入による予想される
結果を定義する。
計画
ビジネスの結果に合わ
せて実行可能な導入
計画を調整する。
準備完了
計画された変更のため
にクラウド環境を準備
する。
移行
既存のワークロードを移行して最新
化する。
ガバナンス
環境とワークロードを管理
する。
管理
ソリューションおよびハイ
ブリッドソリューションの
ための運用管理。

Well-Architected Framework
W-Aは、ワークロードの品質向上に使用できる一連の基本原
則です。フレームワークは、5 つの柱で構成されています。
コストの最適化もたらされる価値を最大化するためのコスト管理
オペレーショナルエクセレンス運用環境でシステムを継続的に動作させる運用プロセス
パフォーマンス効率負荷の変化に対応するためのシステムの能力
信頼性障害から回復して動作を続行するシステムの能力
セキュリティ脅威からアプリケーションとデータを保護すること
Azureのベストプラクティスと特定のビジネスの優先順位に照らしてワークロード
を最適化できるように支援することを目的としている。

CAFとW-Aの違い
CAFとW-Aは一見同じようなクラウド導入に関するものに見
えますが、提案するポイントは違います。
行動
フェーズ課題の顕在化解決提案課題の克服新しい環境継続的改善
システム運用
障害
改修
監視
テスト
自動化
CAF W-A
3rd Party

SaaS開発はじめてなんだけど・・・・

誰と作るか、何を作るか、どうやって作るか、どうやって売るか
スクラムチームアイデア
ボーディング
アーキテクチャービジネスモデル
SaaSではこの2つの関係がとても重要です。

例えば、以下のようなアーキテクチャーの場合、どのような
ビジネスモデルを持っているか想像できますか？
web1 web2 mail
db1 db2 Analytics
Web＋DBが基本構成となっているインフラ構成図です。
WebもDBも冗長化されています。
メールサーバーと解析サーバーもあります。
この構成の問題点は・・・・・・・
モノリス構造であるためビジネスの変化に
合わせずらい。

ではこれはどうでしょう？
恐らく何かのユースケース、フローだと
思いますがここからどのようなビジネス
なのか想像できますか？

どうやって作るのか、を無視したSaaSは必ず破綻する。
では、どのようにしてSaaSを作っていくのか。

The Twelve-Factor AppはSaaS開発におけるベ
ストプラクティスです。

セットアップ自動化のために宣言的なフォーマットを使い、プロジェクトに新しく加わった開発
者が要する時間とコストを最小化する。
下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する。
モダンなクラウドプラットフォーム上へのデプロイに適しており、サーバー管理やシステム管理を
不要なものにする。
開発環境と本番環境の差異を最小限にし、アジリティを最大化する継続的デプロイを可能にする。
ツール、アーキテクチャ、開発プラクティスを大幅に変更することなくスケールアップできる。
Twelve-Factorの方法論は、どのようなプログラミング言語で書かれたアプリケーションにでも適
用できる。また、どのようなバックエンドサービス（データベース、メッセージキュー、メモリ
キャッシュなど）の組み合わせを使っていても適用できる
https://12factor.net/ja/から抜粋
。

The Twelve-Factor App on Azure
I. コードベース
II. 依存関係
V. ビルド、リリース、実行
III. 設定
IV. バックエンドサービス
VI. プロセス
VII. ポートバインディング
VIII.並行性
IX. 廃棄容易性
X. 開発本番一致
XI. ログ
XII. 管理プロセス

超ざっくり概要
1. バージョン管理される1つのコードベースと複数のデプロイ
2. 依存関係を明示的に宣言し分離する
3. 設定を環境変数に格納する
4. バックエンドサービスをアタッチされたリソースとして扱う
5. ビルド、リリース、実行の3つのステージを厳密に分離する
6. アプリを1つ又は複数のステートレスなプロセスとして実行
7. ポートバインディングを通してサービスを公開する
8. プロセスモデルによってスケールアウトする
9. 高速な起動とグレースフル停止で堅牢性を最大化する
10.開発、ステージング、本番環境をできるだけ一致させた状態を保つ
11.ログをイベントストリームとして扱う
12.管理タスクを1回限りのプロセスとして実行する
ちなみに12Factorをオンプレ、もしくはIaaSでやろうとすると非常に難しい
のでPaaSでやりましょう。

概略
バージョン管理されている1つのコードベースと複数のデプロイ
Gitでコードを管理する
1. アプリケーション：ソースコード
2. インフラストラクチャ：Infrastructure as Code, Config, etc.
Factor1．コードベース

コードベース
Twelve-Factorに適合した状態
本番
ステージング
開発
コードベース
コードベースが複数ある場合
本番
ステージング
開発
それぞれにTwelve-Factorが適用できる

コードベース
1つのコードベースを
複数のアプリケーションで共有している場合
アプリA
アプリB
アプリC
Twelve-Factorではない
コードベース
解決策
共通コードをライブラ
リに分解し、パッケー
ジにして配布する

概略
• アプリケーションの設定は、デプロイ（ステージング、本番、開発環境など）の間
で異なり得る唯一のものである。
• 定数ではなく環境変数に格納し、コードから分離する
Factor3．設定

環境変数分離の方法
• Azure App Serviceの場合はAzure管理ポータルより設定可
• 仮想マシンの場合は、通常通り.envをアプリ内に配置する。

Access
Policy
環境変数キー
キーコンテナー
App Services Azure Active
Directory
Key Vault
Managed ID 認証認可
環境変数などのsecretを安全に取り扱うためのサービス
• Web Appsのアプリケーション設定から行う
• App Configurationを使う
• Azure Key Vaultを使う
• Managed Identityを使う

概略
アプリケーションを1つもしくは複数のステートレスなプロセ
スとして実行する
• キャッシュ
• セッション
• ログなど
Factor6．プロセス
ASP.NET Coreの分散キャッシュの方式
・メモリ (AddDistributedMemoryCache)
・SQL Server (AddDistributedSqlServerCache)
・Redis (AddDistributedRedisCache)

PaaSではまず最初に考慮すべきはスケーリングであり、IaaSのような複雑なス
ケーリングはできません。よって、アーキテクチャーを「ステートレス」にする
必要があります。
フロントエンドバックエンドデータストア
ステートフル
1つのサーバー（アプリケーション）にデータ保管含めすべてを内包している。
フロントエンドバックエンドデータストア
ステートレス
データは外部へ保管。アプリケーションとデータを疎結合する。

クラウドインスタンス（IaaSやPaaS）にはデータを置かない。
データを内包してしまうとプロセス管理が複雑になる。
Web Apps Blob
SQL Database
Redis Cache
※セッションスティッキーを使うとロードバランサーの
管理までやらなくてはいけないためKVSを使うべき

概略
• ポートバインディングを通してサービスを公開する
• Webアプリケーションとして公開可能な自己完結形式
• ビルトインサーバーがあること
• ASP.NET Core : Kestrel (HTTP(S)/WebSocket/Reverse
Proxy)
Factor7．ポートバインディング

.NET Coreの場合
環境ごとに異なるサーバー設定が不要になる。
またプロキシとの連絡はTCP/UDPのみとしUnix Socketやファイルシステムを使う
もの、過度に抽象化されたプロトコルは使わないこと。
Kestrel Application
Code
HttpContext
ASP.NET Core Application
Kestrel Application
Code
HttpContext
ASP.NET Core Application
http/https
Reverse Proxy
Server
IIS, Nginx, Apache
http/https http

概要
• プロセスの起動時間は最小化するよう努める
• インフラの突然の死に対して堅牢であるべき
• ASP.NET Core : IApplicationLifetimeインターフェイス
• ApplicationStarted : 完全に起動している状態
• ApplicationStopped : シャットダウンに完了した状態
• ApplicationStopping : シャットダウンを実行している状態
Factor9．廃棄容易性
コードのデプロイやプロセスの再配置 (スケーリング) のため
にプロセスはいつでも再起動される可能性があり、それに備え
なければならない。

コンテナーを活用し廃棄容易性を高める。
• コンテナは原則ステートレス・シェアードナッシングとする
• 永続化領域 (VOLUME) は慎重に扱う必要がある
• 例外的にステートフルなコンテナ (データベースなど) を扱う場合は、その他のス
テートレスなコンテナとは明確に分離する
• コンテナ内で起動するプロセスはデーモン化しない
• コンテナプロセスの管理はコンテナの外側でコンテナオーケストレーションシ
ステムが担う
• コンテナは SIGTERM を正しくハンドリングする
• コンテナの起動時間を最小化する

Azureで取り扱うコンテナーサービス
Web Apps Azure Container Instances Azure Kubernetes Services
Web Apps上でコンテナ
を稼働させたい場合
コンテナをスタンドアロー
ンで稼働させたいとき
マイクロサービス基盤とし
てコンテナを使いたいとき
規模小大

概要
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
• ソースコード
• 設定：Factor3
• バックエンドサービス：Factor4
• Azureを使うなら開発環境は各種エミュレーターを使う
Factor10．本番/開発一致

常に同じ環境を提供する
クラウド上インスタンスの本番・ステージング一致は比較的容易。
Web Appsにおいてはスロットという内部インスタンスを作成することが可能。
スロット1 スロット2
スワップ
Azure Web Appsではスロットの
切り替えをすることで本番/ス
テージングの環境替えをすぐに実
行可能。

ブルーグリーンデプロイメント
ブルーグリーンデプロイメントとは、スロットといわれるシステム区画を自動的に入
れ替えてアプリケーションリリースする方法で、Immutable Infrastructureでは基
本的な構成といわれている。
ロードバラ
ンサー

概要
• ログを時系列に並べたイベントとして扱う
• ×ファイル出力 ○標準出力
• AzureにホストするWebアプリケーションであればAzure Application Insightsに
ログを送る
Factor11．ログ

ログを標準出力する（.NETの場合）
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureLogging((hostingContext, logging) => {
logging.AddConfiguration(…);
logging.AddConsole();
logging.AddDebug();
})
.UseStartup<Startup>();

ログをApplication Insightsに送る（.NETの場合）
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseApplicationInsights()
.ConfigureLogging((hostingContext, logging) => {
logging.AddConfiguration(…);
logging.AddConsole();
logging.AddDebug();
})
.UseStartup<Startup>();

サーバーログの収集（仮想マシンの場合）
Azure Storage
Agent
Agent
Agent
Server

サーバーログの収集（Web Appsの場合）
Web Apps
Application
Insights
Azure
Monitor Diagnostic Monitor
Log Search
Malware Protection
Alert

The Twelve-Factor Appはクラウドネイティブ化するための指
針、方法論。
クラウドの力を最大限に引き出すためには、従来のインフラ思
考ではなくアプリケーション内でクラウドをネイティブに使う
ための実装を行う必要があります。

つまらない世界からもっと刺激のある世界へ変化させよう！

The Twelve Factorで実践するSaaS開発

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Twelve Factorで実践するSaaS開発

Similar to The Twelve Factorで実践するSaaS開発 (20)

More from Atsushi Kojima

More from Atsushi Kojima (15)

The Twelve Factorで実践するSaaS開発