[전산실 이야기] Oracle RAC 구성을 결정 하다 - 준비하기

규모가 그리 크지 않은 회사들만을 경험하다 보니 사실 이론적으로만 이해하고 있던 부분에 대해서 실제적인 경험으로 다기 올 때는 두려움과 설레임 두 가지가 함께 다가 온다. 물론 나는 DBA 이거나 아키텍처를 설계하는 엔지니어가 아닌 사내 내부 프로그램을 개발 하는 응용프로그래머 입장에서의 정리 내용이므로 깊이 있는 데이터베이스에 대한 것들은 전문적인 사이트에서 참고 하시는 것을 권한다.

http://www.dbguide.net/ 또는 http://database.sarang.net/


일반적으로 지금까지 경험해본 것은 대부분 단독형(Stand Alone)형태 이거나 복구용 이중화가 구성된 Active - Standby 구조만 경험해 보았다. 단독형의 경우에는 사용하던 오라클 인스턴스에 장애가 나거나 스토리지 부분에 장애에 대한 위험/리스크가 크기 때문에 최소한 이중화 정도 까지는 구현을 하는 것이 맞지 않나 싶다. 그런데 흔하게 이중화라고 하는
HA(High Availability) 구성이란 노드(Node Server로 이해하자) 1개는 항상 서비스를 하고 있는 활성(Active) 상태이고 나머지 한대는 장애가 발생하지 않는 한 항상 대기(Standby) 상태 이다. HA방식이 장애에 대응하는 구조를 가지고 있긴 하나 서비스 정지(Down Time)을 가진다는 것이다.

내부적으로 지금과 같은 중소(?) 규모의 시스템에서 과연 HA와 RAC 중 어느것을 해야 하는가에 대한 고민을 하게된 대목이기도 하다. 결국 비용차이가 그리 크지 않다는 전제하에 RAC로 결정을 하긴 하였으나 항상 그러하들 의사결정 후엔 불안과 설렘이 공존한다. 과연 잘한것인가? 아니 잘했을꺼야 하고 그걸 합리화 시키는 건지도 모른다. 어찌 되었든 HA구성이 가지고 있는 문제를 보완하여 나온 구조가 RAC 인것 같다. 인터넷을 이것 저것 찾아 보니 과거 버전엔 OPS(Oracle Parallel Server) 구성이란 것으로 처리 한것으로 보이는데 일단 이글 내용에선 제외하고 현재 시점에서의 내용만 기록을 남겨 보도록 한다.

음식점이니 간단한 시나리오로 정리 해보자면

1. 단독형 (Stand Alone)
  - 음식 주문 했다.
  - 장애 발생
  - 일단 주문도 안된다. 주문 됐는지도 확인 안된다.
  - 다시 살아 날때 까지 아무것도 못한다.

( 그러나 사실 음식접업 특성상 시스템이 다 죽어 버린다 한들 가능은 하다. 그래도 최소한 전기는 들어와야 한다. 눈감고 먹긴 힘드니까 - 단 밥을 언제 먹을 수 있을지는 장담하지 못하겟다. )

2. HA(High Availability)
   - 음식주문 창구 1 , 조리 창구 1 (음식주문/창구 2 대기)
   - 장애 발생
   - 음식주문 창구 2, 조리 창구 2 ( 대기 하고 있다 대신 처리 단, 처음 부터 다시 )
   - 가끔 서비스는 다시 가능 한데 전에 주문 했던걸 다시 해야 할수 있음(동기화 문제)
   - 일단 처리는 될 수 있으나 일정(수초 ~ 수분)한 시간 이후에 가능
   - 불편할 수 있으나 대응은 되었다고 본다.

( 그러나 사실 이것 또한 엄청 심한 컴플레인 요소가 되기도 한다. 음식점업 특성상 몰리는 시간이 정해져 있다. 점심/저녁 시스템에서 확인해야 할 할인내역이나 쿠폰 조회가 되지 않는다면 상상 해보라. 피크시간 다운타임 수분은 피를 말리는 일중 하나이다. )

위와 같은 상황을 격고 싶지는 않다는 것이 결론이었다. RAC 구축을 한다고 내부적으로 결론을 내렸다. 헉.. 그런데 돈이 엄청 든다. 물론 Enterprise 가격은 어마 어마 한것에 비하면 많지는 않으나 진짜 이걸 함으로 인해서 모든 장애 요소와 성능의 향상을 기대 할 수 있을까? 하는 두려움이 밀려 온다.

Oracle RAC(Real Application Clusters)는 두대의 서버(Node)에 하나의 스토리지를 공유하는 구조로 가져가고자 한다. 이러한 구조에서는 서버에는 각 인스턴스를 1개씩 구성하고 저장소는 공유하는 구조이다. RAC를 적용하기 이전 OPS는 인스턴스에서 하던 작업의 내용을 디스크에 저장해 두었다가 장애가 발생하였을 때 다른 인스턴스가 디스크에 있는 내용을 로드하여 처리를 해주는 방식이다 보니 디스크에 내용을 저장하고 다시 올려주는 과정에서의 성능적인 부하가 있었던 모양이다. RAC는 서로 다른 Instance 에서 변경된 데이터를 저장 디스크를 거치지 않고 바로 Instance 로 가져올 수 있는 기능인 캐시퓨전(Cache Fusion) 이라는 기능이 사용된다. 캐시퓨전은 서로 독립적인 인스턴스를 마치 하나의 인스턴스인것 처럼 데이터의 교환이 이루어지면서 섞여 있다라는 의미로 해석할 수 있을것 같다.

명확하게 어떤 숫자들을 봐야 하는지 뭐 전문가가 아니다 보니 사실 참 어렵다 어렵다는 생각을 항상 하게 된다. 그렇다고 전산실이 해당 업체를 100% 신뢰 하느냐? 뭐 상황이나 사람마다 다르겠으나 나는 보면 51%와 49%를 왔다 갔다 하는 편이다 보니 어떠한 자료와 근거를 요청 하고 다른곳에서도 비교해보는 것들을 하곤 한다. 모든 분야에 전문가가 될 수 없다 보니 사실 이런 부분이 어느 정도는 믿음을 가져주고 가는 경우가 많지 않을까.

기존의 단독형 구조에서 RAC구로로의 변화 뿐 아니라 기존의 WIN949 캐릭터셋에서 UTF-8로의 변화가 함께 진행 되는 나름 큰 마음 먹고 진행 하는 과정이 더 있어 어떤 부분들을 어떻게 좀더 신경을 써야 하고 스케쥴관리를 해야 하는지에 대한 것이 더 많을 것으로 생각이 된다. 오늘은 그것의 시작으로 어떤 항목과 어떤 단계의 과정에서 어떻게 준비하고 대응해야 하는지 작업을 시작하기 전에 간략하게 단독형(Stand Alone)과 RAC(Real Application Clusters) 구조에 대해서만 간략하게 기술해 보았다.

다음 포스트엔 체크포인트에 대한 부분과 전산실에서의 IT투자 후 평가에 대한 부분을 간략하게 나마 정리해보고자 한다. 규모에 대한 차이는 아니나 그러한 부분에 대해서 소홀 했던것은 사실이다. 우리에게 어떤 방향성이 있어야 하고 어떤 접근을 해야 하고 그래서 우리는 이것이 필요 합니다. 투자해주세요. 한 이후에 적절한 IT투자에 대한 효과 분석이나 평가분석이 부재 하였던 것은 스스로에게도 좀 부끄러운 일이고 조직에도 반드시 필요한 사례인것 같다.

혹 지나다 어설픈 저의 글을 보신 전문가 분들이 계시다면 덧글로 고견을 남겨 주시고 또 도움을 주실수 있는 의견도 언제든지 열려 있습니다.

오늘의 기록은 여기까지 이제 다시 현업으로.... 전산실의 길은 언제까지 일까..