地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

書き込みが多いサービス運用ってどうやるんだろうって散歩しながら思った話

Write-heavyなサービスを運用している場合にうまい感じにスケールさせる方法って何があるんだろうって疑問。Readが多いケースだったり整合性の要件が結果整合性とかであればRDBを使う必要はなさそうだけどそうじゃない場合みたいなやつ。

パッと思いつくのはマシンのスペックアップでCPUとかIOPSの高いディスクとかお金をかければなんとかなるはず。限界は来るからどうなんだろうという感じ。

あとは垂直分割なり水平分割なりでDBやテーブルを分割していくみたいな方法とかもあるのかな。シャーディングしていくことでロック競合を減らしていく戦法。途中で入れるのとかめっちゃ難しそうだけどINSERTの性能劣化がサービスに影響するかなんてサービス開始時に把握できないしでやるのは大変そう(小並感)って感じだった。スナップショット取ってしばらくはダブルライトとか戦略とかで少しずつ移行みたいな大掛かりなものになりそう

qiita.com

この辺の話とかみてると大変そうだな〜と...

engineering.linecorp.com

RDSでやるなら?

Amazon RDS で構築されたデータベースのグループを複数用意してシャーディングされた構成を用意しておいてクライアント側で書き込み先を決定していく方法。こういうのやるのっていくらくらいかかるんだろう...シャードデータベースアーキテクチャとかっていうらしい。

aws.amazon.com

部分的にDynamoDBとかにオフロードさせてサービスを継続させてみたいな方法も良さそうかな?