DB구조가 어떻게 생기고 또한 작동이되는지? 관심밖이였으며 몰라도 된다란 생각을 그동안 하였습니다.
하지만 최근 선배개발자님의 오라클 사내 교육을 수강하면서 생각이 바뀌었습니다.
오라클(DB)에서 이미 고민했던 문제가 알게모르게 어떠한 개발컨셉에서 활용되고 있으며
우리의 어플리케이션 설계에 있어서도 도움이된다란것입니다. 물론 성능좋고 유연한 SQL문을 작성할수 있는것은 보너스입니다만
저는 전자쪽에 조금더 관심이 많습니다.
오라클의 주요 아키텍쳐
실제 강의때 언급된 오라클 아키텍쳐 그림한장으로,어플리케이션에서 몇가지 연결고리를 발견하였습니다. (개인적 관점에의한)
오라클에서 사용되는 용어에 대해 설명은 별도로 하지않고 노랑링크로 이해가 쉬운 블로그 링크로 대체하였습니다. (내공부족 구글링)
어플리케이션 설계에 있어서 공통해결과제
동시성 대량 요청처리
대량의 클라이언트 요청을 어떻게 합리적으로 처리를 하느냐에 대한 고민이며
오라클에서는 Dispatcher와 관련된 설정화를 통해 전략수정을 할수가 있습니다.
어플리케이션에 있어서도,대량의 요청을 처리하기 위해
스레드를 옵션화하고 최적화할수 있는 Dispatcher 개념에대해 고민해야합니다.
관련 개인 학습 자료 :Dispatcher
데이터 무결성
데이터 무결성을 지키기 위해, 오라클은 몇가지 제약조건을 제시합니다.
그러면 어플리케이션 개발자는? 사용자에게 출발하여 데이터가 저장되기전까지 진실된 메시지 전송 보장을 해야합니다.
거짓된 메시지처리( 값이 중간에 바뀌거나? 드랍되었는데 성공처리를 한다거나?)에 의해
DB의 노력이 물거품이 될수 있기때문입니다.
데이터 전송이 100% 이루어집니까? '예스' 라고 한다면 언랭에서는 그것은 거짓화된 추상화처리라고 정의하고 있습니다.
메시지 전송보장은 거짓없는 몇가지 체크포인트와 최소한의 보증을 가지고 이루어집니다.
메시지 전송보장을 위한 노력 : http://erlang.org/faq/academic.html#idp32880720 ( 10.9절 참고 : 언랭에서 크게 성공을 거둔 컨셉 )
관련 개인 학습 자료 : MessageDeliveryReliability
장애대응을 하는 캐시처리
오라클 관련 키워드 : LGWR
오라클은 빠른 캐시처리름 함에 동시에 장애발생에 대응하기위해 DB의 변경 스냅샷(로그)을 유지하려고 합니다.
물론 로그(스냅샷을) 자주찍을때마다 성능은 희생됩니다. 성능과 안정성을 동시에 올리는것은 아주 어려운일입니다.
어플리케이션 개발자는? 대부부분의 DB이외의 처리를 메모리및 디스크에서 하고 있으나
어플리케이션이 중단되거나 ,메모리가 휘발될때에 대해 대응을 하지못하여 완전및 부분 복구를 할수없다란 것입니다.
필요하면 , 어플리케이션도 메모리에 복구와 관련된 스냅샷처리에대해 고민을 해야합니다.
어플리케이션에서는 메모리에 영속성을 부여하는 Persitence 와 관련이 있습니다.
관련 개인 학습 자료 : 03. Persistence
모니터링
오라클 관련 키워드 : PMON , SMON
서비스를 원활하게 유지를하고 대응하기위해서는 오라클에서는 자체 모니터링
데몬이 존재합니다. 어플리케이션에 있어서도 동일한 목적으로
자체 진단기능에대해 고민을 해야합니다.
어플리케이션에서는 관리자를 통한 장애처리모델과 관련이있습니다.
학습중인 관련 컨셉
http://getakka.net/articles/concepts/supervision.html