必須のAWSエンジニアリングチートシート: EC2 →サーバー Lambda → fake servers EBS→ハードドライブ S3 →遅いハードドライブ VPC → LANコスプレ IAM→許可が拒否されました CloudWatch→「自宅にdatadogがあります」

タイムアウトなしでクエリを実行しないでください。 単一の不正なクエリや負荷の急増が、それらなしでも停止やアプリのダウンタイムを引き起こすことがあります。なぜそうなのか考えてみましょう。 長期間実行されているクエリが誤ってアプリに導入された場合を考えてみてください。データベースは通常、短命(10ms以下)のクエリしか処理しませんが、突然1000msかかる新しいクエリが現れます。 これにより資源が消費されるだけでなく、同時取引の数も急増します。接続制限や交換速度制限に到達するか、データベースのCPUやIOPSを100%使い切るかのどちらかです。 同じシナリオを考えますが、すべてのトランザクションに250msのタイムアウト(データベース側)を設定し、指数関数的なバックオフ再試行ロジック+ジッター(アプリ側)を使います。現在、単一のクエリの爆発範囲を制限しました。長期間続くクエリは停止し、バックオフロジックは群れの雷鳴のリスクを最小限に抑えます。 これらのタイムアウトを監視することで、問題のあるクエリを迅速に特定し、変更をロールバックできます。

書き出しログ(WAL)は、データベースが迅速にコミットする方法であり、クラッシュから安全に回復する方法でもあります。 Bツリー以外では、PostgresやMySQLで最も重要な構造だと思います。 (MySQLランドでは「リドログ」と呼ばれています)