어플리케이션 설계에 있어서 공통해결과제

여기서의 어플리케이션은 분산서비스환경에서 작동하는 어플리케이션이며

이와 관련해서는 별도로 정리중에 있습니다.

참고링크 : http://wiki.webnori.com/display/AKKA

동시성 대량 요청처리

---

 

대량의 클라이언트 요청을 어떻게 합리적으로 처리를 하느냐에 대한 고민이며

오라클에서는 Dispatcher와 관련된 설정화를 통해 전략수정을 할수가 있습니다.

어플리케이션에 있어서도,대량의 요청을 처리하기 위해 성능 튜닝에 관련된

스레드를 옵션화하고 최적화할수 있는 Dispatcher 개념에대해 고민해야합니다.

개인정리자료 :Dispatcher

데이터 무결성

---

데이터 무결성을 지키기 위해, 오라클은 몇가지 제약조건을 제시합니다.

이제 몇몇 언어 설계자들은 아예 가드레일을 치고 구속복을 입혀가며 프로그래머들이

널 포인터 역참조 또는 경합 조건과 같은 과거 세대의 실수를 반복하지 않도록 하기 위해 애쓰고 있다.

물론 이러한 제약은 완벽하지 않으며, 나쁜 습관을 반사적으로 피해가는 유능한 프로그래머에게는 오히려 성가신 요소가 되기도 한다.

그러나 많은 프로그래머들이 새로운 언어들의 엄격한 규율과 부가적인 구조를 반갑게 받아들이는 중이다.

-프로그래밍에 있어서 제약조건 

그러면 이러한 무결성 달성을 위해 어플리케이션 개발자가 부가적으로 해야되는 행동은?

사용자에게 출발하여 데이터가 저장되기전까지 진실된 메시지 전송 보장을 해야합니다.

거짓된 메시지처리( 값이 중간에 바뀌거나? 드랍되었는데 성공처리를 한다거나?)에 의해

DB의 노력이 물거품이 될수 있기때문입니다.

데이터 전송이 100% 이루어집니까? '예스' 라고 한다면 언랭에서는 그것은 거짓화된 추상화처리라고 정의하고 있습니다.

-몇가지 통신라이브러리는 전송성공을 가정하며 그것이 항상 성공한것처럼 보이려고 합니다.

메시지 전송보장은  거짓없는 몇가지 체크포인트와 최소한의 보증을 가지고 이루어집니다.

메시지 전송보장을 위한 노력 : http://erlang.org/faq/academic.html#idp32880720 ( 10.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에 기록하지 못하는이상 완전및 부분 복구를 할수없다란 것입니다.

심지어 정상적인 업데이트 절차에서도, 사용자의 세션이 초기화가 됨으로 생기는 문제에대해 대응을 하지 않습니다.

우리는 우리가 가진 로컬 DISK를 낭비적일만큼 활용하지 못하고 있으며 

필요하면 , 어플리케이션도 휘발성이 있는 메모리 복구와 관련된 스냅샷처리에대해 고민을 해야합니다.

저장장치를 분산하고 안정성이 보장이 된다면,  몇가지 서비스를 캐시화하여 고성능 처리로 전환할수 있을것입니다.

이것은 메모리에 영속성을 부여하는 Persitence 와 관련이 있습니다. 

개인정리자료 : 03. Persistence

모니터링

---

오라클 관련 키워드 : PMON , SMON

서비스를 원활하게 유지를하고 대응하기위해서는 오라클에서는 자체 모니터링

데몬이 존재합니다. 이것은 오라클이 장애가 발생할수 있다란것을 가정하고 모니터링시스템이

장애에대한 최선의 노력을 한다란 의미입니다.

어플리케이션에 있어서도 동일한 목적으로

장애대처를 하기위한 기존 예외 핸들링에대한 문제점과 한계점을 인지하고

기존 예외 핸들링 try-catch 는 서비스의 복잡성만 늘리고

장애복구에 실제로 도움이 되지 않음을인지 하는것입니다.

그리고 보편적으로 구조적으로 설계가 잘 되어있지 않아

전역 try는 장애를 발생시키는 요인을 숨기게됩니다. 

자체적인 감독자에의한 모니터링을통한 복구전략을 수립해야합니다.

학습중인 관련 컨셉 : http://getakka.net/articles/concepts/supervision.html

개인정리자료 : Fault Tolerance