ISUCON11予選に出場し53398点で予選敗退しました #isucon

2021/08/21に開催されたISUCON11 予選にチーム「TF」で出場しました。
ISUCON (Iikanjini Speed Up CONtest) についてはこちら→ https://isucon.net

変更履歴

・2021/08/27 18:41: ISUCON11 オンライン予選 全てのチームのスコア(参考値)の順位に更新(68位→67位)

チーム

どちらも初参加の2人で参加しました。言語はGolangを選択しました。

  • maruTA-bis5 (@maruTA_bis5) ←me
    • 普段はJava/PostgreSQLで仕事してる人。GolangわからんけどJavaで再実装する時間はない
    • 開発担当
  • yulis452
    • AWSエンジニアのはずなのに最近物理のインフラを触っている人。開発わからん
    • 情報担当

予選結果

運営の計測による最終スコアは53398点、全体の67位で予選敗退しました。
ベンチマークの履歴は以下。ちなみに初回ベンチ = 10:08:38 の4149点は、当時暫定1位でした。やったね。

やったこと

事前準備

yulis452は開発ノータッチの方針が決まっていたので、手を動かす練習としてISUCON10予選、10本戦、11事前講習をときました。GolangはMattermostのソースを少し読み書きした程度だったので実装面は割と怪しめでしたが、初動での計測ツール設定をある程度Ansibleで行うことを検討していたので、playbookを整備して、早く開発に入れる準備をできた、と最後の練習を終えた時点では考えていました。

予選当日

※当日はサーバーリストの表示順で上から1号機〜3号機と呼称していたため、以下同様に記載します

予選ライブでISUCONDITIONの紹介を見て、いざ始めようとansible-playbookを叩いたらいきなりエラー。pt-query-digestのためのslowlog設定が/etc/mysql/mysql.conf.d/mysqld.cnfを前提にしていたところ、MySQLではなくMariaDBがインストールされていてコケました。
今思えばそこでMySQLに入れ替えるともできたと思いますが、なぜかpt-query-digestを諦めてMariaDBのまま進む方針としました。この時点ですでにテンパってますね・・・

ansibleでの設定が終わった段階で1号機に対してベンチマークを実行するとなぜかfailしました。同じ状態の2号機・3号機を指定したらfailしなかったので、以降は2号機をベンチ対象として指定する方針にしました。(後で運営からアナウンスがありましたが、ベンチマーカーの不具合があったようです。該当したのが弊チームのみという・・・)

DBを3号機に移し、New Relic APMを設定したところで12時、スコアは1000点でした。

前日に調達してあったコンビニ弁当を食べつつ、インデックスを追加したところで27000点台まで伸び、その後細かい修正をいくつか行っていますが、それ以上はすぐには伸びませんでした。

14時前、当日一番のやらかしポイントが到来します。
https://github.com/maruTA-bis5/isucon11-qualify/commit/bece0826949cf71a2ed50bebe11bcba64c1c008b
複数回INSERTするならバルクインサートにしてしまえ、という発想の修正でしたが、

“)”を”~”にtypoするという痛恨のミス。
これによってisu_conditionが全くINSERTされなくなり、加点要素がないためにスコアが1000点のまま変動しなくなりました。
多分冷静ではなかったのでしょう。この後色々な修正を試みますがいつまで経ってもtypoに気づかず、ポータル障害明けの18時過ぎになってようやく気がつきました。。。
紆余曲折あったときの修正の一部が原因でfailしていたのもあったのでrevertして、fail -> 45268点に復帰。すでに残り時間も少なく、これ以上コードに修正を加えるのはリスクがあると感じたため、これ以上コードに大きく手を入れるのは止めることにしました。

最後の調整としてDBのコネクション数を増加させてから、諸々ログ・計測を止めた状態で51198点。再起動試験としてsudo reboot後にISUCONDITIONにアクセスしてデータが入っているのを確認した後、再度ベンチマークを回して最高点の53478点で終了しました。最終スコアとは違いますが、ひとまず初参加ながらスコアを残せそうで一安心です。

感想

初手MariaDBや、午前中から数万点のスコアを出している他チームを見て、かなり焦ってしまったことが諸々のミスにつながっているように思います。普段の仕事でも、プレッシャーがかかるとミスを起こしがちなので、いかにプレッシャーを感じずに進めるかが重要そうです。

yulis452は開発はできないものの、情報整理を得意としているので、今回はマニュアルの確認とベンチ結果の考察をお願いしていました。特にマニュアルについては、「このデータについて加点に関係するか?」という聞き方でも適切に加点内容を説明してもらえたこと、当日マニュアルとは別にアプリケーションマニュアルも存在していたことを指摘してくれたことで非常に助かりました。
とはいえ、私自身もそこまで開発の手が早いわけではないですし、ISUCONの参考実装に頻出の言語に慣れていないので、もう1人開発担当がいれば例の凡ミスにもすぐ気がつけたかもしれないなぁ。

予選当日に使用したリポジトリは以下に公開しています。
https://github.com/maruTA-bis5/isucon11-qualify

[Eclipse][EGit] .projectがルートに配置されるようにGit管理する

前提: Gitのuser.name, user.emailが適切に設定されていること。

この記事の手順で作成したリポジトリは https://github.com/maruTA-bis5/git-init-eclipse です。

1. EclipseのProject Explorerより、Git管理したいプロジェクトを右クリックし、Team > Share Project…を選択する。

2. Share ProjectダイアログのUse or create repository in parent folder of projectを選択する。

3. 対象のプロジェクトを選択し、Create Repositoryボタンをクリックする。

4. Finishをクリックする。

ここまででローカルリポジトリが作成されます。次は初回のコミットを行います。

5. Git Stagingビューを開く。

6. Unstaged ChangesのファイルをStaged Changesに移動し、Commit Messageを入力してCommitをクリックする。
このとき、*.classファイルは表示されていませんが、*.classファイルが出力されるディレクトリは.gitignoreに記載されているため無視されます。他にも無視するファイルがあれば.gitignoreに追記しておきます。
.gigignoreはProject Explorerには表示されないので、このタイミングで修正するか、Git Repositoriesビューから開く必要があります。

初回コミットが完了したら、リモートリポジトリにpushします。(リモートリポジトリでの管理が不要ならここまで)

7. Git StagingビューのPush HEADボタンをクリックする。

8. Location > URIにリモートリポジトリのURL、認証が必要ならAuthenticationを入力しPreview >をクリックする。
画像ではSSHを使用する形で入力していますが、HTTP(S)でも問題ありません。
パスワード認証が必要な場合は、Authenticationを入力しておきます。

9. ブランチの指定は基本的に変更しなくて良いはず。前のステップで入力した認証情報に誤りがあればこの段階でエラーが表示されるので、一度戻って修正する。問題なければPreview >をクリックする。

10. pushのプレビューを確認してPushをクリックする。

11. pushが完了するとpush結果が表示される。失敗した場合もこのダイアログが表示されるので、必ずMessage Detailsの内容を確認する。

Mattermost Apps Framework をJava (JAX-RS)で試してみた

Mattermostと他のアプリケーションを連携する新しい方法として、Mattermost Apps FrameworkがDevelopers Previewとして利用可能になりました。

https://developers.mattermost.com/integrate/apps/

Appsの説明としてBe written in any language.と説明されており、せっかくなのでJavaで試してみました。普段仕事で使うのはJavaなので。。。

リポジトリ: https://github.com/maruTA-bis5/mattermost-apps-example-java

Appsを作るのに最低限必要なことはkaakaaさんの記事やQuick startを読んで頂くとして、それ以外に/installがOKのレスポンスを返さないとインストールに失敗するようです(画面上や/apps listでは問題ないように見えるが、Failed to install appのログが出力される)。mattermost-plugin-appsのコミット0cae0b3fadb7bfae03ffc015cab28654e4bf2d31で確認しました。

Java App側はJAX-RSでサクッと。Quick startではいくつかのjsonファイルを作成してそれをGo側で読み込んで返却するようにしていましたが、動的に生成できるようにデータモデルとJacksonを使っています。

内容としてはQuick startと同じなので代わり映えはありませんが、Goでなくても同じ挙動のAppsを作れるということは確認できました。より複雑な処理が必要になってくるとApps APIを利用することになりますが、Apps Pluginが提供するREST APIなのでそこまで難しくはなさそうです。

Pluginと違って、Go以外の言語でも簡単に作れるのは良いですね。

無理だと思ってたら結局毎日書けたのでAdvent Calendar振り返り

※この記事は丸太式 Advent Calendarの25日目です

まさか最後まで書けるとは思っていなかった

25日目です。

仕事で帰りが23時になる日も多かったですが、自分でもよく書けたと思っています。
何日か日付またいだけど

Advent Calendarの記事はAdventarにまとめてあります。
http://www.adventar.org/calendars/402

おおむね技術系の記事になっています。そういう仕事だし仕方ないね。
どうせ記事を書くなら業務からネタを持ってきたかったのですが、自社フレームワークだったりバージョンが若干古かったりしたので、あまり書くことがありませんでした。

毎日アウトプットするのは大変でしたが、来年は隔週くらいで何かしら出力していきたいです。

さて、明日は仕事納めです。
仕事納まるかなぁ・・・

皆さん、良いお年を!

IT技術者「35歳定年説」について考えてみた

※この記事は丸太式 Advent Calendarの16日目です

IT技術者の定年は35歳であるという節、いわゆる「35歳定年説」がありますが、試しに検索してみると「本当だった」という声と「嘘だった」という声が両方とも見られます。

個人的な見解ではありますが、「35歳定年説」は嘘だと思っています。

まず、日本社会は年功序列の考えがまだまだ強く、IT企業であっても例外ではないということがあります。
会社側が”35歳定年”になってしまうキャリアパス、つまりマネジメントへの道しか提供していない為にこのような俗説が出現したのでしょう。

ただ、35歳だろうが45歳だろうが、途中で技術から離れてしまう様な人は技術者では無いと思っていますし、それまでどれだけの功績を残していても認識を改めることになります。
技術から離れてマネジメント側につく人は、技術にさほど興味が無かったのでしょうね。
本当に技術に興味があれば、現場から離れることはないでしょう。

確かに”プロジェクトマネジメント”は誰かがやらなければならないことですが、だからといって技術から離れるくらいならそんなものは技術者じゃない人に任せておけば良いのです。(技術を知らない人がマネジメントするという問題もありますが、技術から離れてまでマネジメントに専念するならあなたは技術者ではありません)

以上、個人の見解でした。
私が35歳になるまでまだ10年以上ありますが、そのときになっても同じような意見が言える技術者でありたいです。

今年も無謀な挑戦を始めます[Advent Calendar 2014]

※この投稿は、丸太式 Advent Calendar 2014の1日目です

無謀な挑戦=一人でAdvent Calendarを埋める

無謀ですね。
海外ではクリスマスまでのカウントダウンのために、Advent Calendarというカレンダーがあるそうです。
近年、日本のIT系技術者の間ではあるテーマに基づい12月1日から25日まで、日替わりでブログ等のエントリを書く催しがはやっています。

目的

一人でアドベントカレンダーを埋めることで、単純にアウトプットを増やすだけでなく、継続してアウトプットするきっかけにしたいと考えています。
挫折したら挫折したで、また来年がんばろうとは思いますが、去年も挫折しているので今年は毎日何かしら書きたいです。

今年のアドベントカレンダーは、「丸太式 Advent Calendar 2014」にまとめているので、気が向いたらご覧ください。

※去年の挫折した結果はこちら→http://www.adventar.org/calendars/256

GitLab環境のUbuntuを13.10->14.04にアップデートしたときにはまった話

GitLabを手動でインストールしていたUbuntuを13.10から14.04にアップデートした後、GitLabが立ち上がっていないことに気づいたので解決方法を記載します。

たぶんこの問題で一番厄介なのは、service gitlab startコマンド自体は正常に終了するってところです。
ブートログを見ても特に問題が見つからず、いつの間にかGitLabだけが落ちているように見えてしまいます。

環境

  • GitLab 6.6.5
  • Ubuntu 13.10 -> 14.04

原因

実はかなり単純な問題で、charlock_holmesというgemに必要なlibicuパッケージが更新されたことが原因です。
unicornのエラーログを見てみると、/home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.3/lib/active_support/dependencies.rb:229:in `require': libicui18n.so.48: cannot open shared object file: No such file or directory - /home/git/gitlab/vendor/bundle/ruby/2.0.0/gems/charlock_holmes-0.6.9.4/lib/charlock_holmes/charlock_holmes.so (LoadError)とあります。
ここに出てくるlibicui18n.so.48は、Ubuntu 13.10のlibicu48パッケージでインストールされたファイルですが14.04ではlibicu52となっており、そもそもこのファイルは存在しません。

解決法

charlock_holmes gemを再インストールする必要があります。
このgemはNative extensionが要るのでビルド時にlibicui18n.soのバージョンが固定されてしまいます。
若干面倒ではありますが、GitLabのインストールパス/vendor/bundle以下のcharlock_holmes関連ファイルを削除し、bundle installを再実行することで新しいバージョンのlibicui18n.soを参照するようになります。

まとめ

GitLabのUbuntu 14.04向けパッケージが提供されると幸せになれそうですね。
PPAでも良いけど。

Javaの勉強会を探しています

By: Michael SauersCC BY-NC-SA 2.0

Side Dにも書きましたが、おかげさまで就職できました。

会社で主に使う開発言語がJavaなのでどこかの勉強会に参加して知識を深めたいと思っています。
おすすめの勉強会があればぜひ教えてください。