오늘은 8월 19일 진행되었던 컨테이너 서비스에 대한 8월 정기 웨비나를 들으면서 워드에 정리한 글이다.
꾸준히 웨비나를 듣는 이유는
정말 이해가 잘가도록 설명을 잘해주시기도 하고, 보통 솔루션즈아키텍트분들이 웨비나를 해주시는데, 어떤 일을 하시는지 어떤 사고를 길러야하는지 엿볼 수 있고 SA분들이 어떤 자료를, 어떤 이슈를 보고 계시는지 가끔씩 들을 수 있는 기회가 돼서 좋다. 그래서 이메일로 오는 다음 웨비나를 계속 등록하게 되는 것 같다 ^^..개강하면 자주 듣진 못하겠지만 ㅠ.ㅠ
"컨테이너 오케스트레이션이 필요한 이유"
서비스 작게 시작 -> 트래픽 폭증 (다수의 호스트, 셀 수 없는 컨테이너 개수 정도로 성장)
수작업 매우 힘듦, 운영 오버헤드 발생, 인적 부재시 시스템 이슈 발생 : 중앙에서 센트릭하게 오케스트레이션 하는 툴 필요
컨테이너 오케스트레이션이란?
: 오케스트라의 지휘자처럼 중앙에서 각각의 컨테이너에게 기대되는 동작, 상태를 유지할 수 있도록 중앙에서 지휘, 제어 하는 것
=> 고객의 워크로드, 운영팀의 규모, 러닝커브 등의 기준으로 적정 기술을 선택
- 사용자가 원하는 상태의 기준에 따라 컨테이너를 스케쥴링 하는 것
- 컨테이너를 구성하기 위해 로우레벨로 클러스터를 만들어야함
- 컨테이너간의 통신이 필요한 경우 -> 컨테이너 클러스터 안의 컨테이너끼리 통신하려면 서비스 위치를 알기위해 서비스 디스커버리가 필요함
- 컨테이너플립도 프로세스이기 때문에 로깅하고 모니터링하고 있다가 문제가 생기면 적절한 대처를 해야함
- 어떻게 동작하면 좋을지 json, yaml 포맷등으로 정의서를 작성함
- 컨테이너 오케스트레이터는 작성한 정의서를 읽어들여서 정의대로 스케쥴링함
- 오케스트레이션 계층: 기본적인 리소스를 포괄하고 앱 및 서비스를 관리하는 추상화를 제공
하나의 환경처럼 추상화 해놓음
Service Management
- Availability
- Lifecycle
- Discovery
Scheduling
- Placement
- Scaling
- Upgrades
- Rollbacks
Resource Management
- Memory
- CPU
- Ports
클러스터를 직접 관리할 필요없이 ECS, EKS 사용하면 된다.
물리적인 호스트가 클러스터링 되어야함 : EC2를 호스팅환경으로 하고 있는 ECS, EKS
Fargate기반의 ECS, EKS
- 앱매쉬 : 코드변경 없이 서비스들간에 마이크로하게 분산된 서비스들간에 통신과 모니터링 제어
- 클라우드맵: 분산된 서비스들의 호출할 수 있는 위치 확인
- 모니터링: 아마존 클라우드와치, 액스레이
직접 관리해야할 관리포인트가 생김: ECS Agent, Docker Agent ,…
Fargate 는 할 필요없음
: 호스트를 관리할 필요 없음, 서버리스 처럼 운영
관리 불필요 -> 탄력성 증가
컨테이너가 늘어나야되는 상황이 되면 fargate가 늘려줌
이미지 스캐닝이 지원되는 것이 장점
컨테이너 오케스트레이션 툴 : ECS -> 컨테이너 확장하게 도와줌
핵심 구성요소: 스케쥴러와 오케스트레이션
ECS VS EKS
: 어떤 게 좋은지 use case마다 다름
- 태스크 배치 결정과정
- 빈패킹 -> 메모리를 최대한 한쪽에 모아서 효율적으로 사용할 수 있도록
- 스프레드 -> 한 노드에 테스크가 몰리지 않게 골고루 배치
- 어피니티(친화성) -> 특정 컨테이너나 이미지, 특정 라벨이 붙은 노드로 배치
- 디스턴트 인스턴스 -> 각자 다른 노드에 하나씩 배치
- 기본은 스프레드!
- 최소, 최대 지켜져야하는 테스크의 개수지정
- 클라우드 와치로그를 사용하면 다양한 서비스를 전송할 수 있음
- 다른 서비스들로 로그들을 라우팅하면 로그들을 바탕으로 부가가치 만들 수 있음
사용자 로그를 바탕으로 유의미한 인사이트 도출
