tgyun615.info

계층형 아키텍처의 문제 계층형 아키텍처는 토대가 DB이기 때문에, DB 주도 설계를 유도함 계층형 아키텍처는 DB중심적인 아키텍처이기 때문에 비즈니스 관점에서 맞지 않음 → 도메인 로직을 먼저 만들고 제대로 이해해야하 영속성과 웹계층을 만들 수있음 계층형 아키텍처는 같은 계층에 있는 컴포넌트나 아래 계층에 접근이 가능하기 때문에 암묵적으로 용인하면 영속성 → 도메인으로 접근하는 코드가 늘어나게 됨 계층형 아키텍처는 시간이 지나면서 시스템이 비대해질수록, 계층을 건너뛰어 접근하는 경우도 생기게 되면서, 도메인 로직이 전체에 걸쳐 책임이 섞이게 됨 계층형 아키텍처의 이러한 문제의 해결방법으로는 DIP(의존성 역전법칙)으로 해결을 했었음 → 모든 계층에 DIP로 해결해서 적용하면 헥사고날 아키텍처의 형태를 띄..

동시성 문제 해결 방법 Synchronized 이용 RDB Lock 활용 Redis 활용 (Lettuce or Redisson) Synchronized 이용 Synchronized 키워드를 통하여 메소드 해당 블럭을 동기화처리를 함 Synchronized가 선언된 블럭에는 동시에 하나의 스레드만 접근이 가능하기 때문에 동시성 문제를 해결가능 하지만 Synchronzied를 통하여 해결하는 방법은 단일 인스턴스일 경우에만 가능함, 예를 들어서 데이터에 여러개의 인스턴스가 접근하는 경우에는 다수의 인스턴스가 접근이 가능하기 때문에 레이스컨디션이 발생함 (실무에서는 거의 사용되지 않는 방법) RDB Lock 활용 Lock 종류 종류 특징 Pessmistic Lock 실제로 데이터에 Lock을 걸어 정합성을 맞..

멱등성 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질 요청을 여러번 하더라도 한번 요청했을 때와 결과가 같은 성질 멱등성 예시 HTTP 메소드의 멱등성 ansible에서의 멱등성 HTTP 메소드의 멱등성 GET 요청으로 목록을 불러올 경우 행위가 여러번 수행해도, 서버의 상태가 변하지 않고 같은 결과를 기대할 수 있어서 멱등성이 성립됨 PUT 요청으로 특정 데이터를 수정한다고 하면, 데이터가 존재할 경우 수정이 되고 여러번 실행되더라도 요청한 값으로 수정된 결과 값이 같은 상태로 멱등성이 성립됨, DELETE요청도 마찬가지로 존재하든 하지 않던간에 요청을 보낸시점에서 사라지게 되어 멱등성이 성립됨 POST 요청은 데이터가 계속 추가가 되기 때문에 다른 결과가 발생하여 멱등성이 성립되지 않음 ans..

Semantic Versioning 정의 버전 관리가 제각각의 방식으로 관리가 되지 않기 위해 규칙을 정해서 관리하기 위해 Github 공동창업자인 Tom Preston-Werner가 제안한 방식 Major Version : API 변경이 있을 경우 버전업 Minor Version : 기존버전과 호환되면서 새로운 기능이 추가되는 경우 버전업 Patch Version : 기존버전과 호환되면서 버그 수정되는 경우 버전업 Semantic Versioning 규칙 버전명은 반드시 X.Y.Z 형태의 정수여야함 (ex. Major.Minor.Patch) Major버전이 올라가면 Minor와 Patch버전은 0으로 초기화되고, Minor 버전이 올라가면 Patch버전은 0으로 초기화됨 버전 1.0.0을 공개 API로..

TDD (테스트 주도 개발론) 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현 TDD 절차 RED - 실패하는 테스트 추가 GREEN - 테스트를 통과하기 위한 구현 REFACTOR - 통과한 테스트의 구현 설계를 개선, 기존 테스트가 통과 RED (테스트 실패) 하나의 요구사항을 검증하는 테스트 코드를 작성 작성된 테스트가 실패하기 위하는지 확인 GREEN (테스트 성공 / 프로덕션 개발) 테스트가 성공하도록 코드를 구현 테스트 성공은 요구사항을 만족한다는 의미 (요구사항을 만족하기 위한 최소한의 뼈대만 세우자, 살 붙이는건 중요도가 낮음) REFACTOR (리팩토링) 코드베이스 정리 구현 설계 개선 중복 코드 제거 /..

Microservices 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성 구성 : Container, Funcations, API Gateway 등 MSA 등장배경 모놀리식 아키텍처에 한계점으로 인해 등장함 모놀리식의 경우 서비스 변경이 어려움 (여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있어, 수정시 영향도가 큼) 모놀리식은 모든 구성요소가 한프로젝트에 통합되어 있는 형태라 규모가 커질 수록 작은 변경에도 높은 테스트 비용이 발생하며, 하나의 시스템을 개발하여 배포하기 때문에 배포시 비용이 큼 모놀리식 아키텍처에서 부분 서비스 장애시, 전체 서비스의 장애로 확대될 가능성이 큼 MSA 특징 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트 들로 분해하고 이들을 조합..

MSA 개념 살펴보기전에 알아두기 (알긴아는데 기록), MSA 등장전 대부분 애플리케이션은 모놀리식 아키텍처였음 모놀리식 아키텍처 개념 UI 및 비즈니스 로직, DB 액세스 로직 모두 하나의 애플리케이션 산출물로 패키징 되어 애플리케이션에 배포되는 형태 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 가질때를 뜻함 장점 모든 것이 하나로 구성되어 있기 때문에 개발, 빌드 배포, 테스트가 복잡하지 않음 하나로 구성되어 있기 때문에 Scale up하거나 Scale out하기 용이함 개발환경과 방법이 통일되어 있음 단점 규모가 커질 수록, 유지보수가 어려워지며, 애플리케이션 구동시간도 그만큼 늘어나고, 빌드 배포시간도 길어짐 작은 수정사항이 생길경우 전체 영향이 있기 때문에 불안정함 내부 요소간의 ..

많이 들어봤지만 개념을 몰라서 정리 Polling 정의 Client가 서버에 주기적으로 Request를 보내는 기법 주기적으로 Client가 처리해야할 이벤트나 받을 데이터가 있는지 체크 특징 주기적으로 요청하기 때문에 응답 간격을 일정하게 가능 요청 오는 폴링 요청이 처리 이후 다음 폴링이 이루어지기 전에는 언제오는지 몰라서 실시간 처리가 불가능 리소스 낭비가 심함 (http는 단발성 통신이라, header가 무거움, 지속적으로 요청이 오면 서버에 부하 줄 수 있음) 장점도 있지만, 문제점이 더 크기에 Long Polling이 등장함 Long Polling 정의 Client가 Request를 보내고 서버가 바로 Response를 보내지 않고, 이벤트가 발생하거나 보낼데이터가 생길 시 Response로 ..

정의 블록킹 : 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면 다른작업이 끝날때까지 기다렸다가 자신의 작업을 시작하는 것 (Thread관점에서 본다면, 요청 작업을 마칠 때까지 계속 대기) 논블록킹 : 다른 주체의 작업과 상관없이 자신의 작업을 하는 것 동기 : 두주체의 작업을 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작함을 의미 비동기 : 시작, 종료가 불일치, 끝나는 동시에 시작하지 않음을 의미 (두 주체가 서로의 시작 종료시간 관계없이 별도의 작업 수행 시작 / 종료시간을 가지고 있을 때를 의미함) 블록킹 / 논블록킹 기준 블록킹과 논블록킹은 다른 작업을 수행하는 주체를 어떻게 상대하는지에 따라 정해짐 동기 / 비동기 기준 작업을 수행하는 것이 동시에 이루어지거나 동시에 종료되거..