The Twelve-Factor Appで考えるAWSのサービス開発

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
The Twelve-Factor App で考える
AWS のサービス開発
31 October 2018
Amazon Web Services Japan Solutions Architect
Fumihiko Hata ,Yuki Chiba

スピーカー紹介
千葉悠貴
アマゾンウェブサービスジャパン株式会社
シニアソリューションアーキテクト
畑史彦
アマゾンウェブサービスジャパン株式会社
ソリューションアーキテクト

What is The Twelve-Factor App

The Twelve-Factor App
2011年にHerokuのエンジニアが提唱した、アプリ開発の方法論
• セットアップ自動化のために宣言的なフォーマットを使い、プロジェクト
に新しく加わった開発者が要する時間とコストを最小化する。
• 下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する。
• モダンなクラウドプラットフォーム上へのデプロイに適しており、サー
バー管理やシステム管理を不要なものにする。
• 開発環境と本番環境の差異を最小限にし、アジリティを最大化する継続的
デプロイを可能にする。
• ツール、アーキテクチャ、開発プラクティスを大幅に変更することなくス
ケールアップできる。
サービスとして動くアプリを開発しているすべての開発者が対象

I. コードベース
バージョン管理される1つのコードベースと複数デプロイ
II. 依存関係
依存関係を明示的に宣言し分離する
III.設定
設定を環境変数に格納する
IV.バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
V. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
VI.プロセス
アプリを1つ又は複数のステートレスなプロセスとして実行
VII.ポートバインディング
ポートバインディングを通してサービスを公開する
VIII.並行性
プロセスモデルによってスケールアウトする
IX. 廃棄容易性
高速な起動とグレースフル停止で堅牢性を最大化する
X. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
XI. ログ
ログをイベントストリームとして扱う
XII.管理プロセス
管理タスクを1回限りのプロセスとして実行する
https://12factor.net/ja/

What is Cloud

What is Cloud
• 初期投資不要
• 使った分にだけ支払い
• 柔軟なリソースの選択
• 迅速なリソースの確保/解放
それによる素早い開発サイクル
→ システムの付加価値の向上に、より専念

What is Cloud
• 初期投資不要
• 使った分にだけ支払い
• 柔軟なリソースの選択
• 迅速なリソースの確保/解放
それによる素早い開発サイクル
→ システムの付加価値の向上に、より専念
インフラストラクチャは
柔軟・迅速・高コスト効率
その上で動くアプリケーションは？

What is Cloud
クラウド（インフラストラクチャ）には
柔軟性や機動力やコスト効果の高い仕組みが備わっている
それらを十分に活かすアプリケーション構成が
クラウドの力をさらに引き出す

アプリケーションを疎結合にするための指針・方法論
疎結合とクラウドの相性
疎結合なアプリケーションは・・・
• デプロイが容易
• 起動 / 停止 / 中断が容易
• スケールアウト / スケールインが容易

バージョン管理されている1つのコードベースと
複数のデプロイ

コードベースとアプリケーションの間には、常に1対1の関係がある。
• コードベース : アプリケーションが N : 1
→ 分散システム
• コードベース : アプリケーションが 1 : N
→ コードベースの様々なバージョンが複数のアプリケーションから参照され
る状態を管理する必要
→ コードをライブラリに分離
アプリケーションごとにただ1つのコードベースが存在するが、アプリ
ケーションのデプロイは複数存在する。
• デプロイごとに異なるバージョンがアクティブであるかもしれないが、
コードベースはすべてのデプロイを通して同一である

AWS CodeCommit
Secure, scalable, managed Git source control
スターンダードな Git tool が利用可能
Amazon S3 の Scalability, availability, durability
をストレージに活用
Encryption at rest with customer-specific keys
レポジトリサイズの上限なし
Post commit hooks で SNS/Lambda を呼び出し

II. 依存関係

II. 依存関係
https://12factor.net/ja/dependencies
システム全体にインストールされるパッケージが暗黙的に存在することに
決して依存しない
• すべての依存関係を依存関係宣言マニフェストで完全かつ厳密に宣言する
• 実行時には依存関係分離ツールを使って、取り囲んでいるシステムから暗黙
の依存関係が“漏れ出ない”ことを保証する
• 依存関係の指定は、本番環境と開発環境の両方に適用する
いかなるシステムツールの暗黙的な存在にも依存しない
• アプリ外のツールに依存しない(OSにプリインストールされているcurlなど)
• 将来に渡ってそのツールが環境に存在するか、互換性のあるバージョンが提供
され続けるかはわからない
• アプリケーションに必要な機能はアプリケーション内で実装する

依存関係宣言マニフェストと依存関係分離ツール
言語分離ツール宣言マニフェスト
Node.js npm package.json
Ruby bundler gemfile
Python pip requirements.txt
Java mvn package pom.xml
C# NuGet .nuspec
Go dep manifest.json
SAM sam package template.yml
Docker docker build Dockerfile
Ansible ansible-playbook playbook
Infrastructure as Codeでも同様

SAM (Serverless Application Model)
• サーバレスアプリに最適化したAWS CloudFormationの拡張
• サーバレスアプリ用の新たなリソースタイプ
• 関数 (Lambda Function)
• API (API Gateway)
• テーブル (DynamoDB)
• CloudFormationがサポートしているすべてのものをサポート
• 既存のファンクションをSAMテンプレートとしてエクスポート可能
• オープンな仕様（Apache 2.0）
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-ct-example-use-app-spec.html

SAM − デプロイの流れ
Step1 :
SAMの表記方法でCloudFormation
テンプレートを作成する
Step2 :
cloudformation packageコマンドで
パッケージ化しS3バケットに格納する
Step3 :
cloudformation deployコマンドで
パッケージをデプロイする
AWSTemplateFormatVersion: '2010-09-09’
Transform: AWS::Serverless-2016-10-31
Resources:
FunctionName:
Type: AWS::Serverless::Function
Properties:
Handler: handler
Runtime: runtime
CodeUri: s3://bucketName/codepackage.zip
aws cloudformation package ¥
--template-file /path_to_template/template.yaml ¥
--s3-bucket bucket-name ¥
--output-template-file packaged-template.yaml
aws cloudformation deploy ¥
--template-file /path_to_template/packaged-template.yaml ¥
--stack-name my-new-stack ¥ --capabilities CAPABILITY_IAM

III. 設定

III. 設定
アプリケーションの「設定」は、デプロイ（ステージング、本番、開発
環境など）の間で異なり得る唯一のもの。
• 設定をコードから厳密に分離すること
• この“設定”の定義には、アプリケーション内部の設定は含まない
• 認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソース
にすることができるか
設定を「環境変数」に格納する。
• 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる
• 環境変数は、独自形式の設定ファイルやJava System Propertiesなど他の設定
の仕組みとは異なり、環境変数は言語やOSに依存しない標準
• 環境変数は粒度の細かい管理であり、それぞれの環境変数は互いに直交

AWS Systems Manager
Run Command Maintenance
Window
Inventory
State Manager Parameter Store
Patch Manager
Automation
デプロイ、構成
および管理
トラッキングと
アップデート
共有コンポーネント分類と可視化
Resource Groups
Insights
Dashboard

Parameter Store
• 設定データ管理と機密管理のための安全な階層型ストレージ
• パスワード、データベース文字列、ライセンスコードなどのデー
タをパラメータ値として保存可能
• プレーンテキストまたは暗号化されたデータとして保存可能
• 作成時に指定した一意の名前を使用して値を参照
• Run Command, Automation, State Managerなどから参照可能
• 例：Run Commandから参照する場合
aws ssm send-command --instance-ids i-1a2b3c4d5e6f7g8 ¥
--document-name AWS-RunPowerShellScript ¥
--parameter '{"commands":["echo {{ssm:param}}"]}'

環境変数
• AWS Lambda 環境変数
• コンテナのプロセスに
Parameter Storeから
環境変数を経由して
「設定」を注入する例
dockerfile
ENTRYPOINT ["./entrypoint.sh"]
entrypoint.sh
export DB_HOST=$(aws ssm get-parameters ¥
--name /database/sample/host ¥
--query "Parameters[0].Value")

データベースへの認証情報や API キーなど
シークレットのライフサイクル管理
AWS Secrets Manager

IV. バックエンドサービス
バックエンドサービスをアタッチされた
リソースとして扱う

IV. バックエンドサービス
https://12factor.net/ja/backing-services
バックエンドサービスとはアプリケーションが通常の動作の中でネット
ワーク越しに利用するすべてのサービス
• DB、キャッシュ、NWストレージ、キュー、監視サービスなど
• 外部のAPIサービス(Twitter API、 Github APIなど)
ローカルサービスとサードパーティサービスを区別しない
• すべてのバックエンドサービスを設定に格納されたURLでアクセス可能にする
• アプリケーションのコードに変更を加えることなく、ローカルのMySQLをサー
ドパーティサービス(RDSなど)に切り替えることができるべき
リソースは自由にアタッチしたり、デタッチしたりできるように
• DBに問題が起きた場合、既存のDBをデタッチし、バックアップから復元した
DBをアタッチできるようにする

主なAWSのアプリバックエンドサービス
Amazon S3
99.999999999%の耐久性を持つ
容量無制限のオブジェクトストレージ
Amazon RDS
DB管理の運用負荷を軽減する
リレーショナルデータベース
Amazon DynamoDB
データ容量無制限、最大スループット
無制限のNoSQL
Amazon ElastiCache
Memcached, Redisを管理する
インメモリキャッシュ
Amazon SQS
信頼が高くスケーラブルな
メッセージキューサービス
Amazon SNS
publish-subscribe(pub-sub)型の
メッセージングサービス
Amazon Kinesis
ストリームデータ/動画をリアルタ
イムで容易に収集、処理、分析
Amazon CloudWatch
メトリクスやログの収集、可視化、
監視、検知機能を提供

バックエンドサービスを使う上での注意点
バックエンドサービスの遅延、停止の可能性を考慮する
• 代表的なアーキテクチャパターン
• リトライ：一時的な中断を考慮し、バックエンドへのリクエストはリトライする
• タイムアウト：長期サービス断を止めるため、リトライタイムアウトを設ける
• サーキットブレイカー：タイムアウトが頻発する場合、リクエスト自体を止める
※最近はアプリではなくサービスメッシュ層で吸収することも多い
• AWSサービスをバックエンドサービスに使う場合は、各サービスの
Rate Limitを考慮
• Rate Limitを超えるとスロットリングされる
• Rate Limitを把握し、必要に応じて上限緩和申請をおこなう
• 上限緩和ができない場合、キャッシング、キューイング、シャーディングなどの
デザインパターンを導入しバックエンドの負荷を緩和する
https://docs.aws.amazon.com/ja_jp/general/latest/gr/
aws_service_limits.html

Exponential Backoff And Jitter
クライアント数が増えるとスロットリング時に多くのクライアントリソースを無駄にする
「1回めはN個のクライアントが競合を起こし1つだけが成功する、次はN-1個のクライアントが競合、更に次はN-2個の・・・」
→リトライに遅延(Backoff)とゆらぎ(Jitter)を導入する
https://aws.typepad.com/sajp/2015/03/backoff.html
Exponential Backoffの導入効果
Backoffを導入しない場
合クライアント数の2乗
に比例したリクエストが
発生する
Backoffを導入すると
リクエスト数は若干
改善する
スロットリングにあった
全クライアントが同じ
タイミングでリトライしている
Jitterを加えたことで
無駄なリクエスト数
が減っている
リトライタイミングが散らばり、
競合状態の収束が早まる
Jitterの導入効果
遅延はExponential(指数的)に
徐々に長くしている

AWS SDKでのリトライ実装例
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-
core/src/main/java/com/amazonaws/retry/PredefinedBackoffStrategies.java
aws-sdk-java/aws-java-sdk-core/src/main/java/com/amazonaws/retry/PredefinedBackoffStrategies.java
Exponential Backoffの実装
jitterの実装

V. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを
厳密に分離する

V. ビルド、リリース、実行
コードベースは3つのステージを経て、（開発環境ではない）デプロイへ
と変換される
1. ビルド：コードリポジトリを実行可能な塊へと変える変換
2. リリース：上記の成果物を受け取り、それをデプロイの現在の「設定」と結合
3. 実行（ランタイム）：選択されたリリースに対して、アプリケーションのいく
つかのプロセスを起動する
ビルド、リリース、実行の3つのステージを厳密に分離する。
• 一度作られたリリースは変更することはできない
• ビルドステージは開発者によって駆動されるが、
実行ステージは自動で開始されうる
• 実行ステージはできるだけ可変部分を持たないようにするべき

AWS Code Services
AWS CodeCommit
• セキュア、スケーラブルなGit互換のリポジトリサービス
• スタンダードなGit Toolからアクセス可能
• PushなどのイベントをトリガーにSNS/Lambdaを呼び出し可能
AWS CodeBuild
• スケーラビリティに優れたビルドサービス
• ソースのコンパイル、テスト、パッケージ生成をサポート
• Dockerイメージの作成も可能
AWS CodeDeploy
• S3またはGitHub上のコードをあらゆるインスタンスにデプロイ
• デプロイを安全に実行するための様々な機能を提供
• In-place(ローリング) およびBlue/Greenのデプロイをサポート
AWS CodePipeline
• リリースプロセスのモデル化と見える化を実現
• カスタムアクションによる柔軟なパイプライン作成が可能
• 様々なAWSサービスや3rdパーティ製品との統合をサポート

VI. プロセス
アプリケーションを1つもしくは複数の
ステートレスなプロセスとして実行する

VI. プロセス
https://12factor.net/ja/processes
アプリプロセスはステートレスかつシェアードナッシングに
• 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービ
スに格納する(DB、キャッシュエンジンなど)
プロセスのメモリ空間やファイルシステムは、短い単一のトランザクショ
ン内でのキャッシュとして利用してもOK
• メモリやディスクにキャッシュされたものが将来のリクエストやジョブにおい
て利用できることは保証されない
• プロセスが再起動するとメモリやtmpファイルは消えうる
スティッキーセッションは利用しない
• セッションはバックエンドサービスに格納する(redis、memcacheなど)

ステートレス/シェアードナッシングアーキテクチャ
データストアはバックエンドサービスに
• 構造化データ：RDS
• キャッシュ、セッション情報：ElastiCache
• KVS：DynamoDB
• ファイルオブジェクト：S3
ELBのスティッキーセッションは利用しない
共有データストアを作らない
• 極力複数プロセスから共有のNFSマウントなどはしない
• 共有するリソースはバックエンドサービスとして独立
してスケーラビリティを担保できることを確認する
Web/AP
RDS
ElastiCache
(Redis)
S3(コンテンツ配信)
S3(log)

VII. ポートバインディング
ポートバインディングを通してサービスを公開する

WebアプリケーションはポートにバインドすることでHTTPをサービス
として公開し、そのポートにリクエストが来るのを待つ。
• コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない
• リクエストを処理するための実行環境との契約は、ポートをバインドすること
である
ポートバインディングの方法によって、あるアプリケーションが他のアプ
リケーションにとってのバックエンドサービスになれる。
• ポートバインディングによって公開されるサービスはHTTPだけではない
• ほぼすべてのサーバーソフトウェアは、ポートをバインドするプロセスを用い
て動作し、リクエストが来るのを待つ

コンポーネント間のやり取りをポートバインディングで分離
→ 通信が TCP/UDP のレベルで分離される
（例えば、Shared Memory 使ったプロセス間通信では
コンポーネント間がより密結合になってしまう）
あるアプリケーションが他のアプリケーションにとっての
バックエンドサービスになることができる

Elastic Load
Balancing
client
Port Binding
Port
Binding
例）共有メモリ
プロセス間通信
Port Binding

VIII. 並行性

VIII. 並行性
https://12factor.net/ja/concurrency
アプリケーションはプロセス単位でスケールさせる
• １プロセスをマルチスレッドにすることでスケールを担保するのではなく、プ
ロセス単位でスケールアウトする
• マルチスレッドアプリケーションを禁止しているわけではない
アプリケーションは垂直方向ではなく水平方向でスケールさせる
• シェアードナッシングで水平分割可能なTwelve-Factor Appプロセスの性質は、
スケールアウトが容易
アプリプロセスはデーモン化しない、PIDファイルを書き出さない
• プロセスの管理(出力ストリーム、プロセスクラッシュの対応、ユーザーによる
再起動への対応)はOSのプロセスマネージャー（systemdなど)に任せる

水平スケーリングへの対応
アプリケーションインスタンス/コンテナは原則AutoScaling
• サイズ維持： Auto Healingの用途
• 手動スケーリング：必要なときにサイズを手動で変更
• 動的スケーリング：負荷などのメトリクスをベースにスケーリング
• スケジュールベース：定義したスケジュールに基づいてスケーリング
平常時は負荷傾向が予測できる
⇩
スケジュールベース
予定された大量負荷への対策
⇩
＋手動スケーリング
緩やかな負荷変動の対策
⇩
＋動的スケーリング

スケールアウトへの対応
• BootStrap処理、ヘルスチェックパスの実装
• クールダウン期間の考慮
• スパイクトラフィックはAuto Scalingでは救いきれない点は注意
スケールインへの対応
• ログの待避、グレースフルシャットダウンを考慮
• どうしてもすぐに落とせないリソースはライフサイクルフックを実装
水平スケーリングへの対応

IX. 廃棄容易性
高速な起動とグレースフルシャットダウンで
堅牢性を最大化する

IX. 廃棄容易性
プロセスは廃棄容易である、すなわち即座に起動・終了することがで
きる。
• プロセスは、起動時間を最小化するよう努力するべきである
• 素早く柔軟なスケールと、コードや設定に対する変更の素早いデプロイを容
易にし、本番デプロイの堅牢性を高める
SIGTERMシグナルを受け取ったときに、グレースフルにシャットダウ
ンする。
• Webプロセスの場合、グレースフルシャットダウンは、サービスポートのリッ
スンを中止し処理中のリクエストが終了するまで待ち、シャットダウンするこ
とで実現される
• ワーカープロセスの場合、グレースフルシャットダウンは、処理中のジョブを
ワーカーキューに戻すことで実現される

IX. 廃棄容易性
• たいていのWebアプリケーションフレームワークや
Webサーバはきちんと対応されているので気にする必要
がない？
• 例えば、バッチのアプリケーションは、長い実行時間の
途中で速やかに安全に中止や中断をハンドリングできる
設計になっていますか？
• キューイング、ワークフローの活用
• Amazon SQS, AWS StepFunctionsなど

Spot Instance
• オンデマンド
• スタンダードな時間課金型インスタンス
• リザーブドインスタンス
• 1年間または3年間の利用予約をすることで25〜70%前後の割引
• スポットインスタンス
• 使われていないEC2インスタンスに入札して格安利用
• 最大90%程度の大幅コストカットが可能
• Dedicated Host
• お客様専用の物理サーバを確保

Spot Instance
• 使われていないEC2インスタンスに入札して格安利用
ただし、スポット価格高騰あるいはスポットインスタンス
枯渇による強制ターミネートがありうる
コスト削減計算結果をより
速く
簡単に利用柔軟なリソース

開発、ステージング、本番環境をできるだけ
一致させた状態を保つ

https://12factor.net/ja/dev-prod-parity
継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ
• 時間のギャップ: 開発者が編集したコードが本番に反映されるまでを短く
• 人材のギャップ:コードを書いた開発者はそのコードのデプロイに関わる
• ツールのギャップ: 開発環境と本番環境でできるだけ同じツールを使う
バックエンドサービスも開発/本番をできるだけ一致させる
• 開発環境ではSQLiteを使い、本番ではPostgreSQLを使うなどをしない
• バックエンドサービスの違いは、開発環境では動作するアプリが本番環境で動
かいない、という状況を招く

開発環境と本番環境のギャップを小さく
時間のギャップ
• CI/CDパイプラインを導入し継続的にインテグレーション/デプロイする
人材のギャップ
• CI/CDパイプラインでコード開発者が自分でデプロイする
• コードのコミットとデプロイの権限をわける必要がある場合、Dockerイ
メージ、AMI、CloudFormationテンプレートなど同一性が担保できるコ
ンポーネントを分界点として受け渡す
ツールのギャップ
• 開発環境とのポータビリティ→Dockerが得意とするところ
• 開発環境でモックとして動くAWSサービス：
DynamoDBローカル、SAMローカル、LocalStack

XI. ログ

ログ
ログは、すべての実行中のプロセスとバックエンドサービスの出力スト
リームから収集されたイベントが、集約されて時刻順に並べられたスト
リームである。
• ログは一般的にディスク上のファイルに書き込まれる
• しかしこれは出力フォーマットの一つに過ぎない
• ログには固定の始まりと終わりはなく、アプリケーションが稼動している限り
流れ続ける
アプリケーションの出力ストリームの送り先やストレージについて一切関
知しない。
• アプリケーションのイベントストリームは、ファイルに送られたり、ターミナ
ルでtailを使ってリアルタイムに見られたりする

Amazon ECS Logging Driver
• Amazon ECS がサポートしている Docker の Logging Driver
• json-file, syslog, journald, gelf, fluentd, awslogs,
• awslogs
• Amazon CloudWatch Logs にログを送信
• Amazon CloudWatch Logs から他サービスへ容易に連携
• fluentd
• fluentd の in_forward にログを送信
• OSS の豊富なプラグインを使って多くのデータストアや
サービスへログを転送可能

ログを awslogs 経由で収集・分配
Amazon CloudWatch Logs
Amazon S3
Amazon Kinesis
AWS Lambda
Amazon Elasticsearch Service
Amazon ECS 保存
ストリーム
処理
検索

XII. 管理プロセス

XII. 管理プロセス
https://12factor.net/ja/admin-processes
管理プロセス＝アプリのための1回限りの管理・メンテナンス用のタスク
• データベースのマイグレーション(rake db:migrateなど)
• 特定の修正のための一回限りのスクリプト(DBの特定レコードの修正など)
管理タスクは1回限りのプロセスとして、長時間実行されるプロセスと全
く同じ環境で実行する
• 管理プロセスは、あるリリースに対して実行され、そのリリースに対して実行
されるすべてのプロセスと同じコードベースと設定を使う
• 管理用のコードは、アプリケーションコードと一緒にデプロイする
• アプリと同じ依存関係分離ツールを使う
• RubyのWebプロセスが`bundle exec thin start`を使うのであれば、DBマイグレーションには
`bundle exec rake db:migrate`を使う、など

管理タスクは1回限りのプロセスとして実行する
悪い例良い例
db:migrateを手動で実行
db:migrateを実行するためのスクリプトを作成
しデプロイパイプラインに含める
ecs:UpdateService時にアプリ起動スクリプト
内でdb:migrateを実行し、同じスクリプトの中
でRails サーバーを起動
db:migrateを実行するタスクをecs:RunTask
それが成功したら別のデプロイステージに進み、
ecs:UpdateServiceでRailsサーバーコンテナを
アップデート

Wrap up

Twelve-Factor
バージョン管理される1つのコードベースと複数デプロイ
II. 依存関係
III.設定
IV.バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
V. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
VI.プロセス
アプリを1つ又は複数のステートレスなプロセスとして実行
VII.ポートバインディング
ポートバインディングを通してサービスを公開する
VIII.並行性
IX. 廃棄容易性
高速な起動とグレースフル停止で堅牢性を最大化する
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
XI. ログ
XII.管理プロセス
https://12factor.net/ja/

アプリケーションを疎結合にするための指針・方法論
疎結合とクラウドの相性
疎結合なアプリケーションは・・・
クラウドの力を最大限に引き出す

Appendix

合わせて読みたい
Architecting for the Cloud (2010)
 Decouple your components
コンポーネントを疎結合にする
 Design for failure
障害に備えた設計する
 Implement elasticity
伸縮自在性を実装する
 Think parallel
並列化する
https://s3.amazonaws.com/awsmedia/jp/wp/AWS_WP_Cloud_
BestPractices_JP_v20110531.pdf

Thank You!

The Twelve-Factor Appで考えるAWSのサービス開発

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie The Twelve-Factor Appで考えるAWSのサービス開発

Ähnlich wie The Twelve-Factor Appで考えるAWSのサービス開発 (20)

Mehr von Amazon Web Services Japan

Mehr von Amazon Web Services Japan (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

The Twelve-Factor Appで考えるAWSのサービス開発