chroju.dev/blog

the world as code

クラウド時代の「構成図」には何を描くべきなのか

勢いに任せた与太話です。

大事だけど AWS 構成図では省略してしまうことが多いサービスについて - サーバーワークスエンジニアブログ
コーヒーが好きな木谷映見です。 今回は小ネタです。AWS 構成図を書く際、省略してしまうことが多いサービスについて思いを馳せました。 よくある?構成図 リージョン アベイラビリティゾーン ルートテーブル AWS IAM インスタンスプロファイル Amazon EBS Elastic IP Elastic network interface(ENI) セキュリティグループ セッションマネージャーする時のエンドポイント 最終構成図 終わりに よくある?構成図 よくあると思われる構成図を描いてみました。 AWS になじみがある方から見ると、 「ふむ、パブリックサブネットとプライベートサブネットに 1…
大事だけど AWS 構成図では省略してしまうことが多いサービスについて - サーバーワークスエンジニアブログ favicon https://blog.serverworks.co.jp/aws-services-to-be-omitted
大事だけど AWS 構成図では省略してしまうことが多いサービスについて - サーバーワークスエンジニアブログ

この記事の言わんとするところはすごくよくわかる。AWSで構築したシステムの「構成図」は何度も描いてきたが、描いているうちに「どこまで描くべきかな」「ここは省略してもまぁいいか」などと独りごち、最終的にそれっぽいものが完成すれば、なんとなく背徳感を覚えつつも「これでいいか」としてしまったことは何度もある。

とはいえ構成要素を全部盛りにすればいいのかと言えば、そうも思わない。先の記事の最終形の構成図を見ると、それなりにAWSを知っている人でも一瞬ひるむんじゃないかと思う。この記事にしても、省略せず全部描け、という趣旨なわけではなくて、省略しちゃうものって実は結構ありますよね、というスタンスだ。

今後 AWS 構成図を見るとき「書いてないけど実は裏に色々なサービスがいるんだったよな」と思い出していただけますと幸いです。

要するところ、「構成図」とは何を描くものなのかの定義が現代においては曖昧になっている気がしている。

「現代においては」、と書いたが、僕の記憶を辿っていくと、昔はそんなことはなかったし、今でもオンプレであれば迷いなく「構成図」は描けると思う。僕にとって「構成図」という単語から連想されるのは物理構成図と論理構成図だ。この2つは定義がしっかりしており、確かIPAの試験でも出てきたはずだ。

一応書いておくと、物理構成図とは文字通り、システムを構成する物理的な機器の接続などを示した構成図だ。単にこのサーバとこのスイッチが繋がっているよ、という程度にとどまらず、24ポートスイッチのこのポートと、サーバの増設したほうのNIC(「NIC」って書いたの何年ぶりだろう)を繋いでますよ、というところまで図示したりする場合もある。そのために機器ベンダー各社がVisioなどで使える自社製品のイラストを配布していたりするぐらいだ。

論理構成図は論理的なネットワーク、主にはL3のIPネットワークに関して示す。物理的な結線だけを見ても、その上でどのようなIPネットワークが構成されているかはわからないので、ここでVLANが切られていて、サーバには3つNICがあるけどそれぞれ全部違うネットワークに脚が出てますよ、みたいなのを記す。

物理構成図はL1と2、論理構成図はL3を表すわけで、「何を描けばいいか」がハッキリしているし、その目的もわかりやすい。物理的な障害が起きていれば物理構成図を見ながら実際の結線を確認したりするし、機器の設定がおかしいようであれば、実機の状態と論理構成図を照らし合わせたりしていた。

オンプレの時代からクラウドの時代に移り、物理/論理という2種類の構成図は意味を成さなくなってしまった部分がある。論理構成図についてはまだ描きようがあるかもしれないが、真面目にAWSで論理構成図を描こうとすると、Lambda@EdgeはリージョナルエッジだけどCloudFront Functionsはエッジロケーションに描きわけるとか、ELBに紐つけたAWS WAFってVPC内にはないけどどこに描きましょうねとかいろいろ辛くなってくる。そもそも自分たちで構築したネットワークを把握する目的で論理構成図を描いていたわけで、AWS管理下で上手い具合にやっているところを構成図に落とし込みたいかというと、なんか目的感がズレている気にもなってくる。

ということで、クラウド時代にはクラウド時代としての「構成図」が要るんだとは思うが、物理/論理のように一般化されたクラウド向け構成図概念というものは僕の知る限りでは存在しない。各クラウドベンダーともアイコンは配布しているし、diagrams.netのようなサービスがあるぐらいで、みんな図を描いてはいるわけなのだが、物理/論理を描いていた頃に比べると何を描くのかがどうしてもふわふわしちゃうな、という落ち着かなさをずっと覚えている。

試しにググってみたが、AWS公式の AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? - 変化を求めるデベロッパーを応援するウェブマガジン | AWS においても「アーキテクチャ図ではみなさんが「何を伝えたいか」によって図の描き方や図の粒度などの表現を自由に変えて良いと私は考えています ! 」と書かれていた。まぁそうだよね、という気はする。冒頭の記事を見ていて、どの段階の構成図がしっくりくるかは人によっても違うと思う。しっかり全部描いたほうがいいと言う人もいるだろうが、僕としてはルートテーブルやインスタンスプロファイルがそこにあるだろう、というのは経験から推測できるので、別に構成図に欲しいとは思わない。でもインフラにそれほど詳しくない人は欲しいと思うかもしれない。

だから「ここまで描きますよ」という合意の下で、みんなそれぞれの「構成図」を描いていくしかないのだろう。そして冒頭の記事の通り、「省略しているものがありますよ」という了解もまたとても重要だと思う。しかしまぁやっぱり、どこか落ち着かない。