20120927 findjob4 dev_ops

10,298 views
10,256 views

Published on

DevOpsな現場で求められる「インフラがわかるデベロッパ」とは? http://atnd.org/events/31930

Published in: Technology
1 Comment
33 Likes
Statistics
Notes
No Downloads
Views
Total views
10,298
On SlideShare
0
From Embeds
0
Number of Embeds
6,787
Actions
Shares
0
Downloads
58
Comments
1
Likes
33
Embeds 0
No embeds

No notes for slide

20120927 findjob4 dev_ops

  1. 1. DevOpsな現場で求められる 「インフラがわかる デベロッパとは?」 2012/09/27 Find your Ability ! forデベロッパ #4
  2. 2. 自己紹介● ㈱paperboy&co. 梅谷 敦 ○ Twitter : @ume3_ ○ ブログ : インフラエンジニアに成る ○ Ops : 4年目● 普段のお仕事 ○ AWS上でのサーバ構築● 最近の活動 ○ LAMP環境をPuppet化してみて ふつうのインフラエンジニアです
  3. 3. 想定する参加者Web業界でインフラに興味のある開発者ですよね?
  4. 4. 定義● DevOps ○ 運用者と開発者の壁をなくすこと ○ 参考:DevOpsって何? ■ @gosukenator さん● Dev(Development) ○ 開発者 / デベロッパ● Ops(Operations) ※[1] 10+ Deploys Per Day: Dev and Ops ○ 運用者 / インフラエンジニア Cooperation at Flickr[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  5. 5. Agenda● 前半 ○ インフラの昔と今 ○ 私が扱うようになったツール2012 ○ Opsが今求められていること● 後半 ○ Opsが変わる。Devも変わる ○ 現場のインフラの人が求める開発者 ○ DevOpsな現場● まとめ ○ インフラがわかるデベロッパとは? ふつうのOpsが現場を語ってみます
  6. 6. Opsってイッタイゼンタイなんなのさ● 普段何しているの?知らない● そもそも、いっしょに仕事しない● データセンタにいったりきたりするイメージ● 障害対応に忙しそうだ● 夜中に対応したのか、朝帰ったりしている● 今日いないな?と思ったら夜間メンテナンスOpsを知ることでインフラの範囲を探ろう
  7. 7. Opsとはウェブアプリケーションを構築・運用・保守の面から支える人 ○ サーバエンジニア ○ インフラエンジニア ○ ウェブオペレーション(!?)
  8. 8. ウェブオペレーション ● 「ウェブオペレーショ ンは技芸であり、科 学ではない。」[1] ● 技芸は経験から得る ● 経験:悪い判断・理 論と実践の衝突 ● Opsを語る良書 ○ インフラの人を知るのにDevに オススメな一冊[1] 引用元:ウェブオペレーション ―サイト運用管理の実践テクニック まえがき
  9. 9. 今までのOpsデータセンタに行ってサーバを構築。帰ったらサーバの保守手順書を作成して、夜間メンテナンスの運用準備もしなきゃな。日曜日は自宅監視の日なんだよなー。あー!人も時間も足りない。
  10. 10. 今のOpsクラウドのAPIでサーバを構築かつ自動化。手順書をコード化して、柔軟な設定変更を実施。保守時は短時間で復旧。障害を抑えたSPOFなしの設計で、運用に時間をかけて性能監視にチューニングだ!
  11. 11. 運用の技芸が求められている時代 構築 構築 運用 運用 保守 保守今までのOpsは、物理障害の 今のOpsは、運用の時間を確対応に依頼作業や監視など 保し、変化に常に対応できるの保守に時間をとられていた ことが求められる
  12. 12. 運用で必要な技芸とは何か?● 手動作業の自動化 ○ コードが書ける ○ ツールを使いこなせる● パフォーマンスチューニング ○ 性能監視 ○ ハードウェアやミドルウェアのチューニング● 結果、いいシステムを設計することができる守り(保守)から攻め(運用)へ
  13. 13. Opsな私が扱うツール2012● クラウド ○ AWS● 構成管理 ○ Puppet● リビジョン管理 ○ Git● 情報共有 ○ IRC,GitHub● デプロイメント ○ Webistrano● プロジェクト管理 ○ Agile, 付箋紙
  14. 14. AWS(Amazon Web Services)● クラウドの登場はインフラの世界を変えた ○ データセンタ+ハードウェアという制約から開放 ○ サーバの構築をプログラマブルに扱うことが可能 インフラのコード化 NoOps(インフラの人がいらない)と思えるぐらいハードウェアがAPIと化している
  15. 15. Puppet● 構成管理ツール ○ Ruby製。外部DSL● 手順書をコード化する ○ サーバ構築の自動化 ○ 独自のレシピでミドルウェアの「ふるまい」や設定ファイ ルを役割ごとに管理できる実行例)Apacheの設定ファイルの差分を変更後、サービスを自動起動
  16. 16. 例)手順書のコード化 < Puppet のレシピ > ・init.pp wwwという役割のサー バにboto[1]を導入する ・config.pp 固有の設定ファイルを 指定。このとき、インス トールが先と定義。 ・install.pp 事前に定義したpipモ ジュールをインストール[1] boto:https://github.com/boto/boto
  17. 17. Git+GitHub● リビジョン管理 ○ ご存知Gitでコードの世代管理 ○ お一人様Gitでもやる● GitHubでソーシャルコーディング ○ Devとのコミュニケーションにかかせない ○ issueやwikiを活用 例)GitHubでPuppetの設定管理
  18. 18. Webistrano● 自動デプロイツール ○ capistranoをWebアプリでラッパしたもの(Ruby製) ○ 誰もが操作できることに意味がある。Opsもデプロイ DevDesigner Deploy Ops
  19. 19. IRC● DevのIRC文化にのる ○ Opsも他職種も同様。同じツールを使う● Botがはびこるチャンネル達 ○ テストの成否通知 ○ デプロイ通知 ○ git push検知 ○ サーバ障害のアラート (例)IRCにデプロイ通知Botが流れたとき。トリガーはツールによる。
  20. 20. Agile ● Devの文化にのる ● Devはツールや文化 が整っている ● 意識が高い ● 荒ぶる四天王 ○ コスト ○ 時間 ○ スコープ ○ 品質  アジャイルサムライは良書。というよ り、最低限これぐらいのことは意識しな いとちょっと...と思えるか。
  21. 21.    タスク管理といえば付箋紙 Devの文化に興味をもつ。やる。
  22. 22. その他のツール● Jenkins ○ Devが扱うCIツール ○ ビルド作業やバッチ処理としてOpsも扱いたい● Chef ○ Devが好む構成管理ツール(Ruby製) ○ 設定ファイルがRubyの内部DSL ○ OpsもDevの作業内容を把握したい DevなツールをOpsもさわる
  23. 23. 図解Opsの日常
  24. 24. DevOpsにおけるOpsとは● OpsでありDevもやるということ ○ 求められる技芸はコードがかける力 ○ ツールを使いこなすだけではなく、文化の浸透も必要ということは、Devも...Devであり、Opsもやることが求められるているのでは?
  25. 25. 前半のまとめ● 技芸が一部陳腐化 ○ クラウドは今までのOpsを必要としない● 運用の技芸の時代 ○ コードとツール● Opsは自然とDevを求めた ○ 変わらなければいけない文化
  26. 26. Devが語るDevの話はしない● Agileの哲学● テストコード手法● CIツール● 継続的デプロイ● etc ...Opsの視点から、Devに求められていることを語ります
  27. 27. なぜOpsがDevを語るのかDevが求めるOps像がそこにあった。だったら、Opsが求めるDev像を語ってもいいのでは?今回の趣旨です
  28. 28. なぜインフラを知る必要があるのか クラウドが 登場したから
  29. 29. あれ?クラウドが登場したからDevはインフラのことを知らなくてもよくなったのでは?
  30. 30. ちがいます
  31. 31. クラウドが登場したからDevも少しインフラのことを知る必要性が出てきた
  32. 32. スモールスタートの時代● スタートアップにコストをかけたくない● 3人チームが主流 クラウドを使えばインフラ 専任者いらなくね? Dev NoOps Designer Director
  33. 33. Devにも革命を与えたクラウド● NoOpsで開発が進められる時代 ○ クラウドの登場がそれを現実化した ○ サーバを用意する負担が減った分、人がいらない● スマホアプリの開発者は例外 ○ すでにNoOps? ○ インフラをあまり意識しない(いいか悪いかは別) NoOpsならインフラはDevが触るしかない
  34. 34. NoOpsはむずかしい● Opsはいつ登場するのか ○ プロジェクトスタート時の出番は少ない ○ リリース直前や直後 ○ 運用を考えるとOpsがいないことはありえない● プロジェクトやチームごとにOpsは必要か? ○ たまに顔をだすのがクラウド時代のOpsの未来像 基本的にOpsはいる
  35. 35. DevとOpsの境界線が曖昧に● システムの複雑化・冗長化 ○ クラウドならサーバのスケールアップ・アウトが容易に ○ パフォーマンス設計よりレスポンス設計 ○ 豊富な役割を持つサーバとミドルウェアの選択肢 ○ 疎結合● Devの人のインフラの操作範囲が広がった DevはOpsといっしょに Opsをする
  36. 36. DevとOpsの壁をなくす Dev Ops※[1]10+ Deploys Per Day: Dev and Ops Cooperation at Flickr[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  37. 37. Opsが求めるDevとは● Devだけでなく、Opsもやると いう意識と行動がある人● 「だけ」がダメ● インフラに口出ししてほしい
  38. 38. こんなDevはイヤだ● DevはDev、OpsはOpsと線引をする● サーバの設計・構築はOpsまかせ● ミドルウェアの設定変更作業はすべてOpsに● 監視ツールの計測結果を見ない● root権限で出来ない操作はしないしおまかせ今までがそうだからってこれからもそうとは限らないじゃないか
  39. 39. DevとOpsが幸せになるために● DevからOpsへのお願い作業を減らす● GitHubでPull Requestする関係● 積極的なクラウドの活用● 開発環境の構築管理● ログを気にする● 定時処理のDev管理Devに知っていてほしいインフラの接点の一例を紹介
  40. 40. Pull Reqestする文化● 例:Ops管理の設定ファイルを変更したい ○ DevがOpsへPull Requestして確認後、Merge
  41. 41. OpsからDevにもPull Reqest● OpsからDevもある
  42. 42. クラウドを活用したい● AWSならこれをつかいたい! ○ サーバ→EC2 ○ MySQL→RDS ○ ロードバランサ→ELB ○ DNS→Route53 ○ 画像置き場→S3 ○ CDN化→Cloudfront● インフラの選択肢を知る● クラウドはDevとOpsの制約を開放する ○ Devは、ハードウェアをAPIとして見ることができる ○ Opsは、本来やりたいことに時間をかけることができる ○ これやりたい!をいいあえる関係へ
  43. 43. 開発環境の構築はDevがやる● Opsが構成管理したVM(仮想マシン)を使う ○ Opsがやるのは環境イメージを渡す、まで● Devがある程度管理する ○ 本番環境でも必要な設定があれば、Pull Request ○ root権限も開発環境ならさわっちゃうDevでできるインフラのことはOpsにまかせずDevでやる
  44. 44. 様々なログを気にする● 線引が曖昧なログの管理 ○ DevOpsっぷりを探る● 様々なログたちを気にしているか ○ MySQLのスロークエリ ○ Webサーバのアクセスログ ○ メトリクスの採取、性能監視のグラフ化 ○ cron,バッチ処理のログ, etc...● 今時ならFluentdでログ採取 ○ Opsが、 採取閲覧の仕組みを用意 ○ Devが、 閲覧する。気にする
  45. 45. CIツールでcron処理● DevからOpsへの作業依頼代表例 ○ 「cronに〇〇のバッチ処理の登録をお願いします」● DevはJenkinsで定期的な処理を実施 ○ Opsを介さない
  46. 46. DevOpsへのモヤモヤ ・Opsに任せすぎていたかも ・サーバ操作することが増えた ・コードに集中したいけど ・Devとコミュニケーションするなら コードかなー
  47. 47. 時代が求めるDevOps● バズワードや言葉の定義が先ではない ○ 結果そうなっただけのこと● 文化を知る● アウトプットから知る● 現場で起きていることを知る理想:俺達がやっていたことはDevOpsだったんだー!
  48. 48. 後半のまとめ● クラウドはDevをも変える ○ NoOpsな環境もあり、求められる● DevだけOpsだけがよくない ○ DevOpsで行こう● DevOpsは歩み寄りではない ○ 互いの接点を刺激しあう
  49. 49. とはいえ、これからどうするDevOps● Devはコードを書くことに集中したい● DevはOpsに興味がもてるか● DevはOpsがOpsはDevが苦手分野なことも● NoOpsが未来なのか● DevOpsを一人でやることが理想なのか● プログラマの時代。コードの時代● Opsはコード書く技術力がなければ今後は...● それでも、密接なデータセンタとOpsの関係● クラウドを使わない現場に理想のDevOpsな し、って言いたいのかよ! 皆で考えていきたい課題は山積み
  50. 50. インフラがわかるデベロッパとは?自然にDevOpsを実践している人また、その環境にいる人
  51. 51.    最後に そんな環境もあるらしいですよ

×