은행시스템 교착상태 데드락(deadlock) 해결 방법

데이터베이스의 기술적인 관점에서 은행원 알고리즘 등을 설명하면서 교착상태인 deadlock의 해결 방법에 대해서 논하곤 한다.

 

은행과 실제 금융관과 관련한 실무에서는 과연 deadlock의 문제를 해결하기 위해서 어떠한 노력들을 기울이고 있을까?

 

교착상태(deadlock)는 상호간의 트랜잭션 또는 작업이 상호간의 자원의 점유를 하기위해 각자가 현재 점유하고 있는 자원을 놓지않고 붙잡고 있음으로써 발생한다.

 

교착상태 이미지

 

우선 데드락이 발생하는 조건에 대해서 알아보자.

 

   <교착상태(deadlock) 발생조건>

• 상호배제(Mutual Exclusion) - 한번에 오직 한개의 작업만 자원에 접근할 수 있다.
• 잠금과 대기(Hold, Wait) - 자원을 갖고있는 작업이 다른 프로세스의 자원을 대기하는 것
• 선점불가 (No Preemption) - 하나의 작업이 다른 작업으로 부터 자원을 빼앗지 못하는 것
• 순환대기(Circular Wait) - 연쇄적으로 작업이 자원을 대기하는 상태

위와 같은 조건에 의해 데드락이 발생한다.

 

이론적으로는 설명한 바와 같으나 실제적으로 해결을 하기 위해선 어떻게 해야할까?

이론적인 부분 부터 살펴보자.

---

우선 교과서적으로 <교착상태 예방> 과 <교착상태 회피>를 이야기 하곤 한다.

이는 교착상태를 예방하거나 또는 회피하는 프로토콜을 이용하는 방법이다.

또한 교착상태가 되도록 허용한 이후에 이를 회복하는 방법도 사용된다.

위와 같은 방법이 아니고 아예 교착상태 자체를 무시하기도 한다

 

 

<교착상태 예방 : Prevention> 부터 살펴보자.

 

이는 교착 상태가 발생하는 조건 중 하나를 애초에 제거함으로써 해결하는 방법이다.

그 상황자체의 발생가능성을 제한함으로써 자원의 낭비가 심하다는 단점이 있다.

 

• 상호배제 부정 - 여러 작업이 공유자원을 사용할 수 있도록 허용
• 점유대기 부정 - 작업이 실행되기전 모든 자원 할당
• 비선점 부정 - 자원 점유 작업이 다른 자원을 요구하는 경우 자원을 반납하고 대기
• 순환대기 부정 - 자원에 고유한 번호를 할당하여 순서대로 자원 요구

<교착상태 회피 : Avoidance> 는 다음과 같다.

 

이는 교착상태가 발생하면 아예 피해가자는 방식이다.

 

은행원 알고리즘(Banker's Algorithm)이 있다.

 

E,J,Dijkstra가 제안한 방법으로써 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데 유래한 기법이다.

작업이 작원을 요구하는 경우에 시스템은 자원을 할당한 이후 안정상태로 있는지 사전에 검사하여 교착을 회피한다.

안정적인 상태에 있는 경우 자원을 할당하고 그렇지 않은 경우 다른 작업이 자원을 해지할때 까지 대기한다.

---

다음은 조금 더 실무적인 관점에서 교착상태(Deadlock)를 바라보자.

 

 

우선 실무적인 경우에는 데이터베이스 관리자인 DBA와 실제 프로그램 개발자의 관계를 이해해야 한다.

 

사용자가 업무적으로 필요한 어떠한 요구사항에 의해 프로그램 개발자가 프로그램을 개발하게 된다.

그에 따라 필요한 SQL을 작성하게 되며 이에 따라 다양한 트랜잭션에 의해 다양한 요구사항들이 수행되게 되면

그 과정중에 데이터베이스는 필수불가결하게 교착상태에 빠지곤 한다.

 

---

 

이는 위에서 이론적으로 설명한 것처럼 실무적으로는 애초에 교착상태 발생 조건을 완벽하게 제거하거나 회피할 수 없다.

왜냐하면 그 업무적인 요구는 수시로 발생하며 그 교착상태 조건을 동시에 제거하거나 회피할 수 없는 경우가 대부분이기 때문이다.

 

하지만 데이터베이스 관점에서 DBA는 주로 어떠한 업무에서 어떠한 서비스 시간대에 주로 교착상태가 발생하는지에 대한 정보를 제공해준다. 또한 계속 교착상태에 빠져있는 것을 바라만 보고 모니터링 하거나 안내만 할 수 없기에 데이터베이스 시스템적으로 특정 시간이 지나면 교착상태를 제거해주기 위해 상대적으로 덜 중요한 트랜잭션이나 작업을 kill 하는 victim을 선정하기도 한다.

 

 

실제 업무적으로는 kill을 하고 victim을 선정하는 것은 크리티컬하다고 생각할 수 있으나 데이터베이스의 자원을 두 트랜잭션이 점유하여 다른 많은 작업들이 계속 수행되지 않는 것보다 훨씬 낫다고 판단하는 것이다. 그래서 교착상태라고 하는 것을 주기적으로 모니터링 하고 시스템적으로 해결할 수 있는 방안과 개발자가 SQL을 튜닝하거나 또는 프로그램 로직을 새롭게 하여 구현하여 이 문제를 해결하기도 한다.