リファレンスアーキテクチャ: 3 層 OLTP アプリケーション

典型的な業務アプリケーション (注文、決済、在庫) は、短く、単一行で、一貫性が重要なトランザクション (OLTP) を大量に実行する。このツリーは、負荷プロファイルの特定から始めて、プライマリのリレーショナルデータベース、コネクションプーラー、リードレプリカ、キャッシュ層、バックアップ + PITR、監視をいつ導入すべきかを段階的に示す。目的は「最初からすべてを追加する」ことではなく、各ボトルネックが実証されるたびに適切なコンポーネントを追加すること。

負荷プロファイルは: トランザクションの構成と一貫性の要件は?

OLTP アーキテクチャでの最初の判断は、ワークロードが本当にトランザクション型 (ACID を必要とする短い読み書きの混在) かどうか。データは本来リレーショナルで一貫性が重要 (金額、在庫、注文) なのか、ワークロードの大半が読み取りなのか、それとも負荷はまだ非常に低いのか?

• 短いトランザクション、強い一貫性 (金額/在庫/注文)
• 読み取りが大部分を占め、書き込みは少なく、トラフィックは増加中
• 負荷は非常に低い。最もシンプルな構成で十分か?

プライマリのデータベースエンジンは選定済みか、スケールに懸念はあるか?

トランザクションの中核には、リレーショナルエンジン (PostgreSQL、MySQL/InnoDB、Oracle、SQL Server) が適切な基盤。エンジンの選定が明確になったら、次の問題はスケーリング: 現時点では単一インスタンスで十分か、それとも接続数と読み取り負荷が増加しているか?

• エンジンは決まっている。現時点では単一インスタンスで十分
• 接続数が急増し、リソースが不足しつつある
• 読み取り負荷が増加し、プライマリの書き込みインスタンスを圧迫している

読み取りをどうスケールするか: レプリカか、キャッシュか?

読み取り負荷がプライマリインスタンスを圧迫している場合、補完的な 2 つの選択肢がある。レポート/一覧など多少遅れたデータを許容できる読み取りはリードレプリカにルーティングできる。同じ「ホットな」データが何度も要求される場合は、マイクロ秒レイテンシのキャッシュ (Redis) が DB の負荷を軽減する。

• レポート/一覧の読み取りが多い。多少の遅延は許容できる
• 同じ人気データが何度も読み取られる

推奨: 単一プライマリ + プール + バックアップから始める

初期段階ではアーキテクチャをシンプルに保つ: 単一のリレーショナルプライマリインスタンス、その前段のコネクションプール、定期的なバックアップで十分。複雑さを加えるのは、測定されたボトルネックがそれを必要とするときに限る。

推奨: コネクションプーラーを追加する

OLTP では、各アプリケーションインスタンスが独自に接続を開くと、数千の接続によるメモリとスケジューラのオーバーヘッドでプライマリ DB が行き詰まる。間にプーラーを置くことで、少数の実際の DB 接続を多数のアプリケーションリクエストで共有できる。

推奨: リードレプリカを追加する

書き込みはプライマリにとどめ、読み取り専用のトラフィック (レポート、一覧、検索) は、プライマリから供給される 1 つ以上の非同期レプリカにルーティングする。これにより、プライマリは書き込みと一貫性が重要な読み取りに専念できる。

推奨: キャッシュ層を追加する (Redis)

同じ人気データ (セッション、カタログ、プロファイル、ページの断片) が繰り返し読み取られる場合は、DB の前段にインメモリキャッシュを置き、大半の読み取りを DB に到達させずに処理する。レイテンシが下がり、プライマリ DB の負荷が軽減される。