회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
여러분은 서버를 어디에 배포하나요? 10년 전만 해도 IDC 환경 혹은, IDC에 배포된 서버를 호스팅하고 관리하는 서버 호스팅이 가장 일반적인 방법이었습니다. 그러나 10년 사이, 수많은 IT 기업이 클라우드 전환을 마쳤습니다. 특히 스타트업은 물어볼 필요도 없이 클라우드 환경이 당연한 시기가 왔습니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
여러분은 서버를 어디에 배포하나요? 10년 전만 해도 IDC 환경 혹은, IDC에 배포된 서버를 호스팅하고 관리하는 서버 호스팅이 가장 일반적인 방법이었습니다. 그러나 10년 사이, 수많은 IT 기업이 클라우드 전환을 마쳤습니다. 특히 스타트업은 물어볼 필요도 없이 클라우드 환경이 당연한 시기가 왔습니다.
이러한 클라우드 환경이 가져다준 변화 중 하나는 바로 배포와 확장의 유연함입니다.
물론 과거에도 배포를 편리하게 개선하고자 하는 노력이 없었던 것은 아닙니다. 그러나 클라우드 기반 환경에서 발생하는 여러 니즈를 수용하며 유연성은 더 빠르게 발전했죠. 배포만이 아니라 다양한 접근에 대한 유연함, 트래픽 소화량 등 발전 경험 역시 축적되었습니다. 이에 따라 다른 디자인 패턴이 그래왔듯, 클라우드 디자인 사례들 역시 패턴화되었습니다.
그렇다면 클라우드 디자인 패턴이란 무엇이며, 어떻게 써야 하는지 한번 알아봅시다.
불과 10년 전, 서비스를 운영하려면 IDC에 서버를 세팅하거나, 서버 호스팅 업체를 이용해야 했습니다. 하지만 지금은 특정 도메인의 회사나 클라우드 서비스를 직접 운용하는 몇몇 기업을 제외하고, 대부분이 글로벌 클라우드 서비스를 이용한다고 봐도 무방한 시대입니다.
클라우드 환경이 가져다주는 장점은 유연함에 있습니다. 서버 호스팅, IDC 서버 운용 대비 서비스의 운용과 자원 할당, 반납이 매우 유연하죠.
반납이야 비용 효율을 주니 당연한 장점이지만, 다른 부분은 어떤 이점을 줄까요? 과거에는 서버를 늘리려면 서버를 구매하거나 서버 호스팅 업체에 연락해야 했습니다. 또한 이들이 세팅을 완료할 때까지 일단 대기해야 했죠. 만약 서버 호스팅 회사에 유휴 머신이 없는 등 이유로 세팅이 오래 걸리면 확장 자체에 어려움이 많았습니다.
그래서 당시에는 일정 트래픽 이상 유입을 아예 차단하거나, 수용할 수 있는 트래픽을 넘겨 서비스에 장애가 일어나는 일이 지금보다 많았습니다. 이처럼 트래픽이 몰리는 상황을 대비하는 것이 물리적으로 어렵기 때문에, 이를 막는 아키텍처를 짜기보다 예상 범위 내 트래픽을 잘 소화하는 데 집중하기도 했죠.
이제는 상황이 다릅니다. 클라우드 환경이 일반화되었기 때문입니다. 그에 따라 클라우드 환경에 적절한 경험들 역시 쌓였습니다. 이를 다시 클라우드 디자인 패턴이라는 이름으로 정의하기 시작한 것이죠.
보통 디자인 패턴이 그렇듯, 클라우드 디자인 패턴 역시 클라우드 환경에서의 경험과 노하우가 축적되어 패턴으로 굳어졌습니다.
넷플릭스를 비롯한 많은 기업이 MSA로 아키텍처를 바꾸며 변화가 일어났습니다. 이제는 널리 알려진 넷플릭스 줄(Netflix Zuul)을 비롯한 API 게이트웨이, 히스트릭스(Hystrix)를 이용한 서킷 브레이커(Circuit Breaker), 많은 사람들이 알고 쓰고 있는 Pub/Sub 같은 것들 모두 클라우드 디자인 패턴입니다.
즉, 클라우드 디자인 패턴이란 클라우드 환경에서 특정한 상황의 문제를 해결하는 방법들을 모아 이름 붙인 것이라고 봐도 무방합니다.
다시 말해 우리가 마주할 클라우드 환경에서, 이미 많은 사람이 마주친 문제를 풀어줄 방법들이라는 것이죠. 이러한 패턴을 알아두면 우리가 겪을 문제를 대비할 수 있을 것입니다.
이러한 상황에 맞춰 최근 클라우드 디자인 패턴을 적절히 적용하는 개발자의 수요가 높아지고 있습니다. 이를 잘 아는 개발자는 클라우드 환경의 장점을 극대화시키고, 단점은 최소화할 수 있습니다. 디자인 패턴을 적절히 적용한다는 것은 서비스의 확장성, 장애 방지, 장애 대응, 모니터링 등 아주 다양한 관점에서의 역량을 지녔다는 것을 말하기 때문이죠.
그래서 우리는 클라우드 디자인 패턴을 알아야 합니다. 또 적재적소에 이를 잘 적용하는 전략 역시 가져가야 합니다.
무엇보다 이 디자인 패턴은 장애 방지와 대응 측면에서 아주 큰 의미를 지닙니다.
일반적인 디자인 패턴은 코드 작성 과정의 효율이나 성능 이슈 해결에 주로 초점을 둡니다. 그러나 클라우드 디자인 패턴은 그 환경의 특징 때문인지 가용성, 분산 처리, 장애 대응, 장애 방지 측면의 주제가 많습니다.
또한 클라우드 환경에 대한 이해도를 높이는 데에도 도움을 줍니다.
결국 이 디자인 패턴은 클라우드 환경의 문제를 해결하기 위해 나왔습니다. 그러니 환경의 특징과 주요 사례를 살펴볼 아주 좋은 수단이기도 합니다.
클라우드 디자인 패턴은 아주 다양합니다. Pub/Sub 패턴, 사이드카 패턴, 정적 콘텐츠 호스팅 패턴, 제한 (RateLimit) 패턴, 사가 패턴, 인덱스 테이블 패턴, 게이트웨이 집계 패턴, 이벤트 소싱 패턴 등이 대표적이죠. 마이크로소프트가 운영하는 애저(Azure)의 클라우드 디자인 패턴 문서등에서 많은 정보를 확인할 수 있을 것입니다.
물론 글을 쓰고 있는 지금도 많은 개발자가 클라우드 환경에서의 인사이트를 쌓고 있습니다. 이러한 노하우가 공유되고 널리 퍼지면 또 다른 패턴이 만들어질 것입니다. 그러니 이번 글에서 살펴볼 패턴은 모든 클라우드 디자인 패턴이 아닙니다. 애저가 정리한 내용 역시 모든 클라우드 디자인 패턴을 나열한 것이 아니라는 점에 유의해 주세요.
안정성 관련 디자인 패턴은 시스템이 예기치 않은 상황에서도 멈추지 않고 동작하는 것에 집중하는 패턴입니다. 서킷 브레이커, 벌크헤드, 재시도 패턴을 살펴봅시다.
1. 서킷 브레이커(Circuit Breaker)
서킷 브레이커 패턴은 시스템이 연쇄적으로 실패하지 않도록 하는 중요한 패턴입니다.
사례
7.8K
넷플릭스 히스트릭스(Netflix Hystrix): 히스트릭스는 서킷 브레이커 패턴을 구현한 대표적인 예시입니다. 외부 서비스 호출이 실패할 경우, 서비스의 연쇄적인 장애를 방지하는 것에 집중합니다.
장점
① 장애 격리: 서킷 브레이커가 발동하면 문제가 있는 서비스 호출을 중단합니다. 이로 다른 서비스에 영향을 미치는 것을 막을 수 있습니다.
② 빠른 실패(Fail-Fast): 실패를 빠르게 감지하면 리소스를 낭비하지 않습니다.
③ 자동 복구: 일정 시간이 지나면 다시 동작을 시도하며 서비스가 정상화되었는지 확인하고, 회로를 재설정할 수 있습니다.
2. 벌크헤드(Bulkhead)
벌크헤드 패턴은 시스템의 리소스를 분리합니다. 구성 요소 하나가 실패해도 전체 시스템에 영향을 미치지 않기 위해서죠.
사례
아마존(Amazon): 아마존은 특히 서비스에 벌크헤드 패턴을 적극 적용합니다. 여러 서비스와 각 서비스의 구성 요소들이 독립적으로 운영될 수 있도록요.
장점
① 자원 격리: 각 서비스나 구성 요소가 자신의 리소스를 독립적으로 관리하며, 다른 서비스의 장애로 인한 영향을 최소화합니다.
② 안정성 향상: 하나의 서비스나 구성 요소의 장애가 전체 시스템으로 확산되는 것을 막아줍니다.
3. 재시도(Retry)
재시도 패턴은 일시적인 오류가 발생했을 때, 시스템이 자동으로 재시도하며 안정성을 높이는 패턴입니다.
사례
AWS SDK: AWS SDK는 네트워크에 문제가 있거나 일시적으로 오류가 발생하면 자동으로 재시도를 수행합니다. 이로써 안정성을 보장하죠.
장점
① 오류 복구: 일시적인 네트워크 오류, 서비스 과부하를 시스템이 자동으로 극복할 수 있습니다.
② 안정성 증가: 재시도로 서비스의 가용성과 신뢰성을 높일 수 있습니다.
신뢰성 패턴은 시스템이 일관성을 가지며 정확하게 동작하도록 보장하는 패턴입니다. 헬스 체크, 스로틀링, 리더 선출 패턴을 대표로 보겠습니다.
1. 헬스 체크(Health Endpoint Monitoring)
헬스 체크 패턴은 시스템의 상태를 지속적으로 모니터링합니다. 이로써 문제를 조기에 감지하고 대응할 수 있도록 하죠.
사례
쿠버네티스(Kubernetes): 쿠버네티스는 각 컨테이너의 상태를 모니터링하기 위해 헬스 체크 엔드포인트를 사용합니다. 만약 문제가 발생한 컨테이너가 있다면, 이를 자동으로 재시작합니다.
장점
① 실시간 모니터링: 시스템의 상태를 실시간으로 감시하기 때문에, 문제가 발생했을 때 빠르게 대응할 수 있습니다.
② 자동 복구: 이 패턴은 문제 감지와 함께 자동으로 해당 인스턴스를 재시작하거나 대체합니다. 서비스의 신뢰 유지에 큰 도움을 줍니다.
2. 스로틀링(Throttling)
스로틀링 패턴은 시스템이 과부하 상태에 빠지지 않게 하는 데 목적을 둡니다. 요청 수를 제한해 이를 구현하죠.
사례
트위터 API(Twitter API): 트위터 API는 사용자가 일정 시간 내에 보낼 수 있는 요청 수를 제한합니다. 서비스가 과부하에 빠지지 않도록 하기 위함입니다.
장점
① 서비스 보호: 과도한 요청은 시스템 과부하를 불러옵니다. 이를 막으면 안정적인 서비스 제공을 보장할 수 있습니다.
② 품질 유지: 요청을 제한하면 모든 사용자가 일정한 품질로 서비스를 이용할 수 있습니다.
3. 리더 선출(Leader Election)
리더는 분산 시스템에서 중요한 작업을 수행합니다. 이 패턴은 그러한 리더를 동적으로 선택하도록 설계되어 있습니다.
사례
아파치 주키퍼(Apache ZooKeeper): 주키퍼는 분산 환경에서 리더를 선출합니다. 리더, 즉 중요한 작업을 수행할 노드를 결정하는 것이죠.
장점
① 고가용성: 동적으로 리더를 뽑도록 설계하면 특정 노드가 실패하더라도 다른 노드가 리더 역할을 인계받습니다. 이는 즉, 서비스가 중단되지 않는다는 것을 의미합니다.
② 안정성 증가: 이 패턴은 분산 환경에서의 안정적인 서비스 운영을 보장합니다.
메시징 패턴은 시스템 간의 통신을 효과적으로 관리하는 데 목적을 둔 패턴입니다. 메시지 큐, Pub/Sub, 이벤트 소싱 패턴을 대표 예시로 보겠습니다.
1. 메시지 큐(Message Queue)
메시지 큐 패턴을 적용하면 메시지들은 비동기로 전달됩니다. 시스템의 확장성과 유연성을 높이는 패턴입니다.
사례
래빗MQ(RabbitMQ): 래빗MQ는 다양한 서비스들 사이 메시지를 비동기적으로 전달합니다. 시스템의 확장성과 유연성을 제공하는 대표적인 소프트웨어입니다.
장점
① 비동기 처리: 요청과 응답을 비동기로 처리하면, 시스템의 유연성이 높아집니다.
② 부하 분산: 큐로 메시지를 분산하면, 시스템의 부하를 조절할 수 있습니다.
2. Pub/Sub(Publisher-Subscriber)
Pub/Sub 패턴은 한 개의 발행자(Publisher)가 여러 구독자(Subscriber)에게 메시지를 전달하는 구조의 패턴입니다.
사례
아파치 카프카(Apache Kafka): 카프카는 Pub/Sub 패턴으로 대규모 이벤트 스트리밍을 처리할 수 있습니다.
장점
① 확장성: 아주 많은 구독자가 동시에 메시지를 받을 수 있는 구조로 확장성이 뛰어납니다.
② 느슨한 결합: 발행자와 구독자는 서로 느슨하게 결합하고 있습니다. 이는 시스템 유연성을 높여 줍니다.
3. 이벤트 소싱(Event Sourcing)
이벤트 소싱 패턴은 시스템의 상태 변화를 이벤트로 기록합니다. 이로써 모든 상태 변화를 추적할 수 있죠.
사례
이벤트스토어(EventStore): 이벤트스토어는 이벤트 소싱 패턴을 사용하여 모든 상태 변화를 이벤트로 저장합니다. 이를 기반으로 시스템의 상태를 재구성합니다.
장점
① 데이터 일관성: 모든 상태 변경이 이벤트로 기록되면 데이터 일관성을 유지할 수 있습니다.
② 감사 가능성: 이벤트 로그로 시스템의 모든 상태 변경을 추적할 수 있습니다.
③ 복구 용이성: 과거 이벤트를 재생하면 시스템 상태를 특정 시점으로 복구할 수 있습니다.
클라우드 디자인 패턴을 보다 보면 알아야 할 다양한 개념에 대한 이해도를 높일 수 있습니다. 디자인 패턴의 핵심은 이미 수많은 사람이 쌓아온 인사이트에서 내가 앞으로 겪을 문제에 대한 대응을 배울 좋은 방법이라는 점입니다.
패턴이 여러 백엔드 엔지니어가 경험한 뒤에야 알 수 있었던 분산 처리, 장애 대응, 장애 방지, 모니터링과 같은 주제에 몰려 있다는 측면도 중요합니다. 지금 당장 완벽히 흡수하기는 어렵더라도 살펴보기를 권장합니다. 언젠가는 큰 도움이 될 수 있으니까요. 이번 글이 클라우드 디자인 패턴 공부의 첫 시작이 되면 좋겠습니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
좋아요
댓글
공유
공유
