공부하자 - 1000dB

<서론>

프로젝트를 진행하면서 RAC와 HA라는 말을 듣게 되었다. 개발 지식 및 상식은 없다시피한 초보 코더라서 그 자리에서는 못알아들었지만 그저 웃으며 고개를 끄덕였다. DB 관련 용어라 앞으로도 많이 마주할 것 같아 이렇게 따로 정리해보려고 한다. 블로그에 있는 나의 대부분의 글들이 그러하듯 이 글 역시도 인터넷에 돌아다니는 내용을 내 입맛대로 짜깁기 한 것이라 매우매우 부정확한 내용임을 미리 경고해둔다.

<본론>

HA와 RAC 모두 DB 서버의 구성에 관한 것이고, 고가용성을 위해 만들어진 구성이라는 것

처음 RAC와 HA를 들었을 때, 완전히 다른 두 개념인 줄 알았다. 하지만 조금 찾아보니, HA 구성이 먼저 나왔고 HA에서 몇가지를 보완한 것이 RAC라는 것을 알았다(아, 물론 RAC 이전에 OPS라는 것도 있었지만 그건 넘어가도록 하자).

우선 HA.

HA(High Availability)는 2개의 서버를 이용하여 하나는 Active 상태, 나머지 하나는 Standby 상태로 정해놓는다. 거의 모든 부하는 Active에서 부담하고 Standby 상태의 서버는 Active 서버가 장애가 발생하지 않는 이상, 거의 가동하지 않는다. 실제 서비스를 운영하는 Active 서버가 어떠한 장애로 정상적인 작동이 불가능해진다면, 곧바로 Standby 서버가 Active 되면서 다시 서비스를 정상 작동할 수 있게 하는 구성이다.

이해하기 쉬운만큼 구조도 단순하고 따라서 구축 비용도 저렴하다. 또한, 서버 하나만 가동되면 되므로 유지비 역시 저렴하다는 장점이 있다.

하지만, 몇가지 문제점이 있다. 각 서버 별로 별도의 storage를 가지고 있기 때문에 수시로 동기화가 이루어져야 하고, 따라서 성능 저하를 야기할 수 있다. 또한 이런 특성 때문에 각 서버간 데이터 싱크가 맞지 않는 상황도 존재할 수 있다. 마지막으로 굉장히 큰 문제인데, Active 서버가 동작을 멈추면 Standby 서버가 활성화 될 때까지의 트랜잭션을 모두 유실하게 된다는 것이다. 이는 실시간 트랜잭션량이 많은 서비스에서는 치명적인 문제이다.

그렇다면 HA에서 더 보완을 한 RAC는 어떨까?

RAC(Real Application Cluster)는 2개, 혹은 그 이상의 인스턴스가 하나의 storage를 바라보고 있는 구성이다. 각각의 인스턴스를 서버라고 생각하고 HA와 비교한다면 Active, Standby가 아닌 모두 Active 상태라고 할 수 있다. 그리고 모두 하나의 storage를 바라보는 상황이므로 별도의 동기화로 인한 성능 저하는 없다. 또, 하나의 인스턴스에서 장애가 발생해도 곧바로 다음 인스턴스에서 처리해줄 수 있으므로 데이터 유실에 대한 우려도 없다. HA에서는 하나의 서버가 모든 처리를 해야했으므로 상대적으로 큰 부하가 발생하지만, RAC 구성에서는 균형있게 분산되어 처리할 수 있다.

하지만, 이 역시도 단점이 존재한다. 우선 Oracle RAC가 매우 고가의 제품이라는 것이다. 또한 매우 복잡한 환경 구성으로 인해 유지보수 절차 역시도 복잡하며, 운영 인력은 RAC에 대한 충분한 이해도 필수이다. HA구조보다 빠른 복구 시간을 보장하지만, 실제로는 RAC 구조를 다루는데 미숙해서 복구시간을 연장시킬 가능성도 있다.

<결론>

HA : Acitve-Standby 구조. 비용이 적게 들고 간단하지만, 데이터 동기화 문제와 장애 발생 시, 정보 유실 우려

RAC : 여러 인스턴스가 하나의 Storage를 바라보는 구조. HA에 비해 성능과 안정성 모두 뛰어나지만, 비용이 많이 들고 다루기 어려움

장황하게 적어놨지만 결론은 이렇다!

사실 표를 그리거나 이해하기 좋은 그림을 넣고 싶었지만, 이런 막글을 누가 본다고 정성을 쏟을까.. 나중에 내가 다시 볼때 알아보기 쉽게 볼드 처리만 해놔야겠다.

<참조>

1. https://sksstar.tistory.com/63

2. http://blog.naver.com/PostView.nhn?blogId=dark009&logNo=150171352412

3. http://www.dator.co.kr/dataworld/textyle/42729

4. https://codelib.tistory.com/23

그리고 이건 그냥 참고하면 좋을 것

https://irkim.tistory.com/entry/HA%EC%99%80-RAC%EC%99%80%EC%9D%98-%EB%B9%84%EA%B5%90

1. 변수 사용

구글링 결과 제일 많이 나온 방법.. 잠깐 쓰고 버릴 변수를 만들고 그 변수로 ROW_NUMBER() 뒤에 오는 OVER() 조건에 넣어줬다.

이것이 그 쿼리...

DECLARE 부터 통째로 MyBatis 쿼리 xml 파일에 넣었다.

그랬더니 깔끔하게 동작!

2. 서브 쿼리 사용

OVER()의 조건에 상수가 들어가지 않는다는 것이 문제였는데.. 생각하다보니 서브쿼리를 넣으면 어떻게 될까 궁금했다.

결과는 성공. 결국 상수 직접은 아니면서 1이기만 하면 다 되는 것 같다.

깨알팁.. 잊어버리지 않기 위해 블로그에 정리해서 올린다. 다음에도 MSSQL 쓸일이 있겠지.....

<서론>

최근 진행한 프로젝트는 쿼리대신 SP(Stored Procedure)를 이용했고, xml 파일에 별도에 쿼리를 작성하지 않았다.

내 개발 경력이 없다시피 한 수준이고 따라서 SP를 사용한 프로젝트가 처음이라, SP를 사용하면 어떤 장점과 단점이 있는지 이번 기회에 공부 겸 정리하고자 이렇게 블로그에 끄적여본다.

<본론>

1. SP란?

- SQL 명령문들을 마치 하나의 함수처럼 사용하기 위해 DB 내부에 저장된 쿼리의 집합이다.

2. SP의 장점

- 성능 측면

1. SP는 최초 컴파일 시 최적화되며 이후 DB에 캐싱되어 저장된다.

 최초 컴파일 이후엔 다시 컴파일 하거나 최적화 되지 않는다. 즉 자주 사용하는 쿼리일수록 SP로 처리하는 것이 큰 성능 향상을 야기할 수 있다.

2. 네트워크 트래픽을 감소시킬 수 있다.

 SP가 서버에 저장되기 때문에 쿼리가 필요할 때마다 쿼리를 전달해주지 않아도 되며, 필요한 매개변수만 던져주면 되기때문에 트래픽을 줄일 수 있다.

- 개발 측면

1. 개발 언어에 비의존적이다.

비즈니스 로직을 SP로 구현해 놓았다면 개발 언어가 바뀌더라도, 해당 DB에 SP를 호출할 수만 있으면 된다.

2. 유지 보수가 매우 편리해진다.(개발자 == 유지보수)

프로그램을 개발한 사람이 유지보수까지 하게 된다면 DB관련 작업을 할 때, SP만 수정해주면 된다. 비즈니스 로직도 SP로 구현했다면 WAS를 재기동할 필요 없이 SP만 수정하면 된다.

3. SP의 단점

- 개발 측면

1. 유지보수가 어렵다.(개발자 != 유지보수)

앞서 유지보수에 강점이 있다 서술했지만, 유지보수를 하는 사람과 개발한 사람이 다르다면 유지보수는 어려워질 것이다. 데이터 분석이 까다롭고 하나의 프로시저를 여러 곳에서 사용했을 경우 영향도 분석이 어렵다.

2. DB 확장이 매우 힘들다.

서비스 사용자가 많아져 서버의 수를 늘려야할 때, DB의 수를 늘리는 것이 더 어렵다. 또한,  DB 교체는 거의 불가능해진다.

<결론>

SP에 대해 알면 알수록 얻는 것에 비해 잃는 것이 많은 것 같았다. 위 단점에 서술하진 않았지만, DB 자원이 상대적으로 더 비싼데, SP로 비즈니스 로직을 처리하면 당연히 개발 단가가 올라갈 수 밖에 없을 것이다. 또한 서비스 확장을 위해 서버의 수를 늘릴 경우, DB의 수를 늘리는 것보다 WAS의 수를 늘리는 것이 더 효율적이기에 최근 대부분의 개발에서 DB에는 최소의 부담만 주고 대부분의 로직은 WAS에서 처리할 수 있게 한다고 한다.

블로그 글을 쓰기 위해 공부하면서 SP를 사용하는 프로젝트를 앞으로 또 만날 수 있을까 생각이 들었지만, 그냥 이런 게 있구나 하는 심정으로 글을 정리한다.

ps. 틀린 부분은 지적해주세요.

<참초>

https://itability.tistory.com/51

https://okky.kr/article/396251