本日は主にインフラの設計的なことに関して。
連鎖倒産
いい言い方が思いつかなかったんでこんな感じにしました(汗)要はあるサーバーのレスポンスが悪いことが原因で他の業務が遅延し、影響を受けることです。
デメリット
- 重要でないちょっとしたサービスの停止で他のシステムが止まる、などということが起こる
- あるシステムがハングし、適切なエラーを返さないため、いつまでも応答を待ってしまう
対策
- エラー時の対策、障害テスト。基本正常系を前提としないこと
- 受け取るだけ受け取って、そのトランザクションは一旦終わりにし、その後の処理は別のトランザクションで行う(キューイング)
- 同期と非同期を分けること
- 基本マイナス思考(どこかしらでシステムが落ちる、失敗する)で考えること(汗)
- 他のAPIなどを使っている場合も要注意。
エラー監視
正常に稼働しているかどうかの確認。
デメリット
- 異常時の検知(サーバーの死活だけでなく、ユーザー権限なども注意)が遅れる
- バッチ時の処理などすぐにはわからないもの
対策
- 人間の注意力を過信しすぎないこと
- 監視ツールでのテンプレートを参考にする
- DB構築の中のプロセスの1つに入れる
データのバックアップ体制
バックアップをしていない。障害への対策が弱い
デメリット
- いざというときに欲しいときにデータが得られない
対策
- リカバリについてフルバックアップ(いわゆる全データのバックアップ)以外にも差分バックアップなどの方法に熟知しておく
- DB構築時の手順書の中などにバックアップの考えを入れておく
- やや別件だが障害対策時はてんぱっていることが多いので、処理をその場で考えずフローを書いておき頭から実行するのが良い
