デブサミ2018 で伝えきれなかった 快適なマニュアル作成共有を支えるSite Reliability Engineering

SRE Lounge #2 で話した内容です。スタディストでのSRE の取り組みについてまとめた資料です。

Transcript

1. Copyright (C) 2018 Studist Corporation. All Rights Reserved ＼ デブサミ2018 で伝えきれなかった ／ 快適なマニュアル作成共有を支える Site Reliability Engineering 株式会社スタディスト 北野 勝久 #SRELounge
2. Copyright (C) 2018 Studist Corporation. All Rights Reserved 2 #SRELounge 北野 勝久 : @katsuhisa__
3. Copyright (C) 2018 Studist Corporation. All Rights Reserved 3 #SRELounge
4. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge 4
5. Copyright (C) 2018 Studist Corporation. All Rights Reserved 5 #SRELounge 導入企業社数 （有償契約のみ） 1,800社 ※ 2018/3 現在 一社あたり、 約10万ユーザーも
6. Copyright (C) 2018 Studist Corporation. All Rights Reserved Teachme Biz のプロダクトとしての特徴 6 #SRELounge • 業務マニュアル => 業務に必要 => 止められない • 画像・動画ベースのマニュアル => 画像・動画データ:多 • 作成したマニュアルをウェブ上で一般公開する機能 => （我々の直接の）顧客企業の顧客が閲覧 => 影響範囲:大 • マニュアルを実行して欲しい人たちに一斉配信できる機能 => （企業単位で実行される機能なので、） 　　 小規模ではあるがアクセススパイクが生まれる
7. Copyright (C) 2018 Studist Corporation. All Rights Reserved 7 #devsumiE 自己紹介 B2Bプロダクトらしさと、 B2Cプロダクトっぽさの両面があるサービス 非機能要件の考慮事項：多
8. Copyright (C) 2018 Studist Corporation. All Rights Reserved 8 #devsumiE 自己紹介 スタディスト SRE チーム
9. Copyright (C) 2018 Studist Corporation. All Rights Reserved Teachme Biz におけるSRE チームのミッション 9 #SRELounge • 設計や運用上のセキュリティリスク低減 • SLA を守り、顧客の事業的な機会損失の最小化 • 信頼性（RASIS）・パフォーマンス・スケーラビリティ の継続的な向上 • 自動化（自律化）によるToil の削減 • SLO やError Budget を意識した運用の実践 • DevOps, CI/CD, ChatOps などProductivity や開発文化に与する環境整備
10. Copyright (C) 2018 Studist Corporation. All Rights Reserved 10 #devsumiE ミッション達成に向けて 直近一年でやったこと 運用作業自動化 Monitoring 環境刷新 Infrastructure as Code 化 インスタンスの統廃合 必要なツール選定と導入 アラート再設計 運用業務の標準化 DB 移行 インスタンスサイズ最適化 インフラCI 環境整備 全リソースのインスタンスファミリー最新化 運用ルール整備 中途入社社員向け教育 パッチ適用の半自動化 セキュリティ情報自動チェック インフラテスト駆動開発 DB テーブル設計見直し クエリ改善
11. Copyright (C) 2018 Studist Corporation. All Rights Reserved 11 #devsumiE 運用作業自動化 Monitoring 環境刷新 Infrastructure as Code 化 インスタンスの統廃合 必要なツール選定と導入 アラート再設計 運用業務の標準化 DB 移行 インスタンスサイズ最適化 インフラCI 環境整備 全リソースのインスタンスファミリー最新化 運用ルール整備 中途入社社員向け教育 パッチ適用の半自動化 セキュリティ情報自動チェック インフラテスト駆動開発 DB テーブル設計見直し クエリ改善 今日は、Google SRE の考え方をどう実践してきたか、 我々の具体的な事例をふまえつつ共有します。
12. Copyright (C) 2018 Studist Corporation. All Rights Reserved 12 #SRELounge 自己紹介 〜 Monitoring 〜
13. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Before 13 • 何か問題が起きても、何かが起きているということ以外に 何も分からない • パフォーマンスも改善したいが、何からやったらいいのか分からない • アラートの設計が適切ではなく、 そもそも問題が起きていることを検知するのが困難な場合も
14. Copyright (C) 2018 Studist Corporation. All Rights Reserved 14 #devsumiE 自己紹介 この状況で、みなさんなら何から始めますか？
15. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge ぼくたちのやったこと 15 • 障害検知時の対応早期化を最優先とし、サービス状況可視化から着手 ◦ そのためのログ集約基盤づくり • 次に、適切なアラート再設計をした
16. Copyright (C) 2018 Studist Corporation. All Rights Reserved 16 #devsumiE 自己紹介 サービス状況可視化は The Four Golden Signals を意識
17. Copyright (C) 2018 Studist Corporation. All Rights Reserved 17 #devsumiE 自己紹介 The Four Golden Signals
18. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge The Four Golden Signals 18 The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four. http://landing.google.com/sre/book/chapters/monitoring-distributed-systems.html
19. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge The Four Golden Signals 19 1. latency 2. traffic 3. errors 4. saturation ← How "full" your service is. (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O)
20. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge サービス状況可視化の実践 20 • とにかくログ集約 ◦ fluentd, Elasticsearch, Kibana ◦ 問題発生時、モニタリング結果を見れば 疑問が解決する状態が理想 • 性能ダッシュボード ◦ 性能におけるボトルネックを誰もが把握できる状態 ◦ また、latency を計測する考え方として ヒストグラム, パーセンタイルの使い分けを意識する
21. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge 21
22. Copyright (C) 2018 Studist Corporation. All Rights Reserved 22 #devsumiE 自己紹介 アラート再設計時は アラートとチケットの違い を意識しながら設定
23. Copyright (C) 2018 Studist Corporation. All Rights Reserved 23 #devsumiE 自己紹介 only three kinds of valid monitoring output
24. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge 24 There are alerts, which say a human must take action right now. Something that is happening or about to happen, that a human needs to take action immediately to improve the situation. The second category is tickets. A human needs to take action, but not immediately. You have maybe hours, typically, days, but some human action is required. The third category is logging. No one ever needs to look at this information, but it is available for diagnostic or forensic purposes. The expectation is that no one reads it. What is ‘Site Reliability Engineering’? https://landing.google.com/sre/interview/ben-treynor.html
25. Copyright (C) 2018 Studist Corporation. All Rights Reserved • Slack Channel 通知先を分ける ◦ emergency 　( 書き込まれると常に関係者にプッシュ通知 ) ◦ info 　( 必要なタイミングで対応 ) • 通知先の出し分けが容易で、アラート設定が手間でないツール ◦ Stackdriver, NewRelic など アラートとチケットを意識した運用設計 25 #SRELounge
26. Copyright (C) 2018 Studist Corporation. All Rights Reserved • 最終的にどの処理が動いていれば問題ないか？から逆算して ヘルスチェック項目の設定 ◦ 内部的にどの処理を通るリクエストなのか？の見極め ◦ ヘルスチェック対象のURL は雰囲気で決めていないか？ • Env, Role 単位で、監視項目、閾値条件を微調整 その他、実践していること 26 #SRELounge
27. Copyright (C) 2018 Studist Corporation. All Rights Reserved 27 #SRELounge 自己紹介 〜 Toil 削減 〜
28. Copyright (C) 2018 Studist Corporation. All Rights Reserved Toil 削減 28 #SRELounge • ミドルウェア機能拡張で自律化するシステムを目指す ◦ 特定条件下でのgraceful restart による コンピューティングリソースの定期的な自動解放 • インフラまわりの環境構築＆テスト自動化 • 必要な情報収集＆アラートの自動化 ◦ GitHub's security alerts for vulnerable dependencies ◦ OS パッケージに関する情報も
29. Copyright (C) 2018 Studist Corporation. All Rights Reserved 対応優先順位付け 29 #SRELounge • （参考）SRE 本でも、多少のToil を残すことについて言及されている • コンピューティングリソース追加で一時的な先延ばしにできないか？ ◦ このことを判断するためにも、まずはMonitoring 重要 ◦ 雰囲気でスペックアップはただの悪手 • 自動化によるToil 撲滅はもちろん重要だが、 手順書化などのドキュメンテーションを行い、 望まない属人化排除を優先すべきシーンもある ◦ だって人間だもの。
30. Copyright (C) 2018 Studist Corporation. All Rights Reserved 30 #SRELounge 自己紹介 〜 Infrastructure as Code 〜
31. Copyright (C) 2018 Studist Corporation. All Rights Reserved Before 31 • サーバーは変更作業があるたび、 継ぎ足し継ぎ足しで手動作業を行い、運用されてきた ◦ 過去に他者が行った変更作業を把握できるはずもなく、 サーバー構成管理がブラックボックス化 → 悪い意味で、ゴールデンイメージへの依存が起こっていた #SRELounge
32. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Infrastructure as Code の実践 32 • 約2週間かけて複数種ある全サーバーをAnsible 化、 また、同時にインフラテストツールとして、Serverspec 導入 ◦ よりソフトウェア開発に近いフローでインフラ改善できるように ◦ （余談） Ansible とServerspec のファイル管理共通化のため、 　　　　 ansible_spec 導入もした • さらに、ドキュメントやコード内のコメント、 コミットメッセージ含め、すべて英語化
33. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge 33
34. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Infrastructure as Code Repository 英語化の背景 34 • 海外展開の本格化に伴い、システム運用業務を 将来的に海外で行う必要性を見据えた ↑ 可能性ではなく必要性。可能性なら今やらなかった。 • SRE チームを国外にスケールさせるために 現時点で必要なコミュニケーションコスト増と判断
35. Copyright (C) 2018 Studist Corporation. All Rights Reserved 35 #SRELounge 自己紹介 〜 Performance Working Group 〜
36. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Performance Working Group ？ 36 • 株式会社はてなの取り組みを参考にした ◦ サービスのレスポンススピードやエラー率などを 定期的にグラフでチェックし、問題点があれば、 インフラ側・開発側の双方から 考えられる原因について共有する場 • 当面は、性能に関する改善余地がまだまだ大きく、 すでに悪いと分かっている箇所を改善するための場として運営
37. Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Performance Working Group の実践 37 • 開発部内の横断組織 • パフォーマンスに関する学習の場としての側面も ◦ どこをどうなおせば、早くなるのか？という知見の蓄積 • アウトプットの単位を月次で区切ることで、 改善結果の振り返りを行いやすく、 また、社内の利害関係者への報告をしやすい
38. Copyright (C) 2018 Studist Corporation. All Rights Reserved 38 #devsumiE 自己紹介 まとめ
39. Copyright (C) 2018 Studist Corporation. All Rights Reserved ＼ デブサミ2018 で伝えきれなかった ／ 快適なマニュアル作成共有を支える Site Reliability Engineering 株式会社スタディスト 北野 勝久 #SRELounge
40. Copyright (C) 2018 Studist Corporation. All Rights Reserved ＼今日もまだまだ伝えきれなかった／ ＼ デブサミ2018 で伝えきれなかった ／ 快適なマニュアル作成共有を支える Site Reliability Engineering 株式会社スタディスト 北野 勝久 #SRELounge
41. Copyright (C) 2018 Studist Corporation. All Rights Reserved 41 #devsumiE 自己紹介 : @katsuhisa__ スタディストでは、 いっしょに闘ってくれるエンジニアを常に募集中