Robi's Tech Note Robi's Tech Note

Chapter1. 소프트웨어 엔지니어링이란?변화와 확장을 고려한 지속 가능한 소프트웨어 개발 소프트웨어 엔지니어링은 지속 가능성을 고려해야 한다- 지속 가능성: 소프트웨어의 기대 생에 동안 요구되는 모든 기술/사업적 가치 있는 변경에 대응하는 것하이럼의 법칙에 따르면 변경이 기존의 워크플로우와 충돌이 발생할 수 있기에 변경에는 충돌을 조사 ,식별, 해결하는데 따르는 비용도 고려해야 한다- 하이럼의 법칙: API 사용자가 충분히 많다면, 명세에 적힌 내용은 중요치 않으며 시스템의 눈에 보이는 모든 행위를 누군가는 사용하고 있어 개발자가 의도하지 않은 대로 사용하는 사용자가 생긴다는 것조직 또는 시스템의 규모가 커짐에 따라 확장 가능함에 언제든 대비할 수 있어야 한다- 확장 가능함: 인력/자원등의 투자 대비..

10.1 데이터베이스 테스트를 위한 전제 조건10.1.1 데이터베이스를 형상 관리 시스템에 유지DB테스트를 위한 첫 번째 단계로 DB스키마를 일반 코드로 취급하여 Git같은 형상관리 시스템에 저장하는것이 최선이다.테스트용 모델 DB를 운영 DB와 별개로 운영하는 방법도 있지만(아래 그림 참고) 다음과 같은 두 가지 이유로 상당히 좋지 못한 방법이다. 변경 내역 부재: DB스키마를 과거 특정 시점으로 되돌릴 수 없다. 즉 운영 환경에서 버그 재현이 힘들어진다복수의 원천 정보: 개발 상태에 대한 원천 정보를 두고 경합하게 된다(개발중인 스키마가 운영에 반영된다면? Git같은 형상관리를 사용한다면 이런 사고 예방이 가능하다) 10.1.2 참조 데이터도 데이터베이스 스키마다데이터베이스 스키마는 Table, Vi..

9.1 목의 가치를 극대화하기9.1.1 시스템 끝에서 상호 작용 검증하기목을 사용할 때 항상 시스템 끝에서 비관리 의존성과의 상호 작용을 검증해야 한다. 아래와 같은 코드가 있다고 가정할 때,public interface IMessageBus { void sendEmailChangedMessage(int userId, String newEmail);}public class MessageBus implements IMessageBus { private final IBus bus; @Override public void sendEmailChangedMessage(int userId, String newEmail) { bus.send("Type: USER EMAIL CHANGED; Id: ..

1. 레디스와 캐시1) 캐시로서의 레디스사용이 간단하고(key-value형태로 저장) 다양한 자료 구조를 제공한다모든 데이터를 메모리에 저장하기에 저장 및 조회가 상당히 빠르다자체적으로 고가용성 기능을 가지고 있다(레디스 센티널/클러스터로 자동으로 장애 감지)스케일 아웃이 편리하다(클러스터로 자체 샤딩) 2) 캐싱 전략(1) 읽기 전략 - look-aside: 가장 일반적인 배치 방법 (a.k.a lazy loading) 장점: 레디스 장애 시 DB에서 데이터를 가져올 수 있다단점: 장애 발생 시 요청이 매우 많았다면 연결이 한번에 DB로 쏠려서 전체 응답속도가 느려진다※ 레디스를 새로 기동했을 때 캐시 미스로 DB로 연결이 몰릴 수 있기에, 미리 레디스로 데이터를 밀어넣는 캐시 워밍(cache warm..

레디스에서 고가용성을 확보하기 위한 두 가지 기능.※ 가용성: 전체 시간 중 서비스를 정상적으로 사용할 수 있는 시간복제: 마스터 노드의 데이터를 복제본 노드로 실시간 복사하는 기능자동 페일오버: 마스터 노드에서 발생한 장애를 감지해 레디스로 들어오는 클라이언트 연결을 자동으로 복제본 노드로 리디렉션 하는 기능 1. 레디스에서의 복제 구조레디스 복제본 노드의 사용 이유.마스터 노드가 다운되었을 경우를 대비일부 트레픽을 복제본으로 돌려 부하 분산백업을 복제본에서 수행하여 서비스 영향도 최소화레디스는 멀티 마스터 구조를 지원하지 않으므로 복제본 노드에서는 읽기 작업만 수행할 수 있다. 1) 복제 구조 조성하기# 복제본이 될 노드에서 다음 명령어 수행REPLICAOF   2. 복제 메커니즘1) 디스크를 사용..

1. 레디스에서 데이터를 영구 저장하기1) 복제와 백업의 차이복제: 서비스 가용성을 위한 것백업: 장애 상황에서 데이터의 복구를 위한 것 2) 레디스 백업의 종류AOF(Append Only File): 레디스 인스턴스가 처리한 모든 쓰기 작업을 차례대로 기록, 복원 시 파일을 다시 읽어가며 재구성 → 원하는 시점으로 복구가 가능하지만 RDB방식에 비해 용량이 크고 주기적으로 압축이 필요RDB(Redis DataBase): 일정 시점에 메모리에 저장된 데이터 전체를 snapshot하여 저장 → AOF방식보다 복원이 빠르지만 특정 시점으로의 복구는 불가능하나의 인스턴스에서 RDB와 AOF옵션을 모두 사용 가능하고, 관계형 DB만큼의 데이터 안정성을 위하는 경우 두 가지 백업 방식을 동시에 사용하는것을 권장...

1. Sorted Set을 사용한 실시간 리더보드# 플레이어별 점수 저장> ZADD daily-score:220817 28 player:286(integer) 1> ZADD daily-score:220817 400 player:234(integer) 1> ZADD daily-score:220817 45 player:101(integer) 1> ZADD daily-score:220817 357 player:24(integer) 1> ZADD daily-score:220817 199 player:143(integer) 1# 상위 3명의 점수 획득> ZREVRANGE daily-score:220817 0 2 withscores1) "paleyr:234"2) "400"3) "player:24"4) "357"5)..

2. 레디스에서 키를 관리하는 법 1) 키의 자동 생성과 삭제 Stream, Set, Sorted Set, Hash와 같이 하나의 키가 여러 개의 아이템을 가지고 있는 자료 구조에서는 자동으로 키가 생성되고 삭제된다. 키 생성의 세 가지 공통적인 규칙은 아래와 같다. 키가 존재하지 않을 때 아이템을 넣으면 아이템을 삽입하기 전에 빈 자료 구조를 생성 모든 아이템을 삭제하면 자동으로 키도 삭제 (Stream은 제외) 키가 없는 상태에서 키 삭제, 아이템 삭제, 자료 구조 크기 조회 같은 읽기 전용 커맨드를 수행하면 에러 반환 대신 키가 있지만 아이템이 없는 것처럼 동작 2) 키와 관련된 커맨드 (1) 키 조회: EXISTS // EXISTS key [key ...] > SET hello world OK /..