Mimi.log

  멈추지 않는 서비스의 비밀, 고가용성(HA) "서버가 죽었습니다." IT 담당자에게 이보다 끔찍한 말은 없을 것입니다. 서비스 중단은 곧 매출 하락과 신뢰도 추락으로 이어지기 때문입니다. 이를 방지하기 위해 시스템이 24시간 365일 정상적으로 운영되도록 설계하는 것을 고가용성(HA, High Availability) 이라고 합니다. HA 아키텍처의 기본 원리는 간단합니다. '하나가 고장 나면 다른 하나가 대신한다'는 이중화(Redundancy) 입니다. 하지만 이 두 개의 시스템을 평소에 어떻게 운영하느냐에 따라 전략은 크게 두 가지로 나뉩니다. 바로 Active-Active 와 Active-Standby 입니다. 1. Active-Standby: 든든한 예비군 전략 가장 전통적이고 보편적인 방식입니다. '주(Primary) - 부(Secondary)' 구조라고도 불립니다. 작동 원리 평상시에는 메인 서버(Active)만 트래픽을 처리하고, 대기 서버(Standby)는 가동 중이지만 실제 트래픽은 받지 않는 상태로 대기합니다. Active 서버와 Standby 서버는 실시간으로 데이터를 동기화(Replication)하며 서로의 상태를 주기적으로 확인(Heartbeat)합니다. 만약 Active 서버에 장애가 발생하면, 시스템이 이를 감지하고 즉시 Standby 서버를 Active 상태로 전환하여 서비스를 이어받습니다. 이를 페일오버(Failover) 라고 합니다. 장점 구축 용이성: 구조가 단순하여 설계 및 구현이 비교적 쉽습니다. 데이터 정합성: 하나의 서버에서만 데이터를 쓰기 때문에 데이터 충돌 문제가 거의 발생하지 않습니다. 비용 절감: Standby 서버는 트래픽을 처리하지 않으므로, 상황에 따라 Active 서버보다 낮은 사양으로 구성하거나 전원을 꺼두는(Cold Standby) 방식으로 비용을 아낄 수 있습니다. (단, 즉각적인 복구를 위해선 Hot Standby가...

  트래픽 폭주, 서버가 버티는 비결 웹 서비스 운영 중 사용자가 급격히 늘어날 때, 단 한 대의 서버로는 모든 요청을 처리할 수 없습니다. 이때 등장하는 구세주가 바로 로드 밸런서(Load Balancer) 입니다. AWS의 ELB(Elastic Load Balancing)나 ALB(Application Load Balancer)가 대표적인 예입니다. 로드 밸런서는 들어오는 트래픽을 여러 대의 서버(EC2 등)에 골고루 나눠주는 교통경찰 역할을 합니다. 하지만 무턱대고 나누는 것이 아닙니다. ' 어떤 규칙'으로 나눌 것인가 에 따라 서비스의 안정성과 속도가 완전히 달라집니다. 오늘은 가장 대표적인 두 가지 알고리즘, 라운드 로빈(Round Robin) 과 리스트 커넥션(Least Connection) 을 비교 분석해 봅니다. 1. 라운드 로빈(Round Robin): 공평하게 순서대로 가장 기본적이고 직관적인 방식입니다. ' 순차적 분산' 이라고도 부릅니다. 작동 원리 마치 카드 게임에서 딜러가 플레이어들에게 카드를 한 장씩 순서대로 나눠주는 것과 같습니다. 서버가 A, B, C 세 대가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C, 네 번째는 다시 A에게 보냅니다. 현재 서버의 상태나 부하량은 고려하지 않고 오직 순서 에만 입각해 트래픽을 배분합니다. 장점 단순함: 구현이 매우 쉽고 이해하기 편합니다. 리소스 소모 적음: 로드 밸런서가 복잡한 계산을 할 필요가 없어 자체 부하가 적습니다. 동일 환경에 유리: 모든 서버의 스펙이 동일하고, 처리해야 할 요청의 성격(처리 시간)이 비슷할 때 가장 효율적입니다. 단점 부하 불균형: 어떤 요청은 1초 만에 끝나지만, 어떤 요청은 1분이 걸릴 수 있습니다. 라운드 로빈은 이를 무시하고 계속 요청을 보내기 때문에, 운 나쁘게 무거운 작업만 할당받은 특정 서버가 과부하로 뻗어버릴 수 있습니다. 2. 리스트 커넥션(Least Con...

  클라우드 보안의 시작, 네트워크 격리 클라우드 인프라를 구축할 때 가장 먼저 마주하는 용어 중 하나가 바로 VPC(Virtual Private Cloud) 입니다. VPC는 클라우드 내에 만드는 우리만의 가상 데이터 센터입니다. 하지만 단순히 VPC를 만들었다고 끝이 아닙니다. 이 거대한 공간을 어떻게 쪼개고(Subnetting), 어떤 용도로 사용할지 결정하는 것이 보안과 효율성을 좌우합니다. 많은 초보 설계자가 범하는 실수는 모든 리소스를 인터넷에 노출된 하나의 서브넷에 몰아넣는 것입니다. 이는 마치 현관문 없이 금고를 길거리에 두는 것과 같습니다. 오늘은 안전하고 튼튼한 인프라를 위해 서브넷을 퍼블릭(Public)과 프라이빗(Private)으로 나누는 결정적 기준을 알아보겠습니다. 1. 서브넷 분리의 핵심 원리: 라우팅 테이블과 인터넷 게이트웨이 퍼블릭과 프라이빗을 나누는 기준은 물리적인 위치가 아닙니다. 바로 ‘인터넷과 직접 통신할 수 있는가?’ 입니다. 이를 기술적으로 결정하는 것은 라우팅 테이블(Routing Table) 설정입니다. 퍼블릭 서브넷: 라우팅 테이블이 인터넷 게이트웨이(IGW, Internet Gateway) 를 향해 열려 있습니다. 외부에서 들어오는 트래픽을 직접 받을 수 있고, 내부에서 밖으로 나갈 수도 있습니다. 프라이빗 서브넷: 인터넷 게이트웨이로 가는 경로가 없습니다. 외부에서 직접 접근할 수 없으며, 내부IP(Private IP)로만 통신합니다. 2. 퍼블릭 서브넷(Public Subnet): 외부와 소통하는 접점 퍼블릭 서브넷은 외부 사용자의 요청을 가장 먼저 받아내는 '안내 데스크' 역할을 합니다. 따라서 반드시 외부 인터넷 접근이 필요한 리소스 만 이곳에 배치해야 합니다. 퍼블릭 서브넷 배치 기준 로드 밸런서 (Load Balancer, ALB/NLB): 사용자의 트래픽을 받아 뒷단의 서버로 분산시켜주는 역할을 하므로 반드시 공인 IP를 가지고 외부에 노출되어야 합니다. 배...

기업의 운명을 가르는 선택, 인프라 아키텍처 디지털 전환(DX)이 가속화되면서 모든 기업은 중요한 기로에 서 있습니다. 바로 "데이터와 시스템을 어디에 둘 것인가?"라는 질문입니다. 과거에는 회사 내부에 서버실을 구축하는 것이 당연했지만, 이제는 클라우드가 강력한 대안으로 자리 잡았습니다. 하지만 무조건적인 클라우드 전환이 정답은 아닙니다. 이 글에서는 IT 인프라의 두 축인 온프레미스(On-Premise) 와 클라우드(Cloud) 의 개념을 명확히 하고, 의사 결정에 꼭 필요한 5가지 결정적 차이를 분석해 드립니다. 1. 개념의 차이: 소유할 것인가, 빌려 쓸 것인가? 본격적인 비교에 앞서 두 개념을 가장 쉽게 이해하는 방법은 '부동산'에 비유하는 것입니다. 온프레미스(On-Premise): 직접 땅을 사고 집을 짓는 '자가 주택'과 같습니다. 하드웨어부터 네트워크, 운영체제까지 기업이 직접 구매하여 사내 전산실이나 데이터 센터에 구축하고 운용합니다. 모든 통제권이 나에게 있습니다. 클라우드(Cloud): 필요한 만큼 공간을 빌려 쓰는 '호텔'이나 '공유 오피스'와 같습니다. AWS, Azure, Google Cloud 같은 공급자가 구축해 둔 거대한 인프라 자원을 인터넷을 통해 필요한 만큼 빌려 쓰고, 쓴 만큼 비용을 지불합니다. 2. 비용 구조: 초기 투자비용(CAPEX) vs 운영 비용(OPEX) 가장 큰 차이는 돈을 쓰는 방식에 있습니다. 온프레미스: 초기 투자 중심 (CAPEX) 온프레미스는 시스템 구축 초기에 막대한 자본적 지출(CAPEX)이 발생합니다. 서버, 스토리지, 네트워크 장비를 직접 구매해야 하며, 이를 설치할 공간과 전력, 냉각 시스템도 갖춰야 합니다. 구축 후에는 감가상각을 통해 비용을 처리합니다. 장기적으로 시스템 변경이 거의 없다면 총비용 면에서 유리할 수 있습니다. 클라우드: 운영 비용 중심 (OPEX) 클라우드는 초기 구축비...