[클라우드 컴퓨팅] 컨테이너 마이그레이션 (17)

[2] 컨테이너 마이그레이션

마이그레이션
-  클라우드 기반 서비스 운용 중에, 시스템 장애 또는 유지보수 등으로 인해 다운타임이 발생할 수 있다.
-  서버의 유지보수등 예측가능한 다운타임은 마이그레이션을 통해 다운타임을 최소화 할 수 있다.
-  마이그레이션이란, 하나의 물리 머신에서 다른 물리 머신으로 가상 자원을 옮기는 것을 뜻한다.

Mobile Edge Computing (Mobile User + Edge Computing)
-  Task Offloading :복잡한 연산을 클라우드로 offloading
-  기존 접속한 access network와 멀어져 다른 access network에 연결하는 Handover 이벤트가 발생할 수 있다.

마이그레이션 기술의 분류
-  Cold migration : 가상 자원을 정지 한 후, 다른 서버로 옮기는 방식
-  Live migration :가상 자원이 실행 중인 상태를 유지하면서 다른 서버로 옮기는 방식

마이그레이션 기술의 분류2
-  State-less migration : 가상 자원의 상태 정보를 무시하고 이관하는 기법
-  Stateful migration : 가상 자원의 상태 정보를 유지한채로 이관하는 기법
-  지속성 상태 : 파일 시스템에 기록되는 상태 정보(파일, 디렉토리 등)
-  휘발성 상태 : 메모리/캐시/레지스터등에 저장된 상태 정보

마이그레이션 기법
-  Cold, stateless migration
-  Cold, stateful migration
-  Live, stateless migration
-  Live, stateful migration

마이그레이션 시간
-  Preparation time : 수행 전, 현재 사용중인 머신과 새로운 머신의 사전 준비 작업을 수행하는데 소요되는 시간
-  Down time : 수행 동안 발생한느 서비스 중단시간
-  Resume time : 작업 완료 후, 새로운 머신에서 서비스를 재시작 하는데 소요되는 시간
-  Total migration time : 총합 시간

마이그레이션 기법 구현을 위한 핵심 기술
-  Secure file transfer : 가상 자원이 파일의 형태로 전송될 때 보안 위협에 대응하는 전송 기술
-  Autonomous virtual resource control : 사전에 정의된 조건이 만족될 경우 가상 자원을 자동화된 방법으로 정지, 일시 정지, 재시작 하기 위한 관리 기술
-  Logging : 가상 머신, 컨테이너 등의 구동 및 이관 과정에서 발생하는 기록을 저장하기 위한 기술
-  Export : 가상 머신 및 컨테이너의 지속성 상태를 포함하는 탬플릿 이미지를 생성하고 파일의 형태로 저장하는 기술
-  Snapshot : 가상 머신 및 컨테이너의 휘발성 상태 정보를 파일의 형태로 저장하는 기술
-  Dump : Snapshot과 Export를 합하여 Dump라고 표현하기도 한다.

컨테이너 가상화 환경에서의 마이그레이션
-  VM 마이그레이션과 컨테이너 마이그레이션은 기본적인 이관 절차가 거의 동일하다.
-  컨테이너는 이미자 파일의 용량이 상대적으로 작고, 컨테이너 중단 및 시작에 소요되는 시간이 짧다.

컨테이너 가상화 환경에서 마이그레이션 구현을 위한 핵심 요소
-  사용자 요청에 대한 라우팅 : 라우팅 테이블이 업데이트 되는 시점이 중요하다.
-  Live Migration : 이관이 진행되는 동안 서비스 상태가 변경될 수 있다.
-  Dump : 지속성 및 휘발성 상태 정보 관리

@컨테이너 지속성 상태 정보 관리
-  도커의 경우 컨테이너 최상위 레이어인 writable layer에 저장되는 정보를 말한다.
-  Writable layer의 정보만 별도로 저장하거나 export 명령을 사용해 새로운 이미지를 만들어 내는 방식으로 지속성 상태 정보를 파일의 형태로 저장할 수 있다.

@컨테이너 휘발성 상태 정보 관리
-  메모리에 저장된 정보 및 프로세서의 상태 정보를 파일의 형태로 저장하고 새로운 머신으로 전송한다.
-  CRIU : C언어로 작성된 리눅스 전용 tool
-  도커 checkpoint : CRIU를 기반으로 구현된 experimental command (2024)

컨테이너의 cold, state-less migr
-  1. 소스 머신에서 컨테이너 중단
-  2. 이관 (이미지 전송)
-  3. 타겟 머신에서 수신한 이미지를 실행
-  4. 라우팅 테이블 업데이트
-  사전에 이미지 파일을 타겟 머신에 저장하는 방법을 통해 이관 시간을 최소화 할 수 있다.

컨테이너의 cold, stateful migr
-  1. 소스 머신에서 컨테이너 중단
-  2. 상태 정보 Dump
-  3. 이관 (이미지 전송)
-  4. 타겟 머신에서 수신한 이미지와 상태 정보를 사용해 컨테이너 생성
-  5. 라우팅 테이블 업데이트
-  파일 전송 시간이 긴 만큼, 서비스 중단 기간도 길어진다.

컨테이너의 live, state-less migr
-  1. 이관 (이미지 전송)
-  2. 타겟 머신에서 수신한 이미지를 실행하여 컨테이너 생성
-  3. 라우팅 테이블 업데이트
-  마찬가지로 상태 정보 없이 템플릿 이미지를 그대로 사용하기 때문에, 사전에 이미지 파일을 타겟 머신에 저장하는 방법을 통해 이관 시간을 최소화 할 수 있다.

컨테이너의 live, stateful migr
-  컨테이너 중단이 발생해도, 사용자가 인지하지 못할 정도라면, 이 또한 live migr로 볼 수 있다.
-  구현 방법 : pre-copy, post-copy, hybrid (휘발성 상태 전송에 중점을 둠)
-  구현 방법 : log replay (서비스 유형을 고려)

Pre-Copy Migration
-  0. 타겟 머신에 이미지 파일이 이미 존재한다고 가정.
-  1. 소스 머신은 memory state만을 전송한다, 상태 파일을 전송하는 동안 발생한 상태 변경 내역을 다음 차례에 전송하는 방식을 반복적이고 점진적으로 수행 (pre-dump)
-  2. 위의 과정이 지정된 횟수만큼 수행되면, 소스 머신 컨테이너를 중단하고, 마지막 휘발성 상태 정보를 타겟 머신으로 전송
-  3. 타겟 머신은 수신한 상태 정보를 사용해 컨테이너를 시작
-  4. 라우팅 테이블 업데이트

@Pre-Copy Migration Specific
-  1. Pre-dump state
-  2. Transfer pre-dump
-  3. Stop container
-  4. Dump modified state
-  5. Transfer dump
-  6. Resume container

Post-Copy Migration (CRIU -lazy-pages)
-  0. 타겟 머신에 이미지 파일이 이미 존재한다고 가정.
-  1. 소스 머신은 컨테이너를 일시 중단하고, 프로세서 상태만을 저장하여 타겟 머신으로 전송
-  2. 타겟 머신은 수신 받은 프로세서 상태를 이용해 컨테이너를 시작 및 라우팅 테이블 업데이트
-  3. 타겟 머신에서 변경된 메모리 상태를 참조하는 연산 발생 시(page fault), 해당 메모리 상태 정보를 소스 머신으로 부터 수신
-  Pre-Copy Migr보다 빠르다.
-  Page fault 발생 시, 모든 dirty page가 전송 되기 까지 전체적인 서비스 성능이 떨어질 수 있다.

@Post-Copy Migration Specific
-  1. Stop container
-  2. Dump execution state
-  3. Transfer dump
-  4. Resume container
-  5. Transfer faulted pages

Hybrid Migration
-  0. 타겟 머신에 이미지 파일이 이미 존재한다고 가정.
-  1. 소스 머신에서 상태 정보 전체 또는 일부를 타겟 머신으로 1회 전송
-  2. 타겟 머신은 수신 받은 프로세서 상태를 이용해 컨테이너를 시작 및 라우팅 테이블 업데이트
-  3. 변경되었으나 수신 받지 못한 메모리 상태를 참조하는 연산 발생시, 해당 메모리 상태 정보를 소스 머신으로 부터 수신

@Hybrid Migration Specific
-  1. Pre-dump state
-  2. Transfer pre-dump
-  3. Stop container
-  4. Transfer dump
-  5. Resume container
-  6. Transfer faulted pages

Log Replay
-  용량이 작고 연산시간이 높은 서비스의 경우(딥러닝 모델 학습)
-  지속성 상태(학습된 모델)을 직접 전송하는 편이 효율적
-  용량이 크고 연산시간이 적은 서비스의 경우 (비전 기반 딥러닝 학습을 위한 전처리 작업)
-  지속성 상태를 직접 전송하지 않고, 동일한 연산을 타겟 머신에서 수행하는 것이 효율적
-  도커가 지원하는 logs 명령어를 통해 소스 머신에서의 컨테이너와 동일한 상태를 가지는 컨테이너를 재현하는 방법

@Log Replay
-  1. Extract command logs
-  2. Transfer logs
-  3. Start container in target machine
-  4. Replay logs
-  5. Buffer replay
-  6. Stop container in source machine