티스토리 뷰
요즘 대세는 컨테이너(Container) 환경, 쿠버네티스 클러스터(Kubernetes Cluster), 마이크로서비스(MicroService)
데브옵스(DevOps) 이런 형태로 구체화되는 클라우드 네이티브(Cloud Native) 환경
클라우드 네이티브(Cloud Native) 환경
- 위에서 언급한 클라우드 환경에 쿠버네티스 클러스터 및 MSA 서비스가 올라가고 애플리케이션 올라가는 형태
모놀리식 아키텍쳐 (Monolithic Architecture)
- 마이크로서비스 아키텍처와 상반된 개념으로 마이크로서비스 아키텍처 이전의 전통적인 아키텍처
- 하나의 애플리케이션 뭉쳐져 있음(패키지 형태)
마이크로서비스(MicroService)
- 단일 책임 원칙에 맞추어 잘게 쪼개어진 독립적인 빌드/배포가 가능한 최소 단위 서비스/모듈
- 바운디드 컨텍스트(Bounded Context)의 형태대로 분할이 되어서 모듈별로 쪼갠 형태가 발생
바운디드 컨텍스트(Bounded Context)
- 단일 책임 원칙에 기반한 마이크로서비스를 식별하기 위해 큰 업무부터 작은 업무까지 해당 범위의 경계를 구분해 놓은 것
- 이것을 진행하기 위해 이벤트 스토밍(event storming) 같은 것도 사전에 해서 모듈화를 또 개발 형태대로 구성을 하는 형태
이벤트 스토밍(event storming)
- 이벤트와 브레인스토밍의 합성어로 비즈니스 프로세스에서 발생하는 이벤트를 중심으로 도메인 모델을 설계하는 Domain Driven Design의 가장 효율적인 현장에서의 실천법
과거에는 애플리케이션이 패키지 형태로 구성이 됐다가 갑자기 쪼개지다보니까 마이크로서비스(Microservice) 간에 통신을 하다 보니까 일종의 '메시(Mesh)' 그물망 형태로 메시(Mesh)가 되는 형태가 됨
서비스라든가 애플리케이션단의 복잡도가 굉장히 높아질 수밖에 없는 구성 -> 장애 발생 요소가 굉장히 커지는 요인
요즘에는 쿠버네티스 클러스터(Kubernetes Cluster) 및 컨테이너 환경에서 컨테이너라이징(Containering), 도커라이징(Dockering) 통해서 쿠버네티스 클러스터의 여러 개의 단위 모듈들이 파드(Pod) 형태대로 수십, 수백, 수천개 파드들이 탑재되는 형태로 구성이 되어 있음 -> 복잡도가 과하게 발생 -> 운용하는 쪽도 힘들어지고 개발, 유지보수하는 쪽도 굉장히 힘들어짐
-> 개발과 운영을 어떻게 하면 그런 환경에서 잘 할 수 있을까 고민에서 데브옵스(DevOps)의 태동이 생겼다고 이해하면 됨
마이크로서비스로 쿠버네티스 클러스터 형태로 만들어진 것에 대해 신속, 정확하게 조치 및 개발을 하고 CI/CD 파이프라인
(Pipeline) 통해서 배포하고 해당 체계를 반복적으로 수행하게 하고 싶은 것
-> 장애가 발생하면 안되기 때문에 장애에 어떻게 우리가 대처 및 커버리지할수 있을까 ?
-> 장애를 어떻게 하면 최소화 할 수 있고 장애가 발생했을 때 사람의 수작업이 아니라 스스로 셀프링(selfing)할 수 있는 서비스 , 시스템을 어떻게 만들 수 있을까 고민에서부터 SRE(Site Reliabilty Engineering)가 태동이 됨
-> 그런 환경이 실제 구체화된게 구글에서 처음 SRE(Site Reliabilty Engineering) 컨셉을 발표하고 대외적으로도 공유를 하고 SRE에 대한 관점에 대해서 계속 하나의 일하는 방식, 하나의 기업문화 형태로 드라이브되고 하나의 데브옵스(DevOps), 하나의 핵심 카테고리 형태로 진행을 하고 있는 상태
CI/CD 파이프라인(Pipeline)
- 마이크로서비스 및 다양한 애플리케이션을 대상으로 소스를 빌드하고 배포하는 일련의 과정을 Agile하게 진행할 수 있도록 파이프라인을 구성
쿠버네티스 클러스터(Kubernetes Cluster)
- 마이크로서비스이나 다양한 솔루션/애플리케이션을 담고 있는 여러 컨테이너들의 오케스트레이션(지휘, 통제, 조정) 역할을 담당하는 PaaS 플랫폼
컨테이너라이징(Containering)
- 마이크로서비스 및 다양한 애플리케이션이 컨테이너에서 실행될 수 있도록 적재하는 과정
도커라이징(Dockering)
- 마이크로서비스 및 다양한 애플리케이션이 컨테이너 실행 엔진인 도커(Docker)에서 실행될 수 있도록 적재하는 과정
과거에는 사이트 안정성을 어떻게 관리하였고, 무엇이 문제였을까?
처음엔 플랫폼을 구성을 하고 실제 그 안에서 개발을 하고 데이터 애널리틱스(Data Analytics)하는 데 있어서 부지불식 예상치 못한 버그라든가 장애, 이상 현상들이 수없이 많이 발생됨, 인지를 하고 가는 것도 있고, 인지를 해서 그것에 대한 조치를 하는 경우도 있고 또 인지를 못해서 이것저것 요청을 하다가 쿠버네티스 클러스터 안에서 자연스럽게 회복성을 강화시키는 형태로 진행을 하다보니 자연스럽게 조치가 되는 경우도 있음
가장 어려운 부분이 어떻게 하면 이걸 가시적으로 안정화시키고 조치할 수 있을까 또 문제가 만약에 발생이 되었을때 바로바로 적시에 인지를 해서 어떻게 하면 빨리 조치할 수 있느냐 측면에서 어려움이 있음
쿠버네티스 클러스터 환경에서 운영을 하다보면 인지가 어려운 부분이 되게 많음
어떻게 빨리 인지를 하고 조치를 하는 것에 대한 어려움은 있지만 SRE 관점에서 활동을 통해서 좀 더 빠르게 인지하고 빨리 조치하고 사이트 '안정성' 및 '신뢰성'을 극대화하는 활동
데이터 애널리틱스(Data Analytics)
- 문제나 가설 정의-관련 데이터 수집-데이터 정제 및 탐색-데이터 모델링 및 검증-모델 적용의 전체 데이터 분석 프로세스
SRE(Site Reliabilty Engineering)란?
SRE: 사이트 신뢰성을 극대화시키기 위한 활동
온프레미스(on-premise) 및 클라우드(cloud) 환경에서 인프라 엔지니어들이 사이트 아니면 서버, VM에 대한 가용성이라든가 안정성을 극대화하기 위해 여러가지 활동을 해왔음, 그 안에 얼마나 효과적으로 관리하고 장애가 발생되었을 때 장애가 얼마만큼 빠르게 회복되고 또는 빠르게 조치되는냐 판단하고, 이 사이트가 건강하게 유지할 수 있게끔 주어진 여건, 환경, 예산을 통해서 진행
사이트 '건강함'과 '신뢰성'을 극대화하기 위해서 일부러 장애도 주입해보고 약간 이상 현상을 주입해서 이 형태가 잘 유지가 되는지 안 되는지 이걸 계속 모니터링 하고 로깅(logging) 찍어보고, 이상하다 아니다라고 판단할 수 있는 저희 스스로의 어떤 역량을 계속 극대화시키는 활동을 계속 진행함
DevOps와 SRE 차이점은?
데브옵스는 (사내)문화와 그 일하는 방식 측면에서 많이 진행을 했었는데 데브옵스(DevOps)는 상위 개념에서 컨셉츄얼(conceptual) 관점에서 접근했다면 데브옵스(DevOps)에서의 하나의 행동강령 아니면 행동지침 흐름 안에서 SRE가 태동이 됨
데브옵스 안에서는 SRE도 있고 SRE도 하나의 축이고 애자일도 하나의 축이고 코드를 실시간으로 신속하게 배포 및 적용하기 위한
CI/CD 파이프라인도 하나의 축이라고 생각, 결과적으로 데브옵스는 이 전체를 아우르는 형태이고 각각 하위의 버티컬(Vertical) 형태대로 SRE도 있고 그 다음에 CI/CD 파이프라인도 존재하고 애자일도 존재하고 이런 형태가 존재가 됨
SRE는 데브옵스의 하나의 축이고 그 안에서 데브옵스이 다른 축에 있어서는 CI/CD쪽에 국한되어서 실제 코드를 갖다가 애자일하게 반복적으로 계속 어떤 요청이 들어왔을때, 신속 정확하게 CI/CD 파이프라인을 통해서 배포를 하여 실제 고객의 요청이라든가, 마케팅 요청, 어떤 특별한 조치에 대한 부분에 대해서 바로바로 적용할 수 있는 이런 쳬계도 하나의 축이 될 수 있음
전체를 아우르는 애자일한 방법론적인 측면에서도 한 축이 될 수 있음
SRE는 데브옵스 안에서 가장 핵심이 되는 축 중의 하나
As a Service 시대에 SRE가 왜 필요한가
요즘에는 As A Service, As A Platform 다양한 형태대로 서비스가 되고 있음, 고객 또는 소비자들한테 실제 서비스 형태대로 제공이 되는데 중요한 것은 서비스 신뢰성을 어떻게 확보할 수 있느냐 서비스라는 관점에서 봤을 때 특정한 비즈니스 서비스도 존재하고, 특정 플랫폼 서비스도 존재하고 솔루션 관점에서의 서비스도 존재
결과적으로 고객한테 사용할 수 있게 계정을 발급하고 또 환경을 제공하는 형태에서 SRE가 굉장히 필수적인 상황이 될 수 밖에 없고 As a Service 환경에서 고객이 잘 사용할 수 있게 플랫폼 형태대로 서비스가 제공할 때 그 위에서 고객의 데이터 애널리틱스, 별도의 마이크로서비스를 애플리케잇녀 형태대로 탑재를 하건 이런 형태가 됐을 때 정상적으로 잘 유지되고 안정서 있게 서비스가 계속 고객한테 제공이 되는지를 판단할 수 있게 하기 위해서 안정성 있게 서비스가 계속 고객한테 제공이 되는지를 판단할 수 있게 하기 위해서 SRE 활동을 하고 있다.
24시간, 365일 일할 수 있는 상황은 아니고 결과적으로 SRE활동을 통해서 사전 예측 그 다음에 문제가 발생되었을때 자동화된 조치 환경이 될 수 있게 그리고 생플링한 체계 레질리언스(Resilience)한 환경체계를 통해서 사람이 없더라도 자동화될 수 있는 소위 요즘에는 더 큰 주제로 AI Ops
그런 쳬게록 계속 실제 진화 쳬계로 만들어가는 게 중요
As a Service 환경에서 SRE 활동을 통한 AI 옵스(Ops)로 진화하는 고장에서 활동들이 굉장히 중요하고 필수적
AI Ops
- Ops(운영)에 AI 기능을 반영하여 실제 이상 현상이나 징후에 대한 자동화된 탐지, 보고, 조치 등을 특정 운영 인력이 아닌 인공지능에 의해 처리되는 형태
[참고자료]
As a Service 시대의 필수 SRE (상/하편)을 보고 정리한 글입니다.