[용어] MSA, DevOps, SRE 기초개념 + 연관관계

Microservice

- 기존 모놀리틱 구조에서 모든 도메인과 기능이 하나의 시스템에 담겨있고 서비스가 방대해짐에 따라 복잡성이 커졌다.

- Microservice는 기존 모놀리틱 구조에서 방대한 시스템을 적절하게 나눈 구조로 설명된다.

- 'API Gateway'를 두고 기능별/도메인별로 요청이 '분기'하도록 구성된다.

 

특징

[장점]

- 기존 모놀리틱 구조에서는 장애 발생 시 서비스 전체가 마비될 것이다. Microservice는 분리한 서비스 단위로 배포가 가능하기 때문에 자유롭게, 가볍게 배포가 가능하며 확장도 용이하다.(서비스 간 의존도가 떨어지기 때문)

- 애플리케이션 재기동 시간이 크게 단축된다. (보통 모놀리틱은 한번 빌드하는데 엄청난 시간이 소요)

- 다른 서비스와는 API로 연동되기 때문에 유지보수가 쉬워진다.(다른 쪽 코드를 볼 일이 없음). 또한 API로 연동되기 때문에 서비스는 각 특징에 맞는 기술을 사용할 수 있다. 예를들어 여러 가지의 프로그래밍 언어를 사용하는 Polyglot과 같이 각 서비스의 요구사항에 최적화된 프로그래밍 언어, 프레임워크 등을 달리 가져갈 수 있다.

- 배포 단위도 작아지고 소요 시간도 작아진다. 그리고 장애 발생 시에도 해당 서비스 부분만 개선하면 된다. 예를 들어 리그오브레전드 클라이언트는 상점과 채팅 등 서비스가 분리되어 있고 상점 서버가 마비되더라도 로그인, 채팅 서비스 이용 등은 가능한 이유가 MSA로 설계되었기 때문이다.

- 기업에서도 서비스 단위로 팀이 구성될 수 있는데, 이러한 구조를 가지게 될 경우 "기능 개발부터 운영, 인프라, 아키텍처 등 까지 하나의 팀 안에서 해결 가능하다." 즉, 개발과 운영을 같이 하게 된다는 관점에서 DevOps가 설명된다. 여기서 구성된 작은 팀 단위로 agile 문화를 적용한다면 요구사항 선제 대응이 더욱 수월해진다.

 

[단점]

- 서비스들 간 통신에서 실패 처리를 위한 방법 중 널리 사용되는 것이 궁극적 일관성(eventual consistency) 기반의 Saga Pattern이 있지만 이는 애플리케이션 레벨에서 보상 트랜잭션을 개발자가 직접 구현해야 하는 문제점이 있다. 즉, 분산 환경에서 데이터 일관성을 맞추기 위해 오히려 코드 양은 더 늘고 복잡해진다. 

- 서비스 간 매시를 이루기 위한 솔루션, 각 서비스를 제어할 오케스트레이션 툴, 서비스 간 분산된 모니터링 등 분산 환경에 필요한 다양한 기술을 배워야 한다.

- 위 장점에서 말한 특징 중, 다른 서비스와의 API로 연동한다는점과 배포 단위가 작아진다는 점은 오히려 유지보수를 복잡하게 만들 수 있다.(DevOps가 제대로 구비되어있지 않은 경우)

- 적절한 설계가 뒷받침 되어있지 않은 경우 서비스 간 의존성이 커지고 더 복잡해진다.

- 디버깅이 어려워진다. 다른 서비스로 넘어간 데이터가 어떻게 처리돼서 넘어오는지 디버깅할 수 없다. 즉, 통합 테스트 소요 시간이 증가된다.

- 관리해야 할 API가 많아지며 만약 API를 수정해야 한다면 이와 연관된 모든 서비스에서도 수정이 발생한다.

- 괜히 MSA를 적용했다가 관리비용이 늘어날 수도 있다. 서비스 규모도 크지 않고 트래픽이 많지도 않은데 굳이 MSA로 구축했다가 놀고 있는 서버들이 많아질 수도 있다.

 

+) Microservice와 Docker

- 분리된 서비스 모듈 각각을 도커 이미지로 관리할 수 있다.

- VM이 아닌 이미지로 관리되기 때문에 이미지들을 늘리는 방식으로 쉽게 서비스를 확장할 수 있다.

 

 

DevOps

[등장 배경]

과거의 개발과 운영 직무는 단절되어 있었으며 개발자가 개발하면 운영자는 이를 기반으로 운영역할을 하는데 운영자는 안정성을 최우선시하고 개발자는 신규 요구사항 및 기능에 개발하는 것을 최우선시했다. 이러한 구조는 개발자는 운영 관행에 대한 이해가 많지 않고 운영자는 코드 기반의 이해가 부족한 경우가 대부분이었다. 이러한 불일치는 조직 내에서 문제를 야기하는데, 예를들어 개발 내용이 운영자 입장에선 안정성을 위해 "천천히(느리게)" 움직여질 수밖에 없다. DevOps는 이러한 운영자 및 개발자의 장벽을 허물고 서로 간의 이기주의를 탈피하기 위해 설계된 일련의 관행이라고 볼 수 있다.

 

[목적]

개발자를 비롯한 조직의 팀원 간 효율적인 협업을 통해 '최대한 빠르게(민첩하게) 애플리케이션 개발/운영 사이클이 순환'될 수 있도록 하는데 DevOps의 도입 목적가 있다. 결국엔 요구사항에 빠르게 대응하기 위한 문화(조직역량, 방식, 도구의 조합 등)를 의미한다.

 

[활용]

- MSA가 등장함에 따라 서비스 단위로 작은 규모로 팀을 꾸리고 각 팀에는 개발팀, 운영팀을 비롯한 다양한 사람들이 모여 협업한다. 서비스 단위로 배포 및 운영이 진행되다보니, 배포의 주기는 짧아지고 횟수는 더 많아진다. 이러한 환경에서 개발과 운영이 조화를 이루고 변경사항이 빠르게(민첩하게, Agile) 반영될 수 있도록 하는 기술 또는 팀의 문화를 설명하는 것이 'DevOps'이다.

- 즉, DevOps를 설명하기 위해서는 Microservice 구조 기반으로 구성된 작은 팀 단위로 운영할 때 유리한 조직 구조가 된다.

 

 

[일반적으로 말하는 DevOps에 포함되는 사항들]

1. 기업의 기술 문화(커뮤니케이션 + 협업)

- DevOps는 하나의 문화 철학이다. 개발자와 운영자는 주인의식과 책임감을 갖는 문화를 정착시켜서 서로 간의 많은 책임을 공유하고 실제 워크플로우를 합치기도 하며 시간을 절약하기도 한다.

- 즉, 조직 내 침묵을 줄이고 직군 간 장벽을 허문다.

 

2. 툴링과 자동화 활용

- 기존 인프라 관리는 수동으로 해 왔다.

- 코드를 통해 인프라를 관리한다는 의미의 IaC(Infrastructure as Code)라는 개념은 DevOps에 포함될 수 있다.

- IaC 덕분에 개발환경, 테스트환경, 운영환경 간에 서로 유기적으로 바꿔가며 관리할 수 있다.

- 수동적으로 진행하던 배포 프로세스를 CI/CD를 통해 자동화해서 '빠른 배포'가 가능해졌다.

 

3. 모니터링, 로깅 (사후관리)

- 배포 사후 관리인 모니터링과 로깅을 통해 실시간으로 성능에 대한 정보도 얻을 수 있어야 한다.

- 거의 대부분의 것을 '측정'해서 분석한다.

 

4. MSA

- 서비스 단위로 팀을 구성해 배포를 보다 빠르게 하도록 한다.

 

 

SRE(Site Reliability Engineering, 사이트 신뢰 엔지니어링)

- DevOps 환경에서 빠르고 자주 발생하는 배포 과정 중 장애 발생에 대한 우려가 커졌고, "이 장애를 최소화하고자 하는 목적으로 등장했다."

- SRE 사이트 신뢰성을 극대화하기 위한 활동을 의미하며 개발자들이 배포한 애플리케이션을 모니터링하고 운영하는 플랫폼을 자동화한다.

- SRE의 목적은 안정적으로 운영할 수 있도록 하는 과정을 수작업이 아닌 '자동화'를 통해 이루어지도록 하는 것이다.

- 가시적으로 안정화시키고 조치할 수 있을지에 대한 컨셉이다. 문제 발생 시 적시에 인지하고 조치하는 것을 자동화한다. 또한 장애발생에 대한 책임은 모두에게 있다는 문화를 필요로 한다.

- 안정적인 사이트를 운영하고자 하는 기술 (모니터링, 안정적인 배포 시스템, 시스템 관리 도구 등을 포함한 운영체계)

- 서비스를 안정성 있게 계속 고객에게 제공이 되는지 판단하기 위해서 필수적인 DevOps의 요소이다.

- 특정 문제가 발생했을 때, 자동화된 조치, 문제예측 등의 활동이 포함되며 사람이 없더라도 '자동화'로 처리될 수 있는 전반적인 운영환경을 의미한다. 

 

 

SRE 엔지니어가 하는 일

1. 모니터링 지표 정의

- 서비스에 대한 지표를 정하고 이 지표에 대한 목표를 정해서 관리

- 지표 예시:

    1) MTTF(Mean Time to failure: 장애가 발생하지 않고 얼마나 오랫동안 시스템이 정상 작동했는가)

    2) MTTR(Mean time to recover: 장애가 났을 때 복구 시간)

- 각 지표를 데이터화하고 어떤 상황에서 장애가 발생하는지를 판단

 

2. 용량 계획

- 서비스를 운영하는데 필요한 자원(CPU,메모리,디스크,네트워크 등)을 확보하는 작업

- 그 자원에서 동작하는 소프트웨어의 최적화 (성능 튜닝)

- 성능 튜닝은 시스템 안정성에 영향을 크게 주는 요소이므로 SRE에게 필요한 역량

 

3. 변경 관리

- 장애는 사람의 손이 갔을 때 발생한다. 따라서 대부분의 배포 프로세스를 자동화한다. (CI/CD 등)

- 예를 들어, 카나리 배포를 자동화하여 배포과정 중 문제가 발생하면 이를 자동으로 롤백하는 프로세스를 구축 및 자동화한다.

 

4. 문화

- 장애 발생에 대한 책임은 전체에게 있다.

- 위 지표를 통해 수집한 데이터를 활용해야 한다. 운영자만을 위한 지표가 되어서는 안 된다.

 

 

 

정리

IT 서비스 시스템이 방대해짐에 따라 MSA가 등장했고, 분리된 서비스 각각을 도커 기반으로 이미지화해서 배포 관리하게 되었다. 그리고 기업에서는 MSA 기반으로 분리된 각 서비스 단위로 '작은 팀'이 구성되기 시작했으며 각 팀에서는 개발부터 아키텍처, 인프라, 유지보수 등 일련의 라이프사이클을 한 번에 관리하는 구조로 조직되었다. 이러한 흐름에서 DevOps가 설명될 수 있는데, 각 DevOps 팀이 각 서비스를 관리하게 된다면 서비스 단위로 빠르게 요구사항 대응이 가능해진다. 이후, DevOps의 발달 과정 중에 SRE 컨셉이 도출되었다. DevOps 문화 속에서 안정적인 사이트 운영이 목적이라면 SRE를 도입해 서비스의 운영 측면에서 '자동화'까지 고려한 고도화된 구조로 확장될 수 있다.

 

DevOps는 개발과 운영이라는 전체 프로세스를 아우르는 용어이고 그 안에 SRE, 애자일, CI/CD, 커뮤니케이션 등과 같은 속성들이 존재하는 구조이다.

 

이렇듯 MSA, Docker, DevOps, SRE 등은 서로 유기적으로 연결되어 있다. 궁극적인 이들의 적용 목적은 DT 시대에서 기업의 핵심 경쟁력인 '요구사항 선제 대응'을 위함이라고 생각한다. 앞으로는 단순 개발 작업이나 반복적인 운영은 자동화될 것이고 전반적인 개발 및 운영 프로세스를 이해하고 개발할 수 있어야 경쟁력 있는 엔지니어가 되리라 생각한다.