研究室に配属される前に知りたかった研究の流れ

雑記

こんにちは。名取さなさん10万FANS+おめでとうございます。大学まで片道2時間掛かる生活に嫌気が差したので、家に籠もってはたまに大学に行く生活をしています。睡眠が取れているのが何よりの救いです。

さて、大学は研究機関だと言われていますが、研究って具体的になにやるの? と思っていた3年間が終わり、4年目に突入して半年が経ちました。

半年も経つと秋になり、未来の後輩が研究室を決めるために見学や面談に来ているのを観測しています。

自分がその立場にいたとき、自分は研究をどういった流れで何をやるものなのか全く分かっていませんでした。
今もそんなに理解していない気はしますが、少なくとも今ぐらいの認識を研究室配属前に知りたかったな、というのは思っているので、転生したときのためのマニュアルとして少しまとめてみます。

そもそも研究のやり方とか認識とか、研究成果の扱いみたいなのは学問によってどうやら違うらしいのでとりあえず情報科学、とりわけコンピュータサイエンスの近くをやっている人間として書いています。
ちなみに成果は今のところほぼ無で、はじめての学会だね、と言われながら国際学会だし九州だしでよくわからない緊張に押しつぶされて寝込みつつもなんとか学生研究発表で入賞して、あと自腹で別府温泉に入りました。別府八湯温泉道初段程度の実力です。

read more »

tmux でも Touch ID で sudo を使う

Software お役立ち情報

Touch ID が搭載された MacBook Air を買いました。MacBook Air に欲しかった機能の8つ中8つが実現されたので買いました。1つ10点としたら10^8 で1億点だね、という話をしたら首を傾げられました。

Touch ID が sudo でもパスワードを入力する代わりに使えそうだな、と思ったので調べてみたらどうやら pam_tid.so という PAMモジュールが用意されており、コンフィグを弄ることで使えるようです。具体的には /etc/pam.d/sudoauth sufficient pam_tid.so を追記するだけです。簡単ですね。

しかし、tmux のようなターミナルマルチプレクサを使用している場合にはこれだけではうまく動作せず、sudoコマンドを用いても普通にパスワードを求められてしまいます。
(これは各ユーザごとに存在する bootstrap namespace に tmux が存在しないこと? が原因のようです。詳しくは当該リポジトリに説明と詳細へのリンクがあります。)

これに対処するために pam_reattach という PAMモジュールを書いた人がいて、これが使えます。

fabianishere/pam_reattach: A pluggable authentication module that reattaches to the user’s GUI (Aqua) session on macOS

参考にした元の記事やこのリポジトリの README.md には何事もなく以下のようにやれば入ると書いてありますが、これは失敗します。

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr
$ make
$ sudo make install

これは最近の macOS の保護機能の1つである System Integrity Protection が有効になっているためで、rootであっても / 配下のほとんどが書き込み不可能になっています。つまり /usr/lib/pam にビルドされた pam_reattach.so をコピーすることができず失敗します。
多分これを開発するような人は無効にしてるんじゃないでしょうか……

実は/usr/lib/pam/usr/local/lib/pamで代替できます。というわけでそうします。具体的には以下のように PREFIX を変えるだけです。

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local
$ make
$ sudo make install

それではよい tmux life をお過ごしください。

2018年10月あたりの今日このごろ

未分類 雑記

こんばんは。もうすぐ冬ですね。10月あたり、というタイトルで10月31日の深夜にこの記事を書いてますが10月が終わるのとこの記事を公開するのはどちらが早いでしょうか。

最近は時間的割合では主に研究をやっているのですが、それ以外でも色々あり、ちょっと精神面で弱っているなと思っていて、方々にご迷惑を掛けてしまっているなと思っています。
この記事を書いている時点で実際なんらかのしきい値を超えたのでは、と自分で思っていますが、どうでしょうね。

read more »

第51回 情報科学若手の会に参加しました

雑記

こんにちは。きょんたんです。最近は「いいえ」というのが流行っています。いいえ。

情報科学若手の会という情報科学オールジャンル若手オンリーイベントに参加しました。でも最近は若手オンリーじゃないみたいです。
前回が初参加で、初参加なのに突然肩を叩かれて幹事になったので今回は幹事としての初参加になります。

ちなみに幹事ってなんだよみたいな話とか私が気になるお金とかの話とかもろもろは代表幹事のkurochanさんが書いていますので興味がある方はご参照ください

発表のテーマとしては毎回様々あるのですが、なぜか近いテーマを複数人が発表するという事象があり、前回はブロックチェーンで今回は機械学習とかプログラミング言語といったテーマがそれに当てはまっていた気がします。

個人的に一番分かりが多かったのは Segment Routing の話で、なるほど経由地を含めた経路のルーティングとかができて便利そうみたいな気持ちになりました。OpenFlow とかでもできそうですが、ラベルスタックで表現するとハードウェア実装のスイッチとかで高速に実装できて良さそうだなって思いました。

コンテナデータセンターの話は個人的に一番聞きたかった話で、法的な側面でどういった解釈をしてどのように実現するのか、という話やコンテナの魅力が延々と伝わって来て面白いなと思って聞いていました。狭い部屋が好きなのでコンテナを自宅に改造して住みつつ隣のコンテナをデータセンターにしたいですね。

生物から学ぶ深層学習という話は深層学習概論みたいなところがあり、どういった歴史背景でどのように深層学習というものが生まれ、アカデミアとしてはその研究がどのように進んでいて、進んでいくのかというところの傾向が分かって面白かったです。
その次のPFNでの深層学習の話は色々なネットワークの紹介なんかがあり、例えばGANに関する説明なんかは腑に落ちるところがありました。
GANで作られた画像とかはTwitterとかで見ることがしばしばあったのでGはGenarativeのGかな〜ぐらいの認識をしていたのですが、あれは敵対的ネットワークというものでノイズを基になんらかの解釈ができるような(それらしさを持つよう)に延々と学習するんだな、みたいな説明があってとても納得しました。分かってきた。

どの発表も難易度がそこそこ高かったなと思いつつ割と個人的には適度な難しさだったなとは思うんですが、それはたまたま自分が知っている知識がそのあたりに偏在していたからだと思っていて、一般的にみるとそこそこ難易度が高めな発表が多かったのでは、と思っています。
前回は割とテーマ的に自分が知っているところと被らないテーマが多かった気がした(うろ覚え)ので、このあたりは難しいですね。

会場的な話としては、前回は伊東の山喜旅館だったのですが今回の会場は軽井沢の軽井沢研修所というところでした。軽井沢研修所、温泉がない以外は個人的には一万点みたいなところがあり、過ごしやすくて良かったです。ちなみに散歩したところ裏で温泉を掘っていたので来年も軽井沢だったら温泉に入れると良いなって思ってます。
温泉の問題は個人的にはあまり問題視していなくて、それはなぜなら帰りに温泉に行ったからです。軽井沢はそれ自体が温泉地で例えば星野リゾートの発祥地である星野温泉(トンボの湯)というのがありますが、そこから山を越えると草津温泉や万座温泉、鹿沢温泉などがあり、最強の温泉地帯が広がっているわけです。このエントリで書く内容ではないので割愛しますが万座温泉は青白色のにごり湯で最高でした。

幹事として何をしていたかというと概ね無なので来年はもう少しがんばります。 :innocent:

ISUCON8 予選に参加して再起動試験に落ちました

Infrastructure Programming

おはようございます。名取さなにハマっている kyontan です。

最終スコア

チーム「hhkb」で同期3人 (自分 @kyontan, @hogashi, @h-otter) 2回目の参加で2日目で Go 実装でした。学生枠突破ならずでした、悔しい。というよりは 55,982点で全体4位の点数で落ちました。ちなみに hhkb は h-otter, hogashi, kyontan, :boom: ???? の略です。
スキルセット的には、 @h-otter がインフラ(ミドルウェア含)なんでもできる+Goの経験が一番あるマンで、 @hogashi がアプリケーションなんでもできるマンで、 @kyontan はアプリとインフラとDBを一通り見られるマンみたいな感じでした。

今回は真面目に本戦に行きたかったので前々日に ConoHa で ISUCON7 の予選を解き直して練習しました。具体的には ConoHa の練習用イメージを使って 1GBプラン x3台で予選環境を再現しました。結果、10時間程度で 5,204点から509,190点まで持っていけることが分かり、計測と試行の反復を効率的に行えば ISUCON の予選は突破できるという確信を深めていました。
また、前回は最後の最後でベンチマーカを走行させた結果点数が下がって落ちたので、前回の直後に「泣きの1回はやらない」というスローガンを掲げ、1年越しでそれを達成しました。

ベンチマークの初回走行の結果しばらく1位になった

事前に準備したのは Prometheus のサーバ (@h-otter がいい感じにやってくれた)と、やること/できることチェックリストぐらいでしょうか。だいたい大会では開始した瞬間にテンパってそのまま撃沈するのが常なので、思考停止状態でもコピペで動くようなコード片とかを用意しておくと便利ですね。あとは思考が無になったときに確認するべき事項とかを作っておくと良いのではないでしょうか? 頻繁に無になって帰りたくなりました。メンタルは大事。

例えば下のような感じです。

当日は3人がローカルで開発し、本番環境のVMへバイナリを転送して検証する、という進め方でやっていました。Go はクロスプラットフォームでのビルドがしやすいのが便利ですね。

具体的にやったことを羅列します。というか @h-otter が書いていたのを未承諾引用します。順番は適当

  • SELECT * する系のクエリを必要な列しか取らないようにした
  • /api/usersuser_idreservations を全部とってきて、アプリ側で処理してやったらめっちゃ速くなった
    • ここでベンチマーカが重いと言ってくるエンドポイントが /users/:id から /api/events/:id/actions/reserve になった
  • getEventgetEventWithoutDetail と分けた
  • getEventgetEvents を2クエリに
  • sheets へのクエリを消す
    • 効果があったのかは良くわからない
  • MariaDB のチューニング
  • Prometheus と Grafana で可視化
  • ログインのクエリを1つに
  • パスワードを平文で突っ込むようにした
  • DB にインデックス張った (けどあまり良い結果がでなくてもんにょりした)
    • 最初に mysql コマンドでインデックス張ったけど結果が全く変わらなくて、なぜ? と思ったら毎回 /initialize でテーブルを作り直していることに気がついた。
  • IN句を使いたかったので DBにアクセスするライブラリを sqlx に切り替えた
  • トランザクションの開始がおかしいところがあったので直したり デッドロック時にエラーを返さずリトライするようにした

最後は予約時のシート決定を高速化するコードが安定化しなくて入らなかったり、Redisでいい感じにやろうぜみたいなことを思うだけ思ってやらなかったりしました。多分ここができると数万点上がったはず。

あとはスコアに関係ないけど作業便利になる系として、 エラーログでソースコードの行番号を吐くようにしたり、 Makefile 弄って1コマンドでデプロイできるようにしました。
開発は3台のサーバでバラバラにやっていましたがDBは1台だけを参照するようにしました。これはDBのチューニングとかがあって、1台でやった変更を他に反映したりするのが面倒くさかったので。こうすると、やりたい人間が適当にベンチマーク対象のサーバを変更して実行してやればいいので楽でした。

ソースコードは GitHub で管理し、いい感じにやりました。コミットログは下の通りです。

数字がタグに付いていることがありますが、これはいいスコアが出た時にバイナリごとコミットしてタグつけておこうぜ、みたいな感じにした結果でした。

今回の僕の活躍はよく分からなくて、いい感じデバッグ担当だった気がします。PRを見るなりとりあえずマージしてベンチマーカを落としたりバグ探しをしていたりしました。とにかく @h-otter がぶち壊しつつ @hogashi がいい感じに安定化するコードを書いてくれてよかった感がある。

Webサーバはh2oで十分高速だし、画像のトラフィック詰まりもないしで、とにかくアプリケーションコードの改善に注力した/するしかなかった8時間でした。

最終的に残り30分でベンチマーカを叩いたところ3万点前後のスコアが5万点に若干跳ねてそこで打ち止め。一度再起動をしてブラウザからアクセスできることを確認し天命を待ったところ、無事再起動試験で落ち失格となりました。天命……

(追記: スコアが跳ねたのは、最後に実行先サーバを変えた時に インデックスを張る処理を init.sh に書いたサーバで実行したからかもしれないことを思い出した。)

なぜ失格になったのかは分かっていなくて、おそらく /admin/api/reports/events/:id/sales の処理が遅くて不整合が起きて落ちたのかなあなどと思っていますが、2回連続で落ちるのは運が悪かったなと……

なんやかんやでやることがなくならない8時間で、やることが見つからない8時間よりは良かったのではないかと思います。

イキっているなどと言われてもこれは事実だと信じていて、典型的な N+1 を潰すなどすれば予選は通過できるはずなことは分かりましたね。くぅ〜〜

来年はちゃんと本選に行けたらいいですね。頑張りましょう。

そして、参加会場を提供していただいた mixi 様、惜敗の悔しさを教えてくれる最高のコンテストを運営をしていただいたISUCONの運営の皆様、お疲れ様でした、ありがとうございました!

以下は画像です