LoginSignup
3
0

More than 1 year has passed since last update.

@emiki(emiki)

CloudFormationのベストプラクティス、あるのか？

Last updated at Posted at 2021-08-09

常々、CloudFormationテンプレートは本番環境で運用保守するの嫌だなあと思っています。

1.「CloudFormation、コレジャナイ」のきっかけ

まず「CloudFormation、コレジャナイ」と思ったきっかけになった出来事↓

image.png**

2021/7/22(木)「JAWS-UG CLI専門支部 #188R CloudFormation入門」のLTで発表した資料になります。

JAWS-UG朝会で波多野さんが**「CloudFormationに限らずIaC全般、イメージほど運用管理は楽にならない」**とおっしゃっており、その後のお話も私も常々感じていたことだったので首がもげるほど共感すると共に、「CloudFormation苦手って言っていいんだ！」という謎の希望を感じLTに至りました。
CloudFormationは本当に使いどころを考えないと

　楽しさ<初期環境構築の楽さ<<<<<<<<<運用負荷

となり、システム変更や運用保守時に大変な負荷になると考えています。

2.CloudFormationはクラウドの柔軟性を殺す

  • IaCのメリット
  • 誰でも全く同じインフラがスタックの展開だけで構築できる
  • 再現度が高い
  • IaCのデメリット
  • 変化に弱い
  • クラウドの利点である「変化に柔軟に対応できる」「アジリティ（Agility）」の一部を犠牲にする

3.汎用性を求めるためにパラメータを多用

  • 「他のシステム構築にも利用できるように汎用性を高めよう！パラメータを使おう！」

  • ⇒パラメータを多用すると再現性が落ち、CFnのメリットが減る

  • パラメータ変更要件があったとき、パラメータが紐づいている部分をすべてのテンプレートでコメントアウトするとか削除するとかして、紐づきを解除する必要がある

  • ⇒パラメータが別のスタックに紐づいていると「～in use.～なんちゃら」というエラーでパラメータ変更ができない

  • 一部変更するだけでも、紐づいてるパラメータが多いほど変更に関係ないリソースにまで影響が及び、スタック単位の大事故に繋がる可能性あり
    image.png

4.「置換」の恐ろしさ

スタックを展開する際に変更セットで「置換」の項目が「True」になっていて、そのまま展開してしまう事故（Replacementが走る）
image.png

（これを本番環境のRDSでやってしまい、RDSの中身を吹っ飛ばし空っぽのRDSが作成されたという話を聞きぞっとした）
「既存システムのパラメータの一部を変えるためにCFnテンプレートのパラメータ紐づいてる部分を時間をかけて全部コメントアウトして展開してパラメータ変更して再度展開したらreplacementが走って本番環境のEC2とRDSの中身吹っ飛んだ」 ということが起こる可能性は十分ありえる

「変更セットを確認すればいい」
「ロールバック設定にアラートを仕込んでおけば大丈夫」
⇒ その時のreplacementは阻止できても、その部分の変更はスタック更新で実施することを諦めてマネコンかCLIから変更、あとからCFnテンプレートがドリフトしない様に直す、という過程が発生

5.CloudFormationテンプレートの引き継ぎ

CFnを作成した構築チームの人がずっと張り付いていれば事故は起こりにくいが、多くの企業で異動のための引き継ぎや運用保守チームへ引き継ぐ過程が発生するはず。

  • システムの構成や概要を説明するだけではなく、CFnの場合「どこの何が何に紐づいてるか」を明確にしないとシステム変更で事故る確率が高くなる。
  • システムのごく一部変更するだけでも、紐づいてるパラメータが多いほど、変更に関係ないリソースまで影響が及び、さらにCFnに慣れていない運用保守メンバーが対応を実施することで、スタック単位の大事故発生確率が高くなる。

変更を依頼する立場からすると
「システム変更はこの部分しか依頼してないのになぜほかのリソースまで影響が出たのか？」
「この部分の変更だけなのに検証と調査とテンプレート修正に時間かかりすぎでは？ここだけ直すのにどうしてそんなに時間がかかのか？」

となり、依頼主と対応側の認識乖離が発生する可能性もある。

6.CloudFormationのユースケース

個人的に考えるCloudFormationのユースケース

★CFnが適しているケース

１．必ず実施すべきセキュリティ設定をテンプレートにしておく

例えば「CloudTrail証跡有効化する」「ルートアカウントのMFAを有効化しアクセスキーを削除する」等、アカウント開設時に実施すべき項目をテンプレにして必ず実施する決まりとする、など

２．ハンズオン

時間が限られており、一人ひとりが個人のAWSアカウントで全く同じ環境を準備する必要がある、などのケースではとても有効

３．本番環境の変更作業の前に検証環境を一発展開して検証

※ただし実際は「検証用のSWのライセンスがない」「大量インスタンスを展開すると多額の課金が発生」などの理由でそのままCFnテンプレートが使用できることは少ない

もし上記以外で有効な使いどころがあれば教えてください。

7.CloudFormationのメリットとともにデメリットも理解しておきたい

読み解くこと、記述ができることがゴールではなく、お客様のビジネスを助けるために最適なシステムを設計・構築・運用することが最終目標であるはずなので、CloudFormationのメリットもデメリットもおさえたうえで、使いどころを考えていかねばならないサービスだなぁと思います。

色々書き連ねましたが、伝えたいことはすべて波多野さんの資料にまとまっていますのでぜひお読みください。
CloudFormationの理想と現実 〜 冷静にCloudFormationを考える/20210722-jawsug-cli-cloudformation

そのCFnテンプレート引き継げますか？
言うては何ですけどテンプレート化だけなら時間をかければ誰でもできる

8.参考リンク

CFn、さまざまな便利機能もありますので学びつつ、使いどころをおさえて付き合っていきたいと思います。

9.ゆる募

「CloudFormationテンプレート引き継いだけど、今までより運用が楽になってすごくうれしい！」という話があればぜひ教えてください。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0