私は、50,000 以上のセッションを持つ 1 日あたり約 30,000 人のユーザーを抱える e コマース Web サイトを運営しています。RDS m5.xlarge インスタンスを使用しています。日常的な読み取りまたは書き込み操作で特に問題が発生することはありません。ただし、時折、次のような課題に直面することがあります。
- セールや積極的なマーケティングにより、ある日にはユーザー数が2倍以上になり、そのような時にはCPUが1日のうち何回も100%に達することがあります。
- 非常にまれに、大量の書き込みが進行中の場合、読み取りが遅くなることがあります
これを見ると、RDS インスタンスをさらに垂直にスケールアップするか、リードレプリカを起動するか判断できません。この決定を行う際に考慮したい 2 つのポイント:
- 読み取りレプリカがあれば、トラフィック量が多い日に DB の垂直方向の間隔をさらに広げる必要がなくなりますか?
- 読み取りレプリカを使用して、スケーラビリティを高めながらコストを下げるか、または同じままにすることはできますか。
平均すると、m5.xlarge インスタンスで次の使用量になります。
- CPU使用率40%
- DB接続数 100
- RAM 6 GB使用
- 125 書き込み IOPS
- 3 読み取りIOPS
CPU 以外の使用率は非常に低いようですが、リードレプリカはコストを増やすことなくスケーラビリティを向上させる方法でしょうか?
答え1
必要なのは自動スケーリング RDS のようですが、残念ながらコンピューティングには存在しません。
RDS サイズを増やす
インスタンスのサイズを大きくすると、24 時間 365 日の料金が高くなります。これは最も簡単な解決策であり、多くの問題を軽減できるはずです。コストが問題にならない場合は、これがおそらく最善の解決策です。
レプリカの読み取り
もう 1 つの主要なオプションは、読み取りレプリカです。読み取りレプリカはメイン データベース URL とは異なるエンドポイントを持つため、読み取りレプリカを使用するにはソフトウェアを変更する必要があります。たとえば、すべての書き込みをメイン データベースに送信し、すべての読み取りを読み取りレプリカに送信することができます。読み取りレプリカは、マスターからの更新よりわずかに遅れる可能性があります。メイン データベースのサイズを縮小できる場合もありますが、ベンチマークを行うか、アプローチを慎重に行う必要があります。
予想される大きなイベントの前に、読み取りレプリカを手動で起動することを検討することもできます。これは手動で行う必要があり、時間がかかり、アプリケーションは、常に存在するわけではないが時々存在するデータベースに対処する必要があります。
キャッシング
アクセス パターンによっては、Redis / Memcached にデータをキャッシュすると、データベースの負荷が軽減され、データベースを更新する必要がなくなる可能性があります。もちろん、これは同じデータを複数回読み取る必要があり、十分なキャッシュ ストレージがあることに依存します。
オーロラ
検討してみてはいかがでしょうかMySQL 用 Amazon Aurora私自身はまだ使用していませんが、非常にスケーラブルであるはずです。ただし、個々のトランザクションは標準の RDS ほど高速ではない可能性があります。
データベースの最適化
もう 1 つのオプションは、データベース容量を消費しているものを調べて、「コストのかかる」クエリまたはインデックスを最適化することです。クエリが単純で負荷が高いだけの場合は、役に立たない可能性があります。