20120927 findjob4 dev_ops

DevOpsな現場で求められる
「インフラがわかる
デベロッパとは？」
2012/09/27
Find your Ability ! forデベロッパ #4

自己紹介

● ㈱paperboy&co. 梅谷敦
○ Twitter : @ume3_
○ ブログ：インフラエンジニアに成る
○ Ops : 4年目
● 普段のお仕事
○ AWS上でのサーバ構築
● 最近の活動
○ LAMP環境をPuppet化してみて

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

想定する参加者

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

定義

● 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

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

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

Git＋GitHub

● リビジョン管理
○ ご存知Gitでコードの世代管理
○ お一人様Gitでもやる
● GitHubでソーシャルコーディング
○ Devとのコミュニケーションにかかせない
○ issueやwikiを活用
例）GitHubでPuppetの設定管理

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

Designer

Deploy
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もさわる

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

NoOps
Designer Director

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

● NoOpsで開発が進められる時代
○ クラウドの登場がそれを現実化した
○ サーバを用意する負担が減った分、人がいらない
● スマホアプリの開発者は例外
○ すでにNoOps？
○ インフラをあまり意識しない（いいか悪いかは別）

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

NoOpsはむずかしい

● Opsはいつ登場するのか
○ プロジェクトスタート時の出番は少ない
○ リリース直前や直後
○ 運用を考えるとOpsがいないことはありえない
● プロジェクトやチームごとにOpsは必要か？
○ たまに顔をだすのがクラウド時代のOpsの未来像

基本的にOpsはいる

DevとOpsの境界線が曖昧に

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

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

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

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を実
践している人
また、
その環境にいる人

最後に

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

20120927 findjob4 dev_ops

More Related Content

20120927 findjob4 dev_ops