Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
NewsPicksでのAWS活用法
木下 渉
自己紹介
● 名前: 木下渉
● 入社時期: 2014年8月
● 担当: インフラ/サーバーサイド開発/運用作業
● 前職: 金融系SIer(某メガバンクで炎上はしてません)
● 特技: 泥臭いメンテナンス作業
● 好きなアイドル: 安本彩花(...
NewsPicks Hot Topics!!!
登録ユーザー数 149万人突破!
149
経済ニュースプラットフォームへ進化!
100人(以上)のプロのコメント!
エンジニアの体制
UI/UXチーム
コンテンツチー
ム
検索チーム
広告/求人
チーム
エンジニアの悩み
急速に伸びるユーザー数
どんどん広がる業務範囲
限られたエンジニアリソース
そこで・・・
人手のいらないスケーリング
APIサーバー
ここのお話
NewsPicksのアクセス特徴
NewsPicksのアクセス特徴
一斉送信のPUSH通知による急激な負荷
特にアクセスが跳ねるとき・・・
イギリス
EU離脱!
特にアクセスが跳ねるとき・・・
舛添都知事
辞任!
普段のピークの数倍のアクセス
そんなときNewsPicksのエンジニアは・・・
誰も本番ログインなんてしません!
インスタンス管理
AutoScalingを利用
動的スケーリング + スケジュールされたスケーリング + 手動スケーリング
インスタンス管理
AutoScalingを利用
動的スケーリング + スケジュールされたスケーリング + 手動スケーリング
CPU使用率
監視
定時PUSH
に合わせて
速報PUSH時に
起動
(slack連携)
速報時の対応は全てSlackから
Pushするよー
Slack経由で確認
アクセス数
どうだろ?
今回はアクセス
多そう!
台数 緊急時はSlackから台数変更
プッシュ時のAPI台数に変更
Uzabase Meetup#3参照!
http://tech.uzabase.com/
余談:インスタンス管理(その昔)
人力+crontabを利用
動的スケーリング + スケジュールされたスケーリング + 手動スケーリング
「遅くなってない?」と
言われてから動く
常人には読めない
芸術的なcrontab
AWS Console...
3種類のデータベースを使い分け
データベース
ここのお話
RDS(MySQL)
ユーザーデータ/課金周りのデータなどACIDな特性が求められ
るデータや、マスターデータなどで使用
メリット
● トランザクション管理/一貫性
デメリット
● スケーリングが難しい(特に書き込み)
● データが増えるとカラ...
DynamoDB
記事/Pick/お知らせ(フォロー通知やLIKE通知)などで使用
メリット
● データ量を意識する必要がない
● NoSQLなのでカラム追加自由
デメリット
● 集計/結合などには向かない
● データの一貫性が必要なデータには...
DynamoDB
記事やコメント
※オープンソースのDynamic DynamoDBを利用し、スループッ
トも動的に調整
データの増加による
メンテナンス不要
オートスケーリング(もどき)
Dynamic DynamoDBを利用
Elasticache(Redis)
メリット
● オンメモリなので読み書きが高速
● zsetを利用した順序の保持や集計が便利
● expire指定によって、一定時間でデータを Expireできる
● pub/sub機能によるメッセージング
...
例)タイムライン
● フォローしている人がコメントした時刻順に保持( Redisの
ソート済みSetを利用)
● 1ユーザーあたりのデータ量が多い/ 1コメントで大量の書
き込みが発生する
⇛ ユーザーごとにCache Clusterを分散
例)ランキング情報
● Redisの集計機能で計算
● 同じデータに大量のアクセス
⇛ リードレプリカを分散して、ピーク時負荷軽減
終わりに
インフラエンジニアの心得
タフでなければ生きて行けない。
優しくなれなければ生きている資格がない
インフラエンジニアの心得
サービスへの理解がなければ生きて行けない。
安定した基盤を作れなければ生きている資格がない
エンジニア募集中!!!
Upcoming SlideShare
Loading in …5
×

NewsPicksでのAWS活用法

4,735 views

Published on

NewsPicksでのAWSを活用したインフラ利用について

Published in: Technology

NewsPicksでのAWS活用法

  1. 1. NewsPicksでのAWS活用法 木下 渉
  2. 2. 自己紹介 ● 名前: 木下渉 ● 入社時期: 2014年8月 ● 担当: インフラ/サーバーサイド開発/運用作業 ● 前職: 金融系SIer(某メガバンクで炎上はしてません) ● 特技: 泥臭いメンテナンス作業 ● 好きなアイドル: 安本彩花(私立恵比寿中学) ● 好きな相撲の取り口: 前みつ取ってからの一気の寄り
  3. 3. NewsPicks Hot Topics!!!
  4. 4. 登録ユーザー数 149万人突破! 149
  5. 5. 経済ニュースプラットフォームへ進化!
  6. 6. 100人(以上)のプロのコメント!
  7. 7. エンジニアの体制 UI/UXチーム コンテンツチー ム 検索チーム 広告/求人 チーム
  8. 8. エンジニアの悩み 急速に伸びるユーザー数 どんどん広がる業務範囲 限られたエンジニアリソース
  9. 9. そこで・・・
  10. 10. 人手のいらないスケーリング
  11. 11. APIサーバー ここのお話
  12. 12. NewsPicksのアクセス特徴
  13. 13. NewsPicksのアクセス特徴 一斉送信のPUSH通知による急激な負荷
  14. 14. 特にアクセスが跳ねるとき・・・ イギリス EU離脱!
  15. 15. 特にアクセスが跳ねるとき・・・ 舛添都知事 辞任!
  16. 16. 普段のピークの数倍のアクセス そんなときNewsPicksのエンジニアは・・・
  17. 17. 誰も本番ログインなんてしません!
  18. 18. インスタンス管理 AutoScalingを利用 動的スケーリング + スケジュールされたスケーリング + 手動スケーリング
  19. 19. インスタンス管理 AutoScalingを利用 動的スケーリング + スケジュールされたスケーリング + 手動スケーリング CPU使用率 監視 定時PUSH に合わせて 速報PUSH時に 起動 (slack連携)
  20. 20. 速報時の対応は全てSlackから Pushするよー Slack経由で確認 アクセス数 どうだろ? 今回はアクセス 多そう! 台数 緊急時はSlackから台数変更 プッシュ時のAPI台数に変更
  21. 21. Uzabase Meetup#3参照! http://tech.uzabase.com/
  22. 22. 余談:インスタンス管理(その昔) 人力+crontabを利用 動的スケーリング + スケジュールされたスケーリング + 手動スケーリング 「遅くなってない?」と 言われてから動く 常人には読めない 芸術的なcrontab AWS Consoleから インスタンス立ち上げ +ELB組み込み (クリックミスったら死 亡)
  23. 23. 3種類のデータベースを使い分け
  24. 24. データベース ここのお話
  25. 25. RDS(MySQL) ユーザーデータ/課金周りのデータなどACIDな特性が求められ るデータや、マスターデータなどで使用 メリット ● トランザクション管理/一貫性 デメリット ● スケーリングが難しい(特に書き込み) ● データが増えるとカラム追加が大変
  26. 26. DynamoDB 記事/Pick/お知らせ(フォロー通知やLIKE通知)などで使用 メリット ● データ量を意識する必要がない ● NoSQLなのでカラム追加自由 デメリット ● 集計/結合などには向かない ● データの一貫性が必要なデータには向かない ● 料金体系が特殊
  27. 27. DynamoDB 記事やコメント ※オープンソースのDynamic DynamoDBを利用し、スループッ トも動的に調整 データの増加による メンテナンス不要
  28. 28. オートスケーリング(もどき) Dynamic DynamoDBを利用
  29. 29. Elasticache(Redis) メリット ● オンメモリなので読み書きが高速 ● zsetを利用した順序の保持や集計が便利 ● expire指定によって、一定時間でデータを Expireできる ● pub/sub機能によるメッセージング デメリット ● トランザクション処理( MULTI/EXEC程度) ● データの堅牢性(スナップショット /AOFはありますが) ● シングルスレッド
  30. 30. 例)タイムライン ● フォローしている人がコメントした時刻順に保持( Redisの ソート済みSetを利用) ● 1ユーザーあたりのデータ量が多い/ 1コメントで大量の書 き込みが発生する ⇛ ユーザーごとにCache Clusterを分散
  31. 31. 例)ランキング情報 ● Redisの集計機能で計算 ● 同じデータに大量のアクセス ⇛ リードレプリカを分散して、ピーク時負荷軽減
  32. 32. 終わりに
  33. 33. インフラエンジニアの心得 タフでなければ生きて行けない。 優しくなれなければ生きている資格がない
  34. 34. インフラエンジニアの心得 サービスへの理解がなければ生きて行けない。 安定した基盤を作れなければ生きている資格がない
  35. 35. エンジニア募集中!!!

×