전체 글694 [쿠링] 헥사고날 아키텍처를 향하여 (By TDD) 이번 글을 통하여 기존의 쿠링의 계층형 아키택처를 Hexagonal Architecture로 리팩토링 해 나가려 한다. 그럼 기존에 어떠한 점이 불편했기에 이러한 선택을 하게 되었을까? 기존의 문제점부터 한번 살펴보자. 1. 기존 아키텍처의 문제점 1-1) 데이터 중심의 설계? 우선 가장 첫 문제점은 우리의 앱이 어느순간부터 데이터베이스 중심적으로 설계가 진행되고 있었다는 점이다. 사용자를 위한 애플리케이션이라면, 해당 문제를 해결할 도메인 로직이 중요한데... 정작 이점은 고려하지 못하고 구현된 아키텍처였다. 다음 글은 내가 이에 대하여 좀더 설명해 둔 글이기에, 자세한 설명은 다음 글을 읽어봐 주시길! https://blogshine.tistory.com/688 계층형 아키텍처는 왜 데이터베이스 중심.. BackEnd/쿠링 2024. 2. 2. 계층형 아키텍처는 왜 데이터베이스 중심의 설계를 유도할까? 1. 계층형 아키텍처가 어때서? 마틴 파울러의 책, PoEAA (Pattern of Enterprise Application Architecture: 엔터프라이즈 애플리케이션 아키텍처 패턴)을 보면 대표적인 3 계층을 소개하는 파트가 있다. 이름도 그 흔한, 3-tire-아키텍처, 또는 계층형 아키텍처 등 부르는 이름도 은근 다양하다. 이러한 아키텍처를 사용하던 방식을 잠시 떠올려보면... 최상단의 표현 계층이 도메인(서비스) 계층에 의존하고, 다시 도메인 계층은 영속성 계층에 의존하게 된다. 사용자 요청의 시작을 기점으로 생각해보면 이러한 흐름은 자연스럽게 데이터베이스에 의존하게 된다. 개발자가 의식하지 못한 사이에 어느덧 도메인 계층의 코드들이 영속성 계층을 기반으로 만들어지게 된다..... 이쯤 돼.. BackEnd/기타 2024. 1. 25. [쿠링] Pattern 하나로 서버 OOM발생시켜 다운시키기 (Heap Dump 보기) 1. 처음엔 문제인 줄 몰랐다...현 쿠링은 엄청 비싼 인스턴스를 사용하지는 않고 있기 때문에 인스턴스 한대당 Memory가 512MB에 불과한 서버를 사용 중이다. (대신 값싼 거 3대로 운영 중) 심지어 메인서버는 Heroku이고, 테스트서버와 모니터링 서버는 AWS에서 기동중이다.(메인 서버 이전이 쉽지가 않다...) 다행히 지금은 메인서버를 AWS로 이전했고, test서버를 Heroku로 사용중이다! 평상시에는 크게 문제처럼 느껴지지 않던 부분이 시간적 여유를 갖고 보니 조금은 어색하게 느껴진 부분이 있었다.우선 다음 모니터링 기록을 살펴보자 ▶ Heap : G1 Eden Space ▶ Heap : G1 Survivor Space G1 Eden 영역에 수시로 생성되고 있는 양이 어림잡아 170MB.. BackEnd/쿠링 2024. 1. 18. [쿠링] Spring JDBC를 사용한 Batch Insert 구현과 고민 예전부터 시간 나면 해결하고 싶었던 문제 중 하나인 Batch(Bulk) insert에 대한 구현을 하며 이번글을 남기게 되었다. 기존에 주로 사용해 왔던 JPA의 한계로 인하여 이러한 결정을 하게 되었는데, 어떤 문제점과 고민이 있었는지 이번 글을 통하여 공유해 볼까? 한다. 고민 1 : JPA가 무엇인가? 이것부터 생각해 보기 기존에 내가 사용하던 ORM 기술인 JPA는 ORM의 대표 기술이다. 그럼 ORM은 어떤 철학을 갖고 설계된 것일까? 이를 wiki에서 검색해 보았다! ORM (Object–relational mapping) Object–relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programmin.. BackEnd/쿠링 2024. 1. 14. [알고리즘] 불확실한 상황을 현명하게 사용하는 코드 이번글은 학교 알고리즘 수업 시간에 Randomized algorithm을 배우면서 느낀 점을 남기는 글입니다. 어떤 알고리즘을 설명한다기보다는, 제가 느낀 점을 남겨보는 글입니다. 1. 불확실한 상황을 이용해 볼 수 없을까? 우리가 코드를 작성할 때 모든 상황이 확실하게 결정된 상황에서만 진행하는 경우는 거의 없다, 어쩌면 이는 코드뿐만 아니라 대부분의 사람들이 하루를 살아가는 자연스러운 방법(?) 중 하나일지도 모른다. 물론 우리는 계획이라는 것을 만든다. 해당 계획을 통하여 시간이 얼마나 걸릴지 예측할 수도 있고, 얼마나 많은 리소스가 필요한지 또한 측정할 수 있다. 하지만 이는 어느 정도의 사전 정보가 있다는 가정 하에 가능할 것이며, 당장 첫 시도를 해야 하거나, 상황 자체가 너무나 불확실하다면.. Algorithm/PS 알고리즘 정리 2023. 12. 14. [계산 이론] The Halting Problem 컴퓨터를 전공 배우고 있는 사람 입장에서, Halting Problem정도는 한번 증명해 보고 정리해 두면 좋을 것 같다 생각하여 글을 남겨봅니다! 1. Halting Problem 이란? 우선 정의부터 살펴보자! There’s no algorithm that can look at a program’s source code and always correctly determine if the program will run forever or not. 사람의 언어로 조금 바꿔보면, 유한시간안에 프로그램을 실행해보지 않고 정지할지 말지를 결정하는 알고리즘은 존재하지 않는다는 의미이다! 2. Proof by contradiction 다음과 같이 "input과 output을 갖는 halt라는 프로그램(알고리즘)이.. CS/Computation Theory (2023-2) 2023. 12. 12. [계산 이론] Some languages are not Turing-recognizable 이번 증명을 통하여 Turing Machine이 recognize하지 못하는 Language가 있음을 보일 것 이다. 1. 모든 Turing Machine은 countable 하다 모든 튜링머신이 Countable함을 보이기 전에, 우선 모든 String의 집합(∑*)이 모든 alphabet ∑에 대하여 count할 수 있음을 보일것 입니다. ∑* 의 list를 길이가 0, 길이가 1, 길이가 2 ... 순으로 아래로 적어내려 갈 수 있습니다. 또한 각 lenght마다 finite한 수의 String이 있습니다. 이를 그림으로 살펴보면 다음과 같은데, 길이가 0인 String에는 입실론이, 1에는 0과 1, 등등 이 존재합니다. 모든 자연수 1, 2, 3, ... N에 대하여 mapping가능한 하나의 .. CS/Computation Theory (2023-2) 2023. 12. 12. [계산 이론] Non-Context-Free Languages 1. The Pumping Lemma for Context-Free-Languages(CFL) 우리는 보조 정리인 Pumping Lemma를 활용하여 CFL이 아님을 보일 것 이다. 만약 A가 Context-free-lenaguage라면, pumping length p가 존재하며, A의 어떤 String S라도 최소 p만큼의 길이를 갖는다. 또한 그러한 S는 5조각, 즉 S = uvxyz로 나눌 수 있으며, 다음 조건을 만족한다. 조건 2에 의하여 v 또는 y 가 동시에 empty string일수는 없다. 조건 3에 의하여 v,x,y의 길이는 최대 p이다. 2. Proof G를 CFL A의 Context-Free-Grammer(CFG)라 하자. b를 symbol의 최대 수 라고 하자. 예를 들면 다음 C.. CS/Computation Theory (2023-2) 2023. 12. 10. [알고리즘] 최소 공통 조상 LCA(Lowest Common Ancestor) 1. LCA란? LCA(Lowest Common Ancestor)는 주어진 두 노드 a와 b의 최소 공통 조상을 찾는 알고리즘입니다. 예를 들어 다음 그림과 같은 트리가 있다고 했을 때, 12번과 15번 노드의 최소 공통 조상 LCA는 5번 노드가 됩니다. 우선 두 노드의 LCA를 찾는 가장 간단한 O(N)이 걸리 방법으로 2가지 정도가 있다. 2가지에 대하여 간단하게 알아본 후, 이글의 Main 목표인 O(LogN) 안에 해결하는 알고리즘에 대하여 알아보자. 2. O(N) 알고리즘 2-1) 두 Node의 Level을 통일시키는 방식 A와 B의 깊이가 다를 경우 더 깊은 정점의 부모를 따라 하나씩 올라가면서 A와 B의 깊이를 맞춘다. 위의 결과 A와 B가 같다면 A(or B)가 최소 공통조상이다. A !.. Algorithm/PS 알고리즘 정리 2023. 12. 8. [Kafka] Kafka Connect on Docker 1. 문제의 상황 MSA 토이프로젝트를 진행하던 도중 Local에서만 사용하던 Kafka와 Kafka Connector를 Container로 만들어 사용해야 하는 일이 발생하였다. 따라서 모든 서비스에 Dockerfile을 만들어 커테이너화 시켜주었으며, 추가적으로 DB와 Kafka또한 컨테이너화 시켜야 했다. 우선 MSA 토이 프로젝트의 구조는 다음과 같다!! 간단한 쇼핑몰 서비스 이며, 오늘 글에서 다룰 부분은 Order-Service와 Kafka 부분이다. 그냥 Kafka 자체만 필요하면 제공되는 Docker 이미지 사용하면 끝이라 쉽지만, 그 외 Connector를 함께 사용하려 하니 준비해야 할 점이 추가적으로 있었다. 또한 DB에 저장하기 위해 최종적으로 JDBC 라이브러리 또한 필요하여 추가.. BackEnd/Kafka 2023. 12. 6. [알고리즘] HeapSort보다 QuickSort가 더 빠른 이유 1. 왜 HeapSort보다 QuickSort가 현실적으로 더 빠를까? HeapSort와 QuickSort는 대표적으로 O(NlogN)안에 동작하는 정렬알고리즘이다. 하지면 현실성면에서 QuickSort가 더 빠르다는것은 익히 들어 알고있을 것 이다. 왜 그런것 일까? 이에 대하여 알아보자 1-1) 알고리즘의 성능 요인 크게 정렬 알고리즘에서 성능을 미치는 원인은 크게 3가지로 볼 수 있다. 비교 및 스왑을 수행하기 위한 반복자(loop) = 반복자가 어떻게 구현되어있는가의 문제 유효 접근 시간 (지역성) 메모리 소비량 1번의 경우 대부분 시간복잡도를 측정할때 고려하는 요소라, O(NlogN)이라는 표기안에 포함되어있는 개념이다. 따라서 HeapSort와 QuickSort의 차이는 2번인 유효 접근 시간.. Algorithm/PS 알고리즘 정리 2023. 10. 13. [쿠링] 사용자 인증의 시작부터 끝까지의 여정 항상 프로젝트를 진행할 때마다 한 번씩은 고민해 왔던 문제가 있다. 바로 "인증, 인가 가 과연 해당 서비스의 핵심 비즈니스 로직인가?"에 대한 고민이다. 경험이 부족했던 시점에야 당연히 이러한 생각조차 하지 못하여 논의할 내용조차 없었다경험이 조금 있는 시점에서는 일단은 API수준에서 구현은 가능하지만 이를 어떤 방식으로 분리해야 할지 몰랐다. 이번 글에서는 이러한 나의 고민을 스스로 적어보고, 해결해나가는 과정을 기술할 것이다! (즉, 지극히 개인적인 내용.... 태클 환영) 고민 1 : Core Business란 무엇인가? 경계가 있는가?가장 우선적으로 고민했던 부분은 Core Business라는 것 이 뚜렷한 경계가 있는 것 인가였다? 이에 대한 확인을 위해 위대하신 GPT에게 질문을 던져보았다... BackEnd/쿠링 2023. 10. 7. 이전 1 2 3 4 5 ··· 58 다음
