Hi there 👋

当日の感想 解くのに夢中で、全然覚えていないですが、こんな感じでした。 dockerについて Dockerfileがあってdocker剥がそうとして悩む。Dockerfileの中でビルドだけじゃなくて、いろいろやっていて読み解けず混乱していました 結局、dockerは使っていないみたいで、そもそもdocker自体が環境にinstallされていなかったのでスルーすることに 事前に用意したMakefileやシェル環境の準備 微修正で大体上手く動きました 計測グッズの投入 alp/slowquery/pprofは事前練習通り、スムーズに入れられて、分析に辿り着けました 実際ボトルネックで戸惑うことはそんなになかったです（ボトルネックで迷うようなレベルまで辿り着けなかったともいう tbls tblsでER図を出力しようとしたけど、なぜか上手くいかず、結局mysqlにuserを追加して、出力しました 結局外部キーが貼られていないので必要なかったです。schema.sqlファイルをみるだけで十分でした 無駄に時間を使ってしまった 秘伝のタレ なぜか終盤の16時くらいに投入し始めました（始めにやるべきだった なぜかアプリ側のmaxconnectionsを10にしているという、痛恨のミスに後になって気付きました（50くらいにしたかった icon iconが遅いのは計測結果で明らかだったので、iconから手を付けることに ISUCON本に書いてあるMySQLからローカルファイルへの移行が効果的だと判断して、割りとすぐ実装できました でも、実際細かなミスが発生していて、ベンチマーカーも動いてくれず、進みが悪い時間がかなり長くありました ミスの原因としては、icon_hashを見逃していたことと、ディレクトリ指定をミスっていたところ レスポンスのicon_idは何も使っていなかったようですが、0を返したらエラーになったので、uuid返すというよくわからないことをやりました nginxでtry filesで返すようにも設定したけど、あまりスコアには効かなかった気がします etagは存在を忘れてました statistics これもとんでもなく遅いのが初期段階でわかってました 典型的なINDEXとN+1の解消が効果的なので、ChatGPTの力を借りながらひたすら実装していきました iconと同時並行で手を付けていましたが、結局落ち着いて取り組めたのが、14時過ぎくらいだった気がします iconの不具合とベンチマーカーが動いてくれない問題があり、あまり集中できなかったです スキーマ変更の投入手段に悩む schema.sqlを書き替えるだけでは反映されないので、別の方法を考える必要がありました 当日マニュアルでは、drop database/create databaseして、setup.shを実行すれば、再度構築されると書いてあったので、スキーマ変更後にそれをやればよさそうでした ただ、毎回mysqlにlog inして実行するのは効率が悪く＆isudnsのスキーマがなかった（実際はどこかにあった？）ので、軽く整備しました setup.sh同様にcustom.shとsqlファイルを準備して、goのcmdで実行するようにしました ここで間違えてisudnsの方のdatabaseをdropしてしまい、復活できずに、cloudformationから環境を作り直して、かなり時間とられました DNS 今回の問題の肝だったと思いますが、時間がなく着手できなかったです 他のチームの感想みてみると、PowerDNS止めた上で、MySQLではなくインメモリにドメインリストを管理するように自前で実装すればよかった？？ サーバー分割について 17過ぎからサーバー分割に着手しました 時間もなかったので、1:nginx+app,2:dbで一台あまらせる構成でいいやと判断しました （間違えてpublid ipをhostにしてしまったりしたものの）分割はできました initializeで2台目のsetup.shも呼び出すようにしました でも、htopでみると、2のmysqlに負荷がかかっているものの、1でもmysqlが使われており、1のCPUが100%に張り付いていました ここでようやくPowerDNSがMySQLに負荷をかけまくっていることに気付きました… DNSだけでも3台目に逃がそうかと思ったけど、時間がなく断念 unix domain socketもやらないと、と思いつつ忘れていました 最終的に自分のisupipeがまともに動くレベルになっていて少し感動 戦いの記録: https://github.com/EkeMinusYou/isucon13-final 反省点 ベンチマーカーの整合性チェックに頼りすぎ 実行にラグがあるし、例年から落ちることも予想できたので、実際にサイトを確認するなど別の手段で、チェックすべきでした 最初から複数台を見越した準備をするべき 1台でないと解析はしにくいけど、複数台に分割しないとボトルネックに気付けない場合もあるかもしれない また、どう分割するかも、重要なポイントなので、柔軟に構成を変更できるような、準備をあらかじめ整えるべきでした 時間がなくても実際に変更をデプロイする前に、一人レビューするべきでした ケアレスミスでかなり時間を消費してしまったので MySQLのスキーマ変更手段はISUCONの構成に関わらないやり方を用意すべき 今回のgo cmdでいいかな？ 秘伝のタレは一番始めに投入すべき コード読み始めちゃうとなかなかそこに気が回らなくなるので おわりに めちゃめちゃ楽しかったです！素晴らしい大会を開催頂き本当にありがとうございます！！...

まえがき 前々から気になっていた資格 AWS の ソリューションアーキテクト　アソシエイト を取得しました。 https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/ 受けたいなーと思いつつ受講料が 1.5 万円ほどで高く今まで尻込みしていたのですが、今年に入って会社で資格取得制度ができたのでそれを活用して受験しました。 落ちたら自腹になるのでビクビクしてましたが受かってよかったです 😅 モチベーション 背景 AWS は IaaS の中でもっともシェアが高いパブリッククラウドです。 https://www.publickey1.jp/blog/20/iaasaws45azure182320208.html 弊社でも AWS を全面的に採用しているので日々活用しているのですが、クラウドサービスを学習するのはなかなかコストが高いです。 AWS はサービスだけでも 200 程度あり名前を覚えるのだけでも大変で、コアの部分を学習するだけでも独自の文化があり学習にかなりの時間がかかるといって良いと思います。 AWS に特化していくというのは現在の業務にもすぐに活用できますし、私にとってとても良い選択肢に感じました。 体系的に理解したかった 業務で使用しているサービスに関しては日頃から調べていますが、果たしてそれで本当に AWS を理解しているのか？と言われると非常に怪しいです。 新規開発するときを除けばインフラ構成がどうなっているか知らずとも普段の業務に支障が出ることはありません。個人的にはそれなりに把握しているつもりですが、畢竟すでに動いている基盤は何も意識せずに日常的に開発できてしまいます。これは役割分担としては正しいのかもしれませんが、私は裏側でどういうものが動いているのかを知っておきたいし、そもそも役割が会社内で変わりつつあってインフラも深く理解することが求められつつある雰囲気を感じています。 とはいえ、手当たり次第に勉強していくのも厳しいものがあるので SAA という AWS 認定の資格学習を通じて理解が深まればいいなという目論見 がありました。 学習 0 からの学習の場合は書籍などを一冊通して学習するのが最適かもしれないですが、私は業務で使っているので、不得意な分野を集中的に学習 & 練習問題を解きまくる という方針にしました。 教材と学習方法 こちらのサイトの問題集（通称小岩）がもっとも有名らしいですが、私は Udemy で勉強しました。 以下の 3 つのコースを購入しハイブリッドに行き来しつつ学習していきました。 https://www.udemy.com/course/aws-associate/ https://www.udemy.com/course/aws-knan/ https://www.udemy.com/course/aws-uoyc/ まずは これだけで OK からあまりよく知らない分野をピックアップして動画で学習しました。2 倍速がおすすめです。 ハンズオンを推奨しているようですが時間のロスのが大きい気がしたのでただ動画みて理解するだけにしました。 特に以下の内容はよかったのでおすすめです。 Well Architected Framework 信頼性の設計 練習問題は短期突破の講座と演習問題の講座に含まれているのでそちらをひたすら解きまくりました。 学習時間 計算すると 15 時間程度の学習時間でした。もっと頑張った気になっていました。...

まえがき leetcode 始めようと思い環境を整備しました。 leetcode は日本ではそんなにメジャーではないですが、面接などで、エンジニアに出されるコーディング試験などを集めたものらしいです。日本でいう AtCoder みたいなものですね。 正直多少のパフォーマンスより可読性を重視した方が良いと思うのですが、バックエンドエンジニアをやりつつアルゴリズムがわからんというのも問題なので、挑戦してみようと思いました。 仕事で使っている主な言語は TypeScript なのですが、いつの間にか TypeScript も対応しているようでちょうどよかったです。 また、どうせなら以下の要件でやってみたく試してみました。案外簡単に整備できました。 VSCode でコーディング テーマやフォーマッターをいつもと同じにしたかった GitHub でコードを管理 進捗がわかりやすくなるし対外的にアピールできるかも VSCode に leetcode の拡張機能を導入 こちらの拡張機能をインストールするだけです。中華製なのかな？ leetcode-cli というのがあるのでそれをうまく使った拡張機能みたいです。node が必要なのでもし入ってなかったら入れてください。 https://marketplace.visualstudio.com/items?itemName=LeetCode.vscode-leetcodes install & login VSCode に leetcode の拡張機能を install したら以下のようにサイドバーに leetcode が追加されました。 Sign in を押してみると以下のようにログイン方法がリストで表示されます。 私は GitHub でログインしましたが、2factor 認証もそのまま入力できて地味にすごいなと思いました。 problem ログインすると以下のように表示が変わります。 どうやらここに problems のリスト並ぶようです。 試しに Two Sum をクリックしてみると Description が VSCode 上で閲覧できます。 右下の Code now から実際にコーディングを開始することができます。言語を選んで生成するファイルの場所を選ぶ必要があります。 こんな感じでコーディングを開始できます。最高ですね！ ファイル名が自動でついてくれるのがありがたい。 test test や submit も VSCode 上でできるようです。おもむろに test してみた結果が以下です。...

まえがき 最近久々に Python を触ってみました。 Python といえばバージョン管理を考えるのが厄介だなという印象でした。 なにぶん macos ではデフォルトで Python2 が入っているので、Python3 を使うにはバージョン管理ソフトが必須となります。 バージョン管理のツールだと pyenv やら virtualenv やら入り乱れていて、何がデファクトスタンダードだかよくわからないのが実情だったと思います。 今回あらためて Python を書くにあたり調べたところ、どうやら pipenv がもっとも有力なバージョン管理であり、さらにパッケージの管理までしてしてくれるとのことで便利そうだなと思い使ってみました。 結論としては、 pipenv はバージョン管理+パッケージ管理ができる素晴らしいツールですが、ややデメリットもあるかなというところです。 導入(mac) README には書かれていないですが普通に brew で install できます。 brew install pipenv Python のディレクトリで以下を実施して仮想環境を初期化します。このとき Python のバージョンを指定して、そのバージョンで初期化することができます。 pipenv --Python 3.8 またこのときデフォルトではグローバルな場所に環境が構築されますが、環境変数を設定することでローカルな環境( .venv 配下)に構築することが可能です。 https://pipenv-ja.readthedocs.io/ja/translate-ja/advanced.html#pipenv.environments.PIPENV_VENV_IN_PROJECT VSCode では .venv に Python 環境があった方がインタプリターを指定しやすいので、なるべく設定した方が良いと思われ。 初期化すると以下のように Pipfile が生成されます。Pipfile が npm でいう package.json に当たるファイルのようです。 [[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [packages] [dev-packages] [requires] python_version = "3....