18-4 遅い・落ちたを見つける手順

この節を一言で

グラフで気づき、失敗の種類で当たりをつけ、日誌で 1 件まで絞るのが手順です。

図版を準備中グラフの山を指し、日誌を開いて原因を探す店長

グラフで気づき、日誌で絞り込み、原因までたどり着きます。

道具は前の 3 節で揃いました。残るのは、どれをどの順で見るかです。

「なんとなく遅い」「たまに落ちる」は、順番を決めずに探すといちばん時間がかかります。いま読んでいるこのサイト（Cloudflare Lab）でも、この順番を先に決めておきます。

ここでは、遅いの見つけ方、落ちたの見つけ方、日誌での絞り込み、手順のまとめの順に見ます。

Learning goals

この節でできるようになること

• 遅さをどのグラフで見るかを言える
• 失敗の種類と番号の対応を言える
• 日誌で 1 件まで絞る方法を言える
• 困ったときに見る順番を自分で言える

1. 遅いを見つける

「遅い」と言われても、全員が遅いのか、10 人に 1 人だけが遅いのかで話が変わります。平均だけ見ると、後ろの数人が待たされていることに気づけません。

Cloudflare の時間のグラフは、この違いが分かる形になっています。Wall time per execution は呼び出しの始まりから終わりまでの経過時間で、公式は、外への問い合わせを待っている時間や waitUntil() の中の処理も含むと説明しています。CPU Time per execution は、実際に計算していた時間だけです。

どちらも P50・P90・P99・P999 の区切りで出ます。P50 が低いのに P999 だけ高ければ、「ほとんどの人は速いが、一部だけ待たされている」状態です。Memory usage が右肩上がりのときは、公式はメモリの漏れを疑うよう案内しています。

図版を準備中待ち時間の分布で、後ろの数人だけ極端に長い様子

平均だけでは、後ろの数人だけが待たされていることに気づけません。

待ち時間の分布で、後ろの数人だけが極端に長くなっています。平均では見えない形です。

つまり、遅さは平均ではなく、高いほうの区切りで見つけます。

2. 落ちたを見つける

「落ちた」にも種類があります。こちらの取り違えか、手一杯になったのか、本部側の不調かで、直す相手が変わります。

公式は、Requests の Errors に入るのは Script Threw Exception・Exceeded Resources・Internal Error のいずれかを返した来客だと説明しています。内訳は Invocation statuses の表で分かれていて、Worker threw exception は番号 1101、Exceeded resources は 1102 と 1027 に対応します。

Internal Error は Workers の側の不調で、公式は、Worker のコードや上限とは関係がなく、課金の対象にもならないと説明しています。この種類が続くときは公式の稼働状況のページを見ます。なお公式は、こうした状態は HTTP の番号（status codes）とは別物だと断っています。

Workers & Pages›対象の Worker›Metrics の Summary›Errors

図版を準備中失敗の札を「取り違え」「手一杯」「本部側」に仕分ける様子

失敗は種類ごとに分かれていて、直す相手が変わります。

失敗の札が種類ごとに分かれています。番号を見れば、どこを直すかが決まります。

つまり、失敗は種類で分け、番号で当たりをつけます。

3. 日誌から 1 件へ

グラフで「昨日の 15 時に失敗が増えた」と分かっても、原因はまだ分かりません。次は日誌を開き、その時間の失敗した行だけを取り出します。

第 18-1 節の日誌には invocation logs が並び、ページの取得ならメソッドと URL が見出しになります。どの住所で失敗したかは、ここで分かります。自分で書いた覚え書きを JSON の形にしてあれば、項目を指定して絞り込めます。

その場でもう一度起こせるなら、公式は例外をさらに調べる手段として wrangler tail を挙げています。第 18-2 節の方法です。

図版を準備中日誌の頁から失敗の 1 件だけを抜き出す虫めがね

日誌を項目で絞ると、失敗した 1 件だけを取り出せます。

日誌の頁から、失敗した 1 件だけを抜き出します。ここまで来れば、直す場所が決まります。

つまり、グラフは「いつ」を、日誌は「どれ」を教えます。

4. 順番を決めておく

困ってから順番を考えると、あちこち開いて時間を使います。先に決めておけば、迷いません。

Cloudflare Lab では次の順にします。まずグラフで気づき、次に日誌でその時間の行を絞り、必要なら npx wrangler tail で今の様子を聞き、直して deploy し、最後に同じグラフが戻ったかを確かめます。

図版を準備中グラフ・日誌・実況・貼り替えを順に回す 4 つの矢印

気づく・絞る・その場で聞く・直すの順に回すと迷いません。

4 つの矢印が輪になっています。最後の「戻ったか」を省くと、直った気になるだけで終わります。

つまり、順番を決めておくことが、いちばん効く準備です。

Cloudflare Lab での使われ方

ここで紹介した手順が、いま読んでいる Cloudflare Lab でどう使われるかを見ます。

Cloudflare Lab はこの章の実装で、週に一度グラフを見る日を決め、失敗が出た週だけ日誌へ降りる運用にする予定です。第 16 章の毎日の出典確認が落ちた場合も、まず Errors の線を見てから日誌を開きます。実測（最初に見つけた失敗の種類と、その原因）は、この章の実装後に追記します。

つまずきやすいところ

つまずきポイント

失敗の種類と HTTP の番号は別物です

公式は、Invocation statuses は HTTP の status codes とは異なると説明しています。Worker としては成功していても、外の理由で 500 番台が返る場合があります。

つまずきポイント

Internal Error は自分では直せません

公式は、この種類は Workers の側の不調で、コードや上限が原因ではないと説明しています。増えているときは公式の稼働状況を確かめます。

この節のまとめ

• 遅さは平均ではなく、P99・P999 の区切りで見つけます。
• 失敗は Invocation statuses の種類と番号で分け、直す相手を決めます。
• グラフで「いつ」、日誌で「どれ」、必要なら wrangler tail で今を見ます。

この節で出てきた言葉を、つながりの順に並べると次のようになります。

flowchart TD
  A["遅い・落ちた"] --> B["グラフで気づく<br/>Wall time / CPU Time"]
  A --> C["失敗の種類<br/>Invocation statuses"]
  C --> D["番号で当たり<br/>1101 / 1102"]
  B --> E["日誌で 1 件へ<br/>invocation logs"]
  E --> F["今の様子<br/>wrangler tail"]

図のラベル: 遅い・落ちた / グラフで気づく Wall time / CPU Time / 失敗の種類 Invocation statuses / 番号で当たり 1101 / 1102 / 日誌で 1 件へ invocation logs / 今の様子 wrangler tail

次の章では、ここまで手で作ってきた設定を、Terraform のコードで宣言し直します。

この節のチェック

問 1時間のグラフが示す区切りはどれですか？

P50・P90・P99・P999最大と最小だけ平均だけ合計だけ

問 2Wall time per execution に含まれるものはどれですか？

外への問い合わせを待つ時間と waitUntil() の中の処理計算していた時間だけ利用者が読んでいた時間画像を保存していた容量

問 3Worker が拾われなかった例外を投げたときの番号はどれですか？

11011102404503

問 4Internal Error の説明として正しいものはどれですか？

Workers の側の不調で、Worker のコードや上限が原因ではない書いたコードの誤りが原因上限を超えたことが原因利用者の通信が切れたことが原因

問 5例外をさらに調べるとき、公式が挙げている手段はどれですか？

wrangler tailwrangler deploywrangler loginwrangler types

採点する