20140807 AWS Startup Tech Meetup
•
16 likes•4,258 views
スタディプラスで使っている AWS 上の worker、画像変換サーバの話
Recommended
More Related Content
Similar to 20140807 AWS Startup Tech Meetup
Similar to 20140807 AWS Startup Tech Meetup (12)
More from akitsukada
More from akitsukada (20)
20140807 AWS Startup Tech Meetup
- 2. はじめに
- 4. 会社とサービス紹介 スタディプラス株式会社 教育系スタートアップ、 EdTech エンジニア6名デザイナ1名（募集中！） サービス スタディプラス 学習を支援するSNS/プラットフォーム 高校生の 1/4 が利用 ラーニングドラゴン 英単語学習の教材アプリ スタディプラスAPIを利用する モデルケース スタディラウンジ 会員制の有料自習室 はじめに
- 15. Resque を使ってます Resque https://github.com/resque/resque GitHub 製 OSS Rails との親和性大、カンタン、 Webコンソールが気に入った 構成概要 Redis は c3.large を EC2 に立ててます 自分で立てた翌週くらいにElastiCacheが Redisに対応した… worker daemon-spawn で daemon 化 monit でプロセス監視 インスタンスタイプは c1.medium 1台につき10プロセスの worker 振幅10倍のオートスケールな worker とか
- 17. front_worker API サーバがキューイングした job をさばく メール送信 プッシュ通知送信 外部 API 処理 その他リアルタイム性が 求められない処理 ピークタイムは28台・280プロセス、 アイドルタイムは2台・20プロセス 振幅10倍のオートスケールな worker とか
- 18. batch_worker いわゆるバッチ処理も worker でやる。 メールの一斉配信や日次処理など resque-scheduler利用 cron 的に job をキューイングする スケールしやすいようにバッチを設計すると いい感じに 「スケールしやすい」= worker 数を 増やすことでリニアに処理時間が短縮できる といった意味 例：worker 数を2倍に増やすと メール一斉配信の所要時間が半分になる。 わかりやすい！ ピークタイムは20台・200プロセス、 アイドルタイムは1台・10プロセス 振幅10倍のオートスケールな worker とか
- 19. スケールしやすい batch_worker の設計 kicker と processor に分ける kicker resque-scheduler により キューイングされる job を見張り、 並列可能な processor の job を 多数作ってキューイングする processor kicker によって キューイングされる job を見張り、 とにかく次から次へと物量作戦で 処理する 振幅10倍のオートスケールな worker とか
- 20. スケールしやすい batch_worker の設計 振幅10倍のオートスケールな worker とか Resque-scheduler ①kickerのjobを登録 kicker ②kickerの jobを処理 ③processorのjobを たくさん登録 processor ④processorのjobを 物量作戦で処理 processor auto scaling
- 22. front_worker での spot 活用1/2 spot が先にスケールアウトするように 仕向ける 1. spot インスタンスの worker 群と レギュラーインスタンスの worker 群と で Auto Scaling Policy を分ける 2. spot の方がちょっとだけ先にスケール アウトし、ちょっとだけ後でスケールイ ンするようにする 3. spot が優先的に増えていってくれて 大幅にお得に！ もはやスポットで使っている感じではない 振幅10倍のオートスケールな worker とか
- 23. front_worker での spot 活用2/2 spot が買えなくても困らないように作る 仮に spot の価格が高騰して 突然 spot インスタンス群が落ちても… 一時的に job が貯まるだけで、 数分-20分もすればスケールアウトした レギュラーインスタンスの worker 群 が問題なくjobを捌いてくれる もともとリアルタイム性の低い jobなのでまぁ許容できる （ユーザはほぼ気づかない） 振幅10倍のオートスケールな worker とか
- 24. batch_worker での spot 活用 front_worker と同様のことはやっている spot が先にスケールアウトするように仕 向ける spot が買えなくても困らないように作る scheduled action で、大量の job が キューイングされる10分前に大量の spot インスタンスを起動しておく メール一斉配信とか 振幅10倍のオートスケールな worker とか
- 27. spot使用比率まとめ、価格換算 振幅10倍のオートスケールな worker とか 稼働時間（単位:時間） 0 時 1 時 2 時 3 時 4 時 5 時 6 時 7 時 8 時 9 時 10 時 11 時 12 時 13 時 14 時 15 時 16 時 17 時 18 時 19 時 20 時 21 時 22 時 23 時 計 spot 20 10 3 1 1 1 3 5 3 5 5 4 7 7 6 6 7 8 9 12 15 18 20 21 197 res. 4 3 1 1 1 1 1 1 1 1 1 1 3 3 2 2 3 4 4 5 5 5 5 5 63 reg. 2 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 2 2 3 3 3 3 3 25 計 26 14 4 2 2 2 4 6 4 6 6 5 11 11 8 8 11 14 15 20 23 26 28 29 285 課金額（単位:$） 0 時 1 時 2 時 3 時 4 時 5 時 6 時 7 時 8 時 9 時 10 時 11 時 12 時 13 時 14 時 15 時 16 時 17 時 18 時 19 時 20 時 21 時 22 時 23 時 計 spot 0.40 0.20 0.06 0.02 0.02 0.02 0.06 0.10 0.06 0.10 0.10 0.08 0.14 0.14 0.12 0.12 0.14 0.16 0.18 0.24 0.30 0.36 0.40 0.42 3.94 res. 0.20 0.15 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.05 0.15 0.15 0.10 0.10 0.15 0.20 0.20 0.25 0.25 0.25 0.25 0.25 3.09 reg. 0.32 0.16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.16 0.16 0.00 0.00 0.16 0.32 0.32 0.47 0.47 0.47 0.47 0.47 3.95 計 0.91 0.51 0.11 0.07 0.07 0.07 0.11 0.15 0.11 0.15 0.15 0.13 0.45 0.45 0.22 0.22 0.45 0.67 0.69 0.96 1.02 1.08 1.12 1.14 10.98 spot:spot res.=reserved reg.=regular
- 28. worker で困ったりしたところ 突然 worker -> Redis で接続エラー多発 Redis の timeout 設定やulimitにも 問題なし http://d.conma.me/entry/2013/03/21/114044 1aのworkerだけで起きていることが判明 1cは問題なし 原因わからないけどとにかく全workerを1cに振って 回避、気持ち悪い スケールインするときのworkerプロセス後始末 インスタンス terminate 時にworkerをshutdownしたい （何もしないとworking中のjobがworkingのままに…） /etc/rc.d/ に worker_shutdown スクリプトを 配置して対応 振幅10倍のオートスケールな worker とか about 5 hours ago
- 29. worker まとめ 振幅10倍のオートスケールな worker とか オートスケール * spot おいしいです
- 30. サイズ不問の 画像処理とか
- 32. みなさん画像どうしてますか アプリケーション要件として ユーザによって様々なサイズの画像がアッ プロードされる 箇所によって様々な表示サイズを とりうる（サムネイルとか） サイズ不問の画像処理とか
- 34. resizerを自前で作って使っています httpリクエスト時のパラメータによって 任意の画像を任意のサイズで返す。 ElasticBeanstalk 上で稼働する Java アプリ CloudFront - CDN RDS - 元画像のURIを管理 S3 - 画像ファイル置き場 cf. クックパッドさん mod_tofu http://www.slideshare.net/mirakui/ss-8150494 クラスメソッドさん Rudess http://dev.classmethod.jp/cloud/aws/rudess-image- server/ サイズ不問の画像処理とか
- 35. resizerリクエスト例 http://resizer/1?w=50&h=50&m=speed&e=true http://resizer/1?w=512&h=512&m=balanced&e=true http://resizer/1?w=512&h=512&m=ultra_quality {quality} 部分は、利用している ライブラリ imgscalr に依存しているもの。 http://www.thebuzzmedia.com/software/imgscalr-java-image-scaling-library/ ほんとは依存してないほうがいいですね。 サイズ不問の画像処理とか http://resizer/{image_id}?w={width}&h={height} &m={quality}&e={enlargement}
- 36. resizer構成図 サイズ不問の画像処理とか AWS cloud Elastic Beanstalk container bucket with objects Amazon RDS Auto Scaling group Availability Zone Availability Zone Auto Scaling instances instances Elastic Load Balancing download distribution edge location edge location edge location edge location Internet CloudFront users users users users client mobile client client mobile client
- 37. resizer規模感 EC2インスタンス インスタンスタイプ: m1.medium オートスケールで2-8台 画像数 370万枚 リクエスト数 (クライアント側でキャッシュしてるところも大きい) ELB 80/sec @ peak 200万/day 6000万/month CloudFront（最大ヒット率 84%） 450/sec @ peak 1100万/day 3億3100万/month 内 98% はTokyo Region サイズ不問の画像処理とか
- 38. resizerで困ったりしたところ ある月、突然 CloudFront の 請求額が3倍に…！ resizer や CloudFront 弄ってない ユーザ数もreq数も3倍に なんてなってない iOS アプリで 「ユーザ画像サムネイルの画質を向上し てほしい」 という要望に応えたアップデートを かました結果だった 考慮漏れではあったが まぁしゃーなし サイズ不問の画像処理とか
- 41. 最後に 色々言いましたが、 ただいまシステムのフルリプレイスを 推進中であるため全部作り変える予定です。 Scala でスケーラブルなシステムを 作ることに興味がある方、 Swift で E2E テスト書くことに興味がある方 いらっしゃったらお手伝いください＞＜ @akitsukada
- 42. 劇 終 THE END 2014.08.07 @akitsukada