20140717 awssummit2014-cloud-operation

運⽤用を考えるべき理理由とは？

IT関連コストの内訳と今後の⾒見見通し「企業情報システムの運⽤用管理理に関する実態調査」2013年年　⽇日経BP 45％が「運⽤用コスト」保守を含めれば75％

パネラー紹介 • 波⽥田野裕⼀一 – 運⽤用設計ラボ代表社員 • 澤登亨彦 – HiganWorks LLC 代表社員 – OpsRock LLC 業務執⾏行行社員 • 今井⼤大介 – 株式会社ネットプライスドットコム執⾏行行役員エンジニアリング本部⻑⾧長 • モデレータ：荒⽊木靖宏 – アマゾンデータサービスジャパンプリンシパルソリューションアーキテクト

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

波⽥田野裕⼀一   「レガシー運⽤用」に詳しい

澤登享彦  HiganWorks LLC 代表社員 • HiganWorks合同会社 – 構築運⽤用と⾃自動化全般 • OpsRock合同会社 – Chef関連（AWS OpsWorksも）レシピ作成や、Serverspecの Spec作成、導⼊入⽀支援など

澤登享彦  Infrastructure as codeの普及に努⼒力力中 • 著作　Chef活⽤用ガイド（アスキー・メディアワークス） • 最近、ChefつながりでOpsWorksの解説を頼まれる

今井⼤大介   株式会社ネットプライスドットコム執⾏行行役員エンジニアリング本部⻑⾧長  • ギガフロップス株式会社(起業):CTO • 株式会社サイバード(会社売却):技術部でエンジニアのマネジメントしつつ、⼤大量量のモバイルサービス開発+運⽤用 • ⽯石⾒見見ケーブルビジョン株式会社:CATV局の⽴立立ち上げ、通信側担当。光ファイバの敷設~∼サーバー管理理~∼監視~∼ネットサービスまで。

今井⼤大介   AWSでDevOpsを実現するCLI作成運⽤用中 • BEENOS株式会社:事業⽴立立ち上げ屋。いくつかの事業⽴立立ち上げを⾏行行い、現在は新規事業担当エンジニア、デザイナチームを率率率いる。 • オレオレ環境を⽣生み出さないため、環境構築からすべてコマンド化

運⽤用の現場、状況

Operation Lab 運用設計ラボ運用の現場、状況運用設計ラボ合同会社シニアアーキテクト波田野裕一

Operation Lab 運用設計ラボ理想の「運用」を追い求めて ‣サービスの安定社会基盤に相応しい安定運用 ‣業務負荷が平準的個々人ががんばりすぎなくても業務が回る運用現場 ‣運用に対する評価が適正適正な利潤を生む現場と、適切に評価される要員安定した運用楽な運用稼ぐ運用主に2009夏-2011年初頭いろんな運用現場の話を聞いてきました

運用現場における典型的な声 (1) ✓ 業務が多岐に渡り、全てを把握することが困難になっている。 ✓ 業務の設計思想が失われていて、すでにどうにもならない? ✓ ドキュメントが整備されていない。あっても更新されていない。 ✓ どんなドキュメントが必要なのかがわからない。書き方がわからない。 ✓ 一部の人間にしかできない業務があり、業務が集中している。 ✓ 属人化が進み、ノウハウの継承ができていない。 ✓ 異動により現場が混乱することが多い。  InternetWeek 2009 発表資料より

運用現場における典型的な声 (2) ✓ 人が育たない。優秀な人が入ってこない、定着しない。 ✓ がんばっても評価されない。 ✓ 業務や現場自体が評価されている実感がない。 ✓ 運用作業やトラブルが多く、前向きな改善に着手する余裕がない。 ✓ ツールが使いにくいが、改修にはコストと期間が必要なため我慢して使っている。 ✓ 新規のツールを設計したいが、どんな要求があるのか現場でもわかっていない。 InternetWeek 2009 発表資料より

運用現場における典型的な声 (3) ✓ サービス設計導入時の検討漏れや実装が間にあわない部分を「運用でカバーする」など設計側のその場しのぎの影響を直接受ける。 ✓ 個別に対応しすぎて、全てが特別対応に等しくなっている。 ✓ 依頼されてから動き出すまでのリードタイムが長い。 ✓ 声の大きいユーザが強く、必要以上のサポートを強いられる。 ✓ コスト削減要求が強いが、どう効率化すべきなのかが見えない。 InternetWeek 2009 発表資料より

実は「運用現場の悩み」は共通 ✓ 多くの現場が似たようなことで悩んでいる実は自分のところだけじゃない ✓ 多くの問題点に共通の要素複雑そうに見える問題点を解きほぐす

Operation Lab 運用設計ラボ運用研究から見えてきた現実 (レガシー運用) 連載：現場視点からの運用方法論第1回見えない「運用」 - 疲弊する運用現場 http://thinkit.co.jp/story/2010/12/02/1903

「運用」のたてつけがおかしい人によって概念が異なる。本当(?)の「運用」に対する予算がないドキュメントがない属人的だ障害が起きても、実は初動手順はない設計が悪くてもフィードバックできない

じゃ、運用ってなんだ? 運用の妙は一心に存すうまく機能を働かせ用いること、活用。そのもののもつ機能を生かして用いること。活用。 (広辞苑第六版) (宋史岳飛伝、14世紀中葉) (大辞泉)

Operation Lab 運用設計ラボ運用現場の諸問題 1.高負荷 2.属人的 3.見えぬ費用対効果ブラックボックス化低付加価値化業務が複雑化「費用」は一定で「効果」は経年劣化する「費用対効果」は勝手に低減していく現場では制御不能状態

運用の現場、状況今井大介 daisuke@beenos.com BEENOS株式会社（現：株式会社ネットプライスドットコム）執行役員エンジニアリング本部長

スタートアップのサービス開発 • 「地図」ではなく「コンパス」を頼りに • 「顧客開発」のアプローチ • MVP（Minimum Viable Product）：小さく生む • Build - Measure - Learn：変化し続ける BuildLearn Measure ProductData Ideas

スタートアップをめぐる開発・運用の状況【背景】 • 少人数での立ち上げ（インフラエンジニア不在） • 若手中心の経験の浅いエンジニア • Agileでイテレーション周期が短い • ビジネスの検証を優先【課題】 • 運用が考慮されない • 変化し続けるプロダクト（枯れない） • 属人的な知識や経験への依存が強い（自分だけが知っていればいい）

BEENOSの事業開発フローアイデア検証事業性検証 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用 Dev Ops 引き継ぎ設計

BEENOSの事業開発フローアイデア検証事業性検 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用 Dev Ops

BEENOSの事業開発フローアイデア検証事業性検 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用アイデア検証事業性検 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用アイデア検証事業性検 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用アイデア検証事業性検 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用

BEENOSの事業開発フローアイデア検証事業性検証 MVP 事業化スケールプロトタイピングプロダクト開発継続的開発 / 運用

BEENOSの事業開発フロー集中管理？分散協調？

オレオレ環境が生む悲劇 • 環境を作り開発した人だけしかわからないことがある • 作った人も変化の中で試行錯誤してて結局どうなってるのかわからなくなってしまう • 次につくる時、また違うものを作ってしまう（故意・過失） • 監視などの設定も他の人ができなくなっている • Ops側もまず環境の理解をしないと、運用すらままならない開発したエンジニア自体がボトルネック化

オレオレ環境が生む悲劇【Dev】 • 手離れの悪い案件 • 再現性が低く、自分も改めてゼロから調査【Ops】 • 「運用でカバー」などと言われる（人力運用） • 安定しない運用（Bad Know-How） • それが、延々と続く（終わらない苦しみ）非効率・不確実（再現性）・積み重なる恨み

オレオレ環境が生む悲劇もちろん、 ! • セキュリティ • SPOF • スケールアウトに適さないアプリケーション • ドキュメント不在、もしくは更新漏れなど、多くのリスクも。ダメ！ぜったい！

運用の現場、現状澤登享彦  HiganWorks LLC 代表社員

Public/Private IaaSと Infrastructure as Codeで効率を上げる

クラウド x 構成管理ツール ★ APIによるサーバ調達と構成管理  => 管理対象の動的取得  => Chefなどで構成情報も継続更新 ★ コードは再現性がある  => 人による失敗も少なく  => テストしやすい  => 環境も移行しやすい

⾃自動化は運⽤用を救うのか？

Operation Lab 運用設計ラボ自動化は運用を救うのか？運用設計ラボ合同会社シニアアーキテクト波田野裕一

Operation Lab 運用設計ラボ「自分達のやっていることの安定化&永続化のために」自動化は「客観化」の先にある脱属人化客観化整理「記録」はドキュメントの本質的な基礎機能記録「書く」という作業により「整理」されていく「有形の成果物」となることで「客観化」されていく時と空間を超えて知見が共有されていく Level.0 Level.1 Level.2 Level.3 自動化はココ「自分達のやっていることを知る&改善するために」「自分達のやっていることの説明&(自己・他者)評価のために」出典: Internet Week 2011 「運用ドキュメント2011 ∼手軽にスピーディに継続的に保守するためのツール入門」 Part-1 業務企画業務設計

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変わっちゃうし • CLIからの操作も手で打ってるんじゃ意味ないよね • そもそも構築のベストプラクティス理解してるんだっけ？AWS CDP頭に入ってる人∼？ • 広大すぎるAWSの世界

ということで、環境つくりました。（昨年）オレオレ環境を生み出さないため、環境構築からすべてコマンド化 ./bin/hornet magic new_service （CloudFormationとOpsWorksのAPIのラッパー） ※CLIでの運用ならGithubでインフラ管理できる！ ! 標準環境として、素早いプロトタイピングのためのシンプルな環境のtemplateを用意・VPC環境とNATインスタンス・RDS ・Stack: StagingとProduction ・Ruby on railsのWebApplication LayerとELB を想定

hornetコマンドで作られる基本構成（想定） Staging Stack Production Stack Rails Layer Rails InstancesNAT Instance RDS Rails Layer Rails InstancesNAT Instance RDS

サービスへの適用（ところが）最初の案件が大型のEC案件でしかも短納期・VPC環境とNATインスタンス・S3とCloudFront ・RDS（MultiAZ）・ElastiCache（Redis） v.s. DynamoDB ・PHPのWebApplication LayerとELB ・外部APIと通信のためのGateway LayerとELB ! 要件がどんどん追加、環境が変化していく

Staging/Production Stack Web Layer PHP Instances NAT Instance RDS Admin Layer PHP Instances Gateway Layer ElastiCache S3 CloudFront DynamoDB サービス環境の構成

クラウド時代の運⽤用とエンジニアとは？

クラウド時代の運用とエンジニアとは澤登享彦  HiganWorks LLC 代表社員

既存ワークフローのこだわり要素をアップデート

こだわり対象の更新 ★ ネットワーク・サーバのインフラへのこだわり ★ 耐障害性とか、復旧フローとか ★(多分)同等のこだわりをクラウドベンダも持っている  => 労力を新しい要素に向ける  => マルチベンダを苦にしないこと

基準はエンドユーザ ★ 調達のコスト、iDCインフラ冗長化のコスト  => 避けたかったリスクの見なおし ★ 抽象化をベースに視点を省略する  => 構築や管理の労力を削減

クラウド時代の運用とエンジニアとは？今井大介 daisuke@beenos.com BEENOS株式会社（現：株式会社ネットプライスドットコム）執行役員エンジニアリング本部長

Dev→Opsへ • とりあえず、（これだけ盛り込んでても）最低限の運用はできる • 環境を変えようとした時に、ちょっとわかんなくてサーバーで直接環境変えちゃう（作業の完全な再現が難しい） • Deploy時、インスタンス追加時など、後に地獄を見る • しょうがない、きちんとRecipeでやろう • OpsWorksやCloudFormationの仕組みを知らないと困る→必要なところから徐々に仕組みを理解していく • 環境による制約によって、きちんとせざるをえない。（やった！）環境とコードによるベストプラクティスは人を育てる

わかってる人に構築してもらい構築された環境からベストプラクティスを学ぶ

AWSでの運用は、そうでない場合と何が違うのか

AWSに足りないもの、AWSにほしいもの

クラウド時代の「運用」を担う人が使うべきツールとは？

インフラ寄りからサーバーサイドアプリケーションまで書ける人とか、非常に価値が高いです。絶賛求人中です！一緒に働きましょう！

Operation Lab 運用設計ラボクラウド時代の運用とエンジニアとは？運用設計ラボ合同会社シニアアーキテクト波田野裕一

Operation Lab 運用設計ラボクラウド運用のキーワード「問題を根性で解決するのは馬鹿です。問題をエンジニアリングで解決するのがエンジニアの仕事です」 @yoshiori 構造化ここでは「エンジニアリング(工学)の実践」に近い意味で使います。工学では何らかの構造物・構造体を作ることが不可避なためです。 http://d.hatena.ne.jp/Yoshiori/20120217/1329491437

Operation Lab 運用設計ラボサービス運用全体の流れ顧客・外部サービス Inbound Queue Outbound の繰り返し outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリデリバリデリバリデリバリリクエストリクエストリクエスト運用現場窓口フロントエンドバックエンド outbound outbound 出典: 経営情報学会 2010年春季全国研究発表大会「運用業務プロセスのモデル化」 EndPoint API 疎結合

Operation Lab 運用設計ラボ運用プロセスの構造化サービス工程 Step1 開始サービス工程 Step2 サービス工程 Step3 サービス工程 Step4 サービス工程 Step5 提供前処理inbound 本作業後処理 outboundinbound outbound Quality Cost Delivery データに語らせるのがエンジニアリング

Operation Lab 運用設計ラボ構造化された設計のドキュメント化脱属人化客観化整理 Level.1 Level.2 Level.3 How Why 設計実装 CloudFormation OpsWorks(Chef)AMI ドキュメンテーション乱雑でいいからメモを残す

Operation Lab 運用設計ラボインターネット運用は「安く、手間をかけず」が特徴で、運用設計とドキュメンテーションがないがしろにされてきた。(企業の大小、社歴の長さを問わず) 運用ドキュメントを作る時間が… 今後は、リモートワーク拡大、メンバーの流動性向上、サービスのライフサイクル短期化(扱うサービス数の爆発的拡大)により、アンドキュメンテッド設計&運用は致命的な「知識のロスト」を生む可能性が生産ラインを最初に稼動させ、後から金型を作るようなもの先に金型(設計&ドキュメント化)を作成してから、生産ラインを稼動させるようになる CloudFormation OpsWorks(Chef)AMI アウトプットの「品質」定義が無い

Operation Lab 運用設計ラボ • WhatやHowはコード(Infrastructure As Code)に残るが、Whyは人が自らドキュメントに書かなければ残らない。 • クラウド時代になって、オンプレミスと比較してあらゆる制約が減少。制約が無い中で「なぜそうしたか(Why)」を残す重要性が増加。 • 人(Why)とシステム(What/How)が分担してドキュメントを書く時代。主張: クラウド時代の運用ドキュメンテーション How + Why = KnowHow 実装設計運用現場の資産

AWS発⾏行行の運⽤用チェックリスト • フラストレーションの無い運⽤用ができるようにベストプラクティスから抜き出されたチェックリスト ! • 基本編 • エンタープライズ編 • 監査とセキュリティ編 http://aws.amazon.com/whitepapers/ operational-‐‑‒checklists-‐‑‒for-‐‑‒aws/

20140717 awssummit2014-cloud-operation

by yasuhiro araki, Debian Developer, Solutions Architect at Amazon Web Services

on Jul 25, 2014

Statistics

Views

Actions

1 Embed 5

Accessibility

Categories

Upload Details

Usage Rights

Report content

20140717 awssummit2014-cloud-operation Presentation Transcript