AWS環境でIaCを使い始めて運用するためのメリットデメリットと注意点

Slide 1

Slide 1 text

AWS環境でIaCを使い始めて運⽤するためのメリットデメリットと注意点クラスメソッド株式会社 AWS事業本部コンサルティング部 moko (@mokocm ) 2020/06/26

Slide 2

Slide 2 text

2 ⾃⼰紹介もこクラスメソッド株式会社 AWS事業本部コンサルティング部ソリューションアーキテクト 2020 APN AWS Top Engineers 現職: Terraform/CDKでAWS環境の構築前職: ECサイトのSREっぽい事好き: アプリとインフラの中間、TypeScript 好きなAWSサービス: ECS/Amplify/CDK Twitter/GitHub: mokocm

Slide 3

Slide 3 text

3 本⽇お話しすること・IaC(Infrastructure as Code)の利点､⽋点・Terraform/CloudFormation/CDKの紹介・IaCの運⽤⽅法(例) ・まとめ

Slide 4

Slide 4 text

4 今回持って帰って欲しい事 Infrastructure as Codeを利点と⽋点を理解して、本番環境でも利⽤出来るかを判断出来るようになり、運⽤が苦じゃなくなる

Slide 5

Slide 5 text

5 対象＝既にAWS環境でゴリゴリIaCとかCI/CDをしてる⽅は物⾜りないかもしれません。

Slide 6

Slide 6 text

6 ・IaCの利点､⽋点・Terraform/CloudFormation/CDKの紹介・IaCの運⽤⽅法(例) ・まとめ

Slide 7

Slide 7 text

IaCとは︖ Infrastructure as Code(IaC) AWS環境やOSなどの構成をコードベースで記述、更新を⾏うツール、サービス AWSだとTerraform/CloudFormation/CDK/OpsWorks など

Slide 8

Slide 8 text

8 利点・環境の変更をコードベースでレビュー出来る・⼿動での適⽤が無くなるため、ミスが少なくなる・GitHubなどと連携してIssue/PRでトラッキングできる・最新の環境をコードベースで管理出来るため、管理が楽 ※AWS環境を⼿で触らないようしている場合に限る・楽しい←重要

Slide 9

Slide 9 text

9 IaCを導⼊することで幸せになる例・⼤規模(20台〜)かつAutoScaling Groupが複数環境ある・構成変更を⾏う時に⼤量の環境に対してマネコンから⼿動で更新しないといけない・同じような構成で複数の環境を⽤意する必要がある

Slide 10

Slide 10 text

10 IaCを導⼊することで幸せになる例・⼤規模(20台〜)かつAutoScaling Groupが複数環境ある →複数の環境に対してアップデートが出来る・構成変更を⾏う時に⼤量の環境に対してマネコンから⼿動で更新しないといけない・同じような構成で複数の環境を⽤意する必要がある

Slide 11

Slide 11 text

11 IaCを導⼊することで幸せになる例・⼤規模(20台〜)かつAutoScaling Groupが複数環境ある →複数の環境に対してアップデートが出来る・構成変更を⾏う時に⼤量の環境に対してマネコンから⼿動で更新しないといけない →コードベースで管理出来るため、ミスを少なくして時間を節約・同じような構成で複数の環境を⽤意する必要がある

Slide 12

Slide 12 text

12 IaCを導⼊することで幸せになる例・⼤規模(20台〜)かつAutoScaling Groupが複数環境ある →複数の環境に対してアップデートが出来る・構成変更を⾏う時に⼤量の環境に対してマネコンから⼿動で更新しないといけない →コードベースで管理出来るため、ミスを少なくして時間を節約・同じような構成で複数の環境を⽤意する必要がある →コードを使い回すことで同じ環境を簡単に早く⽤意出来る

Slide 13

Slide 13 text

13 ⽋点・Terraform/CloudFormation/CDKなど、ツールに依存するため学習コストが増える・暗黙的なデフォルト値がAWSマネコンのデフォルト値と違う場合がある・IaC管理外でAWS環境を更新すると対応が⼤変になる・ツール固有のバグを踏むことがある・時間がかかる

Slide 14

Slide 14 text

14 ⽋点・Terraform/CloudFormation/CDKなど、ツールに依存するため学習コストが増える・暗黙的なデフォルト値がAWSマネコンのデフォルト値と違う場合がある・IaC管理外でAWS環境を更新すると対応が⼤変になる・ツール固有のバグを踏むことがある・時間がかかる

Slide 15

Slide 15 text

15 ツール固有のバグを踏むことがある TerraformのSecurity Group Cycle Error… Applyしても出続ける謎の差分… 実⾏中に切れるセッション… エラーログにGitHubのIssueのリンク… 環境とコード上の差分を全て⾒てくれない…

Slide 16

Slide 16 text

16 時間がかかるマネコンからポチポチしたほうが早い場合もある

Slide 17

Slide 17 text

17 AWSの知識に加えてIaCの学習コストが掛かることを妥協できますか︖ ⼤量の差分を⽬の前にして、諦めずにやっていけますか︖ IaCに掛けるコストと規模が⾒合っていますか︖

Slide 18

Slide 18 text

18 そもそもIaCを導⼊する必要が本当にあるのか︖

Slide 19

Slide 19 text

19 ･･･とは⾔っても導⼊した⽅が良かったり、後々楽だったりする場合がある。 IaCを使い始めて運⽤をするなら、マネコンで触らない⽅が良い構築だけで、運⽤はIaCを離れるなら

Slide 20

Slide 20 text

20 ・IaCの利点､⽋点・Terraform/CloudFormation/CDKの紹介・IaCの運⽤⽅法(例) ・まとめ

Slide 21

Slide 21 text

21 Terraform HashiCorpが⼿がけるクラウドの構成管理ツール AWS以外にもGCP/Azure/DigitalOcean/CloudFlareなどが対応 Providerを独⾃で⽤意することが出来る。 HCL(HashiCorp Configuration Language)でインフラを記述様々なサービスで対応、とても書きやすい

Slide 22

Slide 22 text

22 Terraform // vpc resource "aws_vpc" "vpc" { cidr_block = "10.0.0.0/16" } // igw resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.vpc.id } // subnet (a) resource "aws_subnet" "subnet_a" { cidr_block = "10.0.0.0/24" vpc_id = aws_vpc.vpc.id availability_zone = "ap-northeast-1a" } // subnet (c) resource "aws_subnet" "subnet_c" { cidr_block = "10.0.0.1/24" vpc_id = aws_vpc.vpc.id availability_zone = "ap-northeast-1c" }

Slide 23

Slide 23 text

23 Terraform // Route Table(0.0.0.0/0 igw) resource "aws_route_table" "public" { vpc_id = aws_vpc.vpc.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.igw.id } } // RouteTableにAssociation resource "aws_route_table_association” "subnet_a" { route_table_id = aws_route_table.public.id subnet_id = aws_subnet.subnet_a.id } resource "aws_route_table_association" "subnet_c" { route_table_id = aws_route_table.public.id subnet_id = aws_subnet.subnet_c.id }

Slide 24

Slide 24 text

24 CloudFormation AWSが提供するIaCツールリソースをJSON/YAMLで記述・Stackset機能でリージョン、 AWSアカウントに⼀括実⾏が可能・プログラミングが書けなくても良い感じに書ける

Slide 25

Slide 25 text

25 CDK 使い慣れたプログラミング⾔語から CloudFormationを出⼒⼀般的なCloudFormationのように明⽰的に全てのリソースを記述出来るほか、数⾏で複数のリソースを作れるモジュールが提供 JavaScript/TypeScript/Python/Java/C#で利⽤可能今激アツなIaCツール

Slide 26

Slide 26 text

26 CDK import { Stack, Construct, StackProps, Duration } from '@aws-cdk/core'; import { Vpc } from '@aws-cdk/aws-ec2’ export class SlackTranslateBotStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const vpc = new Vpc(this, 'TheVPC', { cidr: "10.0.0.0/16" }) } }

Slide 27

Slide 27 text

27 CDK Ref: h'ps://dev.classmethod.jp/ar6cles/aws-cdk-intro-nw/

Slide 28

Slide 28 text

28 CDK https://dev.classmethod.jp/articles/aws-cdk-serverless-develop/ CDK + Lambdaで開発がめちゃめちゃ捗る︕ constructor(scope: Construct, id: string,props?:StackProps) { super(scope, id, props); const lambda = new NodejsFunction(this, 'lambda', { entry: 'lambda/app.ts’, handler: 'handler’, runtime: Runtime.NODEJS_12_X, timeout: Duration.minutes(5) }); const api = new LambdaRestApi(this, 'api', { handler: lambda }); }

Slide 29

Slide 29 text

29 その他 | Serverless ・AWS SAM(Serverless Application Model) ・CLIとCloudFormationの拡張、デプロイが楽・実態はCloudFormationのTransform ・Serverless Framework ・ymlでサーバーレス環境を簡単に設定

Slide 30

Slide 30 text

30 ・IaCの利点､⽋点・Terraform/CloudFormation/CDKの紹介・IaCの運⽤⽅法(例) ・まとめ

Slide 31

Slide 31 text

31 IaCの運⽤⽅法・Gitで管理して、開発者がトピックブランチからmasterブランチに Pull Requestを出し、CIで現環境との差分、コードのレビューを受ける・もちろんmasterブランチは保護して、承認なく直接Push出来ないように・masterブランチにマージされたら環境に適⽤する・Terraformの場合はS3にtfstateを保存する terraform { backend "s3" { bucket = "bucket-name-here" key = "terraform.tfstate" encrypt = ture region = "ap-northeast-1" } }

Slide 32

Slide 32 text

32 運⽤⽅法 | GitHub

Slide 33

Slide 33 text

33 運⽤⽅法 | GitHub

Slide 34

Slide 34 text

34 運⽤⽅法 | GitHub

Slide 35

Slide 35 text

35 運⽤⽅法 | Terraform Cloud Terraform Cloudを使うのもあり。 https://dev.classmethod.jp/articles/terraform-cloud/

Slide 36

Slide 36 text

36 運⽤⽅法 | Terraform Cloud

Slide 37

Slide 37 text

37 IaCの運⽤⽅法・IaCの実⾏に使うIAM UserにのみAWS環境の編集権限を与える・普段マネコンを使うユーザーにはReadOnlyAccessポリシーを付与・本当に⼿動での対応が必要な場合にのみ⼀時的に権限を付与するなど・AWS環境を⼿で触らない

Slide 38

Slide 38 text

38 AWS環境を素⼿で触らない強い意志

Slide 39

Slide 39 text

39 AWS環境を素⼿で触らない強い意思・IaCで管理、運⽤するならAWS環境を直接触らない強い意志が必要・環境の変更はGitHub上で承認を受けてmasterにマージする＝masterブランチが最新である⽅が整合性が取れて管理しやすい・出来るならば、OSレイヤーは簡潔にして極⼒触らずに、使い捨て出来るように

Slide 40

Slide 40 text

40 IaCの運⽤⽅法 Q. それって「Immutable Infrastructure」では︖

Slide 41

Slide 41 text

41 IaCの運⽤⽅法 Q. それって「Immutable Infrastructure」では︖ A. はい。

Slide 42

Slide 42 text

42 IaCの運⽤⽅法 Q. それって「Immutable Infrastructure」では︖ A. はい。 // あくまで個⼈的感想であり理想論で、今⽇⼀番伝えたかった事開発者はインフラを積極的に世話したいとは思わないしアプリケーション開発に集中したい

Slide 43

Slide 43 text

43 IaCの運⽤⽅法 Q. それって「Immutable Infrastructure」では︖ A. はい。 // あくまで個⼈的感想であり理想論で、今⽇⼀番伝えたかった事開発者はインフラを積極的に世話したいとは思わないしアプリケーション開発に集中したいせっかくクラウドにリフトするなら、インフラを極⼒世話しない環境にしませんか︖

Slide 44

Slide 44 text

44 ・IaCの利点､⽋点・Terraform/CloudFormation/CDKの紹介・IaCの運⽤⽅法(例) ・まとめ

Slide 45

Slide 45 text

45 まとめ・Infrastructure as Codeで運⽤する場合環境を素⼿で触らないようにする・これからオンプレミスからクラウドに移⾏する⽅は、 Immutable Infrastructureの考え⽅を再認識する・チームや組織でIaCツールを使っていけるモチベーションがあるのかを確認する