2021年振り返り

すでに年が明けてしまったが、ITエンジニア界では年の暮れに1年を振り返る風習があるようなので、私も見習って書いてみることにする。(趣味/業務関係なく、技術サイドから。手を動かす系はだいたい趣味としてやっている)

(↓長くなったので目次)

仮想ルータ

1月はFRRouting, Eve-NG, CML Sandboxなどを使って仮想ルータをいじっていた。

一応ネットワーク関連の仕事をしているはずなのに、どちらかというとサーバ系/管理システム系の仕事がメインで、ネットワーク装置に触れることなくここまで来てしまった、という危機感から、できるだけお手軽にルータ/スイッチを触って手を動かしながら勉強できる環境を探してきた。2020年はCisco Packet Tracer等を試していたが、MPLSまではできないことがわかっていたため、こちらの記事を参考に、FRRouting+Linuxでできそうだったのでやってみることにした。(今思うと、Eve-NGやCMLの方が簡単だったと思うが、いろいろ勉強にはなった)

なぜMPLSかというと、

  • 諸事情によりSegment Routingをちゃんと知っておく必要がありそうだったが、その前段となるキャリアネットワークの基礎技術として必須だと思った。またMPLS-(L3)VPNに関しては、IGP(OSPF), VRF, EGP(BGP)等、色々な技術の集合体なので、ひととおり勉強できそうだと思った。
  • 諸事情により「リソース管理」というキーワードについて考えており、ネットワークリソースと呼ばれているものの実体や、既存技術としての(L2/L3)VPNサービスで、リソースの管理(帯域制御、予約等)が(管理システムの下のレイヤで)どのように実現されているかに興味があった。

Linux+Docker+FRRoutingに関しては、当初DockerにFRRoutingを入れて、docker networkで複数コンテナをつないでいけば簡単なのでは？と思っていたのだが、docker networkのしくみを使った場合、IPアドレスやデフォルトルートが自動設定される機能があり、一筋縄ではいかなかった。

ただし、ここで1つ問題があります。Docker Networkを使ったネットワーク作成はお手軽なのですが、コンテナをつないだ際、IPアドレスが自動で設定されます。(もしくは--ipオプションで手動指定)。こうして自動もしくは手動でコンテナkernelによって設定されたIPアドレスは、FRRoutingを使って変更・削除することはできません。また、デフォルトルートを含む複数のルートも自動で設定されてしまい、FRRoutingからは変更・削除できません(かつ、Kernel Routeは最優先)

なので純粋にルータを勉強したい(かつお手軽に)場合は、Packet Tracer、GNS3/Eve-NG、CML等を使った方がよいと思われる。ただdocker networkの勉強にはなったし、この過程でtwitterでslankdevさんにいろいろ教えてもらったりする経験ができたのはとても良かった。本当にありがとうございます。自分もいつかFRRoutingでプロトコル実装したりしてcontributeできるようになりたい。

その後はEve-NGでMPLS-TEの設定をしてみたり、Fast Reroute, Path Protectionを試したりして、RSVP-TEによる帯域予約のしくみをなんとなく理解した。SRに関しても、CML Sandboxで基本的な構成を試す所までやったが、他に優先事項ができてしまい、さらに深堀まではできなかったので、今後の課題。

なお、この一連のネットワークネタについて、社内の若手中心の勉強会で発表し啓蒙活動(?)も行った。実際にやってみようと思った人がどれだけいるかわからないけど、少しでも興味を持ってくれる人が増えることを願っている。

Schema Matching

古からの技術であるSchema Matchingの調査をしていた。半分苦し紛れではあったが、有名な論文で提案されている手法の一部をpythonで実装して評価し、研究会や国際学会(のLT的な枠)のネタにはなった。

python実装の1つ、flexmatcherを試した時の記録

Terraform/Stackstorm

TerraformやStackstormの内部構造について調査をしていた。特にTerraformのProviderまわりについては、コードレベルで理解できた気がする。

その他、何かとTerraformにはお世話になった1年だった。

機械学習/深層学習/自然言語処理

個人的にはAIより仮想化とかミドルウェアとかインフラ系の技術の方が多少馴染みがあるのだが、今後避けては通れないだろうし直近でも必要になりそうだったので、GWに有名なNLP本を買ってひととおり手を動かしてみた。

今までほぼブラックボックスとして使っていたWord2Vecのしくみや、RNN, LSTM, Seq2seq, Attentionのアイデアについて理解できた(気になる)良い本だった。

あとはPyTorch, BERT関連で以下のUdemyもやった。

お仕事の方では、インターンのテーマ設定とサポートをやっていた。ざっくり言うとTerraform×機械学習/深層学習といったテーマで、Amazon Sagemakerを使って色々試行錯誤してもらった。Sagemakerのお作法に慣れる必要があり、(今までGoogle Colab等で自前で全て書いていた所からすると)少し学習コストが高く、今回のようなアドホックな研究用途には余り適していなかったかもしれないが、AutoML機能等は便利に使えたのかなと思う。特にビジネスの現場において最速でAIを適用していくために、よくデザインされたフレームワークだと感じた。

Go言語と静的解析

上記のTerraform×機械学習/深層学習をやるにあたって、学習データを作成する必要があった。既存の学習データはなく、その元となる情報はTerraform provider (AWS) の中にしかない状況。しかも単純なgrep等では抽出できず、変数の定義を辿っていくような深い解析が必要。

静的解析をはじめよう - Gopherをさがせ！

そこで静的解析。上記サイトと本を参考に、terraform-provider-awsを静的解析して学習データを作成するコードを書いた。2週間ぐらい？かかった気がするが、何とか間に合わせることができた。(上記サイトと本が非常に役立ちました。ありがとうございます。)

コードについては、競プロ的に言うとメモ化再帰を駆使した1300行ぐらいのもの。ASTをダンプしたものを見つつ、再帰とtype switchとの戦い。でもこういった静的解析をサクッと書けるようになると、プロジェクトに特化して痒いところに手が届くソースコードチェックができて便利ですね。

TCP

理由は分からないが、リソースの限界とかトレードオフとかボトルネックとかそういうのが好きなようで、いろんなリソース限界を発生させたり可視化したりするシリーズをやりたいと思っている。何を言っているかわからないかもしれないが、例えばこういうやつ。

inode (アイノード) を枯渇させてみる - CUBE SUGAR CONTAINER

システム内のいろいろなリソース(資源)に着目し、その限界を知ることでそのシステムのしくみや特性を理解する、というアプローチは教育コンテンツ的な観点でも面白いのではないだろうか。

まずは基本的な所からということで、

第1回 FTPでスループット計測するときの注意事項：教科書には載っていない ネットワークエンジニアの実践技術｜gihyo.jp … 技術評論社

帯域と遅延、TCPウィンドウサイズの関係について。AWSのいろんなリージョンにiperfのサーバを置いて実測などしていた(純粋に測りたかったらtc等で遅延を挿入した方がよいと思うが、リアル環境でどうなるかやってみたかった)。最初Windowsのiperfクライアントで計測していた時に、受信側の挙動がちょっと思ったのと違う結果だったので、rfc1122を読んでみたり、tcpのソースコードを読んでみたり、wiresharkのソースコードを読んでみたりしていた。

当初はブログかQiita等にまとめようと思っていたが、最終的にLinuxのiperfクライアントでやったら普通に思った通りの結果になったので、急に自明に思えてしまって頓挫中。もう少し面白い感じにして何かしらアウトプットできるようにしたい。

マイクロサービス

テトリスを無駄にマイクロサービスにしたら面白いのでは？と急に思い立って作り始めた。

正確に言うと急にではなく、以下のような思惑があった。

  1. 普通分割しないようなものを分割するとどこかで性能限界が来るはずで、それを目の当たりにしたい(リソース限界的な興味)
  2. マイクロサービス(アーキテクチャのシステム)を作る人向けのフレームワークについて考えており、フレームワーク側にどのような機能があると嬉しいのか、イメージを掴みたい。

とりあえずゲームの基本部分を4つのサービスに分けて作ったのだが、

GitHub - tkna/tetris_microservices: How far can Tetris be microservices?

  • 1については、理論的にはメソッド単位、もしくはさらに細かく変数単位にして、変数(メモリ)を各マイクロサービスのデータベースと考える、ということができることに気付いてしまった(やろうと思えばできるけどめちゃくちゃ面倒くさい)。
  • 2について考えるのであれば、1のように1つのゲームを細かく分けて作るようなことは非現実的なので、どちらかというとゲーム以外にユーザ登録サービスとかハイスコアサービスとかを作って普通にオンラインゲームのサービスとして作った方が良さそう。

という割と普通のことに気付いてしまい、頓挫ペンディング中。静的解析で無駄に自動分割してくれる、とか、無駄に分割したサービスをAWS Step Functionsとlambdaで実装する、とか、無駄にKubernetes Operatorとして実装してみる、とかも考えていたが、実用性がなさそうなので現実路線の方で行くかもしれない。

競プロ

11月ぐらいから競プロも始めてみた。まだ全然できなくて恥ずかしいのだが、計算量について考えるよい機会になっている。(メモ化再帰と尺取り法は書けるようになった...)。プログラミングはどちらかというと自分の作りたいものをマイペースに作る方が好きだったのだが(というほど何かを作っているわけではない)、これはこれで面白いですね。何となく受験勉強を思い出す。色々問題を解いて解法のパターンを知れば知るほど強くなれる(少なくとも私のような初心者レベルでは)、その結果がすぐ数字で見れる、という点で。

まとめ

2021年も色々と自分が知らなかった分野に(無謀にも)踏み込むことができた(広く浅くやり過ぎて何がやりたいのかわからない感じになっている気もする...) 今年はもうちょっとまとまったアウトプットとして出せるようにしたい。あと本当はより現場に近い所でリアルなソフトウェアエンジニアリングをしていきたいという気持ちがあるので、現場で通用するエンジニアリング力(＋テックリード力？)の方も引き続き高めていきたい。

その他

  • OpenDayLight

ORM, Swagger/OpenAPI, YANGあたりに興味があり、OpenDayLightを動かしてみようと思ったが失敗

OpenDaylight(Oxygen)でFeature間のコンフリクト？ -

  • 暗渠

運動不足解消のために散歩を始めた結果、街中に怪しげな小径があることに気付き、それが暗渠と呼ばれる川の跡であることを知り、東京の地形と川と暗渠の沼に片足を踏み入れることになった。