要約

  • HealthOmicsが処理中の資源利用を見えるようにし、CloudWatchへの取り込みには料金がかかる。
  • 観測されなかったことと、活動がゼロと測定されたことは区別する必要がある。

資源グラフの空白は、落ち着いた状態に見えるかもしれない。しかし、最も情報が乏しい部分でもあり得る。科学計算の処理に対応すべきかを短時間で判断するチームにとって、両者は同じではない。

AWSは9月11日、HealthOmicsの14指標を発表した。CloudWatchの取り込み料金が適用される。商業的な意義は、資源に関する判断を改善できるかにある。新しい指標の数だけでは、その判断に間に合うかは分からない。

観測には異なる時間枠がある

実行指標のガイドは、次の違いを示している。

対象 文書で示された時間枠
30秒未満のタスク 指標がない場合がある
動的な実行用ストレージの使用量 30分超の遅延があり得る
共有一時領域の使用量 20分ごとの測定

これは、一つの更新頻度を別々に説明したものではない。系列を同じ画面に並べる際にも、違いを残す必要がある。そうしなければ、異なる時点の観測を同じ稼働状態だと思って比較してしまう。

稼働中のタスクに役立つ警告を考えてみたい。有用な時間枠とは、誰かが意味のある判断をまだ下せる間であって、グラフが最終的に埋まるまでの時間ではない。後から得た情報は次の実行に役立ち得るが、それは別の用途であり、約束すべき価値も違う。

空白は資源削減の根拠にならない

観測が欠けているだけでは、タスクが資源を使わなかったとも、十分な余裕があったとも言えない。まず情報の限界を確認する理由であり、直ちに割り当てを減らす理由ではない。これは解釈の原則で、本稿がHealthOmicsの障害を発見したという意味ではない。

タスクのライフサイクルには別の状態情報があり、サービスエラー後に再試行されるタスクには新しい識別子が付く。この情報を資源系列と併せて残せばよい。一度目の空白を、何も変わらなかったかのように次の試行の測定値へつなぐべきではない。

購入側は、長い工程の途中で介入すること、完了後に調べること、次の比較可能な実行に向けて資源を決めることを分けて評価したい。見栄えのよいグラフだけでは原因を証明できず、処理を自動修復したり、科学的な結果の正しさを保証したりもしない。

本稿では顧客の失敗回避、節約額、検知時間を測定していない。観測の選択肢は増えた。その価値は、見える範囲と見えない範囲を理解する対応手順に依存する。