20130719 始めるdev ops

2,525 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,525
On SlideShare
0
From Embeds
0
Number of Embeds
1,048
Actions
Shares
0
Downloads
8
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

20130719 始めるdev ops

  1. 1. インフラチームが無い会社 でのインフラ運用 13年7月20日土曜日
  2. 2. 始めるDevOps アカツキでのDevOps事例 どのように始めればいいのか 13年7月20日土曜日
  3. 3. 自己紹介 田中 勇輔 @csouls ハッカー Lv.3。ユーザ系SIerでERPの運用やイ ンフラ構築の業務を経験した後、現職へ転職。 Rubyとインフラが好物で、アプリ開発と並行 してアカツキのインフラを運用している 13年7月20日土曜日
  4. 4. アカツキ ソーシャルゲーム作っている会社 創業時から使っているものは Ruby on Rails と Nginx エンジニア 9 人。開発しつつインフラ運用 運用の効率化が重要 13年7月20日土曜日
  5. 5. インフラの歴史 創業期 2010~ 構築の自動化 2011~ 運用安定化 2012~ 運用自動化 2013~ 13年7月20日土曜日
  6. 6. 創業期(暗黒時代) 2010~ 別のクラウドサービスからAWSに乗り換 え Load Balancer の性能とインスタンス作 成の手軽さから、AWSへ 最初は手作業でサーバ構築。勘が重要 13年7月20日土曜日
  7. 7. 創業期(暗黒時代) 2010~ 6~7 万DAU Session の保存先が MySQL DB に → Master DBに処理が集中 5分置きに落ちるDBを再起動する作業。 徹夜で memcached を導入し、なんとか 落ちないようになったことも。 13年7月20日土曜日
  8. 8. ユーザ→ ←MySQL 13年7月20日土曜日
  9. 9. 構築の自動化 2011~ サーバ設定スクリプト(shell)を Git で管理 AutoScaling + スポットインスタンスで運 用していたが、思ったよりコストが抑えら れず、サーバも安定しなかったので止めた スポットインスタンス流行りだしたのも、 安定しなかった原因 13年7月20日土曜日
  10. 10. 運用安定化 2012~ Auto Scaling ツールを作成。運用が安定し て人間らしい生活が出来るようになった 13年7月20日土曜日
  11. 11. 運用安定化 2012~ EC2のタグによって役割を管理 EC2に "Role" タグを付けて、役割を指定 /etc/rc.local で git pull & タグに応じたス クリプトを実行 Shellで冪等性を保つために頑張っていた 13年7月20日土曜日
  12. 12. NFS 13年7月20日土曜日
  13. 13. 運用安定化 2012~ NFS サーバはSPOF 稀に Buffer cache が肥大化して障害になる 13年7月20日土曜日
  14. 14. 運用自動化 2013~ Chef, Capistrano 導入 NFSを廃止して、SPOFが無くなった 13年7月20日土曜日
  15. 15. 13年7月20日土曜日
  16. 16. ツール 物理 OS設定・ミドル ウェア アプリケーション AWS Chef Capistrano 13年7月20日土曜日
  17. 17. ミドルウェア設定 Chef Solo knife-solo Berkshelf : Cookbookを管理 serverspec / Vagrant : テスト 13年7月20日土曜日
  18. 18. ミドルウェア設定 Chef Solo サードパーティ cookbook を Berkshelf の 外で管理したり、fork するのはアンチパ ターン アカツキでは、site-cookbooksで上書きし ている 13年7月20日土曜日
  19. 19. ミドルウェア設定 Chef Solo 反映は手動。まだ production 環境への自 動反映はちょっと怖い... serverspec が充実したら Git リポジトリ の master ブランチの更新に応じて自動 で適用する 13年7月20日土曜日
  20. 20. デプロイ Capistrano EC2のRoleタグから、デプロイを実行す るアプリケーションサーバを取得 13年7月20日土曜日
  21. 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. 22. デプロイ AWS の タグはシンプルだけど、超便利 Infrastructure as Code を支えるタグ 13年7月20日土曜日
  23. 23. 監視 監視レイヤ ツール 対象 OS監視 Amazon CloudWatch CPU / メモリ / ディスク / インスタンス数 プロセス監視 God Unicorn / Resque ミドルウェア監視 nagios MySQL Slow query等 アプリケーション監視 NewRelic パフォーマンス 13年7月20日土曜日
  24. 24. God プロセス監視ツール メモリを使いすぎた時、暴走した時の保 険 monit ではなく God を使っている理由は Ruby で書けるから 13年7月20日土曜日
  25. 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. 26. NewRelic チューニングすべきところが一目で分かる DOM processing が支配的なので、CSS / JavaScriptをチューニングする と、パフォーマンスが改善する Applicationサーバの実行時間は応答時間の 1 / 80 くらい 13年7月20日土曜日
  27. 27. NewRelic AppServer の詳細や、ページ詳細が見れる 13年7月20日土曜日
  28. 28. Ruby on Railsだけじゃない NewRelic 13年7月20日土曜日
  29. 29. プラグインが充実してきた 導入プラグイン : EBS,EC2,ELB,MySQL,Newvem,Nginx,R DS,Redis NewRelic 13年7月20日土曜日
  30. 30. アプリケーションサーバの死活監視にも使 っている NewRelic 13年7月20日土曜日
  31. 31. 運用 AutoScaling 13年7月20日土曜日
  32. 32. Auto Scaling 失敗 Scaling Policy の設定ミス。閾値周辺の負 荷により、EC2が頻繁に再起動する → 起動すると1h 分の費用がかかるの で、サーバ費用が一時2倍に 13年7月20日土曜日
  33. 33. 負荷の傾向はPVに従 う CPU負荷よりもPVの 方が安定した曲線を 描く Auto Scaling 13年7月20日土曜日
  34. 34. Auto Scaling PV数を元にScaleしてほしい 閾値周辺で頻繁に起動停止を繰り返したく ない 開発者が失敗せず簡単に使える 13年7月20日土曜日
  35. 35. Auto Scaling Chariot : サーバ1台で処理できるPV数を元 にスケール samplingのどれか1つでも(PV数/base)が稼働インスタンス数を超えてい たら、インスタンス数を(平均PV/base)に合わせる samplingの全てのPV数で(PV数/base)が現在の稼働インスタンス数を下 回っていいれば、インスタンス数を(平均PV/base)に合わせる それ以外は何もしない 13年7月20日土曜日
  36. 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日土曜日
  37. 37. 安定して運用できるようになった 運用コストが思い通りに削減できた まだ公開してない Chariot 13年7月20日土曜日
  38. 38. コラボレーション Github Pull Request, Issue Redmine DevOpsタスク、インフラWiki HipChat 13年7月20日土曜日
  39. 39. Cookbook や Chariot の問題は Github の Issue に 登録して、修正出来そうな人が Pull Request する これから導入したい事や運用の問題は、 Redmine にチケット登録する コラボレーション 13年7月20日土曜日
  40. 40. コラボレーション HipChat チャットツール Campfire の Atlassian版 機能はほぼ一緒だけど、Mac ネイティブア プリが使いやすい 13年7月20日土曜日
  41. 41. 13年7月20日土曜日
  42. 42. コラボレーション Github連携が地味に便利 13年7月20日土曜日
  43. 43. コラボレーション ほのぼのとした雰囲気 13年7月20日土曜日
  44. 44. 目指しているもの : HipChat と Hubot で 発 言を拾ってデプロイ エンジニアだけではなく、デザイナーや データを更新するディレクターがカジュ アルにデプロイ出来るようにしたい コラボレーション 13年7月20日土曜日
  45. 45. DevOpsを推進する 組織が小さく、開発部門と運用部門が分か れていないので、Dev と Ops の垣根がな い DevOpsを始める障害は少ないけど、文 化は参考になるはず 13年7月20日土曜日
  46. 46. 文化 エンジニアチームの理念 2. Keep changing 変化の中心に身を置き、常に改善し続ける "技術の流れに付いていくだけではなく、流れの中に積極的に身を置き、常 に自分自身が変化の中心点にいるように変わり続ける。" 5. Do it yourself 自らの環境は自ら創りだし、改善する "環境は誰かが与えてくれるものでも、最初からそこにあるものでもない。 自らが活動するために最適な環境は自らが考え、自ら手を動かし創りだす姿 勢で取り組む。" 13年7月20日土曜日
  47. 47. 全社最適ではなく、チーム最適 プロダクトごとのチーム プロダクトを作るために最適な技術を、 既存の資産を含め、個々のチームが検討 する 文化 13年7月20日土曜日
  48. 48. 共通言語を持っている とりあえず Ruby で書けばみんな分か るというのは、大きい 文化 13年7月20日土曜日
  49. 49. どのようにして広めていくか 小さく始める まずは Chef Solo から 新規PJのサーバ構築スクリプトを Chef に置 き換えてみるところから 成功体験を共有する ツールを理解してもうのは難しいけど、スト ーリーを理解してもらうのは簡単 13年7月20日土曜日

×