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