IaCで全てが上手くいくと思うなよ_失敗事例のご紹介.pdf

Transcript

1. 1 IaCで全てが上⼿くいくと思うなよ︕失敗事例のご紹介
2. 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
3. 3 初めに 数々のプロジェクトでIaCを利⽤して だいぶ後悔して分かった内容をまとめてます。
4. 4 結論
5. 5 結論(1/3) IaCは⼿段であり、⽬的ではない が、⽬標にするのは良い事
6. 6 結論(2/3) 何も考えないでIaCを始めると破綻する
7. 7 結論(3/3) リソースを素⼿で触らない強い意志
8. 8 話すこと 1. IaC についてのおさらい 2. あるある失敗例3パターン 3. オレ流IaCベストプラクティス
9. 9 1. IaCについてのおさらい
10. 10 初めに IaC = Infrastructure as Code 本セッションではAWS環境のコード化(IaC化) についての話しです。 ※OS/ミドルレイヤーについては触れません
11. 11 初めに IaCツールのご紹介
12. 12 Terraform HashiCorpが⼿がける クラウドの構成管理ツール AWS以外にもGCP/Azure/DigitalOcean/CloudFlareなどが対応 Providerを独⾃で⽤意することが出来る。 HCL(HashiCorp Configuration Language)でインフラを記述 様々なサービスで対応、とても書きやすい
13. 13 CloudFormation AWSが提供するIaCツール リソースをJSON/YAMLで記述 ・Stackset機能でリージョン、 AWSアカウントに⼀括実⾏が可能 ・プログラミングが書けなくても 良い感じに書ける
14. 14 CDK 使い慣れたプログラミング⾔語から CloudFormationを出⼒ ⼀般的なCloudFormationのように明⽰的に全てのリソースを 記述出来るほか、数⾏で複数のリソースを作れるモジュールが提供 JavaScript/TypeScript/Python/Java/C#で利⽤可能
15. 15 CDK Ref: https://dev.classmethod.jp/articles/aws-cdk-intro-nw/
16. 16 その他 | Serverless ・AWS SAM(Serverless Application Model) ・CLIとCloudFormationの拡張、デプロイが楽 ・実態はCloudFormationのTransform ・Serverless Framework ・ymlでサーバーレス環境を簡単に設定
17. 17 2. あるある失敗例3パターン
18. 18 あるある失敗例 ・プロジェクトメンバーがクラウド + IaC未経験で 学習コストが発⽣するパターン ・IaC化が⽬的になってるパターン ・⼿動オペレーションで破綻するパターン
19. 19 あるある失敗例 ・プロジェクトメンバーがクラウド + IaC未経験で 学習コストが発⽣するパターン ・IaC化が⽬的になってるパターン ・⼿動オペレーションで破綻するパターン
20. 20 あるある失敗例 | 学習コスト発⽣パターン ・IaCツールには明⽰的にパラメーターを⼊れる必要がある ・「マネコンでサクッと作ってた」物が裏でどのような リソースが作成されるのかを把握する必要がある ・CDKは良い感じに作ってくれるが、暗黙的に作成される リソースを把握する必要がある ・学習コスト発⽣パターンは、⼤半の場合は時間が解決してく れる。(そのうち慣れる)
21. 21 あるある失敗例 ・プロジェクトメンバーがクラウド + IaC未経験で 学習コストが発⽣するパターン ・IaC化が⽬的になってるパターン ・⼿動オペレーションで破綻するパターン
22. 22 あるある失敗例 | IaC化が⽬的になってるパターン ・IaCで管理するメリットが無いのに頑張ってIaCにしようとする ・→別に構成管理する必要は無いのに無駄に頑張ってしまう ・→結果「マネコンで作ってマネコンで運⽤したほうがよくね︖」 になる ・とは⾔ってもIaCのメリットはたくさんあるので、”⽬標”にして IaCで管理できないかを検討するのは重要。
23. 23 あるある失敗例 ・プロジェクトメンバーがクラウド + IaC未経験で 学習コストが発⽣するパターン ・IaC化が⽬的になってるパターン ・⼿動オペレーションで破綻するパターン ⼀番あるある
24. 24 あるある失敗例 | ⼿動オペレーションで破綻 ・IaCで管理しているリソースをマネコンから⼿動で変更してしまった ・現環境を⾒てコード側で差分を埋めることはできるが、 ・IaCは「コードでリソースを管理」するのがメリット ・IaCで良い感じにリソース管理してるけどデプロイは⼿動 ・これが⼀番良くない ・⾃動化するべき
25. 25 とある事故CloudFormationリポジトリ
26. 26 あるある失敗例 | ⼿動オペレーションで破綻 ・CloudFormationではスタック(ファイル)を分割する事ができる ・スタック間のパラメーターはOutputsで出⼒可能 ・他のスタックが親となるOutputsを⾒てパラメーターとして扱う
27. 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を参照 上のスタックから順番にデプロイする必要がある
28. 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を⼊れ替えたいとなったらどうする︖
29. 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を削除する
30. 30 つらい︕
31. 31 あるある失敗例 | ⼿動オペレーションで破綻 ・どうしてこうなったのか ・依存関係がごっちゃりしてしまっている ・CloudFormationのスタックはライフサイクルごとに管理するべき ・EC2とALBは同じスタックにすると楽になれた ・とは⾔っても規模が⼤きいとめちゃめちゃなコード量になって しまうので⼀⻑⼀短 ・Nested Stackでまとめてデプロイする事もできるけどつらい ・⼦Stackの更新差分が⾒れるようになったのは最近。
32. 32 あるある失敗例 | ⼿動オペレーションで破綻 ・個⼈的には規模が⼤きくなればなるほどTerraformを推奨。 ・コマンド⼀発で全てのファイルの差分を⾒て良い感じにしてくれる $ terraform plan $ terraform apply ・そこら辺のツールの⽐較は深澤さんが喋ってくれるハズ
33. 33 IaCのメリット
34. 34 IaCのメリット（ざっくり ・⼿動オペレーションによる⼈的ミスの最⼩化 コードで環境をレビューできる デプロイも⾃動化したら最⾼ Pull Requestで証跡を残せる ・管理されていないリソースが出来上がらない 謎のSecurity Group、野良インスタンスが出来上がらない ・コピペでサクサク作れる 「同じ環境を別のアカウントでも展開したい･･･」なども簡 単にできる などなど･･･
35. 35 これらは正しくIaCを使った時のみ受けれる メリット
36. 36 IaCのデメリット ・コードに起こすのがしんどい、時間がかかる 慣れないと時間が掛かる ・設計きちんと考えないといけない きちんとした設計や、Gitのフローを組まないと運⽤がしん どくなる ・IaCを使った運⽤を投げ出してしまう マネコンで構成変更した⽅が楽な事に気がついてしまう 誘惑に負けて⼿で触ったら最後･･･ などなど･･･
37. 37 3. オレ流IaCベストプラクティス
38. 38 3. 1 IaCとの付き合い⽅を先に決める
39. 39 3. 1 IaCとの付き合い⽅を先に決める ・IaCを使った運⽤をするか、構築だけで使い捨てるか 初期構築だけでIaCを利⽤してサクサク構築して、後の運⽤ は⼿動オペレーションでやると割り切る。 構成変更が頻繁でない場合は構築だけで使うのもアリ。 この場合何も考えないでOK。 ・IaCで運⽤する場合 ⼤半の場合しっかりとした初期設計とIaCのデプロイフロー があれば軌道修正してなんとかなる。 使い捨てるか、運⽤もずっとIaCでするか はきちんと決める。
40. 40 3. 2 IaCもCI/CDする
41. 41 3. 2 IaCもCI/CDする ・Gitを適切に利⽤する バージョン管理システムは偉⼤。 Pull Requestをフル活⽤してレビューをきちんとする ・CI/CDをきちんと整える Linterとか⼊れるとPull Requestの時点でテストしてくれる のでオススメ Mergeしたら⾃動でデプロイが⾛るようにする。 ⼿動デプロイは⽢え。オペミスの根本的な原因。 普通のアプリケーション開発と同じように扱う。
42. 42 3. 2 IaCもCI/CDする
43. 43 3. 2 IaCもCI/CDする
44. 44 3. 2 IaCもCI/CDする
45. 45 3. 3 AWS環境は素⼿で触らない
46. 46 絶対に触らないでください
47. 47 3. 3 AWS環境は素⼿で触らない ・AWS環境は素⼿で触らない(超重要) Pull Requestで承認されたリソースだけを⾃動でデプロイし てるのに、⼿動でAWS環境を触るとこれまでの苦労が⽔の 泡。 もちろんAWS環境の更新差分をコードに起こして何も無 かったことにできるけど、不⽑なのでやめましょう。 ・マネコンで使うIAM権限はReadOnlyにする 本当に必要な場合にのみAdmin権限等を取得できるフロー にして、物理的に触れないようにしてしまう。 AWS環境は素⼿で絶対に触らない
48. 48 3. 4 スケーリングさせる
49. 49 3. 4 スケーリングさせる ・スケーリングできる環境にするのは重要。 AWSの強みは好きなタイミングでインスタンスを数分で調 達できること。 （もちろん難しいのは重々承知の上で、）せっかくクラウド に持ってくるならスケーリングできるようアプリケーション を改修しましょう。 ガンガンスケーリングさせよう︕
50. 50 3. 5 アプリのデプロイとIaCは別で考える
51. 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などアプリケーションとセット でインフラを作れるツールの場合はセットで扱う。
52. 52 まとめ
53. 53 まとめ ・IaCのメリットはデカいので、是⾮使って⾏こう ただ、”使うことが⽬的”にはならないように注意が必要。 ・ある程度注意するポイントを意識して進めればOK IaC、デプロイフローに現状銀の弾丸はないので、プロジェ クトに合わせてカスタマイズしていくと良い ・せっかくAWSに作るならより良い環境にしていこう スケーリングできるようにしたり、CI/CD周り整備したり、 して、より良い環境を作っていこう