ユーザー数300万！Pairsのインフラの裏側チラ見せします。

この記事はエウレカ Advent Calendar 2015 (Qiita) の14日目の記事になります。

インフラチーム、マネージャーの松尾です。
まだ入社して6ヶ月なのですが今回Pairsフルスクラッチに関わって、
インフラ構成を再構築した話を紹介します。

インフラ構成の再構築がなぜ必要だったか？

以前のインフラ構成では下記のような問題がありました。

• セットアップ がコード化されてないので、いま動いてるサーバのAMIからserver を作るしか新規構築する方法がない。
• そもそも コードがないのでテストも存在しない。
• SPOF が複数存在する為障害が起きた際にすぐにリカバリができない。
• auto scaling に対応していない為突発的な負荷に堪えられない。

これらの問題を解決する為に再構築を行いました。

• infrastructure as code を徹底する。
• serverspec を使ってテストを書く。
• auto scaling に対応する。
• 冗長構成にする。

現在の Pairs のインフラ構成 は下記の図のようになってます。

今回の変更でpublicに出ているサーバを減らしたかった為、Nat Serverを作成して、publicとprivateな環境を分けました。

ここからは今回チューニングしたポイントの一部を紹介します。

web application について

• GOMAXPROCS を設定する。
• エウレカでは1.4を利用しているので、GOMAXPROCSをCPU数に合わせて設定しました。
• Nginx — Go Application間をunix domain socketを使って通信させる。
• Nginx — Go Application 間をTCPで接続した場合、高負荷時の状況においてTCPのリソースが枯渇するといった現象が起こっておりました。
• Nginxでは必ずgzipを有効にする。
• Pairsは台湾でも使われており、台湾ではあまり回線が早くない為server側でコンテンツを圧縮して配信するようにしました。

database について

Pairsフルスクラッチでは、RDS をやめて、MySQL on EC2 にしました。
その理由としては、ブラックボックスになってる箇所を減らしたかったからです。RDSはとても便利なサービスでBackupやFailoverを簡単に設定できます。スタートアップではよく使われており運用の手間がかかりません。ですが突然サーバが高負荷になるような現象が稀に起きており、その際の調査が非常に困難であるという現状がありました。MySQL on EC2 にした事により、BackupやFailoverを自前で実装したりと運用の手間が増えるというデメリットはありましたが問題が起きた際にseverにログインして詳細な調査できる事や、MySQLについても最新のバージョンをすぐに試せるといったメリットがありました。
ここからは簡単にではありますが、MySQL on EC2 のチューニングポイントについて書いていきます。

my.cnf の チューニングポイントをチラ見せします。

設定した箇所は沢山ありますが、全部は載せきれないので一部を紹介する感じです。

• innodb_buffer_pool_size
• 実memory の 6 〜 7割程度
• innodb_file_format,innodb_file_format_max
• 圧縮 table を使いたかったのでBarracudaに変更。
• innodb_io_capacity, innodb_io_capacity_max
• fio で IOPSの値をみながら調整しました。
• innodb_lru_scan_depth
• 一般にinnodb_io_capacityを増やしたら、innodb_lru_scan_depthも増やしたほうがよい。
• innodb_flush_log_at_trx_commit
• デフォルトでは 1 になっている為、2 に変更。

コメントでinnodb_flush_log_at_trx_commit=2にしてる件でコメント頂いてたので追記させていただきます。innodb_flush_log_at_trx_commit=2に設定をすると、OSのクラッシュ時などデータの損失してしまう可能性がある為通常は1を設定するのが良いと思います。今回は一部のslave serverのみ設定しており、slave serverに問題が起きた場合は別serverを用意するという前提で対応しました。設定する際は安全性を考慮して設定するようにお願いします。

file system の チューニングポイントをチラ見せします。

今回file system はxfsにしました。xfsのデフォルトで、barrier機能がonになってる為nobarrierに変更しました。合わせてlazy-countを有効にしてます。(lazy-countはデフォルトで有効だったかも)それ以外でもRAID0にする事でディスクのIO性能をあげました。

上記2つのポイントを変更後、sysbenchでベンチを取った結果、Auroraのデフォルト設定とくらべても2倍以上の性能が出てました。

おわりに

今回はPairsのインフラ再構成の中でも現在の構成と、簡単ではありますがチューニングのポイントについて書かせていただきました。上記には書きませんでしたが、サービスが長く運用していくなかでサービスが大きくなってくると不要なデータが増えていくと思います。不要なデータ削除・及び適切な場所に保存するといった事は必ずやりましょう。
今後のインフラのプランとしては、よりシンプルなserver構成(app server + database server + cache server)を考えてます。なぜいまシンプルな構成にしたいかというと、問題が起きた際の原因調査をスムーズに行う事ができますし、よりスケールしやすい構成を作る事ができると考えてます。こんなインフラを一緒に作ってくれる方がいれば是非連絡ください。