インフラエンジニア不在で120万人のユーザーを支える方法

はじめまして、WEBエンジニアの石橋です。

エウレカではpairs全体の開発責任者としてサーバサイドの開発・管理、インフラの構築・管理を行っています。また、数字やリソースの計画・管理など一部プロデューサー業務も担当しています。

前々職では受託のWEBエンジニアを4年、前職では自社サービスの基幹システムやECシステムのインフラ構築・開発などIT部門の統括、物流・CS部門の統括、自社メディアのプロデューサーとしてマルチタスクな4年間を過ごしていました。

趣味は漫画を読むことです、が最近インフラ周りに時間を取られてなかなか読めていません。。漫画が読めない時間が長く続くと、自分の中の何かのエネルギーがどんどん減っていきいずれは枯渇するような気がしてなりません。1分でも多く漫画を読む為にも、まずはしっかりインフラを整備せねばと今日も仕事に励んでいます。

さて今回は初めての投稿ですので、まずは先日会員が120万人を超えた急成長中のサービス「pairs」をどのようなインフラで支えているのか、その概要をお話したいと思います。

今後は、私や他のエンジニアがpairsのインフラについて掘り下げたブログを書く予定です。

pairsとは

既にご利用してくださっている方もいらっしゃるかもしれませんが、 あまりよく知らない方は、

こちらをご覧いただければ、 雰囲気が掴めるのではないかと思います。

一応、簡単に3行で紹介いたしますと…

  • Facebookプラットフォームを利用した恋愛・婚活マッチングサービスです
  • 日本の他に、台湾でもサービスを展開しています
  • 先日会員数が120万人を突破しました!!(2014年8月現在)
  • よくリニューアルします!

あれ、4行になってしまいましたね。まあ、とにかくよくリニューアルするサービスです。
現状は、PCブラウザ、スマホブラウザ、iOSアプリ、Androidアプリの4種類の環境でサービスを提供しています。またサーバーサイドはPHP、フロントエンドはJavaScript、ネイティブアプリはそれぞれObjective-CとJavaを用いて開発しています。

pairsは海外でも急成長中のOnline Datingサービスの一つで、国内ではこの分野で最大級のサービスに成長しています。これからアジア展開を加速させ、海外の巨大Online Datingサービスである「Zoosk」や「eHarmony」と肩を並べるサービスへ成長させるべく、機能追加、UI/UX改善、マッチングアルゴリズムの改善、サービスの高速化・安定化を光の速さで進めています。

インフラ面で何が大変なのか

pairsのインフラを運用している中で、今までにあまり経験した事の無い難しさを日々感じているので、いくつかピックアップしてご紹介したいと思います。

 

急成長中である事

私がエウレカに入社したのは2013年の7月ですが、それから約1年でDAUが20倍になるほどの急成長を見せているサービスです。常に負荷に耐えうる閾値をウォッチし、その閾値に達する前に対策を行う事が求められます。一瞬たりとも気は抜けません。

サービスの性質上データベースへの負荷が高い事

ユーザー x ユーザーの組み合わせだけデータが溜まるので、データベースへの負荷が高いです。一般的なCGMやWEBメディアが数百万UUと言っているのとはシステムにかかる負荷が異なり、1つの画面遷移で数百のクエリが走るようなシステムの上で、1日数十万人がアクティブに動き回る、まさにデータベース泣かせなサービスです。

また、1回のHTTPリクエストの中にDBのRead/Writeが複雑に絡んでいるので、DBマスタとスレーブのコネクション切り分けも容易ではありません。(この辺りはWEBアプリ側のロジックの課題でもあります。。。)

ビジネスモデル上、サービスダウンは許されない

無料のSNSやWEBメディア、都度課金のECやゲームと異なり、月額課金制のサービスなのでシステムの稼働率が非常に重要になります。(利用規約上は免責ですが)システムが正常に動きその上でユーザーが動き続ける事の対価をいただいているサービスですので、システム落ちてましたごめんなさい、では許されません。 障害対応時のプレッシャーは尋常じゃ無く、恐怖の余り今すぐPCを閉じて全てを忘れてどこか遠い国に行ってしまいたくなる衝動に駆られます。(冗談です。)

そんなシステムですので負荷対策はもちろん、冗長化の面でもいかにSPOFを無くすか、と言う事を強く意識しています。

海外展開もしているのでネットワーク構成が複雑

pairsは台湾に向けてもサービスを展開しており、今後アジア展開を加速させます。 インフラもその事を見込んだ構成になっており、セキュリティを考えて同一VPC内でも別のサブネットとNetwork ACLを設定して運用しています。 ネットワーク構成が複雑になるとオペレーションも複雑になるので、これも大変な事の一つです。

 

そして、何よりこの規模のサービスでpairsが特異なのは、

 

インフラエンジニアがいない事

エウレカには40人近くエンジニアがいますが、インフラエンジニアは1人もいませんし、今までにいたこともありません。
AWSのアドバイザーに相談にのっていただく事はありますが、外注もしていません。 社内のアプリケーションエンジニアが、開発と兼任で運用しています。
だからこそ、多くのユーザーを支えるインフラを出来る限り手間なく管理する為の工夫をしています。

どうやって支えているのか

前述した通りエウレカにはインフラエンジニアがいませんので、pairsのインフラではクラウド時代ならではの便利なサービスをフル活用しています。

まずインフラ構成

pci

 

AWSを使用したベーシックな構成ではありますが、特徴としては、

  • ELBで複数台のWEBサーバへ分散、RDSのリードレプリカで複数台のDBヘ分散する事で負荷を軽減している
  • コンテンツファイル(画像・CSS・JS)はCloudFront経由で配信し負荷を軽減している
  • レコード数の多いテーブル、書き込みの頻度が高いテーブルはDynamoDBを使用することで、DB、特にマスタの負荷を軽減している
  • 2つのAvailability Zoneをまたぐ事でデータセンター全体での障害・災害でもサービス継続ができるようにしている
  • DBマスタはRDSのMulti-AZ配備を行い、DBマスタ単体の障害はもちろん、上述したDC全体での障害・災害にも備えている
  • 1つのVPC内でサブネットをLB、App、DBの3つのレイヤ・日本用とグローバル用で切り分けて、Network ACL、Security Groupを適切に設定する事でセキュリティを確保している

では実際に、各種サービス・ツールをどのように使っているかをご説明します。

AWSの各種サービス

  • ELB:Cross-Zone Load Balancingを使用しています。またSticky Sessionを使ってアプリのセッション管理を行っています。
  • EC2:WEBサーバはCentOS, Apache or nginx, PHP(CodeIgniter)の構成。Apacheはmod_pagespeedを使用してレスポンスタイムの向上を図っています。
  • S3:画像やfluentdに集約されたログを保存しています。
  • CloudFront:CSS/JS/画像のCDNとして使用しています。CSS/JSのoriginはWEBサーバ、画像のoriginは画像変換サーバを指しています。画像変換サーバからはS3に保存している画像を取りに行きます。
  • RDS/MySQL:マスタは緊急対応の初動が遅れる事も考慮してMulti-AZ化しています。またスレーブへのアクセスはAZをまたぐことで発生するレイテンシ対策としてアプリケーション側で同一のAZのスレーブを優先して参照するようにしています。
  • DynamoDB:足あとやユーザーの行動履歴などレコード数が数億を超えるようなデータを格納
  • ElastiCache:MySQLから抽出したデータをキャッシュ
  • SES:メール、プッシュの配信
  • SQS:メール、プッシュのバウンスをキューイングして、PHPでバッチ処理しています。
  • Route53

ログ、分析

  • fluentd:各サーバからログを集約し、S3への保存するタスクとElasticsearchに回すタスクを動かしています。
  • Elasticsearch:アクセスログの解析を行っています。
  • Kibana:アクセスログの解析結果をGUIで表示する優れたツールです。
  • GoogleAnalytics:基本中の基本ですが、かかせません。

デプロイ

  • Capistrano:本番環境のデプロイや、Apacheの再起動などのタスクを登録して使用しています。

監視

  • Zabbix:WEBサーバやログなどユーティリティー系のサーバ、CloudWatchと連携した各種AWSサービスの監視を行っています。
  • New Relic:WEBサーバのリソース監視。PHPやJSのエラー補足、負荷の増減が分かりやすいインタフェースで表示されるので、デプロイ後のモタリングに重宝しています。
  • Crashlytics:ネイティブアプリのクラッシュログ収集

CI/CD

  • Travis CI:GitHubと連携してCIを回しています。
  • AWS OpsWorks:こちらは導入半ばですが、AMIでの管理に限界を感じているので今後本格的に使用していく予定です。

おまけに開発関連

  • Slack:チャットツール デプロイや監視系の通知、コミットの通知は、Slackに飛ぶよう設定されています。
  • JIRA:BTSです。JIRA Agileをプラグインとして入れて、カンバン方式で開発を管理しています。
  • Google Spreadsheet:粒度の荒いタスク管理はこれに限ります。
  • GitHub:Gitリポジトリ管理 ブランチモデルはgit-flowです。
  • Confluence:コンテンツコラボレーションツールで、社内のナレッジベースとして使用しています。
  • TestFlight:iOSのベータテスティング・プラットフォーム。ネイティブアプリのリリース前には必ず社内テストを通します。
  • DeployGate:Androidのベータテスティング・プラットフォーム。同じくリリース前の社内テストに使用しています。

120万人のユーザーを抱えるpairsですが、エウレカはベンチャー企業なので、エンジニアの数は限られています。

  • 社内リソースを考えると出来る限りソフトウェア開発に集中したい。
  • けれどもインフラもある程度自分たちでコントロール可能な状態に置いておきたい。

この相反する要求を満たすために、上記のような構成・体制で開発を行っています。

またエウレカのエンジニアは、ビジネスサイドを理解しマーケティングも自ら行いUI/UXにもこだわり、そうしてつくったサービスを出来る限り多くのユーザーに使ってもらう事で価値をもたらしたいと思っています。そして私たちはそこに共感できる人たちと、一緒に働きたいと思っています。

インフラだけをやるのは何か違うし、サービスの根幹であるインフラが人任せになることで、サービスに対する一人一人の責任が細分化されてしまい、サービスを運営する事が「自分ごと」では無くなってしまう気がしています。

 今後pairsは500万人, 1000万人規模までサービスを拡大していきますが、 サービスが大きくなるとパフォーマンスやコストとの兼ね合いで全てをクラウド任せにするのはどうしても難しくなります。
それでも、より効率的なリソース配分で開発を進めるためにも、サービスに対する責任感を担保しユーザーの皆様に満足いただけるサービスを提供するためにも、エウレカではこれからも積極的に便利なサービスや有効なツールをフル活用してインフラを運用していきます。

最後に

そんなエウレカでは、今はインフラエンジニアだけどアプリケーション開発もゴリゴリやってみたい!と言う方、逆に今はアプリケーション開発しかやっていないけどインフラの事も学びたい!と言う方を積極的に募集しています。 ご応募、お問い合わせはこちらから!お待ちしております!

今回は、第一回ということで、概要のお話でしたが、続けて第二回は弊社エンジニアの森川が「カジュアルなメトリクスデータ計測」と言う題材でpairsの裏側をお見せしちゃいます。