14. 서비스 모니터링하기
14.2.2 CPU 사용류
- CPU 사용률에서는 리소스에서 과도한 작업을 수행하는가를 모티터링한다.
- 리눅스 등 서버로 이용되는 OS에서는
14.2.3 메모리 사용률
- 메모리 사용률에서는 리소스에 제공되는 메모리가 많이 쓰이지 않는가를 확인한다.
- 메모리는 리소스가 처리를 실행할 때 이용하는 작업 영역과 같은 것이다.
- 메모리에는 제한이 있으므로, 여유가 없으면 처리가 실행되지 않기 때문에 결과적으로 대기가 발생한다.
14.2.4 디스크 용량
- 디스크 용량에서는 리소스에 연결된 디스크의 빈 용량이 충분한지 확인한다.
14.2.6 리소스별 모니터링 항목
EC2
- 설치된 OS 자체의 관리를 수행해야 하므로 OS나 미들웨어가 원인이 되는 서버 다운이 발생할 가능성이 있다.
- CPU, 메모리, 디스크 등에도 제한이 있으므로 모두 사용하게 될 가능성이 있다.
- 네트워크 트래픽을 제외하고는 모니터링하는 것이 좋다.
가비아, AWS로 도메인 배포하기
[참고링크]
도커는 '데이터 또는 프로그램을 격리시키는' 기능을 제공한다.
- 도커를 한마디로 정의하자면 '데이터 또는 프로그램을 격리시키는 기능'을 제공하는 소프트웨어이며 이 기능은 주로 서버에 사용된다.
- 클라이언트 컴퓨터에서도 사용할 수는 있지만 현 시점에서는 서버에서 사용하는 것이 주 용도이다.
- 개인용 컴퓨터나 서버에는 여러 가지 프로그램이 함께 동작한다.
- 워드, 엑셀, 메일 프로그램
- 서버에도 아파치, MySQL 등 여러 프로그램이 함께 동작한다.
- 도커는 이렇게 다양한 프로그램과 데이터를 각각 독립된 환경에 격리하는 기능을 제공한다.
- 운영체제 통째로 격리하는 기능이다.
다양한 형태로 조합이 가능한 컨테이너
- 도커를 사용할 때의 원칙 중 하나로, 한 컨테이너에 한 프로그램이라는 것이 있다.
- 보안 및 유지 관리 축면에서 유리하기 때문에
- 워드프레스를 사용하려면 아파치(웹 서버 소프트웨어), MySQL 같으 DBMS, 워드프레스로 세가지 소프트웨어가 필요하다.
도커 컨테이너는 '쓰고 버리는' 일회용품
- 컨테이너는 쉽게 만들 수 있고 컨테이너 하나를 업데이트하면서 계속 사용하기보다는 업데이트된 소프트웨어가 들어있는 새로운 컨테이너를 사용하는 것이 좋다.
- 새로운 버전이 나오면 새로운 컨테이너로 갈아타는 것이다.
- 이것이 가능한 이유
- 컨테이너는 일반적으로 여러 개를 동시 가동하는 상황을 전제로 하기 때문에 여러 개의 컨테이너를 하나하나 업데이트하려면 많은 수고가 든다.
- 초기 구축은 간단히 마쳤는데 유지보수 할 때마다 컨테이너를 일일이 업데이트하려니 컨테이너의 장점이 반감된다.
- 유지보수 횟수가 훨씬 많다.
- 오래된 컨테이너를 버리고 새로운 이미지로부터 새로운 컨테이너를 만들어 갈아타는 방식을 사용한다.
01. 쿠버네티스 개요와 클러스터 설치
1.1 쿠버네티스란?
- 쿠버네티스는 대규모 클러스터 환경에서 컨테이너화된 애플리케이션을 자동으로 배포하고 확장, 관리하는데 필요한 여러가지 요소들을 자동화하는 오픈소스 플랫폼이다.
- 개발자가 컨테이너 환경으로 애플리케이션을 만들면 쿠버네티스로 여러 대의 서버로 구성된 클러스터 환경에 해당 프로그램을 편리하고 안정적으로 배포할 수 있다.
- 쿠버네티스는 사용자 부하에 따라 자동으로 애플리케이션과 서버의 규모를 확장할 수 있고, 네트워크, 스토리지, 모니터링 등 시스템 운영에 필수적인 여러 컴포넌트를 편리하게 구축, 관리할 수 있다.
- 데브옵스 혹은 시스템 운영자 관점에서 바라본 쿠버네티스의 가장 큰 특징은 소스코드 기반으로 클러스터를 운영하고 의도한 상태로 클러스터를 관리하는 것이다.
- 쿠버네티스는 기존의 가상 머신 환경처럼 명령어를 이용해 순차적으로 설정을 변경하면서 시스템을 관리하는 것이 아니라 소스코드를 기반으로 클러스터를 관리한다.
- 스토리지를 연결하는 작업은 다음과 같은 코드로 구현한다.
- 시스템 운영자에게 익숙한 mkfs, mount 등의 명령어를 사용하지 않는다.
- 이 같은 다양한 시스템 설정 및 애플리케이션 설치 등 쿠버네티스 환경에서 이뤄지는 모든 작업은 소스코드로 구현한다.
- 모든 작업을 소스코드로 관리하면 여러 이점이 있다.
- 대표적으로 실제 운영 시스템에 적용하기 전에 코드로 구현할 수 있어 개발팀, 데브옵스팀, 보안팀 등 모든 이해관계자가 사전에 충분히 검토할 수 있다.
- 사전 검증 작업으로 장애를 예방하고 애플리케이션 배포 속도를 향상할 수 있다.
- 담당자 모두 동일한 코드를 기준으로 의사소통하므로 이전에 비해 훨씬 효율적이다.
- 기존 환경은 시스템을 구현하기 전에 다같이 검토 가능한 공통의 도구가 없어 의사소통이 쉽지 않다.
- 쿠버네티스는 클러스터를 '의도한 상태'를 기준으로 관리한다.
- 코드 형태로 배포된 클러스터는 최초 의도한 상태와 현재 실행 중인 상태를 쿠버네티스 컨트롤러가 자동으로 끊임없이 확인한다.
- 만약 차이점을 발견하면 현대 상태를 자동으로 처음에 의도한 상태로 변경한다.
- 쿠버네티스는 클러스터의 전체 상태를 지속적으로 확인하면서 문제가 생긴 애플리케이션은 자동으로 재시작한다.
- 시스템의 자원 사용 현황을 모니터링해서 자원 여유가 있는 노드에 애플리케이션을 적절하게 배치하고 필요한 물리 리소스는 자동으로 증가시킨다.
- 탁월한 클러스터 기본 관리 기능을 무료로 사용 가능한 오픈소스로 제공한다.
- 글로벌 환경의 수많은 기업과 조직의 검증을 받았기에 안정성 또한 매우 뛰어나다.
- 쿠버네티스가 발전하고 새로운 선도 기술로 자리잡으면서 쿠버네티스는 단순 클러스터 관리 기능을 넘어서 일종의 데이터센터 운영의 표준이 되고 있다.
- 애플리케이션을 안정적이고 확장 가능하도록 운영하는데 필요한 스토리지, 네트워크, 모니터링 등을 위한 다양한 부가 기능들이 쿠버네티스를 중심으로 발전하고 있다.
- 쿠버네티스는 리눅스 커널처럼 일종의 클라우드 환경의 표준 운영체제가 되어 가고 있다는 언급도 나오고 있다.
- AWS, 마이크로소프트, 구글, 레드햇, 델, HP 등 수많은 벤더들이 쿠버네티스를 기반의 다양한 솔루션을 지원하고 있다.
쿠버네티스 도입
- 먼저 가상 머신 환경이 아닌 컨테이너 기반이라 애플리케이션 자체를 재설계해야 한다.
- 가상 머신을 도입하는 경우에는 물리 머신과 가상 머신이 차이가 없어 개발자가 사용하기에 거부감이 없다.
- 개발자들은 현재 사용 중인 머신이 물리 머신인지 가상 머신인지 구분조차 할 필요가 없다.
- 컨테이너 환경은 애플리케이션을 컨테이너에 맞게 새롭게 배포해야 하는 어려움이 있다.
- 컨테이너 환경의 쿠버네티스는 기존 가상 머신 환경과 몇 가지 기본 철학이 다르다.
- 가상 머신 환경에서는 각 가상 머신마다 이름을 부여하고 문제가 생겼을 때 서버에 접속한 후 설정을 변경해서 문제를 해결했지만 애플리케이션을 실행하는 기본 단위인 파드는 임의의 이름을 지정하고 문제가 발생하면 즉각 새로운 파드로 교체한다.
- 전통적인 운영 관점에서 문제가 발생한 애플리케이션을 수정하지 않고 빠르게 교체한다는 것은 쉽게 납득하기 어려운 문제 해결 방법이다.
- 쿠버네티스를 도입하기 위해서는 초기에 여러 가지 변화가 필요하다.
현 디지털 환경이 가진 과제
- 고객의 요구사항을 빠르고 장애없이 구현하는 것이다.
- 쿠버네티스는 코드로 애플리케이션과 인프라 구성이 가능하다.
- 새로운 프로그램을 이미지를 찍어내듯이 빠르게 확장할 수 있다.
- 애플리케이션 확장과 원복 등 배포와 관련된 다양한 옵션을 제공함으로써 문제가 발생해을 때 빠르게 복구할 수 있다.
- 운영 중인 서비스를 중단하지 않고도 롤링 업데이트 방식으로 새로운 애플리케이션을 배포할 수 있다.
- 기업이 안정적이면서도 빠르게 고객의 요구사항을 수용해야 한다는 양립하기 어려운 과제를 해결하도록 도와준다.
- 온프레미스 또는 클라우드 환경에서도 동일하게 쿠버네티스 기반으로 애플리케이션이 실행된다.
- 서비스 확장 또는 보안 요구사항에 따라 기업은 온프레미스나 멀티 클라우드 환경으로 이동해야 할 때가 많다.
- 쿠버네티스 환경에서 개발한 애플리케이션은 동일한 인터페이스와 개발 환경을 사용해서 확장이 용이하다.
- 기업의 운영환경에 엄청난 장점이다.
- 초기 시스템 구축 비용도 크게 줄일 수 있다.
개발 기록장