©  2014  Amazon.com,  Inc.  and  its  affiliates.  All  rights  reserved.  May  not  be  copied,  modified,  or  distribut...
運⽤用を考えるべき理理由とは?
IT関連コストの内訳と今後の⾒見見通し
「企業情報システムの運⽤用管理理に関する実態調査」2013年年  ⽇日経BP
45%が「運⽤用コスト」  
保守を含めれば75%
パネラー紹介
• 波⽥田野  裕⼀一  
– 運⽤用設計ラボ  代表社員  
• 澤登  亨彦    
– HiganWorks  LLC  代表社員  
– OpsRock  LLC  業務執⾏行行社員  
• 今井  ⼤大介    
– 株...
波⽥田野  裕⼀一  

運⽤用設計ラボ合同会社  代表社員
• AWS歴  
– 初体験は2010年年頃(EC2)  
– 本格的に触り始めたのは昨年年12⽉月  
– 今年年2⽉月にAPN(パートナ)に登録
波⽥田野  裕⼀一  

「レガシー運⽤用」に詳しい
澤登  享彦

HiganWorks  LLC  代表社員
• HiganWorks合同会社  
– 構築運⽤用と⾃自動化全般  
• OpsRock合同会社  
– Chef関連(AWS  OpsWorksも)レシピ作成や、Serverspe...
澤登  享彦

Infrastructure  as  codeの普及に努⼒力力中
• 著作  Chef活⽤用ガイド(アスキー・
メディアワークス)  
• 最近、ChefつながりでOpsWorksの
解説を頼まれる
今井  ⼤大介  

株式会社ネットプライスドットコム  執⾏行行役員  エンジニアリング本部⻑⾧長

• ギガフロップス株式会社(起業):CTO  
• 株式会社サイバード(会社売却):技術部でエンジニアのマネジ
メント  しつつ、⼤大量量の...
今井  ⼤大介  

AWSでDevOpsを実現するCLI作成運⽤用中
• BEENOS株式会社:事業⽴立立ち上げ屋。いくつかの
事業⽴立立ち上げを⾏行行い、  現在は新規事業担当エン
ジニア、デザイナチームを率率率いる。    
• オレオレ...
運⽤用の現場、状況
Operation Lab
運用設計ラボ
運用の現場、状況
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
Operation Lab
運用設計ラボ
理想の「運用」を追い求めて
‣サービスの安定
社会基盤に相応しい安定運用
‣業務負荷が平準的
個々人ががんばりすぎなくても業務が回る運用現場
‣運用に対する評価が適正
適正な利潤を生む現場と、適切に評価...
運用現場における典型的な声 (1)
✓ 業務が多岐に渡り、全てを把握することが困難になっている。
✓ 業務の設計思想が失われていて、すでにどうにもならない?
✓ ドキュメントが整備されていない。あっても更新されていない。
✓ どんなドキュメント...
運用現場における典型的な声 (2)
✓ 人が育たない。優秀な人が入ってこない、定着しない。
✓ がんばっても評価されない。
✓ 業務や現場自体が評価されている実感がない。
✓ 運用作業やトラブルが多く、前向きな改善に着手する余裕がない。
✓ ツ...
運用現場における典型的な声 (3)
✓ サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」など設計
側のその場しのぎの影響を直接受ける。
✓ 個別に対応しすぎて、全てが特別対応に等しくなっている。
✓ 依頼されてから動き...
実は「運用現場の悩み」は共通
✓ 多くの現場が似たようなことで悩んでいる
実は自分のところだけじゃない
✓ 多くの問題点に共通の要素
複雑そうに見える問題点を解きほぐす
Operation Lab
運用設計ラボ
運用研究から見えてきた現実 (レガシー運用)
連載:現場視点からの運用方法論 第1回 見えない「運用」 - 疲弊する運用現場
http://thinkit.co.jp/story/2010/12/02/...
「運用」のたてつけがおかしい
人によって概念が異なる。
本当(?)の「運用」に対する予算がない
ドキュメントがない
属人的だ
障害が起きても、実は初動手順はない
設計が悪くてもフィードバックできない
じゃ、運用ってなんだ?
運用の妙は一心に存す
うまく機能を働かせ用いること、活用。
そのもののもつ機能を生かして用いること。活用。
(広辞苑 第六版)
(宋史岳飛伝、14世紀中葉)
(大辞泉)
Operation Lab
運用設計ラボ
運用現場の諸問題
1.高負荷
2.属人的
3.見えぬ費用対効果
ブラックボックス化
低付加価値化
業務が複雑化
「費用」は一定で「効果」は経年劣化する
「費用対効果」は勝手に低減していく
現場では制御不...
運用の現場、状況
今井大介 daisuke@beenos.com
BEENOS株式会社(現:株式会社ネットプライスドットコム)
執行役員 エンジニアリング本部長
スタートアップのサービス開発
• 「地図」ではなく「コンパス」を頼りに
• 「顧客開発」のアプローチ
• MVP(Minimum Viable Product):小さく生む
• Build - Measure - Learn:変化し続ける
Bu...
スタートアップをめぐる開発・運用の状況
【背景】
• 少人数での立ち上げ(インフラエンジニア不在)
• 若手中心の経験の浅いエンジニア
• Agileでイテレーション周期が短い
• ビジネスの検証を優先
【課題】
• 運用が考慮されない
• 変...
BEENOSの事業開発フロー
アイデア検
証
事業性検証
MVP
事業化
スケール
プロト
タイピング
プロダクト
開発
継続的開発
/ 運用
Dev
Ops
引き継ぎ
設計
BEENOSの事業開発フロー
アイデア検証
事業性検
MVP
事業化
スケール
プロト
タイピング
プロダクト
開発
継続的開発
/ 運用
Dev
Ops
BEENOSの事業開発フロー
アイデア検証
事業性検
MVP
事業化
スケール
プロト
タイピング
プロダクト
開発
継続的開発
/ 運用
アイデア検証
事業性検
MVP
事業化
スケール
プロト
タイピング
プロダクト
開発
継続的開発
/ ...
BEENOSの事業開発フロー
アイデア検
証
事業性検証
MVP
事業化
スケール
プロト
タイピング
プロダクト
開発
継続的開発
/ 運用
BEENOSの事業開発フロー
集中管理?分散協調?
オレオレ環境が生む悲劇
• 環境を作り開発した人だけしかわからないことがある
• 作った人も変化の中で試行錯誤してて結局どうなってるのかわからなくなっ
てしまう
• 次につくる時、また違うものを作ってしまう(故意・過失)
• 監視などの設定も他...
オレオレ環境が生む悲劇
【Dev】
• 手離れの悪い案件
• 再現性が低く、自分も改めてゼロから調査
【Ops】
• 「運用でカバー」などと言われる(人力運用)
• 安定しない運用(Bad Know-How)
• それが、延々と続く(終わらない...
オレオレ環境が生む悲劇
もちろん、
!
• セキュリティ
• SPOF
• スケールアウトに適さないアプリケーション
• ドキュメント不在、もしくは更新漏れ
など、多くのリスクも。
ダメ!ぜったい!
運用の現場、現状
澤登  享彦

HiganWorks  LLC  代表社員
Public/Private IaaSと
Infrastructure as Codeで
効率を上げる
クラウド x 構成管理ツール
★ APIによるサーバ調達と構成管理

=> 管理対象の動的取得

=> Chefなどで構成情報も継続更新
★ コードは再現性がある

=> 人による失敗も少なく

=> テストしやすい

=> 環境も移行しやすい
⾃自動化は運⽤用を救うのか?
Operation Lab
運用設計ラボ
自動化は運用を救うのか?
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
Operation Lab
運用設計ラボ
「自分達のやっていることの安定化&永続化のために」
自動化は「客観化」の先にある
脱属人化
客観化
整理
「記録」はドキュメント の本質的な基礎機能記録
「書く」という作業により「整理」されていく
「有...
Operation Lab
運用設計ラボ
運用の自動化は、「客観化の結果」であって「目的」ではない。
「自動化」について注意したいこと
「自分達のやっていることの品質安定化&永続化のために」、目的:
手段: 自動 「客観化(構造化)された業務の...
Operation Lab
運用設計ラボ
DevとOpsの「目的」と「手段」
大量生産
工場型モデル
研究所型モデル
受注生産
工場型モデル
Dev
Ops 目的 手段
目的 手段
目的 手段
自動化は運用を救うのか
澤登  享彦

HiganWorks  LLC  代表社員
運用は
『設計+構成管理』から
設計の前提条件を更新
★ 物理/LANをベースにしたシステムの信頼性判断
を見直す
★ 各コンポーネントの独立性を重視して、組み合わ
せによる耐障害性を高める
上流からの最適化
★ 役割ベースでシステム構成を管理
★ PaaS/SaaSなども考慮可能に

=> 自前の運用負担を減少
★ 替えが利く ことを活かす障害対応
★ オンプレでもできればIaaS上に

=> 構築使い回しで再現性・可搬性
Developerと
ツールやスキルを共有
コードにしていくということ
★ インフラの要素をモデル化し、

コードの実行=>構築・構成変更
★ Githubやテストスイート、各種ツールとのインテグレー
ション
★ 初期段階からデプロイまで含めてDevとAgileで
★ 運用フェーズの課題...
自動化は運用を救うか
今井大介 daisuke@beenos.com
BEENOS株式会社(現:株式会社ネットプライスドットコム)
執行役員 エンジニアリング本部長
学ぶ(真似ぶ)モデルとしてのインフラ構築
良いベース環境をつくる
よく考えられた環境には理由がある。(AWS CDP参照)
環境理解を進める中で、設計の意味を知る。
ベストプラクティスをコードで残す
読解可能で、再現性がある。
マニュアルでもい...
ではCloudFormationとOpsWorksを勉強して、
環境構築してください。
「はい、任せてください。」「え?無理でしょ!」
自動化環境を作っていけるのか?
• OpsWorks使える人∼?(OpsWorks自体の敷居の高さ)
• OpsWorksで全部作れるんだっけ?
• Web画面での操作とか、再現性の低い
• というか、AWSマネジメントコンソールすぐUI変わっ...
ということで、環境つくりました。(昨年)
オレオレ環境を生み出さないため、環境構築からすべてコマンド化
./bin/hornet magic new_service
(CloudFormationとOpsWorksのAPIのラッパー)
※CLI...
hornetコマンドで作られる基本構成(想定)
Staging Stack Production Stack
Rails Layer
Rails InstancesNAT Instance
RDS
Rails Layer
Rails Insta...
サービスへの適用(ところが)
最初の案件が大型のEC案件でしかも短納期
・VPC環境とNATインスタンス
・S3とCloudFront
・RDS(MultiAZ)
・ElastiCache(Redis) v.s. DynamoDB
・PHPのW...
Staging/Production Stack
Web Layer
PHP Instances
NAT Instance
RDS
Admin Layer
PHP Instances
Gateway Layer
ElastiCache
S3
C...
クラウド時代の運⽤用とエンジニアと
は?
クラウド時代の運用と
エンジニアとは
澤登  享彦

HiganWorks  LLC  代表社員
既存ワークフローの
こだわり要素を
アップデート
こだわり対象の更新
★ ネットワーク・サーバのインフラへのこだわり
★ 耐障害性とか、復旧フローとか
★(多分)同等のこだわりをクラウドベンダも持って
いる

=> 労力を新しい要素に向ける

=> マルチベンダを苦にしないこと
基準はエンドユーザ
★ 調達のコスト、iDCインフラ冗長化のコスト

=> 避けたかったリスクの見なおし
★ 抽象化をベースに視点を省略する

=> 構築や管理の労力を削減
クラウド時代の運用とエンジニアとは?
今井大介 daisuke@beenos.com
BEENOS株式会社(現:株式会社ネットプライスドットコム)
執行役員 エンジニアリング本部長
Dev→Opsへ
• とりあえず、(これだけ盛り込んでても)最低限の運用はできる
• 環境を変えようとした時に、ちょっとわかんなくてサーバーで直接環境変
えちゃう(作業の完全な再現が難しい)
• Deploy時、インスタンス追加時など、後に地獄...
わかってる人に構築してもらい
構築された環境からベストプラクティスを学ぶ
AWSでの運用は、そうでない場合と何が違うのか
AWSに足りないもの、AWSにほしいもの
クラウド時代の「運用」を担う人が使うべきツール
とは?
インフラ寄りからサーバーサイドアプリケーションま
で書ける人とか、非常に価値が高いです。
絶賛求人中です!一緒に働きましょう!
Operation Lab
運用設計ラボ
クラウド時代の運用とエンジニアとは?
運用設計ラボ合同会社
シニアアーキテクト 波田野 裕一
Operation Lab
運用設計ラボ
クラウド運用のキーワード
「問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのがエ
ンジニアの仕事です」
@yoshiori
構造化
ここでは「エンジニアリング(工学)の実践」に近
...
Operation Lab
運用設計ラボ
サービス運用全体の流れ
顧客・外部サービス
Inbound Queue Outbound の繰り返し
outboundinbound
outboundinbound
外部支援組織
inbound
inb...
Operation Lab
運用設計ラボ
運用プロセスの構造化
サービス
工程
Step1
開
始
サービス
工程
Step2
サービス
工程
Step3
サービス
工程
Step4
サービス
工程
Step5
提
供
前処理inbound 本...
Operation Lab
運用設計ラボ
構造化された設計のドキュメント化
脱属人化
客観化
整理
Level.1
Level.2
Level.3
How
Why
設計
実装
CloudFormation
OpsWorks(Chef)AMI
ド...
Operation Lab
運用設計ラボ
インターネット運用は「安く、手間をかけず」が特徴で、運用設計とド
キュメンテーションがないがしろにされてきた。(企業の大小、社歴の長さ
を問わず)
運用ドキュメントを作る時間が…
今後は、リモートワーク...
Operation Lab
運用設計ラボ
• WhatやHowはコード(Infrastructure As Code)に残るが、Whyは人が自らドキュメントに書かなけ
れば残らない。
• クラウド時代になって、オンプレミスと比較してあらゆる制約...
AWS発⾏行行の運⽤用チェックリスト
• フラストレーションの無い運⽤用ができるようにベス
トプラクティスから抜き出されたチェックリスト  
!
• 基本編  
• エンタープライズ編  
• 監査とセキュリティ編
http://aws.ama...
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
Upcoming SlideShare
Loading in …5
×

20140717 awssummit2014-cloud-operation

4,491 views

Published on

AWSサミット東京2014の1日目、クラウド時代の運用パネルのパネラー、コーディネータの使用スライドです

Published in: Technology

20140717 awssummit2014-cloud-operation

  1. 1. ©  2014  Amazon.com,  Inc.  and  its  affiliates.  All  rights  reserved.  May  not  be  copied,  modified,  or  distributed  in  whole  or  in  part  without  the  express  consent  of  Amazon.com,   クラウド時代の運⽤用 July  17,  2014
  2. 2. 運⽤用を考えるべき理理由とは?
  3. 3. IT関連コストの内訳と今後の⾒見見通し 「企業情報システムの運⽤用管理理に関する実態調査」2013年年  ⽇日経BP 45%が「運⽤用コスト」   保守を含めれば75%
  4. 4. パネラー紹介 • 波⽥田野  裕⼀一   – 運⽤用設計ラボ  代表社員   • 澤登  亨彦     – HiganWorks  LLC  代表社員   – OpsRock  LLC  業務執⾏行行社員   • 今井  ⼤大介     – 株式会社ネットプライスドットコム  執⾏行行役員  エンジ ニアリング本部⻑⾧長   • モデレータ:荒⽊木  靖宏   – アマゾンデータサービスジャパン  プリンシパルソリ ューションアーキテクト
  5. 5. 波⽥田野  裕⼀一  
 運⽤用設計ラボ合同会社  代表社員 • AWS歴   – 初体験は2010年年頃(EC2)   – 本格的に触り始めたのは昨年年12⽉月   – 今年年2⽉月にAPN(パートナ)に登録
  6. 6. 波⽥田野  裕⼀一  
 「レガシー運⽤用」に詳しい
  7. 7. 澤登  享彦
 HiganWorks  LLC  代表社員 • HiganWorks合同会社   – 構築運⽤用と⾃自動化全般   • OpsRock合同会社   – Chef関連(AWS  OpsWorksも)レシピ作成や、Serverspecの Spec作成、導⼊入⽀支援など
  8. 8. 澤登  享彦
 Infrastructure  as  codeの普及に努⼒力力中 • 著作  Chef活⽤用ガイド(アスキー・ メディアワークス)   • 最近、ChefつながりでOpsWorksの 解説を頼まれる
  9. 9. 今井  ⼤大介  
 株式会社ネットプライスドットコム  執⾏行行役員  エンジニアリング本部⻑⾧長
 • ギガフロップス株式会社(起業):CTO   • 株式会社サイバード(会社売却):技術部でエンジニアのマネジ メント  しつつ、⼤大量量のモバイルサービス開発+運⽤用     • ⽯石⾒見見ケーブルビジョン株式会社:CATV局の⽴立立ち上げ、通信側 担当。光  ファイバの敷設~∼サーバー管理理~∼監視~∼ネットサービ スまで。  
  10. 10. 今井  ⼤大介  
 AWSでDevOpsを実現するCLI作成運⽤用中 • BEENOS株式会社:事業⽴立立ち上げ屋。いくつかの 事業⽴立立ち上げを⾏行行い、  現在は新規事業担当エン ジニア、デザイナチームを率率率いる。     • オレオレ環境を⽣生み出さないため、環境構築か らすべてコマンド化  
  11. 11. 運⽤用の現場、状況
  12. 12. Operation Lab 運用設計ラボ 運用の現場、状況 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一
  13. 13. Operation Lab 運用設計ラボ 理想の「運用」を追い求めて ‣サービスの安定 社会基盤に相応しい安定運用 ‣業務負荷が平準的 個々人ががんばりすぎなくても業務が回る運用現場 ‣運用に対する評価が適正 適正な利潤を生む現場と、適切に評価される要員 安定した運用 楽な運用 稼ぐ運用 主に2009夏-2011年初頭 いろんな運用現場の話を聞いてきました
  14. 14. 運用現場における典型的な声 (1) ✓ 業務が多岐に渡り、全てを把握することが困難になっている。 ✓ 業務の設計思想が失われていて、すでにどうにもならない? ✓ ドキュメントが整備されていない。あっても更新されていない。 ✓ どんなドキュメントが必要なのかがわからない。書き方がわからない。 ✓ 一部の人間にしかできない業務があり、業務が集中している。 ✓ 属人化が進み、ノウハウの継承ができていない。 ✓ 異動により現場が混乱することが多い。
 InternetWeek 2009 発表資料 より
  15. 15. 運用現場における典型的な声 (2) ✓ 人が育たない。優秀な人が入ってこない、定着しない。 ✓ がんばっても評価されない。 ✓ 業務や現場自体が評価されている実感がない。 ✓ 運用作業やトラブルが多く、前向きな改善に着手する余裕がない。 ✓ ツールが使いにくいが、改修にはコストと期間が必要なため我慢して使っている。 ✓ 新規のツールを設計したいが、どんな要求があるのか現場でもわかっていない。 InternetWeek 2009 発表資料 より
  16. 16. 運用現場における典型的な声 (3) ✓ サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」など設計 側のその場しのぎの影響を直接受ける。 ✓ 個別に対応しすぎて、全てが特別対応に等しくなっている。 ✓ 依頼されてから動き出すまでのリードタイムが長い。 ✓ 声の大きいユーザが強く、必要以上のサポートを強いられる。 ✓ コスト削減要求が強いが、どう効率化すべきなのかが見えない。 InternetWeek 2009 発表資料 より
  17. 17. 実は「運用現場の悩み」は共通 ✓ 多くの現場が似たようなことで悩んでいる 実は自分のところだけじゃない ✓ 多くの問題点に共通の要素 複雑そうに見える問題点を解きほぐす
  18. 18. Operation Lab 運用設計ラボ 運用研究から見えてきた現実 (レガシー運用) 連載:現場視点からの運用方法論 第1回 見えない「運用」 - 疲弊する運用現場 http://thinkit.co.jp/story/2010/12/02/1903
  19. 19. 「運用」のたてつけがおかしい 人によって概念が異なる。 本当(?)の「運用」に対する予算がない ドキュメントがない 属人的だ 障害が起きても、実は初動手順はない 設計が悪くてもフィードバックできない
  20. 20. じゃ、運用ってなんだ? 運用の妙は一心に存す うまく機能を働かせ用いること、活用。 そのもののもつ機能を生かして用いること。活用。 (広辞苑 第六版) (宋史岳飛伝、14世紀中葉) (大辞泉)
  21. 21. Operation Lab 運用設計ラボ 運用現場の諸問題 1.高負荷 2.属人的 3.見えぬ費用対効果 ブラックボックス化 低付加価値化 業務が複雑化 「費用」は一定で「効果」は経年劣化する 「費用対効果」は勝手に低減していく 現場では制御不能状態
  22. 22. 運用の現場、状況 今井大介 daisuke@beenos.com BEENOS株式会社(現:株式会社ネットプライスドットコム) 執行役員 エンジニアリング本部長
  23. 23. スタートアップのサービス開発 • 「地図」ではなく「コンパス」を頼りに • 「顧客開発」のアプローチ • MVP(Minimum Viable Product):小さく生む • Build - Measure - Learn:変化し続ける BuildLearn Measure ProductData Ideas
  24. 24. スタートアップをめぐる開発・運用の状況 【背景】 • 少人数での立ち上げ(インフラエンジニア不在) • 若手中心の経験の浅いエンジニア • Agileでイテレーション周期が短い • ビジネスの検証を優先 【課題】 • 運用が考慮されない • 変化し続けるプロダクト(枯れない) • 属人的な知識や経験への依存が強い(自分だけが知っていればいい)
  25. 25. BEENOSの事業開発フロー アイデア検 証 事業性検証 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用 Dev Ops 引き継ぎ 設計
  26. 26. BEENOSの事業開発フロー アイデア検証 事業性検 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用 Dev Ops
  27. 27. BEENOSの事業開発フロー アイデア検証 事業性検 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用 アイデア検証 事業性検 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用 アイデア検証 事業性検 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用 アイデア検証 事業性検 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用
  28. 28. BEENOSの事業開発フロー アイデア検 証 事業性検証 MVP 事業化 スケール プロト タイピング プロダクト 開発 継続的開発 / 運用
  29. 29. BEENOSの事業開発フロー 集中管理?分散協調?
  30. 30. オレオレ環境が生む悲劇 • 環境を作り開発した人だけしかわからないことがある • 作った人も変化の中で試行錯誤してて結局どうなってるのかわからなくなっ てしまう • 次につくる時、また違うものを作ってしまう(故意・過失) • 監視などの設定も他の人ができなくなっている • Ops側もまず環境の理解をしないと、運用すらままならない 開発したエンジニア自体がボトルネック化
  31. 31. オレオレ環境が生む悲劇 【Dev】 • 手離れの悪い案件 • 再現性が低く、自分も改めてゼロから調査 【Ops】 • 「運用でカバー」などと言われる(人力運用) • 安定しない運用(Bad Know-How) • それが、延々と続く(終わらない苦しみ) 非効率・不確実(再現性)・積み重なる恨み
  32. 32. オレオレ環境が生む悲劇 もちろん、 ! • セキュリティ • SPOF • スケールアウトに適さないアプリケーション • ドキュメント不在、もしくは更新漏れ など、多くのリスクも。 ダメ!ぜったい!
  33. 33. 運用の現場、現状 澤登  享彦
 HiganWorks  LLC  代表社員
  34. 34. Public/Private IaaSと Infrastructure as Codeで 効率を上げる
  35. 35. クラウド x 構成管理ツール ★ APIによるサーバ調達と構成管理
 => 管理対象の動的取得
 => Chefなどで構成情報も継続更新 ★ コードは再現性がある
 => 人による失敗も少なく
 => テストしやすい
 => 環境も移行しやすい
  36. 36. ⾃自動化は運⽤用を救うのか?
  37. 37. Operation Lab 運用設計ラボ 自動化は運用を救うのか? 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一
  38. 38. Operation Lab 運用設計ラボ 「自分達のやっていることの安定化&永続化のために」 自動化は「客観化」の先にある 脱属人化 客観化 整理 「記録」はドキュメント の本質的な基礎機能記録 「書く」という作業により「整理」されていく 「有形の成果物」となることで「客観化」されていく 時と空間を超えて知見が共有されていく Level.0 Level.1 Level.2 Level.3 自動化はココ 「自分達のやっていることを知る&改善するために」 「自分達のやっていることの説明&(自己・他者)評価のために」 出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1 業務企画 業務設計
  39. 39. Operation Lab 運用設計ラボ 運用の自動化は、「客観化の結果」であって「目的」ではない。 「自動化」について注意したいこと 「自分達のやっていることの品質安定化&永続化のために」、目的: 手段: 自動 「客観化(構造化)された業務の一部」を自動化する。 「目的と手段がひっくりかえる」ことは、よくある 「自動化が目的」の弊害 • 「自動化された業務」の保守が属人化する。 • 「自動化された業務」の仕様が不明になり、業務プロセスが硬直化する。 • 「自動化された業務」でトラブルが発生すると、手動ではリカバリができない。(手順がわからない)
  40. 40. Operation Lab 運用設計ラボ DevとOpsの「目的」と「手段」 大量生産 工場型モデル 研究所型モデル 受注生産 工場型モデル Dev Ops 目的 手段 目的 手段 目的 手段
  41. 41. 自動化は運用を救うのか 澤登  享彦
 HiganWorks  LLC  代表社員
  42. 42. 運用は 『設計+構成管理』から
  43. 43. 設計の前提条件を更新 ★ 物理/LANをベースにしたシステムの信頼性判断 を見直す ★ 各コンポーネントの独立性を重視して、組み合わ せによる耐障害性を高める
  44. 44. 上流からの最適化 ★ 役割ベースでシステム構成を管理 ★ PaaS/SaaSなども考慮可能に
 => 自前の運用負担を減少 ★ 替えが利く ことを活かす障害対応 ★ オンプレでもできればIaaS上に
 => 構築使い回しで再現性・可搬性
  45. 45. Developerと ツールやスキルを共有
  46. 46. コードにしていくということ ★ インフラの要素をモデル化し、
 コードの実行=>構築・構成変更 ★ Githubやテストスイート、各種ツールとのインテグレー ション ★ 初期段階からデプロイまで含めてDevとAgileで ★ 運用フェーズの課題も見えやすい
  47. 47. 自動化は運用を救うか 今井大介 daisuke@beenos.com BEENOS株式会社(現:株式会社ネットプライスドットコム) 執行役員 エンジニアリング本部長
  48. 48. 学ぶ(真似ぶ)モデルとしてのインフラ構築 良いベース環境をつくる よく考えられた環境には理由がある。(AWS CDP参照) 環境理解を進める中で、設計の意味を知る。 ベストプラクティスをコードで残す 読解可能で、再現性がある。 マニュアルでもいいが、どちらか一方ならコード。 開発・運用の「環境による制約」が悪癖を防ぐ 正しい形で運用すれば、楽で安全である 間違うと苦しむ 理解(知識の移植)と実務の分離 環境について理解が浅くても運用が回せる状態にする
  49. 49. ではCloudFormationとOpsWorksを勉強して、 環境構築してください。 「はい、任せてください。」「え?無理でしょ!」
  50. 50. 自動化環境を作っていけるのか? • OpsWorks使える人∼?(OpsWorks自体の敷居の高さ) • OpsWorksで全部作れるんだっけ? • Web画面での操作とか、再現性の低い • というか、AWSマネジメントコンソールすぐUI変わっちゃうし • CLIからの操作も手で打ってるんじゃ意味ないよね • そもそも構築のベストプラクティス理解してるんだっけ?AWS CDP頭に 入ってる人∼? • 広大すぎるAWSの世界
  51. 51. ということで、環境つくりました。(昨年) オレオレ環境を生み出さないため、環境構築からすべてコマンド化 ./bin/hornet magic new_service (CloudFormationとOpsWorksのAPIのラッパー) ※CLIでの運用ならGithubでインフラ管理できる! ! 標準環境として、素早いプロトタイピングのためのシンプルな環境のtemplateを用意 ・VPC環境とNATインスタンス ・RDS ・Stack: StagingとProduction ・Ruby on railsのWebApplication LayerとELB を想定
  52. 52. hornetコマンドで作られる基本構成(想定) Staging Stack Production Stack Rails Layer Rails InstancesNAT Instance RDS Rails Layer Rails InstancesNAT Instance RDS
  53. 53. サービスへの適用(ところが) 最初の案件が大型のEC案件でしかも短納期 ・VPC環境とNATインスタンス ・S3とCloudFront ・RDS(MultiAZ) ・ElastiCache(Redis) v.s. DynamoDB ・PHPのWebApplication LayerとELB ・外部APIと通信のためのGateway LayerとELB ! 要件がどんどん追加、環境が変化していく
  54. 54. Staging/Production Stack Web Layer PHP Instances NAT Instance RDS Admin Layer PHP Instances Gateway Layer ElastiCache S3 CloudFront DynamoDB サービス環境の構成
  55. 55. クラウド時代の運⽤用とエンジニアと は?
  56. 56. クラウド時代の運用と エンジニアとは 澤登  享彦
 HiganWorks  LLC  代表社員
  57. 57. 既存ワークフローの こだわり要素を アップデート
  58. 58. こだわり対象の更新 ★ ネットワーク・サーバのインフラへのこだわり ★ 耐障害性とか、復旧フローとか ★(多分)同等のこだわりをクラウドベンダも持って いる
 => 労力を新しい要素に向ける
 => マルチベンダを苦にしないこと
  59. 59. 基準はエンドユーザ ★ 調達のコスト、iDCインフラ冗長化のコスト
 => 避けたかったリスクの見なおし ★ 抽象化をベースに視点を省略する
 => 構築や管理の労力を削減
  60. 60. クラウド時代の運用とエンジニアとは? 今井大介 daisuke@beenos.com BEENOS株式会社(現:株式会社ネットプライスドットコム) 執行役員 エンジニアリング本部長
  61. 61. Dev→Opsへ • とりあえず、(これだけ盛り込んでても)最低限の運用はできる • 環境を変えようとした時に、ちょっとわかんなくてサーバーで直接環境変 えちゃう(作業の完全な再現が難しい) • Deploy時、インスタンス追加時など、後に地獄を見る • しょうがない、きちんとRecipeでやろう • OpsWorksやCloudFormationの仕組みを知らないと困る→必要なところ から徐々に仕組みを理解していく • 環境による制約によって、きちんとせざるをえない。(やった!) 環境とコードによるベストプラクティスは人を育てる
  62. 62. わかってる人に構築してもらい 構築された環境からベストプラクティスを学ぶ
  63. 63. AWSでの運用は、そうでない場合と何が違うのか
  64. 64. AWSに足りないもの、AWSにほしいもの
  65. 65. クラウド時代の「運用」を担う人が使うべきツール とは?
  66. 66. インフラ寄りからサーバーサイドアプリケーションま で書ける人とか、非常に価値が高いです。 絶賛求人中です!一緒に働きましょう!
  67. 67. Operation Lab 運用設計ラボ クラウド時代の運用とエンジニアとは? 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一
  68. 68. Operation Lab 運用設計ラボ クラウド運用のキーワード 「問題を根性で解決するのは馬鹿です。 問題をエンジニアリングで解決するのがエ ンジニアの仕事です」 @yoshiori 構造化 ここでは「エンジニアリング(工学)の実践」に近 い意味で使います。 工学では何らかの構造物・構造体を作ることが不 可避なためです。 http://d.hatena.ne.jp/Yoshiori/20120217/1329491437
  69. 69. Operation Lab 運用設計ラボ サービス運用全体の流れ 顧客・外部サービス Inbound Queue Outbound の繰り返し outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound 出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」 EndPoint API 疎結合
  70. 70. Operation Lab 運用設計ラボ 運用プロセスの構造化 サービス 工程 Step1 開 始 サービス 工程 Step2 サービス 工程 Step3 サービス 工程 Step4 サービス 工程 Step5 提 供 前処理inbound 本作業 後処理 outboundinbound outbound Quality Cost Delivery データに語らせるのがエンジニアリング
  71. 71. Operation Lab 運用設計ラボ 構造化された設計のドキュメント化 脱属人化 客観化 整理 Level.1 Level.2 Level.3 How Why 設計 実装 CloudFormation OpsWorks(Chef)AMI ドキュメンテーション 乱雑でいいからメモを残す
  72. 72. Operation Lab 運用設計ラボ インターネット運用は「安く、手間をかけず」が特徴で、運用設計とド キュメンテーションがないがしろにされてきた。(企業の大小、社歴の長さ を問わず) 運用ドキュメントを作る時間が… 今後は、リモートワーク拡大、メンバーの流動性向上、サービスのライフサ イクル短期化(扱うサービス数の爆発的拡大)により、アンドキュメンテッド 設計&運用は致命的な「知識のロスト」を生む可能性が 生産ラインを最初に稼動させ、後から金型を作るようなもの 先に金型(設計&ドキュメント化)を作成してから、 生産ラインを稼動させるようになる CloudFormation OpsWorks(Chef)AMI アウトプットの「品質」定義が無い
  73. 73. Operation Lab 運用設計ラボ • WhatやHowはコード(Infrastructure As Code)に残るが、Whyは人が自らドキュメントに書かなけ れば残らない。 • クラウド時代になって、オンプレミスと比較してあらゆる制約が減少。制約が無い中で「なぜそうした か(Why)」を残す重要性が増加。 • 人(Why)とシステム(What/How)が分担してドキュメントを書く時代。 主張: クラウド時代の運用ドキュメンテーション How + Why = KnowHow 実装 設計 運用現場の資産
  74. 74. AWS発⾏行行の運⽤用チェックリスト • フラストレーションの無い運⽤用ができるようにベス トプラクティスから抜き出されたチェックリスト   ! • 基本編   • エンタープライズ編   • 監査とセキュリティ編 http://aws.amazon.com/whitepapers/ operational-‐‑‒checklists-‐‑‒for-‐‑‒aws/

×