Slide 1
Slide 1 text
我々は
どのように
冗長化を失敗したのか
YAPC::Asia 2015
2015/08/22 (Day 2)
kenjiskywalker
Photos : https://www.flickr.com/photos/gsfc 1
Slide 2
Slide 2 text
ある思想を持って
システム構築を行い
失敗をした話をします
よろしくお願いします
2
Slide 3
Slide 3 text
話すこと
挑戦したこと
冗長化について
Redis + Redis Sentinel
Consul
MySQL + mysqlfailover
consul-template
hostsの順番
クラウドという名の混乱
対応
冗長化の終わり、そして
3
Slide 4
Slide 4 text
挑戦したこと
4
Slide 5
Slide 5 text
式年遷宮
インフラストラクチャ
5
Slide 6
Slide 6 text
式年遷宮とは
6
Slide 7
Slide 7 text
”神宮式年遷宮は、
神宮（伊勢神宮）において
行われる式年遷宮
（定期的に行われる遷宮）
である。”
Wikipedia調べ
7
Slide 8
Slide 8 text
何故
式年遷宮を行うのか
8
Slide 9
Slide 9 text
神道での清浄さの維持
技術の伝承という継続性
Wikipedia調べ
”式年遷宮が20年ごとに行われる理由についても、
同じく確たる記録はないため不明である。
推測される主な理由としては、
以下の5点が挙げられる。”
からの一部抜粋
9
Slide 10
Slide 10 text
式年遷宮とは
長期的な品質の担保と
その概念自体の継続性の維持を
目的としたアーキテクチャ
ではなかったのだろうか(仮説)
10
Slide 11
Slide 11 text
Webサービスの運用と
式年遷宮
11
Slide 12
Slide 12 text
Kenji Naito a.k.a kenjiskywalker
The world is not complete
Photos : https://www.flickr.com/photos/gsfc
YAPC::Asia 2014
2014/08/29 (day 1)
12
Slide 13
Slide 13 text
故障率曲線
ＭＴＢＦ（平均故障間隔）
ＭＴＴＲ（平均修理時間）
辛さの平均値
13
Slide 14
Slide 14 text
「動くものは必ず壊れる」
Webサービスの運用
相反するふたつの価値観を
結びつけ成長させる必要がある
14
「24時間365日
正常に動き続けなけければ
ならない」
Slide 15
Slide 15 text
冗長化
15
Slide 16
Slide 16 text
”冗長化（じょうちょうか）とは、
システムの一部に
何らかの障害が発生した場合に備えて、
障害発生後でも
システム全体の機能を維持し
続けられるように予備装置を
平常時からバックアップとして
配置し運用しておくこと。
冗長化によって得られる安全性は
冗長性と呼ばれる。”
Wikipedia調べ
16
Slide 17
Slide 17 text
異常が発生した際に
自動的にアクティブが
遷移する設定を
導入しているところは
結構あると思う
17
Slide 18
Slide 18 text
しかし
18
Slide 19
Slide 19 text
障害発生時、
正常に
切り替わらないことが
ほとんどである
（個人の感想であり効果・効能を示すものではありません）
19
Slide 20
Slide 20 text
そこで
20
Slide 21
Slide 21 text
平常時であっても
常に冗長構成の
アクティブ/スタンバイを
切り替えることによって
異常時の正常動作を
担保できるのではないか
Active/Standby Active/Standby
21
Slide 22
Slide 22 text
それって
式年遷宮では？
22
Slide 23
Slide 23 text
それって
式年遷宮では？
23
Slide 24
Slide 24 text
式年遷宮
インフラストラクチャ
思想
(正常時も常に稼動系を切り替える)
24
Slide 25
Slide 25 text
構成
25
Slide 26
Slide 26 text
構成
Public
Web Server A 02
Web Server A 01
Web Sever B 02
Web Server B 01
26
Slide 27
Slide 27 text
構成
MySQL A Slave
MySQL A Master
Private
MySQL B Slave
MySQL B Master
27
Slide 28
Slide 28 text
構成
Private
Public
VPN
28
Slide 29
Slide 29 text
nginx + Redis(Slave)
Application A 02
各ウェブサーバでは
nginxとRedis、
Web Applicationが動いている
nginx + Redis(Master)
Application A 01
29
Slide 30
Slide 30 text
この構成で
式年遷宮を
実装する場合の課題
30
Slide 31
Slide 31 text
Master/Slave方式の
冗長化されたシステムを
どのように
式年遷宮に対応させるか
31
Slide 32
Slide 32 text
Redisの場合
32
Slide 33
Slide 33 text
Redis Sentinel
Redis Ver. 2.8.9
33
Slide 34
Slide 34 text
Redis Sentinel？
基本スプリットブレインを
予防するためには
最低でも
サーバが３台必要なのでは？
34
Slide 35
Slide 35 text
監視用のサーバを置いた場合
監視用のサーバも遷移させる？
nginx + Redis
Application A 01
Sentinel x1
nginx + Redis
Application A 02
Sentinel x1
nginx + Redis
Application A 03-01
Sentinel x1
nginx + Redis
Application A 03-01
Sentinel x1
?
35
Slide 36
Slide 36 text
冗長化の為に
システム自体を
複雑化するのは避けたい
36
Slide 37
Slide 37 text
台数をそのままに
Redis Sentinelを導入
37
Slide 38
Slide 38 text
Master : Sentinel x1
Slave : Sentinel x2
Redis Master
Sentinel x1
Redis Master
Sentinel x2
38
Slide 39
Slide 39 text
Masterが遷移した際に
Redis Sentinelの数を
操作する(Master x1/Slave x2)に
する必要がある
Redis (New) Slave
Sentinel x1
⇣
Sentinel x2
Redis (New) Master
Sentinel x2
⇣
Sentinel x1
39
Slide 40
Slide 40 text
詰めが甘いところはあるが
可能ではありそうだ
40
Slide 41
Slide 41 text
サーバに障害が発生した際に
アプリケーションをどのように
新しいMasterへ向き先を変えるか
Redis Master
Host 01
Redis (New) Master
Host 02
41
Slide 42
Slide 42 text
Consul
Consul Ver. 0.5.0
42
Slide 43
Slide 43 text
Consul とは
43
Slide 44
Slide 44 text
44
Slide 45
Slide 45 text
Consulとは
いい感じに
DNSレコードを
返すもの
45
Slide 46
Slide 46 text
このConsulを利用して
RedisのMasterが
遷移したことを
アプリケーションへ
知らせたい
46
Slide 47
Slide 47 text
#!/usr/bin/env ruby
redis_name = 'foo-redis'
fqdn = 'service.dc1.consul'
master_redis_name = "master.#{redis_name}.#{fqdn}"
master_redis_hosts = `host -W 1 #{master_redis_name}| grep has`.split("\n")
# マスターが複数台起動していたなら
if master_redis_hosts.length > 1
exit 2
end
redis_is_runnning = `netstat -l | grep -w 6379`
# Redisが動いていなければfail
if redis_is_runnning.nil?
exit 2
end
# Roleがmasterであればtrue
my_redis_role = `/usr/local/bin/redis-cli info | grep role`
my_redis_role.chomp!
if "#{my_redis_role}" == "role:master"
exit 0
else
exit 2
end 47
Slide 48
Slide 48 text
#!/usr/bin/env ruby
redis_name = 'foo-redis'
fqdn = 'service.dc1.consul'
master_redis_name = "master.#{redis_name}.#{fqdn}"
master_redis_hosts = `host -W 1 #{master_redis_name}| grep has`.split("\n")
# マスターが複数台起動していたなら
if master_redis_hosts.length > 1
exit 2
end
redis_is_runnning = `netstat -l | grep -w 6379`
# Redisが動いていなければfail
if redis_is_runnning.nil?
exit 2
end
# Roleがmasterであればtrue
my_redis_role = `/usr/local/bin/redis-cli info | grep role`
my_redis_role.chomp!
if "#{my_redis_role}" == "role:master"
exit 0
else
exit 2
end
１、RedisのMasterのDNSが
複数のIPアドレスを返していない
２、自分のサーバでRedisが動いている
３、その動いているRedisはMasterである
48
Slide 49
Slide 49 text
#!/usr/bin/env ruby
redis_name = 'foo-redis'
fqdn = 'service.dc1.consul'
master_redis_name = "master.#{redis_name}.#{fqdn}"
master_redis_hosts = `host -W 1 #{master_redis_name}| grep has`.split("\n")
# マスターが複数台起動していたなら
if master_redis_hosts.length > 1
exit 2
end
redis_is_runnning = `netstat -l | grep -w 6379`
# Redisが動いていなければfail
if redis_is_runnning.nil?
exit 2
end
# Roleがmasterであればtrue
my_redis_role = `/usr/local/bin/redis-cli info | grep role`
my_redis_role.chomp!
if "#{my_redis_role}" == "role:master"
exit 0
else
exit 2
end
この３つの条件を
満たした時のみ
RedisのMasterのDNSレコードを
Consulで返すようにした
49
Slide 50
Slide 50 text
{
"service": {
"id": "foo-redis master check in HOSTNAME",
"tags": ["master"],
"name": "foo-redis",
"check": {
"script": "/opt/consul/bin/redis-master-check.rb",
"interval": "30s"
}
}
}
50
Slide 51
Slide 51 text
「master.foo-redis.service.dc1.consul」
というRedisのMasterの
DNSレコードが利用できるようになる
51
Slide 52
Slide 52 text
nothing
Old Master fail
master.foo-redis.service.dc1.consul
52
master.foo-redis.service.dc1.consul
52
192.0.2.11
check ok
Slide 53
Slide 53 text
nothing
Old Master fail
master.foo-redis.service.dc1.consul
53
master.foo-redis.service.dc1.consul
53
192.0.2.11
check ok
check ng
nothing
Slide 54
Slide 54 text
nothing
Old Master fail
Run Redis fail over
nothing
master.foo-redis.service.dc1.consul
54
master.foo-redis.service.dc1.consul
54
192.0.2.11
check ok
check ng
failover
nothing
nothing
Slide 55
Slide 55 text
master.foo-redis.service.dc1.consul
55
192.0.2.11
check ok
check ng
failover complete
failover
nothing
192.0.2.12(New)
nothing
Slide 56
Slide 56 text
問題点
このやり方だとConsul上で
常にSlave側がFailした
状態になってしまうので
Consulを利用した
ステートメント管理の
知見のある方、
教えてください&
Master(OK)
Slave(NG)
56
Slide 57
Slide 57 text
Consul ポート8600問題
57
Slide 58
Slide 58 text
ConsulがDNSを返してくれるポートが
8600ポートなので、全サーバに
ConsulとDnsmasqを導入し、
「.consul」
のドメインへのリクエストは
全て8600ポートに
問い合わせるようにした
58
Slide 59
Slide 59 text
conf-dir=/etc/dnsmasq.d
server=/consul./127.0.0.1#8600
/etc/dnsmasq.conf
/etc/dnsmasq.d/10-consul
設定例
59
Slide 60
Slide 60 text
Redisの冗長化完了
60
Slide 61
Slide 61 text
MySQLの場合
61
Slide 62
Slide 62 text
MySQL 5.6(GTID)
mysqlfailover
MySQL Ver. 5.6.22-2
mysql-utilities Ver. 1.5.4-1
62
Slide 63
Slide 63 text
mysqlfailoverとは
63
Slide 64
Slide 64 text
mysqlfailoverとは
他にも一撃で
レプリケーション環境を構築できる
mysqlreplicateなど
便利コマンドが内包されている
MySQLが提供してくれている
MySQL Utilitiesという
便利ツールの中のひとつのコマンド
64
Slide 65
Slide 65 text
mysqlfailoverを利用することで
障害時にMasterを
遷移することはできるが
Redisと同様にどのように
MySQLを利用している
アプリケーションへ
稼動系の切り替えを伝達するか
65
Slide 66
Slide 66 text
Consul
Consul Ver.0.5.0
66
Slide 67
Slide 67 text
mysqlfailoverには
遷移実行前(before_exec)と
遷移実行後(after_exec)で
任意のコマンドが実行できる
67
Slide 68
Slide 68 text
この機能を利用して
Consulで
DNSレコードを
操作してみましょう
68
Slide 69
Slide 69 text
#!/bin/bash
curl -X PUT -d '{"Node":"foo-db-master"}' localhost:8500/v1/catalog/deregister
curl -X DELETE http://localhost:8500/v1/kv/foo-db-master
遷移実行前(before_exec)
deregister-master-db.sh
遷移前にMasterのDNSレコードを削除し
接続できないようにする
69
Slide 70
Slide 70 text
#!/bin/bash
curl -X PUT -d '{"Node":"foo-db-slave"}' localhost:8500/v1/catalog/deregister
curl -X PUT -d '{"Node":"foo-db-master}", "Address":"192.0.2.110"}' \
localhost:8500/v1/catalog/register
curl -X PUT -d '192.0.2.110' http://localhost:8500/v1/kv/foo-db-master
遷移実行後(after_exec)
register-master-db.sh
Masterの遷移が正常に完了した後
Masterのレコードを新MasterのIPアドレスで返す
※ kvは念のための設定
70
Slide 71
Slide 71 text
192.0.2.111
start failover
foo-db-master.node.dc1.consul
71
Slide 72
Slide 72 text
192.0.2.111
start failover
run before_exec
deregister
foo-db-master.node.dc1.consul
72
Slide 73
Slide 73 text
192.0.2.111
start failover
run before_exec
failover
deregister
nothing
foo-db-master.node.dc1.consul
73
Slide 74
Slide 74 text
192.0.2.111
start failover
run before_exec
run after_exec
failover
deregister
192.0.2.112(New)
nothing
foo-db-master.node.dc1.consul
74
Slide 75
Slide 75 text
MySQLの冗長化完了
75
Slide 76
Slide 76 text
しかし、ここで課題が
内部の名前解決をすべて
Consulに委ねてしまうと、
Consulの死 = サービスの死に
つながってしまう
76
Slide 77
Slide 77 text
これではせっかく
サービスの継続性を狙って
自動遷移する冗長構成を
構築したものの
Consulの存在自体が
リスクになる
77
Slide 78
Slide 78 text
あ、Consulが返してる
DNSレコードを
hostsに直接書いちゃお☺
78
Slide 79
Slide 79 text
hostsにDNSレコードを
書いておけば
万が一
Consulの応答がなくなっても
サービスへの影響はなくなる
79
Slide 80
Slide 80 text
consul-template
consul-template Ver. v0.7.0
80
Slide 81
Slide 81 text
consul-template とは
81
Slide 82
Slide 82 text
consul-template とは
Consulの管理しているDNSレコードを
ファイルに書き出す
Consulの管理してるDNSレコードに
変更があった際に任意のコマンドを
実行できる便利ツール
82
Slide 83
Slide 83 text
変化があった場合に
/etc/hostsを書き換えて
Dnsmasqを再起動させるようにした
consul = "127.0.0.1:8500"
template {
source = "/etc/hosts.ctmpl"
destination = "/etc/hosts"
command = "service dnsmasq restart"
}
/etc/consul.d/consul-template.cfg
83
Slide 84
Slide 84 text
# This file generated by consul-template
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
# node{{ range nodes }}
{{.Address}} {{.Node}}
{{.Address}} {{.Node}}.node.dc1.consul{{end}}
{{range services}}
# service {{.Name}}{{range service .Name}}
{{.Address}} {{.Name}}.service.dc1.consul{{end}}{{end}}
/etc/hosts.ctmpl
84
Slide 85
Slide 85 text
作成されるhostsファイル
# This file generated by consul-template
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
# node
192.0.2.111 foo-db-master
192.0.2.111 foo-db-master.node.dc1.consul
192.0.2.112 foo-db-slave
192.0.2.112 foo-db-slvave.node.dc1.consul
...
# service bar-app
192.0.2.11 bar-app.service.dc1.consul
192.0.2.12 bar-app.service.dc1.consul
85
Slide 86
Slide 86 text
/usr/local/bin/consul-template \
-config=/etc/consul.d/consul-template.cfg
設定ファイルを指定し
DaemontoolsやSupervisorなどで
起動させておく
86
Slide 87
Slide 87 text
# node
192.0.2.11 foo-app01
192.0.2.11 foo-app01.node.dc1.consul
192.0.2.12 foo-app02
192.0.2.12 foo-app02.node.dc1.consul
192.0.2.13 foo-app03
192.0.2.13 foo-app03.node.dc1.consul
# service foo-app
192.0.2.11 foo-app.service.dc1.consul
192.0.2.12 foo-app.service.dc1.consul
192.0.2.13 foo-app.service.dc1.consul
試しにfoo-app02を止めると
87
Slide 88
Slide 88 text
こうなる。便利
こうなる
# node
192.0.2.11 foo-app01
192.0.2.11 foo-app01.node.dc1.consul
192.0.2.13 foo-app03
192.0.2.13 foo-app03.node.dc1.consul
# service foo-app
192.0.2.11 foo-app.service.dc1.consul
192.0.2.13 foo-app.service.dc1.consul
88
Slide 89
Slide 89 text
Redis Sentinel + Consul
MySQL(GTID) + mysqlfailover + Consul
Consul + consul-template
89
Slide 90
Slide 90 text
この時点で
解決できていない課題
90
Slide 91
Slide 91 text
MySQLおよびRedisの
遷移時のダウンタイム問題を
解決できていない
稼働系常時遷移を
実践している人いたら
知見を下さい。
よろしくお願いします&
91
Slide 92
Slide 92 text
今考えていることメモ
Web API側、ネイティブアプリ側
それぞれでデータストアに
アクセスできない時に
即エラーを返さず、
バッファリング機能を搭載し
エラーまでのタイムアウト時間を
伸ばすか？しかしその影響は
どの範囲まで許容できる？
92
Slide 93
Slide 93 text
などなど考えていたが
いきなり100％を目指すのは難しい
細かい機能リリース時に
念のためメンテナンスを実施する
昭和的運用だったので
一旦は都度メンテナンスの
タイミングで
正常系を遷移する予定だった
93
Slide 94
Slide 94 text
そして
94
Slide 95
Slide 95 text
この時構築中の
システムが乗る
アプリケーションは
リリースに追われ
結合テストや負荷テストなど
十二分に行われてはいないまま
リリース日が刻々と迫っていた
95
Slide 96
Slide 96 text
本題
96
Slide 97
Slide 97 text
我々は
どのように
冗長化を失敗したのか
97
Slide 98
Slide 98 text
問題
hostsの場合
98
Slide 99
Slide 99 text
内部間の通信が01, 02とある内の
01のみにアクセスが集中していた
access no access
01 02
99
Slide 100
Slide 100 text
何が起こっていたのか
100
Slide 101
Slide 101 text
hostsに設定が書いてある場合
上から順に見ていき、
最初にヒットしたレコードを返す
hosts
---
# service foo-app
192.0.2.11 foo-app.service.dc1.consul
192.0.2.12 foo-app.service.dc1.consul
---
101
request
response
Slide 102
Slide 102 text
01にしか処理が行かないのは
当然といえば当然だった
やる前に気付け問題
102
Slide 103
Slide 103 text
解決作
103
Slide 104
Slide 104 text
Dnsmasq
nsswitch.conf
Dnsmasq Ver. 2.48-14
104
Slide 105
Slide 105 text
全サーバにDnsmasqが
稼働していたので
nsswitch.confで
hostsより先にDnsmasqを
先に見るようにした
105
Slide 106
Slide 106 text
nsswitch.conf
hostsの部分を書き換える
hosts: files dns
before:
after: hosts: dns files
106
Slide 107
Slide 107 text
DNSラウンドロビン
されるようになった
107
Slide 108
Slide 108 text
問題
mysqlfailoverの場合
108
Slide 109
Slide 109 text
mysqlfailoverのログを見ると
ちょくちょくhealth checkに
失敗していた
109
Slide 110
Slide 110 text
mysqlfailoverの仕組み
110
Slide 111
Slide 111 text
def is_alive(self):
"""Determine if connection to server is still alive.
Returns bool - True = alive, False = error or cannot connect.
"""
res = True
try:
if self.db_conn is None:
res = False
else:
# ping and is_connected only work partially, try exec_query
# to make sure connection is really alive
retval = self.db_conn.is_connected()
if retval:
self.exec_query("SHOW DATABASES")
else:
res = False
except:
res = False
return res
Health Check時に
MySQLに接続し
SHOW DATABASESを実行
111
Slide 112
Slide 112 text
def _reconnect_master(self, pingtime=3):
"""Tries to reconnect to the master
This method tries to reconnect to the mast
after 3 attemps, returns False.
"""
if self.master and self.master.is_alive():
return True
is_connected = False
i = 0
while i < 3:
try:
self.master.connect()
is_connected = True
break
except:
pass
time.sleep(pingtime)
i += 1
return is_connected
失敗した場合は
ping(pingtime) x3 試す
x3はハードコードされている
112
Slide 113
Slide 113 text
どうにか３回のリトライ中に
成功はしているようだが、
そもそも
ステージングで検証した時は
Failは起こらなかった...
113
Slide 114
Slide 114 text
ping(pingtime) x3の回数を
増やして様子を見る案もあったが
Failの原因が不明のまま
自動遷移の機構を
入れておくのは危険だった
114
Slide 115
Slide 115 text
原因が不明なため、
Redisも含めた
自動遷移のシステムを停止した
115
Slide 116
Slide 116 text
冗長化は幻しとなった
116
Slide 117
Slide 117 text
原因について
117
Slide 118
Slide 118 text
原因その１
VPNがおかしい
118
Slide 119
Slide 119 text
パブリック層から
プライベート層への接続が
日本中をめぐっていた
119
Slide 120
Slide 120 text
不要なルーティングを
改修した
120
Slide 121
Slide 121 text
mysqladmin ping
121
Slide 122
Slide 122 text
122
Slide 123
Slide 123 text
原因その２
謎のスロークエリ
123
Slide 124
Slide 124 text
時間によって
同じクエリでも
やたら遅いクエリが
存在していた
124
Slide 125
Slide 125 text
クラウド上のDBサーバが
乗っかっているホストの
I/Oが忙しいのでは？と
仮説を立て、DBサーバを
別のホストに移動してもらった
125
Slide 126
Slide 126 text
Slow Queries
126
Slide 127
Slide 127 text
127
Slide 128
Slide 128 text
その３
根本的原因
そもそも利用していた
クラウドサービスが
はじまったばかりで
全然枯れていなかった
128
Slide 129
Slide 129 text
129
Slide 130
Slide 130 text
不穏な動作の原因は
大体特定できたが
ネットワークの不調など
予期しないタイミングで
遷移されても困る
130
Slide 131
Slide 131 text
自動遷移の利便性
- ＭＴＴＲ（平均修理時間）の大幅な削減
- 復旧作業時のヒューマンエラー防止
- 圧倒的な満足感
- 人間がいない清らかな世界感
131
Slide 132
Slide 132 text
手動遷移の優位性
- 意図したタイミングで遷移が可能
- 冗長監視システム誤動作の心配がない
I'm fail over button
Don't push me !!
132
Slide 133
Slide 133 text
復旧時間を犠牲にして、
我々は自動遷移システムを止めた
その代わり
一撃で正確に遷移するような
ヒューマンエラーの起こらない
仕組みを入れることにした
133
Slide 134
Slide 134 text
そして
134
Slide 135
Slide 135 text
のっかるアプリケーションも
乗せるサーバ周りも
問題を抱えたまま
リリースを日を迎えた
135
Slide 136
Slide 136 text
昼寝ができるぐらい遅い
レスポンスタイム
繰り返されるN+1クエリ
それが要件の結果の
動作だったのか
今となっては
誰もわからない各機能
136
Slide 137
Slide 137 text
迫り来る
圧倒的成長機会に
感謝をしながら
改修対応を
行う日々が始まった
※もちろん若干盛っています
137
Slide 138
Slide 138 text
138
Slide 139
Slide 139 text
まとめ、学び
139
Slide 140
Slide 140 text
どれだけリリース直前まで
炎上していても
絶対に
本番環境と同等のシステム構成で
負荷テストをしよう
実証
140
Slide 141
Slide 141 text
結合テストが難しい場合は
各機能毎に負荷テストが
実施できるようにしよう
外部との依存部分を
最小限のモックにするなど
結合を待ってから試験をすることは
極力避けるようにしよう
個別性能試験
141
Slide 142
Slide 142 text
使う理由が良くわからなくても
自分が担当するところは
最終的に自分が
責任を持つことになるので
疑問点をなくすために
完全に検証をやりきろう
道具への理解と責任
142
Slide 143
Slide 143 text
期待するな、
計測しよう
143
Slide 144
Slide 144 text
挑戦するなら
徹底的に検証しよう
144
Slide 145
Slide 145 text
手に馴染んだ
道具を使おう
145
Slide 146
Slide 146 text
当たり前のことを
当たり前に正しく行おう
146
Slide 147
Slide 147 text
Production System is
not your sandbox.
147
Slide 148
Slide 148 text
Webサービスが続く限り
顧客へ価値を
届け続けるために
我々の稼働率の戦いは
これからも続く
148
Slide 149
Slide 149 text
149
Slide 150
Slide 150 text
次回予告
150
Slide 151
Slide 151 text
式年遷宮
インフラストラクチャ
三部作最終章
151
Slide 152
Slide 152 text
クラウドの中心で
式年遷宮を叫んだ愚か者
Take care of system.
鋭意製作中
152
Slide 153
Slide 153 text
To be continued
153
Slide 154
Slide 154 text
おわり
ありがとう
ございました
154
Slide 155
Slide 155 text
Redis
http://redis.io/
Redis Sentinel
http://redis.io/topics/sentinel
MySQL
https://www-jp.mysql.com/
MySQL Utilities
https://dev.mysql.com/downloads/utilities/
Consul by HashiCorp
https://www.consul.io/
consul-template
https://github.com/hashicorp/consul-template
Dnsmasq - network services for small networks. - Simon Kelley
http://www.thekelleys.org.uk/dnsmasq/doc.html
Consulと自作OSSを活用した100台規模のWebサービス運用 by FUJIWARA Shunichiro
https://speakerdeck.com/fujiwara3/consultozi-zuo-osswohuo-yong-sita100tai-gui-mo-
falsewebsabisuyun-yong
参考URL
155
Slide 156
Slide 156 text
参考URL
式年遷宮Infrastracture / さよならインターネット
http://blog.kenjiskywalker.org/blog/2013/08/11/shikinen-sengoo-infrastracture/
神宮式年遷宮 / Wikipedia
https://ja.wikipedia.org/wiki/%E7%A5%9E%E5%AE%AE%E5%BC%8F
%E5%B9%B4%E9%81%B7%E5%AE%AE
冗長化 / Wikipedia
https://ja.wikipedia.org/wiki/%E5%86%97%E9%95%B7%E5%8C%96
完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成
なシステムと、それを支える未完成な人間だけだ / YAPC::Asia Tokyo 2014
http://yapcasia.org/2014/talk/show/4c7651e8-ed53-11e3-9faf-6ba36aeab6a4
156
Slide 157
Slide 157 text
「迷ったら健全な方」
Being healthy dev and ops in Cookpad by Issei Naruta / Speaker Deck
https://speakerdeck.com/mirakui/being-healthy-dev-and-ops-in-cookpad
「仕事道具に対しても責任を持ちたい」
監視ツールの話 by @kazeburo / slideshare
http://www.slideshare.net/kazeburo/ss-13361002
参考URL
157
ImmutableServer / Martin Fowler
http://martinfowler.com/bliki/ImmutableServer.html
BlueGreenDeployment / Martin Fowler
http://martinfowler.com/bliki/BlueGreenDeployment.html
Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components / Chad Fowler
http://chadfowler.com/blog/2013/06/23/immutable-deployments/
インフラ系技術の流れ / Gosuke Miyashita
http://mizzy.org/blog/2013/10/29/1/
Rebuild.fm 25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita).
http://rebuild.fm/25/