はじめに
僕が今の会社に入ってから、最も時間を割いて取り組んできたのがガバナンスの統一です。
入社前までは、インフラエンジニアが不在で、プロダクトごとに開発チームが組まれ、各々のルールで環境が構築されてきたため色々とポリシーがバラバラだったというような状況でした。
これを地道に、カイゼンしてきた取組についてご紹介します。
やったこと
おおよそ2年ほどかけて実施してきた内容は時系列順に以下のとおりです。
- リソースの棚卸し + 命名規則の統一
- インフラ基本設計書の作成
- AWS利用ガイドブックの作成
- CDKのモジュール化
- Slackへのガイドブック違反通知の自動化
リソースの棚卸し + 命名規則の統一
まずは、現状把握が必要です。
リソースを棚卸しして、それぞれの目的や誰が管理しているか？を明確化しました。
中には、古のリソースでもはや誰が管理しているのか？なんのためのリソースかも分からないということもありました。
所在不明なリソースがあることが分かったことだけでも大きな収穫だったと思います。
実際、この活動によって不要リソースを削除したり、スペックの適正化を行ったおかげでAWS利用料はおおよそ20%削減することもできました。
インフラ基本設計書の作成
システムは多々あれど、インフラ自身の要件はさほど変わりません。
例えばで言えば、
- サーバレスサービスを採用する
- インターネットとの通信は双方向暗号化する。AWS内部は非暗号化を許容する
- 命名規則はこうする
- ログは◯ヶ月間保存する
- IaCを採用して、デプロイサーバは統一する
などなど。
これらを全11章のインフラ基本設計書として準備し、これらを満たしていることを設計要件としています。
これで、新しく構築されるシステムや機能に関してはガバナンスを統一することができました。
既存のシステムに対しては、是正するために莫大な開発費がかかることもありますので、可能な限りは是正できましたがコスパも重視しつつ、対応しない選択もしています。
AWS利用ガイドブックの作成
インフラ基本設計書だけではカバーできない部分。
例えば、
- LambdaとECSの使い分けのようなサービス選定のユースケース
- RDSはリーダーインスタンスは横方向で拡縮、ライターインスタンスは縦方向の拡縮のようなサービス固有の設計方針や注意点
このあたりを、「AWSサービス利用」「コスト最適化」「セキュリティ」「テスト」「インシデント」の5分野に分けてガイドブックを作成しました。
相当なボリュームがありますが、一通り読めばきっとSAAは取れるんじゃないかな？というようなレベルを目指して作っています。
開発ベンダさんにもお渡ししているので、サービス利用に関する認識齟齬は発生しづらくなっているものの、読み物としてボリュームが大きいのではじめの理解にかかる学習コストは確実に上がっています。
準備８割という言葉もある通り、この学習コストが後々の運用を楽にすることに繋がっていると信じているので、このコスト増加は許容しています。
CDKのモジュール化
これは、過去に僕が投稿した記事を参照してもらえれば背景などはわかるかなと思います。
誰がCDKのコードを書いても、インフラ基本設計書などを最悪読んでいなかったとしてもルールに従うことができるような仕組みを作ろうと思いモジュール化をしています。
IaC自体、なかなかハードルが高いと感じている人も多いのが事実ですし、これまでCloudFormationを使ってたのでCDKを触ることもしんどい、みたいな声が社内でも聞こえてきます。これはベンダさん含めて。
まぁ、でも僕がコードを書けば済みますし、Cfnのコードを書くよりも、もっと言えばCDKのコードを１から書くよりも圧倒的にコーディングスピードは出ているので十分にメリットがあると思っています。
Slackへのガイドブック違反通知の自動化
色々自動化されるのは良いのだけれど、何が間違っていたの？どう設定すべきなの？が認知されないと意味がありません。
なので、以下のことをやりました。
- ConfigやSecurity Hubなどでガイドブックに従ったルールを策定しておく
- 違反したリソースがあれば、その内容をSlackの特定チャンネルへ通知する（修復はあえてしない）
この「修復はあえてしない」ことがポイントです。
もちろん、セキュリティ的に重大な脆弱性を生むようなものは修復の自動化まで検討すべきであるとは思うものの、まずは自分たちがルールを守れていないことを認識しなければスタート地点にも立てません。
なので、あえて、自動修復はさせないこととしています。
さいごに
以上のような取組を行ってきた結果、おおよそ僕の役割は設計内容のレビューやSlack通知があった場合の開発チームサポートが主になってきました。
これにより、例えば日々のAWS利用料をTableauで可視化したい！とか、Well-Archtected Frameworkの遵守度を確認して、遵守できていない部分は対応していきたい、などインフラエンジニアとしてやっていきたい業務に集中できる環境ができつつあります。
引き続き、よりよいクラウド環境を継続して構築・運用できるように頑張って取り組んでいきたいと思います。