大規模サービスにおけるシステム構成の変遷

皆さん、メリークリスマス。エウレカCEOの石橋です。
eureka Advent Calendar 2016の24日目を担当します。
23日目は弊社松尾による「pairsのインフラコストを最適化しました」でした。

エウレカでは今年の初めに、pairsのGo言語によるフルスクラッチ版をカットオーバーしました。それに伴いシステム構成も大幅に変化し、カットオーバー後もアップデートを重ねてきました。その結果、2016年初頭(上の画像)と、2016年末(下の画像)で、全く異なるシステム構成に変わりました。

2016年初頭
2014

2016年末
a01_design

今回は年末ということで、今年1年の主なシステム構成の変更点についてまとめました。またそれぞれの変更点にeureka tech blogの関連記事があれば参考記事としてリンクをつけています。


Frontend

Web & App Server

Cache

  • ElastiCache (memcached) → ElastiCache (Redis)
    memcachedはシンプルで運用もしやすいのですが、レプリケーションとトランザクションのサポート、型の豊富さ、キーの確認しやすさなどの面からRedisに変更しました。

DB

  • Amazon RDS(MySQL) → MySQL on EC2(MHAで可用性担保, Shardingも実施可能な状態にしています)
  • Amazon Auroraを決済マイクロサービスと台湾版のプロダクション環境で導入。今のところ大きなトラブルはありません。

Image Convert & Delivery

  • Akamai CDN / Nginx + proxy_cache / Nginx + php-fpmの3レイヤ構成 → Akamai Image Manger
    参考資料:Akamai Image Mangerを利用してみんな幸せになった話
    元の3レイヤ構成は、1年半前にキャッシュを保存するディスクの最適化やカーネルパラメータをカリカリにチューニングしたり、HHVM入れたり(でも画像変換の殆どはImageMagickが行うのでHHVMの恩恵を受けれず結局php-fpmにロールバックした)と様々な苦難を乗り越えて構築したシステムだったのですが、Akamai Image Mangerの導入によりあえなく消し去られました。ちなみに当時はAkamai CDNではなくAmazon CloudFrontを使っていました。今でもCSSやJSなど画像以外の静的コンテンツの配信はAkamai CDNを利用しています。

Search(pairsのトップ画面であるユーザー一覧表示時の検索処理。サービスの要です)

Analyze

  • 自社開発の管理画面 + Amazon Redshift → Redash + Fluentd / Embulk + Google BigQuery / MySQL on EC2
    逐次連携が必要なデータはFluentdで、非同期で問題の無いデータは定期的にバッチ処理をEmbulkで実行してMySQLやDynamoDBからGoogle BigQueryに同期しています。またGoogle BigQueryのパフォーマンスを必要としない分析に使うデータは、MySQL on EC2の分析用スレーブサーバをRedashのバックエンドに設定しています。
    RedashはAPIもありますし、Google Apps認証も権限設定も細かにできて、手軽に導入できるので結構おすすめです。
    参考記事:社内ツールを駆使してExcelへのレポートを自動化した話pairsでの活用例から学ぶre:dash導入のすゝめ
  • Flurryの導入

Marketing Analyze

  • 効果測定 : Webは自社のトラッキングシステム + NativeAppは各メディアのSDKでCVとCV金額を計測 → Webは自社のトラッキングシステム + NativeAppはAppsFlyerと自社のトラッキングシステムをつなぎ込み
  • レポーティング : Spreadsheetを手動更新 → Spreadsheetを自動更新
    (1) RedashのAPIと連携し、登録及び購入情報をGoogle Apps Scriptで自動更新
    (2) 代理店が更新する広告予算消化シートと連携して自動更新
    日次で自動的に様々な切り口からCPR (Cost Per Reg), LTR (Life Time Revenue)を計測可能に。
    なお、僕たちが所属するUSのMatch Groupには、Facebook APIなどとつなぎ込み広告予算の消化状況を収集し、ETLを通して各サービスの登録及び購入情報を収集することでリアルタイムにCPR/LTRを把握可能な仕組みがあり、現在導入中です。

Watch & Metrix

  • Zabbix → mackerel / Stackdriver + Amazon S3
    参考資料:eureka x mackerel – eureka monitoring solution
  • New Relic → AppNeta TraceView
  • Sentry, Runscopeの導入
    Sentryでアプリケーションのエラーを、RunscopeでAPIの正常性をチェックしています。
  • 各種通知はSlack + OpsGenie
    参考記事:OpsGenieでMackerelのアラートを電話通知
  • Fluentd + ElasticSearch + Kibana → 廃止
    元々はサービスのパフォーマンス測定に使っていましたが、今はAppNeta TraceViewが代替しています。

DevOps

Other

こうして改めてまとめると、大規模サービスの運用と並行しながらとは思えないくらい構成が変化しているな、と思いました。
またその結果として、RASIS・サービスのUI/UX(レスポンスタイムやフレームレート)・開発効率は大幅に向上していますし、インフラのコストも2/3程度に下がりました。
参考記事:pairsのインフラコストを最適化しました

エウレカでは来年も地道な改善と時には大胆なソリューションを実行しプロダクトの改善スピードを加速することで、より多くのお客様に、より多くの価値を提供して参ります。また、その過程で自分たちもいちビジネスパーソンとして、技術者として成長していきたいと思います。

明日はいよいよ最終日!弊社CTOのkaneshinによる記事をお届けします。お楽しみに!

  • このエントリーをはてなブックマークに追加

エウレカでは、一緒に働いていただける方を絶賛募集中です。募集中の職種はこちらからご確認ください!皆様のエントリーをお待ちしております!

Recommend

go vet の shadow を知る

データ分析の誤りを未然に防ぐ! SQL4つの検算テクニック