最高の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
   

   View Slide

2. #JTF2018
   

   View Slide

3. ● 北野 勝久 / @katsuhisa__
   ● SRE @ Studist Corporation
   ● Organizer of SRE Lounge
   / Rails Developers Meetup
   ● Developers Summit 登壇 etc.
   

   View Slide

4. マニュアル作成・共有プラットフォーム
   

   View Slide

5. View Slide

6. JULY TECH FESTA　今年のテーマ
   最高のITエンジニアリング
   を身につける！
   

   View Slide

7. ぼくの考えた 最高のITエンジニアリング
   最大限ユーザーへの価値提供に
   集中できる状態を維持し続ける
   

   View Slide

8. ユーザーへの価値提供に
   集中できない状態
   ユーザーへの価値提供に
   集中できる状態
   

   View Slide

9. ユーザーへの価値提供に
   集中できない状態
   ユーザーへの価値提供に
   集中できる状態
   減らすための
   守りの設計
   増やすための
   攻めの設計
   今日の本題
   ユーザーへの価値提供を阻害する要因と
   どうやって向き合ったか？をお話します。
   

   View Slide

10. ユーザーへの価値？
    

    View Slide

11. ユーザーにとっての価値とは
    ● ユーザーが価値と感じるもの
    ● ≠ 社内で価値と感じているもの
    

    View Slide

12. サービス運営において、
    ユーザーへの価値提供を
    阻害する要因はたくさんある
    

    View Slide

13. 価値提供を阻害する要因
    ● 障害対応全般
    ○ On-Call 対応, 障害未然防止策含む
    ● 不具合調査
    ● Toil
    

    View Slide

14. 価値提供を阻害する要因
    ● 障害対応全般
    ○ On-Call 対応, 障害未然防止策含む
    ● 不具合調査
    ● Toil
    サービス運営において
    価値があっても、
    ユーザーにとっては
    価値がない施策
    

    View Slide

15. どうやって向き合うか
    

    View Slide

16. 原則
    ● 仕組み・エンジニアリングで問題解決する
    ● 人間が、がんばって解決しようとしない
    

    View Slide

17. なぜか？
    

    View Slide

18. 　ほっておくと、Ops はサービスの規模に比例する
    サービス拡大
    ↓
    Ops お仕事増加
    ↓
    筋肉で解決
    

    View Slide

19. 順調に採用し続けられるのであれば
    筋肉戦術も間違いではないと思う
    

    View Slide

20. でも、2018年現在、
    エンジニア採用めっちゃ難しい
    ● 2017年の インターネット専門職(Webエンジニア含む)の
    転職求人倍率は 5.99倍
    ● 全職種で最高の転職求人倍率
    ● 前年度からの倍率の伸び率も最高
    出典 : https://www.recruitcareer.co.jp/news/20170906.pdf
    

    View Slide

21. 成長するサービスの運営において
    筋肉戦術はどこかで必ず行き詰まる
    

    View Slide

22. Site
    Reliability
    Engineering
    

    View Slide

23. SRE ?
    ● Google の運用チームを率いていた Ben Treynor 提唱
    「 SREは、ソフトウェアエンジニアに
    　 運用チームの設計を依頼した時にできあがるもの 」
    ● class SRE implements DevOps
    ○ それ以外の役割も担う
    ○ 「それ以外」の中身は各社で異なる
    

    View Slide

24. 自分の経歴
    ● 前職
    ○ インフラ・ミドルウェア エンジニア
    ■ DB リストアとか、ミドルウェア設定とか、
    システム移行とか
    ● スタディスト入社後
    ○ ずっとアプリケーション側の開発
    ■ バグつぶしや新機能開発など
    ○ その後、運用まわりも徐々に
    

    View Slide

25. 今月頭まではSAML 認証実装のPM
    

    View Slide

26. しばらくアプリケーション側の開発を
    していたこともあり、
    「ソフトウェアでシステム運用を良くする」
    SRE の考え方はすごくしっくりきた
    

    View Slide

27. Agenda
    ● 自己紹介
    ● 最高のITエンジニアリングとは？
    ● なぜSRE ？
    ● 0→1 フェーズ
    ● 守りの具体事例
    ● 攻めの具体事例
    ● まとめ
    

    View Slide

28. なぜ0→1 フェーズの話をするか？
    ● 圧倒的に事例がない
    ○ 世の中の事例を見ていると 0→1 フェーズは存在せず、
    100スタートの会社ばかりに見える
    ● はじめは何もできていない
    

    View Slide

29. 前提
    現状を打破するための
    効率的な打ち手が分からない
    

    View Slide

30. 当時どうしていたか
    ● エンジニアリングに注力する！という自己暗示
    ○ 油断すると、今までの仕事を
    うまくやることだけに流されてしまう
    ● 片っ端から勉強期
    ○ 他社の構成や運用を徹底的に調べる
    ■ 週3〜5 勉強会に行く
    ■ めっちゃ登壇者に質問する
    ○ 技術書を読みまくる
    

    View Slide

31. 一日の時間をふやす法
    もっとも大切な一項目はこうだ。
    ほかの人々がすでに学んだことに
    耳を傾けよう。
    

    View Slide

32. 他社のつらみを聞いて、
    自社はどうするか考える
    

    View Slide

33. 分からないなりに理論を学ぶ
    

    View Slide

34. いま思えば、
    非効率な学習を大量にやった
    

    View Slide

35. でも、効率か非効率かなんて
    後になってみないと分からない
    （そもそも当時は効率的だと思っていた）
    

    View Slide

36. 問題とは、望まれた事柄と
    認識された事柄の間の相違である
    仕入れた情報をもとに
    To-Be を妄想する。
    

    View Slide

37. ぐちゃぐちゃ期にやってよかったこと
    ● ドキュメンテーション
    ● インスタンスのスペックアップ
    ● 使い捨て前提で自動化用のコードを書く
    

    View Slide

38. ぐちゃぐちゃ期にやってよかったこと
    ● ドキュメンテーション
    ● インスタンスのスペックアップ
    ● 使い捨て前提で自動化用のコードを書く
    

    View Slide

39. 自分の突然死にも備えられる
    

    View Slide

40. 自動化を見据えたドキュメンテーション
    

    View Slide

41. ふだんの心がけも書いて
    頭の中を整理する
    

    View Slide

42. ぐちゃぐちゃ期にやってよかったこと
    ● ドキュメンテーション
    ● インスタンスのスペックアップ
    ● 使い捨て前提で自動化用のコードを書く
    

    View Slide

43. スペックを上げれば、
    解決することが自明な問題をつぶす
    ※モニタリング基盤が整っていない段階での
    スペック変更は無駄が多くなりがちなので注意
    

    View Slide

44. ぐちゃぐちゃ期にやってよかったこと
    ● ドキュメンテーション
    ● インスタンスのスペックアップ
    ● 使い捨て前提で自動化用のコードを書く
    

    View Slide

45. ルーチンを軽減して、
    コンテキストスイッチを減らす
    目の前の作業に集中できる時間が増える
    ただし、適用範囲の見極めに注意
    

    View Slide

46. 適用範囲の見極め？
    

    View Slide

47. 自動化を導入する際には、
    仕事の中でも特に機械的な要素を選ぶ
    新たに自動化を導入すると、
    人間がすべき仕事の全体量は減るが、
    残った仕事はむずかしくなる。
    これが自動化のパラドックスである。
    

    View Slide

48. 0→1 フェーズ まとめ
    ● 業務時間と学習時間のバランスを見直す
    ○ As-Is, To-Be を描くのが遅れると、歪が拡大する
    ● ドキュメントをこまめに書くのは おすすめ
    ● 自動化・効率化は適用範囲を見極めて行う
    

    View Slide

49. Agenda
    ● 自己紹介
    ● 最高のITエンジニアリングとは？
    ● なぜSRE ？
    ● 0→1 フェーズ
    ● 守りの具体事例
    ● 攻めの具体事例
    ● まとめ
    

    View Slide

50. サービス運営における『守り』
    ● ユーザーへの価値提供に集中できない
    状態・時間を減らす
    ● 自分たちの業務の棚卸しを行い、
    ペイン（痛みを伴う問題）を
    どうすれば減らせるか？を考える
    

    View Slide

51. ぼくたちのペインだったこと
    ● 障害時の原因切り分けが高負荷
    ● 障害予防施策の運用負荷が高い
    ● 手動変更で運用されてきたサーバーの
    中身が分からない
    

    View Slide

52. やったこと
    ● Monitoring 基盤を整える
    ● Self-Healing を実装する
    ● インフラをコード化する
    

    View Slide

53. Monitoring 基盤を整える
    

    View Slide

54. Monitoring の実装
    ● インスタンスの死活監視
    ○ CloudWatch
    ● コンピュータリソース, プロセス監視 / 外形監視
    ○ Stackdriver
    ● エラー監視, 性能（レイテンシなど）監視
    ○ NewRelic
    ● エラー可視化, 性能可視化
    ○ fluentd, Elasticsearch, Kibana
    

    View Slide

55. 可視化
    

    View Slide

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
    

    View Slide

57. latency を見る際は、
    パーセンタイル表示を活用する
    Average だと、性能改善の前後比較が分かりづらい
    

    View Slide

58. 性能改善をする際は、
    リクエストのレスポンス時間と呼び出し回数を
    横並べで表示する
    処理速度, 呼び出し回数 どちらも大きいリクエストを
    改善すると成果につながりやすい
    

    View Slide

59. Monitoring Output
    

    View Slide

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
    

    View Slide

61. Monitoring のアウトプット分類
    ● alerts
    ○ 見たらすぐに対応しないといけない
    ● tickets
    ○ 見たらいつか対応しないといけないが、
    急ぎではない
    ● logging
    ○ 基本はためておき、性能診断や監査用途
    

    View Slide

62. アウトプット分類に沿ったアラート設計
    ● alerts, tickets ごとに通知先を分ける
    ○ 通知先の出し分けがしやすいツールだとなおよし
    ■ 通知先を出し分けた上で、
    通知方法を変える
    ○ すぐ対応しなくてよい監視通知が増えると
    アラートがオオカミ少年化する
    ● logging は、データレイクへの格納を基本とする
    

    View Slide

63. その他
    ● 最終的にどの処理が動いていれば問題ないか？
    から逆算して外形監視項目の設定
    ○ 内部的にどの処理を通るリクエストか？
    ● アラートは一度オオカミ少年化してしまうと
    モラルハザードが起きるので、初期に微調整大事
    ● 無駄が可視化され、コストカットも実現
    

    View Slide

64. インフラコストカットの進め方の話は
    またどこかで・・・
    

    View Slide

65. Self-Healing を実装する
    

    View Slide

66. 2011 年にFacebook Engineering Blog に
    投稿された記事
    https://www.facebook.com/notes/facebook-engineering/making-facebook-
    self-healing/10150275248698920/
    

    View Slide

67. Self-Healing
    ● 修復性
    ● エラーが0になることを目指すわけではなく、
    SLO を達成することを目指す
    ○ とは言え、一つのエラーの裏には、
    ユーザーのガッカリ体験があることは、
    忘れてはいけない
    

    View Slide

68. 事例
    ● 特定条件下でのUnicorn の自動再起動
    ○ メモリ枯渇防止, 回復
    ○ unicorn-worker-killer
    ● 非同期処理 worker の数が、特定数を下回ったら
    自動復旧する仕組み【WIP】
    ○ そもそもworker が死なないように
    コード側も修正したい・・・
    

    View Slide

69. システム安定稼働にとっては
    すごく効果があるが、
    やりすぎには注意
    

    View Slide

70. 自律制御がうまく機能しすぎると
    問題を放置しておいてもシステムが安定して、
    アプリケーションが適当な作りをしていても
    それなりに動くようになり、
    問題に気づかないようなコードを書いてしまい、
    どんどん品質が落ちていってしまう、
    ということになりかねません。
    そのため、自律制御は暫定解であって、
    本質的な解ではないということを心して
    コードを組むというのは大事
    

    View Slide

71. インフラをコード化する
    

    View Slide

72. 問題だったこと
    ● Golden AMI 方式で運用していた
    ○ Golden AMI
    ■ サービス稼働に必要な
    一通りの汎用的な設定を終えた独自マシンイメージ
    ● が、変更が手動で継ぎ足し長年運用されており、
    中身がブラックボックス化していた
    ● 構成分からないストレス半端ないし、
    調べ物にいちいち時間がかかる
    

    View Slide

73. 当時のぼく
    「これはBlack AMI では・・・」
    

    View Slide

74. インフラコード化
    ● ブラックボックスの排除
    ● 複数人でインフラを育てることができる
    ● コードレビューやテストコードなど、
    ソフトウェア開発に近いフローで仕事ができる
    

    View Slide

75. 実装
    ● Ansible + Serverspec + Packer + AWS CodeBuild
    ○ ローカルでlint を回して、GitHub にプッシュ
    ○ PR をmerge すると、AWS CodeBuild が動く
    ○ マシンイメージが自動ビルドされる
    

    View Slide

76. Serverspec + Ansible
    ● ソフトウェア開発のリズムで
    インフラコードが書ける
    ● ansible_spec の導入で、
    ディレクトリ構成を重複管理するのを防ぐ
    

    View Slide

77. ● Packer だけでプロビジョニングを実装するのは
    たいへん
    ● Ansible はモジュールが洗練されているので、
    すごく楽に実装できる
    ● 良いところどりをしたい
    Ansible + Packer
    

    View Slide

78. ansible provisioner
    

    View Slide

79. Ansible + Packer の設定
    "provisioners": [
    {
    "type": "ansible",
    "playbook_file": "main.yml",
    "host_alias": "app",
    "user": "sample_user"
    }
    ]
    

    View Slide

80. AWS CodeBuild + Packer
    ● ローカルからマシンイメージをビルドするために
    AWS のセキュリティポートを開けたくない
    ● マシンイメージのビルドはそこそこ時間がかかる
    ○ ローカルで実行完了待ちは、
    ストレスたまりがち
    ● →AWS の上で実行すればどっちも解決
    

    View Slide

81. AWS DevOps Blog
    

    View Slide

82. 守り まとめ
    ● Monitoring やSelf-Healing に取り組んだ結果、
    直近の月間稼働率は 99.98 % まで改善
    ● インフラコード化とマシンイメージ作成の自動化で、
    パッチ適用などの運用効率化ができた
    ● 運用効率化に取り組んでいると、
    サービス全体の指標 (SLI ) に目が行きがちだけど・・・
    

    View Slide

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の向こうには、確実に、
    一つのがっかり体験があるはずです。
    大量にあるアクセスの中のたった一つかもしれませんが、
    そのエラーが出た瞬間、残念な思いをされる方が、
    インターネットのその先に確実にいらっしゃる。
    

    View Slide

84. Agenda
    ● 自己紹介
    ● 最高のITエンジニアリングとは？
    ● なぜSRE ？
    ● 0→1 フェーズ
    ● 守りの具体事例
    ● 攻めの具体事例
    ● まとめ
    

    View Slide

85. サービス運営における『攻め』
    ● ユーザーへの価値提供に集中できる
    状態・時間を増やす
    ● ≒ 未来の自分たちが困ることを減らす
    

    View Slide

86. やったこと
    ● Aurora 移行
    ● Production Readiness Review
    ● Postmortem
    ● Performance Working Group
    

    View Slide

87. Aurora 移行
    

    View Slide

88. DB でなにか起きたら
    ● 限られた運用人数で、
    DB 障害時に迅速復旧させることに不安があった
    ● その頃、DB を暗号化するプロジェクトがあり、
    同時にAurora 移行を実現できないか、と考えた
    

    View Slide

89. Aurora
    SQL
    Transactions
    Caching
    SQL
    Transactions
    Caching
    Logging + Storage
    Master Replica
    メタ情報
    参照
    書き込み
    ● レプリカラグが
    数十ミリ秒
    ● データの
    複数のコピーを
    3つのAZ に保持
    ● クラッシュ回復を
    並列スレッドで
    非同期実行
    

    View Slide

90. Aurora に移行して
    ● Read-Only DB 積極活用への不安が減った
    ● 可用性向上
    ● 勝手に
    はやくなった
    DB 移行前 DB 移行後
    

    View Slide

91. 詳しくは以下の論文がおすすめ
    『Amazon Aurora: Design Considerations
    　for High Throughput Cloud-Native Relational Databases』
    （ http://dl.acm.org/citation.cfm?id=3056101 ）
    

    View Slide

92. Production Readiness Review
    

    View Slide

93. Production Readiness Review
    ● リリース前に信頼性に関するレビューを行う
    ● 大きな機能開発の場合は、
    設計の部分からお手伝いする
    ● 完璧なレビューができなくとも、
    リリース前に変更差分を知るだけで、不安が減る
    

    View Slide

94. https://landing.google.com/sre/book/chapters/evolving-sre-engagement-model.html
    The PRR Model
    

    View Slide

95. Postmortem
    

    View Slide

96. Postmortem
    ● 障害時などの事後振り返り
    ● 顧客影響のあったものに関しては必ず書く
    ● 人を批判するためのものではない
    

    View Slide

97. Postmortem の活用
    ● 良いPostmortem は運用に関わらない
    他のメンバーにも読んでもらう
    ○ 社内の人、誰でも読めるようにしておくと、
    エンジニア以外のメンバーも読んでくれる
    ● 過去のPostmortem は、読み合わせを行い、
    教育材料にしている
    

    View Slide

98. ツールについて
    ● あったほうがよい機能
    ○ 複数人で同時編集可
    ○ コメント機能
    ○ テンプレート機能
    ○ アクションアイテムを管理する機能
    ■ アサイン・期限指定もできれば最高
    ● Dropbox Paper は、↑すべてを満たす
    

    View Slide

99. 記入項目の例
    ● 作成者
    ● ステータス
    ● サマリ
    ● インパクト
    ● 根本原因
    ● 発生要因
    ● 対応
    ● 検出
    ● アクションアイテム
    ● 教訓
    ○ うまくいったこと
    ○ うまくいかなかったこと
    ○ 幸運だったこと
    ● タイムライン
    ● 参考情報
    

    View Slide

100. 個人でも組織でも、
     失敗に真正面から
     取り組めば成長できるが、
     逃げれば何も学べない。
     

     View Slide

101. Performance Working Group
     

     View Slide

102. はてなさんの取り組みを参考にした
     http://hatenacorp.jp/recruit/operation_engineer
     

     View Slide

103. はてなさんでのPWG の取り組み
     > インフラ側と開発側がコミュニケーションする場としては、
     サービスごとに「Performance Working Group（PWG）」という
     定期的なミーティングがあります。
     > サービスのレスポンススピードやエラー率などをグラフでチェックし、
     問題点があれば、インフラ側・開発側の双方から
     考えられる原因について共有します。
     

     View Slide

104. 実践
     ● はてなさんと同じく、
     チームを横断する組織として運営
     ● まだまだ性能に問題のある処理が多く、
     改善を定期的に行う場として活用している
     

     View Slide

105. 実装の一例
     ● バルクインサート化
     ● 無駄なソート・無駄なジョインを撲滅する
     ● （スペックアップなどで）リソース追加して、
     性能改善されるかどうかの判断と実行
     

     View Slide

106. お世話になった本
     ● 『SQL パフォーマンス詳解』
     ● SQL を正しく理解するために
     非常に役立った
     ● ただし、入手困難
     

     View Slide

107. 入荷情報を仕入れて、買いに行った↓
     

     View Slide

108. 成果
     ● 平均レスポンスタイム 3倍高速化
     ● 0.5s 以上かかるスロークエリ 98 % 削減
     ● サービスの根幹をなす処理のいくつかで、
     10倍以上の高速化
     

     View Slide

109. サーバーの平均レスポンスタイム
     

     View Slide

110. とある処理の速度
     改善後
     

     View Slide

111. スロークエリの発生量
     改善後
     

     View Slide

112. 学んだこと
     ● Monitoring 基盤を整えていたおかげで、
     みんなで問題を共有できる状態になっていた
     ● 改善方法を共有することで、
     性能改善の知見がチーム内で共有できた
     ● チームで成果を出すのはたのしい
     

     View Slide

113. 攻め まとめ
     ● スケーラビリティを確保するという観点では
     守りの施策とも言える
     ● レビューやドキュメントづくりによって、
     将来のチームが困る回数を減らすようにも意識
     ● パフォーマンス改善は、Dev とOps 一丸で
     

     View Slide

114. Agenda
     ● 自己紹介
     ● 最高のITエンジニアリングとは？
     ● なぜSRE ？
     ● 0→1 フェーズ
     ● 守りの具体事例
     ● 攻めの具体事例
     ● まとめ
     

     View Slide

115. ウェブオペレーションは
     技芸であり科学ではない
     

     View Slide

116. View Slide

117. ぼくの「一歩進んだ」の解釈
     ↓
     ポジティブな影響を
     世の中に広める
     

     View Slide

118. ポジティブな影響
     ● OSS へのコントリビューションをする
     ● 利用している製品への貢献
     ○ 再現できるバグ報告や、ツール開発など
     ● コミュニティ活動に参加する
     ● 新しく得た知識やノウハウを世の中に発信する
     ● 最高のプロダクトをつくる
     

     View Slide

119. すべての技術は、
     先人の積み重ねの上にある
     「次の人たち」のために
     何かをすることは、すばらしい
     そういうモチベーションを持て、という意味ではない
     結果的にそうなっていれば最高ですね、という意味
     

     View Slide

120. さいごに
     

     View Slide

121. 責任を持って開発をするということ
     ● 当たり前に見えるけど、いちばんだいじ
     ● 今日話した内容は、自分の入社時には
     すべて実装されていない
     

     View Slide

122. 役割・立場にとらわれず、
     「自分はここに責任を持つ」
     というポジションを取る
     

     View Slide

123. 覚悟を決めるのは、
     『精神と時の部屋』の入り口
     

     View Slide

124. View Slide

125. 来年、みなさんの発表を
     楽しみにしています！
     おわり
     

     View Slide