インフラ初心者は、現場で使っているクラウドサービスの構成図を書くのがおすすめ
- よくハンズオンなどで、作りながらインフラを学ぶパターンが多いと思う
- 一方で、すでにできているものをインフラ構成図に落とし込む、ということをやると、いろんな学びが得られる
- ドキュメント整備のきっかけにもなるし、一石二鳥だ！
インフラ環境を構成図に落とし込むのが、なぜ勉強になるのか？
- 既存環境を図に落とし込む作業は、現状の構成を把握し理解する能力が求められる。ハンズオンで覚えた知識の復習にもなる。
- 例えば、図を書いているうちに「ロードバランサーってなんだっけ？」「サブネットグループがprivateかpublicかどうかを決めるのってどんな設定だったっけ？」と、基礎知識を振り返るきっかけが生まれる
- 普段、AWSのコンソール画面から操作していると、決まった流れの中で操作をしているため、あまり深く考えずに「そういうものだから」と浅い理解で進めてしまう。でも構成図に書き起こしていくと、「あれ、これってなんでこんな構成になってるんだ？」と考えるきっかけになる。
- インフラ構成図をたくさん書くことが、今後0からサービスを作るときの予行練習になる
- サービスを最初から構築する場合、見切り発車で進めるよりも、落ち着いてこういったインフラ構成図をまず手書きしてみることが大事
- 特にECSでコンテナサービスを構築するときとか……。あれは頭の中でぼんやり考えていてもなかなか実現できない……
他にはどんなメリットが？
- 新規参画者やPdMが喜ぶ
- 作った図を取っておけば、他の人にとって役立つドキュメントになりうる
- インフラにおける問題点がわかる
- サービスの可用性やセキュリティにおける課題を一目で見つけることができる
- 「あれ、このサブネットグループ、publicになっているけどこれでいいのか……？」
- インフラはサービス開発を進めていくうちに、自分たちでもわからないような形に変貌を遂げていることがよくあるので、それを見直す良い機会になる
- サービスの可用性やセキュリティにおける課題を一目で見つけることができる
作る上でのポイント
- できる限り簡略化しない。とくにサブネットグループの境界はきっちりと区別する。ネットワークの勉強にもなるし、セキュリティ的にも大事な要素だ。
- 図としてのキレイさよりも、「必要な情報がきちんと入っているかどうか？」を重視する
- EC2インスタンスの数やそれぞれの役割、DBとの関連など。マイクロサービスであれば、各サービスとDBは1:1で紐付いているはずだが、果たして……
- 社内用ドキュメントであれば、各リソースのNameを図の中に記載しておくと、それを読んだチームメンバーがコンソール画面上から簡単に見つけ出すことができるのでおすすめ
- draw.ioで作るのがおすすめ
- テンプレが豊富にあるので、作図の手間を減らすことができる
- 作ったらドヤ顔でチーム内に共有しよう。
まとめ
- みんな、クラウドサービスの構成図書こうぜ！ 勉強になるよ！ いつか絶対役に立つよ！
- チームの人も喜ぶよ！