The Twelve-Factor App on AWS

© 2020, Amazon Web Services, Inc. or its Affiliates. All
rights reserved. Amazon Web Services Japan K.K. Keisuke Nishitani (@Keisuke69) Feb 11, 2020 The Twelve Factor App on AWS

rights reserved. Keisuke Nishitani Manager, Senior Solutions Architect Amazon Web Service Japan K.K Everything will be serverless. ⾳楽 x キャンプ x マンガフジロッカー Twitter: @Keisuke69 ブログ他: https://note.com/keisuke69 https://www.keisuke69.net/

rights reserved. The Twelve-Factor App

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

rights reserved. The Twelve-Factor App アプリケーションを疎結合にするための指針・⽅法論疎結合とクラウドの相性疎結合なアプリケーションは・・・デプロイが容易起動 / 停⽌ / 中断が容易スケールアウト / スケールインが容易

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

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

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

rights reserved. 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 を呼び出し

rights reserved. II. 依存関係依存関係を明⽰的に宣⾔し分離する

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

rights reserved. 依存関係宣⾔マニフェストと依存関係分離ツール⾔語分離ツール宣⾔マニフェスト 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でも同様

rights reserved. Lambda Layers 様々なLambdaファンクションで共通利⽤するコンポーネントを個別に持つのではなく、Lambda Layerとして定義し参照することができるように責務を分けることができるようになるため、プログラマはよりビジネスロジックに集中できるように Layerをシェアするエコシステム

rights reserved. 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

rights reserved. 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

rights reserved. III. 設定設定を環境変数に格納する

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

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

rights reserved. 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}}"]}'

rights reserved. 環境変数 • 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")

rights reserved. データベースへの認証情報や API キーなどシークレットのライフサイクル管理シークレットを安全に保管粒度の細かいポリシーでアクセス管理シークレットを⼀元的に保護し監査できるシークレットを⾃動的にローテーション AWS Secrets Manager

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

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

rights reserved. 主な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 メトリクスやログの収集、可視化、監視、検知機能を提供

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

rights reserved. 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(指数的)に徐々に⻑くしている

rights reserved. 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の実装

rights reserved. 分散トレースを使ってアプリケーションを解析＆デバッグ • 問題やエラー、ボトルネックの根本原因を特定し把握 • サービスのどの部分が問題を引き起こしているかを特定 • アーキテクチャのビジュアル・マップを提供 • リクエストのエンドツーエンドトレース • API Gateway/Lambdaもサポート AWS X-Ray

rights reserved. AWS X-Ray

rights reserved. V. ビルド、リリース、実⾏ビルド、リリース、実⾏の3つのステージを厳密に分離する

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

rights reserved. 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パーティ製品との統合をサポート

rights reserved. AWS CodeStar AWS上にアプリケーションをすばやく開発・ビルド・デプロイ AWS上での開発をわずか数分間で開始チームをまたがった開発をセキュアにソフトウェアデリバリの管理を容易に様々なプロジェクトテンプレートから選択

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

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

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

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

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

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

rights reserved. VII. ポートバインディング Elastic Load Balancing client Port Binding Port Binding 例）共有メモリプロセス間通信 Port Binding

rights reserved. VIII. 並⾏性プロセスモデルによってスケールアウトする

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

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

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

rights reserved. IX. 廃棄容易性⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する

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

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

rights reserved. Amazon SQS 特徴 • ⾼い信頼性: 複数のサーバー/データセンターにメッセージを保持 • スケーラブル: 多数の送信者/受信者に対応 • ⾼スループット: メッセージが増加しても⾼スループットを出し続ける構成 • Producer, ConsumerはEC2やモバイルデバイス、オンプレミスサーバーなどで構成 • 実際のやりとりにはAmazon SQS APIを使う⾼い可⽤性と信頼性を提供するフルマネージドなメッセージキューサービス Consumer polling message message Producer

rights reserved. AWS StepFunctions 視覚的なワークフローを使⽤して、分散アプリケーションとマイクロサービスを簡単にコーディネート・アプリケーションを⼀連のステップとして視覚的に定義・アプリケーションのステップが意図したとおりに動作していることを可視化・コンピューティングのステップを操作およびスケールし、需要の増加に応じてアプリケーションを確実に実⾏

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

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

rights reserved. X. 開発/本番⼀致開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ

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

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

rights reserved. XI. ログログをイベントストリームとして扱う

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

rights reserved. 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 の豊富なプラグインを使って多くのデータストアやサービスへログを転送可能

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

rights reserved. FireLens 簡単にコンテナログをストレージや分析ツールに直接追加できる新しい⽅法 FluentBit および Fluentdと協調動作 • いわゆるサイドカー形式 • サポートされた宛先にログを送信可能 Fargate/EC2のいずれのLaunch Typeでも利⽤可能

rights reserved. XII. 管理プロセス管理タスクを1回限りのプロセスとして実⾏する

rights reserved. 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`を使う、など

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

rights reserved. まとめ

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

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

rights reserved. The Twelve-Factor App アプリケーションを疎結合にするための指針・⽅法論疎結合とクラウドの相性疎結合なアプリケーションは・・・クラウドの⼒を最⼤限に引き出す

rights reserved. Thank you @Keisuke69

The Twelve-Factor App on AWS

The Twelve-Factor App on AWS

More Decks by Keisuke69

Other Decks in Technology

Featured

Transcript