少人数で自社サービスから受託案件まで数十ものサービスを提供するために実践しているDevOpsについて、技術的な内容から開発／運用の考え方について

1. SonicGarden流
2013年9月28日
JAWS FESTA Kansai 2013
安達 輝雄 (interu)

2. 自己紹介
安達 輝雄 (Teruo Adachi)
昔はバリバリのインフラ屋。
今は開発からインフラまで幅広く対応。
自称フルスタックエンジニア
福岡出身の独身エンジニア 30歳
創業メンバー

3. SonicGardenについて

4. さっそく本題へ？

5. n ITにおける事業領域の拡大
n 業務のIT化からビジネスをIT化へ
最近のITサービス動向

6. 柔軟かつ継続的に進化可能なサービスを
望むビジネスオーナーが増加
最近のサービス動向
開発スタイルにも変化が。
ウォーターフォール から アジャイル へ
パッケージ から サービス へ

7. ここ最近のサービス動向を実現する
アプローチとしてDevOpsが注目！
最近のサービス動向

8. DevOpsって？

9. DevOpsとは
【引用】http://www.publickey1.jp/blog/11/devops.html

10. DevOpsとは
ビジネスゴールに向かって、
開発者(Dev)と運用者(Ops)が
互いに協力し合い、
柔軟かつSpeedyに
サービスを成長させるための
Practice Business
Value
Passion
Excitement
Skill
Knowledge

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

12. DevとOpsが対立！
DevOpsの概念が浸透し始める以前は・・・
これは開発側の仕事だ！いや、運用側の仕事だ！
この障害はアプリが原因だ！開発側は早急に対応しろ！
運用側がミドルウェアのバージョンアップ対応を
してくれないから迅速な対応は難しい！
現場は・・・

13. これまでは、開発／運用を分離し、
各々の範囲内での部分最適化が進められてきた
【開発】フレームワーク／テストツール
【運用】仮想化／冗長化 成熟化！
DevOpsの考え方で
最適化フェーズに突入！
なぜDevとOpsが対立してたのか？

14. DevとOpsが垣根を越える
アプローチはさまざま
運用者がインフラの構成管理／構築自
動化をやりやすくしただけでなく、プ
ログラマブルであることで開発者も理
解しやすい仕組みであるツール
代表的なツール

15. Chef = DevOps
なのだろうか？

16. 必ずしもそうとは言えません！！
DevOpsの定義を思い出してください。

17. ビジネスゴールに向かって、
開発者(Dev)と運用者(Ops)が
互いに協力し合い、
柔軟かつSpeedyに
サービスを成長させるための
Practice

18. “ビジネスゴールに向かって”という
目的を見失ってはいませんか？
● 技術的興味
● 運用だけを考慮して効率化
ビジネスゴールに向かって、
開発者(Dev)と運用者(Ops)が
互いに協力し合い、
柔軟かつSpeedyに
サービスを成長させるための
Practice
NG

19. ちなみに

20. SonicGardenでも
2008〜2010年の間、
運用の効率化を目的として
を採用

21. なぜ やめた のか？

22. 2010年頃
n クラウドサービスの進化
n マルチテナントアーキテクチャの確立
n ハードウェアアーキテクチャの進化
技術進歩によりシステム構成トレンドにも変化が

23. マルチインスタンス型 から マルチテナント型 へ
複数台サーバ管理の運用効率化の価値が低下
EC2のAMIで管理する方式を採用
（一戸建て型） （集合住宅型）
システム構成の変化

24. 今はどうしているのか？

25. イケてるクラウドサービスの活用！
何でも自分たちで作るのではなく、
イケてるクラウドサービス(SaaS/PaaS/IaaS)を
積極的に活用することで、
開発／運用の一部のリソースをアウトソースして
ビジネスゴールへの近道を目指す
DevOpsの取り組み【１】

26. 採用しているクラウドサービス
OpsWorksが提供しているChefの仕組みを
活用するスタイルに変化
サーバ管理 AWS / Heroku
インフラ構築自動化 OpsWorks / Heroku / CloudInit
バージョン管理 GitHub / Gemnasium
エラー管理 Bugsnag / AirBrake
タスク管理 PivotalTracker
単体／統合テスト Rspec / Capybara / Serverspec
デプロイ自動化 OpsWorks / Heroku / 自社ツール
サービス監視 NewRelic / Munin / Nagios
バックアップ監視／管理 自社ツール

27. DevもOpsもクラウドサービスを
積極採用することで、
少人数でも20以上の
サービス開発／運用が可能に

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

29. “サービスについての考え方”の変化
DevOpsの取り組み【２】

30. 2008年からAWSを利用してきて
"障害を0にはできない"ことを痛感
【参考】http://interu.hatenablog.com/entry/20110425/1303731515
n いきなりインスタンスのフリーズ／リブート
n EBSパフォーマンス低下による影響
n ネットワーク/API障害によるアクセス不可
障害を許容するという考え方

31. ダウンしないことを目指さない
障害が発生した際に
どれだけ早く復旧できるか
を考えるように
障害を許容するという考え方
ダウンしないことにコストを費やし過ぎない
すぐに復旧するなら少しのダウンタイムは許容

32. 【参考】http://interu.hatenablog.com/entry/2012/10/09/122848
障害を許容するという考え方
障害検知から30分以内の復旧を目標に
n インスタンスは使い捨て
n リージョンを越えてのバックアップ（Data/AMI）
n ベンダーロックインの仕組みは利用しない
n LCC的発想によるインフラ構成の共通化

33. 同じ時期に
開発スタイルにも変化が

34. 不具合を許容するという考え方
どれだけ頑張ってもバグは発生する
不具合0を目指すより
発生した際にどれだけ早く直せるか
を考えるように
クリティカルな不具合は防ぐ
そうでないニッチな不具合は発生したらすぐに修正

35. 不具合を許容するという考え方
エラーを検知したらすぐに改修してデプロイを目標に
n エラー検出の仕組み整備
n シンプルなデプロイの仕組み
n リリース間隔の短縮
n デグレ／再発防止のためにテストコード
n 新しいフレームワークの利用

36. 不具合／障害が発生しても
迅速に対応するという考え方により
n ビジネスゴールに到達するために費やせる
開発リソースの増加
ビジネスゴールへのスピードを加速
不具合数
改修コスト
ここまで対応！

37. 許容の裏には厳しい制約も存在
n ソースコードレビューの実施
●
考慮漏れ／ミスの排除
●
質の悪いコードの排除
n DevとOpsのスキルを要求
●
サービスに責任を持つ
●
開発／運用の全体最適を考える
品質向上！
対立排除！

38. この制約で苦しんだメンバーも・・・
http://blog.jnito.com/
兵庫県在住の
NOMAD Programmer
人気ブロガー
西脇のパン屋さんの夫でお馴染み！
2012年採用メンバー！

39. http://blog.jnito.com/entry/2012/07/25/082843
「ソニックガーデンに入社して１ヶ月が過ぎました」
当たり前と言えば当たり前ですが、
求められるハードルがめっちゃ高い！
先輩プログラマが持っているスキルもめっちゃ高い！
この格差は一体なんなの！？
ホンマに一番の下手くそになったら、
毎日すごいプレッシャーやぞ！！

40. 厳しい制約を課したことでの効果
n エンジニアのスキル向上
n アプリ／インフラともにシンプルな仕組みに

41. 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
制約を課す前

42. 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

43. 制約を課した後
厳しい制約を課したことによる効果
n 足りない能力を互いに補完
n ペアオペ／ペアプロにて互いに教育
n 観点が増えることで得意領域の能力も上昇
チームとしての成長も！
DevとOpsという役割分割も排除！

44. 許容／シンプル化により
いろいろと失ってるモノもあるのでは？
と思われますよね？

45. 失ったもの
n サービス稼働率100%の保証
n 不具合が限りなくゼロであるという保証
保証しているところあるの？？

46. 実際のところ
サービス稼働率 とか
どうなのよ？？

47. 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回
費用対効果から考えても良い値

48. 稼働率維持／向上は、
すべてAWSのような
クラウドサービスの
品質向上のおかげでもあります！
万歳！

49. 考え方の変化で
得たもの／失ったもの
いろいろありますが・・・

50. 失うものより得るモノの価値が大きい
エンドユーザの満足度

51. 他にも実践しているDevOpsはありますが、
それらはこの後の懇親会で！
最後にまとめ。

52. まとめ
n イケてるクラウドを積極的に利用
n 厳しい制約を課すことで、シンプルを善とし、
障害／不具合の発生を許容する考え方
におけるビジネスゴールを
より早く実現するDevOpsの取り組み

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