시스템설계 Q&A 2

Q. 설계 디자인 문제의 경우 초기에 질문할 것들은?

• 기능적 요구사항
• 비기능적 요구사항
  • 성능, 확장성, 안정성, 보안
  • 비용최적화
  • 트래픽패턴
• 제약사항
  • 벤드위스, 시스템사양, 외부시스템 디펜던시
• 프로세스
  • 스케일아웃등 의사결정시 데이터 포인트 필요(응답시간, 에러율, CPU/메모리/IO사용율, 대기중인요청, 스레드개수등)
  • 메트릭측정
  • 필드테스트전 로드테스트(환경구축 필요)

Q. 과부하처리

• 웹서버/WAS
  • 정적컨텐츠면 CDN(Content Delivery Network) 고려
  • 커넥션풀
  • 로드밸런싱(리버스 프록시)
  • Scale up, Scale out
  • Auto Scaling
• DB
  • 쿼리최적화/인덱싱
  • 머터리얼뷰(정규화 수준 낮추기)
  • Master/Slave분리
  • 샤딩, 분산트렌젝션(2단계 커밋)
  • NoSQL도입(쓰기작업이 많거나, 주문서등 비정형 데이터 저장)
  • 이벤트소싱(CQRS)
•  캐시적용(Redis등)
  • 읽는경우: Look aside. Cache에 있으면 Cache에서 가져오고 없으면 DB에서 읽고 Cache에 업데이트
  • 쓰는경우:
    • Write Through. 항상 cache에 저장하고 DB에도 저장
    • Write Back. Cache에 저장하고 주기적으로 모아서 DB에 배치 업데이트
  • 일관성보완: 캐시만료timeout, 쓰기시 캐시무효화
  • 가용성보완: 캐시복제

•  
  • Redis의 한계: 싱글스레드. 
    • keys대신 scan사용
• 비동기 처리
  • 대기열 시스템을 통한 고객 경험 개선
•  코드최적화
  • 지연로딩(이미지등), 디바운싱(마지막 요청만 처리)
• 전송방식 변경
  • gRPC
• 외부 디펜던시가 있다면
  • 스로틀링(rate limit포함, 요청수 제한), 서킷브레이크(close, open, half-open)
    • 푸시/풀(전자는 리소스헤비)
    • failover=fallback(다른 결제 시스템)
  • 분리된 Queue에 요청을 저장하고, 백그라운드로 처리. 시스템 복구시 순차적 처리
  • 회로차단기로 막혔을때의 요청을 DLQ(Dead Letter Queue)에 넣고 모니터링 후 원래큐로 돌리거나 후처리.

Q. 장애대층

• 네트워크 실패 문제
  • 다중 AZ, 서킷브레이크(외부 서비스면)
• 단일 실패지점
  • 데이터 복제, 로드밸런싱, 자동장애복구(클라우드), 장애격리(MSA)
  • 다중 AZ

Q. 무중단 DB마이그레이션(RDB > NoSQL기준)

• 데이터 동기화
  • 이미 존재하는 RDB데이터를 NoSQL로 복사(배치, ETL)
• 더블 Writing (RDB, NoSQL)
• 읽기연산을 NoSQL로 전환
• 쓰기연산 전환, RDB중단(feature flag사용)
• 경우에 따라 일부 사용자 또는 서비스만 전환(카나리테스트)
• 중간중간에 일관성확인/모니터링/롤백계획도 수립하면서 해야함

Q. Monolithic에서 MSA로 전환

• 도메인 분석을 통해 몇개 서비스로 나눌지 결정
• 비즈니스영향력이 작고 기술적으로 단순한 도메인 부터 이전
• DB분리 > 서비스간 API설계 > 통계는 별도 ETL구축
• 단점: API는 DB Join보다 비싸고 느림. 대안: 모듈식(펑션콜/공유메모리/로컬큐)

Q. 도메인주도설계(DDD)

• DB스키마 부터 설계하고 CRUD > 비즈니스로직 구현 순서가 아님
• 비즈니스부터 고민. 바운디드 컨텍스트(용어 정의)
• 애그리게이트(대출계좌, 대출자, 대출상품을 묶어 대출로 애그리게이트)
• 이벤트(대출신청, 승인, 상환)
• 서비스(복잡한 비즈니스로직 예를들어 대출 신용평가)

Q. NoSQL vs 스팍/하둡 vs Kafka

• NoSQL: 실시간성
• 스팍/하둡: 배치(하둡은 디스크액세스때문에 느리고, 스팍은 실시간성이 있으나 데이터 저장/관리 기능없음)
• Kafka: 배치보다는 실시간성에 강점. 하지만 메시지가 저장되므로 배치에도 사용가능.