1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

My Infrastructure JourneyAdvent Calendar 2024

Day 11

構成図を書くときに考えていること

Last updated at Posted at 2024-12-10

はじめに

新しいプロダクトをいじるとなった時、まずどのような構成になっているか把握したいとなりますよね。でも構成図を書こう!となった時いったいどこから書けばいいのかわからないとなって断念する…そんなことありませんか?自分はあります。
100%これで書けるようになるという方法はまだ見つかりません、見つかったら共有するし教えて欲しいですが、自分が書くときに気をつけたり考えていることをアウトプットしていこうと思います。

抽象度を決める

まずどれくらいの粒度で書くかを決めます。
例えば他プロダクトとのつながりさえ把握できればいいのなら、DBがどこにあるのかとかキャッシュの有無等を考える必要はないでしょう。
通信のデバッグをしたいのであればsecurity group等書いた方が良いでしょう。
こういったように目的別にどこまで書くかをざっくりと自分は決めています。

主要コンポーネントを把握する

まずどのリソースがあるかを把握します。
抽象度に則り、例えばロードバランサ、インスタンス、DB等どのようなリソースを使うかを洗い出します。
何かしらのツールを使っているのであれば、自分は必要そうなアイコンをこの辺りでフィールドに雑に出し始めます。

動作の流れを把握する

どう並べていくかを考えるときに、自分は動作の流れをたどってリソースを並べていきます。
例えばwebアプリケーションだったら、まずインターネットから名前解決を行なってルーティングされてALBに入って…といった形でその順にリソースを並べて矢印で繋いでいきます。

体裁を整える

繋がりをかけたら、構成図としての体裁を整えていきます。
自分はAWSのAWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?をよく参考にします。
読み手が誰かと、最初に決めた抽象度に応じて書くことを決めていきます。
サイトの例を引用すると、「マルチ AZ を利用して可用性が高い構成にしていることを伝えたい」という場合には、EC2を利用する場合に基本的に利用されるEBSやセキュリティグループを描かないといったように、目的に応じた最後の取捨選択を行います。
個人的に一つ守った方が良いと思うのは、アーキテクチャの"流れ"は上から下 or 左から右に則って作ると見やすくなる印象があります。
img_way-to-draw-architecture_06.8099fdbec65872413000309add2e2614bf0fa050.png

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?