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