構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

検証ミスった

といっても仕事の話ではなくて、個人的な調査をしてQiitaに記事を書いたAmazon AuroraのAsynchronous Key Prefetchのことです。

qiita.com

qiita.com

qiita.com

記事を3つも書いてしまいました。無駄に。

ミスしたポイントは「Auroraは再起動してもバッファキャッシュ(MySQLでいうところのバッファプール)が残る」仕様であることを知っていながら、過去、仕事で性能テストをしたときに「Aurora再起動直後はアプリケーションの動作が遅い」という経験をしていたので、その原因を追求しないまま「ちょっと容量多めのデータを用意しておけば再起動で大丈夫(消えているはず)」と思って雑にテストしたこと、ですが、思い返すと、

 

・仕様上は「再起動しても残る」(説明文には「メモリ内ページキャッシュに保存された既知の一般的なクエリのページを使用してバッファープールを事前にロードします。」と表現されている)とされている

・再起動した場合、クエリキャッシュがクリアされる、プーリングのコネクションの切断検出と再接続が行われる分、再起動前よりクエリの処理が「遅くなる」原因が(バッファプールがクリアされたことの)他にもある

・実際のクエリ処理時間は0.5秒未満だった一方、数百MiB~GiB単位のデータを外部ストレージ(SSD)から読み取るのに通常秒単位の時間が掛かるはず

・Auroraでは既存のMySQLInnoDB)のステータス等の数値が「機構が(本家MySQL/InnoDBと)違うので信用できない可能性がある」(AWSサポート談)とはいえ、プライマリインスタンス(Writer)での「SHOW ENGINE InnoDB STATUS」のBUFFER POOL項目は信用できそうな値が入っていたのに、無視して確認しなかった

 

…などなど、色々出てきます。

全て、事前に知見があったにも関わらず…。

 

・とにかく1項目テストするのに時間が掛かる

・夜中になったので早いところ検証を終わらせて記事にまとめたい

・(当時)「確実にバッファキャッシュを消す」方法を(スナップショットから戻す以外)知らなかった

 

などの事情があって、知見があるのに無視してしまう認知バイアスが働いてしまったようです。

実際の仕事の中でもこういうことはよくあって、MySQL Connector/Jのプロパティにパフォーマンス項目があるにも関わらず、それ以外のプロパティばかり変えて一所懸命テストを繰り返してしまったり(パフォーマンス項目以外の項目が性能に影響することを知っていたが故の認知バイアス)、フェイルオーバー後のバッファキャッシュがどうなるのかなど、本来なら運用上出てくるケースをテスト項目から漏らしてしまったり…。

「1人ではなく複数でチェックしながら実施すれば」という声もありそうですが、それでも見逃すことがあるので、予断(によるバイアス)を避けるためにも「できるだけ自動でやらせる範囲を広げる」ことが必要な気がします。