$30 off During Our Annual Pro Sale. View Details »

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

急成長するサービスを支える 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/

Yoshiaki Yoshida

August 27, 2017
Tweet

More Decks by Yoshiaki Yoshida

Other Decks in Technology

Transcript

  1. 2017.08.27
    吉田 慶章 @kakakakakku
    急成長するサービスを支える
    DevOps 戦略と
    組織変革へのアプローチ
    July Tech Festa 2017

    View Slide

  2. 吉田 慶章 @kakakakakku
    - Makuake : CyberAgent Crowd Funding, Inc.
    - 約2年前に JOIN (社内異動)
    - 責任範囲
    - インフラ / サーバサイド
    - エンジニアリングマネージャー / スクラムマスター
    - 技術広報

    View Slide

  3. 吉田 慶章 @kakakakakku
    - 趣味
    - 技術ブログを毎週書くこと
    - http://kakakakakku.hatenablog.com/
    - 副業
    - プログラミング講師
    - 今年は「技術支援 / コーチング」にも挑戦中

    View Slide

  4. Makuake
    - 2013年8月リリース (現在, 5年目)
    - 国内最大の「クラウドファンディング・プラットフォーム」

    View Slide

  5. そもそも 急成長 って何?

    View Slide

  6. 急成長って何?
    - リクエスト数の増加 (ベースアップ)
    - 定期的にリクエスト数のスパイクが起きる
    - テレビ砲
    - Yahoo! 砲
    - ソーシャル拡散砲
    - データサイズ / ログサイズの桁が変わってくる

    View Slide

  7. 急成長に直面するとどうなる?
    - 全般的にパフォーマンスが低下する
    - 最悪の場合はサービスダウンに繋がる
    - 今まで隠れていた 技術的負債 がどんどんと露見する
    - 昨日まで問題なく稼働していたのに?
    - どうしてこんな実装に?
    - 障害対応ばかりで, 開発が進まない

    View Slide

  8. 今日話すこと

    View Slide

  9. 今日話すこと
    急成長を支える ( ≒ 守る ) ための DevOps 戦略
    急成長を支える ( ≒ 攻める ) ための DevOps 戦略
    DevOps 戦略に必須だった 組織変革 へのアプローチ

    View Slide

  10. 本題に入る前に

    View Slide

  11. 参加者と発表者をシンクロさせる
    アイスブレイク を

    View Slide

  12. ノンバーバルなコミュニケーション
    - ノンバーバル = 非言語
    - ようするに「表情, 態度, トーンなど」のこと
    - うなずき, 笑顔, 目線, ジャスチャーなど
    - 「話したい人」と「話したくない人」の違い
    - 参加者から「ノンバーバル」な反応があると嬉しい
    - ミーティングの場などでも, 活用できる

    View Slide

  13. ☺ ( うんうんーわかるわかるー )

    View Slide

  14. 急成長を支える ( ≒ 守る )

    View Slide

  15. 急成長を支える ( ≒ 守る )
    構成ドリフト / スノーフレークサーバ を撲滅する

    View Slide

  16. 構成ドリフト
    Chef / Ansible などで構成管理をしているのに,

    直接サーバ上で変更をしてしまって, 乖離が生まれること

    スノーフレークサーバ
    構成ドリフトが起きたサーバ群のことで,
    例えば web001 と web002 の設定が異なっていること

    経験ありませんか?

    View Slide

  17. Chef リファクタリング
    - 冪等性が保証されていないレシピが大量にあった
    - execute (shell 実行) を使う場合は creates / not_if とセットで
    - レシピを実行すると必ずミドルウェアが再起動されていた
    - notifies を使う
    - など, 他にもいろいろと
    - 結果的に, ほぼ全てをリファクタリングした

    View Slide

  18. Chef 関連ツールの導入
    - RuboCop : 誰でも Ruby っぽく書けるように
    - 指摘 1000件 → 0件 に
    - Foodcritic : Chef のアンチパターン実装を繰り返さないように
    - 指摘 150件 → 0件 に
    - Berkshelf : オレオレレシピを書かないように
    - Fluentd / Jenkins / Mackerel / PHP など

    View Slide

  19. Serverspec の活用
    - サーバ構成の期待値がわからなかったため, リバースエンジニアリングを頑張った
    - history | grep vi を叩くと歴史が見えてくる
    - つらい
    - 期待値を Serverspec の spec として実装し, 繰り返し適用した
    - 構築後のサーバ確認ではなく, スノーフレークサーバの把握のために活用した
    - 全ロールで spec が通ったときは爽快だった

    View Slide

  20. インフラ CI の導入
    - 開発プロセスを確立するために インフラ CI を導入した
    - CircleCI を使う
    - Chef レシピを修正してプルリクエストを送ると, 自動的に CI が実行される
    - RuboCop
    - Foodcritic
    - knife solo + Serverspec with Docker

    View Slide

  21. 急成長を支える ( ≒ 守る )
    モニタリングを当たり前にする

    View Slide

  22. 必要なメトリクスを可視化できるように
    - メトリクスを可視化できていなく, 意思決定を行える状態ではなかった

    - 僕の口癖「全てはモニタリングから始まるんだ!」
    - サーバメトリクス : Mackerel と Zabbix + Grafana を併用
    - AWS メトリクス : CloudWatch
    - 各種エラーログ : Elasticsearch + Kibana
    - アプリケーションパフォーマンス : New Relic APM

    View Slide

  23. Mackerel の導入
    - メトリクス取得 / アラート設定 / プロセス監視 / ダッシュボード管理
    - 設定値は全て Chef / cloud-init でプロビジョニングできるように
    - アラート設定とダッシュボード管理は Infrastructure as Code に
    - mkr monitors
    - mkr dashboards

    \ なんと, 2日前に「グラフボード」リリース! /

    View Slide

  24. Zabbix をもっと積極的に使う
    - メトリクスを活用するために Zabbix スクリーン職人になった
    - 後に grafana-zabbix を導入して, さらに便利に
    - 大量に出続けていたアラートの精査
    - 日常的に無視されているアラートがあるのは危険

    - ほぼ全てのアラート設定を見直した
    - Zabbix 自体をチューニングし, サーバ数増加による負荷に対応

    View Slide

  25. Proactive Monitoring
    積極的にダッシュボードを見て, 状況把握をすること
    Reactive Monitoring
    閾値を超えたらアラートを飛ばすこと

    View Slide

  26. Proactive Monitoring
    積極的にダッシュボードを見て, 状況把握をすること
    Reactive Monitoring
    閾値を超えたらアラートを飛ばすこと

    View Slide

  27. とにかくダッシュボードは重要
    システムの状態が一目瞭然になる
    ( Zabbix ) ( grafana-zabbix ) ( Mackerel )

    View Slide

  28. New Relic APM
    - New Relic APM : Deployment Tracking
    - ただし Pro 限定
    - デプロイ日時を記録することができる
    - デプロイ前後でのパフォーマンス確認が容易になる

    View Slide

  29. モニタリングを当たり前にしたら
    どうなったか?

    View Slide

  30. 毎日, 健康診断を受けているような状況に
    - どんどん発覚する異常値 / ボトルネック / 課題
    - 効果のある改善施策を日々出せるように
    - ウェブサーバのメモリリークを撲滅
    - ディスク使用量が異常に減り続けているサーバを改善
    - など, 他にもいろいろと
    - アラートが鳴らなくても「何かしら起きている」という共通認識を作れた

    View Slide

  31. 急成長を支える ( ≒ 守る )
    AWS Well-Architected Framework を目指す

    View Slide

  32. AWS Well-Architected
    Framework

    View Slide

  33. AWS Well-Architected Framework
    - クラウドネイティブなアーキテクチャのベストプラクティス集
    - 抽象的な原則
    - CDP (Cloud Design Pattern) と合わせて読むのが良い
    - 「質問集」を活用して「Well-Architected と言えるか?」と考える

    View Slide

  34. AWS Well-Architected Framework
    - 一般的な設計の原則
    - 必要キャパシティーの推測をやめる
    - 本稼働スケールͰシステムをテストする
    - アーキテクチャ変更のリスクを低減する
    - 自動化によってアーキテクチャ実験を簡単にする
    - 発展するアーキテクチャの許可
    - 5本の柱
    - セキュリティ
    - 信頼性
    - パフォーマンス効率
    - コスト最適化
    - 運用上の優秀性

    View Slide

  35. 「質問集」の例
    - SEC 5. AWS リソースへの自動化されたアクセス (アプリケーション、スクリプト、サードパーティーツール

    またはサービスからのアクセスなど) をどのように制限していますか
    - REL 8. システムはコンポーネントの障害にどのように対応しますか
    - PERF 1. システムに対して適切なインスタンスタイプはどのように選択していますか
    - PERF 5. システムに最適なストレージソリューションをどのように選択していますか
    - COST 1. キャパシティーが必要量を満たしているが大幅に超えていないことをどのように実現していますか

    View Slide

  36. 具体的に改善した内容 (ほんの一部)
    - IAM Role を使えるように
    - ネットワーク (VPC) を再設計して運用しやすいように
    - 最適なインスタンスタイプで稼働できるように
    - Standard (Magnetic) EBS を撲滅できるように
    - など, 他にもいろいろと
    - 社内勉強会や雑談を通して, メンバーに知識を横展開した

    View Slide

  37. それって本当に「コスト削減」なの?
    - 1台のインスタンスに EIP をアタッチして運用されていた機能があった
    - かなり重要な機能で, 軽微なプロビジョニングを行うことも難しかった
    - 事前アナウンス + 平日夜間メンテナンス
    - これは「コスト削減」ではなく「運用上の障害」では?
    - ELB を使うことにし, 信頼性も運用しやすさも向上した
    - インスタンスタイプも1個下げることで, 2台になってもコストは同じ

    View Slide

  38. 急成長を支える ( ≒ 攻める )

    View Slide

  39. 当たり前なことを当たり前に実施して
    守りを固めることはできた!
    けど?

    View Slide

  40. 世の中には
    カッコイイ DevOps / SRE 事例ばかり

    View Slide

  41. 隣の芝生は青く見える

    View Slide

  42. いや, ここは身の丈に合った技術選定を!

    View Slide

  43. 急成長を支える ( ≒ 攻める )
    Aurora 移行

    View Slide

  44. Aurora 移行
    - データベースのライフサイクルは長い
    - ウェブサーバと比較すると, スケールアウトも難しく, SPOF になりがち
    - データベースで障害が起きると大惨事になる
    - もともと RDS ではなく MySQL 5.5 on EC2 を運用していた
    - uptime 1000 days 以上 \(^o^)/
    - 急成長を支えるデータベースに移行をしたかった

    View Slide

  45. Aurora 移行
    - Aurora を採用した理由
    - クエリパフォーマンスの高さ
    - 限りなくゼロに近い, Reader のレプリカラグ
    - 高速なフェイルオーバー
    - MySQL 5.6 完全互換


    「Aurora 事例祭り」

    View Slide

  46. クエリパフォーマンスの向上
    - 発行回数 TOP 5 のクエリ全てが2倍以上のパフォーマンスに
    - SELECT 系 (単一テーブル, JOIN など)
    - New Relic で計測している

    View Slide

  47. データドリブンな意思決定ができるように
    - Aurora 移行前は, 分析用のクエリを本番環境のスレーブに投げていた
    - スレーブが高負荷状態になることも
    - 分析用の Aurora Reader を用意し, サービス影響を気にしなくてよいように
    - Redash も導入し, 組織全体がデータドリブンな雰囲気に
    ( ダッシュボード 27個 ) ( クエリ 146個 )

    View Slide

  48. 急成長を支える ( ≒ 攻める )
    サーバレス / フルマネージドサービスの導入

    View Slide

  49. サーバレス
    - 定義はいろいろあれど, FaaS (Function as a Service) + α と考える
    - 銀の弾丸ではないが, 要件に合えば, 積極的に導入していく
    - ステートレス
    - イベントドリブン
    - スケールアウト
    - マイクロサービス
    - 現在, 開発中のものもあったり...?

    View Slide

  50. サーバレス
    - 新しい技術を導入する場合は, スモールスタートを意識する
    - 成功体験があると, 導入障壁が下がる
    - メンバーに知識を横展開するため, まずは社内ツールで導入した
    - 開発用のインスタンスを平日夜間と週末に自動的に停止するツール
    - CloudWatch Events + Lambda (Node.js)
    - CircleCI + Apex + ESLint

    View Slide

  51. フルマネージドサービス
    - 少人数で開発を回していくために, 運用コストをもっと下げたかった
    - AWS フルマネージドサービスを「当たり前に」使う
    - CloudFront / Route 53 / S3
    - RDS / Amazon Elasticsearch Service / ElastiCache
    - Lambda / SQS / ECS
    - などなど
    - ECS (Docker) も, 要件に合えば, 積極的に導入していく

    View Slide

  52. 組織変革へのアプローチ

    View Slide

  53. DevOps is a way of
    thinking and a way of
    working.

    View Slide

  54. DevOps は文化であるはずなのに
    - 経営層が全員非エンジニア & CTO 不在
    - 何を伝えるにしても共通言語がなく, 高コストなコミュニケーションになる
    - 価値観の相違により, 伝わらなかったことも多々あった
    - 「なぜ DevOps なのか?」
    - 「なぜ技術的負債と向き合う必要があるのか?」
    - UI/UX などと違って DevOps は特に理解されにくい

    View Slide

  55. 組織的な課題から目を背けていては
    何も変わらない

    View Slide

  56. 伝わらないからと言って諦めるのではなく
    思い描く組織になるように行動する

    View Slide

  57. 経営層の支持者
    経営層にエンジニアリングのことを知ってもらうしかない

    そして, 信頼してもらう!

    View Slide

  58. 組織変革へのアプローチ
    エンジニアリングのことを知ってもらう

    View Slide

  59. エンジニアリングのことを知ってもらう
    - 社内の技術勉強会に必ず参加してもらった
    - ブログ記事 / 勉強会資料を見てもらった
    - 「どうでしたかー?」と毎回感想を聞くように工夫した
    - プログラミング入門書を買って写経してもらった
    - プログラミング / デバッグの難しさを知ってもらえたのは効果があった
    - GitHub のアクセス権限を与えて, プルリクエストのレビュー風景を見てもらった
    - パフォーマンス改善をしたらグラフを見せてアピールをした

    View Slide

  60. 「経営層を巻き込まないと開発組織は変わらない」
    https://developers.cyberagent.co.jp/blog/archives/4900/

    View Slide

  61. 組織変革へのアプローチ
    計画スキルを高めて, 信頼を勝ち得る

    View Slide

  62. なぜ計画が重要なのか?
    - 無駄を無くすため
    - 優先順位を明確にし, 今やるべきことを今やる
    - 信頼残高を増やすため
    - 「先週まで進捗 90% だったのですが, 考慮漏れがあり 50% です


    - 何度も続くと信頼残高が無くなる
    - 「あの人が言うなら成功しそう」感
    - 僕の計画スキルをメンバーに横展開することで, 信頼を勝ち得る

    View Slide

  63. ラストマイル
    実装が終わっただけじゃ, リリース完了にはならないこと

    デプロイ準備, バックアップ設定, 負荷テストなど,
    重要なのにタスク化されていない場合が結構あるのでは?

    View Slide

  64. 組織変革へのアプローチ
    雑談, 雑談, 雑談

    View Slide

  65. まだ他にもあるアプローチに関しては 2017.09.16 に詳しく紹介予定!
    http://xpjug.com/xp2017/
    結局のところ
    「たくさん雑談をしているかどうか」

    View Slide

  66. まとめ

    View Slide

  67. まとめ
    急成長を支える ( ≒ 守る ) ための DevOps 戦略
    急成長を支える ( ≒ 攻める ) ための DevOps 戦略
    DevOps 戦略に必須だった 組織変革 へのアプローチ

    View Slide

  68. まとめ
    - 急成長を支えられる組織になった
    - サービスの安定化
    - 障害件数の大幅減
    - モニタリングファーストな文化に
    - 技術的に挑戦し, 成長できる組織に
    - 雑談を重要視した活発な雰囲気に

    View Slide