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

1. NewsPicksでのAWS活用法
木下 渉

2. 自己紹介
● 名前： 木下渉
● 入社時期： 2014年8月
● 担当： インフラ／サーバーサイド開発／運用作業
● 前職： 金融系SIer（某メガバンクで炎上はしてません）
● 特技： 泥臭いメンテナンス作業
● 好きなアイドル： 安本彩花（私立恵比寿中学）
● 好きな相撲の取り口： 前みつ取ってからの一気の寄り

3. NewsPicks Hot Topics!!!

4. 登録ユーザー数 149万人突破！
149

5. 経済ニュースプラットフォームへ進化！

6. 100人（以上）のプロのコメント！

7. エンジニアの体制
UI/UXチーム
コンテンツチー
ム
検索チーム
広告／求人
チーム

8. エンジニアの悩み
急速に伸びるユーザー数
どんどん広がる業務範囲
限られたエンジニアリソース

9. そこで・・・

10. 人手のいらないスケーリング

11. APIサーバー
ここのお話

12. NewsPicksのアクセス特徴

13. NewsPicksのアクセス特徴
一斉送信のPUSH通知による急激な負荷

14. 特にアクセスが跳ねるとき・・・
イギリス
EU離脱！

15. 特にアクセスが跳ねるとき・・・
舛添都知事
辞任！

16. 普段のピークの数倍のアクセス
そんなときNewsPicksのエンジニアは・・・

17. 誰も本番ログインなんてしません！

18. インスタンス管理
AutoScalingを利用
動的スケーリング ＋ スケジュールされたスケーリング ＋ 手動スケーリング

19. インスタンス管理
AutoScalingを利用
動的スケーリング ＋ スケジュールされたスケーリング ＋ 手動スケーリング
CPU使用率
監視
定時PUSH
に合わせて
速報PUSH時に
起動
（slack連携）

20. 速報時の対応は全てSlackから
Pushするよー
Slack経由で確認
アクセス数
どうだろ？
今回はアクセス
多そう！
台数 緊急時はSlackから台数変更
プッシュ時のAPI台数に変更

21. Uzabase Meetup#3参照！
http://tech.uzabase.com/

22. 余談：インスタンス管理（その昔）
人力＋crontabを利用
動的スケーリング ＋ スケジュールされたスケーリング ＋ 手動スケーリング
「遅くなってない？」と
言われてから動く
常人には読めない
芸術的なcrontab
AWS Consoleから
インスタンス立ち上げ
＋ELB組み込み
（クリックミスったら死
亡）

23. ３種類のデータベースを使い分け

24. データベース
ここのお話

25. RDS（MySQL）
ユーザーデータ／課金周りのデータなどACIDな特性が求められ
るデータや、マスターデータなどで使用
メリット
● トランザクション管理／一貫性
デメリット
● スケーリングが難しい（特に書き込み）
● データが増えるとカラム追加が大変

26. DynamoDB
記事／Pick／お知らせ（フォロー通知やLIKE通知）などで使用
メリット
● データ量を意識する必要がない
● NoSQLなのでカラム追加自由
デメリット
● 集計／結合などには向かない
● データの一貫性が必要なデータには向かない
● 料金体系が特殊

27. DynamoDB
記事やコメント
※オープンソースのDynamic DynamoDBを利用し、スループッ
トも動的に調整
データの増加による
メンテナンス不要

28. オートスケーリング（もどき）
Dynamic DynamoDBを利用

29. Elasticache（Redis）
メリット
● オンメモリなので読み書きが高速
● zsetを利用した順序の保持や集計が便利
● expire指定によって、一定時間でデータを Expireできる
● pub/sub機能によるメッセージング
デメリット
● トランザクション処理（ MULTI/EXEC程度）
● データの堅牢性（スナップショット /AOFはありますが）
● シングルスレッド

30. 例）タイムライン
● フォローしている人がコメントした時刻順に保持（ Redisの
ソート済みSetを利用）
● 1ユーザーあたりのデータ量が多い／ 1コメントで大量の書
き込みが発生する
⇛ ユーザーごとにCache Clusterを分散

31. 例）ランキング情報
● Redisの集計機能で計算
● 同じデータに大量のアクセス
⇛ リードレプリカを分散して、ピーク時負荷軽減

32. 終わりに

33. インフラエンジニアの心得
タフでなければ生きて行けない。
優しくなれなければ生きている資格がない

34. インフラエンジニアの心得
サービスへの理解がなければ生きて行けない。
安定した基盤を作れなければ生きている資格がない

35. エンジニア募集中！！！