ACM Symposium on Operating Systems Principles (SOSP) 는 세계 유수의 학교와 기업에서 참여하여 시스템, 네트워크 컴퓨팅, Scalability, 커널 보안 등, 운영체제와 관련된 광범위한 주제에 대한 최신 연구 내용을 발표하며, 이에 대해 토론하고 공유하는 대규모의 학술 대회이다. 이번 SOSP 2017은 10월 28일부터 31일까지 4일간 Shanghai Pudong Shangri-La Hotel에서 진행되었으며, 39편의 논문이 발표되었다. 우리는 스토리지 시스템, 파일 시스템을 포함한 최신 연구 동향을 살펴보고자 SOSP 2017학회에 참석하였다.

IMG_1604

IMG_1607

NVMe interface 기반 스토리지의 등장은 매니코어 시스템이 다중 submission queue를 활용하여 입출력 요청을 병렬적으로 처리할 수 있는 환경을 제공하였으나, 파일시스템을 포함한 입출력 스택의 병목은 이러한 최신의 스토리지 기술들이 제공하는 성능을 충분히 활용하지 못하도록 한다 [4]. 이러한 문제를 해결하기 위한 노력은 SOSP 2017에서 발표된 연구들 [2, 3, 5]에서도 확인할 수 있었으며, 이들은 입출력 스택의 확장성을 개선하고 빠른 스토리지의 성능을 활용하기 위한 기법들을 제안하였다. 우리는 이러한 연구 내용들을 확인하고, 그 외 분야의 최신 연구 동향을 확인하기 위해 Shanghai, China에서 개최된 SOSP 2017 학회에 28일부터 31일까지 4일간 참석하였다.
IMG_1609

SOSP 2017은 10월 28일부터 31일까지 Pudong Shangri-La Hotel에서 진행되었으며, 총 13개의 Technical Session에서 논문 39건이 발표되었다. Regular paper를 발표하는 Technical Session 외에도 Poster Session, Birds of feather session, Student Research Competition presentations등이 함께 진행되었다. 학회 첫째 날에 진행된 Resource management Session에서는 Microsoft의 클라우드 컴퓨팅 플랫폼인Azure의 워크로드를 분석한 논문인 “Resource Central: Understanding and Predicting Workloads for Improved Resource Management in Large Cloud Platforms”, Eli Cortez (Microsoft) et al. [1]과, 입출력 명령의 지연시간 예측을 통해 client 요청의 accept/reject 결정 방식을 제안하는 “MittOS: Supporting Millisecond Tail Tolerance with Fast Rejecting SLO-Aware OS Interface”, Mingzhe Hao (University of Chicago) et al. [2]이 발표되었다. Resource Central 논문은 Cloud 시스템의 워크로드 분석 연구의 부족을 지적하며, Microsoft의 클라우드 서비스인 Microsoft Azure’s VM의 워크로드를 3개월간 수집, 분석한 내용을 발표하였다. 분석 결과를 요약하자면, i) VM CPU Utilization은 평균 30%로, 낮은 사용율을 보인다. ii) VM의 Life time (VM start to completion)은 long tail로, 90%의 VM은 하루 미만의 Lift time을 보였다. iii) 약 60%의VM이 Single Core로 동작하였으며, 80%의 VM이 1-2 개의 core를 사용하였다. 또한 70%의 VM이 4GB 미만의 메모리를 사용하였으며, 이러한 small VM들을 하나의 cluster에 할당하는 것이 가능할 것으로 예상하였다. 이들을 하나의 cluster로 묶음으로써 얻을 수 있는 이익에 대해서 저자에게 질문하였으며, 각 VM에게 할당하는 Computing 자원의 fragmentation을 완화할 수 있다는 답변을 받았다. 마지막으로 iv) VM이 사용하는 워크로드로는 interactive 워크로드 (약 30%)보다 Delay-intensive 워크로드 (약 65%)가 많다.

MittOS [2]는 SLO-aware interface를 제공하는 운영체제로, 해당 인터페이스를 사용하여 client는 입출력 요청의 latency deadline을 서버에 전달할 수 있다. 기존의 tail-tolerant 기법들은 microsecond 단위의 tail-tolerant를 지원하지 못하거나, cloning 방식의 사용으로 입출력 가중화 등의 문제를 가지고 있으며, MittOS는 이러한 문제를 개선하는 기법을 제안하였다. MittOS는 입출력 요청이 전달되었을 때, 해당 입출력보다 먼저 도착한 입출력의 개수, OS Queue의 정책 (FIFO, Elevator, Elevator + CFO), 그리고 사용하고 있는 스토리지의 종류를 고려하여, 현재 전달된 입출력 요청의 처리 예상시간을 예측한다. 만일 예측된 처리시간이 Client가 전달한 deadline을 넘어선다면 입출력 요청을 처리하지 않고, client에 reject를 전달한다. Reject를 전달받은 client는 다른 서버 노드에게 요청을 redirection할 수 있으므로, 불필요한 대기 지연을 제거할 수 있다. 스토리지의 성능을 입출력 처리 지연 예측에 고려해야 하며, 이를 위해 MittOS는 스토리지로 HDD를 사용할 경우를 위한 MittCFQ와 SSD를 사용할 경우를 위한 MittSSD로 구성된다. MittCFQ의 경우 HDD의 성능을 profiling 하여 수집된 입출력 성능 값을 사용한다. 이 때, 입출력 성능은 IO Size, Latency, Seek Distance에 따른 함수로 결정된다. MittSSD의 경우 HDD보다 구조가 복잡하며, 입출력 요청의 처리 시간을 예측하기 위해서는 SSD 내부의 병렬화 구조, 가비지 컬렉션 동작 등을 호스트에서 확인 가능해야 한다. 따라서 본 논문에서는 SSD 내부의 동작을 호스트에서 추적할 수 있는 OpenChannel SSD를 사용하였다. MittSSD가 SSD 내부에서 동작하는 Background Task들 (Background Garbage Collection, Wear-leveling, Block scrubbing 등)도 고려하는지 문의를 하였고, 해당 연산들을 포함해서 SSD에서 처리되는 모든 입출력 요청을 추적한다는 답변을 받았다. 또한 NVMe 스토리지의 경우 호스트 계층에 입출력 큐 (Submission Queue, Completion Queue)를 관리하므로, 이를 통해 입출력 처리 지연을 예측할 수 있지 않느냐는 질문에는, NVMe 스토리지 내부 구조가 여전히 Blackbox 이므로, MittSSD를 적용할 수 없다는 답변을 받았다. MittOS는 기존 tail-tolerant 기법 (Hedge [7])와 비교하여 IO completion time을 35% 감소시키었으며, 입출력 요청의 처리 예측 오류율은 1% 미만이다.

IMG_1615

ScaleFS [3] 는 매니코어 환경에서 파일시스템 성능의 Scalability를 보장하기 위해, cache-line conflict를 제거한 파일시스템이다. Min et al [4]이 ATC 2016에서 발표한 연구에서 언급하고 있듯이, 기존 파일시스템들은 page cache의 global lock, directory entry lock 등으로 인해 매니코어 scalability를 제공하지 못한다. 예를 들어, 하나의 디렉토리에 두개의 core가 서로 다른 파일을 생성하고자 하는 경우, directory inode에 대한 lock으로 인해 병렬 처리가 불가능하다. ScaleFS의 경우 파일시스템을 MemFS (in-memory filesystem)와 DiskFS (on-disk filesystem)으로 분리한다. MemFS는 각 파일에 대해 mnode (DiskFS의 inode에 해당)를 관리하며, 각 mnode에 발생한 업데이트를 Per-core operation log에 삽입한다. Log에 삽입된 operation 들은 fsync와 같은 flush command 호출 시 DiskFS에 반영된다. Per-core operation log 에 삽입된 연산 간의 처리 순서를 결정하기 위해 각 연산마다 timestamp를 함께 기록하며, 해당 순으로 DiskFS에 반영한다. Core의 연산을 로깅하는 MemFS와 연산을 영속화하는 DiskFS간의 분리를 통해 매니코어 환경에서의 파일시스템 Scalability를 증가시키었다. Commutative operation [6] (conflict가 발생하지 않는 연산 간의 쌍)의 비율은 EXT4가 65%인 반면 ScaleFS는 99.2%까지 증가시키었다. 동일한directory에 서로 다른 core가 별개의 파일을 생성하는 워크로드에서, 하나의 Core가 MemFS directory mnode의 lock을 잡을 경우, 다른 core가 block되지 않느냐는 질문에, MemFS directory의 각 entry는 hashtable로 관리되며, hash entry마다 lock을 사용하므로 (즉, directory 별로 lock을 사용하지 않으므로) lock contention이 발생하지 않는다는 답변을 받았다.

학회 마지막 날의 오전 session에서 발표된 strata [5]는 작은 크기의 업데이트를 효율적으로 처리하는 대용량의 시스템을 구축하기 위해 다수의 디바이스 타입 (NVM, SSD, HDD)을 사용하는 시스템을 제안한다. strata는 NVM에 operation log를 기록하는 LibFS와, log를 Secondary storage (SSD & HDD)에 반영하는 kernelFS로 구성된다.  각 Application은 NVM의 private 영역에 operation log를 기록하며, 이는synchronous IO로 처리된다. KernelFS는 이를 NVM의 shared 영역으로 digest 하는데, 이 때 불필요한 쓰기 (Ex. 저널 관련 쓰기)는 제거되며 이를 통해 쓰기 증폭이 감소한다. kernelFS는 shared 영역의 log를1GB 단위로 SSD에 asynchronous migration하며, crash 발생 시 operation log를 replay함으로써 복구한다. Operation Log를 사용하면 read 성능이 감소하지 않느냐는 질문에, NVM를 hash로 관리함으로써 읽기 성능을 보완하였다고 답변 받았으며, NVM를 4KByte 단위 블록 hash로 관리하나 쓰기 단위는 블록이 아닌 byte 단위로 수행한다고 답변 받았다. DRAM을 사용할 경우 Crash Consistency를 보장할 수 없는 단점을 가지나, NVM을 사용하는 시스템을 가정할 경우, digest 동작으로 인한 쓰기 증폭 감소 및 small write 성능 증가, crash consistency 보장 등 NVM의 특성을 충분히 활용한 hybrid 기반 파일시스템 연구라 생각한다.

이번 SOSP 2017 학회 출장에서는11개의 Technical Session에 참석하고, 포스터 Session에서 다양한 저자들과 만나 교류함으로써 세계 유수의 연구 기관들의 최신 연구 이슈에 대해서 확인하였다. SSD 와 관련된 소프트웨어, 매핑 알고리즘, 가비지 컬렉션 등 스토리지에 관련된 논문의 수는 적었으나, Strata [5], ScaleFS[3]를 포함하여 여전히 입출력 스택의 병목을 개선하고 빠른 스토리지의 raw bandwidth를 충분히 활용하기 위한 연구들이 계속되고 있음을 확인하였다. 현재 진행중인 VSSIM with NVMe storage 개발을 조속히 진행하여, 추후 이러한 연구들을 지원하기 위한 시뮬레이션 환경을 제공하도록 해야겠다. 본 학회 출장을 지원해준 2017 기초연구실사업 (BRL), 한국연구재단에 감사의 말씀을 드린다.

 

참고문헌

[1] Eli Cortez (Microsoft), Anand Bonde (Microsoft Research), Alexandre Muzio (ITA, Brazil), Mark Russinovich, Marcus Fontoura (Microsoft), and Ricardo Bianchini (Microsoft Research), “Resource Central: Understanding and Predicting Workloads for Improved Resource Management in Large Cloud Platforms”, in Proc. of ACM SOSP 2017

[2] Mingzhe Hao, Huaicheng Li, Michael Hao Tong, Chrisma Pakha, Riza O. Suminto, Cesar A. Stuardo, Andrew A. Chien, and Haryadi S. Gunawi (University of Chicago), “MittOS: Supporting Millisecond Tail Tolerance with Fast Rejecting SLO-Aware OS Interface”, in Proc. of ACM SOSP 2017

[3] Srivatsa S. Bhat (MIT CSAIL and VMware), Rasha Eqbal (MIT CSAIL and Apple), Austin T. Clements (MIT CSAIL and Google), and M. Frans Kaashoek, Nickolai Zeldovich (MIT CSAIL), “Scaling a file system to many cores using an operation log”, in Proc of ACM SOSP 2017

[4] Changwoo Min, Sanidhya Kashyaz, Steffen Maass, Woonhak Kang, and Taesoo Kim (Georgia Institute of Technology), “Understanding Manycore Scalability of File Systems”, in Proc. of USENIX ATC 2016

[5] Youngjin Kwon, Henrique Fingler, Tyler Hunt, Simon Peter, Emmett Witchel (UT Austin), and Thomas Anderson (University of Washington), “Strata: A Cross Media File System”, in Proc of ACM SOSP 2017

[6] A. T. Clements, M. F. Kaashoek, N. Zeldovich, R. T. Morris, and E. Kohler. “The scalable commutativity rule: Designing scalable software for multicore processors”, In Proc. of ACM SOSP 2013

[7] Jeffrey Dean and Luiz Andre Barroso. The Tail at Scale. Communications of the ACM, 56(2), February 2013.