2020-01-21

（後日談）保育園にChaos Engineeringを提案した話

先日、うちの子供が通う保育園から、うちの子供に対するインシデントの報告を受け、今後の対策として保育園にChaos Engineeringを提案するという我ながら変なことをしてきたのですが、その後正式なインシデントレポートと対応策の報告を受けたので書きます。

ことの発端はこちらの記事をお読みください。

qiita.com

保育園からその後の報告をは12月末には聞いており、上記の記事が思った以上に反響があったので、その後どうなったかは書こうと思いいたのですが、年末に家族が次々と倒れ家庭内パンデミックなどがあり書く時間がなくだいぶ時間が開いてしまいました。

なお、先に述べておくと、今回はインシデントレポートとそれに対する対策、フィードバックがメインなので、Chaos Engineeringを期待された方には申し訳ありません。

Chaos Engineeringの原則的には「既知の問題」（今回だと子供が避難訓練からの帰りに行方不明になった）があるならそっちを解決するのが優先で、「新しい問題」（避難訓練のマニュアル不備等）を発見したければChaos Engineeringを導入するのが良いとされているので、今回は既知の問題対応ということもあり再提案は見送りました。

もしChaos Engineeringについてもう少し知りたいということであれば、昨年拙文ながら2本ほど資料を作成しているので、そちらをご覧いただけると参考になるかもしれません。

speakerdeck.com

正確な事故の経緯

前回事故の経緯は聞いたものの、正確なタイムラインを伝えられていなかったのでそこの説明から始まりました。タイムラインとしては以下のような流れだったとのこと。

避難訓練開始
マンション屋上への避難訓練完了、全員の無事を確認。
アプリで避難訓練終了を保護者に通知
マンション屋上より階段を使って園児を降ろし帰園
点呼の結果、園児が1名（うちの子）足りないインシデント発覚
先生2名がマンションに戻る
マンション管理人が保護してくれていたのでお礼を言って帰園
保育園の経営母体＆市にインシデントを報告
保護者（うちの妻）に園長から連絡
保育園内のスタッフで話し合い事故の状況や原因、改善点について議論
保護者へ謝罪と説明

4の最中にうちの子供は階段途中の廊下方面に歩いていってしまったと思われるが、先生はそれを見つけることができなかったとのこと（本人は説明できないし誰も現場を見てないのであくまで推測）。ここからうちの子のがいないと気づきマンションに戻って発見するまでは約15分程度だったとのことですが、靴が脱げて泣きながら歩いてるうちの子をマンション管理人の方が見つけてくれていなかったらと思うと正直ゾッとしました。

また、7のあと妻に連絡が行くまでに30分ほど時間が空いていたのですが、不正確な情報で混乱させないためになるべく正確な話をするために情報をまとめていたとのことなので、まあそういうものかと納得。

事故の原因（保育園側の考察）

前回の話し合いでも聞いていた内容とほとんど重複していたものの、インシデントの詳細レポートが出てきたのでもう少し細かい原因なども出てきました。

最初に泣いた子の対応に保育士の人数を割いたので、最終グループは保育士一人に対して7名の園児（2歳前後）になり全員を目視で管理できなかった。
誰がどの子を連れて降りたか確認をしていなかった
スタッフの間で「誰かが手伝いに来てくれるはず」という思い込みで移動を始めてしまった
マンションの階段を降りてから園に戻る前に点呼を怠った
マンション屋上に園児が残っていないことを確認していなかった
避難訓練のマニュアルに避難訓練完了までは記載していたが帰園については記載がなく、各自の判断で動いていた

今後の対策（案）

保育園からは前回の話し合いの際に我々から言われたコメントなども含め、再度スタッフ全員で話し合い以下の対策を検討していただきました。

避難訓練のマニュアルに帰園までのマニュアルを追記
保育士一人あたりで対応する園児の数を設定
点呼のタイミングをマニュアルに記載し、点呼の際は保育士2名以上で確認をする
屋上から園児を連れて降りる際に、連れて降りる園児の名前を声に出して降りる
責任者2名がマンション屋上に園児が残っていないことを確認

対策案を聞いての提案

保育士一人あたりに設定した対応する園児の数について

前回のインシデント後の説明の際にも園長からは「避難訓練をするにあたり十分な数のスタッフを配置していた」という話をされていたのですが、よく考えてみると避難訓練のために十分なスタッフを用意し、うまく行ったところで、本当に地震などの災害があった際に十分なスタッフがいない場合はどうするのかが気になったので質問してみました。

これは前回も「避難訓練をこなすことが目的になっていた」という話をされたのですが、災害発生時に訓練どおりには行きませんでしたでは済まない話なので、スタッフが少ない場合でも避難ができるようになっているのか再度確認と検討をお願いしました。

点呼のタイミングをマニュアルに記載し、点呼の際は保育士2名以上で確認をする

マニュアルに点呼のタイミングを記載したのはとてもよかったのですが、点呼の担当から「以上」の部分を消して担当を2名なら2名にして担当者をはっきり割り当てたほうが良いのではとお伝えしました。というのも、学術的にもダブルチェック以上はあまり効果をなさないどころか、以下のTweetのように「誰かがやっただろう」や「他の人がやったから大丈夫だろう」と場合によってはチェックが形骸化してしまう恐れがあるので、やるのであれば担当者を予め決めておき、その2名ないしは3名に責任を持って確認させたほうがよいのではという話をしました。

トリプルチェックの弊害 #現場猫 pic.twitter.com/jVkujwrphV
— からあげのるつぼ (@karaage_rutsubo) 2019年8月2日

imamura-net.com

ダブルチェックの有効性を再考する - 厚生労働省 (PDF)

屋上から園児を連れて降りる際に、連れて降りる園児の名前を声に出して降りる

これについてはなんかもっといい解決策はないかと思いましたが、思いつかなかったのでとりあえず現状の案に対するコメントをしました。

マンション屋上から連れて降りる園児の名前を言うだけでなく、下からそれを確認してもらったほうが良いのではないかという話をしました。コミュニケーションでは「私は言った」に対して「私は知らない・言われていない・聞いていない」というミスコミュニケーションが起こりがちです。そのため、声を出して連れて行ったものの、下で園児を受け取る側が正解を把握できていない可能性があり、園児がいなくなった場合に気づくのに遅れる可能性があるのではという話をしました。

これについてはマニュアルにも何らかの確認（下から返事 or 復唱）が盛り込まれるようになるそうです。

その他

改善された避難訓練のマニュアル自体は本当によく（多分Excelで）できていて感心したのですが、やはり前回Chaos Engineeringを提案したように想定外の事態やうまく行かないケースについては検討がされておらず「ミスなくやればこの通りにできるはず！」という内容になっていました。

例えば、「地震が収まった後全員が園庭にて確認された後、マンション屋上への避難を開始する」という記載があったのですが、最悪のケースとして園庭に集合した段階で園児が1名見当たらない場合どうするかなどの記載はなく

いない園児を待つのか？待たずに避難するのか？
待つのならどれぐらい待つのか？
いない園児は探しに行くのか？
探しに行くのであれば誰が探しに行くのか？
etc...

実際に起きうる（というか実際1名いなくなった）事例に対しての検討が抜け落ちているので、そのあたりはもう一度良く考えてもらいたいという話をしました。

何度だって言いたいのですが、1度あることは何度でもあるのです。（きかんしゃトーマスだってそう言ってます。）

www.youtube.com

また、マニュアルにはなくてもいいのですが、なぜ屋上からの降りる宣言、ダブルチェックなどの記載があるのかについて、「よくわからないけど昔からそうだった」と理由を考えずにこなすだけにならないためにも、その理由となった今回のインシデントについてどこかに書き残しておいて共有してもらいたい旨を伝えました。

しかし、マニュアル自体は上記でも述べているように本当に先生方がしっかり作ってくれているので感心たので、「これを他の保護者の方にも開示してみませんか？」と伝えてみました。

私は先生方がここまでしっかりマニュアルを作って避難訓練をしていいることを知らなかったので、親としては先生方が子どもたちの避難訓練のためにここまで頑張ってくれていることについては嬉しく思ったので、他の保護者の方にも先生方の頑張りを知っていただけたらなと思った次第です。また、先生方はあくまで保育の専門家であり、避難訓練の専門家ではないので、保護者の中には警察官や消防官、自衛官などそっち方面の専門家がいる可能性も考えると、このマニュアルをオープンにして、保護者からも意見をもらったほうが良いものができるのではと思ったからです。（クソリプが来る可能性もあるけどそれは対応しなくてもいい旨は合わせて伝えました）

マニュアルの公開についても検討していただくということなので、もし避難訓練のマニュアルが保育園から共有される日が来たら多分同じ保育園だと思ってください。

まとめ

避難訓練でうちの子が行方不明になるというインシデントを受け、対応策にChaos Engineeringを提案したものの採用はされませんでしたｗ

しかしながら、インシデントをきっかけに保育園と話し合いをする中で避難訓練のマニュアルのアップデートや先生方の活動の一端を知り、その改善などを提案することができました。

ちなみにこの記事を書く直前に、保育園の連絡アプリから「避難訓練をしました」という通知が来てドキドキしましたが、妻からも保育園からも連絡がないので無事に避難訓練は終えられたようでホッとしました。

その後、保育園にお迎えに行ったら先生がすごくおどおどした感じで「今日は特に連絡はありませんので・・・」って言われて苦笑いしました。

なお、上の子に「避難訓練どうだった？なんかいつもと違った？」と聞いてみたのですが、「いつもどおりだったよ」と言われたので、子供目線ではいつもどおりだったみたいですが、きっと先生方は頑張ってくれたと思います。

余談

なお、前回の記事を書いたあと妻が友達に今回のインシデントと私の提案について話したところ「え、うちの中学校は避難訓練のときに生徒が一人先生に拉致されて、それを気付けるかってやられてたよ」という話を聞き、私がその場の思いつきで適当に提案したものの、実際にやってる所あるのかと驚きました。（2x年前の話なので今もやってるかは不明です）

また、先日保育園から保護者あてに「使っていない抱っこひもがあればお譲りいただけませんか」というアナウンスがあり、多分避難訓練で乳児クラスの移動で使うんだろうなという気がしたので、我が家にあった使っていないエルゴを寄贈させていただきました。

2020-01-14

GKEで `ingress.kubernetes.io/rewrite-target` が効かないっぽい話

GKE kubernetes

昨年、余暇にKubeInvaders を触っていた時に ingress がうまく動かなくてハマった時に調べたメモ。

kubeinvaders-ingress.yml には以下のように書かれているが、ingressがうまく動かないので書き換えていたのだが、PRを出す前にこれは自分の環境（GKE)では動かないだけで他では動くのだろうかと気になって調べてみたところ、GKEでは動かないということがなんとなく分かった。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubeinvaders 
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - kubeinvaders.org
  rules:
  - host: kubeinvaders.org 
    http:
      paths:
      - path: /
        backend:
          serviceName: kubeinvaders 
          servicePort: 8080

github.com

上記のIssueはingress-gceのものではあるが、GKEも同様に ingress.kubernetes.io/rewrite-target が効かないように見える。

Google のIssue Trackerにも上げられているが反応がないのでまだ実装されていない or このまま実装されなさそうな気配である。

https://issuetracker.google.com/u/0/issues/72484862

そんなわけで、GKEを使っている時に ingress.kubernetes.io/rewrite-target がうまく動いてない場合は何らかのworkaroundが必要見たいという話でした。

2019-08-15

OpenStack Erisを調べてみた

openstack test

Chaos Engineeringを調べてるときに「OpenStackにもFault injectionでOpenStackを試験するプロジェクトがあるよ」と聞いたので調べてみた。

OpenStack Eris

docs.openstack.org

OpenStackに様々な負荷をかけて、OpenStackの性能改善やResilienceにするためのテストフレームワークや、テストスートを作るプロジェクト

Load Injection
Fault Injection

もできる（予定）

OpenStack Erisに関する情報

OpenStack Summit Sydney のフォーラムに２件あったと教えてもらった

Extreme/Destructive Testing

www.openstack.org

LCOO = Large Contributing OpenStack Operators

LCOO - OpenStack

フォーラムのディスカッション内容

What sort of tests do you run today that are destructive in nature?
What is your desired workflow for issues that come up?
How do you determine success/failure of your testing scenarios?
Do you publicly publish your results (if so where)?
What KPI do you evaluate today?
What workloads do you run and against what architectures?

sessionは3part

References: Extreme testing is non-deterministic. Such testing generally is valid with the following reference.
Test Suite: What test scenarios are we trying to get done?
Frameworks & Tools: How do we enable the test suite?

etherpadはこっち https://etherpad.openstack.org/p/SYD-extreme-testing

フォーラムではどういうテストをするのかという議論が行われていたっぽい。また、Rallyとは何が違うのかというQAがあったのもログに残っている。

- What is the difference between Eris and Rally? (From spec it looks the same) (boris-42)
   (samP) Discussion is here http://lists.openstack.org/pipermail/openstack-dev/2017-November/124156.html
   (gautamdivgi) 
We are looking for a solution/mechanism where there the capacity for
- Load generation (Control + Data Plane)
- Failure injection (all over the cloud)
- Data capture (all touch points - not just API requests)
- KPI calculation (all touch points - not just API requests)
- Most importantly - have one part "influence" the other (E.g. run failures or a sequence of failures based on system criteria like netstat session counts or free memory remaining)
Rally does load generation and there are failure injection hooks - but cannot participate in more complex feedback, monitoring & computation mechanisms.
Rally is used today to generate load. Definitely looking to contribute some plugins for load gen & metrics collections enhancements.

LCOO-Extreme Testing-QA-ERIS

www.openstack.org

ここではErisのデモ行われたらしいがフォーラムだったのでビデオはないらしい。

Erisのデモ用の手順

openstack-lcoo.atlassian.net

etherpadはこちら https://etherpad.openstack.org/p/LCOO-Extreme_Testing-QA-ERIS

os-faultsなどが使われるのかというQAのログが残っているがframeworkのプラグインにすればという話が出ている

Will Eris support os-faults in the future? https://github.com/openstack/os-faults
- Need for extensible pluggable framework for fault injection, e.g.
    - Define levels of redundancy within infrastructure and inject faults up to the maximum which can be tolerated given that amount of redundancy (e.g. 2 node failures in a 5-node cluster)
    - Use os-faults to test failure scenarios defined by Self-Healing SIG and ensure that self-healing works
- Preference for reusing existing projects if possible
- If not possible, include gaps analysis in the spec
Maybe split spec into smaller pieces?
Can some example results / demo be published so that people can start looking at Eris and get a feel for what it can do?

まとめ

2年前ぐらいの情報しか見当たらないので特に進展はなさそうなのでもしOpenStackにたいしてChaos Engineeringをするのであれば別のツールを使ったほうが良いかも知れない。

2019-08-13

労働組合とエンジニアの対話会やってみた

日記

先日自分主催で労働組合とエンジニアの対話会をやってみた。

事前に sli.do で質問を集めて、組合側にもソレを共有し、当日は最初に最近のキャリア施策に関する説明をしてもらったあと事前質問を元に質疑をしたがくっそ面白かった。事前質問が想像はしていたけど結構刺々しくて苦笑い。

当日はあまり質問する人がいなさそうだったので、主催者だけどはしゃいで質問しまくったのでちょっと反省してる。

後日（というかさっき）、当日の質疑で出た質問や提案を改めてメールで組合側に送ったので回答待ち。

いやー、おもしろかった。

このあとの回答とか展開に期待！

2019-07-04

IIJのDNSフィルタリング？

日記

週末に我が家のネットがおかしくなったので子どもたちからYoutubeが見られないと大層クレームを受け、私もSlackに繋がらなくなり、Amazon Eco dotも反応しなくなり、何だこれと思いルータやONUの再起動をしても今ひとつなんともならず。

月曜日に帰宅後設定を見ても特に変更がないので障害かと思い調べてみても特に障害情報が上がっておらず困ってTwitterでつぶやいたところ

もしかして（本日開始？）https://t.co/aHyXmRHAFO
— makoro_activity.log (@makoro_br9) July 1, 2019

DNSフィルタリングなんて始めてるのな・・・

そんなわけでDNSフィルタリングされてないDNSを設定したところ

DNSフィルタリングはずしたら行けた！！！https://t.co/I8VHakRow7
— まひと / Mahito (@Mahito) July 1, 2019

ひとまずこれで子供に怒られなくて済むようにはなったものの、一応切り分けをしてみた。

フィルタリングされたDNSの場合

slack.comへのアクセス

dig は通る。

% dig slack.com

; <<>> DiG 9.10.6 <<>> slack.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 705
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;slack.com.            IN    A

;; ANSWER SECTION:
slack.com.        20    IN    A    99.84.134.165

;; AUTHORITY SECTION:
slack.com.        97990    IN    NS    ns-166.awsdns-20.com.
slack.com.        97990    IN    NS    ns-1901.awsdns-45.co.uk.
slack.com.        97990    IN    NS    ns-606.awsdns-11.net.
slack.com.        97990    IN    NS    ns-1493.awsdns-58.org.

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:26:08 JST 2019
;; MSG SIZE  rcvd: 191

tracerouteは通らない

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.305 ms  1.443 ms  1.207 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.436 ms  4.215 ms  4.982 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  5.739 ms  7.775 ms  9.502 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  *^C

twitter.comへのアクセス

なぜかTwitterも通らなくなる

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  3.188 ms  2.069 ms  1.245 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  10.634 ms  12.700 ms  16.098 ms
 3  chiba1-ntteast1.flets.2iij.net (160.13.161.25)  21.534 ms  20.587 ms  13.338 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
^C

でもdigは反応あり

% dig twitter.com

; <<>> DiG 9.10.6 <<>> twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15264
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 10, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com.            IN    A

;; ANSWER SECTION:
twitter.com.        243    IN    A    104.244.42.65
twitter.com.        243    IN    A    104.244.42.1

;; AUTHORITY SECTION:
twitter.com.        4935    IN    NS    ns3.p34.dynect.net.
twitter.com.        4935    IN    NS    ns2.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-02.ns.twtrdns.net.
twitter.com.        4935    IN    NS    c.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns4.p34.dynect.net.
twitter.com.        4935    IN    NS    d01-01.ns.twtrdns.net.
twitter.com.        4935    IN    NS    a.r06.twtrdns.net.
twitter.com.        4935    IN    NS    ns1.p34.dynect.net.
twitter.com.        4935    IN    NS    b.r06.twtrdns.net.
twitter.com.        4935    IN    NS    d.r06.twtrdns.net.

;; Query time: 5 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:27:09 JST 2019
;; MSG SIZE  rcvd: 279

google.comへのアクセス

googleは通る

% traceroute www.google.com
traceroute to www.google.com (172.217.26.4), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.922 ms  1.291 ms  1.186 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  3.250 ms  3.576 ms  3.562 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  4.318 ms  6.603 ms  5.416 ms
 4  tky008lip30.iij.net (202.214.41.93)  5.959 ms  8.551 ms  8.190 ms
 5  tky008bb00.iij.net (210.130.142.89)  9.827 ms  12.476 ms  13.610 ms
 6  tky001bb10.iij.net (58.138.88.1)  13.059 ms  14.238 ms  12.825 ms
 7  tky001ix04.iij.net (58.138.100.62)  12.169 ms
    tky001ix02.iij.net (58.138.100.54)  12.029 ms  9.808 ms
 8  72.14.242.38 (72.14.242.38)  8.725 ms
    202.232.1.86 (202.232.1.86)  7.361 ms
    72.14.242.38 (72.14.242.38)  5.072 ms
 9  * * *
10  72.14.233.220 (72.14.233.220)  10.889 ms
    nrt20s02-in-f4.1e100.net (172.217.26.4)  8.486 ms
    108.170.242.161 (108.170.242.161)  12.765 ms

digもとおる

% dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.            IN    A

;; ANSWER SECTION:
www.google.com.        260    IN    A    172.217.161.68

;; Query time: 4 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Tue Jul 02 21:29:31 JST 2019
;; MSG SIZE  rcvd: 59

フィルタリングされていないDNSの場合

slack.comへのアクセス

% traceroute slack.com
traceroute to slack.com (99.84.134.165), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  13.403 ms  10.315 ms  7.211 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  48.603 ms  39.201 ms  38.889 ms
 3  chiba1-ntteast0.flets.2iij.net (160.13.161.21)  41.529 ms  50.059 ms  41.740 ms
 4  tky008lip30.iij.net (202.214.41.93)  39.944 ms  48.148 ms  50.577 ms
 5  tky008bb00.iij.net (210.130.142.89)  52.023 ms  42.148 ms  62.208 ms
 6  tky001bb10.iij.net (58.138.88.1)  51.263 ms  55.101 ms  61.491 ms
 7  tky001ix15.iij.net (58.138.102.210)  57.440 ms  42.014 ms
    tky001ix11.iij.net (58.138.102.202)  35.866 ms
 8  210.173.176.188 (210.173.176.188)  37.971 ms  42.719 ms  38.336 ms
 9  52.95.30.171 (52.95.30.171)  52.017 ms
    52.95.30.183 (52.95.30.183)  56.138 ms
    52.95.30.169 (52.95.30.169)  41.881 ms
10  52.95.30.18 (52.95.30.18)  71.838 ms
    52.95.30.54 (52.95.30.54)  60.939 ms
    52.95.30.58 (52.95.30.58)  38.320 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  server-99-84-134-165.nrt57.r.cloudfront.net (99.84.134.165)  30.975 ms  45.644 ms  30.776 ms

twitter.comへのアクセス

% traceroute twitter.com
traceroute: Warning: twitter.com has multiple addresses; using 104.244.42.1
traceroute to twitter.com (104.244.42.1), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  150.819 ms  88.796 ms  8.696 ms
 2  chiba01-z03.flets.2iij.net (160.13.161.x)  36.320 ms  39.820 ms  95.059 ms
 3  * chiba1-ntteast1.flets.2iij.net (160.13.161.25)  40.946 ms  47.746 ms
 4  tky008lip31.iij.net (202.214.41.97)  53.321 ms  57.417 ms  61.216 ms
 5  tky008bb01.iij.net (210.130.142.93)  50.467 ms  35.077 ms  27.107 ms
 6  tky001bb11.iij.net (58.138.88.5)  31.195 ms  42.001 ms  38.530 ms
 7  tky001ix15.iij.net (58.138.102.214)  37.889 ms  39.328 ms
    tky001ix11.iij.net (58.138.102.206)  40.044 ms
 8  210.173.176.152 (210.173.176.152)  29.130 ms  31.093 ms  27.638 ms
 9  * * *
10  104.244.42.1 (104.244.42.1)  31.713 ms  298.895 ms  180.441 ms

よくわからん。。。

一応公式には

宛先がレピュテーションデータに含まれている場合、IIJが別途用意するサーバのIPアドレスに宛先を置き換えることで、本来の宛先へアクセスしないようにします。

と書かれているので本来の宛先へアクセスはしてないわけであるが、Twitterを見ても私のように困ってる人もいないのでますます謎は深まる・・・

私はNWは全然強くないので会社の強い人に聞いてみると、どこかでルーティングが書き換えられてるか、単純に機器故障じゃないかといわれた。

何にせよ再び我が家に自由なインターネットが戻ってきたのでこんなもんにしておく。

やっぱりネットワーク良くわからん。。。。

2019-06-12

frigga にみるNetflixのクラスタ命名規則とChaos Monkeyがkubernetes provider v2でうまく動かない理由

oss chaosmonkey netflix k8s

タイトルが長いけど簡単に言うと、Chaos Monkeyはk8s対応を謳ってますが k8s provider v2(Manifest)で Deployment などを使うと動かないことがあります。

github.com

Chaos Monkey should work with any backend that Spinnaker supports (AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry). It has been tested with AWS, GCE, and Kubernetes.

理由はNetflixのクラスタ命名規則に従っていないから。

以下、解説

frigga

friggaはNetflixから公開されているOSSです。

github.com

Utilities for working with Asgard named objects

friggaはAsgardで扱うオブジェクトの名前管理（バリデーションなど）をするライブラリらしいです。

AsgardはSpinnakerの前身であり、AWSのアプリケーションデプロイと管理をするWebコンソールでしたが、今はマルチクラウドでCI/CDを実現するSpinnakerに移行したようです。

github.com

Spinnakerでクラスタをデプロイしたことがある人はわかるかもしれませんが、SpinnakerではApplicaation Name, Stack, Detailで appName-stack-detail という名前をつけて各クラスタを把握していますが、以下のコードを見ると実はこれをfriggaが生成/管理していることがわかります。

Chaos Monkey

Chaos MonkeyもNetflixから公開されているOSSです。

Chaos MonkeyはNetflixがChaos Engineeringを行うためのツールとして代表的なものです。

ここでポイントなのはChaos MonkeyはNetflixが開発しており、Chaos Monkeyにおいてもfriggaがライブラリとして使われているということです。

そしてChaos Monkey v2と呼ばれるバージョンからはChaos Monkeyの動作はSpinnakerと連携するようになっています。 Chaos MonkeyはSpinnakerからクラスタやインスタンスの名前を取得した上で対象となるインスタンスやPodを落とすようになっています。

Spinnaker

次にSpinnakerですが、上記でも述べたようにSpinnakerはAsgardの後継としてAWSだけではなくマルチクラウドでCI/CDを実現するOSSです。

www.spinnaker.io

対象とするクラウドはAWSやGCPなど以外にもOpenStackやKubernetesなども含まれており、こうしたクラウド環境に対してChaos Monkeyと連携しChaos Engineeringを実現することが可能となっています。

・・・というのがREADMEなどに書かれている内容なんですが、実はKubernetes provider v2においてdeploymentなどを使うとChaos Monkeyが動きません。

原因は以下のSpinnakerドキュメントに書いてあるとおりです。

Kubernetes Provider V2 (Manifest Based) - Spinnaker

You can deploy existing manifests without rewriting them to adhere to Frigga. Resource relationships (for example between applications and clusters) are managed using Kubernetes annotations, and Spinnaker manages these using its Moniker library.

ApplicationやClusterをKubernetesのアノテーションやSpinnakerのMonikerというライブラリで管理するので、friggaに準拠しなくても良いようにしたとのことですが、これが原因でKubernetes provider v2においてはChaos Monkeyがfriggaの命名規則に合致しない deployment appName-stack-detail などという名前が出来上がった結果、friggaが管理する命名規則と合致せずエラーを起こしChaos Monkeyが動かないケースが有るという状態になっております。

一応こちらのIssueに上がっており、Slackでもお話はしてコミュニティには伝えたもののまだ対応はされてない模様。

github.com

Serge Poueme [3 months ago] Hi @mahito seems to be that yes. I just had a call with Ben, Ethan and Isaac ( Spinnaker office hours ) and they mentioned the mismatch between the v2 provider responses and chaosmonkey. A workaround would be to use replicasets instead of deployments. I will see if I can try that on our current dev project with minimal impact on the overall service definition.

今の所Chaos Monkeyの対象を Deployment にすると動かないので ReplicaSetを使うのが回避策らしい。