20221106.md

今週何知った？ week:28

各自発表

[name=ken3ypa]

MySQLのクエリチューニングする際に調べたことのまとめとか

背景

• 最近、MySQL5.7 にて遅いクエリのチューニングをした
• 遅いクエリをチューニングする際、色んな手順を行ったり来たり、調べたりしてモタモタしたので、チェックリスト化しておき以降は効率的な調査・検討ができるようにしたい

やることリスト

• SQLが発行されている箇所をコードで確認する
• 遅いクエリが発行されている条件（user_id など）をAPMツール等で確認する
• 発行されているSQLを確認する
• 本番のレコード数と同等程度の環境を用意する

不要なJOINの見直しによる改善

• 不要にJOINしているテーブルがないか確認する

不要な preload による改善

• 利用されていないのに preload されているテーブルがないか確認する
• IN句の中身が3万件以上になっていないか確認する（MySQL5.7以上の場合）

INDEXによる改善

• EXPLAIN結果を取得する
  • Rails Console経由でEXPLAIN結果を取得する。consoleのみで完結させる場合は そのクエリ、ちゃんとチューニングされてる？Railsで確認する方法 - Qiitaを確認
• 利用されているINDEXを確認する
  • そもそも利用されているか否か
    • 使われていても、より早くなりそうなINDEXを選択可能か
      • カーディナリティの低いINDEXが選択されていないか
        • 参考：スロークエリのチューニングについて
• INDEXを追加することで改善可能か確認する
  • カーディナリティを確認。低い場合は不要。低い高いの目安は全体の5%程度に絞れるか否か
  • 複合INDEXが追加可能か
    • 既存の単体インデックスと重複する場合には削除する
      • key(a, b) がある場合 key(a) は不要

Tips：

このインデックスが効いたら早くなるんちゃうの、というとき

• インデックスヒントを使って強制的にINDEXを効かせて検証する
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.9.4 インデックスヒント
• ActiveRecordで発行させるクエリに組み合わせたい時は下記
  • ruby on rails & mysql use force index - Qiita

どのインデックスが効くかよくわからない

• すべてのカラムにIndexをつけてみる
• その状態でEXPLAINを実行し、possible_keysを確認
• 上記結果から効きそうなINDEX、複合INDEXのみ残す

IS NULL / IS NOT NULL はインデックスが使える

• MySQL :: MySQL 5.7 リファレンスマニュアル :: 8.2.1.8 IS NULL の最適化
• MySQL :: MySQL 5.7 リファレンスマニュアル :: 8.3.8 B ツリーインデックスとハッシュインデックスの比較

リンク集

EXPLAIN結果が何を示しているのか読み解きたい

• 漢(オトコ)のコンピュータ道: MySQLのEXPLAINを徹底解説!!

SQLチューニングの外観をつかみたい

• 20151208_02_MySQL_Tuning_for_Beginners.pdf
• SQL を速くするインデックス入門 : B-Tree や複合インデックスが理解できる

---

[name=makicamel]

モノリス、マイクロサービス、モジュラモノリス

参考：[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

モノリスとは

• Wikipedia によると「機能的に区別できるシステムのさまざまな側面（たとえば、データの入力と出力、データの処理、エラーハンドリング、ユーザーインターフェイスなど）が、アーキテクチャとして別々のコンポーネントに分離されているのではなく、すべてが1つに組み合わされたもの」
  • 異なるドメインがひとつのコードベースに存在し、互いの呼び出しを禁止できない、密結合になりやすい
• DHH が「マジェスティックモノリス」とも表現している
  • 敢えて選択するモノリスのような意味
  • 参考
    • The Majestic Monolith - Signal v. Noise - 2016.2.29

長所

• 構築が容易
• リポジトリがひとつでそのリポジトリ内を検索すればすべての機能を見つけることができる
• テストとデプロイのパイプラインもひとつなのでオーバーヘッドを回避できる
• データが単一のデータベースに保存されているのでそのデータベースにクエリを投げればデータを取得できる
• 管理するインフラがひとつで済む
  • インフラが増えると DevOps に割く時間が増える
• WebAPI を介した通信を必要とせず他のコンポーネントを直接呼び出すことができる
  • APIのバージョン管理や下位互換性、遅延の可能性のある呼び出しについて心配する必要がない

短所

• 異なる機能感の境界線が欠如しやすい
• つまり、密結合になりやすい
  • 例えば、税率を計算するコードが配送料を計算するコードを呼び出した場合、税率の計算方法を変更することで配送料の計算結果に影響を与える可能性がある
  • 複雑なモノリシックアプリケーションは急勾配な学習曲線を描く

マイクロサービスとは

• 小さなサービスの集合体として大きなアプリケーションを構築する
• 「Micro Services はアーキテクチャパターンではなく組織的なパターン」 by DHH

短所

• 複数の異なるテストとデプロイのパイプラインのメンテナンスが必要
• サービスごとにインフラストラクチャのオーバーヘッドが増える
• サービス間の通信がネットワーク経由になり遅延が増加する

モジュラモノリスとは

• すべてのコードが単一のアプリケーションを動かすシステムであり、異なるドメイン間に厳密に強制された境界があるシステム
• モノリスとしてアプリケーションを構築するが、アプリケーション内でドメインごとにモジュールとして分割し、各モジュール間の独立性を担保する事を目指す

シタデルアーキテクチャとは

• モノリスで構築しようにも、特殊な要件のため最適な技術スタックがモノリスアプリケーションで採用しているものとは異なる場合などが発生するようになった際に、モノリスアプリケーションとは別に特定の要件のためのシステム(記事内ではOutpostsと呼んでいる)を構築し、モノリスアプリケーションから利用する
• 参考
  • モノリスの亜種のアーキテクチャ(Modular MonolithとかMajestic MonolithとかCitadel Architectureとか)
  • The Majestic Monolith can become The Citadel - Signal v. Noise - 2020.4.8
  • Rails: AppSignalが採用する「シタデルアーキテクチャ」（翻訳）｜TechRacho by BPS株式会社 - 2020.4.8