「転職はとりあえず3年働いてから」って本当ですか？

去年の年末に途中まで書いていた記事が下書きのまま放置されていたので、タイトルはそのままにして、加筆修正しました。半分くらい去年に書いた内容で、半分くらい今日書いた内容です。

「転職はとりあえず3年働いてから」という言葉を就活生時代によく聞いていましたが、当時は就職してすらなかったので転職なんて想像もつきませんでした。僕と同世代のエンジニアは約4年間の間で転職した人の話もそこそこ聞くようになりました。そんな中で僕は新卒で入った会社で働き続けて気がついたらもうすぐ4年になります。

入社して3年が経った

(※ この記事を書き始めた当初は3年でしたが、今はもうすぐ入社して4年になります) サイバーエージェントとという会社に2015年に新卒で入社しました。入社直後は聞きなれない言葉ばかりが飛び交っていて面白かったのでメモして記事にしてました。今みるとちょっと古いですね。

kurochan-note.hatenablog.jp

ちなみに、少し前に増田で似たような記事がバズっていましたがあれは僕は書いていません。中の人からするとちょっと内容が古かったりしたので元社員とかなのかなと想像してます。検索してみたら削除されていました。

入社してから何をやっていたのか

入社以来チームの異動をしたことはなく、ずっと同じチームに居ます。3年目くらいまではずっと同期を見て焦っていたきがします。

業務で対外的に発表した機会は少なくて、たぶん以下の5つくらいです。

Dynalystにおける動的な画像生成 - Speaker Deck

Scalaプロダクトのビルド高速化 - Speaker Deck

Dynalyst流Datadog活用法 (公開用) - Speaker Deck

Datadog Logsでアプリケーションログを管理する - Speaker Deck

月間数千億リクエストをさばく技術 (ArchitectureNight公開用) - Speaker Deck

この5つだけを見るとDevOps寄りな仕事をしているように見えますが、Scalaを書いている時間が一番多いです。インフラ、監視、ミドルウェア、アプリケーションあたりは特に担当領域を分けずにチームメンバ全員で面倒を見るようにしているので、アプリケーションの開発時間が一番長いものの、全員ひととおり触れるはずです。

最後のスライドは社内向けのエンジニアカンファレンスで発表したところ、ベストセッション賞を貰ったので社外向けに内容を加工して発表してみました。timakinというエンジニアが企画したアーキテクチャナイトという勉強会の開催を手伝ったところ、logmiさんが取材に来てくれました。

https://logmi.jp/tech/articles/306550 logmi.jp

公開する前に事前に原稿は共有してもらえて、用語とかもちゃんと表記されていてクオリティの高さにびっくりしました。ほとんど修正の依頼はしていないです。

あとはICTトラブルシューティングコンテストという学生向けのインフラ系の技術を競うコンテストの実行委員(社会人サポータ的なやつ)に会社の名義で参加しています。

developers.cyberagent.co.jp

会社からコンテスト用のサーバとかスイッチとかファイアウォールとかの機材貸出もしていて、インフラ部署の同期とその部署のボスが検証機材等を集めてくれたおかげで毎回協賛できています。そのためにデータセンタ行ってもらったこともあるっぽくてありがたい。。

最近は何をやっていたのか

ずっと広告システムの開発をやっています。バックエンド系が中心です。 3年目になってようやく普通(?)に仕事ができるようになってきた実感があります。4年目も黙々と開発をやっていました。

ようやく色々わかってきた

遅いかもしれませんが、仕事の進め方とか、巻き込み方とか、ようやくわかってきたような実感があります。

採用に関わるようになった

会社のビジョンに「採用には全力を尽くす。」「能力の高さより一緒に働きたい人を集める。」とあります。

ビジョン | 株式会社サイバーエージェント

YJC（良い人を自分たちでちゃんと採用する）プロジェクト始動！ | おざまさブログ。

YJC（良い人を自分たちでちゃんと採用する）プロジェクト始動！ | おざまさブログ。

YJCという取り組みがあって、要するに現場社員が採用にしっかりコミットしようということです。名前の略がしっくりときませんが(笑)採用活動に熱心な社員がたくさん集まってくるのはすごいと思います。うまくいっているところもありますが、うまくいっていないところもあって、まだまだ全社員の力は活かしきれていないのでそのあたりは模索中というところでしょうか。部署の先輩が考案した「ひとりDSP」というエンジニア研修とそれをインターンに展開したものは3年半経った今も改善を重ねて受け継がれていて、直近のインターンも後輩が記事を書いてくれました。

developers.cyberagent.co.jp

この回は僕らは運営はしなくて、運営をしてくれる社員をマネジメントする立場というのをやってみたのですが、それについては年明けに記事を出します。

新卒のトレーナーを担当した

誰が言っていたか忘れましたが、新卒のトレーナーになる人はこれを読んだ方がいいと言われました。

ameblo.jp

僕の働いている事業部の取締役の記事です。 「覚えさせる」のではなく、「成果を出させること」がトレーナーの仕事だというわけです。

ただ無理にやりすぎると「お膳立てされた成果に自分(新卒)が乗っかる」感じになって逆に嫌になる気がするので、バランスを見極めるのがトレーナーの仕事なのでしょう。放置していてもどんどん進めていくタイプの新人の場合は見守りつつ、本当にヤバい時だけストップを掛ける立ち回りがいいんじゃないでしょうか。

高校の時の数学の先生が「『なんでわからないの？』と言ったら教える人失格だ」言っていた言葉が記憶に残っています。もし自分が「なんでこんなこともわからないんだ」と思うことがあったとしてもそれだけは言ったらダメと教わりました。突き放してしまうとわかったフリをする癖がついちゃいますよね。「何がわからないのか分かっていない状態」を一緒に「何が分からないのかが分かっている状態」にするのかトレーナーの業務なのかなと思いました。何がわからないのかが分かっていればあとはその穴を自分で学んで埋めて貰うように促すことができますよね。

Slackに #furikaeri_xxx (xxxはトレーニーの名前)という自分ひとりしか居ないprivateチャネルを作って、ひとりでもくもくとメモを取っていました。基本は新卒と業務のふりかえり面談(トレーナーは月1回以上の頻度でやることになっています)をした時に新卒と話しあって出た話をひたすらメモしてるだけです。あとは業務中にふと思うことがあればふりかえり面談の時に話題に出せるようにあらかじめメモしておいたり。

f:id:kuro_m88:20181231223902p:plain

これだけ見ても他人からすれば何を言っているかわからないですし、ここに書いてある内容自体はたいして重要ではないです。読み返したときにその時の状況とか、考えてたことが想起できるのでお互いに振り返りがやりやすかったです。 毎日日記をつける習慣がある人なら自分でもやっていると思いますが、自分はしないタイプで、新卒のときに1ヶ月ごとでも振り返ったときにあまり思い出せなかったことがあったのでやってみました。 ちなみに1年のトレーナー期間が終わったあとにはこのチャネルにinviteして自分がメモしていた内容は共有しました。何かに使えれば使ってもらえばいいし、必要なければarchiveしてもらえばいいだけなので。

本を書いた

2月にこんな本が発売されました。社会人3年目のエンジニア2人と社会人2年目のエンジニア2人で書きました。

gihyo.jp

さくらインターネットの取締役の伊勢さんからお話をいただきました。雑誌の寄稿はしたことがあったのですが、本を書いたのは初めてでした。普通はこういったチャンスは社内の人間で固めたくなる気がしますが、他社の僕にも話を振ってくださって感謝しています。 ネタを探してまた本を書いてみたいと思っています。

社員総会で表彰された

今年の4月の社員総会で「最優秀ベストエンジニア賞」という賞をいただきました。”最優秀ベスト”って意味が被ってるんじゃないかと社内外からよく指摘されて若干恥ずかしい気持ちになりますが、表彰対象5人の中から1人が最優秀として選ばれるようなのでこういう名前になるようです(?)。3〜4000人くらいの社員の前でいきなり話すことになるとは思っていなかったので何を喋ったのかよく覚えていません…。たぶんたいした話はできませんでしたが、チームメンバーや同期には特に感謝しています。

給料の話

最近は新卒エンジニアの初任給のが各所で話題になっている気がします。 ぱっと思いついたところだと

エンジニアを対象に一律の初任給制度を撤廃し、個々人の能力に応じた給与体系を導入 | 株式会社サイバーエージェント

メルカリ、新卒新入社員向け人事制度『Mergrads（メルグラッズ）』導入 〜個人の能力や経験に応じたオファーを提示、内定者向けにインプットを支援し、内定期間中の昇給も〜 | 株式会社メルカリ

募集要項 - 採用情報 - ヤフー株式会社

採用について｜さくらインターネット新卒採用

などでしょうか。自分の働いている会社は今年から給料が可変になっただけでなく、下限も去年度より上がっていますね。新卒エンジニアの価値がどんどん上がってきていることがわかります。

20代前半の優秀なエンジニアには転職ドラフトを見せないほうがいい - 彼女からは、おいちゃんと呼ばれています

そういう流れもあってなのかどうか知りませんが、「技術政策室」という組織が作られました。

https://7gogo.jp/-FlLmV4De4D7/12734

給料だけじゃないよっていう話は理解できるのですが、「だけ」じゃないので給料「も」大事だと思います。3年目までは何も考えていなかったので特に給料は気にしていなかったのですが、比較対象がなかったので3年目から少しずつ気にするようになりました。

転職ドラフト

転職をする意思がなくても自分がどんな評価をされるのか試せる、「転職ドラフト」というサービスがあります。学生時代を除けば1社でしか働いたことがないので、自分が世間的にどういう評価をされるのか気になり、去年の転職ドラフトに参加してみました。結果としては5社から指名を頂き、うち3社で当時より良い年収で指名を貰いました。

今の給料は当時一番よかった指名額より高くて、結果論で言えば転職しない方が給料がよかったことになります。 もしも転職ドラフトのタイミングで転職していたら自分も損していましたし、会社も(たぶん)機会損失していたでしょうから、1-3年目のうちにもう少し上がっていれば悩まずに済んだのになぁという気持ちがあります。ここの差は埋められるようにしたい。

「転職はとりあえず3年働いてから」って本当ですか？

今の職場に新卒で入ってよかったなという思いはあります。採用の中に関わっているとよく「素直でいいヤツ」という言葉を聞くのですが、僕の同期も本当にそうで、僕の代の採用に関わった人に感謝をしています。同期という繋がりが得られるのは新卒で入社した社員の特権です。非公式ながら、 “Ex CyberAgent Developers Advent Calendar 2016” という退職者アドベントカレンダーが爆誕したこともありました。

Ex CyberAgent Developers Advent Calendar 2016 - Adventar

全然埋まってないんですが、実はこれ、全員同期だったりします。 僕と同じ事業部に居た同期も2人書いていました。

新卒とメンターリングについて考えてみた - Φφ's blog

サイバーエージェントを退職しました | κeenのHappy Hacκing Blog

みんな今でも仲がよくて、Slackでは毎日技術的な話からくだらない話までわいわいしています。

f:id:kuro_m88:20181231223944p:plain

同期は社内の色んな部署で働いているので、他の部署の情報といえばそこまで頻繁に流れてくるわけではないのですが、活躍している様子が耳に入ってくると「燃えている」という表現をすることがあります。4年近くも働いているとチームの重要なポジションに着いているひとも多くなってくるので、そういう人が方針転換をしたり、大きく動かすような仕事をしていると外から見たら炎上しているように見えるかもしれません。まぁみんな元気に仕事ができていればいいことなのかなと。

転職する理由はひとそれぞれですが、同期を見ていると、社外にチャンスを見つけたからというポジティブな理由の人が大半です。移り変わりが激しい業界だからこそ、チャンスだと思ったらすぐに動かないと躊躇しているとチャンスが消滅してしまう、なんてこともあるかもしれません。会社からすれば優秀な人材を失うことほど痛いことはないですが、こういった外部のチャンスをコントロールすることは無理ですし、縛り付けるのは不健全です。外部で新しいチャレンジをしたい、という人はたいてい応援して送り出して貰えるでしょう。優秀な人材を留めておくためには常にチャレンジができる環境を作らないといけないということですね。もし会社がコントロールできる事があるとしたら給料くらいでしょうか。チームや業務への満足度が高いのに給料が理由で優秀な人材が流出する場合があるとすれば悲しいですね。

で、「転職はとりあえず3年経ってから」という噂は本当だったのかという話ですが、あまり関係ないですね。ただ、 自分は結果的に同じ会社どころかずっと同じチームで働いています。自分が働いている会社だと、入社してから3年間ずっと同じチームに居るのは少数だと思います。まわりが当たり前のように異動/転職しているなか自分も動かなくていいのかと不安になったりもしました。 考え方を変えてみれば、「同じ会社で働く」という選択をしているわけです。同じ環境にずっと身を置くにしても、どこかへ行くにしても「選んでいる」という感覚は忘れないようにしないといけないんだろうなぁというのが最近思うことです。

僕は異動もしたことがないので、今のチームの事しか言えませんが、今のチームだと、なにか新しい事を始めたあと、慣れてきたので割と楽になってきたなぁと思ったり、飽きそうになるタイミングになるとたいてい新しいネタが降ってきたりしてあんまり楽はできません(いい意味で)。この会社のひとたちは成長し続けないと死ぬ病気なのかと思うくらいみんな現状維持だけすることに興味がないです。 もちろん、たまたま運良くそうなってるわけじゃなくてそういうマネジメントをしてくれているのだと思います。自分もそういうふうにやっていきたい。

次はなにするの？

ここで突然の転職予告があれば退職エントリーとして仕上がるかもしれませんが、退職しないのでこれは在職エントリーでした。

そして異動もしませんが、来年からチームの開発責任者をさせてもらうことになったのでがんばります。マネジメントっぽいことも業務に入ってくるとがっつり開発というわけにもいかなくて…という話をよく聞きますが、技術は好きなのでどこまでやれるのか試してみようとおもいます。

ただ、頑張りすぎて疲弊するという話もあるのでいい感じのバランスをとれればなと思います。

WireGuardでAllowedIPsに0.0.0.0/0を指定するとパケットが全てVPNインターフェイスに吸い込まれてしまう件

WireGuardという素晴らしいVPNソフトウェアがあります。シンプルなのでほとんどハマりどころはないのですが、自宅で試していたところ少し意図しない挙動を見つけたのでその理由と対処方法をまとめます。 WireGuard: fast, modern, secure VPN tunnel

何が素晴らしいのか、詳細が気になる方はこちらのスライドをご覧になるのがいいと思います。 [CB16] WireGuard:次世代耐乱用性カーネルネットワークトンネル by Jason Donenfeld

AllowedIPsに0.0.0.0/0を指定するとパケットが全てVPNインターフェイスに吸い込まれる

AllowedIPsに0.0.0.0/0を指定するのはどんなときかと言うと、VPNインターフェイス経由で送信するパケットの宛先をすべて許可したい時です。例えば、カフェのFree Wi-Fiが信用できない時にすべてのトラフィックをVPNサーバ経由にしたい時はVPN経由のパケットの宛先IPは何が来るかわからないのですべての宛先のパケットを許可するために0.0.0.0/0を指定しますね。

もしくは、少数派な使い方かもしれませんが、L3 VPNなのでstatic routingをしたり、VPNの両端のインターフェイスでルーティングプロトコル(ospf, bgpなど)を喋るデーモンを起動して動的に経路情報を交換するようにするかもしれません。ルーティングテーブルで宛先を制御する場合も意図せずパケットがフィルタされないようにするためにAllowedIPsは0.0.0.0/0にすると思います。

このような意図で0.0.0.0/0を指定する場合、実際に0.0.0.0/0にマッチするパケット、つまり全てのパケット(後述しますが厳密には全てではありません)がWireGuardのインターフェイスを経由してほしいわけではありません。が、 wg-quick コマンドを使ってWireGuardのインターフェイスを作成すると全てのパケットがWireGuardのインターフェイスに吸い込まれてしまう現象が起きます。

現象の確認

OSはUbuntu18.04です。

ubuntu@c01:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:a3:9e:eb brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.59.79.145/24 brd 10.59.79.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fea3:9eeb/64 scope link
       valid_lft forever preferred_lft forever

NICは1つだけあります。

WireGuardの設定ファイルを作ってみました。wg0.confの中身はこんな感じです。

ubuntu@c01:~$ cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = GIWLRkDQXS/wym2pCWW2VDKTBpUp2a60AB+KSG18SEE=

[Peer]
PublicKey = uKjZpzBmrsp7YGqhpTLajsk2XiKj0HHYoRMkLVOaE2c=
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.100.61:51820

192.168.100.61:51820 というのがVPNの接続先だと仮定します。(適当なIPなので実際には対向は存在しませんが今回は問題ではないのでこのまま続けます)

WireGuardを起動してみる

wg-quick コマンドを使って起動してみます。

ubuntu@c01:~$ sudo wg-quick up wg0.conf
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.1/24 dev wg0
[#] ip link set mtu 1420 dev wg0
[#] ip link set wg0 up
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

ubuntu@c01:~$ sudo wg
interface: wg0
  public key: M91GRcFHFdXtRL4UXh9d18sv1w9/KYbibOYcGyLzAwk=
  private key: (hidden)
  listening port: 51820
  fwmark: 0xca6c

peer: uKjZpzBmrsp7YGqhpTLajsk2XiKj0HHYoRMkLVOaE2c=
  endpoint: 192.168.100.61:51820
  allowed ips: 0.0.0.0/0

ubuntu@c01:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:a3:9e:eb brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.59.79.145/24 brd 10.59.79.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fea3:9eeb/64 scope link
       valid_lft forever preferred_lft forever

wg0 インターフェイスが追加されましたね。

インターネットに向けてpingを打ってみる

8.8.8.8に向けてpingを打ってみました。

ubuntu@c01:~$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms

…あれ？パケットが全部落ちていますね。ちなみに同時にtcpdumpをしてみたのですが、

ubuntu@c01:~$ sudo tcpdump -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
12:52:34.626312 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 1667, seq 3, length 64
12:52:35.650419 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 1667, seq 4, length 64
12:52:36.674427 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 1667, seq 5, length 64

wg0 インターフェイスのIPからインターネットに出ようとしていますね。これは変ですね。

WireGuardを落とすとどうなるでしょう？

ubuntu@c01:~$ sudo wg-quick down wg0.conf
[#] wg showconf wg0
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0

ubuntu@c01:~$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.37 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=3.35 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=3.19 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.196/3.309/3.378/0.093 ms

パケットは普通にインターネットに届いているようです。これが今回困った事象です。

原因

WireGuardを起動した状態でルーティングテーブルを確認してみます。一見問題がないように見えますね。

ubuntu@c01:~$ ip route
default via 10.59.79.1 dev eth0
10.0.0.0/24 dev wg0  proto kernel  scope link  src 10.0.0.1
10.59.79.0/24 dev eth0  proto kernel  scope link  src 10.59.79.145

WireGuardの起動時の出力を見ると気になるログが2箇所あります。

[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820

なにやら怪しいですね。

ubuntu@c01:~$ ip rule
0:      from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

ubuntu@c01:~$ ip route show table 51820
default dev wg0  scope link

fwmark 51820 がパケットにセットされていない場合はルーティングテーブル 51820 を参照するルールで、そのルーティングテーブルはデフォルトルートとして wg0 インターフェイスが設定されています。つまり、何もパケットがマークされていない全てのパケットは wg0 からインターネットに出ていこうとします。これは困りますね。逆にどういう時に fwmark 51820 が付いているのでしょうか？会社の同期がそれっぽいものを見つけてきてくれました。

f:id:kuro_m88:20181104213916p:plain

Routing & Network Namespaces - WireGuard

Improved Rule-based Routing の段落をご覧ください。

we are able to set an fwmark on all packets going out of WireGuard's UDP socket

とあります。WireGuardによって暗号化されたパケットに fwmark をつけてくれるようです。全てのパケットをVPN経由にしたい場合、0.0.0.0/0の宛先をWireGuard経由にしたくなりますが、そうするとVPN自体の暗号化されたパケットもVPNインターフェイス(wg0)にルーティングされてしまいループしてしまって外に出られなくなりますが、 fwmark がついているパケットだけホストに元からあるルーティングテーブルを参照させ、それ以外のパケットは全てVPNインターフェイスにルーティングされるようにしてくれるようです。冒頭で例として挙げた、「カフェのFree Wi-Fiが信用できない時にすべてのトラフィックをVPNサーバ経由にしたい時」などにはありがたい挙動ですが、後者の「static routingをしたり、VPNの両端のインターフェイスでルーティングプロトコル(ospf, bgpなど)を喋るデーモンを起動して動的に経路情報を交換する」場合には全てのパケットがVPNインターフェイスに吸い込まれてはこまりますね。

対処方法

原因はわかりました。デフォルトルートを wg0 向ける設定追加がされないようにすればいいだけですね。残念ながら、 wg-quick コマンド経由でこの設定が自動で投入されないようにする方法は見当たりませんでしたのでかっこ悪いですが以下のような設定をしました。

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PostUp = ip -4 route del 0.0.0.0/0 dev %i table $(wg show %i listen-port)
ListenPort = 51820
FwMark = 0xca6c
PrivateKey = aIG1izlztM2ISSsaLPmQpamqc0FdFnUoYTpeeYNWQm0=

[Peer]
PublicKey = uKjZpzBmrsp7YGqhpTLajsk2XiKj0HHYoRMkLVOaE2c=
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.100.61:51820

追加したのは PostUp = ip -4 route del 0.0.0.0/0 dev %i table $(wg show %i listen-port) の一行です。 %i というのは実行時にインターフェイス名に置き換えられます。追加された設定を直後に消すということですね(笑)

これで思ったような挙動を得ることができました。よかった。

Ubuntu18.04のマシンでKVMで仮想マシンを立ててcloud-initで初期化する

環境

Intel NUC(2コア4スレッド、メモリ32GB)にUbuntu18.04をインストールしました。

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:        18.04
Codename:       bionic

vhost_netを使えるようにする

Virtioという仮想マシンのNICのオーバーヘッドを減らすための技術があるので、それを使えるようにします。 参考: https://qiita.com/nyamage/items/34ab6d56967c74326f99

$ lsmod | grep vhost
# なにも表示されない
$ sudo modprobe vhost_net
$ echo "vhost_net" >> /etc/modules
$ lsmod | grep vhost
vhost_net              24576  0
vhost                  45056  1 vhost_net
tap                    24576  1 vhost_net
# カーネルモジュールがロードされた

KVM関連パッケージをインストールする

$ sudo apt install qemu-kvm bridge-utils libvirt0 libcirt-bin virtinst libguestfs-tools

ネットワーク設定

VMのNICを接続するブリッジを作成します。Ubuntu18.04なので /etc/network/interfaces ではなく、netplanの設定を書きます。 手元環境だと /etc/netplan/01-netcfg.yaml を編集しました。

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces:
        - eno1
      dhcp4: no
      dhcp6: no
      addresses:
        - 192.168.10.2/24
      gateway4: 192.168.10.1
      nameservers:
        addresses:
          - 8.8.8.8
      parameters:
        stp: no
      optional: yes

今回はサーバの物理NICにルータが接続されていて、ルータがNATしてインターネットに出ていく構成のため、サーバ側ではNATをしていません。必要に応じてiptablesでNATの設定を書くなりしてください。

仮想マシンを起動してみる

Ubuntu Cloud Imageを入手する

Ubuntuマシンが起動したかったのでUbuntuを例にします。UbuntuはCloudで起動する用のマシンイメージが配布されています。ISOイメージからインストール作業をしてもいいのですが、せっかくなので配布されているQCOW2形式のイメージを使います。

$ wget https://cloud-images.ubuntu.com/releases/18.04/release/ubuntu-18.04-server-cloudimg-amd64.img -O ubuntu-18.04-server.qcow2

VM用ディスクを作成する

ダウンロードしてきたイメージファイルからそのまま起動してもいいのですが、VMを作るごとにベースイメージをコピーしないといけなくてディスク容量を無駄に消費してしまいます。QCOW2形式はCopy On Writeなイメージなので、差分ディスクが作成できます。

$ qemu-img create -b ubuntu-18.04-server.qcow2 -f qcow2 v01.qcow2 8G
Formatting 'v01.qcow2', fmt=qcow2 size=2361393152 backing_file=ubuntu-18.04-server.qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16

$ ls -lh
total 324M
-rw-rw-r-- 1 kuro kuro 324M Oct 30 01:53 ubuntu-18.04-server.qcow2
-rw-r--r-- 1 kuro kuro 193K Nov  3 15:21 v01.qcow2

v01.qcow2 は193KBしかないことがわかりますね。差分ディスクなのでOSを起動してベースイメージから差分が発生すればするほどファイルサイズが大きくなっていきます。

cloud-initのmeta-dataとuser-dataの作成

このままでもVMは起動できるのですが、Cloud Imageはcloud-initという仕組みを使って起動時にユーザアカウントなどの初期化処理が行われます。KVM単体ではcloud-initの仕組みには対応していないので、VMが起動できてもユーザ設定がされていないためログインができません。 ディスクを直接編集してrootパスワードを変更しておく方法もありますが、せっかくなのでcloud-initの仕組みを応用することにします。 ディスクを直接編集する場合はこちら: https://qiita.com/s1061123/items/fa6d54ef6705135e5969

user-dataというファイルとmeta-dataというファイルを作成します。user-dataの先頭行の#cloud-config という文字列は必須です。その2つのファイルが入ったisoイメージファイルを作成します。

$ cat user-data
#cloud-config
password: ubuntu
chpasswd: {expire: False}
ssh_pwauth: True

$ cat meta-data
instance-id: ubuntu01
local-hostname: ubuntu01
   
$ genisoimage -output userdata.iso -volid cidata -joliet -rock user-data meta-data

参考: https://access.redhat.com/ja/articles/1460743

VMの作成

起動させず、作成のみ行いたい場合は --noreboot をつけます。仮想マシンのディスクのほかにcloud-initの情報が入ったisoイメージをマウントしていてこの情報を使って初期化されます。

$ sudo virt-install --name v01 --ram 1024 --vcpus 2 --arch x86_64 --os-type linux --os-variant ubuntu16.04 --hvm --virt-type kvm --file /home/kuro/kvm/ubuntu/v01.qcow2 --cdrom /home/kuro/kvm/ubuntu/userdata.iso --boot hd --network bridge:br0 --graphics none --serial pty --console pty --autostart --noreboot
    
WARNING  CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media
    
Starting install...
Connected to domain v01
Escape character is ^]
[    0.000000] Linux version 4.15.0-38-generic (buildd@lcy01-amd64-023) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 (Ubuntu 4.15.0-38.41-generic 4.15.18)
...

VMの起動

$ sudo virsh start v01

VMのコンソールにアタッチする

正常に起動できていれば、コンソールにアタッチできているはずです。起動中であれば起動中のログが流れてきますし、そうでなければEnterキーを押せばログインプロンプトが出てくるでしょう。

$ sudo virsh console v01
Connected to domain v01
Escape character is ^]
    
Ubuntu 18.04.1 LTS ubuntu01 ttyS0
    
ubuntu01 login: ubuntu
Password:
Last login: Sat Nov  3 07:59:49 UTC 2018 on ttyS0
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-38-generic x86_64)

初めてKVMを触ったのですが、思ったより簡単でした。

情報科学若手の会に参加しました/運営をしました/幹事とは #wakate2018

第51回 情報科学若手の会に参加してきました。
そして今年は自分が情報科学若手の会の代表幹事になりました。 無事に終えることができてよかったですし、楽しかったです。
最後に若手の会の記事を書いたのは2年前かつ会社のブログだったので、今回はこっちに書いてみます。

adtech.cyberagent.io

どんなことをやったのか

情報科学若手の会はこんな会です。 https://wakate.org/about/

招待講演、若手特別講演は上記のような感じでした。

一般参加者からの発表はざっくりテーマ的にはこんな感じでした。

詳細は開催報告で書くのでそちらに…(早めにアップします。。)
twitterのハッシュタグ #wakate2018 でツイートは追えます。

twitter.com

(会社の元同期でもある)κeenの各プログラミング言語での非同期処理の表現方法についての発表は自分が業務で扱っている技術的対象でもあるので知識の整理になってよかったです。

Futureとその周辺 | κeenのHappy Hacκing Blog

早坂くんの発表はSegmentRoutingについてで、言葉は耳にしたことがあるもののどんなものなのか全く知らなかったので周辺知識と一緒に学ぶことができました。

Segment Routingの利用例と未来 - Speaker Deck

今回の開催地

加藤山崎教育基金の軽井沢研修所にて開催しました。

www.kato-karuizawa.jp

f:id:kuro_m88:20181006131120j:plain

過去6年間は伊東の山喜旅館で開催していましたが、今年は場所を変えてみました。 大研修室は広くて使いやすく、プロジェクターが最新の強いモデルになっていたのでスライドの視認性が高くてよかったです。日程がもうちょっと遅いときれいな紅葉が見られそうです。

情報科学若手の会の幹事とは

幹事を選出する基準は特に決まっていませんが、後述する情報科学若手の会の規約のとおり幹事会によって選出されます。僕は3年前の若手の会の途中に当時の幹事に呼び出されて幹事にならないかと声をかけられ今ココという感じです。 規約は3年くらい前からGitHub上で管理されていて、変更をするにはプルリクエストを投げます。イマドキですね。

github.com

最近では幹事の承認はプルリク上のapproveですし(幹事会をやっている時や意味の変更を伴わない修正は省略することもあります)、プルリクがマージされるとCIによってPDFが自動生成されます。

f:id:kuro_m88:20181009233221p:plain

幹事をやることで金銭的なメリットはないです。一般参加者と同様に参加費を支払って参加しています。そういう意味もあってタイトルには参加しましたと書きました。
幹事も一参加者なので、幹事も楽しめないといけません。幹事が事務作業に追われていて全員が発表を聴けない時もあったそうですが、改善や情報処理学会のご協力により負担が軽減され、今では全員セッションに参加できています。とはいえ幹事も一般発表したりのんびりする暇があるかというと正直厳しいところがあるので事前準備を頑張るとかしていきたいです。

なぜ幹事をやるのかは人によって違うかもしれません。少なくとも自分の場合は若手の会に参加したおかげでたくさん刺激と影響を受けたので、こういうコミュニティに貢献したいという気持ちがあるのでやっています。あと、幹事のメンバーでわいわい企画して運営するのも楽しいです。

お金のはなし

今回、参加者に情報科学若手の会の予算についてどうなっているのか聞かれることがちょくちょくあったので簡単にどうなっているのか書いてみます。
収入は参加者からの参加費と、スポンサー企業からのスポンサー費と、主催である情報処理学会のプログラミングシンポジウム委員会からの補助です。
今年の参加募集ページをご覧頂くとわかりますが、参加費は2泊3日、食費と懇親会費もろもろ込みです。安いと感じられる方が多いのではないでしょうか。学生は格安、社会人も気軽に参加できる程度を目標にしています。 開催地もその点を考慮して選んでいて、費用と環境のバランスが取れる場所を選定しています。
最終的に残った額は全額学生への交通費補助に充当しています。翌年へ予算の繰越はしていません。

情報科学若手の会はどういう会なのか

国会図書館に行って調査したのですが、第8回(43年前！)の参加報告書にはこんなことが書かれていました。

f:id:kuro_m88:20181009233238p:plain

当時は大学卒業後6年以内が若手の会の参加資格だったようです。

f:id:kuro_m88:20181009233253p:plain

今では参加資格を「若手」とあえて明確には定めておりませんが、基本的なスタンスは「学会」「研究会」としています。しかし学会ほど堅い雰囲気もなく、また情報科学という非常にざっくりしたテーマにしているので様々な分野を専門にしている人が集まります。今年は高校生が2名参加して、それぞれショートセッションで発表してくれました。 若手の会ですから、参加者が固定されてしまっては全員一緒に歳を重ねてしまい、気がついたころには若手ではなくなってしまうので常に新規の参加者を集めなければなりません。研究室選びの悩みはもちろん、情報科学若手の会で先輩に相談した結果博士課程まで進学したという人も居るわけで、そういった先輩後輩の相談の場でもあります。そういった場を提供するためには初学者の若手の会への参加ハードルを下げるような工夫や参加しやすい雰囲気づくりをしなければなりません。 一方で情報処理学会の組織の一部であり、「学会」「研究会」のような側面も持ち合わせていますから、最先端の研究の発表やそれなりの基礎知識を前提とする深い発表もされます。 必ずしも全員が理解できる内容ではなく、チュートリアル的な発表もあれば参加者の一部しか完全には理解できない発表もあります。登壇者に対して幹事から特に発表内容の技術的/知識的難易度は指定しておらず、完全にお任せしています。そのおかげで登壇者は話したいこと、参加者と議論したい内容を自由に持ち込んでもらい好きなように時間を使ってもらえているのですが、参加を迷っている人からするとそれがハードルに感じさせてしまっているかもしれません。また、初参加の方はどのような聴衆を想定すればいいのか迷うかもしれません。

ルールなく自由にするのがいい面と悪い面はあるのでここのバランスやどのような立場を取るのかは継続的に話し合っていくようにしたいですね。

これからやること

まずは会計処理等事務的な手続きをして、反省会です。今年は幹事が3人入れ替わったのと開催地を替えてみたこともあり不慣れなことが多かったです。アンケートを読み返したり振り返りをしつつ来年どうするかを幹事で話し合います。その後来年1月のプログラミングシンポジウムで開催の報告をしたら第51回は終了です。 第52回ももちろんやるつもりなので、準備は来年の春くらいからやりましょうかね。

非公式イベントではありますが、情報科学若手の会 冬の陣という1日限定イベントもここ数年は開催しているので今年もやるのかどうかこれから検討します。

wakate.connpass.com

感想とか

情報科学若手の会に初めて参加したきっかけは6年前の夏のことです。 当時は大学2年生でした。大学の授業のTAをやっていたとある先輩からメールで誘われてよくわからないまま参加する言ったのがきっかけです。

f:id:kuro_m88:20181009233349p:plain

読み返してみると思ったより軽いやりとりで、これだけの情報でどうして行こうと思ったんだろうかと思ってしまいました(笑)まぁ、先輩に誘われたからですね。この先輩はすごくて、たしか僕が初参加した年は「ひとりぼっちをなくすこと」を目標に動いていた気がします。初参加だったもので懇親会で浮き気味だったのですが、いろんな参加者を紹介して繋いでくれて、おかげでとても楽しかった記憶があります。ありがとうございます。

気がつけば4回目の参加から幹事になり、今回の7回目(2015年は海外出張が被ったのでオンラインでちょこっと顔を出しただけ)の参加にして代表幹事になってしまいました。だからといって大きく変わったこともなく、今回も楽しかったです。台風がきた時の対処を考えている時はドキドキでしたね。晴れてよかった。 伊東から軽井沢に移り、海から森にきたので緑が豊かでした。

f:id:kuro_m88:20181008131629j:plain f:id:kuro_m88:20181008130111j:plain

キノコがたくさん生えていて探すのが楽しかったです。キジが生息しているそうですが僕は出会えませんでした(´・ω・｀)

発表はどれも楽しかったし、勉強になるものばかりで発表/参加してくださった皆様には感謝です。

今年も情報科学若手の会で出会うようなすごい人達に追いつけるようにがんばろうと思ったのでした。

また来年お会いしましょう！

告知

情報科学若手の会の派生元である、情報処理学会 「第60回プログラミング・シンポジウム」が2019年1月11日〜1月13日の3日間、伊東にて開催されます。 若手の会と違い様々な年代の方が参加されますし、先生方も多くいらっしゃるので若手の会よりはアカデミック色が強めです。今年の1月のプログラミングシンポジウムに初めて参加しましたが、こちらも楽しかったです。

www.ipsj.or.jp