最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」

最高のITエンジニアリングとは、ユーザーへの価値提供に最大限集中できる状態を維持し続ける技術だと私は考えます。では、その状態を阻害する要因は一体何であり、どうすれば取り除くことができるのでしょうか。このような具体的な問題と向き合い、近年注目されているSRE の考え方を取り入れ、実装しながら乗り越えてきた体験談についてお話します。（HashiCorp ツールの実装、運用自動化など）また、一歩進んだITエンジニアになるため、実装に留まらない組織的な施策実行の考え方や実際の進め方についてもお伝えします。July Tech Festa 2018 での発表資料です。

Transcript

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