背景

私は2020年の10月に北陸先端科学技術大学院大学(Japan Advanced Institute of Science and Technology)先端情報科学 博士前期課程の東京社会人コースに入学しました。緒方研究室に所属しています。形式検証が主な研究テーマです。

修了するためには研究以外で20単位以上必要なので、この半年は講義の受講がメインでした。受講した講義は以下のとおりです。

  • システム最適化
  • オペレーティングシステム特論
  • データサイエンス論
  • 機械学習工学
  • 高機能コンピュータネットワーク
  • 遠隔教育システム工学
  • 人間力イノベーション論
  • 創出力イノベーション論

優が7つ、良が1つでした。良があったのはとても残念でした。自習と比べると、必死に勉強しようと自然と思える点、テストやレポートを通して理解度が明確になる点、先生から興味深い話を聞ける点が良かったです。未経験のことを短期間で習得しようとすることも楽しいです。

個人の将来的な目標は技術で未解決の問題を解決することです。人の役に立ち、かつ普遍的な知見となるようなことを目指したいです。博士前期課程では研究をとおして専門性を深めていくための準備をしたいと考えていたので、まだやりたいことはできていません。

よくある質問

いつ勉強していますか?

平日の朝と夜、休日です。

仕事と大学院を両立するのは大変ですか?

まだ、それほど大変だとは感じていません。自分の意志で自由に使える時間が多いことが関係していると思います。ただ、大学院で勉強や研究をしている状態と大学院に入学せず、何もしない状態を比較すれば、前者はやることが単純に増えているので、より大変だと言えるでしょう。また、どれだけ成果を出したいかは人それぞれですし、同様の事象に直面した際に大変だと捉えるかどうかも人それぞれです。

大学は文系学部だったのに、数学は大丈夫ですか?

今のところは大丈夫です。理解できていない箇所を明確にして、予め自習していたからです。ただ、ユーザーとして数学を使っているだけなので、数学自体を研究対象にするレベルのことはわかりません。

In Maude, a module can be imported as a submodule of another in three different modes: protecting, extending, including. This is done with the syntax declarations

protecting ⟨ModuleExpression⟩ . 
extending ⟨ModuleExpression⟩ .
including ⟨ModuleExpression⟩ .

which can be abbreviated, respectively, to

pr ⟨ModuleExpression⟩ . 
ex ⟨ModuleExpression⟩ .
inc ⟨ModuleExpression⟩ .

The different modes of importation can be understood as promises by the user, which would need to be proved by him/herself. Before explaining each difference, I clarify no junk and no confusion. No junk is that extra values should not be added. No confusion is that different values should not be made equal.

The different modes of importation is as follows:

  • protecting mode shows no junk and no confusion.
  • extending mode is to allow junk, but to rule out confusion.
  • including mode is to allow junk and/or confusion.

References

誰?

  • 大学では経済学を専攻していたが、大学院では情報科学の分野で研究をしたい人
  • 社会人
  • プログラミング歴は約5年

受験の流れ

2020-04-19

2020–04–22

2020–04–27

2020–04–28

2020–04–29

2020–05–02

2020–05–03

2020–05–16

2020–05–22

2020–06

2020–07–08

2020–07–19

2020–08–06

2020–08–21

2020–08–22

2020–08–29

その他

  • COVID-19のため出願期間と入試の日程が一度延期になった。
  • 課題は関数型プログラミングと証明に関する内容だった。関数型プログラミング言語を用いて簡単な関数型プログラミング言語を実装した経験、数理論理学の基礎的な内容が書かれた本を読んだ経験、高校数学の知見などが役立ったと思う。
  • 私が学部で文系科目専攻だったことが関係するのか(?)、面接では情報科学や数学に関する基礎的な質問があった。こちらも趣味で色々やっていたことが役立ったと思う。

RustでBFSを練習するために、AtCoder AGC 033 A — Darker and Darker を解きました。

問題概要

解法

コードは以下のような感じで書きました。入力のマクロに関してはhttps://qiita.com/tanakh/items/0ba42c7ca36cd29d0ac8 を参照ください。

In Layered Architecture (e.g., Clean Architecture, or Hexagonal architecture), the key idea is to use the dependency inversion principle. This blog post provides the dependency inversion principle in Rust, skipping the details of Layered Architecture.

The sample in this blog post is a news app which gets news asynchronously. I…

まず、Berkeley Packet FilterとBPF Compiler Collectionについて簡単に説明していきます。(以下ではそれぞれをBPFとBCCと略します。)

BPFとは

BCCとは

BCCを使用しない場合、BPFアセンブラを直接書いたり、ClangでC言語をBPFにコンパイルしたりすることでBPFを利用できます。(LLVM 3.7からLLVMのバックエンドにBPFが追加されています。)

トレース

https://github.com/iovisor/bcc

今回はすでに用意されているbpf/tools/tcptracer.py を利用して、TCPのコネクションをトレースしていきます。以下のようにPythonのファイルを実行します。(-t はタイムスタンプを表示するためのオプションです。)

$ sudo ./tcptracer.py -t
Tracing TCP established connections. Ctrl-C to end.
TIME(s) T PID COMM IP SADDR DADDR SPORT DPORT
0.000 C 7672 curl 4 127.0.0.1 127.0.0.1 59394 16004
0.006 X 7672 curl 4 127.0.0.1 127.0.0.1 59394 16004
0.006 X 7405 http-nio-16004- 6 [::] [0:ffff:7f00:1::] 0 65535
2.061 C 7682 curl 4 10.202.210.1 172.217.161.68 60036 443
2.177 X 7682 curl 4 10.202.210.1 172.217.161.68 60036 443
2.948 A 9565 java 4 127.0.0.1 127.0.0.1 42641 55980

プロセスごとのTCPコネクションの状態を確認することができました。T列のC,A,Xはそれぞれはシステムコールのconnect(), accept(), close()を示しています。

まとめ

参考

Backends For Frontendsの概要

API Gateway

  • リクエストのルーティング
  • APIコンポジション(バックエンドのAPIを複数呼び出して、その結果を集約する)
  • プロトコルの変換
  • 認証・認可
  • リクエストの制限
  • キャッシュ
  • メトリックの収集
  • リクエストログの出力

かなり多くの役割がありますが、これらすべてを1つのサーバで実装するという訳ではありません。認証・認可を共通基盤として切り出したり、リクエストのルーティングはクラウドサービスのロードバランサを使用したりすることがあると思います。API Gatewayはクライアントとバックエンドのマイクロサービスの間に存在するレイヤだと考えた方がよいでしょう。

API Gatewayが存在しない場合、問題がいくつか発生します。主な問題はパフォーマンスの低下でしょう。クライアントがAPIコンポジションを行う場合、大量のリクエストがインターネットを経由することになります。LANとモバイルネットワークでは100倍ほどの差があると考えられます。クライアントが並列にリクエストすればよいという考えもあるかもしれませんが、モダンなブラウザでもTCP同時接続数は6なので、HTTP/1.1での通信だと並列にリクエストしてもパフォーマンスの改善が難しいケースがあります。また、API Gatewayが存在しないのであれば、クライアントがバックエンドのサービスそれぞれの位置を知る必要があります。そのため、クライアントはService Discoveryし、その後で必要なデータ取得のためのリクエストをすることになります。

BFFの文脈だと、API Gatewayの役割の中で焦点が当たるのは主にAPIコンポジションだと思います。BFFが返すべきAPIコンポジションの結果はクライアントごとに大きく異なるからです。次はBFFがどのような考えに基づいて開発されたのかについて説明します。

BFFの歴史的背景

SoundCloud社の事例の詳細は Phil Calçadoの”The Back-end for Front-end Pattern (BFF)”という記事を参照ください。

BFFのメリット

BFFのデメリット

APIコンポジションを実装する上の注意点

また、一部のレスポンスが長時間返ってこないケースや、リトライしても一部のリクエストが失敗するケースを考慮する必要があります。「マイクロサービスAがn秒以内にレスポンスを返さなかったら、マイクロサービスA以外のレスポンスを組み合わせてクライアントに返す」などの仕様を決めておくとよいでしょう。このようなケースを考慮すべきなのはBFFに限った話ではありませんが、BFFはよりクライアントに近いので考慮が漏れた際、ユーザに直接的な影響をもたらしてしまいます。

参考

Takanori Ishibashi

Software engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store