임시 파일 작업 공간 (Working storage)에 대한 노트

임시 파일 작업 공간

비동기 처리나 분산환경에서 추가적으로 필요한 컴포넌트 중의 하나는 임시 파일 작업 공간을 들 수 있다. 임시 파일 작업 공간은 직접 애플리케이션 서버에 네트워크 파일 시스템 (NFS)등으로 마운트 될 수 있는 파일 시스템인데, 작업을 위해서 임시적으로 파일을 저장하는 공간이다.

 아래 그림을 보자, 아래 그림은 업로드된 동영상에서 썸네일을 추출하고 변환을 통해서 아카이빙 스토리지에 저장하는 구조인데, 앞단의 업로드 서버에서 파일이 업로드 되면, 파일은 임시 파일 작업 공간에 저장되었다가, 파일 업로드가 완료되면 메시지 큐에 변환 요청이 들어가게 되고, 뒷단의 변환(Transform)서버에서는 순차적으로 메시지를 받아서, 변환에 필요한 업로드된 파일을 읽어다가 변환한 후 아카이빙 스토리지에 저장하는 방식이다. 아카이빙 스토리지는 저가의 파일 저장소로 아마존 클라우드 S3, 애저 클라우드의 Blob Storage 등으로 가격이 저렴하며 REST API 나 HTTP 프로토콜로 접근이 가능하지만 파일 시스템에 직접 마운트 하는 것은 불가능하다.

만약에 이러한 아카이빙 스토리지만을 사용한다면, 업로드 컴포넌트는 로컬 디스크에 파일을 업로드한 후, 업로드가 끝나면 이 파일을 아카이빙 스토리지에 저장해야 하고, 변환 컴포넌트는 변변환 할 때, 이 아카이빙 스토리지에서 파일을 로컬 스토리지에 복사해놓고 작업을 시작해야 한다.

만약 이러한 비동기 절차가 길면 길 수 록 많은 파일 복사가 발생하게 된다. (로컬과 아카이빙 스토리지간). 아직까지 대부분의 SDK나 API들이 보통 로컬 파일 시스템을 기준으로 개발이 되어 있기 때문에, 직접 아카이빙 스토리지에서 파일을 읽어가면서 작업하는 것이 어렵기 때문에. 로컬 스토리지로의 파일 복사는 일반적인 절차가 되는데, 이러한 작업을 막으려면 중간에 임시 파일 작업 공간을 넣는 것이 방안이 된다. 네트워크 파일 시스템 (NFS)와 같은 파일 시스템을 둬서, 각 서버에 마운트 한후에, 직업 이 NFS로 파일을 업로드 하고, 파일 변환 작업등도 이 NFS에서 모두 끝낸 후에, 작업이 끝난 최종 파일만을 아카이빙 스토리지로 올리는 방법이 있다.

일반적인 NFS를 사용할 수 도 있지만, 대규모 분산환경에서는 이 NFS를 이용한 임시 파일 작업 공간 자체의 IO가 많이 발생할 수 있기 때문에 분산해서 처리할 필요가 있는데,이런 경우 분산 파일 스토리지를 사용하는 방법이 있다. GlusterFS의 경우는 클러스터링 기능을 통하여 분산 기능을 제공하여 IO 성능을 높일 뿐만 아니라 특정 노드가 장애가 났을 때도 파일 복제를 통한 장애 대응이(Fail Over)를 가능하게 한다.

다른 시나리오로는 분산 환경에서의 공유 파일 시스템으로 사용이 가능한데, 아래의 시나리오를 보자, 아래의 시나리오는 많은 로그를 수집하기 위한 로그 수집 시스템으로 앞단의 API 서버 (Log Server)들이 로그 업로드 호출을 처리하고, 그 로그들을 공유 파일 시스템에 쓰는 시나리오이다. 여기서의 제약 사항은 부하량에 따라서 Log Server 수 가 늘어나고 줄어드는 Auto Scale out기능을 사용한다는 것이다.

물론 아래와 같은 구조를 사용하지 않고, 뒷단에 바로 RDBMS나 NoSQL등을 써서 바로 Write 하는 방법도 있고, Flume과 같은 분산 로그 시스템을 쓸 수 도 있지만, 기존의 인프라나 구성을 바꾸지 않고 가장 쉽게 할 수 있는 방식은 API 서버가 로그를 파일에 쓰는 구조이다.

아래 그림과 같이 공유 파일 시스템을 쓰면 장점이, Log Server가 줄거나 늘어남에 상관 없이 로그 파일이 공통된 파일 시스템에 모인다는 장점이다.

각 Log Server에 로그 파일을 써서 주기적으로 중앙 로그 저장소로 긁어갈 수 도 있겠지만, 로그를 긁어가는 수집 시스템에서 현재 기동하고 있는 Log Server들의 목록들을 알아야 한다. Log Server는 Auto Scale out에 의해서 늘어나거나 줄어들 수 있고, 보통 클라우드에서 이러한 Auto Scaling된 인스턴스는 IP주소가 변경되는 경우가 많기 때문에, 중앙 로그 수집 시스템이 그 주소를 알기가 어렵다.

반대로 Log Server가 파일을 중앙 저장소로 주기적으로 밀어주는 방법도 있겠지만, 이 경우 전체 시스템 부하가 줄어들었을 때,서버의 수를 줄이는 Auto Scale In이 발생하였을 때, Log Server의 인스턴스가 로그를 중앙 저장소에 복사하기 전에 내려가 버린다면 로그파일 유실이 발생할 수 있다.

그래서 바로 임시 파일 작업 공간을 만들어서 직접 마운트해서 사용하게 되면, Log Server의 코드 역시 간단하게 일반 로컬 파일 시스템을 접근하는 듯한 구조를 사용하면 되기 때문에 구현이 매우 단순해 진다.

이러한 임시 파일 작업 공간은 성능이나 신뢰성에 따라서 그에 맞는 파일 시스템 구성과 애플리케이션 설계를 해야 한다.

예를 들어 GlusterFS의 경우 하나의 파일에 append하는 데는 성능이 좋은 편이지만 작은 파일을 여러 개 쓰는 데는 성능이 좋지 않기 때문에 위와 같은 로그 시나리오라면 로그를 하나의 파일에 계속 append 해서 쓰는 구조가 좋다. 또한 고 성능이 요구 될 때는 당연히 SSD를 고려하고 RAID 디스크 구성에 있어서도 Striping 구성등을 고려 해야 한다