MySQL ストアドプログラムのバイナリロギング メモ

MySQL Memo

そもそもバイナリログって？

要するにレプリケーションするために必要なイベントが記録されているログ。

ストアドプログラムのバイナリロギング

MySQL :: MySQL 5.6 リファレンスマニュアル :: 20.7 ストアドプログラムのバイナリロギング

  • ロギングがステートメントレベルで行われる場合、ストアドプログラムに関して該当するバイナリロギングの問題がある
    • ※ストアドプログラム -> ストアドプロシージャ、ストアドファンクション、トリガー、イベント
  • ステートメントがマスターとスレーブで別々の行に影響する場合がある
  • SQLステートメントレベルでバイナリロギングが行われるときに起こる
  • ルーチンorトリガーが実行されると行を変更は記録されるが変更をおこなったステートメントは記録されない
    • ストアドプロシージャーでいうCALLが記録されない

プログラムの内容は記録されず、行の変更のみ記録されてそれがレプリケーションに利用されるということ。

  • ストアドファンクションを利用するための条件
    • CREATE ROUTINE or ALTER ROUTINEと、SUPER 権限が必要
    • CREATE FUNCTIONの際は DETERMINISTIC 、 NO SQL または READS SQL DATA の少なくとも 1 つを明示的に指定する必要
    • 上記を緩和するために log_bin_trust_function_creators に1に設定できる
  • トリガーは DETERMINISTIC 指定がないので常に決定的
    • ただし UUID() などは注意が必要

誰かに影響を受けるということ

Engineer

hb.matsumoto-r.jp

matsumotoryさんとはあまり関わりがなかったが、傍から見ていてもすごい人だなとずっと思っていた。技術的にものすごい方というのは言わずもがなだけど、すごく思慮が深くて自分の考えていることを言語化したり定型化したりするスペシャリストだと思っていて憧れの気持ちしかなかった。Twitterに「すごいエンジニア」リストを作ったときも一番にmatsumotoryさんを入れた。今後のご活躍を陰ながら応援していきたい。

またそれに対してのpyamaさんのアンサーブログがとてもよくて、胸にこみ上げるものがあった。

pyama.fun

影響を与え合うというのはとても尊いことで、本当に素晴らしいなぁと感じたので自分のことも文章にしておきたいと思った。

ここからは自分の話。ペパボに入社して一番影響を受けたのは確実にpyamaさんである。入社してからムームードメインに配属されpyamaさんがメンターとしてついた。特にあれこれ細かく指導するわけでもなく、基本は自分で考えて行動しそれについてアドバイスをくれるようなやり方だったように思う。

僕は入社して一番に見たエンジニアがpyamaさんだったので、WEB業界のエンジニアは皆このようにストイックに技術を追いかけてプロダクトを生み出し、それをアウトプットしてもっとすごいエンジニアになっていくというのが良いエンジニアであるということを教わった。一番近くで見ていたし当然相当な影響を受けた。当時の僕はpyamaさんみたいになりたいと思っていたし、同じような振る舞いをしていたように思う。

しかし、だんだんこれは自分には合わないのではないか？という疑問を感じだしたのを覚えている。pyamaさんがプロダクトを生み出して導入しては良い影響が生まれるが、それを支えて運用していくフェーズもある。そのフェーズはすごく嫌だった。僕もすごいプロダクトを生みたいし、自分の好きなものを作りたいとの気持ちがあった。それができない自分にものすごく苛立っていた。その一方、運用していくフェーズのほうが自分にはあっているのではないかと思うようになってきた。フルスタックまではいかないにしてもサーバーからフロントエンドまで支えられるような環境において広く（深くなりたい）技術スキルを習得してきて、だんだんと日々発生する運用案件をいかに効率よく捌きながら問題の根本を捉えて最短で再発しないようにするか考えられるようになってきた。自分自身それが楽しいと思えてきたし、周りからも徐々に評価されるようになってきて、自分の強みとしても捉えられるようになってきた。

そのうちにpyamaさんはシニアエンジニア、CTOとなり組織のことも考えるようになっていった。その後姿をずっと見てきた。今もロールモデルにしているのはpyamaさんだと思う。しかし純粋に同じようになりたいとは思ってなく、逆にこんなにすごい人がいるのだからその人とは違う道を進んで自分なりの強みを持って勝負していけるように意識している。

「今のペパボは職位が上がれば上がるほど、社のエンジニア育成や組織へのコミットメントが必要なフェーズなのでそれもまた一つのミスマッチの要因になったように思う。」

アンサーブログ内で上のようなという文があったのだけど、恐縮ながら陰で見守ってきた僕の個人的な気持ちとしてはpyamaさんに対しても同じことを感じている。それを原因に退職されては困る（切実）ので、そういった道に進めるように自分が支えていけるようになっていけたらいいなという気持ちをしたためておく。

支離滅裂で赤裸々な文章になってしまってpyamaさん万歳！みたいになってしまったけど、たまにはいいか。

誰かに影響を受けるということは、その人と同じように行動して同じ道を進んでいくというよりも、その人の言動を噛み砕き良いところ悪いところをきちんと捉えて、それに対して自分には何ができるのだろう、そして強みを常に考えながら行動していくということだと思いました。いつか誰かに影響を与えられるようになるぞー。まる。

GMOペパボに入って3年、やってきたことを振り返った

Engineer ふりかえり

2018年7月1日でGMOペパボに入社してから3年がたった。自分自身1つの会社で3年を超えて働いたことがなかったので、もう3年も経つのかという気持ちが大きい。3年間あっという間のような長かったような不思議な感覚がある。いい機会なので何をやってきたか振り返ってみた。

ちなみに入社前まではWEBの会社では働いたことはなく、PHPもRubyも仕事では書いたこともない、ましてや技術イベントで登壇などしたこともない、ほぼゼロからのスタートのようなものだった。なぜ入社できたのかはわからないが、とにかくがむしゃらに自分で書いたコードをGitHubにおいたり、ある程度人に見せれるものを作ってHerokuで動かしたりてアピールしていたように思う。

サービス運用

入社してしばらくはがむしゃらに日々の運用案件をこなしていた。サービスの全体像を掴んだり、PHPとRubyで書かれたアプリケーションのソースを読みながら、バグの原因を掴んで治したりして、まずはチームに不可欠な人になろうと必死にやっていた。

先にも書いたように、PHPもRubyも入社まで書いたことがなかったので、入社後勉強の時間を設けてくれてパーフェクトPHPやパーフェクトRubyを読みつつ勉強させてくれてすごくありがたかった。

コードのリーディング力（というか勘所を掴む能力的なもの）は低い方ではないので、「すべての答えはソースコードにある」という気持ちで読みまくっていた。RubyGemsやComposerのようなエコシステムにも触れ、自分でライブラリを書いてみたりした。

github.com

github.com

github.com

コードレビューや先輩のコードを見たり、OSSのソースコードを読んだりして設計を学んだ。仕事では、運用を省力化してそれ以外の新規開発に充てる時間を増やすために自動化をしたりBotをガリガリ書いたりした。運用案件のissueがopenされてからcloseされるまでの時間を自動で計測してくれるBotを作ってその時間をいかに短くしていくか取り組んだりもした。

f:id:kimromi:20180722230940p:plain

開発環境についてはVagrantで立ち上げたVMにChefをあてて作るスタイルがすでにできていた（現在も利用している）。当時は技術的にもよくわかっていなかったので、vagrant upで開発環境出来て便利だな思っていた。

社内の読書会をきっかけにGolangも少しだけ書いてみたがいまいち身が入らず挫折した。

インフラ

そのうち、アプリケーションのサーバーが物理サーバーから自社のプライベートクラウド（OpenStackで組まれている）に移設されていくようになり、自分も進んで取り組み始めた。インフラの構築や監視、ネットワーク周り、ChefやTerraformでコード管理していく技術を学んだ。Dockerも本を読むなどして勉強し、世の中にはこんな便利なものがあるのかと感じた。

一般的なWEBアプリケーションの構成も知り、keepalivedをつかったロードバランサや、Nginxでリバースプロキシを作って各アプリケーションサーバーにリクエストを振り分けたりできるようにもなった。ドメインのサービスに携わっているのもあって、DNSの知識も得ることができた（DNSサーバーの運用はしてないけど）。一通りアプリケーションをサーバーから立ち上げてドメインの設定して、SSL証明書とってNginxに設定してhttpsでサービス公開して監視、運用、移設もできるようになった。

この頃、それまで既存のPHPのレガシーアプリにツラミを感じていたのだが、10年以上問題なく動いててサービスを支えてくれていることに感謝の気持ちを持てるようになってきた。

あともうひとつ、この頃にシニアエンジニアの昇格試験を受けた。udzuraさんにメンターになっていただき、それまでの自分のやってきたことを振り返りつつアドバイスいただいた。結果は見事に撃沈だったが本当に勉強になったし、自分には何が足りないのかがわかった。

チームリーダー

2017年9月、長年チームに在籍してサービスをまるっと知り尽くしている先輩が退社されたのと同時に、ムームードメインチームのリーダーになった。先輩が抜けた穴はかなり大きく大変だったが、コード化や自動化できていなかったところを皆で協力して少しずつコードにしていくことで省力化することができてきている。

リーダーとしては俺について来いタイプでは無いので、どちらかというと見守りつつ下から支えるタイプであると思う（サーバント型？）。自分の意見を押し通すではなく、自分の意見は持ちつつも皆できちんと議論した上で噛み砕きつつ、スッと説得力のあるアイデアを出してまとめるみたいなのを心掛けている。今までリーダーの経験はなくて、最初はどうやったらチームがうまく纏まって機能するか、また雰囲気のいいチームになってメンバーたちが出社が苦にならないかを考えていた。うまくいったかどうかはわからないが、問題はない（と思っている）。リーダーになってから3ヶ月くらい、技術的なアプローチが全然できてなかったので、2018年からは少し肩肘の力を抜いて、本来のエンジニアとしての技術を磨いてアウトプットする作業もやっている。

学生のインターンシップのメンターも初めて経験した。また中途採用の面接官もするようになった。今現在高いスキルはは持ち合わせていなくても継続して学び続けることのできる人かどうか、ペパボの風土に合うかどうかなど、人を見る目が少しついたように思う。

tech.pepabo.com

フロントエンド

最初にフロントエンドの技術に触れたのは社内サービスの顧客管理システムの1機能の中にVue.jsを採用したところから。それまではPHP、Ruby on Rails内で愚直にjQuery、CoffeeScriptで書いていた。その後ショッピングカートを実装したときにユーザーが目に触れるところでVue.jsを採用してリリースした（2017年7月）。

tech.pepabo.com

そのあたりは本番環境にVue.jsを使った話とかVue.js on RailsとかムームードメインのJavaScript環境を整えた話で外部、社内イベントで登壇した。最近のプロジェクトではVue.jsに加えてNuxt.js、TypeScriptを採用してサービスのリニューアルの実装をしている（リニューアルについてはインフォメーションで少しだけ触れている）。

最近触れるようになってきたフロントエンドの技術だが、なぜか面白みと楽しさを感じる。ただうまく言語化できていないので考えていきたい。

見えてきた自分の長所と短所

3年間とにかくがむしゃらに走ってきたように思う。その中でもとにかく手を動かすというのを心がけている。最初はあまり大きくない問題に対して大きなコスト（時間）をかけていた。シニアエンジニアの立候補をきっかけに、問題の大きさをきちんと捉え大きな問題をなるべく小さなコストかつ未来につながる方法で対応していくということをできるようになってきたように感じる。技術的に何かが突出しているエンジニアではない（自分もそれが向いているとあまり思っていない）ので、バランスをとりつつ引き出しをたくさん持った中から手数を多く出していくようにこれからもやっていく。

あとエンジニアにはあまり関係ないが、私は周りの人のことをものすごく観察していて、ちょっと見ただけでその人が何を考えてどんな気持ちなのかなんとなく分かるようなスキルが人よりもありそうということがひょんなことからわかった。自分ではそれが普通だと思っていたのだけど、意外に人はそこまで敏感ではないということに気づいた。チームのリーダーもそのあたりを見込まれて選ばれたのかもしれない。その点も強みとしていけたらよいと思う。

短所として、中長期的な観点で考えて道筋を立てていくことが得意ではない。個人的なことでも、仕事においてもそうである。入社する前まではとにかくWEBの会社に入るというのを目標にしてきてそれに向かっていたが、それが実現してからの3年間特に目標もなく進んでいたように思う。立場的にも中長期的な観点でかつ広い視点で見なければならないようになりつつあるので大きな課題である。

所感

3年間やってきて、本当にやっと最近になって自分のやっていることが売上に直結したりチームにものすごく役に立つものであったりすることが増えてきたように思う。エンジニアは様々な問題を解決する職種であるというところから、問題の重要度&緊急度に対してのコストのかけ方を肌感で掴んできたからだと考えている。まだまだやることは膨大にあるし一つ一つクリアしていきながら自分自身をレベルアップさせていきたい。またこの先エンジニアとしてどうなりたいのか、そもそもなぜエンジニアをやっているのか、エンジニアとしてこれからもやっていきたいのかというところからもう一度見直しながら残り半年過ごしていきたい。