Scalability
共通点のない2つのワークロード
読み取りは公開スキャンに連動します。急増し、キャッシュ可能で、予測できません。書き込みはサプライチェーンのイベントに連動します。安定し、機械が駆動し、追記のみです。両者を一つのシステムとして見積もることが、パスポート基盤が倒れる原因です。
- 読み取り
- 急増型・キャッシュ可能
- 書き込み
- 安定した追記のみ
- 規模を拡大
- 独立して
Definition
デジタル製品パスポートのプラットフォームの規模は何によって決まりますか。
2つの独立したワークロードです。読み取り量は公開スキャンに連動し、これはバースト的で予測しにくい一方、公開階層はすべての呼び出し元に同一であるため大部分をキャッシュできます。書き込み量はサプライチェーンのイベントに連動し、こちらは定常的で機械が生成します。両者は別々に見積もり、別々にスケールさせます。
The consequence for planning is that catalogue size is a poor predictor of either. Event volume tracks how much your products move; read volume tracks how much attention they receive.
負荷の形
1つのシステムで両方をまかなえない理由
| Characteristic | Passport reads | Event writes |
|---|---|---|
| Triggered by | A person scanning a product | A machine recording a step |
| Shape | Bursty and unpredictable | Steady and forecastable |
| Cacheable | The public tier, almost entirely | Not at all — every write is new |
| Latency need | A person is waiting | A queue can absorb it |
| Grows with | Attention and campaign activity | Physical movement of goods |
| Failure impact | A consumer sees nothing | History develops a gap |
設計
この切り分けから導かれること
キャッシュされた公開階層
すべての匿名の呼び出しが受け取る応答は同一であるため、キャッシュから配信されます。
リクエストごとの制限付き階層
クレデンシャルに依存する応答はその場で解決します。コストの高い経路であり、最も頻度の低い経路です。
独立した拡張
スキャンの急増が取り込みを遅らせてはならず、一括インポートがリゾルバを遅くしてもなりません。
追記専用のイベントログ
イベントは変更ではなく追加されるため、書き込みが更新と競合することはありません。
一括取り込み
過去イベントの取り込みは専用の経路で実行し、稼働中の書き込み経路は通りません。
オブジェクトで照会
履歴は識別子で取得します。監査やリコールが実際に用いるアクセスパターンです。
回答
よくある質問
パスポートプラットフォームの負荷を実際に決めるもの
まったく別の2つのものです。読み取りは公開スキャンに連動し、これは公開されていてバースト的で予測できません。放送で取り上げられた製品は、前年1年分を上回る読み取りを1時間で発生させることがあります。書き込みはサプライチェーンのイベントに連動し、こちらは機械が生成し安定しています。一方の見積もりは他方について何も教えてくれません。
なぜ読み取りと書き込みは別のシステムなのですか。
スキャンの急増がイベントの取り込みを遅らせてはならず、イベントの一括インポートが、消費者を待たせているリゾルバを遅くしてもならないからです。リゾルバはほぼ静的でキャッシュ可能な応答を返し、イベントストアは書き込みの多いログをオブジェクト識別子で照会します。これらは別種の問題です。
イベント量は製品数に比例して増えますか。
増えるのは動きに比例してであり、カタログの規模にではありません。流通網を通過するパレット1枚は、倉庫に置かれた千点の商品より多くのイベントを生みます。SKU数で見積もる組織は、たいてい上下どちらにも驚くことになります。
パスポートの読み取りはどうやって速さを保ちますか。
公開階層はキャッシュ可能です。すべての呼び出し元に同じ応答を返し、変更も稀だからです。制限付き階層は提示されたクレデンシャルによって答えが変わるため、リクエストごとに解決されます。つまり高コストな経路ほど利用頻度が低く、これが正しい向きです。
可用性についてどのような約束をしますか。
これらはマーケティングページではなくサービス契約に属する事項であり、調達の過程で書面化します。当社はここに稼働率の数値を意図的に掲載していません。契約もステータスページも伴わない数値は約束ではなく、当社を評価するエンジニアはそれを雑音として扱うからです。
Next step
想定される取扱量をお持ちください
カタログ規模、動きの頻度、そして最も懸念されているキャンペーンのピーク。見出しの数字ではなく、これらに合わせて見積もります。