インフラ構成図を追加するメリットと運用のつらさ

2023年4月24日 10:05

こんにちは、もうすぐゴールデンウィークがやってくるということで、1年の 1/3 が終了するという事実に驚きを隠せない遊撃サーバーチームの濱口です。

みなさんはインフラ構成図を書いたことありますか？おそらくインフラに関わる人であれば書いたことある人が多いのではと思いますが、それ以外の方だとあまり書く機会はないかもしれません。かく言う僕も今回初めて書きました。

なぜインフラ構成図を作成するのか

作業時に罠にハマる確率を下げる

構成図として可視化しておけば、複雑になっていたり特殊な構成になっている部分も一目で把握することができます。
また構成図があると、アプリケーション間で構成の違いなども比較しやすいです。例えば、DBなどのアップグレード作業時に、サービスAでは作業Aだけでいけたけど、サービスBでは事前に作業Bをしてから作業Aをする必要がありそう、などの議論がしやすくなり、必要な作業の漏れを防げます。

誰も何も分からない状態の発生を防ぐ

なんか動いているけど構成図はないし資料もほとんど残ってない、唯一詳しかった人は退職した、という状況になるとなかなか辛いですよね。

また新人が入ってきたり、別のチームから人が移動してきた時にも、サーバーはどこで動いているのか、CI/CDは何がどのタイミングで動くのか、ログはどこに送られているのか、などなど何がどこでどうやって動いているのかをキャッチアップしやすくなり、全体感を把握しやすいというメリットもあります。

課題がすぐ分かる

構成図として可視化されていれば、複雑になっていたり特殊な構成になっている部分を一目で把握できると上述しました。それらの多くは課題になっている部分でもあります。

どうやってるのか

自分は VSCode に拡張機能を入れて Draw.io(今は Diagrams.net と言うのかも) で書いています。

以下の Draw.io Integration という拡張機能を入れることで、VSCode 上でいい感じに Draw.io を利用できるようになります。

書いた構成図は GitHub にプルリクエストを上げるようにしています。そうすることで、構成図を追加・変更する際にいつ、どういった目的での追加・変更なのかが分かりやすくなります。

運用面の課題が多い

とりあえず追加するところまではできたのですが、それを継続するにはいくつか課題がありそうでした。

レイアウトとかコンポーネントの追加方法が人それぞれ

レイアウトやコンポーネントの書き方は人によってバラバラになりがちで、よくいえば個性あふれる、悪くいえば統一感のない構成図になってしまいます。アプリケーション間で構成図を比較する時には、見づらくなってしまうのでそれなりに統一した書き方にしておけるとより良さそうです。
これに関しては diagrams という Python で構成図をいい感じに書けるツールを見つけました。

試しに少し書いてみました。

from diagrams import Diagram, Cluster
from diagrams.aws.compute import ECS, Fargate, ElasticContainerServiceService, ElasticContainerServiceContainer
from diagrams.aws.database import Aurora
from diagrams.aws.network import CF, ALB, InternetGateway, VPC, PrivateSubnet, PublicSubnet, NATGateway
from diagrams.onprem.client import Client

with Diagram(name='サンプル', filename='sample', outformat='svg', direction='TB'):
  client = Client()

  with Cluster('AWS'):
    cf = CF()
    internet_gateway = InternetGateway()
    with Cluster('Region us-east-1'):
      with Cluster('Availability zone c'):
        with Cluster('Public Subnet'):
          alb = ALB()
          nat_gateway = NATGateway()
        with Cluster('Private Subnet'):
          aurora = Aurora("databases")
          # ecs = ECS()
          containers = [
            ElasticContainerServiceContainer('puma'),
            ElasticContainerServiceContainer('sidekiq')
          ]

    client >> cf >> internet_gateway >> alb >> containers >> aurora
    aurora >> containers >> nat_gateway >> internet_gateway >> cf

細かく設定を書けるので、文字や矢印、各コンポーネントのサイズなどを良い感じに統一できそう
学習コスト高そう(cluster とか node の扱い慣れるまでは辛そう)

というように感じました。今回お試しで雑にやったので、矢印の色を変えたり、クラスターのサイズや色、コンポーネントの位置を修正するとかがちゃんとできてません。最初の敷居はちょっと高いけど、ある程度整備できて慣れてくるとなかなか良いのかもしれないなと思いました。ドキュメントやサンプルも結構充実している印象でした。

追加・更新作業が大変

エディタからぽちぽちしても、diagrams を使ってコード化するにしても、ある程度の更新作業が必要になり結構大変なので、欲を言うと自動化できると良いかもしれません。
もし IaC 化が進んでいれば、例えば terraform だと terraform_graph コマンドで構成図を作成できそうですが

そもそも IaC 化できていないといけない
terraform_graph だけだとすごく質素な構成図になるので、プラグイン(inframapとか)を組み合わせて利用する必要がある

などの考慮が必要です。とはいえコマンド1つで作成できるのはとても便利なので IaC 化できている部分だけでも導入するのはありかもしれないなと思いました。

放置される・忘れ去られる

これは原因様々ですが、人手が足りていなかったり、単純に気が付かず忘れていたりするという場合もあるかもしれません。追加して終わりではなく、上記のようにできるだけ自動化を進めたり、定期的に確認する場を設けるなどできると良いかもしれません。

まとめ

インフラ構成図を作成することで、誰も何も分からない状態や作業時に罠にハマる確率を下げる
更新作業が大変だったり、忘れ去られたりするので、運用は工夫する必要がある
誰でも追加しやすいようにコード化したり自動化する仕組み作りまでできると良さそう

構成図はあると色々便利なことは確かなので、引き続き運用面の課題を工夫して改善していけたらと思います。

インフラや開発基盤などの課題解消をお手伝いしていただけるエンジニアを募集しています！それ以外でも様々な職種でお手伝いしていただける方を募集しているので、気になった方は以下を覗いてみてください。

カジュアル面談用の応募フォームもあるのでお気軽にお問い合わせください！

この記事が気に入ったらサポートをしてみませんか？