ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 01. 도커와 쿠버네티스 시작하기
    개발 스터디/데브옵스(DevOps)를 위한 쿠버네티스 마스터 2021. 6. 22. 22:32
    반응형

    이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크

    파트1에서는 왜 쿠버네티스가 현재 인프라 운영 기술의 표준이 되었는지에 대한 설명을 다룬다. 쿠버네티스의 기초가 되는 컨테이너, 도커를 살짝 훑으면서 MSA 성공 사례까지 공부할 수 있다.

    쿠버네티스 이전 아키텍처

    모놀리틱 아키텍처

    전통적인 온프레미스 기반의 "모놀리틱 아키텍처"는 다음과 같이 구성되어 있다.

    쉽게 생각해서, 여러 서비스가 하나의 애플리케이션으로 동작하는 형태이다. 이 경우, 초기 개발 속도를 올려주지만, 애플리케이션이 커지면 커질수록 개발/운영/유지 보수 등이 점점 어려워지는 여러 문제들이 있었다. 첫 번째로는 "스케일 아웃(scale out)" 시 불 필요한 리소스 복제가 일어났다.

    다음과 같이 더 많은 유저 서비스가 필요한 상황에서, 하나의 애플리케이션 형태로 배포되기 때문에, 불필요한 채팅, 게시글 서비스가 같이 복제되는 문제가 있었다. 한 마디로 리소스가 최적화되지 않은 상태로 스케일 아웃이 되어야만 했다. 두 번째로는 "라이브러리 충돌" 문제이다.

    위 그림에서, 유저 서비스는 라이브러리 A 1.0 버전을, 채팅 서비스는 라이브러리 A 1.5 버전을 사용하고 있다. 하위 버전과 호환이 잘된다면 문제가 전혀 없겠지만, 호환이 깨졌다면, 이는 심각한 버그를 일으키곤 했다. 따라서 라이브러리 충돌을 해결하는 기술들이 필요했다. 세 번째로는 "빌드/배포"의 어려움이 있다.

    세 팀 중 유저 서비스를 개발하는 팀이 소스 코드 변경을 할 경우, 모든 팀들이 모여 각 서비스들이 정상적으로 운영되는지 빌드/배포 후 테스트까지 진행해야 했다.

     

    가장 큰 문제는 조그만 코드 변경에도 이러한 작업을 진행해야 한다는데 있다. 서비스가 커지면 커질수록 빌드/배포의 속도는 저하될 수 밖에 없고 테스트는 매우 어려워진다. 이는 서비스 개발 속도를 저하시키는 큰 요인이 되었다.

    마이크로 서비스 아키텍처

    위 문제를 해결하기 위해서 서비스 개발 단위로 묶는 "마이크로 서비스 아키텍처(이하 MSA)"가 나타나게 되었다.

    위 그림처럼, 각각 서비스마다 애플리케이션을 만들어서 배포하는 구조이다. 이렇게 하면 위에서 언급했던 문제들을 해결할 수 있었다.

    먼저 서비스 별로 애플리케이션이 배포되었기 때문에, 보다 효율적으로 스케일 아웃이 가능해졌다.

    또한, 각 애플리케이션은 서로 분리된 환경에서 배포되었기 때문에, 라이브러리 충돌도 사라진다.

    그리고 각 팀별로 빌드/배포/테스트가 진행할 수 있기 때문에 더 빠르고 많이 애플리케이션을 배포할 수 있게 되었다. 이런 만능 도구처럼 보이는 MSA도 여러 단점이 있다. 그 중에서도 손꼽히는게 문제점은 다음과 같다.

    1. 엄청나게 복잡한 분산 트랜잭션에 대한 처리
    2. 더 많이, 더 자주, 변경되는 동적 인프라스트럭처에 대한 관리

    쿠버네티스는 빈번하게 변경되는 동적 인프라스트럭처를 보다 안전하고 쉽게 관리할 수 있게 도와주는 도구이다. 강좌에서는 분산 트랜잭션 처리도 가능하다는데, 이는 강의를 진행하면서 알아보도록 해야겠다.

    컨테이너, 도커, 쿠버네티스

    이제 MSA를 보다 더 쉽게 구성할 수 있는 기술인 쿠버네티스를 살펴보기 전에, 쿠버네티스를 이루고 있는 주요 기술인 컨테이너와 쿠버네티스의 주요 관리 대상인 도커도 함께 알아보자.

    컨테이너

    컨테이너란, 환경을 격리하는 기술을 뜻한다. 다음은 전통적인 배포 구조부터, 컨테이너 배포 구조의 발전 과정을 나타내는 그림이다.

    전통적인 배포 구조에서는 격리 기술이 따로 없었고 라이브러리 충돌이 매우 빈번하게 일어났다.

     

    이에 대한 해결책으로, VM 환경 배포 구조가 나왔다. VM은 아쉽게도, 라이브러리/코드는 물론 OS까지 구현해야 했기에 매우 무거웠다. 이는 CPU 리소스를 엄청나게 잡았기 때문에 서비스가 커지면 커질수록 점점 사용하기 어려워졌다.

     

    VM을 대체하기 위해서 컨테이너 배포 구조가 만들어지게 되었다. 도커(Docker) 등의 컨테이너( 런타임) 기술들은 리눅스 namespace와 cgroup 기술을 통해서, 가벼우면서도 완전히 격리된 환경을 만들 수 있게 도와주었다. 참고로 컨테이너 배포 구조는 기존 네이티브 환경에 비해 1% 정도의 리소스 손실만 일어날 뿐 아주 가볍고 빠르게 동작이 가능하다고 한다.

    도커

    도커는 여러 개의 컨테이너를 관리하는 오픈 소스 기술이다. 유식한 말로는 컨테이너 런타임 기술.

    사실 상, 컨테이너 관리하는 기술 중 표준이라고 볼 수 있다. 주요 용어 두개만 정리하고 가자.

    • 이미지 : 필요한 프로그램, 라이브러리, 소스를 설치한 뒤 만든 하나의 파일
    • 컨테이너 : 이미지를 독립적으로 격리된 공간에서 실행한 가상 환경

    추후 강의에서 더 자세하게 다룬다.

    쿠버네티스

    이런 컨테이너를 관리하는 기술들도, 서비스가 커지면 커질수록, 컨테이너들도 비례하게 늘어나게 되고 이를 감당하기 어려워진다. 쿠버네티스는 쉽게 말해서 여러 컨테이너 런타임(도커)들을 자동으로 운영할 수 있게 도와주는 도구이다.

    추후 강의에서 보다 깊이 알아보자.

    MSA 성공 사례

    사실, MSA 성공 사례보단, 쿠버네티스 성공 사례를 알려주셨으면 좋았을 텐데... 2018년 당시에는 아직까지는 발표된 성공 사례가 매우 적어서 MSA 성공 사례를 같이 보여주시지 않았을까 싶다. 강사님이 소개해준 MSA 성공 사례는 다음과 같다.

Designed by Tistory.