고가용성이란HA(High Availability) 아키텍처는 말 그대로 고가용성 아키텍처를 의미합니다. 여기서 가용성이란 시스템이 정상적으로 사용가능한 정도를 의미하는 말입니다. 즉, 전체 시간 중 시스템이 다운되지 않고 정상적으로 사용가능한 시간의 비율입니다.현대 서비스에서 가용성은 직접적인 매출과도 관련된 중요한 속성입니다. 예를 들어 시간 당 1억씩 버는 쇼핑몰의 경우 1시간 동안 장애가 발생하면 1억의 손실이 발생하게 됩니다. 또한 할인 이벤트와 같이 서비스에서 중요한 순간에 장애가 발생하면 매출뿐만이 아니라 사용자의 경험에 안 좋은 영향을 주어 기회비용까지 잃게 됩니다. 즉, 브랜드 신뢰도와도 연관된 성질입니다. 이런 가용성을 백분율로 표시해놓은 수치가 있습니다. 아래 표는 위키피디아에서 가져왔..

들어가며이전에 작성한 글에서 최종적 일관성에 대해서 알아봤습니다. 분산 시스템에서는 각 시스템간의 디커플링을 지원하기 위해 이벤트 기반으로 동작합니다. 각각의 서비스에서 이벤트를 발행하고 다른 서비스에서 해당 이벤트를 받아서 처리하죠. 그렇다면 여기서 이 이벤트는 어떻게 다른 서비스로 전달이 되는 걸까요?분산 시스템을 공부해보셨다면 메시지 큐라는 단어를 들어보셨을 겁니다. 이런 메시지 큐와 같은 메시징 시스템을 통해 이벤트(메시지)를 주고 받을 수 있는 것 입니다.메시징 시스템은 세 가지 주요 패턴을 가지고 있습니다.메시지 큐: 1:1 통신이며 메시지를 1번만 소비합니다.Pub/Sub(발행/구독): 1:N 통신이며 하나의 메시지를 여러 구독자가 소비합니다.Event Stream(이벤트 스트림): 순서가 ..

들어가기실시간성을 지원하는 서비스에서는 모든 데이터가 항상 완벽하게 일치되지 않는 상황이 있습니다. 예를 들어 SNS에서 누군가가 게시글을 업로드 했을 때, 친구 목록에는 바로 뜨지 않지만 몇 초 후에 보이는 경우가 있습니다. 이것을 최종적 일관성이라고 합니다.이 글에서는 최종적 일관성이 무엇인지, 최종적 일관성을 바탕으로 시스템을 어떻게 설계할 수 있을지에 대해 설명하려고 합니다.최종적 일관성이란분산 시스템에서 최종적 일관성이란 시스템의 각 부분이 특정 시점에서는 서로 다른 데이터 상태를 가지고 있을 수 있단 것을 의미합니다. 하지만 추가적인 업데이트가 발생하지 않는다면 시스템은 모든 구성 요소가 최종적으로는 동일한 상태가 될 것을 보장합니다.즉, 최종적 일관성을 기반으로 설계된 시스템은 노드 간의 순..

SlackSlack은 메신저 및 프로젝트 관리용 협업툴입니다. 원래 Slack은 처음부터 상업용으로 개발한 것이 아니고 타이니 스펙이라는 회사에서 Glitch라는 온라인 MMORPG 게임을 만들던 중 팀 커뮤니케이션을 위해 개발한 사내 도구였습니다. 하지만 Glitch가 실패하고 대신 협업 툴로 개발한 Slack을 발표했습니다. 그리고 막대한 성공을 거뒀습니다. 지금은 하루에만 억단위의 메시지를 전송하는 많은 사용자를 지니고 있습니다.이제 Slack이 이런 메시지들을 안정적으로 처리하기 위해 시도한 내용들을 정리하려고 합니다.초기 아키텍처Slack은 초기부터 서버를 2개로 나누었습니다. 하나는 인증, 권한, API 엔드포인트, 세션 관리 등 대부분의 애플리케이션 로직을 담당하는 Web App, 다른 하나..

마이크로 서비스일반적으로 프로젝트를 진행하게 되면 하나의 서버에 모든 서비스 코드가 들어가게 됩니다. 이런 방식을 모놀리식 아키텍쳐라고 부릅니다. 모놀리식 아키텍쳐는 개발에는 용이하지만 이후에 서비스가 성공하여 규모가 매우 커지게 되면 여러 문제점이 발생할 수 있습니다.유연성 저하 : 간단한 수정 사항에도 전체 애플리케이션을 다시 빌드하고 배포해야 합니다.확장성 한계 : 특정 기능에만 부하가 증가해도 해당 기능만 확장하는 것이 아닌 전체 애플리케이션을 확장해야 합니다.기술 선택의 제약 : 전체 애플리케이션을 하나의 기술 스택으로 구현해야 하기 때문에 기술 도입이나 부분적인 기술 변경에 제약이 있습니다.장애의 영향 범위 확대 : 특정 기능의 장애가 전체 애플리케이션의 장애로 이어질 수 있습니다.이런 문제점..

1. 캐싱이란캐싱이란 자주 사용되는 데이터의 복사본을 캐시 또는 임시 저장 위치에 저장하여 빠르게 접근할 수 있도록 하는 프로세스를 의미합니다.왜 사용할까클라이언트에서 서버에 데이터를 요청하거나 서버에서 DB의 데이터를 읽어오는 등 데이터를 받아올 때는 항상 일정 리소스가 소모됩니다. 그래서 원래의 데이터보다 더 빠르게 접근이 가능한 곳에 복사본을 위치시켜 리소스를 줄이고 응답 시간을 향상 시키기 위해 캐싱을 사용하게 됩니다. 보통 Redis를 활용하여 캐싱을 사용합니다. 2. 캐싱 전략1) 읽기 전략 (Read Strategies)Look Aside데이터를 찾을 때 캐시에 데이터가 있는지 먼저 확인한 후 만약 캐시에 데이터가 없으면 DB에서 조회하는 전략입니다. 읽기 작업이 빈번한 경우에 적합하지만 데..

1. 로드 밸런싱이란로드 밸런싱은 애플리케이션을 지원하는 리소스 풀에 들어오는 네트워크 트래픽(들어오는 요청)을 균등하게 분산하는 것을 의미합니다. 간단히 비유하면 은행에서 고객들(네트워크 트래픽)을 대기 번호표를 뽑게 한 뒤 여러개의 창구(서버)에서 각 고객의 업무를 처리한다고 볼 수 있을 것 같습니다.왜 필요할까?대부분의 간단한 프로젝트에서는 요청이 많이 들어올 일이 거의 없습니다. 그래서 한 대의 서버로도 충분히 트래픽을 감당할 수 있습니다. 하지만 커다란 서비스(토스, 배민, 네이버, 등...)에서는 매우 많은 요청이 들어오기 때문에 한 대의 서버로는 그 트래픽을 감당하기 힘듭니다. 그래서 여러 대의 서버를 구축해 트래픽을 나눠서 서버 1대가 처리하는 트래픽을 줄이기 위해 로드 밸런싱을 사용합니다..

일반적인 시스템 설계일반적으로 개인이나 동아리 or 부트캠프에서 프로젝트를 진행하게 되면 서버 1대, DB 1대를 둔 아래와 같은 설계를 따릅니다.대부분의 개인이나 팀으로 이뤄지는 프로젝트는 많은 트래픽이 발생하지 않습니다. 1대의 서버로도 충분히 감당할 수 있을 정도로요.하지만 갑자기 프로젝트가 알려지면서 트래픽이 몰리면 어떻게 될까요? 각 서버는 성능에 따라 처리할 수 있는 트래픽의 양이 한정되어 있습니다. 그래서 과도한 트래픽을 받게 되면 서버에 장애가 발생할 수 있습니다.만약 복잡한 것이 싫다면 이런 상황에서 서버의 성능을 올리는 것으로 간단하게 해결할 수 있습니다. 더 좋은 CPU나 RAM을 가진 서버로 업그레이드를 하면 더 많은 트래픽을 처리할 수 있습니다. 이를 Scale Up이라고 부릅니다..