Alternative Architecture DOJO Offline #3での資料です。
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Amazon Web Services Japan K.K.Keisuke Nishitani (@Keisuke69)Feb 11, 2020The Twelve Factor App on AWS
View Slide
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Keisuke NishitaniManager, Senior Solutions ArchitectAmazon Web Service Japan K.KEverything will be serverless.⾳楽 x キャンプ x マンガフジロッカーTwitter: @Keisuke69ブログ他: https://note.com/keisuke69https://www.keisuke69.net/
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.The Twelve-Factor App
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.The Twelve-Factor App2011年にHerokuのエンジニアが提唱した、アプリ開発の⽅法論• セットアップ⾃動化のために宣⾔的なフォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最⼩化する。• 下層のOSへの依存関係を明確化し、実⾏環境間での移植性を最⼤化する。• モダンなクラウドプラットフォーム上へのデプロイに適しており、サーバー管理やシステム管理を不要なものにする。• 開発環境と本番環境の差異を最⼩限にし、アジリティを最⼤化する継続的デプロイを可能にする。• ツール、アーキテクチャ、開発プラクティスを⼤幅に変更することなくスケールアップできる。サービスとして動くアプリを開発しているすべての開発者が対象http://12factor.net/http://12factor.net/ja/(⽇本語訳)
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.The Twelve-Factor Appアプリケーションを疎結合にするための指針・⽅法論疎結合 と クラウド の相性疎結合なアプリケーションは・・・デプロイ が容易起動 / 停⽌ / 中断 が容易スケールアウト / スケールイン が容易
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Twelve-FactorI. コードベースバージョン管理される1つのコードベースと複数デプロイII. 依存関係依存関係を明⽰的に宣⾔し分離するIII.設定設定を環境変数に格納するIV.バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱うV. ビルド、リリース、実⾏ビルド、リリース、実⾏の3つのステージを厳密に分離するVI.プロセスアプリを1つ⼜は複数のステートレスなプロセスとして実⾏VII.ポートバインディングポートバインディングを通してサービスを公開するVIII.並⾏性プロセスモデルによってスケールアウトするIX. 廃棄容易性⾼速な起動とグレースフル停⽌で堅牢性を最⼤化するX. 開発/本番⼀致開発、ステージング、本番環境をできるだけ⼀致させた状態を保つXI. ログログをイベントストリームとして扱うXII.管理プロセス管理タスクを1回限りのプロセスとして実⾏するhttps://12factor.net/ja/
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.I. コードベースバージョン管理されている1つのコードベースと複数のデプロイ
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.I. コードベースコードベースとアプリケーションの間には、常に1対1の関係がある。• コードベース : アプリケーション が N : 1→ 分散システム• コードベース : アプリケーション が 1 : N→ コードベースの様々なバージョンが複数のアプリケーションから参照される状態を管理する必要→ コードをライブラリに分離アプリケーションごとにただ1つのコードベースが存在するが、アプリケーションのデプロイは複数存在する。• デプロイごとに異なるバージョンがアクティブであるかもしれないが、コードベースはすべてのデプロイを通して同⼀である
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS CodeCommitSecure, scalable, managed Git source controlスターンダードな Git tool が利⽤可能Amazon S3 の Scalability, availability, durabilityをストレージに活⽤Encryption at rest with customer-specific keysレポジトリサイズの上限なしPost commit hooks で SNS/Lambda を呼び出し
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.II. 依存関係依存関係を明⽰的に宣⾔し分離する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.II. 依存関係https://12factor.net/ja/dependenciesシステム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない• すべての依存関係を 依存関係宣⾔ マニフェストで完全かつ厳密に宣⾔する• 実⾏時には 依存関係分離 ツールを使って、取り囲んでいるシステムから暗黙の依存関係が“漏れ出ない”ことを保証する• 依存関係の指定は、本番環境と開発環境の両⽅に適⽤するいかなるシステムツールの暗黙的な存在にも依存しない• アプリ外のツールに依存しない(OSにプリインストールされているcurlなど)• 将来に渡ってそのツールが環境に存在するか、互換性のあるバージョンが提供され続けるかはわからない• アプリケーションに必要な機能はアプリケーション内で実装する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.依存関係宣⾔マニフェストと依存関係分離ツール⾔語 分離ツール 宣⾔マニフェストNode.js npm package.jsonRuby bundler gemfilePython pip requirements.txtJava mvn package pom.xmlC# NuGet .nuspecGo dep manifest.jsonSAM sam package template.ymlDocker docker build DockerfileAnsible ansible-playbook playbookInfrastructure as Codeでも同様
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Lambda Layers様々なLambdaファンクションで共通利⽤するコンポーネントを個別に持つのではなく、LambdaLayerとして定義し参照することができるように責務を分けることができるようになるため、プログラマはよりビジネスロジックに集中できるようにLayerをシェアするエコシステム
© 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
© 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-31Resources:FunctionName:Type: AWS::Serverless::FunctionProperties:Handler: handlerRuntime: runtimeCodeUri: s3://bucketName/codepackage.zipaws cloudformation package \--template-file /path_to_template/template.yaml \--s3-bucket bucket-name \--output-template-file packaged-template.yamlaws cloudformation deploy \--template-file /path_to_template/packaged-template.yaml \--stack-name my-new-stack \ --capabilities CAPABILITY_IAM
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.III. 設定設定を環境変数に格納する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.III. 設定アプリケーションの 「設定」 は、デプロイ(ステージング、本番、開発環境など)の間で異なり得る唯⼀のもの。• 設定をコードから厳密に分離すること• この“設定”の定義には、アプリケーション内部の設定は 含まない• 認証情報を漏洩させることなく、コードベースを今すぐにでもオープンソースにすることができるか設定を 「環境変数」 に格納する。• 環境変数は、コードを変更することなくデプロイごとに簡単に変更できる• 環境変数は、独⾃形式の設定ファイルやJava System Propertiesなど他の設定の仕組みとは異なり、環境変数は⾔語やOSに依存しない標準• 環境変数は粒度の細かい管理であり、それぞれの環境変数は互いに直交
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS Systems ManagerRun Command MaintenanceWindowInventoryState Manager Parameter StorePatch ManagerAutomationデプロイ、構成および管理トラッキングとアップデート共有コンポーネント分類と可視化Resource GroupsInsightsDashboard
© 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}}"]}'
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.環境変数• AWS Lambda 環境変数• コンテナのプロセスにParameter Storeから環境変数を経由して「設定」を注⼊する例dockerfileENTRYPOINT ["./entrypoint.sh"]entrypoint.shexport DB_HOST=$(aws ssm get-parameters \--name /database/sample/host \--query "Parameters[0].Value")
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.データベースへの認証情報や API キーなどシークレットのライフサイクル管理シークレットを安全に保管粒度の細かいポリシーでアクセス管理シークレットを⼀元的に保護し監査できるシークレットを⾃動的にローテーションAWS Secrets Manager
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.IV. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う
© 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をアタッチできるようにする
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.主なAWSのアプリバックエンドサービスAmazon S399.999999999%の耐久性を持つ容量無制限のオブジェクトストレージAmazon RDSDB管理の運⽤負荷を軽減するリレーショナルデータベースAmazon DynamoDBデータ容量無制限、最⼤スループット無制限のNoSQLAmazon ElastiCacheMemcached, Redisを管理するインメモリキャッシュAmazon SQS信頼が⾼くスケーラブルなメッセージキューサービスAmazon SNSpublish-subscribe(pub-sub)型のメッセージングサービスAmazon Kinesisストリームデータ/動画をリアルタイムで容易に収集、処理、分析Amazon CloudWatchメトリクスやログの収集、可視化、監視、検知機能を提供
© 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
© 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.htmlExponential Backoffの導⼊効果Backoffを導⼊しない場合クライアント数の2乗に⽐例したリクエストが発⽣するBackoffを導⼊するとリクエスト数は若⼲改善するスロットリングにあった全クライアントが同じタイミングでリトライしているJitterを加えたことで無駄なリクエスト数が減っているリトライタイミングが散らばり、競合状態の収束が早まるJitterの導⼊効果遅延はExponential(指数的)に徐々に⻑くしている
© 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.javaaws-sdk-java/aws-java-sdk-core/src/main/java/com/amazonaws/retry/PredefinedBackoffStrategies.javaExponential Backoffの実装jitterの実装
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.分散トレースを使ってアプリケーションを解析&デバッグ• 問題やエラー、ボトルネックの根本原因を特定し把握• サービスのどの部分が問題を引き起こしているかを特定• アーキテクチャのビジュアル・マップを提供• リクエストのエンドツーエンドトレース• API Gateway/LambdaもサポートAWS X-Ray
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS X-Ray
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.V. ビルド、リリース、実⾏ビルド、リリース、実⾏の3つのステージを厳密に分離する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.V. ビルド、リリース、実⾏コードベースは3つのステージを経て、(開発環境ではない)デプロイへと変換される1. ビルド:コードリポジトリを実⾏可能な塊へと変える変換2. リリース:上記の成果物を受け取り、それをデプロイの現在の「設定」と結合3. 実⾏(ランタイム):選択されたリリースに対して、アプリケーションのいくつかのプロセスを起動するビルド、リリース、実⾏の3つのステージを厳密に分離する。• ⼀度作られたリリースは変更することはできない• ビルドステージは開発者によって駆動されるが、実⾏ステージは⾃動で開始されうる• 実⾏ステージはできるだけ可変部分を持たないようにするべき
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS Code ServicesAWS CodeCommit• セキュア、スケーラブルなGit互換のリポジトリサービス• スタンダードなGit Toolからアクセス可能• PushなどのイベントをトリガーにSNS/Lambdaを呼び出し可能AWS CodeBuild• スケーラビリティに優れたビルドサービス• ソースのコンパイル、テスト、パッケージ⽣成をサポート• Dockerイメージの作成も可能AWS CodeDeploy• S3またはGitHub上のコードをあらゆるインスタンスにデプロイ• デプロイを安全に実⾏するための様々な機能を提供• In-place(ローリング) およびBlue/GreenのデプロイをサポートAWS CodePipeline• リリースプロセスのモデル化と⾒える化を実現• カスタムアクションによる柔軟なパイプライン作成が可能• 様々なAWSサービスや3rdパーティ製品との統合をサポート
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS CodeStarAWS上にアプリケーションをすばやく開発・ビルド・デプロイAWS上での開発をわずか数分間で開始チームをまたがった開発をセキュアにソフトウェアデリバリの管理を容易に様々なプロジェクトテンプレートから選択
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VI. プロセスアプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VI. プロセスhttps://12factor.net/ja/processesアプリプロセスはステートレスかつシェアードナッシングに• 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービスに格納する(DB、キャッシュエンジンなど)プロセスのメモリ空間やファイルシステムは、短い単⼀のトランザクション内でのキャッシュとして利⽤してもOK• メモリやディスクにキャッシュされたものが将来のリクエストやジョブにおいて利⽤できることは保証されない• プロセスが再起動するとメモリやtmpファイルは消えうるスティッキーセッションは利⽤しない• セッションはバックエンドサービスに格納する(redis、memcacheなど)
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.ステートレス/シェアードナッシングアーキテクチャデータストアはバックエンドサービスに• 構造化データ:RDS• キャッシュ、セッション情報:ElastiCache• KVS:DynamoDB• ファイルオブジェクト:S3ELBのスティッキーセッションは利⽤しない共有データストアを作らない• 極⼒複数プロセスから共有のNFSマウントなどはしない• 共有するリソースはバックエンドサービスとして独⽴してスケーラビリティを担保できることを確認するWeb/APRDSElastiCache(Redis)S3(コンテンツ配信)S3(log)
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VII. ポートバインディングポートバインディングを通してサービスを公開する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VII. ポートバインディングWebアプリケーションは ポートにバインドすることでHTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。• コンテナが実⾏環境にWebサーバーランタイムを注⼊することを頼りにしない• リクエストを処理するための実⾏環境との契約は、ポートをバインドすることであるポートバインディングの⽅法によって、あるアプリケーションが他のアプリケーションにとってのバックエンドサービスになれる。• ポートバインディングによって公開されるサービスはHTTPだけではない• ほぼすべてのサーバーソフトウェアは、ポートをバインドするプロセスを⽤いて動作し、リクエストが来るのを待つ
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VII. ポートバインディングコンポーネント間のやり取りをポートバインディングで分離→ 通信が TCP/UDP のレベルで分離される(例えば、Shared Memory 使ったプロセス間通信ではコンポーネント間がより密結合になってしまう)あるアプリケーションが他のアプリケーションにとってのバックエンドサービスになることができる
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VII. ポートバインディングElastic LoadBalancingclientPort BindingPortBinding例)共有メモリプロセス間通信Port Binding
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VIII. 並⾏性プロセスモデルによってスケールアウトする
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.VIII. 並⾏性https://12factor.net/ja/concurrencyアプリケーションはプロセス単位でスケールさせる• 1プロセスをマルチスレッドにすることでスケールを担保するのではなく、プロセス単位でスケールアウトする• マルチスレッドアプリケーションを禁⽌しているわけではないアプリケーションは垂直⽅向ではなく⽔平⽅向でスケールさせる• シェアードナッシングで⽔平分割可能なTwelve-Factor Appプロセスの性質は、スケールアウトが容易アプリプロセスはデーモン化しない、PIDファイルを書き出さない• プロセスの管理(出⼒ストリーム、プロセスクラッシュの対応、ユーザーによる再起動への対応)はOSのプロセスマネージャー(systemdなど)に任せる
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.⽔平スケーリングへの対応アプリケーションインスタンス/コンテナは原則AutoScaling• サイズ維持 : Auto Healingの⽤途• ⼿動スケーリング:必要なときにサイズを⼿動で変更• 動的スケーリング:負荷などのメトリクスをベースにスケーリング• スケジュールベース:定義したスケジュールに基づいてスケーリング平常時は負荷傾向が予測できる⇩スケジュールベース予定された⼤量負荷への対策⇩+⼿動スケーリング緩やかな負荷変動の対策⇩+動的スケーリング
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.スケールアウトへの対応• BootStrap処理、ヘルスチェックパスの実装• クールダウン期間の考慮• スパイクトラフィックはAuto Scalingでは救いきれない点は注意スケールインへの対応• ログの待避、グレースフルシャットダウンを考慮• どうしてもすぐに落とせないリソースはライフサイクルフックを実装⽔平スケーリングへの対応
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.IX. 廃棄容易性⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.IX. 廃棄容易性プロセス は 廃棄容易 である、すなわち即座に起動・終了することができる。• プロセスは、 起動時間を最⼩化する よう努⼒するべきである• 素早く柔軟なスケールと、コード や 設定 に対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を⾼めるSIGTERMシグナルを受け取ったときに、グレースフルにシャットダウンする。• Webプロセスの場合、グレースフルシャットダウンは、サービスポートのリッスンを中⽌し処理中のリクエストが終了するまで待ち、シャットダウンすることで実現される• ワーカープロセスの場合、グレースフルシャットダウンは、処理中のジョブをワーカーキューに戻すことで実現される
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.IX. 廃棄容易性• たいていのWebアプリケーションフレームワークやWebサーバはきちんと対応されているので気にする必要がない?• 例えば、バッチのアプリケーションは、⻑い実⾏時間の途中で速やかに安全に中⽌や中断をハンドリングできる設計になっていますか?• キューイング、ワークフローの活⽤• Amazon SQS, AWS StepFunctionsなど
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Amazon SQS特徴• ⾼い信頼性: 複数のサーバー/データセンターにメッセージを保持• スケーラブル: 多数の送信者/受信者に対応• ⾼スループット: メッセージが増加しても⾼スループットを出し続ける構成• Producer, ConsumerはEC2やモバイルデバイス、オンプレミスサーバーなどで構成• 実際のやりとりにはAmazon SQS APIを使う⾼い可⽤性と信頼性を提供するフルマネージドなメッセージキューサービスConsumerpollingmessage messageProducer
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS StepFunctions視覚的なワークフローを使⽤して、分散アプリケーションとマイクロサービスを簡単にコーディネート・アプリケーションを⼀連のステップとして視覚的に定義・アプリケーションのステップが意図したとおりに動作していることを可視化・コンピューティングのステップを操作およびスケールし、需要の増加に応じてアプリケーションを確実に実⾏
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Spot Instance• オンデマンド• スタンダードな時間課⾦型インスタンス• リザーブドインスタンス• 1年間または3年間の利⽤予約をすることで25〜70%前後の割引• スポットインスタンス• 使われていないEC2インスタンスに⼊札して格安利⽤• 最⼤90%程度の⼤幅コストカットが可能• Dedicated Host• お客様専⽤の物理サーバを確保
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Spot Instance• 使われていないEC2インスタンスに⼊札して格安利⽤ただし、スポット価格⾼騰あるいはスポットインスタンス枯渇による強制ターミネートがありうるコスト削減 計算結果をより速く簡単に利用 柔軟なリソース
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.X. 開発/本番⼀致開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.X. 開発/本番⼀致https://12factor.net/ja/dev-prod-parity継続的デプロイしやすいよう開発環境と本番環境のギャップを⼩さく保つ• 時間のギャップ: 開発者が編集したコードが本番に反映されるまでを短く• ⼈材のギャップ:コードを書いた開発者はそのコードのデプロイに関わる• ツールのギャップ: 開発環境と本番環境でできるだけ同じツールを使うバックエンドサービスも開発/本番をできるだけ⼀致させる• 開発環境ではSQLiteを使い、本番ではPostgreSQLを使うなどをしない• バックエンドサービスの違いは、開発環境では動作するアプリが本番環境で動かいない、という状況を招く
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.開発環境と本番環境のギャップを⼩さく時間のギャップ• CI/CDパイプラインを導⼊し継続的にインテグレーション/デプロイする⼈材のギャップ• CI/CDパイプラインでコード開発者が⾃分でデプロイする• コードのコミットとデプロイの権限をわける必要がある場合、Dockerイメージ、AMI、CloudFormationテンプレートなど同⼀性が担保できるコンポーネントを分界点として受け渡すツールのギャップ• 開発環境とのポータビリティ→Dockerが得意とするところ• 開発環境でモックとして動くAWSサービス:DynamoDBローカル、SAMローカル、LocalStack
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.XI. ログログをイベントストリームとして扱う
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.ログログは、すべての実⾏中のプロセスとバックエンドサービスの出⼒ストリームから収集されたイベントが、集約されて時刻順に並べられたストリームである。• ログは⼀般的にディスク上のファイルに書き込まれる• しかしこれは出⼒フォーマットの⼀つに過ぎない• ログには固定の始まりと終わりはなく、アプリケーションが稼動している限り流れ続けるアプリケーションの出⼒ストリームの送り先やストレージについて⼀切関知しない。• アプリケーションのイベントストリームは、ファイルに送られたり、ターミナルでtailを使ってリアルタイムに⾒られたりする
© 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 の豊富なプラグインを使って多くのデータストアやサービスへログを転送可能
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.ログを awslogs 経由で収集・分配Amazon CloudWatch LogsAmazon CloudWatch LogsAmazon CloudWatch LogsAmazon CloudWatch LogsAmazon S3Amazon KinesisAWS LambdaAmazon Elasticsearch ServiceAmazon ECS 保存ストリーム処理検索
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.FireLens簡単にコンテナログをストレージや分析ツールに直接追加できる新しい⽅法FluentBit および Fluentdと協調動作• いわゆるサイドカー形式• サポートされた宛先にログを送信可能Fargate/EC2のいずれのLaunch Typeでも利⽤可能
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.XII. 管理プロセス管理タスクを1回限りのプロセスとして実⾏する
© 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`を使う、など
© 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サーバーコンテナをアップデート
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.まとめ
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.The Twelve-Factor Appアプリケーションを疎結合にするための指針・⽅法論疎結合 と クラウド の相性疎結合なアプリケーションは・・・• デプロイ が容易• 起動 / 停⽌ / 中断 が容易• スケールアウト / スケールイン が容易
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.The Twelve-Factor Appアプリケーションを疎結合にするための指針・⽅法論疎結合 と クラウド の相性疎結合なアプリケーションは・・・クラウドの⼒を最⼤限に引き出す
© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Thank you@Keisuke69