티스토리

개발이야기

검색하기

블로그 홈

개발이야기

seungjjun.tistory.com/m

seungjjun 님의 블로그입니다.

구독자: 3

방명록 방문하기

주요 글 목록

2024년 회고 2024년의 키워드는 '경험'이었다.2023년 4월에 개발자로 커리어를 시작하며 2023년은 회사에 적응하며 보냈었고, 차츰 적응이 되기 시작했던 2024년은 다양한 경험을 하기 위해 이것저것 시도를 많이 해보았다.회고를 통해 이번 연도에 경험했던 것들을 다시 돌아보며 정리해보려고 한다. 우당탕탕 사이드 프로젝트우선 2024년 1월에는 사이드 프로젝트를 "비사이드"라는 플랫폼을 통해 시작했다."비사이드"는 사이드 프로젝트 모임 플랫폼인데, 14주간 개발자, 디자이너, 기획자들과 함께 한 팀을 이루어 프로젝트를 출시하는 프로그램에 참여했었다. (다시 찾아보니 지금은 사라지고 10일 만에 끝내는 포텐데이라는 프로그램만 존재한다.)결과부터 말하면 프로젝트는 출시조차 하지 못하게 되었다.기획, 디자인, 개발까지.. 공감수 1 댓글수 1 2024. 12. 23.
Kafka Streams, 코파티셔닝(co-partitioning)을 모르면 벌어지는 KStream-KTable Join 대참사 Kafka Streams를 활용하여 실시간 피드 제공 기능을 개발하는 도중 KStream-KTable 간 조인 시 발생했던 문제 상황을 공유하고자 합니다.글에서 제공되는 예시 코드는 실제로 동작하지 않는 pseudo code입니다. 현재 상황코스피/코스닥에 상장된 기업들의 주가 정보(시가/고가/종가/현재가 등등)을 5초마다 호출하여 파티션이 5개인 토픽에 저장합니다.오전 6시에 이전 영업일의 코스피/코스닥에 상장된 기업들의 valuation 값(per, pbr, psr 등등)들이 저장된 엑셀 데이터를 파싱하여 DB 저장 및 파티션이 1개인 토픽에 저장합니다. 두 토픽에 저장된 데이터를 이용하여 각 기업의 실시간 주가 정보를 이용하여 valuation을 계산하여 오전 6시에 엑셀 데이터를 파싱하여 토픽에.. 공감수 0 댓글수 0 2024. 11. 6.
자바에서의 CRTP(Curiously Recurring Template Pattern) 최근 빌더 패턴을 구현하다 CRTP(Curiously Recurring Template Pattern) 패턴을 알게 되었는데, 처음 접하는 패턴이라는 점과 제네릭을 통해 구현된 다소 복잡해 보이는 패턴이라 공부하게 되었습니다. 이번 글을 통해 CRTP 패턴이 무엇인지와 장단점에 대해 소개드립니다. CRTP란?CRTP는 원래 C++에서 주로 사용되는 패턴으로 클래스가 자신의 서브클래스 타입을 제네릭 매개변수로 사용하는 디자인 패턴입니다. 자바에서는 주로 빌더 패턴에서 자식 클래스의 타입을 부모 클래스에 전달하여 메서드 체이닝 시 자식 클래스의 메서드를 사용할 수 있게 합니다. (제네릭을 이용한 재귀적 타입 제한) 즉, 빌더 패턴에서 주로 이루어지는 메서드 체이닝에서 자식 클래스 타입을 유지함으로 컴파일 시.. 공감수 0 댓글수 0 2024. 8. 6.
주식 시황 피드의 종가 오류 해결기(데이터 일관성 개선) 항상 버그는 퇴근하고 발생하는 것 같은 기분이 듭니다. 주식 시장이 마감되고 코스피/코스닥에 상장된 종목들의 종가 및 종목 수익률을 계산하여 당일 시황의 전반적인 상황을 피드로 생성하여 제공하는 기능을 개발하여 개발 서버에 배포된 상태입니다. 그런데 당일 코스피/코스닥 종목들의 주가 변동률이 잘못 계산되어 피드가 생성되는 버그가 발생하였습니다.문제의 원인을 파악하기 전 기존 피드를 생성하는 프로세스를 확인해 보겠습니다. 피드 생성 프로세스현재 저희 서비스는 MSA 구조로 설계되어 있고 피드를 생성하는 데는 3개 서버의 의존성이 있습니다.코스콤에서 코스피/코스닥에 상장된 종목들의 주가 정보를 호출하여 DB에 저장하는 서버당일 시황 관련 정보를 수집하고 요약하여 생성하는 서버 (ML팀)피드를 생성하는 서버.. 공감수 0 댓글수 0 2024. 7. 30.
Confluent Schema Reference 관련 문제 문제기존 Protobuf 포맷으로 정의된 스키마(Version 1)에 새로운 inner message를 생성하여 스키마 버전(Version 2) 업을 하는 경우 이전 버전 스키마가 새로 생성한 inner message 를 참조하지 못하여 스키마 업그레이드를 하지 못하는 문제가 발생. 해결스키마에 inner message를 생성하는 방식이 아닌 별도의 schema를 생성하여 수정할 스키마에서 이를 참조하는 방식으로 해결 + Terraform Provider로 Confluent Schema Reference 적용 시 발생한 문제A스키마에서 B스키마를 참조할 경우 참조할 스키마(B)가 먼저 생성이 되어 있어야 한다."A" 스키마에서 새로운 메시지인 "B" 스키마를 참조하려고 할 때, "B" 스키마 생성과, ".. 공감수 0 댓글수 0 2024. 7. 24.
[Java] List.of()와 Arrays.asList() 차이 문제List에 데이터를 추가할 때, null값 그 자체를 추가해야 하는데 NPE 에러가 발생했다.List.of() 메서드를 이용해 List를 만들어주었는데 List.of() 메서드는 null 요소를 허용하지 않기 때문에 발생한 문제였다. 해결해결은 간단히 List.of() 메서드 대신 Arrays.asList() 메서드를 사용하는것으로 변경하여 문제를 해결 할 수 있었는데, 이 둘의 차이가 무엇인지 알아보자. List.of() vs Arrays.asList()List.of()우선 List.of() 메서드는 자바9 버전 이후에 도입된 메서드로 파라미터로 전달받은 값들을 불변 리스트로 만드는 역할을 한다. 그리고 요소 하나하나 null인지 Objects.requireNonNull()메서드로 검사를 한다. 그.. 공감수 0 댓글수 0 2024. 7. 6.
정규화(Normalization)란? 정규화(Normalization)정규화: 데이터의 중복과 삽입, 갱신, 삭제 시 발생할 수 있는 이상 현상(insert, update, deletion anomaly)을 최소화하기 위해 일련의 정규화(Normal Forms, NF)에 따라 관계형 데이터베이스를 구성하는 과정이다.NF: 정규화되기 위해 준수해야 하는 몇 가지 rule 정규화 과정 : 1NF -> 2NF -> 3NF -> BCNF보통 실무에서는 3NF 혹은 BCNF 까지 만족하면 정규화되었다고 말한다. (최소 정규화 단계) 왜 정규화를 해야 할까?정규화를 하는 궁극적인 목표는 데이터의 중복을 줄이고 데이터의 무결성과 일관성을 유지하기 위해서이다. 비정규화된 데이터베이스 테이블 (고객 정보와 주문 정보를 하나의 테이블에 저장) ID .. 공감수 1 댓글수 0 2024. 6. 6.
MVCC(Multi-Version Concurrency Control) 개념 MVCC(Multi Version Concurrency Cotnrol)란?개념MVCC(Multi-Version Concurrency Control)은 데이터베이스에서 동시성을 제어하는 방법 중 하나로, 다수의 사용자가 동시에 데이터베이스를 사용할 때 트랜잭션 간의 격리 수준을 유지하여 동시성을 제어한다. MVCC의 가장 큰 목적은 Lock을 사용하지 않고 일관된 읽기를 제공하는 것이다. 동작 원리MVCC는 데이터의 버전(snapshot)을 관리함으로써 동시성을 관리한다.-> MVCC에서 Multi version인 이유가 하나의 데이터에 대해 여러 개의 버전이 동시에 관리된다는 의미이다.예를 들어, 두 트랜잭션의 read-write 간 데이터를 읽는(read) 시점에 해당 데이터의 스냅샷을 유지하고 다른.. 공감수 0 댓글수 1 2024. 6. 4.
Connection을 미리 생성하는 이유 Spring Boot을 사용하면 Connection pool에 미리 Connection을 생성하는데, 미리 생성하는 이유로 DB와 connection을 맺는 비용이 크기 때문에 애플리케이션 시작 시 미리 pool에 생성해 두어 필요할 때마다 꺼내 사용한다고 알고 있다. DB와 애플리케이션이 Connection을 맺는데 비용이 큰 이유가 뭘까?우리는 애플리케이션과 DB가 통신하는 방법을 알아야 한다.기본적으로 애플리케이션과 DB 서버와 통신을 하는 방법은 TCP/IP를 통해 통신을 하게 된다.TCP/IP는 신뢰성이 높은 통신 방법으로 신뢰성을 보장하기 위해 3-way handshake 과정을 통해 연결을 하고 연결을 종료할 때는 4-way handshake 과정을 통해 연결을 종료하게 된다. https:.. 공감수 0 댓글수 0 2024. 5. 21.
[E-commerce] 트랜잭셔널 아웃박스 패턴을 활용한 이벤트 기반 주문 처리 시스템 설계 및 구현(With Kafka) 현재 서비스의 트랜잭션 범위에 대한 이해상품 주문 결제 트랜잭션Tx -> 사용자 조회 -> 장바구니 조회 -> 주문 및 주문 아이템 생성 -> 재고 차감 -> 결제 -> 주문 정보 전송 -> commit현재 트랜잭션 범위의 문제점긴 트랜잭션 : 하나의 트랜잭션에서 주문, 결제 같이 여러 작업을 처리하게 될 경우 트랜잭션의 작업 시간이 길어져, 다른 트랜잭션에서 커넥션이 필요할 때 대기시간이 길어져 사용성이 떨어진다.-> 트랜잭션의 사용시간이 길어 생기는 문제전체 롤백 문제 : 주문 정보를 외부 데이터 플랫폼에 전송 도중 오류로 인해 전송에 실패하면 이전 작업(주문 생성, 재고 차감, 결제)들이 모두 롤백된다. 상품 주문 시 핵심적인 비즈니스 로직이 부가적인 주문 정보 전송 로직에 의해 롤백되고 있기 때문.. 공감수 0 댓글수 1 2024. 5. 17.
메시지 큐와 카프카 메시지 큐란?메시지 큐는 분산된 환경에서 프로세스나 프로그램의 시스템 간 데이터를 교환하기 위해 사용되는 통신 기법이다. 그리고 메시지를 일시적으로 저장하는 큐(queue)로 송신자(producer)와 수신자(receiver/consumer) 간비동기 통신을 가능하게 한다. 메시지 큐 사용 이유이러한 메시지 큐를 사용하는 이유가 뭘까?비동기 처리 : 메시지 큐를 사용하면 producer와 consumer가 독립적으로 작동할 수 있다.이는 producer는 메시지를 큐에 넣고 바로 다음 작업을 처리할 수 있고, consumer도 메시지를 수신하며 자신의 속도에 맞게 메시지를 처리할 수 있다.느슨한 결합 (decoupling) : 시스템 간 서로 직접 통신하지 않고 메시지 큐를 이용하기 때문에 시스템의 각.. 공감수 0 댓글수 0 2024. 5. 15.
2024년 5월 2주차 주간회고 애플리케이션 성능 향상이번 주차는 인덱스와 캐시를 이용해 기존 애플리케이션의 성능을 높이는 것이 주요 목표였다. 애플리케이션의 성능을 높이기 위해서는 여러 가지 방법이 존재하겠지만 그 중 이번에는 DB의 성능 튜닝과 캐시를 이용하여 애플리케이션의 성능을 향상해보았다. 저번주와 마찬가지로 이번주도 인덱스의 대한 이해를 위해 Real MySQL8.0의 인덱스 챕터 부분을 읽고 시작한 게 매우 도움이 되었다.그 중 DB 성능 튜닝의 핵심은 "어떻게 디스크 I/O를 줄이느냐가 관건"이라는 것을 배웠다. 디스크의 I/O를 줄이는 방법으로는 인덱스를 이용해 DB를 최적화하는 방법과 캐싱 방법이 존재한다. 인덱스인덱스를 통한 효율적인 쿼리로 불필요하게 데이터에 접근하는 것을 줄일 수 있기 때문에, 인덱스에 대해 공.. 공감수 0 댓글수 0 2024. 5. 13.
[E-commerce] 캐시를 통한 애플리케이션 성능 개선 Redis 캐시 읽기 전략Look Aside (Cache Aside)데이터를 조회할 때, 캐시에 저장된 데이터가 읽는지 확인하고 없으면 DB에서 조회하는 전략캐시에 장애가 생겨도 DB에서 조회하면 되기 때문에 캐시 장애가 애플리케이션에 영향을 미치지 않는다.동일 조회 쿼리가 반복적으로 발생하는 상황에서 적합한 전략Read ThroughLook Aside 전략과 다르게 데이터를 캐시에서만 조회하는 전략조회하려는 데이터가 캐시에 없으면 캐시에서 DB에 접근하여 조회 후 캐시에 저장DB에 접근하는 횟수를 줄여 성능을 높일 수 있지만 캐시에 장애가 발생할 경우 애플리케이션에 영향을 미친다.Redis 캐시 쓰기 전략Write Back비동기로 캐시와 DB를 동기화 한다.DB에 저장할 데이터를 캐시에 저장해두었다가.. 공감수 0 댓글수 1 2024. 5. 10.
[E-commerce] 쿼리 분석 및 인덱스 설계를 통한 성능 개선 인덱스(Index)인덱스는 책의 목차와 비슷하다고 생각하면 편하다.책의 목차를 보고 어디에 무엇이 있는지 바로 확인할 수 있는 것 처럼 인덱스도 바로 찾고자 하는 데이터를 찾을 수 있다. 목차도 "ㄱ", "ㄴ" 순으로 정렬되어 있는 것 처럼 인덱스도 정렬되어 보관이 된다.그래서 미리 정렬된 상태에서 새로운 인덱스를 추가,삭제, 변경하는 작업은 느리지만 조회(SELECT)하는 작업은 빠르게 처리 가능하다. 즉, 인덱스는 데이터 저장 성능을 희생하고 데이터의 읽기 속도를 높이는 기능이다.B-TreeB-Tree는 칼럼의 원래 값을 변형시키지 않고 인덱스 구조체 내에서는 항상 정렬된 상태로 유지한다.B-Tree는 트리 구조이며, 최상상위에 "루트 노드(Root node)"하나가 존재하며, 하위에 자식 노드가 붙.. 공감수 0 댓글수 0 2024. 5. 10.
2024년 5월 1주차 주간회고 대용량 트래픽 & 데이터 처리 챕터 시작본격적으로 대용량 트래픽과 데이터를 처리하기 위한 과정이 시작되었다. 이번주는 현재 이커머스 서비스에서 발생할 수 있는 동시성 상황들을 분석해 보고 여라가지 방법들의 각각의 장단점을 파악하여 직접 동시성 문제를 해결해 보았다. 우선 나는 이전까지 개인적으로 진행하는 프로젝트나 실무에서 조차 동시성 문제를 직접 고려해 본 적이 없다. 그래서 어떤 상황에서 동시성이 발생하는지 1도 모르고 더군다나 DB에 대한 공부를 거의 하지 않아서 어떻게 해결해야 하는지 1도 모르는 상황이었다. 그래서 DB를 먼저 공부해야겠다고 생각을 하여 현재 주로 사용하는 DB인 MySQL을 공부하기 위해 Real MySQL8.0을 사서 먼저 트랜잭션과 잠금 파트를 읽어보았다.덕분에 MySQL.. 공감수 0 댓글수 0 2024. 5. 4.
[E-commerce] 동시성 문제 해결하기 (비관적 락, 네임드 락, 분산 락) 이커머스 서비스에서 발생할 수 있는 동시성 문제들을 정리하고, 다양한 방법으로 동시성 문제를 해결해 보며 겪은 경험들을 공유해 보자 합니다. 동시성 문제가 발생할 수 있는 유즈케이스Case 1 (조회한 상품 재고 수량이 맞지 않는 경우)1. 사용자 A가 재고가 5개인 상품을 조회하고 재고 1개 차감 요청, 트랜잭션 시작2. 사용자 B가 동시에 동일 상품의 상품을 조회, A의 트랜잭션이 아직 커밋되지 않았기 때문에 재고가 5개인 것으로 확인3. 사용자 A의 트랜잭션이 커밋되어 실제 재고는 4개로 업데이트4. 실제 상품의 재고는 4개이지만 사용자 B가 조회한 상품의 재고는 5개로 재고 정합성 불일치 문제 발생 Case 2 (동시에 상품을 주문할 때, 상품의 재고가 부족한 경우)1. 사용자 A가 재고 3개 차.. 공감수 1 댓글수 0 2024. 5. 1.
2024년 4월 3주차 주간회고 E-commerce 마무리이번주는 E-commerce 서버 구축을 마무리하는 한 주로 아직 구현하지 못한 장바구니 관련 기능과 미비된 통합 테스트를 추가 작성하고, 주문 결제 시스템을 이벤트 기반 아키텍처 구조로 변경하는 작업을 했다.특히 기존 하나의 트랜잭션 단위의 주문 결제 시스템에서 이벤트 기반 아키텍처 구조로 변경하는데 많은 시간을 사용했다.이벤트 기반 아키텍처 구조로 변경했을 때의 이점과 왜 변경해야 하는지에 대한 고민과 독립적인 트랜잭션 구성 방법에 대한 많은 고민을 하고 관련해서 트러블 슈팅 글을 작성했다.https://seungjjun.tistory.com/328 [E-commerce] 주문 결제를 이벤트 기반 아키텍처로 구축하기주문 결제를 이벤트 기반 아키텍처로 구축하기 이 글에서는 주문.. 공감수 0 댓글수 0 2024. 4. 23.
[E-commerce] 프로젝트 회고 프로젝트 선택 E-commerce 서버 구축 프로젝트를 통해, 다양한 기술적 문제와 해결 방안을 경험할 수 있었다. 프로젝트의 선택 과정부터 구현까지, 트랜잭션 관리 방안, 이벤트 기반 아키텍처 구조로의 전환과 같은 문제들을 다루면서 평소에 경험할 수 없었던 내용들을 학습하면서 프로젝트를 진행했던 것 같다. 처음에는 문서 작업부터 시작했는데, 프로젝트 초기 단계에서는 문서 작업의 어려움을 많이 느꼈다. 특히, 변경이 잦은 ERD와 API 명세의 수정이 반복되어 힘든 부분이 있었지만, 실제 개발을 진행하는 과정에서 초기 프로젝트 설계의 중요성과 필요성을 인식할 수 있었다. 트랜잭션 처리의 고민과 해결 이번에 이커머스 서비스를 진행하면서 가장 시간을 많이 소비했던 부분이 주문 결제 시스템의 트랜잭션 처리 였.. 공감수 0 댓글수 0 2024. 4. 17.
[E-commerce] 주문 결제를 이벤트 기반 아키텍처로 구축하기 주문 결제를 이벤트 기반 아키텍처로 구축하기이 글에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서 겪었던 문제와 그 과정을 공유하고자 합니다. 현재 이커머스 프로젝트의 주문 결제 시스템은 한 트랜잭션 내에서 동기 처리 방식으로 처리하고 있습니다. 현재 OrderUseCase를 간단히 살펴보면사용자 조회 -> 상품 조회 -> 상품 재고 조회 -> 주문 -> 결제 -> 재고 차감 순으로 주문 결제 시스템이 이루어져 있습니다. 그럼 이 주문 결제 시스템을 이벤트 기반 아키텍처로 구축하면서 겪었던 문제와 과정을 정리해 보겠습니다. 이벤트 기반 아키텍처로 변경하는 이유결합도 감소현재 주문 결제 시스템은 상품 재고 관련 로직, 결제 로직이 주문 로직에 깊게 관여되어 도메인끼리 강한 결합을 갖고 있다는.. 공감수 0 댓글수 0 2024. 4. 16.
함수적 종속성 (FD, Functional Dependency) 함수적 종속성(FD, Functional Dependency)함수적 종속성이란?함수적 종속성이란, 테이블 내에서 한 속성 X 값에 따라 다른 속성 Y의 값이 유일하게 결정이 될 때 “X가 Y를 함수적으로 결정한다.”라고 표현한다.반대로 "Y가 X에 함수적으로 종속된다."라고 표현할 수 있고 이는 테이블 내의 어떤 두 행에서 X의 값이 같다면 Y의 값도 반드시 같아야 한다는 것을 의미한다. 이러한 두 값 사이의 제약 관계를 functional dependency(FD)라고 부른다. 사용자 테이블을 예시 ID 이름 주소 1.. 공감수 0 댓글수 0 2024. 4. 14.
2024년 4월 2주차 주간회고 E-commerce 시작이번 주는 저번주에 ERD, 시퀀스 다이어그램 설계한 것을 바탕으로 본격적으로 e-commerce 서버 구축을 코드 작성을 통해 시작한 한 주였다.기본적인 잔액 조회 및 충전, 상품 조회, 주문 및 결제 API를 구현하고 관련 비즈니스 로직의 유닛 테스트 및 통합 테스트를 작성하는 게 이번 주 과제의 주요 포인트였다.기존에 설계하면서 생각하지 못했던 부분들이 코드를 작성하면서 생각이 나다 보니까 반복적으로 기존 설계 문서를 수정하는 상황이 발생했었다.예를 들어 기존에는 주문 결제 과정을 두 개의 API로 분리하여 설계했던 것을 코드를 작성하다 보니 하나의 트랜잭션 단위에서 처리하도록 변경한 것과 상품에 대한 테이블 설계를 상품과 상품 재고 테이블로 나눴던 부분 같이 기존 설계했을 .. 공감수 0 댓글수 0 2024. 4. 13.
[E-commerce] Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까? Facade Pattern을 사용하여 시스템 응집도와 재사용성을 어떻게 개선할 수 있을까? 이전 글에서 OrderService에서 의존하고 있는 컴포넌트가 너무 많아 응집도가 떨어지고 강결합이 발생하는 문제가 있었다고 언급을 했었습니다. 그래서 이번엔 facade pattern을 E-commerce 서비스에 적용하여 리팩터링 한 내용을 정리해보려고 합니다. 기존 OrderService 코드 public class OrderService { private final UserReader userReader; private final UserPointManager userPointManager; private final UserPointValidator userPointValidator; private fin.. 공감수 0 댓글수 0 2024. 4. 11.
[E-commerce] 주문 결제 트랜잭션 단위를 어떻게 가져가야 할까 주문 결제 트랜잭션 단위를 어떻게 가져가야 할까 이번에 이커머스 서비스를 만들면서 주문 결제 트랜잭션 단위를 어떻게 설계할 것인지에 대해 고민을 많이 하게 되었습니다. 우선 이 서비스에서 결제는 별도의 pg사를 연동하지 않고 user 테이블에서 point를 관리하여 이 point로 결제를 하는 서비스입니다. 주문 결제 트랜잭션을 분리하는 방안과 하나의 트랜잭션으로 가져가는 2가지 방안에 대해 어떤 방법이 더 적절(?)한 지 고민하고 생각했던 내용을 정리해보려고 합니다. 사실 "이 방법이 무조건 맞아!" 같은 정답이 없다는 건 머리로는 알지만 이런 선택을 해야 할 때는 누군가 정답을 줬으면 좋겠다는 마음이 있습니다. 아직까지는 트레이드 오프하는 게 쉽지 않은 것 같습니다.. 주문 결제 트랜잭션 분리 우선 .. 공감수 1 댓글수 0 2024. 4. 10.
2024년 4월 1주차 주간회고 E-Commerce 서버 구축 시작3주 차 과제는 3주간 서버 구축을 진행할 3개의 시나리오 중 하나를 선택하여 요구사항을 분석하고 관련 문서(시퀀스 다이어그램, ERD, API 명세 등등)를 작성하는 게 과제였다. 문서 작업이 중요하다는 것은 알지만 아직까지도 제일 하기 어렵고, 귀찮은 작업이였다. 귀찮게 느껴지는 이유 중 가장 큰 이유가 ERD 설계나 API 명세를 미리 작성을 해두면 처음부터 끝까지 수정이 되지 않으면 좋겠지만 어쩔 수 없이 중간 중간 수정이 불가피하게 발생하는데, 이 작업이 반복되어 귀찮게 느껴지는 것 같다. 그래서 프로젝트 시작 전 하는 설계에서 개발자로서 역량이 드러난다고 생각이 되었다. 아무튼 나는 이번 과제에서 e-commerce 서버 구축 과제를 선택했다. 다른 2개는 .. 공감수 0 댓글수 0 2024. 4. 9.
Domain과 Entity의 두 얼굴? 개발을 하다 보면 “도메인”과 “엔티티”라는 용어는 한 번씩 듣게 된다. 그런데 누구는 도메인을 엔티티와 비슷한 개념으로 사용해서 이야기하는 것 같고, 누구는 도메인과 엔티티는 다르다! 라고 말을 하는 것을 종종 볼 수 있다. 나 또한 그랬고 두 개념이 어떻게 다른지, 실상 모르고 용어를 사용했었다. 결론부터 말하면 내가 이해한 도메인과 엔티티는 같은 의미로 사용될 수도 있고 아닐 수도 있다. 얘가 지금 무슨 소리 하는 거지 할 수 있다.. 우선은 도메인과 엔티티는 내가 만들려는 애플리케이션의 아키텍처 설계에 따라 달라질 수 있다. 즉, 어떻게 설계했느냐에 따라 사용되는 용어의 의미가 달라질 수도 있고 같아질 수도 있다. 그래서 도메인, 엔티티 이야기를 할때는 맥락파악이 중요하다. 2가지 케이스로 나눌 .. 공감수 0 댓글수 0 2024. 3. 31.
2024년 3월 4주차 주간회고 Clean + Layered Architecture이번 2주 차 과제는 아키텍처 설계가 중점인 과제를 진행했다.평소 애플리케이션을 구성할 때 아키텍처 설계 없이 무지성으로 Layered Architecture로 설계하여 애플리케이션을 만들었었는데, 이번 과제를 진행하면서 다양한 아키텍처에 대해 배울 수 있었다. (Layered, Clean, Hexagonal, Clean + Layerd) 이제껏 무지성으로 설계해 왔던 아키텍처를 실제 애플리케이션을 만들 때, 어떻게 아키텍처를 설계할지 고민하며 "이렇게 설계했을 때의 장점이 무엇이지?", "기존에 내가 설계했던 방식은 이러한 문제점이 있었구나" 같은 생각들을 정리하고 몸으로 직접 느낄 수 있었다. 가장 크게 배운 부분은 "하위 계층의 변경은 상위 계층으.. 공감수 0 댓글수 4 2024. 3. 30.
2024년 3월 3주차 주간회고 한 주를 돌아보며 회고를 작성합니다 TDD1주차는 TDD로 point 이용 / 충전 관련 애플리케이션을 만드는 과제를 진행했다.평소 개발 방식이 기능 구현 → 테스트 작성 순이었는데, 역순으로 테스트 코드 작성을 먼저 하려니 어색하고 생각해야 할 부분이 많았다.어떤 기능을 구현해야 하는지 요구사항을 정확히 파악해야 테스트 코드를 작성할 수 있는데, 테스트 코드를 먼저 작성하면서 하나의 시나리오를 구성한다고 생각하면 편했다.예를 들어 포인트를 충전하는 기능을 구현한다면, 테스트 코드를 아래의 흐름으로 먼저 작성할 수 있다.포인트를 충전할 사용자의 정보를 준비한다.해당 정보의 사용자에 포인트를 충전하는 메서드를 호출한다.메서드의 결괏값이 내가 예상한 결괏값과 일치한지 검증한다.테스트 코드를 작성할 때, 검.. 공감수 0 댓글수 0 2024. 3. 28.
Actions Runner Controller 를 이용해 self-hosted runner로 배포하기 Actions Runner Controller 를 이용해 self-hosted runner로 배포하기 Github actions workflow를 실행시키는 환경에는 Github가 제공하는 github-hosted 환경과 자체적으로 관리하는 self-hosted 환경이 존재한다. 대부분(나 또한 그랬듯이) github-hosted 환경에서 빌드 및 배포 작업을 진행한다. 대표적으로 ubuntu-latest 환경(windows-latest, macos-latest..)이 있다. 하지만 이번에 self-hosted 환경에서 애플리케이션을 빌드 및 배포하는 작업을 진행했다. self-hosted runner를 어디에서 실행시킬지도 2가지 방법으로 나뉜다. (다른 방법이 더 존재할 수도..) EC2에서 실행 e.. 공감수 1 댓글수 0 2024. 3. 19.
AWS EKS “instances failed to join the kubernetes cluster” Error AWS EKS “instances failed to join the kubernetes cluster” Error AWS EKS Node Group을 생성 하는데, instances failed to join the kubernetes cluster 에러가 발생하는 문제가 있었다. 결론부터 나의 경우 체크해보아야 하는 부분은 크게 3가지였다. Cluster Private, Public Endpoint 확인 Cluster Worker Node의 IAM 권한 확인 Cluster가 배치된 VPC 내 Subnet 연결 설정 확인 노드 그룹 생성 시 인스턴스는 정상적으로 생성이 되었는데, 해당 인스턴스가 eks cluster에 Join이 되지 않아 cluster 생성에 실패하는 문제였는데 어떻게 해결했는지 복기해.. 공감수 0 댓글수 0 2024. 3. 12.
EKS ERROR couldn't get current server API group list: the server has asked for the client to provide credentials AWS EKS Cluster를 생성 후 node를 확인하기 위해 node를 확인하는 명령어(kubectl get nodes)를 입력했는데 아래 에러가 발생했다. 대충 에러 로그가 의미하는 바는 현재 권한이 없는 게 문제인 것 같은데, eks 사용하기 위해 별도의 IAM을 만들어 eks 관련 역할을 부여해 주었는데도 위와 같은 에러가 발생해 꽤나 삽질을 하느라 시간을 소비했다. 에러를 해결하기 위해 시도했던 과정들을 나열을 해보자. 1. 로컬의 kubectl 설정 업데이트 aws eks update-kubeconfig --region --name 위 명령어로 현재 로컬의 kubectl 설정(kubeconfig 파일)을 업데이트하여 EKS cluster에 접근이 가능하도록 했다. Updated context.. 공감수 2 댓글수 0 2024. 3. 11.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.