5.1 컨테이너 애플리케이션 구성: 클라우드 네이티브 애플리케이션 구성

개발자를 위한 쉬운 도커 강의 | 데브위키 - 인프런

 

이번 시간에는 클라우드 네이티브 애플리케이션의 개념을 공부한다. 클라우드의 정의와 클라우드가 어떤 부분에서 중요한지 살펴보자. 그리고 클라우드 네이티브 애플리케이션이 무엇인지, 왜 중요하게 다루어지는지에 대해서 공부한다.

 

먼저 클라우드의 개념부터 정리해보자. 예전부터 네이버 클라우드나 구글 클라우드를 한 번쯤은 사용해 봤을 것이다. 그래서 클라우드라는 단어 자체는 친숙하게 느껴진다. 앞서 언급한 클라우드는 보통 스토리지 저장소를 의미한다. 클라우드 서비스를 사용하면 제가 원하는 파일들을 클라우드에 저장해 놓을 수 있다. 그러면 사용한 만큼만 비용을 지불하고 더 많은 파일을 저장하고 싶을 때는 저장한 만큼 추가 비용을 지불하면 되는 것이다. 그런데 이렇게 업로드한 파일들은 실제로 어디에 저장될까?

 

1. 클라우드

각각의 클라우드 업체들은 자체적으로 서버들을 가지고 있고 여기에 모든 사용자들의 파일이 물리적으로 섞여 있는 상태로 저장된다. 하나의 물리 드라이브에 여러 사용자의 파일이 저장될 수 있는 것이다. 클라우드 서비스를 사용한다는 것은 이런 인프라적인 부분을 신경 쓰지 않고 실제 서비스의 기능만 사용하겠다는 것을 의미한다. 극단적으로 클라우드 스토리지를 사용하지 않는다고 생각해보면 당장 USB부터 들고 다녀야 한다. 클라우드를 사용하면 물리적인 디바이스에서 자유로워지고 필요할 때마다 빠르게 확장할 수 있는 편리함을 누릴 수 있다.

 

클라우드와 공유경제

클라우드는 공유경제와 깊은 연관이 있다. 이미 공유경제의 개념은 주위에서도 많이 볼 수 있다. 예를 들어서 그린카나 쏘카 같은 서비스를 사용하면 자동차를 구매하지 않고도 시간당 요금으로 자동차를 사용하실 수 있다. 일반적으로 차를 직접 구매하려면 목돈을 지불해야 되고 유지보수를 직접 해야한다. 그 대신 플랫폼 사업자의 차를 대여해서 사용하는 것이다. 이 과정에서 차량을 다른 사람과 함께 공유하는 것을 암묵적으로 받아들이는 것이다. 클라우드 컴퓨팅도 같은 개념으로 이해하시면 된다.

 

AWS 전세계 클라우드 리전(Region) 위치

 

클라우드 컴퓨팅은 단순히 스토리지에 국한되지 않고 전반적인 서버 컴퓨터로 개념이 확장된다. 예를 들어 우리가 2코어의 4GB 메모리를 가진 컴퓨터를 사용하고 싶으면 클라우드 사업자의 계정을 만들어서 서버를 구매하면 5분에서 10분 내로 이 서버에 접속하실 수 있다. 클라우드 사업자는 대형 데이터 센터를 지역별로 구축해 놓고 가상화 기술을 활용한다.사용자가 서버를 구매할 때마다 VM을 한 대 만들어서 접속 정보를 제공해 주는 것이다.

 

클라우드와 비용

 

일반 기업이 서버를 새로 한 대 구매하려면 서버 구매 과정부터 배송, 설치, 유지보수까지 아주 많은 비용을 지출하게 된다. 그리고 또 시간도 오래 걸린다. 그리고 이 서버 기계 자체의 감가상각과 유지하기 위한 인력 비용, 전기 사용 비용, 폐기 비용도 결국 서버의 소유자가 부담해야 하는 금액이다. 그래서 기업들은 이런 비용들을 없애고 클라우드 서비스를 사용하는 것이다.

 

2. 클라우드 종류

클라우드 운영 회사

• 다른 회사의 서버를 빌려서 운영
• 다른 회사가 모두에게 서버를 빌려줄 경우: 퍼블릭 클라우드(Public Cloud)
• 다른 회사가 특정 조직에게만 서버를 빌려줄 경우: 프라이빗 클라우드(Private Cloud)

클라우드를 딱 한마디로 정의하자면 다른 회사의 서버를 빌려서 운영하는 것이다. 여기서 다른 회사는 대표적으로 마이크로소프트의 Azure, 아마존의 AWS, 구글의 GCP가 있습니다. 이 3개 회사들은 어떤 사용자든 계정만 만들면 서비스를 사용할 수 있습니다.

 

이렇게 누구나 사용할 수 있는 클라우드 서비스를 Public Cloud라고 부른다. 그런데 이런 자원들을 조직 내에 IT 계열사가 제공하는 경우도 있다. 이런 계열사가 제공하는 서비스는 같은 조직 내에 속해 있는 회사에만 서버를 만들어서 제공한다. 이런 경우에는 AWS나 Azure 같은 아예 다른 회사의 서버를 사용하는 것보다 보안에도 뛰어나고 비용적으로도 효율적이다. 이런 케이스는 Private Cloud라고 부른다.

 

클라우드의 특징은 사용 요청을 한 즉시 서버를 만들어 준다는 것이다. 서버를 만드는 것을 일반적으로 프로비저닝이라고 부른다. 그리고 서버를 사용한 시간을 측정해서 시간이나 월 단위로 요금을 청구한다는 것이 가장 큰 특징이다.

 

 

3. 클라우드 특징

1. 트래픽이 증가할 때 바르게 대처할 수 있는가? (확장성, Scalability)
   클라우드 환경에서는 서버 추가가 10분 내로 이루어진다. 온프레미스에서는 서버가 미리 준비되어 있지 않은 경우 새로운 서버를 증가하는데 오랜 식나이 소요된다. (주문, 배송, 설치 등)
2. 장애 발생 시 빠르게 복구할 수 있는가? (복원력, Resilience)
   클라우드 환경에서는 백업 및 복구가 빠르게 이루어질 수 있다. (Disaster Recovery)
   장애에 대응하기 위한 다양한 지역의 서버를 구축할 수 있다.
3. 운영 비용을 효율적으로 운영할 수 있는가?
   사용한 만큼만 지불할 수 있기 때문에 운영 비용에 더 효율적이다.

지금까지는 클라우드에 있어서 운영이나 관리상의 장점만 설명했다. 실제로 클라우드를 사용하는 핵심적인 이유는 현대 애플리케이션이 겪는 다양한 문제들을 클라우드를 통해서 해결할 수 있기 때문이다.

 

첫 번째로 트래픽이 증가할 때 빠르게 대처할 수 있는지가 이슈이다. 현대 애플리케이션에서는 사용자의 수요의 변동이 크다. 예를 들어서 온라인 커머스 같은 경우, 특정 할인 기간에 사용자의 요청이 급증할 수도 있다. 회계 시스템 같은 경우는 특정 기간이 아닐 때에는 트래픽이 거의 없을 수도 있다. 그래서 이런 트래픽 변동에 유연하게 대처할 수 있는지가 중요하다. 트래픽이 증가할 때는 빠르게 서버를 늘려야 한다. 트래픽이 없을 때는 서버가 낭비되기 때문에 서버를 줄일 수도 있어야 한다. 클라우드가 상용화 되기 전, 보통 서버를 사내에 직접 구성할 때는 서버의 용량을 증가하는 것이 쉽지가 않다. 그래서 트래픽의 최대값을 예상한 다음에 이 최대치에 맞춰서 서버를 구성했다. 그런데 이럴 경우에도 서버가 수용할 수 있는 양 이상의 트래픽을 받을 경우에는 서버가 다운될 수 있다. 여기서 클라우드를 사용하면 서버 추가가 빠르게 이루어질 수 있다. 그래서 트래픽이 증가할 때 서버를 증가시켜서 이 트래픽을 수용하고 트래픽이 다시 줄어들면 서버를 제거할 수 있는 것이다. 그러면 불필요한 서버 사용을 줄이면서 사용한 만큼만 비용을 지불할 수 있다. 이런 특징을 Scalability, 확장성이라고 부른다. 정리하자면, 클라우드를 사용하면 확장성을 가질 수 있고 트래픽 증가에 빠르게 대처할 수 있다.

 

두 번째로 장애가 발생했을 때 빠르게 복구할 수 있는지에 대한 부분이다. 회사 내 서버실에서 모든 서비스를 운영하고 있는 상태에서 이 회사에 갑자기 정전이 되었다고 생각해보자. 이런 경우에 모든 서비스에 장애가 일어나고 심한 경우에는 데이터가 날아갈 수도 있을 것이다. 가장 최근에 일어났던 사건으로는 카카오의 데이터 센터에서 화재가 발생해서 서비스가 중단되는 시간이 길어져서 아주 큰 이슈가 되었다. 그렇다고 클라우드의 서버를 운영한다고 해서 모든 것이 해결되지는 않는다. 결국 이 클라우드 사업자들도 국내의 어딘가의 데이터 센터를 가지고 있는 것이기 때문에 이 데이터 센터에 문제가 발생할 수도 있는 것이다. 그럼에도 클라우드 서비스가 복원력이 뛰어나다고 하는 이유는 전 세계의 다수의 데이터 센터를 그럼에도 클라우드 서비스가 복원력이 뛰어나다고 하는 이유는 전 세계의 다수의 데이터 센터를 만약에 제가 Azure Cloud Service를 한국 서울 데이터 센터에 운영하고 있고 부산에도 장애를 대비하기 위한 예비 서버를 운영한다고 생각해보자. 이 경우에 서울의 데이터 센터에 장애가 발생했을 때 부산 센터의 서버로 트래픽을 전환시킬 수 있을 것이다. 부산이 아닌 일본이나 미국의 서버를 운영할 수도 있을 것이다. 이렇게 복구에 사용하는 서버를 DR, Disaster Recovery라고 부른다. 클라우드를 사용하면 글로벌 다양한 지역의 서버를 저렴한 비용으로 가질 수 있다. 국내 업체가 해외 데이터 센터를 구축하려면 비용이 아주 많이 발생한다. 클라우드를 사용하면 이런 서버들을 해외 서비스 전용 서버로 활용할 수도 있고, 재해복구용 서버로 활용할 수도 있을 것이다. 그렇다고 클라우드가 무조건 좋은 것은 아니다. 잘 활용하지 못하면 양날의 검이다.

 

세 번째로 운영 비용을 효율적으로 가져갈 수 있는지에 대한 부분에 대해서 이야기해보자. 지금까지 말한 부분만 정리하면 클라우드가 저렴할 것 같지만 실제로 비효율적으로 사용해서 비용이 훨씬 비싸게 청구되는 케이스가 아주 많다. 전문 아키텍트가 서버 가용량을 적절하게 구성해야 되고 비용 최적화를 지속적으로 수행해야 전문 아키텍트가 서버 가용량을 적절하게 구성해야 되고 비용 최적화를 지속적으로 수행해야 한다. 그리고 단순히 해외 서버를 구성한다고 해서 재해복구나 해외 서비스가 바로 이루어지는 것도 아니다.

 

4. 클라우드 네이티브

클라우드 네이티브

• 클라우드: 복잡한 대형 애플리케이션이 겪는 다양한 문제들을 클라우드 환경 구성을 통해 해결
• 클라우드 네이티브 애플리케이션: 클라우드 환경을 더 잘 활용할 수 있는 애플리케이션 구조

 

1. MSA
   트래픽 증가에 빠르게 대처하기 위해서 애플리케이션이 MSA 구조로 개발되어야 한다.
2. 컨테이너(Container)
   컨테이너를 활용해 실행 환경에 종속되지 않는 동작이 보장되어야 한다.
3. 상태비저장(Stateless)
   애플리케이션 서버는 상태를 가지지 않아야 한다.
   상태를 가지지 않는 애플리케이션은 어디에나 즉시 배포될 수 있다.
4. DevOps 및 CI/CD
   배포가 자동화되어야 하고 빠르게 릴리즈가 수행되어야 한다.

서버를 구성하는 것은 이런 모든 과정의 시작점에 불과하다. 핵심은 클라우드가 아닌 애플리케이션에 있다. 애플리케이션이 클라우드에 적합하지 않으면 클라우드를 사용하는 것은 크게 의미가 없을 수 있다. 클라우드 네이티브에 대한 개념은 여기서 출발했다. 클라우드 네이티브는 클라우드 환경을 더 잘 활용할 수 있는 애플리케이션 구조를 의미한다. 그러면 어떤 애플리케이션을 클라우드 네이티브 애플리케이션이라고 부르는가?

 

다양한 요인들이 있지만 강의와 연관된 부분을 위주로 설명한다. 첫 번째로 MSA이다. MSA에 대해서는 다음 장표에서 자세하게 다룰 것이다. 간단하게 말씀드리자면 MSA는 애플리케이션을 여러 단위로 분리해서 트래픽 증가에 효율적으로 대처하기 위한 소프트웨어 아키텍처이다.

 

두 번째로 컨테이너이다. 컨테이너의 이미지에는 소프트웨어가 실행하기 위한 환경들이 모두 포함되어 있다. 이 이미지를 가지고 있으면 어떤 환경에서든 동일한 실행 동작을 보장할 수 있다. 아까 클라우드를 사용하면 서버를 여러 곳에 운영할 수 있다고 언급했다. 이런 특성을 잘 활용하려면 컨테이너를 필수로 활용해야 하는 것이다. 컨테이너를 사용하지 않으면 각각의 서버의 프로그램을 별도로 운영해야 하고 결국 환경에 불일치 문제가 발생할 가능성이 커진다.

 

다음으로 상태 비저장이다. 애플리케이션 자체는 상태를 가지지 않아야 한다. 상태를 가질 경우에는 외부의 이 상태가 분리되어 있어야 한다. 상태를 가진다는 것은 결국 각각의 서버가 다르게 동작할 수 있다는 것을 의미하기 때문이다. 상태를 가지지 않아야 언제 어디서나 빠르게 배포될 수 있고 여러 대의 서버가 동시에 같은 역할을 하도록 운영할 수 있다. 이미지를 컨테이너로 실행할 때 컨테이너에 읽기쓰기 레이어가 생기는 것이 기억날 것이다. 그리고 컨테이너를 삭제하면 이 읽기쓰기 레이어도 함께 제거되었다. 컨테이너는 태생적으로 상태 비저장의 특징을 가지고 있다. 컨테이너를 사용한다는 것은 스테이트리스한 상태 비저장 형태로 운영한다는 것을 의미한다. 

 

The Twelve-Factor App (한국어)

유명한 자료로 12Factors라는 자료가 있다. 12Factors는 클라우드 환경에서 운영하는 애플리케이션의 요구 사항에 대해서 잘 정리해 놓았다. 강의 자료 아래의 링크로 들어가 보면 한글화도 잘 되어 있다.

 

5. MSA

모놀리식과 마이크로서비스아키텍처

 

다음으로 마이크로 서비스 아키텍처, MSA에 대해서 학습한다. 애플리케이션을 개발할 때, 예전에는 모든 기능을 하나의 애플리케이션에 구성했다. 이런 전통적인 방식을 모놀리식 방식이라고 부른다. 이 경우에는 하나의 애플리케이션의 크기가 커지기 때문에 이 애플리케이션을 실행하는데 시간이 오래 걸리게 된다. 트래픽이 증가할 때는 이 트래픽을 받을 수 있는 새로운 서버를 증가시켜야 하는데 이 서버의 실행 시간이 길어지면 그만큼 트래픽에 대처할 수 있는 능력도 떨어지게 된다. 그리고 하나의 애플리케이션이 크면 클수록 개발에 들어가는 빌드 시간이나 배포 시간이 오래 걸리게 된다. 그리고 실제로 트래픽이 사용하는 기능이 주문 기능이라고 생각해보면 이 애플리케이션 하나에는 실제로 증가가 필요하지 않은 결제나 상품관리, 회원관리 같은 기능들도 포함되어 있기 때문에 서버를 한 대 늘릴 때마다 비효율적으로 리소스를 사용하게 된다. 이에 반해서 MSA는 도메인이나 기능별로 여러 개의 모듈로 분리해서 서버를 배포한다.

 

이 서버들은 각각 트래픽을 수용한다. 그래서 주문 트래픽이 늘어날 경우에는 주문 기능을 가진 모듈만 증가시키면 된다. 각각의 모듈이 크기가 작아졌기 때문에 개발도 간편해지고 서버를 스케일아웃하는 시간도 빨라진다. 여기서 서버를 스케일아웃한다는 것은 서버의 대수를 늘려서 트래픽에 대처한다는 것을 의미한다.

 

반대로 '스케일인(Scale In)'은 서버의 개수를 줄이는 것을 말한다. 그리고 모듈별로 완전히 독립되어 있기 때문에 각각의 모듈들이 서로 다른 언어를 사용해서 개발이 가능하다는 장점이 있다. 그리고 서비스에 기능 장애가 발생할 때도 보통 모듈 단위로 발생하기 때문에 하나의 기능 에러로 인해서 모든 서비스에 영향이 끼치는 문제를 방지할 수 있다.

 

모놀리식 그리고 마이크로서비스 아키텍처의 특징

 

모놀리식 구조와 MSA 구조의 장단점을 표로 비교보자. 먼저 모놀리식은 단일 코드 베이스와 단일 애플리케이션으로 개발된다. MSA는 기능별로 독립된 여러 개의 서비스가 존재한다. 그래서 모놀리식 아키텍처는 한 번 배포할 때 전체 코드를 다시 배포해야 한다. MSA는 변경된 모듈만 따로 배포할 수 있다. 그리고 모놀리식은 서버를 여러 대 두는 것이 비효율적이기 때문에 보통 서버 한 대의 리소스를 증가시키는 수직 확장, 스케일 업 방식을 사용한다. MSA 같은 경우는 서버의 대수를 늘리는 수평 확장, 스케일 아웃 방식을 활용한다. 그리고 모놀리식 아키텍처는 상대적으로 개발 난이도가 낮다. 그래서 초반에 개발하는 속도가 빠르다. 하지만 프로젝트가 커지면 커질수록 전반적인 파악이 어려워지고 개발 속도도 느려진다는 단점이 있다. MSA 같은 경우는 초기에 구성하는데 시간이 오래 걸리고 아키텍처가 복잡해진다는 단점이 있다. 그리고 장애가 발생했을 때는 모놀리식 아키텍처는 전체 애플리케이션이 영향을 받게 된다. MSA에서는 문제가 발생한 기능만 장애가 발생하게 된다. 그리고 모놀리식은 일반적으로 하나의 스택을 채용해서 개발이 이루어진다. MSA 같은 경우는 서비스 별로 다양한 기술 스택을 활용할 수 있다. 모놀리식은 유지보수에 있어서 전체 소스코드가 유기적으로 연관되어 있기 때문에 전반적인 소스코드의 이해가 필요하고 그래서 이 전체 모듈을 이해하는데 시간이 오래 걸린다.

 

하지만 MSA 같은 경우 각각의 서비스가 일단 독립적으로 동작하는 것이 보장되어 있기 때문에 개발자는 하나의 서비스에 대한 부분만 파악해도 된다. 하지만 MSA의 가장 큰 단점이 서버의 대수가 늘어나기 때문에 전반적인 리소스 사용량이 늘어난다. 그리고 하나의 애플리케이션만 있는 것보다 모든 서버들이 직접 통신해야 되기 때문에 이러한 네트워크 통신도 관리해야 되고 각각의 서버들의 데이터의 일관성 유지 이슈도 있기 때문에 상대적으로 모놀리식 아키텍처보다 복잡도가 매우 높아진다.

 

그럼에도 불구하고 잘 활용하기만 하면 클라우드 네이티브 애플리케이션으로서 가질 수 있는 장점이 더 크기 때문에 MSA로 많이 전환하는 추세이다. 정리하자면 MSA는 클라우드 네이티브 애플리케이션에 잘 어울리는 소프트웨어 구조이다. MSA 아키텍처의 장점을 잘 활용하기 위해서는 컨테이너를 활용하는 것이 필수이다.

 

이번 시간에는 클라우드의 개념과 클라우드 네이티브 애플리케이션의 특성에 대해서 정리했다. 강의를 수강하면서 컨테이너의 사용 방법을 익히는 것도 중요하지만, 컨테이너 기술이 왜 사용되고 왜 주목받고 있는지 그리고 컨테이너가 어디에 어떻게 적용될 수 있는지 이해하시는 것도 중요하다. 다음 시간부터는 실제로 컨테이너화 돼서 개발되어 있는 Leafy 애플리케이션을 구축해보자.