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

Slide 1

Slide 1 text

1年年で1台-‐‑‒>100台まで増やした話或いは各フェーズでの苦労について株式会社Gunosy CTO ⽯石橋雅和 2014 年年 9 ⽉月

Slide 2

Slide 2 text

©Gunosy Inc. こんにちは、Gunosyです 2

Slide 3

Slide 3 text

©Gunosy Inc. 16 突然ですが

Slide 4

Slide 4 text

©Gunosy Inc. Gunosyシステム構成(2012.11) 4

Slide 5

Slide 5 text

©Gunosy Inc. Gunosyシステム構成(2012.12) 5

Slide 6

Slide 6 text

©Gunosy Inc. Gunosyシステム構成(2013.11) 6

Slide 7

Slide 7 text

©Gunosy Inc. 本⽇日の内容過去のシステム構成を振り返りつつ、各フェーズで苦労したポイントなどをシェアさせていただきます 7

Slide 8

Slide 8 text

©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

Slide 9

Slide 9 text

©Gunosy Inc. ぐの史〜～（続き） 2013/09-‐‑‒12 (70台 -‐‑‒> 100台） l ユーザアクション、コメントシステム導⼊入 – ⼀一気に書き込みにあふれたアプリへ l GunosyAds – 広告基盤 l データ分析基盤の強化 – Redshift導⼊入へ 2014/01-‐‑‒ l 割と構成は安定 – SNS MobilePush⽤用テンポラリサーバが多数 9

Slide 10

Slide 10 text

©Gunosy Inc. 2012/11-‐‑‒2012/12 (1台 -‐‑‒> 10台）個⼈人運⽤用時代 l さくらVPSで運⽤用 l ⼀一台ぜんぶ⼊入り l Apache l Rails l MySQL l テスト機兼バックアップサーバは存在した 10 原初Gunosyは⼀一台だった

Slide 11

Slide 11 text

©Gunosy Inc. 2012/11-‐‑‒2012/12 (1台 -‐‑‒> 10台） l シンプルかつ⼤大胆な構成 l AWS移設を機に少しずつちゃんとした構成に 11 原初Gunosyは⼀一台だった

Slide 12

Slide 12 text

©Gunosy Inc. 2012/11-‐‑‒2012/12 (1台 -‐‑‒> 10台） l 2012年年末にAWSに移⾏行行 l アプリがバランサ下で動くか検証しつつまずは Web⼀一台、バッチ⼀一台の構成 l RDSは最初からMultiA Zを採⽤用 12 AWS移⾏行行時（移⾏行行初⽇日）

Slide 13

Slide 13 text

©Gunosy Inc. 2012/11-‐‑‒2012/12 (1台 -‐‑‒> 10台） l 程なくアプリのセッション関連が確認できたので安⼼心のELB導⼊入 l AvailabilityZone複数利利⽤用（但し各ゾーンWe bサーバは2台のギリギリ） l バッチ以外は⼀一旦⽚片ゾーン落落ちてもどうにかなる構成に 13 AWS移⾏行行時（移⾏行行3⽇日後）

Slide 14

Slide 14 text

©Gunosy Inc. 2012/11-‐‑‒2012/12 (1台 -‐‑‒> 10台）まずはAWS移⾏行行とシンプルな障害耐性を実装した l DBの複数ゾーン構成、Webのロードバランサ導⼊入 l 簡単な設定で複数AZに跨り、かつスナップショットが楽に取れるRDSは初期の運⽤用の不不安を低減した当時負荷が⾼高いのはメール送信だった l メールで⾒見見るユーザ >>> Webで⾒見見るユーザ – ⼀一番よく呼ばれたパスはメールからのリダイレクタ l メールからのリダイレクタ呼び出しを凌凌げばよく、かつメールは徐々に届くのであまり問題が無かった 14

Slide 15

Slide 15 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l アプリが安定してきたのでログ収集周りを整理理 l MongoDBのcapped にとりあえずデータを流流し込み、永続はS3に⼀一任 l ついでにバッチプロセス関連も複数ノード構成に 15 AWS移⾏行行時（移⾏行行2週後）

Slide 16

Slide 16 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l 半静的なページ呼び出しが増えてきたのを考慮してRedis導⼊入 l レンダリングしたhtml のキャッシュならびにマイニュース表⽰示時のRD S読み込みを避ける⽤用途 l 割と現状と差のない構成 16 AWS移⾏行行時（移⾏行行3週後）

Slide 17

Slide 17 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l 2013/01/29リリース l リリース後2週間でメール経路路ユーザ数超え l ユーザとの接点が⼀一気に変化 17 iPhoneリリース

Slide 18

Slide 18 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l 負荷の中⼼心がメール -‐‑‒> APIエンドポイントに変化 l 8時丁度度にユーザが押し寄せる l 読まれる記事数も多い l 15分ぐらいずっと重い 18 iPhoneリリース、で露露呈した問題

Slide 19

Slide 19 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l RDS(MySQL)のCPU使⽤用率率率が上昇していた l 各ユーザ向けのデータはRedisでキャッシュしているのに何故？ l 三⽇日三晩悩んだ末、認証時のユーザ取得でMySQLのインデクスが効いてないことが発覚 l SHOW PROCESSLISTだいじ 19 iPhoneリリース、で露露呈した問題

Slide 20

Slide 20 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台） l 処理理がアレだとWebノード数を増やしても基本解決しない l どこがどう重たいのか正しく観察しよう 20 iPhoneリリース、で得た教訓

Slide 21

Slide 21 text

©Gunosy Inc. 2013/01-‐‑‒2013/04（10台 -‐‑‒> 25台）アプリをリリースして l ユーザ増加ペースが圧倒的に上がった l 事前にログ処理理経路路、キャッシュ保持⼿手段等準備できていたのでチューニングに専念念できた負荷の中⼼心がメールでは無くなった l 8時丁度度のスパイクからの数分のAPI呼び出しを捌く l 登録ペースが増えたのでSNS巡回の部分もボトルネックになりがちだった 21

Slide 22

Slide 22 text

©Gunosy Inc. 2013/05-‐‑‒2013/08（25台 -‐‑‒> 70台） l 10~∼70万ユーザ程度度 l ユーザ増加ペースがさらに上昇して如何に最初のマイニュースを効率率率的に届けるかが課題に l ⼣夕刊ローンチで推薦実⾏行行時間の⼤大幅短縮が必要になる 22 ユーザ数増加、⼣夕刊ローンチ

Slide 23

Slide 23 text

©Gunosy Inc. 2013/05-‐‑‒2013/08（25台 -‐‑‒> 70台） l ユーザ増加に伴いパーソナライズ関連のバッチノードが増加 l ELB以下のアプリ層も順調に増加 l ⼀一部静的コンテンツ配信にCloudFrontを採⽤用 l マイニュース⽤用RDSを分離離 23 ユーザ数増加、⼣夕刊ローンチ

Slide 24

Slide 24 text

©Gunosy Inc. 2013/05-‐‑‒2013/08（25台 -‐‑‒> 70台）ユーザ登録ペースが上がって l 初期処理理（SNSアカウントからの興味推定）のデータ取得部分が明らかにボトルネックに l 並列列処理理可能だが増やしすぎるとRateLimitらしきもので弾かれる l エラー内容から⼈人間の操作で台数を増減する謎のノウハウが流流⾏行行⼣夕刊がリリースされて l 従来１⽇日１回だった推薦処理理が2回になった l 3~∼4時間ぐらいかけて⾏行行っていた推薦を1時間以内で終えるようにした(60分ルール) l こちらはプロファイラをつかって重たい部分を⽚片っ端から外す地道な仕事 24

Slide 25

Slide 25 text

©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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©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がより激しいためﬂuent/redisについてはゾーン別に⽴立立てており互いにセカンダリの構成になった 27

Slide 28

Slide 28 text

©Gunosy Inc. 2014/01-‐‑‒（100台 -‐‑‒> 1XX台） l 100万〜～ユーザ l トピック/コンテンツキャッシュの採⽤用により CloudFrontがより活⽤用 l APNS/GCMプッシュを端末に向けて打つようになり MobilePush呼び出し⽤用の⼀一時サーバが増加 28 V4リリース、MobilePush

Slide 29

Slide 29 text

©Gunosy Inc. Recap l いまのとこと構成要素はそんなに変わらずに対処できた l 早めにアーキテクチャを決められたので増やしたいとこを増やす、チューニングする等に専念念できた l  ボリューム増加に対処するパターンを決めるまでが鍵 l Gunosy/Adsともに届けるコンテンツ種類が豊富になっていき、ユーザも増え続ける l 必要に応じて構成は変更更し続けるし、変えてくのもとても楽しい仕事だよ 29