Slide 1
Slide 1 text
\最高のITエンジニアリングを支える/
守り と 攻め の
設計技術とSRE
JULY TECH FESTA 2018/07/29 (日)
北野 勝久 @katsuhisa__
Copyright (C) 2018 Studist Corporation. All Rights Reserved
Slide 2
Slide 2 text
#JTF2018
Slide 3
Slide 3 text
● 北野 勝久 / @katsuhisa__
● SRE @ Studist Corporation
● Organizer of SRE Lounge
/ Rails Developers Meetup
● Developers Summit 登壇 etc.
Slide 4
Slide 4 text
マニュアル作成・共有プラットフォーム
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
JULY TECH FESTA 今年のテーマ
最高のITエンジニアリング
を身につける！
Slide 7
Slide 7 text
ぼくの考えた 最高のITエンジニアリング
最大限ユーザーへの価値提供に
集中できる状態を維持し続ける
Slide 8
Slide 8 text
ユーザーへの価値提供に
集中できない状態
ユーザーへの価値提供に
集中できる状態
Slide 9
Slide 9 text
ユーザーへの価値提供に
集中できない状態
ユーザーへの価値提供に
集中できる状態
減らすための
守りの設計
増やすための
攻めの設計
今日の本題
ユーザーへの価値提供を阻害する要因と
どうやって向き合ったか？をお話します。
Slide 10
Slide 10 text
ユーザーへの価値？
Slide 11
Slide 11 text
ユーザーにとっての価値とは
● ユーザーが価値と感じるもの
● ≠ 社内で価値と感じているもの
Slide 12
Slide 12 text
サービス運営において、
ユーザーへの価値提供を
阻害する要因はたくさんある
Slide 13
Slide 13 text
価値提供を阻害する要因
● 障害対応全般
○ On-Call 対応, 障害未然防止策含む
● 不具合調査
● Toil
Slide 14
Slide 14 text
価値提供を阻害する要因
● 障害対応全般
○ On-Call 対応, 障害未然防止策含む
● 不具合調査
● Toil
サービス運営において
価値があっても、
ユーザーにとっては
価値がない施策
Slide 15
Slide 15 text
どうやって向き合うか
Slide 16
Slide 16 text
原則
● 仕組み・エンジニアリングで問題解決する
● 人間が、がんばって解決しようとしない
Slide 17
Slide 17 text
なぜか？
Slide 18
Slide 18 text
ほっておくと、Ops はサービスの規模に比例する
サービス拡大
↓
Ops お仕事増加
↓
筋肉で解決
Slide 19
Slide 19 text
順調に採用し続けられるのであれば
筋肉戦術も間違いではないと思う
Slide 20
Slide 20 text
でも、2018年現在、
エンジニア採用めっちゃ難しい
● 2017年の インターネット専門職(Webエンジニア含む)の
転職求人倍率は 5.99倍
● 全職種で最高の転職求人倍率
● 前年度からの倍率の伸び率も最高
出典 : https://www.recruitcareer.co.jp/news/20170906.pdf
Slide 21
Slide 21 text
成長するサービスの運営において
筋肉戦術はどこかで必ず行き詰まる
Slide 22
Slide 22 text
Site
Reliability
Engineering
Slide 23
Slide 23 text
SRE ?
● Google の運用チームを率いていた Ben Treynor 提唱
「 SREは、ソフトウェアエンジニアに
運用チームの設計を依頼した時にできあがるもの 」
● class SRE implements DevOps
○ それ以外の役割も担う
○ 「それ以外」の中身は各社で異なる
Slide 24
Slide 24 text
自分の経歴
● 前職
○ インフラ・ミドルウェア エンジニア
■ DB リストアとか、ミドルウェア設定とか、
システム移行とか
● スタディスト入社後
○ ずっとアプリケーション側の開発
■ バグつぶしや新機能開発など
○ その後、運用まわりも徐々に
Slide 25
Slide 25 text
今月頭まではSAML 認証実装のPM
Slide 26
Slide 26 text
しばらくアプリケーション側の開発を
していたこともあり、
「ソフトウェアでシステム運用を良くする」
SRE の考え方はすごくしっくりきた
Slide 27
Slide 27 text
Agenda
● 自己紹介
● 最高のITエンジニアリングとは？
● なぜSRE ？
● 0→1 フェーズ
● 守りの具体事例
● 攻めの具体事例
● まとめ
Slide 28
Slide 28 text
なぜ0→1 フェーズの話をするか？
● 圧倒的に事例がない
○ 世の中の事例を見ていると 0→1 フェーズは存在せず、
100スタートの会社ばかりに見える
● はじめは何もできていない
Slide 29
Slide 29 text
前提
現状を打破するための
効率的な打ち手が分からない
Slide 30
Slide 30 text
当時どうしていたか
● エンジニアリングに注力する！という自己暗示
○ 油断すると、今までの仕事を
うまくやることだけに流されてしまう
● 片っ端から勉強期
○ 他社の構成や運用を徹底的に調べる
■ 週3〜5 勉強会に行く
■ めっちゃ登壇者に質問する
○ 技術書を読みまくる
Slide 31
Slide 31 text
一日の時間をふやす法
もっとも大切な一項目はこうだ。
ほかの人々がすでに学んだことに
耳を傾けよう。
Slide 32
Slide 32 text
他社のつらみを聞いて、
自社はどうするか考える
Slide 33
Slide 33 text
分からないなりに理論を学ぶ
Slide 34
Slide 34 text
いま思えば、
非効率な学習を大量にやった
Slide 35
Slide 35 text
でも、効率か非効率かなんて
後になってみないと分からない
（そもそも当時は効率的だと思っていた）
Slide 36
Slide 36 text
問題とは、望まれた事柄と
認識された事柄の間の相違である
仕入れた情報をもとに
To-Be を妄想する。
Slide 37
Slide 37 text
ぐちゃぐちゃ期にやってよかったこと
● ドキュメンテーション
● インスタンスのスペックアップ
● 使い捨て前提で自動化用のコードを書く
Slide 38
Slide 38 text
ぐちゃぐちゃ期にやってよかったこと
● ドキュメンテーション
● インスタンスのスペックアップ
● 使い捨て前提で自動化用のコードを書く
Slide 39
Slide 39 text
自分の突然死にも備えられる
Slide 40
Slide 40 text
自動化を見据えたドキュメンテーション
Slide 41
Slide 41 text
ふだんの心がけも書いて
頭の中を整理する
Slide 42
Slide 42 text
ぐちゃぐちゃ期にやってよかったこと
● ドキュメンテーション
● インスタンスのスペックアップ
● 使い捨て前提で自動化用のコードを書く
Slide 43
Slide 43 text
スペックを上げれば、
解決することが自明な問題をつぶす
※モニタリング基盤が整っていない段階での
スペック変更は無駄が多くなりがちなので注意
Slide 44
Slide 44 text
ぐちゃぐちゃ期にやってよかったこと
● ドキュメンテーション
● インスタンスのスペックアップ
● 使い捨て前提で自動化用のコードを書く
Slide 45
Slide 45 text
ルーチンを軽減して、
コンテキストスイッチを減らす
目の前の作業に集中できる時間が増える
ただし、適用範囲の見極めに注意
Slide 46
Slide 46 text
適用範囲の見極め？
Slide 47
Slide 47 text
自動化を導入する際には、
仕事の中でも特に機械的な要素を選ぶ
新たに自動化を導入すると、
人間がすべき仕事の全体量は減るが、
残った仕事はむずかしくなる。
これが自動化のパラドックスである。
Slide 48
Slide 48 text
0→1 フェーズ まとめ
● 業務時間と学習時間のバランスを見直す
○ As-Is, To-Be を描くのが遅れると、歪が拡大する
● ドキュメントをこまめに書くのは おすすめ
● 自動化・効率化は適用範囲を見極めて行う
Slide 49
Slide 49 text
Agenda
● 自己紹介
● 最高のITエンジニアリングとは？
● なぜSRE ？
● 0→1 フェーズ
● 守りの具体事例
● 攻めの具体事例
● まとめ
Slide 50
Slide 50 text
サービス運営における『守り』
● ユーザーへの価値提供に集中できない
状態・時間を減らす
● 自分たちの業務の棚卸しを行い、
ペイン（痛みを伴う問題）を
どうすれば減らせるか？を考える
Slide 51
Slide 51 text
ぼくたちのペインだったこと
● 障害時の原因切り分けが高負荷
● 障害予防施策の運用負荷が高い
● 手動変更で運用されてきたサーバーの
中身が分からない
Slide 52
Slide 52 text
やったこと
● Monitoring 基盤を整える
● Self-Healing を実装する
● インフラをコード化する
Slide 53
Slide 53 text
Monitoring 基盤を整える
Slide 54
Slide 54 text
Monitoring の実装
● インスタンスの死活監視
○ CloudWatch
● コンピュータリソース, プロセス監視 / 外形監視
○ Stackdriver
● エラー監視, 性能（レイテンシなど）監視
○ NewRelic
● エラー可視化, 性能可視化
○ fluentd, Elasticsearch, Kibana
Slide 55
Slide 55 text
可視化
Slide 56
Slide 56 text
The Four Golden Signals
● latency
● traffic
● errors
● saturation
○ How full your service is.
http://landing.google.com/sre/book/chapters/monitoring-distributed-systems.html
Slide 57
Slide 57 text
latency を見る際は、
パーセンタイル表示を活用する
Average だと、性能改善の前後比較が分かりづらい
Slide 58
Slide 58 text
性能改善をする際は、
リクエストのレスポンス時間と呼び出し回数を
横並べで表示する
処理速度, 呼び出し回数 どちらも大きいリクエストを
改善すると成果につながりやすい
Slide 59
Slide 59 text
Monitoring Output
Slide 60
Slide 60 text
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 61
Slide 61 text
Monitoring のアウトプット分類
● alerts
○ 見たらすぐに対応しないといけない
● tickets
○ 見たらいつか対応しないといけないが、
急ぎではない
● logging
○ 基本はためておき、性能診断や監査用途
Slide 62
Slide 62 text
アウトプット分類に沿ったアラート設計
● alerts, tickets ごとに通知先を分ける
○ 通知先の出し分けがしやすいツールだとなおよし
■ 通知先を出し分けた上で、
通知方法を変える
○ すぐ対応しなくてよい監視通知が増えると
アラートがオオカミ少年化する
● logging は、データレイクへの格納を基本とする
Slide 63
Slide 63 text
その他
● 最終的にどの処理が動いていれば問題ないか？
から逆算して外形監視項目の設定
○ 内部的にどの処理を通るリクエストか？
● アラートは一度オオカミ少年化してしまうと
モラルハザードが起きるので、初期に微調整大事
● 無駄が可視化され、コストカットも実現
Slide 64
Slide 64 text
インフラコストカットの進め方の話は
またどこかで・・・
Slide 65
Slide 65 text
Self-Healing を実装する
Slide 66
Slide 66 text
2011 年にFacebook Engineering Blog に
投稿された記事
https://www.facebook.com/notes/facebook-engineering/making-facebook-
self-healing/10150275248698920/
Slide 67
Slide 67 text
Self-Healing
● 修復性
● エラーが0になることを目指すわけではなく、
SLO を達成することを目指す
○ とは言え、一つのエラーの裏には、
ユーザーのガッカリ体験があることは、
忘れてはいけない
Slide 68
Slide 68 text
事例
● 特定条件下でのUnicorn の自動再起動
○ メモリ枯渇防止, 回復
○ unicorn-worker-killer
● 非同期処理 worker の数が、特定数を下回ったら
自動復旧する仕組み【WIP】
○ そもそもworker が死なないように
コード側も修正したい・・・
Slide 69
Slide 69 text
システム安定稼働にとっては
すごく効果があるが、
やりすぎには注意
Slide 70
Slide 70 text
自律制御がうまく機能しすぎると
問題を放置しておいてもシステムが安定して、
アプリケーションが適当な作りをしていても
それなりに動くようになり、
問題に気づかないようなコードを書いてしまい、
どんどん品質が落ちていってしまう、
ということになりかねません。
そのため、自律制御は暫定解であって、
本質的な解ではないということを心して
コードを組むというのは大事
Slide 71
Slide 71 text
インフラをコード化する
Slide 72
Slide 72 text
問題だったこと
● Golden AMI 方式で運用していた
○ Golden AMI
■ サービス稼働に必要な
一通りの汎用的な設定を終えた独自マシンイメージ
● が、変更が手動で継ぎ足し長年運用されており、
中身がブラックボックス化していた
● 構成分からないストレス半端ないし、
調べ物にいちいち時間がかかる
Slide 73
Slide 73 text
当時のぼく
「これはBlack AMI では・・・」
Slide 74
Slide 74 text
インフラコード化
● ブラックボックスの排除
● 複数人でインフラを育てることができる
● コードレビューやテストコードなど、
ソフトウェア開発に近いフローで仕事ができる
Slide 75
Slide 75 text
実装
● Ansible + Serverspec + Packer + AWS CodeBuild
○ ローカルでlint を回して、GitHub にプッシュ
○ PR をmerge すると、AWS CodeBuild が動く
○ マシンイメージが自動ビルドされる
Slide 76
Slide 76 text
Serverspec + Ansible
● ソフトウェア開発のリズムで
インフラコードが書ける
● ansible_spec の導入で、
ディレクトリ構成を重複管理するのを防ぐ
Slide 77
Slide 77 text
● Packer だけでプロビジョニングを実装するのは
たいへん
● Ansible はモジュールが洗練されているので、
すごく楽に実装できる
● 良いところどりをしたい
Ansible + Packer
Slide 78
Slide 78 text
ansible provisioner
Slide 79
Slide 79 text
Ansible + Packer の設定
"provisioners": [
{
"type": "ansible",
"playbook_file": "main.yml",
"host_alias": "app",
"user": "sample_user"
}
]
Slide 80
Slide 80 text
AWS CodeBuild + Packer
● ローカルからマシンイメージをビルドするために
AWS のセキュリティポートを開けたくない
● マシンイメージのビルドはそこそこ時間がかかる
○ ローカルで実行完了待ちは、
ストレスたまりがち
● →AWS の上で実行すればどっちも解決
Slide 81
Slide 81 text
AWS DevOps Blog
Slide 82
Slide 82 text
守り まとめ
● Monitoring やSelf-Healing に取り組んだ結果、
直近の月間稼働率は 99.98 % まで改善
● インフラコード化とマシンイメージ作成の自動化で、
パッチ適用などの運用効率化ができた
● 運用効率化に取り組んでいると、
サービス全体の指標 (SLI ) に目が行きがちだけど・・・
Slide 83
Slide 83 text
https://ihara2525.tumblr.com/post/17029509298/%E4%B8%80%E8%A1%8C%E3%81%AE%E3%83%AD%E3%82
%B0%E3%81%AE%E5%90%91%E3%81%93%E3%81%86%E3%81%AB%E3%81%AF%E4%B8%80%E4%BA%BA%
E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%81%8C%E3%81%84%E3%82%8B
アクセスログの一行の200からは、その方を幸せにできたのかどうかは
わかりません。ただ、一行の500の向こうには、確実に、
一つのがっかり体験があるはずです。
大量にあるアクセスの中のたった一つかもしれませんが、
そのエラーが出た瞬間、残念な思いをされる方が、
インターネットのその先に確実にいらっしゃる。
Slide 84
Slide 84 text
Agenda
● 自己紹介
● 最高のITエンジニアリングとは？
● なぜSRE ？
● 0→1 フェーズ
● 守りの具体事例
● 攻めの具体事例
● まとめ
Slide 85
Slide 85 text
サービス運営における『攻め』
● ユーザーへの価値提供に集中できる
状態・時間を増やす
● ≒ 未来の自分たちが困ることを減らす
Slide 86
Slide 86 text
やったこと
● Aurora 移行
● Production Readiness Review
● Postmortem
● Performance Working Group
Slide 87
Slide 87 text
Aurora 移行
Slide 88
Slide 88 text
DB でなにか起きたら
● 限られた運用人数で、
DB 障害時に迅速復旧させることに不安があった
● その頃、DB を暗号化するプロジェクトがあり、
同時にAurora 移行を実現できないか、と考えた
Slide 89
Slide 89 text
Aurora
SQL
Transactions
Caching
SQL
Transactions
Caching
Logging + Storage
Master Replica
メタ情報
参照
書き込み
● レプリカラグが
数十ミリ秒
● データの
複数のコピーを
3つのAZ に保持
● クラッシュ回復を
並列スレッドで
非同期実行
Slide 90
Slide 90 text
Aurora に移行して
● Read-Only DB 積極活用への不安が減った
● 可用性向上
● 勝手に
はやくなった
DB 移行前 DB 移行後
Slide 91
Slide 91 text
詳しくは以下の論文がおすすめ
『Amazon Aurora: Design Considerations
for High Throughput Cloud-Native Relational Databases』
（ http://dl.acm.org/citation.cfm?id=3056101 ）
Slide 92
Slide 92 text
Production Readiness Review
Slide 93
Slide 93 text
Production Readiness Review
● リリース前に信頼性に関するレビューを行う
● 大きな機能開発の場合は、
設計の部分からお手伝いする
● 完璧なレビューができなくとも、
リリース前に変更差分を知るだけで、不安が減る
Slide 94
Slide 94 text
https://landing.google.com/sre/book/chapters/evolving-sre-engagement-model.html
The PRR Model
Slide 95
Slide 95 text
Postmortem
Slide 96
Slide 96 text
Postmortem
● 障害時などの事後振り返り
● 顧客影響のあったものに関しては必ず書く
● 人を批判するためのものではない
Slide 97
Slide 97 text
Postmortem の活用
● 良いPostmortem は運用に関わらない
他のメンバーにも読んでもらう
○ 社内の人、誰でも読めるようにしておくと、
エンジニア以外のメンバーも読んでくれる
● 過去のPostmortem は、読み合わせを行い、
教育材料にしている
Slide 98
Slide 98 text
ツールについて
● あったほうがよい機能
○ 複数人で同時編集可
○ コメント機能
○ テンプレート機能
○ アクションアイテムを管理する機能
■ アサイン・期限指定もできれば最高
● Dropbox Paper は、↑すべてを満たす
Slide 99
Slide 99 text
記入項目の例
● 作成者
● ステータス
● サマリ
● インパクト
● 根本原因
● 発生要因
● 対応
● 検出
● アクションアイテム
● 教訓
○ うまくいったこと
○ うまくいかなかったこと
○ 幸運だったこと
● タイムライン
● 参考情報
Slide 100
Slide 100 text
個人でも組織でも、
失敗に真正面から
取り組めば成長できるが、
逃げれば何も学べない。
Slide 101
Slide 101 text
Performance Working Group
Slide 102
Slide 102 text
はてなさんの取り組みを参考にした
http://hatenacorp.jp/recruit/operation_engineer
Slide 103
Slide 103 text
はてなさんでのPWG の取り組み
> インフラ側と開発側がコミュニケーションする場としては、
サービスごとに「Performance Working Group（PWG）」という
定期的なミーティングがあります。
> サービスのレスポンススピードやエラー率などをグラフでチェックし、
問題点があれば、インフラ側・開発側の双方から
考えられる原因について共有します。
Slide 104
Slide 104 text
実践
● はてなさんと同じく、
チームを横断する組織として運営
● まだまだ性能に問題のある処理が多く、
改善を定期的に行う場として活用している
Slide 105
Slide 105 text
実装の一例
● バルクインサート化
● 無駄なソート・無駄なジョインを撲滅する
● （スペックアップなどで）リソース追加して、
性能改善されるかどうかの判断と実行
Slide 106
Slide 106 text
お世話になった本
● 『SQL パフォーマンス詳解』
● SQL を正しく理解するために
非常に役立った
● ただし、入手困難
Slide 107
Slide 107 text
入荷情報を仕入れて、買いに行った↓
Slide 108
Slide 108 text
成果
● 平均レスポンスタイム 3倍高速化
● 0.5s 以上かかるスロークエリ 98 % 削減
● サービスの根幹をなす処理のいくつかで、
10倍以上の高速化
Slide 109
Slide 109 text
サーバーの平均レスポンスタイム
Slide 110
Slide 110 text
とある処理の速度
改善後
Slide 111
Slide 111 text
スロークエリの発生量
改善後
Slide 112
Slide 112 text
学んだこと
● Monitoring 基盤を整えていたおかげで、
みんなで問題を共有できる状態になっていた
● 改善方法を共有することで、
性能改善の知見がチーム内で共有できた
● チームで成果を出すのはたのしい
Slide 113
Slide 113 text
攻め まとめ
● スケーラビリティを確保するという観点では
守りの施策とも言える
● レビューやドキュメントづくりによって、
将来のチームが困る回数を減らすようにも意識
● パフォーマンス改善は、Dev とOps 一丸で
Slide 114
Slide 114 text
Agenda
● 自己紹介
● 最高のITエンジニアリングとは？
● なぜSRE ？
● 0→1 フェーズ
● 守りの具体事例
● 攻めの具体事例
● まとめ
Slide 115
Slide 115 text
ウェブオペレーションは
技芸であり科学ではない
Slide 116
Slide 116 text
No content
Slide 117
Slide 117 text
ぼくの「一歩進んだ」の解釈
↓
ポジティブな影響を
世の中に広める
Slide 118
Slide 118 text
ポジティブな影響
● OSS へのコントリビューションをする
● 利用している製品への貢献
○ 再現できるバグ報告や、ツール開発など
● コミュニティ活動に参加する
● 新しく得た知識やノウハウを世の中に発信する
● 最高のプロダクトをつくる
Slide 119
Slide 119 text
すべての技術は、
先人の積み重ねの上にある
「次の人たち」のために
何かをすることは、すばらしい
そういうモチベーションを持て、という意味ではない
結果的にそうなっていれば最高ですね、という意味
Slide 120
Slide 120 text
さいごに
Slide 121
Slide 121 text
責任を持って開発をするということ
● 当たり前に見えるけど、いちばんだいじ
● 今日話した内容は、自分の入社時には
すべて実装されていない
Slide 122
Slide 122 text
役割・立場にとらわれず、
「自分はここに責任を持つ」
というポジションを取る
Slide 123
Slide 123 text
覚悟を決めるのは、
『精神と時の部屋』の入り口
Slide 124
Slide 124 text
No content
Slide 125
Slide 125 text
来年、みなさんの発表を
楽しみにしています！
おわり