대용량 배치에 commit이 필요한 이유 = 게임 세이브 포인트가 있는 이유

스스로의 정체성을 어떤 개발자라고 아직도 정의하기 어렵지만,

현재 배치 프로그램 개발이 많은 팀 소속이다.

(온라인 솔루션 개발을 간혹 하고는 있지만 고기만두 업무에서는 비중이 현재 높지 않은 편이다)그 중에서도 테이블 U/I/D보다, SELECT 후 자료를 가공 및 추출하는 형식의 개발이 많고,

그렇게 나온 데이터 파일로 업무를 하는 경우가 많은 편이라 잊고 있던 부분에 대한 글을 하나 써보려고 한다.

 

---

내 일이 아니라서 말을 얹기 조심스럽지만

간략하게 두줄요약으로 설명하자면.

(원래 더 빨리 쓰고 싶었지만 대외비라 즉시적으로 글을 쓸 수 없었고, 사실 아직도 해결 관련해서는 진행중.)

대용량, 실시간성 테이블을 건드리는 배치인데, 어떤 원인으로 오류가 발생

-> 사태가 겉잡을 수 없이 커짐, 긴 장애 발생

 

으로 이어지는 끔찍한 일이 발생했었다. 정도.

728x90

 

 

그래서 배치에 대한 전수조사를 해보니 생각보다 중간 commit이 없이 얼레벌레 돌아가는 배치가 많음이 확인되었다.

 

중간 commit이 왜 필요한가?

문제가 생기면, commit한 부분까지 살리고 롤백 처리를 하여 장애가 발생할 경우 영향도를 최소화할 수 있다.

그나마 있는 부분에 대한 데이터는 건질 수 있다는 뜻이다.

그리고 그 중간점에 대한 기준은 처리 용량에 따라 1000건 ~ 10만건 등으로 매우 다양하다.

 

수천만건을 한 큐에 원커밋을 친다거나,

아예 그런 절차가 없이 돌아가는 경우 문제가 발생했을 때 대처가 힘들어진다.

돌아가던 작업을 kill처리하여 중단할 경우에도, 이 부분으로 인한 문제가 발생한다.

몇 시간 동안 수천만건 u/i/d되고있던 배치가 수행 중지되어야 할 때,

롤백을 해야 하는데 그 중간 세이브 포인트가 없어지면

그 롤백조차도 트랜잭션 맨 처음까지로 돌아가야 하는 문제가 발생하고,

롤백이 완전히 종료되는데에도 또 수 시간이 걸린다.

그런 경우 더 큰 장애가 발생할 수 있다.

 

두 상황에 대하여 그림으로 비교해보면 이와 같다.

 

편의상 세이브포인트를 1개만 그려보았는데, 확 느낌이 온다.

---

반응형

출처 - 젤다

콘솔 게임 실행에 있어서, 중간 저장점으로 돌아가서 플레이를 하는 경우가 있다.

보스전에서 능력부족 아이템부족 등의 이슈로 죽어버려서 재도전을 해야 한다든가 하는 상황을 생각해볼 수 있겠다.

그런 게 아니더라도 세이브포인트를 일부러 여러 개 만들 수 있도록 만들어준 게임들이 있다.

세이브포인트로 돌아가서 다른 실행을 할 때 엔딩의 방향이 달라지기도 한다.

 

우리가 그래도 개발자로 일을 하고 있는 이상,

프로그램의 엔딩은 조금이라도 좋은 쪽으로 바꿀 수 있지 않을까?

늘 안정적인 상황만 있으면 좋겠지만,

외부적 이슈로 인해서든 뭘로 인해서든 문제는 항상 생길 수 있다는 점,

그리고 가장 최악의 경우를 상상하더라도 최대한 괜찮을 수 있어야 함을 내가 하는 일을 통해 많이 느끼고 있다.