MENU
  1. ホーム
  2. テクノロジー
  3. QPSとは？徹底解説！システム性能からビジネス価値まで【国内外の事例で学ぶ】

QPSとは？徹底解説！システム性能からビジネス価値まで【国内外の事例で学ぶ】

テクノロジー
2025年11月3日
目次

序論：QPS(Queries Per Second)

デジタルがビジネスの根幹をなす現代において、「速度」は単なる利便性を超え、企業の競争力を決定づける生命線です。その「速度」を測る指標として頻繁に登場するのが「QPS」です。

本レポートは、技術指標である「Queries Per Second」をその本質的な定義から、それがもたらすビジネスへの絶大な影響、実現するためのアーキテクチャ設計、そして未来の展望までを、国内外の豊富な事例を交えながら徹底的に解説します。さらに、読者の知的好奇心に余すところなく応えるため、他の2つのQPSについてもコラムとして後述し、包括的な理解を提供します。このレポートを通じて、QPSという指標が技術とビジネスを繋ぐ架け橋となり、いかにして企業の持続的な成長を支える羅針盤となり得るのかを明らかにしていきます。

あわせて読みたい
パフォーマンステストとは？目的・種類・評価項目・やり方を徹底解説 【】 ウェブサイトやアプリケーションの「サクサク感」はなぜ重要か？ 現代のデジタル社会において、ウェブサイトやアプリケーションの動作が「サクサクしている」こと…

第1章：QPS (Queries Per Second) の基礎――システムの心拍数を理解する

QPSとは何か？

QPSは「Queries Per Second」の略語であり、日本語では「秒間クエリ数」と訳されます。これは、データベース管理システム（DBMS）や全文検索システム、APIサーバーといった情報システムが、1秒あたりにどれだけの数の問い合わせ（クエリ）を処理できるかを示す性能指標です 1。

クエリとは、システムに対する具体的な要求や命令のことを指します。例えば、データベースに対して特定のデータを要求する「検索」、新しいデータを追加する「登録」、既存のデータを更新する「更新」などがこれにあたります。QPSは、こうした要求をシステムがどれだけ素早く、かつ大量に処理できるかという「処理能力」や「スループット」を定量的に表すための指標です。その性質から、システムの”心拍数”に例えられることもあります。この数値が高ければ高いほど、システムの処理能力が高いことを意味します。

QPSの計算方法

QPSの算出方法は極めてシンプルです。特定の時間内に処理された総クエリ数を、その測定時間（秒）で割ることで求められます 3。

計算式は以下の通りです。

$$\text{QPS} = \frac{\text{総クエリ数}}{\text{測定時間（秒）}}$$

例えば、あるウェブアプリケーションのデータベースが5分間（300秒）に90,000件の検索クエリを処理したとします。この場合のQPSは以下のように計算されます。

$$\text{QPS} = \frac{90,000 \text{件}}{300 \text{秒}} = 300$$

この結果は、当該システムが1秒あたり平均して300件のクエリを処理する能力を持つことを示しています。

なぜQPSが重要なのか？

この単純な数値が、現代のデジタルビジネスにおいて極めて重要な戦略的価値を持ちます。その理由は、QPSがシステムの負荷耐性を定量的に示し、最終的にユーザーエクスペリエンス（UX）に直結するためです 3。

高いQPSを維持できるシステムは、多くのユーザーが同時にアクセスする高負荷な状況下でも、応答の遅延やサービスの停止といった事態に陥るリスクが低くなります。ECサイトのセール時や、SNSで情報が拡散された際の突発的なアクセス集中（いわゆる「バズ」）にも耐えうる堅牢なサービスを提供するためには、高いQPSが不可欠です。

逆に、システムのQPSが低い場合、アクセスが少し増加しただけでレスポンスが著しく悪化し、ユーザーはページの表示を待たされたり、操作が完了しなかったりといったストレスを感じることになります。このような劣悪な体験は、ユーザーの離脱を招き、ビジネス上の機会損失に直結します。したがって、QPSは単なる技術的な数値ではなく、ビジネスの成否を左右する根幹的な要素として認識されなければなりません。

第2章：技術的深掘り――QPS、TPS、RPSの違いと関係性

QPSを正確に理解し、システムパフォーマンスを多角的に評価するためには、しばしば混同されがちな類似の指標であるTPS (Transactions Per Second) と RPS (Requests Per Second) との違いを明確に把握することが不可欠です。これらの指標は、それぞれ異なるレイヤーで異なる対象を計測しており、その関係性を理解することがシステム全体のボトルネックを特定する鍵となります。

RPS (Requests Per Second)

RPSは「秒間リクエスト数」を意味し、サーバーが1秒あたりに受信するHTTPリクエストの総数を計測します。これは、Webサーバー、ロードバランサー、CDN（Content Delivery Network）など、システムの最も外側、いわば「玄関口」で観測される指標です 13。

RPSが計測する「リクエスト」には、ユーザーのブラウザが要求するあらゆるものが含まれます。例えば、HTMLファイル、CSSファイル、JavaScriptファイル、画像ファイルといった静的なリソースへのリクエストから、アプリケーションの特定の機能を呼び出す動的なAPIコールまで、その種類を問いません 13。したがって、RPSはシステム全体にかかるトラフィックの総量を把握するための最も広範な指標と言えます。

QPS (Queries Per Second)

前述の通り、QPSは「秒間クエリ数」を意味し、主にデータベースや検索エンジンが1秒あたりに実行するクエリ（データの読み取り・書き込み命令）の数を計測します。これは、システムのデータ層、つまり情報を保管・管理する「書庫」のパフォーマンスを示す指標です 13。

RPSがシステムへの入り口の混雑度を示すのに対し、QPSは内部のデータ処理エンジンがどれだけ効率的に働いているかを示します。多くのWebアプリケーションにおいて、データベースは最も負荷が集中しやすく、パフォーマンスのボトルネックとなりがちな部分です。そのため、エンジニアはQPSを注意深く監視し、データベースが過負荷状態に陥らないようにシステムを設計・運用します 13。

TPS (Transactions Per Second)

TPSは「秒間トランザクション数」を意味し、システムが1秒あたりに完了させる「ビジネストランザクション」の数を計測します。ここで言うトランザクションとは、単一のリクエストやクエリではなく、ユーザー視点での一連のまとまった処理やビジネスフロー全体を指します 14。

例えば、ECサイトにおける「商品の購入」は典型的なトランザクションです。この一連のフローには、在庫の確認、注文情報の記録、決済処理、通知の送信といった複数のステップが含まれます。これらのステップがすべて正常に完了して初めて「1トランザクション」としてカウントされます 17。したがって、TPSはアプリケーション層で計測され、システムがビジネス上の成果をどれだけの速度で生み出しているかを示す、よりビジネス価値に近い指標と言えます。

指標間の階層的な関係性：具体例から学ぶ

これら3つの指標の関係は階層的であり、1つのビジネストランザクション（TPS）が複数のリクエスト（RPS）を発生させ、それらのリクエストがさらに複数のクエリ（QPS）を引き起こすという構造になっています。この関係性を、ECサイトでの商品購入シナリオを通じて具体的に見ていきましょう 17。

シナリオ：ユーザーがECサイトで商品を1つ購入する

この「商品購入」という一連のビジネスフローが完了すると、システムは**「1 TPS」**を記録します 17。しかし、この1回の購入の裏側では、ユーザーの操作に応じてシステム内部で以下のような複数の処理が連鎖的に実行されています。

  1. 商品詳細ページの表示: ユーザーが商品をクリックすると、ブラウザはサーバーにページ表示を要求します (1 RPS)。サーバーはアプリケーションロジックを実行し、データベースから商品名や価格、説明文などの情報を取得します (1 QPS)。
  2. カートへの追加: ユーザーが「カートに入れる」ボタンをクリックすると、新たなリクエストが送信されます (1 RPS)。サーバーはまずデータベースに在庫状況を確認し (1 QPS)、在庫があればカート情報を更新（書き込み）します (1 QPS)。
  3. 購入手続き画面への遷移: ユーザーが「購入手続きへ」ボタンをクリックすると、画面遷移のためのリクエストが発生します (1 RPS)。サーバーはユーザーの配送先住所などの情報をデータベースから取得します (1 QPS)。
  4. 注文の確定: ユーザーが「注文を確定する」ボタンをクリックすると、最終的なリクエストが送信されます (1 RPS)。サーバーは注文情報をデータベースに書き込み (1 QPS)、外部の決済代行サービスへ決済リクエストを送信し (1 RPS)、データベースの在庫数を減らす更新処理を行います (1 QPS)。

このシナリオをまとめると、ユーザー視点での**1回の購入（1 TPS）を達成するために、システムは合計で5回のリクエスト（5 RPS）と6回のデータベースクエリ（6 QPS）**を処理していることがわかります。

このように、TPSはビジネスの成果を、RPSとQPSはその成果を達成するためにシステムの下位レイヤーで発生する具体的な処理量をそれぞれ表しています。この階層構造と各指標の比率を分析することは、システムの健全性を診断する上で極めて有効です。例えば、「TPSあたりのQPS」が高い場合、それは1つのビジネス成果を達成するために過剰なデータベースアクセスが発生していることを示唆しており、非効率なクエリ（N+1問題など）が存在する可能性を浮き彫りにします。このような分析を通じて、漠然と「サイトが遅い」という問題に対し、「データベースのクエリ効率を改善する」という具体的な打ち手を導き出すことが可能になるのです。

以下の表は、これら3つの指標の特性をまとめたものです。

指標正式名称主な計測対象計測レイヤービジネス上の意味
RPSRequests Per SecondHTTPリクエスト（静的/動的問わず）Webサーバー、ロードバランサー、CDNサイトへのトラフィック総量
QPSQueries Per Secondデータベースへの問い合わせ（Read/Write）データベース、検索エンジンデータ処理層の負荷と効率
TPSTransactions Per Second一連のビジネス処理（購入、登録など）アプリケーション層ビジネス成果の達成速度

第3章：QPSがビジネスに与える戦略的インパクト

QPSは単なる技術的な性能値にとどまらず、ビジネスの根幹をなす様々な要素に直接的かつ重大な影響を及ぼします。高いQPSを維持する能力は、優れた顧客体験の提供から収益の最大化、さらにはブランド価値の構築に至るまで、企業の競争力を多方面から支える戦略的な資産となります。

ユーザーエクスペリエンス（UX）への直接的な影響

QPSとユーザーエクスペリエンス（UX）の関係は、極めて直接的です。高いQPSは、システムの高速な応答性を保証します。ユーザーがウェブサイトやアプリケーション上で何らかのアクション（ページのクリック、情報の検索、フォームの送信など）を起こした際に、システムが即座に反応し、次の画面や結果を素早く表示できることは、優れたUXの最も基本的な要件です 3。

ユーザーは、待たされることなくスムーズに目的を達成できる体験を「快適」と感じます。この快適さが、サービスに対する満足度やエンゲージメントを向上させるのです 19。逆に、システムのQPSが低く、処理能力に余裕がない場合、ユーザーのアクションに対するシステムの応答は遅延します。ページの読み込みに数秒待たされたり、ボタンをクリックしても反応がなかったりといった体験は、ユーザーに多大なストレスを与え、サービスを利用する意欲を削ぎます。最悪の場合、ユーザーは目的を達成する前にサイトを離脱してしまい、二度と戻ってこない可能性すらあります。

コンバージョン率（CVR）と収益への貢献

UXの低下は、ビジネスの生命線であるコンバージョン率（CVR）の悪化と、それに伴う収益の損失に直結します。コンバージョンとは、ウェブサイト上での最終的な成果、例えば商品の購入、会員登録、資料請求などを指します。

数多くの調査研究が、ウェブサイトの表示速度とCVRの間に強い相関関係があることを示しています。例えば、ページの表示が1秒遅れるだけでCVRが数パーセント低下し、直帰率（1ページだけ見てサイトを離脱するユーザーの割合）が大幅に上昇するというデータは広く知られています。ユーザーは、遅いサイトで辛抱強く待ってはくれません。より高速で快適な競合サイトへと簡単に移動してしまいます。

したがって、高いQPSを維持し、常に高速なレスポンスを提供し続けることは、ユーザーをコンバージョンへと導き、機会損失を防ぐための必須条件です 20。特に、大規模なセールやキャンペーンでアクセスが集中する際に高いQPSを維持できるかどうかは、その成否を直接的に左右します。

サーバーコストとインフラ投資の最適化

QPSは、サーバーやクラウドインフラにかかるコストにも直接的な影響を与えます。ビジネスの成長に伴い、システムが処理すべきQPSは増加していきます。この増加する負荷に対応するためには、インフラへの投資が必要となります。

ここで重要になるのが「効率性」です。同じQPSを処理するにも、アーキテクチャの効率性によって必要なサーバーリソースの量は大きく異なります。例えば、1000 QPSを処理するために10台のサーバーが必要な非効率なシステムと、同じ1000 QPSを2台のサーバーで処理できる効率的なシステムとでは、運用コストに5倍の差が生まれます 21。

QPSを継続的に監視し、ボトルネックを特定して最適化を図ることは、無駄なサーバーリソースを削減し、インフラコストを最適化することに繋がります 22。これは、近年注目されているFinOps（Cloud Financial Operations）の観点からも極めて重要な活動です。効率的なシステムは、少ない投資でより高いパフォーマンスを実現し、企業の収益性を高めます。

ブランドの信頼構築と競争優位性

最後に、安定して高いパフォーマンス（高いQPS）を提供し続けることは、ユーザーからの信頼を獲得し、強力なブランドイメージを構築する上で不可欠です。「あのサービスは、いつでもサクサク快適に使える」という一貫したポジティブな体験は、ユーザーのロイヤリティを高め、リピート利用を促進します 22。

特に、金融取引や重要なコミュニケーションツールなど、信頼性が重視されるサービスにおいては、パフォーマンスの安定性はサービスの品質そのものと見なされます。システムダウンや頻繁な遅延は、ユーザーの信頼を著しく損ない、ブランド価値を毀損します。

競争の激しいデジタル市場において、優れたパフォーマンスはもはや「あれば良い」ものではなく、「なくてはならない」ものです。他社との明確な差別化要因となり、ユーザーが自社のサービスを選び続ける理由となります。このように、QPSを中心としたパフォーマンスへの継続的な投資は、短期的な収益向上だけでなく、長期的なブランド価値と持続的な競争優位性を築くための基盤となるのです 3。

第4章：高QPSを実現するアーキテクチャ設計と技術要素

数万、数百万といった極めて高いQPSを要求される現代のウェブサービスにおいて、単一のサーバーでその負荷を処理することは物理的に不可能です。高QPSを実現するアーキテクチャの基本思想は、古代ローマの戦略にも通じる「分割統治（Divide and Conquer）」、すなわち、巨大な負荷を複数のコンポーネントに賢く分散させ、各個撃破していくことにあります。ここでは、その思想を実現するための4つの主要な技術要素について詳述します。

1. 水平スケーリングと負荷分散（ロードバランシング）

高QPSへの最も基本的なアプローチは、サーバーの台数を増やすことでシステム全体の処理能力を向上させる「水平スケーリング（スケールアウト）」です。しかし、単にサーバーを増やしただけでは、特定の一台にアクセスが集中してしまい、効果がありません。

そこで不可欠となるのが、外部からのリクエストを複数のサーバーに効率的に振り分ける「ロードバランサー」の存在です 23。ロードバランサーは、システムの入り口に立つ交通整理役として機能し、各サーバーの負荷が均等になるようにリクエストを分散させます。これにより、システム全体として高い処理能力を発揮し、一台のサーバーに障害が発生しても他のサーバーでサービスを継続できる可用性の向上にも寄与します。

ロードバランサーがリクエストを振り分ける際には、様々なアルゴリズムが用いられます。

  • 静的分散 (Static Load Balancing): サーバーの現在の状態を考慮せず、あらかじめ定められたルールに従ってリクエストを割り振るシンプルな方式です。代表的なアルゴリズムに、リクエストをサーバーに順番に割り振る「ラウンドロビン」があります 26。構成が単純である一方、サーバーの処理能力に差がある場合や、特定の処理に時間がかかる場合に負荷が偏る可能性があります。
  • 動的分散 (Dynamic Load Balancing): 各サーバーの現在の負荷状況（CPU使用率、接続数など）をリアルタイムに監視し、最も余裕のあるサーバーに動的にリクエストを割り振る、より高度な方式です。代表的なアルゴリズムとして、現在アクティブな接続数が最も少ないサーバーを選択する「リーストコネクション」が挙げられます 27。これにより、より効率的で均一な負荷分散が可能となります。

2. 積極的なキャッシュ活用

高QPSアーキテクチャにおいて、最も劇的な効果をもたらす技術の一つが「キャッシュ」です。キャッシュとは、一度処理した結果や頻繁にアクセスされるデータを、データベースのような低速なストレージではなく、高速なメモリ上に一時的に保存しておく技術です 29。

ユーザーからリクエストが来た際、まずキャッシュにデータが存在するかを確認します。データが存在すれば（キャッシュヒット）、低速なデータベースにアクセスすることなく、即座にそのデータをユーザーに返すことができます。これにより、応答速度が飛躍的に向上すると同時に、システムのボトルネックになりがちなデータベースへのアクセス数を大幅に削減できます。データベースのQPS負荷が軽減されることで、システム全体としてより多くのリクエストを処理できるようになります。

キャッシュは、その保存場所によっていくつかの種類に分類されます。

  • ブラウザキャッシュ: ユーザーのPCやスマートフォンのブラウザ内にデータを保存します。ロゴ画像やCSSファイルなど、サイト全体で共通して使われる静的ファイルが対象となります 31。
  • サーバーキャッシュ/CDN: サーバー側、あるいは世界中に分散配置された専用のキャッシュネットワーク（CDN）にデータを保存します 31。特にCDNは、ユーザーに地理的に最も近いサーバーからコンテンツを配信することで、物理的な距離による遅延を最小限に抑える効果もあります。

3. データベースの最適化

多くのシステムにおいて、最終的にデータを永続化し、複雑な検索を行うデータベースは、パフォーマンスの核心部であり、最もボトルネックになりやすいコンポーネントです。したがって、データベース自体の処理効率を極限まで高めることが、高QPS達成のためには不可欠です。

  • インデックスの活用: インデックスは、巨大なテーブルから特定のデータを高速に見つけ出すための、本の「索引」のような仕組みです。検索条件として頻繁に使用されるカラム（列）に対してインデックスを作成しておくことで、データベースはテーブル全体をスキャン（全件検索）することなく、目的のデータが格納されている物理的な位置に直接アクセスできます。適切に設計されたインデックスは、検索クエリのパフォーマンスを数桁単位で向上させることが可能です 33。
  • クエリチューニング: 同じ結果を得るためのSQLクエリでも、その書き方によって実行効率は天と地ほど異なります。非効率なクエリは、必要以上にデータベースのリソース（CPUやI/O）を消費し、システム全体のQPSを低下させる主要な原因となります。データベースが提供する実行計画分析ツール（例：EXPLAIN）を用いてクエリの動作を分析し、より効率的な書き方に修正（チューニング）する作業は、データベースパフォーマンスを維持する上で継続的に必要となります 34。

4. オートスケーリング

オートスケーリングは、システムの負荷状況に応じて、サーバーの台数を自動的に増減させるクラウド時代に不可欠な仕組みです 38。

事前に「CPU使用率が80%を超えた状態が5分続いたらサーバーを1台追加する」「CPU使用率が20%を下回った状態が10分続いたらサーバーを1台削減する」といったルールを設定しておきます。これにより、テレビで紹介された際のアクセス急増や、深夜の閑散期など、トラフィックの増減に人手を介さず自動で追従することが可能になります。

オートスケーリングは、パフォーマンスとコストの両面で大きなメリットをもたらします。トラフィックのピーク時にはサーバーをスケールアウトさせてサービスを安定稼働させ、可用性を確保します。一方で、トラフィックが少ない時間帯には余分なサーバーを自動的に停止（スケールイン）することで、無駄なインフラコストを徹底的に削減します。この弾力的で効率的なリソース管理能力は、高QPSを経済的に実現するための鍵となります 39。

これら4つの技術要素は、独立して機能するのではなく、相互に連携し合うことで、堅牢かつスケーラブルな高QPSアーキテクチャを形成します。例えば、効果的なキャッシュ戦略はデータベースへの負荷を軽減し、データベース最適化の重要性を相対的に低下させます。また、オートスケーリングは負荷分散と連携し、常に最適なサーバー台数でリクエストを処理します。このように、多層的な防御と最適化を組み合わせることが、現代の巨大なトラフィックを支えるアーキテクチャの核心なのです。

第5章：QPSに基づくキャパシティプランニングとコスト最適化

高QPSを安定的に処理できるシステムを構築・運用するためには、将来の負荷を正確に予測し、それに基づいて適切なリソースを計画する「キャパシティプランニング」が不可欠です。このプロセスは、システムの安定稼働を保証するだけでなく、過剰なインフラ投資を避け、コストを最適化する上でも極めて重要です。

ビジネス指標からのQPS推定

キャパシティプランニングの第一歩は、技術的な指標であるQPSを、ビジネスの成長予測と結びつけることです。ビジネスサイドが持つ「来期のユーザー数は1.5倍になる見込みだ」といった予測を、エンジニアリングサイドが理解できる「必要なQPSはどのくらいか」という問いに変換する必要があります。この変換プロセスは、両者の間の共通言語となり、データに基づいたインフラ投資の意思決定を可能にします 43。

そのための一般的な手法が、DAU（Daily Active Users）などのビジネス指標からQPSを概算する方法です 44。

計算例：DAUから平均QPSを算出する

以下に、具体的なステップを示します。

  1. DAU (Daily Active Users) の設定:
    まず、対象となるサービスの1日あたりのアクティブユーザー数を設定します。ここでは、DAU = 100万人と仮定します。
  2. 1ユーザーあたりのアクション数の想定:
    次に、1人のアクティブユーザーが1日に平均して何回のアクション（ページの閲覧、検索、投稿、いいねなど、サーバーへのリクエストを発生させる操作）を行うかを想定します。この数値はサービスの特性によって大きく異なりますが、ここでは1ユーザーあたり平均20アクション/日と仮定します。
  3. 1日の総リクエスト数の計算:
    DAUと1ユーザーあたりのアクション数を掛け合わせることで、1日の総リクエスト数を算出します。
    $$1,000,000 \text{人} \times 20 \text{回/人} = 20,000,000 \text{リクエスト/日}$$
  4. 秒間リクエスト数 (平均QPS) への変換:
    最後に、1日の総リクエスト数を1日の総秒数（$24 \text{時間} \times 60 \text{分} \times 60 \text{秒} = 86,400 \text{秒}$）で割ることで、システムが平均的に処理すべきQPSを求めます。
    $$\text{平均QPS} = \frac{20,000,000 \text{リクエスト}}{86,400 \text{秒}} \approx 231.5 \text{ QPS}$$
    安全マージンを考慮して、約232 QPSと見積もることができます。

ピークトラフィックへの備え

上記の計算で得られたのは、あくまで「平均」QPSです。しかし、実際のウェブサービスのトラフィックは一日中均一であることは稀で、特定の時間帯に集中する「ピーク」が存在します。例えば、ニュースサイトであれば朝の通勤時間帯、ECサイトであれば夜22時以降やセール開始直後などがピークタイムにあたります。

システムは、この最も負荷が高いピーク時のQPSを処理できなければ、サービスダウンに繋がってしまいます。したがって、キャパシティプランニングにおいては、平均QPSだけでなく、ピークQPSを考慮することが不可欠です。

ピークQPSの推定には、過去のアクセスログを分析するのが最も正確ですが、新規サービスの場合は経験則（例えば、パレートの法則を応用し、「1日のトラフィックの80%が特定の4時間（1日の1/6）に集中する」と仮定するなど）を用いて算出します。この仮定に基づくと、ピーク時間帯のQPSは平均の約5倍 ($80\% \div (1/6) \approx 4.8$) になると見積もることができます。先の例で言えば、$232 \text{ QPS} \times 5 = 1160 \text{ QPS}$ がピーク時に必要なキャパシティの目安となります。

コスト最適化戦略

必要なQPSを見積もった上で、次はそのキャパシティをいかに経済的に実現するかというコスト最適化のフェーズに移ります。

  • ライトサイジング (Right-Sizing): 予測されたピークQPSに基づき、サーバーのスペック（CPU, メモリ）や台数を過不足なく適切に選択することです。過剰なスペックは無駄なコストを生み、過小なスペックはパフォーマンスの低下を招きます。
  • オートスケーリングの活用: 前章で述べた通り、オートスケーリングはコスト最適化の強力な武器です 38。ピーク時にはサーバーを自動で増やして負荷に対応し、閑散期には自動で減らしてコストを削減することで、需要の波に合わせた柔軟で無駄のないリソース運用を実現します。
  • アーキテクチャ効率の追求: 高いQPSを、より少ない計算リソースで達成できる効率的なアーキテクチャやミドルウェアを選択することも重要です。例えば、ある分析ワークロードにおいて、Apache DruidはGoogle BigQueryと比較して12倍の価格性能比を実現したというベンチマーク結果もあります 21。技術選定の段階で、パフォーマンスだけでなくコスト効率も評価軸に加えるべきです。
  • 新技術の導入: 近年では、AI/MLを用いてトラフィックをより正確に予測し、オートスケーリングをプロアクティブ（予測的）に実行するシステムも実用化されつつあります 3。これにより、突発的な負荷変動にもより迅速に対応しつつ、さらなるコスト削減が期待されています。

第6章：【国内外事例研究】巨大トラフィックを支える技術戦略

理論的なアーキテクチャ設計を理解した上で、次に世界をリードするテクノロジー企業が実際にどのようにして数百万、数千万というQPSを処理しているのか、その具体的な技術戦略を見ていきましょう。これらの事例は、高QPSを実現するための原則が、実際のビジネス課題とどのように結びついているかを示してくれます。

事例1: Netflix – 800万QPSを支えるAPIアーキテクチャの進化

課題:

世界最大の動画ストリーミングサービスであるNetflixは、テレビ、スマートフォン、ゲーム機など数百種類に及ぶ多様なデバイスに対して、パーソナライズされたコンテンツを配信する必要があります。そのトラフィックは膨大で、1日に20億を超えるリクエストを処理する必要がありました 46。初期のアーキテクチャでは、全てのデバイスに対して画一的なREST APIを提供していましたが、これには大きな問題がありました。デバイスごとに必要なデータが異なるにもかかわらず、汎用的なAPIは常に同じ構造のデータを返すため、不要なデータ通信（Chattiness、おしゃべり）が大量に発生していました。これはパフォーマンスを低下させるだけでなく、各デバイスチームが新機能を開発する際にAPIチームがボトルネックとなり、開発速度を著しく阻害していました 47。

解決策:

Netflixは、各サービスが独立して開発・運用されるマイクロサービスアーキテクチャの利点を維持しつつ、APIの非効率性を解消するため、API集約層に「GraphQL Federation」を導入するという先進的なアプローチを選択しました 49。

GraphQL Federationは、複数の独立したGraphQLサービス（スキーマ）を、あたかも一つの巨大なグラフAPIであるかのように見せる技術です。これにより、Netflixは以下の2つを両立させることに成功しました。

  1. バックエンドの柔軟性: 各マイクロサービスチームは、自分たちのドメインに対応するGraphQLサービス（DGS: Domain Graph Service）を独立して開発・運用できます。
  2. フロントエンドの効率性: UI開発者は、単一のエンドポイントに対してクエリを投げるだけで、複数のマイクロサービスから必要なデータだけを一度の通信でまとめて取得できます。

このアーキテクチャの中核をなすGraphQL Gatewayは、UIからのクエリを受け取ると、それを複数のDGSへのサブクエリに分解する「クエリプラン」を生成します。そして、依存関係のないサブクエリを並列実行することで、複数のマイクロサービスからのデータ取得を高速化しています。このプランニングと実行に伴うオーバーヘッドは、最悪の場合でも約10ms程度に抑えられています 49。

さらに、データ層では、NoSQLデータベースであるApache Cassandraを大規模に活用しています。Netflixはデータベースへの直接アクセスを抽象化する独自のレイヤーを構築し、そのレイヤーを通じてピーク時には800万QPSという驚異的なトラフィックを処理しています 50。

事例2: Amazon DynamoDB – 高可用性とスケーラビリティの設計思想

設計思想:

Amazon DynamoDBは、Amazon自身の巨大なEコマースプラットフォームを支えるために開発された、フルマネージドのNoSQLデータベースサービスです。その設計思想の根源は、2007年に発表された伝説的な論文「Dynamo: Amazon’s Highly Available Key-value Store」に遡ります 51。

Dynamoの設計における最大の目標は、「Always-on（常時稼働）」、つまりいかなる障害が発生してもサービスが停止しないという極めて高い可用性（Availability）を実現することでした。そして、この目標を達成するために、Dynamoは意図的に強い一貫性（Consistency）を犠牲にするという、当時としては画期的なトレードオフを選択しました。これは、分散システムにおいて可用性、一貫性、分断耐性の3つを同時に満たすことはできないという「CAP定理」に基づいた、極めて戦略的な設計判断でした。

主要技術:

DynamoDBがほぼ無限のスケーラビリティと高い可用性を実現している背景には、Dynamo論文で示された以下のような独創的な技術があります。

  • Consistent Hashing: データをリング状の仮想空間にマッピングし、各サーバーノードにそのリング上の一部を分担させるデータ分割・複製方式です。この方式の最大の利点は、サーバーの増減に極めて柔軟に対応できる点です。新しいサーバーを追加した場合でも、リング全体を再配置するのではなく、隣接するノードとの間で一部のデータを移動させるだけで済むため、シームレスなスケールアウトが可能となります 51。
  • パーティショニング (Partitioning): データを「パーティション」と呼ばれる物理的なストレージ単位に分割し、水平スケーリングを実現します。QPSやデータ量が増加し、一つのパーティションの限界に近づくと、DynamoDBはバックグラウンドで自動的にパーティションを分割・追加し、負荷を分散させます。ユーザーは、この複雑なパーティション管理を意識する必要がありません 52。
  • キャパシティモード (Capacity Modes): ワークロードの特性に応じて、スループット（QPS）を事前に確保し、コストを予測しやすくする「プロビジョニングモード」と、リクエストが発生した分だけ料金を支払う、予測不能なトラフィックに適した「オンデマンドモード」の2つを選択できます。これにより、ユーザーはパフォーマンスとコストの最適なバランスを取ることが可能です 54。

事例3: メルカリ – 国内最大級フリマアプリのパフォーマンス改善

アプローチ:

国内最大級のフリマアプリであるメルカリの事例は、巨大なトラフィックを支えるための地道かつ包括的な最適化の重要性を示しています。特に、CtoCモールである「メルカリShops」のパフォーマンス改善事例では、単一の技術に頼るのではなく、ユーザーのリクエストが通過する経路全体（データベースからCDNまで）を俯瞰し、各所でボトルネックを特定・改善するという、ホリスティックなアプローチが取られています 56。

具体的な施策:

メルカリShopsチームは、ユーザー体験に直結する表示速度を改善するため、以下のような多岐にわたる施策を実施しました。

  • バックエンド/インフラ層: アプリケーションサーバーとして利用しているCloud Runの「最小インスタンス数」を引き上げました。これにより、リクエストがない状態が続いた後にインスタンスがゼロになる「コールドスタート」の発生頻度を減らし、レスポンスの初期遅延を改善しました 56。
  • CDN層: 商品ページのようにアクセス数が少なく、キャッシュにヒットしにくい「ロングテール」なコンテンツに対しても、CDNのキャッシュ保持期間を意図的に延長しました。これにより、キャッシュヒット率が向上し、オリジンサーバーへの負荷を軽減することに成功しました 56。
  • マイクロサービス層: メルカリのアーキテクチャはマイクロサービスで構成されており、GraphQLを通じて複数のサービスが連携して一つの画面を生成しています。チームは、画面表示のボトルネックとなっていた関連マイクロサービス（機械学習を用いた推薦商品の取得処理や、ユーザーIDの変換処理など）を個別に特定し、それぞれの処理を高速化しました 56。

これらの事例から導き出されるのは、高QPSを実現するための「唯一の正解」は存在しないということです。Netflixは開発組織のスケーラビリティを重視してGraphQL Federationを、Amazonは極限の可用性を求めて一貫性をトレードオフする独自のデータベースを、そしてメルカリは既存のアーキテクチャの中で全体最適を追求しました。成功する企業は、自社のビジネス要件と技術的制約を深く理解し、それに応じた最適なアーキテクチャを主体的に選択・構築しているのです。

第7章：QPSの未来展望――次世代技術との融合

QPSの管理と最適化は、システムのパフォーマンスを維持・向上させるための継続的な挑戦です。そして今、5G、エッジコンピューティング、AI/ML、さらには量子コンピューティングといった次世代技術の波が、この挑戦に新たな可能性をもたらそうとしています。これらの技術との融合により、QPSの管理はより動的で、予測的で、そして効率的なものへと進化していくでしょう。

エッジコンピューティングと5Gによる超低遅延QPS

従来の中央集権的なクラウドコンピューティングモデルでは、ユーザーのデバイスからデータセンターまでの物理的な距離が、通信遅延（レイテンシー）の越えられない壁となっていました。しかし、「エッジコンピューティング」は、計算リソースやデータをユーザーの近く（ネットワークのエッジ）に配置することで、この問題を解決します。

2024年には市場への投資額が60億ドルを超えると予測されるこの分野は、5G通信の普及と相まって、QPS処理のあり方を根本的に変える可能性を秘めています 3。5Gが持つ「超低遅延」「広帯域」「多数同時接続」という特性とエッジコンピューティングを組み合わせることで、データセンターまでデータを往復させることなく、エッジ側でリアルタイムにリクエストを処理できます。

これにより、自動運転、遠隔医療、リアルタイムAR/VRといった、ミリ秒単位の応答性が要求されるアプリケーションにおいて、従来では不可能だった超低遅延のQPS処理が実現します。負荷はエッジとクラウドの間で動的に分散され、ユーザーに最も近い場所で最適なパフォーマンスが提供されるようになるでしょう 3。

AI/MLが駆動する予測的QPS最適化

AI（人工知能）およびML（機械学習）の活用は、QPS管理を「事後対応型」から「予測・予防型」へと進化させます。

現在主流のオートスケーリングは、CPU使用率などのメトリクスが閾値を超えたことを検知してからサーバーを増やすという、リアクティブ（事後対応的）なアプローチです。これに対し、「予測的QPS調整システム」は、過去の膨大なトラフィックパターンや、イベントカレンダー（セールの開始、祝日など）といった外部情報をAI/MLモデルに学習させ、未来の負荷を高い精度で予測します 3。

この予測に基づき、アクセスが急増する「前」にプロアクティブ（予防的）にサーバーをスケールアウトさせることが可能になります。これにより、突発的なトラフィック増によるパフォーマンス低下を未然に防ぎつつ、より精緻なリソース管理によるコスト削減を実現できます。スタンフォード大学のAI Indexレポートによると、AIの推論コストは2022年から2024年にかけて280倍も削減されており、このような高度な予測システムの導入コストは急速に低下しています 3。

量子コンピューティングによる負荷分散の最適化

さらに未来を見据えれば、量子コンピューティングがQPS管理に革命をもたらす可能性も視野に入ってきます。特に、「量子アニーリング」と呼ばれるタイプの量子コンピュータは、無数の選択肢の中から最適な組み合わせを見つけ出す「組み合わせ最適化問題」を、従来のコンピュータとは比較にならない速度で解くことに長けています。

数千、数万台のサーバーから構成される超大規模システムにおいて、「どのリクエストをどのサーバーに割り振れば、システム全体のスループットが最大化され、遅延が最小化されるか」という負荷分散の問題は、まさにこの組み合わせ最適化問題そのものです。現在、この問題に対して量子アニーリングを用いた負荷分散最適化アルゴリズムの研究が進められており、従来手法と比較して計算時間を大幅に短縮する成果が報告されています 3。

まだ研究開発段階ではあるものの、将来的には、量子コンピューティングがシステム全体のQPSをリアルタイムで完全に最適化し、リソース効率を極限まで高める未来が訪れるかもしれません。

結論：QPSは単なる技術指標から、ビジネス成長の羅針盤へ

本レポートを通じて、QPS (Queries Per Second) という指標が持つ多層的な意味とその戦略的重要性を明らかにしてきました。QPSは、単にサーバーの処理能力を測るための技術的なメトリクスではありません。それは、ユーザーエクスペリエンスの質を決定し、企業の収益性を左右し、インフラコストの効率を規定し、そして最終的には市場における競争優位性そのものを築く、極めて戦略的なビジネス指標です。

技術的な側面では、QPSをRPSやTPSといった関連指標との文脈で理解することの重要性を探りました。これらの指標間の関係性は、システムの健全性を診断するための強力なレンズとなります。1つのビジネストランザクション（TPS）に対して、どれだけのリクエスト（RPS）とクエリ（QPS）が発生しているかを分析することで、パフォーマンスのボトルネックがシステムのどのレイヤーに潜んでいるのかを特定し、的確な改善策を講じることが可能になります。

また、高QPSを実現するためのアーキテクチャ原理として、負荷分散、キャッシュ、データベース最適化、オートスケーリングという4つの柱を詳述しました。これらの技術は独立したものではなく、相互に連携し、補完し合うことで、堅牢でスケーラブルなシステムを形成します。この原理を理解することは、技術チームとビジネスチームが共通の言語で対話し、データに基づいた合理的な意思決定を行うための不可欠な基盤となります。

NetflixやAmazonといった世界的なテクノロジー企業が示した事例は、QPSを中心としたパフォーマンス管理を、単なる技術課題としてではなく、組織文化のレベルにまで昇華させることが、グローバルな成功にいかに不可欠であるかを物語っています。彼らは、自社のビジネスモデルに最適なパフォーマンス特性を定義し、その達成のためにアーキテクチャ上の大胆なトレードオフを行い、継続的な最適化を組織全体で推進してきました。

デジタルビジネスの戦場において、速度は正義です。そしてQPSは、その速度を測るための最も根源的な尺度の一つです。ビジネスの成長に伴い、システムへの負荷は必然的に増大していきます。その未来を見据え、QPSを企業の成長戦略における羅針盤として位置づけ、継続的な性能管理戦略を構築し、実行すること。これこそが、変化の激しいデジタル時代を勝ち抜き、持続的な成功を収めるための鍵となるのです。

引用文献

  1. e-words.jp, 11月 3, 2025にアクセス、 https://e-words.jp/w/QPS.html#:~:text=QPS%E3%80%90Queries%20Per%20Second%E3%80%91%E3%82%AF%E3%82%A8%E3%83%AA%E6%AF%8E%E7%A7%92&text=%E3%83%87%E3%83%BC%E3%82%BF%E3%81%AE%E6%A4%9C%E7%B4%A2%E3%82%84%E5%8F%96%E5%BE%97,%E6%80%A7%E8%83%BD%E6%8C%87%E6%A8%99%E3%81%A8%E3%81%97%E3%81%A6%E7%94%A8%E3%81%84%E3%82%89%E3%82%8C%E3%82%8B%E3%80%82
  2. qpsの意味・使い方・読み方 | Weblio英和辞書, 11月 3, 2025にアクセス、 https://ejje.weblio.jp/content/qps
  3. QPS完全ガイド：システム性能の要となる指標を徹底解説~中野哲平のエンジニア道 – note, 11月 3, 2025にアクセス、 https://note.com/nakano_teppei1/n/nd6d362375ea9
  4. QPS（クエリ毎秒）とは – IT用語辞典 e-Words, 11月 3, 2025にアクセス、 https://e-words.jp/w/QPS.html
  5. マーケティングの考え方について(ターゲティングとQPS)① | コンサルタントコラム | 中堅・中小企業向け経営コンサルティングの小宮コンサルタンツ, 11月 3, 2025にアクセス、 https://www.komcon.co.jp/column/2846/
  6. マーケティングに力を入れよう ～お客様が求めるQPSの組み合わせ～ – FOLIO – キャシュモ, 11月 3, 2025にアクセス、 https://cashmo.jp/blog/2018/05/16/201805marketing/
  7. 競合他社との違いを分析する際は、Ｑ（クオリティ）、Ｐ（プライス）、Ｓ（サービス）で比較してみる, 11月 3, 2025にアクセス、 https://diamond.jp/articles/-/214689
  8. マーケティングの考え方② 企業の存続とのつながり | コンサルタントコラム – 小宮コンサルタンツ, 11月 3, 2025にアクセス、 https://www.komcon.co.jp/column/2850/
  9. QPS研究所 会社紹介, 11月 3, 2025にアクセス、 https://impact-consortium.fsa.go.jp/wp-content/uploads/2025/03/wg03_04_03.pdf
  10. 小型SAR衛星で切り拓く、QPS研究所の新時代・地球観測ビジネス｜Inside IR – note, 11月 3, 2025にアクセス、 https://note.com/insideir/n/n713c5bf6c04c
  11. QPS研究所、営業・経常利益の通期黒字化を達成 売上高は商用機運用開始でYoY+344.5, 11月 3, 2025にアクセス、 https://finance.logmi.jp/articles/379897
  12. QPS研究所が10億円の追加資金調達を実施 – PR TIMES, 11月 3, 2025にアクセス、 https://prtimes.jp/main/html/rd/p/000000032.000049970.html
  13. What is QPS and How it Affects System Design, 11月 3, 2025にアクセス、 https://systemdesignschool.io/fundamentals/qps
  14. Understanding the difference between Virtual Users and Requests Per Second (RPS), 11月 3, 2025にアクセス、 https://loadfocus.com/blog/2024/06/understanding-the-difference-between-virtual-users-and-requests-per-second-rps
  15. Database Performance: Impact of Storage Limitations | simplyblock, 11月 3, 2025にアクセス、 https://www.simplyblock.io/blog/database-performance-storage-limitations/
  16. TPS和QPS的区别 – CSDN博客, 11月 3, 2025にアクセス、 https://blog.csdn.net/qq_27706119/article/details/142353300
  17. SRE Monitoring Indicators (Part 1): The “Need for Speed” in …, 11月 3, 2025にアクセス、 https://medium.com/@sreThoughts/sre-monitoring-indicators-part-1-the-need-for-speed-in-throughput-and-performance-375adb04496d
  18. ユーザーエクスペリエンスとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典, 11月 3, 2025にアクセス、 https://wa3.i-3-i.info/word11633.html
  19. ユーザーエクスペリエンス（UX）を評価する主な指標 | 見える化エンジンラボ, 11月 3, 2025にアクセス、 https://www.mieruka-engine.com/media/ux-rate
  20. たったこれだけ！コンバージョン率を上げる究極の3つの方法！, 11月 3, 2025にアクセス、 https://kkusaba.com/increase-conversion-rate/
  21. Things to Consider When Scaling Analytics for High QPS – Developer Center – Imply, 11月 3, 2025にアクセス、 https://imply.io/developer/articles/things-to-consider-when-scaling-analytics-for-high-qps/
  22. What is queries per second (QPS) and what is it used for? – SOAX, 11月 3, 2025にアクセス、 https://soax.com/glossary/qps
  23. ロードバランサー（Load Balancer）とは？意味・定義 | IT用語集 | NTT docomo Business Watch, 11月 3, 2025にアクセス、 https://www.ntt.com/bizon/glossary/j-r/load-balancer.html
  24. 負荷分散 – ロードバランサとは、DNSラウンドロビンとは – ネットワークエンジニアとして, 11月 3, 2025にアクセス、 https://www.infraexpert.com/study/loadbalancer1.html
  25. 負荷分散とは？ | ロードバランサーの仕組み | Cloudflare, 11月 3, 2025にアクセス、 https://www.cloudflare.com/ja-jp/learning/performance/what-is-load-balancing/
  26. 負荷分散とは？必要性と仕組み、選び方を解説 – アクセリア株式会社, 11月 3, 2025にアクセス、 https://www.accelia.net/column/trend/6566/
  27. 負荷分散入門(ロードバランサ入門) 第3回 リクエストの分散機能 (1/2), 11月 3, 2025にアクセス、 https://www.fujitsu.com/jp/products/network/security-bandwidth-control-load-balancer/ipcom/material/data/1/3.html
  28. 負荷分散アルゴリズムの種類 – Cloudflare, 11月 3, 2025にアクセス、 https://www.cloudflare.com/ja-jp/learning/performance/types-of-load-balancing-algorithms/
  29. キャッシュとは？初心者でも分かる仕組みやキャッシュクリア（削除）の方法 | マーケトランク, 11月 3, 2025にアクセス、 https://www.profuture.co.jp/mk/column/about-cache-clear
  30. ブラウザのキャッシュとは？仕組みと効果的な活用方法を徹底解説！, 11月 3, 2025にアクセス、 https://linedot-design.com/blog/978/
  31. キャッシュとは？Webサイト高速化にかかせない機能をご紹介！, 11月 3, 2025にアクセス、 https://digitalidentity.co.jp/blog/seo/seo-tech/cash-speed-up.html
  32. ホームページのキャッシュ対策、正しく理解してWebサイトを快適に！ – アートクリック, 11月 3, 2025にアクセス、 https://artclick.jp/column/cache-update-20240508/
  33. データベースの速攻テクニック インデックスの仕組みと最適化ガイド – ITとPCに関連する用語の解説, 11月 3, 2025にアクセス、 https://it-notes.stylemap.co.jp/webservice/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E9%80%9F%E6%94%BB%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E3%80%80%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE/
  34. 検索速度を劇的に向上！MySQLインデックス最適化ガイド – テンファイブ株式会社, 11月 3, 2025にアクセス、 https://10-5.jp/blog-tenfive/5070/
  35. DB Index 最適化方法 #Java – Qiita, 11月 3, 2025にアクセス、 https://qiita.com/rumblekat03/items/8ddb761331fc17258a0d
  36. インデックスでSQLのパフォーマンス爆上がり！O記法高速化を実現 …, 11月 3, 2025にアクセス、 https://www.ye-p.co.jp/node/360
  37. インデックスのパフォーマンスチューニング｜【データベース基礎】インデックスの仕組みを理解する（初学者向け） – Zenn, 11月 3, 2025にアクセス、 https://zenn.dev/farstep/books/learn-database-index-basics/viewer/index-performance-tuning
  38. オートスケールとは | クラウド・データセンター用語集 – IDCフロンティア, 11月 3, 2025にアクセス、 https://www.idcf.jp/words/auto-scale.html
  39. オートスケーリングとは | IBM, 11月 3, 2025にアクセス、 https://www.ibm.com/jp-ja/think/topics/autoscaling
  40. オートスケールとは？メリットや使用上の注意点（ステートレスとステートフルについて）も解説, 11月 3, 2025にアクセス、 https://www.rworks.jp/system/system-column/sys-entry/21683/
  41. Azure Monitor での自動スケーリング – Microsoft Learn, 11月 3, 2025にアクセス、 https://learn.microsoft.com/ja-jp/azure/azure-monitor/autoscale/autoscale-overview
  42. 【初心者向け】 Amazon EC2 Auto Scaling について | SunnyCloud, 11月 3, 2025にアクセス、 https://www.sunnycloud.jp/column/20210712-01/
  43. Capacity Planning – USENIX, 11月 3, 2025にアクセス、 https://www.usenix.org/system/files/login/articles/login_feb15_07_hixson.pdf
  44. Capacity Estimation in Systems Design – GeeksforGeeks, 11月 3, 2025にアクセス、 https://www.geeksforgeeks.org/system-design/capacity-estimation-in-systems-design/
  45. System Design 101 | QPS. What is QPS? | by Prakash Singh – Medium, 11月 3, 2025にアクセス、 https://medium.com/@psingh.singh361/system-design-101-qps-6c4d65a2a3ff
  46. Optimizing the Netflix API, 11月 3, 2025にアクセス、 http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
  47. The Netflix API Optimization Story – InfoQ, 11月 3, 2025にアクセス、 https://www.infoq.com/news/2013/02/netflix-api-optimization/
  48. Redesigning the Netflix API – Netflix TechBlog, 11月 3, 2025にアクセス、 http://techblog.netflix.com/2011/02/redesigning-netflix-api.html
  49. How Netflix Scales its API with GraphQL Federation | Netflix TechBlog, 11月 3, 2025にアクセス、 https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
  50. How Netflix optimizes use of Apache Cassandra® for massive scale – YouTube, 11月 3, 2025にアクセス、 https://www.youtube.com/watch?v=n_SXhW-x0WA
  51. Dynamo: Amazon’s Highly Available Key-value Store, 11月 3, 2025にアクセス、 https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
  52. DynamoDB Architecture | By Joud W. Awad – Medium, 11月 3, 2025にアクセス、 https://medium.com/@joudwawad/dynamodb-architecture-5a38761501a7
  53. Build scalable, event-driven architectures with Amazon DynamoDB and AWS Lambda, 11月 3, 2025にアクセス、 https://aws.amazon.com/blogs/database/build-scalable-event-driven-architectures-with-amazon-dynamodb-and-aws-lambda/
  54. What is Amazon DynamoDB? – Amazon DynamoDB – AWS Documentation, 11月 3, 2025にアクセス、 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html
  55. DynamoDB throughput capacity – AWS Documentation, 11月 3, 2025にアクセス、 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html
  56. メルカリShops パフォーマンス改善 奮闘記 – Mercari Engineering, 11月 3, 2025にアクセス、 https://engineering.mercari.com/blog/entry/20221114-souzoh-performance-improvement/
テクノロジー
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

目次