오랜만에 일기를 쓴다.이정도면 일기(日記)가 아니라 연기(年記)가 아닐까. 이번해에는 신변이 변한 것이 꽤 있었다. 원래 살던 곳에서 이사를 하기도 했고, 이직도 했다. 여름쯤 새로운 곳으로 가족이 전부 이사를 했다. 더 살기 좋은 곳으로 오게되어 다행이다. 부모님도 마음에 들어하신다.(부모님 집이니까 부모님이 마음에 들어하는게 중요하지)취업한 이후 계속 같이 살고 있는데 점점 독립하고 싶은 생각이 든다. 하지만 아직 경제적으로 부담스럽기도 하고 집을 구하는 과정도 복잡할 것 같아서 귀찮은게 크다. 하반기에는 이직을 했다.퇴사를 회사에 고한 후 주위 분들이 왜 퇴사하는지 여쭤보는 일이 많았다. 어떤분은 "퇴사에는 크게 두가지 - 지금 있는 곳이 싫어서 혹은 앞으로 갈 곳이 더 좋아서 가 있는데 당신은 ..
9월 중순경, 파트너사에서 대시보드에서 이벤트로그가 다운로드 실패하는 CS가 인입되었다. 바로 재현해본 결과, 대시보드에서 적정 기간을 설정하여 데이터 저장 시 응답으로 게이트웨이 타임아웃(504)을 받고 있었다. https://developer.mozilla.org/ko/docs/Web/HTTP/Status/504 504 Gateway Timeout - HTTP | MDN 하이퍼텍스트 전송 프로토콜 (HTTP) 504 Gateway Timeout 서버 에러 응답 코드는 서버가 게이트웨이 혹은 프록시의 역할을 하는 동안 시간 안에 업스트림 서버(upstream server)로부터 요청을 마치기 위해 developer.mozilla.org 문서에 따르면 504는 웹서버 혹은 프록시에서 발생하는 것이다. 해..
가고싶은 회사 (순위 상관 x) - 카카오뱅크코어뱅킹 개발자 - 공통· IT 개발 및 운영 경력 1년 이상 5년 이하인 분· 유연한 사고와 커뮤니케이션 역량이 있는 분· 자기주도적인 개발과 전체 프로세스를 고려한 설계와 구현이 가능한 분· 책임감이 높으며, 배우고자 하는 열정이 가득한 분-> 신입 가능한듯 - 토스뱅크Server Developer - platform고가용성의 확장 가능한 시스템을 설계하고 운영해본 경험이 필요해요.대규모의 실시간 트래픽을 처리하는 시스템 개발 경험이 필요해요.Spring Framework 기반의 개발 경험이 필요해요.성능 최적화와 운영 자동화를 위한 지속적인 노력해온 경험이 필요해요.순발력과 빠른 판단을 통한 문제 해결 능력이 필요해요.변화를 두려워하지 않고 새로운 기술에..
기술중심으로 입사후 한일 (내가 메인)막 어려운 것, 아예 못할 것 같은걸 한적은 없는 것 같다..(곧 정체기가 오지 않을까) - 로그성 테이블 (로우데이터 테이블, 포인트 지급 테이블) 개선서비스 내 장애 요소가 된 테이블. 데이터가 많이 쌓이는 테이블인데 정규화 x 인덱스 잘못 걸린 테이블이라 대시에서 조회시 높은 확률로 계속 log query가 실행되어 db burst balance 가 0이되고... 이런 상태였다.- 로그성 테이블이 용량이 크더라도 잘 다운로드 되게함이게 기술적인건가 모르겠는데 일단 안되고 있었으니까.. 기존에는 select 해온 모든 데이터를 메모리에 fetching 한 뒤(...) 응답으로 내려주는 무지막지한 구현이었다. 이렇다보니 아무리 테이블에 인덱스가 잘 걸려있어도 데이..
서버 개발한지 10개월.. 거의 1년이 돼 간다. 현재 속한 팀이 사내에서도 신 사업 개발과 관련되어 있어서 스타트업 내의 또 다른 스타트업의 느낌이다.신 사업 = 피처 개발의 연속.. 이기 때문에 거의 계속 정신없이 jira 카드 쳐내기 바빴던 것 같다. 특히 수습기간에 더 그랬다.지금 까지 내가 main 으로 구현한 기능들은 (입사 후 서사 순) 1. 내부 포인트 -> 네이버페이 전환 기능이름만 보면 거창하지만 사실,우리 서버 사내 네이버페이 전환 서버 실제 네이버페이 서버에서 내가 작업했던 것은 1번 이었기 때문에, 실제 네이버페이 서버와의 통신과정이 어떻게 되는지는 알지 못한다. (전환이 어떻게 되고 유저인증은 어떻게 하며 데이터 암호화는 어떻게 하는지 등)이때 서버만 작업한게 아니라 프론트도..
[27] Using MRR MySQL 엔진은 실행계획을 수립하면 핸들러 API로 스토리지 엔진을 호출해서 쿼리를 처리한다. 이때, 스토리지 엔진은 실행계획에 대해 알지 못하므로 최적화에 한계가 있다. 예를 들어 같은 페이지에 있는 레코드라도 한건한건 디스크를 조회할 수도 있다. 이러한 단점을 보완하기 위해 Mulit Range Read(MRR)이라는 최적화가 도입됐다. MySQL 엔진은 여러개의 키값을 스토리지 엔진에 넘겨주고, 스토리지 엔진은 키값을 정렬해서 최소한의 페이지 접근으로 필요한 레코드를 읽게 최적화한다. [28] Using sort_union(...), Using union(...), Using intersect(...) index merge와 같은 여러 인덱스를 사용하는 쿼리에서 인덱스들..
[23] Using index condition 옵티마이저가 인덱스 컨디션 푸시 다운 최적화를 사용할 때 표시된다. [24] Using index for group-by 정렬된 인덱스를 읽어서 순서대로 그루핑작업만 하면 될때 표시된다. -> 따로 정렬작업이 필요없기때문에 효율적 단순히 인덱스를 쭉 읽는 방법과, 필요한 부분만 읽는 방법이 있다 - 타이트 인덱스 스캔을 통한 GROUP BY 처리 AVG(), SUM(), COUNT()는 전부 다 읽어야한다. 이경우 단순히 GROUP BY를 위해 인덱스를 이용하지만, 루스 인덱스 스캔은 아니다. 실행계획에서 Using index for group-by가 표시되지 않는다. - 루스 인덱스 스캔을 통한 GROUP BY 처리 MIN(), MAX() 는 맨앞, 맨뒤..
[18] Select tables optimized away MIN, MAX 만 SELECT 절에 사용되거나 GROUP BY로 사용될 때 인덱스를 오름차순/내림차순 으로 1건만 읽는 형태의 최적화가 적용되면 Extra 컬럼에 'Select tables optimized away'라고 표시된다. [19] Start temporary, End temporary 세미 조인 최적화 중에 옵티마이저가 duplicate weep out을 쓰면 표시된다. duplicate weep out: 불필요한 중복 레코드를 제거하기 위해 내부 임시테이블을 사용한다는 뜻. [20] unique row not found 두개의 테이블이 유니크 키(PK 포함)로 아우터 조인했는데 아우터 테이블에 일치하는 레코드가 없을 때 표시된다...
[14] Plan isn't ready yet 다른 커넥션에서 아직 쿼리의 실행 계획을 수립하지 못했을 때 표시된다. 이 경우 여유 시간을 갖고 난 후 EXPLAIN FOR CONNECTION을 실행하면 대상 커넥션의 실행 계획을 확인할 수 있다. [15] Range checked for each record(index map: N) 조인에서 t1.id >= t2.id 이런 조건이 있을 때 t1.id에 따라 비교해야할 t2의 레코드 수가 달라진다. 이 경우 옵티마이저는 레코드마다 인덱스 레인지 스캔을 할지 풀스캔을 할지 결정해야하는데 이때 표시되는 것이 range checked for each record이다. index map은 테이블의 인덱스 중에서 사용할 것을 1로 표시하는 비트맵을 16진수로 바꾼..
10.3.8 key_len 컬럼 쿼리를 위해 사용하는 다중(단일 포함) 컬럼 인덱스에서 몇개의 컬럼까지 사용했는지(인덱스의 각 레코드에서 몇 바이트까지 사용했는지) 알 수 있다. NULLABLE한 컬럼에는 추가적으로 1바이트가 붙는다. 10.3.9 ref 컬럼 동등 비교 조건으로 어느 값이 참조됐는지 확인 가능. 상수값을 지정했으면 const, 다른 테이블의 컬럼을 지정했으면 해당 컬럼이 명시된다. 동등 비교 조건에 연산을 넣게 되면 func로 나온다. 이 때는 MySQL서버가 내부적 혹은 명시적(쿼리에 써있다면)으로 해당 함수를 실행시킨후 조건을 확인한다. 되도록 타입을 일치시키는게 좋다. 10.3.10 rows 컬럼 실행 계획에서 예측된 레코드 수(쿼리를 처리하기 위해 얼마나 많은 레코드를 읽고 체크..