この記事は検索エンジンプロダクトを一緒に開発してた同窓会 Advent Calendar 2023 19日目の記事です。昨日は umeneri さんの PrometeusでHasuraのコンテナのメトリクスを可視化する でした。
re:Invent 面白かったですね! いま自分は Web サービスのデータベース周りを仕事にしていることもあり、特に Amazon Aurora Limitless Database がワクワクもあり、「自前でシャーディング構成組む前に発表されてよかったあー」というところでもありました。
ということで、DBのシャーディングからのらりくらりと逃げて時間稼ぎしていた話をします。
適切に時間稼ぎをする
まず、このような話が出てくるのは端的に言うと「DB の1クラスタでは(writerの)負荷が限界に近い」という状況です。ですが、「負荷が限界に近い」というのがなかなか難しい判断です。
クラウドの場合、だいたい1つスケールアップするとスペック2倍です(1.5倍のパターンもある)。ということは、「あと1段階しかない」となっても案外伸びしろが残っていたりします。しかも、上限を超えるインスタンスクラスが出たり、より性能の良い CPU がリリースされることも(特に最近は)多いです。負荷上昇のペースがそこまで速くない場合、「時間が経てば勝手に解決される」という状況になっている可能性は低くありません。
負荷上昇のペースはサービス成長のペースだけでなく、アクセスパターンの変化も影響が大きいです。サービス開発当初から負荷対策を頑張っているようなケースでない場合、無駄な処理を削ったり、遅いクエリを reader に送ったりするだけでかなり負荷が下がって、上昇ペースも抑えられたりします。
これらは時間稼ぎとも言えますが、「負荷が限界に近い」を早めに判断しすぎた場合、「安全」といえば聞こえがよいものの、ソリューションが限られて将来的につらみを味わうこともあります。「根本解決」といった言葉に踊らされず、冷静に時間稼ぎをすることも時には必要です。
ソリューションが増えそうか
時間稼ぎをするときに、「時間稼ぎをするとより良いソリューションが増えそうか」という観点も重要です。
その観点でいうと、運用が面倒なところはみんながつらみを抱えているため、日進月歩な分野になりやすい印象もあります。今回の話でいうと NewSQL などはまさにそこに当てはまりそうです。
また、Azure Cosmos DB のようなシャーディングのマネージドサービスが提供され始めていて、AWS も NewSQL なりシャーディングなりに対して近いうちに何かしらの手を打ってくることは、以前からある程度想像できる状況ではありました。
どれを採用するかという話は別途ありますが、良さげな選択肢が現在進行系で増えている状況ならできるだけ揃ってから判断するほうがよいです。
という感じでちょこちょこと改善していたら Amazon Aurora Limitless Database が出てきて「あーはん」という話でした。
まとめ…?
こういった感じで、「やるのが大変だし、やったらやったでその後も運用が大変」という類のものは「やらなくてすむならそれに越したことはない」というスタンスで適切に時間稼ぎしつつ、調べ物や準備作業はちょこちょこと進めておいて、本当に必要になったときに最適な選択肢をガッと実行するのがよいかなあと思います。
ちなみにこのスタンス最大の弱点は「やらなくてすんだー!」となった場合でも特に目立つことは何もやってないので偉い人にほめられたりはしないということです。褒められたい人は運用浮いた分でアグレッシブにやりましょう! 私は子育てで体力的にボロボロなのでのんびりやってます…。