본문 바로가기
클라우드

클라우드 아키텍처

by oncerun 2021. 10. 30.
반응형

 

 

포털 서비스, 금융 서비스 등은 사용자가 상시 이용하는 기초 서비스를 제공해야 한다. 즉 1년 365일 동작을 해야 하며, 사용자 접속 불능 시 서비스 품질 및 신뢰도 저하로 이어지면 해당 업체에게 큰 타격이 온다.

 

최근 발생했던 KT 인터넷 사용불가에 대해서 전국적으로 큰 이슈가 됐었다. KT를 사용하는 회사는 일시적으로 업무가 중단되고, 실제 사용자들의 금전적인 피해가 가기도 했다. 

클라우드로 서비스를 제공하는 업체들은 이러한 상황을 막기 위해 무중단 서비스 재배치 클라우드 아키텍처를 고려할 수 있다. 오늘은 무중단 서비스 재배치, 무정지 서비스, 동적 장애 감지 및 복구를 공부한다.

 

[추신]

KT DNS 서버에 트래픽 증가는 있었지만, DDos 공격은 없었다고 나옴.  실제 원인은 부산 국사에서 기업 망 라우터 교체 작업 중 작업자가 잘못된 설정 명령을 입력하였고, 이후 라우팅이 안되어 전국적인 인터넷 네트워크 장애가 발생함. 설정 오류에 따른 장애 발생 과정은 접속 단말 -> 지역 라우터 -> 센터 라우터 등을 거쳐 국내외 네트워크로 연결되는데,
라우터 테이블 업데이트필요.
라우터끼리는 네트워크 경로정보를 구성하기 위해 최신의 경로정보를 라우터끼리 교환하는 프로토콜을 사용.
kt <-> 외부는 BGP 프로토콜, KT 내부는 IS-IS 프로토콜 사용  이후 경로정보를 종합해서 최종 라우팅 경로를 설정함.  이 과정에서 IS-IS 프로토콜 명령어 마무리하는 부분에서 EXIT 명령어 누락으로 BGP프로토콜에서 교환해야 할 경로 정보가 IS-IS 프로토콜로 전송
통상 1만 개 이하의 경로정보를 교환하는 IS-IS 프로토콜에 수십만 개의 BGP 프로토콜 정보가 유입되면서, 라우팅 경로에 오류가 발생.
부산 지역의 잘못된 라우팅 경로가 설정된 이후 다른 지역의 IS-IS 라우터 등에도 잘못된 업데이트 정보가 전송되어 모든 지역 라우터가 잘못된 정보로 네트워크 장애 상황. 

 

작업 상황 : KT 관제에서 야간작업을 승인했지만 주간 작업 수행 -> 장애 발생,  KT 협력업체 작업자들만 구성하여 작업 수행 -> 박살....  ->  사람은 실수를 할 수 있으며, 실수를 방지하기 위해 시스템을 도입한다. 그 시스템에서 검증하지 않았기 때문에 시스템이 잘못한 것이다.  작업자분들 정말 힘드실 텐데 마음에 짐 조금이라도 덜었으면 좋겠다.

 

 

 

[클라우드에서 무중단 서비스를 위한 대응]

 

온프레미스 환경에서는 이중화 서버 구조 구축을 하는 방식을 예를 들 수 있다.  실제 시스템과 동일한 기능을 하는 시스템을 구성하여 무중단 서비스를 대응할 수 있다.

반면 클라우드 환경은 동작중인 서버를 복제하거나, 새 가상 서버를 생성하여 복제하거나, 이중화 구조도 지원한다.

온프레미스 환경보다 좀 더 유연성을 가지면서 무중단 서비스를 대응할 수 있다.

 

다운 타임을 요구하는 작업이 발생하는 경우 가상화 인프라 관리자가 새로운 물리 서버들에 있는 하이퍼바이저에게 새로운 VM을 요구하여, 생성 완료 시 기존 서버에서 동작하는 VM을 복제하여 새로운 VM으로 OS 및 프로그램을 이관하여 사용자들의 요청을 응답하도록 할 수 있다. 

 

클라우드 상의 무중단 서비스 재배치가 갖는 장점

 

1. 안정적인 서비스 이관이 가능해진다.

2. 원본 서버의 정비 작업 완료 시 새 VM을 원본 서버의 VM으로 다시 복제하여 다운 타임을 최소화

3. 사용자의 요청이 클라우드 VM 처리 가능한 용량을 벗어난 경우 로드 밸런서와 네트워크 연결이  자동으로 이루어짐

 

가상 디스크 이관 (저장장치)

 

클라우드 환경에 사용할 수 있는 가상 디스크는 크게 두 가지로 나눌 수 있습니다. 실제 존재하는 스토리지, 원격에 존재하는 가상 스토리지로 나뉠 수 있다.

 

VM에 붙어있는 스토리지가 어떻게 구성되어 있는지에 따라 이관 절차가 달라진다.

 

 가상 서버 디스크가 로컬 스토리지 타입 혹은 비공유 디스크 타입인 경우에는 데이터 이관 시간이 정말 길게 소요된다.  반면 원격 공유디스크에 데이터가 저장되어 이관하는 경우에는 로컬 스토리지 및 비공유 디스크 타입인 경우보다 데이터 이관 시간이 적게 소요되지만, 이관 이후 원격에서 데이터를 읽고 쓰기 때문에 접근 속도가 로컬 디스크에 비해 느릴 수 있다는 단점이 존재한다. 

 

중요한 점은 로컬과 공유 디스크의 적절한 데이터 분배가 중요하다. 빠른 접근이 필요한 OS와 서비스 구동에 필요한 프로그램 코어 파일, 자주 접근되는 데이터 및 데이터베이스 이 외의 데이터는 공유 디스크에 저장한다. 즉 하이브리드로 상황에 맞추어 아키텍처를 구성해야 한다.

 

 

[무정지 서비스]

클라우드라고 해서 서비스 장애가  발생하지 않는 건 아니다. 클라우드 서비스의 장애의 원인으로는 실제 물리 서버의 시스템에 장애가 발생하거나, 장비가 노후되어 응답하지 않고, 하드웨어의 실제적인 고장 등을 들 수 있다.

 그렇기에 온프레미스와 비슷하게 클라우드에서 제공하는 서버들도 이중화가 되어있어야 하는데, 이중화가 되어있지 않는 경우에는 SPOF(Single poing of failure)이 발생한다. SPOF는 시스템 구성 요소가 정상적으로 동작하지 않는 경우 시스템 전체에 영향이 가는 지점 또는 장치를 말한다.

 

 

이러한 SPOF를 방지할 수 있는 아키텍처가 중요하여 장애 방지, 조치 시스템을 구축하여야 한다.

 

장애 방지 시스템 (Fault tolerance system)

 : 시스템의 일부의 결함, 고장이 발생하여도 정상적 혹은 부분적으로 기능을 수행할 수 있는 시스템, 예를 들어 서버 한대에 장애가 발생하여도 로드밸런서에 의해 작업량을 분배하여 시스템 기능을 정상적으로 수행하는 경우이다.

 

장애 조치 시스템 ( Failover system)

 : 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 경우 예비 시스템으로 자동 전환되는 기능을 수행하는 시스템, 예를 들어 로드밸런서, 네트워크 마비 시 대기 중인 서버를 사용하여 동일 기능하는 VM을 복제하여 사용자의 요청을 처리한다.

 

 

 

[동적 장애 감지 및 복구]

 

물리 리소스에 발생하는 장애

 

 - 메모리 에러, 디스크 에러, CPU 에러, 장비 노후로 인한 시스템 크래시

 

방대한 물리 장비들이 배치되어 있는 데이터센터에 장애 발생 시 매번 원인을 찾고 문제를 해결하는 것은 비효율 적이다. 인프라 관리자가 방대한 물리 서버를 일일이 확인하면서 장애 발생 예상을 찾고 교체하는 것은 사실상 불가능하다. 그렇기 때문에 장애 시나리오를 만들고 장애 발생 시 조치 방안에 따라 해결하는 것이 중요하다. 

 

장애 감지 기법으로 유명한 것은 바로 하트비트 모니터링이다 (헬스 체크) 대표적인 설루션 혹은 프로그램은 zoo keeper 등이 있다.

이러한 프로그램은 물리적인 장비에 일정 시간마다 하트비트를 전송하고 응답이 없을 때 장애로 판명하여 장애를 통보하는 방식이다.

 

클라우드 모니터 

 - 가상 서버, 네트워크 장비 등의 클라우드 리소스의 사용량과 이벤트가 발생하는지를 지속적으로 감시하고, 이벤트 발생 시 장애 조치

 

관제 시스템에서는 관찰 및 감시, 이벤트 발생 시 대응 행위 결정, 행우 수행, 보고, 에스컬레이션 순으로 처리된다.

 

에스컬레이션이란 클라우드 모니터가 장애 상황의 심각성에 따라 클라우드 사업자 및 관리자에게 보고하기까지 거치는 절차이다.  

 

에스컬레이션 절차

 

  • 장애 조치 이후 배치 파일 실행
  • 시스템 로그에 콘솔 메시지 전송
  • 로그 파일 전송
  • 관리자에게 이메일 메시지 전송
  • SNMP 트랩 전송

* SNMP(Simple Netwokr Management Protocol) : ICMP와 상당히 비슷합니다.  ICMP는 ping을 통해 해당 서버가 요청을 받을 준비가 되었는지 간단하게 확인할 때 사용하는 프로토콜입니다.  장비가 서버 요청자가 클라이언트라고 했을 때 요청자가 장비에게 SNMP request를 보냅니다. 그러면 그 장비는 내가 어떤 상황이고, 어떤 사용량을 보이며, 처리속도는 얼마 정도 되는 전반적인 시스템 상황을 SNMP Response를 요청자에게 보냅니다.

반면 SNMP Trap은 SNMP보다 조금 더 간결합니다. 트리거를 장비에 마련하여, 장비의 리소스들의  임계값을 설정한 후 해당 임계값을 넘는 경우 요청하지 않아도 관리자에게 SNMP Trap을 자동으로 발송하는 기능입니다.

 

 

 

반응형

'클라우드' 카테고리의 다른 글

멀티테넌시  (0) 2021.10.31
클라우드 서비스 이해  (0) 2021.10.30
클라우드  (0) 2021.10.24
가상머신(VM)이란?  (0) 2021.02.05
클라우드 서비스란 뭐지?  (0) 2021.02.02

댓글