Developers Summit 2013 Summer

基調講演

DevOpsは開発現場とビジネスの間に何を生むか？

Publickey 新野さん

DevOps、かなり盛り上がっている
DevOpsの始まりと広がり
- 2009/6/3 Oreillyのイベント「Velocity」 - 10 deploys per day dev&ops cooperation at Flickr
  - 2009/10 DevOps Days
最初は相手にされなかったDevOps
DevOpsの原点
- ビジネスは変化を要求してくる
- 変化に伴うリスクを、ツールとカルチャーで低減する
- カルチャー
- ツール
  1. Automated infrastructure
  2. Shared version control
  3. One step build and deploy
DevとOpsの言い分
DevとOpsの協力関係のあり方
- Dev 継続的デプロイメント
  - アジャイル
  - Git
  - Jenkins
  - 自動テストツール
- Ops Infrastructure as Code
  - クラウド
  - Chef
  - Puppet
  - Vagrant
で、うまくいってるの？
メトリクスで判断しよう
- ログ解析
- メトリクス取得
- メトリクスで判断
  - ユーザ滞留時間なり、ビジネス上の指標
メトリクスはすり合わせが肝心
- あらかじめ決めておく
- どんな情報がログから取り出せるのか
- その中でどれがメトリクスとして使えるのか
- それ以外で評価すべきことはあるか
エンタープライズでの課題
- 日本のSIビジネスにDevOpsは適用できるのか？
- BizとDev/OpsはDevOpsのメトリクスを握れるのか？
- どのプロジェクトをDevOpsで進めるか、選べるのか？
- そもそもアジャイルやクラウドの採用にハードルがあるのではないか？

DevOps at ChatWork

ChatWork　山本さん

チャットワークのコンセプト

クラウド型ビジネスチャットツール

わりとミッションクリティカル

DevOps?

Dev: どんどん機能追加したい
Ops: 安定運用したい

ChatWorkにおけるDevOpsの考え方

極力__運用しない__

大規模チャットシステムにおける運用の勘所

データベース
- write heavyな負荷
- Amazon RDS, DynamoDB
ファイルサーバ
- 要Scale Out
- Amazon S3
リアルタイム通信
- C10K問題
- Google API Channel API

Leanなサーバアーキテクチャ移行

Paas → PaaS + IaaS
成長に伴いIaas比率をあげていく

障害発生時のフロー

基本的に自動復旧
- ファイルオーバー
- ロードバランサから切り離し
- 代替機能へフォールバック
Nagios通知
- 不調なサーバの切り替え
- 各種プログラムの改修

全社的に見たDev/Ops/Biz

Dev = デベロッパ＆デザイナ
Ops = インフラ＆サポート
Biz = マネージメント＆マーケティング

ChatWorkで取り組んでいること

ほとんどのコミュニケーションはチャットで。メールはしない。口頭確認やMTGは最低限に。
プロジェクトごとにグループチャットを作成し、関係者を全員入れる
タスクの生まれる「背景」を共有する。言われたことだけをする"作業者"を作らない

質疑

障害発生時は？
- Opsの人がまず原因究明。必要ならDevに。
受発注の関係の経験

EnterpriseでのDevOpsの勘所

Microsoft 長沢さん

ビジネスニーズと戦略的なIT

ビジネスとITが牽引
ジャストインマーケット
IT計画と投資は、顧客中心に

エンタープライズでのITの"ユーザー"とは？

お客様
従業員

エンタープライズアプリケーションの進化

基礎体力
戦闘力

BUILD - MEASURE - LEARN

ビジネスにフォーカスした戦略的なIT

必ず必要なもの

共通ゴール
成果物の共同所有
自動化

MicrosoftとDevOps

Services
Enterprise IT
Software (Platform)
- パッケージにも継続的デリバリーが波及

質疑

メトリクスでサイクルタイムとMTTRがあったが、どう大事なの？
- サイクルタイムが短いほど、ビジネス価値が見えやすい
- MTTRはDevとOpsにまたがる。ITに近いメトリクスとしてお互いのよさがわかる

DevOps x Opscode Chef

クリエーションライン　浦底さん

Automated Infrastructure

インフラの構成を自動化
単なる自動化ツールではない
インフラ構成管理フレームワーク

Infrastructure as code

サーバインスタンスはオブジェクトである
インフラをモデル化

コードで定義することで

リポジトリ管理が可能に
ブランチ管理
コードの差分把握
コードレビュー
コードの共有
テスト駆動インフラ開発が可能に

テスト駆動にテストは不要か

必要
テスト駆動で維持する品質は低下の防止

Chefの大原則　定義されたあるべき姿に対して

冪等性
収束

クラウド前提の現在

可用性
迅速性
再利用性
継続的

コードによって拡がる可能性

コード化されたビジネス

Dev + Ops = Change

時間がかかるのは当たり前
「全てを一度に変える」のは不可能
文化から変えていく

Chef実演

Change! Now.

できることから始めよう

サンドボックスから開放せよ！

日本HP 藤井さん

"エンタープライズ", "DevOps"?

"サンドボックス"タイプ
"BETA"タイプ

"BETA"なエンタープライズの特質

しがらみ
スキル
別にそんな頻繁に"リリース"しない

ギャップは、"BETA"なればこそ

DevOps
- スピード＆ビジネス俊敏性
OpsDev
- 効率化と低コストの推進

成熟度モデルによる段階的アプローチ

CMMIを模したDevOps成熟度
アクティビティベースの成熟度モデル

リリースプロセスの効率化

テスト・デプロイを一連の流れとして自動化

サンドボックスから開放せよ

リリースが頻繁でなければDevOpsはいらない？
リリース頻度は関係ない。
"BETA"なエンタープライズにとっては、リリース可能な品質獲得のスキーム
DevOpsを、サンドボックスから開放しよう！
DevOpsで、新しい開発アプローチをサンドボックスから開放しよう！

基礎からわかるDevOps

アマゾンデータサービスジャパン吉羽さん

DevOpsの基礎

ビジネス環境の変化
Amazonの3つのコアビジネス
- コンシューマ向け
- セラー向け
- ITインフラビジネス

ビジネスのためにITを活用

開発者と運用者の壁

開発者は新しい機能をどんどん作る
運用者は安定した運用を提供する

ミッションの違い

It's not my business
サイロ化
オーバーヘッド

サイロ化によるオーバーヘッド

価値を生む作業に時間を使えていない・ムダがある！

ビジネスは変化する

フィードバックループ

顧客とビジネスの間のフィードバクループを加速する
顧客の期待に応え続ける

DevもOpsもビジネスの成果達成を支える

DevOpsは考え方で、プロセスやフレームワークではあい
実装は現場によって異なる

文化によるサポート

お互いの尊重
お互いの信頼
失敗に対する健全な態度
お互いを非難しない

ツールによるサポート

インフラ構築自動化
バージョン管理
継続的インテグレーション
デプロイ自動化
監視
情報共有
ダッシュボード

開発プロセスとの関係

アジャイル開発

Scrum
- 優先順位をつけて１つづつ確認
XP - 19個のプラクティス
共通理解
- 完了の定義を作り、何を持って出荷可能かを定める
- 定義はビジネス+Dev+Opsで作成
品質の作り込み
- 早く見つけて速く直す

継続的デリバリー

繰り返し型の開発 Scrum
継続的インテグレーション Scrum + XP
継続的デプロイ Lean

自動化による時間の使い方の変化

Infrastructure as code
クラウドコンピューティング
Design for Failure
- 全てのものが壊れる前提で設計する
- サーバもアプリケーションも
- 1か所壊れても動くように

DevOpsいつやるの？

いまでしょ！の前にやることがあります

あなたの組織のゴールは？
現実を見つめなおす
小さく始める
１日にしてならず
当たり前のことを当たり前に
- バージョン管理
- コーディング規約
- コードレビュー
- テスト自動化
- ドキュメント
- …
組織づくり
成功をみんなで祝う

DevOpsは銀の弾丸ではない

自分の組織にとってDevOpsとは何なのか？どうなれば成功かを考え、着実に小さい成功を積み上げる

HTML5 x SIer 業務システムこそWebの力が必要だ

html5j えんぷら部部長川田さん

姿を変えようとしている業務システムのWebについて

業務屋は本当に、Webをやっていたのか？
事実上IE6のみだったのが、変化しようとしている
1. Windows XPサポート終了
  - 既存のWeb資産はどう維持するか？
  - 企業はOSをアップグレードしてくれた
2. スマートデバイスの普及・セキュリティ技術の進化
  - システムがデスクから解放されつつある
3. RIAの登場・オープン系へのシフト
  - 多様化したRIAの実現手段
  - 既存資産の移行

HTML5で何が変わるのか

HTML5は使用を決める仕組みが違う
- バザール方式

業務屋さんにとってのHTML5

Canvasでグラフの描画
AppCacheを使ってオフライン化
WebSocketをつかった監視

業務システム固有のユーザビリティの工学

フォーカスとか
Enterでタブ移動したり
ime-modeとか

CSS3で標準化！

長いライフサイクルに負けない、瑕疵担保を乗り切る相互運用性の技

素直にHTML5を使う
新しいほうが標準準拠性が高い

比較的新しいHTML5の活用のタイミングは？

セマンティクス

Webブラウザが対応しない
非対応になる
要素の選択に時間をとられる

WebSocket

APIサーバが対応しない
Apacheが対応しない
ネットワークが対応しない

最後に

エンタープライズで扱うには、安定度の見極めが難しい
2014年あたりの勧告化を楽しみに！

Hadoopを使わない独自の分散処理環境の構築とその運用

IIJ 前橋さん

分散システム開発の動機

ISPにおいて、サービスの状態把握は必須
そのために大量のログデータを扱う必要がある
ISPにおける大規模データ
- ほぼすべて時系列データ
- 分析したい項目や抽出条件は多岐にわたる
巨大なログデータの処理といえばhadoop

Hadoop相当のものを自作

ddd + ddfs
- 社内用
pmux

自作した理由

Hadoopはバッチ処理に特化している
自社開発でノウハウをためるため
用途を特化して作ればより効率のよいものが作れる
やってみたかったから

分散処理の原理は難しくない

Hadoopはバッチシステム
- 24秒の遅延が気にならないような、巨大なバッチ処理
- やることが決まっている定形処理
やりたいこと
- サービス運用者は、試行錯誤により、より深いデータ分析を行う
- 分析に必要なパラメータは多様であり、事前に網羅することは困難→定形でない
データを生のまま保存し、オンデマンドで抽出する必要がある

開発したものの機能と仕組み

ddd
- 大量の時系列データを蓄積し、必要に応じて短時間で検索・集計結果を返す
- 時系列データに最適化した分散ファイルシステム
- 自動レプリケーションによるデータ冗長化
- 楽観的タスクスケジューリング
- 極めて小さいデータを、何もせず素通しにする応答速度
  - Hadoop 19秒
  - ddd 0.12秒
pmux
- pipeline multiplexerに由来
- オープンソース
- https://github.com/iij/pmux
- 標準入出力を介してMapReduceするためのコマンドラインツール
- ファイルがあるノードで処理を実行

デバッグとテスト

多数のノードを前提とした分散システムのデバッグは超大変
ネットワークをモック化
- 複数ノード環境をシミュレーション
テストへの組み込み
- CIツールによって自動実行
実環境でしか再現できないトラブルもある
- ノード間通信の集中に起因
  - コネクション数限界
  - パケットの消失
- ノード間の通信をキューを使って制御

自作した甲斐はあった？

もちろんYES
サービスや社内システムのバックエンドで活用
ビッグデータに関する新サービスで応用予定

運用について

サービスのバックエンドとして利用
ノードの設置場所
運用の基本思想
- 楽をする
- 機材は壊れることを前提
- 監視とモニタリングはしっかり
サーバについて
- ネットワークブート
- 起動後にChefで必要な物をインストール
- 仮想化技術は使っていない
- HDDは搭載しているが、データ格納用途のみ
- dddやGlusterFSのレベルで冗長化
- 故障はそれなりに起こる
監視について
- 死活監視・ポート監視
- ディスク残量監視
- MapReduceの実行時間監視
- モニタリング
  - ファシリティレベル
  - 各種リソース
  - アプリケーションレベル

まとめ

ISPは、サービス状態の把握のために巨大なログデータを扱う必要がある
分散処理システムを独自に開発
- 定型でない処理に対応
運用
- 今時の普通のやり方
- モニタリング重視

Webサービスのための10/40Gigabit Ethernetの可能性

さくらインターネット松本さん

Webサービスと1/10/40GbEの使い分け

クラウド事業者では一般的な構成

実際の機器

10 Gigabit Ethernet NICとは？
- (画像)
40 Gigabit Ethernet NICとは？
- (画像)
10 Gigabit Ethernet Cableは光とメタル
- SFP+ Copper Cable(50cmで¥5000くらい)
- SFP+ Optical Cable
40 Gigabit Ethernet Cableは光とメタル
- QSFP+ Copper Cable
- QSFP+ Optical Cable
- 根本的にケーブルが異なる
  - 曲げ径が大きい
  - コネクタを抜き差しするうちカード自体が抜けたり
10 Gigabit Ehternet Switchの価格帯
- $8280〜$14250までの標準価格帯
10 Gigabit Ehternet Switchの価格帯
- $14670からの標準価格帯
高価な測定機器というハードル
- Intel x86サーバで測定環境を作ってしまう
Linux系ツールのバージョンアップが必須
- 速度表示が違ったり
10GbEドライバのインストール方法は簡単
ベンダーによる10GbE NIC性能差は？
- サービスの特性に合わせてNICを選ぶ
HighGig DATA Transfer Benchmark

まとめ

使い方次第
お金をかけなくても、運用できる
自分たちでやろう！

エンタープライズTED

私と開発とコミュニティ

メントルシステム販売　木下さん

システム開発に携わっている女性へ

プログラマーになったきっかけ

自分で企画したものを自分で作って世の中に提供したい!
挫折を繰り返す
前向きになるものの、自分だけでは限界

Windows女子部

だめもとで企画コンテストに参加
チーム内では好評
賞はもらえなかったが、ちょっと自信に

色々うまく動き出す

目標へ一歩近づく
Windows女子部部長に

まとめ

ちょっと一歩踏み出すことで、一気に世界が変わります
コミュニティには沢山のチャンスがある

そろそろ社内研修を活かしませんか？

gumi 高柳さん

社内研修に活かしたこと

研修にファシリテーションを足してみました
- 「場の概念」を足す
- 「関係性の構築」を足す
ヒアリングにコーチングを足す
- 主体性が発現

社内研修の活かし方

社内研修の２つの力

強制力
- 一緒に作りましょう
公認
- 現場の研修を会社が認めています

設計要素マラソン！

株式会社ビッグツリーキャピタル　高安さん

設計前に行うこと
- システム全体の把握
共通設計
機能仕様
- 粒度を整える
画面設計
- 画面遷移図
- レイアウト
- イベント設計
帳票設計
外部連携設計
DB設計
処理詳細設計
アーキテクチャ設計との関係

まとめ

設計のキーワードは「粒度」「網羅的」「整合性」
DevOpsを検討する場合でも、全体像をしり、要素を知る
そして、「試行錯誤するための計画」を作り、試行錯誤する
その中で何かがみつかるはず

Anonymous Inner Programmer

フリーランス見習い　佐々木さん

海上保安庁のテレタイプのコンピュータ化
電子交換機の開発
埋め込みマーク解析ツールBillを自作し、MS-DOS学習ツールを作る
COBOL巨大コピー句群から、単体テストデータを半自動生成
DDJJ誌休刊時の総目次をXML化、編集部へ寄贈
JUnitテストコードから単体テスト仕様書を自動生成
Lotusノーツデータベースの文章をCSV化するstrucText2csv
引退して、翻訳作業向け生産管理ツール、モジモジくん開発してます

まとめ

-　リアルな世界 -　コンピュータを使った素敵な世界を作ろう！

mshibuya/Devsumi2013Summer.md