전체 글
F-lab 멘토링 후기(2/2) - 개발이 다이빙이라면
F-lab 멘토링 후기(2/2) - 개발이 다이빙이라면
2023.03.182편에서는 '왜 멘토링을 선택했는지'에 대해 리뷰해보려고합니다. 어느 순간 저는 개발이 다이빙이 아닐까라는 생각이 들었습니다. 멘토링 이전의 저는 다이빙을 한다면서 계속 배를 타고 여기저기 다니면서 수심이 얕은 곳만 다녔습니다. 개발자에게 필요한 것은 에프랩에서 작성한 블로그를 한 편 보게 됩니다. https://f-lab.kr/blog/importance-of-self-improvement 개발자는 왜 40살에 치킨집을 차리게 될까? 올해 하반기부터 블로그를 제대로 시작하면서 이라는 콘텐츠를 기획하게 되었는데요. 이 카테고리에서는 개발 기술 관련 글, 프로젝트, 스터디 경험담 등 ‘좋은’ 개발자로 성장하기 f-lab.kr 블로그의 제목은 개발자는 왜 40살에 치킨집을 차리게 될까? 로 제가 가지고 있는..
F-lab 멘토링 후기(1/2) - 관객에서 다이버로
F-lab 멘토링 후기(1/2) - 관객에서 다이버로
2023.03.11멘토링 전의 나, 멘토링 중의 나, 멘토링 후의 나에 대한 내용을 담은 멘토링 리뷰입니다. 목차 [1편] 관객에서 다이버로 - 명화를 감상하려면 - Intro. - 평범한 관람객이 멘토라는 전문가와 '모나리자'를 분석한다면? - 절망의 계곡을 너머 깨달음의 비탈길로 한걸음 - 오롯이 홀로 서보기 [2편] 개발이 다이빙이라면 - 개발자에게 필요한 것은? - 독학으로 채울 수 없는 것 - 멘토링? 멘토? 구루? - 모르는게 적을수록 많이 안다. - 멘토링에서 하는 다이빙 F-lab을 고민하시는 분들 뿐만 아니라 저 또한 처해있는 상황이 모두 다를 것이기 때문에 '꼭 했으면 좋겠다'라는 의견보다 자신의 개발 실력이 더이상 성장하지 않는다라고 느끼며 답답함을 느끼거나 개발자로써의 커리어에 대한 고민을 하시는 분..
2022년의 회고록
2022년의 회고록
2023.01.10작년의 회고록은 2월이 돼서야 쓴 것을 보고 2022년의 회고록은 이번 해가 지나가기 전에 미리 써보려고 한다. 분명히 새해가 시작되기 전과 후는 바쁠 것이라는 예상과 새롭게 가는 곳에서 적응하기 위해 정신이 없을 것이란 느낌적인 느낌이 들기 때문이다. 지금 다시 2021년의 회고를 보면 난 팀원으로써, 개발자로서, 나 자신으로써도 많이 부족했다. 나에게 2022년은... 진짜 게임은 지금부터 시작이다. 2022년 전반전 2022년의 첫 시작은 비참했다. 새해가 시작되면 흔히 회사에서는 새로운 마음으로 산뜻하게 일을 시작하곤했지만 새해가 시작됨과 동시에 소문이 들려오기 시작했다. 회사 자금이 점점 바닥을 보이고 있다. 2021년의 마지막에 생각했듯이 이직하겠다는 마음은 굳건했다. 하지만 고민해야 될 것은..
[#12] YOUSINSA, 이대로 괜찮은가?
[#12] YOUSINSA, 이대로 괜찮은가?
2022.11.11개요 마지막 개선사항까지 포스팅을 완료했지만 그동안 면접, 포트폴리오 피드백을 다양하게 받으면서 알게 된 부분과 더불어서 이미 알고 있는 개선 필요 지점, 아쉬운 부분을 기록하기 위해 "이대로 괜찮은가" 편을 남기려고 합니다. 그리고 이렇게 기록된 사항을 바탕으로 다시 프로젝트를 이어서 진행하면서 개선해나가면서 최종적인 목표인 Version 4까지 달려가기 위한 증거로 남기고 싶었습니다. YOUSINSA 프로젝트 테스트 시나리오의 한계 개선을 진행해서 목표한 동시 사용자 500명을 기준으로 각각의 API에 대해서 1250 TPS는 달성했습니다. 하지만 실서비스에서도 정상적으로 돌아갈 것이라 낙관할 수 있을까라는 의문이 들었습니다. 실서비스에서도 정상적으로 문제없이 돌아갈 것이라고 확신하게 되는 경우는 무..
[#11] 재고 관리는 어떻게 해야될까? - 3. Eventually Consistency
[#11] 재고 관리는 어떻게 해야될까? - 3. Eventually Consistency
2022.11.07개요 이전 포스팅에서 진행했듯이 Lua Script를 적용함으로써 Redis의 Atomic한 재고 관리를 수행할 수 있었습니다. 곧바로 nGrinder를 통해 트래픽을 발생시켜 이전보다 개선되었는지 확인하고 싶은 마음이 굴뚝같았으나 다시 한번 고민에 빠졌습니다. 왜 항상 Database는 구매 시마다 차감되는 재고를 기록해야될까? A. [#10] 재고 관리 Integrity 문제 포스팅을 해결하는 시점에서는 재고를 실시간으로 차감하여 실물상 재고와 서비스 상의 재고를 일치시켜 고객 경험을 높이기 위해서 구매 시마다 Database에서의 실시간 재고 차감이 필요합니다. B. [#11] 재고 관리는 어떻게 해야 될까? - 1. Redis Transaction 포스팅부터 [#11] 재고 관리는 어떻게 해야될까..
[#11] 재고 관리는 어떻게 해야될까? - 2. Lua Script
[#11] 재고 관리는 어떻게 해야될까? - 2. Lua Script
2022.11.07개요 이전 포스팅에서는 Redis의 Transaction을 사용하여 Cache Layer에서의 데이터 일관성을 보장하려고 시도했지만 Redis의 Transaction과 관련된 동작에서 Read-Write 패턴의 사용은 지원하지 않는 한계점이 있었습니다. 이런 한계점을 다시 해결해보기 위해서 Redis와 관련된 동작을 분석해보았습니다. 재고 관리와 관련된 Redis의 동작을 정리하면 크게 3가지로 요약할 수 있습니다. - Redis에 해당 제품의 재고가 없으면 Database에서 재고를 갖고 온 뒤 검증한다. - Redis에 해당 제품의 재고가 있다면 재고 수에 대해 검증한다. - 재고수를 차감한 뒤 Database에도 차감된 재고를 동기화한다. Redis에서 지원하지 않는 동작은 수행하지 못하는 것일까?..
[#11] 재고 관리는 어떻게 해야될까? - 1. Redis Transaction
[#11] 재고 관리는 어떻게 해야될까? - 1. Redis Transaction
2022.10.27개요 지금까지 데이터의 무결성을 위해 해결을 시도한 영역은 백엔드를 구성하는 부분 중 Database였습니다. 데이터 베이스에서 Transaction들을 Serial하게 수행하여 무결성을 확보하고 성능과 Trade-Off 했습니다. 하지만 E-Commerce 분야에서 하나의 상품을 많은 사람들이 구매하는 상황은 빈번하게 발생한다고 생각했었을 때 성능 또한 향상시킬 필요성이 있습니다. 왜냐하면 구매를 하기 위해 오랜 시간 대기하였지만 실패되는 경험은 유저에게 서비스의 신뢰도를 떨어뜨린다고 판단했습니다. 그렇다면 어떻게 재고 데이터의 무결성을 보장하면서 성능 또한 올릴 수 있을지 방안을 고안해보았습니다. 구매 주문 과정 분해하기 현재는 '재고'라는 상태를 모두 데이터 베이스에 저장하기 때문에 발생하는 문제라..
[#10] 재고 관리 Integrity 문제 - 2
[#10] 재고 관리 Integrity 문제 - 2
2022.10.15개요 이번 포스팅에서는 재고 관리 Integrity 문제 1편의 마지막에 '왜 Database Lock이 Distributed-Lock보다 TPS 성능이 좋겠나왔는가?'를 다뤄보려고 합니다. 주의🚫 : 해당 테스트에서 Distributed-Lock이 DB Lock보다 성능이 안 좋게 나왔지만 Database Lock은 항상 Distributed-Lock보다 좋다라는 관점은 적절하지 않습니다. Distributed-Lock은 왜 사용할까? 처음 예상하기로는 In-memory DB를 통해서 Lock을 수행하므로 막연히 더 빠르겠지(?)라는 생각을 갖고 있었습니다. 더불어 분산 락으로 인해 Database에서 해당 Row에 대한 Update 동작을 경합할 Transaction의 수가 적어지니 Database에..
[#10] 재고 관리 Integrity 문제 - 1
[#10] 재고 관리 Integrity 문제 - 1
2022.10.13개요 구매 부분은 대부분 서비스들의 핵심이고 커머스 도메인에서 재고 관리의 경우 비즈니스와 밀접한 연관이 있다고 생각합니다. 관리측면에서 보면 100개 밖에 없는 상품을 120개 판매했다고 기록한다면 추후 실제 재고를 관리하는 팀에서는 추가 발주를 진행해야 될 수도 있고 만약 추가 발주를 통해 재고가 확보가 안된다면 구매했던 고객들의 상품을 취소해야 합니다. 결국 이런 일들이 반복되면 비즈니스적으로 악영향을 끼칠 것이 분명합니다. 도메인마다, 서비스마다 다를 수도 있습니다! 결국 Trade-Off가 핵심 10개의 제품을 10명이 1개씩 구매했지만 2개가 남아있는 상황같이 반대의 경우는 어떨지 생각해보았습니다. 현재 구매를 진행한 고객들은 상품을 잘 받았지만 재고가 있어 추가적으로 구매하려 했지만 실패하는..
[#9] Scale-Out 테스트 결과 분석하기
[#9] Scale-Out 테스트 결과 분석하기
2022.10.11개요 Scale-Out에 필요한 사전 준비 사항들은 모두 Infra에 반영하여 구성을 완료했습니다. Pinpoint를 Scale-Out 시킨 Server에 모두 설치하여 Application Server를 모니터링할 수 있도록 구성하였고 Database Server의 경우 이전과 마찬가지로 Prometheus, Grafana를 통하여 테스트 결과를 확인했습니다. TPS 비교 이번 테스트의 목표는 Scale-Out을 도입하였을 때 어느정도의 성능 향상이 이루어지는지와 또 다른 병목지점을 찾기 위한 목적입니다. Scale-Out을 위한 사전 작업을 적용하기 전과 Scale-Out 적용된 Infra를 비교했습니다. 그래프를 확인해보면 전반적으로 Scale-Out시 성능이 향상 된 것을 볼 수 있습니다. 비교를..
[#8] Scale-Out을 위한 사전 준비 작업
[#8] Scale-Out을 위한 사전 준비 작업
2022.10.05개요 이전에 진행했던 Scale-Up을 통해서 Application Server의 Resource 부족의 재검증과 성능이 개선되는 것을 포스팅했었습니다. 마지막으로 결론은 '이제는 Scale-Out을 해야 할 때'라고 적었었습니다. 그래서 이번 포스팅을 통해 Scale-Out을 어떻게 진행했는지 보겠습니다. 수평적 확장(?) #1에서 개선하여 지속적으로 사용해온 Infra 구조도입니다. 바로 수평적 확장을 적용해보겠습니다. 현재 Client라고 볼 수 있는 nGrinder Agent가 요청을 분산해서 보낸다면 바로 수평적 확장이 가능하겠지만 추가적인 Component나 로직이 없으므로 기본적으로 기존에 요청을 보내던 Server로 보낼 것입니다. 비슷한 개념으로 MSA(Micro-Service Archi..
[#7] DeadLock 발생 해결하기
[#7] DeadLock 발생 해결하기
2022.10.04개요 Scale-Out을 위한 사전 작업을 진행하기 전에 구매 API를 정상화할 필요성이 있었습니다. 이전 #1[구매주문] 에서 다뤘듯이 같은 품목 옵션을 많은 사람들이 동시에 구매하는 경우 DeadLock이 발생하며 CannotAquireLockException이 발생했습니다. 그리고 쿼리 최적화에서 인덱스가 영향을 줄 수 있을지 몰랐다는 부분과 연관됩니다. 정확히는 제약 조건이 어떤 영향을 줄지 몰랐다는 점입니다. 그럼 어떻게 DeadLock의 원인과 해결했는지에 대한 설명을 진행해보겠습니다. 어디서 DeadLock이 발생할까? Pinpoint를 사용하여 StackTrace를 볼 수 있어 문제의 실마리는 쉽게 찾을 수 있었습니다. MySQL에서 DeadLock이 발견되어 Exception이 발생하게 ..