1.
WEB OPERATION
2015年 GMOペパボ新卒エンジニア研修
Webオペレーション研修イントロダクション

2.
アジェンダ
Webオペレーション研修 … おさらい
Webオペレーションとは … 言葉が内包するもの
研修における位置付け … 何を学んでほしいのか
Nyahについて … ペパボの仮想インフラ基盤の紹介
研修の進め方 … ゴール、チーム、ルール、見積りと計画

3.
月 火 水 木 金
10:00 読書会
11:00 基礎研修
13:00 昼
14:00 基礎研修
17:00 CK 研修 CK 基礎研修
18:00 リフレク＆シェアリング・次回目標・日報
Webアプリケーションを 正常稼働 させるために必要な知識の修得 (7/6∼8/7)
Webオペレーション研修
Web開発
モバイル
Web
オペレーション
http://www.slideshare.net/hifumis/20150608-thetaoofpepaboengineer-49152106

4.
Webオペレーションとは
言葉が内包するもの

5.
役割、期待、実態から見るWebオペレーション
Webオペレーションとは
1. 役割：どのような職種か
2. 期待：必要とされている知識領域
3. 実態：どのように業務を遂行しているのか

6.
1. 役割：どのような職種か
Webオペレーションとは
• Webアプリケーションを正常稼働さ
せるのに必要な知識や経験を備えた
専門職種
• ペパボでは、「インフラエンジニア」
が主にこの領域を担当
※ちなみに表紙の魚は「バラクーダ（オニカマス）」らしい

7.
2. 期待：必要とされている知識領域
Webオペレーションとは
ネットワーク・ルーティング・スイッチング・ファイアウォール・負
荷分散・高可用性・障害復旧・TCPやUDPのサービス・NOCの管
理・ハードウェア仕様・複数のUnix環境・複数のウェブサーバ技術・
キャッシュ技術・データベース技術・ストレージインフラ・暗号技術・
アルゴリズム・傾向分析・キャパシティ計画立案…
『ウェブオペレーション 1章』より

8.
3. 実態：どのように業務を遂行しているのか
Webオペレーションとは
• 先の知識領域を1人で全部やるのは大変
• ペパボでは、東京のインフラグループ・
福岡のインフラチームが横断的に活動
• 得意な分野を牽引し、得意な分野で助け
合い、連携して業務を遂行している

9.
3. 実態：どのように業務を遂行しているのか（例として）
Webオペレーションとは

10.
ペパボにおける「インフラG/T」と「情シス」の違いは知ってる？
Webオペレーションとは
• サービスのインフラを支えているのがインフラG/T
• ロリポップ！、ヘテムル、カラーミー、…
• ペパボスタッフのインフラを支えているのが情シス
• PC機器類、社内ネットワーク、社内インフラ、…
※完全にこの通りでは無いが、概形として。

11.
まとめ：役割、期待、実態から見るWebオペレーション
Webオペレーションとは
1. 役割：Webアプリを正常稼働させるのに必要な知識や経
験を備えた専門職種
2. 期待：必要とされている知識領域は多岐にわたる（最近
は仮想化・分散化技術等も）
3. 実態：ペパボではインフラ部隊が問題解決にあたる

12.
研修における位置付け
何を学んでほしいのか

13.
何を学んでほしいのか
研修における位置付け
• エンジニア全員に持ってほしい能力
• ペパボの強みを知る
• 科学ではなく技芸

14.
エンジニア全員に持ってほしい能力
研修における位置付け
• 開発者もメトリクスは見るし、運
用者もコードは書く時代*
• 「何かが来た」** ときに、迅速か
つ適切な対応をするには、Webオ
ペレーション能力も必要
* http://www.slideshare.net/studio3104_com/yapc-asia-2014
** https://speakerdeck.com/inouetakuya/ec-performance-testing

15.
エンジニア全員に持ってほしい能力：対話と協調の大切さ
Webオペレーションとは
If non-communicative & non-collaborative…
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
It’s not my machines,
it’s your code!
It’s not my code,
it’s your machines!

16.
エンジニア全員に持ってほしい能力：視野を更に広げよう
Webオペレーションとは
• エンジニアは自らの職能を越えた動きを推奨されている*
• 研修を通しての繰り返しになるが、研修の3つの軸を学
ぶことで、広く深い知識や経験を手に入れてほしい
* https://speakerdeck.com/kentaro/engineering-in-gmo-pepabo-inc?slide=15

17.
ペパボの強みを知る
Webオペレーションとは
http://www.slideshare.net/hifumis/20150608-thetaoofpepaboengineer-49152106/27

18.
科学ではなく技芸
Webオペレーションとは
• 正規の教育や資格、標準、「正しい方法」はない
• プロフェッショナルの知識や経験、ツール、プロセスが
「Webオペレーション」という技芸になっていった
• 研修というサポート環境のもとで、実践的な「型」を身
につけてほしい

19.
まとめ：何を学んでほしいのか
Webオペレーションとは
• 開発・運用はエンジニアに修得してほしいスキル
• Webオペレーションはペパボの強みの1つ
• プロフェッショナルの技術から、実践的な「型」を学ぶ

20.
Nyahについて
ペパボの仮想インフラ基盤の紹介

21.
OpenStackをベースとしたペパボの仮想インフラ基盤 (IaaS)
次世代開発環境としてのNyah
• サービスに必要なインフラ基盤を、
仮想化技術にもとづいて提供
• 作りたいものをバーンと作って公
開できる環境
http://www.slideshare.net/ume3_/pb-tc01-bob001

22.
Nyahが無かった頃の開発環境：Maglica
Episode Zero
• https://github.com/mizzy/maglica
• http://www.slideshare.net/mizzy/
maglica-techkayac
• GH:E tech/maglica-usage

23.
Nyah説明会・ハンズオン
• @ume3_ (ボブさん) 主導
• 本日7/6 14:00-16:00
• ＠放送室

24.
まとめ
Nyahについて
• サービスに必要なインフラ基盤を仮想化技術にもとづい
て提供してくれる君
• 昔（今も現役だけど）はmaglicaを使っていた
• 午後にハンズオンを予定

25.
研修の進め方
ゴール、チーム、グランドルール、見積りと計画について

26.
グランドルール
見積りと計画
チーム
ゴール

27.
アプリが「動く」インフラを、ステップ・バイ・ステップで成長させる
ゴール

28.
アプリが「動く」インフラを、ステップ・バイ・ステップで成長させる
ゴール
manual install infra as code transfer
high
availability
test
Vagrant編 Nyah編

29.
Vagrant編
VagrantにRails Tutorialのアプリケーションが動く環境を作る

30.
VagrantにRails Tutorialで作ったWebアプリケーションが動く環境を作る
ステップ：manual install
• パッケージマネージャやエディタ
などを駆使して頑張る
• gistなどに手順をメモしておく
※historyコマンドは便利

31.
rails s -b 0.0.0.0 -p 80 して、VM上のWebアプリにアクセス可能にする
ステップ：manual install
VM
——————
app, db
rails, mysql (or
mariadb)

32.
ペパボのプロダクションでも使われている構成にジャンプアップする
ステップ：manual install
VM
——————
app, db
nginx + unicorn
(socket), mysql

33.
やること
ステップ：manual install
1. VagrantでVM (CentOS 7) を作る
2. Rails Tutorialで作ったWebアプリ
をVM上で動かす (rails server)
3. nginx + unicornに切り替える
※出来る人は2を飛ばしても良い

34.
サーバは意図通りに動いてますか？それをどうやって保証しますか？
ステップ：test
• パッケージなに入れた？
• 設定ファイルを変更した？
• サービスは起動した？
• サービスは自動起動する？
• ポートはリスンしてる？
• 適切な権限を与えた？
• 実行ユーザは存在する？
• サービスは動作してる？

35.
サーバの構成・状態をテストしよう
ステップ：test
✓パッケージなに入れた？
✓設定ファイルを変更した？
✓サービスは起動した？
✓サービスは自動起動する？
✓ポートはリスンしてる？
✓適切な権限を与えた？
✓実行ユーザは存在する？
✓サービスは動作してる？

36.
1st: Serverspec
ステップ：test(ing tools)
• サーバの状態をコードにより自動
的にテストするためのツール
http://serverspec.org
https://github.com/serverspec

37.
2nd: Infrataster
ステップ：test(ing tools)
• サーバの振る舞いをテストするた
めのツール
• 出来たらやってみよう
https://github.com/ryotarai/infrataster

38.
やること
ステップ：test
1. Serverspecをインストール
2. サーバのテストを書く
3. 余裕があればInfratasterでのテ
ストも導入する

39.
Infrastructure as Code : コードとしてのインフラ
ステップ：infra as code
package 'nginx' do
action :install
end
service 'nginx' do
action [:enable, :start]
end

40.
Configuration management tool : 構成管理ツール
ステップ：infra as code
• インフラの状態を構造化
• プラットフォーム間の差異を吸収
• Puppet, Chef, Ansible, Itamae…

41.
構成管理ツールとして、Itamaeを使っていきましょう
ステップ：infra as code
• https://github.com/itamae-kitchen/itamae
• 構成管理ツールの学習そのものは研修
の本質からやや逸れる
• Web開発研修でRubyを扱った
• Itamaeはシンプル、軽量、Ruby DSL

42.
やること
ステップ：infra as code
1. Itamaeをインストールする
2. manual installの手順をコード化する
3. 新規VMにItamaeを実行する
4. テストをオールグリーンにする
※3と4は往復することもあり得る

43.
やることまとめ
Vagrant編
1. Web開発研修で作成したRailsアプ
リを、Vagrantで動かす
2. Serverspec, Infratasterなどでサーバ
の構成・振る舞いをテストする
3. Itamaeでサーバ構成をコード化する

44.
Nyah編

45.
WebアプリをNyahで動かせるようにする
ステップ：transfer
1. NyahのVMを1個作る
2. Itamaeでサーバ構築
3. テストをオールグリーンにする

46.
VM
——————
app, db
可用性に対する課題
ステップ：high availability
• 1サーバで動いているものが多い
• リソースの食い合い
• どのパッケージがどのシステムに
必要なのか分かりにくい複雑な依
存関係

47.
VM
——————
a role
可用性に対する課題 : 役割ごとにVMを用意する
ステップ：high availability
• 再利用できるネットワークアクセ
ス可能な単位 (サービス)* に分割
• 構成の変更に伴うコードや設定の
修正・変更
VM
——————
a role
VM
——————
a role
VM
——————
a role
VM
——————
a role
* 「ウェブオペレーション 5章 コードとしてのインフラ」より

48.
可用性に対する課題 : 役割に対して適切なスペックを与える
ステップ：high availability
• ストレージ、メモリ、CPU、…
• それぞれの役割に対して適切な
flavor (OpenStackの仮想ハード
ウェアの名称) を選択する VM
——————
a role
VM
——————
a role
VM
——————
a role
VM
——————
a role
VM
——————
a role

49.
Normal stage
まずはここから

50.
app/dbの分離
ステップ：high availability
app
db
nginx + unicorn
(socket)
mysql

51.
dbのレプリケーション (backup, redundancy)
ステップ：high availability
app
db
(master)
db
(repl)
nginx + unicorn
(socket)
mysql

52.
Grand stage
より本格的なインフラ構成をめざして

53.
unicorn
リバースプロキシの導入
ステップ：high availability
app
db
(master)
db
(repl)
reverse proxynginx
upstream (TCP)

54.
appサーバの冗長化 (scale out)
app
ステップ：high availability
db
(master)
db
(repl)
reverse proxy
app
nginx
unicorn
upstream (TCP)

55.
セッションストレージの分離
app
ステップ：high availability
db
(master)
db
(repl)
reverse proxy
app session storage
redis,
memcached

56.
Extra stage
余裕があればやってみよう

57.
監視・メトリクスの導入 (monitoring)
app
ステップ：high availability
db
(master)
db
(repl)
reverse proxy
app session storage
Nagios
sensu
consul-alert
mackerel.io
Munin
New Relic

58.
Legendary stage
研修よりはるか高みへ

59.
研修としてはオーバクオリティ… (この辺から high っぽくなってくる)
app
ステップ：high availability
db
(master) slave
proxy
app
session (active)
proxy
load balancer
lvs + keepalived,
serf + haproxy, …
reference to slave
session (standby)
lb
redis sentinel, …
lb
lb

60.
やること (Extra, Legendaryはおかわり案件)
ステップ：high availability
1. app/dbを分離
2. dbの冗長化
3. リバースプロキシの導入
4. appの冗長化
5. セッションサーバの分離

61.
サーバ移行、冗長化、オーケストレーション
Nyah編
1. Nyah上のVMでアプリケーショ
ンを動かす
2. 役割ごとにVMを分割し、耐障
害性を向上させる

62.
ゴール
グランドルール
見積りと計画
チーム

63.
前提 : ノウハウを共通化させる必要性について
チーム
• 構成管理ツールやデプロイツールの選択肢は多様
• サービス特性に応じたツール選択は必須
• 複数人での活動に耐えうる運用の確立は重要

64.
2人1組になってインフラを設計、構築、運用していきましょう
チーム
• リポジトリ、コード、ドキュメント、Issueの活用
• 外部公開出来ない情報も出るため、作業場はGH:Eで🙇

65.
Shuffle!
チーム
• 1週間ごとにチームは交代
• 他の人が手がけた運用に触れる経験
• その運用を引き継ぐも刷新するも自由、ただし対話とい
うプロセスはとっても大切

66.
「test」のフェーズからチーム作業を開始しましょう
チーム
manual install infra as code transfer
high
availability
test

67.
各フェーズで相談しなければならないことの例
チーム
• お互いのmanual installの作業内容に問題は無いか？
• testの内容はこれで十分か？
• Itamae recipeの設計内容はこれで良いか？
• デプロイツールはどうする？

68.
まとめ
チーム
• 「test」フェーズから、2人1組のチームを作って運用する
• チームは1週間毎に交代する
• それぞれのフェーズで運用方法を確かめ合っていく
• github.com ではなくGH:Eに新規リポジトリを作る

69.
ゴール
見積りと計画
チーム
グランドルール

70.
BDD (Bosukete Driven Development) は変わらず
グランドルール
http://www.slideshare.net/hifumis/20150609-webdevelopmenttraining/26

71.
ゴール
チーム
グランドルール
見積りと計画

72.
基本的なプロセスはWeb開発研修と同じだが、難易度は増した
見積りと計画
• 「やること」の幅が広がった
• 「やること」の複雑さが増した
• 見積りの単位はストーリーポイン
ト？理想時間？
https://speakerdeck.com/kenchan/web-dev-training-introduction

73.
使える時間と場所
見積りと計画
• 7/6 16:00-17:00 音楽室
• 7/7 10:00-12:00 美術室

74.
まとめ
見積りと計画
• Web開発研修と同じやり方を再び実践
• 前回よりも難易度は高い
• 3時間程度でやりましょう

75.
まとめ
Webオペレーション研修 … 7/6∼8/7に実施する基礎研修の1つ
Webオペレーションとは … Webアプリを正常稼働させるための多岐
にわたる知識や経験を備え、課題解決にあたる専門職
研修における位置付け … Webオペレーションの型をプロから学ぼう
Nyahについて … OpenStackをベースとしたペパボのIaaS
研修の進め方 … さいきょうのインフラをチームでつくろう

76.
Appendix

77.
DevOps
• It's not abstraction.
• It's not even "infrastructure as
code".
• It's not any single tool.
• It's not about provisioning.
• It's not about deployment.
• It's not about a job
description or position.
• It's also not about the cloud, except
for the part where deployment and
provisioning of infrastructure gets
easier to understand for groups of
people who historically wouldn't have
touched that part of the business.
• It *is* about the collaborative and
communicative culture and the
tools and process that arise from
that culture. Nothing more.
http://www.rationalsurvivability.com/blog/2010/05/incomplete-thought-the-devops-disconnect/#comment-3375

78.
Provisioning Toolchain
Provisioning Toolchain by Lee Thompson (Velocity 2010),
サーバプロビジョニングのこれまでとこれから (デブサミ2014) より作成
Application Service Orchestration
System Configuration
OS install
Cloud or VM
Image Launch
Capistrano Fabric
Serf Consul
Puppet Chef
Itamae
Kickstart Cobbler
EC2 OpenStack
Orchestration
Configuration
Bootstrapping
Ansible

79.
Test Driven Infrastructure
Virtualization and Cloud Computing have made it easy to procure
and provision hardware and virtual servers. But with this flexibility
comes scale and complexity, and managing our virtual estates has
become increasingly difficult. Using techniques more familiar in the
software development world such as TDD, BDD and CI offers an
approach to managing this complexity and gives us the confidence
to make changes to our infrastructure in a safe, repeatable and
automatable manner. Provisioning testing tools, like rspec-puppet,
Test Kitchen and serverspec, are available for most platforms.
http://www.thoughtworks.com/radar/techniques/provisioning-testing

80.
Nightmare microservices
Migrating to Microservices by @adrianco GOTO Berlin 2014
“Death Star” Architecture Diagrams
Netflix Gilt Groupe (12 of 450) Twitter
As visualized by Appdynamics, Boundary.com and Twitter internal tools