1年で1台->100台まで増やした話

Transcript

1. 1年年で1台-‐‑‒>100台まで増やした話 或いは各フェーズでの苦労について 株式会社Gunosy  CTO  ⽯石橋雅和 2014  年年  9  ⽉月
2. ©Gunosy Inc. こんにちは、Gunosyです 2
3. ©Gunosy Inc. 16 突然ですが
4. ©Gunosy Inc. Gunosyシステム構成(2012.11) 4
5. ©Gunosy Inc. Gunosyシステム構成(2012.12) 5
6. ©Gunosy Inc. Gunosyシステム構成(2013.11) 6
7. ©Gunosy Inc. 本⽇日の内容 過去のシステム構成を振り返りつつ、各フェーズで苦労した ポイントなどをシェアさせていただきます 7
8. ©Gunosy Inc. ぐの史〜～ 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） l 法⼈人化、AWSへの移設 – 最低限の冗⻑⾧長化、メール送信 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l iPhone版リリース – 負荷の中⼼心がメール送信からAPIエンドポイントへ 2013/05-‐‑‒2013/08（25台  -‐‑‒>  70台） l ユーザ増加、⼣夕刊リリース – 時間内にバッチ処理理を終わらせるチューニングに奔⾛走 8
9. ©Gunosy Inc. ぐの史〜～（続き） 2013/09-‐‑‒12    (70台  -‐‑‒>  100台） l ユーザアクション、コメントシステム導⼊入 – ⼀一気に書き込みにあふれたアプリへ l GunosyAds – 広告基盤 l データ分析基盤の強化 – Redshift導⼊入へ 2014/01-‐‑‒   l 割と構成は安定 – SNS  MobilePush⽤用テンポラリサーバが多数 9
10. ©Gunosy Inc. 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） 個⼈人運⽤用時代 l さくらVPSで運⽤用 l ⼀一台ぜんぶ⼊入り l Apache l Rails l MySQL l テスト機兼バック アップサーバは存 在した 10 原初Gunosyは⼀一台だった
11. ©Gunosy Inc. 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） l シンプルかつ⼤大胆な構成 l AWS移設を機に少しずつちゃ んとした構成に 11 原初Gunosyは⼀一台だった
12. ©Gunosy Inc. 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） l 2012年年末にAWSに移⾏行行 l アプリがバランサ下で 動くか検証しつつまずは Web⼀一台、バッチ⼀一台 の構成 l RDSは最初からMultiA Zを採⽤用 12 AWS移⾏行行時（移⾏行行初⽇日）
13. ©Gunosy Inc. 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） l 程なくアプリのセッシ ョン関連が確認できたの で安⼼心のELB導⼊入 l AvailabilityZone複数 利利⽤用（但し各ゾーンWe bサーバは2台のギリ ギリ） l バッチ以外は⼀一旦⽚片ゾ ーン落落ちてもどうにかな る構成に 13 AWS移⾏行行時（移⾏行行3⽇日後）
14. ©Gunosy Inc. 2012/11-‐‑‒2012/12  (1台  -‐‑‒>  10台） まずはAWS移⾏行行とシンプルな障害耐性を実装した l DBの複数ゾーン構成、Webのロードバランサ導⼊入 l 簡単な設定で複数AZに跨り、かつスナップショットが 楽に取れるRDSは初期の運⽤用の不不安を低減した 当時負荷が⾼高いのはメール送信だった l メールで⾒見見るユーザ  >>>  Webで⾒見見るユーザ – ⼀一番よく呼ばれたパスはメールからのリダイレクタ l メールからのリダイレクタ呼び出しを凌凌げばよく、か つメールは徐々に届くのであまり問題が無かった 14
15. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l アプリが安定してきた のでログ収集周りを整理理 l MongoDBのcapped にとりあえずデータを流流 し込み、永続はS3に⼀一任 l ついでにバッチプロセ ス関連も複数ノード構成に 15 AWS移⾏行行時（移⾏行行2週後）
16. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l 半静的なページ呼び出 しが増えてきたのを考慮し てRedis導⼊入 l レンダリングしたhtml のキャッシュならびにマ イニュース表⽰示時のRD S読み込みを避ける⽤用途 l 割と現状と差のない構成 16 AWS移⾏行行時（移⾏行行3週後）
17. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l 2013/01/29リリース l リリース後2週間でメ ール経路路ユーザ数超え l ユーザとの接点が⼀一気 に変化 17 iPhoneリリース
18. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l 負荷の中⼼心がメール  -‐‑‒>  APIエンドポイントに変化 l 8時丁度度にユーザが押し寄せる l 読まれる記事数も多い l 15分ぐらいずっと重い 18 iPhoneリリース、で露露呈した問題
19. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l RDS(MySQL)のCPU使⽤用率率率が上昇していた l 各ユーザ向けのデータはRedisでキャッシュしているのに何故？ l 三⽇日三晩悩んだ末、認証時のユーザ取得でMySQLのインデクスが 効いてないことが発覚 l SHOW  PROCESSLISTだいじ 19 iPhoneリリース、で露露呈した問題
20. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） l 処理理がアレだとWebノード数を増やしても基本解決しない l どこがどう重たいのか正しく観察しよう 20 iPhoneリリース、で得た教訓
21. ©Gunosy Inc. 2013/01-‐‑‒2013/04（10台  -‐‑‒>  25台） アプリをリリースして l ユーザ増加ペースが圧倒的に上がった l 事前にログ処理理経路路、キャッシュ保持⼿手段等準備でき ていたのでチューニングに専念念できた 負荷の中⼼心がメールでは無くなった l 8時丁度度のスパイクからの数分のAPI呼び出しを捌く l 登録ペースが増えたのでSNS巡回の部分もボトルネッ クになりがちだった 21
22. ©Gunosy Inc. 2013/05-‐‑‒2013/08（25台  -‐‑‒>  70台） l 10~∼70万ユーザ程度度 l ユーザ増加ペースがさら に上昇して如何に最初のマ イニュースを効率率率的に届け るかが課題に l ⼣夕刊ローンチで推薦実⾏行行 時間の⼤大幅短縮が必要になる 22 ユーザ数増加、⼣夕刊ローンチ
23. ©Gunosy Inc. 2013/05-‐‑‒2013/08（25台  -‐‑‒>  70台） l ユーザ増加に伴いパー ソナライズ関連のバッチ ノードが増加 l ELB以下のアプリ層も 順調に増加 l ⼀一部静的コンテンツ配信 にCloudFrontを採⽤用 l マイニュース⽤用RDSを分 離離 23 ユーザ数増加、⼣夕刊ローンチ
24. ©Gunosy Inc. 2013/05-‐‑‒2013/08（25台  -‐‑‒>  70台） ユーザ登録ペースが上がって l 初期処理理（SNSアカウントからの興味推定）のデータ 取得部分が明らかにボトルネックに l 並列列処理理可能だが増やしすぎるとRateLimitらしきも ので弾かれる l エラー内容から⼈人間の操作で台数を増減する謎のノウ ハウが流流⾏行行 ⼣夕刊がリリースされて l 従来１⽇日１回だった推薦処理理が2回になった l 3~∼4時間ぐらいかけて⾏行行っていた推薦を1時間以内で終 えるようにした(60分ルール) l こちらはプロファイラをつかって重たい部分を⽚片っ端 から外す地道な仕事 24
25. ©Gunosy Inc. 2013/05-‐‑‒2013/08（25台  -‐‑‒>  70台） 分析タスクの複雑化 l MongoDBのM/R等使ってやっていた集計処理理が徐々 に重たくなってくる l S3からログを落落としてきて解析するケースが増加 l 分析に使う試験ノード 朝刊⼣夕刊（現マイニュース）⽤用RDSを分離離 l レコード数及び物理理サイズが⼤大きくなってきたため、 メンテナンス等考慮し7⽇日分だけローテーションするこ とにしてアーカイブ⽤用にRDSを分離離 l 当時で7⽇日以前の記事へのアクセスは0.1%未満 l 本体DBを軽くすることでスナップショット等軽くなった 25
26. ©Gunosy Inc. 2013/09-‐‑‒2013/12（25台  -‐‑‒>  70台） l アクション要素が増え RDSを増設 l Adsローンチにて同様 の構成が増える l 100台構成を突破 26 V3リリース、Adsローンチ
27. ©Gunosy Inc. 2013/09-‐‑‒2013/12（70台  -‐‑‒>  100台） Redshiftの導⼊入 l MongoDBのM/R等使ってやっていた集計処理理が徐々 に重たくなってくる l S3からログを落落としてきて解析するケースが増加 l 分析の⼿手法も多彩になってきたためRedshiftを導⼊入 GunosyAdsのローンチ l ELB/App/Redis/Fluentd/S3/Redshift/Batch l Gunosy側とほぼ同様の構成 l IOがより激しいためfluent/redisについてはゾーン別 に⽴立立てており互いにセカンダリの構成になった 27
28. ©Gunosy Inc. 2014/01-‐‑‒（100台  -‐‑‒>  1XX台） l 100万〜～ユーザ l トピック/コンテンツキャ ッシュの採⽤用により CloudFrontがより活⽤用 l APNS/GCMプッシュを端 末に向けて打つようになり MobilePush呼び出し⽤用の ⼀一時サーバが増加 28 V4リリース、MobilePush
29. ©Gunosy Inc. Recap l いまのとこと構成要素はそんなに変わらずに対処できた l 早めにアーキテクチャを決められたので増やしたいと こを増やす、チューニングする等に専念念できた l   ボリューム増加に対処するパターンを決めるまでが鍵 l Gunosy/Adsともに届けるコンテンツ種類が豊富にな っていき、ユーザも増え続ける l 必要に応じて構成は変更更し続けるし、変えてくのもと ても楽しい仕事だよ 29
30. ©Gunosy Inc. おわりに ⼀一年年でダイナミックに構成が変わっていくGunosyは、これ からも構成を（たぶん）変え続けます。 興味があるエンジニアの皆様、お⼒力力をお貸し下さい。 30
31. ©Gunosy Inc. 16 Thank  you
32. ©Gunosy Inc. 16 Q&A