Untitled.jpeg

bookmark

시스템 안정화

엔터프라이즈 소프트웨어는 냉소적이여야한다.

안정성(stablility)을 얻기 위해 반드시 많은 비용이 들지는 않지만, 안정성이 부실하면 상당한 비용이 발생한다.

아키텍처 수립, 설계, 세부 시스템 구현 할 때 많은 의사 결정 시점이 시스템의 안정성에 영향을 미친다.

안정성의 정의

일시적 충격(impulse), 영구적 변형력(stress), 구성요소의 장애가 정상처리를 방해하더라도 계속 트랜잭션을 처리하는 성질.

수명 연장

시스템 장애 주요 원인은 메모리 누수, 데이터 증가 이며 테스트 중에는 잘 드러나지 않음.

이러한 버그는 개발환경, 부하테스트 등에서도 잡히지 않는다.

따라서 자체 장기 안정성 테스트를 시행

• 개발용 컴퓨터를 두어 JMeter, 마라톤, 그 외 부하테스트 도구를 이용하여 지속적으로 요청을 발생시킴.

장애 모드(failure mode)

피해 결과를 포함하여 원래의 계기와 균열이 다른 시스템으로 퍼져가는 것을 의미.

시스템의 필수 기능을 결정, 균열 차단기(crackstopper)를 구축하여 복원탄력성(resiliance)를 확보.

균열 확산 차단

항공사의 장애 모드 적용 예시.

• 자원 Pool에서 자원이 없을 경우 요청 Thread를 Block하도록 구성됨. ⇒ 모든 Thread 정지됨.
• RMI(Remote Method Invocation) 호출의 시간 제한이 없음.
• CF 서버들을 서비스 그룹으로 묶지 않음. ⇒ 균열 확산
• 아키텍처 문제로는 요청/응답 메시지 큐를 사용하지 않음.

장애 사슬

모든 시스템 장애는 연쇄적으로 발생

결함 발생 ⇒ 균열 생성 ⇒ 결함의 오류가 됨 ⇒ 장애 발생

강한 결합은 균열을 가속화 함.

결함 다루는 방식은 두 가지의 진영이 존재

• A: 결함에 잘 견딜 수 있도록 만든다. 예외 처리하여 결함이 오류가 되지 않도록 방지.
• B: 결함을 견디게 만든다는 목표는 무의미함. 결함은 언제 어디서든 발생함.

두 진영의 공동 목표는 **결함은 결코 완벽한 방지가 불가능하며 결함이 오류가 되지 않도록 막아야 함**

안정성 안티 패턴

소프트웨어의 위기

하드웨어, 언어, 오픈소스 라이브러리 등 소프트웨어의 폭발적인 발전이 있었지만,

자원과 애플리케이션의 도달 범위 또한 폭발적으로 증가하며 요구 신뢰성도 증가함.

시스템 간 긴밀한 결합이 많아지고 고도의 상호 작용 복잡성이 발생함.

이러한 강한 결합은 한 부분의 균열이 시스템 경계를 넘어 확산되도록 한다.

통합 지점

통합 지점은 시스템에서 가장 문제가 많은 부분.

Context Diagram 유형

• 나비 패턴 : Monolith
• 거미줄 패턴

예시

• Socket 프로토콜: 호출 Block을 방지하기 위해 소켓 제한 시간을 설정해야 함.
• HTTP 프로토콜: Timeout과 응답 처리를 정밀하게 제어할 수 있는 클라이언트 라이브러리 사용.

통합 지점 대응책

• Circuit Breaker 와 Decoupling middleware 이용.
• 테스트 활용: 부하 + 테스트 하네스,

요점

• 통합 지점은 필요악
• 다양한 형태의 장애에 대비
• 언제 추상 계층 속을 들여다봐야 할지 파악
• 장애는 신속하게 전파됨
• 패턴을 적용하여 통합 지점의 문제를 방지

연쇄 반응

수평 확장 (Farm, Cluster) 아키텍처는 다중화로 내결함성(FT)을 확보하지만,

부하가 발생 시 메모리 누수, 동시성 버그가 빈번하게 일어남.

나아가서 Thead가 Block 되어 응답하지 못할 때 연계 장애를 유발 가능.

요점

• 서버 하나가 멈추면 나머지 서버도 위험에 빠질 수 있다.
• 자원 누수 확인
• 시간 관련 버그 픽스
• Autoscaling 을 이용
• 격벽(bulkhead)으로 방어

연계 장애

하위 계층의 장애로 자원 풀이 소진되어 발생 ⇒ 통합지점에 Timeout을 설정 필요

요점

• 간극을 뛰어넘는 균열을 차단
• 자원 풀을 꼼꼼히 살펴라
• Timeout과 Circuit Breaker를 이용

사용자

트래픽

• Capacity를 넘는 트래픽을 방지하기 위해 Auto-scaling을 이용함, 버그로 인한 많은 비용 발생 우려
• 세션(사용자)은 메모리를 소비하며 장애에도 메모리를 차지함으로 가능한 작게 유지
• WeakReference를 사용하면 메모리 상황에 따라 GC 가능
• Memcached, Redis 등을 이용하여 세션 데이터를 보관
• Socket TIME_WAIT를 낮추어 메모리의 빠른 회수

서비스 비용

• 비용이 높은 트랜잭션을 이용하여 공격적인 테스트를 통해 처리 능력 계획

비정상 활동 사용자

요점

• 사용자는 메모리를 소비한다
• 사용자는 예상할 수 없는 이상한 일을 한다.
• 악의적인 사용자 존재
• 사용자들의 공격