という記事を書きました。
Poetry を使ってみた
この記事は KMC 2 Advent Calendar 2019 3日目の記事ということにしました。
Poetry
Python の Dependency Manager は pipenv が有名で、自分もリリース当初から使っていた。ただ、最近はリリースが一年間されておらず、割と不安な状態*1。
最近は pipenv への対抗馬として Poetry が開発されているらしい。こちらは活発でリリースも頻繁にされており良い感じ。
pipenv で決まりだと思っていたのに… と思いながらも Poetry を使ってみた。
pipenv は Pipfile で依存パッケージを記述するが、Poetry では pyproject.toml を用いる。その他細かい使い方は README 参照。
感想
良かったところ
- ちゃんと使える
PyPI にアップロードするのがとても楽になる
pyproject.tomlに書いたらpoetry build && poetry publishで終わり！依存解決が早い
- グラフィカルなコンソール表示
機能の取捨選択が良い
pipenv はおもてなし機能が多すぎると思う。
ソースコードがきれい
これは出たばかりだからかも。
poetry run の実装を見たところ、ちゃんと os.exec しているので安心した。
イマイチなところ
CLI のインターフェースは pipenv のほうが好き
poetry addはinstallコマンドにまとめて欲しい、とか。pyproject.tomlが無いときにaddやinstallしても、良しなにinitされて動いて欲しい、とか。カスタマイズが弱い
単純にフラグが少なくて、要求とマッチせず困ることがある。
また、 pipenv ではフラグ類は基本的に環境変数で設定できるが、Poetry は一部のフラグしか設定できない。
まだ絶賛開発中である
時々バグっぽい挙動がある。作者が想定していそうなパッケージストラクチャを使っていれば動くが、そこから外れるとよく分からないエラーが出る。結局ソースコードを読むことになる。
（良い意味でも悪い意味でも）かっちりしている
パッケージ追加時において、pipenv はデフォルトのバージョン指定は
*（どのバージョンでも ok）である。それに対して、 Poetry は^{current version}となる。個人の開発レベルでは*のほうが嬉しい（*にする手段はある）。
結論
まだ開発中ではあるものの、パッケージマネージャとして欲しい機能がちょうど良く揃っていて良いソフトウェアだと感じた。特に setup.py を生成してくれるのが魅力的で、PyPI にアップロードしようという気持ちにしてくれる。
もうすぐ 1.0 が出るらしいし、当面は Poetry で過ごそうと思う。
*1:master だけは進んでいる…
iTerm2 JISキーボード 文字 拡大 Karabiner-Elements
iTerm2 で文字を拡大するショートカットは ⌘ + である。
JISキーボードでは + は Shift ; を入力することになるので、⌘ + は JIS では Shift ⌘ ; が入力される。
一方 iTerm2 では、Shift ⌘ ; が Open Command History に割り当てられている。このため、JISキーボードで文字を拡大しようとすると謎の機能が発火してしまう。
これの対策として、
- iTerm2 を表示している
- JISキーボードである
場合、Karabiner-Elements で Shift ⌘ ; を ⌘ + に変換するようにする。
{ "title": "Send Cmd+'+' on iTerm2", "rules": [ { "description": "Send Cmd+'+' on iTerm2", "manipulators": [ { "type": "basic", "from": { "key_code": "semicolon", "modifiers": { "mandatory": [ "command", "shift" ] } }, "conditions": [ { "type": "frontmost_application_if", "bundle_identifiers": [ "com.googlecode.iterm2" ] }, { "type": "keyboard_type_if", "keyboard_types": [ "jis" ] } ], "to": [ { "key_code": "keypad_plus", "modifiers": [ "left_command" ] } ] } ] } ] }
YAML から JSON に変換するツールを Nim で書き、GitHub Actions でリリースする
最近 config が YAML になっているアプリケーションが多い。ただ、自分は YAML の読み書きが苦手である。
設定を書くには機能が多すぎるのと、（config なので）ネストしやすいのにインデントが関わってくるのが苦手なのだと思う。
何度かハマった結果、これからは JSON に変換して読むことにした。JSON を読むのには慣れているし、jq など色付・抽出するツールも持っているので最高 *1 。
YAML を JSON に変換するツールは世の中に多くあるが、そんなに大変じゃないので自分で作ることにした*2。
何で作るか
案1 Ruby で書く
Ruby は標準ライブラリに YAML パーサーが入っているので、適当な ruby のスクリプトを書けば目的は達成される。
ただ、そのためだけに Ruby 入れるのも嫌だな…って思ってやめた。
案2 Go で書く
Go のようなコンパイラ言語であれば、標準ライブラリに入ってなくともコンパイルすれば良いので楽である。
また、Go は goreleaser や go get などインストールしやすい環境が整っており最高。
というわけで初めは Go で書いていたのだけど、YAML と JSON で型が微妙に違う（YAML は map[int]interface{} のこともあるが、JSON は map[string]interface{}）のが面倒でやめた。
案3 Nim で書く（採用）
Nim は先日 1.0.0 が出たイケイケの言語で、Python っぽく書けて便利という評判が自分の中である。Go が無理なら Nim チャンス！ということで Nim で書くことにした。
Nim の YAML ライブラリ は最高で、loadToJson 関数があるので一瞬で終わった。
バイナリを作る
リリース周りは CI でやりたい。今回は GitHub Actions を使ってみることにした。GitHub Actions では、Action を組み合わせたり、自分でコマンドを記述したりして CI の動作を記述する。
Action は 公式がいくつか配布している 他、サードパーティのもある。今回はサードパーティ Action は使わない方向でやってみた。
Nim with GitHub Actions
公式では Golang など様々な言語をインストールする Action があるが、残念ながら Nim はない。なので自分で環境構築を行った。
macOS
brew が入っているので、 brew install nim する。
Ubuntu
Ubuntu では Docker を使った（apt で Nim が配布されているものの、バージョンが古くて依存ライブラリがコンパイルできない）。
amd64 だと 公式 Nim Docker Image を使えばよかったが、クロスコンパイルはできなかったので、 arm 用には クロスコンパイルできる Image を Docker Hub に作った *3。
ちなみに、GitHub Workflow には Docker 上で動かしたり Volume を作ってくれたりする機能があるが、それを使うにはパブリックイメージを使う必要がある。そうでない場合は自前で docker build して docker run ... することになると思う。
その他
良かった
- 何でもできる
- Cron っぽいこともできる のはすごい
- Public repository だと無料
- 20並列までいけるし、ビルド開始も素早い。 MS 様〜〜
- macOS や Windows がある
- Nim では OS をまたいだクロスコンパイルは難しいので非常にありがたい
- macOS では brew が入ってたりする ので何でもできる
- GitHub のトークンを渡すのが楽
- 勝手に生成してくれる
悪かった
まだ出たばかりというのもあって、使いづらい点も多かった。
公式の Actions が機能不足
artifact は一つずつしか Upload できない等、「一応できるけど不便」みたいな例が多い。 特にリリース周りは不便で、本当はもっとうまくできるのにな…と言いながら長い Workflow になってしまった。
job 間で値の受け渡しがしずらい
値を直接受け渡しすることはできず、 artifact 経由になってしまう。「一回リリースつくって、そこに並列で artifact を追加する」といったケースでは upload_url を渡すことができずに困った。
情報が多くない
ドキュメントはちゃんとしているが、ユースケースがまだ少ないため情報が探しにくい。
YAML エディタが使いにくい
エラーや補完を出てくれるのは嬉しいが、改行時は普通に改行してほしいな…。
多くの問題は時が経てば解決するだろう。
感想
VSCode 上で ESLint を使った TypeScript のフォーマット
- https://github.com/microsoft/vscode-eslint を入れる
- VSCode のデフォルトフォーマッタを切る
グローバルか、ワークスペース上の .vscode/settings.json などに書くと良い
{ "typescript.format.enable": false }
- TypeScript で ESLint が働くようにする
"eslint.validate": [ "javascript", "javascriptreact", { "language": "typescript", "autoFix": true }, { "language": "typescriptreact", "autoFix": true } ],
ISUCON9 予選に参加した（failed）
最近は O-Ku-Ri-Mo-No Sunday! にはまっている。めっちゃ良くない？
ということで先日 ISUCON9 に参加した。
チームは :innocent: で id:wass80, id:utgwkk と参加した。
全体的な話は utgwkk の記事を参照。
自分のやったことは大体以下の issue に書いてある。レポジトリも以下参照 *1 。
トラブル集
今回もいろんなことが起きたので列挙してみる。
サーバー構成を1台と勘違いする
全員が [重要] と書いてある場所を読み飛ばしてスコアの計算方法ばっかり気にしていた結果、複数台構成ができないと思い込んでいた！
コンテスト中は「これ複数台勝手に立てたらどうなるかな〜」とか言ってました。1台だったのでインフラ担当の自分は途中暇だった。
たとえ構成は1台限定だったとしても、3台立ててそれぞれ作業用にしたら良かったなあ、という反省も。
VSCode Remote をやめることで得点が10倍になる
なんか 410 点ぐらいしか出なくておかしいな〜とか言いながら htop を見ていたら VSCode Remote がめちゃくちゃ CPU 食ってた。やめると 4100 点ぐらいになって最大のブレイクスルーだった。
Gunicorn のオプションを間違えてプロセスが大量発生する
Gunicorn の --worker-connections を 10000 にしようとしたときに、間違えて -w 10000 として ワーカー数が 10000 になった。当然プロセスが大量に生まれるので、アクセスするとめちゃくちゃ重くて Load average が 170 になった。
sudo や w すらも謎のエラーで使えなくなったので、 root で入って systemctl kill した。 systemctl は kill できるので最高！*2
uWSGI の restart が効かないので reboot を繰り返す
いろいろあって Gunicorn を uWSGI に載せ換えたのだけど、なぜか restart がハングするようになってしまった。面倒なのでサーバーごと reboot することで restart の代わりにしていた。後述の Redis と同じ理由かも？
途中から systemctl kill --signal=9 すると restart=true で立ち上がることに気付いたのでそれを使うようにした。 systemctl は kill できるので最高！*3
Redis が立ち上がらないので memcached にする
Redis を apt で素朴に入れたけど apt install や systemctl restart がハングしたので諦めて memcached 入れた。おそらく↓の話っぽい。
bind のハマり、MySQL より redis-server を apt で入れると /etc/redis/redis.conf に bind 127.0.0.1 ::1 と書いてあって v6 は disable されているので systemctl redis-server start が刺さって apt install が失敗したように見えるやつの方で 10 分ぐらい捨てたやつがあった...
— れい (Yoshikawa Ryota) (@rrreeeyyy) September 8, 2019
Redis は kill して purge した。 systemctl は kill できるので最高！*4
並列 http アクセスライブラリを入れようとして未実装であることに気づく
transactions で外部 API を呼んでいるところが直列で遅かったので、並列にしよう！ということで検索して出てきた httpx というライブラリを使うことにした。
このドキュメントに即して実装を始めたのだけど、20分程度して実装が終わりつつあったときにドキュメントにある警告文の存在に気付いた。
Warning
This page documents some proposed functionality that is not yet released. See pull request #52 for the first-pass of an implementation.
悲しいね〜。文章読めるようになる必要がある。
Gunicorn や uWSGI を使うと点数が伸びなくなる
途中、デバッグのために Gunicorn じゃなくて Flask の app.run() を直接使っていた。それでうまく伸びていたのだけど、Gunicorn にした瞬間に点数が1/10になった。uWSGI でも同様で、これについては今も謎。コンテスト中盤からずっとネックになっていて、終盤ドタバタした遠因になったと思う。
今見たら app.run() の方は threaded=True になってるので、10 workers の Gunicorn とはいろいろ違ったんだろうか。でも初めは上手くいってたので謎。
並列処理たちとのたたかい
gthread
Gunicorn は gthread を使うことができるのでなんとなく設定して使ったら動いているように見えた。ただ、大量に受け取りすぎて 499 ばかり返すようになってしまったので、もう少しチューニングが必要そうな雰囲気だった。
nodejs でも同じような悩みがあるのだろうか。それとも真にイベントループな言語は関係ないのだろうか...。
transaction
今回は transaction での外部 API が直列でめちゃくちゃ遅いのが課題になっていた。Python の並列処理にいい思い出が無いので、そこだけ nodejs に流すことも考えたものの、cookie やらを考えて結局 Python で行うことにした。
ただ Python の async await ほとんど分からないので難航。出たの最近だし機能もどんどん増えてるので、ぱっと調べるには向いていなかった *5。
結局最後の最後*6には aiohttp 使って勘でなんとかなった気もするけど、他のエラーでてたので分からなかった。
次回は go か node でやってもいいなあ、でも今回で async への理解深まったので Python で使える気もする。自分が一番好きで詳しい言語である Python によく分からないメジャー機能があるのがとても悔しい…。
良かった点
反省点ばっかりなのもアレなので良かった点も。
- 遠隔で行ったが、専用ディスプレイにずっと遠隔者のディスプレイを写していた
- スムーズな情報共有ができたと思う。全員同じ場所にいても有効だと思った。
- 次は VSCode Liveshare とか使ってみたいな。
- バグったときのために、オリジナル版を別ポートで動かしていた
- バグったときにレスポンスをオリジナル版からも取得して diff する、といった活動を行っていて低コストながら高速にバグを発見できた
- 計測やログイン環境のセットアップは順調にできた
- pt-query-digest や kataribe などでボトルネックの計算をちゃんと行っていた
- 定期的に git commit していたので容易に rollback できた
- スコア計算方法の部分はちゃんと読み込んでいた
- 手が空いたときに弁当を買いに行くという判断をした
- 昼飯をちゃんと食べた
- 楽しかった
その他
@チーム
今年もありがとうございました。 wass の迅速な方針決めや実装は頼りになったし、utgw が N+1 や index をバシバシ解決していく姿は最高だった。来年も頑張りたい！！
@運営
今回も楽しかったです！
バランスの良い問題になってて良かったです。isucari や還元キャンペーンなど、いかにもメルカリっぽい話題でニヤッとしました。あと得点がレスポンス数ではなく取引価格の合計なのも、実際のサービス目標感があって良かったです。
運営・インフラ提供・問題作成者の皆さん、ありがとうございました！！
感想
今年はあんまりやる気なくて練習もせず適当に始めたのだけど、実際やったらめっちゃ楽しいし、負けたらめっちゃ悔しい。 ISUCON4 からずっと参加しているけど、最高のコンテストだと思う。
次回もあれば絶対に参加したい！！！！！本戦行くぞ！！！
