★テーマ
攻めの運用の極意
●スピーカー
株式会社ディー・エヌ・エー / MySQL Casual / qpstudy / Shibuya.pm / Tsukuba.R
岩永 亮介 氏
モバゲーのサーバーサイド
オペレーションエンジニア
DBA
マネージャー
http://www.oreilly.co.jp/books/9784873114934/
ウェブオペレーション――サイト運用管理の実践テクニック
１６章 アジャイルインフラストラクチャ
読むべし
アプリケーションはインフラであり
インフラはアプリケーションである
●インフラはアプリケーションである
○運用の為に必要な要素
・性能管理
・オライリー キャパシティプランニング
1、現行のインフラがどの程度適切に機能しているか
2、許容可能なパフォーマンスぉ維持する為に何が必要か
・「配置」とは？
自動インストールツール
自動構成
・ビジネスメトリクス
アプリケーションメトリクス
システムメトリクス
監視とは継続的なテストである
Negios Plugin
○management(構成管理）
・どのサーバがどういうスペックでどういう役目でどういうステータスか？
○Collection（情報収集）
・あらゆる数値がどういう状態にあるか継続的に収集する
○Configuration（設定管理）
・役割毎にどういう設定にすべきかを管理
・設定がただ正しいか監視出来る
あらゆる事項を見やすく可視化する
可視化できるなら監視できる
○Touryou
・設定管理に特化したツール
・テンプレートのファイルと現在置かれているファイルを比較して、diffがあればNGとする
・Chefでも良かったが、組織で使う以上は何かカスタマイズを入れたくなる
testの仕組みが欲しかった
中央からsshでさくっといやりたかった(サーバー側で実行したくない)
そのため、Chefは使わず、自分で作った
自分で作ってしまった方が正解に近づく場合もある
かと言って、みんなが好き勝手作ればいいというわけではない
○コンポーネント間のプロトコルを先に考える
・API等
ファイル管理→DB管理に変わったとしても、APIだけいじれば修正出来る
API=Libraryではない
API=HTTP APIが近い
○運用の要素を分類して考えた
・必要なアプリは自分で書けばいい
・間のAPIだけは先に決めるべき
●アプリケーションはインフラである
○システムは成長する
・トレンドが変わったりして、どんどん変わって行く
・作って終わりはあり得ない
・動くものではなく、動き続けるものを作る
・今は動いていても、ちょっとしたら動かなくなるようなものを作っても仕方が無い
○.*Ops
・Operational Mentality
運用している時も、常に「今動いているけどそのうち動かなくなるな」
みたいなことを思っておいた方がいい
本当に怖いのは対立構造じゃなく、無関心になられること
運用しなくていいシステムよりも、運用が楽しくなるようなシステムを作る
みんなで運用する
普通だと運用中障害が起こったりして辛かったりする
●感想
まだ本格的に自分が責任者としてシステム運用をしたことはないが、
将来的には絶対に必要になる知識ばかりの内容だった。
自分の持っている知識としても弱い分野だったので、今後の参考にしていきたい。
また、Chefのような既存のツールを使わず、使いやすいように自分で開発したという話を聴いて、
「自分で作ろう」というエンジニアとして必要な発想が自分にはまだまだ弱いと感じた。
今後はただあるものを使うだけでなく、必要なものを自分で作るということもより意識していきたい。
攻めの運用の極意
●スピーカー
株式会社ディー・エヌ・エー / MySQL Casual / qpstudy / Shibuya.pm / Tsukuba.R
岩永 亮介 氏
モバゲーのサーバーサイド
オペレーションエンジニア
DBA
マネージャー
http://www.oreilly.co.jp/books/9784873114934/
ウェブオペレーション――サイト運用管理の実践テクニック
１６章 アジャイルインフラストラクチャ
読むべし
アプリケーションはインフラであり
インフラはアプリケーションである
●インフラはアプリケーションである
○運用の為に必要な要素
・性能管理
・オライリー キャパシティプランニング
1、現行のインフラがどの程度適切に機能しているか
2、許容可能なパフォーマンスぉ維持する為に何が必要か
・「配置」とは？
自動インストールツール
自動構成
・ビジネスメトリクス
アプリケーションメトリクス
システムメトリクス
監視とは継続的なテストである
Negios Plugin
○management(構成管理）
・どのサーバがどういうスペックでどういう役目でどういうステータスか？
○Collection（情報収集）
・あらゆる数値がどういう状態にあるか継続的に収集する
○Configuration（設定管理）
・役割毎にどういう設定にすべきかを管理
・設定がただ正しいか監視出来る
あらゆる事項を見やすく可視化する
可視化できるなら監視できる
○Touryou
・設定管理に特化したツール
・テンプレートのファイルと現在置かれているファイルを比較して、diffがあればNGとする
・Chefでも良かったが、組織で使う以上は何かカスタマイズを入れたくなる
testの仕組みが欲しかった
中央からsshでさくっといやりたかった(サーバー側で実行したくない)
そのため、Chefは使わず、自分で作った
自分で作ってしまった方が正解に近づく場合もある
かと言って、みんなが好き勝手作ればいいというわけではない
○コンポーネント間のプロトコルを先に考える
・API等
ファイル管理→DB管理に変わったとしても、APIだけいじれば修正出来る
API=Libraryではない
API=HTTP APIが近い
○運用の要素を分類して考えた
・必要なアプリは自分で書けばいい
・間のAPIだけは先に決めるべき
●アプリケーションはインフラである
○システムは成長する
・トレンドが変わったりして、どんどん変わって行く
・作って終わりはあり得ない
・動くものではなく、動き続けるものを作る
・今は動いていても、ちょっとしたら動かなくなるようなものを作っても仕方が無い
○.*Ops
・Operational Mentality
運用している時も、常に「今動いているけどそのうち動かなくなるな」
みたいなことを思っておいた方がいい
本当に怖いのは対立構造じゃなく、無関心になられること
運用しなくていいシステムよりも、運用が楽しくなるようなシステムを作る
みんなで運用する
普通だと運用中障害が起こったりして辛かったりする
●感想
まだ本格的に自分が責任者としてシステム運用をしたことはないが、
将来的には絶対に必要になる知識ばかりの内容だった。
自分の持っている知識としても弱い分野だったので、今後の参考にしていきたい。
また、Chefのような既存のツールを使わず、使いやすいように自分で開発したという話を聴いて、
「自分で作ろう」というエンジニアとして必要な発想が自分にはまだまだ弱いと感じた。
今後はただあるものを使うだけでなく、必要なものを自分で作るということもより意識していきたい。