2017-04-26 ビザスク x アイリッジ合同勉強会資料 自分たちのサービスの「数字」をモニタリングして、将来に備えた対策をしよう

1. STRICTLY PRIVATE AND CONFIDENTIAL｜© 2016 iRidge, Inc.
「5年前の自分たちに伝えたい」
ユーザー数5,500万人になる前にやっておきたい事

2. 自己紹介
植木 基博
■ 何やってる人
・自社サービス popinfoの責任者
・popinfoチームのリーダー
■ Python歴は
・アイリッジに入ったタイミング から 8年
・美術大学卒 なので、計算機言語科学とかを専攻してない
・プログラム初めて書いたのは小3 Basic, Z80
1

3. popinfoチームの紹介
自社サービス、popinfoの企画、開発、運用
2
大切にしていること / チームの目線
● 良い設計
● 良いコード
● 良いレビュー
● 良い手順
普段から最善を尽くす

4. 3
年前

5. 数字で見る popinfo (ポップインフォ)

6. 数字で見る popinfo
349,053,710 件 .
5,216,056,559 箇所
43 台 .
10 人 . 5

7. 数字で見る popinfo
349,053,710 件 .
.
6

8. 数字で見る popinfo
5,216,056,559 箇所
7

9. 数字で見る popinfo
43 台 .
.
8

10. 9
年前

11. すみません、古すぎてわかりませんでした。
3年前 ってことにさせてください。
10

12. 11
年前

13. 数字で見る popinfo
20,712,048 件 .
699,649,508 箇所
5 台 .
2.5 人 . 12
1
10

14. 数字で見る popinfo
13
2008 2011 2014 2017
こん時

15. 今困っていること
急激に増える配信数に対して、、、
・性能を追いつかせるだけで大変
・インフラ台数も増えだし、管理が大変
・人を増やしても、キャッチアップが大変
▶ こういった問題はすぐに解決できない
14

16. 3年前の自分たちに伝えたいこと
「モニタリング」
そろそろ始めたほうが良いよ。
15

17. STRICTLY PRIVATE AND CONFIDENTIAL
株式会社アイリッジ
どんなの
16

18. どんなの?
17

19. どんなの?
18
直近1時間のシステム利用動向を表示

20. どんなの?
19
指定期間の動向をグラフ表示
月単位、年単位での推移を確認

21. STRICTLY PRIVATE AND CONFIDENTIAL
株式会社アイリッジ
今の課題 (創るにあたる経緯)
20

22. 課題
popinfoでは、今、パフォーマンスに起因する問題が大半。
反省点
・顧客のユースケースを見れていなかった。
⇛いつの間にか、高負荷、高スループットな要求が。。
・エラーではカバーできない (というかエラーではない)
⇛遅延やレイテンシを継続的に計測する必要がある。
▶来年、3年後、5年後を予想する必要!!
▶アプリケーション / サービスの動向をモニタリングが必要!!
21

23. アプリケーション / サービスの何を監視するのか
「アプリケーション / サービスの動向」をモニタリングする
似ているけど違うもの
・システムリソース監視 (CPU,Memory,Disk, I/O, Network… )
・サービスの死活監視 (APIは動いている?)
22

24. アプリケーション / サービスの何を監視するのか
リソース監視、死活監視は別で用意
23
Datadog 、CloudWatchを利用した、リソース、End2Endの監視

25. なぜアプリケーション / サービスの監視をするのか
リソース監視だけではなぜダメなのか?
SLO（Service Level Objective）との関連性が無い。
⇛ 入稿から配信まで 99.995%で10秒以内を目標とする
⇛ API成功率 99.995% を目標とする
・アプリケーションが動作した結果のモニタリングが必要
・CPU利用率80% メモリ利用率 80% とは無関係
・これら指標を、長期的に見続けていく必要がある
24

26. STRICTLY PRIVATE AND CONFIDENTIAL
株式会社アイリッジ
システム構成
25

27. 利用したもの
26
S3 lambda CloudWatch SNS

28. 概要
27
STAGE: Buffer
・とにかく永続化する
STAGE: Routing
・ログ種別ごとに分割
STAGE: Processing
・任意の処理を実行

29. 概要
28
STAGE: Buffer
・とにかく永続化する
役割
このステージではログの保全を第一に考える。各サーバのログを信
頼性の高いS3に入れることでログのロスト等を防ぐ。ログの分類、
加工等は後続の処理に任せる。
要件
ログをロストしないこと
ログ出力から集約されるまでの時間を可能な限り短くすること
ログ基盤の停止をすぐに検知できること
基盤停止からの復旧時に途中から処理を再開できること
構成
fluentd + fluent-plugin-s3

30. 概要
29
STAGE: Routing
・ログ種別ごとに分割
役割
ログの種類やホスト毎に分類し各S3バケットに転送。
バケット毎にログの種類を分類することで、後続の処理で一貫した
処理ができるようにする。
要件
ログ出力から集約されるまでの時間を可能な限り短くすること
極力、転送のみを行い、複雑な処理を持ち込まないこと
構成
lambda (S3 -> S3)

31. 概要
30
役割 (メトリクスの生成)
CloudWatch メトリクスを生成し、中長期的なモニタリングを可能にす
ること。
一定頻度以上で起きるWarningに対し、適切なアラームを運用の中
で設定できるようにする。
構成
lambda (S3 -> CloudWatch Put Metrics)
役割 (エラーメールの送信)
ログレベルがErrorのものは、いち早く通知する。
構成
lambda (S3 -> SNS) (+ lambda (SNS -> Slack))
STAGE: Processing
・任意の処理を実行

32. 概要
31
ちなみに、この2つのバケットは、「サービスログ」と、「その他ログ」
サービスログは、BIツールなどに取り込むようなビジネス側で利用するデータ。
その他ログは、StackTraceなど。これからroutingしていく候補。

33. 数字で見る popinfo
349,053,710 件 .
5,216,056,559 箇所
43 台 .
10 人 .32

34. 運用費
33
$9/month

35. まとめ

36. まとめ
35
● 自分たちのサービスの「数字」をモニタリング
して、将来に備えた対策をしよう

38. We are hiring
37
● Python + AWS Lambda 等、サーバーレスな
開発に興味がある方
● 品質にこだわって、サービス開発をしたい方
● Go言語書きたい人