공부하자 - 1000dB

<서론>

프로시저에 비즈니스 로직이 녹아있는 프로젝트를 하다보니 여러 프로시저 안에서 다른 프로시저를 부르는 경우를 많이 봤다. 그런데 간혹 프로시저 말고, 사용자 정의 함수를 호출하는 경우도 보였는데, 갑자기 사용자 정의 함수는 왜 쓰는 건지 궁금해졌다. 계속 프로시저만 써도 될 것 같은데 어째서 사용자 정의 함수를 쓰는 걸까? 

<본론>

프로시저와 사용자 정의 함수 모두 호출하게 되면 미리 정의 해놓은 기능을 수행하는 프로그램들이다. 인터넷에서 쉽게 찾을 수 있는 이 둘의 차이점이라면 아마 리턴 값인 것 같다.

프로시저는 리턴값이 없어도 되지만, 사용자 정의 함수는 꼭 있어야 한다.
또한 프로시저는 리턴값이 하나가 아닌 여러 개로 나와도 되지만, 함수는 오직 하나의 값만 있어야 한다.

인터넷에서 찾은 답은 이해하기는 쉬웠지만 와닿지는 않았다. 왜냐, 정말 차이가 저것뿐이라면 굳이 사용자 정의 함수를 쓸 필요가 없기때문이다. 프로시저로 사용자 정의 함수가 할 수 있는 일을 다 할 수 있는데, 굳이 둘을 섞어가며 쓸 이유는 없을 것이다. 그래서 좀더 인터넷을 찾아 봤다. 찾은 답은 다음과 같다.

위 표와 같이 정리할 수 있는데, 특별히 굵게 처리된 부분이 사용자 정의 함수를 쓰는 이유의 핵심인 것 같다. 사실 표만 보면 프로시저는 되는데, 사용자 정의 함수는 안되는 것들이 무척이나 많다. 하지만 그 중 유일하게 가능한 것이 SELECT 쿼리 안에서는 사용자 정의 함수만 사용 가능하다는 점인 것 같다.

<결론>

배움이 부족하여 위와 같이 밖에 알아내지 못했다. 영어 실력이 좋았다면 영어로 된 문서들도 참고하면서 공부했을테지만, 한글도 제대로 못읽는 관계로 이정도로 마무리 지으려 한다.

<참고자료>

자료 출처를 적어놓지 못했다.. 원작자분들 죄송합니다.

<서론>

프로젝트를 진행하면서 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

<서론>

최근 진행한 프로젝트는 쿼리대신 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