読者です 読者をやめる 読者になる 読者になる

でこてっくろぐ ねお

でこてっくろぐ(http://dekokun.github.io/)から進化しました。でこらいふろぐ(http://dekolife.hatenablog.com/)の姉妹版。デコテックログ(deko tech log)である

はてなに入社して経験したMySQL4系のオンラインでのmaster切り替え

このエントリははてなエンジニアアドベントカレンダー2015の12日目です。

developer.hatenastaff.com

昨日は id:daiksy によるこちらのエントリでした。

daiksy.hatenablog.jp

現在、私は東京のオフィスで働いているのですが、京都のエンジニアと共に仕事をする場面が多いです。しかし、上記エントリに記載されている様々な取り組みのおかげで遠隔地でもかなり働きやすい環境だなというのを感じています。これからもより皆が働きやすい環境になるように私もいろいろと工夫をしていけたらなと思います。

このエントリでは、今年の8月にはてなに入社した私が最近経験したMySQL4系のmaster切り替え手法について説明します。

背景・概要

はてなの運用するWebサービスではデータストアとしてMySQLが使われる場面が多いです。それにより、入社してから私もMySQLのmasterサーバを切り替える必要があるようなメンテナンスを何度か行いました。

masterサーバを切り替えるようなメンテナンスを行う理由としては様々なものが考えられます。例えば

  • サーバのディスク使用量が増えてきておりこのままでは近日ディスク使用量が100%になってしまいサービスが停止してしまう(からディスク容量の多い別のサーバに切り替えよう)
  • サービスの成長に伴いサーバのCPU使用率が高まってきており放っておくとそのうちシステムが高負荷に陥ってサービスに影響が出てしまう(から性能の良い別のサーバに切り替えよう)

などがパッと思いつくのではないでしょうか

もちろん、上に挙げた問題への対策はサーバの切り替え以外にもいろいろ考えられます。ディスク使用量が多ければ、不要なデータを消す、データを圧縮するなどで対処することが可能な場合がありますし、CPU使用率が上がっている場合はインデックスやクエリ、キャッシュ戦略を見直すなどにより対処することが可能な場合もあります。 しかしそれらの手を打ったとしても、どうしてもサーバを切り替える必要が出てくる場合もあります。また、話は変わりますが、サーバを切り替えるためにはサービスを止めてDBへのアクセスがない状態にして切り替えるのが最も安全ではありますが、可能であればサービスを止めない状態のまま切り替えたいですよね。

このエントリでは、MySQLにおいて、サービスを止めずにmasterサーバを手動で別のサーバへ切り替える作業について説明します。

特に、今回ははてなで行われている「MySQL4」系のmaster切り替え手法、その中でもMySQL4系特有の「masterサーバを切り替える際にどのように旧masterのslaveサーバ群を新masterのslaveにするか」に重点を置いて説明していきます。

MySQL5.0が世に出てからもう10年になります。今ではMySQLのバージョンに関する世間の耳目は5.6や5.7、もしくは、MySQLではないですが互換性のあるDBとしてAmazon AuroraやMariaDBに集まっていますね。そんな中では、MySQL4系を運用している人はかなり少ないのではないかと思います。 はてなでも古いバージョンのMySQLは新しいバージョンのMySQLに切り替えていっているところです。しかし、まだ一部でMySQL4系も使われています。先日私ははてなのサービス運用を行っている中で稀にあるMySQL4系のmasterサーバの切り替えを、人生において初めて行いました。そこで行った作業内容が比較的面白い感じでしたので、その内容をお伝えしたいと思いこの記事を書いています。

具体的にどのように面白いと感じたかと言いますと、以下のようなものが挙げられます。

  • 昔の人はこんなことをやったりしたのか、という歴史を体験するような面白さ
  • MySQLの管理関連のツールの充実していないMySQL4系においてツールを使わずに作業することによって、改めてMHAやmk-slave-moveなどのツールが内部で何を行っているのかについて実感することができた
  • こんな職人芸っぽい作業をしたぞ、という自己満足感
    • これは本来はエンジニアとしてはよくない感情ですね。もっと如何に楽するか、職人芸を撲滅するかを考えなくては。とは思うのですが、一方で、「こんな変なことやってやったぜ」のような喜びはやはりあるなぁと思っています

ですので、読む皆様も上記のような気持ちを感じながら読むと、「俺はMySQL4系なんか触ったこともないし触る予定もない」という人も楽しく読むことができるのではないかと思います。

MySQL5系のmasterサーバの切り替えに関しては、最後におまけとしてほんの少しだけ(本当にほんの少しだけですが)載せてありますのでそちらもご参照ください。

前提知識としてのはてなでのMySQLの冗長構成と、本ブログ内での用語

はてなではMySQLのmasterサーバは以下の図にありますように相互レプリケーションによるactive-standby構成で運用されています。以下図では、太い矢印の向きがレプリケーションにおけるbinlogの流れを表しています。また、以下では「active master」が、現在サービスに使用されているmasterサーバを表し、「standby master」が、active masterに障害が起きた際/もしくは手動でサーバを切り替える際の切り替え役として待機しているサーバを表すこととします。

このブログ内で「master切り替え」といった場合は、active masterとstandby masterを切り替える(旧active masterをstandby masterとしてサービスから外し、旧standby masterをactive masterとしてサービスから外す)ことを表します。

f:id:dekokun:20151210232746p:plain

master切り替えのステップ

さて、手動でmaster切り替えを行うためには、以下2つのステップを実行する必要があります。

  1. 旧active masterにぶら下がっているslaveを新active masterにぶら下げる f:id:dekokun:20151211012501p:plain
  2. Webサーバからの接続を旧active masterから新active masterに向ける f:id:dekokun:20151211012629p:plain

"1."がこのエントリの最大のテーマとなっています。 MySQL5系ですと、MHAという便利なツールがあり、そちらに任せてしまえば、設定さえちゃんとしていれば上記"1.", "2."を機械がよしなに実施してくれるので大変ありがたいのですが、MHAはMySQL5.0以上しか対応していません。

"2." については、一般的にはなんらかの形でDB接続に使用されているIPアドレスを旧active masterサーバから新active masterサーバに付け替える、もしくはDB接続の際にDNSを使用して接続先IPを特定している場合はDNSレコードの書き換えによって接続先のIPを変更する、などの方法でWebサーバからのアクセス先を切り替えている場合が多いかと思います。 はてなでもkeepalivedによるIP付与及びgarpの送信や、(AWSであれば)ENIの付け替えによって、Webサーバからの接続に使用しているIPを新active masterに付与することでWebサーバからの接続を新active masterに向けるようにしています。切り替えサーバが別のネットワークに所属している場合はまた別の方法で…などもありますが、こちらにつきましては、MySQL5でも4でも特に行っていることは変わらないです。詳細は割愛させていただきます。

それでは、実際にMySQL4系において"1."で行うべきであることを知るべく、以下で"1."を更に細かいステップに分けていきましょう。

旧active masterにぶら下がっているslaveを新active masterにぶら下げるステップ

MySQLにおいて、MySQL5.6に搭載されるGTIDを使えない場合、slaveを別のmasterに付け替える際は、slaveの現在のbinlogのポジションが新masterではどのポジションに対応するかを把握してそのポジションに対してCHANGE MASTER TOを打つ必要があります。 実際に行う必要があるのは以下です。

  1. active masterの更新をロックする
  2. 切り替え対象の全slave、及び新active masterの、レプリケーションが最後に実行したクエリのactive master上のbinlogのポジション(説明が難しいですね…Exec_Master_Log_Posのことです)がactive masterの現在のbinlogのポジションに到達するのを待つ
  3. 新active masterの現在のbinlogのポジションを把握する
  4. 切り替え対象の全slaveにて、レプリケーションを止めた後に"3."で把握したポジションへCHANGE MASTER TOを使って切り替え、レプリケーションを再開する
  5. active masterの更新ロックを解除する

うーん複雑ですね。ただ複雑であるだけならいいのですが、active masterの更新をロックしているがために、上記を高速で実施する必要があるというのがまた難しいところです。

これらを自動的に行ってくれているMHAのありがたさが身にしみます。

旧active masterにぶら下がっているslaveを新active masterにぶら下げるステップ(更新ロックを行わないver)

私が作業を行った際は上記の手順で行ったのですが、後から更新ロックが不要な手順が存在すると発覚したのでした。。。

まだ私はこの更新ロックを行わない手順ではslaveの切り替えを行ったことはないのですが、参考までにステップを書いておきます。

イデアとしては、上記更新ロックを行う方法では「切り替え対象のslaveの現在のポジションが新active masterのどのポジションに対応するかが分からないために、active masterの更新を止めることで新active masterと切り替え対象のslaveの更新を止めて、現在のslaveのポジションに対しての新active masterのポジションを把握する」という考えだったのですが、更新ロックを行わない方法は、「切り替え対象のslaveのレプリケーションを止め、mysqlbinlogコマンドなどを使用して最後のクエリをbinlogから特定した後に、新active masterのbinlogからそのクエリに対応するクエリのポジションを把握する」という考えです。

  1. 切り替え対象のslaveのレプリケーションを止める
  2. mysqlbinlogコマンドで最後のクエリを特定する
  3. 新active masterにて、上記切り替え対象のslaveの最後のクエリに対応するポジションをmysqlbinlogコマンドから特定する
  4. 上記ポジションに対してCHANGE MASTER TOを使って切り替え、Slaveを再開する

この手順ですと、基本的にslaveは1台ずつ操作していく形になり、更に確実に操作対象のslaveが遅延するために対象のslaveをサービスから外しながら実施する必要がありその分時間はかかりますが、masterサーバの更新を止めずに済むというのは非常に大きいため、なるべくこちらの手順で行ったほうが良さそうでしたね…次回から気をつけます…

手順

では、(更新ロックを行う方の)コマンド等を書いた手順のお披露目です。職人芸が必要となるっぽい感じがしますね。私が実際に行った手順ははてなお手製スクリプトによってもう少しだけ自動化されてはいるのですが、ほぼ以下のとおりです。

前準備

tmux-cssh などを使用し、複数のサーバに同時にコマンドを投げられるような環境を作っておく

active masterの更新をロック

mysql> FLUSH TABLES WITH READ LOCK;

切り替え対象のslaveのExec_Master_Log_Posがactive masterの現在のbinlogのポジションに到達するのを待つ

切り替え対象の全slave、及び新active masterにて以下を打ち、Exec_Master_Log_Posを確認

mysql> SHOW SLAVE STATUS\G

active masterにて以下を打ってPositionを確認

mysql> SHOW MASTER STATUS\G

両者が一致するまで待つ

新active masterの現在のポジションを把握する

新active masterにて

mysql> SHOW MASTER STATUS\G

ここで、FileとPositionからCHANGE MASTER TO構文を構築する

CHANGE MASTER TO master_host='xx.xx.xx.xx', master_user='xxx', master_log_file='xxxxxxxx-bin.xx', master_log_pos=x;

切り替え対象の全slaveにて、レプリケーションを止めた後に"3."で把握したポジションへCHANGE MATER TOを使って切り替え、レプリケーションを再開する

切り替え対象の全slaveにて、以下を実施

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO master_host='xx.xx.xx.xx', master_user='xxx', master_log_file='xxxxxxxx-bin.xx', master_log_pos=x;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G     // slaveがちゃんと動いているか確認

active masterの更新を解除

mysql> UNLOCK TABLES;

重要なのは、上記を出来る限り素早く(可能であれば5秒以内くらいで)行うことです。

はい、大変ですね!ちなみに、上記手順以外でも細かいことをいうと新active masterでFLUSH LOGSを打つことによってCHANGE MASTER TOを事前に用意しておいたりできるようにしたりという小技もあるのですが、まぁだいたい上記のような感じのことを先日行ったという話でした。

練習なども行った後に実際に作業を行ってみると結構さくっとできるようになったのですが、もうあまり行いたくない類の作業ですね。

感想など

「背景・概要」のところにも記載してありますが、このエントリは、「先日行ったMySQL4系のmaster切り替えの手順が面白かったから共有しよう」という思いの元に書かれたもので、実際に皆様のMySQLの運用にはほぼ立たないかと思いますが、楽しんでいただけましたでしょうか。もし他にもMySQL4系の運用を行っている方がいらっしゃいましたらお友達になりたいなぁと思います。

このエントリを書きながら「この作業は自動化しなくてはあかんやつや」という思いを受けもしましたが、そもそもはてなにおいて現在MySQL4系はだいぶ減ってきているため、自動化も大切ですが、とにかくMySQL4系を撲滅することに力を割かなくてはいけないなというのを強く感じました。 また、このような作業を行うとMHAなどの自動化ツールの重要性が改めてよく分かるなというのは感じました。

本題とは関係ない話なのですが、この記事を書くことによって、これまでなんとなくしか分かっていなかったことが明確になり、非常に勉強になったなというのも感じます。私は前職でアプリケーションエンジニアだったのですがはてなでインフラエンジニアになり、知識が足りないところが非常に多いのですが、そんな私こそブログにいろいろ書いていくことで学んでいかなくてはならないということもまた強く思いました。

おまけ MySQL5系におけるmaster切り替え手法

slaveの付け替えにつきましては、上記でも少し単語を出していますがMHA (MySQL5以上対応)を使うのが最も良いのではないでしょうか。

また、MySQL5系のslaveの付け替えについては私はmk-slave-moveというコマンドをいつも使っており皆さんも使うといいと思います。mk-slave-moveはIt was retired because it didn't work consistently.ということでPercona Toolkitに含まれていないのが非常に残念です。なお、このブログを書くまで私は「mk-slave-moveは、内部でSTART SLAVE UNTIL という構文を使用しており、MySQL5以上でないと使えない」と思っていたのですが、START SLAVE UNTIL構文はMySQL4.1.1から対応されているようでして、もしかしたらMySQL4.1.1以降でしたらmk-slave-moveを使うことができるかもしれません。そちらはまだ検証を行ってはいないため、どなたか使ったことのある方などいらっしゃいましたら教えていただけたらと思います。

他にも、上記に少し書きましたようにMySQL 5.6の場合はGTIDを使用しても楽にslaveの付け替えを行うことができるという話は聞いていますが、私はGTIDについては詳しくないので今後の研究課題としておきます。

最後に

はてなでは、様々なversionのミドルウェアを触ることが大好き(だけどなるべく新しいバージョンにしていきたいという思いを持つ)メンバーを募集しています。

hatenacorp.jp

アドベントカレンダーですが、明日はid:hatz48 です!どんな内容になるのか楽しみです!皆様もお楽しみに!!!!

PHP使いとScala使いとPerl使いが集まって #ISUCON 予選敗北した話と雑な決勝内容予想

タイトルの通りで、PHP使いとScala使いとPerl使いが集まって死力を尽くしたのですがISUCONに敗北したのでした。ISUCON当日までの流れと当日の反省点などを記録していきたいと思います。特に技術的内容はない。

 

ついでに、最後に雑な決勝の予想を載せておきました。

 

ブログ書かねばと言いながら延び延びになっていていつのまにかISUCON決勝が明日に迫っていたので慌てて公開。


チームビルディング

かれこれ2年連続PHPでISUCONに出場し、2年連続で「優勝してPHPの優秀さを証明してみせる」と言っては決勝までは進むけれども決勝では惨敗する というのがいつものパターンだった私ですが、今年は夏に、はてなという名前のPHPのピの字もないPerlScalaの会社にインフラ担当として転職しておりまして、「はてなの社員とISUCONに出た場合、PerlScalaになるだろうしPHPの優秀さは示せそうにないのが極めて残念ではあるが、 それはそれとして今年こそ優勝するぞ」と強い意気込みをもって過ごしていたのでした。

そして優勝するために社内のいろいろな人に声をかけつつチームビルディングを行っていたのですがそこで誤算発生。なんと、ISUCON決勝のある10/31は私の大学時代の友人の結婚式の日でありまして、 皆がISUCON決勝を頑張っている中、私ははるか遠く九州まで出掛けていることが発覚したのでした。

流石に決勝に参加できないのは申し訳ないということで当時声をかけていたメンバーには一度チーム解散宣言をしたうえで、「決勝には出られないのですがISUCON予選だけでも出たいです。 誰か一緒に参加していただけませんか」と弱気に社内で呼びかけていたところ、超若手が参加してくれることになりました。彼は社内でScalaを書いており ました。私はPHP使いながらもScalaJVMは学ばなくてはいけないと思っていたので、「よしScalaで予選を戦おう」と決めたのは大変自然な流 れだったのでした。そして、更に「Scalaで戦うのですがScala使いでもScalaを勉強したい人でも、あと1人メンバー募集中です。」と社内で声をかけたところ、若手のホープ新卒2人目、Perl使いが手を挙げてくれまして、無事にISUCON予選には3人チームで参加できることになったのでした。

このような流れで、PHP使いとScala使いとPerl使いが1同に会すというドリームメンバーでISUCONを戦うことになったのでした。

決勝に出られない私がチームを組めたというのは大変ありがたく、嬉しく思った次第で「(私は参加できないけど)若い2人に絶対に決勝を体験してもらいたい」と強く決意した次第でした。

なお、インフラ担当は私であとの2人はアプリケーションエンジニアとなっております。また、前々から「ISUCONで若者潰す」みたいなことを言っていたのですが、超若い2人とチームを組んだことにより平均年齢が劇的に下がったため方針を転換し「おっさん潰す」という感じで頑張ることにしました。

 

なお、1人は京都から参加で残り2人は東京から参加ということで、遠隔でやってました。


チーム名決め


チーム名は大切です。これによって当日のテンションがかなり変わってきます。


scala祭り」「常勝」「殺戮摂理(ラジカルサーカス)」「二重言語(ヒステリックリボルバー)」など色々案を出しましたが、結局参加者各位のIDを混ぜたようなチーム名に落ち着きました。


事前準備


Scalaで行く」と言ったもののインフラ担当の私がJVMの知識が全くないこともあり、必死でJVMの勉強を行いました。具体的には、社内でJVMのインフラを見ている方に「JVM勉強したいんですがいい本ないっすか」と聞いて教えてもらえた「Javaパフォーマンス」をひたすら読んでいました。その結果、JavaGCについては結構詳しくなった感じがしました。

 

O'Reilly Japan - Javaパフォーマンス



また、最初に設定したいカーネルパラメータの値や入れておきたいツールについてまとめたりをしていました。


当日開始前、再度の使用言語決め


私たちはISUCONの2日目に参加したのですが「Twitterを見ている限り、ISUCON1日目のPHP実装は何か変なことがあったっぽい」「ISUCON1日目はNode実装がなかったらしい」という情報を見て、「Web業界ではそこまでメジャーではないScala実装も何かしら問題がある可能性がある、最悪実装自体が存在しない可能性がある」という結論に達し、もしscalaがダメだった場合の使用言語の選定方法を決めることにしたのでした。

そこで再度3人の使用可能言語などを調査したところ、PHP, Scala, Perlの超得意言語の他にも「3人ともJSは書ける」「@stefafafanはPHPを読んだことがある」「goなら3人とも大丈夫?」などという話が出たのですが、結果として、「特に何事もなければScalaでいく」「もしScalaに何かあった場合は@stefafafanがまだ読め、私が超得意なPHPでいく」という結論になったのでした。

今思えばこれが失敗でした。インフラ担当の得意なPHPでそのままいくのではなく、アプリケーションエンジニアが得意な言語に合わせるべきで「ScalaがダメだったらPerlでいく」というのが正解だったなぁと今になっては思います。

 

当日、開始

 

開始して早々「Scala実装では初回のベンチマークは通りません」という話が出てきたため、Scalaはやめて上記決めていた方針通りPHPでいくことに決定しました。

 

アプリケーションエンジニア2人にはコードを読んでもらいつつ私はとにかくアプリケーションを動かすというのに注力しながら頑張っていき、一旦アプリケーションを動かして最初のベンチマークが通ったのでした。めでたかった。

 

当日、その後

 

アクセスログから遅いエンドポイントを特定し、スロークエリログから遅いクエリを特定し、というのを行いながら15時くらいに3位になってめっちゃテンション上がったりしながらも、得点の伸びがそこで止まり、その後は特に何もできず終わったのでした。

 

なお、my.cnfが別の場所にあることに気づかなかったインフラ担当の私は本当に死すべき存在として名前を刻まれるべきでしょう。

 

最後の10分くらいでなぜかベンチマークがfailし始めて、最終的に得点が出ませんでした。謎。

 

反省点

 

上にも記載したのですが、私がインフラ担当だったのに私が一番得意(他の2人はそんなに得意ではない)な言語を選択してしまったというのが最大の失敗で、前半の私のボトルネックっぷりが半端なくその結果様々な場面で問題が発生した感がありました。

 

私のせいで優秀な2人の足を引っ張ってしまったなぁと反省しきり。

 

私がボトルネックになったことで(というかむしろそれによって私がかなりテンパったことで優先度付けが崩壊し)最大にやばかったのが以下2点。

 

my.cnfが別の場所にあるのに気づかなかった

 

ISUCON開始直後、「my.cnfを書き換えてスロークエリログを出そう」となったわけですが、なぜかmy.cnfを書き換えてもログが出ません。あれあれおかしいなと思いながら、set globalでログを出すようになり、その直後に全然別の理由でmysqlが起動しなくなるなど事件がありそのままmy.cnfの件は忘れ去っていまし た。

最後の方で「あ、my.cnfの設定まだしてないじゃん」となりinnodb buffer poolの設定などをしたのですが「あれ、buffer pool増やしたのになんかOSがメモリ使ってないなぁ。DBデータのファイル量的にそんなことはないはずだが…なんかおかしいなぁ」と思いつつ、その後別の何かにまた忙殺されてそのままになっていたのでした。ひどかった…

 

各人の開発環境を作れなかった

 

毎年のように各人の開発環境をサーバ上に別ポートで立ち上げてそこで開発しようと思っていたのですが、どうもGCEでファイアウォール設定をしても動かない。ローカルの開発環境を作るのもPHPはちょっと面倒だなぁという感じで、最終的に、アプリエンジニアの1人はサーバ上のプログラムを直接編集し、もう1人はPHPを書いたことないにも関わらずローカルで適当に書き換えてはpushしてサーバ上で動作を見てみるという感じになり、かなりめちゃくちゃだった。

 

それにもかかわらずでかいパッチをポンと作ってそいつがほぼそのままパッと動かせることができた彼はスゲェなと思った限りでした。

 

良かったこと

 

とにかく、私が決勝に出られない状態にもかかわらずチームを結成できて予選に参加できたことは本当に嬉しかったです。また、同じチームだった若者2人はこの経験によって1年後、ものすごい人材になり来年の弊社の層は更に厚くなりいい感じだなという思い(若者に負けないようにもちろん私も頑張りますとも!)

 

あと、15時くらいにn+1問題解決して突如3位に躍り出たのは普通にテンション上がった。嬉しかった。

 

決勝予想

 

以下のようなナウい感じのワードが飛び交う

 

不必要なマイクロサービス

 

「マイクロサービス」などと言って1台のサーバ内に不必要に複数のdockerコンテナが(もしくは別ポートでHTTPサーバが何台も)立っておりそれぞれがお互いのAPIを叩きまくっている世界観。それらを分解する(マイクロサービスをやめるか、そのまま別サーバへ持っていくか)ところから全てが始まる。

 

ビッグ(?)データ

 

アクセス情報を貯めて最後にそのアクセス情報を集計させる。スループットが上がってベンチマーク中のアクセス数が増えるほど最後の集計でタイムアウトしやすくなる。

 

最初は同期的にログ書き込み及び集計をしているので、fluentd(等)を使って非同期にしたり集計を後でまとめてやるようにしたりすることで飛躍的に点数上昇が見込まれる(…のか…?)、等(出題陣から、やはりfluentdが活躍する何かが出てくるのではないかという予想がある)

 

最後に

 

来年こそは優勝したい(その頃にはPerlもしくはScalaの裏側に習熟しているように頑張ります)

 

というわけで、九州行ってきます!皆さんISUCON決勝頑張って!!!

 

併せて読みたい

 

t-kyt.hatenablog.com

 

stefafafan.hatenablog.com

 

 

YAPC Asia 2015の感想やわからなかったことを調べたことなど #yapcasia

YAPC::Asia Tokyo 2015に参加してきた。

各発表で思うところがあったものをまとめてみる。

なお、以下は対象の発表を聞いたかもしくは発表資料を読んだ人くらいしか理解できない内容です。発表資料を読みましょう。

前夜祭

技術ブログを書くことについて語るときに僕の語ること

「これまで自分が書いたエントリを振り返ってみて、『この方向でいいのだろうか』みたいなのを考える」みたいなの、極めて参考になった。

私も過去のブログを振り返ってみて、「これまではこの方向で楽しかったけど、少なくとも今後はこうじゃないな、じゃあどうなんだろう」という思いに駆られた。

さて、じゃあどうなんだろう。考えなくてはいけない。y_uukiさんのお陰で考えることができて感謝感謝である。圧倒的感謝。

1日目

メリークリスマス!

ホビット指輪物語Perl 6について。

「Perl6はクリスマスに出す予定、ただ、何が起きるかはわからないよね」という話を聞いて以下を思い出した。

Gitのプロジェクトにて、すでに存在するオブジェクトと同じSHA-1を持つコミットをしてしまう可能性があるという不安に対して、

それよりも「あなたの所属する開発チームの全メンバーが、同じ夜にそれぞれまったく無関係の事件で全員オオカミに殺されてしまう」可能性のほうがよっぽど高いことでしょう。

参照:Git - リビジョンの選択

あと、指輪物語は映画で観ていたけどホビットは映画も観てなければ小説も読んでないので、どっちかで中身を知っておかなくてはいけないなと思った。

世界展開する大規模ウェブサービスのデプロイを支える技術

Miiverseのデプロイについて。

以前、Mamiyaを見て、「これが新しいデプロイの形…!!!」という感動を覚えたものだったが、同じコンセプトで、fujiwara/stretcher · GitHub というのも作られたんですね。知らなかった。

「なんかよくわからない事態になっても、消してから再度pushすれば普通に動くようになっている」みたいな話があって、そういう、状態を他からもらってくることによって簡単に復旧できるような環境にできているのはとてもよいですねという感じだった。

Consulと自作OSSを活用した100台規模のWebサービス運用

このYAPCではよくConsulの話を聞いたが、一時期よく聞いていたSerfはどうなったのかなという感じがある。

Serfはもう当たり前のものになったか、機能がある程度似ているConsulに皆の注目を奪われてSerfはあまり使われなくなったのかどちらかなのであろう。

というか、私自身ConsulとSerfの違いをそこまでよく知っているわけではない(「SerfにKVSとか高機能なヘルスチェックがついたのがConsulでしょ」くらいのイメージ)のでConsul vs. Serf - Consul by HashiCorpを読んでみた。

「SerfにKVSとか高機能なヘルスチェックがついたのがConsulでしょ」以外に以下のような感じらしい

  • 両方ともゴシッププロトコルで情報伝播
  • ConsulのほうがWANを経由してもSerfほど性能が落ちないらしい
  • CAP定理でいうと、ConsulはCPでSerfはAPとのこと
    • Consulは中央サーバがquorumを維持できなくなるとオペレーションできなくなるので
  • あと、上記URLには記載がなかったが、Consulはサーバ/クライアント型でSerfは全員が同等というのと、ConsulにはDNS Interfaceがないというのが結構大きいかなと今回の発表を聞いていて思いました

Consul、stale modeで使っていればかなり信頼性高く使っていけそうな気配を感じた

Conway's Law of Distributed Work

リモートワークについて

  • 今、私は東京で京都のメンバーとリモートワークをしているのですが、これからも積極的にチャット上で話していこうと思いました
  • 「オフィスにいれば偶然コミュニケーション出来る機会があるが、リモートではそうではないので積極的に!」という感じですので
  • 私がリモートワークで意識していることは正しかったなぁという感じで安心した

Electron: Building desktop apps with web technologies

esa.io - 趣味から育てたWebサービスで生きていく

  • プロダクトへの強い愛を感じた
  • よく寝るのは極めて大切

2日目

Google Cloud Platformの謎テクノロジーを掘り下げる

BigQueryの100億行のフルスキャン及び正規表現マッチが10秒で結果を返すとか、Nearlineというデータアーカイブサービスは安いにもかかわらずデータロードがかなり早いとか、コンテナをいい感じに配置することでハードの性能をかなり高いレベルで使い切ることができているとかそういう感じで結構面白さは伝わった

全体的に、「これはすげぇぇ!!」もしくは「すごいんだろうけどよくわからん!!!」のオンパレードだった

個人的にはロードバランサのIPアドレスTCP anycastを使用して常に1つだけ(ELBはDNSラウンドロビン)とか「最近はディスクIOが高価なので、コンテナアーカイブ用のNearlineは安くできる」とかの話しが結構面白いよねという感じがした。

我々はどのように冗長化を失敗したのか

これだけ考えて構築したConsulを本番環境で動かせなかったというのは極めて無念だっただろうなぁという思いが強い。「Consulによって最初はDNSラウンドロビンされていたがConsulの冗長性に不安を抱いてhostsも使うようにした結果ラウンドロビンされなくなっていた」とか「Public層からPrivate層への接続が日本を駆け巡っていた」とか「なぜか同じクエリでもえらいスロークエリになる場合があってDBのホストを移行したらなおった」とか、忙しい中だとちゃんと確認せずについついはまりがちな失敗談が、良かった。

LVSなどの枯れた技術を使った冗長性の担保とConsulを使った冗長性の担保があり、「手に馴染んだ道具を使おう」という話だったが、LVSよりもConsulのほうがある程度それ自身の障害に強いなどあり得ると思うが、大丈夫今回手に馴染んだLVSではなくConsulを使って、「Consulのほうがここが強いぜ」みたいなのはあったか」みたいな質問をしたら褒められたのでよかった

答えは、やはり「それ自身の障害への強さだろう」とのことだった。

ソーシャルゲームにおける AWS 移行事例

とにかく「すぐに役に立つぜ!」的な実践的内容が詰まっていてすごかった。便利。

「それまでのデータセンターでの運用だと、プールしているサーバ費用については全車共通費用についていてプロジェクト側の費用が見かけ上安くなっていたが、AWSになって少し高くなった」みたいな話しも極めて重要なところだしそういうのも含めて話されているのがすごく良かった。

HTTP2 時代の Web

私は「理解した 導入する」の層に行きたい!!ある程度理解していたが再度理解を深められた。 「RTTを減らすか、光はこれ以上早くならないのでそもそもRTの回数自体を減らすか」 我々も社内ツールにh2oをリバースプロキシとして導入して検証するくらいはできそうだしやってみたいと思った。

サーバサイドプッシュで、せっかくキャッシュがあっても送りつけるというのはなんとかならんものか…(cookieを使って対処する実装案などがあるという話ではあった)

nginxさんのHTTP/2実装が楽しみ!!

最後に

超面白かった。最近なんかもやもや感あったのが吹っ切れた感じがする。

うぉぉぉぉぉぉ!!!!!