構成を書く

箱と線だけで書く

構成図の箱は部品、線は要求やデータを渡す向きです。席の予約サービスなら、入口、アプリ、保存先を箱にして、どこからどこへ渡すかを線で表します。

半年後の担当者が、予約の要求をどこへ送るか辿れれば役目を果たします。箱の名前には、監視やほかのシートと同じ名前を使います。

台数を図に書くと、増やすたびに図も更新する必要があります。数字は規模シートに置き、図にはそのシートへの参照を添えます。

DAU 3万、1人6回なら、1日18万件を86400秒で割り、平均は約2 QPSです。ピーク係数50で100 QPS、1台40件毎秒なら3台という前提を、別のシートで管理します。

予算の月5万円も制約シートに置きます。図を読む人が前提を確認できるように、シートの名前を揃えておけば、数字を図に重ねる必要はありません。

名前と繋がりを確かめる

図を読んだら、どの線にも繋がっていない箱と、箱に無い名前へ向かう線を探します。孤立した箱は、不要な部品か、線を書き忘れた部品です。

箱に無い名前へ線が伸びていたら、箱の書き忘れか名前の揺れを疑います。箱の一覧に名前があるかを、線の両端について確かめます。

app と application が同じものだと知っているのは、書いた人だけです。障害対応の最中に読む人へ、名前を推測する仕事を残さないようにします。

予約サービスで解いてみる

箱を lb、app、database、queue、worker とし、線を次の表で示します。lb は入口で要求を振り分け、worker は通知を送る部品です。

この図では、db という箱が無く、database が孤立しています。保存先を2つ足すのではなく、同じ部品の名前を取り違えたのか確かめます。

保存先が1つなら、線の先を database に直します。これで全ての箱が線に繋がり、線の両端が箱の一覧に存在する図になります。

ただし、名前と線が揃っても予約が正しく完了する証拠にはなりません。構成図で繋がりを確認したら、次の回で予約1件が通る順番を読みます。