導入結果
ネットワーク構成の可視化により分かったこと
常に最新のネットワーク構成図を提供できるようになったことで、ネットワークの全体像や個別リソースの役割と関係性が簡単に把握できるようになり、以下のようなことが分かりました。
- 放置されていた、これまで知らなかったサーバの存在や、すでに不要となったELBやProxyなどの存在
- 特定のEC2インスタンスを調査したい際、どのような経路にアクセスできるか
- 思った以上にネットワーク設計が複雑になっていたこと
可視化された複雑さ
おそらく図をご覧いただければ一目瞭然ですね……（こちらはSREチームのメンテナンス用のインスタンスなのでセキュリティ的に公開して問題ないものになります）。
第一印象を端的にまとめると、なんか汚いですよね。
しかし、それはCloudMapperが悪いのではありません、実際に複雑な設定になっているものがそのまま図示されているのです。今回の図で特にグレーの線が多いのは、変更作業の影響を局所化するために、個別のサービス単位でSecurityGroupを作成しており、それがすべて描画されているためです。
これは予想外の気づきでしたが、CloudMapperのおかげで、今後のSecurityGroupの作成ポリシーを変更するきっかけになりました。
まとめ
ネットワーク設定の部分は手を加える機会が少ないので、塩漬け状態で管理するケースも少なくないです。しかし、ここ数年はインフラレイヤーも変化が激しく、放置しておくとあっという間にレガシーな環境になってしまうため、日々更新されていきます。今携わっているシステムも、3年ほど前に作られたシステムですが、1年ごとに大きくネットワーク構成が変わっていたことが分かりました。
今回の課題に取り組んだことで、インフラのコード化（Infrastructure as Code）だけではシステムの全体像の把握は難しく、さらに手動でのドキュメント更新は現実的ではないことが分かりました。それに対して、CloudMapperやいくつかの仕組みを組み合わせることで、AWSのリソース可視化を自動で手軽にできることが分かりました。
今後の展望
昨今といっても数年前からですが、Cloud Native Computing Foundationという団体が設立されたように、クラウドネイティブと呼ばれるクラウドを前提としたシステム設計が浸透しはじめています。
クラウドネイティブになっても、リソース管理とは完全に無縁ではいられません。逆に、急速にサービス・リソースが拡大・縮小する時代だからこそ、運用作業もそれに追随するようなスピードが求められます。しかし、旧来の運用作業で変化に追随していくのは非常に厳しいのが現実です。
このため、運用作業の徹底した効率化、もっというとNoOps!の方向に向かうべきだと考えています。
今回のようなネットワーク構成図の作成も、構成が頻繁に変わるからこそ自動化が重要なファクターになりました。システム構成の変更に合わせて運用作業を柔軟に変更していくためにも、情報の可視化、手動作業の削減を日々行っていく必要があります。
今後も運用作業をなくし、NoOps!の方向に突き進んでいきたいと思います。
