현금영수증 배치처리 하면서 도비랑 논쟁했던 사항이다.
AWS Lambda에 비즈니스 로직을 넣는 것이 어떤가에 대한 이야기 일 수 있다.
내가 로직을 넣었던 이유는 작업을 끊어서 처리를 했으면 좋겠는 것에 이유가 있었다.
가령 큰 용량의 파일을 이동을 하는 작업을 한다고 한다.
총 4개의 디렉토리를 물리적으로 분리된 곳에 이동을 시키려고 한다. (각 디렉토리에는 다수의 서브디렉토리가 있고 데이터들이 있다.)
이동은 복사 + 삭제의 트랜잭션 작업이라고 할 수 있다.
만약 작업을 각 디렉토리별로 트랜잭션을 묶어 이동을 시키는 것과, 전체 4개를 한꺼번에 하나의 트랜잭션으로 묶는 것은 어떤 차이를 가져올까?
후자의 경우로 하면 아래와 같은 그림을 그릴 수 있다.
위가 이동할 대상이고, 아래가 옮겨질 대상이다.
총 4개의 디렉토리 즉, Audio, Photo, PhotoAR, Video 가 옮길 대상이고, 그중 Audio 디렉토리는 이동이 완료되었다.
하지만 아직 트랜잭션은 진행중이므로 모든 데이터가 복사되기 전까지는 원본 데이터가 지워지면 안된다.
왜 이런 공간을 많이 잡아먹는 전략을 사용하는지는 정확히 알 수는 없지만 작업이 언제라도 취소 될 수 있기 때문이다.
만약 사용자가 X 버튼을 누르면 옮겨질 곳에 복사한 것만 지우면 된다.
만약 옮겨진 디렉토리를 원본에서 지우는 작업을 미리했다면 다시 원본 경로로 roll-back을 위해서 재복사를 해서 돌려놔야 할 것이므로 작업이 더 복잡해진다.
따라서 만약에 각 4개의 복사를 나눠서 작업을 진행하면, 하나의 작업이 끝나면 원본이 있는 곳은 그 공간을 사용할 수 있게 된다.
물론 오래 걸리는 작업이라면 한 번 작업을 시켜놓고 다른 일을 할 수도 있을 것이다. (fire-and-forget)
하지만 나눠서 하는 작업도 스크립트나 배치적인 처리를 해놓으면 일일이 모니터링 및 작업지시를 할 필요도 없을 것이다.
(내가 Finder를 통해서 이동/복사 하는 이유에는 파일 시간 동기화가 되기 때문이 가장 크다)
다음날 아침
작업이 끝나고 나서 용량 확보가 되었는지 확인을 해보았다.
'algorithm' 카테고리의 다른 글
작심삼주 오블완 챌린지 - 햄버거 당첨 (0) | 2024.12.09 |
---|---|
[현실] piggyback을 할지 말지? (0) | 2020.11.24 |
[취약성] ReDoS (정규식을 이용한 서비스 거부) (2) | 2019.07.17 |
분할 정복(D&C; divide and conquer) (0) | 2018.12.26 |