오픈 채팅방에커리어 상담글이 올라왔다. 현재 나는 4년째 백엔드 개발자고 8개월째 이직 준비중에 있다. 또한 도메인변경을 원했기 때문에 커리어 상담을 신청하게 되었다. 어찌 저찌 신청서를 제출하고 기달렸다. 10월 26일 일요일 7시에 상담해준다는 연락을 메일로 받았다. 사실 토욜이었는데 취소되었고 일욜로 바뀌었지만 난 못봤다. 상담 시작간단하게 자기소개를 하고 어떤것을 지금 중점적으로 해야 하는지 설명해주셨다. 일단 나는 이커머스로 도메인 변경을 원했는데사실 이커머스에서 어떤일을 하는지 왜 그 도메인을 원하는지에 대해 구체적으로 고민하지 않았던거 같다. 단순히 생각했을때 고객들과 가장 밀접한 도메인이라고 생각만 했지 구체적으로 생각하지는 않은거 같다.기술같은 경우도 머릿속에 아른거리는 기술들만 있지 실..
이전 장에서 예고한것처럼 쿠키랑 세션에 대해 알아봅시다. HTTP에서 TLS이 추가되어서 보안이 증가된 형태인거는 이제 이해했는데 그렇다면, 인증쪽은 어떻게 처리를 해야 할까요? 아니 애초에 이게 왜 필요한건지 이해할 필요가 있을거 같습니다. 웹이나 앱등등 사용자를 등록하게 되어집니다. 등록을 하게 되면 로그인이라는걸 하게 되는데 그런 다음 어떻게 해야 할까? 쿠키나 세션 하물며 JWT토큰 조차 없다고 생각해보자 이거는 그냥 데이터에 불과할겁니다.. 그걸 통해 뭔가 액션을 취할 수 는 있겠는데 그걸 계속 유지를 시킬 수는 없습니다. 왜냐하면 HTTP는 알다시피 Stateless 비연결성 프로토콜입니다. 즉, 한 번 요청하고 응답이 끝나면 그 연결에 대한 기억은 완전히 사라집니다. 여기서 어라? HTTP는..
지난번에 TCP와 UDP를 학습하였습니다. 이제 이것을 발전시킨 기술 하나를 살펴볼 건데요. 그것은 바로 HTTP입니다.HTTP가 웹을 위한 프로토콜로 잘 알려져 있긴 하지만 HTTP에 대해 잘 알지 못하고 있습니다. 인터넷에 HTTP를 검색하면 많은 정보들이 나오긴 하지만 생각만큼 잘 와닿지 않았습니다. 1960년대에 HTTP라는 기술에 대한 설계가 시작이 되었고, 팀 버너스 리를 필투로 1989년에 HTTP가 개발이 되었다고 합니다. 어떻게 보면 중요한 내용일 수도 있겠지만, 생각해 보면 지금 말하고 있는 사실과 HTTP의 연관성을 짓지 못하는 경우가 많은 거 같습니다. 이러한 이유가 발생한 이유가 뭘까요? 단순히 암기를 하려고 했던 게 아닐까요? 이번에 제대로 HTTP를 빠개봅시다.HTTP는 어디에..
* 초안입니다. 배경TCP는 뭐고 UDP는 뭘까우리가 알기로는 TCP는 느리지만 신뢰성이 좋다고 하고, 그리고 UDP는 느리지만 신뢰성이 좋지 않는다고 한다.왜 그럴까?어떤 이유 때문에 TCP는 느릴까?TCP는 UDP보다 하는일이 굉장히 많다. 예를 들어, 신뢰성과 안정성을 보장하기 위해서는 기능이 많이 필요하다.다음은 TCP,UDP가 하는일은 다음과 같다고 한다.📡 TCP (이중 확인, 안정형)[연결 준비] → 3-way handshake[데이터 전송] → 패킷 전송 후 ACK 수신[손실 발생] → 재전송[혼잡 발생] → 전송 속도 감소[종료] → 4-way handshake로 세션 정리➡️ 신뢰성 높음, 하지만 왕복 지연(RTT)마다 제어 수행 → 상대적으로 느림⚡ UDP (던지고 잊기, 불안정형)..
학습 키워드Unit Test / Integration Test / E2E Test테스트 Pyramid테스트 커버리지 vs 유의미한 테스트유닛테스트라는건 뭘까?서비스단에서? 컨트롤단에서? 음 아무래도 상관없으려나유닛테스트는 단위테스트라고 하며그림을 보면 알수 있듯이 단위 테스트는 테스트 피라미드 바닥에 존재하며 굉장히 많은 수 가 있다는 것을 알 수 있습니다.이는 간단하게 작성이 되어진다는 뜻이 되어집니다.이전 포스트에서도 말했었지만 테스트코드는 굉장히 중요합니다. 그렇다는 이야기는 e2e를 하든 통합을 하든 유닛을 하든작성을 하는것이 좋습니다. 여기서 중요한 사실은 유닛테스트가 양이 제일 많다는 것입니다. 그렇다는건 유닛테스트를 중점으로 테스트코드를 짜야 된다는 뜻이 됩니다.그리고 그림에서 보면 알 수 ..
10주간을 되돌아 보며10주동안 이커머스에서 발생할 수 있는 여러가지를 학습을 하였다. 1주차로 워밍업을 하고 2~10주차에서 본격적으로 설계를 진행하였다.사실 어떤것을 학습을 하였는지 구체적으로 기억은 잘 나지 않는다. 일단 기억이 나는데로 얘기를 해보자면1주차1주차때 테스트 코드를 작성하였다. 테스트 코드의 중요성은 잘 알고 있었지만 뭐랄까 막연한 두려움이 있었다. 어떻게 작성하면 될까...@DisplayName("두개에서 한개를 제거하는 경우, 주문 상품의 갯수는 한 개를 리턴합니다.")@Testvoid returnOrderItemSizeIs1_whenRemove1Product() { //given OrderItemModel orderItem1 = OrderItemModel.builder() ..
랭킹이라가는건 뭘까 단순한 줄 세우기인가어떤 기술을 사용하면 효율적일까?사실 랭킹은 생각보다 쉽다.정확히 말하면 쉽게 생각할 수록 쉽게 만들 수 있는거라 생각한다.랭킹은 RDB로 하는것이 좋을까? 아니면 nosql로 하는것이 좋을까?정답은 없다고 생각한다.어떤 기술을 사용해야 한다는것은 없다고 생각한다.nosql중에는 레디스를 활용해서 데이터를 저장한다.결국 RDB랑 레디스와 비교를 하는것이 중요하다고 생각이 든다.어떤것이 더 랭킹 시스템에 어울릴수 있는지 생각할 수 있을거 같다.나는 랭킹 시스템을 레디스로 만들었는데 그 이유는 낮은 오버헤드와 읽기 성능이 좋다는 것을 높게 평가하였다.레디스는 다양한 자료구조를 지원하는데 그 중에서도 Zset을 이용하게 되었다. Zset은 레디스가 가지고 있는 낮은 오버..
배경카프카에서 수신한 정보를 토대로 계산하여 랭킹을 산출하고 있었다. 지금 보여주고 있는것이 사용자가 원하는 랭킹일까?잘 모르겠다. 실제로 운영이 되지 않는점도 크다고 생각한다. 만약 실제로 운영 된다면, 사용자들이 자주 들어오는 시간을 측정해서 가중치를 반영할 수도 있다 생각한다. 실제로 운영되는 환경이 아니기 때문에 부하테스트를 돌려서 확인하는것이 최선이지 않나 싶다.랭킹 서비스를 만들기 위해서는 데이터를 저장을 해야 한다. 그래야 그걸 통해 정보를 보여줄 수 있기 때문이다. 그래서 최대한 예상을 해서 작성해보려구 한다.수신 장치현재 카프카를 통해 데이터를 수신하고 있다.각 토픽에 맞게 메시지를 전송하고 있다.@Component@RequiredArgsConstructorpublic class Prod..
사실 카프카에 대해 잘 모르겠다. 아직..카프카가 고가용성이라고는 하지만 이게 개발자인 나에게 엄청나게 와닿지는 않았다.나야 프로듀서에서 컨슈머로 데이터만 잘 전달만 하는게 목적이기 때문이라 생각이든다.그렇다고 해서 저 부분이 중요하지 않는다는건 아니다.내가 말하고 싶은건 개발자인나에게 저것보다는 어떻게 사용할 수 있는냐가 더 중요하지 않나 생각이든다.그래서 그 부분에 초점을 맞춰서 공부를 했던거 같다.프로듀서의 개념토픽의 개념파티션키의 개념컨슈머의 개념배치 리스너 오프셋 개념..등등 여러가지 개념들을 그 초점에 맞추면서 공부를 하였다.저 개념들을 100% 전부 이해한건 아니지만 이제 시작이라 생각이 든다. 하나하나 전부 이해한것은 아니지만적어도 커다란 맥락에서 저러한 개념들을 왜 사용하는지 확실하게 이..
배경카프카는 어떤 목적으로 사용이 되어질까? 왜 하필 카프카일까?사실 반드시 카프카여야 된다는 이유는 없다고 생각한다. 카프카는 우리가 알기에는 메시지 큐정도만 알고 있는데사실 단순한 메시지 큐는 아니다. 정확히 말하면 분산 메세지 스트리밍 플랫폼이다.카프카에 대해서는 엄청나게 공부할것이 많지만 여기에서는 두 가지만 이야기를 할 예정이다. 프로듀서와컨슈머.. 프로듀서에서 메시지를 발송하고 컨슈머쪽에서 받는 그럼 시스템이다.구현하면서 생각보다 쉽지 않음을 느꼇다.어떤 부분에서 고민했는지 생각해보자.프로듀서프로듀서는 다음과 같이 작성을 하였다.public class LikeKafkaEventPublisher { private final KafkaTemplate kafkaTemplate; private f..
생각보다 이벤트에 대해 많은 고민을 하지 않았던거 같다.단순히 커멘드가 뭔지 이벤트가 뭔지 거기에 초점을 맞췄던거 같다.과연 내 프로젝트에 어떻게 이벤트를 적용할지 단순하게 생각했던거 같다.내가 생각한건주문 -> 쿠폰결제 -> 포인트결제 -> 재고좋아요 -> 집계 이렇게 생각을 했었다.이렇게 생각해도 크게 문제 될거 까지는 없지만 뭐랄까 어떤 흐름에서 어떻게 흘러가는지 그게 블로그글에 잘 드러내지 않은점이 아쉬움에 남는거 같다.그래도 잘한점은 커멘드와 이벤트를 어떻게 분리하고 고민한점은 나름 잘했던거 같다.나는 다음과 같이 커멘드와 이벤트를 분리하였다.커멘드는 특정 도메인이 타 도메인에게 메시지를 전달할것인가이벤트는 특정 도메인이 타 도메인에서 동작하는 행동을 알 수 있을까 였다.이런 기준으로 생각하니 ..
