본문 바로가기

algorithm

[think] 오래걸리는 작업을 나눠서 하는게 좋을까?

현금영수증 배치처리 하면서 도비랑 논쟁했던 사항이다.

AWS Lambda에 비즈니스 로직을 넣는 것이 어떤가에 대한 이야기 일 수 있다.

 

내가 로직을 넣었던 이유는 작업을 끊어서 처리를 했으면 좋겠는 것에 이유가 있었다.

 

가령 큰 용량의 파일을 이동을 하는 작업을 한다고 한다.

총 4개의 디렉토리를 물리적으로 분리된 곳에 이동을 시키려고 한다. (각 디렉토리에는 다수의 서브디렉토리가 있고 데이터들이 있다.)

이동은 복사 + 삭제의 트랜잭션 작업이라고 할 수 있다.

 

만약 작업을 각 디렉토리별로 트랜잭션을 묶어 이동을 시키는 것과, 전체 4개를 한꺼번에 하나의 트랜잭션으로 묶는 것은 어떤 차이를 가져올까?

 

후자의 경우로 하면 아래와 같은 그림을 그릴 수 있다.

2.4TB 복사에 약 4시간 걸리는 것으로 예상이 되고 있다.

위가 이동할 대상이고, 아래가 옮겨질 대상이다.

총 4개의 디렉토리 즉, Audio, Photo, PhotoAR, Video 가 옮길 대상이고, 그중 Audio 디렉토리는 이동이 완료되었다.

 

하지만 아직 트랜잭션은 진행중이므로 모든 데이터가 복사되기 전까지는 원본 데이터가 지워지면 안된다.

실제 데이터가 이동되었지만 아직 기록이 안된 것으로 나온다.
아직 원본이 있는 디스크는 공간이 늘어나지 않았다.

왜 이런 공간을 많이 잡아먹는 전략을 사용하는지는 정확히 알 수는 없지만 작업이 언제라도 취소 될 수 있기 때문이다.

만약 사용자가 X 버튼을 누르면 옮겨질 곳에 복사한 것만 지우면 된다.

만약 옮겨진 디렉토리를 원본에서 지우는 작업을 미리했다면 다시 원본 경로로 roll-back을 위해서 재복사를 해서 돌려놔야 할 것이므로 작업이 더 복잡해진다.

 

따라서 만약에 각 4개의 복사를 나눠서 작업을 진행하면, 하나의 작업이 끝나면 원본이 있는 곳은 그 공간을 사용할 수 있게 된다.

물론 오래 걸리는 작업이라면 한 번 작업을 시켜놓고 다른 일을 할 수도 있을 것이다. (fire-and-forget)

하지만 나눠서 하는 작업도 스크립트나 배치적인 처리를 해놓으면 일일이 모니터링 및 작업지시를 할 필요도 없을 것이다.

(내가 Finder를 통해서 이동/복사 하는 이유에는 파일 시간 동기화가 되기 때문이 가장 크다)

다음날 아침

작업이 끝나고 나서 용량 확보가 되었는지 확인을 해보았다.

크기가 0이 아닌 이제 206.62GB 이다.
사용 가능 용량이 190.7 MB에서 2.41TB 로 늘어났다.
Destination