보배로움

클린 아키텍처, 마이크로 서비스 패턴 책을 읽으면서 Command, Query Class들이 나왔는데, 무슨 차이며 어떤 역할이길래 이런 이름(Suffix)으로 네이밍했을까 궁금했다. 근데 책에서 나와있길래 짧게 적어본다. - Command (커맨드, 명령): 데이터 생성/수정/삭제(CUD) 시에 사용 - Query (쿼리, 조회): 데이터 읽기(R) 시에 사용 개발 상에서 많이 사용되던 단어다보니 의미를 생각하지 않아서 이해가 잘 안되던 것이었는데, 단어의 본래 의미와 한국어 해석을 보면 이해가 간다. 결국, 데이터를 생성/수정/삭제하는 CUD 작업과 관련이 되어있다면 Command Suffix가 붙은 네이밍을 사용하고, 데이터를 조회하는 R 작업과 관련이 되어 있다면 Query Suffix가 붙은 네..

Consistent hashing은 Hashing을 일관되게 유지하는 방법이다. 이게 뭐다 라고 설명하기 보단, 먼저 상황을 예시로 들어보자. 노드 3개에 데이터를 분산 저장하는 상황이 있다. 제일 쉬우면서 분산저장하는 법은 데이터의 특정 값(이름 등)을 이용해 Hashing 결과 값을 구하고, 해당 값의 node로 배치하는 법이 있다. 수식으로 나타낸다면 hash(data-key) % 3 으로 데이터가 저장되는 노드 번호를 구할 수 있을 것이다. 이러한 예시에서 노드의 수가 세상이 끝날 때까지 변함이 없다는게 보장된다면 문제 없이 동작할 수 있다. 하지만 역시나 그럴 확률은 적다. 주변 환경에 따라, 유저의 수가 증감함에 따라, 회사/서비스의 상황에 따라 분산저장 노드의 개수는 변할 수 있고, 그렇게 ..

2021년 마지막 날, 다른 개발자들의 회고 릴레이에 참여하여 나도 올해의 나를 다시 되돌아보고자 한다. 인생 회고는 몇 주전 정리를 했으니, 올해의 개발과 성장에 초점을 맞춰 글을 작성했다. 개발자로서의 첫 발을 내딛다 올해 1월, (돈을 받고 일하는) 개발자로서의 첫 발을 내딛었다. 11번가 이커머스 기업에서 백엔드 개발자로 취업하게 되었고, 일을 시작했다. 솔직히 말하면 최근 떠오르는 이커머스 기업들에 비해 눈에 띄지 않아 매력이 없어보일 수 있지만, 컨퍼런스의 영상들(MSA로의 전환, 스케일아웃 없이 순간 급증하는 주문 처리하기)들을 보며 ‘배울점들은 충분히 많겠다’라는 생각을 가지고 입사를 결정하게 됬다. 입사 전만 해도 나는 Node/Express 기반의 서버 개발을 하던 그리고 아키텍처, 클..

`만들면서 배우는 클린 아키텍처` 책을 보면서 헥사고날 아키텍처 구조에 대해 학습하고 있다. 기존까지는 생각하지 못했던, 또한 패키지나 구조에 대해 잘 몰라 '이렇게 하는게 맞나'하면서 고민했던 것들이 좀 풀려나가는 것 같다. 이 글에서는 학습하며 배웠던 패키지 구조와 간단 아키텍처를 백업용으로 작성하고자 한다. 패키지 구조 책에서는 adapter, application, domain을 주 패키지로 잡고, 내부적으로 port, in, out 등의 부 패키지로 구성하고 있다. com.binux.server ├── BinuxApplication.java ├── BinuxConfiguration.java ├── BinuxConfigurationProperties.java ├── account │ ├── ada..

Kubernetes를 CLI 상에서 활용하다보면 특정 리소스의 uid를 출력할 일이 생긴다. 그럴 때 마다 `kubectl edit`을 통해 uid 값을 확인하거나, `kubectl get kind/resource -o yaml`로 확인하곤 했다. 근데 이게 한 두 번이면 상관이 없는데, Operator를 개발하며 계속적으로 확인해야 했고 이 귀찮음을 이겨내고자 리눅스 커맨드라인을 사용하기로 했다. 그래서 결국 아래와 같이 하면 uid를 뽑아낼 수 있다. kubectl get pod request-pod -o yaml | grep uid | cut -d ":" -f 2 cut 대신 awk를 통해서도 뽑아낼 수 있다. kubectl get pod request-pod -o yaml | grep uid | ..

Operator에서 Controller를 만들 때, 해당 리소스의 status, spec 을 명시해주어야만 한다. spec 은 말 그대로 해당 리소스의 스펙을 의미해서 별로 헷갈리는게 없었는데, status 는 뭐지 하는 생각과 동시에 spec 도 해당 리소스의 스펙이라지만 어떻게 되는거지 라는 생각이 겹쳐져 전체가 헷갈리게 되버렸다. TL;DR spec: 원하는 상태(desired state)를 의미 status: 현재 상태(current state)를 의미 spec, status 가 다르다면, 쿠버네티스 시스템/Operator 등을 통해 status를 spec에 맞게 변경해나가게 된다. 단순히 보면 spec과 status가 같은 값을 가지고 status를 spec으로 맞춰주겠구나 할 수 있지만, 꼭 ..

Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어집니다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용됩니다 (공식문서에서도 디버깅 시에 Event를 활용하고 있습니다). Events 조회 Kubernetes Event는 어떻게 조회할 수 있을까요? 사실 Kubernetes를 다뤄보았다면 한번 쯤은 Events 리소스를 본 적이 있을겁니다. 가장 흔한 예로 이미지 Pull 실패 가 있겠네요. 잘못된 컨테이너 이미지를 입력해서 Deployment 또는 Pod를 생성해서 조회하면 아래와 같은 오류가 ..

@ApplicationScoped 어플리케이션에서 사용되는 bean instance. 주입 시점에 공유되며 기본적으로 해당 어노테이션을 사용해 bean을 생성하면 지연(lazy) 생성된다. 즉, Client proxy를 통해 메서드가 호출될 때 초기화되며 생성된다. @Singleton Client proxy가 사용되지 않는다는 점 빼고는 @ApplicationScoped 와 같다. 즉, 주입 시점에 인스턴스가 생성(eager)된다. @RequestScoped Current request(보통 Http request)와 관련이 있는 bean instance. Spring에서 사용하는 @RequestScope 와 유사하다. @Dependent pseudo-scope 을 가지는 bean instance. In..