쿠버네티스 입문자를 위한, 알기쉬운 개념설명(이진현 상무/맨텍, “디지털 플랫폼 전략 수립을 위한 쿠버네티스 실전 활용서” 저자)

 

인터뷰를 통해서 전문가의 관점을 쉬우면서도 구체적으로 끌어내는 고우성의 잇(IT)터뷰입니다.
요즘 대세인 쿠버네티스, 컨테이너 관련된 개념들을 바로 쉽게 이해하고 싶은 분들을 위하여 준비하였습니다. 오케스트레이션(Orchestration)이란 단어가 의미하는 것은 무엇인지, 컨테이너를 얘기할 때 이뮤터블(Immutable), 레이어란 속성은 왜 나오는지, 쿠버네티스의 구성 요소들은 무엇인지, 복구와 보안은 어떻게 되는지 등 여러분들이 평소 궁금해할 만한 내용을 추려보았습니다. “디지털 플랫폼 전략 수립을 위한 쿠버네티스 실전 활용서”의 저자인 맨텍의 이진현 상무와 함께 최대한 쉽게 알아보겠습니다.

 

진행자 : 고우성 PD/토크아이티 (wsko@talkit.tv, https://talkit.tv/)
게스트 : 이진현 상무/맨텍, “디지털 플랫폼 전략 수립을 위한 쿠버네티스 실전 활용서” 저자
쿠버네티스 실전활용서_이진현 저자
디지털 플랫폼 전략 수립을 위한 쿠버네티스 실전 활용서, 이진현 저자

 


 
 

1. 오케스트레이션(Orchestration) vs 오토메이션(Automation)

 

이진현 : 자동화(오토메이션)는 뭔가를 감지해 내고 뭔가를 배포했고 배포와 감지, 여기에 많이 특화되어 있어요. 배포된 애플리케이션과 그다음에 어떤 감지하는 도구가 뭔가를 감지했었을 때 액션을 누가 취해야 하나요?
예를 들어, 아파치 톰캣이랑 데이터베이스라는 걸 내가 배포했어요. 배포는 누군가 자동으로 할 수가 있잖아요. 자동화 도구를 활용하면서 배포할 수 있는데 만약 그 배포된 인프라와 배포된 데이터베이스, 미들웨어에 장애가 생겼다고 보겠습니다. 그리고 감시하는 자동화, 자동화 툴에서 또 감시까지 했어요.
그러자 문제가 발생했어요. 조치는 누가 취합니까?
고우성 : 운영 쪽에서 해야 하는 거 아닙니까?
이진현 : 사람이 와서 조치를 취해야 하죠. 대부분 사람이 와서 조치해야 합니다. 사람 의존적이죠. 그리고 사람이 와서 조치를 취한다는 의미는 좋은 엔지니어가 들어오면 조치가 잘 될 것입니다. 주니어 엔지니어가 들어가서 잘 안되면 시니어가 올 때까지 대기하고 있어야 합니다.
그러니까 품질이 사람에 의해서 좌지우지됩니다. 즉, 완벽한 의미의 자동화는 아닌 거죠.
자동화 관점에서 볼 때 조치에 대한 부분까지 자동화를 해주겠다는 것, 그게 애드온(Add-on)된 것이 오케스트레이션(Orchestration)입니다.
‘장애가 발생했다!’
‘내가 가서 살려줄게.’
해서 가보니까 부하가 걸립니다. 그럼 이것을 또 스케일 아웃을 해야 할 거 아닙니까?
‘그거 내가 자동으로 해줄게.’
이런 개념이 추가로 더 들어갔다고 생각하시면 되겠습니다.

 
 

2. 컨테이너 이미지 vs 컨테이너 런타임

 

이진현 : 우리가 소프트웨어를 본다면 소프트웨어를 이미지로 만든 파일이 ISO잖아요. 그래서 이제 우리가 예를 들어서 ‘윈도우즈 OS를 깐다’고 하게 되면 CD를 가지고 오면, CD 안에 ISO 파일이 있어요.
고우성 : 그렇죠.
이진현 : 그 ISO 파일만 가지고 OS 운영이 되나요?
고우성 : 안되죠. 실행시켜야죠.
이진현 : 그렇죠. 그 패키지를 깔고 윈도우즈 프로그램을 띄워야만 윈도우즈 OS를 쓸 수 있습니다. 오피스(office programs)도 마찬가지고요. 컨테이너도 마찬가지입니다. 컨테이너를 파일 형태로 보관한 것을 우리가 이미지라고 해요. 그리고 이 이미지를 구동해서 메모리에 어떤 이미지를 띄워줘야지만 그 이미지를 우리가 쓸 수가 있잖아요.
고우성 : 그러니까 이미지는 구동의 개념은 없는 거네요.
이진현 : 구동을 시켜요. 그 이미지를 구동시킨 것을 말하는 겁니다. 그걸 런타임이라고 얘기합니다.

 
 

3. 이뮤터블(Immutable), 레이어

 

이진현 : ‘이뮤터블(Immutable)’의 뜻이 뭔가요?
고우성 : ‘변하지 않는’ 아닙니까?
이진현 : ‘불사, 변하지 않는’을 뜻합니다. 한 번 만들어지면 절대 안 변하는, 그냥 쉽게 말하면 ‘Read only’예요. 그냥 ‘Read only’. 스토리지로 따지면 WORM 스토리지(Write Once Read Only) 아시죠? 한번 Write를 해버리면 그다음부터 위변조가 불가능합니다. 즉, 위변조가 불가능한 인프라라고 생각하시면 됩니다.
VM은 어떻습니까? 그다음 물리 서버는 어떻습니까?
OS 안에 들어가서 내가 파일을 마음대로 조작이 가능하잖아요.
고우성 : 그렇죠.
이진현 : 컨테이너는 그게 안 됩니다. 물론 컨테이너를 실행하게 되면 재기록(Rewritable) 할 수 있는 레이어가 생성되면서 거기서 파일도 저장하고 변경할 수 있어요. 대신 내렸다 올리잖아요? 다시 원래의 이미지 형태로 돌아갑니다.
고우성 : 어떻게 보면 컨테이너를 쓰지 않았던 기존 IT 인프라 분에서 근무했던 분들한테는 좀 생소한 개념일 수 있겠네요?
이진현 : 생소한 개념이죠. 그래서 컨테이너를 VM처럼 기대하고 쓰시는 분들 입장에서는 굉장히 불편합니다. 왜냐하면 우리 회사가 옛날에 그랬었어요.
2014년에 컨테이너를 도입했고 저희가 쓰는 패키지가 내부적으로 데이터베이스를 가지고 있어요. 컨테이너 안에 데이터가 다 저장된 거죠. 어느 순간 가보니까 데이터가 사라지고 없는 거예요.
“이거 어떻게 된 거야?”
“디스크가 잘못됐나?”
“스토리지가 잘못됐나?”
그렇게 몰고 갔습니다. 하하.
고우성 : 하하.
이진현 : 컨테이너 특성으로는 도저히 이해 못했던 거죠. 그런데 나중에 컨테이너에는 데이터를 저장하면 안 된다는 것을 알게 된 거예요.
그래서 컨테이너는 내부의 데이터를 저장할 수 없고, 저장된 데이터는 내려갔다 올라오면 다시 리셋이 되고 원래 이뮤터블한, 원래 그 무결한 이미지 형태로 돌아갑니다.
그러면 이 데이터를 어떻게 될까요?
그래서 이제 퍼시스턴트 볼륨(Persistent Volume)이라고 해서 영구 볼륨이라는 걸 만들어서 붙여줘야 합니다. 그 데이터는 외부에 저장하기 때문입니다.
‘이뮤터블(Immutable)’이라는 특징 자체가 완전무결한, 누구나 조작하더라도 다시금 되돌릴 수 있는 그런 환경을 말합니다. VM 같은 것을 한번 조작해 버리면 되돌리려면 어떻게 합니까?
백업본(backup copy)을 가져다가 Reinstall을 해요. 그런데데 백업본(backup copy)을 가져다가 Reinstall을 하니까 백업본도 이미 조작된 것입니다. 랜섬웨어 공격이 대표적이잖아요. 하하.
고우성 : 하하.
이진현 : 그래서 뭐 하이퍼바이저 벤더들이 하이퍼바이저는 랜섬웨어 오염 안 된다고 하는데, 하이퍼바이저 자체가 오염이 되어 VM을 못 띄우는 사람들이 대단히 많거든요.
VM 같은 경우는 조작될 위험성이 매우 큽니다. 근데 컨테이너의 경우, 누군가 와서 조작하더라도 다시 원래 이미지를 가져와서 다시 살릴 수가 있습니다. 원래 그 이뮤터블(Immutable) 이미지를 가져와서요. 그래서 ‘이뮤터블(Immutable)’ 이라고 이야기하게 됩니다.
그러면 내가 뭔가를 더 애드온(Add-on)해서 하려면 뭘 어떻게 해야 하느냐? 레이어 구조라는 특징이 있어요. 그래서 하나의 이미지를 만든 그 레이어는 Read Only입니다.
고우성 : 아, 거기에 한 레이어를 더 쌓는군요?
이진현 : 더 만들어 쌓으면 돼요. 쌓고 그것을 이미지로 만들면 됩니다.
고우성 : 그래서 이미지들이 엄청 많은 거군요? 다양한 이미지들이요.
이진현 : 이제 이미지를 계속 만듭니다. 대신 레이어를 쌓게 되면, 예를 들어 ABC라는 레이어가 하나 있어요. 위에 D라는 레이어를 하나 더 만들어 쌓았어요.
즉, 기존에 ABC라는 레이어가 하나 있고, ABCD 레이어로 컨테이너 이미지를 또 만들었어요.
그러면 파일이 ABC는 1MB, ABCD는 1.2MB라면 디스크에 남는 것은 총 2.2MB가 될 수 있잖아요?
그런데 그렇게 안 남습니다. 원래 이미지에 위에 레이어가 하나 더 추가된 것이기 때문에 ‘추가된 증분에 대해서만 용량이 더 증가’합니다. 바로 이런 특징이 있습니다.
고우성 : 그런 것들이 잘만 쓰면 애자일한 운영을 할 때, 개발할 때 도움 되겠네요.
이진현 : 컨테이너 장점은 뭔가 잘못됐다 싶으면 원래 이미지로 되돌릴 수 있는 원래 변경이 안 된 상태로 만드는 그럼 장점이 있습니다. 그래서 나중에 롤백(Rollback)하기도 굉장히 쉽죠.

 
 

4. 쿠버네티스 내재화 왜 어려운가?

 

이진현 : 실질적으로 쿠버네티스 내재화를 시행했던 회사들도 꽤 있습니다. 성공한 회사도 있지만 실패한 회사도 있습니다. 가장 좋은 것은 내재화하는 것이죠. 그런데 내재화를 하기에는 너무 많은 인력이 필요하고 너무 많은 기관과 관리 이슈들이 존재합니다.
제가 책에서도 표현했는데 친구가 생일이에요. 그럼 주로 이제 케이크를 많이 선물하시죠. 그 케이크를 만들어 줄 수도 있잖아요.
*쿠버네티스 (k8s, Kubernetes, 큐브, kube) : 컨테이너화된 애플리케이션을 배포, 관리 및 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼
고우성 : 케이크를요? 하하.
이진현 : 네, 나만의 케이크를 정성스럽게 만들어 줄 수 있죠.
고우성 : 제가 만약 젊다면 애인한테 그렇게 해줄 수도 있어요. 점수 따려고요. 그런데 지금은 그렇게 안 하죠. 하하.
이진현 : 네, 지금 그렇게 안 합니다. 왜요? 사서 제공해주는 게 더 싸고요.
고우성 : 그것보다 더 좋은 건 기프티콘이죠. 하하.
이진현 : 그렇죠. 기프티콘은 내가 원하는 것으로 바꿀 수도 있고요.
케이크를 직접 만든다면 만드는 정성이 있지만 근본적으로 맛이 없습니다. 하하.
평생 살아봐야 케이크를 몇 개나 만들겠습니까? 그러다 보면 만들다가 케이크를 태우는 경우가 많고요. 비용도 많이 듭니다. 정말 많이 듭니다.
그래서 사서 선물하는 케이크가 맛도 좋습니다. 한편, 기프티콘을 주게 되면 다른 것으로 적용할 수도 있습니다. 이런 이유로 대부분 케이크를 사다 주잖아요.
내재화도 마찬가지입니다. 내재화를 해서 유리한 조직이 있지만 이런 툴들을 도입해서 운영하는 게 비용적으로 훨씬 더 싼 경우가 많아요. 특히 쿠버네티스 같은 경우는 일반적으로 이런 툴을 도입하는 게 많이 쌉니다.
왜일까요? 쿠버네티스 자체가 릴리즈가 굉장히 잦습니다. 삼개월에 한 번씩 릴리즈가 됩니다. 그리고 End of Life(EOS)라고 하죠. 단종 주기가 아주 짧습니다.
일반적으로 우리가 하는 상용소프트 같은 경우는 단종 주기가 보통 5년, 6년을 가잖아요. 그리고 웬만한 오픈 소스도 비용을 지불하면 한 2년 정도 유지 관리를 해준단 말입니다.
쿠버네티스는 단종 주기가 딱 9개월입니다. 우리는 쿠버네티스 기반으로 궁극적으로 PaaS를 구축합니다. 쿠버네티스만 있는 게 아니란 말이에요. 쿠버네티스 위에 여러 가지 요소들을 얹어야 됩니다. 에코 솔루션을 가져옵니다. 20에서 40여 종류, 많게는 80여 종의 에코 솔루션들, CICD, 로깅, 모니터링 관리 포털,
그다음에 통합인증 등 이런 오픈소스를 다 가져와서 레이어를 쌓아나가야 하는 겁니다. 그러면 이런 것들도 다 알아야 합니다. 중간에 Integration 해야 합니다. 사실, 이런 플랫폼 구축하는 데 1년이 걸립니다.
1년 걸려서 플랫폼을 출시했는데, 내가 사용한 쿠버네티스가 단종 돼요. 하하. 그래서 쿠버네티스를 업데이트하려고 해요. 업데이트하려니까 앞에 있는 에코 솔루션들과 호환성 문제가 발생하는 거죠.
고우성 : 또 충돌이 나는 거죠.
이진현 : 네. 갑자기 어떤 오픈소스가 사라지고 또 어떤 걸로 보니까 로깅을 elastic으로 해놨더니만 이번에는 라이선스를 바꿔버렸네요? 상용으로도 이게 갑자기 사용할 수 없는 이런 일도 발생하고 이런 문제가 계속 생깁니다. 이런 것들을 컴플라이언스까지 우리가 생각해서 유지 관리하기가 쉽지 않다는 것입니다.

 


영상으로 시청하기!


◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.