タダです.
RDS ログを S3 にアップロードする Python スクリプトを ECS で実行に向けての記事や運用時に遭遇した気づきを書いたのですが,この記事でも運用し続けてみて発生した課題に対する対策をまとめていきます.
運用してみての課題
RDS ログを S3 アップロードを定期的に実行し始めて RDS の CPU 負荷が高騰していることに気付きました.WRITER だと60%ほど,READER だと30%ほどログをダウンロードしてる時間帯で高くなっていたこと,ログダウンロードも全てのファイルを落としており実行時間が長くなっていたため,この課題を解決するように対策を打ちました.
課題に対する対策
対策として,S3 にログがないもしくはログがあってもログファイルのサイズが増えている場合にダウンロードするように変更することにしました.加えて,当初は S3 へログをアップロードする時にダウンロードしたログファイルをそのままアップロードしたのですが,処理スピードを上げるために gzip にしてアップロードするように変更しました
差分の判定
差分のみダウンロード・アップロードするために入れた判定が gzip でアップロードする際にオブジェクトのメタデータとして,gzip 前のログファイルサイズを入れるようにしました. describe_db_log_files API のレスポンスで Size があり,ログファイルサイズを取れるためこの値をメタデータに入れてアップロードしました.
オブジェクトアップロード例
S3.Object.put(
Body=[ログファイルデータ],
Metadata={
'log-raw-size': str(ログファイルサイズの変数),
}
)
そして,アップロードしたメタデータから log-raw-size と describe_db_log_files API からとってきたファイルサイズを比較して同じならダウンロード処理はスキップし,同じじゃなければダウンロードするようにしました.
差分判定部分の抜粋
def compare_size(self, rdslog: 'RDSLog') -> bool: return rdslog.size == self.log_raw_size()
差分判定を入れた結果
差分ダウンロード・アップロードを入れた結果,初回実行時はオブジェクトにメタデータがなくフルアップロードになってしまいますが,2回目以降は CPU 負荷は WRITER が最大3%ほど上昇した位で留まり実行時間も元々の3分の1に収まりました.
まとめ
RDS ログを定期的に S3 にアップロードする処理を動かし始めて気づいた運用課題に対する対策をまとめました.
