Sevity Blog

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: 배치보다는 실시간성에 강점. 하지만 메시지가 저장되므로 배치에도 사용가능.

 인과관계 추론

• RCT(Randomized Controlled Trial). 즉 A/B테스트는 랜덤하게 나누는게 중요하며 인과관계를 과학적으로 보여준다(나머지기업은 인과관계추론이 완전하게 안됨) 좋지만 인공실험이 필요.
• RD(Regression Discontinuity): 회귀불연속설계법. 경계선에 집중

• 집군분석(Cluster Analysis):

• 패널데이터분석: 평행 트렌드 가정이 성립해야함.

생성 패턴 (Creational Patterns)
생성 패턴은 객체 생성과 관련된 문제를 해결합니다.

싱글턴 패턴 (Singleton Pattern): 클래스의 인스턴스가 하나만 생성되도록 보장.
팩토리 메서드 패턴 (Factory Method Pattern): 객체 생성을 서브클래스에 위임.
빌더 패턴 (Builder Pattern): 복잡한 객체를 단계별로 생성합니다.

• 생성자의 인수가 너무 길고 복잡할때 이를 보완.
• method chaining 과 함께 사용

프로토타입 패턴 (Prototype Pattern): 기존 객체를 복제하여 새 객체를 생성합니다.

• python deepcopy()

구조 패턴 (Structural Patterns)

구조 패턴은 클래스나 객체의 구성을 단순화하고 확장성을 높입니다.

어댑터 패턴 (Adapter Pattern): 호환되지 않는 인터페이스를 변환하여 함께 작동하게 합니다.

• 바꾸기 힘든 레거시를 품은 새로운 클래스 만들어서 기존 구조와 통합

브리지 패턴 (Bridge Pattern): 구현부에서 추상화를 분리하여 독립적으로 변화할 수 있게 합니다.

• 잘 안쓰는듯? abstract 와 interface 사이에 다르를 놓는것 같은데..

컴포지트 패턴 (Composite Pattern): 객체들을 트리 구조로 구성하여 부분-전체 계층을 표현합니다.

• 단일요소와 집합요소를 모두 같은 부모를 상속 받도록 해서 복잡한 트리구조도 단일 개체로 표현가능
• Folder와 File이 모두 Unit이라는 부모를 상속받도록 하는 것 생각

데코레이터 패턴 (Decorator Pattern): 객체에 동적으로 새로운 책임을 추가합니다.
퍼사드 패턴 (Facade Pattern): 복잡한 시스템에 대한 간단한 인터페이스를 제공합니다.

• 이건 그냥 복잡한 단계를 하나의 API로 묶어서 단순화 하는 개념.

플라이웨이트 패턴 (Flyweight Pattern): 공유를 통해 대량의 객체를 효율적으로 지원합니다.
프록시 패턴 (Proxy Pattern): 다른 객체에 대한 대리자나 플레이스홀더 역할을 합니다.

• 준비시간이 오래걸리는 프린터 앞에 버퍼프린터 대리자로 모아서 처리하는거 생각하면 됨

행동 패턴 (Behavioral Patterns)
행동 패턴은 객체 간의 책임과 알고리즘을 관리합니다.

책임 연쇄 패턴 (Chain of Responsibility Pattern): 요청을 객체의 체인을 통해 전달합니다.
명령 패턴 (Command Pattern): 요청을 객체로 캡슐화합니다.

• 행동도 객체화 할수 있다는 것(포토샵 액션 리스트 생각)

해석자 패턴 (Interpreter Pattern): 문법 규칙을 클래스로 표현합니다.

• 컴파일러 비슷한일 할때, 클래스로 처리

반복자 패턴 (Iterator Pattern): 컬렉션의 요소를 순회하는 방법을 제공합니다.
중재자 패턴 (Mediator Pattern): 객체 간의 상호작용을 캡슐화하여 객체들이 직접 참조하지 않도록 합니다.
메멘토 패턴 (Memento Pattern): 객체의 상태를 캡쳐하고 복원합니다.
감시자 패턴 (Observer Pattern): 객체 간의 일대다 의존성을 정의합니다.

• 구독하면 알림보내는거 생각하면됨. 이벤트일 필요없고 콜백도 가능

상태 패턴 (State Pattern): 객체의 내부 상태에 따라 행동을 변경합니다.

• 상태를 객체로 표현하여, 조건문처리를 단순화 한다.

전략 패턴 (Strategy Pattern): 알고리즘을 캡슐화하여 상호 교체 가능하게 합니다.

• 암것도 아님. 추상화를 통해 sum()등의 행동을 갈아 끼울 수 있다는 것.

템플릿 메서드 패턴 (Template Method Pattern): 알고리즘의 구조를 정의합니다.
방문자 패턴 (Visitor Pattern): 객체 구조에 새로운 연산을 추가합니다.

• 데이터와 행동을 클래스 분리. 이렇게 하면 행동의 추가 확장이 편해짐(sum, avg등)