'Programer Story/DB Stroy'에 해당되는 글 22건

  1. 2007.01.08 데드락 (Dead Rock) -3 by gala

작성자 : 손호성 (NTFAQ.CO.KR)

http://www.ntfaq.co.kr or http://www.mcse.co.kr

 

데드락과 라이브락(Deadlock and Livelock)

앞 부분에서 실무에서는 대략 서버의 상황이 어떠 어떠할 때 데드락이 발생한 게 아닌가

하고 의심해 본다고 했습니다. 물론 좀더 정확히 해보기 위해서는 데이터베이스를

주기적으로 추적해 보면 더욱 확실하게 알 수 있을 것입니다. 이제는 데드락이 왜

일어나는 지를 이해해 보기로 하죠. 데드락이 어떠한 상황에서 발생되는지를

이해하게 되면 이에 대해서 보다 잘 대처할 수 있을 것입니다.

 

우선 기억해야 할 것에 대해서 생각해봅시다. 데드락은 일종의 락(Lock)이고

데이터베이스가 처하는 상황(Situation)입니다. 이는 어떠한 기능을 일컫는 말도 아니고

소프트웨어의 버그도 아니며, 런타임 에러 상황도 아님을 반드시 기억해야만 합니다.

이는 정상적인 데이터베이스의 활동이지만, 소프트웨어적으로나 혹은 프로세스적으로

유익하지 않은 상황이므로 되도록이면 회피해야만 합니다.

 

데드락을 설명하기 전에 블러킹(Blocking)과 라이브락(Livelock)에 대해서 먼저

설명하기로 하죠. 혹자들은 블러킹이나 라이브락을 데드락과 혼동하는 경우가 있는데

이 기회에 보다 잘 이해하기 바랍니다.

 

우선 트랜잭션 1과 2가 동일한 자원을 놓고서 이에 접근하는 과정을 살펴보기로 합시다.

트랜잭션 1과 트랜잭션 2는 동일 자원("Resource")에 대해서 동시에 접근하고 있습니다.

이 경우 트랜잭션 1이 해당 자원에 락을 걸고 그 자원을 이용하게 됩니다.

뭐. 데이터 수정이나 추가와 같은 작업들을 수행할 것입니다.

이 경우 트랜잭션 2는 트랜잭션 1이 잡고 있는 락을 해제할 때까지 기다려야만 하죠.

이상 없이 트랜잭션 1이 락을 풀게 되면 트랜잭션 2는 해당 자원을 자유로이 이용할

수 있을 것입니다. 물론 트랜잭션 2도 해당 자원에 잠금을 설정하여 이용할 것입니다.

 

이 경우 한 트랜잭션은 락 상태에 있고 또 다른 트랜잭션인 트랜잭션 2는 대기 상태에

빠져 있게 됩니다. 이렇게 한 트랜잭션이 락을 걸고 있어서 다른 트랜잭션이 대기

상태에 빠지는 상황을 라이브락(Livelock)이라고 하고 이러한 행위를

블러킹(Blocking)이라고 합니다. 이러한 블러킹은 꼭 라이브락에만 국한되는 것은

아니고 락을 사용하는 모든 상황에서 발생하는 것이므로 보다 폭 넓게 이해하기

바랍니다. 어쨌든 라이브 락 또한 정상적인 상황이죠. 하지만 그래도 이러한 락이

오랜 기간 지속된다면 다른 트랜잭션들이 대기상태에서 기다려야 하므로

애플리케이션에 좋지 않은 영향을 주게 되므로 되도록이면 트랜잭션이 잠금을

유지하는 기간을 짧게 가지도록 해야만 합니다.

 

<그림 4> 라이브락과 블러킹

 

이제 라이브락과 블러킹에 대해서 이해하셨을 것입니다.

블러킹은 잠금을 사용할 때의 일반적인 동작이고 라이브락 또한 정상적인 잠금 상황입니다.

 

그렇다면 데드락은 무엇이죠? 이런 상황을 생각해봅시다. 두 명의 바보가 있는데

각각 갑돌이와 차돌이라고 하고 두명 모두 오른손에는 사과를 들고 있고 왼손에는

배를 들고 있다고 가정합니다. 갑돌이는 자기 오른손에 있는 사과가 맛있어보이지만

왼손의 배는 차돌이께 더 맛있어 보입니다. 그래서 차돌이의 배를 뺏으려고 하고

있습니다. 차돌이는 반대로 갑돌이의 사과를 뺏으려고 하고 있습니다.

이런 경우 두 바보들은 자기가 좋아하는 과일들을 안 뺏기려고 안간힘을 쓰고

상대편의 과일은 뺏으려고 하게 되죠. 두 바보가 동일하게 힘이 세다면

그리고 시간이 무한히 길다면 두 바보들은 영원히 자신의 과일도 상대편의 과일도

먹을 수 없는 상황이 되고 맙니다.

 

이러한 상황이 데이터베이스에도 일어나게 됩니다. 각 트랜잭션들을 갑돌이와

차돌이같은 바보들이고 자원 1과 자원2는 사과와 배 같은 과일들입니다.

트랜잭션 1이 자원 1에 대해서 락을 걸고 트랜잭션 2는 블러킹당해서 라이브락 상태에

있게 됩니다. 정상적인 경우 트랜잭션 1이 락을 해제하면 트랜잭션 2는 자원 1을

사용할 수 있을 것입니다. 하지만, 라이브 락이 하나 더 걸려있는 것을 주의하세요.

트랜잭션 2가 자원 2에 잠금을 걸고 있는데 트랜잭션 1도 이 자원 2를 사용하려고

들어갔다가 블러킹 당해서 라이브락 상태에 빠져 있습니다.

 

<그림 5> 데드락

 

두 바보의 힘들이 같다면 이는 영원히 지속되는 무한루프와 같은 상태를 발생하게 됩니다.

하나의 상황을 가정해 보죠. 트랜잭션 1이 자원 1의 락을 해제하여 트랜잭션 2가

자원 1을 사용할 수 있을까요? 정답은 그럴 수가 없다 입니다. 락의 해제는 언제

이루어지는지 기억하십니까? 바로 트랜잭션이 커밋 되거나 롤백 되어질 때입니다.

따라서 자원 1에 대한 락도 트랜잭션 1이 완료되는 순간까지라고 할 수 있지만,

트랜잭션 1은 결코 완료되지는 않습니다. 왜냐면 트랜잭션 2가 자원 2에 대한 락을

풀어줘야만 자원 2를 사용하고 트랜잭션을 완료해 자원 1에 대한 잠금도 해제할 수

있지만 트랜잭션 2또한 트랜잭션 1이 자원 1에 대한 락을 해제하기 전까지는

결코 자원 2에 대한 락을 해제하지 않을 것입니다.

 

이 두 고집 쎈 트랜잭션들은 주위의 간섭이 없다면 이러한 상황을 계속 진행해

나갈 것입니다. 데드락은 바로 이러한 상태를 예로 든 것입니다. 이는 반드시 두개의

트랜잭션에서만 일어나는 상황이 아니라 여러 개의 트랜잭션들이 연속적으로

이러한 교착 상태에 빠져버릴 수 있습니다. 이러한 데드락 또한 데이터베이스에서

정상적인 상황이고, 이제까지 출시된 어떠한 데이터베이스들도 이러한 데드락

현상을 완전히 해결한 제품을 출시한 적이 없습니다. 물론 이에 대한 몇 가지의

해결책들을 제공하고 있으므로 너무 걱정하지는 마시기 바랍니다.

Posted by gala
l