최경열 군은, 컴퓨팅 관련 최근 동향 파악 및 역량 증진을 위하여 OSDI 2016에 참석 하였다.
해당 국제 학술대회 OSDI (USENIX Symposium on Operating Systems Design and Implementation)에서는 매년 운영체제, 네트워크, 클라우드 등 다양한 분야에 대한 논문들이 발표되며 특히 운영체제 및 스토리지 분야에 있어서는 세계적으로 인정받는 수준 높은 주제 및 이슈를 다루고 있다. 또한 OSDI 학회는 1994년도부터 2016년도까지 총 12번 개최된 국제학술대회로 Facebook, Google, Microsoft 등 다양한 기업들로부터 후원을 받고 있다. OSDI‘16 학회의 참가를 통해서 학회 내에서 발표되는 다양한 논문들을 파악하고 해당 논문 내용에 대해서 저자 혹은 발표자와 커뮤니케이션을 통해 필요한 정보를 얻을 수 있었다. 또한 각각의 논문 내용에 대한 개별적인 이해뿐 아니라 학회 내에서 발표되는 전반적인 논문의 성향을 파악함으로써 운영체제 및 스토리지 분야에 대한 최신 개발 트렌드를 확인할 수 있었다.
OSDI’16 학회에서 발표되는 47개의 구두 논문, 그 외 수십개의 Post-Session 논문들 중에서 특별히 관심을 가지고 있는 3개 논문에 대해 이전부터 가지고 있던 궁금한 사항들을 해당 논문의 저자들에게 질문하였다. 해당 논문들의 내용을 간단히 요약하면 다음과 같다.
1) The SNOW Theorem and Latency-Optimal Read-Only Transactions
네트워크를 사용하는 분산 스토리지 시스템에서 Read-Only Transaction이 가질 수 있는 4가지 Property를 제시하고 이를 통해 종래에 존재하는 여러 분산 파일 시스템(ex> COPS, Rococo)들의 최적화 모델을 제시하여 구현하였다.
(Q-1) 논문 상의 Evaluation 파트에서 SNOW Property의 Optimization에 대한 성능 분석의 대상으로 기존 분산 파일 시스템 COPS와 해당 파일 시스템을 Latency-Optimal을 적용한 COPS-SNOW를 비교하였다. 하지만 실제 COPS-SNOW의 구현은 COPS가 아닌 COPS의 후속 모델인 Eiger를 변형하였다고 되어 있는데 이 경우 실제 COPS를 Optimal한 결과 분석으로 적절치 못한 것을 아닌가?
(A-1) Eiger는 COPS의 후속 모델로 Original COPS와 달리 write-only transaction(SNOW Property: +W) 을 수행할 수 있기 때문에 질문에서 걱정한 문제가 발생할 수 있다. 위 논문에서는 이러한 문제점을 고려하여 Eiger에서 write-only transaction 기능을 Disable하도록 코드를 수정한 상태에서 COPS-SNOW로 변경 작업을 수행하였다.
(Q-2) COPS-SNOW의 Latency 측정 결과에 대해서 궁금한 점이 있다. 논문의 성능 분석 지료를 보면 쓰레드의 개수가 증가함에 따라 COPS-SNOW의 Latency가 높아지게 되는데 그 이유로 COPS-SNOW에서 발생하는 System Overload를 원인으로 지목하였다. 그런데 실제 256개 이상의 쓰레드 개수에서 Latency가 쓰레드의 개수가 증가하였음에도 오히려 낮아지는 부분을 확인할 수 있는데 이유가 무엇인가?
(A-2) COPS-SNOW에서의 256 쓰레드 이상의 워크로드는 시스템의 오버로드가 발생한다. 이는 쓰레드 개수 증가에 따른 정비례 관계에 있는 것은 아니며 시스템의 오버로드 발생에 대해서는 여러 고려해야 할 Side Effect 요인이 많기 때문에 쓰레드 개수가 많아진다고 무조건 Latency가 높아진다고 볼 수는 없다.
2) Incremental Consistency Guarantees For Replicated Objects
분산 파일 시스템 내 여러 개의 Data Center 안에 저장되어 있는 Replicated Object에 대해서 Consistency 보장을 위한 Strong Consistency, consistency보다 적은 latency를 우선으로 하는 Weak Consistency 모델이 있는데 위 논문에서는 두 Consistency Model의 장, 단점을 고려하여 Latency-Optimization을 통해 두 모델을 모두 사용하는 ICG 기법을 제시하고 있다.
(Q-1) 논문 상에 들어있는 Figure 1에서는 Consistency Model을 Strong Consistency Model과 Weak Consistency Model, 그리고 그 중간 영역에 해당하는 Gray Zone으로 분류해놓았다. 발표 과정에서는 두 Consistency Model을 절대적인 Latency값 (200ms)를 기준으로 분류하였는데 실제 Latency는 해당 워크로드의 특성, 스토리지, 네트워크 환경에 따라 크게 변동되는데 이 점에 대해서는 어떻게 생각하는가?
(A-1) 논문 및 발표 자료에서 제시되어 있는 Consistency 기준은 어디까지나 상대적인 것이며 당신이 말한 대로 실험 조건에 따라 위 Consistency 조건은 변경될 수 있다.
(Q-2) 위 논문에서 나온 실험 결과를 보면 ICG의 Consistency가 Strong Consistency와 동일하게 유지되면서 동시에 더 적은 Latency로 워크로드가 처리되는 것을 확인할 수 있다. 이에 대해서 스토리지, 네트워크 상황의 변동으로 Consistency를 위해 필요로 하는 시간이 줄어들었을 때, 동일한 실험결과를 얻을 수 있을 것인가?
(A-2) 위 논문의 구현은 자바 스크립트를 기반으로 하였으므로 일반 스토리지의 低 latency 조건은 고려되지 않았다.
3) Browsix: Bridging the Gap Between Unix and the Browser
대부분의 Web-application은 Browser 환경에서 제공하지 못하는 OS-API를 필요로 한다. 이러한 이유로 Application은 유저 인터페이스를 위한 Browser front-end side, OS-API 기능이 사용되는 Server back-end side로 분리된다. 이러한 문제를 해결하기 위해서 해당 논문에서는 Browsix라는 Interface를 제시한다. Browsix는 Unix의 핵심 기능을 브라우저 Interface로 옮김으로써 브라우저 Interface가 하나의 Operating System으로 동작하게 만든다.
(Q-1) Browsix가 Web-application의 Server back-end 사이드를 Browser 사이드로 옮김으로써 서버 통신으로 이한 Network Latency가 발생하지 않음에도 불구하고 실제 Browsix의 성능이 Native Browser + OS에서의 성능보다 떨어지는 이유는 무엇인가?
(A-1) Browsix를 통해 실제 Network Latency를 없애는데 성공하였지만 Browsix 구현으로 인한 부차적인 Overhead가 발생하였다. Browsix에서 발생하는 가장 큰 문제는 Javascript Overehead이다. Browsix는 기존 브라우저 기능뿐만 아니라 OS-abstraction 기능 모두 Javascript로 구현되어 있기 때문에 실제 Web-application의 동작 과정에서 기존 Server back-end side에서 C/C++과 같은 언어로 처리되었던 부분이 모두 Browsix 내에서 Javascript로 처리된다. 이러한 이유로 Javascript의 자체적인 처리 속도로 인하여 Browsix의 성능이 떨어지게 된다.
(Q-2) Browsix가 OS의 핵심 기능들을 Browser 내로 가져옴으로써 Web-application개발에 있어 OS-independency를 얻었음을 알 수 있었다. 그런데 Browsix는 사용하는 Browser의 종류와 무관하게 해당 Framework의 기능을 지원해주는가? (Browsix는 Browser-independency한가?)
(A-2) 결론부터 말하자면 Browsix는 모든 Browser에 대해서 동일한 기능을 지원해주지는 못한다. 예를 들어 Browsix의 Shared Memory 기능의 경우, 오직 Firefox와 Chrome Browser에서만 지원이 되는 문제가 있다. 이러한 이유로 Browsix는 OS-independency하다고 할 수 있지만 반대로 Browser에 dependent한 특성을 지닌다.
이번 OSDI 학회 참석은 스스로의 연구 개발에 자극제 역할을 해주었다. OSDI 학회에서 발표된 여러 논문을 살펴보면서 세계 최고 수준의 연구 레벨의 높이를 알 수 있었고 동시에OSDI 학회에서 확인할 수 있었던 연구 개발 분야의 최신 트렌드는 앞으로의 연구 방향을 설정하는데 큰 도움이 되었다. 특히, 현재 Storage 및 Transaction 분야는 단순히 단일 컴퓨터 내에서의 I/O 처리 동작보다는 네트워크 상에서 여러 개의 서버를 대상으로 하는 분산 파일 시스템을 중점적인 연구 대상으로 보는 것을 확인할 수 있어 이 부분에 대한 고려가 필요함을 느낄 수 있었다.
