[Wiki] Container(컨테이너)란? ("WTF is a container" 아티클 번역)

WTF is a container? (번역 포스팅)

본 포스트는 techcrunch.com의 "WTF is a container?"라는 글을 번역한 것입니다. 부족한 번역, 발번역, 또는 그냥 해석이라 보일 수도 있지만, 혹시라도 언어의 장벽에 막혀 어려움을 겪는 분들이 계시다면 조금이나마 도움이 되고자 정리해보았습니다. 오타, 오역 등에 대한 따끔한 지적 부탁드립니다. 감사합니다.

---

컨테이너가 왜 그렇게 중요한지 이해하기 위해서, 물리적인 컨테이너(실제 컨테이너)를 생각해보자. 현대의 shipping industry는 우리가 작은 shipping container size를 "표준화"하였기 때문에 우리가 생각하는대로 잘 돌아가고 있다. 이 표준이 도래하기 전에는 그 어느 무더기 짐이든, 배송을 하는 것은 매우 어렵고 힘든 작업이었다. 예를 들어, 스마트폰과 펼쳐진 팔레트가 함께 실려있고, 트럭에 들어가게 된다면 어떤 난리가 날지 상상해보라. 아시아로부터 스마트폰을 배송하는데 특별한 배를 이용하는 대신, 우리는 단지 그것들을 모두 컨테이너에 넣고, 모든 컨테이너 배에 설비될 것이라는 것을 알아두기만 하면 된다.

소프트웨어 컨테이너 뒤의 약속은 본질적으로 이와 같다. 모든 OS와 소프트웨어(아마 당신의 소프웨어가 필요로 하는 소프트웨어인 의존성 소프트웨어일 수도 있다.)를 포장해서 들고 돌아다니는 대신에, 당신은 단지 당신의 코드와 그 코드의 의존성(dependencies)들을 그 어디에서나 작동하는 컨테이너에 꾸려두기만 하면 된다. 그리고 컨테이너는 일반적으로 꽤 작기 때문에, 당신은 많은 양의 컨테이너들을 하나의 컴퓨터에 꾸려둘 수 있다.

이게 왜 그렇게 중요한 문제일까? 컨테이너가 인기를 얻기 전에는, 소위 "가상 머신"들이 한 대의 서버가 서로 독립적인 여러 개의 다른 애플리케이션을 돌릴 수 있게 하고 싶을 때 모두가 딱 떠올릴 수 있는 기술(go-to technology)이었다. 그 기술은 1세대 클라우드 애플리케이션이 가능하게 만들었다. 만약 당신이 새로운 서버를 각각의 모든 애플리케이션에 적용해야 한다면, 그 대가는 매우 높을 것이다.(손해가 더 클거라는 의미)

그러나, 가상 머신은 OS와 코드를 함께 패키징 하는 방식으로 동작한다. 가상 머신에서 동작하는 OS들은 그들 스스로가 한 서버를 독차지하고 있다고 생각하지만, 실제로는 여러 개의 가상 머신 무리(그 가상 머신들은 그들 자신의 OS를 동작시키고 있고, 서로에 대해서는 모르고 있다.)가 하나의 서버를 공유하고 있는 형태이다. 그 가상 머신들 아래에는 가상 머신들(guest) 각각이 스스로가 세계에서 가장 중요한 존재라고 믿도록 만드는 주 OS(host)가 있다. Guest 가상 머신들은 기본적으로 모방된(emulate)된 서버에서 실행되며 오버 헤드가 많이 발생하고 작업 속도가 느려지게 된다.(하지만 다시 말하자면, 당신이 여러개의 다른 OS를 하나의 같은 서버에 동작하게 할 수 있다는 말이기도 하다.)

컨테이너를 운반하는 이야기의 관점에서(그리고 그것의 터무니 없는 마무리로부터 비유를 가져오기 위해서) 가상 머신들은 커다란 컨테이너 배에 많은 양의 자그마한 수영장을 가진 것과 유사하다. 그리고 그 수영장들은 자신들만의 작고 특수화된 컨테이너 배를 가지고 있는 것이다.

컨테이너는 매우 다른 방식으로 작동한다. 컨테이너는 오로지 애플리케이션과 그 컨테이너가 필요로 하는 라이브러리 그리고 프레임워크 등 만을 포함하기 때문에, 당신은 하나의 host OS에 여러개의 컨테이너를 올릴 수 있다. 이 서버 위에서 동작하는 단 하나의 OS는 host OS이고, 컨테이너는 그 host OS와 직접적으로 소통한다. 이러한 방식은 컨테이너가 작고 오버헤드가 극도로 적을 수 있게 해준다.

가상 머신은 소위 "하이퍼바이저"(hypervisor)를 guest OS와 host OS 사이의 emulate된 층으로서 사용한다. 컨테이너에게는 container engine(그리고 container engine 중에는 현재 Docker Engine이 가장 인기있다.)이라는 것이 이에 rough하게 대응된다.

컨테이너는 오래 전, 리눅스의 핵심 기술이 되었다. 그러나 컨테이너는 여전히 쓰기 어려웠다. Docker는 컨테이너를 쉽게 사용하게 만들겠다는 약속과 함께 시작됐고, 개발자들은 빠르게 그 아이디어를 이해하기 시작했다.(그 아이디어에 동조하기 시작했다.)

컨테이너는 개발자들이, 쉽게 소프트웨어가 어디에 배포되든, 잘 동작할 것이라는 것만 알면 되도록 만들어주었다. 컨테이너는 또, 종종 "microservices"라고 불리는 것을 가능하게 만들었다. 하나의 거대한 monolithic 애플리케이션을 가지는 대신에, microservice는 application을 여러 개의 작은 파로 쪼개고 각 파트들이 서로 대화가 가능하게 만들었다. 이 의미는 서로 다른 팀들이 그들이 그 애플리케이션들이 서로 상호작용하는 방법을 바꾸지 않는 한, 더 쉽게 각기 다른 파트의 애플리케이션에 대해서 일할 수 있도록 했다는 것이고, 그들이 서로에게서 독립적으로 일할 수 있게 했다는 의미이다. 이는 소프트웨어 개발을 더 빠르게 만들었고, 발생 가능한 에러를 테스팅하는 것을 쉽게 만들었다.

이 모든 컨테이너들을 관리하기 위해서는, 당신은 이 컨테이너들을 각기 다른 기기에 push하는데 도움을 주고, 그것들이 정상적으로 작동하는지 확신하게 해주며, 수요가 높아졌을 때, 적은 수의 컨테이너만 더 생성하면 되도록 도와주는 Kubernetes(구글이 본래 개발했다.)와 같은 전문적인 소프트웨어 집합이 필요하다. 그리고 만일 컨테이너들이 서로에 대해서 인지하도록 하고 싶다면, 당신은 여전히 모든 컨테이너마다 IP 주소를 할당해줄 수 있는 가상 네트워크를 설정하는 방법도 필요할 것이다.

컨테이너는 모든 종류의 애플리케이션을 작동할 수 있지만, 컨테이너와 가상 머신이 매우 다르기 때문에 많은 대기업들이 여전히 사용 중인 대다수의 오래된 소프트웨어들은 이런 구조와 호환되지 않는다. 그러나 가상 머신은 이러한 오래된 애플리케이션들을 AWS나 Microsoft Azure와 같은 클라우드 서비스로 옮기는데 도움을 주기에 컨테이너가 가상 머신보다 더 좋다고 하더라도, 가상 머신이 곧바로 사라지지는 않을 것이다.

---

링크 : WTF is a container?