MySQL Casual Talks vol.8で喋ってきた

先日行われたMySQL Casual Talks #8で登壇してきた。会場を貸してくださったテコラスさん、主催者ならびに参加者の皆様ありがとうございました。



発表のネタ

ネタは「トレタのMySQL」と「はじめてのRails+MySQLの運用でOctopusでハマったこと」の二つを用意したんだが、後者は内容がRailsに寄りすぎていたというのと、時間的にもアレだったので自粛した。

小規模限定回ということだったんだが、そもそもウチは小規模なんだろうか？という疑問があった。なので「これできるの小規模だからだよなぁ…」と思えることを捻出して喋ってみた。

トレタのMySQL

内容的には、

• 小規模だと、Likeで全文検索とかアンチパターンみたいなことやっててもでも割と動くよ。
• 小規模だと大規模に比べて運用は楽。でもこれは台数が少ないからということではなく、アーキテクチャがシンプルだから。
• 大規模であってもシンプルなアーキテクチャであれば運用は楽なはずなので無駄なミドルウェア極力導入はすべきではない。
• とはいってもその用途に特化したミドルウェアの導入は問題解決のソリューションの一つなので、このようなアンチパターンで問題が顕現化してきたら検討はすべき。
• ビジネスが成長するまではRails+MySQLみたいにザクっと作れる定番の組み合わせでいいと思うよ。
• ビジネスの成長に伴い、データ量が増加してくるとアンチパターンから脱却しないとなあ。
• データの肥大化、エンジニアの人数の増加に伴い、RailsのマイグレーションではいずれDB周りの運用が回らなくなってくるんだろうなあ(生alterの負荷、マイグレーションファイルを全員でいじる..etcが辛くなってくるはず)

といったことを喋ったはず。ちなみに全文検索の退避先としてAWS Elasticsearch Serviceの検証は開始している。

初めてのRails+MySQLの運用でOctopusでハマった


こっちが内容がRailsに寄りすぎだったので自粛した方。Octopusのせいでデプロイ時にエラー多発して困ったけど、issue見たら対応策があったってのと、ソース読んでみたらOctopusがRails <-> MySQLのコネクションを勝手にごにょごにょしていたという事案の共有。というかこの記事をスライド化したもの。

おわり