03 Apr 2022

最近読んだもの 39 - USD 7 章、MySQL スケールなど

  • Understanding Software Dynamics
    • 7 章まで読んだ
    • 今度は 6 章の実験環境に加えて、Disk IO があり、たまにテーブルロックもある状況で、複数クライアントから並行してリクエストするケース
    • 例えばロック待ちで 1 並列時にはなかった遅延が発生したり、バッファからディスクにフラッシュするタイミングでレイテンシが悪化したりする様子を確認していく
      • こう書くと平凡な内容にみえるかもしれないが、本文ではこれをかなり詳細に確認しながら論を進めている
    • 最先端のソフトウェアエンジニアリングはこんな感じなのかなと思わされたり、自分の普段の仕事と比較したりして、圧倒されている
    • どんどん面白くなってきた
  • Scaling MySQL stack, ep. 1: Timeouts · Kir Shatrov
    • Global なクエリ実行時間上限は短くして (SET GLOBAL MAX_EXECUTION_TIME=2000 など)、既知のスロークエリはクエリ単位でタイムアウトを伸ばす (SELECT /*+ MAX_EXECUTION_TIME(1000) */ FROM など) のがおすすめ
    • コードベースが大規模な場合への、コントローラーのアクション単位でタイムアウトを管理する仕組みも紹介している
  • Scaling MySQL stack, ep. 2: Deadlines · Kir Shatrov
    • 次は個別のクエリのタイムアウトではなく、リクエストごとのグローバルな実行時間上限を設ける話
    • ruby では rack-timeout が有名だが問題もある
      • たぶんだけど、制限時間に達したら「割り込み」的な方法で処理を中断し例外を投げ、その際に Go でいう defer のような後処理がうまくできずに状態の一貫性が保てないというリスクが本質的にあるらしい
    • 対策として Go でいう context のような deadline という概念をおすすめしていた
      • リクエストを受けたタイミングからの経過時間を持っておき、クエリを投げる・API を呼び出すといった CPU が待たされる処理の前に時間切れになっていないかチェックする
      • そのクエリや API 呼び出し自体のタイムアウトは上記の MAX_EXECUTION_TIME のような個別のタイムアウトでカバーする
      • ということらしい
    • 欠点として CPU が待たされる処理を行う全箇所に自分で deadline チェック処理を埋め込む必要があるが、たいていは支配的なのは RDBMS へのクエリと外部 API との通信くらいなので、そこだけおさえておけば十分
  • rack-timeout/risks.md at master · sharpstone/rack-timeout
    • rack-timeout のリスク
    • 上記の記事の補足
  • Scaling MySQL stack, ep. 3: Observability · Kir Shatrov
  • 10 Books Shopify’s Tech Talent Think You Should Read — Culture (2022)
Extreme Ownership: How U.S. Navy SEALs Lead and Win (English Edition)
English Edition by Jocko Willink (著), Leif Babin (著) Format: Kindle Edition
A Philosophy of Software Design, 2nd Edition (English Edition)
English Edition by John K. Ousterhout (著) Format: Kindle Edition