この記事について

みなさんAWS構成図書いていますか？

私が所属している部署はAWSのインフラ構築をメイン業務としています。そのためAWS構成図を作成する機会が多いです。
また、自分以外が作成する構成図をレビュー/確認する機会も多いです。

私はAWS構成図を作成するとき、１つのシステムに対する論理な構成と物理な構成を分けて構成図を作った方がが良いと考えています。(AWSに限った話ではありませんが)

ただ実際の現場では、物理構成のみを構成図としているケースがほとんどです。論理構成がないのです。

この記事では、「そもそも論理構成/物理構成とは何か？」と「なぜ論理構成と物理構成を分けた方がいいのか？」という私の持論をケーススタディを交えながら語っていきます。

あくまで持論ですので、参考程度にしていただけると幸いです。

AWS構成図

まずAWS構成図についておさらいしましょう。

AWS上にサービスを構築する際には、AWS構成図を作成することが多いかと思います。(弊社では構成図と読んでいますが、世間的にはアーキテクチャ図と呼ぶ方が多いようです)

AWS構成図はシステム構成をAWSリソース中心に描写したものです。

AWS構成図の例：

https://aws.amazon.com/jp/builders-flash/202204/way-to-draw-architecture/?awsf.filter-name=*all

AWS構成図を見ることで、そのシステムの構成を短時間で理解することができます。AWSを利用したシステムを作る際には、構成図が必要不可欠です。

物理構成と論理構成

論理構成と物理構成という考え方はオンプレミスにおけるネットワーク構成を表す手法として用いられることが多いです。

オンプレミスのネットワーク構成においては

• 論理構成図：システム管理者がシステム構成を把握するための構成図
• 物理構成図：インフラ管理者がハードウェア構成を把握して、インフラ構築の参考にするための構成図

と使い分けをするのが一般的です。

参考：https://itpfdoc.hitachi.co.jp/manuals/3020/30203K0420/CMSY0020.HTM

そして、この考え方はAWS構成図にも当てはめることができます。

AWS構成図においては

• 論理構成：システムの構成を直感的にイメージするための構成図
• 物理構成：システムの構成を論理的に理解するための構成図

と考えると分かりやすいです。

論理構成と物理構成についてもう少し深掘りしてみましょう。

論理構成

論理構成で伝えるべきことはシステム構成の直感的なイメージ像です。

具体的に言うと

• アーキテクチャ
• 構成要素(コンポーネント)
• コンポーネントの役割
• コンポーネント間のつながり

論理構成図を見ることで、システムのアーキテクチャや利用されているコンポーネント、そのコンポーネント間のつながり方を即座に理解できます。

物理構成

物理構成で伝えるべきことはインフラ構成の詳細な構成イメージです

具体的に言うと

• コンポーネント間の正確な接続
• コンポーネントが属している正確な場所
• コンポーネントの正確な数

物理構成図はインフラ管理者が構築などを行う際に参考にされます。
そのためコンポーネントがどこに位置しているかなどを正確に伝える必要があります。対象のAWSリソースがどのVPCのどのサブネットに属しているかなどの詳細な情報が物理構成図として描写されます。

 

 

論理構成と物理構成は分けた方がいい

このように、構成図は論理構成と物理構成では描写する内容が全く異なります。
そのため、構成図は論理構成図と物理構成図を分けて作成した方が良いと思います。

しかし、その理屈が全てのシステムにおいて当てはまる訳ではありません。
規模が小さかったり、コンポーネントが少ないシステムでは物理構成図と論理構成図は同じようなものになりやすいです。その場合は分ける必要はありません。まず物理構成図を作成して、そこでシステムの構成を直感的に伝えることが難しそうだと感じた場合に、論理構成図を作れば良いと思います。

ケーススタディ

では、論理構成と物理構成を分けた方が良いということについて、ケーススタディを用いて説明します。

以下の物理構成図をご覧ください。

どうでしょう？
これだけをパッと見ると

• アプリケーションのフロントにCloudFrontがある
• CloudFrontはAPI Gateway + Lambdaをバックエンドとしている
• DBはDynamoDBとRDS くらいならすぐにわかるかと思います。

でもシステムがどういったアーキテクチャなのか、各AWSリソースの立ち位置はなんなのか、はじっくり見ないと理解できません。

そこで、以下の論理構成図をご覧ください。

この論理構成図を見たら、このシステムのアーキテクチャはマイクロサービスアーキテクチャに則っているということがすぐにわかります。また、3つのサービス(XXサービス/YYサービス/ZZサービス)があり、XXサービスのバックエンドDBがRDS、YYサービスとZZサービスのバックエンドDBがDynamoDBというコンポーネント間のざっくりとした接続もすぐに理解できます。

もし物理構成図を見る前に、論理構成図を見ていたらどうでしょうか？
まずアーキテクチャやコンポーネント間のざっくりとしたつながりを理解した状態で、詳細な構成を見ることができるので格段に理解しやすいのではないでしょうか？

今回のケーススタディはまだシンプルなシステムを取り扱っていますが、より複雑なシステムであれば、論理構成と物理構成を分けることの効果が大きくなると思います。