Okinawa SRE ミートアップ 発表資料 https://java-kuche.doorkeeper.jp/events/92831 ※公開しない方がよさげな内容を一部削ってます

1. の改善事例
Okinawa SRE Meetup
@miyaz697

2. ⾃⼰紹介
名前︓宮⾥ 新司 (@miyaz697)
JAWS-UG沖縄コアメンバー、3児の⽗
所属︓ 千株式会社 ものづくり部
幼稚園・保育園向けの写真販売サービス
を運営しています
SREチームリーダーとして、インフラ運⽤
／改善のお仕事してます
๏ Solutions Architect - Associate
๏SysOps Administrator - Associate

3. まずはじめに
伝えたいこと

4. 🎉祝OkinawaSREコミュニティ誕⽣🎉
SRE同⼠で情報共有／相談したいなー
でも、沖縄にはSREやってる⼈が少ない印象
と、思ってたところに
あります︕︕︕あざます︕︕︕

5. アジェンダ
はいチーズ︕の改善事例を紹介
千JOIN後２年間で実施した内容（SRE的な⼀例）
モニタリング
パフォーマンス
開発環境／CD
注）AWS前提の話です。⽤語の説明などは省きます＾＾︔

6. 改善事例 〜モニタリング〜

7. Elasticsearch-Kibana
woothee
nginxでupstreamからヘッダ連携
Zabbix監視⽅式変更
CloudWatchメトリクス取得にはtrapperを使う
CloudWatchメトリクス⾼速取得ツールGo実装
改善事例 〜モニタリング〜

8. 改善前
必要なときにアクセスログを収集して分析
✓必要な時にすぐに分析できない＆属⼈化
✓アプリエラーをメール＆Slackに通知はしてた
けどリアクティブになってしまう
Elasticsearch-Kibana

9. 改善後
簡単に可視化／分析できるES-Kibana導⼊
wootheeでUserAgentの分類
✓UserAgentを分類してくれるやつ（詳細次ページ
✓fluentdプラグイン[fluent-plugin-woothee]
nginxにAPサーバから情報連携
✓アプリ寄りの情報(例︓userId)をnginxログに出⼒
可視化するとプロアクティブな運⽤ができる︕
Elasticsearch-Kibana

10. wootheeで分類したデータの可視化例
スマホorPC／ブラウザ種類／バージョン／UAで分類
Elasticsearch-Kibana

11. nginxにAP寄り情報を連携（以下例）
AP側で応答ヘッダにX-UserAccountNoをセット
nginxアクセスログ（LTSV）に出⼒
proxy_hide_header/fastcgi_hide_headerでクラ
イアントに返すヘッダから削除
✓利⽤イメージは次ページ
Elasticsearch-Kibana

12. Elasticsearch-Kibana
nginxにAP寄り情報を連携するとできること
アクション別平均応答時間
UU数
CVR
その他多数

13. 改善前
１台のZabbixでインターネット経由で監視
CloudWatchメトリクス取得が負荷⾼い
ZabbixはPull型の監視⽅式なので、監視対象ホ
ストの増加に耐えられない
Zabbix監視⽅式

14. 改善前のZabbixサーバ負荷
LoadAvg(/CPUコア)が常に1〜2の状態
✓2年前 t2.medium(cpu2,mem4G)で35台監視でこの状態。⾼すぎ︕
Zabbix監視⽅式

15. なぜ⾼負荷か︖
CloudWatchメトリクス取得⼿段が⾼コスト
✓get_rds_metric.shスクリプトをメトリクス毎に１分間隔で実⾏し、結
果をDBに保存する。という動作をします。
✓AWSサービスごとに約２０メトリクス取得しており、例えば監視対象イ
ンスタンスが１０ある場合、1分間に200回実⾏することになる。これが
⾼負荷の原因。
Zabbix監視⽅式

16. CloudWatchメトリクス取得イメージ（改善前）
Zabbix監視⽅式
awscli
CloudWatch
ElastiCache
RDSElasticsearch SQS Auto Scaling
EC2
②メトリクスごとに
awscliを実⾏
③CloudWatchから
最新のメトリクスを取得
①Zabbixが１分間隔で
メトリクス数分
スクリプトを実⾏

17. Zabbix側でメトリクス取得プロセスを⼤量⽣成するのはコストが⾼い︕
並列度のコントロールもできないので、急激に負荷があがります︕
改善策としては、「外部チェック(Pull型)」から「Zabbixトラッパー(Push型)」を使
って監視する⽅式に変更した。
• Pull型︓データを取りに⾏き、返ってきた値を登録する（Prometheusもこれ）
• Push型︓データを送りつけて値を登録（Mackerel、Datadogなどはこれ）
問題点
Zabbix監視⽅式
awscli CloudWatch
Pull
awscli CloudWatchPush

18. CloudWatchメトリクス取得イメージ（改善後）
Zabbix監視⽅式
ElastiCache
RDS SQS
Auto Scaling
EC2
Elasticsearch
awscli
①crontab(5分毎)で、
サービス単位で実⾏
③取得した複数メトリクスを
一括でトラッパーアイテムに登録
②監視対象インスタンスを取得し、
必要なメトリクス分ループして取得
CloudWatch

19. CloudWatchメトリクス取得をさらに改善
メトリクス数が増えてきてこのままだと耐えられない
Golangでメトリクス⾼速収集ツールを作った
✓1400メトリクスを8秒で取得
✓t2.smallでCPU使⽤率10%ほど
✓下記をZabbix-Proxyサーバのcrontab設定するだけ
*/5 * * * * /path/to/tool | zabbix_sender -z 127.0.0.1 -T -i - >/dev/null 2>&1
✓Qiita紹介記事︓GoでCloudWatchメトリクスを⾼速に取得
Zabbix監視⽅式

20. 改善後イメージ
Zabbix監視⽅式
CloudWatch
EC2
Server
Proxy
CloudWatch
EC2
Proxy
CloudWatch
EC2
Proxy
CloudWatch
EC2
Proxyがバッファするの
でZabbixサーバ負荷も
分散＼(^o^)／
今の数倍のインスタンス
数でも⼤丈夫、たぶん

21. 改善事例 〜パフォーマンス〜
ここで ⼒尽きました。。orz
➡続きは次回で m(_ _)m
改善事例 〜開発環境／CD〜

22. 弊社の改善事例を紹介しました
みなさんの事例も教えてください
コンテナ/k8s導⼊メリット
オートスケール環境のおすすめな監視⽅法あります︖
SREノウハウを共有してレベルアップしていきましょう︕
チーム内のタスクの振り⽅・進捗管理とか
夜間作業・障害対応など苦労話なども
まとめ

23. ご清聴ありがとうございました