スプーキーズのちょっとTech。

SPOOKIES社内のより技工的な、専門的なブログページです。

エイチームさん主催の勉強会に行ってきた

スプーキーズ スプーキーズ-community インフラ インフラ-mysql

技術ブログの方では「はじめまして」になります、アルバイトの 本田 です！

急ではありますが、スプーキーズには勉強会参加支援制度があります。

勉強会参加支援制度とは、勉強会に参加する費用を会社から出してもらう代わりに、

学んできたことを社内にフィードバックする制度です！

今回は、僕が勉強会参加支援制度を使って参加してきたエイチームさん主催の勉強会について、

社内だけでなく、社外にもお伝えできれば！と思います。


↓ 以下本編↓

TL;DR

  • エイチームさんが実際のサービスで使った便利なミドルウェアやツールの紹介
  • MySQLオンラインマイグレーションツールgh-ostで深夜メンテ回避
  • RUNDECKでジョブを一元管理
  • VSCodeが熱い！（Emacs民に人権なし。悲しみ。）
  • MySQL界隈が熱い！
  • 俺はエンジニアだ！俺は速くしたい！（パフォーマンスチューニングの話）

勉強会情報

  • イベント名：ATEAM TECH 大阪「見せます!Webサービス開発を支えるミドルウェア/ツール」
  • 主催：エイチームさん（大阪支社）
  • 主題：Web開発において便利なミドルウェアやツールを紹介。主にサーバサイド
  • イベントリンク：https://ateam.connpass.com/event/104825/

キーノート おおざっぱまとめ

【発表01】MySQLオンラインマイグレーションツールgh-ostで深夜メンテナンスを無くした話

発表者：s2terminal さん

ある日、深夜メンテナンスが必要となった

  • エイチームさんのとあるサービス

    • DAU：数十万
    • Monthle Page View：億以上

  • そのサービスで使用しているDB

    • MySQL
      • 構成：master/slave
      • donwloads：600万件以上
      • データベースI/O：数十/秒（同社サービス内トップ？）

  • あるテーブルに新しくカラムを追加しないといけなくなった

    • 現在DBに格納されているレコード数は膨大
    • migrateに時間がめちゃくちゃかかる

↓でもでも

  • サービスを止めるわけにはいかない…（じゃあ、深夜メンテ？）
  • 深夜メンテは絶対にしたくない…
  • なにか良い方法はないか…

GitHubがいい感じのツールをOSSで開発してるよ

その名は 『gh-ost』

  • Github：https://github.com/github/gh-ost
  • 正式名称：GitHub's Online Schema Migrations for MySQL
  • オンラインマイグレーションツール
  • 本番で動いているテーブルのコピー（ゴーストテーブル）を作成し、そっちにmigrateかけて、できあがったら本番のものと入れ替える
  • 本番用のテーブル内のデータが更新されたときは、非同期でゴーストテーブルも更新する。
    • レプリケーションの作成って非同期ですよね？それと同じ仕組みを使うことで、gh-ostも非同期で、データ同期できます！
      • すなわち、binary logを見てる

gh-ostのいいところ

  • 実行状況をGUIで確認できる
  • migrateが完了したゴーストテーブルと本番テーブルの入れ替えは手動で行える
    • gh-ostにmigrate作業を深夜のうちにやっておいてもらい、担当者が出社してきたら、テーブルの入れ替えをコマンドひとつでぽちーっとやって、動作チェックできる！
    • もちろん全て自動で行うことも可能！

つまり、深夜メンテしなくてよくなった！

感想

エイチームさんが運用している大きなサービスで実際に使ったツールに関する話で、動かしてみてどうだったかというところも聞けたのでかなりおもしろい話だった。

自分も来年から大規模なサービスに関わるので、こういった知識は大変ためになる。

【発表02】サービスを支えるジョブ管理システム

発表者：kytiken さん

エイチームにおけるジョブ（バッチ処理）

  • アフィリエイトサービスにおける、クライアント企業へのレポートメールなどはジョブとして、定期的に自動で行っている。

ジョブ管理システム有名所

  • cron
    • 管理するジョブが増えてくると分かりづらい（ただのコマンドの列挙だし）
    • サーバが増えてくると、あのcronどこで管理してたっけ？ってなる
    • エラー時のログが分かりづらい

解決策 『RUNDECK』

  • RUNDECK
    • ジョブスケジューラ
    • 実行されるジョブ一覧を管理画面で確認できる
    • 実行状況をリアルタイムで確認できる
      • パーセンテージ表示
    • rundeckがssh接続でサーバにアクセスしジョブを実行する（エージェントレス）
    • cronと同じ形式で記述可能（cronからコピペするだけでいい）
    • webhook対応（slackへの通知も可能）
    • fluentdにログ保存可能
    • rundeckのGUIでジョブ登録可能（コマンドとかジョブ名、実行サーバ名とか入力するだけ）

rundeckで運用してみて

  • rundeck自体が落ちたら全ジョブが死ぬ（当たり前）
    • 対策：クラスタモード
  • 動作が重い
    • t2.smallで運用していたが、ジョブが増えるにつれて重くなった
    • 対策：JVMのチューニング
  • h2databaseがデフォルトDB
    • Java動作で負荷が高くなった（重い？）
    • 対策：外部DBに変更
  • ジョブの頻度が多い場合に負荷が高くなり始めた
    • ログが大量になったため負荷が高くなった
    • 対策：ログを定期的に削除
      • APIが存在するが、全削除しかなくて困る（対策要検討）

感想

こちらの話も実際にRUNDECKで運用してみてどうだったかという話まで聞けたので、参考になった。

ジョブは一元管理するか、ドキュメント作ったりしないと、すぐに迷子になってしまうものだと思っているので、こういうツールはいいと思いました。

ただ、デメリットも多い模様で、使うときは要検討！

【発表03】サービスで活用したRailsパフォーマンスチューニングツールの話

発表者：@sakupa さん（エイチームの方）

パフォーマンスチューニングをやることになった経緯

  • 開発優先でパフォーマンスチューニングできてなかった
  • ISUCONに出て刺激を受けた
    • 大会でやったことを業務に活かす！
  • なぜパフォーマンスチューニング？
    • 俺はエンジニアだ！俺は速くしたい！
      • ↑かっこよすぎる

パフォーマンスチューニングにおける優先度を決定

  • CV（コンバージョン）に繋がるページ
    • コンバージョン：Webサイト上で獲得できる最終的な成果
  • できるだけ小さい改修
  • あくまでリファクタリング

パフォーマンス監視サービスの導入

  • New Relic（ニューレリック）
    • ローカル段階から導入できる！
    • Railsならgemいれるだけで動く

発行クエリ数が多いぞ！？

  • New Relicにより発見
  • 続けてrack-mini-profilerで調査するとN+1問題が発生していることも見つけた
  • bulletでN+1問題の場所特定
  • チューニング！

パフォーマンスチューニングにおいて大事なこと

  • ボトルネックを細かく追うこと

感想

パフォーマンスチューニングをやるさいに、先輩からなぜやるのか聞かれたそうですが、「俺はエンジニアだ！俺は速くしたい！」と言い切ったそうです。 こういうエンジニアになりたいです。

プロファイラは僕も触ったことがありますが、導入が大変だったのを覚えています。 RailsならGem入れるだけでごにょごにょしてくれるらしい！（それがいいのか悪いのかは置いといて…）

LT大会 おおざっぱまとめ

【LT01】Effective Debugging React Apps in VSCode

発表者：むらじゅん（@murajun1978）さん

宣伝

どのエディタ使ってますか？

  • VSCodeが大半
  • Emacs民の人権なし

No more Print Debug

  • print debug は無駄が多い
  • VSCodeのデバッグ機能をどんどん活用していこうという話
    • ただし、Railsでは ruby-debug-ideとdebase gemが必要
      • 最新版はうまく動作しないから、Beta版使わないといけない
  • VSCode Recipes にデバッグのサンプルいっぱい
  • なにやらVSCodeのデバッグに関する設定ファイル？について話されていたが、そもそもVSCode使っていない僕にはなんのことか分からなかった…（ここが本題だったのに…）

感想

最近、VSCodeが熱い！って話をよく聞くけど、会場の8割型がVSCodeユーザだったのは焦った。

自分もちょっと試してみようかな！

【後日談】

家に帰って試してみました。 結論としては、以下の理由で即アンインストールしました。 - 自分の用途の範囲では、別にVSCodeだからできることがなかった - Emacsのキーマップにしましたが、デフォルトのキーマップとコンフリクトしまくり

感想：エディタひとつでなんでもやってしまいたい人にはいいのかも。でも、僕はIDEはIDE。エディタはエディタで分けたい人。… アンインストール！

【LT02】MySQL InnoDB Cluster

発表者：@masayuki14 さん（スプーキーズのアンバサダーです！）

発表資料：https://speakerdeck.com/masayuki14/mysql-innodb-cluster-woshi-tuteyun-yong-woshou-ba-kisiyou

MySQL InnoDB Cluster がすごい

  • 3つのコンポーネントを使って作る高可用性構成
  • セットアップが簡単
    • MySQL Shell で簡単にセットアップ
  • 自動フェイルオーバー
  • マスターの自動昇格
  • M/Sの接続を自動で切り替える
  • スケールアップが容易

感想

他の参加者の方がMySQL Routerが単一障害点になるからどうなんだろう…って議論されていて、それを聞くのも、またおもしろかったです！ （確かにMySQL Routerが死ぬと終わりですね…）

↓ 社内勉強会にて @masayuki14 さんからもらった補足コメント

MySQL Routerは、Appサーバーに同梱して動作させる使い方がいいのだけど、 昨今のコンテナを使ってやる場合、AppコンテナとMySQLRouterコンテナに分離すると MySQLRouterが単一障害点になるんじゃないか、っていうはなし。

MySQLRouterコンテナも一つじゃなくて複数建てれば分散できる。 MySQLRouterの死活をチェックして別の接続先に切り替える、 みたいな冗長化するのはあんまり意味ないんじゃないか、というところ。

全体を通じての感想

f:id:spookies_honda:20181206201659p:plain:w350
お酒！ピザ！お寿司！

Meet Up 形式のイベントだったため、 勉強会スタート前からお酒飲んだり、ご飯を食べたり、かなりアットホームな雰囲気で始まりました。

エイチームさんが実際に使っているツールを知ることができ、加えて、実運用においてどうだったかというところまで教えてもらえたので、かなり有意義な時間でした。

次は来年の1, 2月ごろ開催だそうです。 また参加したい！