Movatterモバイル変換

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

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

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

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

© 2018, 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 を呼び出し

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

© 2018, 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でも同様

© 2018, 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

© 2018, 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

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

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.AWS Systems ManagerRun Command MaintenanceWindowInventoryState Manager Parameter StorePatch ManagerAutomationデプロイ、構成および管理トラッキングとアップデート共有コンポーネント分類と可視化Resource GroupsInsightsDashboard

© 2018, 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}}"]}'

© 2018, 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")

© 2018, 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をアタッチできるようにする

© 2018, 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メトリクスやログの収集、可視化、監視、検知機能を提供

© 2018, 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

© 2018, 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(指数的)に徐々に長くしている

© 2018, 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の実装

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

© 2018, 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パーティ製品との統合をサポート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© 2018, 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 保存ストリーム処理検索

© 2018, 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`を使う、など

© 2018, 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サーバーコンテナをアップデート

© 2018, 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/

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.合わせて読みたい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

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

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

More from Amazon Web Services Japan

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