大規模サービスにおけるシステム構成の変遷
皆さん、メリークリスマス。エウレカCEOの石橋です。
eureka Advent Calendar 2016の24日目を担当します。
23日目は弊社松尾による「pairsのインフラコストを最適化しました」でした。
エウレカでは今年の初めに、pairsのGo言語によるフルスクラッチ版をカットオーバーしました。それに伴いシステム構成も大幅に変化し、カットオーバー後もアップデートを重ねてきました。その結果、2016年初頭（上の画像）と、2016年末（下の画像）で、全く異なるシステム構成に変わりました。
2016年初頭
![2014]()
2016年末
![a01_design]()
今回は年末ということで、今年1年の主なシステム構成の変更点についてまとめました。またそれぞれの変更点にeureka tech blogの関連記事があれば”参考記事”としてリンクをつけています。
Frontend
- Web : PHP + AngularJS → golang（初回のWebページロード時のレンダリングのみ） + AngularJS + TypeScriptでSPA化 参考記事
- iOS : Objective-C + Swift2.0 → Swift3.0 参考記事
- Android : Kotlinの導入 参考記事
Web & App Server
- PHP (apache + mod_php) → golang (Nginx + Go-FCGI / UNIXドメインソケット)
UNIXドメインソケットは速度面を重視した選択です。Webアプリケーションはバックエンドもフロントエンドもフルスクラッチしました。 参考記事
- APIをWebとNativeで完全に一本化し、ドキュメンテーションはJSON Hyper-Schema + prmdで実現しています。 参考記事
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 参考記事
元の3レイヤ構成は、1年半前にキャッシュを保存するディスクの最適化やカーネルパラメータをカリカリにチューニングしたり、HHVM入れたり（でも画像変換の殆どはImageMagickが行うのでHHVMの恩恵を受けれず結局php-fpmにロールバックした）と様々な苦難を乗り越えて構築したシステムだったのですが、Akamai Image Mangerの導入によりあえなく消し去られました。ちなみに当時はAkamai CDNではなくAmazon CloudFrontを使っていました。
Search（pairsのトップ画面であるユーザー一覧表示時の検索処理。サービスの要です）
- RDB + Cacheで頑張る(平均2sec、遅くて10sec) → EC2 on ElasticSearch(平均200msec、遅くて3sec) 参考記事
Analyze
- 自社開発の管理画面 + Amazon Redshift → Redash + Fluentd / Embulk + Google BigQuery / MySQL on EC2 参考記事
逐次連携が必要なデータはFluentdで、バッチ処理で大丈夫なデータはMySQLやDynamoDBから定期的にバッチ処理でGoogle BigQueryに連携しています。
Google BigQueryのパフォーマンスを必要としない分析に使うデータは、MySQL on EC2の分析用スレーブサーバをRedashのバックエンドに設定しています。
RedashはAPIもありますし、Google Apps認証も権限設定も細かにできて、手軽に導入できるので結構おすすめです。
- 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 + New Relic → mackerel / Stackdriver + Amazon S3 参考資料
- Sentry, Runscopeの導入
- 各種通知はSlack + OpsGenie 参考記事
- Fluentd + ElasticSearch + Kibana → 廃止
DevOps
- Deploy : Capistrano → Ansible + Slack (ChatOps化しました)
- Provisioning : Golden AMIから手動で構築 → Terraform + Ansible + ServerSpec 参考記事
- Migration : SQL手動実行 → Kamimai 参考記事
- CI : Circle CI → Travis CI（CircleCI上のサーバのI/Oが遅いので、TravisCIに移行中）
Other
こうして改めてまとめると、大規模サービスの運用と並行しながらとは思えないくらい構成が変化しているな、と思いました。
またその結果として、RASIS・サービスのUI/UX（レスポンスタイムやフレームレート）・開発効率は大幅に向上していますし、インフラのコストも2/3程度に下がりました（参考記事）。
エウレカでは来年も地道な改善と時には大胆なソリューションを実行しプロダクトの改善スピードを加速することで、より多くのお客様に、多くの価値を提供して参りたいと考えています。また、その過程で自分たちもいちビジネスパーソンとして、技術者として成長していきたいと思います。
明日はいよいよ最終日！弊社CTOのkaneshinによる記事をお届けします。お楽しみに！
エウレカでは、一緒に働いていただける方を絶賛募集中です。募集中の職種はこちらからご確認ください！皆様のエントリーをお待ちしております！
皆さん、メリークリスマス。エウレカCEOの石橋です。
eureka Advent Calendar 2016の24日目を担当します。
23日目は弊社松尾による「pairsのインフラコストを最適化しました」でした。
エウレカでは今年の初めに、pairsのGo言語によるフルスクラッチ版をカットオーバーしました。それに伴いシステム構成も大幅に変化し、カットオーバー後もアップデートを重ねてきました。その結果、2016年初頭（上の画像）と、2016年末（下の画像）で、全く異なるシステム構成に変わりました。
2016年初頭
2016年末
今回は年末ということで、今年1年の主なシステム構成の変更点についてまとめました。またそれぞれの変更点にeureka tech blogの関連記事があれば”参考記事”としてリンクをつけています。
Frontend
- Web : PHP + AngularJS → golang（初回のWebページロード時のレンダリングのみ） + AngularJS + TypeScriptでSPA化 参考記事
- iOS : Objective-C + Swift2.0 → Swift3.0 参考記事
- Android : Kotlinの導入 参考記事
Web & App Server
- PHP (apache + mod_php) → golang (Nginx + Go-FCGI / UNIXドメインソケット)
UNIXドメインソケットは速度面を重視した選択です。Webアプリケーションはバックエンドもフロントエンドもフルスクラッチしました。 参考記事 - APIをWebとNativeで完全に一本化し、ドキュメンテーションはJSON Hyper-Schema + prmdで実現しています。 参考記事
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 参考記事
元の3レイヤ構成は、1年半前にキャッシュを保存するディスクの最適化やカーネルパラメータをカリカリにチューニングしたり、HHVM入れたり（でも画像変換の殆どはImageMagickが行うのでHHVMの恩恵を受けれず結局php-fpmにロールバックした）と様々な苦難を乗り越えて構築したシステムだったのですが、Akamai Image Mangerの導入によりあえなく消し去られました。ちなみに当時はAkamai CDNではなくAmazon CloudFrontを使っていました。
Search（pairsのトップ画面であるユーザー一覧表示時の検索処理。サービスの要です）
- RDB + Cacheで頑張る(平均2sec、遅くて10sec) → EC2 on ElasticSearch(平均200msec、遅くて3sec) 参考記事
Analyze
- 自社開発の管理画面 + Amazon Redshift → Redash + Fluentd / Embulk + Google BigQuery / MySQL on EC2 参考記事
逐次連携が必要なデータはFluentdで、バッチ処理で大丈夫なデータはMySQLやDynamoDBから定期的にバッチ処理でGoogle BigQueryに連携しています。
Google BigQueryのパフォーマンスを必要としない分析に使うデータは、MySQL on EC2の分析用スレーブサーバをRedashのバックエンドに設定しています。
RedashはAPIもありますし、Google Apps認証も権限設定も細かにできて、手軽に導入できるので結構おすすめです。 - 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 + New Relic → mackerel / Stackdriver + Amazon S3 参考資料
- Sentry, Runscopeの導入
- 各種通知はSlack + OpsGenie 参考記事
- Fluentd + ElasticSearch + Kibana → 廃止
DevOps
- Deploy : Capistrano → Ansible + Slack (ChatOps化しました)
- Provisioning : Golden AMIから手動で構築 → Terraform + Ansible + ServerSpec 参考記事
- Migration : SQL手動実行 → Kamimai 参考記事
- CI : Circle CI → Travis CI（CircleCI上のサーバのI/Oが遅いので、TravisCIに移行中）
Other
こうして改めてまとめると、大規模サービスの運用と並行しながらとは思えないくらい構成が変化しているな、と思いました。
またその結果として、RASIS・サービスのUI/UX（レスポンスタイムやフレームレート）・開発効率は大幅に向上していますし、インフラのコストも2/3程度に下がりました（参考記事）。
エウレカでは来年も地道な改善と時には大胆なソリューションを実行しプロダクトの改善スピードを加速することで、より多くのお客様に、多くの価値を提供して参りたいと考えています。また、その過程で自分たちもいちビジネスパーソンとして、技術者として成長していきたいと思います。
明日はいよいよ最終日！弊社CTOのkaneshinによる記事をお届けします。お楽しみに！
エウレカでは、一緒に働いていただける方を絶賛募集中です。募集中の職種はこちらからご確認ください！皆様のエントリーをお待ちしております！
