出典について
この記事はThe Percona Performance Blog内のTom Diederich氏によるFacebook’s Simon Martin on semi-synchronous replication(2015/9/4)を翻訳したものです。
Facebookには月間14.9億のアクティブユーザーがおり、世界の最大のMySQLユーザーの1つである。FacebookのMySQLインフラチームのプロダクションエンジニアであるSimon Martinは、スペアのない2台のサーバーから始まって、世界で最大の規模の1つになるまで、キャリアの大部分でMySQLに取組んできた。
SimonはFacebookが取組んできた、準同期レプリケーションを会社の様々なサービスに本格展開してきた際のいくつかの挑戦について、9月22日のPercona Live Amsterdamで紹介する予定である。彼の講演は、"The highs and lows of semi-synchronous replication"という適切なタイトルがついている。私は先日、SimonとPC上でお話をさせていただいた。
我々のやりとりは下部に記すが、まずは読者の皆様に特別に、Percona Liveの登録時に"BlogInterview"のプロモーションコードを入力することによって、登録料が20ユーロ割引になることをご案内しよう。これはご自由に共有して欲しい! :)
Tom: 1台から10台のスケールでは、MySQLはFacebookにとってどのような重要性があるだろうか?どのようにFacebookはMySQLを使っているのだろうか?
Simon: 10台。我々は大部分のリクエストを処理する、メモリのキャッシュレイヤに精通しているが、MySQLは我々のグラフを永続的に保存している。これは全てのプロフィールのデータや、全ての友人、likeとコメント、またそしてイベント、place、その他へのlikeとコメントがMySQLに永続的に保存されることを意味する。
我々はこの役割においてMySQLの3つの機能に依存している。第1に、最終的な保存先としてデーターをロストしない必要があり、InnoDBはこの領域において十分に実証されている。第2に、高可用である必要があり、MySQLとInnoDBは両方とも大変安定しており、冗長性を保つ為にレプリケーションも利用している。
最後に、外部のキャッシュがあるとはいえ、レイテンシーおよびスループットの両面で性能基準を満たす必要があり、MySQLは両者を備えており、読取りトラフィックをレプリケーションを利用して離れた場所のスレーブに分散させることができる。
Tom: 準同期レプリケーションをFacebookで利用する上で何が利点で、そしてそのサイズを配備する上で利用するときに何が課題となっただろうか？
Simon: これは大きな質問で、これについては50分くらい話せるね! 我々はMySQLのマスター、またはマスターを収容しているホストがクラッシュした時のダウンタイムを短縮する為の解決策として準同期レプリケーションを調べ始めた。歴史的にはレプリケーションを運用していて、マスターがクラッシュした場合、選択に迫られる。ダウンタイムを短縮する為に他のスレーブを直ちに昇格させることもできるが、スレーブがマスターから全てのトランザクションを受取ったことを保証することは不可能である。Facebookではユーザーのデータをロストすることはできないので、昇格が必要になる前に必ずマスタを回復させスレーブを再接続させる選択を行う。デメリットとしては、負荷の高いホスト上でのInnoDBのリカバリが遅くなりうることで、ホストが再起動されればさらに遅くなり、何分もダウンすることになる。
現在では我々は準同期レプリケーションを運用しており、これはすくなくとも1つのスレーブがトランザクションを受取ったことを確認するまで、マスターはトランザクションをコミットしないものである。この運用ではマスターがクラッシュした時に、一番最新のデータを持つスレーブは全てのデータを持っているため、SQLスレッドによってバイナリログが適用されれば、クラッシュリカバリを待つことなく安全にマスターに昇格させることが出来る。
しかし、これにも多くの課題がある。第1に、性能の問題があり、トランザクションを実行するのにネットワークを往復する時間が必要となるため、スレーブが近接している必要がある。異なる場所にあるスレーブは、異なる地域(region)にあるものはいうまでもないが、大変遅くなる。
スレーブの可用性にも注意する必要があり、以前はスレーブがマスターに短い間接続されていなくても問題にはならなかったが、準同期レプリケーションではこれは書込みの停止およびコネクションの詰まりにつながる。したがってレプリケーショントポロジーをどのようにするかについて一層気を配る必要がある。99.999%のアップタイムをサービスの目標とする場合、スレーブに同じSLAが要求され、スレーブが利用可能でありコミットが確認できるよう接続されている必要がある。
"webscale"でこれを運用する際にはwebscale自身の要件が発生する。人手を介すものはスケールしないため、我々の他の環境と同様に全てが自動化されている必要がある。我々の自動化は全ての故障に対応し、どんな状況でも介入なしにシステムが復旧する必要がある。SLAを保ち、また、技術者が常に修理しなければいけない事態を抑止する為に、ある特定の日の需要で発生する発生確率がとても低いエッジケースに関しても自動で対処される必要があるのだ。
Tom: 今年のカンファレンスで(自分の講演を除いて)何を一番楽しみにしているのだろうか？
Simon: まだ全部が発表されてないようにみえるが、コミュニティーの状況を確認できるすばらしい機会だ。いつもはキーノートを楽しんでいる。"Binlog Servers at Booking.com"は確実にみる予定で、我々が準同期レプリケーションで行っているのと似た内容のようなので、アイデアを比較してみるつもりだ。MySQL 5.7の講演もどんなクールな新機能がやってくるのかの情報を得るためにみる予定だ！
