RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法
はじめに
この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。
翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。
免責
いつものやつ
目次
- はじめに
- 免責
- 目次
- 概要
- 1. 導入
- 2. ネットワーク設計の要件
- 3. データセンタートポロジーの概要
- 4. データセンタールーティングの概要
- 4.1 L2オンリー設計
- 4.2 L2/L3ハイブリッドの設計
- 4.3 L3オンリー設計
- 5. ルーティングプロトコル設計
- 6. ECMPの考察
- 6.1 基本的なECMP
- 6.2 複数のAS番号をまたがるBGP ECMP
- 6.3 重み付けされたECMP
- 6.4 コンシステントハッシュ法
- 7. ルーティング収束の特性
- 7.1 障害検知のタイミング
- 7.2 イベント伝搬のタイミング
- 7.3 Closトポロジーのファンアウトの効果
- 7.4 罹障範囲
- 7.5 ルーティングマイクロループ
- 8. 設計の追加の選択肢
- 9. セキュリティの懸念事項
Intel NICを搭載したLinuxサーバのLLDPが正しく動作しない問題
サマリー
Intel NICを搭載したLinuxサーバにおいて lldpd をインストールして設定を行ってもその設定が反映されず、ハードウェアの情報が表示される場合、Intel NIC (i40e) のLLDPオフロードが有効になっているためこれを無効にする必要がある。
詳細
lldpdを apt install lldpd でインストールしたのち、以下のように設定を行った。
configure system interface pattern eno*,ens* configure lldp portidsubtype ifname
ネットワークスイッチ側からLLDPネイバーを表示すると以下のようになった。Chassis IdにはMACアドレス、Port infoにはLinux上でのインターフェイス名が見えることが期待値であったが、ハードウェア固有の値が表示されている。
{master:0}
me@myswitch> show lldp neighbors
Local Interface Parent Interface Chassis Id Port info System Name
xe-0/0/8 ae2 39373638-3935-5099-4E99-303330309999Embedded ALOM, Port 1
xe-0/0/10 ae2 39373638-3935-5099-4E99-303330309999PCI-E Slot 1, Port 1
{master:0}
me@myswitch> show lldp neighbors interface xe-0/0/8
LLDP Neighbor Information:
Local Information:
Index: 147 Time to live: 121 Time mark: Tue Jun 2 06:27:34 2020 Age: 12 secs
Local Interface : xe-0/0/8
Parent Interface : ae2
Local Port ID : 521
Ageout Count : 0
Neighbour Information:
Chassis type : Locally assigned
Chassis ID : 39373638-3935-5099-4E99-303330309999
Port type : Mac address
Port ID : 00:00:5e:a2:72:00
Port description : Embedded ALOM, Port 1
System Description : HPE ProLiant DL360 Gen10
また、サーバ側からLLDPの自身の情報とネイバーの情報を表示すると、ChassisIDやPorIDが正しく設定されていることがわかり、ネイバーが見えていないこともわかる。スイッチ側の設定はスイッチ間のLLDP設定で正しく表示できていることが確認できていたため、これはスイッチからのLLDPDUがLinuxのレイヤーまで届いていないということになる。
root@myserver:~# lldpcli show chassis
-------------------------------------------------------------------------------
Local chassis:
-------------------------------------------------------------------------------
Chassis:
ChassisID: mac 00:00:5e:7b:a4:10
SysName: myserver
SysDescr: Ubuntu 18.04.3 LTS Linux 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64
MgmtIP: 10.102.253.54
MgmtIP: fe80::ac91:afff:fe1f:aee0
Capability: Bridge, on
Capability: Router, on
Capability: Wlan, off
Capability: Station, off
-------------------------------------------------------------------------------
[lldpcli] # show interfaces ports eno5
-------------------------------------------------------------------------------
LLDP interfaces:
-------------------------------------------------------------------------------
Interface: eno5, via: unknown
Chassis:
ChassisID: mac 00:00:5e:7b:a4:10
SysName: myserver
Port:
PortID: ifname eno5
PortDescr: eno5
TTL: 120
-------------------------------------------------------------------------------
root@myserver:~# lldpcli show neighbor ports eno5 ------------------------------------------------------------------------------- LLDP neighbors: -------------------------------------------------------------------------------
生のハードウェアIDが表示されていたため、BIOSの設定を疑って漁ってみたが、見つからなくて途方に暮れたので友人たちに訪ねてみると早速ヒントを貰った
NICか何かがオフロードしちゃって応答してたとかいう事象があったような… https://t.co/qOrKDpdi4u
— Masayuki Kobayashi (@markunet) 2020年6月2日
Intel NIC (i40eドライバ)でLLDPのオフロードが有効になっているようである。
centos6 - Disable internal Intel X710 LLDP agent - Server Fault
バージョン2.3.6以降のi40eのドライバーではethtool経由でLLDPオフロードを無効にできるようであるが、Ubuntu18.04で使っていたドライバはそれより若いバージョンであったため、 debugコマンド経由で無効にする方法を利用した。以下のようにdisable-lldp-offload.sh という名前でスクリプトを配置し、再起動時でもオフロードの無効化が自動でできるようにするため、/etc/cron.d/lldp から@rebootで呼び出すことにした(systemdではなく)。
#!/bin/bash i40e_path=/sys/kernel/debug/i40e for dev in $i40e_path/*; do [ -e "$dev" ] || break echo lldp stop > "${dev}/command” done
@reboot root sleep 60 && /root/disable-lldp-offload.sh
スイッチ側からも無事に正しい情報を参照できるようになった。
{master:0}
me@myswitch> show lldp neighbors
Local Interface Parent Interface Chassis Id Port info System Name
xe-0/0/8 ae2 00:00:5e:7b:a4:10 eno5 myserver
xe-0/0/10 ae2 00:00:5e:7b:a4:10 ens1f0 myserver
ありがとう @markunet !!
JANOGのCode of Conduct
こんにちは。JANOG(日本ネットワーク・オペレーターズ・グループ)というコミュニティで運営委員をやってるゆやりんです。
コミュニティ•カンファレンス運営 Advent Calendar 2019ということで、JANOGの運営について紹介しようと書いていたら、あまりにも長大なポエムが出来上がってしまったので、ほとんど捨てて要点を絞って最近話題のCode of Condactについて話したいと思います。
JANOGは7000名のネットワーク技術者のコミュニティ
日本ネットワーク・オペレーターズ・グループ(JANOG)はネットワーク運用者が集まる技術コミュニティです。インターネットはいろいろな組織や事業者のネットワークが相互接続することで形成されています。そのためそれを運用する技術者たちも繋がりを持ち、組織の壁を超えて技術的な情報を交換したり、共通の課題を解いていく必要があります。JANOGはそのためのコミュニティです。
1997年に北米のNANOG (North American NOG) に参加して刺激を受けた技術者たちが立ち上げ、今年で22年目になります。会員はメーリングリストの登録者数で数えており約7000名です。
活動のメインは年２回のMeeting
JANOGでは年２回ミーティングを開催しています。例年1月と7月に開催しており、最近では水曜の午後から金曜日までの2日半の開催になっています。
最近ではJANOG44ミーティングが神戸で開催され過去最高の1602名が参加しました。
参加者は増え続けてついに1600名に
私が学生のときに初めて参加したJANOG26の時期は都内だと700名、地方だと300-400名程度の出席でした。それがここ５年くらいでどんどん増えてJANOG41で1000名超え、今回のJANOG44では1600名になりました。
JANOGのCode of Conduct をつくった
1600名も参加するミーティングともなると、色々な人が参加することが想定されます。JANOGでは2016年6月頃から検討をはじめて、2017年8月に「JANOG行動規範」として公開しました。
https://www.janog.gr.jp/doc/janog-comment/jc11.txt
JANOG行動規範
JANOGの価値は幅広い参加者の知見と興味、率直な意見交換に支えられています。
これはメーリングリストやミーティング、ワーキンググループなど、
JANOGがその目的を達成するための様々な活動の全てに共通しています。それぞれの参加者は、異なる背景や状況、意見を持ちうることを認識し、
お互いに思いやり尊重しあいましょう。あらゆる嫌がらせや誹謗中傷、
反社会的行為は許容されません。この行動規範に反する行為や言動に対して、JANOG運営委員会は当該人物の退出や除名などの必要な措置を講ずることがあります。共に楽しみ、共に課題を乗り越え、充実したコミュニティを作っていきましょう。
以上
なにか個別の問題が発生したので制定したという経緯ではなく、海外を中心に他のコミュニティでCoCを制定することが当たり前の流れになってきており、JANOGでもこれが必要になるだろうという判断を行いました。
ドラフトを策定して公開、次のJANOGミーティングで説明、意見募集。その次のJANOGミーティングのオープンマイクで採択という流れを取りました。そのため検討から約１年を要しています。
他のコミュニティのCoCを参考にした
CoCは同じく運営委員の金子さんや松崎さんが中心となって策定をしていただきました。策定にあたって他のコミュニティ、特にネットワーク系でアジア圏でカンファレンスを行っているAPNICやAPRICOTなどを参考にしており、APNICのCoCをベースに作成しました。
-
APRICOT Code of Conduct / Anti-harrassment Policy | APRICOT 2017
-
HOWTO design a code of conduct for your community | Ada Initiative
前向きなCoCを作ろう
なぜCoCが必要だと判断したのかは、松崎さんがJANOG39で開催してくれたJANOG行動規範BoF (Bird of feather, 同好会)の資料でも書かれている通り、
- 僕たちがどういう価値観や倫理的指針を持って活動しているか明文化しておきたい
- 嫌がらせ（ハラスメント）は許されない行為だと明確にしておきたい
- この思いに賛同する人がどんどん参加して、このコミュニティが発展してくれると嬉しい
という３点が主な理由です。会員やミーティング参加者の行動を厳しく縛るような後ろ向きな規約を決めるのではなく、参加する人が安心して参加できるように前向きなCoCにしたいと作る際に方針を決めました。
JANOG39 :: [JANOGCOC] コミュニティの行動規範 - JANOGはどうする？
JANOGというコミュニティがどのような価値観を持っているかを表明するとともに、ハラスメントに対して許容しない、ハラスメントがあればアクションを取るということを明文化することで、そうした行為が行われた際にミーティング実行委員（スタッフ）のみなさんが自発的に行動できる指針を示しておくという効果ももあります。
CoCはコミュニティの価値を高めるために必要
「昔はそんなもの必要なかった」というご意見もいただきますが、我慢させられ泣き寝入りしてしまう人もたくさんいたのではないかと思います。
コミュニティ運営者がCoCを作ることで、そうしたハラスメントを受けた方をケアし、またハラスメントを抑止することで、コミュニティの価値や魅力を上げていくことに繋がります。それによりコミュニティが活性化して会員や参加者もその恩恵を受けることができるようになり、良い循環が生まれます。
検索するとCoCの雛形なども公開されていたりするので、まだCoCを制定していないコミュニティ運営者はぜひ制定してみてください。
NTTComを退職してNTTComに入社します
TL;DR
平成から令和への時代の変遷とともにNTTComを退職し、スペシャリスト社員としてNTTComに入社し、新たな人生を歩みます。
仕事としてはSDNのテックリードとしてNTTComのクラウドのSDN基盤のStabilityとScalabilityの向上に引き続きチャレンジしていきます。
一階級飛び級して課長相当のロールの仕事をして、終身雇用と年功序列と労働組合の轍から外れる人生を歩むことになります。お給料もあがります。
これからは、短期的にはテックリード→アーキテクト/エンジニアリングマネージャー→CTOのような感じで、NTTComの中でのエンジニアのキャリアアップのロールモデルとして活躍し、道を切り開いていきたいと思います。
長期的にはNTTComに限らず、ネットワークのおもしろい案件を渡り歩いて請け負っていく、エンジニアやエンジニアリングマネージャーとして生きていこうかなと思います。おもしろい案件があればいつでもお声がけお待ちしております。
どしたん？
実は年明けから転職活動をしていました。理由としては
- 知り合いから一緒に仕事をしたいと誘われていたおもしろい案件が複数あった
- 年末のイベントで「エンジニアの給与が低い」という意見に対して社長が「自分の市場価値を考えろ」と煽ってきたので測りたくなった（最下部に補足追記あり 2019-05-01 18:30）
- 転職活動を経験しておかないといざという時に失敗すると思ったので、全部落ちてもいいからとりあえず経験値を積もうと思った
- 年末年始と社内で不信感の溜まる出来事が立て続けに起きた
- 大きい仕事が一区切りした
- ちょうど切りの良い年齢だったので、年末年始の考える時間で、自分の人生はこのままでいいのかと不安に思った
- NTTの中でこのまま出世するにしても、他の会社を知らないまま偉くなりたくないなと思っていた
という要因がたまたま同じ時期に重なったというのが大きいです。
いくつかの会社から無事に内定をいただきまして、うち１社でネットワーク＆ソフトウェアエンジニアとして最強のデータセンターネットワーク＆クラウド基盤を構築しようと、転職する気満々で円満退職に向けて社内調整を行っていたのですが、いろいろなことがあって、結果としてNTTComに残ることにしました。内定を頂いた会社の皆様にはご迷惑をおかけして本当に申し訳ないです。
何があったん？
もともと社内でたくさんの先輩方から目をかけて頂いていたので、転職に際して強い引き止めがあることは予想していました。なので自分が何がやりたくて辞めるのか、なぜその会社に行くのかをちゃんと説明して、納得はしてもらえないだろうけど、理解はしていただいて、それから辞めようと思い、お世話になった方々に仁義を切って回っていました。
そこにこの記事ですよ。
「おしかけラグビー」というキャッチーなフレーズが話題になってTwitterやはてなのエンジニア界隈で大炎上したわけです。辞めるつもりの会社とはいえ愛着はあったし、今辞めたらラグビーボールを投げつけられたから辞めたと勘違いされかねないので、これはいかんとすぐに火消し記事を書いたわけです。
そしたらはてブでも反響があり、ねとらぼの記事にもなり、誤解はある程度解けて、徳力さんにもべた褒めされたわけです。
これらの記事は社内でも色んな人に見られて、感謝や好意的な反応、応援をいただきました。そして僕は内心「次の記事、退職エントリーなんやけどどないしょ…」って冷や汗をかきつづけていました。
こんな出来事がタイムリーに起きてしまった結果、結論から言うと、この記事で言及されている新キャリアパスの「スペシャリスト社員」として、キャリアップしていくモデルケースになっていくことにしました。
どゆこと？
記事にも書かれている通り、スペシャリスト社員自体はもともと社内に密かにいたのですが、誰がスペシャリスト社員なのかも公にされていない状態でした。また、スペシャリスト社員自体が正社員の劣化版のような状態で始まっていました。しかしながら今は業界他社と競争力のある環境で人材を確保するための枠であり、多種多様なキャリアアップを実現するための制度となろうとしています。
仰々しくいいましたが平たく言うと、やっとIT系企業では普通の雇用が始まったということです。スタートラインに立っただけなんですが、この一歩はNTTのようなトラディショナルな日本の大企業にとっては大きな転換だと感じます。
そして私自身がこの制度で転身し、後輩のエンジニアたちの道標となるということが、NTTComを変えて優秀な若手エンジニアの環境や待遇を良くする方法を悩んでいた中で、非常に魅力的な選択肢として心に響いたので残る決心をしました。
その決心の土台として、今の仕事がチャレンジングで面白かったのと、今のチームが最高に良いチームだったことは非常に大きかったです。
なんで退職？
スペシャリスト社員になるために雇用替えを行うので、一旦退職という扱いになります。退職金もいただきます。そしてNTTの終身雇用＆年功序列のシステムから外れます。
そういやこれまたタイムリーに経団連会長が終身雇用のギブアップ宣言をされましたね。NTTの業務自体はなくなるとは思いませんが、経営する主体は変わることはあるんじゃないかなと思います。その時にいくらNTTとはいえ勤続年数が上がるに連れて給与が上がるシステムは全くもって期待できないと思います。
そしてスペシャリスト社員ということで職務型（いわゆるJob Description型）の雇用体系に変わります。なので今のポジションが無くなったら、どうなるかわかりません。
というわけで僕自身は一度終身雇用を捨てた身であって、転職先がたまたま同じ会社だっただけという認識です。なので常に転職市場に繰り出すことは考えています。
給料あがったの？
あがりました。他社とある程度の競争力のある水準まであげていただきましたし、職位としても非管理職の役付きになってすぐにもかかわらず、管理職である課長相当のロールにあげていただきました。次の職位にあがるためには３年とか一定期間を待って試験を受けないといけない中、実質一階級飛び級したことになります。これは実力さえ示せば勤続年数に関係なく上の役職相当の仕事ができるということで、トラディショナル・ジャパニーズ・カンパニーにおいては大きな変化だと感じています。逆に言えば育成の猶予があった３年をすっ飛ばして、その職位としての結果を求められる過酷な状況に自分を追い込んだということです。
また、スペシャリスト社員＝給与アップというわけではありません。JDベースの仕組みですので、当たり前の話ですが、そのポジションの会社にとっての重要性や、その人に期待する役割などによって給料は決まります。
そのような結果、私より職位が高い人に比べて額面上は高い給料になっている場合もあります。NTTのような序列のある会社の中でこの状況は精神的に結構キツイです。でもどこかでこの逆転現象を起こさないと、自分より若い人たちの給料も上がらないと思ったので、自分がこの役目を買って出ることにしました。
終身雇用から外れたので退職金とかはありませんし、住宅補助や扶養手当のような一部の福利厚生もありません。そしてなにより将来の保証がありません。その分を考えた時に本当に良かったのかどうかはまだわかりません。が、どうせ辞めるつもりやったんやからええやろと吹っ切りました。
あがったとは言っても id:kumagi よりは安いし、彼らはそこから上がっていくことを考えると、まだまだGAFAへの流出は防げない水準であると関係者には伝えてあります。僕が内定を頂いき転職しようとしていたところはGAFAではなく国内企業です。たまたまこういう特殊なきっかけがあったので私の流出は防げましたが、待遇や環境を総合的に考えると、実は国内企業への流出を防げる水準にも全然なっていないということは言っておいたほうが良いかもしれません。
何の仕事やんの？
そもそも今まで何の仕事をしてるのかあまり公にしてませんでしたが、エンタープライズ業界向けのクラウドサービスのSDN基盤を作ってました。ひとまずはこれまで通りの仕事内容になるのですが、テックリードの肩書も正式にもらえる予定なので、引き続きチームを引っ張ってSDN基盤のSREを実現してStabilityとScalabilityの向上にチャレンジしていきたいと思っています。対外活動も引き続きやっていきます。
Why NTTCom？
NTTComは国内でIaaS/クラウドの開発ができる事業者の中で最大規模だと思っています（ちなみにNTTドコモもやってるよ）。AWSやGCPの開発をやりたいと思うと、どうしてもアメリカの本社に行かないといけないですよね、知らんけど。今のチームにJoinしたときに中身を知って「え？NTTComがこんなにすごいサービス作ってるの！？」ってびっくりしました。
自分たちで開発しているからこそ、障害が起こると自分が日常で使っている色々なシステムやサービスが止まってしまう怖さや責任感もありますし、だからこそ「NTTComのクラウドのネットワーク全部俺」って言える楽しさもあります（もちろん私だけじゃなくてみんなで作ってますが、そういう気持ちでいられるということです）。それを結構魅力に感じています。
まだまだ直さないといけないところはたくさんあるし、日本企業の古い文化や体質が残っているところもたくさんありますが、労働組合が強く労働者が守らていて休みも取りやすい超絶ホワイトな会社であるというNTTの従来型の良い面も保ちながら、オフィスも新しくなったし、リモートワークもできるし、フレックス勤務もできるし、副業もできるし、Job Description型の雇用体系もできるし、会社自体も時代に合わせてここ数年で劇的に改善しています。
従来どおり適度な仕事で安定した人生を送りたい方にはもちろん、不安定な環境でもいいので自己実現したい尖ったエンジニアにも、両方の人たちにおすすめできる会社になってきています。
※ 自席ですが狭く見えるのは写ってはいけないものが写らないように狭い範囲だけを撮っているからです。なおMacBook 1画面派でモニターはあんまり使ってませんので私はデュアルディスプレイにはしてません。ぬいぐるみは「おしかけぷよぷよ部」を始めようと思ったからです。
さいごに
この件についてはたくさんの関係者の方に動いていただきました。本当にありがとうございました。
ところでお客様の中に、ネットワークのすべての分野に精通していて、クラウドコンピューティングが好きで、データセンターネットワークを作るのが好きで、特にBGPとかEVPNとかVXLANとかが好きで、でもVRRPとかSTPとかARP/NDとかエッジ・ホスト側のネットワーク技術も好きで、tcpdumpでパケットレベルのデバッグをするのが好きで、C++とPythonの読み書きデバッグが好きで、Linuxのカーネルやネットワークスタックが好きで、OpenStackが好きで、CassandraとかRabbitMQとか分散ミドルウェアが好きで、docker/k8sとかのコンテナ技術が好きで、英語をしゃべるのが好きなエンジニア、いらっしゃいましたらTwitterとかで @yuyarin までご連絡ください。
それでは令和時代もよろしくお願いいたします。
追記
『「エンジニアの給与が低い」という意見に対して社長が「自分の市場価値を考えろ」と煽ってきた』という部分にネガティブな反応が見受けられたのですが、まずこれはこれは私個人に対して向けた言葉ではなく、意見を出した人個人に「君は市場価値がない」という意味で言ったわけでもありません。
社長は社会人として当たり前のことを指摘したに過ぎないと思っています。何の根拠もなく給料を上げろというのは筋が通っていませんし、NTTヨーロッパの人の話を聞いていても他社提示額を以って給与交渉をするようですので、そのような方法を以って話をしようという意図だったのだと思います。社長からすると、会社全体で見たときに市場価値より高い給料で雇われている人がたくさん見えるのだと思います。
そのようなわけで、私も反発して感情的に転職をしようと思ったわけではなく、なるほど確かにと理性的に納得して、それを確かめるために転職市場に繰り出そうと思った次第です。
追記２
有益情報をいただきました！
ジョブディスクリプション型の契約雇用で生きていくというのは今後増えていくでしょう。産業医として１つだけ言いたいのは、ノーパソ一本だと首を傷めるので対策してくださいということです！ #働き方改革 #産業医 #IT系https://t.co/InQksZQiWm
— ヤマコー👓リハ医・産業医 (@rehabithc) May 1, 2019
NTTCom社員は本当にラグビー部員におしかけられているのか？
TL;DR
そんな事実は無いし、技術職も希望をちゃんと伝えればちゃんと配属されると思うので内定者・就活中の学生の皆様は安心してね。
この記事は何？
この記事がはてなブックマークやTwitterのエンジニア界隈で大変な話題になっているけど、事実と違うことが書かれて炎上しているのが中のエンジニアとして大変悲しいですし、内定者や就活中の学生のみなさんが不安になってしまうと思ったので、ちゃんと解説するいわゆる火消し記事です。
この記事は勤務時間中に上司の許可や広報の許可を得ずに書いていますので、普通の会社なら怒られるかもしれませんが、うちの会社は多分大丈夫だと思います。
あくまで一社員とその周囲からの観測範囲をベースにして書いているので、見え方が違うこともあるかもしれませんが、そこはBGPの経路情報と同じでご容赦を。
炎上しているポイント
主に以下の２点で炎上していると認識しています。
ポイント１：技術職がどこに配属されるのかわからない
「技術職として採用する場合、『どの部署に配属されるかはわかりません』と言ってきました。ところが、それだと『じゃあ御社には行きません』といわれてしまうケースも多くて。採用の環境の変化を感じます。だからこそ、色々な経験ができるのが当社のよさだと伝えていかなければならないと思っています」
ポイント２：業務中にラグビー部が突入してきてボールを投げてくる
職場に突然、ラグビー部員がわーっと入っていって、社員にボールをパスしたり、体を動かしてもらったりするんです。
要約
- 技術リクルーティングの枠組の中で採用された技術職は配属先はちゃんと希望されたところに行けるようになっています。
- 「おしかけラグビー」はラグビー部員が広報する活動のこと。色々な企業や団体に招かれて行っているみたいですが、NTTコム社内で突然ラグビー部がラグビーボールを投げつけている事実はありません。
技術職の配属について
私が入社した2011年ごろは記事に書いてあることは確かに本当でした。正確には技術職という枠組みもなくて、一律「新入社員」という扱いでした。その中で意にそぐわない配属をされて涙を流した同期もいました。
しかしここ数年は技術リクルーティングという枠組みを作って採用活動を行っており、こちらの枠組みでは、配属先の部署はある程度コントロールされて「約束通り」になるように頑張っています。クラウドのベアメタルの開発、クラウドのSDNの開発、高速ルータの開発、OCNの開発、といった感じで、ネットワーク、クラウド、セキュリティ、アプリケーションなど複数の分野で技術の専門家を採用しています。
もともとの採用方針がいわゆる日本企業的な「コミュ力重視」の採用で、そういうのが苦手だけどとても優秀なエンジニアがNTTComに入社しなくなってしまうのを避けるためのパスです。大学によっては推薦の枠組みがあるので、その時はご相談ください。
少なくともこの採用パスに入ることができる実力を持った腕利きのエンジニアには「何処に配属されるのか分からない」みたいな状況は待っていません。
『スペシャリスト採用』のような仕組みがあってもいいのかもしれませんが、現実には3年ぐらいたってから選べるようにする方がいいかなと思っています。
という部分については私も納得行かないので、技術リクルーティングで採用されたエンジニアは１年目からスペシャリスト採用になる選択肢を持てるように声を上げていきたいと思います。
ラグビー部がラグビーボールを投げてくる件について
今までのNTTComでの業務時間中にラグビー部からラグビーボールを投げられたことはありません。もしかして僕は社員じゃなかったのかと不安になりましたが、エンジニアのSlackでアンケートを取ったところ21名（のべ在籍年数128年）から即回答があり、業務時間中にラグビー部から突然ラグビーボールを投げられた経験は誰一人ありませんでした。
親切な方が調べてTwitterで発信してくださっています
トレンドにまであがっている押しかけラグビー
— よっしー (@yo0715) March 27, 2019
本当に社内に乱入するようなトンデモ企画ならラグビークラスタで話題になっているはずなので、調べてみた
ハッキリいって拡散されている記事が間違い
あれ、完全に出鱈目やんけ。本当はフォーマルに職場に顔出ししたり、ラグビー体験企画じゃん pic.twitter.com/afP3tY2Xxm
そもそも押しかけラグビーは就業中に乱入する企画ではなくて、ラグビー部を通した健康増進を目的としたスポーツ体験企画です
— よっしー (@yo0715) March 27, 2019
本当にこのインタビュー答えた人は何ということを…https://t.co/rqBS85V3Lv pic.twitter.com/4y53xhC7Rm
そのようなわけでこの部分については中の人的には「そんなことやってへんやろー」っていう事実が歪んで伝わった程度の記事が、思いの外のキャッチーさで炎上してしまったという感じです（もしかしたらどっかで本当にやってるのかもしれないけど）。
まぁ、大丈夫です、ラグビーボールは飛んできません。
この記事で本当に伝わってほしいこと
外資IT系の友人たちからは「やっと10年前だな」という言葉を頂いていますが、これは本当にそのとおりです。私の見方としては「やっと"まとも"な改革ができる人が人事部長になれる時代がやってきた」のです。
山本恭子さんは数々の抵抗勢力に負けずに改革を推進して、社員が働きやすい会社を作ってきています。彼女は我々エンジニアの希望の星でもあります。なのでラグビーの件で「こんな人がトップだから」と言われるのはとても悲しいですし、より制度がよくなるように助言やサポートはしていきたいです（この記事も一つの形です）。
在宅勤務やフレックスなど働きやすい仕組みも整ってきましたし、能力型の「スペシャリスト社員制度」も始まっていますので、腕に覚えがあればGAFAに匹敵するぐらいの給与もでるかもしれません、知らんけど。制度などの面では本当に働きやすく、ここ１年で劇的に良い職場になってきました。
記事でも言及されている通り、課長が勤務管理で忙しすぎるとか、まだまだ改善しないといけない面もたくさんありますが、それを人事部はちゃんと認識していて、なんとかしようと頑張っています。出さなくても良いネガティブな内容を敢えて出しているというのは「これから変えていくという有言実行のメッセージ」だと捉えています。
ところでお前誰？
NTTComでエンタープライズ向けのクラウドサービスのSDN基盤を開発してるよ。ネットワーク機器の検証もするし自分たちでコードも書くよ。開発環境もMacBook ProでSlack、G Suite、Confluence、Jira、GitHubだよ。今はスケーラビリティを上げつつもSDNのSREを実現して安定したネットワークが作れるようにチームで頑張ってるよ。
その前はインターネットエクスチェンジのJPNAPでネットワークエンジニアとソフトウェアエンジニアの両方をやってたよ。ガリガリソフトウェアを書いてネットワーク運用の自動化とかやってたよ。バックボーンの設計とかもやってたよ。
ネットワークとソフトウェアの両方ができるいい会社だよ。
まとめ
他の会社の炎上記事もこんな感じなのかなぁって思うと、話半分に読むのが良いのかなと思いました。
宣伝
NTTの人たちがやっているエンジニアリング的なお話に興味がある方はどうぞ
FAQ
映像があるんだけど？
この件については詳しくは知りませんが、場所はNTTCom社内ではなく浦安市役所だと思います。さすがにそこにいきなりおしかけるのは不法侵入になりますので、先方から招聘いただいて実施したイベントではないかと思います。その場合は、社内でいきなりラグビーボールをぶん投げてくるのとは事情が全く異なるかと思います。
取材場所はラグビーチームのシャイニングアークスの拠点であるアークス浦安パークだと思います。そのご縁で浦安市役所に伺ったのかと思います。
ちなみに浦安市にNTTComの事業部のオフィスはありません。
たった21人の調査？
大手町プレイスっていう新築のビルにオフィスを移転しました！１フロア300-400人で仕切りもない大部屋なのでオフィスにラグビー部員が突入してきたらすぐわかりますよ。そういう状態で少なくともサービス開発・エンジニア系のフロアでそういった事象は21人の目で観測されなかったということです。ご指摘の通りSlackにいなさそうな部署の人のフロアで突入があったら、わかりません。営業系のフロアとか、社長室とか。
NTT Com Tech Night #1を開催しました! (レポート) | NTT Communications Developer Portal
火消し業者？
そうそう、NTTComでは副業もOKになりました。副業ってことにしてお金貰えばよかった…！
Telnetでネットワーク機器を操作するときのBCIP - Ruby編
こんにちは、ゆやりんです。今年のNetOpsCoding Advent Calendarもいよいよ最終日になりました。たくさんの役に立つ＆頭のおかしい投稿ありがとうございます。お仕事が忙しかったので最終日を選びました。オオトリにふさわしい記事はなんだろうかと考えていましたが、やっぱりTelnetについて書こうと思います！！
はじめに
ネットワーク機器を操作する手段としてNETCONFやREST APIなどが登場する中、ネットワークの要件や制約からそういった機能を使うことができず、未だにTelnetやSSHでコンフィグを行わないといけない場合ということがあります。え？どの機器かって？昨日のtaijijijiくんの記事を読んでみて下さい。で、そういった状況でどのようにこのTelnetを利用したクライアントを実装するとよいのか、私のRubyでの実装の最善策(Best Current Implementational Practices)を紹介したいと思います。
大変申し訳無いことにコードを全部公開できないのですが、なるべくエッセンシャルな部分は共有できればと思います。いずれプロジェクトの全貌も公開できればなぁあと思います。
アーキテクチャ
Telnetクライアント周りの全体像はこんな感じなります。
Telnetクライアントの実装としては王道のNet::Telnetを使って、プロキシとしてrancidのxloginを使うのがベストでした。
それをラップする機器ごとのTelnetクライアントを作り、コマンドを投げたら必要なレスポンスだけが返ってくるようにします。
その機能を使って、各機器のCLI相当の機能を提供するのが「機器固有レイヤーのClient」です。例えばインターフェイスにデスクリプションを設定するなどの具体的なメソッドを提供います。
その上位アプリケーションとして「ビジネスロジックレイヤーのClient」が存在します。これら２つの違いは、同じインターフェイスにデスクリプションを設定するというタスクについて、機器固有レイヤーのクライアントがルータのインターフェイス名を取るのに対し、ビジネスロジックレイヤーのClientはお客様の回線IDなどを引数に取ることです。ビジネスロジックレイヤーのClientでは与えられたIDから機器固有のIDに変換する役割を持ちます。また、複数の機器がある時に共通のインターフェイスを提供することでさらに上位のアプリケーションに対して抽象化された機能を提供します。例えばLAGを作るという機能は、CiscoではPort-Channelを作ることですし、Juniperではaeインターフェイスを作ることですし、Brocade(Ironware)ではLAGオブジェクトを作ることで、それぞれ手順が異なります。これらの差分を吸収します。
ここで作られたクライアントはビジネスロジックレイヤーのワークフローの中から呼び出されます。
Net::Telnet + xlogin
チームメイトの goto_infamouse 君が検証をしてくれているので、あわせてそちらの記事もお読み下さい。
Net::Telnet + xlogin の特徴
Telnet経由で機器を操作する方法として他にpty + IO#expectや、ruby_expectなども検討しましたが、実装と比較を行った結果Net::Telnet + xloginが一番扱いやすいと判断しました。
rancidに付属するxloginはexpectのスクリプト群で、Cisco IOS用のcloginやFoundary用のfloginなど、数十種類の機器に対するログインスクリプトが用意されています。一からexpectのスクリプトを書くよりは、これらを利用したほうが効率が良いです。
使っている機器はFoundaryやCiscoそのものではないので、スクリプトはfloginやcloginを改造してhogeloginを機器ごとに作って別リポジトリで管理しています。
xloginの良いところはコードにパスワードを書く必要が無いところです。実行者の ~/.cloginrc に書く必要があるので、パスワードを誤ってGitリポジトリに突っ込んでしまうみたいなミスも起きません。
Net::Telnet + xlogin の異常系の処理
商用ネットワーク環境で動かすシステムを作るときに一番重要になるのが異常系の処理です。想定される色々なエラーに対してNet::Telnetの動作を検証しました。たとえば、xloginスクリプトが無い、パーミッションが違う、異常終了する、ホスト名が引けない、機器へのIP接続性がない、ACLで接続拒否される、パスワードが間違っている、などなど、色々なパターンです。だいたいは Errno::EPIPE や Net::ReadTimeout で処理できますが、以下の３パターンは、正しく処理しないとルータのvtyを専有し続けるという点で、気をつけなければならないエラーでした。
間違ったenableパスワード
.cloginrc に記載されているパスワードが間違っていた場合、xloginのタイムアウト秒後に Net::ReadTimeout の例外が発生しますが、正しく処理しないとxloginの親プロセスがinitの子プロセスに移って、ルータのvtyを専有し続けます。 Net::ReadTimeout を補足した時は即座に xlogin のプロセスを kill する必要があります。
ネットワークの切断でtelnetセッションが切れる
途中でネットワーク機器への接続が切れる場合です。さきほどのケースと同様に Net::ReadTimeout が発生しますが、 xlogin を kill してもネットワーク接続性が無いため、ルータの vty は専有されたままになり、ルータ側の telnet-timeout を待つことになります。接続性が切れてもすぐに回復するような場合や、ACLやHWが原因でそのセッションだけ停止される場合に問題になります。今のところ対処方法はありません。
Matchで指定したプロンプトが来なかった
Net::Telnetではプロンプトのマッチングを行うことができます。期待したプロンプトが来なかった場合に「間違ったenableパスワード」の場合と同様の動作が発生します。
A::Telnet
A::Telnet の役割
Net::Telnetのラッパーを各機器ごとに作っています。ルータAのライブラリをA::Telnetとしましょう。このラッパーの主な目的は「コマンドを投入して、表示結果を得る」という機能を上位アプリケーションに提供することです。更に挙げれば次のような機能を提供しています
- Net::Telnetの例外を適切に処理する
- ログイン関連の機器固有のエラーを処理する
- コマンドに対する出力だけを返す
- コマンド実行後のプロンプトの判定を可能にする
- 機器の操作ログの保存
A::Telnet のコマンド処理
例えば show clock というコマンドを実行すると時刻が表示されて、次のプロンプトが出る表示が出るような場合、Net::Telnetでcmdメソッドを実行すると次のような値が帰ってきます。
puts telnet.cmd('show clock') => "show clock\n22:02:20.947 JST Sat Dec 24 2016\n\e]1hostname\ahostname"
入力したコマンドそのものがエコーされ、実際に欲しい表示が出力され、その次のプロンプト（しかもターミナルのタイトルを変更するエスケープシーケンスが入っていることがある）が含まれる３行の文字列が返ってきます。これらを処理して本来欲しいコマンドの出力結果だけを上位アプリケーションに返します。
この時に次のプロンプトを得ることができるので、保存しておくとプロンプトの判定に利用することができます。Telnet経由の操作では正しい階層に入ったかどうかプロンプトで確認する必要があります。例えば global レベルと interface レベルの両方で実行可能なコマンドがあったときに、interfaceレベルでコマンドを実行しようとしたのに interface GigabitEthernet 1/1 が失敗して global レベルで投入してしまった、というようなことが起こりうるからです（そういうCLI設計もやめてほしいですが）。
あるネットワークに対する実装は次のようになっています。
def execute_cmd(opt) result = @connection.cmd(opt) # @connectionはNet::Telnetのインスタンスです response = result.split($/) # 先頭行は入力したコマンドなので除外 command = response.shift # 最終行はコマンド入力後のプロンプトなので結果から除外 next_prompt = response.pop _log(response.join($/)) @current_prompt = next_prompt return response.join($/) end
A::Telnet の接続開始部分
Net::Telnetでxloginを使った時のやっかいな部分は、デバッグが非常にやりづらいということです。何が原因でどこで死んでいるのかぱっと見分からないからです。さらにプロセスが残りる続けたりルータのvtyを食ったままになっていたりと大変でした。接続を開始するメソッドはこんな感じです。Proxy オプションに xlogin を IO.popen で作ったオブジェクトを渡してあげることで、ログイン処理をrancidに丸投げすることができます。プロセス終了時や異常終了時に xlogin を kill することに備えて、pidを保存しておきます。
def open_connection
proxy_command = "#{@xlogin} #{@hostname}"
prompt = /^telnet@#{@hostname}(>|.*#)/
prompt_enable = /^telnet@#{@hostname}#/
timeout = @timeout
wait_time = 0
begin
@proxy = IO.popen(proxy_command, 'r+')
@proxy_pid = @proxy.pid
_log("proxy opened #{proxy_command} with pid #{@proxy_pid}")
@connection = Net::Telnet.new({
'Prompt' => prompt,
'Timeout' => timeout,
'Waittime' => wait_time,
'Binmode' => false,
'Telnetmode' => false,
'Proxy' => @proxy,
})
_log("created Net::Telnet instance")
r = execute_waitfor(prompt_enable)
# 1. proxyコマンドが異常な挙動を起こしている場合
unless r
error_message = "unexpected behavior of proxy command"
_log(error_message)
raise Errno::EPIPE, error_message
end
# 1. Error: Couldn't login
# a. ホスト名が解決できない場合(Name or service not known)
# b. ネットワーク接続性はあるがホストに接続できない場合(No route to host)
# 2. Error: Connection Refused
# a. telnetのACLでdenyされている(Connection refused)
# 3. Error: Connection closed
# a. ログインパスワードが間違っている
if r =~ /Error:/
raise A::LoginError, r
end
# ２回waitforするとうまくいくというおまじない
r = execute_waitfor(prompt_enable)
_log("login completed")
_log(@current_prompt)
cmd("terminal length 0")
# Errno::ENOENT
# proxyコマンドが存在しない場合
rescue Errno::ENOENT => e
raise e
# Errno::EACCES
# proxyコマンドの実行権限がない場合
rescue Errno::EACCES => e
raise e
# Errno::EPIPE
# proxyコマンドとのパイプが確立できない場合
# 接続エラーなのでコネクションを閉じる必要が無い
rescue Errno::EPIPE => e
raise e
# Net::ReadTimeout
# enableパスワードの不一致
# ネットワーク接続性の喪失
# X::LoginError
# 17行上で投げてる
#
# 接続した状態でのexpectのエラーなのでコネクションを閉じる
rescue => e
close_connection
raise e
end
end
このメソッドはpriavteで、コンストラクタから呼ばれます。
「２回waitforするとうまくいくというおまじない」という部分に苦労を感じ取って頂けるとうれしいです。。。
A::Telnet のコマンド実行部分
publicメソッドとして外部に出しているのがこのcmdメソッドです。コマンドを受け取って、その表示結果だけを返す機能を提供しています。当初はここでプロンプト判定も行っていましたが、current_promptメソッドを提供して、判定は上位アプリケーションに任せる設計に変更しました。
def cmd(command) result = '' begin @current_command = command _log("#{@current_prompt}#{command}") result = execute_cmd(command) rescue Errno::EPIPE => e raise e rescue => e close_connection raise e end return result end
A::Telnet の接続終了部分
接続終了時には SIGHUP で xlogin のプロセスを殺します。先にexitなどのコマンドでtelnetセッションから抜けている場合には xlogin のプロセスが終了しているためはkillを行おうとしても IOError が発生します。この例外はここで無視します。
def close_connection return unless @connection _log("closing connection...") begin unless @proxy_pid==0 _log("sending SIGHUP to proxy with pid #{@proxy_pid}...") # telnetなのでSIGHUPで適切に接続を終了してくれることを期待する Process.kill(:HUP, @proxy_pid) end # Errno::ESRCH # プロセスが存在しない場合 rescue Errno::ESRCH => e _log("process with pid #{@proxy_pid} not found") # NOP end begin @connection.close # IOError # @connectionがcloseされている場合 # @proxyをkillしているので必ず発生するはず rescue IOError => e # NOP end _log("connection closed") @connection = nil @proxy_pid = 0 end
いまや安全にこのクライアントを使って機器操作できているのはチームメイトの goto_infamouse 君がNet::Telnetの動作検証をしっかりやってくれたおかげです。
機器固有レイヤの A::Client
機器固有レイヤの A::Client の役割
このA::Clientクラスは機器固有の処理をする部分で一番実装が膨らむ箇所です。具体的にはCLIコマンドに相当するメソッドを提供して、その結果を構造化されたデータとして返します。
例えば Cisco IOS の show interface summary コマンドを例にすると、次のような利用を想定しています。
c = CiscoIOS::Client.new(hostname, options) c.show_interface_summary => [{ 'Interface' => 'FastEthernet0', 'Up' => true, 'IHQ' => 0, ... },{ 'Interface' => 'FastEthernet1', 'Up' => false, 'IHQ' => 0, ... }, ... ]
また、各種コマンドを実行したときのエラーハンドルやプロンプトのチェックもこのクラスで実施します。
機器固有レイヤの A::Client の構成
こんな感じの仕組みになっています。
module A class Client include ::A::CliParser def initialize(hostname, options = {}) @hostname = hostname @telnet = start_client(hostname, options) end def close stop_client end private def start_client(hostname, options) A::Telnet.new(hostname, options) end def stop_client @telnet.close end def exec_cmd(command) @telnet.cmd(command) end public def show_interface(interface_names) interface_names = validate_interface_names(interface_names) res = exec_cmd("show interface #{interface_names}") parse_show_interface(res) end end module CliParser def parse_show_interface(res) # CLIの結果をパースして構造化して返す end end end
CLIのパーサはテストをしやすくするためにモジュールとして切り出してあります。start_clientやexec_cmdなどもメソッドとして切り出しているのは、テストのときにモックのメソッドに差し替えられるようにするためです。
機器固有レイヤの A::Client のCLIパーサのテスト
このクラスでは愚直にCLIコマンドに相当するメソッドとそのパーサを実装するだけなので、それほど悩む点はありませんが、ひとつあるとするならばCLIパーサのテストです。
CLIの表示結果から、得られるHashオブジェクトが一意に定まるはずなので、テストケースとして入力をテキストで、出力をYAMLで用意しておきます。
# spec/fixtures/ios/15.0/show_interface_summary/mixed-interfaces.txt *: interface is up IHQ: pkts in input hold queue IQD: pkts dropped from input queue OHQ: pkts in output hold queue OQD: pkts dropped from output queue RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) TRTL: throttle count Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ----------------------------------------------------------------------------------------------------------------- * FastEthernet0 0 0 0 130 194000 50 195000 52 0 FastEthernet1 0 0 0 0 0 0 0 0 0
# spec/fixtures/ios/15.0/show_interface_summary/mixed-interfaces.yml - Interface: "FastEthernet0" Up: true IHQ: 0 ... - Interface: "FastEthernet1" Up: false IHQ: 0 ...
テストはRSpecを使って次のように書いています。
# spec/ios/cli_parser_spec.rb def path_of_example(version, command, case_name) command = command.tr(' ', '_') "spec/fixtures/ios/#{version}/#{command}/#{case_name}" end def load_input(version, command, case_name) File.read("#{path_of_example(version, command, case_name)}.txt") end def load_expected_output(version, command, case_name) YAML.load_file("#{path_of_example(version, command, case_name)}.yml") end def get_method_name(command) command = command.tr(' ', '_').tr('-', '_') "parse_#{command}" end def exec_parse(parser, version, command, case_name) input = load_input(version, command, case_name) method_name = get_method_name(command) parser.method(method_name).call(input) end RSpec.shared_examples "interface mixed-interfaces" do it "parses normal output" do case_name = 'mixed-interfaces' expected = load_expected_output(version, command, case_name) expect(exec_parse(parser, version, command, case_name)).to eq(expected) end end RSpec.shared_examples "interface error-invalid-slot-number" do it "raises error for invalid slot number" do case_number = 'error-invalid-slot-number' expect{ exec_parse(parser, version, command, case_number) }.to raise_error(A::InvalidInputError, 'Invalid input -> 100/1') end end RSpec.describe A::CliParser do let(:test_class) { Struct.new(:parser) { include A::CliParser } } let(:parser) { test_class.new } context "with IOS Version 12.0" do let(:version) { '12.0' } describe "parse show interface summary" do let(:command) { 'show interface summary' } include_examples "interface mixed-interfaces" include_examples "interface error-invalid-slot-number" ... end describe "parse show ip ospf" do ... end context "with IOS Version 15.0" do let(:version) { '15.0' } ... end ... end
工夫したポイントとしては、バージョンが複数あり、コマンドが複数あり、ケースが複数あるので、それぞれに識別子をつけてそれを指定すればテストができるようにしたところです。ここでいうケースは「インターフェイス名に無効な値を指定した場合」とか「10Gの正しく設定されたインターフェイスの場合」とかです。
まず、CLIParserをモジュールとして分離しているので、let(:test_class) { Struct.new(:parser) { include A::CliParser } } と let(:parser) { test_class.new } でパーサの機能だけを持った試験用のクラスを作成します。
context と let(:version) { '12.0' } を使ってOSのバージョンを指定し、describe の let(:command) { 'show interface summary' } で対象のコマンドを指定します。
ケースは RSpec.shared_examples を使ってバージョンやコマンドを通して共通化しておきます。これを include_examples case_name で呼び出します。
バージョン、コマンド、ケース名の３つがわかると、入力ファイルのパス、出力ファイルのパス、CLIパーサのメソッド名が自動的にわかるように命名規則を定めています。
shared_example の中では、入力のテキストを読み込み、パーサに食わせて、出力のYAMLと比較する、ということをやっています。
このようにテストを書いておけば、少なくとも既知のコマンド出力に対しての動作を保証できるのでとても安心です。
ビジネスロジックレイヤのClient
ビジネスロジックレイヤでは次のことを行うつもりです。というのもまだしっかりと実装ができていなくて、この設計でいいのかわからないからです。
たとえばVLANを変更するといった処理をするときに、機器Aではインターフェイスをshutdownする必要があるが、機器Bでは必要ない、といった場合に、これらのワークフローの違いをどう扱えばいいのかという課題に直面します。上位のワークフローで扱うのか、このクラスでワークフローを隠蔽したメソッドを提供するのか、難しいです。単にやるだけならこのレイヤーで吸収してしまえばいいのですが、例えば「Web画面にshutdownされることの警告を出したい」となってしまうと困ります（実際にはshutdownされないのに警告を出して「shutdownされる可能性があります」みたいに言う手もありますが）。
このあたりに関しては試行錯誤している最中なので、もう少し知見が溜まってきたら記事を書いてみたいですし、もしも経験のある方がいらっしゃれば記事を書いてほしいです。
さいごに
今年のクリスマスイブはTelnetの記事を書いて過ごしました。
Merry Christmas and Happy NetOpsCoding!!
保育園を増やすか移民を受け入れるかどっちがいい？
あんまりプライベートなこととか政治的な意見は公に書きたくないんだけど、 id:gomi-box から待機児童ゼロチャレンジバトン（#taikijidou0challenge）なるものが回ってきたので書きます。
時間が無い人のためのまとめ
タイトルはちょっと飛躍してますが本質は結局はそういうことなんじゃないのかなーと思う。
最初にまとめておくとこの記事にはこういう話が書いてある：
- 待機児童を減らすことはあくまで手段で、目的は日本の人口を増やすことだよ
- 日本の人口を増やそうと思うと３人は産まないとだめだよ
- 働きたいから保育園に預けるってのはワガママだよ
- でも今の世論や政策のようにワガママを聞いてもらえない状況だと、みんな子供は多くても１人で産むの止めちゃうよ
- 日本政府がやるべきことは国民個人がワガママ＝自己利益の最大化に走ろうとした時に日本の人口を増やせるような方向へ誘導する政策を実行することだよ
- それができないと年金は破綻するし、経済を維持するために移民を受け入れないといけなくなるよ
- ちなみに移民も子供を産んで保育園に預けようとするから、日本人は更に保育園に預けられなくなって子供を産む数が減るよ
- みんなそれでも平気？
そもそも日本の人口を増やさなくていいとか移民大歓迎って人にとっては、この記事は価値がありませんので、ここで読むのを止めていただくことを推奨する。
ここから国に対する要求として次の３点を主張する。
- 子供を３人産める環境を作れ
- 育児と仕事の選択をさせるな、両立させろ
- 保育を親ではなく国の義務・責任にしろ
ここでは「保育園」を０歳から小学校入学までの保育施設をひっくるめた意味で使いたいので幼稚園の延長保育や認定こども園なども含めたいと思う。
最低３人産まないと日本の人口は増えない
女性１人当たり2.08人産まないと日本の人口は維持できないらしい。結婚しない女性もいるだとうし、子供を産まない夫婦もいるので、産む気のある夫婦では３人は少なくとも産まないと日本の人口を維持できないし増やすこともできない思う。なので３人産む前提で話を進めたいと思う。
子供が１人である程度活動できるようになるのを小学校１年生だとすると、１人産んだ時につきっきりで子供の面倒を見ないといけなくなるのは０歳から６歳頃までの６年間になる。３人産むとなると最低でも８年はかかる。法的な育児休業は１歳６ヶ月までだし企業規定の育児休業も３歳までのところが多く、年子で３人とか無理なので実際は間隔を空けて10年近くかかることになる。
また共働きしないと家計が成り立たない世帯は保育園に預けざるを得ないので、彼らの話はしない。共働きしなくても家計は成り立つけど働きたいから預けたいという世帯を対象にする。
それから、３歳までは親が育てたほうがいい等の育児論や教育論もここでは扱わない。
男女平等と自己実現を尊重する価値観
昔は男は外で稼ぎ女は家の面倒を見ろという価値観だったかもしれないけど、現代は違う。男女平等が叫ばれ女性の社会進出が叫ばれ、それが実現できてきているように思う。
男女関係なく個人の自己実現を尊重する風潮が少なくとも若い世代ではあるんじゃないかなと思う。いわゆるやりたいことをやってなりたい自分になるってやつだ。
僕も妻には働いて欲しいというか、自分のやりたいことをやってほしいと思う。だから育児の負担は半分ずつにしたいと思っている。
なのでここでは男が女がどっちがという話はしない。
女性の権利等の話はちょうど今日素晴らしい記事がホッテントリ入りしていましたので、そちらを読むことをお勧めします。
働き盛りに仕事を長期間休まないといけないのは辛い
３人の子供を育てるとなると、２人で負担を分担しても５年、片方だけが負担するなら10年を乳幼児の育児に専念することになる。
５年とか10年の休業というのは20歳で就職して60歳で定年したときに就労できる40年の間のそれぞれ12%、25%に相当する。
しかもただの５年、10年ではない。大半の人は20代後半から30代の一番仕事がノってきて頑張らないといけない期間に休業することになる。復帰する頃には30代後半や40代に突入している可能性が高い。
その期間働けないということはこの年功序列の日本社会においては残念ながら出世に大きく影響がある。出世を望まなくとも10年のハンデは非常に大きい。
転職をしようと思ってもただでさえ雇用の流動性の低い日本でブランクを抱えて40歳前後で転職というのもなかなか能力と経験がずば抜けていないと難しい話だ。
だから活躍したいのに保育園に預けられなくて日本死ねって言いたくなる気持ちは痛いほどよく分かる。
働きたいから子供を保育園にあずけるのは確かにワガママです
そうした自己実現のために子供を保育園に預けたいという願望は確かにワガママだと言える。それは間違いない。
ただ、そういうワガママな人たちに国のせいにすんなとかワガママだとか自己責任だとか努力が足りないとか地方に引っ越せとか言っても何の意味もない。むしろ逆効果だ。子供を産んだのに日本の社会はなんて酷い仕打ちをするんだと思ってしまう。
そもそも共働きしないと行きていけない人たちしか保育園に預けてはいけないなんていう決まりはない。会見で化粧している余裕があるとかブランド物の抱っこ紐だとかいう批判は筋違いも甚だしいので取り合う必要はないだろう。
保育園問題に対する批判は出産を萎縮する
子供を産んでも自己責任といわれ何かを要求するとワガママだと叩かれる風潮が出来上がってしまうと、子供を産みたいと思う人は減ってしまう。
今の御時世結婚は損だから独身でいようとか子供を産んだら自分たちの時間や使えるお金が少なくなるから産まないでおこうみたいな主張が少なくなく聞かれる状況なのだ。
その上更に、子供を産んだうえで自分の生きたいように生きようとすると社会から叩かれるような空気を膨らませるとますます少子化が加速する。
レベル０の勇者をパーティーに加えて稼いだゴールドを勇者の装備につぎ込みスライム狩りを始めるのだ。２人で海外旅行に行くのもおしゃれなレストランにいくのも無理どころか外食すら厳しい。親達の自己実現など程遠くなってしまう。
個人の最適解は子供を産まないことになる
そうなってくると彼らの個人としての最適解としては子供を産まないということになる。
これは結婚しない・子供を産まないのがお得という風潮にも既に現れている。
子供のために家賃の安い郊外に引っ越して長時間かけて通勤し、趣味も我慢して節制に励む。そんなことするぐらいだったら子供なんてイラネって考える人達は今後ますます増えてくるんじゃないかなと思う。
この発想は特に自己実現欲の強うそうな高所得者層やインテリ層に多いんじゃないかなと思う。そうだとすると後は言わずもがな。
こんな風にもし個人が自己実現のために局所最適化を行うこと自体が嫌なのであれば「１億総活躍」みたいなことは言わないでおいて欲しい。
産んだとしても１人で終わり
もう一度言うが、こういう人たちに「ワガママ言うな、死ね」といっても何の意味もないのだ。「じゃあもう子供産むのやめよー」ってなるだけなのだ。
１人産んで保育園に入れられず、それに文句を言ったら袋叩きに遭う、こんな仕打ちなんだったら２人目を産みたいと思えるか、というより１人目の育児で精一杯で現実的に産めなくなるよね。そんな苦渋を舐めた人たちが２人目を産もうと思わないよね。
それに１人目を仮に保育園に入れられたとしても２人目も保育園に入れられる保証はないのだから（優先度は上がる）、保育園に１人目を預けられたとしても不安は拭えない。
自分たちの遺伝子を残したいという目的であれば子供は１人で十分なのだ。
国がやるべきことは「囚人のジレンマ」の解消
個々が自分の利益を最大化しようとした結果、系全体にとって望ましくない結果になることをゲーム理論の用語で「囚人のジレンマ」と言う。
今のままでは個人が自己実現のために人生を最適化すると子供を産まない選択肢をとるようになり少子化が進行する。これは国家にとって望ましい結果ではないと思う。
そうならないように、１億総活躍の自己実現を求めて国民が個人の人生の最適化に走る時に、国家として利益を最大化できるような仕組みを作ることが政治家の仕事であると思う。保育園を作らない理由をたらたら述べるだけの人はいらない。
もし出生率が増えることが国家として望ましい結果なのであれば、子供を産めば産むほどお得になる制度を整備しないといけない。例えば環境問題のために「エコカー減税」でやったように。出生で言うなら政策ではないが一企業であるソフトバンクがやっているように。
僕は保育園問題の専門家ではないので、保育士の給料がどうとか騒音問題がどうとか独身税の是非とか不妊の人への配慮といった個々の戦術について提案・議論するだけの知識を持ち合わせていないので、そのへんの議論は専門家にお任せするが、日本国家の戦略としてこの方向性は間違っていないと思う。
保育園が増やせないなら移民を受け入れることになる
３人産まないといけないのに産む気のある人が１人で産むのを止めてしまう社会になると当然人口は減少の一途をたどる。そうすると経済を支える生産年齢層がむちゃくちゃ減る。
そうすると年金システムが破綻するのは容易に想像がつくだろう。
そうならないよう生産年齢層を増やすためには外国から人を招かざるを得ない。つまり移民の受け入れだ。
日本の風土や文化を鑑みると、移民受け入れは合わないと思う。受け入れたとしても慣習や文化の違いから様々な場所で軋轢を生み、日本人のストレスはマッハだろう。すでにそのようなことが起きていることは度々マスメディアで取り上げられていると思う。今後それが加速すると、今は関係ないと思っている人も巻き込まれることになるだろう。
保育はもはや福祉ではない
生存のためには必須ではないが最低限の幸福の実現のために行われるのが福祉であるならば、もはや保育は福祉だと思ってはいけない。シラク三原則のブコメでも指摘があるように国家の義務として保育を扱い、家族構成や両親の生き方や経済状況に関係なく産まれてくる全ての子供を育て上げる仕組みを作れないのであればこの国に未来はない。
保育園問題は20年先の種まきだ
当たり前の話だが生まれたての赤ん坊が成人するまで20年かかる。
つまりこの保育園問題は20年先への投資であることを理解して欲しい。
逆に言うならば、問題が生じてから対応しようとしても効果が現れるまでに20年かかるということだ。問題に気づいた時には既に手遅れになっている可能性が高い。
そうならないためにも今このタイミングで何かしらの対策は講じなければならない。
もしかしたらもう遅いのかもしれないけどね。
誰が声を上げるのか？
で、この問題に誰が声を上げるのだろうか？
保育園に受かった親たちは通知が届くまでは皆同じ気持で元ネタの記事を読んでいたに違いないと思う。１つ歯車が狂っていたら自分も日本死ねという側になっていたのだ。
でも保育園に受かったら受かったで今度はそっちに集中しなきゃいけなくなる。彼らとしては政治活動をする余裕があるなら子供にリソースをつぎ込みたいのだ。送り迎えがあるから早く起きて家をでなければならない。デモする余裕があるなら少しでも睡眠時間に充てて体力の回復に努めたいというのが本音だろう。
そうなると声を上げるのは落ちてしまった親たちになる。彼らも３歳児クラスで保育園に預けられるようになるかもしれないし、小学校に入るようになったら過去の話になってしまう（今度は学童問題が待っているんだけどね）。
すでに指摘があるように継続してこの保育園問題を政治に訴える人はいないのだ。
保育園問題は国家の生存戦略の問題です
保育園に預けられる預けられないとかで困ってる人が声を上げるべき問題では無いんです。
国家として次の世代をどう繋いでいくかという問題だと思うんです。
家族構成や両親の生き方や経済状況に関係なく、産まれてくる全ての子供を育て上げられる仕組みを国家として作り上げて、全ての夫婦が安心して子供を産めるようにして下さい。
政治家の皆様、そこんとこよろしく。
FAQ
Q. 家から働けばよくね？
A. 子供の面倒見ながら仕事とか無理
Q. 保育園じゃなくて親に預ければよくね？
A. 自己実現のために親の自己実現を犠牲にするとか鬼畜。子育て終わったと思ったら孫育てとか地獄っしょ。
あとは思いついたら足していく
