Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a 20130719 始めるdev ops
Similar a 20130719 始めるdev ops (20)
20130719 始めるdev ops
- 4. アカツキ ソーシャルゲーム作っている会社 創業時から使っているものは Ruby on Rails と Nginx エンジニア 9 人。開発しつつインフラ運用 運用の効率化が重要 13年7月20日土曜日
- 5. インフラの歴史 創業期 2010~ 構築の自動化 2011~ 運用安定化 2012~ 運用自動化 2013~ 13年7月20日土曜日
- 6. 創業期(暗黒時代) 2010~ 別のクラウドサービスからAWSに乗り換 え Load Balancer の性能とインスタンス作 成の手軽さから、AWSへ 最初は手作業でサーバ構築。勘が重要 13年7月20日土曜日
- 7. 創業期(暗黒時代) 2010~ 6~7 万DAU Session の保存先が MySQL DB に → Master DBに処理が集中 5分置きに落ちるDBを再起動する作業。 徹夜で memcached を導入し、なんとか 落ちないようになったことも。 13年7月20日土曜日
- 9. 構築の自動化 2011~ サーバ設定スクリプト(shell)を Git で管理 AutoScaling + スポットインスタンスで運 用していたが、思ったよりコストが抑えら れず、サーバも安定しなかったので止めた スポットインスタンス流行りだしたのも、 安定しなかった原因 13年7月20日土曜日
- 10. 運用安定化 2012~ Auto Scaling ツールを作成。運用が安定し て人間らしい生活が出来るようになった 13年7月20日土曜日
- 11. 運用安定化 2012~ EC2のタグによって役割を管理 EC2に "Role" タグを付けて、役割を指定 /etc/rc.local で git pull & タグに応じたス クリプトを実行 Shellで冪等性を保つために頑張っていた 13年7月20日土曜日
- 12. NFS 13年7月20日土曜日
- 13. 運用安定化 2012~ NFS サーバはSPOF 稀に Buffer cache が肥大化して障害になる 13年7月20日土曜日
- 14. 運用自動化 2013~ Chef, Capistrano 導入 NFSを廃止して、SPOFが無くなった 13年7月20日土曜日
- 15. 13年7月20日土曜日
- 17. ミドルウェア設定 Chef Solo knife-solo Berkshelf : Cookbookを管理 serverspec / Vagrant : テスト 13年7月20日土曜日
- 18. ミドルウェア設定 Chef Solo サードパーティ cookbook を Berkshelf の 外で管理したり、fork するのはアンチパ ターン アカツキでは、site-cookbooksで上書きし ている 13年7月20日土曜日
- 19. ミドルウェア設定 Chef Solo 反映は手動。まだ production 環境への自 動反映はちょっと怖い... serverspec が充実したら Git リポジトリ の master ブランチの更新に応じて自動 で適用する 13年7月20日土曜日
- 21. # config/deploy.rb def 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? ret end def tag(tag_value, *args) AWS.memoize { tagged_servers(tag_key, tag_value).each do |host| server(host, *args) end } end # config/deploy/environment.rb tag 'app', :web, :app デプロイ 13年7月20日土曜日
- 22. デプロイ AWS の タグはシンプルだけど、超便利 Infrastructure as Code を支えるタグ 13年7月20日土曜日
- 23. 監視 監視レイヤ ツール 対象 OS監視 Amazon CloudWatch CPU / メモリ / ディスク / インスタンス数 プロセス監視 God Unicorn / Resque ミドルウェア監視 nagios MySQL Slow query等 アプリケーション監視 NewRelic パフォーマンス 13年7月20日土曜日
- 24. God プロセス監視ツール メモリを使いすぎた時、暴走した時の保 険 monit ではなく God を使っている理由は Ruby で書けるから 13年7月20日土曜日
- 25. 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日土曜日
- 26. NewRelic チューニングすべきところが一目で分かる DOM processing が支配的なので、CSS / JavaScriptをチューニングする と、パフォーマンスが改善する Applicationサーバの実行時間は応答時間の 1 / 80 くらい 13年7月20日土曜日
- 32. Auto Scaling 失敗 Scaling Policy の設定ミス。閾値周辺の負 荷により、EC2が頻繁に再起動する → 起動すると1h 分の費用がかかるの で、サーバ費用が一時2倍に 13年7月20日土曜日
- 35. Auto Scaling Chariot : サーバ1台で処理できるPV数を元 にスケール samplingのどれか1つでも(PV数/base)が稼働インスタンス数を超えてい たら、インスタンス数を(平均PV/base)に合わせる samplingの全てのPV数で(PV数/base)が現在の稼働インスタンス数を下 回っていいれば、インスタンス数を(平均PV/base)に合わせる それ以外は何もしない 13年7月20日土曜日
- 36. Chariot $ ruby bin/watcher app-‐name 10 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.0 10 minuts PV average: 1283.4 Current [3] Expect [2] but config min value is [3] -‐-‐-‐ Do nothing -‐-‐-‐ # AWSの設定 access_key_id: AWS_ACCESS_KEY_ID secret_access_key: AWS_SECRET_KEY ec2_endpoint: ec2.ap-‐northeast-‐1.amazonaws.com cloud_watch_endpoint: monitoring.ap-‐northeast-‐1.amazonaws.com elb_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日土曜日
- 39. Cookbook や Chariot の問題は Github の Issue に 登録して、修正出来そうな人が Pull Request する これから導入したい事や運用の問題は、 Redmine にチケット登録する コラボレーション 13年7月20日土曜日
- 40. コラボレーション HipChat チャットツール Campfire の Atlassian版 機能はほぼ一緒だけど、Mac ネイティブア プリが使いやすい 13年7月20日土曜日
- 41. 13年7月20日土曜日
- 44. 目指しているもの : HipChat と Hubot で 発 言を拾ってデプロイ エンジニアだけではなく、デザイナーや データを更新するディレクターがカジュ アルにデプロイ出来るようにしたい コラボレーション 13年7月20日土曜日
- 45. DevOpsを推進する 組織が小さく、開発部門と運用部門が分か れていないので、Dev と Ops の垣根がな い DevOpsを始める障害は少ないけど、文 化は参考になるはず 13年7月20日土曜日
- 46. 文化 エンジニアチームの理念 2. Keep changing 変化の中心に身を置き、常に改善し続ける "技術の流れに付いていくだけではなく、流れの中に積極的に身を置き、常 に自分自身が変化の中心点にいるように変わり続ける。" 5. Do it yourself 自らの環境は自ら創りだし、改善する "環境は誰かが与えてくれるものでも、最初からそこにあるものでもない。 自らが活動するために最適な環境は自らが考え、自ら手を動かし創りだす姿 勢で取り組む。" 13年7月20日土曜日
- 49. どのようにして広めていくか 小さく始める まずは Chef Solo から 新規PJのサーバ構築スクリプトを Chef に置 き換えてみるところから 成功体験を共有する ツールを理解してもうのは難しいけど、スト ーリーを理解してもらうのは簡単 13年7月20日土曜日