Page History
| Info |
|---|
DB구조가 어떻게 생기고 또한 작동이되는지? 관심밖이였으며 몰라도 된다란 생각을 그동안 하였습니다. 하지만 최근 선배개발자님의 오라클 사내 교육을 수강하면서 생각이 바뀌었습니다. 오라클(DB)에서 이미 고민했던 문제가 알게모르게 어떠한 개발컨셉에서 활용되고 있으며 우리의 어플리케이션 설계에 있어서도 도움이된다란것입니다. 물론 성능좋고 유연한 SQL문을 작성할수 있는것은 보너스입니다만 저는 전자쪽에 조금더 관심이 많습니다. |
오라클의 주요 아키텍쳐
개인적 관점에의해 오라클의 아키텍쳐와 최근 학습중인 분산처리 어플리케이션 개발의 아키텍쳐와 닮은 부분이 있어서 연결고리를 만들어 보았습니다.
| ||
| Warning | ||
|---|---|---|
오라클 아키텍쳐를 설명할 내공이 없어서 원본사진을 그대로 담았으며 오라클에서 사용되는 고유 단어에 대해 설명은 하지않고, 노랑링크로 이해가 쉬운 블로그 링크 참조하였습니다
|
어플리케이션 설계에 있어서 공통해결과제
여기서의 어플리케이션은 분산서비스환경에서 작동하는 어플리케이션이며
이와 관련해서는 별도로 정리중에 있습니다.
참고링크 : http://wiki.webnori.com/display/AKKA
동시성 대량 요청처리
...
대량의 클라이언트 요청을 어떻게 합리적으로 처리를 하느냐에 대한 고민이며
...
어플리케이션에 있어서도,대량의 요청을 처리하기 위해 성능 튜닝에 관련된
스레드를 옵션화하고 최적화할수 있는 Dispatcher 개념에대해 고민해야합니다.
관련 개인 학습 자료 개인정리자료 :Dispatcher
데이터 무결성
...
데이터 무결성을 지키기 위해, 오라클은 몇가지 제약조건을 제시합니다.
이제 몇몇 언어 설계자들은 아예 가드레일을 치고 구속복을 입혀가며 프로그래머들이
널 포인터 역참조 또는 경합 조건과 같은 과거 세대의 실수를 반복하지 않도록 하기 위해 애쓰고 있다.
물론 이러한 제약은 완벽하지 않으며, 나쁜 습관을 반사적으로 피해가는 유능한 프로그래머에게는 오히려 성가신 요소가 되기도 한다.
그러나 많은 프로그래머들이 새로운 언어들의 엄격한 규율과 부가적인 구조를 반갑게 받아들이는 중이다.
-프로그래밍에 있어서 제약조건
그러면 이러한 무결성 달성을 위해 어플리케이션 개발자가 부가적으로 해야되는 행동은?
어플리케이션 개발자는? 사용자에게 출발하여 데이터가 저장되기전까지 진실된 메시지 전송 보장을 해야합니다.
...
데이터 전송이 100% 이루어집니까? '예스' 라고 한다면 언랭에서는 그것은 거짓화된 추상화처리라고 정의하고 있습니다.
-몇가지 통신라이브러리는 전송성공을 가정하며 그것이 항상 성공한것처럼 보이려고 합니다.
메시지 전송보장은 거짓없는 몇가지 체크포인트와 최소한의 보증을 가지고 이루어집니다.
메시지 전송보장을 위한 노력 : http://erlang.org/faq/academic.html#idp32880720 ( 10.9절 참고 9:언랭에서 크게 성공을 거둔 컨셉 )
관련 개인 학습 자료 개인정리자료 : MessageDeliveryReliability
장애대응을 하는 캐시처리
...
오라클 관련 키워드 : LGWR
오라클은 빠른 캐시처리름 캐시처리를 함에 동시에 장애발생에 대응하기위해 DB의 변경 변경부의 스냅샷(로그)을 유지하려고 합니다.
Redo Log <> 스냅샷의 본질적 의미와 사용기술이 다를수있으나
Redo Log 는 주로 100만분의1초의 변경도 감지하고 기록하는 고성능 CCTV라고하면
스냡샷은 주로 필요할때 찍는 백업의 용도로 쓰입니다.
여기서는 Redo Log = 지속적인 변경부의 스냡샷이라고 해두겠습니다.
(Wha is the diffrence between a Redo log and Snapshot에서 더 세부적인 차이를 검색하실수 있습니다.)
물론 로그를 자주기록할때마다 성능은 희생됩니다. 성능과 안정성을 동시에 올리는것은 아주 어려운일입니다.
어플리케이션 개발자는? 대부부분의 DB이외의 DB이전의 처리를 메모리및 디스크에서 하고 있으나있으며 ,
어플리케이션이 중단되거나 ,메모리가 휘발될때에 대해 대응을 하지못하여
마지막 상태를 DB에 기록하지 못하는이상 완전및 부분 복구를 할수없다란 것입니다.
심지어 정상적인 업데이트 절차에서도, 사용자의 세션이 초기화가 됨으로 생기는 문제에대해 대응을 하지 않습니다.
우리는 우리가 가진 로컬 DISK를 낭비적일만큼 활용하지 못하고 있으며
필요하면 , 어플리케이션도 메모리에 휘발성이 있는 메모리 복구와 관련된 스냅샷처리에대해 고민을 해야합니다.
저장장치를 분산하고 안정성이 보장이 된다면, 몇가지 서비스를 캐시화하여 고성능 처리로 전환할수 있을것입니다.
어플리케이션에서는 이것은 메모리에 영속성을 부여하는 Persitence 와 관련이 있습니다.
관련 개인 학습 자료 개인정리자료 : 03. Persistence
모니터링
...
오라클 관련 키워드 : PMON , SMON
서비스를 원활하게 유지를하고 대응하기위해서는 오라클에서는 자체 모니터링
데몬이 존재합니다. 이것은 오라클이 장애가 발생할수 있다란것을 가정하고 모니터링시스템이
장애에대한 최선의 노력을 한다란 의미입니다.
어플리케이션에 어플리케이션에 있어서도 동일한 목적으로
자체 진단기능에대해 고민을 해야합니다.
장애대처를 하기위한 기존 예외 핸들링에대한 문제점과 한계점을 인지하고
기존 예외 핸들링 try-catch 는 서비스의 복잡성만 늘리고
장애복구에 실제로 도움이 되지 않음을인지 하는것입니다.
그리고 보편적으로 구조적으로 설계가 잘 되어있지 않아
전역 try는 장애를 발생시키는 요인을 숨기게됩니다.
자체적인 감독자에의한 모니터링을통한 복구전략을 수립해야합니다어플리케이션에서는 관리자를 통한 장애처리모델과 관련이있습니다.
학습중인 관련 컨셉 : http://getakka.net/articles/concepts/supervision.html
개인정리자료 : Fault Tolerance