[Vol.11 No.4] 도커 컨테이너 이관 (Docker container migration): Part II

  • 작성자

    관리자
  • 작성일자

    2021-12-10 00:00
  • 조회수

    428

도커 컨테이너 이관 (Docker container migration): Part II

 

한림대학교 소프트웨어융합대학 김태운(taewoon@hallym.ac.kr)



1. 들어가는 말
  지난 “도커 컨테이너 이관 (Docker container migration): Part I”에서는 엣지 컴퓨팅 환경에서 Stateful and Live Container Migration을 구현하기 위해 필요한 기본 기술에 대해 살펴보았다. 이번 고는 컨테이너 이관 기술 및 구현을 다룬다.


2. 컨테이너 이관 기술: 연구 동향
  지난 고에서 소개한 바와 같이 Stateful Migration 이란 상태를 보존한 채로 컨테이너를 이관하는 것을 말하여, 이때 “상태”란 휘발성 정보(메모리 내용, 프로세스 실행 정보 등)뿐 아니라 비 휘발성 정보(파일시스템에 저장된 정보 또는 파일)를 포함한다. Live Migration이란 온라인실시간으로 진행되는 이관을 말하여, 이때 컨테이너 서비스 사용자가 서비스 단절 등을 경험하지 않도록 이관 작업이 Transparent 하게 진행되어야 한다.

  컨테이너 이관 기술은 크게 두 가지로 나눌 수 있는데 하나는 State-Transfer Migration(상태 전송 이관 기법)이고, 다른 하나는 State-Rebuilding Migration(상태 재생성 이관 기법)이다. 설명을 돕기 위해 아래 <그림 1>과 같이 각 Access Point(AP)에 하나의 Edge Server(ES)가 연결된 IEEE 802.11 WLAN 네트워크를 가정한다. 사용자 단말(MU)이 AP-1을 통해 ES-1(src)로부터 오프로딩 서비스를 받고 있다. 잠시 후, 사용자의 이동으로 인해 AP-2로 핸드오프[1]가 발생했고 오프로딩 서비스 지연시간을 최소화 하기 위해 ES-1(src)에서 ES-2(tgt)로 컨테이너를 이관하려는 상황이다.
 



<그림 1> 네트워크 구성


  일반적인 상태 전송 이관 기법[2]은 CRIU[3] 등의 도구를 활용하여 메모리 상태를 저장하고, 원격 파일 전송 도구를 활용하여 메모리 상태 및 파일 시스템의 변경 사항을 ES-2(tgt)로 전송한다. 모든 전송이 완료되면, ES-2(tgt)는 ES-1(src)의 최신 상태와 동일한 상태로 컨테이너를 실행할 수 있다. 상태 재생성 이관 기법[4]은 상태를 직접 전송하지 않는다. 대신, ES-1(src)에서 수행한 작업 내역(또는 실행 명령어)을 ES-2(tgt)로 전송하고, ES-2(tgt)는 수신한 작업 내역을 순서대로 재실행 하여 ES-1(src)와 동일한 상태를 만들어낸다.


3. 컨테이너 이관 기술: 구현 및 검증
  컨테이너 이관 기술 구현을 위해 <그림 1>과 동일한 네트워크 환경 및 시나리오를 사용한다. 사용자 단말은 AP-1을 통해 ES-1(src)로부터 오프로딩 서비스를 받고 있으며, AP-2로 핸드오프 되는 순간 ES-1(src)에서 ES-2(tgt)로 이관 작업이 시작된다. 실험 환경은 노트북 한 대와 데스크 탑 PC 두 대로 구성했다. 노트북은 사용자 단말의 역할(오프로딩 서비스 요청)을 수행하고, PC-1은 AP-1 및 ES-1 역할을, PC-2는 AP-2 및 ES-2 역할을 수행한다. Linux Traffic Control 도구인 tc[5]를 사용하여 AP간 데이터 전송 시 RTT가 200ms가 되도록 지연시간을 추가했다.

  도커 공식 이미지 저장소(https://hub.docker.com)에 공개된 python:3.8 이미지를 베이스로 설정하고, 오프로딩 서비스를 구현한 파이썬 어플리케이션을 실행하도록 커스텀 이미지를 구성하여 컨테이너를 운용한다. 이미지는 다수의 읽기 전용 계층(Read-Only Layers)으로 구성되어 있고, 이는 컨테이너의 파일 시스템을 구성하는데 사용한다. 컨테이너 실행 중에 파일 시스템에 변경 사항이 발생하면(예: 파일 생성, 수정, 삭제 등) 해당 내역이 쓰기 계층(Writable Layer)에 저장된다. 

  본 고에서 구현하는 컨테이너 이관 기술은 Stateful Migration 기법이며, 이관이 진행되는 동안 서비스 단절이 없는 Live Migration 기법이다. 동작 방식은 다음과 같다. 사용자가 AP-2로 핸드오프 되면, ES-2(tgt)는 ES-1(src)에게 컨테이너 이관을 요청한다. 컨테이너 이관 요청을 수신한 ES-1(src)는 1) 실행중인 컨테이너를 이미지로 저장하여 ES-2에게 전송하고 2) 체크포인트를 생성하여 ES-2에게 전송한다. 실행중인 컨테이너를 이미지로 저장하면 읽기 전용 계층 및 쓰기 계층의 내용이 파일 형태로 저장되어, 컨테이너 구동 중에 발생한 파일 시스템의 상태 변화를 보존할 수 있다. 이때 사용하는 명령어는 docker commit, 그리고 docker save 이다. 이미지 생성 및 체크포인트 생성 후에도 컨테이너가 지속적으로 서비스를 제공할 수 있도록 --pause=false--leave-running=true 옵션을 사용한다. 이미지 및 체크포인트 파일 전송에는 secure copy protocol(scp)을 사용하여 보안을 유지한다. ES-2(tgt)는 수신한 이미지로 컨테이너를 생성하고, 수신한 체크포인트로 컨테이너를 실행하여 ES-1(src)와 동일한 상태를 복원할 수 있다.

  ES-1(src)에서 이미지 및 체크포인트를 생성하고 전송한 후에 컨테이너를 즉시 종료하지 않는 이유는 다음과 같다. 사용자가 AP-2로 핸드오프 된 직후에 ES-2(tgt)로 컨테이너 이관이 시작되는데, 컨테이너 이관 시간은 상황에 따라 가변적이며 상당시간 지속될 수 있다. 따라서, ES-1(src)에서 이미지 생성 및 체크포인트 생성 직후 ES-1(src)를 종료한다면 ES-2(tgt)에서 컨테이너 복원이 진행되는 동안 서비스가 중단될 수 있다. 이를 방지하기 위해, AP-2는 ES-2(tgt)에서 컨테이너가 복원될 때까지 사용자의 서비스 요청을 AP-1으로 전달 해 주고 ES-1(src)를 통해서 서비스 받을 수 있게 한다. AP-2는 이렇게 전달된 서비스 요청을 별도의 선입선출 방식의 자료구조로 보관하고 있다가 ES-2(tgt)에서 컨테이너 복원이 완료되면 ES-2(tgt)에 순차적으로 전달하여 이관 중에 발생한 ES-1(src)와 ES-2(tgt)간 상태 차이를 동기화한다.

  아래의 <그림 2>는 1 request/second 의 속도로 서비스 요청을 보내는 사용자의 컨테이너가 이관 될 때, 개별 서비스 요청의 응답시간 변화를 측정한 결과이다. 실험 시작을 기준으로 50초 경과 후 사용자는 AP-2로 핸드오프 된다. 이로 인해 50번째 request 부터 응답시간이 크게 증가하는데, 이는 AP-2가 수신한 사용자 요청을 AP-1으로 전달하여 ES-1(src)가 처리하고, 그 결과를 다시 AP-2로 돌려보내는 과정에서 소모하는 시간 때문이다. 참고로, 실험환경에서 AP간 전송에 소요되는 지연시간은 수십 ms 수준이나, 리눅스 tc 유틸리티를 사용하여 AP간 전송지연시간을 단뱡향 기준 100ms, RTT 기준 200ms 수준으로 설정했다. 이관에 소요되는 총 시간은 약 37초이며, 대부분의 시간을 컨테이너 이미지(약 950MB) 전송에 소비했다.
 



<그림 2> 컨테이너 이관으로 인한 서비스 응답시간 변화 측정



4. 맺음말
  총 2개의 파트로 구성된 도커 컨테이너 이관 기술 소개는, 지난 고에서 컨테이너 이관에 필요한 기본 기술을 살펴보았고 이번 고에서 Stateful and Live Migration 기법을 구현하는 것으로 마무리한다. 본 고에서 소개한 컨테이너 이관 기법은 기초적인 상태 전송 이관 기법의 하나로써, 체크포인트 도구를 사용하여 메모리 상태를 전송하고, 실행중인 컨테이너의 읽기 전용 계층과 쓰기 계층을 모두 전송하여 파일시스템의 변경사항을 유지한다. 하지만, 이는 비효율적인 이관 기법인데, 예를 들어, [2]에서 언급한 바와 같이 체크포인트와 쓰기 계층의 전송만으로 컨테이너를 이관할 수 있기 때문이다.


<참고자료>
[1] A. Mishra, M. Shin, and W. Arbaugh, “An empirical analysis of the IEEE 802.11 MAC layer handoff process,” ACM SIGCOMM Computer Communication Review, vol. 33, no .2, pp. 93–102, 2003.
[2] L. Ma, S. Yi, N. Carter, and Q. Li, “Efficient live migration of edge services leveraging container layered storage,” IEEE Transactions on Mobile Computing, vol. 18, no. 9, pp. 2020-2033, Sep. 2018.
[3] Checkpoint/Restore In Userspace, CRIU. [Online]. Available: https://criu.org/.
[4] C. Yu and F. Huan, “Live migration of Docker containers through logging and replay,” in Proc. International Conference on Mechatronics and Industrial Informatics (ICMII), Zhuhai, China, 2015.
[5] Linux Traffic Control. [Online]. Available: https://man7.org/linux/man-pages/man8/tc.8.html.