yapcasia2015

我々はどのように冗長化を失敗したのか

Transcript

1. 我々は   どのように   冗長化を失敗したのか YAPC::Asia  2015   2015/08/22  (Day  2) kenjiskywalker Photos : https://www.flickr.com/photos/gsfc 1
2. ある思想を持って   システム構築を行い   失敗をした話をします よろしくお願いします 2
3. 話すこと 挑戦したこと   冗長化について   Redis  +  Redis  Sentinel   Consul   MySQL  +  mysqlfailover   consul-template   hostsの順番   クラウドという名の混乱   対応   冗長化の終わり、そして 3
4. 挑戦したこと 4
5. 式年遷宮   インフラストラクチャ 5
6. 式年遷宮とは 6
7. ”神宮式年遷宮は、   　神宮（伊勢神宮）において   　行われる式年遷宮   　（定期的に行われる遷宮）   　である。”   Wikipedia調べ 7
8. 何故   式年遷宮を行うのか 8
9. 神道での清浄さの維持   技術の伝承という継続性 Wikipedia調べ ”式年遷宮が20年ごとに行われる理由についても、   　同じく確たる記録はないため不明である。   　推測される主な理由としては、   　以下の5点が挙げられる。” からの一部抜粋 9
10. 式年遷宮とは   長期的な品質の担保と   その概念自体の継続性の維持を   目的としたアーキテクチャ   ではなかったのだろうか(仮説) 10
11. Webサービスの運用と   式年遷宮 11
12. 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
13. 故障率曲線 ＭＴＢＦ（平均故障間隔）   ＭＴＴＲ（平均修理時間） 辛さの平均値 13
14. 「動くものは必ず壊れる」 Webサービスの運用 相反するふたつの価値観を   結びつけ成長させる必要がある 14 「24時間365日      正常に動き続けなけければ   　ならない」
15. 冗長化 15
16. ”冗長化（じょうちょうか）とは、   　システムの一部に   　何らかの障害が発生した場合に備えて、   　障害発生後でも   　システム全体の機能を維持し   　続けられるように予備装置を   　平常時からバックアップとして   　配置し運用しておくこと。   　冗長化によって得られる安全性は   　冗長性と呼ばれる。” Wikipedia調べ 16
17. 異常が発生した際に   自動的にアクティブが   遷移する設定を   導入しているところは   結構あると思う 17
18. しかし 18
19. 障害発生時、   正常に   切り替わらないことが   ほとんどである （個人の感想であり効果・効能を示すものではありません） 19
20. そこで 20
21. 平常時であっても   常に冗長構成の   アクティブ/スタンバイを   切り替えることによって   異常時の正常動作を   担保できるのではないか Active/Standby Active/Standby 21
22. それって   式年遷宮では？ 22
23. それって   式年遷宮では？ 23
24. 式年遷宮   インフラストラクチャ 思想 (正常時も常に稼動系を切り替える) 24
25. 構成 25
26. 構成 Public Web Server A 02 Web Server A 01 Web Sever B 02 Web Server B 01 26
27. 構成 MySQL A Slave MySQL A Master Private MySQL B Slave MySQL B Master 27
28. 構成 Private Public VPN 28
29. nginx + Redis(Slave) Application A 02 各ウェブサーバでは   nginxとRedis、   Web  Applicationが動いている nginx + Redis(Master) Application A 01 29
30. この構成で   式年遷宮を   実装する場合の課題 30
31. Master/Slave方式の   冗長化されたシステムを   どのように   式年遷宮に対応させるか 31
32. Redisの場合 32
33. Redis  Sentinel   Redis  Ver.  2.8.9 33
34. Redis  Sentinel？   基本スプリットブレインを   予防するためには   最低でも   サーバが３台必要なのでは？ 34
35. 監視用のサーバを置いた場合   監視用のサーバも遷移させる？ 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
36. 冗長化の為に   システム自体を   複雑化するのは避けたい 36
37. 台数をそのままに   Redis  Sentinelを導入 37
38. Master : Sentinel x1 Slave : Sentinel x2 Redis Master Sentinel x1 Redis Master Sentinel x2 38
39. Masterが遷移した際に   Redis  Sentinelの数を   操作する(Master  x1/Slave  x2)に   する必要がある Redis (New) Slave Sentinel x1 ⇣ Sentinel x2 Redis (New) Master Sentinel x2 ⇣ Sentinel x1 39
40. 詰めが甘いところはあるが   可能ではありそうだ 40
41. サーバに障害が発生した際に   アプリケーションをどのように   新しいMasterへ向き先を変えるか Redis Master Host 01 Redis (New) Master Host 02 41
42. Consul   Consul  Ver.  0.5.0   42
43. Consul  とは 43
45. Consulとは   いい感じに   DNSレコードを   返すもの 45
46. このConsulを利用して   RedisのMasterが   遷移したことを   アプリケーションへ   知らせたい 46
47. #!/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
48. #!/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
49. #!/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
50. { "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
51. 「master.foo-redis.service.dc1.consul」 というRedisのMasterの   DNSレコードが利用できるようになる   51
52. nothing Old Master fail master.foo-redis.service.dc1.consul 52 master.foo-redis.service.dc1.consul 52 192.0.2.11 check ok
53. 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
54. 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
55. 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
56. 問題点 このやり方だとConsul上で   常にSlave側がFailした   状態になってしまうので   Consulを利用した   ステートメント管理の   知見のある方、   教えてください& Master(OK) Slave(NG) 56
57. Consul  ポート8600問題 57
58. ConsulがDNSを返してくれるポートが   8600ポートなので、全サーバに   ConsulとDnsmasqを導入し、   「.consul」 のドメインへのリクエストは   全て8600ポートに   問い合わせるようにした 58
59. conf-dir=/etc/dnsmasq.d server=/consul./127.0.0.1#8600 /etc/dnsmasq.conf /etc/dnsmasq.d/10-consul 設定例 59
60. Redisの冗長化完了 60
61. MySQLの場合 61
62. MySQL  5.6(GTID)   mysqlfailover   MySQL  Ver.  5.6.22-2   mysql-utilities  Ver.  1.5.4-1 62
63. mysqlfailoverとは 63
64. mysqlfailoverとは 他にも一撃で   レプリケーション環境を構築できる mysqlreplicateなど   便利コマンドが内包されている MySQLが提供してくれている   MySQL  Utilitiesという   便利ツールの中のひとつのコマンド 64
65. mysqlfailoverを利用することで   障害時にMasterを   遷移することはできるが Redisと同様にどのように   MySQLを利用している   アプリケーションへ   稼動系の切り替えを伝達するか 65
66. Consul   Consul  Ver.0.5.0   66
67. mysqlfailoverには 遷移実行前(before_exec)と   遷移実行後(after_exec)で 任意のコマンドが実行できる 67
68. この機能を利用して   Consulで   DNSレコードを   操作してみましょう 68
69. #!/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
70. #!/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
71. 192.0.2.111 start failover foo-db-master.node.dc1.consul 71
72. 192.0.2.111 start failover run before_exec deregister foo-db-master.node.dc1.consul 72
73. 192.0.2.111 start failover run before_exec failover deregister nothing foo-db-master.node.dc1.consul 73
74. 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
75. MySQLの冗長化完了 75
76. しかし、ここで課題が 内部の名前解決をすべて   Consulに委ねてしまうと、   Consulの死  =  サービスの死に   つながってしまう 76
77. これではせっかく   サービスの継続性を狙って   自動遷移する冗長構成を   構築したものの   Consulの存在自体が   リスクになる 77
78. あ、Consulが返してる   DNSレコードを   hostsに直接書いちゃお☺ 78
79. hostsにDNSレコードを   書いておけば   万が一   Consulの応答がなくなっても   サービスへの影響はなくなる 79
80. consul-template   consul-template  Ver.  v0.7.0 80
81. consul-template  とは 81
82. consul-template  とは Consulの管理しているDNSレコードを   ファイルに書き出す Consulの管理してるDNSレコードに   変更があった際に任意のコマンドを   実行できる便利ツール 82
83. 変化があった場合に   /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
84. # 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
85. 作成される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
86. /usr/local/bin/consul-template \ -config=/etc/consul.d/consul-template.cfg 設定ファイルを指定し   DaemontoolsやSupervisorなどで   起動させておく 86
87. # 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
88. こうなる。便利 こうなる # 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
89. Redis Sentinel + Consul MySQL(GTID) + mysqlfailover + Consul Consul + consul-template 89
90. この時点で   解決できていない課題 90
91. MySQLおよびRedisの   遷移時のダウンタイム問題を   解決できていない   稼働系常時遷移を   実践している人いたら   知見を下さい。   よろしくお願いします& 91
92. 今考えていることメモ Web  API側、ネイティブアプリ側   それぞれでデータストアに   アクセスできない時に   即エラーを返さず、   バッファリング機能を搭載し   エラーまでのタイムアウト時間を   伸ばすか？しかしその影響は   どの範囲まで許容できる？ 92
93. などなど考えていたが   いきなり100％を目指すのは難しい 細かい機能リリース時に   念のためメンテナンスを実施する   昭和的運用だったので   一旦は都度メンテナンスの   タイミングで   正常系を遷移する予定だった 93
94. そして 94
95. この時構築中の   システムが乗る   アプリケーションは   リリースに追われ 結合テストや負荷テストなど   十二分に行われてはいないまま   リリース日が刻々と迫っていた 95
96. 本題 96
97. 我々は   どのように   冗長化を失敗したのか 97
98. 問題   hostsの場合 98
99. 内部間の通信が01,  02とある内の   01のみにアクセスが集中していた　 access no access 01 02 99
100. 何が起こっていたのか 100
101. 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
102. 01にしか処理が行かないのは   当然といえば当然だった   やる前に気付け問題 102
103. 解決作 103
104. Dnsmasq   nsswitch.conf   Dnsmasq  Ver.  2.48-14 104
105. 全サーバにDnsmasqが   稼働していたので   nsswitch.confで   hostsより先にDnsmasqを   先に見るようにした 105
106. nsswitch.conf   hostsの部分を書き換える hosts: files dns before: after: hosts: dns files 106
107. DNSラウンドロビン   されるようになった 107
108. 問題   mysqlfailoverの場合 108
109. mysqlfailoverのログを見ると   ちょくちょくhealth  checkに   失敗していた 109
110. mysqlfailoverの仕組み 110
111. 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
112. 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
113. どうにか３回のリトライ中に   成功はしているようだが、   そもそも   ステージングで検証した時は   Failは起こらなかった... 113
114. ping(pingtime)  x3の回数を   増やして様子を見る案もあったが   Failの原因が不明のまま   自動遷移の機構を   入れておくのは危険だった 114
115. 原因が不明なため、   Redisも含めた   自動遷移のシステムを停止した 115
116. 冗長化は幻しとなった 116
117. 原因について 117
118. 原因その１   VPNがおかしい 118
119. パブリック層から   プライベート層への接続が   日本中をめぐっていた 119
120. 不要なルーティングを   改修した 120
121. mysqladmin  ping 121
123. 原因その２   謎のスロークエリ 123
124. 時間によって   同じクエリでも   やたら遅いクエリが   存在していた 124
125. クラウド上のDBサーバが   乗っかっているホストの   I/Oが忙しいのでは？と   仮説を立て、DBサーバを   別のホストに移動してもらった 125
126. Slow  Queries 126
128. その３   根本的原因   そもそも利用していた   クラウドサービスが   はじまったばかりで   全然枯れていなかった 128
130. 不穏な動作の原因は   大体特定できたが   ネットワークの不調など   予期しないタイミングで   遷移されても困る 130
131. 自動遷移の利便性   -  ＭＴＴＲ（平均修理時間）の大幅な削減   - 復旧作業時のヒューマンエラー防止   - 圧倒的な満足感   - 人間がいない清らかな世界感 131
132. 手動遷移の優位性   -  意図したタイミングで遷移が可能   - 冗長監視システム誤動作の心配がない I'm fail over button Don't push me !! 132
133. 復旧時間を犠牲にして、   我々は自動遷移システムを止めた   その代わり   一撃で正確に遷移するような   ヒューマンエラーの起こらない   仕組みを入れることにした 133
134. そして 134
135. のっかるアプリケーションも   乗せるサーバ周りも   問題を抱えたまま   リリースを日を迎えた 135
136. 昼寝ができるぐらい遅い   レスポンスタイム 繰り返されるN+1クエリ それが要件の結果の   動作だったのか   今となっては   誰もわからない各機能 136
137. 迫り来る   圧倒的成長機会に   感謝をしながら   改修対応を   行う日々が始まった ※もちろん若干盛っています 137
139. まとめ、学び 139
140. どれだけリリース直前まで   炎上していても   絶対に   本番環境と同等のシステム構成で   負荷テストをしよう 実証 140
141. 結合テストが難しい場合は   各機能毎に負荷テストが   実施できるようにしよう   外部との依存部分を   最小限のモックにするなど   結合を待ってから試験をすることは   極力避けるようにしよう 個別性能試験 141
142. 使う理由が良くわからなくても   自分が担当するところは   最終的に自分が   責任を持つことになるので   疑問点をなくすために   完全に検証をやりきろう 道具への理解と責任 142
143. 期待するな、   計測しよう 143
144. 挑戦するなら   徹底的に検証しよう 144
145. 手に馴染んだ   道具を使おう 145
146. 当たり前のことを   当たり前に正しく行おう 146
147. Production  System  is   not  your  sandbox. 147
148. Webサービスが続く限り   顧客へ価値を   届け続けるために   我々の稼働率の戦いは   これからも続く 148
150. 次回予告 150
151. 式年遷宮   インフラストラクチャ   三部作最終章 151
152. クラウドの中心で   式年遷宮を叫んだ愚か者   Take  care  of  system.   鋭意製作中 152
153. To  be  continued 153
154. おわり ありがとう   ございました 154
155. 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
156. 参考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
157. 「迷ったら健全な方」   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/