アプリケーション修正のフェーズ

この章について

SRE チーム内での動作確認から、全社展開後のアプリケーション修正に掛けての作業について振り返ります。

SRE チーム内で動作確認・見つかった不具合を修正（2022/4 〜 5）

アプリケーション修正に必要な情報は集めたものの、このまま各開発チームに情報を展開して「後はよろしく」と任せてもうまく行かないことが目に見えていたので、まずは私が所属する SRE チーム内で、先のフェーズで修正（仮修正）したアプリケーションの動作確認を行いました。

v1 を DB として使う従来環境とともに v3 の DB と修正後のアプリケーションによる新環境を比較可能な状態で用意して、小規模（3 〜 4 人）で動作確認を行いました。

ここでは私のコード修正ミスによるデグレ数点と、MySQL Connector/J のバージョン間差異による以下の不具合 1 点を見つけて修正しました。

• パラメータグループでデフォルトどおりexplicit_defaults_for_timestampに1（有効）を指定した状態
• NOT NULLかつDEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMPのTIMESTAMP・DATETIME列に対して
• nullでUPDATEするとエラーに
  • 旧バージョンではエラーは出ずUPDATE時のタイムスタンプで更新された

アプリケーション修正の全社展開（2022/5）

SRE チーム内での動作確認を経て、

• その時点でリリース済みのアプリケーションの主要な修正点
  • 差分の取り込みが可能な形でソースコードを共有
• その他、どのような箇所のどのようなポイントを調査して追加の修正点を見つけるか

を各開発チームに共有しました。

ただし、前述のとおりコード中にORDER BYが一意でない箇所が大量に存在し、それをすべて調査・確認して修正するのは困難が予想されたので、この時点で修正／見送りの判断ラインを全開発チームで話し合ってもらい、共通の線引きを行いました。

結果的に、私が前のフェーズで個人的に決めたラインよりも許容範囲が広くなりました（修正対象を削減）。

アプリケーション修正・修正後の動作確認（2022/6 〜 9）

各開発チームで修正点の再調査と修正が始まったものの、当初アサインされたメンバーのスキルの関係で思うように進まず、また別の開発プロジェクトの納期との兼ね合いもあり、修正点の調査は細々と続いていたものの本格的な作業は 2022/8 頃からのスタートとなりました。

その関係で、元々は修正したアプリケーションを数回に分けてリリースしてもらう計画で進めていたのが、結果的に移行直前の 2022/10 にまとめてリリースすることになってしまいました。

また、途中で MySQL Connector/J のバージョン間差異などによる不具合が 2 点出てきました。

rewriteBatchedStatements=trueのときにROW_COUNT()の結果が不正

MySQL Connector/J 8.0.29 のバグのようでしたので、8.0.28 にバージョンダウンしました。

java.sql.ResultSet.getObject()で一旦取得してからjava.sql.Timestamp型に値を変換するコードがExceptionに

フォーマット無指定の状態（デフォルト）で渡ってくる日付のフォーマットが変わり、秒以下が無くなったのが原因でした。

java.sql.ResultSet.getTimestamp()で取得するようコードを変更しました。