BPStudy#25に参加してきました
BPStudy#25 パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ という勉強会に参加してきました。
最近、忙しかったので久しぶりの勉強会参加&ブログ書き込みです(汗)。
スピーカーは、id:kazuhookuさん
プレゼン資料は、いくつか組み合わせた感じだけど、この2つの資料をメインに説明をしてました。
とても濃いお話だったので、自分はついていくのがやっとって感じでしたが、とても楽しかったです。
今回は、勉強会で自分が印象に残ったことを書いてみます。
どこまでやるかの指標を設定する
パフォーマンスチューニングはきりがないから、処理速度には上限があるはずなのでどこまでチューニングするかの指標を設定することが大切。
たとえば、理論上の最速値(MIPSとかバンド幅とか)の70%に到達することを指標にするとか。
とても納得。でも、指標を設定するにはそれなりのスキルがいるので指標を設定できる人になる必要がありますね。
自分はそのスキルをもってないので、まずはそのスキルが必要ですな(汗)。
mysql_timelineってツールを使うことで指標を出すことができるっぽいので、一度試してみようと思います。
スケールアウトは2000年代のトレンド
スケールアウトは2000年代のトレンド。
コミュニケーションツール(mixiとか)はシステムの規模は大きいが、データのつながりが弱いのでスケールアウトが容易。
スケールアウトの流行は、スケールアウトをしやすいシステムが増えてきているからって話。
当たり前の話かもしれないけど「複雑な業務システムでスケールアウトなんてことはやっちゃだめなんだなぁ」って思いました。
雑誌の特集とかを読んで、どこかのお偉いさんが「次のシステム移行はスケールアウトで!!!」なーんてことがあったりすると悲惨なプロジェクトが生まれそうなんで、ちょっと怖いです。
とりあえず、無茶なスケールアウトについては「やめましょう」っていえるエンジニアでいようと思いました。
スケールアップの逆襲
革新的なサービスが登場しなければ、コスト的にスケールアップがまたはやるのではないか
やっぱりハードウェアの性能をアップすることで解決できるなら、それが一番楽。
案件によってはスケールアウトが必要な局面もあるかもしれないけど、スケールアップで解決できるなら、そちらを選択したいですね。
大規模ウェブサービスの課題
大規模ウェブサービスのチューニングはRDBMSのパーティショニングが多数解となっている。
初期は、アプリケーション毎のパーティショニングで、最近はユーザーごとのパーティショニングが主流となっている。
この問題点は、事前の分割設計が難しいこと、運用開始後の再分割が難しいということがあげられる。
ここらへんの話は、大規模ウェブサービスの仕事をしたことがない自分には「へー」という感じでした。
ユーザーだけではなく、ユーザーと商品と倉庫でパーティショニングをしているところもあるらしいです。
あと、経験がなくても事前の分割設計が難しいということは、パーティショニングしているシステムがどういう処理をするのかを説明してもらったので自分も理解できました。
RDB使ってると、正規化さえしていればリリース前に仕様変更が入ってもなんとかなったりしますが、パーティショニングしているとかなり厳しそう。
これは最近はやりの分散KVSにも同じことが言えそうですね。
こういった案件では、開発の初期段階でかなりしっかり設計をしていく必要がありそうです。
Incline & Pacific
RDBMSと分散KVSのいいとこどりを目指しているプロダクト。RDBMSの動的パーティショニング技術。
Inclineは、ノード間のデータ同期に専念。pacificはRDBMSのshardに専念。
ここまでディープになると、自分は「ぽかーん」って感じです(苦笑)。
でも、RDBMSのパーティショニングを実施するのに、自動化できる部分は自動化した方が絶対よいはずなので正式版がでれば使われるのではないでしょうか。
参加した人にしかわからないかもしれませんが、運用後の再分割の説明をする際に「ユーザーから書き込み権限をとっちゃうんで整合性は大丈夫です」って内容はとても面白かったです。
まとめ
チューニングの基本的な考え方もふまえて説明してもらったので、とても勉強になったし、楽しかったです。
自分は、BPStudy#22で初めてBPStudyに参加したのですが、その時も同じように感じたので、これからも参加していきたいですね。