노연진 군은, 스토리지와 파일시스템 관련 최근 동향 파악 및 역량 증진을 위하여 FAST 2017에 참석 하였다.
이번 15th USENIX Conference on File and Storage Technologies 즉 FAST’17 은 파일 시스템 및 스토리지 분야에서 세계 최고의 학회이다. 학회에 참석하는 세계 유수 연구소의 파일 시스템에서의 이슈 분석 및 동향 파악, 논문의 저자 혹은 부저자와 직접적인 질문 및 답변을 통해 논문 내용 이해 및 교류를 가질 수 있었던 좋은 기회였다. 또한 포스터 세션에서 발표한 논문에 대한 많은 연구자들과의 질답을 통해 보완 사항이나 최근 파일시스템 및 스토리지에서의 관심 분야를 확인할 수 있었던 기회를 가질 수 있었다. 또한, 파일 시스템 및 스토리 분야의 최신 기술 습득의 최고의 기회이기도 하며, 학회에 참석하는 구글, 마이크로소프트, 페이스북, 넷앱 등의 세계적 기업의 최신 기술을 접할 수 있는 좋은 기회였다.
첫째 날에는 “Disaggregate Paging for efficient Large Page Management”를 발표하기 위해 현지 시간 18:00~20:00 까지 Poster Session에 참석 하였다. 해당 세션에서 많은 질문자들과 답변을 통해 대형 페이지에 대한 아이디어 공유 및 보완 사항 등을 얻을 수 있었고 그 중 일부에 대해 써보고자 한다.
Q : 대형 페이지 사용 시 무슨 장점이 있으며, MongoDB나 Redis와 같은 DB와 무슨 관계인가?
A : 대형 페이지는 TLB의 메모리 관리 효율을 높여 전체적인 시스템 성능의 상승을 가져오는 효과를 가진다. 때문에, 메모리 객체의 크기가 크거나 자주 파일을 생성 및 삭제를 하는 프로그램의 경우 대형 페이지를 통해 메모리 관리에 대한 빠른 처리를 진행할 수 있다. MongoDB와 Redis가 그와 같은 경우이지만, 현재 리눅스의 대형페이지 관리 기법인 THP는 비효율적인 메모리 할당으로 인해 해당 DB에서는 THP를 사용하지 않는 것을 권장하기 때문에, 본 논문을 통해 빠른 대형 페이지의 메모리 회수 및 효율적인 관리를 진행하고자 한다.
Q : 대형 페이지의 비효율적인 메모리 관리? 그리고 편중된 페이지 접근은 무엇을 의미하는가?
A : 리눅스에서 대형 페이지 기능을 사용할 경우 페이지의 할당은 모두 대형 페이지의 단위로 실시된다. 즉, 아무리 작은 데이터 접근에도 대형 페이지 단위로 메모리를 할당하기 때문에 메모리의 사용량이 기하급수적으로 증가한다. 또한, 실제 요청된 페이지는 모두 접근 빈도만 확인하므로, 대형 페이지의 일부 영역에만 메모리 접근이 잦은 경우, 즉 편중된 경우에는 나머지 사용되지 않는 메모리 영역에 대한 회수가 불가능하여 메모리의 비효율적인 사용을 가속화 한다. 마지막으로 대형 페이지 기법에서는 메모리를 직접 회수하지 않고 단순히 대형 페이지를 소형 페이지로 분리하는 작업만 진행하기 때문에 이를 해결하기 위한 기법이 필요하며 이를 해결하고자 했다.
Q : 그럼 편중된 페이지를 확인하는 방법은 무엇인가? 있다면 실제 실험을 진행하였는가?
A : 대형 페이지 자료 구조체의 내부에 얼마나 많은 프로세스가 해당 대형 페이지를 사용하는지 카운트하는 Access Counter와 해당 대형페이지 내부에 얼마나 많은 기본 페이지들이 사용되는지를 카운팅하는 Referenced Page Counter를 두어 두 값중 하나라도 기준보다 낮은 경우 대형 페이지를 기본 페이지로 분리하는 작업을 진행한다. 반대로 두 값 모두 기준 값보다 낮은 경우 대형 페이지를 직접 할당 해제하는 작업을 진행하고자 한다. 아직 구상중인 아이디어이기 때문에 실제 구현은 되지 않았고 실험을 진행하진 못했다.
Q : 대형 페이지를 사용하는 다른 이유가 있다고 생각하나? 예를 들어 현재 가상 머신에서는 게스트 머신의 메모리를 관리할 때 대형 페이지 단위로 묶어서 사용한다고 한다. 이와 같은 기법의 사용 이유 및 이를 위한 기법에 대해 새로 고려해 보았는가?
A : 가상 머신에서 대형 페이지를 쓴다는 얘기는 아직 들어보지 못했다. 다만 호스트 머신에서 게스트 머신의 메모리를 관리한다는 측면에서는 확실히 대형 페이지를 사용하면 성능상의 이득이 발생할 것 같다. 게스트 머신을 사용하기 위해 TLB를 낭비하지 않는다는 점에서는 더더욱 그럴 것 같다.
둘째 날에서는 포스터 세션을 통해 “Application Crash Consistency and Performance with CCFS”에 대한 내용에 대해 부저자와 이야기 해볼 수 있었다. CCFS에서는 기존 EXT4의 Compound Journaling에서 발생하는 문제를 해결하고, Application 단위로 Crash 상황에서의 Order Consistency를 보장하기 위한 기법을 개발한 논문이다. CCFS에서는 응용 프로그램 별로 stream이라는 자료 구조체를 할당한다. Stream은 각 응용 프로그램을 위한 개별 러닝 트랜잭션 개념으로 사용되며, COW 방식을 사용하여 스트림 별 메타데이터 일관성을 보장하는 기법을 사용한다. 이를 통해 메타데이터 저널링을 응용 프로그램 별로 실시할 수 있으며, 응용 프로그램에서의 저널링 순서를 보장할 수 있다는 장점이 있다. 해당 논문에 대해 질문한 사항으로는 아래와 같다.
Q : 재미있는 아이디어인데, 혹시 응용프로그램의 메타데이터 갱신이 같은 파일에 대해서 발생하는 상황을 어떻게 처리하는가?
A : 각 응용 프로그램에서는 스트림을 시작할 때, 스트림을 시작하기 전 변경할 영역에 대해 COW 기법을 사용한다. 때문에 두 스트림이 서로 같은 파일에 대해 작업을 진행할지라도 COW를 발생시키기 때문에 문제 없다.
Q : 그 말은 같은 파일의 같은 영역에 대해서도 적용되는가? 예를 들어 응용 프로그램 1이 폴더 /X를 만들고 응용 프로그램 2가 /X에 새로운 파일을 쓰는 경우와 같을 때 두 응용 프로그램에서 COW를 사용해도 문제가 발생할 것 같다.
A : 그와 같이 응용 프로그램 사이에서 순서를 보장을 직접적으로 보장해 줘야하는 경우에는 각 응용 프로그램의 스트림을 병합하여 하나의 스트림으로 취급한다. 이 후 새로운 스트림에 대한 요청이 들어온 경우 다시 각각의 앱에 따른 별도의 스트림 저널링을 실시한다.
Q : 충돌이 날때마다 개별 스트림들을 하나로 병합할 때에는 기존 EXT4와 비교하여 성능이 감소될 것 같은데, 이를 어떻게 생각하나?
A : 물론 그렇다. CCFS는 성능을 향상시키는 것을 주 목적으로 하지않고 응용 프로그램의 저널링 순서를 보장하면서, EXT4와 비교하여 그리 크게 떨어지지 않는 성능을 가지는 것을 목표로 하기 때문이다.
마지막으로 “DIDACache: A Deep Integration of Device and Application for Flash Based Key-Value Caching” 논문은 시간이 없어 실제 저자와 이야기해보지는 못했지만, 저자의 발표와 논문을 읽고 최대한 내용을 요약해보고자 한다. 기존 Facebook에서 개발한 Fatcache 기법은 Memcache 기법을 기반으로 만들어진 Flash 스토리지를 위한 Key-value Cache 기법이다. Fatcache에서는 응용 프로그램 단위에서의 Key-Value매핑 정보를 유지하기 위해 Hash 테이블 자료 구조를 통해 KV 값을 관리하며, Value값을 Slab 할당자를 통해 관리한다. 자세히는 Value 데이터를 Slab 할당자의 slot 단위로 분산하여 하나의 Key 자료 구조체에 slot 집합을 통해 데이터를 저장하도록 하는 기법을 사용한다. 때문에, Value 값에 대한 데이터 변경 및 할당 해제 요청 시 직접 Value에 접근하지 않고 Hash 매핑 테이블에서 해당 내용을 갱신하거나 삭제하기만 한다. 이렇게 사용되지 않는 영역은 응용 프로그램 단의 GC를 통해 회수되며, 별도의 GC 오버헤드가 존재한다. 문제는, Flash 스토리지에서도 페이지 매핑 및 GC 등의 작업을 처리하기 때문에, 이와 같은 GC 및 매핑 테이블 관리와 같은 작업을 중복적으로 사용한다는 문제가 있다. 때문에, DIDAcache에서는 이러한 점을 참조하여 Flash 스토리지 기반 Key-Value caching 시 해당 Value에 대한 매핑 테이블을 작성할 때, Key 값이 직접 Flash 스토리지의 물리 Way 및 Channel에 직접 매핑할 수 있도록 변경하였다. 즉, FTL과 응용 프로그램 단에서 발생한 매핑 오버헤드 및 GC 오버헤드를 응용 프로그램에서만 실시하도록 통합하여 오버헤드를 감소시키는 것을 목적으로 한다. 본 논문에서는 이를 위해 Flash 스토리지 기반 Key-Value 캐시 응용프로그램을 개발하였으며, KV 캐시에서 발생한 Slab 할당 명령을 Flash 명령어로 변경시키기 위한 라이브러리를 개발하였다. 또한, FTL를 직접 수정할 수 있는 Open Channel SSD를 통해 FTL에서 별도의 작업을 진행하지 않도록 변경하였으며, 덕분에 DIDAcache에서의 Flash 스토리지는 GC 및 매핑 테이블 유지를 하지 않고 Flash 명령어만 처리하여 성능 및 데이터 관리를 효율적으로 사용할 수 있게 된다.
이번 FAST’17에서 가장 인상적이였던 것은 역시 CCFS 논문이였다. 응용 프로그램의 저널링 순서를 보장하기 위해 응용 프로그램마다 별도의 스트림을 통해 저널링을 시도한다는 아이디어는 매우 신선하였으며, 저널링에 대해 공부할 때 배웠던 많은 내용을 바탕으로 부저자와 얘기할 수 있어 매우 값진 경험이였다고 생각한다. 또한, 최근 파일 시스템 및 스토리지에서 순서 보장 및 저널링 컨텐션에 대한 관심이 매우 높다는 것을 알 수 있었으며, OpenChanel SSD를 통해 새로운 펌웨어를 만들거나 FTL 정책을 변경을 통해 성능 및 일관성 보장 작업을 더욱 효울적으로 진행하는 것을 보고 해당 내용에 대해서도 관심을 가지게 된 계기가 되었다. 무엇보다도 이번에 발표한 대형 페이지에 대해 다수의 유익한 코멘트를 받아 개인적으로도 즐거운 시간이였다.