急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ / Approaches of DevOps and Organization

July Tech Festa 2017 で「急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ」という発表をしてきた
http://kakakakakku.hatenablog.com/entry/2017/08/27/234215

July Tech Festa 2017
https://2017.techfesta.jp/

Transcript

1. 2017.08.27 吉田 慶章 @kakakakakku 急成長するサービスを支える DevOps 戦略と 組織変革へのアプローチ July Tech Festa 2017
2. 吉田 慶章 @kakakakakku - Makuake : CyberAgent Crowd Funding, Inc. - 約2年前に JOIN (社内異動) - 責任範囲 - インフラ / サーバサイド - エンジニアリングマネージャー / スクラムマスター - 技術広報
3. 吉田 慶章 @kakakakakku - 趣味 - 技術ブログを毎週書くこと - http://kakakakakku.hatenablog.com/ - 副業 - プログラミング講師 - 今年は「技術支援 / コーチング」にも挑戦中
4. Makuake - 2013年8月リリース (現在, 5年目) - 国内最大の「クラウドファンディング・プラットフォーム」
5. そもそも 急成長 って何？
6. 急成長って何？ - リクエスト数の増加 (ベースアップ) - 定期的にリクエスト数のスパイクが起きる - テレビ砲 - Yahoo! 砲 - ソーシャル拡散砲 - データサイズ / ログサイズの桁が変わってくる
7. 急成長に直面するとどうなる？ - 全般的にパフォーマンスが低下する - 最悪の場合はサービスダウンに繋がる - 今まで隠れていた 技術的負債 がどんどんと露見する - 昨日まで問題なく稼働していたのに？ - どうしてこんな実装に？ - 障害対応ばかりで, 開発が進まない
8. 今日話すこと
9. 今日話すこと 急成長を支える ( ≒ 守る ) ための DevOps 戦略 急成長を支える ( ≒ 攻める ) ための DevOps 戦略 DevOps 戦略に必須だった 組織変革 へのアプローチ
10. 本題に入る前に
11. 参加者と発表者をシンクロさせる アイスブレイク を
12. ノンバーバルなコミュニケーション - ノンバーバル = 非言語 - ようするに「表情, 態度, トーンなど」のこと - うなずき, 笑顔, 目線, ジャスチャーなど - 「話したい人」と「話したくない人」の違い - 参加者から「ノンバーバル」な反応があると嬉しい - ミーティングの場などでも, 活用できる
13. ☺ ( うんうんーわかるわかるー )
14. 急成長を支える ( ≒ 守る )
15. 急成長を支える ( ≒ 守る ) 構成ドリフト / スノーフレークサーバ を撲滅する
16. 構成ドリフト Chef / Ansible などで構成管理をしているのに,
 直接サーバ上で変更をしてしまって, 乖離が生まれること スノーフレークサーバ 構成ドリフトが起きたサーバ群のことで, 例えば web001 と web002 の設定が異なっていること 経験ありませんか？
17. Chef リファクタリング - 冪等性が保証されていないレシピが大量にあった - execute (shell 実行) を使う場合は creates / not_if とセットで - レシピを実行すると必ずミドルウェアが再起動されていた - notifies を使う - など, 他にもいろいろと - 結果的に, ほぼ全てをリファクタリングした
18. Chef 関連ツールの導入 - RuboCop : 誰でも Ruby っぽく書けるように - 指摘 1000件 → 0件 に - Foodcritic : Chef のアンチパターン実装を繰り返さないように - 指摘 150件 → 0件 に - Berkshelf : オレオレレシピを書かないように - Fluentd / Jenkins / Mackerel / PHP など
19. Serverspec の活用 - サーバ構成の期待値がわからなかったため, リバースエンジニアリングを頑張った - history | grep vi を叩くと歴史が見えてくる - つらい - 期待値を Serverspec の spec として実装し, 繰り返し適用した - 構築後のサーバ確認ではなく, スノーフレークサーバの把握のために活用した - 全ロールで spec が通ったときは爽快だった
20. インフラ CI の導入 - 開発プロセスを確立するために インフラ CI を導入した - CircleCI を使う - Chef レシピを修正してプルリクエストを送ると, 自動的に CI が実行される - RuboCop - Foodcritic - knife solo + Serverspec with Docker
21. 急成長を支える ( ≒ 守る ) モニタリングを当たり前にする
22. 必要なメトリクスを可視化できるように - メトリクスを可視化できていなく, 意思決定を行える状態ではなかった - 僕の口癖「全てはモニタリングから始まるんだ！」 - サーバメトリクス : Mackerel と Zabbix + Grafana を併用 - AWS メトリクス : CloudWatch - 各種エラーログ : Elasticsearch + Kibana - アプリケーションパフォーマンス : New Relic APM
23. Mackerel の導入 - メトリクス取得 / アラート設定 / プロセス監視 / ダッシュボード管理 - 設定値は全て Chef / cloud-init でプロビジョニングできるように - アラート設定とダッシュボード管理は Infrastructure as Code に - mkr monitors - mkr dashboards
 ＼ なんと, 2日前に「グラフボード」リリース！ ／
24. Zabbix をもっと積極的に使う - メトリクスを活用するために Zabbix スクリーン職人になった - 後に grafana-zabbix を導入して, さらに便利に - 大量に出続けていたアラートの精査 - 日常的に無視されているアラートがあるのは危険 ⚠ - ほぼ全てのアラート設定を見直した - Zabbix 自体をチューニングし, サーバ数増加による負荷に対応
25. Proactive Monitoring 積極的にダッシュボードを見て, 状況把握をすること Reactive Monitoring 閾値を超えたらアラートを飛ばすこと
26. Proactive Monitoring 積極的にダッシュボードを見て, 状況把握をすること Reactive Monitoring 閾値を超えたらアラートを飛ばすこと
27. とにかくダッシュボードは重要 システムの状態が一目瞭然になる ( Zabbix ) ( grafana-zabbix ) ( Mackerel )
28. New Relic APM - New Relic APM : Deployment Tracking - ただし Pro 限定 - デプロイ日時を記録することができる - デプロイ前後でのパフォーマンス確認が容易になる
29. モニタリングを当たり前にしたら どうなったか？
30. 毎日, 健康診断を受けているような状況に - どんどん発覚する異常値 / ボトルネック / 課題 - 効果のある改善施策を日々出せるように - ウェブサーバのメモリリークを撲滅 - ディスク使用量が異常に減り続けているサーバを改善 - など, 他にもいろいろと - アラートが鳴らなくても「何かしら起きている」という共通認識を作れた
31. 急成長を支える ( ≒ 守る ) AWS Well-Architected Framework を目指す
32. AWS Well-Architected Framework
33. AWS Well-Architected Framework - クラウドネイティブなアーキテクチャのベストプラクティス集 - 抽象的な原則 - CDP (Cloud Design Pattern) と合わせて読むのが良い - 「質問集」を活用して「Well-Architected と言えるか？」と考える
34. AWS Well-Architected Framework - 一般的な設計の原則 - 必要キャパシティーの推測をやめる - 本稼働スケールͰシステムをテストする - アーキテクチャ変更のリスクを低減する - 自動化によってアーキテクチャ実験を簡単にする - 発展するアーキテクチャの許可 - 5本の柱 - セキュリティ - 信頼性 - パフォーマンス効率 - コスト最適化 - 運用上の優秀性
35. 「質問集」の例 - SEC 5. AWS リソースへの自動化されたアクセス (アプリケーション、スクリプト、サードパーティーツール
 またはサービスからのアクセスなど) をどのように制限していますか - REL 8. システムはコンポーネントの障害にどのように対応しますか - PERF 1. システムに対して適切なインスタンスタイプはどのように選択していますか - PERF 5. システムに最適なストレージソリューションをどのように選択していますか - COST 1. キャパシティーが必要量を満たしているが大幅に超えていないことをどのように実現していますか
36. 具体的に改善した内容 (ほんの一部) - IAM Role を使えるように - ネットワーク (VPC) を再設計して運用しやすいように - 最適なインスタンスタイプで稼働できるように - Standard (Magnetic) EBS を撲滅できるように - など, 他にもいろいろと - 社内勉強会や雑談を通して, メンバーに知識を横展開した
37. それって本当に「コスト削減」なの？ - 1台のインスタンスに EIP をアタッチして運用されていた機能があった - かなり重要な機能で, 軽微なプロビジョニングを行うことも難しかった - 事前アナウンス + 平日夜間メンテナンス - これは「コスト削減」ではなく「運用上の障害」では？ - ELB を使うことにし, 信頼性も運用しやすさも向上した - インスタンスタイプも1個下げることで, 2台になってもコストは同じ
38. 急成長を支える ( ≒ 攻める )
39. 当たり前なことを当たり前に実施して 守りを固めることはできた！ けど？
40. 世の中には カッコイイ DevOps / SRE 事例ばかり
41. 隣の芝生は青く見える
42. いや, ここは身の丈に合った技術選定を！
43. 急成長を支える ( ≒ 攻める ) Aurora 移行
44. Aurora 移行 - データベースのライフサイクルは長い - ウェブサーバと比較すると, スケールアウトも難しく, SPOF になりがち - データベースで障害が起きると大惨事になる - もともと RDS ではなく MySQL 5.5 on EC2 を運用していた - uptime 1000 days 以上 ＼(^o^)／ - 急成長を支えるデータベースに移行をしたかった
45. Aurora 移行 - Aurora を採用した理由 - クエリパフォーマンスの高さ - 限りなくゼロに近い, Reader のレプリカラグ - 高速なフェイルオーバー - MySQL 5.6 完全互換
 
 「Aurora 事例祭り」
46. クエリパフォーマンスの向上 - 発行回数 TOP 5 のクエリ全てが2倍以上のパフォーマンスに - SELECT 系 (単一テーブル, JOIN など) - New Relic で計測している
47. データドリブンな意思決定ができるように - Aurora 移行前は, 分析用のクエリを本番環境のスレーブに投げていた - スレーブが高負荷状態になることも - 分析用の Aurora Reader を用意し, サービス影響を気にしなくてよいように - Redash も導入し, 組織全体がデータドリブンな雰囲気に ( ダッシュボード 27個 ) ( クエリ 146個 )
48. 急成長を支える ( ≒ 攻める ) サーバレス / フルマネージドサービスの導入
49. サーバレス - 定義はいろいろあれど, FaaS (Function as a Service) + α と考える - 銀の弾丸ではないが, 要件に合えば, 積極的に導入していく - ステートレス - イベントドリブン - スケールアウト - マイクロサービス - 現在, 開発中のものもあったり...？
50. サーバレス - 新しい技術を導入する場合は, スモールスタートを意識する - 成功体験があると, 導入障壁が下がる - メンバーに知識を横展開するため, まずは社内ツールで導入した - 開発用のインスタンスを平日夜間と週末に自動的に停止するツール - CloudWatch Events + Lambda (Node.js) - CircleCI + Apex + ESLint
51. フルマネージドサービス - 少人数で開発を回していくために, 運用コストをもっと下げたかった - AWS フルマネージドサービスを「当たり前に」使う - CloudFront / Route 53 / S3 - RDS / Amazon Elasticsearch Service / ElastiCache - Lambda / SQS / ECS - などなど - ECS (Docker) も, 要件に合えば, 積極的に導入していく
52. 組織変革へのアプローチ
53. DevOps is a way of thinking and a way of working.
54. DevOps は文化であるはずなのに - 経営層が全員非エンジニア & CTO 不在 - 何を伝えるにしても共通言語がなく, 高コストなコミュニケーションになる - 価値観の相違により, 伝わらなかったことも多々あった - 「なぜ DevOps なのか？」 - 「なぜ技術的負債と向き合う必要があるのか？」 - UI/UX などと違って DevOps は特に理解されにくい
55. 組織的な課題から目を背けていては 何も変わらない
56. 伝わらないからと言って諦めるのではなく 思い描く組織になるように行動する
57. 経営層の支持者 経営層にエンジニアリングのことを知ってもらうしかない そして, 信頼してもらう！
58. 組織変革へのアプローチ エンジニアリングのことを知ってもらう
59. エンジニアリングのことを知ってもらう - 社内の技術勉強会に必ず参加してもらった - ブログ記事 / 勉強会資料を見てもらった - 「どうでしたかー？」と毎回感想を聞くように工夫した - プログラミング入門書を買って写経してもらった - プログラミング / デバッグの難しさを知ってもらえたのは効果があった - GitHub のアクセス権限を与えて, プルリクエストのレビュー風景を見てもらった - パフォーマンス改善をしたらグラフを見せてアピールをした
60. 「経営層を巻き込まないと開発組織は変わらない」 https://developers.cyberagent.co.jp/blog/archives/4900/
61. 組織変革へのアプローチ 計画スキルを高めて, 信頼を勝ち得る
62. なぜ計画が重要なのか？ - 無駄を無くすため - 優先順位を明確にし, 今やるべきことを今やる - 信頼残高を増やすため - 「先週まで進捗 90% だったのですが, 考慮漏れがあり 50% です 」 - 何度も続くと信頼残高が無くなる - 「あの人が言うなら成功しそう」感 - 僕の計画スキルをメンバーに横展開することで, 信頼を勝ち得る
63. ラストマイル 実装が終わっただけじゃ, リリース完了にはならないこと デプロイ準備, バックアップ設定, 負荷テストなど, 重要なのにタスク化されていない場合が結構あるのでは？
64. 組織変革へのアプローチ 雑談, 雑談, 雑談
65. まだ他にもあるアプローチに関しては 2017.09.16 に詳しく紹介予定！ http://xpjug.com/xp2017/ 結局のところ 「たくさん雑談をしているかどうか」
66. まとめ
67. まとめ 急成長を支える ( ≒ 守る ) ための DevOps 戦略 急成長を支える ( ≒ 攻める ) ための DevOps 戦略 DevOps 戦略に必須だった 組織変革 へのアプローチ
68. まとめ - 急成長を支えられる組織になった - サービスの安定化 - 障害件数の大幅減 - モニタリングファーストな文化に - 技術的に挑戦し, 成長できる組織に - 雑談を重要視した活発な雰囲気に ✌