OSC Korea Blog

다양한 소식을 전합니다.
Blog

비대면 디지털 전환과 케이오스 엔지니어링

비대면 디지털 전환과 케이오스 엔지니어링
원문보기
Photo by Yung Chang on Unsplash

백신 개발과 보급이 박차를 가하고 있지만, 코로나19 아직도 현재 진행형이다. 크게는 전세계 경제, 교역, 관광등의 산업이 정지되었고 작게는 모든이들의 평범한 일상을 앗아갓다. 지금 이 순간에도 3차 유행이라고 불려질만큼 전세계적으로 확진자가 폭증하고 있고 세계 각국들은 봉쇄령이라는 최후의 카드를 꺼내들고 있다. 우리나라도 코로나19 유행 초기에는 확진자 수 세계 2위를 기록하기도 했지만 검사-추적-치료를 골자로한 소위 말하는 K-방역으로 이동제한이나 의료시스템의 붕괴 없이 코로나 확산을 통제하고 있어 세계적으로 주목 받고 있다.

외신들로부터 모범적이라고 극찬받고 있는 현재 우리나라의 감염병 대응 시스템은 2015년 메르스 방역 실패의 교훈으로 탄생되었다고 볼수있다. 186명이 감염되고 그 중 38명이 사망한 메르스 사태를 혹자는 “우리나라 전체 보건방역시스템의 스트레스 테스트였다”라고 평가하기도 한다.

코로나19는 우리의 일상에 많은 변화를 가지고 왔다. 외출이 제한되면서 자연스럽게 사회 및 경제 전 분야에 걸쳐 비대면 디지털 전환이 가속화 되었다. 필자를 예로 들자면 나는 지금 재택근무를 하면서 이글을 쓰고 있고, 어제 저녁은 배달앱으로 치킨을 시켜먹었다.종종 주말에 마트나 백화점에 가서 쇼핑을 했지만 지금은 로켓배송이 없으면 살수가 없다. 베트남어를 다시 배워보려고 어학원사이트에 접속을 해보니 실시간 온라인 수업이 등장했다. 물론 코로나 이전에도 존재하던 서비스들이지만 포스트 코로나 시대에서는 기존의 언택트 서비스들은 더 활성화되었고 더 많은 분야로 확장되고 있다. 가장 최근에 봤던 신박한 서비스는 비대면 세탁 서비스였다. 집앞에 옷을 두면 다음날 세탁되어서 돌아오는..

이러한 생활 및 소비 패턴의 급격한 변화로 인해 디지털 트랜스포메이션은 이제 기업들에게 선택이 아닌 필수가 되었고 이런 변화에 더 빠르고 유연하게 대응하기 위해서 클라우드 네이티브 및 마이크로 서비스 개발론이 대세가 되고 있다. 클라우드 네이티브 애플리케이션이란 프라이빗, 퍼블릿 및 하이브리드 클라우드 환경에서 구동되도록 설계 및 개발된 애플리케이션이다. 기존에 온프레미스 환경에서는 애플리케이션을 구동하려면 해당 서비스에 특정 하드웨어를 구축 및 할당해야 했다. 초기 설계단계부터 사용량 예측을 해서 서버사이즈를 정해야했고 서비스의 성공 여부가 불투명한 단계에서도 인프라에 대한 초기투자가 필요했고 추후에 사용자가 늘어나더라도 탄력적으로 서버 크기 및 갯수를 늘리는데 제한적이었다. 이런한 제한사항들은 기업들에게 신규 비지니스 모델을 시장에 내놓고 실행시키는걸 더 어렵게 만들었었다. 클라우드의 등장으로 인해서 기업들은 인프라 구축시간 및 초기투자비용은 최소화하고 탄력성 및 확장성은 극대화함으로써 빠르게 변화하는 소비자의 요구에 맞춘 서비스를 더 빠르게, 더 적은 리스크를 감당하면서 제공할수 있게 되었다. 하지만 단순히 기존에 온프레미스에서 실행되던 애플리케이션을 클라우드에서 이전해서 구동시킨다고 해서 클라우드 네이티브 애플리케이션이라고 부를수는 없다. 기존에 온프레미스 환경에서는 모놀리식 아키텍처라고 해서 애플리케이션 구성요소들이 하나의 배포단위로 구성되고 단일서버에서 구동되었고 해당 아키텍처는 아래와 같은 단점을 가지고 있다.

  • 모든 기능들이 단일 서비스로 실행되기 때문에 특정 기능에 대한 수요가 늘어날때도 해당 서비스 전체를 확장해야 한다.
  • 새로운 기능을 추가하거나 기존의 기능을 개선해야 할 때 각 기능들의 연관성, 전체 서비스에 대한 구조 및 특성을 파악해야 하기 때문에 빠른 서비스 개발이 제한된다.
  • 특정 기능에 대한 수정이 이루어 지거나 새로운 기능을 추가할 때 애플리케이션 전체를 빌드, 테스트, 배포 해야 하고 코드 베이스가 증가함에 따라서 빌드, 테스트, 배포에 걸리는 시간이 역시 증가하기 때문에 빠르고 즉각적인 배포가 어렵다
  • 전체 애플리케이션이 특정 프로그래밍 언어, 데이터베이스 엔진, 프레임워크, 라이브러리 등에 구속되어 있기 때문에 특정 기능에 최적화된 개발툴 사용이 제한적이다.

이러한 단점을 가진 애플리케이션 구조는 클라우드의 장점을 극대화 시키기에는 알맞지 않았고 새로운 개발 방법론이 대두되었다. 클라우드 네이티브를 얘기할때 항상 붙어 다니는 개발 방법론인 마이크로서비스 아키텍쳐(MSA)이다. 마이크로서비스 아키텍쳐(MSA)는 애플리케이션을 핵심 기능으로 세분화해서 각각의 기능들을 독립적인 서비스로 구성, 구축, 배포하고 각 서비스들의 간의 통신을 API로 설계하는 현대적인 애플리케이션 설계 방법론이고 아래와 같은 장점을 가지고 있다.

  • 유연한 확장: 특정 서비스에 대한 요청이 증가할 경우 서비스 전체를 확장할 필요 없이 해당 서비스만 확장 시킬 수 있고 특정 서비스의 워크로드 특성에 따라 리소스를 할당할수있다
  • 개방성 향상: 애플리케이션을 구성하는 각각의 서비스들은 API나 Messaging Protocols(HTTP, MQ, 이벤트 스트리밍) 을 통해서 통신하므로 개발자들은 필요한 기능에 맞는 최적의 언어, 기술, 도구들을 자유롭게 선택할수 있다.
  • 생산성 향상: 하나의 큰 애플리케이션을 구성하는 다수의 서비스들을 각각의 독립된 팀에서 전담하여 동시에 개발할 수 있다. 이는 개발에 소요되는 시간을 단축할 수 있으며 애자일 개발 방법론을 도입할 경우에는 개발 주기를 보다 단축할 수 있다.
  • 손쉬운 배포: 배포 단위가 작아짐으로써 개발자가 적용한 애플리케이션의 변경 사항을 더 빠르게 빌드, 테스트, 배포할 수 있고 변경된 사항에 문제가 발생하더라도 더 빠르게 복구 및 수정 할 수 있다.
  • 안정성 향상: 모놀리식 아키텍처에서는 각 구성 요소가 서로 종속되어 있기 때문에 단일 서비스의 장애가 전체 애플리케이션 장애를 초래할 수 있다. 반면 마이크로서비스 아키텍쳐에서의 독립적인 서비스들은 서로에게 미치는 영항이 없거나 최소화된다.

그럼 어떤 구조를 가진 애플리케이션을 마이크로 서비스 아키텍처라고 부를수 있을까? 마이크로서비스를 설계하는 방식에 정답은 없다. 각기 다른 요구사항에 따라 아키텍처가 달라질 수 있고 시스템을 설계하는 사람마다 다른 관점에서 마이크로서비스를 바라볼 수 있기 때문이다. 하지만 마이크로서비스를 설계할 때 “애자일 소프트웨어 개발론”, “서비스 지향 아키텍처”, “API 기반 디자인”, “지속적인 통합 및 전달(CI/CD)”를 기초로 해야한다는 것에는 이견이 없다.

그럼 마이크로서비스를 도입하면 앞서 언급한 장점만 있는 것일까? 마이크로서비스는 말 그대로 작은 단위로 쪼개진 서비스가 각각 독립적으로 기능을 가지고, 하나의 서비스를 동작하게 한다. 이렇게 분산된 서비스들은 빠르고 애자일하게 서비스를 제공하는 반면 작은 단위로 쪼개진 서비스로 인해 장애(Failure)가 발생할 수 있는 지점이 많고 이로 인해 발생하는 서비스 다운타임은 비즈니스에 심각한 영향을 끼치게 된다. 따라서, 비즈니스에 심각한 영향을 줄수 있는 장애 상황을 미리 파악하고 선제적으로 대응하는 것은 매우 중요하다. 하지만 정말로 선제적으로 대응하는 기술이 있을까?

지금으로부터 10년전 넷플릭스는 클라우드로 애플리케이션을 이전하면서 하나의 고민에 빠졌다. 기존에는 시스템 안정성을 테스트 할때 하드웨어에 직접적인 장애를 유발할수가 있었다. 가령 특정 서버들의 연결된 전원 스위치를 강제로 끊다거나 네트워크 케이블을 뽑는 방식으로. 하지만 클라우드 세계에서는 이야기가 다르다. AWS나 GCP 같은 퍼블릭 클라우드 같은 경우에는 하드웨어 리소스 자체에 접근이 불가능했고, 자체적으로 구축한 클라우드일지라도 서버들은 가상머신(VM)으로 실행되므로 물리적인 방식으로 장애를 발생시켜서 서비스 안전성을 확인하는게 쉽지 않은 작업이었다. 뿐만아니라 마이크로서비스 아키텍처에서는 각각의 서비스들은 다수의 가상머신에 분산되어서 배포되었고 애플리케이션은 더 빠르게 확장하면서 넷플릭스를 이루는 서비스의 갯수는 기하급수적으로 늘어나기 시작했다. 특정 서비스가 정상적으로 작동하더라도 이 서비스과 연동된 다른 서비스의 장애로 연쇄적인 장애를 발생시킬수도 있고 각 서비스간의 상호작용 및 종속성을 미리 파악해서 시스템을 더 안정적으로 설계, 구축 및 개발하는 것이 제한적일수 있다. 이러한 복잡한 분산시스템에서 발생할수 있는 문제를 더 빠르게 발견하고 개선할수 있도록 하기 위해서 케이오스 엔지니어링 이라는 방법론이 탄생했다.

케이오스 엔지니어링이란 고의로 시스템에 장애를 유발해서 1) 장애 대응 프로세스를 확인하거나 2) 예측되지 못한 새로운 문제점을 파악하는 방법론이다. 우리가 실생활에서 접할수 있는 예로 비유한다면 “소방훈련”이 될수 있다. 화재가 발생했다고 가정할때 정해진 시간안에 탐지기가 동작해서 경보를 울리는지, 스프링클러는 작동하는지, 비상구는 열려있는지, 누가 사람들을 인솔해서 집결지로 이동할지, 특정 임무에 지정된 인원이 부재시에는 어떻게 할건지 등의 화재 대응 프로세스를 확인하고, 문제점을 파악하고, 개선하는 것처럼 말이다.

케이오스 엔지니어링 역시 하나의 방법론이지만 몇가지 원칙은 있다.

  • 정상상태에 대한 정의: 서비스가 정상이다, 비정상이다를 판단하는 기준은 아마 다 다를것이다. 일반적인 웹서비스라면 접속불가 상태가 장애일 것이고, 온라인 게임의 경우에는 지연시간이 특정 임계치를 넘어설 경우에 장애라고 볼수도 있을것이다. 정상상태와 장애를 구분할수 있는 기준을 세워야한다.
  • 운영환경에서 실험: 테스트 환경이 아닌 운영 환경에 문제를 유발하여 실제로 발생할수 있는 여러가지 변수를 파악하는것이다. 물론 코드형 인프라로 운영 환경과 동일한 테스트 환경을 구축하고 가상의 트래픽을 생성한 후에 이상 현상을 발생시키는 실험을 할수도 있겠지만 실제로 벌어질수 있는 변수를 모두 포함할수는 없기 때문이다. 그리고 고의로 문제를 발생시켰을때 실제 사용자가 영향을 받지 않아야 실제로 문제가 발생했을때 역시 정상 동작할것이기 때문이다.
  • 지속적인 실험: 시스템이 지속적으로 변화함에 따라 문제를 일으킬수 있는 변수 역시 변할것이다. CI/CD(지속적인 통합/ 지속적인 전달)뿐만 아니라 Continuous Chaos 역시 자동화되어야 한다.

현실세계에서는 수많은 희생을 통해서 인류가 발전해 왔지만 디지털 세계에서는 희생없는 발전도 가능하다.

최근 국내에서도 케이오스 엔지니어링에 대한 관심과 상용 서비스에 대한 수요가 빠르게 증가하고 있다.  Gremlin 은 이런 케이오스 엔지니어링의 원칙을 적용하여 기업에서 즉시 사용할 수 있도록 설계된 유일한 상용 솔루션이다. OSC Korea는 국내에서 유일하게 케이오스 엔지니어링 경험이 있는 디지털 트랜스포메이션 전문기업이다. 최근 Gremlin 을 국내 대기업에 도입 컨설팅, 기술 검증 (PoC), 구축 까지 진행하였다.  

해당 기업에서는 클라우드 서비스, IT 분석 및 컨설팅, 데브옵스, 마이크로서비스 아키텍쳐 등의 업무를 제공하고 인프라 자동화, 컨테이너 오케스트레이션, 로그인 관리, 모니터링, 리포팅, CI/CD 컨설팅 등 여러 서비스를 제공하고 있다. 자세한 정보는 http://www.osckorea.com/solution/gremlin 에서 확인할 수 있다.


Latest posts

1 / 8
Next