$30 off During Our Annual Pro Sale. View Details »

The Twelve-Factor App on AWS

Keisuke69
February 12, 2020

The Twelve-Factor App on AWS

Alternative Architecture DOJO Offline #3での資料です。

Keisuke69

February 12, 2020
Tweet

More Decks by Keisuke69

Other Decks in Technology

Transcript

  1. © 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

    View Slide

  2. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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/

    View Slide

  3. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    The Twelve-Factor App

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    I. コードベース
    バージョン管理されている1つのコードベースと
    複数のデプロイ

    View Slide

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

    View Slide

  9. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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 を呼び出し

    View Slide

  10. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    II. 依存関係
    依存関係を明⽰的に宣⾔し分離する

    View Slide

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

    View Slide

  12. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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でも同様

    View Slide

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

    View Slide

  14. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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

    View Slide

  15. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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

    View Slide

  16. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    III. 設定
    設定を環境変数に格納する

    View Slide

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

    View Slide

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

    View Slide

  19. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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}}"]}'

    View Slide

  20. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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")

    View Slide

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

    View Slide

  22. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    IV. バックエンドサービス
    バックエンドサービスをアタッチされた
    リソースとして扱う

    View Slide

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

    View Slide

  24. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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
    メトリクスやログの収集、可視化、
    監視、検知機能を提供

    View Slide

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

    View Slide

  26. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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(指数的)に
    徐々に⻑くしている

    View Slide

  27. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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の実装

    View Slide

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

    View Slide

  29. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    AWS X-Ray

    View Slide

  30. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    V. ビルド、リリース、実⾏
    ビルド、リリース、実⾏の3つのステージを
    厳密に分離する

    View Slide

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

    View Slide

  32. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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パーティ製品との統合をサポート

    View Slide

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

    View Slide

  34. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    VI. プロセス
    アプリケーションを1つもしくは複数の
    ステートレスなプロセスとして実⾏する

    View Slide

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

    View Slide

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

    View Slide

  37. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    VII. ポートバインディング
    ポートバインディングを通してサービスを公開する

    View Slide

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

    View Slide

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

    View Slide

  40. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    VII. ポートバインディング
    Elastic Load
    Balancing
    client
    Port Binding
    Port
    Binding
    例)共有メモリ
    プロセス間通信
    Port Binding

    View Slide

  41. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    VIII. 並⾏性
    プロセスモデルによってスケールアウトする

    View Slide

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

    View Slide

  43. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    ⽔平スケーリングへの対応
    アプリケーションインスタンス/コンテナは原則AutoScaling
    • サイズ維持 : Auto Healingの⽤途
    • ⼿動スケーリング:必要なときにサイズを⼿動で変更
    • 動的スケーリング:負荷などのメトリクスをベースにスケーリング
    • スケジュールベース:定義したスケジュールに基づいてスケーリング
    平常時は負荷傾向が予測できる

    スケジュールベース
    予定された⼤量負荷への対策

    +⼿動スケーリング
    緩やかな負荷変動の対策

    +動的スケーリング

    View Slide

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

    View Slide

  45. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    IX. 廃棄容易性
    ⾼速な起動とグレースフルシャットダウンで
    堅牢性を最⼤化する

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  52. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    X. 開発/本番⼀致
    開発、ステージング、本番環境をできるだけ
    ⼀致させた状態を保つ

    View Slide

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

    View Slide

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

    View Slide

  55. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    XI. ログ
    ログをイベントストリームとして扱う

    View Slide

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

    View Slide

  57. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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 の豊富なプラグインを使って多くのデータストアやサー
    ビスへログを転送可能

    View Slide

  58. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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 保存
    ストリーム
    処理
    検索

    View Slide

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

    View Slide

  60. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    XII. 管理プロセス
    管理タスクを1回限りのプロセスとして実⾏する

    View Slide

  61. © 2020, Amazon Web Services, Inc. or its Affiliates. All 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`を使う、など

    View Slide

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

    View Slide

  63. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    まとめ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. © 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
    Thank you
    @Keisuke69

    View Slide