주제

3장 - 시스템 안정화를 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

6

@caffeine-library/readers-release-everything

호출하는 클라이언트는 RMI 소켓에 제한 시간을 설정하도록 작성될 수 있었다. 예를 들어 새로운 소켓을 생성할 때 Socket.setSoTimeout() 메소드를 호출하는 소켓 팩토리를 가져다 쓸 수 있었다. 특정 시점에 CF에서는 EJB 대신 HTTP 기반의 웹 서비스를 만들기로 결정할 수도 있었다. 그러면 클라이언트는 HTTP 요구에 시간 제한을 걸 수 있게 된다. (p.65)

2장에서 항공사 사례에 대해 얘기하면서, 경원님께서 왜 timeout을 걸지 않았지?라고 말씀해주신게 떠올라서 적어봤습니다 ㅎㅎ 3장에 timeout 설정 관련된 얘기가 나올 줄이야. 경원님의 선견지명 👍

7일 만에 발생하는 메모리 누수를 테스트하지 않았다면 7일 후에 메모리 누수가 발생할 것이다. (p.62)

개발(베타) 환경에서 QA를 할 때, 실제로 위와 같은 메모리 이슈는 테스트하기 어려울 것 같은데요. 이처럼 개발 환경에서의 QA나 성능테스트는 어느 정도 한계가 존재한다고 생각합니다.

그럼 개발 환경에서 부하테스트를 잘 진행하기 위해선 어떻게 해야될까? 에 대해 한번 생각해보게 됐습니다. 책에서는 아래와 같은 방안을 제시했네요.

때로는 비용 때문에 완벽한 환경을 구성하도록 승인받기 어렵다. 그렇다면 주요 부분만 테스트하고 나머지는 제거하도록 하자. 테스트를 전혀 하지 않는 것보다는 낫다. (p.63)

개발 환경에서는 운영환경과 비슷한 트래픽 및 부하를 주기엔 너무나 막대한 비용이 요구됩니다. 또, 개발 환경에서 운영환경과 비슷하게 요청을 만들어주기 위해선 너무나 많은 외부 API 모킹, 외부 서비스 모킹 등이 필요합니다.

💬 여러분은 개발(베타) 환경에서 부하 테스트를 어떻게 진행하나요? 경험을 공유받고 싶습니다!

🙎‍♂️ 일단 저는 베타 환경에 데이터를 N건 밀어넣었을 때, API를 쐈을 때 이에 대한 응답이 M초 걸린다 와 같이 직접 테스트를 해보는데요 (어차피 베타 환경이니까!), 운영에선 좀 더 느릴수도 있기 때문에 최대한 보수적으로 성능을 계산하여 리팩터링을 진행하는 것 같습니다.

만약 외부 서버와 연동돼야 하는 e2e 테스트 같은 느낌으로 부하테스트를 진행해야 된다면? 이런 경우는 아직 없었던 거 같습니다. 외부 서버 API 모킹이라든지, 외부 서버에 직접 저희한테 API를 쏴달라든지 하면서까지 성능 및 부하테스트를 진행하진 않았던 거 같아요.

💬 여러분은 개발(베타) 환경에서 부하 테스트를 어떻게 진행하나요? 경험을 공유받고 싶습니다!

실질적은 경험 공유는 부족하여 안타깝습니다, 여러모로 사례를 만들어 경험을 넓히고 싶군요.

제 당시 조직적/주기적인 부하 테스트 업무는 없어서 아쉽습니다.
- 개인적으로는 Fiddler, Postman, 파이썬으로 반복적인 API 요청을 때려보는 수준이었습니다.
- 물론, 최대 컨텐츠를 때려넣는 식의 "부하"는 테스트 해 봤으나...
- 일부 시니어 롤로서 스크립트 기반 부하 테스트 하시더라구요. (아직 SOAP가 걷어지기 전!)
AWS에서의 부하 테스트 솔루션 백서
- Taurus(타우러스)라는 부하 테스트 도구를 활용한 솔루션 소개입니다.
- 타우러스는 Gatling, JMeter, Selenium등을 실행자로 삼아서 테스트 할 수 있는 도구입니다. 도커 이미지로 제공되고, 테스트 시나리오를 YAML로 작성합니다.
하나 중요한게, AWS에는 부하 테스트 정책이 있어서 참고하셔야 한다는 점. 제한 대역폭이나, DDoS 테스트는 파트너를 통해야 한다는 등 정책이 있습니다.

Tests that purposefully attempt to overwhelm the target and/or infrastructure with packet or connection flooding attacks, reflection and complexity attacks, or other large volumes of traffic are not considered network stress tests but are considered distributed denial of service (DDoS) tests. 의도적으로 패킷, 홍수 공격, 리플렉션 공격, 복잡성 공격, 큰 볼륨의 트래픽으로 대상과 인프라를 버겁게 하는 테스트는 DDoS 공격을 한 것으로 간주합니다.

EC2 스트레스 테스팅 정책
- EC2에서 1Gbps, 1Gbpps 트래픽을 1분이상 유지할 경우 공격 간주
- 확신이 없다면 Test intake form을 AWS 서포트에 제출하여 확인 받기
DDoS 테스팅 정책

서론

안정성이 높은 시스템과 낮은 시스템은, 둘 다 QA를 통과한다
냉소적 시선의 필요성 : 장애가 일어나도 예상했기 때문에 놀랍지 않다
낮은 안정성으로 인해 장애가 발생하면, 막대한 비용 발생하는 반면에 높은 안정성을 갖추기 위해 발생하는 비용은 크지 않다
따라서, 안정성을 높이는 방향으로 의사 결정을 해야 한다

3.1 안정성 정의

트랜잭션 : 시스템이 처리하는 추상적인 작업 단위
- 예시 : 온라인 상거래 사이트
  - ‘주문 진행’이 하나의 트랜잭션이며, ‘신용 카드 확인’ 같은 외부 시스템 연동을 포함
혼합 작업 부하(mixed wordload) : 시스템에서 처리되는 서로 다른 트랜잭션 유형의 조합
시스템
- 완결적이면서 상호 의존적인 하드웨어, 애플리케이션, 서비스의 집합
- 사용자의 트랜잭션을 처리하는 데 필요
- 하나의 애플리케이션일 수도 있고, 다중 계층 네트워크일 수도 있음
안정성
- 일시적인 충격, 영구적인 변형력, 구성 요소의 장애가 정상적인 처리를 방해하더라도 계속 트랜잭션을 처리하는 능력
- 안정성이 높은 시스템은 배포를 오랫동안 하지 않아도 리소스 소진이 발생하지 않아 계속해서 트랜잭션을 정상적으로 수행할 수 있다

3.2 수명 연장

리소스 소진으로 인해 서버가 멈추면, 수명을 다한 것이고 재시작을 통해 복구할 수 있음
수명을 다하는 주요 원인
- 메모리 누수와 데이터 증가
- 일반적인 테스트로는 잡히지 않음
  - 며칠/몇 주 이상 길게 띄워놓고, 꾸준한 부하를 받아야만 재현할 수 있는데 비용 문제 등으로 재현하기 어려움
  - 그러나, 저비용으로 최대한 비슷한 재현은 해볼 수 있음

3.3 장애 모드

균열(crack) : 장애를 일으키게 된 최초 원인
장애 모드(failure mode) : 균열이 다른 시스템으로 번지는 방식
- 안전한 장애 모드 : 다른 시스템으로의 전파가 충분히 대비된 장애 모드
- 위험한 장애 모드 : 다른 시스템으로의 전파가 대비되지 않은 장애 모드
안전한 장애 모드를 설계해야 한다
- 균열 차단기(crackstopper)를 구성

3.4 균열 확산 차단

CF 프로젝트 회고
- 장애 모드를 계획하지 않았음
- 계획했다면, 키오스크와 IVR에 장애가 전파되지 않을 수 있었음
- 무한정 블록이 아니라, 블록에 Timeout을 줬다면, 균열이 차단될 수 있었음
균열 확산 차단 방법
- Timeout 주기
- 연결 풀의 연결 소진 시 추가 연결 생성
- 서비스 그룹을 분할하여, 같은 서비스 그룹끼리만 균열 확산을 허용 (다른 서비스 그룹에는 균열 차단)
- 메시지 큐를 통한 통신 → 자연스럽게 미응답 시나리오를 대비한 설계를 하게 됨
결합이 강할수록 균열 전파율도 높아지고 결합이 약할수록 균열 전파율도 낮아짐

3.5 장애 사슬

결함 : 소프트웨어에 잘못된 내부 상태
오류 : 눈에 띄게 잘못된 작동
장애 : 시스템이 응답하지 않는 것
장애 사슬 : ‘결함 → 오류 → 장애’로 이어짐
결함은 완벽히 방지할 수 없으나 결함이 오류로 발전하지 않게 막아야 한다

마치며

다양한 서비스에 다양한 장애가 있지만 그 패턴은 비슷하다
4장 : 안정성 안티 패턴
5장 : 안정성 패턴
안정성이 높은 아키텍처
- 균열이 확산되는 것을 막는다
- 피해를 억제한다
- 시스템 전체에 장애가 번지지 않고, 부분적인 기능이 유지되도록 돕는다

caffeine-library / release-everything

[keyword] 3장 - 시스템 안정화 #8

주제