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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved Teachme Biz のプロダクトとしての特徴 6 #SRELounge ● 業務マニュアル => 業務に必要 => 止められない ● 画像・動画ベースのマニュアル => 画像・動画データ:多 ● 作成したマニュアルをウェブ上で一般公開する機能 => （我々の直接の）顧客企業の顧客が閲覧 => 影響範囲:大 ● マニュアルを実行して欲しい人たちに一斉配信できる機能 => （企業単位で実行される機能なので、）　　小規模ではあるがアクセススパイクが生まれる

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved Teachme Biz におけるSRE チームのミッション 9 #SRELounge ● 設計や運用上のセキュリティリスク低減 ● SLA を守り、顧客の事業的な機会損失の最小化 ● 信頼性（RASIS）・パフォーマンス・スケーラビリティの継続的な向上 ● 自動化（自律化）によるToil の削減 ● SLO やError Budget を意識した運用の実践 ● DevOps, CI/CD, ChatOps などProductivity や開発文化に与する環境整備

Slide 10

Slide 10 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved 10 #devsumiE ミッション達成に向けて直近一年でやったこと運用作業自動化 Monitoring 環境刷新 Infrastructure as Code 化インスタンスの統廃合必要なツール選定と導入アラート再設計運用業務の標準化 DB 移行インスタンスサイズ最適化インフラCI 環境整備全リソースのインスタンスファミリー最新化運用ルール整備中途入社社員向け教育パッチ適用の半自動化セキュリティ情報自動チェックインフラテスト駆動開発 DB テーブル設計見直しクエリ改善

Slide 11

Slide 11 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved 11 #devsumiE 運用作業自動化 Monitoring 環境刷新 Infrastructure as Code 化インスタンスの統廃合必要なツール選定と導入アラート再設計運用業務の標準化 DB 移行インスタンスサイズ最適化インフラCI 環境整備全リソースのインスタンスファミリー最新化運用ルール整備中途入社社員向け教育パッチ適用の半自動化セキュリティ情報自動チェックインフラテスト駆動開発 DB テーブル設計見直しクエリ改善今日は、Google SRE の考え方をどう実践してきたか、我々の具体的な事例をふまえつつ共有します。

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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)

Slide 20

Slide 20 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge サービス状況可視化の実践 20 ● とにかくログ集約 ○ fluentd, Elasticsearch, Kibana ○ 問題発生時、モニタリング結果を見れば疑問が解決する状態が理想 ● 性能ダッシュボード ○ 性能におけるボトルネックを誰もが把握できる状態 ○ また、latency を計測する考え方としてヒストグラム, パーセンタイルの使い分けを意識する

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved ● Slack Channel 通知先を分ける ○ emergency 　( 書き込まれると常に関係者にプッシュ通知 ) ○ info 　( 必要なタイミングで対応 ) ● 通知先の出し分けが容易で、アラート設定が手間でないツール ○ Stackdriver, NewRelic などアラートとチケットを意識した運用設計 25 #SRELounge

Slide 26

Slide 26 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved ● 最終的にどの処理が動いていれば問題ないか？から逆算してヘルスチェック項目の設定 ○ 内部的にどの処理を通るリクエストなのか？の見極め ○ ヘルスチェック対象のURL は雰囲気で決めていないか？ ● Env, Role 単位で、監視項目、閾値条件を微調整その他、実践していること 26 #SRELounge

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved Toil 削減 28 #SRELounge ● ミドルウェア機能拡張で自律化するシステムを目指す ○ 特定条件下でのgraceful restart によるコンピューティングリソースの定期的な自動解放 ● インフラまわりの環境構築＆テスト自動化 ● 必要な情報収集＆アラートの自動化 ○ GitHub's security alerts for vulnerable dependencies ○ OS パッケージに関する情報も

Slide 29

Slide 29 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved 対応優先順位付け 29 #SRELounge ● （参考）SRE 本でも、多少のToil を残すことについて言及されている ● コンピューティングリソース追加で一時的な先延ばしにできないか？ ○ このことを判断するためにも、まずはMonitoring 重要 ○ 雰囲気でスペックアップはただの悪手 ● 自動化によるToil 撲滅はもちろん重要だが、手順書化などのドキュメンテーションを行い、望まない属人化排除を優先すべきシーンもある ○ だって人間だもの。

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Infrastructure as Code の実践 32 ● 約2週間かけて複数種ある全サーバーをAnsible 化、また、同時にインフラテストツールとして、Serverspec 導入 ○ よりソフトウェア開発に近いフローでインフラ改善できるように ○ （余談） Ansible とServerspec のファイル管理共通化のため、　　　　 ansible_spec 導入もした ● さらに、ドキュメントやコード内のコメント、コミットメッセージ含め、すべて英語化

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Infrastructure as Code Repository 英語化の背景 34 ● 海外展開の本格化に伴い、システム運用業務を将来的に海外で行う必要性を見据えた ↑ 可能性ではなく必要性。可能性なら今やらなかった。 ● SRE チームを国外にスケールさせるために現時点で必要なコミュニケーションコスト増と判断

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Performance Working Group ？ 36 ● 株式会社はてなの取り組みを参考にした ○ サービスのレスポンススピードやエラー率などを定期的にグラフでチェックし、問題点があれば、インフラ側・開発側の双方から考えられる原因について共有する場 ● 当面は、性能に関する改善余地がまだまだ大きく、すでに悪いと分かっている箇所を改善するための場として運営

Slide 37

Slide 37 text

Copyright (C) 2018 Studist Corporation. All Rights Reserved #SRELounge Performance Working Group の実践 37 ● 開発部内の横断組織 ● パフォーマンスに関する学習の場としての側面も ○ どこをどうなおせば、早くなるのか？という知見の蓄積 ● アウトプットの単位を月次で区切ることで、改善結果の振り返りを行いやすく、また、社内の利害関係者への報告をしやすい