20130719 始めるdev ops

インフラチームが無い会社でのインフラ運用

13年7月20日土曜日

始めるDevOps

アカツキでのDevOps事例

どのように始めればいいのか


自己紹介

田中　勇輔 @csouls

ハッカー Lv.3。ユーザ系SIerでERPの運用やインフラ構築の業務を経験した後、現職へ転職。

Rubyとインフラが好物で、アプリ開発と並行してアカツキのインフラを運用している


アカツキソーシャルゲーム作っている会社

創業時から使っているものはRuby on Rails と Nginx

エンジニア 9 人。開発しつつインフラ運用

運用の効率化が重要


インフラの歴史

創業期 2010~

構築の自動化 2011~

運用安定化 2012~

運用自動化 2013~


創業期(暗黒時代) 2010~

別のクラウドサービスからAWSに乗り換え

Load Balancer の性能とインスタンス作成の手軽さから、AWSへ

最初は手作業でサーバ構築。勘が重要


創業期(暗黒時代) 2010~

6~7 万DAU

Session の保存先が MySQL DB に → Master DBに処理が集中

5分置きに落ちるDBを再起動する作業。徹夜で memcached を導入し、なんとか落ちないようになったことも。


ユーザ→

←MySQL


構築の自動化 2011~

サーバ設定スクリプト(shell)を Git で管理

AutoScaling + スポットインスタンスで運用していたが、思ったよりコストが抑えられず、サーバも安定しなかったので止めた

スポットインスタンス流行りだしたのも、安定しなかった原因



Auto Scaling ツールを作成。運用が安定して人間らしい生活が出来るようになった



EC2のタグによって役割を管理

EC2に "Role" タグを付けて、役割を指定

/etc/rc.local で git pull & タグに応じたスクリプトを実行

Shellで冪等性を保つために頑張っていた


NFS



NFS サーバはSPOF

稀に Buffer cache が肥大化して障害になる


運用自動化 2013~

Chef, Capistrano 導入

NFSを廃止して、SPOFが無くなった


ツール

物理

OS設定・ミドルウェア

アプリケーション

AWS

Chef

Capistrano


ミドルウェア設定

Chef Solo

knife-solo

Berkshelf : Cookbookを管理

serverspec / Vagrant : テスト


ミドルウェア設定Chef Solo

サードパーティ cookbook を Berkshelf の外で管理したり、fork するのはアンチパターン

アカツキでは、site-cookbooksで上書きしている


ミドルウェア設定Chef Solo

反映は手動。まだ production 環境への自動反映はちょっと怖い...

serverspec が充実したら Git リポジトリの master ブランチの更新に応じて自動で適用する


デプロイ

Capistrano

EC2のRoleタグから、デプロイを実行するアプリケーションサーバを取得


# 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

デプロイ


デプロイ

AWS のタグはシンプルだけど、超便利

Infrastructure as Code を支えるタグ


監視

監視レイヤツール対象

OS監視 Amazon CloudWatchCPU / メモリ / ディスク /

インスタンス数

プロセス監視 God Unicorn / Resque

ミドルウェア監視 nagios MySQL Slow query等

アプリケーション監視 NewRelic パフォーマンス


God

プロセス監視ツール

メモリを使いすぎた時、暴走した時の保険

monit ではなく God を使っている理由はRuby で書けるから


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


NewRelic

チューニングすべきところが一目で分かる

DOM processing が支配的なので、CSS / JavaScriptをチューニングすると、パフォーマンスが改善するApplicationサーバの実行時間は応答時間の 1 / 80 くらい


NewRelic

AppServer の詳細や、ページ詳細が見れる


Ruby on Railsだけじゃない

NewRelic


プラグインが充実してきた

導入プラグイン :

EBS,EC2,ELB,MySQL,Newvem,Nginx,RDS,Redis

NewRelic


アプリケーションサーバの死活監視にも使っている

NewRelic


運用

AutoScaling


Auto Scaling

失敗

Scaling Policy の設定ミス。閾値周辺の負荷により、EC2が頻繁に再起動する→ 起動すると1h 分の費用がかかるので、サーバ費用が一時2倍に


負荷の傾向はPVに従う

CPU負荷よりもPVの方が安定した曲線を描く

Auto Scaling


Auto Scaling

PV数を元にScaleしてほしい

閾値周辺で頻繁に起動停止を繰り返したくない

開発者が失敗せず簡単に使える


Auto Scaling

Chariot : サーバ1台で処理できるPV数を元にスケール

samplingのどれか1つでも(PV数/base)が稼働インスタンス数を超えていたら、インスタンス数を(平均PV/base)に合わせる

samplingの全てのPV数で(PV数/base)が現在の稼働インスタンス数を下回っていいれば、インスタンス数を(平均PV/base)に合わせる

それ以外は何もしない


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数


安定して運用できるようになった

運用コストが思い通りに削減できた

まだ公開してない

Chariot


コラボレーション

Github

Pull Request, Issue

Redmine

DevOpsタスク、インフラWiki

HipChat


Cookbook や Chariot の問題は Github の

Issue に登録して、修正出来そうな人が

Pull Request する

これから導入したい事や運用の問題は、Redmine にチケット登録する




HipChat

チャットツール

Campfire の Atlassian版

機能はほぼ一緒だけど、Mac ネイティブアプリが使いやすい


コラボレーションGithub連携が地味に便利


コラボレーションほのぼのとした雰囲気


目指しているもの : HipChat と Hubot で発言を拾ってデプロイ

エンジニアだけではなく、デザイナーやデータを更新するディレクターがカジュアルにデプロイ出来るようにしたい



DevOpsを推進する

組織が小さく、開発部門と運用部門が分かれていないので、Dev と Ops の垣根がない

DevOpsを始める障害は少ないけど、文化は参考になるはず


文化

エンジニアチームの理念2. Keep changing変化の中心に身を置き、常に改善し続ける"技術の流れに付いていくだけではなく、流れの中に積極的に身を置き、常に自分自身が変化の中心点にいるように変わり続ける。"

5. Do it yourself自らの環境は自ら創りだし、改善する"環境は誰かが与えてくれるものでも、最初からそこにあるものでもない。自らが活動するために最適な環境は自らが考え、自ら手を動かし創りだす姿勢で取り組む。"


全社最適ではなく、チーム最適

プロダクトごとのチーム

プロダクトを作るために最適な技術を、既存の資産を含め、個々のチームが検討する

文化


共通言語を持っている

とりあえず Ruby で書けばみんな分かるというのは、大きい

文化


どのようにして広めていくか

小さく始める

まずは Chef Solo から

新規PJのサーバ構築スクリプトを Chef に置き換えてみるところから

成功体験を共有する

ツールを理解してもうのは難しいけど、ストーリーを理解してもらうのは簡単


20130719 始めるdev ops

Documents