あれ
ブログのリプレイスできたああああああああ!!!!!
AWS Amplifyで動かしたら月額1万円かかって爆死したので、Vultrに戻した。
ついでにPostgreSQLからDuckDBに変えてみた。
PostgreSQLで300msかかってた処理が100msになった。やったぜ。
あれ
Next.jsとGraphQLという現代兵器を使うから高速化出来るかな〜〜と思ったけど、むしろ遅くなってて残念。
むしろなんのチューニングもしてないPostgreSQLとExpress.jsでコレだけ速い現行版が謎。
現行版と比べてみると、無駄なクエリを投げてるな。コレを現行版に似せてやればよろしい。
現行版はキャッシュがなければ170msぐらいで飛んでくるので、そこまで行ければ嬉しい。
『t_wの輪郭』に攻撃が来た 2022年11月6日
は?やべぇ。攻撃来てるかも。攻撃戦だ。
nginxのログみたら、SQLっぽいクエリで検索めっちゃされてる。
nginxでIPをはじくようにした。
IPをBANしたら、一旦攻撃は止んだ。
攻撃の対策どうしよう、fail2banのnginx-403-404は設定してるけど、サイト内検索を連打されるとこれ効かないんだよな。
WAF入れるのが手っ取り早いんだろうけど、勉強にならないし、お金かかるしで、もうちょっとほかの手段を検討したい。
①fail2banでSQLインジェクションを検知してBANする
②nginxで高頻度の検索を検知してBANする
あたりかしら
設定するのめんどくせー
ちゃんと設定できてるか検証するのもめんどくせー
①検証用の被攻撃サーバーと攻撃用サーバーを立ててそこで対策が有効かを検証
②本番環境に反映したら攻撃用サーバーから攻撃してみて、ちゃんと対策されているか検証
って感じで進めるとお行儀が良さそう。
めんどくせー
本番環境でペペぺって設定して、自宅のPCから実際攻撃して検証したい。そして自宅のPCから本番環境にアクセスできなくなるワナ。
こういうのって制定された手順とかあるんかな。ありそう。先に調べよう。
そもそもサイト内検索が大変重たいという問題も解決したい。
自作の検索機能がDBにインデックス張ってないわ、title LIKE %hogehoge% OR body_text LIKE %hogehoge%
とかやって全文検索走るわでイケてない。
DBにちゃんとインデックス張ればいいんだろうけど、PostgreSQLの日本語のインデックスって、PGroonga入れたり、pg_bigm入れたりで、これまた検証サーバー立てないと怖いのよね。
めんどくせー。
pgvector
Grafanaのデータソース
Alertmanager
AWS CloudWatch
Azure Monitor
Elasticsearch
Google Cloud Monitoring
Graphite
InfluxDB
Loki
Microsoft SQL Server (MSSQL)
MySQL
OpenTSDB
PostgreSQL
Prometheus
Jaeger
Zipkin
Tempo
Testdata
『pgpool-IIによるオンメモリクエリキャッシュの実装』
『t_wの輪郭』のバックアップ
- Vultrでスナップショットを取る
- 復旧できるか確認すること
- 2022年5月5日復旧できた
- 復旧できるか確認すること
- Vultrのバックアップ機能を使う
- バックアップ頻度を週次から日次に変更した
- 復旧できるか確認すること
- PostgreSQLのアーカイブを作成してダウンロード
- →SSH/SCPを使わなくても良くしたい、というか手間を減らしたい