言語は Go、最終スコアは15532点、参考スコアを上から数えると45位だったようです。悔しい。
具体的な取り組みは下の方で述べますが、MySQL移行はバグなく完遂し、さてここからチューニングしていくぞ！という感じのところで終わりました。エンジンが掛かるまでの速度が足りなかった。

毎回、運営の皆様にはいくら感謝しても足りませんが、今回も取り組みがいのある問題で楽しかったです。ベンチマーカーも最後まで待ち時間がほぼなく、スコアも安定していたのでとてもストレスフリーでした。ありがとうございました。

マルチテナントで大量の SQLite3 データベースがあることが分かったとき、ISUCON本を読んだだけの人間には解かせないってことね!と思いながらニコニコしました。

ところで知り合いがたくさん著者に名を連ねているISUCON本ですが、予選の2週間前に購入し、予選開始1時間前に部屋から発掘されました。
30分ぐらいで流し読みしたのですが、大変実利的な内容に溢れているなあと感じました。nginx の upstream で keep-alive を有効にする方法は知らなかった……

9:00 起床

前日も早く寝るぞと自分に言い聞かせながら4時半まで起きてしまい、念には念で8時に掛けた目覚ましが1時間鳴っていました。すでにこの時点で心も体も終わっています。

部屋の隅にISUCON本が積まれているのを発見しました。ちいとぽも積まれています。
h-otterと合流するために移動しつつ、パラパラと眺めます。

10:00

まだ合流のため移動中ですが予選が始まっているようです

10:05

合流しました。 CloudFormation テンプレートを流します

10:22 初回スコア 2732

起動したのでベンチを回しました。この時点で分担も何も決まっていません。

とりあえず kataribe を入れたり pt-query-digest を入れたりします。
「そういえば先日の社内ISUCONで Cloud Profiler 便利だったな……」みたいなことを思いながら、入れ方を調べます。
GCPプロジェクトが必要らしいので作ったり、サービスアカウントキーを発行したりします。予選始まってからやることではない。

11:30ごろ

Cloud Profiler を入れたので眺めました

12:00

h-otter が MySQL 対応の実装を終わらせて、「Uber eatsでも呼ぶか〜」と言いながら、なぜか歩いてマクドナルドに飯を買いに行きます。なんで??

13:03 MySQL移行 3023点

MySQL移行が一段落します。今思うと速かった。

sqlite から SQL をダンプしてゴニョゴニョやり始めて十分程度経ったあと、 sqlite3-to-sql って名前のスクリプトあるけど?? と気付いて笑ってました。先に気付こうね。

とりあえず MySQL に流し込むこと数分、INSERT が一向に終わらないことに気が付きます。このままでは POST /initialize がタイムアウトしてしまうため、バルクインサートをするクエリに書き換えることにしました。

sed で気合でバルクインサートに書き換えましたが遅い。ここで1台目のインスタンスがメモリを食いつぶして死にます。160万件のINSERTを一発でやると死ぬことが分かる。
先日の社内ISUCONでもインスタンスのメモリを食いつぶしたんだよな……と思いながら1台目を捨てます。

これが答えです。

for i in `seq 1 100`; do echo $i; mv $i.sql $i.sql.bak; sed -z -e "s/);\n/);\n\n/" -e "s/NULL\n);/NULL\n);\n\n/g" -e "s/);\nINSERT INTO [a-z_]* VALUES/)\n,/g" $i.sql.bak > $i.sql; done

それなりに早くなりましたが、まだ遅いので tenant の player_score テーブルにおいて、 updated_at が一定以上のレコードを DELETE する作戦に切り替えます。これで10秒程度で POST /initialize が通るようになりました。

DELETE FROM tenant_X.player_score WHERE updated_at > 1654041599;
DROP TABLE tenant_X.competition;
DROP TABLE tenant_X.player;

他のチームの参加記を読んだら 「/var/lib/mysql をコピーする」「毎回 mysqldump を実行する」みたいな筋肉実装が多くて震えました……

確かここらへんで h-otter がなぜか flock を倒す実装を書くもベンチがコケました。
「そこはボトルネックじゃないっぽいし一旦revertしよ?」と、人の競技中の努力を無に帰すような心無い発言をしました。ごめんなさい。

なぜかここからしばらく無の時間が続きます。なぜ……

15:20 3758点

h-otter が competitionRankingHandler の N+1 を潰したようです。

15:50 6336点

グッとクエリを睨んで indexを追加。playerAddHandler がかなり速くなりました。

ALTER TABLE visit_history ADD INDEX (competition_id, player_id, created_at);
ALTER TABLE visit_history ADD INDEX (created_at);
ALTER TABLE tenant_X.player_score ADD INDEX (competition_id, player_id, row_num DESC);

マルチテナントのDBをそのまま持ってきたので、tenant_id は無視するようにしました。

16:08 7923点

h-otter が playerHandler の N+1 を潰したようです。

そして player_score に index を追加。
ALTER TABLE player_score ADD INDEX (player_id, competition_id);

バルクインサートと、JSONシリアライザの変更(encoding/json → goccy/go-json)をした結果、スコアがやや増加しました。(8269点)

16:36 10253点

なんかヤバそうな実装の dispenseId を倒しました。1万点突破。
よくわからんけど順序保証されてたほうが良さそうな気がしたので、 time.Now().UnixNano() を文字列にしてそのまま突っ込みました。爆速。

たしかこのあたりで、 tenant の player_score は (tenant_id, competition_id, player_id) ごとに最新の1行だけあればいいことに h-otter が気付きましたが、あまり速くならず。
この時点で row_num に関する index を落とすべきでした。

既存の tenant_{1..100} に対してもそれを適用しましたが、スコアとしては特に変化なしでした。

このあたりでベンチマーカのログから、タイムアウトでユーザーが減ったという表示がなくなり、ようやくISUCON始まったな! という気持ちになります。すでに手遅れ。

17:03 12505点

h-otter が jwt のパース結果をキャッシュします。神

17:45 14363点

app + DB の2台構成にした気がします。

17:50 15962点

流石にやや諦めムード。ログを切ったりできることをしました。
忘れずDEBUGログを切ったりスロークエリーを切ったりしました。偉い。

「再起動試験はしなくていいでしょ！」で終了

感想

1. MySQL 移行をバグらせずに完遂できた俺達は偉い (本当に偉いと思っている)
2. 毎回意味不明なバグを仕込んで後半暗澹たる感じにあるので、今回はほぼ最後までノーバグで駆け抜けられたのは良かった。良くも悪くも我々は大人になった
3. プロファイラ / スロークエリ / アクセスログの3本柱をちゃんと見ながら走れたのは本当に良かった。常に事実は正しい。fact based / metrics-driven
4. 後半のスコアのブチ上がり方が楽しかった。というかここに来るまでを自分は第一関門を突破した段階だと思っている。やれる改善はたくさん残っていたし、あと1時間あれば更に2倍, 3倍のスコアは出ていたんだろうなと思うと悔しい

そのほか

1. 午前中からの競技は本当に心も体も終了していて何も捗らなかった。ISUCONに必要なのは健康な心と身体
2. デカいテレビで h-otter がリゼ・ヘルエスタと名取さなの原神ガチャ配信をずっと流していた。「縁起がいいと思ったんだけどなあ」って何?
3. その後はリゼがパワプロしてた。リゼ・ヘルエスタについて私が知っているのは第一第二第三皇女のいずれかであるということぐらいです。
4. 最後1時間ぐらいローテンションお嬢様 (壱百満天原サロメ)流したら集中力が0になった。何?

この記事を書いている時点で、すでにこのブログが構築したクラスタ上で動いているところまでは来ていますが、ゆっくり備忘録がてらまとめていくことにします。

ただkubeadmでシングルノードで立てても面白くないよね、ということで、色々と試してみることにしました。

1. 実験のしやすさを考慮してVMの上に建てる
   1. VM基盤は n0stack を使う
2. 可能な範囲でちゃんと冗長化する
3. ちゃんとアプリケーションを乗っける
4. 完全なお遊び用のクラスタは別に作る

あたりを基本方針にしました。

ホストについて

さて、まずサーバはどうするかという問題がありました。現代なので冗長化するなら3台欲しいので、お手軽かつ高速なマシンが3台必要でした。

また、過去にも同じことをやろうとして、秋葉原で安く売っていたサーバ(通称赤鯖)を3台買ってはいましたが、CPUもRAMも足りない && ファンの音がうるさいということで放置されて早3年が経過したので、次は静かなマシンが良かったわけです。

というわけで安くて速くて静かでRAMが積めるマシンを検討した結果、 Lenovo の M75q Tiny Gen2 を購入しました。定番ですね。Ryzen 7はコアが多くて速い。
ただ、予算の都合でまだ2台しか買えてません。

購入後の感想ですが、静かで小さいので自室の足元に置いても気にならずかなり満足しています。CPU使うと流石にファン回って気になりますけどね。

一方で、色々構築をすすめるにつれ、ストレージが256GBだと足りないか? と思うことがあり、SATAのSSDを追加することを検討しています。
ストレージ足すなら別に小さい必要はなかったのでは……という気持ちがあり、 V55t Mini-Tower とかでも良かったのでは……という気持ちに。計画性がない。

ストレージをどうするか問題は常に付きまといますね。後述するかもしれませんが、現在は、このクラスタとは別に以前から運用していた FreeBSDサーバに刺さっている雑なディスクをミラーリングしてNFS共有しています。RDBMSとかやろうとするとiSCSIの方が良いかもしれない……

OSは雑に Ubuntu 20.04 Server を選択。

n0stack

今回のVM基盤です。別にlibvirtでもOpenStackでもなんでも良いのですが、構築が楽 & 動作が軽くて、コードはなんとなく分かるので気になったら自分で直せるし、ぐらいの気持ちで選択しました。

n0tsack は 友人の @h-otter が主となって開発していて、過去には ICTトラブルシューティングという大会で数百VM規模で動いた実績があります。紹介記事は本人が書いてるので読んでください。

n0stackの紹介 – h-otterの備忘録

https://h-otter.hatenablog.jp/entry/2019/09/22/164251

https://github.com//n0stack/n0stack を眺めて、 n0core と n0cli があれば動くことが分かったので適当にやります。

VMを起動する/管理する本体である n0core は、全体の管理をする api とQEMU等を制御する agent からなります。
データストアは api にいて、デフォルトでは設定不要の LevelDB を使用します。LevelDB は特にデーモン等が不要のDBで、api が動くホストの /var/lib/n0core あたりに勝手に保存されます。
冗長化したければ etcd も使えます、が構築時点では
etcd or LevelDB を使っていて、デフォルトだと LevelDB を使うので、特にDBの設定は不要です。雑に GitHub の README を見てデプロイします。

VMのセットアップはあまり考えずにドキュメントを参照すれば良い、と思いきやハマりました。QEMUの仕様が変わったらしい? https://github.com/n0stack/n0stack/pull/239 で解決。そのうちマージします。

適当な Ubuntu が起動することを確認したところで一旦ここまで。(ホスト名は k8s-0X だが別に Kubernetes は動いていない)

とりあえずIOSのバックアップをすべく copy コマンドで自宅のサーバへ IOS をアップロードしようとした。しかし、Permission denied と怒られてアップロードに成功しなかった。

tftp (具体的には tftpd-hpa) サーバでの tftp 127.0.0.1 によるアップロード/ダウンロードはできる。何かがおかしい……

状況を整理

tftpd は 0.0.0.0:69/udp で listen している。 (systemctl start で動かない問題もあったが、それはまた別の問題)

# sudo lsof -i:69
COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
in.tftpd 29780 root    4u  IPv4 xxxxxxx      0t0  UDP *:tftp
in.tftpd 29780 root    5u  IPv6 xxxxxxx      0t0  UDP *:tftp

tftpd root は /srv/tftpboot。こういう挙動をする。

# tftp 127.0.0.1
tftp> get something
Error code 2: Only absolute filenames allowed
tftp> get /something
Error code 2: Forbidden directory
tftp> get /srv/tftpboot/something
Received 7 bytes in 0.0 seconds

IOSでのエラーメッセージはこんな感じ。tftpd は verbose フラグを付けてもだんまり。

#copy flash:c800-universalk9-mz.SPA.153-3.M3.bin tftp://10.0.0.1/srv/tftpboot/ios/
Address or name of remote host [10.0.0.1]?
Destination filename [srv/tftpboot/ios/c800-universalk9-mz.SPA.153-3.M3.bin]?
%Error opening tftp://10.0.0.1/srv/tftpboot/ios/c800-universalk9-mz.SPA.153-3.M3.bin (Permission denied)

なるほど……?

解決方法

ホスト名とパスの間にもう1つ / を足せばよい。つまり tftp://[ホスト名]//パス とすればよい。

#copy flash:c800-universalk9-mz.SPA.153-3.M3.bin tftp://10.0.0.1//srv/tftpboot/ios/
Address or name of remote host [10.0.0.1]?
Destination filename [/srv/tftpboot/ios/c800-universalk9-mz.SPA.153-3.M3.bin]?
!!!!!!!!!!!!!!(snip)!!
68176296 bytes copied in 129.832 secs (525112 bytes/sec)

気付いたきっかけは Destination filename の確認プロンプトだが、まさかこんなところでハマるとは思わなかった。
自宅インフラはトラブルシューティングが99%

最近はご家庭用の Wi-Fi AP であるところの Meraki Go も導入したが、こちらはコンソールに入る必要がないどころかそもそもコンソールポートが存在しない。
なんならインターネットに接続しないと初期セットアップすらできないし、Web設定画面はおまけでメインの設定は iOS / Android アプリから行うハイテク仕様。これがクラウドネイティブアクセスポイントってやつか〜

必要十分に高速で、かつ最高に安定している。おすすめです。

前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコアは4410点でした。再起動試験までたどり着けなかった……悔しい……

チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) での参加でした。学生は2人いたはずですがエントリーをミスったので学生は1人ということになっています。

使用した言語

私はRubyが一番得意だと思っていますが、非同期処理が書きやすいとか型が着いていると嬉しい、みたいなことはあり今回もGo言語です。
でも今回はN+1潰すときの型マッピングで無駄に時間を溶かしてしまったので、Rubyの方が良かったかもしれない……つらい……

開始前の準備

Prometheus/Grafana等のサーバの設定を @h-otter にお願いしました。前回のコードを読み返しつつ、何をしたかを思い出すなどした。

時間がなくて完全に忘れてしまいましたが、せめて練習はやっておくべきでしたね…

あと、 Alibaba Cloud の UI が色々不思議な感じで良かったですね。

本番

完全に正解していますが、今回はマイクロサービス問だということに気が付いたのは開始してからだいぶ経ってからでした。

開始30分前、チームメイトとの雑談「今日は何がでるかなー」「フリマアプリかオークションかそういうやつでしょ」「マイクロサービスとかね」「わかる〜」 #isucon

— kyontan@新刊はまだ (@sukukyon) September 8, 2019

今回できたことが異常に少ない気がする。kataribeのログを眺めつつ、チームでやったことは以下のことです。比較的時系列だけどそうでない部分もあるかも。

• 開始スコアは 2310
• 10:30 メモリ多いな〜って思っていたら2, 3台目のインスタンスタイプを間違えていたことに気がつく。インスタンス立て直し
  • コードは既にリポジトリへ追加していたのでチームメイトはルール/コードリーディングを進める
• 10:50ごろ: 作業開始
• 11:30ごろ?: MySQL 5.7 を 8.0 へ (@h-otter)
  • スコア変化なし
• 11:45 DBにインデックスを張る(@kyontan)
  • 多分間違えていて、これらにインデックスを貼りましたがあまり効いていなかったようにみえました
  • BigQuery の触りすぎでRDBのインデックスの挙動をほぼ忘れたのも敗北ポイント

config (name)
items (created_at, id)
items (id)
items (buyer_id)
items (seller_id)
shippings (transaction_evidence_id)
transaction_evidences (id)
transaction_evidences (item_id)
users (account_name)
users (id)

• 12:20: カテゴリをオンメモリへ (@hogas, @h-otter)
  • 2510点ぐらい
• 12:30: http2 対応, 静的ファイルをキャッシュ, アップロードされた画像を nginx で返すなど
  • スコア変化なし
• 13:30: config もキャッシュするように
• 14:00: 新着商品には発売中の商品だけを返すようにする (@hogas)
• 14:45  – 16:00: GET /users/transactions.json の N+1 を潰す (@kyontan)
  • 3500点ぐらい
  • なぜか色々ハマって2時間半ぐらい溶かしていた。これは敗北ポイント
  • 多分ここらへんでMySQLがサチらなくなっていた気がする
    • CPUがサチっていたことに気が付いていたが原因が分からず (pprofをなぜ見なかったのか……)
• 15:30: UserSimple が持つ情報は全てオンメモリでキャッシュする
  • ユーザの存在チェックだけするような部分 (権限チェック) も基本的にこれで対応できるのでそうした
  • 4210点
    • ここからスコア上がらず……
• 16:00: 同じクエリを何度か叩いているエンドポイントがあったので潰す (@hogas, @kyontan)
• 16:00ごろ: transactions 以外詰まってないしCPUに余裕があるので campaign (負荷レベル)を弄ったところ外部APIで 403エラー  {“error”:”IP address is not allowed”} が連発しだす
  • 主にGET /users/transactions.json での外部 shipment  サービスへのリクエストで連発
  • 外部APIへの403はアプリケーション的には500を返す仕様だったので、これが連発してベンチマーカが途中終了し完走しない
  • ここらへんで手詰まりに
• 17:00: 明らかに不要な SELECT FOR UPDATE を削除 (4箇所+ぐらい)
  • これかこれの次辺りで4410点。これがベストスコア
• 17:10: 外部APIを叩く部分で exponential backoff を実装 (@h-otter)
  • 変化なし / 403 が連発する
• 17:30: 外部APIをリクエストするエンドポイントだけ2台へ分散する
  • 403 の連発は解決せず、なぜ……
• 18:10: 最終スコア0点 (failed) で終了

色々施策を打つもスコアの変化要因が今ひとつ分からず頭が回っていなかったですね。
特に外部API が undocumented な 403 を返す (しかもメッセージは 「許可されていないIPアドレス」) というのは全然分かりませんでした。
マイクロサービス問題なら単一IPから連続でアクセスすると弾くようになっているのかな、などと思い、後半で外部APIへリクエストをするエンドポイントだけ複数台へ分散するなどしていましたが全く解決せず泥沼へ。

これベンチマーカと外部API側に問題あるのでは? みたいな気持ちになりつつ、マイクロサービス問だしちゃんとbackoffとか実行すればいけるでしょ! と思っていましたが、意図したエラーだったのかは未だに分からず……

他の方の感想を見た限りでは、ポータルサイトへ登録されていないIPからのアクセスは弾かれるみたいですが、これについてはUI上で正しく登録されていることを確認したので問題なさそうでした。
11:00 ごろにインスタンスを立ち上げ直してIPを再登録したのがポータルサイトの何らかのエッジケースを踏んだのでは? などと勝手に邪推しています。謎ですね。

そのほか、 campaign の値を変えると何が変わるのか (POST系アクセスが増える?)、みたいなことも終了後にログを分析してようやくなんとなく傾向がわかり悔しい気持ちに。

感想

終わってみれば途中重大な気付き (「外部APIのレスポンスキャッシュできるじゃん」「ユーザの嗜好に合わせて商品出し分けたら?」など) があり、見逃しの多い回でした。
bcrypt の件は全く気づいておらず。前回は初手でやった(があまり意味がなかった) pprof を今回なぜ見なかったのか……

短い時間で追い詰められている環境の中でどれだけ集中できる / 気付けるか、というのが重要になると改めて感じました。

コンテストとしては今回も設定が面白く、運営の手の込みようが分かり、かつ短期間で取り組みがいのあるとても良い問題でした。
運営の皆様、大変お疲れさまでした。

正確には、Amazon.co.jp を見たら異常に高くてそりゃ転売したら儲かるな、という気持ちになったので、適当に人を募って Amazon.com (US) で共同購入しました。
関税や送料を足した結果、YubiKey 5 NFC が5500円, YubiKey 5C が6100円ぐらいで買えました。良かったですね。

YubiKey といえばそもそも OTP が出てくるキーボードとして認識されるデバイスですが、最近だと WebAuthn で使えたりしますね。あとは PKCS#11 の署名用や適当な鍵を登録できたりします。

雑に手元の macOS でssh するぞ、と思ったら地味にハマってしまったのでいろいろやった結果動くようになったのでメモ

手順だけ分かればおっけー！という方は Gist にパッチ等まとめたので、そちらを参照してください: https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

検証環境のバージョンは macOS Mojave 10.14.4 で、OpenSSH は 7.9p1, LibreSSL 2.7.3 が入っていました。
ただ、今回は最終的に OpenSSH と OpenSSL は自前でビルドしたのであまり関係ありません。
より重要そうな Homebrew でインストールしたパッケージのバージョンは、 OpenSSH 7.9p1, OpenSSL 1.0.2r (26 Feb 2019), OpenSC 0.19.0 です。

まず、下記の記事などを参考に鍵の生成を試みます。

Putty CAC で SSH に YubiKey を使う(OpenSC編) – enjoy struggling
https://blog.haniyama.com/2018/02/02/yubikey-ssh-opensc/

GUI のツール (YubiKey PIV Manager) の場合は PIN を設定すると自動的に Authentication と Key Management 用の鍵を生成してくれます。現代だとデフォルトで ecdsa-sha2-nistp256 の鍵が生成されるんですね。便利。

公開鍵を取り出そうとした

YubiKey へのアクセスや署名(でよいのでしょうか?) にはスマートカード等で使う OpenSC を使用するようです。今回は Homebrew でインストールしました。 (brew install opensc)

早速試してみます。まずは上の

# ssh-keygen -D /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so
C_GetAttributeValue failed: 18
C_GetAttributeValue failed: 18
cannot read public key from pkcs11

うまく行きませんね。(上手く行った場合はこの記事を読む必要はありません。最後のステップまで飛ばしてください。

パッチを当てる

エラー文でググると偉大な先達の記事が出てきます。今回この記事がなかったら即死していたでしょう。

ssh with yubikey ECDSA keys – lithium03の物置
https://lithium03.info/yubikey/index.html

この記事を読むと、「RSA鍵なら問題なくいける」「OpenSSH が OpenSC を使うときに (具体的には PKCS#11 の署名等で) ECDSA鍵に対応できてない」ということが分かります。

親切にパッチや、そのパッチの元になったチケットまでリンクがあります。

2474 – Enabling ECDSA in PKCS#11 support for ssh-agent
https://bugzilla.mindrot.org/show_bug.cgi?id=2474

このチケットを見ると、Fedora 28 では既にこのパッチがバックポートされていること、upstream には OpenSSH 8.0 でマージされる予定であることが分かります。

ちなみにパッチは OpenSSH 7.6p1 用で、上の記事では 7.8p1 用に書き換えられたものが公開されていますが、現時点の Homebrew でインストール可能なのは 7.9p1 ということで、パッチを修正しました。

というわけでパッチです: https://gist.github.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8

ビルドする

Homebrew でパッチとかどうやるんだ……と思いましたが、どうやら brew edit openssh で行けるみたいです。こんなに簡単に当てられるなんて……便利だ……

Homebrew: Patching an existing package
https://www.ralfebert.de/snippets/brew-apply-patch-to-package-formula/

というわけで雑に既に書かれている patch の下に、以下のように追記してやるとパッチが当たります。

# Add support ECDSA for PKCS11, ref: https://bugzilla.mindrot.org/show_bug.cgi?id=2474
patch do
  url "https://gist.githubusercontent.com/kyontan/763952e7be68a2e96d5c3f0ad0d3bce8/raw/2ad5f854eba7704fbb7af2182ac57ee82b9a8f61/openssh-7.9p1-pkcs11-ecdsa.patch"
  sha256 "93b4e48321db94d785833a9414b12467a4741156cec90fa3052a4092acec8938"
end

インストールは brew install --build-from-source openssh です。既にインストールしてあるものがある人は install を reinstall に読み替えてください。

ビルドできたら、ビルドした ssh や ssh-keygen のパスをよしなに通してやります。勝手に通ってるかもしれません。(rehash なりしてから ssh -V の結果を見るとかすれば分かると思います)

うおおおおお！！！！

# ssh-keygen -D /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDnIbZ4ANu...
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBv0e8HKnx...

というわけで公開鍵が見られました。2つ見えたのは、上で自動的に作られると行っていた Authentication と Key Management 用の鍵がどちらも見えてるからだと思います。普通は上の方を使えば良いはずです。

鍵を登録して、ssh していきます。 ssh -I /usr/local/Cellar/opensc/{version}/lib/opensc-pkcs11.so host です。

# ssh -v -I /usr/local/Cellar/opensc/0.19.0/lib/opensc-pkcs11.so user@xxx.monora.me
OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
...
debug1: Connection established.
debug1: provider /.../opensc-pkcs11.so: manufacturerID <OpenSC Project> cryptokiVersion 2.20 libraryDescription <OpenSC smartcard framework> libraryVersion 0.19
debug1: provider /.../opensc-pkcs11.so slot 0: label <Yubico PIV Authentication> manufacturerID <piv_II> model <PKCS#15 emulate> serial <...> flags 0x40d
debug1: have 1 keys
debug1: have 2 keys
...
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Will attempt key: /.../opensc-pkcs11.so ECDSA SHA256:Z7dluZC4FCEsUAC0HYiITr5+I83bLtHUxOwdla81Rtc token
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
debug1: Server accepts key: /.../opensc-pkcs11.so ECDSA SHA256:nr/MvmFI6cYmChV97dMVIBeE2Uq5UmhVvoIdIuayLvg token
Enter PIN for 'Yubico PIV Authentication':
debug1: Authentication succeeded (publickey).
Authenticated to xxx.monora.me ([xxx.yyy.zzz.www]:22).
...
# sl
...

というわけで ssh 出来ました。嬉しいですね。

パッチを見て当ててみたらエラーが出た瞬間にやる気をなくして、うだうだやっていたら3時間ぐらい掛かってしまいましたが、なんとか動いてよかったです。

それでは皆さまもハッピーYubiKeyライフをお過ごしください！

チーム「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年越しでそれを達成しました。

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

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

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

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

• SELECT * する系のクエリを必要な列しか取らないようにした
• /api/users は user_id で reservations を全部とってきて、アプリ側で処理してやったらめっちゃ速くなった
  • ここでベンチマーカが重いと言ってくるエンドポイントが /users/:id から /api/events/:id/actions/reserve になった
• getEvent を getEventWithoutDetail と分けた
• getEvent と getEvents を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時間よりは良かったのではないかと思います。

ISUCONの予選に向けて昨日は練習をしていたわけだけど、知っていることをちゃんと愚直にできれば比較的現実的な時間で予選突破ラインには十分立てることが分かったので良かった

— kyontan@新刊はまだ (@sukukyon) September 14, 2018

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

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

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

以下は画像です

寒いです。12月10日です。10日ということは、 whywaita Advent Calendar 2017 の10日目ということです。なんとあと1枠らしいです。

9日目は @kadokusei (~= @hyr3k) さんで 体重 – /var/log/ でした。

ところで文脈もなにもないですが Just Because! が良いです。小宮恵那さん……

さて先日、 Twitter を眺めていたところ 「真っ赤な“1/4Uサイズ”のブレードサーバーが税込4,980円で大量販売中」  という記事が流れていました。
Core i5-2520M@2.5GHz / RAM2G / Diskless という構成ですが、Intel の GbE NIC x4 があるなかなか変態なマシンです。5000円だったのでつい3台買いました。IPMI もあります。ちなみに1台当たりで RAM が 4GB でした。

kamijin_fanta さんという方がこれに VyOS on Hyper-V をやっている記事があるので、こちらもご参照ください。

赤鯖にVyos入れて最高のインターネッツを手に入れた

これは A.T.WORKS というメーカーの国産サーバで、謎です。とりあえずドキュメントとかファームウェアの更新は公式ストアのダウンロードページに転がっています。

何故かシャーシも付いてきたので適当に突っ込みます。10台入るので、あと7台追加できますね。とはいえ部屋の室温で冷却するにはこの程度の密度が限界かと……

画像の左下にある赤いやつがそれです。雑ですね。周りも汚いですね……

さて、ディスクレスとはいえ開けてみると SATAポートもディスクベイもあるので、2.5インチのHDDを買えば普通に使えるでしょう。
しかし先立つものがなく、しかし他のサーバは余っているのでネットワークブートさせて遊んでみることにしました。

PXE とは

PXE とは…… ざっくりと説明するとネットワークブートのための仕組みの1つです。
NIC に書き込まれたPXEブートローダが、ネットワーク上のサーバから OS のカーネルを取得して起動する方法です。

基本的には起動時に DHCP でIPアドレスを取得する際に、サーバが IPアドレス等の情報と一緒にカーネル等が置かれているサーバ(TFTPサーバ)のアドレスを返すことで実現されます。
いわゆる大量のPCを管理する手間を減らしたい(~ シンクライアント化したい) 大学なんかでよく見かけますね。MMA部室の端末でも同様の仕組みを採用しています。
もちろん一般的な誤家庭でも、DHCPサーバとTFTPサーバ等を立てれば実現できます。近年では PXE を発展させた iPXE などもあります。こちらだと例えばカーネルを通常の HTTPサーバから取得するようにできたりします。便利ですね。

実際の実現にあたっては、 「PXE 構築」なんかでググって頂ければ山のように日本語の資料がヒットしますので割愛します。

Container Linux

今回はこれを用いて CoreOS Container Linux を起動させ、自動的に Docker Swarm クラスタを構築したいという話をします。

Container Linux は CoreOS 社が開発している、コンテナ基盤のための軽量Linuxディストリビューションです。docker や etcd と言ったコンテナで用いるソフトウェアがデフォルトで入っているほか、fleet というクラスタマネージャ (というか分散 systemd) なんかがデフォルトで入っています。
CoreOS 社は他にも Docker Registry の Quay やコンテナランタイムである rkt や cloud-config の代替を狙っている Ignition, エンタープライズ向け Kubernetes こと Tectonic の開発なんかもしていますね。

もうお察しかと思いますが、 Container Linux には fleet というクラスタマネージャがあり、更に Tectonic があります。つまり、 Docker Swarm の文脈にはかすりもしません。イケイケな皆さんは Kubernetes を構築すると便利だと思います。
(実は Kubernetes クラスタを構築しようとしたらオンメモリファイルシステムでは容量が足りなかったので Docker Swarm でお茶を濁しています)

CoreOS は今回のよう物理ホスト(ベアメタル)に対して直接プロビジョニングをするためのプロダクトも用意しています。 Matchbox です。使ってください。
今回は使いません。

起動してみる

CoreOS はもちろん PXE での起動に対応しており、簡潔なドキュメントがあります。 これに従えば簡単に起動までは行なえます。やってみましょう。

最終的なディレクトリ構造としては以下のようになります。
/tftpboot は適宜 tftp のルートディレクトリに読み替えてください。また、 pxelinux.cfg/default の内容は下に書いてあります。

/tftpboot
├── coreos
│   ├── coreos_production_pxe_image.cpio.gz
│   └── coreos_production_pxe.vmlinuz
├── pxelinux.0
└── pxelinux.cfg
    └── default

default coreos
prompt 1
timeout 15

display boot.msg

label coreos
menu default
kernel coreos/coreos_production_pxe.vmlinuz
initrd coreos/coreos_production_pxe_image.cpio.gz
append coreos.first_boot=1

さて、対象のマシンは起動したでしょうか? 手元では30秒ほど OS の読み込みに掛かったあと、OS本体が約4秒で起動してくるのが観測できました。速いです。

ただ、おそらくログインもできず、ssh もできないでしょう。直接本体に接続されている端末にログインしたい場合は、ドキュメントにある通り、 coreos.autologin を設定すれば可能です。

実際にもうこれで fleet で遊んだりできます。この状況では、 /(rootfs) がメモリ上にあるので、メモリの空き容量分しか書き込むことができませんが、メモリが潤沢にあればこの上に Tectonic や kubeadm を用いて Kubernetes を構築したりもできるでしょう。ちなみに 4GB では足りませんでした。

Docker Swarm

Docker swarm というのは Docker 本体に取り込まれたクラスタリングの機能です。複数のノードでサービスという単位でコンテナの管理が行えます。
Docker 本体に統合されているので、Container Linux に docker がデフォルトで入っているということはそのまま docker swarm mode で既存のクラスタに join させればそのままクラスタの一員となります。
クラスタにはマネージャとワーカの区別があり、マネージャは Raft アルゴリズムで分散合意を行うため、本来であれば耐障害性のためにも3以上の奇数台を用意することが望ましいですが、今回は DHCP/TFTPにしたサーバをそのまま使います。

# docker swarm init
Swarm initialized: current node (hogefuga) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-... 10.0.xxx.yyy:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

上で表示されているコマンドを起動時に入力させればそのまま docker swarm のクラスタにジョインしてくれるでしょう。やっていきましょう。
(ちなみに、デフォルトでは docker swarm のマネージャ自信もコンテナが起動するホストの1つとなります。次のコマンドを打てばそのノードではコンテナが起動しなくなります。 docker node update --availability drain)

Ignition Config

起動時に任意のコマンド等を実行する方法といえば、あの cloud-config がありますね……
Container Linux では最近 Ignition というものに置き換えられました。直接書いてもいいですが、 cloud-config の記法で書いたものは ct (config-transpiler) というコマンドを用いて変換することができます。
ちなみにオンラインのバリデータがあって、 どちらの記法でもここでバリデーションができます。

では用意しましょう。ついでに ssh できるように authorized_keys なんかも追加できます。 ssh したくない? 確かに。
ともかく systemd unit を2つ書くだけです。ところで docker-swarm-leave.service がちゃんと動いてない気がするのでどなたか教えてください。

passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ecdsa-sha2-nistp256 ...
systemd:
  units:
    - name: docker-swarm-join.service
      enabled: true
      contents: |
        [Unit]
        Description=Docker swarm join script
        Requires=docker.service
        After=docker.service

        [Service]
        Type=oneshot
        ExecStart=/usr/bin/docker swarm join --tokenSWMTKN-1-... 10.0.xxx.yyy:2377

        [Install]
        WantedBy=multi-user.target
    - name: docker-swarm-leave.service
      enabled: true
      contents: |
        [Unit]
        Description=Docker swarm leave script
        Before=shutdown.target reboot.target halt.target

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/bin/true
        ExecStop=/usr/bin/docker swarm leave

        [Install]
        WantedBy=multi-user.target

さて、このファイルを実際に起動時に渡すためには ct で変換したり、 newc 形式のアーカイブにしたりする必要があるのでやります。

$ mkdir usr/share/oem
$ ct < container-linux.config > usr/share/oem/raw.ign
$ find usr | cpio -o -H newc -O oem.cpio
$ gzip oem.cpio

結果的にでてきた oem.cpio.gz を以下のような感じに配置します。

/tftpboot
├── coreos
│   ├── coreos_production_pxe_image.cpio.gz
│   ├── coreos_production_pxe.vmlinuz
│   └── oem.cpio.gz
├── pxelinux.0
└── pxelinux.cfg
    └── default

また、 pxelinux.cfg/default も修正します。は以下のようになります。 oem.cpio.gz を読ませているのと、実際にそれを参照させている部分の2箇所です。

 
default coreos
prompt 1
timeout 15

display boot.msg

label coreos
menu default
kernel coreos/coreos_production_pxe.vmlinuz
initrd coreos/coreos_production_pxe_image.cpio.gz,coreos/oem.cpio.gz
# append console=tty0 console=ttyS1 coreos.autologin=tty0
append coreos.first_boot=1 coreos.config.url=oem:///raw.ign

さて、起動させて見ましょう。マネージャ側で docker node ls とか叩けば分かると思います。
いい感じになりましたでしょうか?

あとは docker service コマンドでよしなにサービスを作ってやると、いい感じにロードバランスされたりヘルスチェックしたりライブアップデートできたりすると思います。
ポートの公開をすると、マネージャを含む全てのノードでそのポートが共有され、自動的にロードバランスされます。つまり、そのサービスのコンテナが動いていないノードにアクセスしても、内部のトンネル(VXLANです)を通ってコンテナへの疎通性が確保されます。

そのあたりは「docker swarm」とかでググると出ると思います。 nginx とかでも簡単にできますね。

ところでボリュームのマウントは癖があって、 bind なんかは各ノードのローカルファイルシステムを参照します。なので、そういったことをしたい時はよしなにやりましょう。 nfs とかを検証できると良いですね。

ちなみに再起動したりするとどんどん死んでるノードが一覧に増えますが気にしないでください。気になる時は docker node rm で消しましょう。以下がワンライナーです。

 
docker node ls | tail -n+2 | grep Down | cut -d' ' -f1 | xargs -r docker node rm"

さて、今回は簡単に Docker Swarm を用いたクラスタの構築をしてみましたが、実際により大きい規模でやろうとすると Kubernetes や DC/OS (Mesos, Marathon) なども候補に入るかと思います。
そちらについてもやっていきましょう。

ところで Docker / CoreOS をプロダクションでバリバリ使うサービスに興味のある方向けに、 こんな求人やこんな募集があります。もしご興味ありましたら Twitter 等でも良いのでお声掛けください。

では皆様、よいコンテナライフを!

Ruby実装で挑み、最終スコア 38605点@2017-10-22 20:59:30, ベストスコア: 67792点@2017-10-22 20:44:59 でした。
ベストスコアでは予選ラインは超えていたんだなあと思いますが、最終的には伸び悩んだチームも多いようで、結局落ち着くところに落ち着いたのかなと思います。

ソースコードは kyontan/isucon7_qual です。踏み台でやっていた影響でコミッタが僕に見えますが、だいたい僕ではない。

次回も参加したいなという気持ちになってきたので、ひとまずはやったことを記していきます。

実は僕と @hogas は ISUCON6 の夏期講習に出たことがありましたが、そのときには日程等もあり参加しておらずということで、今回が初参加に。
@h-otter というインフラにとても強い同期がいたことや、周囲でも参加する人間が何故か多く、とにかくやっていくしかないという流れに。

チーム名を決めるところで消耗/摩耗し、本番前日までSlackはほとんど流れておらず。前日夜になって僕とか @h-otter がぽちぽち参加記やチューニングできそうなところを貼っていく感じに。

最近、正午より前に起きると早起きしたと言い出す僕が時間に間に合っていたあたりで色々とミスっていたんですが、東京都内の某所で3人で集まってやっていました。

事前にやった

とりあえずグローバルIPを持つ作業用サーバを用意しておいた。Rubyは事前に入れておいて、開始後に MySQL  も入れてスタンドアロンで動くようにした。あとあと @hogas はここでずっと作業してたり、 @h-otter が Prometheus のサーバを立てたりしていた。便利

コードについては GitHub リポジトリを立てて、普通にブランチ切ってやっていた。便利

情報共有は対面だったので、コードスニペット貼れるしリアルタイムで最高な HackMD を例のごとく使っていた。ベンチマーカの結果を全部ペタペタ貼っていたら容量制限に引っかかり、2スレ目、3スレ目が誕生した。HackMDのタイトルは「ISUCON7 まだチーム名で消耗してるの? 2スレ目」でした。

やったこと

ミドルウェアより下は正直 @h-otter に丸投げしていたので、アプリケーションより上をぽちぽち見ていました。
インフラについては正直何をしたのかは全容を把握していないですが、初手で nginx や MySQL に基本のチューニングを突っ込み、Prometheus で延々と監視しながらPDCAを回していたっぽい。正しいインフラチューニングや……

言語は僕と @hogas が使い慣れている Ruby を選択しました。正直クエリ弄るぐらいでいいなら Go でもいいよねーって言っていましたが、慣れてるほうが便利でした。Sinatra の文字列には幼馴染のような安心感がある。

僕と @hogas はよしなにアプリケーションコードを読みながら色々した。以下は色々

erb を haml に置き換える / hamlit gem の導入

気持ち+2000点ぐらい

初期実装が erb で、erubis に置き換えるというのも一案ありましたが、行きの車内で「erubis hamlit 速度」などで検索した結果やっぱり hamlit かとなっており、ノータイムで haml に書き換えることを決断しました。
erb2haml とかあったね〜と @hogas と話しながらやってもらった。

以下様子です

. @hogextend 「erb2hamlどうやって使うの?」ぼく「とりあえず rails new して突っ込んでみたら?」 #isucon

— きょんたん (@sukukyon) October 22, 2017

僕「ﾖｯｼｬ(gem install rails)」

— hogas (@hogextend) October 22, 2017

(erb2haml はコマンドラインツールとかではなく、Rails に追加する rake タスク群ということに気が付いた様子)

nginx <-> Puma を UNIXドメインソケットに

気持ち +2000点

定番です。HTTP 5000/tcp から UNIXドメインに変えた。

SQL のクエリ改善

気持ち+10000点ぐらい

これは定番ですね。SELECT のカラムを絞ったり (@hogas)、 LIMIT を付けたり (@hogas)、インデックスを張ったりした。N+1 は手を付けていましたが、コード変更に集中できなくて最終的に投げてしまった。悔しい

終了直前にソースコード眺めてたら statement.close を意図的に忘れていそうなコードが見つかり慌てて修正した。スコア上の変化は分からず。

 画像を静的ファイルに書き出す

気持ち+15000点ぐらい

ユーザーのアバター画像が DB に blob で入っていたので、雑に Ruby のワンライナーで書き出して (ここまで @kyontan)、 nginx に try_files で食わせる (@h-otter) みたいなことをした。
既に話題になっていますが、最終的には Cache-control 的な問題でキャッシュヒット率が悪かったらしい。むむむ。

SHA1 を殺す (パスワード, アバター画像)

気持ち+2000点

パスワードのソルトを生成している random_string を見たときに、これは要らないのではと思ってしまったのが始まり。初期データのパスワードはハッシュ化されていたので、 id が1000より大きい user は全て平文パスワードを DB に突っ込んだりした。 (by @hogas)
アバター画像は、ファイルの内容を SHA1 したものをファイル名に使用する実装になっていましたが、もしかしていけるのではと言いながらユーザIDをそのままファイル名にしたら通ってしまったのでそのままに。

Redis (最終的に入れず)

気持ち+2000点ぐらい(?)

画像をバイナリで入れるのはまあそうだね〜〜と言いながら、Redis に載せようとしていた。正直コードの変更は大したことがないのは分かっていたので実装はシュッとできたけれど、実際に動かしてみると意外とスコアに有意な差が出なかった。その後も永続化周りで少し足踏みしていたり、他の変更を見ていたために最終的に入れられなかった。残念

アプリケーションサーバ3台化

気持ち +3000点ぐらい

@h-otter がラスト30分でイケると言い出してやってた。ここで Puma (アプリケーションサーバ) のスレッド数を調整していた (10 -> 18スレッド)時に出したのがベストスコアです。

その他

• 再起動試験は何の問題もなかった????
  • 過去の参加記なんかを見てるとここが関門かなというのはあったので絶対やっておきたかった (やりました)
  • Redis に手を出してなかったのでここで不安はあまりなかった
• MySQL の Too Many Connections が割りと頻発した
  • ここは statement.close 忘れも影響してるかなと思うけれど、500が途中で出たり安定しないことがあった。最終的には安定しました
• 日ごろは頭痛の頭の字もないのに、とにかく頭痛が酷かった。緊張にはやはり弱い。
• JSONシリアライザが遅いのは分かっていて、 Oj を入れるぞと言いながら入れるのを忘れた。あれを入れただけでシリアライズについては数倍速くなるというのは分かっていたので、ただただつらい。
• ICTトラブルシューティングコンテストでスコアサーバを延々とやっていたことが知見として生きたとは思う。DB設計なりアプリケーション設計なりチューニングなり。
  • 当時のオーバーキルなチューニングしたときの操作が生きることになるとは思ってなかった
• 最後のベンチマークの結果を見て全員で嘘やんって言ってた
  • ルールを読んでなかった。次回は読みます
  • にゃーん

そういえば30分ほどですがスコアボードの上位に乗っていました。学生トップなのは分かっていたので、これは予選突破できるんじゃない? とか言いながら笑っていたのを覚えています。このあたりが後々ボーダーになるんだろうな〜という話をしていて、実際そうなったのである程度読みは正しかったのかなと思いつつ。

総括/最高

監視に強い人(@h-otter)強い。常に横で IOバウンドかネットワークバウンドか、みたいなことを見ながらアドバイスしてもらえる環境は最高。

限られた時間の大会という環境でもくもくとコードいじれる人(@hogas)強い。とにかく僕が頭が回ってなくてコードをまともに書けない状況にあったので、そんな中でちゃんと改善する変更を入れ続けてくれて最高。

基本的にどこに手を入れればいいか、この変更はコスパ的にどうかみたいなことを常に考えながら立ち振る舞えてはいたと思うので、そういった点ではなかなか善戦はできたかなと思いつつ。
しかし、できたことは山のように残っているなという感想。、途中で集中力が切れてしまったこともあり、こういう結果になったのは悔しいなと思う。

ただ、これだけ言えるというのはつまりバランスが最高だということに他ならなくて、こういった駆け引きができるバランスのゲームを作るのはとにかく難しいなと思っているだけに最高だな！！！という気持ちです。
こんな最高のコンテストを生み出してくれた運営の皆様、ありがとうございました。そしてお疲れ様でした！

本選に行かれる皆様はぜひとも頑張ってほしいなと思うところです。

次回は最高の♨️から最高の心構えでやっていきたい。

成果物は kyontan/datadog-zabbix-history です。

長い前置き

ところで皆様は Datadog を使われていますでしょうか?
インフラ監視系の SaaS やソフトウェアというと、今挙げた Datadog を始め, Mackerel や Zabbix, Nagios, AWS Cloudwatch 等々、現状では様々なプロダクトが存在しています。最近だと Datadog や Prometheus の名前をよく見かける気がします。

そんな中最近、自分のバイト先では使われているのが Datadog です。サーバの監視なんかだと、 Integration の種類も多く、デフォルトで様々なメトリックが取れることや、ダッシュボードの見やすさなどがイケているかなと。
特に SaaS だと、バッファリングがあるにしてもメトリクスの抜け落ちや一時アクセスできなくなる問題などはあり、クリティカルなものを全部載せるわけにもいかず、ただ SaaS の恩恵は受けたいというのが正直なところでしょう。
(mackerel-agent のログを眺めているとたまに何故か 404 が返ってきていて笑います)

ただ、設定が複雑化したり、そもそも設定数が多くて移行がダルいというのが正直なところです。エイヤでやる体力があれば良いですが、ホスト数が増え、監視項目が万の単位であるとそれはそれは……

おそらく皆さんは Zabbix のアイテムやらなんやらを XML で書き出してごにょごにょしたり、それを Prometheus の設定にいい感じに変換する何かを書いたりされているかと存じます。そしてそんなコードは短いから/特定のドメインに特化しているからと公開せず、誰もが誰かは書いているだろうと思いながら書いていることでしょう。そうですよね?

今回ご紹介するのはそんなあるあるプロダクトです。やることは記事のタイトルに書いてありますね。

本編

最初にも書きましたがこれ (kyontan/datadog-zabbix-history) です。実装としては、Zabbix の DB からメトリクス (Zabbix でいうアイテムのヒストリ) を勝手に拾ってきます。
いい感じに動きます。良かったですね。

現状イケてないところが1つあって、 dd-agent は独自の組み込み python を使うので pip で入れたパッケージを読んでくれません。インポートパスを弄ります。良くないですね。

まだ、とりあえず動くというところなので、様子を見ていきたいですね。

ICTSC6 で CloudStack を使用していた話はまだ書いていなし多分書かないですが、使用していました。

その中で、API を叩いてくれる薄っぺらいラッパーコマンドであるところの exoscale/cs を叩いてデプロイなりVMの起動停止なりボリュームのアタッチなどをやっていたわけですが、デプロイ関連で少しハマったので解決策を紹介。

ちなみにこれ: https://github.com/exoscale/cs。 exoscale 、 CloudStack なんですかね……

CloudStack の API はあまりにも愚直なのでパラメータが無限に多くてしんどいという話はさておき

APIの一覧は http://cloudstack.apache.org/api/apidocs-4.9/ にあります。 (4.9 の場合)
VM を作成する場合は、 deployVirtualMachine

書いてある通りですが、必須なパラメータは以下の3つです。

• serviceofferingid
• templateid
• zoneid

それとは別に、IPアドレスを固定したり複数のネットワークにVMを接続するときは iptonetworklist パラメータを指定するわけですが、このパラメータの設定がなんもわからんという感じです。

iptonetworklist[0].ip=10.10.10.11&iptonetworklist[0].ipv6=fc00:1234:5678::abcd&iptonetworklist[0].networkid=uuid

難しすぎる。なんで突然配列の演算子が出てきて & で繋ぐ必要があるんだ……

実際に直に API を叩いたことはないのですが、 cs ではこの通りにパラメータを書いても上手く動いてくれません。
なので、以下のようにする必要があります

cs deployVirtualMachine ... iptonetworklist[0].ip=192.168.15.3 iptonetworklist[0].networkid=4bbc38e5-3e36-4a11-9c93-5a5261911120

ただ & で繋げずにスペースで区切るだけです。どういう挙動なんだろう……
どこにも仕様が載っていないので試行錯誤せざるを得ないわけですが、やっていきましょう

結局 cs コマンドの引数はこんな感じになってしまうので非常に読みづらい。各位 Ansible のパワーに頼っていきましょう。僕は Ruby でラッパーを書きました。

cs deployVirtualMachine displayname='vm1-p15-t7' name='vm-x-hoge' serviceofferingid='3ebb38bf-dbb6-42b1-b301-041d3546b5dc' templateid='cec5838f-1bae-442f-9009-9e27dcf33941' zoneid='57305097-d51a-467b-bbec-862ab20850d1' hostid='3edc5cc0-5375-462d-8a38-b2e4920791f4' account='xxx' domainid='1d43bf7b-b00c-41ba-959a-e422c4649547' startvm='false' iptonetworklist[0].ip=192.168.15.3 iptonetworklist[0].networkid=4bbc38e5-3e36-4a11-9c93-5a5261911120