SonicGarden流

2013年9月28日JAWS FESTA Kansai 2013

安達 輝雄 (interu)

自己紹介

安達 輝雄 (Teruo Adachi)

昔はバリバリのインフラ屋。今は開発からインフラまで幅広く対応。自称フルスタックエンジニア

福岡出身の独身エンジニア 30歳

創業メンバー

SonicGardenについて

さっそく本題へ？

n ITにおける事業領域の拡大

n 業務のIT化からビジネスをIT化へ

最近のITサービス動向

柔軟かつ継続的に進化可能なサービスを望むビジネスオーナーが増加

最近のサービス動向

開発スタイルにも変化が。

ウォーターフォール から アジャイル へ　

パッケージ　 から　サービス へ

ここ最近のサービス動向を実現する

アプローチとしてDevOpsが注目！

最近のサービス動向

DevOpsって？

DevOpsとは

【引用】http://www.publickey1.jp/blog/11/devops.html

DevOpsとは

ビジネスゴールに向かって、

開発者(Dev)と運用者(Ops)が

互いに協力し合い、

柔軟かつSpeedyに

サービスを成長させるための

PracticeBusiness

Value

PassionExcitement

SkillKnowledge

ホントにDevOpsって大事なの？

DevとOpsが対立！

DevOpsの概念が浸透し始める以前は・・・

これは開発側の仕事だ！いや、運用側の仕事だ！

この障害はアプリが原因だ！開発側は早急に対応しろ！

運用側がミドルウェアのバージョンアップ対応をしてくれないから迅速な対応は難しい！

現場は・・・

これまでは、開発／運用を分離し、各々の範囲内での部分最適化が進められてきた

【開発】フレームワーク／テストツール

【運用】仮想化／冗長化 成熟化！

DevOpsの考え方で最適化フェーズに突入！

なぜDevとOpsが対立してたのか？

DevとOpsが垣根を越えるアプローチはさまざま

運用者がインフラの構成管理／構築自動化をやりやすくしただけでなく、プログラマブルであることで開発者も理解しやすい仕組みであるツール

代表的なツール

Chef = DevOps

なのだろうか？

必ずしもそうとは言えません！！

DevOpsの定義を思い出してください。

ビジネスゴールに向かって、

開発者(Dev)と運用者(Ops)が

互いに協力し合い、

柔軟かつSpeedyに

サービスを成長させるための

Practice

“ビジネスゴールに向かって”という

目的を見失ってはいませんか？

● 技術的興味● 運用だけを考慮して効率化 ビジネスゴールに向かって、

開発者(Dev)と運用者(Ops)が

互いに協力し合い、

柔軟かつSpeedyに

サービスを成長させるための

Practice

NG

ちなみに

SonicGardenでも

2008〜2010年の間、

運用の効率化を目的として

を採用

なぜ やめた のか？

2010年頃n クラウドサービスの進化

n マルチテナントアーキテクチャの確立

n ハードウェアアーキテクチャの進化

技術進歩によりシステム構成トレンドにも変化が

マルチインスタンス型 から マルチテナント型 へ

複数台サーバ管理の運用効率化の価値が低下

EC2のAMIで管理する方式を採用

（一戸建て型） （集合住宅型）

システム構成の変化

今はどうしているのか？

イケてるクラウドサービスの活用！

何でも自分たちで作るのではなく、イケてるクラウドサービス(SaaS/PaaS/IaaS)を

積極的に活用することで、

開発／運用の一部のリソースをアウトソースして

ビジネスゴールへの近道を目指す

DevOpsの取り組み【１】

採用しているクラウドサービス

OpsWorksが提供しているChefの仕組みを活用するスタイルに変化

サーバ管理 AWS / Heroku

インフラ構築自動化 OpsWorks / Heroku / CloudInit

バージョン管理 GitHub / Gemnasium

エラー管理 Bugsnag / AirBrake

タスク管理 PivotalTracker

単体／統合テスト Rspec / Capybara / Serverspec

デプロイ自動化 OpsWorks / Heroku / 自社ツール

サービス監視 NewRelic / Munin / Nagios

バックアップ監視／管理 自社ツール

DevもOpsもクラウドサービスを積極採用することで、

少人数でも20以上のサービス開発／運用が可能に

他にも

クラウドの進化や経験により変化したこと／ものはさまざま

“サービスについての考え方”の変化

DevOpsの取り組み【２】

2008年からAWSを利用してきて

"障害を0にはできない"ことを痛感

【参考】http://interu.hatenablog.com/entry/20110425/1303731515

n いきなりインスタンスのフリーズ／リブート

n EBSパフォーマンス低下による影響

n ネットワーク/API障害によるアクセス不可

障害を許容するという考え方

ダウンしないことを目指さない障害が発生した際に

どれだけ早く復旧できるかを考えるように

障害を許容するという考え方

ダウンしないことにコストを費やし過ぎないすぐに復旧するなら少しのダウンタイムは許容

【参考】http://interu.hatenablog.com/entry/2012/10/09/122848

障害を許容するという考え方

障害検知から30分以内の復旧を目標に

n インスタンスは使い捨て

n リージョンを越えてのバックアップ（Data/AMI）

n ベンダーロックインの仕組みは利用しない

n LCC的発想によるインフラ構成の共通化

同じ時期に

開発スタイルにも変化が

不具合を許容するという考え方

どれだけ頑張ってもバグは発生する

不具合0を目指すより

発生した際にどれだけ早く直せるかを考えるように

クリティカルな不具合は防ぐそうでないニッチな不具合は発生したらすぐに修正

不具合を許容するという考え方

エラーを検知したらすぐに改修してデプロイを目標に

n エラー検出の仕組み整備

n シンプルなデプロイの仕組み

n リリース間隔の短縮

n デグレ／再発防止のためにテストコード

n 新しいフレームワークの利用

不具合／障害が発生しても迅速に対応するという考え方によりn ビジネスゴールに到達するために費やせる

開発リソースの増加

ビジネスゴールへのスピードを加速

不具合数

改修コスト

ここまで対応！

許容の裏には厳しい制約も存在

n ソースコードレビューの実施● 考慮漏れ／ミスの排除● 質の悪いコードの排除

n DevとOpsのスキルを要求● サービスに責任を持つ● 開発／運用の全体最適を考える

品質向上！

対立排除！

この制約で苦しんだメンバーも・・・

http://blog.jnito.com/

兵庫県在住の

NOMAD Programmer

人気ブロガー

西脇のパン屋さんの夫でお馴染み！

2012年採用メンバー！

http://blog.jnito.com/entry/2012/07/25/082843

「ソニックガーデンに入社して１ヶ月が過ぎました」

　当たり前と言えば当たり前ですが、　求められるハードルがめっちゃ高い！

　先輩プログラマが持っているスキルもめっちゃ高い！　この格差は一体なんなの！？

　ホンマに一番の下手くそになったら、　毎日すごいプレッシャーやぞ！！

厳しい制約を課したことでの効果

n エンジニアのスキル向上

n アプリ／インフラともにシンプルな仕組みに

Lv 5

Lv 50 Lv 5

Lv 50

Lv 40 Lv 20

厳しい制約を課せたことによる効果

Dev 能力 Ops 能力

　　アプリ開発ならお任せ！ 　インフラわかんない

　まぁまぁわかるよ 　わからないこともない

　アプリわからない 　インフラなら任せとけ！

玄人Dev

一般エンジニア

玄人Ops

Level 50 Level 3

Level 15

Level 3

Level 20

Level 50

制約を課す前

Lv 5

Lv 50 Lv 5

Lv 50

Lv 40 Lv 20

厳しい制約を課したことによる効果

Dev 能力 Ops 能力

　インフラを意識++　わかりやすいコード++ 　基礎能力++

　わかりやすいコード++ 　インフラを経験++

　開発にも従事++ 　障害切り分け対応能力++

玄人Dev

一般エンジニア

玄人Ops

Level 50 ⇒ 60 Level 3 ⇒ 20

制約を課した後

Level 50 ⇒ 60Level 3 ⇒ 20

Level 20 ⇒ 30 Level 15 ⇒ 30

制約を課した後

厳しい制約を課したことによる効果

n 足りない能力を互いに補完

n ペアオペ／ペアプロにて互いに教育

n 観点が増えることで得意領域の能力も上昇

チームとしての成長も！

DevとOpsという役割分割も排除！

許容／シンプル化により

いろいろと失ってるモノもあるのでは？と思われますよね？

失ったもの

n サービス稼働率100%の保証n 不具合が限りなくゼロであるという保証

保証しているところあるの？？

実際のところ

サービス稼働率 とかどうなのよ？？

99.896%

メンテナンスを含まない場合は 99.974%

Gmailの2012年の正常稼働率は 99.983%http://news.mynavi.jp/news/2013/04/09/066/index.html

サービス稼働率

【期間】2013/01/01 〜 2013/09/26

メンテナンスによる停止：5時間弱インスタンス強制マイグレート：1回インスタンス障害：1回OSレイヤ以上の障害：2回

100.00% メンテナンスによる停止：0分インスタンス強制マイグレート：1回インスタンス障害：0回

費用対効果から考えても良い値

稼働率維持／向上は、

すべてAWSのようなクラウドサービスの

品質向上のおかげでもあります！

　　　　　万歳！

考え方の変化で得たもの／失ったもの

いろいろありますが・・・

失うものより得るモノの価値が大きい

エンドユーザの満足度

他にも実践しているDevOpsはありますが、

それらはこの後の懇親会で！

最後にまとめ。

まとめ

n イケてるクラウドを積極的に利用n 厳しい制約を課すことで、シンプルを善とし、障害／不具合の発生を許容する考え方

　　　　　　におけるビジネスゴールをより早く実現するDevOpsの取り組み

ご清聴ありがとうございました。