AWS Black Belt Online Seminar 2017 Deployment on AWS
13 likes14,868 views
AWS Black Belt Online Seminar 2017 Deployment on AWS
![v2 v1 v1 v1 v1 v1 v1 v1
v2 v2 v1 v1 v1 v1 v1 v1
v2 v2 v2 v2 v1 v1 v1 v1
v2 v2 v2 v2 v2 v2 v2 v2
One-at-a-time
Min. healthy hosts = 99%
[Custom]
Min. healthy hosts = 75%
Half-at-a-time
Min. healthy hosts = 50%
All-at-once
Min. healthy hosts = 0
CodeDeploy - デプロイメント構成](https://image.slidesharecdn.com/20170822blackbeltdeploymentonaws-170822041216/85/AWS-Black-Belt-Online-Seminar-2017-Deployment-on-AWS-25-320.jpg)
![AMIにどこまでいれるか？
Linux
J2EE
アプリコード
Log4J
Spring
Hibernat
e
Struts
Tomcat
Apache
Linux
J2EE
アプリコード
Log4J
Spring
Hiberna
te
Struts
Tomcat
Apache
EC2
L
i
n
u
x
J
E
E
Y
o
u
r
C
o
d
e
L
o
g
4
J
S
p
r
i
n
gH
i
b
e
r
n
a
t
e
S
t
r
u
t
s
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
Y
o
u
r
C
o
d
e
L
o
g
4
J
S
p
r
i
n
gH
i
b
e
r
n
a
t
e
S
t
r
u
t
s
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
Y
o
u
r
C
o
d
e
L
o
g
4
J
S
p
r
i
n
gH
i
b
e
r
n
a
t
e
S
t
r
u
t
s
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
Y
o
u
r
C
o
d
e
L
o
g
4
J
S
p
r
i
n
gH
i
b
e
r
n
a
t
e
S
t
r
u
t
s
T
o
m
c
a
t
A
p
a
c
h
e
アプリ
コード
Amazon
S3
Log4J
Spring
Struts
Linux
J2EE
Hiberna
te
Tomcat
Apache
Linux
J2EE
アプリ
コード
Amazon
S3
Hiberna
te
Tomcat
Log4J
Spring
Struts
Apache
EC2
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
L
i
n
u
x
J
E
E
H
i
b
e
r
n
a
t
e
T
o
m
c
a
t
A
p
a
c
h
e
EC2
Linu
x
JEE
Linu
x
JEE
Chef
Chef
スクリプト
Java AMIJavaスタック Java AMI
AMI
起動時取得
起動時取得
起動時取得
[1]全部入りAMI [2]Golden Image [3]最小構成AMI
29](https://image.slidesharecdn.com/20170822blackbeltdeploymentonaws-170822041216/85/AWS-Black-Belt-Online-Seminar-2017-Deployment-on-AWS-29-320.jpg)
![AMIにどこまでいれるか？
方式 メリット デメリット
[1]全部入りAMI 同一性の確保
起動時間が早い
デプロイ毎にAMIを作り直す
必要がある
[2]GoldenImage あとはアプリコードのみ最新
を取得すれば良く扱いやすい
[3]最小構成AMI 柔軟に中身を変更できる 起動処理に時間がかかる。場
合によっては外部ライブラリ
が取得できないことも
30](https://image.slidesharecdn.com/20170822blackbeltdeploymentonaws-170822041216/85/AWS-Black-Belt-Online-Seminar-2017-Deployment-on-AWS-30-320.jpg)
AWS Black Belt Online Seminar 2017 Deployment on AWS
- 1. 【AWS Black Belt Online Seminar】 Deployment on AWS アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 千葉 悠貴 2017.08.22
- 2. ✤ Name : 千葉 悠貴（ちば ゆうき） ✤ Role : Solutions Architect ✤ Segment : Internet Media ✤ Favorite Service : CloudFormation
- 3. AWS Black Belt Online Seminar とは AWSJのTechメンバがAWSに関する様々な事を紹介するオンラインセミナーです 【火曜 12:00~13:00】 主にAWSのソリューションや 業界カットでの使いどころなどを紹介 (例：IoT、金融業界向け etc.) ※今回だけ異なります 【水曜 18:00~19:00】 主にAWSサービスの紹介や アップデートの解説 (例：EC2、RDS、Lambda etc.) ※開催曜日と時間帯は変更となる場合がございます。 最新の情報は下記をご確認下さい。 オンラインセミナーのスケジュール&申し込みサイト – https://aws.amazon.com/jp/about-aws/events/webinars/ 3
- 4. 内容についての注意点 • 本資料では2017年8月22日時点のサービス内容および価格についてご説明しています。最新 の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 • 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に 相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 • 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途 消費税をご請求させていただきます。 • AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 4
- 6. アプリのデプロイメントに必要な要素 ✤ デプロイの自動化 ✤ デプロイのヘルスチェック ✤ 失敗時のロールバック ✤ 開発、本番など複数環境への考慮 ✤ AutoScalingへの対応 6
- 7. デプロイパターン／デプロイツールの選択肢 ✤ デプロイパターン - In-Placeデプロイ - Blue/Greenデプロイ - カナリアリリース ✤ デプロイツール - CodeDeploy - CloudFormation - ElasticBeanstalk etc... 7
- 10. 代表的なデプロイメントパターン 10 In-Place Blue/Green カナリアリリース v1 v2 v1 v1 v2 既存ノードのアセットを更新 (1台ずつデプロイする場合 ローリングデプロイと呼ぶ) 新規ノードを配備し、 デプロイ〜テスト後に トラフィックを切り替え 新バージョンをデプロイした 一部のノードを本番トラフィック に組み込みテストする (In-PlaceもBlue/Greenもあり) v1 v1 v２
- 11. In-Place デプロイメント ✤ デプロイ方法 – 既存ノードに新しいアセットを配置 – Pull型(ノードが自分から新規アセットを取得)がおすすめ – ロールバックは過去バージョンのアセットをIn-Placeデプロイ ✤ メリット – インフラ(ノード)の新規プロビジョニングが不要 – アプリケーション担当者のみで完結する ✤ デメリット – ロールバックに時間がかかる – 複数ノード間での一貫性の保持が難しい 11 v1 v2 v1
- 12. Blue/Green デプロイメント ✤ デプロイ方法 – 新規にノード(群)を作成し新しいアセットを配置 – 新環境でテストが通ったらトラフィックを切り替え(Swap) ✤ メリット – 本番環境に昇格する環境で事前テストができる – ロールバックは旧環境にSwapするだけ ✤ デメリット – 一時的に追加のリソースが必要 12 v1 v2
- 13. Blue/Green Swapパターン 13 Swap Load Balancer Route 53 ALB Target Group Target Group ◎切り替えが早い(DNSのTTLに依存しない) DNS Cutover Route 53 ALBALB Target Group Target Group ◎加重ルーティングが使える 必要に応じて 暖気申請を！
- 14. Route53 加重ルーティング ✤ ユースケース – A/Bテスト – サーバー毎に性能の偏りがある場合 – カナリアリリース 相対的な重みを 0-255で指定 Routing Policyに ”Weighted”を選択 14 http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-weighted 同じ名前・種類のレコードセットに重みをつけて、 ルーティング先の頻度を決定するRoute53の機能
- 15. カナリアリリース 15 v1 v1 v２ ✤ デプロイ方法 – 本番トラフィックを部分的に新バージョンのアプリにも流し、問題 なければデプロイ範囲を広げていく – In-Place：少数の既存ノードのアセットを更新する – Blue/Green：加重Routingでトラフィックを部分的にGreenに流す – ロールバックはカナリアホストを切り離すだけ ✤ メリット – 本番のトラフィックでテストするため、 サービスの全停止を防ぐことができる
- 17. AWSが提供する様々なデプロイツール/サービス 17 CloudFormation CodeDeploy Elastic Beanstalk OpsWorks Stacks SAM AMI
- 21. AWS CodeDeploy 21 ✤ アプリデプロイに特化したサービス – 指定したグループに、指定したファイルを、 指定した割合ずつデプロイ – 安全にデプロイするための様々な機能を提供 – In-Place, Blue/Greenに対応 ✤ エージェントを入れれば利用可能 – Pull型のデプロイ – Linux & Windows対応 ✤ デプロイに関連するアプリ再起動などの 処理をフックスクリプトで実行可能 Staging Production Dev Deployment groups Agent Agent Agent Agent Agent Agent Agent AWS CodeDeployv1, v2, v3
- 22. CodeDeploy - デプロイの流れ 配布物をアップロード（S3 またはGitHubリポジトリ) CodeDeployに デプロイを指示 CodeDeploy Agentが ポーリングしデプロイ指示を検知 CodeDeploy Agentが配布物をダ ウンロードし、AppSpecファイルに 従ってデプロイを実行
- 23. CodeDeploy - リビジョンとロールバック リビジョン ✤ ソースコード、Webページ、実行ファイル、スクリプトなどと AppSpecファイルをまとめたアーカイブ - Linux: zip, tar, compressed tar - Windows: zip ✤ S3バケットやGitHubリポジトリに保存 ロールバック ✤ 以前デプロイされたリビジョンを再デプロイできる ✤ デプロイメントが失敗した際に自動的にロールバックするようにデ プロイメントグループを設定することが可能
- 24. CodeDeploy - デプロイメントグループ ✤ アプリケーションをデプロイする単位を指定 ✤ リビジョンとグループを指定してデプロイする ✤ 下記のいずれか、または両方で指定可能 - EC2 タグ - Auto Scaling グループ ✤ カナリアリリースにも利用可能 Dev Test Prod v2.0 v1.2 v1.1 v2.0 v1.2 v1.1 v2.0 v1.2 v1.1
- 25. v2 v1 v1 v1 v1 v1 v1 v1 v2 v2 v1 v1 v1 v1 v1 v1 v2 v2 v2 v2 v1 v1 v1 v1 v2 v2 v2 v2 v2 v2 v2 v2 One-at-a-time Min. healthy hosts = 99% [Custom] Min. healthy hosts = 75% Half-at-a-time Min. healthy hosts = 50% All-at-once Min. healthy hosts = 0 CodeDeploy - デプロイメント構成
- 26. CodeDeploy - Blue/Greenデプロイ 26 ✤ Green環境へのデプロイとCLB/ALBでのSwapをCodeDeployが実行 ✤ Green環境は以下の２パターンをサポート - 既存のAuto Scalingグループのコピー - 事前に構築済みのGreen環境用のインスタンス群(デプロイメントグループ) ALB Target Group Target Group 0. ASG Copy 1. Deploy 2. Swap
- 28. CloudFormation + Custom AMI 28 Step1: 新規ノードに最新のアセットを デプロイしCustom AMIを作成 v1 v2 v2 Step2: CloudFormationでCustomAMI からGreen環境 (AutoScalingGroupなど)を作成 Step3: Blue環境からGreen環境へSwap (Swap作業もCLI/SDKを利用し た自動化を推奨) ✤ CloudFormationはAWSリソース をテンプレート化しデプロイする サービス - アプリを含めたAMIからインスタンス ごとデプロイ - アプリのデプロイサービスではない ため、In-Placeデプロイはできない ✤ CodeDeployとの組み合わせも可 - MWまでをAMI化し、アプリは起動時 にCodeDeployでIn-Placeデプロイ
- 30. AMIにどこまでいれるか？ 方式 メリット デメリット [1]全部入りAMI 同一性の確保 起動時間が早い デプロイ毎にAMIを作り直す 必要がある [2]GoldenImage あとはアプリコードのみ最新 を取得すれば良く扱いやすい [3]最小構成AMI 柔軟に中身を変更できる 起動処理に時間がかかる。場 合によっては外部ライブラリ が取得できないことも 30
- 31. Custom AMI の継続的インテグレーション 31 https://aws.amazon.com/jp/blogs/news/how-to-create-an-ami-builder-with-aws-codebuild-and-hashicorp-packer/
- 33. Elastic Beanstalk 33 ✤ 速く簡単にアプリケーションをデプロイ可能 ✤ インフラストラクチャの準備＆運営からアプリ ケーションスタックの管理まで自動化 ✤ Auto Scalingによりコストを抑えながらスケー ラビリティを確保 ✤ Java, PHP, Ruby, Python, Node.js, .NET, Docker, Go, カスタムプラットフォームに対応 定番構成の構築・アプリデプロイの自動化サービス
- 34. Elastic Beanstalk - デプロイの選択肢 34 http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html 方式 失敗時の影響 時間 ダウンタイム ELB 暖気 DNS切替 ロールバック デプロイ先 All at once ダウンタイム発 生 🕐 ダウンタイ ム発生 不要 無し 再デプロイ 既存 Rolling 1バッチ分だけ サービスアウト 🕐🕐 (バッチサイ ズに依存) 無し 不要 無し 再デプロイ 既存 Rolling with additional batch 最初のバッチで あれば最小 🕐🕐🕐 (バッチサイ ズに依存) 無し 不要 無し 再デプロイ 新規+既存 Immutable 最小 🕐🕐🕐🕐 無し 不要 無し 再デプロイ 新規 Blue/Green (URL swap) 最小 🕐🕐🕐🕐 無し 必要 有り URL swap 新規 Route53 による切替 最小 🕐🕐🕐🕐 無し 必要 有り URL swap 新規
- 36. OpsWorks Stacks 36 ✤ Chefのレシピを使って、デプロイや運用 タスクを自動化 ✤ ライフサイクルイベントにより動的な構成 変更への対応が可能 ✤ アプリデプロイに特化した機能が使いたい 場合はCodeDeployと併用も可能 アプリケーションやデータベースの構成管理サービス AWS OpsWorks スタック LBレイヤー Webレイヤー DBレイヤー EC2インスタンス上の OpsWorksエージェント
- 37. OpsWorks Stacks - デプロイ方法 37 http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/best-deploy.html ✤ OpsWorksのスタックコマンドをインスタンスを指定して実行 – Deploy コマンド (アプリケーション用) – Update Custom Cookbooks コマンド (クックブック用) ✤ ローリングデプロイやBlue/Greenデプロイなどの仕組みはOpsWorks の機能にはないため、自動化したい場合個別の作り込みが必要 – ローリングデプロイ ヘルスチェックを確認しながら1台づつDeployコマンドを実行する – Blue/Green 新規スタック作成〜SwapまでをCloudFormationなどで自動化する
- 39. CloudFormation + ECS/ECR 39 Step1: DockfileからDockerイメージを Buildし、ECRにPush Cluster Step2: CloudFormationのテンプレート でタスク定義内のECRのイメー ジタグを更新しUpdateStack (ECSサービスの初回作成も CloudFormationで実施する) Step3: ECSのサービス更新がおこなわれ、 新規タスクがローリングデプロイ される ✤ ECSサービスの更新では、新しい Task定義で新規タスクをデプロ イし古いタスクを削除していく ✤ CloudFormationでタスク定義、 ECSサービスの作成/更新をおこ なうことでデプロイ自動化が可能
- 40. ECS – Greenテストとカナリアリリース 40 https://aws.amazon.com/jp/blogs/news/bluegreen-deployments-with-amazon-ecs/ https://github.com/awslabs/ecs-canary-blue-green-deployment Route 53 ALBALB Target Group Target Group ✤ ECSのマネージド更新もBlue/Greenデプ ロイ(コンテナが入れ替わる)だが、自動的 にローリングアップデートされてしまう ✤ Green環境でのテストやカナリアリリース をおこないたい場合、別途ECSサービスを 作成する ✤ 切替方式はEC2と同様DNS Cutoverか Swap LoadBalancerで ✤ カナリアリリースしたい場合Route53の 加重ルーティングがおすすめ
- 42. Serverless Application Model ✤ サーバレスアプリに最適化したAWS CloudFomationの拡張 ✤ サーバレスアプリ用の新たなリソースタイプ - 関数 - API - テーブル ✤ CloudFormationがサポートしているすべてのものをサポート ✤ 既存のファンクションをSAMテンプレートとしてエクスポート可能 ✤ オープンな仕様（Apache 2.0） 42 http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-ct-example-use-app-spec.html
- 43. SAM − デプロイの流れ Step1 : SAMの表記方法でCloudFormation テンプレートを作成する Step2 : AWS CLIのcloudformation package コマンドでパッケージ化し、S3バケッ トに格納する Step3 : AWS CLIのcloudformation deploy コマンドでパッケージをデプロイする 43 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
- 45. CI/CDパイプライン Source Build Test Deploy 継続的インテグレーション 継続的デプロイメント 継続的デリバリー
- 46. AWS Code Services AWS CodeCommit ✤ セキュア、スケーラブルなGit互換のリポジトリサービス ✤ スタンダードなGit Toolからアクセス可能 ✤ PushなどのイベントをトリガーにSNS/Lambdaを呼び出し可能 AWS CodeBuild ✤ スケーラビリティに優れたビルドサービス ✤ ソースのコンパイル、テスト、パッケージ生成をサポート ✤ Dockerイメージの作成も可能 AWS CodePipeline ✤ リリースプロセスのモデル化と見える化を実現 ✤ カスタムアクションによる柔軟なパイプライン作成が可能 ✤ 様々なAWSサービスや3rdパーティ製品との統合をサポート
- 47. CodePipelineがサポートするデプロイパターン(2017年8月時点) 47 EC2 Platform Deployment Tool CloudFormation + Custom AMI CodeDeploy Elastic Beanstalk OpsWorks Stacks Elastic Beanstalk OpsWorks Stacks LambdaECS CloudFormation (SAM)CloudFormation + ECS/ECR EC2(仮想マシン) Dockerコンテナ サーバーレス ※OpsWorks Stacksは東京リージョン未対応
- 49. ECSの継続的デプロイメント 49 Developers AWS CodeCommit AWS CodePipeline AWS CodeBuild AWS CloudFormation Amazon ECS Amazon ECS/ECR 1.git pushで リポジトリを更新 2.CodePipeline が更新を検知し パイプラインを開始 4.CloudFormationが ECRのDockerイメージを ECSクラスタに展開 3.CodeBuildがDockerイメージを ビルドしECRへプッシュ https://aws.amazon.com/jp/blogs/news/continuous-deployment-to-amazon-ecs-using-aws- codepipeline-aws-codebuild-amazon-ecr-and-aws-cloudformation/
- 50. サーバーレスアプリの継続的デプロイメント 50 Developers AWS CodeCommit AWS CodePipeline AWS CodeBuild AWS CloudFormation 1.git pushで リポジトリを更新 2.CodePipeline が更新を 検知しパイプラインを開始 4.CloudFormationの Create/Execute Changeset を実行しSAMパッケージをデプロイ 3.CodeBuildがpackageコマンド でパッケージ化し、生成したパッ ケージをS3バケットに格納 S3 Bucket Serverless Application https://d0.awsstatic.com/events/jp/2017/summit/devday/D4T7-6.pdf
- 51. 51 AWS CodeStar
- 56. Complete!
- 57. セットアップ内容 ✤ サンプルアプリケーション - EC2 or Beanstalk or Lambda ✤ CodeCommitリポジトリ ✤ CodeBuildビルドプロジェクト ✤ デプロイツール - CodeDeploy or Beanstalk or CloudFormation ✤ CodePipeline 継続的デプロイメントパイプライン ✤ CloudWatchメトリクス ✤ プロジェクトダッシュボード
- 60. 60 FAQ
- 61. EC2(仮想マシン)へのデプロイ方法の選択方針は？ 61 ✤ プラットフォームの選択 – EC2は一番汎用性があり、新機能がすぐに使える – Beanstalk, OpsWorks Stacksはアプリ、MW、インフラなどの構成管理を 任せられる一方、仕様や制約を受け入れる必要がある ✤ デプロイツールの選択 – より”アプリケーションのデプロイ”に特化しているのはCodeDeployと Elastic Beanstalk – アプリデプロイだけでなくインフラのプロビジョニングも考慮し、 CloudFormationとその他の各ツールを組み合わせで使うのがベスト
- 62. 本番、開発など複数環境への対応は？ 62 ✤ 環境変数などを利用して、ソースコードから設定情報を分離する – EC2(AMI)：インスタンスタグ – CloudFormation：Parameters セクション – Elastic Beanstalk： .ebextensionsのnamespaceオプション – OpsWorks Stacks：アプリケーション環境変数 – ECS：タスク定義のenvironmentプロパティ(コンテナ環境変数) – Lambda：Lambda関数の環境変数 ✤ 実装例 on EC2 – タグ値に変数を指定し、 user-dataなどで指定した起動スクリプト 内インスタンス起動時にインスタンス内部の環境変数を書き変える – インスタンスメタデータで自身のインスタンスIDを取得し、 describe-instanceでタグ値を確認する http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
- 63. パスワード等の秘密情報を上手く扱うには？ ✤ EC2 Systems Managerのパラメータストアを使う – AWS Key Management Service (KMS)の鍵を使って暗号化しな がらパラメータを保存可能 – そのKMSの鍵を扱える権限を持っている場合のみ、復号しながら 取り出すことが可能 ✤ 実装例 on ECS – コンテナのEntrypointでパラメータストアから情報を取り出し、 アプリケーションに環境変数で渡す – そのコンテナのタスクには、対応するKMSの鍵を操作できる権限 を持ったIAMロールを指定する https://aws.amazon.com/jp/blogs/news/managing-secrets-for-amazon-ecs-applications-using- parameter-store-and-iam-roles-for-tasks/63
- 64. デプロイにおけるDevとOpsの役割分担は？ ✤ DevとOpsの責任共有モデルを作る – サービスはアプリとインフラが揃って正常に稼働する ⇒アプリ=Dev、インフラ=Opsという分担はしない – サービスのリリースプロセスの中で分界点を考える ⇒テスト環境まではDev、本番環境からはOpsなど ✤ 同一性が担保しやすいコンポーネントを分界点とする – AMI – Dockerイメージ – CloudFormationテンプレート – Green環境 64
- 65. まとめ ✤ デプロイパターン – AWSはBlue/Greenやカナリアリリースといったデプロイパターン をサポートするツール／サービスを多数提供 – Blue/Greenの切替はLBまたはDNSで実現する – カナリアリリースにはRoute53の加重ルーティングを活用する ✤ デプロイツール – プラットフォームに合わせて最適なツールを選択する – 運用形態に合わせて複数のツールを組み合わせて最適化する ✤ 継続的デプロイ – Codeサービスを活用しフルマネージドのパイプラインを構築可能 65
- 67. 参考情報 ✤ ホワイトペーパー – Blue/Green Deployments on AWS – AWS での継続的統合と継続的デリバリーの実践 – Infrastructure as Code ✤ クラウド活用資料集 – 開発者ツールカテゴリ – 管理ツールカテゴリ – AWSのプロビジョニングからデプロイまで 67
- 68. 68