[컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커] 1장. 새로운 인프라 환경이 온다

• on-premise 환경
  • 엔지니어가 개발 환경을 만들어 제공하면 사용자(주로 개발자)가 그에 맞는 도구를 모두 설치해야 했던 환경

→ 이제 고전적인 인프라 환경이 되었음.

→ 이제는 이미 구성된 환경을 사용자가 필요에 따라 선택하고 조합해서 사용할 수 있게 제공되는 서비스로서의 인프라 환경 (IaaS)이 됨.

• agile 방법론
  • 인프라 환경이 빠르게 갖춰지는 만큼, 소프트웨어도 빠르게 개발하고 적용되길 고대하게 되면서 등장.
  : 일정 주기를 정한 다음에, 해당 주기에 맞춰 요구 사항을 만족하는 프로토타입을 만들고, 이를 개선해 나가며 최종 목표에 접근하는 방식.
  • ↔ 폭포수(waterfall) 방법론
    • 계획 단계에서 설계와 환경을 완전히 구비한 후 예정된 목표를 달성해나가는 방식

→ 이런 애자일 방법론의 시대에 맞춰,

사용자가 요구하는 인프라를 즉각 제공하는 주요 기능은 유지하면서,

• 사용자마다 독립적인 환경에서 개발해도 모두 동일한 결과를 얻을 수 있고,
• 개발된 소프트웨어의 성능을 보장하며,
• 인프라의 가용 리소스를 최대한 확보할 수 있는

인프라 환경으로 변화 중.

이제 이런 요구사항을 만족하는 새로운 컨테이너 인프라 환경을 알아보자!

 

1.1 컨테이너 인프라 환경이란

컨테이너를 중심으로 구성된 인프라 환경

• 컨테이너란?
  • 가상화 상태에서 동작하는 프로세스보다 가볍고 빠르게 동작함.
• 하나의 운영체제 커널에서 다른 프로세스에 영향을 받지 않고 독립적으로 실행되는 프로세스 상태.

컨테이너 인프라 환경의 장점을 충분히 이해하기 위해,

개발자가 인프라를 이용해 개발하는 서비스의 설계 부분을 살펴보자.

 

1.1.1 모놀리식 아키텍처

하나의 큰 목적이 있는 서비스, 또는 애플리케이션에 여러 기능이 통합돼 있는 구조.

• 소프트웨어가 하나의 결합된 코드로 구성됨
• 장점
  • 초기 단계에서 설계하기 용이함
  • 개발이 좀 더 단순하고
  • 코드 관리가 간편함
• 단점
  • 수정이 많을 경우, 어떤 서비스에서 이뤄진 수정이 연관된 다른 서비스에 영향을 미칠 가능성이 커짐
  • 서비스가 커질수록 단순했던 서비스 간의 관계가 매우 복잡해질 수 있음.
  ⇒ 마이크로 서비스 아키텍처의 등장

• 이처럼 뉴스, 카페, 웹툰, 결제 등의 서비스가 하나의 애플리케이션 안에 포함된 경우.
• 장점
  • 보안이나 데이터베이스 접속 등의 설정을 공통으로 사용하며 서비스를 구현하면, 개발 속도는 매우 빠를 것.
• 단점
  • 웹툰 서비스의 사용량이 증가해 서버를 증설해야하면, IaaS 덕분에 사용량 증가에 따라 인프라를 증설하는 것은 어렵지 않음.
  • 하지만, 웹툰 서비스의 사용량이 늘었다고 뉴스, 블로그 등의 다른 서비스가 포함된 애플리케이션까지 확장하는 것은 비효율적.
  • 또, 특정 서비스를 수정하는 과정에서 예기치 못한 에러가 발생하면, 해당 서비스 외에 전체 서비스를 이용할 수 없는 상황이 생길 수 있음.

 

1.1.2 마이크로 서비스 아키텍처

개별 기능을 하는 작은 서비스를 각각 개발해서 연결함.

• 보안, 인증 등과 관련된 기능이 독립된 서비스를 구성하고 있으며, 다른 서비스들도 독립적으로 동작할 수 있는 완결된 구조.
• 장점
  • 개발된 서비스를 재사용하기 쉬움
  • 향후 서비스가 변경됐을 때 다른 서비스에 영향을 미칠 가능성이 줄어듦
  • 사용량의 변화에 따라 특정 서비스만 확장할 수 있음.
  → 사용자의 요구 사항에 따라 가용성을 즉각적으로 확보해야 하는 IaaS 환경에 적합.
• 단점
  • monolithic 아키텍처보다 복잡도가 높음.
  • 각 서비스가 서로 유기적으로 통신하는 구조로 설계되기 때문에, 네트워크를 통한 호출 횟수가 증가해 성능에 영향을 줄 수 있음.

→ 하나의 애플리케이션 안에 포함돼 있던 뉴스, 블로그, 웹툰 서비스가

각 서비스와 관련된 기능과 데이터베이스를 독립적으로 가지는 구조.

• 각 서비스는, API 게이트웨이와 REST API를 이용한 통신 방식으로 사용자(외부)의 요청을 전달함.
• 서비스 개수는 고정된 것이 아니기 때문에, 어떤 서비스가 등록돼 있는지 파악하기 위해 서비스 디스커버리를 사용함.
• 수많은 서비스의 내부 통신을 이벤트로 일원화하고, 이를 효과적으로 관리하기 위해 별도의 이벤트 버스를 서비스로 구성함.

⇒ 각 서비스는 필요한 기능이 특화된 데이터베이스를 선택해 개별 서비스에 할당할 수 있게 됨.

⇒ 고객의 요구 사항에 따라 분석 서비스를 새로 추가해야 할 때도 기존에 있는 이벤트 버스에 바로 연결하면 되므로 매우 유연하게 대응할 수 있음.

⇒ 각 서비스는 독립적으로 동작할 수 있는 완결된 구조라서, 이미 개발된 기능이 다른 서비스에 필요하다면 바로 재사용할 수 있음.

 

1.1.3 컨테이너 인프라 환경에 적합한 아키텍처

그러면 컨테이너 인프라 환경에서는 어떤 아키텍처를 사용해야 좋을까?

과거와 달리 현재는, 작은 단위로 빠르게 배포할 수 있으며 시스템 확장에 유연하게 대처할 수 있는 기반 기술이 충분히 마련돼 있기 때문에,

중소기업에서의 소규모 프로젝트는 모놀리식 아키텍처로 구현을 시작하고, 시스템이 성장하고 기능이 늘어나면 마이크로서비스 아키텍처로 전환하는 것을 선호하는 경향이 있음.

하지만 소규모 프로젝트라도 마이크로서비스 아키텍처로 설계하면

• 기능에 집중한 안정적인 서비스를 구현할 수 있고
• 구현된 서비스를 재사용할 수 있으며,
• 해당 서비스를 다른 서비스와 연결해 구조화하기 때문에 장기적으로 볼 때 유지보수 측면에서 매우 유리함.
• 컨테이너 인프라 환경
  • 마이크로서비스 아키텍처로 구현하기 적합함.
  • 컨테이너를 서비스 단위로 포장해, 손쉽게 배포하고 확장할 수 있음.
  • 컨테이너는 마이크로서비스 아키텍처의 서비스와 1:1로 완벽하게 대응함
  • 또 이후 소개할 도구들을 이용하면 도입 , 설계 , 운용 비용이 감소하고 생산성이 향상됨

→ 그럼 컨테이너 인프라 환경을 지원하는 도구 중 현업에서 자주 사용하는 몇 가지를 간략하게 살펴보자!

 

1.2 컨테이너 인프라 환경을 지원하는 도구

컨테이너 인프라 환경은 크게

• 컨테이너
• 컨테이너 관리
• 개발 환경 구성 및 배포 자동화
• 모니터링

으로 구성됨.

→ 이를 지원하는 도구 가운데 업계에서 가장 많이 사용하는 도구 몇 가지를 알아보자.

 

1.2.1 도커 (Docker)

컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들고, 관리하는 것을 도와주는 컨테이너 도구

• 운영체제 환경에 관계없이 독립적인 환경에서 일관된 결과를 보장함.
• 현업에서 가장 많이 사용하는 컨테이너 도구!
  • 이외의 컨테이너 도구 : 테이너디 (Containerd), 크라이오 (CI-O), 파드맨 (Podnan) 등

 

1.2.2 쿠버네티스 (Kubernetes)

다수의 컨테이너(이 책에서는 도커)를 관리하는데 사용함.

• 컨테이너의
  1. 자동 배포와,
  2. 배포된 컨테이너에 대한 동작 보증,
  3. 부하에 따른 동적 확장
  등의 기능을 제공.
• 처음에는 다수의 컨테이너만 관리하는 도구였지만, 지금은 컨테이너 인프라의 필요한 기능을 통합하고 관리하는 솔루션으로 발전함.
• 컨테이너 인프라를 기반으로 API 게이트웨이, 서비스 디스커버리, 이벤트 버스, 인증 및 결제 등의 다양한 서비스를 효율적으로 관리할 수 있는 환경을 제공하고 이를 내외부와 유연하게 연결해 줌.
• 급격한 상승세를 보이고 있는 컨테이너 관리 도구.
  • 이 외의 컨테이너 관리 도구: 도커 스웜 (Docker Swar), 메소스 (Mesxs), 노마드(Nonad) 등

 

1.2.3 젠킨스 (Jenkins)

지속적 통합 (CI, Continuous integration)과 지속적 배포 (CD, Continuous Deployment)를 지원

• CICD
  • 개발한 프로그램의 빌드, 테스트, 패키지화, 배포 단계를 모두 자동화해 개발 단계를 표준화함.
  • 개발된 코드의 빠른 적용과 효과적인 관리를 통해 개발 생산성을 높임.

→ 즉, 컨테이너 인프라 환경처럼 단일 기능을 빠르게 개발해 적용해야 하는 환경에 매우 적합한 도구!

• 이 외의 CICD 도구: 뱀부 (Bamboo), 깃허브 액션 (Github Action), 팀시티 (Teancity) 등

 

1.2.4 프로메테우스와 그라파나

모니터링을 위한 도구

• 프로메테우스 : 상태 데이터를 수집
• 그라파나 : 프로메테우스로 수집한 데이터를 관리자가 보기 좋게 시각화함.

→ 프로메테우스와 그라파나는, 컨테이너로 패키징돼 동작하며,

최소한의 자원으로 쿠버네테스 클러스터의 상태를 시각적으로 표현함.

컨테이너 인프라 환경에서는, 중앙 모니터링이 필요함.

→ 많은 종류의 소규모 기능이 각각 나누어 개발되기 때문.

⇒ 프로메테우스와 그라파나의 조합이, 효율적으로 모니터링 하는 방법 중 하나.

• 프로메테우스 외의 모니터링 데이터 수집 도구→ 하지만 오픈 소스를 활용하는 기업은 프로메테우스 외 다른 선택지가 없을 정도로 탁월한 효율을 자랑함.
• : 데이터독 (DataDog), 인플럭스 DB(InfluxDB), 뉴 렐릭 (New Relic) 등
• 그라파나 외의 데이터 시각화 도구→ 업계에서는 그라파나와 키바나가 시장을 양분한 상태.
• 하지만, 프로메테우스를 사용할 때 그라파나가 더 간결하게 구성할 수 있어서 선호함.
• : 키바나 (Kibana), 크로노그래프 (Chronogral) 등

 

1.3 새로운 인프라 환경의 시작

• 책 소개
  • 앞서 소개한 다섯 가지 도구로 실제 컨테이너 인프라 환경을 구성해 보면서, 새로운 인프라 환경을 이해하고 실무에서 응용할 수 있도록 구성됨.
  • 목차3장 - 쿠버네티스의 개념과 여러 기능을 알아보고 실제로 어떻게 구현하는지5장 - 컨테이너 인프라 환경에서 CICD 실습
  • 6장 - 복잡한 컨테이너 인프라 환경을 효율적으로 관리하는 모니터링 방법 제시
  • 4장 - 쿠버네티스가 관리하는 컨테이너를 집중적으로 살펴보기
  • 2장 - 버추얼 박스와 게스트 운영체제(CentOS)로 가상화 인프라 환경 구성

→ 그러면 실습에 필요한 가상 환경을 구축하는 것부터 시작해 보자!