📘

精神衛生を保ちながらAWSリソースを管理、更新するために大切なこと

2020/11/29に公開

AWS

インフラ

チーム

idea

なぜこの記事を書こうと思ったのか

３ヶ月ほど、新規開発で AWS リソースの設計、作成、更新、運用なども含めてガッツリ経験させて頂きました。
インフラのコード化には CloudFormation を使いました。

開発がひと段落して私の手から離れた後に、他のチームメンバーが CloudFormation に手を入れようとしたところ、非常に怖がっていました。
「しっかりドキュメントも書いてあるのに何故だろう？」と思いました。

どうやら 心理的安全性が低い ようで（AWS で何かやらかしたら怖い、もう本番で動いているし）細かい確認依頼が度々発生してしまい、チームの生産性が 著しく低下 してしまいました。

皆さんの中にも結構「AWS でやらかすのが怖い」と思っている方はいらっしゃるかと思いましたので、「精神衛生を保ったまま自信を持って AWS リソースを管理する」ためにはどうすれば良いかをまとめてみました。

AWS リソースの管理を任された方はもちろん、チームの生産性を向上させたいチームリーダーの方にも参考になれば良いなと思います😁

ステージング環境を用意すべし

タイトルそのままですが、必ずステージング環境を本番環境とは別に用意するようにしましょう。
「何かやらかしても大丈夫」と思える環境が丸ごと存在するのは大きな安心に繋がります。

意外とケチって作成していないチームもあるようなのですが、AWS ならコスト面でもそんなに重荷にはならないことが多いです。
何故なら、「従量課金」であることがクラウドサービスの大きなメリットであり、AWSでもそのメリットを享受できるからです。

Lambda や DynamoDB など、使った分だけ料金を支払うサービスを利用するようにしておくと、ステージング環境構築のハードルが下がります。

ステージング環境でやらかしても責めず、そこから学ぶことを促すべし

色々と考え方はあると思いますが、私の理解ではステージング環境は失敗をしてそこから学習するためにあります。

なので、ステージング環境でDBのデータを消してしまうなどのミスを犯したことに対して怒ったり責めたりするような雰囲気があるのでは、ステージング環境を構築している意味が無いと思います。

インフラはコード化するべし

手動で画面からポチポチ AWS リソースを作成するのではミスをする可能性が高いです。

基本的なことですが、ツールは何でも良いのでコード化しておくことをお勧めします。
コード化しておくことによって CI/CD パイプラインと統合することが出来ます。これにより生産性も上がり、ミスも減らすことが出来るでしょう。

ミスした個人ではなく仕組みを恨むカルチャーを作るべし

人間は誰でもミスをします。
誰かがやらかした時、その内容にもよるとは思いますが、ミスしたその人自身を非難していませんか？

私もそういうことが0だとは言えません（😅）が、「誰がやってもミスが起きないような仕組み」を構築できなかったチームの責任の方が大きいと思います。
人間がミスをするのは当たり前なのですから、それを前提とした仕組みを作っていく必要があります。

個人に反省を促して終わりにするよりも、一緒に仕組みを見直して見た方が生産的ではないでしょうか😊

【例】

コマンドを打ち間違えた → Mac から打つのではなく CI に頼るようにしよう
手順をミスした → チームの wiki はちゃんと用意されている？それは曖昧な記述になっていない？

細かくバックアップを取るべし

「やらかすのが怖い」の原因を掘っていくと、大体は DB や S3 のデータを消してしまうことです。
別にLambda関数を消してしまったとしても、コード自体は git に残っているでしょうから、それをまたデプロイすればどうってことありませんよね。

これも当然ですが、バックアップを細かく取りましょう。
AWS は、 RDS でも Dynamo でもデータのバックアップについてはしっかりサポートされていて簡単に作成することが出来ます。
S3 もアクシデントに対応するためにバージョニング機能を提供してくれています。https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ObjectVersioning.html

ほんの少しのお金をケチるべきでは無いでしょう。
バックアップの作成を自動化することももちろん出来ますので、一度設定しておけば安心です。

変更セットを確認すべし

コード化したインフラをデプロイする時には、必ず「この内容で実行しますがよろしいですか？」の確認をするタイミングがあります。
めんどくさいとついつい確認をスキップしていきなりデプロイとかしてしまいがちです。開発の本当に初期で、ステージング環境であるならばそれでも良いかもしれません。テンプレートは頻繁に書き換えるでしょうから、１つプロパティ値を変更しただけで毎回確認するのは面倒です。

しかし、予期しない挙動は突然やってきます。
リソースは更新されると思っていたら、更新はできなくて丸ごと置換扱いになったり。。。

結局実行したらどうなるか、というのは AWS にしか分からないのです。
そしてそれを画面や CLI から確認できるのですから、それを怠るべきではないでしょう。

余談ですが、 terraform では変更セットの確認がしやすいです。逆に CloudFormation だとちょっとこの辺の使い勝手が悪い印象です😅

DeletionPolicy をうべし

公式

DeletionPolicy 属性を使用すると、スタックが削除された際にリソースを保持または (場合によっては) バックアップできます。制御する各リソースに対して DeletionPolicy 属性を指定します。DeletionPolicy 属性が設定されていない場合、AWS CloudFormation ではデフォルトでリソースが削除されます。

DB や S3 には問答無用で付けておきましょう。
公式からの抜粋ですが、

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  myS3Bucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain

こんな感じで DeletionPolicy: Retain にしておくとこのリソースがテンプレートから削除された場合でもリソース自体は削除されずに残り続けます。
スタックの管理対象から外れるだけです。

クリティカルな事故が起きる可能性は極めて低いことをチームと共有すべし

そもそもエンジニアの心理的安全性を高めるためのここまでの施策を行うのですから、これらを全て行ったとしても当のエンジニアに伝わっていなければ意味がありません😓

「こうこうこういう対策をしているから気にせず作業してもらって大丈夫。もし何かあったらその時は一緒に改善策を考えよう！」 と伝えてみてください。

もちろん人にもよりますが、エンジニアは特に「何となく大丈夫」とか言われるよりも理屈で大丈夫な理由を説明した方が納得できる人が多いかもしれませんね（完全な個人的主観）
間違っても「やることやったから後はもう知らない」という態度をしてはいけません。

いかがでしたか。
「どれも当たり前だな」と思った方もいらっしゃるのでは無いかと思いますし、その通りです。
何も心理的安全性を高めるのに難しいことや特別なことをする必要は無いのです。

リーダーでないと判断できないような内容もあるかと思いますが、大事なのはチームのカルチャー作りです🧐
単なるチームの一員だとしてもチームカルチャーに良い影響を与えることは十分に可能です。

自分やチームが気持ちよく作業できるように、これらの指針が参考になれば幸いです。