[개념] MSA, 컨테이너의 등장과 Agile, DevOps 문화는 무엇인가

제조업에서 DBA, 미들웨어 엔지니어로 일하면서 가장 크게 느낀 부분은, 한 번 설계하고 배포한 시스템은 그 시스템을 전부 뒤엎지 않는 이상, 변경을 하기가 굉장히 까다롭다는 것이다.

이는 필자가 일하고 있는 회사가 제조업이기 때문이고, 제조업 특성 상 생산 가동 시간이 매출에 가장 큰 영향을 미치며, 이는 곧 IT 조직의 '변화'에 대한 두려움으로 경직을 불러옴으로써 야기된 결과라고 생각한다. 이러한 문제가 비단 제조업에서만 일어날 것 같지는 않다.

 

각설하고, 더 이상의 레거시 시스템을 찍어내는 행동을 반복하지 않기 위해, 나부터라도 조금씩 최신 IT 트렌드를 공부하고 이러한 기술들을 사내에 안정적으로 도입 및 적용시키며, 기존의 변화가 어려운 낡은 시스템에서 유연한 변화가 가능한 시스템으로 탈바꿈하는 것을 목표로 해보고자 한다.

 

그러기 위해서는, 이제는 트렌드라고 부르기도 뭐한, IT의 기본적인 아키텍처 또는 문화로 자리 잡은 MSA, 컨테이너, Agile, DevOps 등의 개념부터 알아볼 필요가 있다. 이번 포스팅에서는 이러한 것들의 개념을 정리하고자 한다.

 

---

MSA(Micro Service Architecture)를 논하기 전에, 우리는 지난 수십년 간 IT 시스템의 표준이었던 모놀리식 아키텍처(Monolithic Architecture)에 대해 알아볼 필요가 있다.

 

모놀리식 아키텍처(Monolithic Architecture)란?

: MSA와 반대되는 개념으로, 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다. 통상적으로, 단일 코드 베이스의 애플리케이션 또는 그러한 애플리케이션이 동작되는 시스템을 말하며, 이 애플리케이션 하나는 단일 데이터베이스에 연결되는 구조이다.

모놀리식 아키텍처의 다이어그램

모놀리식 아키텍처의 장점

• 단순성 : 모든 코드가 단일 코드 베이스에 있으므로, 변경 사항이 발생할 경우, 적용할 모든 코드가 한 곳에(한 프로젝트 내에) 존재한다는 의미이다. 또한 개발환경 즉, 로컬에서 실행해야 할 경우, 단일 애플리케이션만 실행하면 되는 단순함이 있다.
• 간편한 배포 : 단일 프로젝트로 배포하면 되므로 간편하다(?). → (Downtime이 자유로운 도메인이라면, 간편하다.)
• 보편성 : 대부분의 개발자가 모놀리식 아키텍처에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있다.
• 인프라 구성 용이 : 하나의 프로젝트, 즉, 하나의 애플리케이션 및 DB만 배포하면 되므로, 인프라 구성이 쉽고 관리 point가 적다. (초기에만 그렇다고 본다.)

 

모놀리식 아키텍처의 단점

• 유지 보수의 어려움 : 시간이 지남에 따라 분명 애플리케이션의 규모가 커질텐데, 이에 따른 어려움이 생길 수밖에 없다. 단일 프로젝트로 개발하면서 필요한 모듈들이 굉장히 많을텐데, 하나의 기능을 변경하고자 하면, 이를 참조하거나 영향을 받는 모든 모듈들도 수정해야 하기 때문이다. 또한 가장 큰 문제로는, 작은 부분을 수정하고 반영하는 데에 있어서도, 전체 애플리케이션이 한 번은 종료되어야 한다는 점이다.
• 유연하지 않은 확장성(Scale 측면) : 애플리케이션의 특정 부분에 대한 요청을 받으면, 이 부분만을 확장할 수는 없고, 전체 애플리케이션을 확장해야 한다.
• 대규모 팀 작업의 어려움 : 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에, 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀의 작업에 영향을 줄 수 있다.
• 기술 사용 제한 : 모듈 간의 의존성이 매우 높아, 다른 기술 스택으로 변경하는 것이 매우 어렵다.

---

MSA(Micro Service Architecture)란?

: 애플리케이션을 작은 서비스로 분할하고, 각 서비스가 서로 독립적(느슨한 결합)이므로 기술 및 의존성에 구애 받을 확률이 낮다. 또한, 각 서비스 별로 고유한 데이터베이스를 소유할 수 있으며, 그로 인해 많은 이점도 제공하지만, 여러 문제와 복잡성 또한 수반하게 된다.

MSA 아키텍처의 다이어그램

MSA의 장점

• 유연한 확장성(Scale 측면) : 각각의 마이크로 서비스는 서로 독립적이므로, 매우 유연한 확장이 가능하다. 또한 이는 애플리케이션의 고가용성이 필요할 때 매우 유용하게 된다.
• 독립적인 배포 : 마이크로 서비스는 서로 느슨하게 결합되어 있으므로, 하나의 마이크로 서비스만 배포할 수 있다. 수정 사항이 생겼을 때, 전체 애플리케이션의 작동을 멈출 필요가 없게 되는 것이다.
• SPOF 제거 : 애플리케이션을 여러 소규모 서비스로 분할하여, 전체에 영향을 미치는 단일 실패 지점을 제거할 수 있다.
• 서로 다른 DB 소유 가능 : 각 마이크로 서비스의 특징에 따라, RDBMS가 적합할 수도 있고, NoSQL이 적합할 수도 있다. 이러한 각 서비스에 적합한 DB와 연결하여 서비스의 유연한 변화 및 확장을 가져갈 수 있다.
• 다양한 기술 스택 사용 가능 : 하나의 프로젝트가 아니기 때문에, 서로 다른 언어를 사용하여 개발할 수 있게 된다.
• 민첩성 : 전체 애플리케이션에 큰 영향을 주지 않고, 새로운 것을 추가할 수 있어, 새 버전을 배포하는 것이 매우 쉽다.

 

MSA의 단점

• 개발 환경의 뒷받침 : 여러 개의 마이크로 서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 개발환경(로컬)에서 많은 애플리케이션을 실행할 수 있는 환경이 갖춰져야 한다.
• 디버깅의 어려움 : 디버깅 및 테스트 시, 둘 이상의 마이크로 서비스를 실행해야 할 수 있어, 이 부분이 어려울 수 있다.
• 개발의 어려움 : 마이크로 서비스 간의 통신에서 동기/비동기 방식의 통신을 고려하고, 다양한 Workflow 및 시나리오에서의 오류 처리, 중앙화된 모니터링 체계의 필요성, 오류 식별의 어려움 등이 있을 수 있어, 개발하는 동안에 복잡성이 증가한다.

---

여기까지 애플리케이션 개발 및 유지 보수에 대한 측면, 즉, 개발자의 입장에서 모놀리식 아키텍처와 MSA의 아키텍처를 이해했다면, 이제 인프라 엔지니어의 입장에서 생각해보자.

 

“MSA, 좋다 이거야. 근데 그렇게 잘게 잘게 쪼개 놓은 서비스들을 올릴 서버는 다 어떻게 만들고 관리하라고?” 라는 문제를 인프라 엔지니어가 해결해야 한다.

소규모의 마이크로 서비스들을 하나의 물리적 서버에 모두 올리자니, 이건 MSA의 최대 장점인 유연한 확장성을 없애버리는 것이고, 그렇다고 각 서비스마다 VM을 만들자니, 불필요한 OS 관리 포인트(취약성 패치 등..)와 OS가 차지하는 리소스와 오버헤드가 과도하게 증가하게 된다.

 

이러한 문제의 해결책으로, 한 물리적 서버에 대해서(하나의 OS 안에서) 각 서비스별로 독립된 공간을 만들어보자는 아이디어가 나오고, 이는 곧 컨테이너의 등장이 된다.

(물론, 컨테이너의 등장 배경은, 정확히 이러한 문제보다는 애플리케이션 개발과 운영 간 간극을 최소한으로 좁히고, 이를 이미지로 관리하기 위함이라는 게 더 옳은 듯 하다.)

 

컨테이너(Container)란?

: 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 소프트웨어 패키지.

OS를 가상화하여 프라이빗 데이터 센터에서 퍼블릭 클라우드 또는 개발자의 개인 노트북에 이르기까지 어디서나 실행이 가능하다.

왼쪽: Virtual Machine / 오른쪽 : Container (Docker 예시)

 

컨테이너의 장점

• 책임 분리 : 컨테이너화를 통해 개발자와 운영팀의 책임을 분리함으로써, 각자가 잘하는 것에 더 집중할 수 있게 된다. 개발자는 컨테이너에 함께 빌드할 애플리케이션의 로직과 종속 관계에 집중하고,
  운영팀은 특정 소프트웨어 버전 및 구성과 같은 애플리케이션의 세부 요소 대신 배포 및 관리에 집중할 수 있게 된다.
• Workload 이동성 : 컨테이너는 Linux, Windows, Mac 등의 OS를 가지리 않고, VM, 물리적 서버, 개발자 컴퓨터, 데이터 센터, 온프레미스 환경, 퍼블릭 클라우드 등 사실상 어느 환경에서나 구동되므로, 개발 및 배포가 매우 쉬워지게 된다.
• 애플리케이션 격리 : 컨테이너는 OS 수준에서 CPU, 메모리, 스토리지, 네트워크 리소스를 가상화하므로, 개발자에게 다른 애플리케이션으로부터 논리적으로 격리된 OS 환경을 제공한다. 즉, 다른 컨테이너의 과부하로 인해 내 컨테이너가 죽는 경우를 보지 않아도 된다.

 

컨테이너의 단점

• 모든 컨테이너는 동일한 OS에서 실행되어야 하며, OS 또는 버전을 조합해서 사용할 수 없는 게 관리 Point 면에서는 장점이 될 수 있지만, 거대한 시스템에 대해 다양한 환경으로 운영할 수 없다는 게 단점으로 될 수 있겠다.
• 컨테이너가 올라가는 OS가 모든 컨테이너에 대해 공유되므로, VM보다 보안이 취약해질 수 있다.
• MSA 아키텍처가 적용되지 않은 컨테이너는 이미지로 만들어 찍어낼 수 있다는(?) 장점 외에, 비용 대비 VM과 견주어 우위에 있는 장점이 없어 보인다.

 

MSA와 컨테이너의 공통되는 키워드는 결국 ‘경량화’이다. 애플리케이션 아키텍처도, 인프라 아키텍처도 결국 '커다란 문제를 해결하기 위해 작은 단위로 쪼개야 한다'는 IT의 보편적인 진리가 한번 더 통한 셈이다.

---

그렇다면, 개발과 운영 업무를 하는 문화에도 ‘경량화’란 게 있을까? 우리는 이를 ‘Agile’ 방법론과 ’DevOps’ 문화라는 키워드로 살펴보기로 하자.

 

Agile 방법론이란?

: ‘Agile’이란, ‘기민한, 민첩한’ 이라는 뜻으로, 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더하고 수정해 나가는 탄력적인 방법론을 말한다.

짧은 단위의 스프린트가 모여 스크럼 형태로 일하는 Agile 방법론

오늘날 많은 기업에서는 위 그림과 같은 *스크럼 형태로 애자일 프로세스를 주로 활용하는데, 특징적인 것은 변화에 수동적으로 대처하기보다 변화를 하나의 고정값으로 전제하여, 1~4주라는 짧은 단위의 스프린트 단위로 디자인,개발,테스트를 진행한다는 것이다. (⇒경량화한 프로세스의 지속적인 반복)

 

 

*스크럼 : 비즈니스 요구를 충족시키는 데에 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발 및 전달하는 관리 프레임워크

 

Agile 방법론의 등장배경

IT 엔지니어라면, Agile하면 Waterfall(폭포수) 방법론이 당연하게 떠오를 것이다.

Waterfall 방법론은 아래 그림과 같은 요구사항 정의 및 서비스 설계 → 디자인 → 개발 → 테스트 → 배포 과정이 순차적으로 진행되며, 이전 단계가 완료된 후에야 그 다음 단계로 나아가게 된다.

하나의 IT Product가 출시되기까지 심사숙고(?)하는 Waterfall 방법론

 

이 방법의 장점으로는, 단계별로 업무를 분담하므로 맡은 바가 명확하고, 계획 단계의 문서화로 단계마다 소요되는 시간이나 현재 상황을 추적하고 병목을 파악하기도 쉽다는 것이다.

그러나, 위에서 물이 떨어질 때까지 마냥 기다리고 있어야 하니 서비스 런칭까지의 속도가 매우 느리며, 떨어진 요구사항대로 기능을 만들었으나 느린 속도에 의해 수 개월이 지난 시점에 해당 서비스가 배포되고 나면, 시장 상황은 이미 변해버려 더 이상 고객이 그 기능을 필요로 하지 않은 경우도 발생할 수 있다는 치명적인 단점을 가지고 있다.

 

결국 고객의 요구사항을 더 기민하게 대응하고 실현시키기 위한 방법론으로 Agile 방법론이 등장하게 되었다고 볼 수 있다.

Agile 소프트웨어 개발 방법론에서는 다음과 같은 가치를 더 중요시 한다.

• 과정에 대한 공정과 과정에 사용되는 도구 자체 < 개인과의 상호작용, 커뮤니케이션
• 포괄적인 문서 < 작동하는 소프트웨어 자체
• 계약 협상을 통한 이득 < 고객과의 협력을 통한 프로젝트 성공을 통한 이득
• 계획은 일단 따르는 것 < 계획과 다르더라도 변화에 기민하고 유연하게 대응하는 것

---

DevOps란?

기존 개발팀과 운영팀 간의 Silo(사일로) 현상을 제거하는 소프트웨어 제공 접근 방식 또는 그러한 문화를 말한다. 이는 새로운 Tool과 문화를 통해 코드 배포 또는 인프라 프로비저닝과 같이 수동적이고 느리던 기존 프로세스에 대해 자동화하는 것을 목표로 한다. 이러한 자동화를 통해 애플리케이션 및 서비스를 신속하게 제공할 수 있는 조직의 능력 향상이라는 방향성을 가지는 문화라고 볼 수 있다.

선순환(?) 고리를 통한 IT Product의 지속적인 개선을 지향하는 DevOps

DevOps 등장 배경

하나의 IT Product를 출시하기 위해서는, 프로젝트를 개발하고, 빌드하고, 테스트하고, 배포하고, 운영하는 등의 업무가 필요한데, 보통 지금까지의 회사들은 이를 개발팀과 운영팀으로 나누어 수행해왔다.

시스템 간 연결이 점점 더 복잡해지고, 그에 따른 필요한 기술과 고객의 요구사항이 지속적으로 변화해 감에 따라, 한 IT Product를 출시하고 운영하는 데에 있어서 같은 방향을 바라봐야할 IT팀 내에서도, 개발팀과 운영팀 간의 소통은 매우 어려워져 갔다.

이러한 사일로 현상을 타파하고, 개발팀과 운영팀 간의 협력과 통합을 강조하며, “개발팀처럼 생각하는 운영팀, 운영팀처럼 생각하는 개발팀”이라는 슬로건을 통해, 개발과 운영이 하나의 파이프라인으로 통합되어, IT Product의 품질 향상과 고객 요구사항을 더 기민하게 만족시키자는 것이다.

 

번외 - Agile과 DevOps의 구분?

필자는 DevOps라는 문화 자체가 Agile 방법론을 IT 실무적으로 좀 더 효율적으로 수행하기 위한 구체적인 방법론 또는 문화라고 생각하기에 둘의 차이점에 대해 굳이 알고 싶지는 않지만,
Agile은 고객과의 상호 작용에,
DevOps는 개발팀과 운영팀 간의 긴밀한 협력 관계 구축에 집중한다는 포인트로 접근하면 좋을 듯 하다.

 

결국 이 두 용어가 추구하는 공통적인 가치는, 공유/개방성/자율성 및 소통과 협력을 매우 중요시하며,
경량화 및 MVP 모델을 지향하고, 절차와 프로세스보다는 Fast Fail 및 이에 대한 피드백에 대한 반복을 통한
지속적인 개선과 변화를 장려한다는 것에 있다.

---

참고

https://yozm.wishket.com/magazine/detail/1813/

모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까? | 요즘IT

http://www.itdaily.kr/news/articleView.html?idxno=208378

[전문가 강좌] MSA와 애자일(Agile) - 아이티데일리

https://cloud.google.com/learn/what-are-containers?hl=ko

컨테이너란?  |  Google Cloud

https://www.vmware.com/kr/topics/glossary/content/vms-vs-containers.html?resource=cat-1065884937#cat-1065884937

Why use containers vs. VMs? | VMware Glossary

https://www.codestates.com/blog/content/애자일방법론-워터폴방법론

애자일과 워터폴 방법론 비교 | 정의, 차이, 장단점, 적합한 조직 - 코드스테이츠 공식 블로그

https://engineering-skcc.github.io/devops/DevOps1-애자일과데브옵스/

데브옵스 알아가기(1) : 애자일과 데브옵스