エイチームさんの勉強会に行ってきた『見せます!Webサービス開発を支えるミドルウェア/ツール』
TL;DR
- エイチームさんが実際のサービスで使った便利なミドルウェアやツールの紹介
- MySQLオンラインマイグレーションツールgh-ostで深夜メンテ回避
- RUNDECKでジョブを一元管理
- VSCodeが熱い!(Emacs民に人権なし。悲しみ。)
- MySQL界隈が熱い!
- 俺はエンジニアだ!俺は速くしたい!(パフォーマンスチューニングの話)
勉強会情報
- イベント名:ATEAM TECH 大阪「見せます!Webサービス開発を支えるミドルウェア/ツール」
- 主催:エイチームさん(大阪支社)
- 主題:Web開発において便利なミドルウェアやツールを紹介。主にサーバサイド
- イベントリンク: ateam.connpass.com
キーノート おおざっぱまとめ
1. MySQLオンラインマイグレーションツールgh-ostで深夜メンテナンスを無くした話
発表者:s2terminal さん
ある日、深夜メンテナンスが必要となった
エイチームさんのとあるサービス
- DAU:数十万
- Monthle Page View:億以上
そのサービスで使用しているDB
- MySQL
- 構成:master/slave
- donwloads:600万件以上
- データベースI/O:数十/秒(同社サービス内トップ?)
- MySQL
あるテーブルに新しくカラムを追加しないといけなくなった
- 現在DBに格納されているレコード数は膨大
- migrateに時間がめちゃくちゃかかる
↓でもでも
- サービスを止めるわけにはいかない…(じゃあ、深夜メンテ?)
- 深夜メンテは絶対にしたくない…
- なにか良い方法はないか…
GitHubがいい感じのツールをOSSで開発してるよ
その名は 『gh-ost』
- GitHub's Online Schema Migrations for MySQL
- オンラインマイグレーションツール
- 本番で動いているテーブルのコピー(ゴーストテーブル)を作成し、そっちにmigrateかけて、できあがったら本番のものと入れ替える
- 本番用のテーブル内のデータが更新されたときは、非同期でゴーストテーブルも更新する。
- レプリケーションの作成って非同期ですよね?それと同じ仕組みを使うことで、
gh-ost
も非同期で、データ同期できます!- すなわち、
binary log
を見てる
- すなわち、
- レプリケーションの作成って非同期ですよね?それと同じ仕組みを使うことで、
gh-ostのいいところ
- 実行状況をGUIで確認できる
- migrateが完了したゴーストテーブルと本番テーブルの入れ替えは手動で行える
- gh-ostにmigrate作業を深夜のうちにやっておいてもらい、担当者が出社してきたら、テーブルの入れ替えをコマンドひとつでぽちーっとやって、動作チェックできる!
- もちろん全て自動で行うことも可能!
つまり、深夜メンテしなくてよくなった!
感想
エイチームさんが運用している大きなサービスで実際に使ったツールに関する話で、動かしてみてどうだったかというところも聞けたのでかなりおもしろい話だった。
自分も来年から大規模なサービスに関わるので、こういった知識は大変ためになる。
2. サービスを支えるジョブ管理システム
発表者:kytiken さん
エイチームにおけるジョブ(バッチ処理)
- アフィリエイトサービスにおける、クライアント企業へのレポートメールなどはジョブとして、定期的に自動で行っている。
ジョブ管理システム有名所
- cron
- 管理するジョブが増えてくると分かりづらい(ただのコマンドの列挙だし)
- サーバが増えてくると、あのcronどこで管理してたっけ?ってなる
- エラー時のログが分かりづらい
解決策 『RUNDECK』
- RUNDECK
rundeckで運用してみて
- rundeck自体が落ちたら全ジョブが死ぬ(当たり前)
- 対策:クラスタモード
- 動作が重い
- t2.smallで運用していたが、ジョブが増えるにつれて重くなった
- 対策:JVMのチューニング
- h2databaseがデフォルトDB
- Java動作で負荷が高くなった(重い?)
- 対策:外部DBに変更
- ジョブの頻度が多い場合に負荷が高くなり始めた
- ログが大量になったため負荷が高くなった
- 対策:ログを定期的に削除
- APIが存在するが、全削除しかなくて困る(対策要検討)
感想
こちらの話も実際にRUNDECKで運用してみてどうだったかという話まで聞けたので、参考になった。
ジョブは一元管理するか、ドキュメント作ったりしないと、すぐに迷子になってしまうものだと思っているので、こういうツールはいいと思いました。
ただ、デメリットも多い模様で、使うときは要検討!
LT大会 おおざっぱまとめ
1. Effective Debugging React Apps in VSCode
発表者:むらじゅん(@murajun1978)さん
あまりメモ取れてません。ごめんなさい笑 (流れがスムーズすぎて、つい聞き入ってしまったんです。ええそうです。)
宣伝
Shinosaka.rb #32
やるからきてね〜
どのエディタ使ってますか?
No more Print Debug
- print debug は無駄が多い
- VSCodeのデバッグ機能をどんどん活用していこうという話
- ただし、Railsでは
ruby-debug-ide
とdebase
gemが必要- 最新版はうまく動作しないから、Beta版使わないといけない
- ただし、Railsでは
- VSCode Recipes にデバッグのサンプルいっぱい
- なにやらVSCodeのデバッグに関する設定ファイル?について話されていたが、そもそもVSCode使っていない僕にはなんのことか分からなかった…(ここが本題だったのに…)
感想
shinosaka.rb 行ってみよう!
最近、VSCodeが熱い!って話をよく聞くけど、会場の8割型がVSCodeユーザだったのは焦った。
自分もちょっと試してみようかな!
2. MySQL InnoDB Cluster
発表者:@masayuki14 さん
MySQL InnoDB Cluster がすごい
- 3つのコンポーネントを使って作る高可用性構成
- セットアップが簡単
- MySQL Shell で簡単にセットアップ
- 自動フェイルオーバー
- マスターの自動昇格
- M/Sの接続を自動で切り替える
- スケールアップが容易
感想
こんな便利な機能があるんですね!
他の参加者の方がMySQL Router
が単一障害点になるからどうなんだろう…って議論されていて、それを聞くのも、またおもしろかったです!
@masayuki14 さんの発表で↓こういうものがあります。 かなりおもしろかったです! ぜひご一読を!
3. サービスで活用したRailsパフォーマンスチューニングツールの話
発表者:@sakupa さん(エイチームの方)
パフォーマンスチューニングをやることになった経緯
- 開発優先でパフォーマンスチューニングできてなかった
- ISUCONに出て刺激を受けた
- 大会でやったことを業務に活かす!
- なぜパフォーマンスチューニング?
- 俺はエンジニアだ!俺は速くしたい!
- ↑かっこよすぎる笑
- 俺はエンジニアだ!俺は速くしたい!
パフォーマンスチューニングにおける優先度を決定
- CV(コンバージョン)に繋がるページ
- コンバージョン:Webサイト上で獲得できる最終的な成果
- できるだけ小さい改修
- あくまでリファクタリング
パフォーマンス監視サービスの導入
- New Relic
- ローカル段階から導入できる!
- Railsならgemいれるだけで動く
発行クエリ数が多いぞ!?
- New Relicにより発見
- 続けて
rack-mini-profiler
で調査するとN+1問題が発生していることも見つけた bullet
でN+1問題の場所特定- チューニング!
パフォーマンスチューニングにおいて大事なこと
- ボトルネックを細かく追うこと
感想
パフォーマンスチューニングをやるさいに、先輩からなぜやるのか聞かれたそうですが、 「俺はエンジニアだ!俺は速くしたい!」と言い切ったそうです笑
こういうエンジニアになりたいですね笑
プロファイラは、自分も使ったことがありますが(開発のバイトやってます)、導入が大変だったのを覚えています。 RailsならGem入れるだけなんですね!
全体を通じての感想
Meet Up 形式のイベントだったため、 勉強会スタート前からお酒飲んだり、ご飯を食べたり、かなりアットホームな雰囲気で始まりました。
大阪消費激しめ#AteamMeetUp pic.twitter.com/8Haszck5UT
— エンジニアさん 🌓 (@yyh_gl) 2018年11月15日
エイチームさんが実際に使っているツールを知ることができ、加えて、実運用においてどうだったかというところまで教えてもらえたので、かなり有意義な時間でした。
次は来年の1,2月ごろ開催だそうです。 また参加したい!