Large-scale Access Patternの設計

ゴール

次のような判断を組み合わせられるようにします。

読み取り集中
+
同じデータへ集中
        ↓
再利用による負荷削減を評価

読み取り集中
+
広いデータ範囲へ分散
        ↓
読み取り処理の水平分散を評価

書き込み集中
+
少数のキーへ集中
        ↓
パーティションキー設計
+
書き込みシャーディングを評価

短時間だけ急増
+
非同期処理可能
        ↓
既習のバッファリングを適用

大きな連続I/O
        ↓
スループットを重視

小さなランダムI/O
        ↓
IOPS / レイテンシーを重視

さらに、

十分なサービス能力がある

のに、

1つのキー
1つの接続
1つの処理先

へ負荷が集中していないかを確認します。

1. 平均値だけではアクセスパターンは分からない

例えば1時間平均が、

10,000リクエスト / 秒

でも、

通常
1,000リクエスト / 秒

毎時0分から5分
100,000リクエスト / 秒

かもしれません。

別のシステムでは、

常時
10,000リクエスト / 秒

かもしれません。

平均値だけなら近くても、

一時的なピーク

と、

恒常的な高負荷

では設計判断が異なります。

そのため、

平均
+
ピーク
+
ピーク継続時間
+
読み取り / 書き込み比率
+
アクセス先の偏り

を確認します。

2. 総量と分布を分けて考える

大規模システムでは、

全体の処理能力が不足している

場合だけが問題ではありません。

例えば全体では余裕があっても、

特定のパーティションキー

特定のデータ

特定のDBインスタンス

特定の接続先

だけへ負荷が集中すれば、その部分がボトルネックになります。

つまり、

総処理能力の不足

と、

負荷分散の失敗

を分けて考えます。

3. 読み取り集中型では「読み取りの形」を見る

読み取り集中型でも、

同じデータを繰り返し読む

場合と、

広いデータ範囲を
さまざまな条件で読む

場合では、適用するパターンが異なります。

前者は、

同じ結果を再利用できるか

が重要です。

後者は、

読み取り処理を
複数の処理先へ分散できるか

が重要です。

ここでは個々のキャッシュ方式やレプリカ機能を再度学ぶのではなく、

読み取り集中
↓
どこに集中しているか
↓
再利用か水平分散か

を判断します。

4. 同じ読み取り集中型でも偏り方が違う

例えば、

商品数
1,000万

総読み取り
50,000 / 秒

でも、

パターンA

上位100商品
→ 全読み取りの80%

なら、非常に強い偏りがあります。

パターンB

1,000万商品へ
比較的広く分散

なら、同じ総読み取り量でも負荷の形が違います。

したがって、

読み取り集中

だけではなく、

読み取り対象の分布

まで確認します。

5. 書き込み集中型でも総書き込み数だけでは足りない

例えば、

100,000書き込み / 秒

というワークロードでも、

多数のキーへ均等に書き込む

場合と、

1つのキーへ
90,000書き込み / 秒

では大きく異なります。

確認するのは、

書き込み量
+
書き込み先の分布

です。

分散データストアでは、

十分な総処理能力

があっても、

一部のアクセス先へ集中

していれば性能目標を満たせない場合があります。

6. DynamoDBではアクセスが実際に分散するキーを選ぶ

Amazon DynamoDBでは、

パーティションキーの値が多数ある

だけでは十分ではありません。

重要なのは、

実際の読み取り / 書き込み要求も
パーティションキー全体へ
十分に分散する

ことです。

例えば、

UserId

が多数存在し、それぞれへ比較的均等にアクセスするなら分散しやすくなります。

一方、

100万種類のキー

が存在していても、

1つのキー
→ 全トラフィックの90%

ならアクセス分布は偏っています。

7. ホットキーとホットパーティション

特定のパーティションキー値へ大量アクセスが集中すると、

ホットキー

となり、その結果、

一部の物理パーティションへ
負荷が集中

する可能性があります。

この場合、

テーブル全体には余裕がある

のに、

一部の要求だけ
スロットリングされる

ことがあります。

大規模設計では、

全体の使用率

だけでなく、

アクセス先ごとの偏り

を確認します。

8. 現在の日付などへ書き込みを集中させない

例えばイベントを、

パーティションキー
=
2026-09-15

だけで保存すると、その日の大量書き込みが同じ論理キーへ集中します。

翌日になれば、

2026-09-16

へ集中先が移るだけです。

問題は、

日付という値が使われていること

ではなく、

現在の1つの値へ
大量アクセスが集中すること

です。

9. 書き込みシャーディング

少数のキーへ大量書き込みが集中する場合は、

書き込みシャーディング

によってキー空間を広げる方法を評価できます。

例えば、

2026-09-15#0
2026-09-15#1
2026-09-15#2
...

のように分ければ、

1つの論理グループ
↓
複数のパーティションキー値

へ書き込みを分散できます。

目的は、

書き込み先の集中を減らす

ことです。

10. ランダムシャーディングのトレードオフ

書き込み時にランダムなサフィックスを付けると、

書き込み先
↓
広く分散

させやすくなります。

しかし、

2026-09-15の全データ

を取得したい場合、

2026-09-15#0
2026-09-15#1
2026-09-15#2
...

へ問い合わせて、結果を統合する必要があります。

つまり、

書き込み分散を改善
        ↑
        │
読み取り時の問い合わせ数や
結果統合処理が増える場合がある

というトレードオフがあります。

11. 計算可能なシャーディング

サフィックスをランダムに決める代わりに、

UserId
DeviceId
OrderId

などから計算できれば、

どのシャードへアクセスすべきか

を読み取り側でも特定しやすくなります。

例えば概念的には、

hash(UserId) % 10

のような方法です。

ただし、

シャード数を増やすほど必ず良い

わけではありません。

12. シャード数にはトレードオフがある

例えば10シャードで十分なワークロードを、

10,000シャード

へ分割すると、

問い合わせ先の増加

結果統合処理

アプリケーションの複雑化

につながる可能性があります。

したがって、

書き込みの分散
+
読み取りパターン

をセットで設計します。

13. バーストか恒常負荷かを分類する

次の2つは区別します。

通常 1,000 / 秒
↓
5分だけ 10,000 / 秒
↓
1,000 / 秒へ戻る

と、

10,000 / 秒が
長時間継続

です。

前者は、

短時間のバースト

として扱えます。

後者は、

基礎処理能力そのものが
新しい需要へ追いついているか

を確認する必要があります。

ここではバッファリング自体を再度説明するのではなく、

一時的ピーク
か
持続的需要
か

の分類を行います。

14. 同期要求と非同期要求を分ける

同じバーストでも、

処理完了を待たずに受け付け可能

なら、既習のバッファリングパターンを適用できます。

一方、

200 ms以内に
結果を返す必要がある

ような同期経路では、

後から処理

へ単純には置き換えられません。

したがって、

バースト量
+
継続時間
+
同期 / 非同期

をセットで確認します。

15. シーケンシャル / ランダムは性能指標を決めるために使う

ストレージアクセスでは、

大きな連続I/O

と、

小さなランダムI/O

で重視する性能指標が異なります。

既習のとおり、

大きなシーケンシャルI/O
→ スループット

小さなランダムI/O
→ IOPS / レイテンシー

が基本です。

ここではこれを、

大規模アクセスパターンの分類条件

として利用します。

16. 1つのワークロードに複数I/Oパターンが存在する

例えば分析システムが、

10 TBのログ本体
→ 大きな連続読み取り

と、

小さなインデックス情報
→ ランダム参照

の両方を持つことがあります。

この場合、

システム全体がシーケンシャル

または、

システム全体がランダム

と1種類に決めつけません。

処理経路ごとのアクセスパターン

に分解して考えます。

17. シーケンシャルI/Oと連番キーは別問題

シーケンシャルアクセス

は、

データを連続した順序で処理する

というI/O特性です。

一方、

Timestamp
1
2
3
4

のような、

順番に増えるキー

はデータ分散の問題です。

例えば現在時刻へアクセスが集中すれば、

ホットスポット

を形成する場合があります。

したがって、

シーケンシャルI/O

と、

順次増加するキー

を混同しません。

18. S3の大規模アクセスではクライアント側も並列化する

Amazon S3は大規模なリクエスト処理へスケールできます。

ただし、アプリケーションが、

1つの接続
+
逐次リクエスト

だけで処理していれば、クライアント側がボトルネックになる可能性があります。

高い集約スループットが必要なら、

複数接続
+
複数の同時リクエスト

へ処理を分散します。

19. 大きなS3オブジェクトはバイト範囲で並列取得できる

非常に大きなAmazon S3オブジェクトでは、HTTPのRangeを使用して一部分だけを取得できます。

例えば、

0〜99 MB

100〜199 MB

200〜299 MB

300〜399 MB

を複数接続から同時取得すれば、

1つの巨大なGET

だけに依存せず、読み取りを並列化できます。

大きなオブジェクト
↓
複数範囲へ分割
↓
並列GET
↓
集約スループット向上

という設計です。

20. S3の高リクエストレートでは再試行も設計する

Amazon S3は高いリクエストレートへ自動的にスケールします。

急激に高いリクエストレートへ変化した際には、内部スケーリング中に一時的な、

HTTP 503 Slow Down

が発生する場合があります。

そのため大規模アクセスでは、

並列化
+
再試行
+
503の監視

まで考えます。

21. 1つの特徴だけで設計を決めない

実際のワークロードは、

読み取り集中
+
バースト

や、

書き込み集中
+
ホットキー

のように、複数の特徴を同時に持ちます。

例えば、

通常時
→ 読み取り中心

キャンペーン開始時
→ 書き込みも急増

一部商品
→ 読み取りが極端に集中

なら、

読み取りの再利用

読み取り処理の水平分散

一時的書き込みピークの吸収

ホットキーの回避

を、それぞれ別の問題として評価します。

22. 「大きくする」と「分散する」を使い分ける

単純な処理能力不足なら、

より大きなリソース

が有効な場合があります。

しかし、

1つのホットキー

1つのレプリカ

1つの接続

1つの処理経路

へ負荷が集中している場合、リソースを大きくするだけでは根本原因が残ることがあります。

大規模設計では、

垂直スケール

だけでなく、

水平スケール

負荷分散

並列化

を評価します。

23. 大規模になるほど平均ではなく分布を見る

例えば、

平均CPU使用率
30%

でも、

一部の処理先
100%

その他
10%

なら均等ではありません。

同様に、

平均応答時間
50 ms

でも、

特定のキーだけ
2秒

なら利用者影響があります。

したがって、

平均

だけでなく、

負荷の分布

を設計判断へ含めます。

24. 代表的な判断表

25. SAP-C02での判断フロー

大規模ワークロード
        ↓

まず負荷の種類を分解

読み取り集中
書き込み集中
バースト
シーケンシャル
ランダム

        ↓

時間的な偏りはある？

一時的
または
持続的

        ↓

アクセス先の偏りはある？

特定キー
特定レプリカ
特定接続
特定経路

        ↓

処理を分散できる？

水平分散
シャーディング
並列接続
バッファリング

        ↓

処理経路ごとの性能指標を確認

読み取りスループット
書き込みスループット
IOPS
レイテンシー
キュー深度
など

        ↓

総処理能力だけでなく
負荷分布も性能目標を満たすか確認

まとめ

大規模アプリケーションでは、

トラフィックが多い

だけでは設計を決めません。

確認するのは、

読み取り中心か

書き込み中心か

一時的なバーストか

持続的な高負荷か

シーケンシャルアクセスか

ランダムアクセスか

アクセス先が均等か

一部だけがホットになっていないか

並列化できる処理を
1つの経路へ集中させていないか

です。

特に大規模では、

総処理能力

と、

負荷の分布

を別々に確認します。

DynamoDBでは、

実際のアクセスが
パーティションキー全体へ
十分に分散するか

を確認し、必要なら書き込みシャーディングを評価します。

Amazon S3では、

複数接続
+
並列リクエスト
+
大きなオブジェクトのバイト範囲取得

によってサービス側の大規模処理能力を活用します。

最終的には、

アクセスパターン
↓
時間的な偏り
↓
アクセス先の偏り
↓
ボトルネック
↓
分散 / 並列化方法
↓
アーキテクチャパターン

の順で判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド
• AWS Well-Architected Framework — Performance Efficiency Pillar
• Amazon DynamoDB — パーティションキー設計のベストプラクティス
• Amazon DynamoDB — 書き込みシャーディング
• Amazon EBS — I/O特性とモニタリング
• Amazon S3 — パフォーマンスのガイドライン
• Amazon S3 — パフォーマンスの設計パターン