20120927 findjob4 dev_ops

DevOpsな現場で求められる

「インフラがわかる

デベロッパとは？」

2012/09/27Find your Ability ! forデベロッパ #4

自己紹介

● ㈱paperboy&co. 梅谷 敦○ Twitter : @ume3_○ ブログ ： インフラエンジニアに成る○ Ops : 4年目

● 普段のお仕事○ AWS上でのサーバ構築

● 最近の活動○ LAMP環境をPuppet化してみて

ふつうのインフラエンジニアです

想定する参加者

Web業界でインフラに興味のある開発者ですよね？

定義

● DevOps○ 運用者と開発者の壁をなくすこと○ 参考：DevOpsって何？

■ @gosukenator さん

● Dev(Development)○ 開発者 / デベロッパ

● Ops(Operations)○ 運用者 / インフラエンジニア

[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

※[1] 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

Agenda

● 前半○ インフラの昔と今○ 私が扱うようになったツール2012○ Opsが今求められていること

● 後半○ Opsが変わる。Devも変わる○ 現場のインフラの人が求める開発者○ DevOpsな現場

● まとめ○ インフラがわかるデベロッパとは？

ふつうのOpsが現場を語ってみます

Opsってイッタイゼンタイなんなのさ

● 普段何しているの？知らない● そもそも、いっしょに仕事しない● データセンタにいったりきたりするイメージ● 障害対応に忙しそうだ● 夜中に対応したのか、朝帰ったりしている● 今日いないな？と思ったら夜間メンテナンス

Opsを知ることでインフラの範囲を探ろう

Opsとは

ウェブアプリケーションを構築・運用・保守の面から支える人

○ サーバエンジニア○ インフラエンジニア○ ウェブオペレーション(!?)

ウェブオペレーション

● 「ウェブオペレーションは技芸であり、科学ではない。」[1]

● 技芸は経験から得る● 経験：悪い判断・理

論と実践の衝突● Opsを語る良書

○ インフラの人を知るのにDevにオススメな一冊

[1] 引用元：ウェブオペレーション ―サイト運用管理の実践テクニック　まえがき

今までのOps

データセンタに行ってサーバを構築。帰ったらサーバの保守手順書を作成して、夜間メンテナンスの運用準備もしなきゃな。日曜日は自宅監視の日なんだよなー。あー！人も時間も足りない。

今のOps

クラウドのAPIでサーバを構築かつ自動化。手順書をコード化して、柔軟な設定変更を実施。保守時は短時間で復旧。障害を抑えたSPOFなしの設計で、運用に時間をかけて性能監視にチューニングだ！

今のOpsは、運用の時間を確保し、変化に常に対応できることが求められる

構築

保守

運用

今までのOpsは、物理障害の対応に依頼作業や監視などの保守に時間をとられていた

運用の技芸が求められている時代

構築

運用

保守

運用で必要な技芸とは何か？

● 手動作業の自動化○ コードが書ける○ ツールを使いこなせる

● パフォーマンスチューニング○ 性能監視○ ハードウェアやミドルウェアのチューニング

● 結果、いいシステムを設計することができる

守り（保守）から攻め（運用）へ

Opsな私が扱うツール2012

● クラウド○ AWS

● 構成管理○ Puppet

● リビジョン管理○ Git

● 情報共有○ IRC,GitHub

● デプロイメント○ Webistrano

● プロジェクト管理○ Agile, 付箋紙

AWS(Amazon Web Services)

● クラウドの登場はインフラの世界を変えた○ データセンタ＋ハードウェアという制約から開放○ サーバの構築をプログラマブルに扱うことが可能

インフラのコード化

　NoOps(インフラの人がいらない)と思えるぐらいハードウェアがAPIと化している

Puppet

● 構成管理ツール○ Ruby製。外部DSL

● 手順書をコード化する○ サーバ構築の自動化○ 独自のレシピでミドルウェアの「ふるまい」や設定ファイ

ルを役割ごとに管理できる

実行例）Apacheの設定ファイルの差分を変更後、サービスを自動起動

例）手順書のコード化

< Puppet のレシピ >・init.ppwwwという役割のサーバにboto[1]を導入する・config.pp 固有の設定ファイルを指定。このとき、インストールが先と定義。・install.pp 事前に定義したpipモジュールをインストール

[1] boto:https://github.com/boto/boto

Git＋GitHub

● リビジョン管理○ ご存知Gitでコードの世代管理○ お一人様Gitでもやる

● GitHubでソーシャルコーディング○ Devとのコミュニケーションにかかせない○ issueやwikiを活用例）GitHubでPuppetの設定管理

● 自動デプロイツール○ capistranoをWebアプリでラッパしたもの（Ruby製)○ 誰もが操作できることに意味がある。Opsもデプロイ

Webistrano

Deploy

Dev

Designer

Ops

IRC

● DevのIRC文化にのる○ Opsも他職種も同様。同じツールを使う

● Botがはびこるチャンネル達○ テストの成否通知○ デプロイ通知○ git push検知○ サーバ障害のアラート

(例）IRCにデプロイ通知Botが流れたとき。トリガーはツールによる。

Agile

● Devの文化にのる● Devはツールや文化

が整っている● 意識が高い● 荒ぶる四天王

○ コスト○ 時間○ スコープ○ 品質

　アジャイルサムライは良書。というより、最低限これぐらいのことは意識しないとちょっと...と思えるか。

　　　タスク管理といえば付箋紙

Devの文化に興味をもつ。やる。

その他のツール

● Jenkins○ Devが扱うCIツール○ ビルド作業やバッチ処理としてOpsも扱いたい

● Chef○ Devが好む構成管理ツール(Ruby製)○ 設定ファイルがRubyの内部DSL○ OpsもDevの作業内容を把握したい

DevなツールをOpsもさわる

図解

Opsの日常

DevOpsにおけるOpsとは

● OpsでありDevもやるということ○ 求められる技芸はコードがかける力○ ツールを使いこなすだけではなく、文化の浸透も必要

ということは、Devも...

Devであり、Opsもやることが求められるているのでは？

前半のまとめ

● 技芸が一部陳腐化○ クラウドは今までのOpsを必要としない

● 運用の技芸の時代○ コードとツール

● Opsは自然とDevを求めた○ 変わらなければいけない文化

Devが語るDevの話はしない

● Agileの哲学● テストコード手法● CIツール● 継続的デプロイ● etc ...

Opsの視点から、Devに求められていることを語ります

なぜOpsがDevを語るのか

Devが求めるOps像がそこにあった。だったら、Opsが求めるDev像を語ってもいいのでは？今回の趣旨です

なぜインフラを知る必要があるのか

クラウドが

登場したから

あれ？クラウドが登場したから

Devはインフラのことを知らなくてもよくなったのでは？

ちがいます

クラウドが登場したから

Devも少しインフラのことを知る必要性が出てきた

● スタートアップにコストをかけたくない● 3人チームが主流

スモールスタートの時代

Dev

Designer Director

クラウドを使えばインフラ専任者いらなくね？

NoOps

Devにも革命を与えたクラウド

● NoOpsで開発が進められる時代○ クラウドの登場がそれを現実化した○ サーバを用意する負担が減った分、人がいらない

● スマホアプリの開発者は例外○ すでにNoOps？○ インフラをあまり意識しない（いいか悪いかは別）

NoOpsならインフラはDevが触るしかない

NoOpsはむずかしい

● Opsはいつ登場するのか○ プロジェクトスタート時の出番は少ない○ リリース直前や直後○ 運用を考えるとOpsがいないことはありえない

● プロジェクトやチームごとにOpsは必要か？○ たまに顔をだすのがクラウド時代のOpsの未来像

基本的にOpsはいる

DevとOpsの境界線が曖昧に

● システムの複雑化・冗長化○ クラウドならサーバのスケールアップ・アウトが容易に○ パフォーマンス設計よりレスポンス設計○ 豊富な役割を持つサーバとミドルウェアの選択肢○ 疎結合

● Devの人のインフラの操作範囲が広がった

DevはOpsといっしょにOpsをする

DevとOpsの壁をなくす

[1] http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

※[1] 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

Dev Ops

Opsが求めるDevとは

● Devだけでなく、Opsもやるという意識と行動がある人

● 「だけ」がダメ● インフラに口出ししてほしい

こんなDevはイヤだ

● DevはDev、OpsはOpsと線引をする● サーバの設計・構築はOpsまかせ● ミドルウェアの設定変更作業はすべてOpsに● 監視ツールの計測結果を見ない● root権限で出来ない操作はしないしおまかせ

今までがそうだからってこれからもそうとは限らないじゃないか

DevとOpsが幸せになるために

● DevからOpsへのお願い作業を減らす● GitHubでPull Requestする関係● 積極的なクラウドの活用● 開発環境の構築管理● ログを気にする● 定時処理のDev管理

Devに知っていてほしいインフラの接点の一例を紹介

Pull Reqestする文化

● 例：Ops管理の設定ファイルを変更したい○ DevがOpsへPull Requestして確認後、Merge

OpsからDevにもPull Reqest

● OpsからDevもある

クラウドを活用したい

● AWSならこれをつかいたい！○ サーバ→EC2○ MySQL→RDS○ ロードバランサ→ELB○ DNS→Route53○ 画像置き場→S3○ CDN化→Cloudfront

● インフラの選択肢を知る● クラウドはDevとOpsの制約を開放する

○ Devは、ハードウェアをAPIとして見ることができる○ Opsは、本来やりたいことに時間をかけることができる○ これやりたい！をいいあえる関係へ

開発環境の構築はDevがやる

● Opsが構成管理したVM(仮想マシン)を使う○ Opsがやるのは環境イメージを渡す、まで

● Devがある程度管理する○ 本番環境でも必要な設定があれば、Pull Request○ root権限も開発環境ならさわっちゃう

DevでできるインフラのことはOpsにまかせずDevでやる

様々なログを気にする

● 線引が曖昧なログの管理○ DevOpsっぷりを探る

● 様々なログたちを気にしているか○ MySQLのスロークエリ○ Webサーバのアクセスログ○ メトリクスの採取、性能監視のグラフ化○ cron,バッチ処理のログ, etc...

● 今時ならFluentdでログ採取○ Opsが、 採取閲覧の仕組みを用意○ Devが、 閲覧する。気にする

CIツールでcron処理

● DevからOpsへの作業依頼代表例○ 「cronに〇〇のバッチ処理の登録をお願いします」

● DevはJenkinsで定期的な処理を実施○ Opsを介さない

DevOpsへのモヤモヤ

・Opsに任せすぎていたかも・サーバ操作することが増えた・コードに集中したいけど・Devとコミュニケーションするならコードかなー

時代が求めるDevOps

● バズワードや言葉の定義が先ではない○ 結果そうなっただけのこと

● 文化を知る● アウトプットから知る● 現場で起きていることを知る

理想：俺達がやっていたことはDevOpsだったんだー！

後半のまとめ

● クラウドはDevをも変える○ NoOpsな環境もあり、求められる

● DevだけOpsだけがよくない○ DevOpsで行こう

● DevOpsは歩み寄りではない○ 互いの接点を刺激しあう

とはいえ、これからどうするDevOps

● Devはコードを書くことに集中したい● DevはOpsに興味がもてるか● DevはOpsがOpsはDevが苦手分野なことも● NoOpsが未来なのか● DevOpsを一人でやることが理想なのか● プログラマの時代。コードの時代● Opsはコード書く技術力がなければ今後は...● それでも、密接なデータセンタとOpsの関係● クラウドを使わない現場に理想のDevOpsな

し、って言いたいのかよ！皆で考えていきたい課題は山積み

インフラがわかるデベロッパとは？

自然にDevOpsを実践している人また、その環境にいる人

　　　最後に

そんな環境もあるらしいですよ