Download - 20130719 始めるdev ops
インフラチームが無い会社でのインフラ運用
13年7月20日土曜日
始めるDevOps
アカツキでのDevOps事例
どのように始めればいいのか
13年7月20日土曜日
自己紹介
田中 勇輔 @csouls
ハッカー Lv.3。ユーザ系SIerでERPの運用やインフラ構築の業務を経験した後、現職へ転職。
Rubyとインフラが好物で、アプリ開発と並行してアカツキのインフラを運用している
13年7月20日土曜日
アカツキソーシャルゲーム作っている会社
創業時から使っているものはRuby on Rails と Nginx
エンジニア 9 人。開発しつつインフラ運用
運用の効率化が重要
13年7月20日土曜日
インフラの歴史
創業期 2010~
構築の自動化 2011~
運用安定化 2012~
運用自動化 2013~
13年7月20日土曜日
創業期(暗黒時代) 2010~
別のクラウドサービスからAWSに乗り換え
Load Balancer の性能とインスタンス作成の手軽さから、AWSへ
最初は手作業でサーバ構築。勘が重要
13年7月20日土曜日
創業期(暗黒時代) 2010~
6~7 万DAU
Session の保存先が MySQL DB に → Master DBに処理が集中
5分置きに落ちるDBを再起動する作業。徹夜で memcached を導入し、なんとか落ちないようになったことも。
13年7月20日土曜日
ユーザ→
←MySQL
13年7月20日土曜日
構築の自動化 2011~
サーバ設定スクリプト(shell)を Git で管理
AutoScaling + スポットインスタンスで運用していたが、思ったよりコストが抑えられず、サーバも安定しなかったので止めた
スポットインスタンス流行りだしたのも、安定しなかった原因
13年7月20日土曜日
運用安定化 2012~
Auto Scaling ツールを作成。運用が安定して人間らしい生活が出来るようになった
13年7月20日土曜日
運用安定化 2012~
EC2のタグによって役割を管理
EC2に "Role" タグを付けて、役割を指定
/etc/rc.local で git pull & タグに応じたスクリプトを実行
Shellで冪等性を保つために頑張っていた
13年7月20日土曜日
NFS
13年7月20日土曜日
運用安定化 2012~
NFS サーバはSPOF
稀に Buffer cache が肥大化して障害になる
13年7月20日土曜日
運用自動化 2013~
Chef, Capistrano 導入
NFSを廃止して、SPOFが無くなった
13年7月20日土曜日
13年7月20日土曜日
ツール
物理
OS設定・ミドルウェア
アプリケーション
AWS
Chef
Capistrano
13年7月20日土曜日
ミドルウェア設定
Chef Solo
knife-solo
Berkshelf : Cookbookを管理
serverspec / Vagrant : テスト
13年7月20日土曜日
ミドルウェア設定Chef Solo
サードパーティ cookbook を Berkshelf の外で管理したり、fork するのはアンチパターン
アカツキでは、site-cookbooksで上書きしている
13年7月20日土曜日
ミドルウェア設定Chef Solo
反映は手動。まだ production 環境への自動反映はちょっと怖い...
serverspec が充実したら Git リポジトリの master ブランチの更新に応じて自動で適用する
13年7月20日土曜日
デプロイ
Capistrano
EC2のRoleタグから、デプロイを実行するアプリケーションサーバを取得
13年7月20日土曜日
# config/deploy.rbdef tagged_servers(tag_key, tag_value, default=[]) @ec2 ||= AWS::EC2.new(ec2_endpoint: 'ec2.ap-‐northeast-‐1.amazonaws.com') ret = @ec2.instances.map do |instance| next if instance.tags[tag_key] != tag_value next if instance.status != :running instance.dns_name.empty? ? instance.ip_address : instance.dns_name end.compact return default if ret.empty? retend def tag(tag_value, *args) AWS.memoize { tagged_servers(tag_key, tag_value).each do |host| server(host, *args) end }end # config/deploy/environment.rbtag 'app', :web, :app
デプロイ
13年7月20日土曜日
デプロイ
AWS の タグはシンプルだけど、超便利
Infrastructure as Code を支えるタグ
13年7月20日土曜日
監視
監視レイヤ ツール 対象
OS監視 Amazon CloudWatchCPU / メモリ / ディスク /
インスタンス数
プロセス監視 God Unicorn / Resque
ミドルウェア監視 nagios MySQL Slow query等
アプリケーション監視 NewRelic パフォーマンス
13年7月20日土曜日
God
プロセス監視ツール
メモリを使いすぎた時、暴走した時の保険
monit ではなく God を使っている理由はRuby で書けるから
13年7月20日土曜日
God
マスタープロセスはGodで監視し、Workerは
kzk/unicorn-worker-killer で、定期的に再起動
require ::File.expand_path('../config/environment', __FILE__)require 'unicorn/oob_gc'require 'unicorn/worker_killer' # リクエストを実行しているときはGCしないuse Unicorn::OobGC# 3072~4096リクエスト実行したら再起動するuse Unicorn::WorkerKiller::MaxRequests, 3072, 4096 run XXXXXXX::Application
13年7月20日土曜日
NewRelic
チューニングすべきところが一目で分かる
DOM processing が支配的なので、CSS / JavaScriptをチューニングすると、パフォーマンスが改善するApplicationサーバの実行時間は応答時間の 1 / 80 くらい
13年7月20日土曜日
NewRelic
AppServer の詳細や、ページ詳細が見れる
13年7月20日土曜日
Ruby on Railsだけじゃない
NewRelic
13年7月20日土曜日
プラグインが充実してきた
導入プラグイン :
EBS,EC2,ELB,MySQL,Newvem,Nginx,RDS,Redis
NewRelic
13年7月20日土曜日
アプリケーションサーバの死活監視にも使っている
NewRelic
13年7月20日土曜日
運用
AutoScaling
13年7月20日土曜日
Auto Scaling
失敗
Scaling Policy の設定ミス。閾値周辺の負荷により、EC2が頻繁に再起動する→ 起動すると1h 分の費用がかかるので、サーバ費用が一時2倍に
13年7月20日土曜日
負荷の傾向はPVに従う
CPU負荷よりもPVの方が安定した曲線を描く
Auto Scaling
13年7月20日土曜日
Auto Scaling
PV数を元にScaleしてほしい
閾値周辺で頻繁に起動停止を繰り返したくない
開発者が失敗せず簡単に使える
13年7月20日土曜日
Auto Scaling
Chariot : サーバ1台で処理できるPV数を元にスケール
samplingのどれか1つでも(PV数/base)が稼働インスタンス数を超えていたら、インスタンス数を(平均PV/base)に合わせる
samplingの全てのPV数で(PV数/base)が現在の稼働インスタンス数を下回っていいれば、インスタンス数を(平均PV/base)に合わせる
それ以外は何もしない
13年7月20日土曜日
Chariot
$ ruby bin/watcher app-‐name10 minuts PV dataset: 2013-‐07-‐19 17:06:00 +0900: 1416.0 2013-‐07-‐19 17:07:00 +0900: 1269.0 2013-‐07-‐19 17:08:00 +0900: 1220.0 2013-‐07-‐19 17:09:00 +0900: 1286.0 2013-‐07-‐19 17:10:00 +0900: 1293.0 2013-‐07-‐19 17:11:00 +0900: 1352.0 2013-‐07-‐19 17:12:00 +0900: 1252.0 2013-‐07-‐19 17:13:00 +0900: 1248.0 2013-‐07-‐19 17:14:00 +0900: 1232.0 2013-‐07-‐19 17:15:00 +0900: 1266.010 minuts PV average: 1283.4Current [3]Expect [2] but config min value is [3]-‐-‐-‐ Do nothing -‐-‐-‐
# AWSの設定access_key_id: AWS_ACCESS_KEY_IDsecret_access_key: AWS_SECRET_KEYec2_endpoint: ec2.ap-‐northeast-‐1.amazonaws.comcloud_watch_endpoint: monitoring.ap-‐northeast-‐1.amazonaws.comelb_endpoint: elasticloadbalancing.ap-‐northeast-‐1.amazonaws.com # アプリの設定min: 3 # 最低起動インスタンス数event-‐min: 20130722_2220-‐20130722_2310: 15 20130723_2115-‐20130723_2205: 30 20130723_2205-‐20130723_2255: 15 sampling: 10 # CloudWatchから取得するサンプリング数(1分につき1つ)
base: 1000 # 1インスタンスが処理できる分間PV数
13年7月20日土曜日
安定して運用できるようになった
運用コストが思い通りに削減できた
まだ公開してない
Chariot
13年7月20日土曜日
コラボレーション
Github
Pull Request, Issue
Redmine
DevOpsタスク、インフラWiki
HipChat
13年7月20日土曜日
Cookbook や Chariot の問題は Github の
Issue に 登録して、修正出来そうな人が
Pull Request する
これから導入したい事や運用の問題は、Redmine にチケット登録する
コラボレーション
13年7月20日土曜日
コラボレーション
HipChat
チャットツール
Campfire の Atlassian版
機能はほぼ一緒だけど、Mac ネイティブアプリが使いやすい
13年7月20日土曜日
13年7月20日土曜日
コラボレーションGithub連携が地味に便利
13年7月20日土曜日
コラボレーションほのぼのとした雰囲気
13年7月20日土曜日
目指しているもの : HipChat と Hubot で 発言を拾ってデプロイ
エンジニアだけではなく、デザイナーやデータを更新するディレクターがカジュアルにデプロイ出来るようにしたい
コラボレーション
13年7月20日土曜日
DevOpsを推進する
組織が小さく、開発部門と運用部門が分かれていないので、Dev と Ops の垣根がない
DevOpsを始める障害は少ないけど、文化は参考になるはず
13年7月20日土曜日
文化
エンジニアチームの理念2. Keep changing変化の中心に身を置き、常に改善し続ける"技術の流れに付いていくだけではなく、流れの中に積極的に身を置き、常に自分自身が変化の中心点にいるように変わり続ける。"
5. Do it yourself自らの環境は自ら創りだし、改善する"環境は誰かが与えてくれるものでも、最初からそこにあるものでもない。自らが活動するために最適な環境は自らが考え、自ら手を動かし創りだす姿勢で取り組む。"
13年7月20日土曜日
全社最適ではなく、チーム最適
プロダクトごとのチーム
プロダクトを作るために最適な技術を、既存の資産を含め、個々のチームが検討する
文化
13年7月20日土曜日
共通言語を持っている
とりあえず Ruby で書けばみんな分かるというのは、大きい
文化
13年7月20日土曜日
どのようにして広めていくか
小さく始める
まずは Chef Solo から
新規PJのサーバ構築スクリプトを Chef に置き換えてみるところから
成功体験を共有する
ツールを理解してもうのは難しいけど、ストーリーを理解してもらうのは簡単
13年7月20日土曜日