MSSQL Always ON 을 사용하기 위한 전략

먼저 그림을 보면 기존에 MSCS 서비스와는 달리 CSV 클러스터 공유볼륨이 필수조건이 아닙니다. 서버 박스의 인터널 레이드 볼륨 디스크나 단독 DAS 및 공유구성을 하지 않은 저장장치를 사용할수 있게 되었습니다.   서비스는 MSCS가 필수이긴 하지만 쿼럼디스크 역시도 공유볼륨을 사용하지 않아도 됩니다. 공유폴더를 사용해도 되고 기본값으로 유지해도 클러스터 서비스는 유지가 되기에 예전에 필수 종속이 많이 자유로워진거는 사실입니다.

MSSQL 2005 부터 DB 미러링 기능이 추가되었는데 그당시 구성해보고 사용해본 결과로 아쉬운건 복제된 서버에 데이터 읽기가 불가능한건 아니지만 스냅샷을 찍고 읽어야 하는 수동작업이 필요했고 관리자를 통해야 하는 번거로움이 있었습니다. 둘째는 리스너인데 미러링 연결은 파트너A/파트너B 연결드라이버를 구성하여 자동 페일오버를 구성하여 진행하였지만 처음 자동 장애조치는 해결이 되었으나 다시 원복후 접속은 이루어지지 않는 단점이 존재했습니다.

이러한 문제를 해결한게 AlwaysON 구성입니다. MSCS에서 리스너 구성을 하고 SQL에서 복제를 하고 동기식 복제와 비동기식 복제 방식으로 안정성과 성능을 동시에 해결이 되었습니다.

대부분 AlwaysON은 MSCS처럼 이중화 목적으로 접근을 하기 쉬운데 이중화보단 읽기전용을 좀더 전략적으로 활용하기 위한 구성으로 접근하는것이 좋습니다. 서비스 되는 SQL서버에서 여러 테이블을 조인하고 조회하는 경우가 생기면 성능에 많은 영향을 주기 때문입니다. 통계나 보고서 목적으로 타 업무 서비스에서 데이터를 조회하는 경우 서비스되는 SQL서버에 붙어서 실행되면 난리가 나는 경우도 흔합니다. 실제 서비스가 그 많은 데이터 조회 때문에 대기를 타는 경우가 많아서입니다.

먼저 윗 그림에서는 동기방식인데  보조노드가 먼저 커밋되어야만 주노드가 커밋되는 구조입니다. 즉 보조노드에서 백업이나 통계 및 보고서 데이터IO를 많이 일으키게 되면 주노드에서 영향을 주기도 합니다. 보통 이런경우는 드물기는 하지만 엔터프라이즈 환경에서는 종종 발생하는 현상이기도 합니다. 그러기에 두번째 그림처럼 비동기식 노드를 추가하여 활용하는 방법이 있습니다. MSSQL은 읽기전용을 사용하지 않으면 1개의 인스턴스 라이센스 비용만 들어간다고 합니다. 그러기에 AlwaysON은 장애조치 용도는 읽기전용을 사용하지 말고 DR 구성으로 추가하여 비동기 방식으로 조회서비스를 전략적으로 사용하는것이 안정성이나 성능이나 큰 효과를 볼수가 있습니다. 비동기라고 하면 데이터가 늦게 출력되지 않나?라고 의구심을 가질수 있지만 거이 그런 경우는 드물다고 볼수 있습니다.  1G 네트워크만으로도 실시간으로 복제하는데는 충분하고 최근에는 10G 네트워크를 사용하는 추세이다 보니 고민할 사항은 전혀 아니라고 할수 있습니다. 1G 네트워크 속도가 많이 아쉽다고 느끼는 상황이 있는데 이 경우는 대용량 테이블을 인덱스 리빌드 하거나 대용량 테이블을 온라인으로 파티션 구성할때 였습니다. 이 경우는 보조노드가 커밋되는 디스크 속도에 따른 네트워크 속도도 어느정도 따라줘야 하는 경우가 있긴 하지만 이런 경우 역시도 흔한 경우가 아니기 때문에 고려사항은 아닐거라고 판단이 됩니다.

마무리 하며 MSSQL AlwaysON 구성은 이중화로 접근하기 보다는 안정적으로 서비스 부하분산을 목적으로 접근하는것이 매우 효율적이다라고 말하고 싶고 이부분을 고려하여 전략적으로 사용하는걸 권장하는바입니다.