먼저 저는 SQL Server 엔지니어입니다. ec2의 m4.4xlarge에 EBS 1TB볼륨을 붙여…

먼저 저는 SQL Server 엔지니어입니다.
ec2의 m4.4xlarge에 EBS 1TB볼륨을 붙여 SQL Server를 사용 중입니다. SQL Server에서 제공하는 기본 backup 명령을 수행할 경우 EBS의 대역폭을 순간적으로 소진해서 SQL Server의 쿼리처리량이 초당 2500->1000으로 떨어져 버립니다.
백업을 수행해야 하는데 어떻게 하는게 좋을까요? ㅜㅜ

25 thoughts on “먼저 저는 SQL Server 엔지니어입니다. ec2의 m4.4xlarge에 EBS 1TB볼륨을 붙여…

  1. 백업 동작이라 iops는 높지않고 대역폭의 제한에 걸리는거 같습니다. 스냅샷의 경우 데이터가 계속 변경되는 운영중인 sql server 장비에서 떳을때 정합성 문제 없이 잘 될까요?

  2. 스냅샷도 괜찮긴 한데 250G 스냅샷 뜰때보니 시간이 세월아 내월아 걸리더군요. 그 사이에 DB 데이터 변경이 발생하면 그다지 유용하지 않은 것 같아요.

  3. 데이터가 계속해서 변경되는 상태에서 스냅샷을 뜰 경우 정합성 문제는 없을까요? 그리고 sql server의 데이터 파일을 2개의 ebs에 각각 보관했을 때 2개의 ebs를 완전히 동일한 시점을 기준으로 스냅샷을 생성할 수 있을까요? sql server라 데이터 정합성이 굉장히 중요해서요..

  4. PIOPS 를 사용하시고 EBS Optimized 를 사용하세요.그러면 ebs 데이터 전송은 별도의 네트워크로 구성되서 서버 네트워크는 영향 받지 않습니다. 그리고 해당 옵션을 사용 하시면 일부 비용상승이 발생하며, 네트워크 대역폭은 4Gbps입니다.

  5. PIOPS는 비용이 너무 비싸서 고려하지 않고 있습니다. ㅠ_ㅠ EBS optimized는 사용하는 상태이구요. 별도 네트워크라고 하더라도 백업을 수행하기 위해 해당 EBS의 데이터를 읽을 때 대역폭 병목이 걸리면서 다른 서비스를 위힌 데이터를 읽는데서 문제가 발생하는것 같습니다. 대역폭 제한은 EBS마다 정해져 있어서 m4.4xlarge의 경우 2Gbps같습니다. SQL Server에서 백업시 최대한 빨리 백업을 수행하려고 하는지 백업이 진행되는동안 모든 대역폭을 최대한 사용해 버리면서 문제가 발생하는것 같습니다.

  6. slave 구성후 엑스트라 백업은 어떠신지요??
    dump백업은 사용자 없는 시간에 돌리는게 좋을듯 하구요,가능하면 slave 구성해서 slave에서 백업을 하시는건 어떨지요???

    그래도 문제가 있다면 rds나 오로라 추천 드립니다
    dbms가 mysql 이 맞으시다면요

  7. JaeBeom Cho slave 구성을 한다면 데이터를 반영하기 위해 주기적으로 로그백업을 해서 넘겨야 하는데 시간이 짧을 뿐이지 로그백업이 수행되는 동안 동일한 문제가 발생했습니다. RDS의 경우 사용할 수 있는 옵션들이 제한적인게 많아서 DBA가 있는 입장에서는 EC2가 비용도 싸고 튜닝하기도 더 나아 보여서 백업때문에 RDS를 선택한다는건 좋아 보이지 않았습니다. 그리고 MySQL은 아니고 Microsoft SQL Server입니다. ^^;

    Kyosung Choo 교성아.. 유지관리계획으로 백업을 할때, 3rd party 솔루션을 이용해 백업을 할때, SQL Server에서 제공하는 기본 로그전달을 구성할때 등 이런 옵션을 줄수가 없는 경우가 많은데 이럴땐 어떻게 해야 하지? 그리고 이 옵션은 대역폭을 명시적으로 제한하는 옵션은 아닌거 같은데 그 옵션을 주면 대역폭 문제가 발생하지 않는다고 다른 사람들에게 어떻게 설명을 하지?

  8. 정의용 간단한 예로 RDS에서는 SQL Server의 시작 파라메터로 주는 옵션을 AWS에서 제공하는 몇가지(10개정도?) 밖에 설정할 수 없습니다. 사용자에게 connection string만 제공하는 형태이기 때문에 어쩔수 없는거 같구요. SQL Server가 설치된 windows로 접속을 못할테니 windows에서 일반적으로 성능 모니터링을 위해 사용하는한 Perfmon 같은것도 사용 안될것 같습니다. DBA입장에서 SQL Server로 connection만 된다는건 건드릴 수 있는 부분이 많이 제한되게 느껴지는건 사실입니다.

  9. 파라미터 그룹에 왠만한건 다 가능하던데요 실제 그렇게 사용도하구요 프로시져도 문제없고 흠.. rds사용하는 고객들도 몰라서 첨에 해맬뿐이지 파라미터 그룹 활용하면 rds 인스턴스별로 설정이 가능합니다. 어떤 옵션이 안되는지 알 수 있을까요?

  10. 파라미터 그룹에 들어가셔서 UI를 보면 시작 파라메터로 TraceFlag 10개 정도와 나머지는 모두 sp_configure 명령으로 설정할수 있는 옵션들입니다. 지정된 10개 TraceFlag외에는 아무것도 지정할 수 없는게 문제인거죠.

    아래 이미지에서 앞쪽에 보이는 숫자들이 TF(TraceFlag)입니다.
    http://www.brentozar.com/wp-content/uploads/2015/06/RDS-%C2%B7-AWS-Console-2015-06-18T09-17-48.png

    예를들어 lock pages in memory 옵션을 지정하기 위한 845옵션이 없습니다.
    이건 단순한 예시이구요 SQL Server를 튜닝하다 보면 상황에 따라 다양한 TF를 설정해야 할 수 있어야 하는데 너무 부족한듯 합니다.

  11. RDS는 DBA 입장이 아닌 개발자 입장에서의 선택이라서 제한이 많은 편이예요. 만약 세부적인 설정, 모니터링 등을 위해서는 EC2에서 with SQL Server 버전을 선택하시는 것이 바람직해 보입니다.

  12. 스냅샷의 경우 초기 1회는 매우 느린편인데 그 이후에는 증분백업이라 빠른 편입니다. 단, DB 내용이 많이 변경이 되는 것이라면 스냅샷의 주기도 짧게 가져가야 빠른 백업이 가능하죠.

    DB백업시 어느 순간부터 속도가 떨어지는 이유는 EBS 버스트 기능이 들어가서 i/o가 크지 않을 경우 일정 시간 이후에 최대성능으로 사용할 수 있거든요. 물론 최대성능 역시 일정 시간 이후에 원상복구 되기 때문에 앞서 초당 1000으로 떨어진 시점이 바로 현재 사용하시는 EBS의 기본 성능이라고 보시면 됩니다.

    EBS는 볼륨크기 에 따라 iops가 변경이 되기에 용량을 늘려서 속도를 보장하는 방법과 iops를 고정으로 쓰는 방법이 있어요. 이건 비용 부분을 살펴보시고 용량을 변경 하시면 좋을 것 같아요.

    EBS 볼륨크기에 따른 기준성능과 최대 버스트 기간은 아래의 링크를 참고 하세요.
    http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

    더불어 SSD로 바뀐 최근에는 Raid를 쓰는 것과 단일 용량을 늘리는 방법이 별로 차이가 없는 것 같더라고요.

  13. MSSQL 이었군요.. 이해 했습니다.. 좋은 부분을 알게 되었습니다.
    확실히 AWS 의 RDS MSSQL 은 클러스터도 안되고 인프라적인 부분에서도 불편하죠
    “스냅샷의 경우 크기가 큰 최초의 스냅샷이나 변경된 블록이 많은 후속 스냅샷의 경우 몇 시간씩 걸릴 수 있습니다”

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.