The Grid Part 2에서 데이터베이스 감사: 배포 후 관찰

이 시리즈의 이전 게시물에서 이 프로젝트의 요구 사항을 수집하는 방법, 사용할 도구를 결정한 방법, 서비스 중단을 피하기 위한 배포 계획에 대해 이야기했습니다. 약속한 대로 이 후속 게시물은 배포 후 관찰과 이를 성공적으로 만든 요인에 중점을 둡니다.

준비된 명령문 및 명령 클래스 필터링

이 프로젝트의 초기 디자인은 포함된 명령 목록을 사용하거나 제외된 명령을 사용하여 실제로 감사해야 하는 범위로 범위를 제한하도록 방출된 이벤트를 필터링할 수 있는 percona 플러그인의 기능을 활용하는 것이었습니다.

이 기능은 감지된 모든 sql 명령을 mysql에 고유한 목록을 기반으로 하는 클래스로 표시하고 감지된 명령 클래스를 억제하거나 내보내야 하는지 여부를 출력 계층에서 결정하는 플러그인에 의존합니다.

그래서 우리는 행 데이터에 대한 쓰기나 변경을 일으키지 않은 모든 SQL 명령을 제외하기 위해 audit_log_exclude_commands 기능을 활용하는 초기 청사진을 작성했습니다. 포함 목록에 범위 내 명령 클래스가 누락될 위험이 있고 감사 로그에 공백이 생기는 이유가 될 수 있다고 생각했기 때문에 제외 목록을 선택했습니다.

그러나 테스트한 첫 번째 클러스터에서 이러한 명령문이 성공적으로 실행되었고 데이터 변경의 경우에도 성공적으로 수행되었음에도 불구하고 감사되는 모든 명령이 오류 로 분류되는 것을 보았습니다. 또한 해당 오류 분류와 상관관계가 있는 것으로 보이는 제외 목록에 관계없이 모든 쿼리가 중앙 집중식 syslog 서버로 내보내지는 것을 보았습니다.

이는 우리가 실제로 필요한 것보다 훨씬 더 많은 이벤트를 Elasticsearch에 저장하고 있다는 것을 의미하며, 이는 적시에 잘못된 행동을 분석하고 감지하는 능력에 가장 확실히 영향을 미칠 것입니다. 보안 팀과 협력하여 버그 추적기를 통해 Percona에 문제를 알리고 명령 기반 필터링도 중앙 syslog 계층으로 이동하기로 결정했습니다.

엔지니어링의 모든 것과 마찬가지로 여기에서 절충안은 DB 네트워킹 계층을 통해 더 많은 데이터를 보내고 중앙 집중식 syslog 계층의 필터링을 더 복잡하게 만들고 그 대가로 탄력적 검색 확장 요구 사항을 더 관리하기 쉽고 데이터베이스 측 구성을 더 단순하게 만드는 것이었습니다.

성능

이 프로젝트에서 우리에게 많은 고민을 덜어준 가장 중요한 결정 중 하나는 이러한 로그를 트래핑하고 중앙 집중식 syslog 서버로 보내기 위해 rsyslog 기능을 사용하기로 결정한 것입니다.

그러나 장단점이 없는 것은 없습니다.

이 결정은 별도 시스템의 가동 시간과 그 사이에 있는 네트워크 스택의 안정성이 감사 팀에 이 감사 솔루션에 대한 확신을 주는 데 필요한 SLA를 제공하는 데 중요하다는 것을 의미했습니다.

그러한 타협을 원하지 않고 DB 스택 내에서 감사 로그 지속성에 대한 책임을 유지해야 하는 사람들을 위해 감사 플러그인에서 FILE 핸들러를 사용한 다음 로컬 logstash를 사용하여 로그를 가져와 분석 시스템에 전달할 것을 권장합니다. 선택.

후자의 선택은 데이터베이스 프로세스에서 훨씬 더 많은 디스크 IOP가 소비되고 감사 플러그인 및 logstash가 차지한다는 것을 의미하며, 이는 데이터베이스 테이블 파일, 운영 로그 및 감사 사이에서 인스턴스의 디스크 공간 균형을 신중하게 조정해야 함을 의미합니다. 플러그인 로그. 귀하의 옵션을 평가하는 것은 비즈니스에서 더 쉽게 운영/허용할 수 있는 옵션에 전적으로 의존하지만 그럼에도 불구하고 선택권은 있습니다.

우리의 경우 rsyslog 선택은 사용량이 많은 데이터베이스에 가장 적은 영향을 미치는 것으로 판명되었으며 정상 작동 중에는 성능에 영향을 미치지 않는 것으로 나타났습니다. 감사 플러그인은 데이터베이스 성능에 영향을 미치지 않으면서 이벤트를 계속해서 보내고 있었습니다. 모두 데이터베이스 측에서 디스크 기반 작업을 사용하지 않는 아키텍처를 선택했기 때문입니다.

과거의 결정이 결실을 맺다

이 프로젝트를 시작할 때 가장 먼저 우려했던 것 중 하나는 성능에 미치는 영향이었습니다. 범위의 데이터베이스 클러스터 중 하나는 매우 바쁜 시간을 보았고 해당 애플리케이션은 지연에 민감하므로 플러그인을 배포한 후 숫자를 비교하기 위해 초당 트랜잭션, 디스크 및 CPU 사용률과 같은 성능 메트릭을 추적해야 했습니다. 그에 대한 처벌이 무엇인지 보십시오.

정상적인 운영에서 패널티가 많이 발생하지 않는다는 사실은 매우 기뻤습니다. 앞에서 언급했듯이 SYSLOG 핸들러를 사용하기로 결정했기 때문에 일반적으로 이러한 감사 이벤트를 추적하기 위해 로컬 디스크 용량을 사용할 필요가 없었습니다.

그러나 우리는 또한 '정상 작동' 시간만을 기준으로 계획하고 싶지 않았습니다.

우리는 또한 rsyslog가 로컬 스풀 파일로 폴백해야 할 때 이러한 이벤트가 더 중요한 DB 클러스터에 대한 서비스 중단에 영향을 미치는 서비스로 합성되지 않는다는 것을 알아야 했습니다. 프로덕션 환경에서 면밀히 관찰하면서 rsyslog 스풀링 동작을 테스트함으로써 우리는 데이터베이스를 기능적으로 분할하기 위한 지난 몇 년 간의 작업이 rsyslog 스풀링과 같은 이벤트를 디스크로 흡수한 다음 다시 전송해야 하는 많은 디스크 IOP 용량의 예상치 못한 이점을 얻었다는 것을 깨달았습니다. 이 모든 이벤트.

우리는 이러한 이벤트 동안 디스크 사용률이 증가하는 것을 분명히 주목했지만 db 인스턴스를 심각한 상태로 만들거나 고객 대면 활동에 영향을 미치지 않았습니다.

절충안

소프트웨어 엔지니어링의 모든 것과 마찬가지로 항상 절충점이 있습니다. 이 프로젝트에서는 더 안정적이고 로그 손실 가능성이 적은 로그 전달 방법을 고려했습니다. 여기에는 로그를 디스크에 쓴 다음 logstash와 같은 것을 사용하여 수집하고 보안 팀이 사용할 분석 대상으로 보내는 것이 포함됩니다.

그러나 이는 데이터베이스 측에서 상당한 디스크 IOP 소비를 의미했으며 이러한 데이터베이스에 대한 고객 대면 통화의 서비스 품질에 잠재적으로 영향을 미칠 수 있음을 알고 있었습니다.

우리는 rsyslog에서 복원력 있는 로깅을 사용하고, 적당한 크기의 스풀을 사용하고, TCP를 사용하여 이벤트를 로그 모니터링 스택으로 보내면 비즈니스 요구를 충분히 충족할 수 있다고 결정했습니다. 인생의 모든 것이 그렇듯 영원한 것은 없습니다. 그리고 우리는 이 결정이 미래에 재검토되어야 할 필요가 있다는 것을 알고 있습니다.

마침내

이 프로젝트는 6개의 클러스터와 많은 수의 인스턴스를 포함하면서 DB 운영 팀이 여전히 빠르게 성장하는 비즈니스에서 계속 조명을 유지하는 동안 단일 분기에 완료되었습니다. 이는 DBE와 보안 팀 간의 긴밀한 협력 없이는 불가능했으며, 범위를 제한하고 우리 모두가 비즈니스를 보다 안전하게 만드는 최종 목표를 주시하도록 하는 강력한 제품 관리가 없었다면 불가능했을 것입니다.