노연진 군은, 컴퓨팅 관련 최근 동향 파악 및 역량 증진을 위하여 OSDI 2016에 참석 하였다.
OSDI는 명실 공히 시스템 소프트웨어 분야에서 세계 최고의 학회이다. 학회에 참석하는 세계 유수 연구소의 OS 분야 연구 동향 파악, 논문 저자와 직접적인 질문 및 답변을 통한 논문 내용 이해 및 교류를 위한 좋은 기회였다. 또한 시스템 소프트웨어 분야의 최신 기술 습득의 최고의 기회이기도 하며, 학회에 참석하는 구글, 마이크로소프트, 페이스북, 넷앱 등의 최고의 기업의 최신 기술을 접할 수 있는 좋은 기회였다.
첫째 날 진행된 포스터 세션에서 Emory University의 ”Mithril: Mining Block Correlation for Cache Prefetching”[1] 논문을 찾아볼 수 있었다. 해당 논문은 기존 공간, 시간적 지역성을 통해 캐싱을 하던 방식과는 달리 데이터 마이닝 기법인 연관성(Correlation)을 고려하여 데이터를 캐싱하는 기법으로, 일정 Time Stamp내에 캐싱된 두 데이터 블록이 같이 나온 횟수가 많으면 많을수록 연관성이 높다고 판단한다. 연관성이 높은 두 블록은 지역성이나 동작 프로세스 등에 상관없이 캐싱할 경우 성능이 높아지는 것을 발견하여, 이를 바탕으로 실험을 실시하였다. 이에 대한 정확한 이유와 증명이 확실하지 않아 아직 시작단계의 논문인 것으로 보이지만, 분산 파일 시스템이나 Big Data에 쓰이는 데이터 마이닝의 기법을 개별 컴퓨터의 캐싱 기법으로 사용하여 성능상의 이득을 본 것에 의미를 두어 논문을 선정하게 되었다. 아래는 저자에게 Mithril 기법에 대한 질문을 한 후 답변 받은 내용이다.
Q1. 기존 블록 캐싱 기법에서 지역성이 아닌 데이터 마이닝을 사용한 계기가 있는가?
A1. 캐싱 기법에 관해서는 연구실의 캐시 블록 Trace 자료를 클러스터링 기법을 통해 분석하는 과정에서, 일정 time stamp 내에 일정 데이터 블록이 지속해서 나온 것을 확인하였으며, 이에 착안하여 데이터 마이닝 기법을 적용하여 보았다.
Q2. 시간적 연관성이 높은 두 블록은 공간적, 시간적 지역성 및 프로세스간의 관계도 상관없이 캐싱할 경우 성능상의 이득이 있는 이유는 무엇인가?
A2. 데이터 마이닝에서 쓰이는 방식인 Decision Tree와 같이 우리는 캐싱 블록의 특성(Attribute)을 고려하여 가장 성능이 좋은 집단을 판별하였으며, 이 중 동일 Time Stamp 내에서 반복적으로 나타나는 두 캐싱 블록의 경우가 모든 경우에서 좋은 성능을 내는 것을 확인하였다.
Q3. 두 캐싱 블록이 연관성이 높다는 것은 어떻게 확인하는가? 즉, 캐싱 블록들에 대해서 기록하는 자료구조나 이를 관리하는 스레드가 있는가?
A3. 본 논문에서는 두 캐싱 블록이 나타나는 횟수를 기록하는 자료구조를 생성하였으며, 캐싱 블록 Prefetch 시 이 자료구조를 참고하여 캐싱하는 기법을 구현하기 위해 페이지 폴트 핸들러 부분을 수정하였다.
같은 날 “EC-Cache: Load-Balanced, Low-Latency Cluster Caching with Online Erasure Coding”[2] 논문 또한 흥미로운 주제였다. 저자는 현재 페이스북 아마존 EC2와 같은 대용량의 클러스터 환경에서 Object의 크기가 증가하며, 이에 따른 서버 간의 불평등한 접근(Skewed Popularity)이 발생한다고 주장하는 것으로 논문의 내용을 시작한다. 이에 대한 근거 자료로 페이스 북의 데이터 센터의 자료를 분석하여, 대부분의 워크 로드가 대용량의 Object에 편중되어 있다는 자료를 제공하였다. 논문의 주제인 EC-Cache는 이러한 환경에서 기존 분산 파일 시스템(Distribute File System)에서 사용하는 Object Caching 최적화 기법을 다룬 논문이다. 논문의 기본 주제는 기존 데이터 복구에 사용하는 Erasure Coding을 수정하여 하나의 Object를 k개로 분산 후 r개의 패리티를 생성 후 임의의 서버들에 분산시켜 저장하는 기법에 대해 설명하고 있다. EC-Cache는 이와 같은 구조를 통해 분산 파일 시스템에서 대용량의 Object를 여러 서버에 분산시켜 로드 밸런싱 및 Tail Latency 문제를 해결하여 성능상의 이득을 얻을 수 있다고 한다. 아래는 부 저자와 EC-Cache에 대해 궁금한 점에 대해서 질문하고 답변 받은 내용이다.
Q1. 논문에서는 EC-Cache에서 Erasure Coding에서 k의 값에 따라 성능이 증감하는데, Object의 크기에 따라 k의 값이 변화할 수 있는가? 혹은 k의 값에 변화를 줄 수 있는 변수가 있는가?
A1. Object의 크기가 커지면 커질수록 최대 성능을 내는 k의 값이 커질 수 있지만, 대게 k=7일 때 가장 좋은 성능을 내며 이는 Object의 크기가 10~100Mbyte인 경우 대부분 일치했다. k의 값에 변화를 줄 수 있는 또 다른 변수로는 서버의 개수를 들 수 있다고 본다. 단일 서버와 같이 서버의 수가 적을 때에는 k의 값이 크면 클수록 성능이 좋지 않다.
Q2. EC-Cache의 Read Latency가 좋은 것은 확인할 수 있지만, Write 시에 Split이나 Encode같은 방식을 Client에게 강요하므로 이에 대한 오버헤드가 존재하지 않는가?
A2. 물론 기존 방식에 비하면 Write(PUT) 명령어 실행 시, client에 Object를 Encoding하는 오버헤드가 존재할 수 있다. 하지만, 이와 같은 오버헤드는 Write의 성능을 크게 감소시키지 않으며, 반대로 Write 시에도 로드 밸런싱이 가능하므로 성능상의 이득을 얻을 수도 있다.
Q3. 큰 Object일수록 데이터 접근이 많은 Skewed Popularity 문제는 본 논문에서 충분히 다룬 것 같은데, 혹시 RAID 환경에서 발생하는 Small Write Problem과 같이 작은 Object의 경우에도 EC-Cache 기법을 적용하는가?
A3. 논문에서도 다룬 내용이지만, 작은 Object의 경우에는 오히려 EC-Cache를 적용하는 것이 오버헤드일 수 있다. 때문에, 본 논문에서는 이를 고려하여 작은 Object(주로 1Mbyte 이하)인 경우, 기존 방식인 Selective Replication 기법을 적용한다.
마지막으로 찾은 논문은 두 번째 포스터 세션에서 진행된 “Coordinated and Efficient Huge Page Management with Ingens” 논문이었다. Huge Page에 대해서 개념 및 구조를 살펴본 적이 있었으며, 성능상의 문제점을 제시한 커뮤니티 내용을 읽은 기억이 있어 해당 논문을 선정하였다. 먼저 논문에서는 현재 대용량의 서버와 같은 환경을 다룰 경우 MongoDB, Redis, 또는 리눅스와 같은 다양한 시스템에서는, 페이지의 기본 크기인 4Kbyte 뿐만 아니라2Mbyte나 4Gbyte와 같이 다양한 크기의 페이지를 사용할 수 있도록 Huge page 기법을 지원한다고 한다. 이와 같은 Huge Page는 Head Page라 불리는 첫번째 4Kbyte 페이지만 TLB 캐시에 적재함으로써 대용량 데이터의 TLB 캐싱 오버헤드를 감소시키는 장점이 있다. 허나, 대부분의 시스템에서 사용중인 Huge Page 방식은 Memory Bloating 및 High Page Fault Latency 문제 등에 대해 최적화되지 않아 성능상 오버헤드가 존재한다. 때문에, 이를 해결하고자 Huge Page를 관리하기 위한 기법인 Ingens를 소개하며, 별도의 스레드를 통해 비동기적으로 페이지들을 Huge Page로 변환(Promote)하거나 해제(Demote)하는 작업을 진행한다. 다음은 부 저자와 Ingens 기법에 대해 궁금한 점에 대해서 질문하고 답변 받은 내용이다.
Q1. 리눅스의 Transparent Huge Page 기법은 page 관리를 위해 Anonymous Mapping을 사용하여 프로세스 간의 동기화나 Zero Page 문제 등이 존재하는데, 이를 고려하였음에도 불구하고 리눅스의 Huge Page 기법을 사용한 이유는?
A1. 리눅스를 선택한 계기는, 리눅스의 Huge Page 기법은 현재 시중에 있는 어떠한 기법보다 좋은 성능을 내기 때문이며, 추후 개발계획으로 Anonymous Page 뿐만 아니라 일반 파일 시스템에서도 Huge Page를 지원할 계획이라 들었기 때문이다.
Q2. Huge Page 사용 시 발생할 수 있는 문제로 Memory Bloating 및 High Page Fault Latency를 들었는데, 페이지의 크기가 커짐에 따라 Prefetch 및 Evicting 과정에서 문제가 발생할 수 있지 않을까?
A2. Prefetch와 Evicting 과정은 Ingens에서는 담당하지 않고, 단순히 LRU List 내부에 있는 페이지들을 Huge Page로 전환하는 Promote 및 Huge Page로 묶인 페이지를 해제하는 Demote 과정만을 담당한다.
Q3. Ingens의 Promote와 Demote 과정에서 Huge Page 만의 별도 LRU List를 설정하여 Promote, Demote를 결정하게 한다면 성능상의 이득이 존재할까?
A3. Demote 과정을 더욱 빨리 진행할 수 있을 것이라는 면에서는 재밌는 생각이지만 Promote 과정에서는 페이지를 이동시키는 오버헤드가 발생할 것 같다. 자세한 것은 실험이 필요할 것 같다.
이번 OSDI 2016 학회 참석을 통해서 세계 수준의 논문이 어떠한 내용을 담고 있으며, 어떠한 트렌드를 가지는지 조금이나마 알게 되었다. 현재 페이스북이나 아마존같은 대기업의 데이터센터에서 사용되는 클러스터 파일 시스템의 관리 오버헤드를 줄이는 문제, 대용량 파일 시스템에서의 프로그램 관리 등 점점 거대한 규모의 컴퓨터 시스템 관리에 주목하는 현 논문들의 동태를 알 수 있었으며, 이를 반영하여 컴퓨터 계열에서 Big Data나 Heavy Workload인 시스템에서의 동작을 주로 고려하는 것을 볼 수 있어 연구 방향이나 주제를 정하는데 좋은 지표가 될 수 있을 것 같다.