Anatomy

数字の裏まで、
透かして見る。

Anatomy は、ダッシュボードの数字 1 つから、それを支えるサーバーとサービスのつながりを透かして見せる、インフラの可視化ツールです。

下の画面をなぞってください。各パネルの真下に、その数字をつくっている構成が写っています。キーボードでは画面を選んで矢印キーで動かせます。下のボタンで、表の画面と裏の構成図を切り替えられます。

注文サービス本番

直近 1 時間 ・ 06:40 更新

注文数

1,284件 / 時

前の 1 時間より 8% 多い

決済の成功率

99.2%

失敗 10 件 / 1,294 件

応答時間 p95

412ms

目標 300 ms を超えています

最近の注文

注文時刻金額(円)状態
#4821306:393,480発送待ち
#4821206:3812,900発送待ち
#4821106:38760決済待ち
#4821006:375,210発送待ち
#4820906:352,040完了

在庫の同期

3分前

倉庫 2 拠点 ・ 5 分ごと

注文数 の裏

orders-api ×3注文を受け付ける APICPU 41%← lb-01 から→ payment-svc へ
pg-orders-01注文のデータベース(主)読み取り待ち 290 ms
pg-orders-02複製(読み取り用)ほぼ空き

決済の成功率 の裏

payment-svc決済の取り次ぎ← orders-api から
決済代行外部のサービス応答切れ 10 件

応答時間 p95 の裏

edge配信網の入口12 ms
lb-01振り分け6 ms→ orders-api へ

p95 412 ms のうち
290 ms は pg-orders-01

最近の注文 の裏

order-events注文のできごとを流す列滞留 0
mail-worker確認メール
ledger-worker売上の記帳

在庫の同期 の裏

inventory-sync5 分ごとに実行
倉庫 東正常
倉庫 西再試行 3 回
  • edge から lb-01、lb-01 から orders-api へつながる。この経路が遅い。
  • orders-api は pg-orders-01 と payment-svc へつながる。pg-orders-01 の読み取り待ちが 290 ms。
  • pg-orders-01 は複製の pg-orders-02 へつながる。
  • payment-svc は外部の決済代行へつながる。
  • order-events は mail-worker と ledger-worker へつながる。
  • inventory-sync は倉庫 東と倉庫 西へつながる。倉庫 西は再試行中。

読影所見

上の画面から読み取れたこと。数字が悪いとき、どこを見ればいいかが先に分かります。

表の数字裏でたどった経路所見
応答時間 p95 412 msedge → lb-01 → orders-api → pg-orders-01遅さの約 7 割は pg-orders-01 の読み取り待ち。読み取りをレプリカ(pg-orders-02)へ逃がせば、目標の 300 ms に収まる見込み。
決済の成功率 99.2%orders-api → payment-svc → 外部の決済代行失敗 10 件はすべて外部の決済代行の応答切れ。こちらのサービスの不具合ではない。
在庫の同期 3 分前inventory-sync → 倉庫 API(東・西)倉庫 西 の API だけ再試行が続いている。同期は間に合っているが、西の担当へ知らせておく。

写し方

読むもの
トレース(OpenTelemetry 形式)、クラウドの設定、コンテナの配置。サーバーに常駐させるプログラムは要りません
更新の間隔
1 分ごと。構成が変わると、次の 1 分で図も変わります
重ね合わせ
今お使いのダッシュボードのパネルに、裏の構成を結びつけます。作り直しは要りません
残す期間
構成の履歴を 90 日。「先週の火曜の構成」と見比べられます

自分の画面を、透かしてみる。

チーム 月 38,000 円(サービス 20 個まで)。最初の 14 日間は無料です。

14 日間ためす
LP Lab