The Twelve-Factor App
✤
元は
Herokuのエンジニアが公開したモダンな
Webアプリケーション
開発のための方法論
⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは一 読しておくべき
✤ Docker
によるアプリケーション開発や
Lambdaのようなサーバレスコ
ンピュートの普及に伴い、改めて重要性が増しつつある
✤ URL
http://12factor.net/
http://12factor.net/ja/
（日本語訳）
The Twelve-Factor App
✤ Codebase -
コードベース
-⎻ バージョン管理されている1つのコードベースと複数のデプロイ
⎻ デプロイされているアプリとコードベースは常に1:1であるべき
✤ Dependencies -
依存関係
-⎻ 依存関係を明示的に宣言し分離する
⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しな いこと
⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱 されるべき
The Twelve-Factor App
✤ Config -
設定
-⎻ 環境によって異なる設定はOSレベルの環境変数によって注入されるべきである
✤ Backing services -
バックエンドサービス
-⎻ アプリケーションがネットワーク越しに利用するようなサービスはすべてリ ソースとして扱う
⎻ データベースやメッセージブローカーといったものはアタッチされたリソース として扱う
⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの 切り替えはリソースハンドルの切り替えとする
The Twelve-Factor App
✤ Build, release, run -
ビルド、リリース、実行
-⎻ ビルド、リリース、実行の3つのステージを厳密に分離する
⎻ それぞれのリリースは一意のIDを持つべき
✤ Process -
プロセス
-⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実行す る
⎻ プロセス間で何も共有はしない
⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを用いる
⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとし て扱い、永続化されることを期待しない
The Twelve-Factor App
✤ Port binding -
ポートバインディング
-⎻ ポートバインディングを通してサービスを公開する
⎻ Webアプリケーション自体がサービスとなってリクエストを待ち受けること
⎻ リクエストを受け付ける何かを用意するのではなく、アプリに組み込まれるべき
✤ Concurrency -
並行性
-⎻ プロセスモデルによってスケールアウトする
⎻ 水平方向へのプロセスのスケールアウトによって並行性を担保する
The Twelve-Factor App
✤ Disposability - 廃棄容易性
-⎻ 高速な起動と簡単な廃棄
⎻ グレースフルシャットダウン
✤ Dev/prod parity - 開発/本番一致
-⎻ 開発、ステージング、本番環境をできるだけ一致させた状態を保つ
⎻ CI/CDは各環境が揃っていることで実現される
✤ Log - ログ
-⎻ 出力ストリームの保存先やルーティングには関与しない
⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない
⎻ シンプルに標準出力に吐き出すだけ
⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に用意 する
✤ Admin processes - 管理プロセス
-⎻ 管理タスクを1回限りのプロセスとして実行する
その他のベストプラクティス
✤
メモリ設定
⎻ メモリ設定はパフォーマンス設定と同義、メモリサイズと比例してCPU能力も割り当 てられる
⎻ コストを気にしがちだが、メモリを増やすことで処理時間がガクンと減り、結果的に コストはそれほど変わらずとも性能があがることもある
⎻ 最小から少しずつ調整し、変更しても性能が変わらない値が最適値
✤ VPC
は必須でない。必要でない限り使用しない
⎻ 使うのはVPC内のリソースにどうしてもアクセスする必要があるときだけ
⎻ 同期実行が必要な箇所やコールドスタートを許容できない箇所ではなるだけ使わない
⎻ VPC内のリソースとの通信が必要なのであれば非同期にする
⎻ RDBMSのデータ同期が必要なのであればDynamoDB StreamsとLambdaを使って非同期に
その他のベストプラクティス
✤ Design for failure
⎻ リトライ
⎻ Dead Letter Queueの活用（非同期の場合）
✤
冪等性はお客様のコードで確保する必要がある
⎻ AWS Lambdaで保証しているのは最低1回実行することであり1回しか実行しな いことではない
⎻ 同一イベントで同一Lambdaファンクションが2回起動されることがまれに発生 する
⎻ DynamoDBを利用するなどして冪等性を担保する実装を行うこと
その他のベストプラクティス
✤
コールドスタートについて
⎻ 安定的にトラフィックが発生している場合、コールドスタートの発生頻度は多くない
⎻ コールドスタートによる遅延が一切許容できないのであればそもそもLambdaをやめる ことも検討を
⎻ コールドスタートの時間は言語の特性と大きく関連する
✤
ローカル実行について
⎻ Lambdaで使われているAMIは公開されている
⎻ ファンクションといってもただのプログラムなのでローカル環境でも容易に実行でき る
⎻ Contextとイベントを再現する必要があるが、単に必要な値を入れたオブジェクトを用 意するだけいい
⎻ イベントのサンプルは公開されている