선생님 질문이 있습니다~

계속 이어서 답변 드리겠습니다. 

+  일반적인 회사에서는 메인DB?로 오라클을 제일 많이 운영하는 것 같은데요~ 요즘 빅데이터로 활용 측면에서 오픈 DBMS(maria, mongo db)도 선호하는 것 같은데 오라클이 오픈DBMS에 비해서 안정적인 운영면에서 최대 장점은 어떤 점이라고 생각하시나요~? 

=> 오라클의 가장 큰 장점은 안정성, 성능, 운영/관리 편이성 입니다. 

안정적인 운영면에서 최대 장점은 개별 기능을 얘기하는 것 보다는 그동안 오라클이 보여준 Mission Critical 시스템에서의 운영 경험이라고 얘기하는게 제일 좋을 것 같습니다. 금융권 기간계는 오픈 소스 db를 사용하지 않으며, 대부분이 오라클이고 일부 IBM DB2가 있습니다. 또한 대부분의 제조쪽 기간계 역시 오라클DB이며, 일부(일부 보다는 많습니다) MS-SQL 서버를 사용하고 있습니다.

하지만 요근래는 오픈소스 DB가 많이 활성화 되어 있습니다. 오픈 소스 DB역시 많은 안정성을 가지고 있습니다. 그렇다고 오픈소스 DB로 기존에 오라클을 무조건 대체할 수는 없습니다. 세부 기능적으로 많이 다르기 때문에 오라클 DB 경험자들이 오픈 소스 DB를 실제 운영하다보면 여러가지 부족한 점을 많이 느낍니다. 

+그리고 성능분석은 시스템레벨->세션레벨->SQL레벨로 진행한다고 설명해 주셨는데요~ 갑자기 위 경우처럼 동시접속자수가 급증하면서 서비스 제공을 할 수 없으면(이런 경우는 재해복구가 아닌 것 같은데 DR센터에서 작업을 해주어야 하나요;;) 일반적으로 어떤 순서로 실무에서는 대응을 하는지도 궁금합니다 ^^

=> DR로 동시 접속 부하를 분산하기 위해서는 미리 애플리케이션 단에서 이러한 작업이 선행되어야 합니다. 동시 접속자 수가 급증했을 경우 DR로 조회성 쿼리(DML 제외)를 분산할 수 있도록 애플리케이션 서버단에서 접속 분산을 시켜줘야 합니다. 

하지만 질문은 동시 접속자수 급증에 따른 서비스 제공을 할 수 없을 경우라고 하셨으니까, 이런 경우는 DR로 돌려봐야 과부하로 DR도 죽습니다.  

동시 접속자수 급증의 경우에는 가장 부하를 많이 사용하는 서비스를 내릴 수 밖에 없습니다. 일단 내리고 접속 사용자를 진정 시켜야 합니다.  이런 경우를 예방하기 위해서 동적 자원할당들을 수행하려면 사전에 많은 준비를 통해서 시스템을 구축해야 합니다(이 방식은 너무 많은 설명이 필요하므로 여기까지만 설명 드리겠습니다)

+끝으로 한가지만 더 여쭤봐도 될까요~;;  3번 답변해주신 내용 중에서 DB단에서는 최소 10ms으로 줄여야 한다는 말씀은 수행시간인가요 아님 1회 wait time 기준인 건가요~? 그리고 RAC 증설 후 동시접속자수 테스트는 실무에서도 swingbench에서 동시접속자수 지정해서 테스트해 보는 방법이 일반적인지요..업무적으로 재정의한다는 말씀은 접속 경로를 변경한다는 뜻인가요~?

=> DB에서 수행하는 전체 시간을 10ms 로 잡은 것입니다. 일반적으로 신규 시스템/기존 증설 시 동시 접속자수를 정확하게 테스트하려면 swingbench보다 더 정교한 시스템을 도입해야 합니다. swingbench는 정해진 로직 예를 들어 Order Entry에 최적화 되어 있습니다. 하지만 일반 사용자 시스템은 Order Entry 형태가 당연히 아닌 경우가 대부분입니다. 물론 Swingbench로는 사용자 로직을 구성할 수 있지만, 이것은 swingbench를 아주 잘 다뤄야 할 뿐만 아니라 로직을 구성하는 시간도 매우 많이 소모됩니다. 

상용 load 툴의 경우 사용자가 UI에서 수행하는 로직을 db에서 수집해서 이것을 load 시나리오로 만들 수 있습니다. 이렇게 하려면 상용 툴도 사야하고, 이 툴을 구동할 수 있는 엔지니어도 함께 투입되어야 합니다. 

업무적으로 재 정의하라는 것은 SQL 로직을 업무적으로 줄이라는 것입니다. 가령 게시판 로직을 경우 밑에 바로가기 Link로 게시판 paging을 만들어야 한다면 이러한 UI 로직을 제거하는 것입니다. 

+수업내용 중에 RAC이 한 DB에서 여러 instance를 띄울 수 있다고 하셨는데 오라클 DBMS 라이센스를 구매할 때 RAC서버를 따로 구매해야 한다는 말씀이신가요~? (인터넷으로 찾아보니 오라클 데이터베이스 RAC 1000유저 (1000명 동시접속자 커버가능한 서버인 듯 한데요~) 4억정도 가격이던데.. 유지보수 서류에는 Multi-Instance라고만 기재되어 있고 RAC이라는 용어는 없어서 RAC이 도입되어 있는지 확인하기가 어려워서요~) 

=> 네, RAC 라이센스는 별도로 구매해야 합니다. 오라클 DBMS 라이센스에 RAC Option 라이센스가 있습니다. RAC 여부는 DBA에게 물어보시면 될 것 같습니다. 

이어서 계속 답변 드리겠습니다. 

6. DB백업정책을 세운다고 하면 강의시간에 말씀하신 DR센터에서 active-active, active-standby 정책으로 핫, 웜, 콜드 방식으로 운영할 지를 결정하는 건가요~? 그리고 보안이 중요해서 DB보안솔루션을 적용하면 성능이 좀 안 좋아지지는 경향이 있는지도 궁금합니다.  

=> 백업과 DR은 살짝 성격이 다릅니다(이걸 몰라서 질문하신건 아닌것 같습니다만..)

상세한 DB 백업 정책은 너무 범위가 커서 여기서 말씀 드리기가 어렵지만, 대략적으로는 Hot Backup, Cold Backup 으로 나눌 수 있습니다. 

보통 Hot backup은 DB를 정상적으로 운용하면서 백업을 받습니다. 데이터 파일, 아카이브 파일, Control 파일을 백업 받습니다. 이때 전체 데이터 파일을 다 백업 받을 것일지, 가장 최근 백업 이후로 변경된 부분만 백업을 받을 것인지에 따라 incremental backup을 결정하게 됩니다.  Cold backup은 말 그대로 DB를 Shutdown 한 상태에서 백업을 수행하는 것입니다. 

이밖에도 백업 정책은 백업 주기등 여러가지를 포함합니다. 가령 Hot backup 1회/1일, Cold backup 1회/3개월등. 이는 사이트의 특성, 최소 복구 시간, 최대 데이터 손실량등을 여러 요소등을 감안하여 백업 정책을 세우게 됩니다. 

DR 시스템에서도 백업을 받을 수 있습니다만, 설명이 길어질것 같아 생략하도록 하겠습니다. DR 시스템 백업의 전체적인 방향성은 위와 비슷합니다. 

DB 보안 솔루션을 적용하면 일반적으로 성능이 저하됩니다.  피할 수는 없지만 POC등을 통해서 어느정도 영향이 되는지 테스트를 반드시 해보는 게 좋습니다. 오라클 TDE 같은 경우는 오라클 Kernel 단에서 보안이 되므로 거의 성능 저하가 발생하지는 않지만, DB 보안의 경우 국정원 인증등의 이슈로 워낙 국산 솔루션을 권장하므로 조직내에서 규격이 정해져 있습니다. 성능 이슈보다는 이에 대한 이슈가 더 앞섭니다. 

7.  성능측정도구가 TPC-H, maxgauge라는  솔루션들도 있던데 DB성능 측정하려면 swingbench로 성능테스트하고 awr report로 분석하는 방법이 실무자분들이 사용하시는 일반적인 성능 측정 방법인가요~? 

=> TPC-H는 TPC org에서 정한 배치성 부하 테스트 프로그램입니다. TPC-H 프로그램을 TPC org에서 다운로드해서 배치성 프로그램 부하를 줄수 있습니다. 

maxgauge는 성능 모니터링 솔루션입니다. 국산 솔루션 중에서도 뛰어난 db 성능 모니터링 툴입니다.  TPC-H로 부하를 발생 시키고 maxgauge로 성능을 모니터링 할 수 있습니다만, TPC-H를 다루려면 좀 전문적인 능력이 필요하며 maxgauge는 가격이 좀 있습니다. 

실무자들이 swingbench + awr 또는 TPC-H + maxgauge로 성능 측정을 하기에는 좀 난이도가 있습니다. 실제 이를 활용하는 사람들은 어느정도 db 전문 경험이 많이 쌓인 사람들입니다.  제가 강의에서 말씀드린 내용들을 이해하고 이를 실무에 적용하는 수준에 이르려면 꽤 오랜기간 경험치가 쌓여야 합니다.  실무자라기 보다는 전문 DB 컨설턴트등이 Swingbench + awr을 활용합니다.  

8. 강의 내용 중에도 DB Link관련해서 설명해 주셨는데요~ 요즘은 DB Link를 ESB 인터페이스로 데이터를 교환하도록 시스템 수정을 하는 경우가 많은 것 같아서요~ ESB 인터페이스로 바꾸면 DB Link를 이용시 Remote SQL 성능문제는  해결이 되는 건가요~? 그리고 시스템 사이 서로 다른 인터페이스(ESB,MCI, FEP 등)를 연결할 때 이슈는 어떤 점이 있을까요~?

=> ESB로 인터페이스를 바꾸어도 Remote SQL의 성능 문제를 해결할 수는 없습니다. DB link는 하나의 DB에서 로컬 테이블은 물론이고 원격 DB의 원격 테이블을 바로 Access 할 수 있습니다. ESB는 두개의 서로 다른 DB에 서로 다른 접속을 하게 되고, 각각의 결과들을 ESB 단에서 결합하므로 DB Link와 유사한 처리를 합니다.  다만 처리를 수행하는 주체가 ESB로 바뀌었을 뿐입니다.  이 과정에서 성능 최적화를 위해서 개별 처리로직을 최소한으로 바꾸면서 튜닝을 수행할 수는 있습니다.  하지만 DB Link역시 튜닝을 통해 성능을 개선할 수 있습니다. 또한 ESB 로직을 통한 변환이 오히려 DB Link 최적화 보다 성능이 저하될 수 있습니다. 

결론 적으로 DB Link로 성능 문제가 있다고 이를 ESB로 해결할 수 없습니다(오히려 더 나빠질 수 있습니다). 만약 ESB로 누군가 해결했다고 한다면 그건 ESB로 업무로직 변경또는 개별 로직을 튜닝했기 때문이고 이는 DB Link 튜닝으로도 가능합니다.  

그리고 ESB 연결시의 이슈는 제가 ESB 전문가가 아니어서 잘 모르겠습니다. 

오늘은 여기까지만 답변 드렸으면 합니다. 

안녕하십니까, 

잘 듣고 계시다니 저도 기분은 좋은데,,, 한번에 너무 많은 질문을 올려 주셨군요. 

그것도 개별 질문이 답변에 많은 내용이 담겨 있어야 할 질문을 해주셔서, 살짝 난감하기도 합니다만,,, 어찌되었든 아래와 같이 답변 드립니다. 

1. 실무에서 시스템 성능(응답시간)이 안 좋다고 하면 데이터베이스 성능 문제때문인 경우가 대부분인가요~? 물론 경우에 따라 다르겠지만 응용시스템(s/w), 인프라(h/w)에 비해 SQL튜닝이나 강의 내용 해결방안을 적용하면 시스템 성능이 좋아지는 경우가 많은지 궁금합니다.

=> 업종별로 차이가 있을 수 있지만 금융권의 경우 시스템 성능이 안좋을 경우 (개인적인 생각으로는) 70% 정도는 데이터베이스 성능 문제인 것 같습니다.  이 중 80% 정도는 SQL 튜닝 또는 Storage를 고성능 H/W또는 SSD로 변경을 통해 해결될 수 있습니다. 특히 OLTP 프로그램은 HDD에서 SSD로 변경시 큰 성능 향상이 가능합니다(요즘은 거의 SSD가 대세라 이미 SSD Storage로 되어 있을 수도 있습니다)   나머지 20% 정도는 강의내용에서 다루는 instance tuning으로 해결이 될 수 있습니다. 

2. 강의 내용 중에 오전 시간같이 동시접속자가 많을 때는 배치수행을 하면 성능상 안 좋다고 하셨는데요~ 그럼 예를 들어, 리스크 배치 같은 많은 시나리오를 묶음 배치하는 경우 수행하는데 1일정도 소요된다면 오전 시간에도 배치가 수행될텐데요~ 이런 경우 수행 시간을 단축시키려면 시뮬레이션 솔루션?엔진? 성능을 향상시키는 방법밖에 없나요~? 그런 경우 일반적으로 실무에서는 벤더분들이 오셔서 작업을 해주시는지.. 아님 용역을 따로 발주하나요;;; (+ 일반 배치프로그램인 경우에도 배치수행시간 을 단축하려면 다시 프로그래밍하는 방법 밖에 없는지 궁금합니다) 

=> 배치 성능을 향상시키는 방식은 여러가지가 있습니다. 그중 가장 대표적인 방법은.

1. SQL 튜닝

2. 병렬 수행 성능 극대화를 위한 H/W 증설(또는 교체) 

- SQL에서 병렬 수행을 효과적으로 수행할 수 있도록 CPU Core 증설 및 Storage 증설(또는 교체)

이를 수행하는 방법은 딱 정해진것은 없습니다만, SQL 튜닝의 경우 DBMS 벤더(예를 들어 오라클)가 이를 직접 해주는 경우는 거의 드뭅니다. 물론 영업적으로 매우 중요한 고객 일 경우 오라클에서 직접 이를 수행해 주는 경우는 있지만 이는 매우 특별한 경우 입니다.  보통은 따로 용역을 발주하거나 유지보수 업체를 통해 전문 튜너를 요청하여 진행 할 수 있습니다. 유지보수 업체를 통해 전문 튜너를 요청할 경우 별도의 비용이 필요한지는 유지 보수 업무 계약 범위를 확인해 보시면 됩니다. 

3.  금융권에서는 오라클 도입하면 동시접속자 대응하기 위해서 RAC도 도입한다고 하셨는데요~ 어떤 서비스를 출시해서 신청기간동안 신청자가 급증해서 접속대기자가 20만명이 넘는 정도가 된다면 기존 750명정도로 구축된 시스템(최대 3초 내 디스플레이)에서는 최대한 대기시간을 줄이고 처리할 수 있는 방법은 없는 건가요~?(실무에서는 서버증설?임대?방법으로 대응하는 것 같던데.. 질문이 너무 추상적이라 죄송합니다..ㅜㅜ) RAC은 레거시시스템에 도입된다고 하셨는데 접속자분들은 홈페이지나 어플 채널을 통해서 접속을 해도 RAC이 어느정도 많은 동시접속을 커버할 수 있는 건가요~?    

=> 동시 접속 대응은 가장 중요한건 SQL 튜닝입니다. 그런데 질문 주신 기준 750명 정도로 된 시스템은 20만명 넘는 정도로는 아무리 SQL 튜닝을 잘해도 대응하기 어렵습니다. 

최대 3초내 디스플레이는 접속 대기자 20만명이라면 db 단에서는 최소 10ms(느낌상 10ms입니다만 아무 기준 없습니다) 로 줄어야 합니다. 물론 접속 대기자 20만명이 10ms 이상이 되는 SQL 쿼리를 날려야 한다면 이 경우는 반드시 업무적으로 재정의해서 10ms 정도로 SQL이 만들어 질수 있도록 해야 합니다. 

이렇게 SQL을 최적으로 만든 다음에 RAC등의 증설을 통해서 동시 접속 대기자수를 얼마나 받아 들일 수 있는지 테스트를 한 후에 용량 증설을 고려해야 합니다. 

RAC가 어느정도 많은 동시 접속을 커버할 수 있는지는 답변을 드릴 수가 없습니다. 다만 OLTP 성 프로그램인 경우 1개의 서버에서 동시접속 1000이라면 2개의 RAC에서는 1800~1900 정도 될 수 있습니다. 3개라면 2700정도, 그런데 이게 선형으로 무한하게 증가하지 않습니다. RAC가격도 고가로 2~3개만 되어도 가격이 부담입니다. 

4.  데이터베이스에서 DW로 ETL을 이용해서 데이터를 이관?한다고 하셨는데요~ 보통 ETL로 이동된 DW 데이터는 정합성측면에서 데이터베이스하고 불일치하는 경우는 많이 없나요~? 그럼 DB, DW 정합성을 확인, 유지하려면 실무에서는 솔루션을 이용해서 확인하나요(+ 외부기관에서 데이터를 가져오는 경우도 정합성, 무결성 검증을 솔루션 이용하는지 DBA분이 직접 작업하시는 건가요..) 

=> DW DB와 기간계 DB는 반드시 정합성을 맞추기 위해서 노력해야 합니다. 사실 ETL이나 DW 유지보수에서 많은 시간을 들이는 부분이 이 정합성 부분입니다. 보통은 솔루션을 사용하지 않고 DW/ETL 개발자들이 맞춥니다.  검증은 주로 DW/ETL 개발영역에서 배치 프로그램 기반으로 여러가지 검증 로직을 구현하여 수행을 합니다. 

5. 차세대시스템을 구축하면 기존 시스템에서 데이터 이관?을 해야 할텐데 이런 경우는 업무중단 최소화하려고 업무 외 시간에 마이그레이션?작업을 하는 건가요~? 그리고 데이터 이행하고 안정화 기간이 필요한 것 같던데 이런 경우 오라클은 안정화되는 동안 일반적으로 어떤 이슈들이 나오는 편인가요..

=> 물론입니다. 데이터 이관은 반드시 업무외 시간에 수행합니다. 물론 업무중에도 이행을 수행할 수 있도록 CDC 솔루션을 동원하여 중요한 테이블의 경우는 실시간 동기화를 맞추면서 수행할 수도 있지만, 기본은 업무 시간외 이관 입니다. 

데이터 이관후 안정화에 관련된 이슈는 너무 내용이 많아서 여기에서 답변 드릴 수가 없을 것 같습니다. 

질문 내용이 많아서 오늘은 여기까지 적고, 시간이 나는대로 나머지 내용 답변 드리겠습니다. 

선생님께서 설명해 주셔서 궁금증이 다 해결되었습니다~^-^ 

기회 되실때 다른 데이터베이스 강좌도 오픈해 주시면 꼭 수강하겠습니다~

감사합니다~^^ 꾸벅(--)(__)

바쁘실텐데 답변해 주셔서 너무너무 감사합니다 ~~

설명해 주신 내용을 보니 궁금했던 점들이 이제 이해가 갑니다~~

공부하려고 인강 많이 들었는데 제일 설명을 잘 해주시는 것 같습니다~(^_^)

다시 한번 감사드립니다~ ^^

저도 질문드리면서도 죄송해서 한 두가지만 알려주셔도 좋을 것 같다고 생각했는데 정성껏 답변해주셔서 너무 감사합니다~~

(ㅜ_ㅜ)   

끝으로 한가지만 더 여쭤봐도 될까요~;;  3번 답변해주신 내용 중에서 DB단에서는 최소 10ms으로 줄여야 한다는 말씀은 수행시간인가요 아님 1회 wait time 기준인 건가요~? 그리고 RAC 증설 후 동시접속자수 테스트는 실무에서도 swingbench에서 동시접속자수 지정해서 테스트해 보는 방법이 일반적인지요..업무적으로 재정의한다는 말씀은 접속 경로를 변경한다는 뜻인가요~?

수업내용 중에 RAC이 한 DB에서 여러 instance를 띄울 수 있다고 하셨는데 오라클 DBMS 라이센스를 구매할 때 RAC서버를 따로 구매해야 한다는 말씀이신가요~? (인터넷으로 찾아보니 오라클 데이터베이스 RAC 1000유저 (1000명 동시접속자 커버가능한 서버인 듯 한데요~) 4억정도 가격이던데.. 유지보수 서류에는 Multi-Instance라고만 기재되어 있고 RAC이라는 용어는 없어서 RAC이 도입되어 있는지 확인하기가 어려워서요~) 

+  제가 혼자 공부하다가 궁금해서 여쭤본거라서 나머지 질문들은 꼭 답변 안해주셔도 괜찮습니다~^^  그냥 드리는 말씀이 아니라 강의가 너무 좋습니다~ 나중에 기회가 되신다면 SQL 튜닝강의도 오픈해주시면 좋을 것 같습니다~ ^^