かきあげせいろはラーメンがたべたい

技術プログラミングいろいろ記録メモ備忘にゃーん!

ISUCON12予選に参加しました!

これです。 isucon.net

毎年盛り上がっているのをTwitterで見つつも、自分はインフラが全然わからなかったのでいままで参加したことはありませんでした。 しかし一昨年ぐらいからインフラをちゃんと勉強していこうと決意していたことと、書籍「達人が教えるWebパフォーマンスチューニング」を読んだことでチャレンジしてみようという気持ちになったので思い切って参加してみました。

gihyo.jp

結果は惨敗でしたが、とても学びが多かったので久しぶりブログに記録します。

知識レベル

  • 普段はJavaでバックエンド、VueやAngularでフロントエンドを書く仕事をしています
  • インフラに触る機会はほぼありませんが、たまにデプロイのためにEC2をつかったノーマルな?インフラを触ることがあります

予選でやったこと

  • 開始と同時に展開されたマニュアルを読みました
  • 画面を一通り見ました
  • 初期状態でベンチマークを実行しました
  • 参考実装をJavaに切り替えました
  • この状態でベンチマークを実行しました
  • ソースコードをGit管理しました(ソースコードがどこにあるかを探すのに結構時間をつかいました。sysytemctlのserviceからたどればよかった…)
  • DBの接続情報をソースコードから探してDBアクセスし、テーブルなどを確認しました
  • mysql --help | grep "Default options" -A 1でDBの設定情報を探し、そこからログファイルの場所も探しました
  • ベンチマークを実行しつつtopをみて、DBのCPU使用率が支配的だったのでDBから着手することにしました
  • スロークエリログの設定をONにしました
  • pt-query-digestをインストールし、visit_historyテーブルに対してのクエリをチューニングすることにしました
  • SELECTで指定されているカラムを狙い複合INDEXを作成しましたcreate index player_id__created_at__idx3 on visit_history(tenant_id, competition_id, player_id, created_at);
  • 実行計画でINDEXが使われていることを確認し、再度ベンチマークを実行しました
  • 再度ベンチマークを実行しつつtopをみて、アプリの方がCPU使用率が高くなったので、alpをインストールしnginxのログフォーマットをalp用に変更しました
  • alpの結果からランキングを取得するエンドポイントが重い事がわかったので、処理内部にストップウォッチを仕込み、一番重そうな箇所を特定しました
  • プレイヤー情報取得部分がN+1になっていたので、処理前に一回のSQLで全取得するようにしました
  • 再度ベンチマークを実行し、スコアが上昇することを確認しました
  • スコアの上昇具合が他のチームと乖離しすぎていることに疑問を抱き始めました
  • 再度マニュアルを読み返したところ、initのエンドポイントがスコアにとてもかかわっていることを認識し、処理の内容を確認しました
  • SQLiteのファイルをのぞいたところ、何をやっているのかよくわからず、しかしファイルの名称からテナント関連の処理をしてそうということだけわかりました
  • SQLiteの改善をあきらめ再度topでDBが重くなっていることを確認し、replaceのクエリを改善することにしました
  • そもそも一意のIDを払い出せればよさそうだったため、JavaでUUIDを生成しSQLは実行しないようにしました
  • 再度ベンチマーク
  • 18:00になったので終了

振り返り

やったことを列挙しましたが、一つ一つのオペレーションに慣れておらず、時間がかかっていました。たとえばスロークエリログを有効にした場面ではログローテートをしたあとに書き込みがされなかったりして、その解決に時間をとられたりなど普段触っていないこと起因のような機動力の遅さをとても感じました。 上記が一番強く感じたことですが、それ以外にも

  • 全体を俯瞰する能力がなさすぎる(nginxのことをしばらく忘れてた)
  • ソースコードを見つけるのに時間がかかった(セオリーを知らない)
  • Gitを活用出来ていない(一人チームであった・ソースコード以外の設定ファイルはcpコマンドでバックアップとるだけだった)
  • Javaで実行時間を計る方法を、LocalTime.now()以外の見やすい方法を考えておくべきだった
  • アプリケーションの全体を詳細までつかめていない
    • 各エンドポイントが何をするのかわかっていない(そこから呼ばれているメソッドのシグネチャぐらいまでしか目を通していなかった)
  • インスタンスが3つあるのがなぜなのか理解していない
  • DBのスロークエリログと、アクセスログで一番上の事象を改善してもスコアにあまり反映されないことの理由に気付くのが遅い
    • 一番のボトルネックを解消しないと他のアクションの効果が薄いという旨の記述が書籍「達人が教えるWebパフォーマンスチューニング」にあったのに
  • 最後に再起動実験をしなかった(レギュレーションを読んでの、当日やることリストを作るべきだった)
  • MySQLやNGINXの設定のセオリーがわかっていない
    • 設定項目を見ても何についての設定なのか理解できない
  • 触ったことの無い技術要素であるSQLiteに忌避感が出てしまった
    • なにをやってるか理解できなかった
  • Gitを経由せず、サーバーのコードを直接書き換えた方が機動力があったかもしれない(VScodeでできたような…)
  • 自分はインフラ関連が未熟で、ソースコードを見ることしかできないのだから最初の時点で気合いを入れて全部のコードを見て分かりやすいようにリファクタリングするぐらいの強い気持ちを持てばよかった
  • 一緒に参加する友達がいなかったorz

総じて…

あまりにも広い範囲で能力が足りていませんでした。普段の仕事が整備されたものであることや、自分で作るアプリケーションは作りきりで終わりだったり複雑なインフラを必要としていないこと等、知識・経験両方が不足していることを強烈に感じています。 今回参加することでこれらの課題に気付けただけでも大きな収穫になったはず…

ネガティブなことが多いですが、曲がりなりにも計測し改善するというサイクルを予選中にできたことや、業務でほぼ経験のない高パフォーマンスのためのSQLチューニングを少し実践できたことなど、成功体験も積めました。

次回の開催の時までにもっと力をつけて来年も参加したいと思います!!

最高に楽しいカンファレンスbuilderscon tokyo 2019に参加してきました(自分用メモ&感想)

昨年初めてbuilderscon2018に参加した際、楽しく技術発表するお祭りといった珍しい雰囲気のカンファレンスだったので好きになり、光の速度でチケットを購入しました。 カミオカンデコンパイラライブコーディングの話は聞けなかったのですが、がすごく盛り上がっていたらしく、動画が後ほど公開されるのであればみたいです。

続きを読む

設計Night2018@自分用理解メモ

builderscon2018で(@shinpei0213)さんによる発表「開発現場で役立たせるための設計原則とパターン」を聞きました。 https://nekogata.hatenablog.com/entry/2018/09/10/163206

現場において暗黙知となっている部分、例えばコードレビュー時にどのコードが良い悪いなどを議論する際に、その現場で技術的に優れている人(もしくは年数が長い人とか)だけが把握している"良い悪い"を、設計原則(単一責任原則や開放閉鎖原則)などを"良い悪い"の基軸として据えることで、議論のテーブルに持っていくことができるのではないか。

という問題提起から、

「問題に対して、その設計原則が最適である」というのはどのように判断するのか?

「結局はケースバイケース」という答えのようで答えになっていない結論とするしかないのか?

というさらなる問題に対して、

デザインパターンなどを利用し、構造やコードを作成する」⇄「設計原則を利用し問題に対して良い構造になっているか見直す」

というサイクルを繰り返すことで、最適な状態を削り出していくのが良いのではないか。

という発表でした。

私はまだまだ経験の少ないプログラマーで、入門書の次のレベルとはどういうことなのだろうか?そもそも良いコードとはどういうことなのだろうか?デザインパターンや設計原則を少し学んだけど、現場で活かせているような気がしない。という疑問でしばらく悩んでいました。

この発表は、上記の疑問に一定の答えを示してくれていると感じ、大変感動しました。

その発表の続編(上記だけでは解決できていない問題がテーマ)に当たる勉強会に参加してきました。

設計Night2018 powered by Classi

https://connpass.com/event/104821/

続きを読む

builderscon tokyo 2018 に参加してみた(その2)(自分用メモ&感想)

全てのエンジニアに知ってもらいたいOSの中身について

  • OSのレイヤーが自分の手から離れると怖い
  • OSを知るとちょっと幸せ
  • OSを知ってみよう
  • ブートシーケンスからOSの動きを紐解く
  • プロテクトモード
    • 特権かんり
      • 自分の権限より上位の権限を利用するときにシステムコールする
      • OSにアクセス => 一般保護例外
    • メモリ管理
      • メモリアドレス指定方法(ページんぐ)(リニアアドレス):ページ(OFFSET) => PTE => PDE
      • セグメント
    • タスク管理(マルチタスク)
      • TSSが管理している(メモリやレジスタの状態保持)
続きを読む