2020 年を振り返る
2020 年は例年と大きく違う年でした。生活スタイルが変わったことは今年の最も大きな特徴でしょう。ミーティングや学会などの仕事を進めるためのイベントだけでなく、勉強会や会食、飲み会などの仕事以外のオンライン化は身近で感じた一番大きな変化だったように思います。
2020 年は実にアグレッシブな開始となりました。
私、魔女のキキ!
— k5342 (@k5342) 2019年12月31日
あっちは新年早々初詣先でインロックされた私の鍵! pic.twitter.com/EkJxx3QdnO
研究
研究では初めて国際学会で Accept を貰えたのがビッグイベントです。当該ペーパーは厳しいコメントとともに Reject され続けていたのですがブラッシュアップを重ねてようやく公開できました。例えば最初から落とそうとして批判的な立場のレビュワーに当たることもありますし、スコープが伝わってない場合もありました。落ち続けるレビューについて指導教員氏はずっと支えてくださいました。結果的に良い結果にできてよかったです。同じ内容でも表現や切り口が重要なのだと思いました。特にディスカッションをしっかりと書くことを意識しました。あと性能評価を取るときは結果のブレークダウンなど、ディスカッションのための材料を提供することはめちゃくちゃ大事だなと思いました。
こんな感じの論文にならないようにしたい。
ISUCON
ISUCON 楽しかったです。 k5342.hatenablog.com
来年はより良い結果を残したい。チーム「いすこんがさき、しゅうろんはあと」でISUCON10本戦に出場し、「またあいま賞」を受賞したk5342 @k5342 さん。当日の流れを振り返りながら、反省点や学びをブログにまとめています。#isuconhttps://t.co/DXwaMj9jHO
— はてなブログ|思いは言葉に。 (@hatenablog) 2020年10月6日
Discord
今年はオンライン関係で Discord にお世話になりっぱなしでした。これまでずっと使ってきたこともあって Nitro 契約しました。
Bot も作ってるのですが、2 年前に GitHub で公開した Discord Bot がいつのまにか 100 サーバ以上に導入されていた。この Bot に関しては GitHub の README 以外にはどこにも情報を書いてないんですが、いつの間にか発見されるものなんですね。。ちなみに Discord は 100 サーバを超えると Verification できるようで、プロセスをこなすとバッジが貰えた。嬉しい
Verified Bot Developer バッジをもらった pic.twitter.com/rHon2u3NZO
— k5342 (@k5342) 2020年5月11日
GitHub
その他
今年買って良かったもの
- Aterm WG1200HP4 (無線 LAN ルータ) ... Wi-Fi 5 対応 2x2 アンテナなルータ。エンタプライズなものほど多機能じゃないし VLAN なども使えないけど、WPA3 対応など比較的新しい機能が沢山載ってる。で、安い。コスパいいと思う。管理画面がモダンでいい感じ。10 年ほど使い続けてきた Airmac Express は退役となりました。
- Among Us ... パーティーゲームとしてよき
- 桃鉄 ... 人間の勝利に対する貪欲さ・心理戦を垣間見れる神ゲー。今作からオンラインに対応したのでリアルファイトが減少した点◎ 6000円払ってすごろくする価値がある。
来年
- 修論を書いています。卒業できるように頑張ります
- いろいろ終わればどこか旅行に行きたいですね
ISUCON 10 本戦に参加しました
ISUCON 10 の予選・本戦に「いすこんがさき、しゅうろんはあと」で @chigichan24 と @Pelkira と参加しました。結果は予選が総合 107 位 (学生枠 4 位で本戦出場)、本戦 18 位 (またあいま賞) でした。
スコアは予選が 1,301 点、本戦が 11,000 点ほどでした。 この記事では本戦問題の回答解説にあまり触れられていません。スコアが跳ねた回答を期待される方は他の方の記事や講評を参照してください。。
言語は今年から Golang に変更しました。我々のチームが本戦の時間内でやった内容は以下です
- 計測の効率化 (半自動化, 結果は自動的に Discord にポスト)
- AudienceService ListTeams の N+1 修正
- 不足した index の追加
- contestants.team_id
- teams.withdrawn, created_at DESC
- score_raw, score_deduction
- benchmark_jobs.team_id
- notifications.contestant_id, read
- TeamCapacity = 60
- 「あるべき通知を受信していないことが検知されました」の修正 (不発)
- makeLeaderboardPB のキャッシュ (不発)
また、我々のチームの予選時の内容は @chigichan24 の記事が本質情報なのでこちらを参照してください。 chigichan24.hatenablog.com
続きを読む2019 年を振り返る
2019 年を振り返る.今年は大学院の授業も始まり,B4 のときよりも時間の使い方が難しかった.
2 月.学部の卒論を提出&発表会がありました. 3 月.研究室に配属されて最初の論文発表をしました. 4 月.修士課程に進学しました.論文をサブミットしました. 5 月. 6 月.論文をサブミットしました. 7 月. 8 月.6 月に出した論文の結果が返ってきて,修正の上,再提出となりました. 9 月.論文を修正してサブミットしました. 10 月. 11 月.SC19 に参加してきました. 12 月.論文をサブミットしました.
論文について.論文は同じ研究プロジェクトを三度切り口を変えて (あるいは表現を改善して) 提出しました.やってることは同じですが表現ひとつで印象ががらっと変わるのが面白いところです.文章を書いていて思ったことはいくつかあります.
- 命名は大事です.自分のアイデアに名前をつけるとこれから述べる事象が読み手にとって新しい概念であることを暗に示せます.また書き手にとっても事象の説明を用語の導入として済ませることができるので情報を整理しやすいです.以下は例です.どっちが分かりやすいでしょうか.
- サーモンランのラッシュイベントでイクラを納品する場合,ヒカリバエが付いたイカは壁にはりつきながら左右に移動することでシャケを無力化できるのでウェーブの成功率が上がる.
- サーモンランのラッシュイベントでイクラを納品する場合,セミと呼ばれるテクニックを使うと良い.セミは壁に貼り付きながら左右に移動する行為であり,シャケを無力化できるのでウェーブの成功率が上がる.
ところで去年のブログを見てみましょう
2018 年を振り返る.いままでこういうブログ書いたことなかったけど今年はやってみる. 継続的にアウトプットすることが大切だと思うので,こういうタイミング以外にも記事を書く頻度を高くしていきたいですね.
2020-12-31: 下書きに塩漬けされてたので公開
2018 年を振り返る
2018 年を振り返る.いままでこういうブログ書いたことなかったけど今年はやってみる. 継続的にアウトプットすることが大切だと思うので,こういうタイミング以外にも記事を書く頻度を高くしていきたいですね.
今年は大学生活では院試や研究室への配属といった B4 的なイベントがあったのと,課外活動のほうでも長期インターンといった比較的大きめのイベントに参加していました.昨年よりは学外活動を増やせたように思います.
一方で趣味の時間,OSS 活動や自己研磨 (?) に充てた時間は?と訊かれると,考え事をするかキーボードを叩く時間以外は全てスプラトゥーンに吸われていた気がしています.どれくらいのプレイ時間かというと通常使用で Pro コンを 2 台破壊した程度*1ですね.あのゲーム楽しすぎるんですよ.そんでもって「お前のウデマエはどうなのよ?」と聞かれると今年の成果は S+4 です (◞‸◟)...と,時間をかけた割にはウデマエ X に到達してなくてなんともいえない気持ちになります.それでもまあ昨年と比較すれば S+ の維持は安定してできるようにはなっていて,ガチアサリを含めた全ルールで S 落ちすることはなくなったのでこれもまた少し進歩したといういい感じの解釈をしておきましょう.
月ごとで振り返るやつ
時系列順に振り返ってみます.なにをしていたか憶えていないのもあるのですが前半は密度が低いですね.ほんまスプラトゥーンしかやってなかったんじゃないか.
1 月
2 月
- 全ルール S+ に上がった
3 月
- Figma でずっと遊んでいた.Web ブラウザでここまでできるって本当にいい時代になったんですね.
4 月
- 学年++
- 大学院の授業が受講可能になったので手続きなどした
- 弊大学で大学院科目を受講するには電子的な学務システムとは別に受講したい大学院科目を紙に書いて年度初めに提出する必要があって履修計画もそれに合わせて早めに立てる必要がありで,なかなか事務作業で大変だった
- Galantis のライブにいった.最高.
- Minecraft サーバをナウくして遊んでいた
- 研究室に配属されました.HPC 系の分野になります.
5 月
- esa.io を契約した.授業ノートと研究ノートは全部ここに投げ込むことにした.現状いい感じです.
- 大学院入試の出願
- MPICH のソースコードを読む日々を送っていた.ctags 最高. github.com
6 月
- 大学院入試がありました
- 推薦だったので試験科目は面接だけでしたが,研究計画書を出す必要があったので書きました
- 計画書を書く過程で研究内容が一度整理できたし良い機会でした
- 質問内容はやはり研究内容のモチベーションの部分が多かったです.具体的には提案手法を理解するための質問,このような例では提案手法の適用ができない場合があるがどうお考えか?な質問でした.研究者としての態度を見られてるのかなぁとか考えてました.
- 面接官氏は顔色ひとつ変えず質問するタイプの方だったので表情から相手の状態を探れず,うまく答えられていたかどうかは謎です.
- PFN で二ヶ月インターンが決まりました
- テーマは「分散深層学習/深層学習のためのHPC・分散データ管理」で応募しました
- なお B4 の夏休みに長期インターンに行っていいか指導教員氏に尋ねたところ二つ返事で OK をもらえました.大変にありがたかったです.
7 月
- 大学院入試に合格しました
- 卒業できれば来年度は大学院に進学します
8 月
US 配列届いたぞー!!! pic.twitter.com/Q7EfAxOGhF
— k5342 (@k5342) 2018年8月4日インターンをしていました
- セキュリティキャンプにジュニアゼミのチューターで参加しました
- ジュニアゼミは小・中学生限定で参加できる今年度新設のゼミなのですが,キャンプの 5 日間で受講生の皆さんが自作パケットで TCP の 3-way ハンドシェイクを喋れるようになる様子は涙なしには見れませんでした
9 月
- インターンをしていました
- ISUCON 予選に参加しました k5342.hatenablog.com
10 月
- 技術書典に参加した.初参加でしたがむっちゃ人が多くてすごかった.こんなにたくさんいるエンジニアの中で競争をしていかねばならないのだなあと思いました.
- Pro コン (三代目) を壊した.ジャイロの調子がむちゃくちゃ悪くなった.だいたい 200 時間ごとに壊れてる気がします.
11 月
- 卒論をやっていた
- 自転車でコケて肩を強打した.幸いにも骨は折れてなかったですが腕が上がらなくなるレベルでした.自転車運転するときは水たまりには気をつけたほうがいいですよ.
12 月
- SC 勉強会に参加した.関東に引っ越してから勉強会に参加するのは初めてだったのですが,こういうコアな勉強会は積極的に参加していきたいですね.
- 卒論をやっていた
- スマブラを買ってしまった.むらびと練習してます.
アクティビティで振り返るやつ
緑化活動についてですがインターンやバイトを除けば昨年とあまり変化がないです.ブログに関しては昨年と比較すれば更新頻度は高くなったと思います.2019 年はさらにアウトプットできるようにがんばりましょう.
総括
- 来年も頑張っていきましょう
- そういえばそろそろ誕生日なんですよね.こちらのほしいものリストもよろしくお願いします.
いかがでしたか?ではまた~
*1:数値として出ていたのは 2790 時間.付けっぱなしだった時間もあるので純粋なプレイ時間ではないですが
ISUCON8 予選に参加した
ISUCON8 の予選に去年と同じメンバーの @chigichan24, @euglena1215 と,チーム 牛久大仏「う~ん顔採用w!」 で参加してきました.
最終スコアは 4000 点くらいで,予選敗退です.スコアも跳ねなかった.様々なボトルネックが把握できたし様々な手法も試したがそれらは効果的な解ではなかった.悔しいですが忘れないうちに書きます.策は打ったが結果にコミットできなかった記事です.答え合わせをしたい人は回れ右.
※ ISUCON とは,Iikanjini Speed Up CONtest の略で,制限時間 7 時間で互換性を保ったまま (つまり,同じ入出力ができる状態で) 与えられたアプリケーションを高速化するコンテストです.
チームメイトの記事は以下です. @chigichan24 の記事では Nginx や MariaDB などのミドルウェア改善の視点から全体を振り返った記事が書かれています. chigichan24.hatenablog.com
@euglena1215 の記事ではアプリケーションコード改善の視点から記事が書かれています. euglena1215.hatenablog.jp
プロローグ
前回は予選突破できたものの課題は山積していた.予選は頑なにサーバと向き合い続けたらなんとか突破できた.が,本戦ではアプリケーションをゴリゴリ修正する必要があったので,歯がたたなかった.反省点は概ね以下の通り.
- アプリケーションコード修正の優先順位が低かった
- レギュレーションの見落としが多かった (特に予選の帯域制限や
/fetch
の扱い) - N+1 解決の優先順位が低かった
- 初期の準備に時間がかかりすぎた
- git ready にするまで時間かかったりパスワードミスって fail2ban に BAN されたりした
すげー悔しかったので今年の ISUCON は 6 月くらいから始まっていました. esa を使って情報共有もした.esa 便利ですよ.基本的に社会人とは経験の差がすごいので,とりあえず真似できるようになろうと強豪チームの実装ステップを追って共有した.
戦略
今年はアプリケーションを治そう,他のつよいチームと比較してもアプリケーションの修正が少なかったのは分かっていたし,とりあえず Nginx と向き合い続けるのは危険じゃないか,という考えから以下のような方針でいった.
- レギュレーションをしっかり読む
- Nginx はお気持ち程度にする
- N+1 は確実に潰す
- 計測を確実にする
計測は前回は完全に雰囲気でやっていたので,ちゃんと事前練習した.ツールも覚えた. あと僕は基本的に怠惰な人間性の持ち主なので,去年の fujiwara 組のように Docker Compose を用意するわけでもなく全部サーバサイドで修正したがる.前回はサーバサイドで全員が同じユーザで開発したので history 汚染や意図しない git checkout がやばかった,ので,開始直後に全員分の公開鍵や dotfiles を突っ込むのと個別のユーザを作る Ansible Playbook を書いて実戦投入した1.この作戦は前半の焦りを緩和するのに大いに役立ったと思う.チームメイトには Vim 使用を強制した.Vim 利用者増加にも貢献できたと思う.
当日
予選はそういうつよい気持ちで参加した.今回は torb という映画館のチケット取得用 Web アプリで,一般ユーザが使うインタフェースと管理画面が付いた実装です.平成狸合戦バブル経済.アプリは ConoHa のサーバ上に乗っていて 1GB RAM で CPU は 1 コアのサーバが各チームに 3 台与えられました.パブリックな方向には 50Mbps とキツめの帯域制限があります.
僕のチームは Ruby 実装を使っていて最終的な構成は以下のような感じです.
今年はアプリケーション修正に重きを置く作戦で,具体的な担当を決めていませんでしたが,最も作業量が多かったものを上げるなら k5342 → 計測,chigichan24 → サーバ設定最適化,euglena1215 → アプリケーション修正 といった感じでした.チームでやったことは以下のとおり.
# | k5342 | chigichan24 | euglena1215 |
---|---|---|---|
10:00 | Ansible を走らせる | サーバを眺める | レギュレーションを読む |
10:15 | yum install nginx | ||
10:40 | 複数台の .conf と App を Git 管理下にする | アプリケーション修正準備 | |
10:45 | DB にインデックスを貼る | ||
11:00 | 複数台で git push できるようにする | Nginx 化 | |
11:15 | 80 と 22 ポート以外が開かない原因調査 | Nginx の max_connections 増やす | kataribe でプロファイルをとる |
12:10 | get_events の N+1 を考える |
静的ファイルに Cache-Control 設定 | get_events の N+1 を考える |
12:30 | euglena1215 手伝う | euglena1215 手伝う | ペアプロで get_events の N+1 を治す |
14:41 | MariaDB の max_connection 増やす | get_events の N+1 を消すget_event の details 無し版をつくる |
|
14:53 | DB: isu1, App: isu2 に構成変更するも fail | get_event の N+1 を消す作業 |
|
15:00 | isu2 の GET /initialize がやたら速いことに気づく |
||
15:00 | GET /initialize がサイレントにコケる原因調査 |
||
15:10 | DB: isu1, App: isu2 完成 | ||
15:19 | SELECT のトランザクションを消してみる | ||
15:20 | App でやたらスワップしてることに気づく | ||
15:25 | App を修正して csv のメモリ使用量削減に挑戦 | ||
16:00 | やっぱ get_event 完全に直さないとキツい? |
メモリ足りひんから MariaDB も控えめにチューニングする | Puma のワーカ設定変更芸人 |
17:00 | とりあえず三台使い切ろう | ||
17:07 | DB: isu1, App: isu2, isu3 完成 | ||
17:20 | 再起動チェック | ||
17:45 | 祈りを捧げる | ベンチガチャ | ベンチガチャ |
18:00 | 終了 | 終了 | 終了 |
去年と違って複数台構成がシュッとできたところはすごくよかったと思うし,インデックスや静的ファイル配信みたいな基礎的な部分も序盤でできていた点は成長だと思う. 一方で時系列に治してみてみると僕があまりアプリケーションコード修正に参加できておらず,反省点が活かしきれなかった.
フィーリングに頼らず計測をうまいこと活用できたと思っていて,ボトルネック把握に特に役立てられたと思っています.例えばベンチマーク中にページアウトがアホほど起こっていてこのせいでアプリが律速していたことに去年の自分は気づけなかったと思う.
しかし,計測がうまくいったとしても,それをどう解決すれば効果的かというフェーズではまだまだ取りうる選択肢が少ないかなというのと,それを短時間で実現できるかというのはまた別の話ですね,これらは今年痛感した課題.
あと get_events
修正用の SQL クエリをシュッと書いた (間違ってないクエリだった) んだけど,デバッグするときに参考実装で表示されているイベントと違う event_id でデバッグしていて 結果が違う!w とか騒いでいて (当たり前),有りもしないバグを探し続けた結果 1 時間くらい溶かしたのですげえ悔しい.そこはペアプロしてたのに最初気づけなくて,3 人のリソースが空振りした...ように思えるが,一人でやってたら気づけなかったかもしれないし,悩ましいですね.これも実力です.及ばなかった.
今回はボトルネックが 帯域 → (静的ファイルのキャッシュ) → CPU → (インデックスを貼る) → (N+1 修正) →メモリ → (複数台構成) → メモリ (!!!) と前回よりは進めたと思っていますが,メモリバウンドになったときにどのエンドポイントがそうさせているのか,アプリまるごと複数台にコピーするんではなくエンドポイント単位で複数台構成にするアイデアは思いついても良かったかなという感じですね.ISUCON やパフォーマンスチューニングにおいては推測よりも計測が大事と言われますが,単に計測をすれば良いのではなく,それを細かい粒度で行うことも重要であることを痛感しました.今回の例でいうと,複数台に増やすのも単にアプリケーション全体のメモリが足りないからではなく,もう少し対象を絞って,(このエンドポイントはアクセスが少ない割に重すぎるのでこれだけ移すなど) 具体的な根拠を伴ってできれば良いスコアに近づけたのかなと思っています.
最後に
このメンバーで出るのは残念ながら今年で最後で,2 年間 ISUCON を通して様々な勉強をさせていただきました.ありがとうございました.また今年は Wantedly のオフィスの一室をお借りして参加させていただきました.ホワイトボードや空調,ディスプレイやスクリーンなどの快適な環境を提供いただきとても感謝しています.
あと今年の ISUCON はシステムがすごくて,チームでひとつベンチマーカが存在していてキューがサクサクだったのと,例年の定石が通用しにくい超良い問題設定や,そこそこ重量がある実装と,あらゆる点で前回よりもパワーアップしていて解いていてとてもおもしろかったです.ISUCON はとても楽しくコンピュータの勉強ができる機会なので皆さん是非参加しましょう. 僕は今年は残念ながら本戦には参加できないので,来年の ISUCON に向けてアップを始めます.次は勝ちに行きます.
-
Ansible Playbook は初挑戦だったが大変に冗長なコードを書いてしまったので後日勉強する↩
OBS でイイ感じにテロップを出して LT を配信した話
先日,某 LT 会があり,その様子を身内用の限定公開で配信したのでその構成に触れつつ記事を書きます.
構成
配信ソフトウェアはオープンソースの配信用ソフトウェアとして有名な OBS (Open Broadcaster Software) で,これを使って考えていた当初の理想構成は以下のような感じです.
名前 | 役割 |
---|---|
iVCam | iPhone をワイヤレスカメラとして Windows で使用可能にします. |
jikkyo | Twitter のリアルタイム検索結果をオーバーレイ表示します. |
Capture board | 発表者 PC の出力をキャプチャしてパススルー出力に流します.Intensity Shuttle を使っています. |
テロップを出したい
前回の LT も同様な構成で配信をしていて,このときのライブ配信やアーカイブを見た人から「いま誰が何を喋ってるか分かりにくい」という声があったので,今回は今誰が何を喋っているかをテロップとして出したい気持ちになりました.OBS にはテキストソースというのがあり,これを使います.テキストソースにはファイルの現在の内容をリアルタイムで表示してくれる機能 (!!!) があるので,これを使って Web ブラウザからテロップ表示内容を遠隔で変更する簡易的なアプリケーションを作ってみました.遠隔で操作できるようにした理由は,単にそっちのがカッコいいのと,真面目な理由として配信用マシンでカチャカチャ操作すると音が配信に乗っちゃうためです.
作った
日曜大工おじさんの出番.
obs-textsource-webserver は,テキストソースの表示内容を Web ブラウザから遠隔で切り替えられる Ruby 製ツールです.OBS が動いている端末と同じ端末で使います.このツールは TSV (Tab Separated Value; タブ区切りテキスト) で書かれたファイルを起動時に読み込み,Web インタフェースを通じて表示する行を切り替え,選択された行についてカラムの値をカラム名と同じファイル名として書き込みます.ファイルの読み書きで表示内容を切り替えるので多少ラグがあります.
今後の展望
今回は OBS のテキストソースをいい感じに切り替える Web サーバを作りました.実は OBS には他にブラウザソースがあり (!!!),これを使うことでブラウザの表示内容を配信画面に載せることができます.ブラウザソースは内部で Chromium がレンダリングしていて,Chromium で動くようなものなら基本的になんでも表示できるので,CSS や JavaScript によってアニメーションやより凝ったデザインが可能になります.次はこのブラウザソースで表示できるビューを出力する機能が欲しいですね.それで外部のサーバに載せてワチャワチャできて良さそう.
LaTeX で PDF 画像が表示されないとき
環境
- TeXLive 2015 (
2015.20160320-1ubuntu0.1
) - dvipdfmx (Version 20150315)
状況
Excel Office 365 で出力した PDF を PDF 画像として \includegraphics
で読み込むと,LaTeX で生成された PDF に画像が表示されない (空白になる).
以下のような出力がある:
dvipdfmx:warning: Version of PDF file (1.7) is newer than version limit specification. dvipdfmx:warning: pdf_open: Not a PDF 1.[1-5] file. dvipdfmx:warning: pdf: image inclusion failed for "./1b.pdf". dvipdfmx:warning: Could not find image resource... dvipdfmx:warning: Interpreting special command epdf (pdf:) failed. dvipdfmx:warning: >> at page="2" position="(170.079, 567.02)" (in PDF) dvipdfmx:warning: >> xxx "pdf:epdf bbox 0 0 729 516 clip 0 width 256.07481pt (./1b.pdf) "
直し方
dvipdfmx に引数を与えて PDF 1.7 を明示的に指定する (-V 7
).僕は latexmk
を使っているので ~/.latexmkrc
を編集.
#!/usr/bin/env perl $latex = 'platex -8bit -kanji=utf8 -shell-escape -guess-input-enc -synctex=1 -interaction=nonstopmode %S'; $dvipdf = 'dvipdfmx -V 7 %S'; ~~~~ <- add this option