IaCで全てが上手くいくと思うなよ_失敗事例のご紹介.pdf

Slide 1

Slide 1 text

1 IaCで全てが上⼿くいくと思うなよ︕失敗事例のご紹介

Slide 2

Slide 2 text

2 ⾃⼰紹介⾨別優多 - moko クラスメソッド株式会社 AWS事業本部コンサルティング部ソリューションアーキテクト 2020 APN AWS Top Engineer 2021 APN AWS Top Engineer 2021 APN ALL AWS Certifications Engineer 前職: ECサイトのSREっぽい事⼊社: 2019/07 好きなIaCツール: TerraformたまにCDK, CFn 好きなAWSサービス: AppSync Twitter/GitHub: @mokocm

Slide 3

Slide 3 text

3 初めに数々のプロジェクトでIaCを利⽤してだいぶ後悔して分かった内容をまとめてます。

Slide 4

Slide 4 text

4 結論

Slide 5

Slide 5 text

5 結論(1/3) IaCは⼿段であり、⽬的ではないが、⽬標にするのは良い事

Slide 6

Slide 6 text

6 結論(2/3) 何も考えないでIaCを始めると破綻する

Slide 7

Slide 7 text

7 結論(3/3) リソースを素⼿で触らない強い意志

Slide 8

Slide 8 text

8 話すこと 1. IaC についてのおさらい 2. あるある失敗例3パターン 3. オレ流IaCベストプラクティス

Slide 9

Slide 9 text

9 1. IaCについてのおさらい

Slide 10

Slide 10 text

10 初めに IaC = Infrastructure as Code 本セッションではAWS環境のコード化(IaC化) についての話しです。 ※OS/ミドルレイヤーについては触れません

Slide 11

Slide 11 text

11 初めに IaCツールのご紹介

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

15 CDK Ref: https://dev.classmethod.jp/articles/aws-cdk-intro-nw/

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 2. あるある失敗例3パターン

Slide 18

Slide 18 text

18 あるある失敗例・プロジェクトメンバーがクラウド + IaC未経験で学習コストが発⽣するパターン・IaC化が⽬的になってるパターン・⼿動オペレーションで破綻するパターン

Slide 19

Slide 19 text

19 あるある失敗例・プロジェクトメンバーがクラウド + IaC未経験で学習コストが発⽣するパターン・IaC化が⽬的になってるパターン・⼿動オペレーションで破綻するパターン

Slide 20

Slide 20 text

20 あるある失敗例 | 学習コスト発⽣パターン・IaCツールには明⽰的にパラメーターを⼊れる必要がある・「マネコンでサクッと作ってた」物が裏でどのようなリソースが作成されるのかを把握する必要がある・CDKは良い感じに作ってくれるが、暗黙的に作成されるリソースを把握する必要がある・学習コスト発⽣パターンは、⼤半の場合は時間が解決してくれる。(そのうち慣れる)

Slide 21

Slide 21 text

21 あるある失敗例・プロジェクトメンバーがクラウド + IaC未経験で学習コストが発⽣するパターン・IaC化が⽬的になってるパターン・⼿動オペレーションで破綻するパターン

Slide 22

Slide 22 text

22 あるある失敗例 | IaC化が⽬的になってるパターン・IaCで管理するメリットが無いのに頑張ってIaCにしようとする・→別に構成管理する必要は無いのに無駄に頑張ってしまう・→結果「マネコンで作ってマネコンで運⽤したほうがよくね︖」になる・とは⾔ってもIaCのメリットはたくさんあるので、”⽬標”にして IaCで管理できないかを検討するのは重要。

Slide 23

Slide 23 text

23 あるある失敗例・プロジェクトメンバーがクラウド + IaC未経験で学習コストが発⽣するパターン・IaC化が⽬的になってるパターン・⼿動オペレーションで破綻するパターン⼀番あるある

Slide 24

Slide 24 text

24 あるある失敗例 | ⼿動オペレーションで破綻・IaCで管理しているリソースをマネコンから⼿動で変更してしまった・現環境を⾒てコード側で差分を埋めることはできるが、・IaCは「コードでリソースを管理」するのがメリット・IaCで良い感じにリソース管理してるけどデプロイは⼿動・これが⼀番良くない・⾃動化するべき

Slide 25

Slide 25 text

25 とある事故CloudFormationリポジトリ

Slide 26

Slide 26 text

26 あるある失敗例 | ⼿動オペレーションで破綻・CloudFormationではスタック(ファイル)を分割する事ができる・スタック間のパラメーターはOutputsで出⼒可能・他のスタックが親となるOutputsを⾒てパラメーターとして扱う

Slide 27

Slide 27 text

27 あるある失敗例 | ⼿動オペレーションで破綻・network.yml︓ VPC/Subnetのスタック・サブネットIDを出⼒・ec2.yml︓ EC2とSecurity Groupのスタック・network.ymlからサブネットIDを参照・EC2のIDを出⼒・alb.yml︓ ALBとTargetGroupのスタック・network.ymlからサブネットIDを参照・ec2.ymlからEC2のIDを参照上のスタックから順番にデプロイする必要がある

Slide 28

Slide 28 text

28 あるある失敗例 | ⼿動オペレーションで破綻・network.yml︓ VPC/Subnetのスタック・サブネットIDを出⼒・ec2.yml︓ EC2とSecurity Groupのスタック・network.ymlからサブネットIDを参照・EC2のIDを出⼒・alb.yml︓ ALBとTargetGroupのスタック・network.ymlからサブネットIDを参照・ec2.ymlからEC2のIDを参照ダウンタイムなしでEC2を⼊れ替えたいとなったらどうする︖

Slide 29

Slide 29 text

29 あるある失敗例 | ⼿動オペレーションで破綻・network.yml︓ VPC/Subnetのスタック・サブネットIDを出⼒・ec2.yml︓ EC2とSecurity Groupのスタック・network.ymlからサブネットIDを参照・EC2のIDを出⼒・alb.yml︓ ALBとTargetGroupのスタック・network.ymlからサブネットIDを参照・ec2.ymlからEC2のIDを参照 1. ec2.ymlで新しいEC2を作る 2. alb.ymlで新しいEC2をターゲットグループへ追加する 3. 正常にヘルスチェックが通って居ることを確認して、alb.ymlから古いEC2を削除する 4. ec2.ymlで古いEC2を削除する

Slide 30

Slide 30 text

30 つらい︕

Slide 31

Slide 31 text

31 あるある失敗例 | ⼿動オペレーションで破綻・どうしてこうなったのか・依存関係がごっちゃりしてしまっている・CloudFormationのスタックはライフサイクルごとに管理するべき・EC2とALBは同じスタックにすると楽になれた・とは⾔っても規模が⼤きいとめちゃめちゃなコード量になってしまうので⼀⻑⼀短・Nested Stackでまとめてデプロイする事もできるけどつらい・⼦Stackの更新差分が⾒れるようになったのは最近。

Slide 32

Slide 32 text

32 あるある失敗例 | ⼿動オペレーションで破綻・個⼈的には規模が⼤きくなればなるほどTerraformを推奨。・コマンド⼀発で全てのファイルの差分を⾒て良い感じにしてくれる $ terraform plan $ terraform apply ・そこら辺のツールの⽐較は深澤さんが喋ってくれるハズ

Slide 33

Slide 33 text

33 IaCのメリット

Slide 34

Slide 34 text

34 IaCのメリット（ざっくり・⼿動オペレーションによる⼈的ミスの最⼩化コードで環境をレビューできるデプロイも⾃動化したら最⾼ Pull Requestで証跡を残せる・管理されていないリソースが出来上がらない謎のSecurity Group、野良インスタンスが出来上がらない・コピペでサクサク作れる「同じ環境を別のアカウントでも展開したい･･･」なども簡単にできるなどなど･･･

Slide 35

Slide 35 text

35 これらは正しくIaCを使った時のみ受けれるメリット

Slide 36

Slide 36 text

36 IaCのデメリット・コードに起こすのがしんどい、時間がかかる慣れないと時間が掛かる・設計きちんと考えないといけないきちんとした設計や、Gitのフローを組まないと運⽤がしんどくなる・IaCを使った運⽤を投げ出してしまうマネコンで構成変更した⽅が楽な事に気がついてしまう誘惑に負けて⼿で触ったら最後･･･などなど･･･

Slide 37

Slide 37 text

37 3. オレ流IaCベストプラクティス

Slide 38

Slide 38 text

38 3. 1 IaCとの付き合い⽅を先に決める

Slide 39

Slide 39 text

39 3. 1 IaCとの付き合い⽅を先に決める・IaCを使った運⽤をするか、構築だけで使い捨てるか初期構築だけでIaCを利⽤してサクサク構築して、後の運⽤は⼿動オペレーションでやると割り切る。構成変更が頻繁でない場合は構築だけで使うのもアリ。この場合何も考えないでOK。・IaCで運⽤する場合⼤半の場合しっかりとした初期設計とIaCのデプロイフローがあれば軌道修正してなんとかなる。使い捨てるか、運⽤もずっとIaCでするかはきちんと決める。

Slide 40

Slide 40 text

40 3. 2 IaCもCI/CDする

Slide 41

Slide 41 text

41 3. 2 IaCもCI/CDする・Gitを適切に利⽤するバージョン管理システムは偉⼤。 Pull Requestをフル活⽤してレビューをきちんとする・CI/CDをきちんと整える Linterとか⼊れるとPull Requestの時点でテストしてくれるのでオススメ Mergeしたら⾃動でデプロイが⾛るようにする。⼿動デプロイは⽢え。オペミスの根本的な原因。普通のアプリケーション開発と同じように扱う。

Slide 42

Slide 42 text

42 3. 2 IaCもCI/CDする

Slide 43

Slide 43 text

43 3. 2 IaCもCI/CDする

Slide 44

Slide 44 text

44 3. 2 IaCもCI/CDする

Slide 45

Slide 45 text

45 3. 3 AWS環境は素⼿で触らない

Slide 46

Slide 46 text

46 絶対に触らないでください

Slide 47

Slide 47 text

47 3. 3 AWS環境は素⼿で触らない・AWS環境は素⼿で触らない(超重要) Pull Requestで承認されたリソースだけを⾃動でデプロイしてるのに、⼿動でAWS環境を触るとこれまでの苦労が⽔の泡。もちろんAWS環境の更新差分をコードに起こして何も無かったことにできるけど、不⽑なのでやめましょう。・マネコンで使うIAM権限はReadOnlyにする本当に必要な場合にのみAdmin権限等を取得できるフローにして、物理的に触れないようにしてしまう。 AWS環境は素⼿で絶対に触らない

Slide 48

Slide 48 text

48 3. 4 スケーリングさせる

Slide 49

Slide 49 text

49 3. 4 スケーリングさせる・スケーリングできる環境にするのは重要。 AWSの強みは好きなタイミングでインスタンスを数分で調達できること。（もちろん難しいのは重々承知の上で、）せっかくクラウドに持ってくるならスケーリングできるようアプリケーションを改修しましょう。ガンガンスケーリングさせよう︕

Slide 50

Slide 50 text

50 3. 5 アプリのデプロイとIaCは別で考える

Slide 51

Slide 51 text

51 3. 5 アプリのデプロイとIaCは別で考える・アプリケーションのデプロイはアプリケーションのリポジトリ内のCI/CDパイプラインで完結させるべきデプロイのために毎回CloudFormation/Terraformをこねくり回すのはしんどいので分離する。・インフラとアプリの境界線をきちんと引く AutoScalingでAMIを⼊れ替える例) ・インフラ︓VPC, Subnet, EC2, AutoScaling, Codeシリーズ初期設定・アプリ︓PackerでAMI作ってCodeシリーズを直接叩く・Golden AMIにするかuser-dataにするかは好み AWS CDK / Copilot / SAMなどアプリケーションとセットでインフラを作れるツールの場合はセットで扱う。

Slide 52

Slide 52 text

52 まとめ

Slide 53

Slide 53 text

53 まとめ・IaCのメリットはデカいので、是⾮使って⾏こうただ、”使うことが⽬的”にはならないように注意が必要。・ある程度注意するポイントを意識して進めればOK IaC、デプロイフローに現状銀の弾丸はないので、プロジェクトに合わせてカスタマイズしていくと良い・せっかくAWSに作るならより良い環境にしていこうスケーリングできるようにしたり、CI/CD周り整備したり、して、より良い環境を作っていこう