| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- 백그라운드스레드
- 인덱스 레인지 스캔
- 잠금없는읽기
- 세컨더리 인덱스
- 인덱스 스킵 스캔
- 인덱스 풀 스캔
- 언두로그
- Redis아키텍처
- 1년차개발자
- CPU
- 버퍼풀
- 외부API연동
- 외부API
- Undo Log
- 공유락
- Snapshot Read
- 실행 사이클
- 비식별자
- 배타락
- 갭 락
- 프라이머리 키
- 테스트컨테이너
- 트랜잭션아웃박스패턴
- 개발자성장기
- 데이터 무결성
- 루스 인덱스 스캔
- InnoDB 격리수준
- 인덱스 구조
- 레코드 락
- 멱등성
- Today
- Total
목록전체 글 (22)
DS log
오늘은 연차다. 처음 회고를 작성해봐서 어떻게 작성해야할 지 모르겠지만, 무의식의 흐름대로 써보려고 한다.우선, 지금 내 삶에 가장 큰 영향을 주고 있는 회사에 대해서 작성해보려고 한다.회사 사정이 좋지 않다.말 그대로다. 회사 사정이 좋지 않다. 회사 내에서는 여러가지 이유로 희망 퇴직 및 권고 사직을 받고 있다. 기존에 내가 진행하던 솔루션이 회사의 주 사업 중 하나였는데 해당 사업이 실패하면서 동시에 내 커리어도 멈추게 되었다. 뭐 그렇다고 아직 회사를 잘리지는 않았으나 뭐 어떻게 될런 지 모르겠다. 자세한 이야기를 말할 수는 없지만 내가 어떻게 할 수는 없는 것이니깐 버티는 수밖에 없을 듯하다. 회사에서 무엇을 얻었나?1년 조금 넘게 초기 솔루션을 개발하고, 운영하면서 얻은 것은 많지만 지금 생각..
작년에 '외부 서비스 데이터를 연동해서 자사 서비스에 최적화된 통계 화면을 제공해!' 라는 요구사항을 받았습니다.이번 포스팅에서는 해당 요구사항을 해결하면서 고민했던 부분을 정리해보려고 합니다.요구사항 분석구체적인 요구사항은 아래와 같습니다.2시간 주기로 최신화된 데이터를 제공하라.기간별로 통계 데이터를 조회가 가능해야한다.또, 개발자로서 고려해야하는 상황은 아래와 같습니다.외부 API 응답 속도는 통제할 수 없다.1차 설계요구사항을 받고 대략적으로 설계를 해봤을 때 처음 든 생각은 내부 서비스에 API 요청을 하면 요청 시점에 외부 API를 호출해 응답을 가공한 뒤 반환하는 동기 처리 방식이었습니다. '당장 오늘 점심까지 해라' 와 같이 시간 제한이 타이트하지 않기도 하고, 자사 서비스의 스레드가 외..
기존에 Redis하면 자동 반사로 특징은 싱글 스레드! 라고 암기가 되어있었는데요. 이번에 좋은 기회로 Redis를 공부하게 되서 오늘은 Redis 내부 아키텍처에 대해서 소개해보려고 합니다. 메인 스레드와 보조 스레드Redis는 메인 스레드 1개와 백그라운드 보조 스레드들로 구성되어 있습니다. 간단하게 주요 작업은 메인 스레드가 처리하고 시간이 오래걸리는 작업은 백그라운드 보조 스레드가 처리하는 구조입니다. 1. 메인 스레드 메인 스레드는 클라이언트의 모든 명령어를 순차적으로 처리하는 핵심 엔진입니다. 이때 이벤트 루프 기반의 비동기 I/O를 활용하여 단일 스레드임에도 불구하고 높은 처리량을 보여줍니다. 2. 보조 스레드 보조 스레드들은 메인 스레드가 처리하기에 시간이 오래 걸리는 I/O 작업을 전..
요즘 AI를 사용하여 개발할 때 테스트 시나리오를 먼저 생각하는 것은 기본이 된 거 같습니다.불과 1년전만 하더라도 테스트 시나리오부터 생각하지 않았는데 말이죠.이제는 개발을 할 때 구현할 Spec을 정해놓은 다음에 고려한 테스트 시나리오를 전부 입력한 다음에 테스트 시나리오가 성공할 때까지 딸깍합니다.그러곤, 다음 할 것으로 넘어가서 다음에 무엇을 할 지 생각하곤 합니다.왜 테스트를 작성해야할까?왜 테스트를 작성해야할까? 인제는 개발을 AI가 하기 때문에 사실상 제가 할 수 있는 게 테스트 시나리오를 생각하고 구상하는 것뿐입니다.식상한 이야기지만, 최근에 개발하고 있는 서비스가 대대적으로 개편이 되고 있습니다.벌써부터 머리가 아픈데, 기존 API에 대해서 하위 호환성을 지켜야합니다. 하위 호환성 이것을..
회사에서 회원 탈퇴 기능에 대한 요구사항을 받았습니다.데이터베이스 하나에 삭제해야하는 데이터가 다 있으면, 처리하기가 쉽겠지만 그렇지 않았습니다. 서비스와 연동하는 다른 서비스의 데이터 또한 제거를 해야만 했습니다. 제거 요구사항은 각 데이터의 성격에 따라서 Hard Delete 처리를 하거나 Soft Delete 처리를 수행해야했습니다. 운이 좋게도? 담당자분들이 모종의 이유로 없었기 때문에 외부 서버의 API까지 개발할 수 있었습니다.오늘은 이 요구사항을 처리하면서 고민했던 것들을 정리해보려고 합니다.요구사항 정리회원 탈퇴 시 해당 사용자와 관련된 데이터를 제거해야한다. (내부 서비스)회원 탈퇴 시 해당 사용자와 관련된 데이터를 제거해야한다. (외부 서비스)회원 탈퇴 시 해당 사용자와 관련된 이..
이번 글에서는 회사에서 개발하면서 겪었던, 저에게 꽤 의미 있던 경험을 정리해보려고 합니다. 저는 B2B 솔루션을 개발하는 팀에 속해 있습니다. 이번에 그 솔루션에 계약마다 다른 쿼터 정책을 적용해야 하는 기능을 개발하게 됐습니다. 기본적인 CRUD 개발이 아니라서 확실히 흥미롭긴 했습니다. 그런데, '계약에 관한 정책이 위에서 정해지지 않았는데, 내 마감기한은 그대로네 이대로라면 야근 확정이네 ~ ' 하는 자포자기의 심정도 들었습니다. 뭐 아무튼 기쁜(?) 마음으로 야근을 하며 기한 내에 기능 개발을 완료할 수 있었습니다. ^^ 포스팅으로 돌아와서 기능 요구사항을 간단히 정리하면 아래와 같습니다.기능마다 서로 다른 쿼터 정책이 필요하고, 그 정책은 계약에 따라 달라진다. 처음에는 "기능마다 if-e..
안녕하세요. 이번 포스팅에서는 외래키 왜 사용하지 않는 것일까? 라는 주제로 공부하고 생각한 내용을 공유하려 합니다.먼저, 외래키가 무엇인지 알아야겠죠.외래키는 무엇일까? 외래키는 테이블 간에 서로 연관된 데이터를 참조할 수 있게 하는 도구입니다. 부모 테이블과 자식 테이블이 있다고 할 때, 부모 테이블은 참조되는 칼럼 값을 가지고 있는 테이블이고, 자식 테이블은 부모 테이블의 값을 참조하는 칼럼을 가진 테이블입니다.외래키 왜 존재하는 걸까? 실무에서 외래키는 잘 사용하지 않습니다. 그럼에도 불구하고 MySQL에는 존재하고 있죠. 왜 MySQL에는 외래키라는 게 있는 지 생각해보았습니다.첫 째, 데이터 무결성을 보장하기 위해서 외래키가 존재한다. 애플리케이션 개발을 하다보면, 의도한 데이터를 받으려고 R..
안녕하세요. 이번 포스팅에서는 InnoDB 스토리지 엔진의 S Lock과 X Lock에 대해서 알아보려고 합니다. 공유 락(Shared(S) Lock)공유 락은 락을 보유한 트랜잭션이 행을 읽을 수 있도록 허용하는 락입니다.예를 들어서, T1이 행 R에 S락을 보유 중일 때 T2의 S락 요청은 즉시 승인되지만 X 락 요청은 차단됩니다. 쉽게 말하면, 하나의 행에 대해서 공유 락만 휙득 가능하고 공유 락을 휙득한 트랜잭션만이 읽기 연산이 가능합니다.공유 락을 사용해 조회하면 트랜잭션 내 조회한 데이터가 변경되지 않음을 보장할 수 있습니다. 아래와 같이 SELECT FOR SHARE 를 사용하여 특정 데이터로부터 공유 락을 획득할 수 있습니다.SELECT * FROM table_name WHERE id = ..