maeil-mail 질문 모음 (1~311)

OSIV(Open Session In View)

OSIV(open session in view) 는 영속성 컨텍스트를 뷰까지 열어둔다는 의미입니다. 영속성 컨텍스트가 살아있으면 엔티티는 영속 상태로 유지될 수 있어, 뷰에서도 지연 로딩을 사용할 수 있어요. OSIV의 핵심은 뷰에서도 지연 로딩이 가능하도록 하는 것입니다. 가장 단순한 구현은 클라이언트 요청이 들어올때 필터나 인터셉터에서 트랜잭션을 시작하는 방법인데요. 이를 트랜잭션 방식 OSIV라고 합니다. 하지만, 트랜잭션 방식 OSIV는 표현 계층에서도 엔티티를 수정할 수 있기 때문에 유지보수하기 어려운 코드를 만들 수 있습니다.

트랜잭션 방식의 OSIV의 문제는 어떻게 풀어볼 수 있을까요? 🤔

최신 방식의 OSIV는 트랜잭션 방식의 문제를 해결합니다. 스프링 OSIV는 OSIV를 사용하면서 트랜잭션은 비즈니스 계층에서만 사용해요. 표현 계층에서는 트랜잭션이 없기 때문에 수정이 불가능합니다. 하지만, 표현 계층에서 트랜잭션 없는 읽기를 이용해 지연 로딩은 가능합니다. 동작 원리는 다음과 같습니다.

1. 클라이언트의 요청이 들어오면 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다.
2. 응용 계층에서 @Transactional로 트랜잭션을 시작할 때 미리 생성한 영속성 컨텍스트를 찾아와서 트랜잭션을 시작합니다.
3. 응용 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시합니다. (영속성 컨텍스트는 종료하지 않습니다.)
4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지할 수 있습니다.
5. 필터, 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료하는데 이때 플러시는 수행하지 않습니다.

스프링 방식의 OSIV의 문제점을 한 번 생각해볼까요? 😀

• 표현 계층에서 엔티티를 수정하면 데이터베이스에 반영하지 않습니다. 하지만, 엔티티를 수정한 이후 트랜잭션을 시작하는 응용 계층을 시작한 경우 문제가 발생합니다. 응용 계층 트랜잭션이 끝나고 영속성 컨텍스트를 플러시하는 과정에서 변경 감지가 동작할 수 있습니다.
• OSIV 기능을 사용하면 상대적으로 오래 DB 커넥션을 점유하기 때문에 커넥션 고갈로 이어질 수 있습니다.

OSIV 기능을 비활성화하여 성능 최적화를 해볼 수 있어요. 🤓

OSIV 기능이 활성화되어 있는 경우에는 트랜잭션의 범위를 벗어나도 커넥션을 계속 유지해요. 만약 트래픽을 많이 받는 상황이라면, 커넥션 고갈로 이어질 수 있습니다. OSIV 기능을 비활성화하여 데이터베이스 커넥션을 효율적으로 사용할 수 있습니다.

그러면 무조건 OSIV 기능을 비활성화해야 할까요? 🤔

무조건 비활성화하기 보다는 꺼야하는 근거가 필요해요. 만약 트랜잭션 범위 밖에서 지연로딩을 반드시 수행해야하는 경우에는 비활성화하기 어려울 수도 있어요.

데이터베이스를 복제하여 사용하는 경우, 데이터소스도 분리해야하는데요. OSIV 기능으로 인해 예기치 않은 데이터베이스로 요청이 전달될 수 있어요. 그리고, 대량의 트래픽이 발생하는 경우처럼 데이터베이스 커넥션을 효율적으로 사용해야할 수도 있습니다. 위와 같은 경우에는 OSIV 비활성화를 고려해볼 수 있을 것 같아요.

결국, 요지는 상황에 적합한 경우 OSIV 기능을 비활성화하는 것이 적절하다고 생각합니다.

RAID(Reduntant Array of Independent Disks)

RAID는 수 많은 데이터들을 안전하게 저장하거나 성능을 높이기 위해 여러 하드 디스크나 SSD를 마치 하나의 장치처럼 사용하는 기술입니다.

RAID 구성 방식에 대해서 설명해주세요. 🤓

RAID-0 은 여러 보조기억장치에 데이터를 나누어 저장하는 구성 방식입니다. 데이터를 저장할 때 하드 디스크는 각 장치에 번갈아 데이터를 저장합니다. 이때 줄무늬처럼 분산되어 저장된 데이터를 스트라이프라고 하며 분산하여 저장하는 방식을 스트라이핑이라고도 합니다.

데이터를 분산하여 저장하기 때문에 저장된 데이터를 읽고 쓰는 속도가 빨라집니다. 하나의 대용량 저장 장치를 사용하면 여러 번에 걸쳐 읽고 써야하는 데이터를 동시에 읽고 쓸 수 있기 때문입니다. 가령, 4TB 저장 장치 한개 읽기 속도보다 RAID 0 구성으로된 1TB 장치 네 개 읽기 속도가 더욱 빠릅니다. 하지만, 저장된 정보가 안전하지 않다는 단점이 존재합니다.

RAID-1 은 복사본을 만드는 구성이며 미러링이라고도 부릅니다. 디스크에 문제가 발생해도 복구가 가능합니다. 하지만 하드 디스크 개수가 한정되었을 때, 사용 가능한 용량이 적어지며 RAID-0에 비해 쓰기 속도가 느립니다.

RAID-4는 복사본을 만드는 대신 오류를 검출하고 복구하기 위한 정보를 저장한 장치를 두는 구성 방식입니다. RAID-1 보다 적은 하드 디스크로도 데이터를 안전하게 보관할 수 있습니다. 다만, 새로운 데이터가 저장될 때마다 패리티 저장 디스크에도 데이터를 써야 하므로 병목 현상이 발생할 수 있다는 단점이 있습니다.

RAID-5 는 RAID-4의 병목 현상을 극복하기 위해 패리티 정보를 분산하여 저장합니다. 그리고, RAID-6 는 서로 다른 두 개의 패리티를 두는 방식입니다. RAID-6는 오류 검출 및 복구 수단이 두 개가 생기므로, RAID-4나 RAID-5 보다 안전합니다. 하지만, 패리티가 두 개이므로 쓰기 속도는 RAID-5보다 느립니다.

RAID를 직접 구성 해보신 적이 있나요? 🤔

예시입니다! 각자 경험하신 프로젝트 상황에 맞는 대답을 준비해주세요.

RAID를 직접 구성한 적은 없습니다. 하지만, 매일메일 서비스의 백엔드를 구축하면서 AWS RDS를 사용했는데요. AWS RDS는 필요한 스토리지 용량에 따라 자동으로 데이터를 여러 Amazon EBS 볼륨에 스트라이핑하여 성능을 강화하는 것으로 알고 있습니다.

참고 : Amazon RDS DB 인스턴스 스토리지 작업

@Value 어노테이션 주의점

@Value은 설정 파일에 설정한 값을 주입할 수 있는 어노테이션입니다. 첫 번째로 주의해야 할 부분은 주입 시점입니다. @Value 어노테이션은 대상 컴포넌트가 스프링 빈으로 등록되고 의존 관계를 주입할 때 동작합니다. 따라서 환경 변수를 주입받는 대상 클래스에 @Component 어노테이션을 붙여주지 않는다면 해당 클래스는 컴포넌트 스캔이 대상이 되지 않아 스프링 빈으로 등록되지 않고, @Value 어노테이션 또한 동작하지 않습니다.

또한 상황에 따라서 적절한 주입 방식을 선택해야 하는데요. 빈을 주입받을 때와 마찬가지로 @Value 어노테이션을 사용할 때도 필드 주입, 생성자 주입, setter 주입 등의 방식을 사용할 수 있습니다. 따라서 이들의 장단점을 비교하고, 상황에 따라 적절한 주입 방식을 선택해야 합니다.

마지막으로 프로퍼티 파일의 경로와 스코프를 확인해야 합니다. application.yaml 이 클래스 패스에 존재해야 하고, 프로퍼티 파일이 여러 개일 경우 우선순위를 고려해야 합니다.

@ConfigurationProperties 어노테이션과의 차이점은 무엇인가요? 🤔

스프링의 프로퍼티 파일의 값은 Environment에 등록되는데요. 두 어노테이션 모두 이 값을 불러올 수 있다는 공통점이 있습니다. 단, @Value의 경우에는 단일 값을 주입받기 위해서 사용되며, RelaxedBinding이 적용되지 않습니다. RelaxedBingding이란 프로퍼티 이름이 조금 달라도 유연하게 바인딩을 시켜주는 규칙을 의미합니다. 반면, @ConfigurationProperties 어노테이션은 프로퍼티에 있는 값을 클래스로 바인딩하기 위해 사용됩니다. 그리고, 한 번에 여러 값을 바인딩 받을 수 있으며 RelaxedBinding을 적용합니다.

@ExceptionHandler란?

@ExceptionHandler 애너테이션은 Spring MVC에서 컨트롤러(@Controller)나 전역 예외 처리를 위한 @ControllerAdvice 클래스의 메서드에서 발생하는 예외를 처리하는 데 사용되는데요. 이 애너테이션은 특정 예외를 처리하는 메서드를 지정하거나 메서드의 파라미터로 처리할 예외를 설정할 수 있습니다.

어떤 방식으로 동작하나요? 🤔

Spring MVC 애플리케이션에서 예외가 발생하면, DispatcherServlet이 적절한 HandlerExceptionResolver를 찾아 예외를 처리합니다. Spring에 기본적으로 등록된 HandlerExceptionResolver는 세 가지가 있으며, 각 리졸버는 우선순위에 따라 예외를 처리합니다. 그 중 ExceptionHandlerExceptionResolver가 가장 먼저 동작하며, 발생한 예외가 @ExceptionHandler에 등록되어 있는지 확인합니다. 만약 처리할 수 없는 예외라면 다음 리졸버로 넘어갑니다. ExceptionHandlerExceptionResolver의 특징은 예외가 WAS로 던져지지 않고 직접 처리된다는 것입니다.

이렇게 함으로써 예외가 발생했을 때 적절한 방법으로 처리되어 사용자에게 친화적인 에러 메시지를 제공하거나 로깅 등의 추가 작업을 수행할 수 있습니다.

@ResponseBody(or ResponseEntity<T>)가 있을 때와 없을 때 차이점

@ResponseBody 혹은 ResponseEntity<T> 반환을 사용한다면, 스프링은 컨트롤러에서 반환된 값을 HTTP 응답 본문에 직접 씁니다. 이때 자바 객체를 자동으로 JSON이나 XML 등의 타입으로 직렬화합니다. 만약, 없는 경우에는 스프링은 반환값을 뷰 이름으로 해석합니다. 뷰 이름으로 해석한 이후에, 뷰 리졸버를 사용해 뷰를 찾고 응답합니다.(뷰에 전달할 모델이 있다면, 이를 뷰에 전달하고 응답합니다.)

@ResponseBody와 ResponseEntity<T> 반환 중 어떤 방식이 더욱 좋나요? 😀

@ResponseBody를 사용하는 경우, 코드를 간결하게 유지할 수 있습니다. 하지만, 상태코드와 헤더를 유연하게 변경하기는 어렵습니다. 반면, ResponseEntity<T> 반환의 경우 상태코드와 헤더를 유연하게 변경할 수 있으나 작성할 코드량이 증가한다는 단점이 있습니다. 팀 상황에 맞게 적절한 방법을 사용하는 것이 중요하다고 생각합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 제제의 ResponseBody vs ResponseEntity

Filter

Filter는 요청 및 응답의 전처리와 후처리를 수행하고 서블릿 컨테이너에 의해 실행되는 Java 클래스입니다. 주로 요청 로깅, 인증, 인코딩 설정, CORS 처리, 캐싱, 압축 등의 공통 기능을 구현하는 데 사용됩니다.

특징

1. Filter는 서블릿 컨테이너(예: Tomcat) 수준에서 동작합니다. 모든 요청이 서블릿으로 전달되기 전에 Filter를 거칩니다.
2. 생명 주기: Filter는 doFilter 메서드를 통해 요청 및 응답을 처리합니다. FilterChain을 통해 다음 필터 또는 최종 서블릿으로 요청을 전달합니다.
3. 순서: web.xml이나 @WebFilter 애노테이션을 통해 설정할 수 있으며, 필터의 순서는 설정 파일에서 정의합니다.

Interceptor

Interceptor는 특정 핸들러 메서드 실행 전후에 공통 기능을 구현합니다. 주로 요청 로깅, 인증, 권한 검사, 세션 검사, 성능 모니터링 등을 수행하는 데 사용됩니다.

특징

1. Interceptor는 Spring MVC의 핸들러 수준에서 동작합니다. Dispatcher Servlet이 컨트롤러를 호출하기 전에 Interceptor를 거칩니다.
2. 생명 주기
   • preHandle 메서드: 컨트롤러의 메서드가 호출되기 전에 실행됩니다.
   • postHandle 메서드: 컨트롤러의 메서드가 실행된 후, 뷰가 렌더링되기 전에 실행됩니다.
   • afterCompletion 메서드: 뷰가 렌더링된 후 실행됩니다.
3. 순서: WebMvcConfigurer를 구현한 클래스에서 addInterceptors 메서드를 사용하여 설정합니다. 인터셉터의 순서는 등록 순서에 따릅니다.

(Servlet) Filter vs (Handler) Interceptor

[View를 응답하는 경우]

이미지 출처 : www.egovframe.go.kr

1. 클라이언트로부터 HTTP 요청이 들어옵니다. 이때 DispatcherServlet이 프론트 컨트롤러의 역할을 수행합니다.
2. HandlerMapping을 통해 URL에 매핑된 핸들러를 조회합니다.
3. DispatcherServlet은 찾은 핸들러를 실행하기 위해 HandlerAdapter를 사용합니다.
4. HandlerAdapter가 실제로 요청을 처리하는 메서드를 호출합니다.
5. 컨트롤러는 결과 데이터를 Model 객체에 담고, View 이름을 반환합니다.
6. ViewResolver는 View 이름을 기반으로 적절한 뷰를 찾습니다.
7. ViewResolver가 찾은 뷰를 사용해 최종적으로 HTML과 같은 응답을 생성합니다.

[Message Converter의 동작]

JSON과 문자열 등을 응답하는 경우는 View를 응답하는 경우와 유사한 흐름으로 동작합니다. 단, ViewResolver 대신 HttpMessageConverter 가 동작합니다. MessageConverter는 HTTP 요청과 응답 두 경우 모두 사용될 수 있습니다. 이때 클라이언트의 HTTP Accept 헤더와 반환 타입 정보, Content-Type 등을 조합하여 타입에 맞는 HttpMessageConverter가 선택됩니다.

1. 클라이언트로부터 HTTP 요청이 들어옵니다. 이때 DispatcherServlet이 Front Controller의 역할을 수행합니다.
2. HandlerMapping을 통해 URL에 매핑된 핸들러(컨트롤러)를 조회합니다.
3. @RequestMapping 을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter가 ArgumentResolver를 호출해 핸들러가 필요로 하는 파라미터의 값을 생성하고, 컨트롤러 메서드를 호출하면서 값을 넘겨줍니다. 이때 ArgumentResolver가 HttpMessageConverter를 사용해 필요한 객체를 생성합니다.
4. 컨트롤러는 전달받은 파라미터를 사용하여 서비스 계층과 데이터 접근 계층을 호출해 비즈니스 로직을 수행합니다.
5. @ResponseBody 와 HttpEntity 를 처리하는 ReturnValueHandler가 HTTPMessageConverter를 호출해 응답 결과를 만들어냅니다.

이 두 어노테이션의 주요 차이점은 HTTP 응답의 처리 방식에 있습니다.

@Controller

주로 뷰(View)를 반환하는 컨트롤러를 정의할 때 사용됩니다. 메서드가 반환하는 값은 뷰 리졸버(View Resolver)에 의해 해석되어 JSP, Thymeleaf 등과 같은 템플릿 엔진을 통해 HTML을 생성합니다.

@RestController

주로 RESTful 웹 서비스 API를 정의할 때 사용됩니다. 메서드가 반환하는 값은 자동으로 JSON 또는 XML 형식으로 변환되어 HTTP 응답 본문에 포함됩니다. 이는 @Controller와 @ResponseBody의 결합된 형태입니다.

@ControllerAdvice는 모든 컨트롤러에 대해 전역 기능을 제공하는 애너테이션입니다. @ControllerAdvice가 선언된 클래스에 @ExceptionHandler, @InitBinder, @ModelAttribute를 등록하면 예외 처리, 바인딩 등을 한 곳에서 처리할 수 있어, 코드의 중복을 줄이고 유지보수성을 높일 수 있습니다. @ControllerAdvice는 내부에 @Component가 포함되어 있어 컴포넌트 스캔 과정에서 빈으로 등록됩니다. @RestControllerAdvice는 내부에 @ResponseBody를 포함하여 @ExceptionHandler와 함께 사용될 때 예외 응답을 Json 형태로 내려준다는 특징이 있습니다.

이들은 클라이언트 측에서 보낸 데이터를 Java 객체로 만들어주는데 RequestBody 는 요청의 본문(Body)에 있는 값을 바인딩할 때 사용하고, ModelAttribute 는 요청 파라미터나 multipart/form-data 형식을 바인딩할 때 사용합니다.

RequestBody

• 클라이언트가 보내는 요청의 본문을 자바 객체로 변환합니다.
• 내부적으로 HttpMessageConverter를 거치는데, 이때 ObjectMapper를 통해 JSON 값을 java 객체로 역직렬화합니다.
• 따라서 변환될 java 객체에 기본 생성자를 정의해야 하고, getter나 setter를 선언해야 합니다. 참고
• cf. record에 기본 생성자를 따로 정의하지 않았는데 역직렬화가 되는 이유
  • record 는 기본생성자를 자동으로 제공하지 않는 대신, ’모든 필드를 초기화하는 생성자’를 제공합니다.
  • jackson 은 일반 객체와 달리, record를 역직렬화할 때는 ’모든 필드를 초기화하는 생성자’를 사용해 역직렬화하기 때문입니다.

ModelAttribute

• 두가지 사용법이 있습니다.
• 첫번째 사용법인 메서드 단에서의 사용법은 jsp의 Model에 하나 이상의 속성을 추가하고 싶을 때 사용합니다.
  • e.g. model.addAttribute(“속성 이름”, “속성 값”)
• 두번째 사용법인 인자 단에서의 사용으로 클라이언트가 보내는 요청의 파라미터나 multipart/form-data 형식의 데이터를 자바 객체로 변환합니다.
• 내부적으로 ModelAttributeMethodProcessor를 거치는데, 이때 지정된 클래스의 생성자를 찾아 객체로 변환합니다.

출처: https://tecoble.techcourse.co.kr/post/2021-05-11-requestbody-modelattribute/

출처: https://blog.karsei.pe.kr/59

Tomcat

웹 서버와 웹 컨테이너의 결합한 형태입니다. 현재 가장 일반적이고 많이 사용되는 WAS입니다. 컨테이너, 웹 컨테이너, 서블릿 컨테이너라고도 부릅니다. JSP와 서블릿 처리, 서블릿의 수명 주기 관리, 요청 URL을 서블릿 코드로 매핑, HTTP 요청 수신 및 응답, 필터 체인 관리 등을 처리해줍니다.

서블릿이 무엇인가요? 🤔

서블릿은 자바를 이용해 웹 서비스를 만들기 위한 스펙입니다. 클라이언트가 프로그램으로 요청을 보내면 그 요청에 대한 결과를 응답해주기 위해서 사용됩니다. 서블릿은 다음과 같이 동작합니다.

1. 사용자가 URL을 입력하면 사용자의 요청이 서블릿 컨테이너로 전송됩니다.
2. 요청을 받은 컨테이너는 HttpServletRequest, HttpServletResponse를 생성합니다.
3. 서블릿 매핑 정보를 이용해 사용자가 요청한 경로를 처리할 수 있는 서블릿을 찾습니다.
4. 서블릿의 service 메서드를 호출하고 HTTP 메서드 여부에 따라서 doGet(), doPost()를 호출합니다.
5. 각 메서드는 요청을 처리하고 HttpServletResponse 객체를 이용해 응답을 처리합니다.

서블릿의 생명주기는 어떻게 되나요? 🤓

사용자의 요청이 들어오면 서블릿 컨테이너가 서블릿이 존재하는지 확인하고 없는 경우 init() 메서드를 호출하여 생성합니다. 이후 요청은 service() 메서드를 실행합니다. 만약 서블릿에 종료 요청이 들어오는 경우에는 destroy() 메서드를 호출합니다.

AutoConfiguration의 시작은 @SpringBootApplication 어노테이션 안에 있는@EnableAutoConfiguration 이라는 애노테이션입니다.

@EnableAutoConfiguration은 @Import(AutoConfigurationImportSelector.class)를 통해 자동 구성 클래스를 가져옵니다.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

    Class<?>[] exclude() default {};

    String[] excludeName() default {};
}

자동 구성 클래스를 가져올 때는 AutoConfigurationImportSelector 클래스의 selectImports(AnnotationMetadata annotationMetadata) 라는 메서드를 이용하고, getAutoConfigurationEntry(AnnotationMetadata annotationMetadata); 메서드를 통해 Import할 클래스가 무엇인지 알 수 있게 됩니다.

• 간단한 메서드 동작 과정 설명

1. getCandidateConfigurations(annotationMetadata, attributes); - AutoConfiguration의 후보들을 가져온다.
2. removeDuplicates(configurations); - 중복을 제거한다.
3. getExclusions(annotationMetadata, attributes); - 자동 설정에서 제외되는 설정에 대한 정보를 가져온다.
4. configurations.removeAll(exclusions); - 제외되는 설정을 제거한다.
5. getConfigurationClassFilter().filter(configurations); - 필터를 적용한다.

출처 : https://velog.io/@realsy/Spring-Boot-AutoConfiguration-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC

Spring은 Spring Framework의 핵심 모듈들을 기반으로 한 프레임워크로 엔터프라이즈 애플리케이션 개발을 지원하기 위한 대규모 오픈 소스 프로젝트입니다. Spring Framework를 사용하기 위해서는 설정 파일 작성을 통한 스프링 컨테이너 구성, 필요한 빈 객체 등록 및 의존성 설정, 데이터베이스 연결, 트랜잭션 관리 등 다양한 설정을 개발자가 직접 수동으로 구성해야 했습니다. 따라서 프로젝트 초기화 과정에서 많은 설정과 의존성을 추가하게 되며 프로젝트는 시작하는데 시간이 많이 걸렸습니다. 또한 스프링을 통해 웹 애플리케이션을 구축하기 위해서는 별도의 WAS를 설치하고 설정해야 했습니다.

Spring Boot는 Spring의 문제점을 해결해주고, 더 쉽고 빠르게 스프링 애플리케이션을 개발할 수 있도록 해주는 도구입니다. Spring Boot를 사용하면 Spring에서 제공하는 여러 기능들을 자동으로 설정하여 개발자가 보다 쉽게 사용할 수 있도록 해줍니다.

Spring Boot의 주요 특징

1. 자동 설정(Auto Configuration)

   • Spring Boot는 애플리케이션의 설정을 자동으로 구성합니다.
   • @EnableAutoConfiguration, @SpringBootApplication 어노테이션을 통해 자동 설정을 활성화합니다.

2. 의존성 관리 간소화

   • 특정 기능을 쉽게 추가할 수 있도록 여러 개의 라이브러리와 의존성을 하나의 패키지로 묶어 제공하는 starter 의존성 통합 모듈을 제공합니다.
   • 예: spring-boot-starter-web, spring-boot-starter-data-jpa, spring-boot-starter-security

3. 내장 서버

   • Tomcat, Jetty, Undertow와 같은 내장 웹 서버를 제공하여, 애플리케이션을 독립 실행형 JAR 파일로 배포하고, 바로 실행할 수 있게 합니다.
   • 배포를 위해 War 파일을 생성해서 Tomcat에 배포할 필요 없으며, JAR 파일에는 모든 의존성 라이브러리가 포함되어 있어 외부 서버 없이도 애플리케이션을 실행할 수 있습니다.

데이터 액세스 기술을 사용하는 Spring 기반 애플리케이션을 더 쉽게 구축할 수 있습니다.

애플리케이션에 대한 데이터 액세스 계층을 구현하는 것은 상당히 번거로울 수 있습니다. 가장 간단한 쿼리를 실행하려면 너무 많은 상용구 코드를 작성해야 합니다. 페이지 매김, Auditing, 기타 자주 필요한 옵션을 추가하면 결국 길을 잃게 됩니다.

Spring Data JPA는 실제로 필요한 만큼의 노력으로 데이터 액세스 계층의 구현을 크게 개선하는 것을 목표로 합니다. 개발자는 다양한 기술을 사용하여 리포지토리 인터페이스를 작성하면 Spring이 자동으로 이를 연결해 줍니다. 심지어 사용자 정의 파인더를 사용하거나 예제를 통해 쿼리를 작성하면 Spring이 쿼리를 작성해줍니다.

1. 더 이상 DAO 구현이 필요하지 않습니다. 인터페이스를 확장함으로써 표준 DAO에서 사용할 수 있는 표준 데이터 액세스에 가장 적합한 CRUD 방법을 얻을 수 있습니다.
2. 사용자 정의 액세스 메서드 및 쿼리
   • 인터페이스에서 새로운 메소드를 정의하기만 하면 됩니다.
   • @Query 주석을 사용하여 JPQL 쿼리 제공
   • Spring Data의 고급 사양 및 Querydsl 지원을 사용
   • JPA Named 쿼리를 통해 사용자 정의 쿼리 사용
3. Automatic 사용자 정의 쿼리: 정의된 모든 메서드를 분석하고 메서드 이름에서 쿼리를 자동으로 생성 하려고 시도합니다
4. Transaction Configuration: 클래스 수준에서 읽기 전용 @Transactional 주석을 사용하고, 읽기 전용이 아닌 메서드에 대해 재정의됩니다.

• JPA는 기술 명세입니다. 자바 애플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스입니다. JPA는 단순한 명세이기 때문에 인터페이스와 규약만 정의하며, 실제 구현체는 제공하지 않습니다.

• Hibernate는 JPA의 구현체 중 하나입니다. JPA가 정의한 javax.persistence.EntityManager와 같은 인터페이스를 직접 구현한 라이브러리입니다. JPA의 구현체 중 하나일 뿐이므로, DataNucleus, EclipseLink 등 다양한 JPA 구현체로 대체할 수 있습니다.

• Spring Data JPA는 JPA를 쉽게 사용할 수 있도록 지원하는 모듈입니다. JPA를 한 단계 추상화시킨 Respository 라는 인터페이스를 제공합니다. 개발자가 Respository 인터페이스에 정해진 규칙대로 메서드를 만들어주기만 하면, 해당 메서드 이름에 적합한 쿼리를 날리는 구현체를 만들어 자동으로 Bean으로 등록해줍니다.

  Spring Data JPA는 JPA를 기반으로 하며, 반복적인 코드 작성을 줄이고 데이터 접근 계층을 단순화 합니다. 이 때 JPA를 추상화 했다는 의미는, Spring Data JPA의 Repository 의 구현에서 JPA를 사용하고 있다는 것입니다. 예를 들어 Respository 인터페이스의 기본 구현체인 SimpleJpaResporitory 는 내부적으로 EntityManager 를 사용합니다.

@Override
public boolean isNew(T entity) {

    if(versionAttribute.isEmpty()
          || versionAttribute.map(Attribute::getJavaType).map(Class::isPrimitive).orElse(false)) {
        return super.isNew(entity);
    }

    BeanWrapper wrapper = new DirectFieldAccessFallbackBeanWrapper(entity);

    return versionAttribute.map(it -> wrapper.getPropertyValue(it.getName()) == null).orElse(true);
}

새로운 Entity인지 여부는 JpaEntityInformation의 isNew(T entity)에 의해 판단됩니다. 다른 설정이 없으면 JpaEntityInformation의 구현체 중 JpaMetamodelEntityInformation 클래스가 동작합니다. @Version이 사용된 필드가 없거나 @Version이 사용된 필드가 primitive 타입이면 AbstractEntityInformation의 isNew()를 호출합니다. @Version이 사용된 필드가 wrapper class이면 null여부를 확인합니다.

public boolean isNew(T entity) {

    Id id = getId(entity);
    Class<ID> idType = getIdType();

    if (!idType.isPrimitive()) {
        return id == null;
    }

    if (id instanceof Number) {
        return ((Number) id).longValue() == 0L;
    }

    throw new IllegalArgumentException(String.format("Unsupported primitive id type %s", idType));
}

@Version이 사용된 필드가 없어서 AbstractEntityInformation 클래스가 동작하면 @Id 어노테이션을 사용한 필드를 확인해서 primitive 타입이 아니라면 null 여부, Number의 하위 타입이면 0인지 여부를 확인합니다.@GeneratedValue 어노테이션으로 키 생성 전략을 사용하면 데이터베이스에 저장될 때 id가 할당됩니다. 따라서 데이터베이스에 저장되기 전에 메모리에서 생성된 객체는 id가 비어있기 때문에 isNew()는 true가 되어 새로운 entity로 판단합니다.

직접 ID를 할당하는 경우에는 어떻게 동작하나요? 🤔

키 생성 전략을 사용하지 않고 직접 ID를 할당하는 경우 새로운 entity로 간주되지 않습니다. 이 때는 엔티티에서 Persistable<T> 인터페이스를 구현해서 JpaMetamodelEntityInformation 클래스가 아닌 JpaPersistableEntityInformation의 isNew()가 동작하도록 해야 합니다.

public class JpaPersistableEntityInformation<T extends Persistable<ID, ID> 
        extends JpaMetamodelEntityInformation<T, ID> {

    public JpaPersistableEntityInformation(Class<T> domainClass, Metamodel metamodel, 
            PersistenceUnitUtil persistenceUnitUtil) {
        super(domainClass, metamodel, persistenceUnitUtil);
    }

    @Override
    public boolean isNew(T entity) {
        return entity.isNew();
    }

    @Nullable
    @Override
    public ID getId(T entity) {
        return entity.getId();
    }
}

새로운 Entity인지 판단하는게 왜 중요할까요? 🤓

@Override
@Transactional
public <S extends T> S save(S entity) {

    Assert.notNull(entity, "Entity must not be null");

	if (entityInformation.isNew(entity)) {
		entityManager.persist(entity);
		return entity;
	} else {
		return entityManager.merge(entity);
	}
}

SimpleJpaRepository의 save() 메서드에서 isNew()를 사용하여 persist를 수행할지 merge를 수행할지 결정합니다. 만약 ID를 직접 지정해주는 경우에는 신규 entity라고 판단하지 않기 때문에 merge를 수행합니다. 이때 해당 entity는 신규임에도 불구하고 DB를 조회하기 때문에 비효율적입니다. 따라서, 새로운 entity인지 판단하는 것은 중요한 부분입니다.

추가 학습 자료를 공유합니다.

• save()시 식별자가 존재하는 경우 어떻게 동작할까?
• Persistable - 새로운 엔티티 판별 여부 설정
• save메서드로 살펴보는 persist와 merge 개념

ddl-auto 옵션은 스프링 부트 애플리케이션에서 Hibernate와 같은 JPA 구현체를 사용할 때 데이터베이스 스키마 관리를 제어하는 설정입니다. 이 옵션은 application.properties 또는 application.yml 파일에서 설정할 수 있으며, 다양한 값에 따라 데이터베이스 스키마에 대해 다른 동작을 수행합니다. ddl-auto 옵션에는 none, validate, update, create, create-drop 등이 존재합니다.

각 옵션에 대한 설명을 해주시겠어요? 🤔

none으로 설정하면 데이터베이스 스키마와 관련된 어떠한 작업도 수행하지 않습니다. 데이터베이스 스키마를 수동으로 관리하고 싶을 때 유용하며, 프로덕션 환경에서 주로 사용됩니다.

validate는 애플리케이션이 시작될 때, 엔티티 매핑이 데이터베이스 스키마와 일치하는지 검증하며 스키마 변경은 따로 수행하지 않습니다. 프로덕션 환경에서 엔티티와 데이터베이스 스키마가 일치하는지 확인하고 싶을 때 사용합니다.

update는 엔티티 매핑과 데이터베이스 스키마를 비교하여 필요한 경우 스키마를 업데이트합니다. 기존 데이터는 유지되지만, 새로운 엔티티나 변경된 엔티티 필드는 스키마에 반영됩니다. 해당 옵션은 엔티티에 변경이 발생할 때 자동으로 스키마를 업데이트하고 싶을 때 유용합니다. 프로덕션 환경에서는 예기치 않은 스키마 변경을 방지하기 위해 주의가 필요합니다.

create는 애플리케이션이 시작될 때 기존 스키마를 삭제하고 새로 생성합니다. 데이터가 모두 삭제되며 엔티티 매핑을 기반으로 새로운 스키마가 생성됩니다. 개발 초기에 빈 데이터베이스 스키마를 반복적으로 생성해야 할 때 유용합니다. 기존 데이터가 모두 삭제되므로 프로덕션 환경에서는 사용하지 않습니다.

create-drop은 create와 유사하지만, 애플리케이션이 종료될 때 스키마를 삭제한다는 점이 다릅니다. 해당 옵션은 테스트 환경에서 일시적인 데이터베이스 스키마가 필요한 경우 유용하며, 매 테스트 실행 시마다 깨끗한 데이터베이스 상태를 유지하고자 할 때 사용됩니다. 프로덕션 환경에서는 사용하지 않습니다.

프로덕션 환경에서 스키마 변경은 어떻게 해야하나요? 🤓

스키마 변경이 필요할 때는 적절한 데이터베이스 마이그레이션 도구(Flyway, Liquibase 등)를 사용하여 제어된 방식으로 스키마를 관리하거나, 사용자가 없는 새벽에 스키마 변경 작업을 수동으로 진행하는 것이 더욱 안전할 수 있습니다.

엔티티 매니저에 대해 알기 위해선 영속성 컨텍스트에 대해 알아야 합니다. 영속성 컨텍스트는 엔티티를 영구 저장하는 환경으로 1차 캐싱, 쓰기 지연, 변경 감지를 통해 영속 로직을 효율적으로 할 수 있게 해줍니다. 이러한 효율적인 영속 로직 수행을 위해서 엔티티는 영속성 컨텍스트에 관리되어야 합니다. 이런 작업을 도와주는 것이 바로 엔티티 매니저입니다. 엔티티 매니저는 엔티티의 상태를 변경하고, 영속성 컨텍스트와 상호작용함으로써 영속 로직을 수행하는 역할을 가지고 있습니다.

조금 더 구체적으로 엔티티 매니저의 역할을 설명해 주실 수 있을까요? 🤔

엔티티는 영속성 컨텍스트와 관련하여 4가지 상태(비영속, 영속, 준영속, 삭제)를 가질 수 있는데요. 엔티티 매니저는 persist, merge, remove, close 메서드를 이용하여 엔티티의 상태를 변경할 수 있습니다. 또한, 엔티티 매니저는 영속성 컨텍스트의 1차 캐시로부터 엔티티를 조회할 수 있으며, 쓰기 지연 저장소에 있는 쿼리들을 flush하여 DB와 동기화시킬 수 있습니다. 또한 JPQL이나 Native Query를 이용해 직접 DB로부터 데이터를 불러올 수도 있습니다.

엔티티의 각 상태에 대해서 설명해주세요. 😀

Member member = new Member("산초");

비영속 상태는 엔티티 객체가 새로 생성되었지만, 아직 영속성 컨텍스트와 연관되지 않은 상태입니다. 이 상태에서는 데이터베이스와 전혀 관련이 없으며, 엔티티 객체는 메모리 상에만 존재합니다.

em.persist(member);
em.merge(detagedMember);
em.find(Member.class, 1L);

영속 상태는 엔티티 객체가 영속성 컨텍스트에 관리되고 있는 상태입니다. 이 상태에서는 엔티티의 변경 사항이 자동으로 데이터베이스에 반영됩니다.

em.detach(member);
em.clear();
em.close();

준영속 상태는 엔티티 객체가 한 번 영속성 컨텍스트에 의해 관리되었지만, 현재는 영속성 컨텍스트와 분리된 상태입니다. 이 상태에서는 엔티티 객체의 변경 사항이 더 이상 데이터베이스에 반영되지 않습니다. 영속성 컨텍스트 종료, 트랜잭션 종료 등으로도 준영속 상태로 전환됩니다.

em.remove(member);

삭제 상태는 엔티티 객체가 영속성 컨텍스트에서 제거된 상태입니다. 이 상태에서는 엔티티 객체가 데이터베이스에서 삭제됩니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 산초의 영속성 컨텍스트와 EntityManager
• [10분 테코톡] 잉, 페퍼의Spring Data JPA 삽질일지

JPA N + 1 문제는 연관 관계가 설정된 엔티티를 조회할 경우에, 조회된 데이터 개수(N)만큼 연관관계의 조회 쿼리가 추가로 발생하는 현상입니다. 예를 들어, 블로그 게시글과 댓글이 있는 경우, 게시글을 조회한 후 각 게시글마다 댓글을 조회하기 위한 추가 쿼리가 발생할 수 있습니다. 이를 N + 1 문제라고 합니다.

findAll 메서드의 글로벌 패치 전략 별 N + 1 문제 상황에 대해서 설명해주세요. 🤓

spring data jpa에서 제공하는 repository의 findAll 메서드입니다!

글로벌 패치 전략을 즉시로딩으로 설정하고 findAll()을 실행하면 N + 1 문제가 발생합니다. 이는 findAll()은 select u from User u라는 JPQL 구문을 생성해서 실행하기 때문입니다. JPQL은 글로벌 패치 전략을 고려하지 않고 쿼리를 실행합니다. 모든 User를 조회하는 쿼리 실행 후, 즉시로딩 설정을 보고 연관관계에 있는 모든 엔티티를 조회하는 쿼리를 실행합니다.

글로벌 패치 전략을 지연 로딩으로 설정하고 findAll()을 실행하면 N + 1 문제가 발생하지 않습니다. 이는 연관관계에 있는 엔티티를 실제 객체 대신에 프록시 객체로 생성하여 주입하기 때문입니다. 하지만 프록시 객체를 사용할 경우에 실제 데이터가 필요하여 조회하는 쿼리가 발생하고 N + 1 문제가 발생할 수 있습니다.

N + 1 문제는 어떻게 해결할 수 있을까요? 🤔

N + 1 문제를 해결하기 위해서는 fetch join, @EntityGraph를 사용해 볼 수 있습니다. fetch join은 연관 관계에 있는 엔티티를 한번에 즉시 로딩하는 구문입니다. @EntityGraph도 비슷한 효과를 만들어내며, 쿼리 메서드에 해당 어노테이션을 추가해 사용할 수 있습니다.

select distinct u
from User u
left join fetch u.posts

@EntityGraph(attributePaths = {"posts"}, type = EntityGraphType.FETCH)
List<User> findAll();

추가 학습 자료를 공유합니다.

• JPA 모든 N+1 발생 케이스과 해결책
• JPA Pagination, 그리고 N + 1 문제

Checked Exception은 컴파일 시점에 확인되며, 반드시 처리해야 하는 예외입니다. 자바에서는 IOException, SQLException 등이 이에 속합니다. Checked Exception을 유발하는 메서드를 호출하는 경우, 메서드 시그니처에 throws를 사용하여 호출자에게 예외를 위임하거나 메서드 내에서 try-catch를 사용하여 해당 예외를 반드시 처리해야합니다.

Unchecked Exception은 런타임 시점에 발생하는 예외로, 컴파일러가 처리 여부를 강제하지 않습니다. 자바에서는 RuntimeException을 상속한 예외들이 해당됩니다. 일반적으로 프로그래머의 실수나 코드 오류로 인해 발생합니다.

각각 언제 사용해야 할까요? 🤔

정답이 없는 영역이라고 생각해요. 자신의 주관을 만들면서 학습해봐도 좋을 것 같아요!

Checked Exception은 외부 환경과의 상호작용에서 발생할 가능성이 높은 예외에 적합합니다. 예를 들어, 파일 입출력, 네트워크 통신 등에서 발생할 수 있는 예외는 Checked Exception으로 처리하는 것이 좋습니다. 이러한 예외는 예측 가능하며, 호출하는 쪽에서 적절히 처리할 수 있는 여지가 있습니다.

Uncheked Exception은 코드 오류, 논리적 결함 등 프로그래머의 실수로 인해 발생할 수 있는 예외에 적합합니다. 예를 들어, null 참조 또는 잘못된 인덱스 접근 등은 호출자가 미리 예측하거나 처리할 수 없기 때문에 Unchecked Exception으로 두는 것이 좋습니다.

Error와 Exception의 차이는 무엇인가요? 🤓

Error는 주로 JVM에서 발생하는 심각한 문제로, OutOfMemoryError, StackOverflowError 등 시스템 레벨에서 발생하는 오류입니다. 이는 일반적으로 프로그램에서 처리하지 않으며, 회복이 어려운 오류에 속하며, 애플리케이션 코드에서 복구할 수 없는 심각한 문제를 나타냅니다.

반면, Exception은 프로그램 실행 중 발생할 수 있는 오류 상황을 나타냅니다. 대부분의 경우 회복 가능성이 있으며, 프로그램 내에서 예외 처리를 통해 오류 상황을 제어할 수 있습니다. Exception은 다시 Checked Exception과 Unchecked Exception으로 나눌 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 케로의 예외처리
• 기억보단 기록을 - 좋은 예외(Exception) 처리
• custom exception을 언제 써야 할까?

일급 컬렉션(First-Class Collection)은 하나의 컬렉션을 감싸는 클래스를 만들고, 해당 클래스에서 컬렉션과 관련된 비즈니스 로직을 관리하는 패턴을 말합니다. 아래 코드 중에서 Order의 List 자료구조를 감싼 Orders가 일급 컬렉션의 예시입니다.

// 일급 컬렉션
public class Orders {

    private final List<Order> orders;

    public Orders(List<Order> orders) {
        validate(orders); // 검증 수행
        ...
    }

    public void add(Order order) {
        if (order == null) {
            throw new IllegalArgumentException("Order cannot be null");
        }
        orders.add(order);
    }

    public List<Order> getAll() {
        return Collections.unmodifiableList(orders);
    }

    public double getTotalAmount() {
        return orders.stream()
                     .mapToDouble(Order::getAmount)
                     .sum();
    }
}

public class OrderService {
  
    private final Orders orders = new Orders();

    public void addOrder(Order order) {
        orders.add(order);
    }

    public Orders getOrders() {
        return orders;
    }

    // 추가 비즈니스 로직...
}

일급 컬렉션을 사용해야하는 이유는 무엇인가요? 😀

일급 컬렉션 클래스에 로직을 포함하거나 비즈니스에 특화된 명확한 이름을 부여할 수 있습니다. 또한, 불필요한 컬렉션 API를 외부로 노출하지 않도록 할 수 있으며, 컬렉션을 변경할 수 없도록 만든다면 예기치 않은 변경으로부터 데이터를 보호할 수 있습니다.

추가 학습 자료를 공유합니다.

• 기억보단 기록을 - 일급 컬렉션의 소개와 써야할 이유
• 이유와 솔루션으로 정리하는 객체지향 생활체조 원칙

인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조로 백과사전의 색인과 같습니다. 저장되는 컬럼의 값을 사용하여 항상 정렬된 상태를 유지하는 것이 특징입니다. 이러한 특징으로 인해 인덱스는 INSERT, UPDATE, DELETE의 성능이 희생된다는 것이 단점입니다.

인덱스는 어떤 자료 구조로 이루어져있나요? 🤔

MySQL InnoDB를 기준으로 설명드리자면, B+Tree와 같은 변형 B-Tree 자료구조를 이용해서 인덱스를 구현합니다. 기본 토대는 B-Tree 인덱스이기 때문에 이를 기준으로 설명합니다. B-Tree 인덱스는 컬럼의 값을 변형하지 않고 인덱스 구조체 내에서 항상 정렬된 상태로 유지합니다.

B-Tree(Balanced-Tree)에서는 크게 3가지 노드가 존재합니다. 최상위에 하나의 루트 노드가 존재하며, 가장 하위 노드인 리프 노드가 존재합니다. 이 두 노드의 중간에 존재하는 브랜치 노드가 존재합니다. 최하위 노드인 리프 노드에는 실제 데이터 레코드를 찾아가기 위한 주소값을 가지고 있습니다.

InnoDB 스토리지 엔진에서는 세컨더리 인덱스(프라이머리 인덱스를 제외한 모든 인덱스)의 리프 노드에는 레코드의 PK가 저장됩니다. 따라서 세컨더리 인덱스 검색에서는 레코드를 읽기 위해 PK를 가지고 있는 B-Tree를 다시 한번 검색해야합니다.

MySQL 스캔 방식은 어떤 게 있나요? 😀

MySQL에는 크게 인덱스 레인지 스캔, 인덱스 풀 스캔, 루스 인덱스 스캔 방식이 있습니다.

인덱스 레인지 스캔은 검색할 인덱스 범위가 결정되었을 경우 사용하며 가장 빠릅니다.

• 인덱스에서 조건을 만족하는 값이 저장된 시작 리프 노드를 찾습니다.(index seek)
• 시작 리프 노드부터 필요한 만큼 인덱스를 차례대로 읽습니다. (index scan)
• 인덱스 키와 레코드 주소를 이용해 저장된 페이지를 가져오고 레코드를 읽어옵니다.

레코드를 읽어오는 과정에서 랜덤 IO가 발생할 수 있습니다. 읽어야할 데이터 레코드가 전체 20-25%의 경우에는 풀 테이블 스캔(순차 IO를 이용)이 더욱 좋을 수 있습니다.

인덱스 풀 스캔은 인덱스를 사용하지만 인덱스를 처음부터 끝까지 모두 읽는 방식입니다.

• 인덱스를 ABC 순서로 만들었는데 조건절에 B 혹은 C로 검색하는 경우 사용됩니다.
• 인덱스를 생성하는 목적은 아니지만, 그래도 풀 테이블 스캔보다는 낫습니다. (데이터 레코드까지 읽지 않는 경우)

루스 인덱스 스캔은 듬성듬성하게 인덱스를 읽는 것을 의미합니다. (앞서 언급한 인덱스 레인지, 인덱스 풀 스캔은 타이트 인덱스 스캔으로 분류됩니다.)

• 중간에 필요하지 않은 인덱스 키 값은 무시하고 다음으로 넘어가는 형태로 처리합니다.
• group by, max(), min() 함수에 대해 최적화하는 경우에 사용됩니다.

추가 학습 자료를 공유합니다.

• [Database] 인덱스(index)란?
• [MySQL] 프라이머리 키(PK, Primary Key)에 대해 쉽고 완벽하게 이해하기
• [MySQL] B-Tree로 인덱스(Index)에 대해 쉽고 완벽하게 이해하기
• [10분 테코톡] 안돌의 INDEX
• [10분 테코톡] 초코칩&로키의 인덱스와 스캔 튜닝

트랜잭션의 격리 수준은 동시에 여러 트랜잭션이 실행될 때 한 트랜잭션이 다른 트랜잭션의 연산에 영향을 받지 않도록 하는 정도를 말합니다. 낮은 격리 수준은 동시 처리 능력을 높이지만, 데이터의 일관성 문제를 발생시킬 수 있습니다. 반면, 높은 격리 수준은 데이터의 일관성을 보장하지만, 동시 처리 능력이 떨어질 수 있습니다. 즉, 데이터 정합성과 성능은 반비례합니다. 트랜잭션 격리 수준은 개발자가 트랜잭션 격리 수준을 설정할 수 있는 기능을 제공하는 기능입니다.

트랜잭션 격리 수준은 어떤 것이 있고 각각 어떤 특징이 있나요? 🤔

트랜잭션 격리 수준은 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ가 존재합니다.

READ UNCOMMITTED는 커밋이 되지 않은 트랜잭션의 데이터 변경 내용을 다른 트랜잭션이 조회하는 것을 허용합니다. 또한 해당 격리 수준에서는 Dirty Read, Phantom Read, Non-Repeatable Read 문제가 발생할 수 있습니다.

READ COMMITTED는 커밋이 완료된 트랜잭션의 변경사항만 다른 트랜잭션에서 조회할 수 있도록 허용합니다. 특정 트랜잭션이 이루어지는 동안, 다른 트랜잭션은 해당 데이터에 접근할 수 없습니다. Dirty Read는 발생하지 않지만, Phantom Read, Non-Repeatable Read 문제가 발생할 수 있습니다.

REPEATABLE READ는 한 트랜잭션에서 특정 레코드를 조회할 때 항상 같은 데이터를 응답하는 것을 보장합니다. 하지만, SERIALIZABLE과 다르게 행이 추가되는 것을 막지는 않습니다. Non-Repeatable Read 문제가 발생하지 않지만, Phantom Read 문제가 발생할 수 있습니다.

SERIALIZABLE은 특정 트랜잭션이 사용중인 테이블의 모든 행을 다른 트랜잭션이 접근할 수 없도록 잠급니다. 가장 높은 데이터 정합성을 가지지만 성능이 가장 낮습니다. MySQL의 경우 단순한 SELECT 쿼리가 실행되더라도 데이터베이스 잠금이 걸려 다른 트랜잭션에서 데이터에 접근할 수 없습니다.

발생하는 문제를 기준으로 설명을 잘해주셨네요. 그런데 각 문제들은 어떤 문제들인가요? 🤓

Dirty Read는 한 트랜잭션이 다른 트랜잭션이 변경 중인 데이터를 읽는 경우 발생합니다. 다른 트랜잭션이 아직 커밋되지 않은 (즉, 롤백할 가능성이 있는) 데이터를 읽어서, 그 데이터가 나중에 롤백될 경우 트랜잭션의 결과가 변경될 수 있습니다. 이는 데이터의 일관성을 깨뜨릴 수 있습니다.

Phantom Read는 한 트랜잭션이 동일한 쿼리를 두 번 실행했을 때, 두 번의 쿼리 사이에 다른 트랜잭션이 삽입, 갱신, 삭제 등의 작업을 수행하여 결과 집합이 달라지는 경우를 말합니다. 이로 인해 한 트랜잭션 내에서 일관성 없는 결과를 가져올 수 있습니다.

Non-Repeatable Read는 같은 트랜잭션 안에서 동일한 쿼리를 실행했을 때, 다른 결과를 얻는 경우를 의미합니다. 예를 들어, 한 트랜잭션이 같은 데이터를 두 번 읽을 때, 첫 번째 읽기와 두 번째 읽기 사이에 다른 트랜잭션이 해당 데이터를 변경했을 경우 발생할 수 있습니다.

추가 학습 자료를 공유합니다.

• [MySQL] 트랜잭션의 격리 수준(Isolation Level)에 대해 쉽고 완벽하게 이해하기
• wiki - Isolation (database systems)
• MySQL의 팬텀 리드를 재연하기
• [10분 테코톡] 러쉬의 MySQL 트랜잭션 격리 수준

자바에서 객체를 복사할 때 얕은 복사와 깊은 복사라는 두 가지 방식이 있습니다. 먼저 Book과 Author라는 두 클래스를 사용해서 예제를 살펴볼게요. Book은 책의 이름(name)과 저자(author) 정보를 가지고 있고, Author는 저자의 이름을 가지고 있습니다.

class Book {

    private String name; // 책 이름
    private Author author; // 저자

    public Book(String name, Author author) {
        this.name = name;
        this.author = author;
    }

    public Book shallowCopy() { // 얕은 복사
        return new Book(this.name, this.author);
    }

    public Book deepCopy() { // 깊은 복사
        Author copiedAuthor = new Author(this.author.getName());
        return new Book(this.name, copiedAuthor);
    }

    public void changeAuthor(String name) { // 저자 이름 변경
        author.setName(name);
    }

    @Override
    public String toString() {
        return "Book name : " + name + ", " + author;
    }

    static class Author {

        private String name; // 저자 이름

        public Author(String name) {
            this.name = name;
        }

        public String getName() { // 저자 이름 반환
            return name;
        }

        public void setName(String name) { // 저자 이름 변경
            this.name = name;
        }

        @Override
        public String toString() {
            return "Author : " + name;
        }
    }

    public static void main(String[] args) {
        Author author1 = new Author("조슈아 블로크");
        Book book1 = new Book("이펙티브 자바", author1);

        // 얕은 복사 후 변경
        Book shallowCopyBook = book1.shallowCopy();
        shallowCopyBook.changeAuthor("Joshua Bloch");

        // 얕은 복사 결과 출력
        System.out.println("After shallow copy and change:");
        System.out.println("Original book1: " + book1);
        System.out.println("Shallow copied book: " + shallowCopyBook);

        Author author2 = new Author("마틴 파울러");
        Book book2 = new Book("리팩터링", author2);

        // 깊은 복사 후 변경
        Book deepCopyBook = book2.deepCopy();
        deepCopyBook.changeAuthor("Martin Fowler");

        // 깊은 복사 결과 출력
        System.out.println("
After deep copy and change:");
        System.out.println("Original book2: " + book2);
        System.out.println("Deep copied book: " + deepCopyBook);
    }
}

shallowCopy() 메서드는 새로운 Book 객체를 만들지만, 내부의 Author 객체는 원본과 동일한 객체를 참조합니다. 즉, Book 객체는 새로 만들었지만, Author 객체는 새로 만들지 않고 기존의 것을 그대로 사용합니다. 예를 들어, book1에서 shallowCopyBook을 만든 후, shallowCopyBook의 저자 이름을 “Joshua Bloch”로 바꾸면 book1의 저자 이름도 “Joshua Bloch”로 바뀝니다. 둘이 같은 Author 객체를 공유하고 있기 때문에 두 Book 객체의 Author가 동시에 변경되는 거죠.

반면 deepCopy() 메서드는 Book 객체와 Author 객체 모두 새로운 객체로 만들어줘요. 그래서 book2에서 deepCopyBook을 만들고 deepCopyBook의 저자 이름을 “Martin Fowler”로 바꾸어도, book2의 저자 이름은 여전히 “마틴 파울러”로 남아 있어요. deepCopyBook과 book2가 서로 다른 Author 객체를 참조하고 있기 때문이에요.

출력 결과를 보면,

After shallow copy and change:
Original book1: Book name : 이펙티브 자바, Author : Joshua Bloch
Shallow copied book: Book name : 이펙티브 자바, Author : Joshua Bloch

얕은 복사에서 shallowCopyBook과 book1이 같은 Author를 공유하니까, shallowCopyBook의 저자 이름을 바꾸면 book1의 저자 이름도 바뀐 거예요.

After deep copy and change:
Original book2: Book name : 리팩터링, Author : 마틴 파울러
Deep copied book: Book name : 리팩터링, Author : Martin Fowler

깊은 복사한 deepCopyBook과 book2는 서로 다른 Author 객체를 참조하니까, deepCopyBook의 저자 이름을 바꿔도 book2는 영향을 받지 않습니다.

로그는 서버가 동작할 때 서버의 상태와 동작 정보를 시간 경과에 따라 기록된 결과입니다. 로그는 시스템의 오류와 문제들을 쉽게 찾아낼 수 있도록 도와줍니다. 반면, 메트릭은 시스템의 성능과 상태에 대한 통계적인 정보를 의미합니다. 메트릭을 잘 수집하면 시스템의 현재 상태를 손쉽게 파악할 수 있고, 사업 현황에 관한 유용한 정보를 얻을 수 있습니다. 가령, 메트릭은 DAU, Retension, CPU 사용량, 메모리 사용량 등이 있습니다.

로그와 메트릭을 수집해 보신 적이 있나요? 🤔

아래부터는 예시로 생각해주세요! 각자 진행하신 프로젝트 상황에 맞는 답변을 생각해 주세요. 😀

스프링 부트 액추에이터를 사용해 메트릭을 생성하고 프로메테우스에 저장한 다음 그라파나로 시각화한 경험이 있습니다. 수집한 지표는 다음과 같습니다.

• CPU, 메모리, JVM 힙 사용량
• 톰캣 스레드 풀과 데이터베이스 커넥션 풀 상태
• error 레벨 로그 증가량

로깅은 LogBack을 이용했습니다. 그리고, Loki에 7일동안 보관하도록 설정했으며 로그 추적을 위해 MDC를 사용했습니다.

언급해주신 메트릭을 수집하신 이유가 있으신가요? 🤓

CPU, 메모리, JVM 사용량 지표를 수집한 이유는 서비스가 현재 안정적으로 동작하고 있는지 파악하기 위함입니다. 또한, 톰캣 스레드 풀과 커넥션 풀의 상태와 error 레벨 로그를 수집한 이유는 서버 프로그램 내부에 비정상적인 상황이 생기는 것을 신속히 대응하기 위함입니다.

System.out.println을 사용하면 로깅 프레임워크는 사용하지 않아도 되지 않나요? 👀

로그를 출력하는 경우 대기 시간이 발생합니다. 그리고, 로그 또한 데이터이기 때문에 저장 공간을 요구합니다. 따라서, 정말로 필요한 경우에만 로깅을 수행하는 것이 비용 효율적입니다. 하지만, System.out.println은 로그 레벨 설정과 환경 별 필터링을 적용하기 까다롭습니다. 반면, 로깅 프레임워크는 로그 레벨 설정, 필터링 등 로그의 양 조절을 하기 위한 기능을 제공하기 때문에 이를 사용하는 것이 서비스 운영에 유리합니다.

추가 학습 자료를 공유합니다.

• [제미니의 개발실무] 로깅과 로그관리 + 분산 추적
• [10분 테코톡] ☂️ 검프의 Logging(로깅) #1
• [10분 테코톡] ☂️ 검프의 Logging(로깅) #2
• [액추에이터] - 액추에이터(Actuator) 시작하기
• [액추에이터] - 마이크로미터(Micrometer)와 메트릭(Metric)

JPA에서 ID를 생성하기 위해서는 직접 할당과 자동 할당을 사용할 수 있습니다. 직접 할당은 @Id어노테이션만을 사용하여 Id값을 직접 할당하는 방식입니다. 반면, 자동 할당은 @Id와 @GeneratedValue를 함께 사용해서 원하는 키 생성 전략을 선택하는 방식입니다. @GeneratedValue의 stretagy 옵션을 통해 생성 전략을 설정할 수 있는데, 여기에 올 수 있는 값인 GenerationType는 다음과 같습니다.

@Target({ElementType.METHOD, ElementType.FIELD})  
@Retention(RetentionPolicy.RUNTIME)  
public @interface GeneratedValue {  
    GenerationType strategy() default GenerationType.AUTO;  
  
    String generator() default "";  
}

public enum GenerationType { 
	AUTO,
	IDENTITY,
	SEQUENCE, 
	TABLE
}

자동 생성 방식을 사용할 때 각 전략에 대해서 설명해주세요. 🤔

IDENTITY 전략은 기본 키 생성을 DB에 위임하는 전략입니다. 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용됩니다. 해당 전략을 사용하면 엔티티를 생성할 때 쓰기 지연이 적용되지 않습니다. 왜냐하면 JPA에서 엔티티를 영속하기 위해선 식별자가 필요한데, IDENTITY 전략에서는 이 식별자가 DB에 저장되어야 할당되기 때문입니다. 따라서 엔티티를 생성할 때 즉시 INSERT 쿼리가 실행되어야 합니다. 이때 하이버네이트를 사용하는 경우에는 INSERT 쿼리의 결과를 다시 조회하지 않기 위해서 내부적으로 Statement.getGeneratedKeys를 사용합니다. 추가로 IDENTITY 전략을 사용하면 배치 인서트가 불가하다는 점을 주의해야합니다.

SEQUENCE 전략은 시퀀스 키 생성 전략을 지원하는 DB에서 사용할 수 있습니다. 데이터베이스 시퀀스란, 유일한 값을 자동으로 생성하게 하는 객체입니다. auto_increment와 달리 초기 값과 한번에 증가할 크기를 설정할 수 있습니다. 해당 시퀀스를 키 생성 전략으로 갖는 DB에 대해 SEQUENCE 전략을 사용할 수 있습니다. 어떤 시퀀스를 사용할 것인지를 @SequenceGenerator 로 설정할 수 있습니다. SEQUENCE 전략은 em.persist()를 호출하는 경우 먼저 데이터베이스 시퀀스를 이용하여 식별자를 조회합니다. 이후 조회한 식별자를 엔티티에 할당한 후에 엔티티를 영속성 컨텍스트에 저장합니다. 트랜잭션을 커밋하여 플러시가 일어나면 엔티티를 저장한다는 점에서 IDENTITY 전략과 차이가 있습니다.

TABLE 전략은 키 생성 전용 테이블을 만들어 시퀀스를 흉내내는 전략입니다. 어떤 테이블을 사용할 것인지를 @TableGenerator로 설정할 수 있습니다. TABLE 전략은 값을 조회하면서 SELECT 쿼리를 사용하며 증가를 위해 UPDATE 쿼리를 사용합니다. SEQUENCE 전략보다 DB와 한번 더 통신한다는 점에서 성능이 안좋다는 단점이 있지만, 모든 DB에 적용할 수 있다는 장점이 있습니다.

AUTO 전략은 데이터베이스 방언에 따라서 IDENTITY, SEQUENCE, TABLE 중 하나를 자동으로 선택합니다. 데이터베이스를 변경해도 코드를 수정할 필요가 없다는 장점이 있습니다.

추가 학습 자료를 공유합니다.

• [JPA] 기본 키(Primary Key)매핑 - @Id, @GeneratedValue
• [JPA] 기본 키 매핑 - SEQUENCE, TABLE 전략의 최적화
• Identity 전략으로는 Batch Insert가 불가능한 이유
• 최범균님 JPA - JPA 기초 05 엔티티 식별자 생성 방식

equals와 hashCode 메서드는 객체의 동등성 비교와 해시값 생성을 위해서 사용할 수 있습니다. 하지만, 함께 재정의하지 않는다면 예상치 못한 결과를 만들 수 있습니다. 가령, 해시값을 사용하는 자료구조(HashSet, HashMap..)을 사용할 때 문제가 발생할 수 있습니다.

class EqualsHashCodeTest {

    @Test
    @DisplayName("equals만 정의하면 HashSet이 제대로 동작하지 않는다.")
    void test() {
        // 아래 2개는 같은 구독자
        Subscribe subscribe1 = new Subscribe("team.maeilmail@gmail.com", "backend");
        Subscribe subscribe2 = new Subscribe("team.maeilmail@gmail.com", "backend");
        HashSet<Subscribe> subscribes = new HashSet<>(List.of(subscribe1, subscribe2));

        // 결과는 1개여야하는데..? 2개가 나온다.
        System.out.println(subscribes.size());
    }

    class Subscribe {

        private final String email;
        private final String category;

        public Subscribe(String email, String category) {
            this.email = email;
            this.category = category;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (o == null || getClass() != o.getClass()) return false;
            Subscribe subscribe = (Subscribe) o;
            return Objects.equals(email, subscribe.email) && Objects.equals(category, subscribe.category);
        }
    }
}

왜 이런 현상이 발생하나요? 🤔

해시값을 사용하는 자료구조는 hashCode 메서드의 반환값을 사용하는데요. hashCode 메서드의 반환 값이 일치한 이후 equals 메서드의 반환값 참일 때만 논리적으로 같은 객체라고 판단합니다. 위 예제에서 Subscribe 클래스는 hashCode 메서드를 재정의하지 않았기 때문에 Object 클래스의 기본 hashCode 메서드를 사용합니다. Object 클래스의 기본 hashCode 메서드는 객체의 고유한 주소를 사용하기 때문에 객체마다 다른 값을 반환합니다. 따라서 2개의 Subscribe 객체는 다른 객체로 판단되었고 HashSet에서 중복 처리가 되지 않았습니다.

동일성과 동등성은 객체를 비교할 때 중요한 개념입니다. 자바에서는 이 두 개념을 equals() 메서드와 == 연산자를 통해 구분할 수 있습니다.

equals()와 ==의 차이는 무엇인가요?

equals()는 객체의 내용을 비교하는 반면, ==는 객체의 참조(레퍼런스)를 비교합니다. 따라서 두 객체의 내용이 같더라도 서로 다른 객체라면 equals()는 true를 반환할 수 있지만, ==는 false를 반환합니다.

동등성(Equality)은 뭔가요?

동등성은 논리적으로 객체의 내용이 같은지를 비교하는 개념입니다. 자바에서는 equals() 메서드를 사용하여 객체의 동등성을 비교합니다. Apple 클래스를 예시로 보면, Object.equals 메서드를 오버라이딩하여 객체의 실제 데이터를 비교하도록 했습니다. 그래서 apple과 anotherApple은 다른 객체이지만, 무게가 같기 때문에 동등성 비교 결과 true가 반환됩니다.

public class Apple {

    private final int weight;

    public Apple(int weight) {
        this.weight = weight;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Apple apple = (Apple) o;
        return weight == apple.weight;
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(weight);
    }

    public static void main(String[] args) {
        Apple apple = new Apple(100);
        Apple anotherApple = new Apple(100);

        System.out.println(apple.equals(anotherApple)); // true
    }
}

왜 equals() 메서드를 오버라이딩 했나요?

public class Object {
    ...
    public boolean equals(Object obj) {
        return (this == obj);
    }
    ...
}

Object 클래스의 equals() 메서드는 == 연산자를 사용하여 동일성을 비교합니다. 그리고 모든 클래스는 Object 클래스를 상속하여 동일성 비교를 기본으로 동작하기 때문에, 동등성 비교가 필요한 클래스에서 필요에 맞게 equals & hashCode 메서드를 오버라이딩해야 합니다.

동일성(Identity)은 뭔가요?

동일성은 두 객체가 메모리 상에서 같은 객체인지 비교하는 개념입니다. 자바에서는 == 연산자를 사용하여 객체의 동일성을 비교합니다. == 연산자는 객체의 레퍼런스(참조)를 비교하므로, 두 변수가 동일한 객체를 가리키고 있는지를 확인합니다.

public static void main(String[] args) {
    Apple apple1 = new Apple(100);
    Apple apple2 = new Apple(100);
    Apple apple3 = apple1;

    System.out.println(apple1 == apple2); // false
    System.out.println(apple1 == apple3); // true
}

apple1과 apple2는 참조가 다르기 때문에 == 연산 결과 false가 반환되지만, apple1의 참조를 가지는 apple3은 == 연산 결과 true를 반환합니다.

String은 객체인데 == 비교해도 되던데 어떻게 된건가요?

문자열 리터럴은 문자열 상수 풀(String Constant Pool) 에 저장되기 때문에, 동일한 문자열 리터럴을 참조하면 == 연산자가 true를 반환할 수 있습니다. 하지만 new 키워드를 사용하여 문자열을 생성하면 새로운 객체가 생성되므로 == 연산자가 false를 반환할 수 있습니다. 따라서 문자열 비교 시 항상 equals() 메서드를 사용한 동등성 비교를 하는 것이 좋습니다.

public class StringComparison {
    public static void main(String[] args) {
        String str1 = "안녕하세요";
        String str2 = "안녕하세요";
        String str3 = new String("안녕하세요");
        
        // 동일성 비교
        System.out.println(str1 == str2); // true
        System.out.println(str1 == str3); // false
        
        // 동등성 비교
        System.out.println(str1.equals(str2)); // true
        System.out.println(str1.equals(str3)); // true
    }
}

// String.class equals 오버라이딩 되어있음.
public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    return (anObject instanceof String aString)
            && (!COMPACT_STRINGS || this.coder == aString.coder)
            && StringLatin1.equals(value, aString.value);
}

Integer 같은 래퍼 클래스는 어떻게 비교하나요?

래퍼 클래스도 객체이기 때문에 == 연산자는 참조를 비교합니다. 값 비교를 원할 경우 equals() 메서드를 사용해야 합니다. 다만, 자바는 특정 범위의 래퍼 객체를 캐싱하므로 같은 값의 Integer 객체가 같은 참조를 가질 수 있습니다(-128 ~ 127). 하지만 일반적으로 equals()를 사용하는 것이 안전합니다.

추가 학습 자료를 공유합니다.

• 자바의 동등성과 동일성 이해하기
• how-do-you-implement-equals-hashcode-methods
• what-is-the-difference-between-identity-and-equality-in-oop
• equals와 hashCode는 왜 함께 재정의해야 할까요?

@Component, @Service, @Controller, @Repository는 각각의 클래스를 특정 역할을 수행하는 Spring Bean으로 등록할 때 사용됩니다. 각 애너테이션은 클래스가 어떤 역할을 하는지를 명시적으로 나타내며, Spring의 @ComponentScan 기능을 통해 자동으로 Bean으로 등록됩니다. @Service, @Controller, @Repository 어노테이션은 내부적으로 @Component 어노테이션을 사용하고 있으며, 각 특징과 용도는 아래와 같습니다.

• @Component는 가장 일반적인 형태의 어노테이션으로, 특정 역할에 종속되지 않는 일반적인 Spring Bean을 나타냅니다. 공통 기능을 제공하는 유틸리티 클래스나, 특정 계층에 속하지 않는 일반적인 컴포넌트를 정의할 때 사용됩니다.

• @Service는 비즈니스 로직을 수행하는 클래스에 사용되며 서비스 레이어의 Bean을 나타냅니다.

• @Controller는 Spring MVC에서 웹 요청을 처리하는 컨트롤러 클래스에 사용되며 프레젠테이션 레이어의 Bean을 나타냅니다.

• @Repository는 데이터베이스와의 상호작용을 수행하는 클래스에 사용되며. 데이터 액세스 레이어의 Bean을 나타냅니다.

@Controller, @Repository 대신 @Component 사용하면 안되나요?

Spring 6(Spring Boot 3) 이전 버전에서는 @Component + @RequestMapping으로도 Bean 및 핸들러로 등록되었습니다. 하지만 Spring 6 이후 부터 @Controller 외에는 핸들러로 등록하지 않아 웹 요청을 정상적으로 수행할 수 없습니다.

public class RequestMappingHandlerMapping extends RequestMappingInfoHandlerMapping
		implements MatchableHandlerMapping, EmbeddedValueResolverAware {
    ...
    @Override
    protected boolean isHandler(Class<?> beanType) {
        return AnnotatedElementUtils.hasAnnotation(beanType, Controller.class); // 컨트롤러 애너테이션인지 확인
    }
    ...
}

@Repository를 @Component로 대체할 경우, PersistenceExceptionTranslationPostProcessor에 의해 예외가 DataAccessException으로 변환되지 않습니다. 이 경우 데이터 액세스 계층에서 발생하는 예외 처리에 영향을 미칠 수 있습니다.

또 @Service, @Controller, @Repository는 각각 특정 계층을 나타내므로, AOP의 포인트컷을 정의할 때 유용하게 사용될 수 있습니다. @Component를 사용하면 이러한 계층 구분이 불분명해져 AOP 적용이 어려울 수 있습니다.

추가 학습 자료를 공유합니다.

• Spring Bean Annotations
• @RequestMapping without @Controller registered as handler [SPR-17622]
• General ORM Integration Considerations

외부 서비스 장애로 인해 응답이 오래 걸린다고 했을 때 외부 API 응답으로 대기하는 자원들이 운영 서버 내부에 쌓이면서 성능에 악영향을 줄 수 있습니다. 이를 해결하기 위한 가장 기본적인 방법은 타임아웃을 설정하는 것입니다. 크게 타임아웃에는 커넥션 타임아웃과 리드 타임아웃, HTTP 커넥션 풀 타임아웃을 설정해 볼 수 있습니다.

다음과 같이 특정 서비스의 장애가 전체 서비스에 영향을 주는 경우는 어떻게 해결할 수 있을까요? 🤔

1. A 서비스, B 서비스, C 서비스 연동 코드가 HTTP 커넥션 풀을 공유한다.
2. A 서비스의 장애로 응답 시간 지연이 발생하는 경우
    2-1. 풀에 남은 커넥션이 점점 줄어든다.
    2-2. 풀에서 커넥션을 구하는 대기 시간이 증가한다.
    2-3. B, C 서비스에 대한 연동도 함께 대기한다.

이 경우는 벌크헤드 패턴을 적용해 볼 수 있습니다. 벌크헤드 패턴은 기능의 종류마다 자원 사용을 분리하는 것을 의미하는데요. 자원을 격리하여 서비스 일부에 장애가 발생해도 전체로 전파되지 않도록 보장해 주는 패턴입니다. 위 예시에서는 외부 서비스마다 다른 HTTP 커넥션 풀을 사용하도록 벌크헤드 패턴을 적용할 수 있습니다. 서로 다른 커넥션 풀을 사용하기 때문에 A 서비스에 문제가 발생해도 B,C의 영향을 최소화할 수 있습니다.

외부 서비스 장애가 계속 발생하면 어떻게 되나요?

지속되는 외부 서비스 장애로 타임아웃에 의한 서비스 에러가 발생할 수 있습니다. 외부 서비스가 장애가 발생했는데도 불구하고 운영 서버는 계속 요청을 보내게 되니, 불필요하게 응답 시간이 저해되고, 처리량도 감소하게 됩니다. 이 문제를 해결하기 위해서는 서킷 브레이커를 적용할 수 있는데요. 서킷 브레이커는 오류가 지속되는 경우 일정 시간 동안 기능 실행을 차단할 수 있습니다. 서킷 브레이커가 빠른 실패를 도와주기 때문에 외부 서비스 장애에 의한 응답 시간 증가를 예방할 수 있습니다.

추가 학습 자료를 공유합니다.

• 외부 API 장애에 영향 덜 받는 3가지 방법
• Bulkhead 패턴을 사용한 장애 격리
• Connection Timeout과 Read Timeout 살펴보기

TCP 3-way handshake는 TCP/IP 네트워크에서 안정적이고 연결 지향적인 통신을 설정하기 위해 사용되는 절차입니다. 이 절차는 클라이언트와 서버 간에 신뢰할 수 있는 연결을 설정하기 위해 세 개의 메시지(세그먼트)를 교환하는 과정을 포함합니다.

우선 클라이언트는 서버에 연결을 요청하는 SYN 세그먼트를 보내는데요. 이 세그먼트에는 초기 순서 번호(Sequence Number)와 윈도우 크기(Window Size) 정보가 포함되어 있습니다.

이후 서버는 클라이언트의 요청을 수락하고, SYN과 ACK 플래그가 설정된 세그먼트를 클라이언트에 보냅니다. 이 세그먼트는 서버의 초기 순서 번호와 클라이언트의 초기 순서 번호에 대한 응답(ACK=클라이언트의 초기 순서 번호 + 1)을 포함합니다.

클라이언트는 서버의 응답을 확인하고, ACK 플래그가 설정된 세그먼트를 서버에 보냅니다. 이 세그먼트는 서버의 순서 번호에 대한 응답(ACK=서버의 초기 순서 번호 + 1)을 포함합니다. 이 절차가 완료되면 클라이언트와 서버 간에 신뢰할 수 있는 연결이 설정되고, 데이터 전송이 시작될 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 🔮 수리의 TCP/IP
• [네트워크 쉽게 이해하기 22편] TCP 3 Way-Handshake & 4 Way-Handshake

동기와 비동기는 호출하는 함수의 작업 완료를 기다리는지 여부의 차이가 있습니다. 함수 A가 동기로 함수 B를 호출하면 A는 B의 작업이 완료될 때까지 기다려야 합니다. 따라서 작업이 순차적으로 진행됩니다. 반면, 함수 A가 비동기로 함수 B를 호출하면 A는 B의 작업 완료를 신경 쓰지 않고 따로 동작합니다. 따라서 작업이 순차적으로 진행되지 않습니다.

블로킹과 동기는 어떤 차이가 있나요? 🤔

두 개념은 유사하면서도 다른데요. 동기 호출에서는 호출된 함수가 작업을 완료할 때까지 호출한 함수가 기다립니다. 즉, 작업이 순차적으로 진행되는 것을 의미합니다. 반면, 블로킹은 함수가 호출된 후, 호출한 함수의 결과를 기다리기 위해 실행을 멈추는 상태를 의미합니다. 즉, 제어권이 반환되지 않고 대기하는 상황입니다.

스프링에서 비동기 처리는 어떻게 하며 무엇을 주의해야 하나요?

스프링에서는 @Async 어노테이션을 사용하여 비동기 처리를 수행할 수 있습니다. 해당 어노테이션을 사용하기 위해서는 몇 가지 주의할 부분이 있는데요. 기본적으로 @Async 가 적용된 메서드에서 발생하는 예외는 호출자에게 전파되지 않습니다. 비동기 메서드에서 예외를 정상적으로 처리하기 위해서는 별도의 비동기 예외 처리기를 사용해야 합니다. 또한, @Async 어노테이션은 프록시 기반으로 동작하기 때문에 같은 클래스 내부에서 직접 호출하는 경우 별도의 스레드에서 메서드가 실행되지 않습니다. 그리고, 비동기 메서드 내에서 생성한 트랜잭션은 상위 트랜잭션과 무관한 생명주기를 가집니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 호기의 blocking VS non-blocking, sync VS async
• [10분 테코톡] 🐰 멍토의 Blocking vs Non-Blocking, Sync vs Async
• [테코블] 동기와 비동기 with webClient
• [Spring] @Async와 스레드풀

DBMS에서 트랜잭션을 특별한 제어 없이 병행 수행을 허용한다면 데이터의 일관성과 무결성을 보장하기 어려울 수 있습니다. 이때, 병행 수행되는 트랜잭션들을 제어하기 위해서 락을 사용할 수 있으며 DBMS에서 락은 크게 공유 락과 배타 락으로 분류할 수 있습니다.

공유 락(Shared Lock) 은 읽기 락(Read Lock)이라고 부르며, 공유 락이 걸린 데이터에 대해서 다른 트랜잭션에서도 공유 락을 획득할 수 있지만, 배타 락은 획득할 수 없습니다. 즉, 공유 락을 사용하면 트랜잭션 내에서 조회한 데이터가 변경되지 않는다는 것을 보장합니다.

SELECT * FROM table_name WHERE id = 1 FOR SHARE;

배타 락(Exclusive Lock) 은 쓰기 락(Write Lock)이라고 부르며, 배타 락이 걸린 데이터에 대해서 다른 트랜잭션에서는 공유 락과 배타 락을 획득할 수 없습니다. 즉, 배타 락을 획득한 트랜잭션은 데이터에 대한 독점권을 가집니다.

SELECT * FROM table_name WHERE id = 1 FOR UPDATE;

정리하자면, 공유 락이 걸린 데이터는 다른 트랜잭션에서 공유 락을 획득 할 수 있고, 배타 락이 걸린 데이터는 다른 트랜잭션에서 어떤 종류의 락도 획득할 수 없어서 대기하는 상황이 발생할 수 있습니다.

데드 락은 언제 발생하며 어떻게 해결할 수 있나요? 🤔

데드 락(Dead Lock) 이란 교착 상태로, 두개 이상의 트랜잭션이 서로 필요로 하는 데이터의 락을 점유하고 있어서 무한히 대기하는 상황을 말합니다. 트랜잭션은 락을 획득하지 못하는 경우, 다른 트랜잭션이 점유하고 있는 락이 해제될 때까지 대기합니다. 예를 들어, 다음과 같은 트랜잭션들이 존재한다고 가정하겠습니다.

• 트랜잭션 A, B가 있고 id가 1, 2인 데이터가 있는 상황에 두 트랜잭션이 시작합니다.
• 트랜잭션 A는 id 1번을 읽고, 2번 데이터를 변경하는 트랜잭션입니다.
• 트랜잭션 B는 id 2번을 읽고 1번을 변경하는 트랜잭션입니다.

이때 다음과 같은 상황에서 데드 락이 발생할 수 있습니다.

• A는 1번, B는 2번 데이터에 대해 공유 락을 획득합니다.
• A는 2번 데이터의 공유 락을 가지고 있는 B 트랜잭션이 락을 해제할 때까지 대기합니다.
• B는 1번 데이터의 공유 락을 가지고 있는 A 트랜잭션이 락을 해제할 때까지 대기합니다.

데드 락을 해결하기 위해서 트랜잭션에서 락 획득 순서를 일관되게 할 수 있습니다. 모든 트랜잭션에서 1번 데이터, 2번 데이터 순으로 락을 획득할 시 데드 락이 발생하지 않습니다. 혹은 락 타임 아웃을 설정하여 데드 락 상황을 해결할 수 있습니다.

추가 학습 자료를 공유합니다.

• MySQL 8.0의 공유 락(Shared Lock)과 배타 락(Exclusive Lock)
• JPA의 비관적 락, MySQL 8.0 공유락과 베타락을 통한 동시성 제어
• Shared and Exclusive Locks
• [10분 테코톡] ⛲️ 오즈의 데이터베이스 Lock

단위 테스트는 소프트웨어의 가장 작은 단위, 즉 개별 메서드나 함수의 기능을 검증하는 테스트입니다. 특정 기능이 올바르게 동작하는지 확인하기 위함이며 독립적이고 빠르게 실행됩니다. 반면 통합 테스트는 개별 모듈들이 결합되어 전체 시스템이 올바르게 동작하는지 검증하는 테스트입니다. 모듈 간의 상호작용이 올바르게 동작하는지 확인하기 위함이며 실제 데이터베이스, 네트워크 등의 외부 시스템과의 통합을 테스트합니다.

슬라이스 테스트는 무엇인가요? 🤔

슬라이스 테스트는 특정 레이어(ex. controller, service, repository)에 대한 테스트입니다.애플리케이션의 특정 슬라이스가 올바르게 동작하는지 확인하기 위해 작성됩니다. 스프링의 특정 컴포넌트만 로드하여 테스트하므로 상대적으로 빠르게 실행됩니다. 관련된 어노테이션으로는 @WebMvcTest, @DataJpaTest 등이 있습니다.

테스트 코드를 작성해야하는 이유가 무엇인가요? 🤓

테스트 코드를 작성하면 버그를 조기에 발견할 수 있으며 리팩터링을 수행할 경우 유용합니다. 또한, 개발 속도를 향상 시킬 수 있으며 코드에 대한 문서로서 역할을 수행할 수 있습니다.

추가 학습 자료를 공유합니다.

• Spring Boot 슬라이스 테스트
• 스프링캠프 2019 [Track 2 Session 3] : 무엇을 테스트할 것인가? 어떻게 테스트할 것인가? (권용근)
• 스프링캠프 2023 [Session 5] 실무에서 적용하는 테스트 코드 작성 방법과 노하우 (김남윤)

스레드, 프로세스, 코어의 수가 많을수록 시스템 성능이 향상된다고 생각할 수 있지만, 실제로는 그렇지 않을 확률이 큽니다.

스레드가 많으면?

스레드가 지나치게 많아지면 운영체제가 스레드 간 컨텍스트 스위칭을 자주 수행해야 하여 CPU 자원이 스레드 관리에 소모됩니다. 이로 인해 실제 작업 수행 효율이 떨어질 수 있으며, 많은 스레드가 동시에 실행될 경우 메모리나 캐시, 락 등의 자원을 경쟁하게 되어 성능 저하나 데드 락이 발생할 가능성이 높아집니다. 또한, 스레드가 많아지면 동기화와 상태 관리가 복잡해져 버그 발생 가능성도 커집니다.

프로세스가 많으면?

각 프로세스는 독립된 메모리 공간을 가집니다. 그래서 많은 프로세스가 동시에 실행되면 메모리 사용량이 급격히 증가할 수 있습니다. 또한, 프로세스를 생성하고 관리하는 데는 상당한 시스템 자원이 소모되며, 프로세스 간 통신(IPC)이 필요할 경우 성능 저하가 발생할 수 있습니다. 프로세스 간 컨텍스트 스위칭은 스레드 간 컨텍스트 스위칭보다 더 많은 오버헤드를 수반하기 때문에, 프로세스 수가 많아지면 시스템 성능이 저하될 수 있습니다. 운영체제는 동시에 실행할 수 있는 프로세스 수에 제한이 있으며, 이를 초과하면 새로운 프로세스 생성이 불가능하거나 시스템이 불안정해질 수 있습니다.

코어가 많으면?

많은 코어를 가진 CPU는 병렬 처리 성능을 향상시킬 수 있지만, 이를 최대한 활용하기 위해서는 소프트웨어가 멀티코어 환경에 최적화되어 있어야 합니다. 단일 스레드 작업이 주를 이루는 경우, 추가 코어의 이점을 제대로 활용하지 못할 수 있습니다. 또한, 코어 수가 많아질수록 CPU의 비용과 전력 소비가 증가할 수 있으며, 발열 관리도 더 복잡해집니다.

추가 학습 자료를 공유합니다.

• CPU가 멀티태스킹을 하는 방법: 프로세스 VS 스레드
• 완전히 정복하는 프로세스 vs 스레드 개념
• [10분 테코톡] 🌷 코다의 Process vs Thread

애플리케이션과 데이터베이스가 통신을 하기 위해서는 데이터베이스 커넥션이 필요합니다.

데이터베이스 커넥션의 생애주기 :

1. 데이터베이스 드라이버를 사용하여 데이터베이스에 연결
2. 데이터 읽기/쓰기를 위한 TCP 소켓 열기
3. 소켓을 통한 데이터 읽기/쓰기
4. 연결 종료
5. 소켓 닫기

커넥션 풀이 없다면 애플리케이션에서 데이터베이스에 접근해야하는 요청을 처리할 때마다 커넥션을 새로 생성하여 연결하고 해제하는 과정을 반복해야 합니다. 이 과정은 비용이 상당히 많이 들기 때문에 요청의 응답시간이 길어집니다.

또 동시에 많은 요청이 들어올 경우 매번 새로운 커넥션을 생성하게 되는데, 데이터베이스의 최대 연결 수를 초과할 수 있습니다. 데이터베이스는 일반적으로 동시에 처리할 수 있는 요청 개수에 제한이 있는데, 이 제한을 초과하면 요청이 거부되어 사라지거나, 데이터베이스 자체가 비정상 종료될 수 있습니다.

데이터베이스 커넥션 풀을 사용함으로써 얻을 수 있는 장점은 무엇인가요?

커넥션 풀(Connection Pool)은 애플리케이션과 데이터베이스 간의 데이터베이스 연결(Connection)을 미리 생성해두고, 이를 재사용하는 기법을 말합니다. 데이터베이스에 접근할 때마다 새로운 연결을 생성하고 종료하는 대신, 미리 준비된 연결을 재사용함으로써 성능을 향상시키고 자원 사용을 최적화할 수 있습니다.

커넥션 풀의 주요 구성 요소는 초기 풀 크기(Initial Pool Size), 최소 풀 크기(Minimum Pool Size), 최대 풀 크기(Maximum Pool Size), 연결 대기 시간(Connection Timeout) 등이 있고, 이를 통해 커넥션을 효율적으로 관리하고 사용할 수 있습니다.

그럼 커넥션 풀 사이즈는 클 수록 좋나요? 🤔

커넥션을 사용하는 주체는 스레드(Thread)이기 때문에, 커넥션과 스레드를 연결지어 생각해야 합니다. 만약 커넥션 풀 사이즈가 스레드 풀 사이즈보다 크면, 스레드가 모두 사용하지 못해서 리소스가 낭비됩니다. 반대로 커넥션 풀 사이즈가 스레드 풀 사이즈보다 작으면, 스레드가 커넥션이 반환되기를 기다려야 하기 때문에 작업이 지연됩니다.

커넥션 풀 사이즈와 스레드 풀 사이즈의 균형이 맞더라도, 너무 큰 사이즈로 설정하면, 데이터베이스 서버, 애플리케이션 서버의 메모리와 CPU를 과도하게 사용하게 되므로 성능이 저하됩니다.

추가 학습 자료를 공유합니다.

• A Simple Guide to Connection Pooling in Java
• HikariCP
• 데이터베이스 커넥션 풀의 이해와 최적화 전략
• 데이터베이스 커넥션 풀 (Connection Pool)과 HikariCP
• DBCP (DB connection pool)의 개념부터 설정 방법까지! hikariCP와 MySQL을 예제로 설명합니다!

예를들어 사용자가 www.google.com을 입력하면, 브라우저는 HTTP 프로토콜을 사용해 구글 웹 서버와 통신하려고 합니다. HTTP는 OSI 7계층 중 애플리케이션 계층에서 동작하는 프로토콜입니다.

이때 브라우저는 요청한 도메인 이름(www.google.com)에 대한 IP 주소를 알아야 하기 때문에 DNS(Domain Name System) 서버에 질의합니다. 이 질의 과정 또한 애플리케이션 계층에서 이루어지며, DNS 서버는 해당 도메인에 대한 IP 주소(예를 들어, 142.250.190.78)를 응답합니다.

IP 주소를 얻은 후, 브라우저는 구글 서버와 통신을 시작합니다. HTTP는 TCP/IP를 기반으로 작동하므로, 데이터를 주고받기 전에 TCP 3-Way Handshake 과정이 필요합니다. 이 단계는 전송 계층(4계층) 에서 이루어집니다.

TCP 연결이 성립된 후, 브라우저는 HTTP Request 메시지를 생성하여 구글 서버에 보냅니다. 예를 들어, 브라우저는 “GET / HTTP/1.1”이라는 요청을 TCP 프로토콜을 통해 80번 포트로 전송합니다. 이때 데이터는 패킷(Packet) 형태로 네트워크를 통해 전달됩니다. 네트워크를 통해 데이터를 전송하기 위해서는 네트워크 계층(3계층) 에서 IP 주소를 사용하고, 데이터 링크 계층(2계층) 에서 MAC 주소를 사용하여 패킷이 전송됩니다.

구글 서버는 클라이언트의 요청을 수신하고 이를 처리한 후, HTTP Response 메시지를 생성하여 응답합니다. 서버는 요청이 성공했음을 알리는 200 OK 상태 코드와 함께 웹 페이지 데이터를 전송합니다. 브라우저는 이 응답을 받아 HTML, CSS, 자바스크립트 등의 데이터를 해석하여 화면에 페이지를 렌더링합니다.

모든 데이터 전송이 완료되면 클라이언트와 서버는 4-Way Handshake 과정을 거쳐 TCP 연결을 종료합니다.

추가 학습 자료를 공유합니다.

• 웹의 동작 방식
• 웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가
• 웹 브라우저에 URL 입력하면 일어나는 일 - 인프라 위주

연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 멱등성이라고 합니다. HTTP 메서드의 멱등성은 동일한 요청을 한번 보내는 것과 여러번 보내는 것이 서로 동일한 효과를 지니며, 서버의 상태도 동일하게 남을 경우에 멱등하다고 이야기할 수 있습니다. 대표적으로 멱등한 메서드는 GET, HEAD, PUT, DELETE, TRACE, OPTIONS 가 있습니다.

멱등성은 어떻게 활용될 수 있나요? 🤔

모종의 이유로 전송 커넥션이 끊어졌을 때, 멱등성은 클라이언트가 다시 같은 요청을 해도 되는가에 대한 판단 근거가 될 수 있습니다. 멱등하다면 요청을 재시도할 때 같은 서버의 상태를 보장하기 때문에 문제가 없습니다. 반면, 멱등하지 않다면 재시도 요청시 중복 요청을 보내 문제를 발생 시킬 수 있습니다. 예를 들어, 사용자가 결제하는 시점에 타임아웃으로 인해 정상 응답을 못받는 상황을 생각해 볼 수 있습니다. 해당 경우에서 멱등하지 않은 결제 API 경우에는 결제가 성공했는지 수동으로 확인하고 재요청해야합니다. 반면, 멱등한 결제 API의 경우에는 안심하고 여러 번 요청할 수 있으며 중복 요청으로 발생하는 문제(중복 결제)를 방지할 수 있습니다.

추가 학습 자료를 공유합니다.

• 토스페이먼츠 - 멱등성이 뭔가요?
• [HTTP] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유
• HTTP 멱등성(idempotency):개념에서 적용까지

대표적인 동시성 제어 방식으로 MVCC(Multi-Version Concurrency Control) 와 Lock-Based Concurrency Control이 있습니다.

MVCC(Multi-Version Concurrency Control)

MVCC는 데이터의 여러 버전을 유지하여 트랜잭션이 동시에 데이터를 읽고 쓸 수 있도록 하는 방식입니다. 각 트랜잭션은 자신만의 일관된 스냅샷을 기반으로 데이터를 읽어, 다른 트랜잭션의 변경 사항에 영향을 받지 않습니다.

데이터의 각 버전을 유지하여 읽기 작업이 쓰기 작업과 독립적으로 이루어질 수 있습니다. 트랜잭션은 시작 시점의 스냅샷을 기반으로 데이터를 읽어, 다른 트랜잭션의 변경 사항을 보지 못합니다.

또한 읽기 작업 시 잠금을 사용하지 않아 높은 동시성을 제공합니다. 읽기 작업이 잠금에 의해 지연되지 않아, 읽기 중심의 애플리케이션에서 우수한 성능을 보입니다. 읽기 작업 시 잠금을 사용하지 않으므로, 쓰기 작업과의 충돌이 줄어듭니다. 하지만 여러 버전의 데이터를 유지해야 하므로 저장 공간이 더 많이 필요할 수 있습니다.

트랜잭션이 시작된 시점의 데이터 상태를 기반으로 읽기 작업을 수행하여 일관성을 유지합니다. 또 갭락과 넥스트키 락을 통해 팬텀 리드를 방지합니다.

Lock-Based Concurrency Control

Lock-Based 방식은 데이터에 접근할 때 잠금(Lock) 을 사용하여 동시성을 제어합니다. 트랜잭션이 데이터를 읽거나 수정할 때 해당 데이터에 잠금을 걸어 다른 트랜잭션의 접근을 제한합니다. 즉, 잠금을 통해 데이터의 일관성과 무결성을 직접적으로 제어합니다.

데이터에 접근할 때 잠금을 걸어 다른 트랜잭션의 접근을 제한합니다. 읽기 작업은 공유 잠금을, 쓰기 작업은 배타 잠금을 사용하여 동시성을 제어합니다. 많은 다수의 트랜잭션이 동일한 데이터에 접근할 경우 성능 저하가 발생할 수 있습니다. 또 잘못된 잠금 순서나 설계로 인해 교착 상태(Deadlock)가 발생할 위험이 있습니다.

MVCC와 Lock-Based Concurrency Control 둘 중 어떤 걸 사용해야 하나요? 🤔

실제 데이터베이스 시스템, 특히 MySQL의 InnoDB는 MVCC와 Lock-Based 방식의 장점을 결합하여 동시성 제어를 최적화합니다.

읽기 트랜잭션은 MVCC를 사용하여 일관된 스냅샷을 기반으로 데이터를 읽으므로, 잠금을 최소화하고 높은 동시성을 유지할 수 있습니다.

쓰기 트랜잭션은 잠금을 사용하여 데이터의 일관성과 무결성을 유지하면서, 동시에 데이터 충돌을 방지합니다.

추가 학습 자료를 공유합니다.

• [Database] MVCC(다중 버전 동시성 제어)란?
• MVCC(Multi Version Concurrency Control) 알아보기
• Lock Based Concurrency Control Protocol in DBMS
• What is MVCC? How does multiversion concurrency control work?

Phantom Read란 무엇인가요?

Phantom Read는 트랜잭션이 동일한 조건의 쿼리를 반복 실행할 때, 나중에 실행된 쿼리에서 처음에는 존재하지 않았던 새로운 행이 나타나는 현상을 말합니다. 이는 주로 읽기 일관성(Read Consistency) 을 유지하는 과정에서 발생할 수 있는 문제로, 데이터의 삽입이나 삭제가 다른 트랜잭션에 의해 이루어질 때 발생합니다.

-- 트랜잭션 A 시작
START TRANSACTION;

-- 트랜잭션 A 첫 번째 조회
SELECT * FROM orders WHERE amount > 150;

-- 트랜잭션 B 시작
START TRANSACTION;

-- 트랜잭션 B 새로운 행 삽입
INSERT INTO orders (customer_id, amount) VALUES (4, 250);

-- 트랜잭션 B 커밋
COMMIT;

-- 동일한 조건으로 트랜잭션 A 두 번째 조회시, 트랜잭션 A의 첫 번째 조회에는 존재하지 않던, 트랜잭션 B에서 삽입된 새로운 행이 함께 조회된다.
-- 단, MVCC를 지원하는 경우 해당 케이스에서 팬텀 리드가 발생하지 않는다.
SELECT * FROM orders WHERE amount > 150;

갭락(Gap Lock)이란?

갭 락은 특정 인덱스 값 사이의 공간을 잠그는 락입니다. 기존 레코드 간의 간격을 보호하여 새로운 레코드의 삽입을 방지합니다. 갭 락은 범위 내에 특정 레코드가 존재하지 않을 때 적용됩니다. 트랜잭션이 특정 범위 내에서 데이터의 삽입을 막아 팬텀 읽기(Phantom Read) 현상을 방지합니다. 예를 들어, 인덱스 값 10과 20 사이의 갭을 잠그면 이 범위 내에 새로운 레코드 15를 추가할 수 없습니다.

-- id 1, 3, 5가 저장된 orders 테이블

-- 트랜잭션 A 시작
START TRANSACTION;

-- 트랜잭션 A 1-3과 3-5 사이의 갭과 3 레코드 락 설정(넥스트키 락)
SELECT * FROM orders WHERE orders_id BETWEEN 2 AND 4 FOR UPDATE;

-- 트랜잭션 B 시작
START TRANSACTION;

-- 트랜잭션 B가 id 4에 데이터 삽입 시도 시, 갭락으로 인해 삽입이 차단되어 대기
INSERT INTO orders (orders_id, orders_amount) VALUES (4, 200);
...

넥스트키 락(Next-Key Lock)이란?

넥스트키 락은 레코드 락과 갭락을 결합한 형태로, 특정 인덱스 레코드와 그 주변의 갭을 동시에 잠그는 락입니다. 이를 통해 레코드 자체의 변경과 함께 그 주변 공간의 변경도 동시에 제어할 수 있습니다.

넥스트키 락은 특정 레코드와 그 주변 공간을 잠그기 때문에, 다른 트랜잭션이 새로운 레코드를 삽입하여 팬텀 리드를 발생시키는 것을 방지합니다.

-- 트랜잭션 A 시작
START TRANSACTION;

-- 트랜잭션 A amount = 200인 orders_id = 2 레코드에 대한 레코드 락과 1-2, 2-3에 대한 갭락을 동시에 잠금으로써 넥스트키 락을 설정
SELECT * FROM orders WHERE orders_amount = 200 FOR UPDATE;

-- 트랜잭션 B 시작
START TRANSACTION;

-- 트랜잭션 B orders_id = 4, orders_amount = 200인 레코드 삽입 시도 시, 넥스트키 락으로 인해 차단되어 대기
INSERT INTO orders (orders_id, order_amount) VALUES (4, 200);
...

갭락과 넥스트키 락을 통한 팬텀 리드 방지 메커니즘

트랜잭션 A가 특정 범위의 데이터를 조회할 때, 해당 범위에 대해 갭락 또는 넥스트키 락을 설정합니다. 락이 설정된 범위 내에서는 트랜잭션 B가 새로운 레코드를 삽입하거나 기존 레코드를 수정하는 것이 차단됩니다. 따라서, 트랜잭션 A가 다시 동일한 조건으로 조회를 수행하더라도, 트랜잭션 B에 의해 새로운 데이터가 삽입되지 않아 팬텀 리드가 발생하지 않습니다.

추가 학습 자료를 제공합니다.

• MySQL - InnoDB Locking
• MySQL - Transaction Isolation Levels
• [MySQL] 스토리지 엔진 수준의 락의 종류(레코드 락, 갭 락, 넥스트 키 락, 자동 증가 락)

CORS(Cross Origin Resource Sharing)는 출처가 다른 곳의 리소스를 요청할 때 접근 권한을 부여하는 메커니즘입니다. 리소스를 주고받는 두 곳의 출처가 다르면 출처가 교차한다고 합니다. 이때 출처는 URL뿐만 아니라 프로토콜과 포트까지 포함됩니다. 만약 클라이언트의 출처가 허용되지 않았다면 CORS 에러가 발생할 수 있습니다.

CORS는 왜 필요한가요?

과거에는 크로스 사이트 요청 위조(CSRF, Cross-Site Request Forgery) 문제가 있었습니다. 피해자의 브라우저에서 다른 애플리케이션으로 가짜 클라이언트 요청을 전송하는 공격입니다.

CSRF를 예방하기 위해 브라우저는 동일 출처 정책(SOP, same-origin policy)을 구현했습니다. SOP가 구현된 브라우저는 클라이언트와 동일한 출처의 리소스로만 요청을 보낼 수 있습니다.

하지만, SOP는 한계가 있습니다. 현대의 웹 애플리케이션은 다른 출처의 리소스를 사용하는 경우가 많기 때문입니다. 따라서, SOP를 확장한 CORS가 필요합니다.

CORS는 어떻게 작동할까요? 🤔

브라우저가 요청 메시지에 Origin 헤더와 응답 메시지의 Access-Control-Allow-Origin 헤더를 비교해서 CORS를 위반하는지 확인합니다. 이때, Origin에는 현재 요청하는 클라이언트의 출처(프로토콜, 도메인, 포트)가, Access-Control-Allow-Origin은 리소스 요청을 허용하는 출처가 작성됩니다.

이렇게 단순하게 요청하는 것을 Simple Request라고 합니다. Simple Request은 요청 메서드(GET, POST, HEAD), 수동으로 설정한 요청 헤더(Accept, Accept-Language, Content-Language, Content-Type, Range), Content-Type 헤더(application/x-www-form-urlencoded, multipart/form-data, text/plain)인 경우에만 해당합니다.

브라우저가 사전 요청을 보내는 경우도 있습니다. 이때 사전 요청을 Preflight Request라고 합니다. 브라우저가 본 요청을 보내기 이전, Preflight Request를 OPTIONS 메서드로 요청을 보내어 실제 요청이 안전한지 확인합니다.

Preflight Request는 추가로 Access-Control-Request-Method로 실 요청 메서드와, Access-Control-Request-Headers 헤더에 실 요청의 추가 헤더 목록을 담아서 보내야 합니다.

이에 대한 응답은 대응되는 Access-Control-Allow-Methods와 Access-Control-Headers를 보내야 하고, Preflight Request로 인한 추가 요청을 줄이기 위해 캐시 기간을 Access-Control-Max-Age에 담아서 보내야 합니다.

또한 인증된 요청을 사용하는 방식도 있는데요. 이를 Credential Request라고 합니다. 쿠키나 토큰과 같은 인증 정보를 포함한 요청은 더욱 안전하게 처리되어야 합니다. 이때 Credential Request를 수행합니다.

Credential Request를 요청하는 경우에는 서버에서는 Access-Control-Allow-Credentials를 true로 설정해야 하며 Access-Control-Allow-Origin에 와일드카드를 사용하지 못합니다.

추가 학습 자료를 공유합니다.

• 토스페이먼츠 - CORS 대응하기
• MDN - 교차 출처 리소스 공유 (CORS)
• 테코블 - CORS란?

포워드 프록시(Forward Proxy)

포워드 프록시는 주로 클라이언트 측에 위치하여, 사용자가 인터넷에 접근할 때 중개자 역할을 합니다.

예를 들어, 회사 내부 네트워크에서 근무하는 직원이 외부 웹사이트에 접속하려고 할 때, 포워드 프록시 서버를 통해 요청이 전달됩니다. 이 과정에서 사용자의 실제 IP 주소는 숨겨지고, 프록시 서버의 IP 주소가 대신 사용됩니다.

포워드 프록시의 핵심 기능 중 하나는 익명성 제공입니다. 사용자의 실제 IP를 숨김으로써 개인정보 보호와 보안 측면에서 큰 장점을 제공합니다.

또한 캐싱을 통해 네트워크 성능을 향상시킵니다. 자주 요청되는 웹 페이지나 파일을 프록시 서버에 저장해두면, 동일한 요청이 다시 들어올 때 빠르게 응답할 수 있어 네트워크 대역폭을 절약할 수 있습니다.

이와 함께 보안 강화 기능도 포워드 프록시의 중요한 역할 중 하나입니다. 악성 웹사이트나 불법적인 콘텐츠에 대한 접근을 차단하여 네트워크 보안을 강화하고, 바이러스나 악성 코드의 유입을 예방할 수 있습니다.

리버스 프록시(Reverse Proxy)

리버스 프록시는 서버 측에 위치하여 외부에서 들어오는 클라이언트의 요청을 내부 서버로 전달하는 역할을 합니다.

리버스 프록시의 핵심 기능 중 하나는 로드 밸런싱입니다. 다수의 백엔드 서버로 트래픽을 분산시켜 서버 과부하를 방지하고, 서비스의 고가용성을 유지할 수 있습니다.

또한 외부에서 직접 백엔드 서버에 접근하지 못하게 하여 DDoS 공격이나 해킹 시도로부터 서버를 보호할 수 있습니다.

SSL 종료는 리버스 프록시의 또 다른 중요한 기능입니다. SSL/TLS 암호화를 리버스 프록시에서 처리함으로써 백엔드 서버의 부담을 줄이고, 중앙에서 인증서를 관리할 수 있습니다.

또한, 리버스 프록시는 캐싱 및 콘텐츠 최적화 기능을 통해 정적 콘텐츠를 캐싱하여 응답 속도를 향상시키고 서버 부하를 줄일 수 있습니다.

추가 학습 자료를 제공합니다.

• 포워드 프록시와 리버스 프록시
• Reverse Proxy / Forward Proxy 정의 & 차이 정리 - Inpa Dev ‍

기본적으로 @Transactional, @Cacheable, @Async 등의 애너테이션은 런타임에 동작하는 Spring AOP를 기반으로 동작합니다. Spring AOP가 제공하는 JDK Dynamic Proxy, CGLIB 방식 모두 타깃이 구현하는 인터페이스나 구체 클래스를 대상으로 프록시를 만들어서 타깃 클래스의 메서드 수행 전후에 횡단 관심사에 대한 처리를 할 수 있습니다.

Spring은 빈 생성시, 해당 빈에 AOP 애너테이션이 있는지 검사하고, 있다면 프록시 객체를 생성하여 빈을 대체합니다. AOP 적용 대상인 클래스의 경우, 즉, @Transactional과 같은 AOP 애너테이션이 하나라도 선언된 클래스는 프록시로 감싸집니다.

JDK Dynamic Proxy의 경우 타깃 클래스가 구현하는 인터페이스를 기준으로 프록시를 생성하여public 메서드만 AOP 적용 가능합니다. CGLIB 방식의 경우 인터페이스를 구현하지 않는 클래스를 상속하여 프록시를 생성하고, private을 제외한 public, protected, package-private 메서드에 AOP 적용 가능합니다.

@Slf4j  
@RequiredArgsConstructor  
@Service  
public class SelfInvocation {  
  
    private final MemberRepository memberRepository;  
  
    public void outerSaveWithPublic(Member member) {  
        saveWithPublic(member);  
    }  
  
    @Transactional  
    public void saveWithPublic(Member member) {  
        log.info("call saveWithPublic");  
        memberRepository.save(member);  
        throw new RuntimeException("rollback test");  
    }  
  
    public void outerSaveWithPrivate(Member member) {  
        saveWithPrivate(member);  
    }  
  
    @Transactional  
    private void saveWithPrivate(Member member) {  
        log.info("call saveWithPrivate");  
        memberRepository.save(member);  
        throw new RuntimeException("rollback test");  
    }  
}

public interface MemberRepository extends JpaRepository<Member, Long> {  
}

@SpringBootTest  
class SelfInvocationTest {  
  
    private static final Logger log = LoggerFactory.getLogger(SelfInvocationTest.class);  
  
    @Autowired  
    private SelfInvocation selfInvocation;  
  
    @Autowired  
    private MemberRepository memberRepository;  
  
    @AfterEach  
    void tearDown() {  
        memberRepository.deleteAllInBatch();  
    }  
  
    @Test  
    void aopProxyTest() {  
        // @Transactional 애너테이션을 가지고 있으므로, 빈이 Proxy 객체로 대체되어 주입된다.  
        assertThat(AopUtils.isAopProxy(selfInvocation)).isTrue();  
        // interface를 구현하지 않은 클래스이므로 CGLIB Proxy가 생성된다.  
        assertThat(AopUtils.isCglibProxy(selfInvocation)).isTrue();  
    }  
  
    @Test  
    void outerSaveWithPublic() {  
        Member member = new Member("test");  
  
        try {  
            selfInvocation.outerSaveWithPublic(member);  
        } catch (RuntimeException e) {  
            log.info("catch exception");  
        }  
  
        List<Member> members = memberRepository.findAll();  
        // self invocation 문제로 인해 트랜잭션이 정상 동작하지 않음.  
        // 예외 발생으로 인한 롤백이 동작하지 않고 남아있음.
    
      assertThat(members).hasSize(1);  
    }  
  
    @Test  
    void outerSaveWithPrivate() {  
        try {  
            selfInvocation.outerSaveWithPrivate(new Member("test"));  
        } catch (RuntimeException e) {  
            log.info("catch exception");  
        }  
  
        List<Member> members = memberRepository.findAll();  
  
        // self invocation 문제로 인해 트랜잭션이 정상 동작하지 않음.  
        // 예외 발생으로 인한 롤백이 동작하지 않고 남아있음.        assertThat(members).hasSize(1);  
    }  
  
    @Test  
    void saveWithPublic() {  
        Member member = new Member("test");  
  
        try {  
            selfInvocation.saveWithPublic(member);  
        } catch (RuntimeException e) {  
            log.info("catch exception");  
        }  
  
        List<Member> members = memberRepository.findAll();  
  
        // 외부에서 프록시 객체를 통해 메서드가 호출되었기 때문에 트랜잭션 정상 동작, 롤백 성공.  
        assertThat(members).hasSize(0);  
    }  
}

Spring AOP는 외부에서 프록시 객체를 통해 메서드가 호출될 때만 AOP 어드바이스(트랜잭션 관리)를 적용합니다. 같은 클래스 내에서 메서드를 호출하면, 프록시를 거치지 않고 직접 호출되므로 트랜잭션 어드바이스가 적용되지 않습니다.

이를 해결하기 위해서는 자기 자신을 프록시로 주입 받아 프록시를 통해 메서드를 호출하거나, 별도의 클래스로 분리하거나, AspectJ를 이용하는 방법이 있습니다. AspectJ를 사용하면 동일 클래스 내에서의 메서드 호출에도 AOP 어드바이스를 적용할 수 있습니다.

자기 자신을 프록시로 주입 받는 방법

@Slf4j  
@RequiredArgsConstructor  
@Service  
public class SelfInvocation {  
  
    private final MemberRepository memberRepository;  
    private final SelfInvocation selfInvocation;  
  
    public void outerSaveWithPublic(Member member) {  
        selfInvocation.saveWithPublic(member);  
    }  
  
    @Transactional  
    public void saveWithPublic(Member member) {  
        log.info("call saveWithPublic");  
        memberRepository.save(member);  
        throw new RuntimeException("rollback test");  
    }
    ...
}

이 방법은 순환 의존성 문제를 일으킬 수 있어 권장되지 않습니다.

별도의 클래스로 분리하는 방법

@Slf4j  
@RequiredArgsConstructor  
@Service  
public class TransactionService {  
  
    @Transactional  
    public void outer() {  
        log.info("call outer");  
        logCurrentTransactionName();  
        logActualTransactionActive();  
        inner();  
    }  
  
    @Transactional(propagation = Propagation.REQUIRES_NEW)  
    public void inner() {  
        log.info("call inner");  
        logCurrentTransactionName();  
        logActualTransactionActive();  
    }  
  
    private void logActualTransactionActive() {  
        boolean actualTransactionActive = TransactionSynchronizationManager.isActualTransactionActive();  
        log.info("actualTransactionActive = {}", actualTransactionActive);  
    }  
  
    private void logCurrentTransactionName() {  
        String currentTransactionName = TransactionSynchronizationManager.getCurrentTransactionName();  
        log.info("currentTransactionName = {}", currentTransactionName);  
    }  
}

// 로그
// call outer  
// currentTransactionName = server.transaction.TransactionService.outer  
// actualTransactionActive = true  
// call inner  
// currentTransactionName = server.transaction.TransactionService.outer  
// actualTransactionActive = true

outer가 inner 메서드를 호출하는데, outer의 propagation 속성은 REQUIRED, inner는 REQUIRES_NEW로 서로 다른 트랜잭션으로 분리되어야 합니다. 하지만, 로그를 보면 동일한 outer의 트랜잭션에 속해있습니다. 이처럼 트랜잭션 전파 속성이 다른 두 메서드가 동일한 클래스 내부에서 self invocation 호출하면 의도대로 동작하지 않습니다. 이 때 outer와 inner 메서드를 각각 다른 클래스로 분리하여 호출하면 해결할 수 있습니다.

// OuterTransactionService
@Slf4j  
@RequiredArgsConstructor  
@Service  
public class OuterTransactionService {  
  
    private final InnerTransactionService innerTransactionService;  
  
    @Transactional  
    public void outer() {  
        log.info("call outer");  
        logCurrentTransactionName();  
        logActualTransactionActive();  
        innerTransactionService.inner();  
    }  
  
    private void logActualTransactionActive() {  
        boolean actualTransactionActive = TransactionSynchronizationManager.isActualTransactionActive();  
        log.info("actualTransactionActive = {}", actualTransactionActive);  
    }  
  
    private void logCurrentTransactionName() {  
        String currentTransactionName = TransactionSynchronizationManager.getCurrentTransactionName();  
        log.info("currentTransactionName = {}", currentTransactionName);  
    }  
}

// InnerTransactionService
@Slf4j  
@RequiredArgsConstructor  
@Service  
public class InnerTransactionService {  
  
    @Transactional(propagation = Propagation.REQUIRES_NEW)  
    public void inner() {  
        log.info("call inner");  
        logCurrentTransactionName();  
        logActualTransactionActive();  
    }  
  
    private void logActualTransactionActive() {  
        boolean actualTransactionActive = TransactionSynchronizationManager.isActualTransactionActive();  
        log.info("actualTransactionActive = {}", actualTransactionActive);  
    }  
  
    private void logCurrentTransactionName() {  
        String currentTransactionName = TransactionSynchronizationManager.getCurrentTransactionName();  
        log.info("currentTransactionName = {}", currentTransactionName);  
    }  
}

// 로그
// call outer  
// currentTransactionName = server.transaction.OuterTransactionService.outer  
// actualTransactionActive = true  
// call inner  
// currentTransactionName = server.transaction.InnerTransactionService.inner  
// actualTransactionActive = true

이처럼 각각 프록시를 생성할 수 있게 두 클래스로 분리하면 AOP 어드바이스가 적용되어 의도한 대로 독립적인 트랜잭션을 시작할 수 있게 됐습니다.

추가 학습 자료를 제공합니다.

• Spring - Proxying Mechanisms
• Spring - Programmatic Transaction Management
• 테코블 - AOP에 대한 사실과 오해 그런데 트랜잭션을 사알짝 곁들인..

Connection Timeout은 클라이언트가 서버에 연결을 시도할 때, 일정 시간 내에 연결이 이루어지지 않으면 발생하는 타임아웃입니다. TCP 소켓 통신에서 클라이언트와 서버가 연결될 때, 정확한 전송을 보장하기 위해 사전에 세션을 수립하는데, 이 과정을 3-way-handshake라고 합니다. Connection Timeout은 이 3-way-handshake가 일정 시간 내에 완료되지 않을 때 발생합니다. 즉, 서버의 장애나 응답 지연으로 인해 연결을 맺지 못하면 Connection Timeout이 발생합니다.

Socket Timeout은 Connection Timeout 이후에 발생할 수 있는 타임아웃입니다. 클라이언트와 서버가 연결된 후, 서버는 데이터를 클라이언트에게 전송합니다. 이때 하나의 데이터 덩어리가 아니라 여러 개의 패킷 단위로 쪼개서 전송되는데, 각 패킷이 전송될 때의 시간 차이 제한을 Socket Timeout이라고 합니다. 만약 서버가 일정 시간 내에 다음 패킷을 보내지 않으면, 클라이언트는 Socket Timeout을 발생시키고 연결을 종료할 수 있습니다.

Read Timeout은 클라이언트와 서버가 연결된 후, 특정 I/O 작업이 일정 시간 내에 완료되지 않으면 발생하는 타임아웃입니다. 클라이언트와 서버가 연결된 상태에서, 서버의 응답이 지연되거나 I/O 작업이 길어져 요청이 처리되지 않을 때 클라이언트는 연결을 끊습니다. Read Timeout은 이러한 상황을 방지하기 위해 설정된 타임아웃으로, 일정 시간 내에 데이터가 읽혀지지 않으면 클라이언트가 연결을 종료합니다.

네트워크 통신에 타임아웃이 필요한 이유는 무엇인가요?

타임아웃이 필요한 이유는 자원을 절약하기 위함입니다. 가령, 외부 서비스로 요청을 보냈지만 해당 요청이 무한정 길어질 수 있습니다. 이때 서비스의 요청이 자원을 가지고 있으면, 서비스의 자원이 고갈되어 장애가 발생할 수 있습니다. 타임아웃을 설정하면 이렇게 요청이 무한정 길어지는 상황을 예방할 수 있습니다.

타임아웃 테스트는 어떻게 해볼 수 있을까요? 🤔

그리고, 정말로 필요할까요?

가상 서버를 띄우고 임의로 지연을 추가하여 타임아웃을 테스트할 수 있습니다. 하지만, 테스트 환경을 구축하기 위한 시간이 들며 자동화된 테스트에 지연 시간이 추가되는 것이 단점입니다. 타임아웃 설정을 테스트하여 얻을 수 있는 것과 테스트를 하기 위해서 잃어야 하는 것을 신중히 고려하여 필요성을 따지는 것이 중요하다고 생각합니다.

추가 학습 자료를 공유합니다.

• 토스페이먼츠 - 타임아웃
• 성공/실패를 단언할 수 없는 네트워크 에러 안전하게 다루기

서버 사이드 렌더링(SSR) 은 서버 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS 코드를 응답합니다. 브라우저에서는 JS 코드를 다운로드하고, HTML에 JS를 연결합니다.

이처럼 모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달되기 때문에 SEO에 유리합니다. 또한 JS 코드를 다운로드 받고 실행하기 전에 사용자가 이미 렌더링된 HTML을 볼 수 있으므로, JS 다운로드를 기다려야 하는 CSR에 비해 초기 구동 속도가 빠릅니다.

클라이언트 사이드 렌더링(CSR) 은 클라이언트 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 빈 뼈대만 있는 HTML을 응답합니다. 클라이언트는 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드 받은 뒤, JS를 통해 동적으로 페이지를 만들어 브라우저에 보여줍니다.

빈 뼈대만 있는 HTML을 받아오기 때문에 웹 크롤러 봇 입장에서 색인할만한 콘텐츠가 존재하지 않아 SEO에 불리하다는 단점이 있습니다. 또 브라우저가 JS 파일을 다운로드하고, 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다는 단점이 존재합니다. 하지만 초기 로딩 이후 페이지 일부를 변경할 때에는 서버에 해당 데이터만 요청하면 되기 때문에 이후 구동 속도가 빠릅니다. 서버는 HTML 뼈대를 넘겨주는 역할만 수행하면 되므로 서버 측의 부하가 적고, 클라이언트 측에서 연산과 라우팅 등을 직접 처리하기 때문에 반응속도가 빠르고 UX도 우수하다는 장점이 있습니다.

추가 학습 자료를 공유합니다.

• 타미의 CSR과 SSR
• CSR, SSR, SPA, MPA? 상사한테 혼나기 전에 알아야하는 것

스택(Stack) 은 후입선출이라는 개념을 가진 선형 자료구조입니다. 스택 자료구조에서 삭제(pop)는 가장 최상단(top)에서만 이루어집니다. 비어있는 스택에서 값을 추출하려고 시도하는 경우를 스택 언더플로우라고 하며, 스택이 넘치는 경우를 스택 오버플로우라고 합니다. 대표적인 활용 사례는 스택 메모리, 브라우저 뒤로가기 기능, 언두 기능, 수식 괄호 검사 등이 있습니다.

자바에서 스택은 어떻게 사용할 수 있나요?

Stack이라는 클래스를 사용할 수 있습니다. 하지만, Deque 인터페이스 구현체를 사용하는 것이 권장됩니다. 왜냐하면, Stack 클래스는 내부적으로 Vector를 상속 받고 있기 때문입니다. Vector를 상속받은 Stack은 인덱스를 통한 접근, 삽입, 제거 등이 실질적으로 가능합니다. 이는 후입선출 특징에 맞지 않기 때문에 개발자가 실수할 여지가 있습니다.

또한, Vector의 메소드들은 synchronized로 구현되어 있어 멀티 스레드 환경에서는 동기화의 이점이 있으나, 단일 스레드 환경에서는 불필요한 동기화 작업으로 인해 성능 측면에서 좋지 않습니다. 반면에, Deque 인터페이스는 후입선출의 특성을 완전히 유지하면서도 동기화 작업을 가지는 구현체와 그렇지 않은 구현체를 선택할 수 있습니다. 이는 개발자가 필요에 따라 동기화 작업의 오버헤드를 회피하고 성능을 최적화할 수 있도록 합니다.

추가 학습 자료를 공유합니다.

• Java 의 Stack 대신 Deque

웹 서버는 정적 컨텐츠(HTML, CSS, JS, 이미지 등)를 제공하는 역할을 수행합니다. 동적 컨텐츠 요청 시 요청을 WAS로 전달할 수도 있습니다. 대표적인 웹 서버로는 Apache, Nginx 등이 있습니다. 반면, 자바 진영에서 WAS(Web Application Server) 는 서블릿 컨테이너 기능을 제공하고, 동적 컨텐츠를 생성하거나, 애플리케이션 로직을 실행하는 데 특화되어 있습니다. 대표적인 WAS로는 Tomcat이 있습니다. 정리하자면, 웹 서버는 정적 컨텐츠 제공에 특화되어 있으며, WAS는 동적인 컨텐츠 생성과 데이터 처리에 특화되어 있습니다.

WAS도 정적 컨텐츠를 제공할 수 있는데 웹 서버가 따로 필요한 이유는 무엇인가요? 🤔

WAS가 너무 많은 역할을 담당하면 과부하될 수 있습니다. 웹 서버를 따로 분리하면 WAS는 중요한 애플리케이션 로직에 집중할 수 있으며, 웹 서버는 정적 리소스를 처리하면서 업무 분담이 가능합니다. 또한, 시스템 리소스를 효율적으로 관리할 수 있습니다. 정적 컨텐츠가 많이 사용되는 경우에는 웹 서버를 증설하고, 애플리케이션 자원이 많이 사용되면 WAS를 증설하면 됩니다. 이외에도 로드 밸런싱을 하거나, 캐싱 및 압축, HTTPS 등을 웹 서버에서 처리하도록 할 수 있습니다.

추가 학습 자료를 공유합니다.

• 웹 서버와 WAS(Web Application Server)
• [10분 테코톡] 👩‍🦰희봉의 웹서버 vs WAS

HTTP(Hypertext Transfer Protocol) 는 웹에서 클라이언트와 서버 간 통신을 위한 통신 규약입니다. 하지만, HTTP는 암호화되지 않는 평문 데이터를 전송하기 때문에 제 3자가 정보를 조회할 수 있다는 위험이 있습니다. 이를 해결하기 위해서 HTTPS가 등장했습니다.

HTTPS(Hyertext Transfer Protocol Secure) 는 HTTP에 데이터 암호화가 추가되었습니다. 암호화된 데이터를 전송하기 때문에 제 3자가 볼 수 없도록 할 수 있습니다.

HTTPS는 어떻게 적용할 수 있나요?

HTTPS를 적용하기 위해서는 인증된 기관(Certificate Authority, CA)에게 인증서를 발급받아야 합니다. CA에 인증서를 요청하면 CA 이름, 서버의 공개키, 서버의 정보를 활용하여 인증서를 생성하고 이를 CA 개인 키로 암호화하여 서버로 전송합니다. 이때 인증서는 CA 개인 키로 암호화되니 신뢰성을 확보할 수 있습니다. 이러한 인증서를 서버측에서 발급받으면 HTTPS를 적용할 수 있습니다.

HTTPS 동작 원리에 관해서 설명해 주세요. 🤔

클라이언트가 서버로 최초로 요청할 때 암호화 알고리즘, 프로토콜 버전, 무작위 값을 전달합니다. 이를 받은 서버는 클라이언트에게 암호화 알고리즘, 인증서, 무작위 값을 전달하며, 클라이언트는 서버의 인증서를 CA의 공개키로 복호화하여 검증합니다. 검증이 끝난 이후에는 클라이언트와 서버에서 생성된 무작위 값을 조합하여 Pre Master Secret 값을 생성하여 서버 공개키로 암호화하여 전달합니다.

서버는 전달받은 암호화된 데이터를 개인 키로 복호화하여 Pre Master Secret를 얻습니다. 클라이언트와 서버는 일련의 과정을 통해 Pre Master Secret를 Master Secret으로 변경하고, 해당 정보를 이용해 세션 키를 생성합니다. 이러한 과정을 TLS 핸드 쉐이크라고 하며, 이후부터 클라이언트와 서버는 세션 키를 활용한 대칭키 암호화 방식으로 데이터 송수신을 수행합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 리니의 HTTPS
• 생활코딩 암호학 시리즈

Record는 Java 16에서 정식 출시된 특별한 유형의 클래스로 불변성(Immutable) 을 기본으로 합니다.

기존의 클래스와 달리 모든 필드가 final 키워드로 선언되며, 객체 생성 후 변경할 수 없습니다. 또한 필드 선언만으로 자동으로 생성자, getter, equals(), hashCode(), toString() 등 메서드를 자동으로 생성해 주어 보일러 플레이트 코드를 줄일 수 있습니다. 이러한 특성으로 인해 멀티 스레드 환경에서 데이터가 의도치 않게 변경되지 않고 안전하게 전달할 수 있습니다.

// 기존 클래스 기반 DTO
public class MemberDto {

	private final String name;
	private final String email;
	private final int age;

	public MemberDto(String name, String email, int age) {
		this.name = name;
		this.email = email;
		this.age = age;
	}

	public String getName() {
		return name;
	}
	
	public String getEamil() {
		return email;
	}
	
	public int getAge() {
		return age;
	}
}

// Record. 생성자, getter, hashCode(), equals(), toString() 자동 완성
public record MemberDto(String name, String email, int age) {}

그럼 Record로 생성한 모든 객체는 DTO인가요?

모든 Record 객체가 DTO인 것은 아닙니다. Record는 단순히 데이터를 캡슐화하는 역할을 하는데, DTO 외에도 값 객체(Value Objects) 등의 다양한 용도로 사용될 수 있습니다.

// 값 객체로 사용
public record Coordinates(double x, double y) {}

DTO는 계층 간 데이터 전송을 목적으로 하는 객체인 반면, VO는 도메인 모델 내에서 특정 값을 표현하는 객체로 사용됩니다. 따라서, Record는 이 두 가지 모두에 적합하게 사용할 수 있지만, 그 목적에 따라 사용 방법이 달라집니다.

Record와 VO를 비교해주세요

Record와 VO는 모두 객체의 상태가 변경되지 않는 것을 보장합니다. 또 데이터를 캡슐화하여 표현하는 데 초점을 맞춥니다. 마지막으로 VO는 값 기반의 동등성을 가지며, Record도 동일한 필드 값을 가지면 동일한 객체로 간주된다는 점이 공통점입니다.

VO는 도메인 모델내에서 특정 개념을 표현하고, 도메인 로직과 밀접하게 관련이 있습니다. 즉, VO는 비즈니스 로직이나 규칙을 가질 수 있습니다. 반면에 Record는 단순히 데이터를 캡슐화하여 전달하는데 의미가 있습니다.

결론적으로 Record는 VO를 구현하는 데 적합하지만, VO의 모든 특성을 완벽히 대체하지는 않습니다. VO는 더 넓은 도메인 맥락에서 사용되며, 비즈니스 로직을 포함할 수 있습니다.

Record의 한계는 뭐가 있을까요?

Record는 extends를 사용하여 다른 클래스를 상속할 수 없고, 필드가 final로 선언되기 때문에 확장이 어렵습니다. 또 주로 데이터를 전달하려는 목적으로 설계되었기 때문에 비즈니스 로직을 포함하기에 적절하지 않습니다. 마지막으로 Java 14 또는 16 이전 버전에서 호환이 불가능하다는 점이 있습니다.

추가 학습 자료를 제공합니다.

• 자바 DTO vs Record, 무엇을 사용해야 할까?
• Java의 레코드 - 전체 튜토리얼 - 사용하지 않는 최고의 새로운 Java 기능
• [10분 테코톡] 타칸의 Record
• [10분 테코톡] 🎼라흐의 DTO vs VO

DB Replication은 데이터베이스의 고가용성과 데이터 안정성을 보장하기 위해 널리 활용되는 핵심 기술입니다. 특히, 대규모 애플리케이션 환경에서는 데이터의 지속적인 가용성과 신뢰성이 매우 중요하기 때문에, 원본(Source) 서버와 복제(Replica) 서버 간의 데이터 동기화는 필수입니다. MySQL 기준으로 설명하겠습니다.

바이너리 로그(Binary log)를 저장하는 방식은?

Replication은 Source 서버에서 발생하는 모든 데이터 변경 사항을 Replica 서버로 복제하여 두 서버 간의 데이터 일관성을 유지하는 메커니즘입니다. 이러한 과정은 주로 Binary log를 기반으로 이루어지며, Binary log는 Source 서버에서 실행된 모든 데이터 변경 쿼리를 기록하는 역할을 합니다. MySQL에서는 이 Binary log를 저장하는 방식으로 Row, Statement, Mixed의 세 가지 방식을 제공하며, 각 방식은 고유한 장단점을 가지고 있습니다.

Row

Row 방식은 데이터베이스의 각 행별로 변경된 내용을 정확히 기록합니다. 이 방식은 데이터 일관성을 매우 높게 유지할 수 있다는 큰 장점이 있습니다. 예를 들어, 특정 행이 수정되었을 때 그 행의 이전 상태와 변경된 상태를 모두 기록하므로, 복제 서버에서도 원본 서버와 동일한 데이터 상태를 유지할 수 있습니다. 그러나 모든 행의 변경 사항을 저장하기 때문에 Binary log 파일의 크기가 급격히 증가할 수 있어 저장 공간에 부담을 줄 수 있는 단점이 존재합니다.

Statement

반면에 Statement 방식은 데이터 변경을 일으킨 SQL 문 자체를 Binary log에 기록합니다. 이 방식은 로그 파일의 크기를 상대적으로 작게 유지할 수 있어 저장 공간을 절약할 수 있는 장점이 있습니다. 하지만 실행할 때마다 다른 값을 반환하는 함수와 같이 비확정적(non-deterministic) SQL 쿼리가 실행될 경우, 동일한 쿼리가 Source와 Replica 서버에서 다른 결과를 초래할 수 있어 데이터 불일치 문제가 발생할 수 있습니다. 예를 들어, SELECT NOW()와 같은 함수는 실행 시점에 따라 다른 결과를 반환할 수 있기 때문에, 이를 포함한 쿼리는 복제 시 문제가 될 수 있습니다.

Mixed

이러한 문제를 보완하기 위해 MySQL은 Mixed 방식을 제공합니다. Mixed 방식은 상황에 따라 row 기반과 statement 기반을 혼합하여 로그를 기록합니다. 비확정적 SQL이 아닌 경우에는 statement 방식을 사용하여 저장 공간을 절약하고, 비확정적 SQL이 실행되는 경우에는 row 방식을 사용하여 데이터 일관성을 유지합니다. 이를 통해 두 방식의 장점을 모두 활용할 수 있으며, 데이터 불일치 문제를 최소화할 수 있습니다. 다만, 구현이 다소 복잡할 수 있다는 단점이 존재합니다.

복제 과정

Source 서버에서 데이터 변경 쿼리가 실행되고, 선택된 로그 저장 방식에 따라 Binary log에 기록된 후, Replica 서버의 IO Thread가 Binary log를 읽어와 Replica 서버의 Relay log로 전송합니다. Relay log는 Replica 서버에서 Source 서버의 Binary log를 저장하는 임시 저장소 역할을 하며, 이곳에 저장된 로그를 기반으로 Replica 서버의 SQL 스레드가 실제 데이터베이스에 변경 사항을 적용합니다. 이 과정은 매우 효율적으로 설계되어 일반적으로 약 100밀리초 이내에 데이터 동기화가 완료됩니다. 이러한 빠른 동기화 속도 덕분에 원본과 복제 서버 간의 데이터 일관성이 실시간에 가깝게 유지될 수 있습니다.

SOLID 원칙은 객체지향 설계 5원칙이라고도 불리며, 각 원칙의 앞 글자를 따서 만들어졌습니다. 객체지향설계의 핵심 중 하나는 의존성을 관리하는 것인데요. 의존성을 잘 관리하기 위해서는 SOLID 원칙을 준수해야 합니다.

단일 책임 원칙(Single Responsibilty Principle) 은 클래스가 오직 하나의 목적이나 이유로만 변경되어야 한다는 것을 강조합니다. 여기서 “책임”이란 단순히 메서드의 개수를 뜻하지 않고, 특정 사용자나 기능 요구사항에 따라 소프트웨어의 변경 요청을 처리하는 역할을 의미합니다.

즉, 클래스는 한 가지 변화의 이유만 가져야 하며, 이를 통해 변경이 발생했을 때 다른 기능에 영향을 덜 미치도록 설계됩니다. 이렇게 하면 유지보수가 쉬워지고 코드가 더 이해하기 쉬워집니다.

개방 폐쇄 원칙(Open-Closed Principle) 은 확장에는 열려있고, 변경에는 닫혀 있어야 함을 강조합니다. 이때 확장이란 새로운 타입을 추가함으로써 새로운 기능을 추가하는 것을 의미하며, 폐쇄란 확장이 일어날 때 상위 레벨의 모듈이 영향을 받지 않아야 함을 의미합니다. 이를 통해서 모듈의 행동을 쉽게 변경할 수 있습니다. 모듈이란 크기와 상관없이 클래스, 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미합니다.

리스코브 치환 원칙(Liskov Substitution Principle) 은 서브 타입은 언제나 상위 타입으로 교체할 수 있어야 합니다. 즉, 서브 타입은 상위 타입이 약속한 규약을 지켜야 함을 강조합니다. 이 원칙은 부모 쪽으로 업 캐스팅하는 것이 안전함을 보장하기 위해 존재합니다. 상위 타입에 대해 기대되는 역할과 행동 규약이 있는데 이를 벗어나면 안 됩니다. 만약, 하위 타입이 상위 타입에 기대되는 역할을 만족하지 않는다면, 상위 타입을 사용하는 클라이언트 코드에서는 하위 타입이 누구인지 물어봐야 하는데, 이는 OCP를 달성하기 어렵게 합니다. LSP를 위반하는 대표적인 사례로는 Rectangle 예제가 있습니다.

인터페이스 분리 원칙(Interface Segregation Principle) 은 클라이언트 입장에서 인터페이스를 분리해야 함을 강조합니다. 사용하지 않지만 의존성을 가지고 있다면 해당 인터페이스가 변경되는 경우 영향을 받습니다. 따라서, 독립적인 개발과 배포가 불가합니다. 사용하는 기능만 제공하도록 인터페이스를 분리해 변경의 여파를 최소화할 수 있습니다.

의존성 역전 원칙(Dependency Inversion Principle) 은 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 되며, 모두 추상화에 의존해야 함을 강조합니다. SOLID는 서로 연관이 있는데요. 의존성 역전 원칙을 통해서 하위 레벨의 모듈은 개방 폐쇄 원칙을 준수하면서 새로운 타입이 추가 가능합니다.

앞으로 어떤 확장이 필요한지 완벽히 알아야 OCP를 제대로 할 수 있는 거 아닌가요? 🤔

그런데.. 소프트웨어에 어떤 기능을 추가하고 변경할지 예측이 어렵지 않나요?

변경을 예상하고, 준비하지 말고 고객이 원한 것만 만들어서 빨리 전달하고 피드백을 수용하는 방법을 사용해 볼 수 있습니다. 변화에 대한 가장 좋은 예측은 변화를 경험하는 것이라고 생각합니다. 발생할 것 같은 변화를 발견한다면 향후 해당 변화와 같은 종류의 변화로부터 코드를 보호할 수 있습니다. 즉, 고객이 요구할 모든 종류의 변경을 완벽하게 예측하고, 이에 대한 변경에 대응하기 위해 추상화를 적용하는 대신에 고객이 변경을 요구할 때까지 기다리고 추상화를 만들어서 향후 추가로 재발하는 변화로부터 보호될 수 있도록 하는 것입니다. 이때 OCP를 준수하도록 코드를 작성할 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 클로버의 SOLID
• 백명석님 클린 코더스 - SOLID Foundation

다중 서버 환경에서 세션 기반 인증 방식을 사용하는 경우에는 세션 불일치 문제가 발생할 수 있습니다. 만약 서버 A, B를 관리하고 있을 때, 로드밸런서는 사용자의 요청을 상황에 맞게 A, B 중 한 곳으로 전달합니다. 유효한 로그인 요청이 A 서버로 처음 도착하면 사용자에 대한 세션 정보는 A 서버에 저장됩니다. 이후에 해당 사용자의 또 다른 요청이 로드 밸런서에 도착했을 때, B 서버로 도착하게 되면 사용자의 세션 데이터가 존재하지 않기 때문에 요청이 제대로 처리되지 않습니다. 이를 세션 불일치 문제라고 합니다.

세션 불일치 문제는 어떻게 해결할 수 있나요? 🤔

세션 불일치 문제는 크게 3가지 방식으로 해결할 수 있습니다. 스티키 세션 방식, 세션 클러스터링 방식, 스토리지 분리 방식입니다.

각 방식에 대한 설명과 장단점을 말해주세요. 😀

스티키 세션 방식은 사용자 요청이 항상 사용자 세션 정보가 저장된 서버로 가도록 고정하는 방식입니다. 사용자 요청의 쿠키나 IP를 통해서 어느 서버로 고정 시킬지 결정합니다. 해당 방식은 단순하다는 장점이 존재합니다. 반면, 특정 서버에 트래픽이 집중될 수 있다는 문제점과 사용자의 세션 정보를 가지고 있는 서버가 다운되면 해당 서버에 고정된 사용자는 다시 로그인해야하는 문제점이 존재합니다.

세션 클러스터링 방식은 특정 서버에 사용자 세션 정보가 생성될 때, 다른 서버로 정보를 복제하는 방식입니다. 여러 서버에 세션 정보를 중복으로 저장하므로 스티키 세션의 트래픽 몰림 현상과 세션 정보 유실 문제를 해결한다는 장점이 있습니다. 반면, 세션 정보를 중복 저장한다는 점에서 메모리를 비효율적으로 사용하며, 세션 정보 복제 과정에서 발생하는 네트워크 트래픽 문제, 세션 정보 복제 지연으로 인한 일시적인 세션 정보 유실 문제가 발생할 수 있습니다.

스토리지 분리 방식은 세션 정보를 저장하는 공간을 외부로 분리하는 방식입니다. 세션 클러스터링 방식, 스티키 세션 방식에서 발생하는 문제를 해결할 수 있습니다. 해당 방식은 스토리지에 대한 단일 장애 지점(Single Point Of Failure)이 문제가 될 수 있으며, 클러스터링과 같은 HA 구성으로 단일 장애 지점을 해소하여도 복제 지연으로 인한 일시적인 세션 정보 유실 문제는 발생할 수 있습니다. 또한, 외부 스토리지를 관리하기 위한 추가적인 리소스가 요구될 수 있습니다.

추가 학습 자료를 공유합니다.

• 개발바닥 - 호돌맨의 창의력 쑥쑥 문제 2
• 다중 서버 환경에서의 세션 불일치 문제와 해결방법

로드 밸런싱이란 애플리케이션을 지원하는 리소스 풀에 들어오는 네트워크 트래픽(들어오는 요청)을 균등하게 분산하는 것을 의미합니다. 이를 수행하는 로드 밸런서는 애플리케이션 서버 앞단에 위치하며 클라이언트 요청을 지시하고 제어합니다. 이를 통해서 애플리케이션의 가용성, 확장성, 보안 및 성능을 확보할 수 있습니다.

알고 계신 로드 밸런싱 알고리즘이 존재하나요? 🤔

각 방식을 설명해 주세요. 필요하시면 화이트보드를 사용해 주셔도 좋습니다. 😀

라운드 로빈(Round Robin) 방식은 모든 요청이 순서대로 처리되는 방식입니다. 서버가 3대(A, B, C)가 존재하면 요청은 ABCABC 순서대로 전달됩니다. 모든 서버의 처리 능력이 동등하고, 요청의 고른 분산이 중요한 경우 고려해볼 수 있습니다. 구현이 쉬우며 고른 분산을 보장한다는 것이 장점입니다. 하지만, 서버 부하나 응답 시간을 고려하지 않고 서버의 처리 능력이 다른 경우 비효율적이라는 것이 단점입니다.

가중치 라운드 로빈(Weighted Round Robin) 방식은 라운드 로빈 방식에 가중치라는 개념을 추가합니다. 각 서버는 처리 능력과 가용 자원에 따라서 가중치를 할당 받게 됩니다. 그리고, 라운드 로빈 방식을 사용하되 가중치가 높은 서버는 가중치에 비례하여 상대적으로 더욱 많은 요청을 받게 됩니다.

라운드 로빈보다 상대적으로 구현이 복잡하지만 각 서버의 처리 능력을 고려하지 않는다는 라운드 로빈 방식의 단점을 개선합니다. 하지만, 여전히 서버의 상태를 고려하지 않는 방식이라는 점을 유의해야합니다.

최소 연결(Least Connections) 방식은 각 서버의 활성 연결 수를 모니터링하고 있는 경우에 사용할 수 있습니다. 가장 적은 활성 연결이 존재하는 서버에게 요청을 전달하는 방식입니다. 각 서버의 처리 능력이 다른 경우에는 적합하지 않을 수 있습니다. 처리 능력이 큰 서버는 상대적으로 활성 연결을 더욱 많이 수립할 수 있기 때문입니다. 최소 연결 방식은 각 서버의 처리 능력이 비슷하지만 특정 이유로 한 서버에 동시 연결 수가 많아 지는 상황이 존재하는 경우 고려해볼 수 있습니다.

로드 밸런싱 대상에 상대적으로 처리 능력이 큰 서버가 존재하는 경우에는 라운드 로빈과 마찬가지로 가중치라는 개념을 사용해볼 수 있습니다. 이를 가중치 최소 연결(Weighted Least Connections) 방식이라고 합니다.

최소 응답 시간(Least Response Time) 방식은 각 서버의 응답 시간을 모니터링하고 있는 경우에 사용할 수 있습니다. 응답 시간이 가장 빠른 서버에 요청을 전달하는 방식입니다. 서버들마다 응답 시간이 다양할 경우, 가장 빠른 서버에 요청을 전달하여 사용자 경험을 개선하는데 도움이 될 수 있습니다. 응답 시간을 기반으로 하기 때문에 서버의 부하 상태, 활성 연결 수와 같은 다른 요소들을 고려해야하는 경우에는 적합하지 않을 수 있습니다.

IP 해시 방식은 클라이언트 요청의 IP를 기반으로 요청을 전달합니다. IP를 이용해 구한 해시값을 기반으로 요청을 전달할 서버를 결정합니다. IP 해시 방식은 클라이언트와 서버 간의 친화성 유지에 초점을 맞춘 방식으로 클라이언트의 상태에 관리에 용이하다는 장점이 있습니다. 하지만, 상황에 따라서 부하가 균등하게 이루어지지 않는다는 단점이 존재합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡]🐿 제이미의 Forward Proxy, Reverse Proxy, Load Balancer
• System Design Basics - Load Balancing Algorithms
• AWS - 로드 밸런싱이란 무엇인가요?

동시성(Concurrency)이란?

동시성이란 이름처럼 실제로 여러 작업을 동시에 수행하는 것이 아니라, 논리적으로 동시에 실행되는 것처럼 보이게 만드는 개념입니다. 단일 코어를 기준으로 시간 분할을 통해 여러 스레드를 번갈아 가며 작업을 수행함으로써, 마치 동시에 여러 작업이 처리되는 것처럼 보이게 합니다.

사용자의 입력을 기다리거나, 네트워크 요청, 파일 입출력 등의 I/O 작업 시에는 CPU가 유휴 상태로 대기하게 됩니다. 이때 CPU가 아무 일도 하지 않고 대기하는 대신, 컨텍스트 스위칭을 통해 다른 스레드의 작업을 처리할 수 있습니다. 이러한 특성 덕분에 서버는 여러 클라이언트의 요청을 동시에 처리할 수 있어 효율적입니다. 다만, 동시성 환경을 신중하게 고려하지 않으면 여러 스레드를 사용하면서 Deadlock, Race Condition, Starvation 등의 문제가 발생할 수 있습니다.

병렬성(Parallelism)이란?

병렬성이란 물리적으로 동일한 시간에 여러 작업을 독립적으로 수행하는 것을 의미합니다. 여러 개의 코어가 각각 독립된 스레드의 작업을 동시에 처리함으로써, 실제로 여러 작업이 동시에 실행됩니다. 동시성과는 달리, 하나의 코어가 여러 스레드를 번갈아 가며 처리할 필요 없이, 각 코어에서 독립적으로 작업을 실행합니다.

독립적인 하위 작업으로 나눌 수 있는 계산과 같은 작업을 여러 코어에 분산함으로써, 작업 완료 시간을 최소화할 수 있어 고성능 컴퓨팅에 이상적입니다. 하지만 병렬 처리는 데이터나 리소스를 공유할 때 작업 간 동기화가 필요할 경우가 많아, 이러한 동기화로 인해 상당한 오버헤드가 발생할 수 있습니다.

추가 학습 자료를 제공합니다.

• Concurrency vs Parallelism: A Simplified Explanation
• Concurrency vs Parallelism
• 동시성 (Concurrency) vs 병렬성 (Parallelism)

캐시는 성능 향상과 부하 감소를 목표로 합니다. 이때 캐시를 사용하는 양상이 서비스에 큰 영향을 끼치기도 합니다. 따라서, 캐싱 전략을 이해하는 것은 중요합니다.

Cache Aside(Lazy Loading) 방식에 대해서 설명해주세요. 😀

Cache Aside 방식은 캐시 히트 시 캐시에서 데이터를 불러오며, 캐시 미스 발생 시 원본 데이터베이스에서 조회하여 반환합니다. 애플리케이션은 캐시 미스가 발생하면 해당 데이터를 캐시에 적재합니다.

해당 방식은 실제 요청된 데이터만 캐시에 저장되므로 불필요한 데이터 캐싱을 줄일 수 있습니다. 또한, 캐시에 문제가 발생해도 애플리케이션은 원본 데이터베이스에 직접 접근할 수 있기 때문에 서비스가 계속 작동할 수 있다는 장점이 있습니다. 하지만, 캐시 미스가 발생하는 경우에만 데이터를 캐시에 적재하기 때문에 원본 데이터베이스와 같은 데이터가 아닐 수도 있으며, 초기에는 대량의 캐시 미스로 인한 데이터베이스 부하가 발생할 수 있습니다.

캐시 불일치를 해소할 수 있는 쓰기 전략에 대해서 알고 계신가요? 🤔

캐시 불일치(Cache Inconsistency) 란 원본 데이터베이스에 저장된 데이터와 캐시에 저장된 데이터가 서로 다른 상황을 의미합니다. Write Through, Cache Invalidation, Write Behind 방식으로 이러한 캐시 불일치를 해소할 수 있습니다.

Write Through 방식은 원본 데이터에 대한 변경분이 생긴 경우, 매번 캐시에 해당 데이터를 찾아 함께 변경하는 방식입니다. 2번 쓰기가 발생하지만, 캐시는 항상 최신 데이터를 가지고 있습니다. 캐시는 다시 조회되는 경우에 빛을 발휘합니다. 무작정 데이터를 갱신하거나 저장하는 방식은 리소스 낭비가 될 수 있으니 해당 방식을 사용하는 경우, 만료 시간을 사용하는 것이 권장됩니다.

Cache Invalidation 방식은 원본 데이터에 대한 변경분이 생긴 경우, 캐시 데이터를 만료시키는 방식입니다. Write Through 방식의 단점을 보완한 방식이며 캐시에 데이터가 삭제되니 캐시 불일치에 대한 걱정을 하지 않아도 됩니다.

Write Behind(Write Back) 방식은 원본 데이터에 대한 변경분이 생긴 경우, 캐시를 먼저 업데이트한 이후 추후에 원본 데이터를 변경합니다. 디스크 쓰기 작업을 비동기 작업으로 수행하여 성능을 개선할 수 있습니다. 원본 데이터와 캐시가 일시적으로 일치하지 않을 수 있있기 때문에 쓰기 작업이 빈번하며 일시적인 캐시 불일치를 허용하는 서비스에서 유용하게 사용될 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 저문, 라온의 Cache & Redis
• 잘못된 캐싱 전략이 당신의 서비스를 망치고 있습니다

REST(Representational State Transfer) 는 자원의 표현을 이용하여 상태를 주고받는 것을 의미합니다. 여기서 자원이란 소프트웨어가 관리하는 모든 것을 의미하며 자원의 표현은 자원을 나타내기 위한 이름을 의미합니다. 가령, 서버가 관리하는 주문 데이터는 order 라고 표현할 수 있습니다. 최근에는 일반적으로 자원의 상태를 나타내기 위해 JSON 포맷을 사용합니다. REST는 네트워크 상에서 클라이언트와 서버의 통신 방식 중 하나이며, HTTP 프로토콜을 사용합니다. 구체적으로는 HTTP URI를 활용하여 자원을 명시하고 HTTP METHOD를 통해 CRUD 연산을 적용하는 것을 의미합니다.

API(Application Programming Interface) 란 컴퓨터 프로그램 간 정보를 주고받을 수 있도록 하는 일종의 출입구와 같은 역할을 수행합니다. API가 REST 기반으로 구현되어 있다면, 이를 REST API라고 부릅니다.

REST의 장단점은 무엇인가요? 🤔

REST는 서버와 클라이언트의 역할을 명확하게 분리해 주며, HTTP 프로토콜을 따르는 모든 플랫폼에서 사용할 수 있습니다. 또한, CURL, Postman을 사용하여 간단하게 테스트할 수 있다는 장점도 존재합니다. 반면, 요청 및 응답 스타일의 통신만 지원합니다. 그리고, HTTP 메서드로 행위를 표현하기 어려운 경우도 존재하며 요청 한 번으로 여러 자원을 가져오기 어렵다는 단점이 존재합니다.

그리고 REST 방식의 경우 자원의 상태를 전송하기 위해서 JSON 메시지 포맷을 사용합니다. JSON과 같은 텍스트 포맷은 자기 서술적이며, 메시지 소비자가 자신이 관심이 있는 값만 골라서 사용하고 나머지는 무시하면 되므로 메시지 구조가 자주 바뀌어도 하위 호환성을 보장하는 것이 유리합니다. 하지만, 메시지가 다소 길다는 것이 단점입니다. 메시지가 길다면 네트워크 트래픽을 더욱 사용하며 전송 속도가 느릴 수 있으며, 메시지를 해석하는 데에 오버헤드가 발생할 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 🐯 심바의 RESTful
• REST란? REST API란? RESTful이란?

ACID는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)의 약자이며, 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 의미합니다.

각 속성은 어떤 의미를 가지나요? 🤔

원자성(Atomicity) 은 트랜잭션 내부 연산들이 부분적으로 실행되고 중단되지 않는 것을 보장합니다. 쉽게 말하자면, 트랜잭션은 전체 성공과 전체 실패 중 한 가지만 수행한다는 것입니다. 예를 들면 계좌 이체 트랜잭션은 다음과 같은 연산으로 이루어져 있습니다. 이때 2번 과정에서 에러가 발생하면 1번 과정을 취소해야 합니다.

1. A 계좌에 3000원 출금
2. B 계좌에 3000원 입금 

일관성(Consistency) 은 트랜잭션이 성공적으로 완료되면 일관성 있는 데이터베이스 상태로 유지되는 것을 보장합니다. 가령, 제약조건과 같이 데이터베이스에 정의된 규칙을 트랜잭션이 위반하는 경우에는 해당 트랜잭션은 취소되어야 합니다.

격리성(Isolation) 은 동시에 실행되는 여러 트랜잭션이 서로 독립적임을 보장합니다. 가장 엄격할 경우에는 트랜잭션을 순차적으로 실행하기도 합니다. 트랜잭션을 수행할 때 다른 트랜잭션이 해당 작업 사이에 끼어들지 못하도록 보장합니다. 쉽게 이야기하자면 트랜잭션 밖에서 어떠한 연산도 중간 단계의 데이터를 볼 수 없음을 의미합니다. 가령, 계좌 이체 작업에서 A 계좌의 잔고와 B 계좌의 잔고 총합이 10,000원인 상태로 시작했을 때, 특정 순간에는 총합이 10,000원이 아닌 경우도 있을 것입니다. 하지만, 다른 트랜잭션은 항상 잔고의 총합인 10,000원을 볼 수 있도록 보장되어야 합니다.

지속성(Durability) 은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 보장합니다. 시스템에 장애가 발생해도 성공적으로 수행된 트랜잭션의 결과는 항상 데이터베이스에 반영되어 있어야 합니다. 전형적으로 트랜잭션은 로그로 남고, 로그가 저장되어야 트랜잭션이 성공되었다고 간주합니다. 추후 장애가 발생한다면 이 로그를 활용해 데이터베이스를 회복합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 로건의 Transaction
• 데이터베이스 트랜잭션(transaction)을 아십니까? 그리고 트랜잭션의 매우 중요한 속성들인 ACID를 아십니까? 모르신다면 들렀다 가시지요
• 심화 - ACID 데이터베이스와 BASE 데이터베이스의 차이점은 무엇인가요?
• 심화 - 분산 데이터베이스 탐구: 데이터 복제와 일관성

기존 개발하고 있던 서비스의 서버가 한계에 도달하는 경우, 스케일 업(Scale-Up) 혹은 스케일 아웃(Scale-Out) 을 고려할 수 있습니다.

스케일 업 은 기존의 서버를 더욱 높은 사양으로 업그레이드하는 것을 의미합니다. 예를 들어, AWS에서 EC2 t2.micro에서 t2.small로 업그레이드하는 방식이 스케일 업입니다. 스케일 업 방식은 상대적으로 간단하게 서버의 성능을 항상 시킬 수 있다는 장점이 있습니다. 하지만, 특정 서버를 무한정 업그레이드할 수 없으며, 장애에 대한 자동복구(failover)나 다중화(re-dundancy) 방안을 제시하지 않습니다. 또한 스케일 업 전략을 선택하는 경우에는 향후 사용량을 미리 추정하여 미리 고사양의 서버를 확보하는 경우가 있습니다. 이러한 경우 실제 필요한 서버의 사양보다 과한 사양의 장비를 확보할 수 있기 때문에 비용적인 손실이 존재할 수 있습니다.

스케일 아웃 은 비슷한 사양의 장비를 추가하여 수평으로 확장하는 방식입니다. 서버로 들어오는 많은 요청을 비슷한 사양의 서버 n대로 분산시켜 성능을 향상시킵니다. 스케일 아웃 방식은 그때그때 필요한 만큼 서버를 추가할 수 있으므로 상대적으로 스케일 업 방식보다 비용 효율적일 수 있습니다. 또한, 특정 서버의 장애 발생 상황에서도 스케일 업 방식보다 가용성이 높습니다. 하지만, 스케일 아웃 방식은 n대의 서버를 관리해야 하므로 관리 포인트가 늘어나며, 각 서버에 부하를 분산하기 위한 로드 밸런싱에 대한 고민이 추가로 필요하다는 단점이 있습니다.

추가 학습 자료를 공유합니다.

• 테코블 - Scale-up과 Scale-out에 대해 알아보자!
• [10분 테코톡] 🍇포도당의 scale up vs scale out, SPOF

컨텍스트 스위칭(Context Switching)이란?

컨텍스트 스위칭은 CPU나 코어에서 실행 중이던 프로세스나 스레드가 다른 프로세스나 스레드로 교체되는 과정을 말합니다. 이는 멀티태스킹 시스템에서 여러 작업을 효율적으로 관리하기 위해 필수적인 메커니즘입니다.

컨텍스트(Context)란?

컨텍스트는 프로세스나 스레드의 현재 상태를 의미합니다. 여기에는 CPU의 레지스터 상태(프로그램 카운터, 스택 포인터 등)와 메모리 상태가 포함됩니다. 컨텍스트는 프로세스나 스레드가 실행을 중단하고 나중에 다시 시작할 때 필요한 모든 정보를 담고 있습니다.

컨텍스트 스위칭이 필요한 이유

멀티태스킹 시스템에서는 여러 프로세스나 스레드가 동시에 실행되는 것처럼 보이도록, CPU가 짧은 시간 단위로 작업을 전환하며 여러 작업을 처리합니다. 이를 통해 사용자에게는 여러 작업이 동시에 진행되는 것처럼 인식되며, 시스템 자원을 효율적으로 활용할 수 있습니다.

컨텍스트 스위칭이 발생하는 시점

• Time Slice(Quantum)를 다 사용했을 때: 각 프로세스나 스레드에게 할당된 CPU 시간이 다 소진되면 스위칭이 발생합니다.
• I/O 작업이 필요할 때: 프로세스나 스레드가 I/O 작업을 수행해야 할 경우, CPU는 다른 작업을 처리하기 위해 현재 작업을 중단하고 스위칭을 수행합니다.
• 우선순위 변경: 더 높은 우선순위의 작업이 발생하면 현재 작업을 중단하고 우선순위가 높은 작업으로 전환할 수 있습니다.

컨텍스트 스위칭을 수행하는 주체

컨텍스트 스위칭은 운영체제의 커널(kernel) 에 의해 수행됩니다. 커널은 시스템 자원을 관리하고 프로세스 및 스레드의 상태를 조정하여 효율적인 작업 처리를 담당합니다.

컨텍스트 스위칭의 구체적인 과정

프로세스 컨텍스트 스위칭(다른 프로세스에 속한 스레드 간의 컨텍스트 스위칭)

1. 현재 프로세스의 상태 저장: 실행 중인 프로세스의 레지스터 상태와 메모리 정보를 저장합니다.
2. 다음 프로세스의 상태 로드: 스케줄러가 선택한 다음 실행할 프로세스의 저장된 상태를 로드합니다.
3. 프로세스 전환: CPU는 새로운 프로세스의 실행을 시작합니다.
4. 추가 메모리 처리: 새로운 프로세스의 가상 메모리 주소 체계를 설정하고, MMU(Memory Management Unit)와 TLB(Translation Lookaside Buffer)를 업데이트합니다.

스레드 컨텍스트 스위칭(같은 프로세스에 속한 스레드 간의 컨텍스트 스위칭)

1. 현재 스레드의 상태 저장: 실행 중인 스레드의 레지스터 상태를 저장합니다.
2. 다음 스레드의 상태 로드: 동일한 프로세스 내에서 실행할 다음 스레드의 상태를 로드합니다.
3. 스레드 전환: CPU는 새로운 스레드의 실행을 시작합니다.
4. 메모리 처리 생략: 동일한 프로세스 내 스레드 간 전환이므로 메모리 관련 추가 처리가 필요 없습니다.

프로세스와 스레드 컨텍스트 스위칭의 공통점

1. 커널 모드에서 실행: 컨텍스트 스위칭은 항상 운영체제의 커널 모드에서 수행됩니다.
2. CPU 레지스터 상태 교체: 현재 실행 중인 작업의 레지스터 상태를 저장하고, 다음 작업의 레지스터 상태를 복원합니다.

프로세스와 스레드 컨텍스트 스위칭의 차이점

같은 프로세스에 속한 스레드들 간의 컨텍스트 스위칭은 같은 프로세스에 속하기 때문에 메모리 영역을 공유합니다. 그래서 스위칭이 발생해도 메모리와 관련한 추가적인 작업이 발생하지 않습니다.

하지만 다른 프로세스에 속한 스레드 간의 컨텍스트 스위칭의 경우 메모리 프로세스간 메모리 주소 체계가 다르기 때문에, 메모리 주소 관련 처리를 추가적으로 수행해야 합니다.

그래서 MMU(Memory Manage Unit) 또한 새로운 프로세스의 주소 체계를 바로보도록 수정해줘야 하고, TLB(Translation Lookaside Buffer)라는 가상 메모리 주소와 실제 메모리 주소의 매핑 정보를 들고 있는 캐시도 비워줘야 합니다. 만약 TLB 캐시를 비워주지 않는 경우 이전에 작업했던 프로세스의 주소에 접근할 가능성이 있기 때문에 반드시 수행해야 합니다.

스레드 컨텍스트 스위칭이 프로세스보다 빠른 이유

스레드 컨텍스트 스위칭(Thread Context Switching)의 경우 프로세스 컨텍스트 스위칭(Process Context Switching)과 달리 MMU 새로운 주소 체계 바로보도록 수정하고 TLB 가상 메모리, 실제 메모리 저장된 캐시를 비우는 등의 메모리 주소 관련 작업을 하지 않고, CPU의 상태 정보만 바꿔주면 되기 때문입니다.

추가 학습 자료를 제공합니다.

• 쉬운코드 - 컨텍스트 스위칭 뽀개기! 의미와 종류와 왜 스레드 컨텍스트 스위칭이 더 빠르다고 하는지까지..! 이 모든 것을 시원~~하게 설명합니다!!
• 완전히 정복하는 프로세스 vs 스레드 개념
• [OS] 컨텍스트 스위칭: 프로세스 컨텍스트 스위칭 VS 스레드 컨텍스트 스위칭

HTTP/1.1에 대해서 설명해주세요.

HTTP는 웹상에서 클라이언트와 서버 간 통신을 위한 프로토콜입니다. HTTP/1.0의 경우에는 한 개의 요청과 응답마다 TCP 커넥션을 생성하여 사용됐습니다. 하지만, 이러한 방식은 매 요청마다 연결을 생성하는 오버헤드가 발생합니다. HTTP/1.1은 이러한 문제를 지속 커넥션(Persistent Connection) 이라는 지정한 타임아웃만큼 커넥션을 종료하지 않는 방식으로 해결합니다.

또한 파이프라이닝(Pipelining) 을 지원하여 요청의 응답 지연을 감소합니다. 파이프라이닝에서 HTTP 요청은 연속적이며, 순차적으로 전달됩니다. 기존에는 요청한 이후에 응답을 기다리고 그 다음 요청을 보냈는데요. 파이프라이닝에서는 필요한 모든 자원에 대한 요청을 순차적으로 서버로 전송한 다음 모든 요청에 대한 응답을 한 번에 기다리게 됩니다.

HTTP/1.1은 1.0 버전에 비해 상당히 개선됐지만 여전히 문제가 존재하는데요. 대표적으로 Head-of-Line Blocking(HOL Blocking) 문제가 있습니다. 만약 3개의 요청을 파이프라인을 통해 전송을 한다고 했을 때, 서버는 모든 요청을 순서에 맞춰서 응답해야 합니다. 이때 첫 번째 요청이 오래 걸린다고 하면, 나머지 요청은 첫 번째 요청의 처리를 기다려야 합니다. 또한, 1.1 버전은 매 요청마다 동일한 헤더를 반복하여 전송한다는 문제점도 존재합니다.

HTTP/2.0에 대해서 설명해주세요.

HTTT/1.1는 메시지를 일반 텍스트 형식으로 전송했습니다. 2.0부터는 기존 HTTP 메시지를 프레임이라는 단위로 분할하고 이를 바이너리 형태로 만들어서 전송합니다. 따라서, 기존 1.1 버전에 비해 파싱 및 전송 속도가 향상되었습니다.

또한, HTTP/2.0 부터는 멀티플렉싱(Multiplexing) 을 지원합니다. 이는 하나의 커넥션을 사용하여 요청과 응답을 병렬로 처리할 수 있는 방식입니다. 클라이언트가 서버로 여러 요청을 동시에 보내도 각 요청이 독립적으로 처리되기 때문에 애플리케이션 레이어의 HOL Blocking 문제를 해결합니다. 또한 HPACK 헤더 압축 방식을 사용해 반복되는 헤더를 효율적으로 관리하여 대역폭 사용이 최적화되었습니다.

추가 학습 자료를 공유합니다.

• 웹 개발자라면 알고 있어야 할 HTTP의 진화 과정
• gRPC 를 도입하는 이유에 대해서 알아보자 (feat. HTTP 1.0 vs HTTP 1.1 vs HTTP 2.0)
• [10분 테코톡] 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC
• HTTP3까지 버전별 변천사와 동작원리

관계형 데이터베이스는 고정된 로우와 컬럼으로 구성된 테이블에 데이터를 저장합니다. 그리고 SQL을 사용하여 여러 테이블에 존재하는 데이터와 관계에 따라서 조인하여 합칠 수도 있습니다. 관계형 데이터베이스는 데이터를 중복 없이 한 번만 저장하고, 데이터 무결성을 보장합니다. 관계형 데이터베이스의 경우 일반적으로 스케일 업을 사용하여 확장합니다. 관계형 데이터베이스는 스키마를 유연하게 바꾸기 어렵다는 한계가 존재합니다. 또한, 관계가 존재하기 때문에 비즈니스 요구사항이 더욱 발전하면 복잡한 쿼리가 생기게 됩니다.

반면, 비 관계형 데이터베이스는 NoSQL이라고 불리기도 하는데요. 정해진 스키마가 존재하지 않으며 자유롭게 데이터를 저장하고 조회할 수 있습니다. 문서, 키-값, 와이드 컬럼, 그래프 유형이 존재합니다. 대량의 데이터와 높은 사용자 부하에서도 손쉽게 확장할 수 있습니다. 반면 중복을 허용하는 NoSQL의 경우 데이터의 일관성이 저하되며 용량이 증가한다는 단점이 존재합니다.

어떤 상황에서 각 유형의 데이터베이스를 사용하는 것이 적절할까요? 🤔

데이터가 구조화되어 있고, 자주 변경되지 않으며, 트랜잭션과 복잡한 쿼리, 그리고 데이터 무결성과 일관성이 중요한 경우 관계형 데이터베이스를 선택할 수 있습니다. 트랜잭션이 필요한 서버 애플리케이션을 개발하는 경우가 대표적인 예시입니다. 반면, 아주 낮은 응답 지연시간이 요구되거나, 다루는 데이터의 스키마가 빈번히 변경되거나, 아주 많은 양의 데이터를 저장해야 하는 상황에서는 비 관계형 데이터베이스를 고려할 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 스플릿, 애쉬의 SQL과 NoSQL
• SQL vs NoSQL 파헤치기: 당신의 프로젝트에 완벽한 데이터베이스는?

그림과 함께 설명해 주시겠어요? 😀

대규모 트래픽 환경에서 캐시를 운용하는데, Cache Aside(캐시 미스 발생 시 적재) 전략을 사용한다고 가정하겠습니다. 이때, 수많은 요청들이 동시에 캐시 미스를 확인하고 원본 저장소에서 데이터를 가져와 캐시에 적재하는 상황이 발생할 수 있는데요. 이를 캐시 스탬피드 현상 혹은 Thundering Herd 문제라고 표현합니다. 캐시 스탬피드 현상은 원본 데이터베이스와 캐시의 성능을 저하할 수도 있습니다.

이 문제는 어떻게 풀어볼 수 있을까요? 🤓

해당 방식은 크게 잠금, 외부 재계산, 확률적 조기 재계산 방식으로 풀어볼 수 있습니다.

잠금(Locking) 방식 은 한 요청 처리 스레드가 해당 캐시 키에 대한 잠금을 획득합니다. 이로인해 다른 요청 처리 스레드들은 잠시 대기합니다. 잠금을 획득한 스레드는 사용자 요청에 응답하는 과정동안 캐시 적재 작업은 비동기 스레드로 처리할 수 있습니다. 잠금을 사용하기 때문에 성능 저하 가능성이 존재하며, 잠금 획득 스레드의 실패, 잠금의 생명 주기, 데드락 등 다양한 상황을 고려해야한다는 단점이 존재합니다.

외부 재계산(External Recomputation) 방식 은 모든 요청 처리 스레드가 캐시 적재를 수행하지 않습니다. 대신, 캐시를 주기적으로 모니터링하는 스레드를 별도로 관리하여 캐시의 만료시간이 얼마 남지 않은 경우, 데이터를 갱신하여 문제를 예방합니다. 해당 방식은 다시 사용되지 않을 데이터를 포함하여 갱신하기 때문에 메모리에 대한 불필요한 연산이 발생하고, 메모리 공간을 비효율적으로 사용할 가능성이 존재합니다.

확률적 조기 재계산(Probablistic Early Recomputation) 방식 은 캐시 만료 시간이 얼마 남지 않았을 경우, 확률이라는 개념을 사용하여 여러 요청 처리 스레드 중에서 적은 수만이 캐시를 적재하는 작업을 수행하여 스탬피드 현상을 완화할 수 있습니다.

추가 학습 자료를 공유합니다.

• 라인 기술 블로그 - req-shield로 캐시의 골칫거리 'Thundering Herd 문제' 쉽게 풀기!
• 화해 기술 블로그 - 캐시 스탬피드를 대응하는 성능 향상 전략, PER 알고리즘 구현
• 대용량 트래픽 아니면 안 보셔도 됩니다! 선물하기 서비스 캐싱 전략 / if(kakaoAI)2024
• What is Cache Stampede ?

분리된 시스템 간의 비동기 연동은 시스템 간의 결합도를 낮출 수 있으며, 호출된 시스템의 응답을 기다리지 않으므로 더욱 빨리 사용자의 요청에 응답할 수 있다는 장점이 있습니다. 비동기 연동 방식으로 메시징 시스템 활용, 데이터베이스 활용, CDC 활용 방식을 알고 있습니다.

각 방식에 대한 설명과 고려 사항을 설명해 주세요. 😀

메시징 시스템 활용 방식은 두 시스템 사이에 메시징 시스템을 두어 비동기로 연동하는 방식입니다. 해당 방식은 한 시스템에서 메시지를 생성해서 메시징 시스템에 송신한 이후, 다른 시스템에서 메시징 시스템으로부터 메시지를 읽어와 메시지를 처리합니다. KafKa, RabbitMQ가 주로 메시징 시스템으로 활용됩니다. 해당 방식은 처리량이 높은 것이 장점입니다. 하지만, 메시지 유실, 메시지 소비 순서, 트랜잭션에 대한 고민이 추가적으로 필요합니다. 트랜잭션에 대한 고민을 더욱 말씀 드리자면, 1개의 트랜잭션 내에 메시지 전송과 데이터베이스 삽입이 존재한다고 했을 때, 데이터베이스 삽입이 실패했는 데 메시지는 전송되거나, 데이터베이스 삽입은 성공했는데, 메시지 전송이 실패한 경우를 떠올려 볼 수 있습니다. 만약 이러한 상황이 존재한다면, 2개의 작업을 어떻게 원자적으로 수행할 수 있을 지 추가적인 고민이 필요합니다.

데이터베이스 활용 방식은 데이터베이스를 메시징 시스템처럼 사용하는 방법입니다. 한 시스템에서 데이터베이스 테이블에 필요한 메시지 레코드를 추가하고 연동 시스템이 테이블을 주기적으로 읽습니다. 만약 새로운 메시지가 추가되면 연동 시스템은 다른 시스템으로 메시지를 전송합니다. 해당 방식은 트랜잭션과 메시지 순서가 보장되며, 메시지 유실에 대한 걱정이 없다는 것이 장점입니다. 하지만, 해당 방식은 범용성이 떨어질 수 있습니다. 메시지에 대한 형식이 빈번히 변경될때마다 메시지 레코드에 대한 스키마도 변경해주어야하기 때문입니다. 추가적으로 해당 방식은 삭제 정책과 읽기 빈도 등 추가적으로 고민해야할 부분들이 존재합니다.

CDC(Change Data Capture) 활용 방식은 데이터베이스의 변경 사항을 조회하여, 이를 다른 시스템에 전파하는 방식입니다. 가령 별도의 시스템이 변경 감지 대상 데이터베이스의 바이너리 로그를 조회하여 변경을 전파하도록 구현할 수 있습니다. 해당 방식은 트랜잭션이 보장되며, 메시지를 생성하거나 별도로 저장할 필요가 없으니 상대적으로 애플리케이션 로직이 단순하다는 장점이 있습니다. 하지만, 변경 로그만 존재할뿐 왜 바뀌었는지에 대한 추가적인 정보가 없기 때문에 사용하는데 제약이 존재할 수 있습니다.

추가 학습 자료를 공유합니다.

• [최범균님 유튜브] 초식 - 시스템 간 비동기 연동 4종 세트
• [NHN FORWARD 22] 분산 시스템에서 데이터를 전달하는 효율적인 방법

CAP 정리는 분산 데이터베이스 시스템이 CAP 중 2개의 속성만을 제공할 수 있다는 이론입니다. CAP 정리에 따르자면, 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 등 3가지 속성을 모두 만족하는 분산 데이터베이스 시스템은 존재하지 않습니다.

각 속성에 대해서 설명해주시겠어요? 🤔

• 일관성(Consistency) 은 모든 클라이언트 요청은 어느 노드에 연결되어도 같은 데이터를 볼 수 있음을 의미합니다.
• 가용성(Availability) 은 노드 일부에 문제가 발생하여도 시스템은 클라이언트의 모든 요청에 유효한 응답을 전해줄 수 있어야 함을 의미합니다.
• 분할 내성(Partition Tolerance) 은 노드 사이에 통신이 불가능한 상황(파티션)에서도 시스템이 계속 동작한다는 것을 의미합니다.

각 속성의 조합을 예시와 함께 설명해 주실 수 있나요? 🤓

3개의 분산된 데이터베이스가 존재한다고 가정해 보겠습니다. 해당 분산 데이터베이스 시스템에서는 특정 서버에 쓰기 작업이 발생하면 나머지 서버에 데이터가 전파됩니다. 이때, 만약 A 파티션(1대의 노드), B 파티션(2대의 노드)으로 네트워크가 분할되었다면 이때 파티션 간 노드들은 서로 통신할 수 없기 때문에 데이터 전파가 불가능합니다.

CA 시스템은 일관성과 가용성을 지원하며 분할 내성을 희생합니다. 하지만, 통상적으로 네트워크 장애는 피할 수 없는 일로 여겨지므로 분산 시스템에서 분할 내성은 희생하기 어렵습니다. 따라서 실세계에 CA 시스템은 존재하지 않습니다.

그러면 CP 혹은 AP 시스템이 현실적인 대안이 될 수 있는데요. 파티션이 발생한 상황에서 CP 시스템은 파티션이 해결되기 전까지 다른 데이터베이스의 연산을 중단시켜 일관성을 지키고 가용성을 희생합니다.

반면, AP 시스템은 파티션 문제가 발생해도 읽기 및 쓰기 작업을 중단하지 않습니다. 이 경우 일관성은 희생되지만 파티션 문제가 해결되는 경우 동기화 작업을 수행하여 최종적인 일관성을 보장할 수 있습니다.

추가 학습 자료를 공유합니다.

• 기계인간 John Grib - CAP 정리

응집도(Cohesion) 는 모듈에 포함된 내부 요소들이 연관되어 있는 정도를 나타냅니다. 결합도(Coupling) 는 의존성의 정도를 나타내며, 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타냅니다.

응집도와 결합도는 변경과 관련이 깊으며, 일반적으로 좋은 설계란 높은 응집도와 낮은 결합도를 가진 모듈로 구성된 설계를 의미합니다. 객체의 행동에서 객체가 알고 있는 모든 정보를 사용하거나, 변경이 존재하는 경우 특정 모듈만 수정되면 응집도가 높다고 판단할 수 있습니다. 또한, 특정 모듈을 변경하는 경우에 다른 모듈도 변경해야 하는 상황에서는 결합도가 높다고 판단할 수 있습니다.

캡슐화의 정도가 응집도와 결합도에 영향을 미치는데요. 캡슐화를 지키면, 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아집니다. 따라서, 응집도와 결합도를 고려하기 전에 먼저 캡슐화를 향상하기 위해 노력해야 합니다.

캡슐화는 무엇인가요? 😀

객체 내부의 세부적인 사항을 감추는 것을 캡슐화라고 합니다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것입니다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 더욱 쉽게 변경할 수 있습니다. 만약 캡슐화가 약화되어 있다면, 클라이언트 코드로 변경이 전파되어 변경이 쉽지 않을 수 있습니다. 그리고, 협력을 재사용하기 어려운 상황을 만들어낼 수 있는데요. 이러한 상황을 예방하기 위해서 캡슐화는 객체지향 프로그래밍에서 기본기로 여겨집니다.

추가 학습 자료를 공유합니다.

• [우아한테크세미나] 190620 우아한객체지향 by 우아한형제들 개발실장 조영호님
• [10분 테코톡] 아루의 객체지향과 추상화 수준
• [10분 테코톡] 🍟 웨지의 OOP

Redis가 단일 스레드(single-threaded)로 설계된 이유는 주로 성능 최적화, 복잡성 감소, 그리고 데이터 일관성을 유지에 있습니다.

단일 스레드 모델은 멀티스레드 모델에 비해 설계와 구현이 상대적으로 간단합니다. 멀티스레드 환경에서는 동시성 문제(레이스 컨디션, 데드락 등)를 처리하기 위해 복잡한 동기화 메커니즘이 필요하지만, 단일 스레드 환경에서는 이런 문제를 자연스럽게 회피할 수 있습니다.

동시에 여러 스레드가 동일한 데이터를 수정하려고 할 때 발생할 수 있는 데이터 불일치 문제를 방지합니다. 모든 명령어가 순차적으로 처리되기 때문에, 복잡한 락(lock) 메커니즘 없이도 데이터의 일관성을 자연스럽게 유지할 수 있습니다.

Redis는 주로 메모리 내에서 빠르게 수행되는 I/O 작업을 처리하는 인메모리 데이터베이스로 설계되어, 매우 빠른 응답 시간을 제공합니다. 단일 스레드 이벤트 루프(event loop)를 사용함으로써 컨텍스트 스위칭(Context Switching)에 소요되는 오버헤드를 최소화할 수 있습니다.

Redis는 이벤트 기반(event-driven) 아키텍처를 채택하여 네트워크 요청을 효율적으로 처리합니다. 단일 스레드 이벤트 루프는 비동기적으로 여러 클라이언트의 요청을 처리할 수 있으며, 이를 통해 높은 동시성을 구현할 수 있습니다. 멀티스레드 모델에서는 이러한 비동기 처리의 이점을 충분히 활용하기 어려울 수 있습니다.

Redis 6.0 부터 클라이언트로 부터 전송된 네트워크를 읽는 부분과 전송하는 I/O 부분은 멀티 스레드를 지원합니다. 하지만 실행하는 부분은 싱글 스레드로 동작하기 때문에 기존과 같이 Atomic을 보장합니다.

추가 학습 자료를 공유합니다.

• Redis - Diving Into Redis 6.0
• Why the heck Single-Threaded Redis is Lightning fast? Beyond In-Memory Database Label
• [입 개발] Redis 6.0 – ThreadedIO를 알아보자.

교착 상태(deadlock) 는 두 개 이상의 작업이 서로 상대방의 작업이 끝나기만을 기다리고 있어 결과적으로 아무것도 완료되지 못하는 상태를 의미합니다. 가령, A 프로세스가 자원 A를 가지고 자원 B를 필요로 합니다. 그리고, B 프로세스는 자원 B를 가지고 자원 A가 필요할 때 두 개의 프로세스는 교착 상태에 빠져 어느 작업도 진행할 수 없는 상황이 됩니다.

교착 상태가 발생하는 조건을 알고 계신가요? 🤔

4가지 조건(상호 배제, 점유 대기, 비선점, 원형 대기)이 모두 만족하는 경우, 교착 상태에 빠질 수 있습니다.

• 상호 배제(mutual exclusion) 는 한 프로세스가 사용하는 자원을 다른 프로세스가 사용할 수 없는 경우를 의미합니다.
• 점유 대기(hold and wait) 는 자원을 할당받은 상태에서 다른 자원을 할당받기를 기다리는 상태를 의미합니다.
• 비선점(non-preemption) 은 자원이 강제적으로 해제될 수 없으며 점유하고 있는 프로세스의 작업이 끝난 이후에만 해제되는 것을 의미합니다.
• 원형 대기(circular wait) 은 프로세스들이 원의 형태로 자원을 대기하는 것을 의미합니다.

자바에서 교착 상태는 어떻게 해결할 수 있나요? 😀

// thread 1
synchronized (resource1) { 
  synchronized(resource2) { ... }
}

// thread 2
synchronized (resource2) { 
  synchronized(resource1) { ... }
}

예를 들어, 자바의 syncronized 키워드로 인한 교착 상태가 발생했다고 가정해보겠습니다. 위와 같은 경우에는 외부 synchronized 블록 내부에 synchronized 블록을 포함하지 않도록 개선하여 점유 대기 조건을 제거하여 교착 상태를 해결할 수 있습니다.

이외에도 ReentrantLock을 사용하는 경우에는 tryLock() 메서드를 사용하여 타임아웃을 설정하거나, lockInterruptibly() 메서드를 사용하여 데드락이 발생하는 경우, 인터럽트를 통해 스레드를 깨울 수 있습니다.

정리하자면 교착 상태가 발생하는 4가지 조건 중 하나를 충족하지 못하게 하거나, 대기하는 경우 무한정 기다리지 않는 방식으로 교착 상태를 풀어볼 수 있습니다.

추가 학습 자료를 공유합니다.

• [OS] 데드락(Deadlock)은 언제 발생하고, OS, Java에서 어떻게 해결할까?
• [JAVA] 자바 쓰레드 동기화(1) - synchronized, wait()/notify()
• [JAVA] 자바 쓰레드 동기화(2) - ReentrantLock과 Condition

특정 메서드를 호출하는 경우 인자로 전달하는 방법은 크게 2가지가 존재하는데요. 값에 의한 호출(Call By Value), 참조에 의한 호출(Call By Reference)이 이에 해당됩니다.

값에 의한 호출(Call By Value) 은 메서드를 호출할 때, 값 자체를 넘겨주는 방식입니다. 메서드를 호출하는 함수의 변수와 호출된 함수의 파라미터는 서로 다른 변수입니다.

반면, 참조에 의한 호출은(Call By Reference) 는 메서드를 호출할 때, 참조를 직접 전달하는 방식입니다. 참조를 직접 전달하기 때문에 호출하는 함수의 변수와 호출된 함수의 파라미터는 동일한 변수입니다. 따라서, 파라미터를 수정하는 경우 그대로 원본에도 영향을 미칩니다.

자바는 어떤 방식을 채택하나요? 🤓

자바는 값에 의한 호출(Call By Value)만 존재합니다.

자바의 변수는 스택 영역에 할당됩니다. 이때, 변수의 타입이 원시 타입인 경우에는 값 또한 스택 영역에 저장됩니다. 그리고, 참조 타입인 경우 객체 자체는 힙 영역에 저장되고 스택 영역에 존재하는 변수가 객체의 주소를 가지고 있습니다.

만약 특정 메서드에 원시 타입의 변수를 인자로 전달하여 호출하면, 호출된 메서드의 해당 파라미터가 변경되어도 원본은 수정되지 않습니다. 왜냐하면, 호출된 메서드의 스택 프레임에 인자로 주어진 변수의 값이 복사되어 사용되기 때문입니다.

반면, 참조 타입의 변수를 인자로 전달하여 호출하는 경우에는 호출된 메서드 내부에서 원본이 수정될 수 있습니다. 하지만, 이러한 방식은 호출된 메서드의 스택 프레임에 참조 타입 변수를 중복하여 생성하기 때문에 값에 의한 호출로 판단됩니다. 가령, 다음과 같은 코드가 존재할 때, foo 메서드의 스택 프레임과 var 메서드의 스택 프레임에 각각 같은 student 객체의 주소를 가지고 있는 참조 타입 변수인 student가 존재합니다.

public void foo() {
    Student student = new Student();
    var(student);
}

public void var(Student student) {
    student.study();
}

추가 학습 자료를 공유합니다.

• 코드라떼 - 자바 메모리 모델 기초
• 코드라떼 - Java == Call By Value

방어적 복사(Defensive Copy) 는 원본과의 참조를 끊은 복사본을 만들어 사용하는 방식이며, 원본의 변경에 의한 예상치 못한 사이드 이펙트를 방지하여 안전한 코드를 만들 수 있는데 도움이 됩니다.

방어적 복사는 2가지 시점이 존재하는데요. 생성자의 인자로 받은 객체의 복사본을 만들어 내부 필드를 초기화하거나, getter 메서드에서 객체를 반환할 때, 복사본을 만들어 반환할 수 있습니다. 만약 컬렉션 자료구조를 반환하는 경우라면 자바의 Unmodifiable Collection을 사용하여, 외부에서 Collection에 대해 조회만 할 수 있도록 강제할 수 있습니다. 자바에서 Unmodifiable Collection은 set(), add(), addAll() 처럼 컬렉션에 요소를 추가하거나 변경하는 메서드를 사용하는 경우, 예외를 발생합니다.

다음 코드에서 발생할 수 있는 문제점은 무엇일까요? 🤔

public class Lotto {

  private final List<LottoNumber> numbers;

  public Lotto(List<LottoNumber> numbers) {
      validateSize(numbers);
      this.numbers = new ArrayList<>(numbers);  // 방어적 복사
  }
}

위 코드는 두 가지 문제점이 발생할 수 있습니다.

첫 번째는 생성자의 파라미터로 주어진 LottoNumber 리스트의 각 요소가 외부에서 변경될 수 있는 가능성이 존재합니다. 이러한 문제가 발생하는 이유는 방어적 복사가 깊은 복사가 아니기 때문입니다. 가령, 외부에서 다음과 같은 코드를 작성할 수 있습니다.

Lotto lotto = new Lotto(numbers);
numbers.get(0).changeNumber(1);

이 문제를 해결하기 위해서는 생성자의 파라미터에 Integer 리스트를 입력받거나, 방어적 복사 수행 시 내부 객체까지 깊은 복사를 수행할 수 있습니다.

또한 위 코드는 검증을 수행하는 시점에 외부에서 컬렉션이 변경이 발생할 수 있는 가능성이 존재합니다. 예를 들어, validateSize 메서드를 통과하고 방어적 복사를 수행하기 전에 외부에서 numbers에 값을 추가하는 경우, 검증은 성공했지만 객체의 값은 유효하지 않을 수 있습니다. 이 잠재적인 문제를 해결하기 위해서는 방어적 복사가 검증이 수행되기 이전에 이루어져야 합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 이든의 방어적 복사
• 테코블 - 방어적 복사와 Unmodifiable Collection

해시(Hash) 자료 구조는 키값 쌍으로 이루어진 데이터 구조로 키를 이용해 값을 O(1) 시간 복잡도로 찾을 수 있습니다. 해시 자료 구조는 키를 해시 함수에 넣어서 나오는 결과를 기반으로 값을 관리하는데요. 해시 함수는 다른 키를 사용해도 같은 결과가 나오는 경우가 존재합니다. 이를 해시 충돌(Hash Collision) 이라고 합니다.

해시 충돌은 어떻게 완화할 수 있나요? 🤓

해시 충돌을 완화하기 위한 접근 방법으로 개방 주소법과 분리 연결법이 대표적인데요. 개방 주소법(Open Addressing) 은 특정 값이 들어가야 하는 자리(버킷)가 이미 사용되고 있는 경우 다른 해시 버킷에 데이터를 삽입하는 반면, 분리 연결법(Separate Chaining) 은 버킷을 연결 리스트나 트리 형태로 관리하여 버킷에 들어갈 값의 수에 제한을 두지 않도록 하여 충돌을 완화합니다.

개방 주소법에서 다른 해시 버킷을 찾기 위한 방법에는 어떤 것이 존재하나요? 🤔

버킷이 이미 사용되고 있는 경우, 다른 해시 버킷을 찾기 위한 여러 방법이 존재합니다. 선형 탐사법, 제곱 탐사법, 이중 해싱이 이에 해당됩니다.

선형 탐사법(Linear Probing) 은 임의의 고정된 크기만큼 한 칸씩 옮기면서 빈 버킷을 찾는 방법입니다. 선형 탐사법은 특정 버킷 주변이 모두 채워져 있는 경우 해시 성능이 저하될 수 있습니다. (1차 군집 현상) 따라서, 해당 접근 방법은 해시 자료 구조 전체에 해시 충돌이 균등하게 발생할 때 유용합니다.

제곱 탐사법(Quadratic Probing) 은 선형 탐사법처럼 한 칸씩 찾는 것이 아닌 제곱으로 늘리면서 빈 버킷을 찾습니다. 보폭이 점점 늘어나기 때문에 선형 탐사법처럼 특정 영역에 값이 밀집되어 저장되어도 해당 영역을 빠르게 벗어날 수 있습니다. 하지만, 여러 값이 해시 함수로 같은 값을 갖게 될 경우 모두 같은 순서로 탐사할 수밖에 없어 비효율적인 상황이 발생할 수 있습니다. (2차 군집 현상)

이중 해싱(Double Hashing) 은 해시 충돌이 발생하는 경우, 보조 해시 함수를 사용하는 방법입니다. 해당 방법은 해시 충돌 가능성이 가장 작지만, 추가적인 보조 해시 함수에서 연산이 발생하기 때문에 다른 방식에 비해 많은 연산량이 요구됩니다.

추가 학습 자료를 공유합니다

• [10분 테코톡] 👩‍🏫코니의 #️⃣Hash Function
• [NAVER - D2] Java HashMap은 어떻게 동작하는가?

일반적으로 단일-헤드 디스크 시스템에서 특정 데이터 블록(하나 이상의 섹터로 이루어짐)을 읽거나 쓰기 위해서는 헤드를 데이터가 존재하는 트랙으로 이동시키는 과정, 원하는 데이터가 저장된 섹터가 헤드 아래로 회전되어 올 때까지 기다리는 과정, 데이터를 전송하는 과정이 필요합니다. 그리고 이 모든 과정을 수행하는 데 걸리는 시간을 디스크 접근 시간(Disk Access Time) 이라고 합니다. 디스크 접근 시간은 탐색 시간, 회전 지연 시간, 데이터 전송 시간을 합쳐 계산할 수 있습니다.

• 탐색 시간(Seek Time) 은 헤드를 데이터가 존재하는 트랙으로 이동시키는 과정에서 소요되는 시간을 의미합니다. 기계적인 이동이기 떄문에 시동 시간이 필요합니다. 액세스할 데이터들의 지역성이 높은 경우에는 헤드의 이동 거리가 짧아지기 때문에 평균 탐색 시간을 단축할 수 있습니다.

• 회전 지연 시간(Rotational Latency) 은 원하는 데이터가 저장된 섹터가 헤드 아래로 회전되어 올 때까지 기다리는데 소요되는 시간을 의미합니다.

• 데이터 전송 시간(Data Transfer Time) 데이터를 전송하는데 소요되는 시간을 의미합니다. 주로, 블록의 크기, 회전 속도, 트랙의 저장 밀도, 버스 전송률 및 제어기 내부 전자회로의 속도에 따라 결정됩니다.

하드 디스크에서 랜덤 액세스보다 순차 액세스가 더욱 빠른 이유가 무엇인가요? 😀

랜덤 액세스의 경우, 디스크 다른 위치에 흩어져 있는 데이터 블록을 읽어야 하기 때문에 헤드를 여러 번 움직여야 하며, 각 블록에 접근할 때마다 회전 지연 시간을 기다려야 합니다. 이러한 기계적인 이동으로 발생하는 지연으로 인해 랜덤 액세스가 순차 액세스보다 상대적으로 느립니다. 반면, 순차 액세스는 데이터가 연속적인 경우 발생하는데요. 상대적으로 랜덤 액세스에 비해 기계적인 이동이 적기 때문에 빠른 속도를 보입니다.

추가 학습 자료를 공유합니다.

• HDD(하드 디스크 드라이브)의 역사, 원리, 미래 [씨게이트 X 안될과학 - 긴급과학]
• 순차(Sequential) I/O와 랜덤(Random) I/O

URI (Uniform Resource Identifier) 는 인터넷에서 자원을 식별하기 위한 문자열입니다. URI는 URL과 URN을 포함하는 상위 개념입니다. 즉, 특정 자원을 식별하기 위한 포괄적인 방법을 제공하며, 자원의 위치나 이름을 나타낼 수 있습니다.

URL (Uniform Resource Locator) 는 URI의 한 형태로, 인터넷상에서 자원의 위치를 나타내는 방식입니다. 자원이 어디에 있는지를 설명하는데 사용되며, 자원에 접근하기 위한 프로토콜을 포함합니다. 예를 들어, 웹페이지의 URL은 해당 페이지가 위치한 서버의 주소와 접근 방법(예: HTTP)을 포함합니다. ex) https://www.example.com/path/to/resource

URN (Uniform Resource Name) 은 URI의 또 다른 형태로, 자원의 위치와 상관없이 자원의 이름을 식별하는 방식입니다. 자원의 위치가 변하더라도 동일한 식별자를 유지할 수 있게 합니다. 특정 스키마를 따르며, 자원에 대한 영구적인 식별자를 제공합니다. ex) urn:isbn:0451450523 (특정 책의 ISBN 번호)

추가 학습 자료를 공유합니다.

• URI, URL 그리고 URN
• 카카오페이 기술 블로그 - URL이 이상해요! Java와 Spring 중 범인은 누구?

CPU 스케줄링은 운영체제가 프로세스들에게 공정하고 합리적으로 CPU 자원을 배분하는 것을 의미합니다. 만약 CPU 스케줄링이 없다면, 반드시 실행되어야 할 프로세스들이 실행되지 못할 수 있으며, 당장 급하지 않은 프로세스가 실행되는 등 무질서한 상태가 발생할 수 있습니다. CPU 스케줄링은 선점형과 비선점형 방식으로 구현할 수 있으며, 다양한 스케줄링 알고리즘이 존재합니다.

선점형 스케줄링과 비선점형은 각각 어떤 특징이 존재하나요? 🤓

• 선점형 스케줄링(Preemptive Scheduling) 은 프로세스가 CPU를 사용하고 있더라도 운영체제가 프로세스로부터 자원을 강제로 빼앗아 다른 프로세스에 할당할 수 있는 방식입니다. 해당 방식은 응답 시간이 낮으며, 효율적이지만 컨텍스트 스위칭 오버헤드가 발생할 수 있으며 경쟁 상태가 발생할 수 있습니다.

• 비선점형 스케줄링(Non-preemptive Scheduling) 은 하나의 프로세스가 자원을 사용하고 있다면 해당 프로세스가 종료되거나 스스로 대기 상태로 전환되기 전까지 다른 프로세스가 자원을 점유할 수 없는 스케줄링 방식을 의미합니다. 컨텍스트 스위칭 비용이 상대적으로 적지만, 응답 시간이 길 수 있습니다.

알고 계신 CPU 스케줄링 알고리즘에 대해서 간략하게 설명해 주세요. 😀

• 선입 선처리 스케줄링(FCFS, First Come First Served Scheduling) 은 준비 큐에 삽입된 순서대로 프로세스들을 처리하는 비선점형 스케줄링 방식입니다. 공정해보이지만, 호위효과(Convoy Effect) 가 발생할 수 있다는 점에서 부작용이 존재합니다. 예를 들어, 준비 큐에 A(실행 시간 10ms), B(실행 시간 5ms), C(실행 시간 2ms)이 순서대로 존재할 때, C 프로세스는 2ms를 실행하기 위해서 15ms를 기다려야 합니다.

• 최단 작업 우선 스케줄링(SJF, Shortest Job First Scheduling) 은 준비 큐에 삽입된 프로세스 들 중에서 CPU 이용 시간이 가장 짧은 프로세스부터 실행되는 비선점형 스케줄링 방식이에요. 호위효과를 방지하고, 평균 대기 시간이 짧다는 이점이 존재합니다. 하지만, CPU 실행 시간이 긴 프로세스는 기아 현상(Starvation) 발생할 가능성이 존재합니다. 기아 현상은 프로세스가 자원을 할당받지 못하고 무한정 준비 큐에 존재하게 되는 상황을 의미합니다.

• 라운드 로빈 스케줄링(RR, Round Robin Scheduling) 은 선입 선처리 스케줄링에 타임 슬라이스(각 프로세스가 CPU를 사용할 수 있는 정해진 시간) 개념이 추가된 방식입니다. 라운드 로빈 방식은 정해진 타임 슬라이스만큼의 시간 동안 돌아가며 CPU를 이용한 선점형 스케줄링 방식입니다. 타임 슬라이스의 크기가 크다면 선입 선출과 비슷해져 호위 효과가 발생할 수 있으며, 너무 작은 경우에는 문맥 교환 비용이 커질 수 있습니다.

• 최소 잔여 시간 우선 스케줄링(SRT, Shortest Remaininng Time Scheduling) 은 최단 작업 우선(SJF)에 선점형 스케줄링을 혼합한 방식입니다. 프로세스가 실행되는 도중 실행 시간이 짧은 프로세스가 추가되면 현재 실행되는 프로세스를 중단하고 해당 프로세스에게 CPU를 할당합니다.

• 다단계 큐 스케줄링(Multilevel Queue Scheduling) 은 우선 순위별로 준비 큐를 여러 개 사용하는 방식입니다. 우선 순위가 가장 높은 큐에 있는 프로세스들을 먼처 처리하고, 우선순위가 가장 높은 큐가 비어 있다면, 그 다음 우선순위 큐의 프로세스들을 처리합니다. 해당 방식은 큐를 여러 개 두어서 프로세스 유형 별로 우선순위를 구분하여 실행하는 것이 편리해지며, 큐별로 타임 슬라이스를 지정하거나, 다른 스케줄링 알고리즘을 사용할 수 있습니다.

우선 순위가 존재하는 스케줄링은 기아 현상이 발생할 텐데, 어떻게 해결할 수 있나요? 🤔

최단 작업 우선(SJF), 최소 잔여 시간(SRT)이나 다단계 큐 스케줄링은 일종의 우선 순위 스케줄링이며, 말씀 주신 기아 현상이 발생할 수 있습니다. 기아 현상을 방지하기 위해서는 대표적으로 에이징 기법이 존재합니다. 에이징(Aging) 이란 오랫동안 대기한 프로세스의 우선순위를 점차 높이는 방식입니다.

예를 들어, 다단계 큐 스케줄링의 기아 현상 문제를 해결하기 위해서 에이징 기법이 적용된 다단계 피드백 큐 스케줄링(Multilevel Feedback Queue Scheduling) 방식이 존재하는데요. 해당 방식은 새로 준비 상태가 된 프로세스가 있다면, 우선순위가 가장 높은 우선순위 큐에 삽입되고 타임 슬라이스 동안 실행됩니다. 만약, 해당 큐에서 실행이 끝나지 않는다면 프로세스는 다음 우선순위 큐에 삽입됩니다.(결국 CPU를 오래 사용해야 하는 프로세스는 점차 우선순위가 낮아집니다.) 만약 우선순위가 낮은 큐에서 너무 오래 기다리고 있는 프로세스가 있다면 점차 우선순위가 높은 큐로 이동시키는 에이징 기법을 적용해 기아 현상을 예방합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 레오, 하디의 Process Scheduling

운영체제는 사용자가 실행하는 프로그램이 하드웨어 자원에 직접 접근하는 것을 방지해 자원을 보호합니다. 왜냐하면, 프로그램이 CPU, 메모리, 하드 디스크에 마음대로 접근하고 조작할 수 있다면, 자원이 무질서하게 관리 될 수 있으며 한 프로그램의 실수가 전체 컴퓨터에 영향을 주기 때문입니다. 운영체제는 프로그램들이 자원에 접근하려 할 때 오직 자신을 통해서만 접근하도록 하여 자원을 보호합니다.

따라서, 프로그램은 자원에 접근하기 위해서 운영체제에게 도움을 요청해야 합니다. 그리고, 프로그램의 요청을 받은 운영체제는 응용 프로그램 대신 자원에 접근해 요청한 작업을 수행합니다. 이러한 과정은 이중 모드로 구현되는데요. 이중 모드(Dual Mode) 는 CPU가 명령을 실행하는 모드를 사용자 모드와 커널 모드로 구분하는 방식입니다.

• 사용자 모드(User Mode) 는 운영체제 서비스를 제공받을 수 없는 실행 모드입니다. CPU가 해당 모드인 경우, 입출력 명령어와 같은 하드웨어 자원 접근 명령을 실행할 수 없습니다. 일반 프로그램은 기본적으로 사용자 모드로 실행됩니다.

• 커널 모드(Kernel Mode) 는 운영체제 서비스를 제공받을 수 있는 실행 모드로 커널 영역의 코드를 실행할 수 있습니다. CPU가 커널 모드로 명령어를 실행하면 자원에 접근하는 명령어를 비롯한 모든 명령어를 실행할 수 있으며, 운영체제는 커널 모드로 실행됩니다.

사용자 모드로 실행되는 프로그램이 자원에 접근하는 운영체제 서비스를 제공받으려면 운영체제에 요청을 보내 커널 모드로 전환되어야 하는데요. 말씀 주신 시스템 콜(System Call) 은 이때 운영체제 서비스를 제공받기 위한 요청을 의미합니다. 시스템 콜은 일종의 소프트웨어 인터럽트입니다. 시스템 콜을 발생시키는 명령어가 실행된다면, CPU는 현재까지의 작업을 백업한 뒤에 커널 영역 내에 시스템 콜을 수행하는 인터럽트 서비스 루틴을 실행한 이후, 다시 기존 실행하고 있었던 프로그램으로 복귀하여 실행을 계속합니다.

추가 학습 자료를 공유합니다.

• 널널한 개발자 - 컴퓨터가 3층집인건 알고 있죠?
• 널널한 개발자 - 인터럽트에서 DirectX까지
• Geekific - Java Native Interface | Guide to JNI | What is JNI? | Geekific

GC(Garbage Collection)는 자바의 메모리 관리 방법의 하나이며, JVM의 힙 영역에서 동적으로 할당했던 메모리 중에서 필요 없어진 객체를 주기적으로 제거하는 것을 의미합니다. GC는 특정 객체가 사용 중인지 아닌지 판단하기 위해서 도달 가능성(Reachability) 라는 개념을 사용하는데요. 특정 객체에 대한 참조가 존재하면 도달할 수 있으며, 참조가 존재하지 않는 경우에 도달할 수 없는 상태로 간주합니다. 이때, 도달할 수 없다는 결론을 내린다면 해당 객체는 GC의 대상이 됩니다.

도달 가능성은 어떻게 판단하나요? 🤓

힙 영역에 있는 객체에 대한 참조는 4가지 케이스가 존재하는데요. 힙 내부 객체 간의 참조, 스택 영역의 변수에 의한 참조, JNI에 의해 생성된 객체에 대한 참조(네이티브 스택 영역), 메서드 영역의 정적 변수에 의한 참조가 이에 해당됩니다. 이때, 힙 내부 객체 간의 참조를 제외한 나머지를 Root Set이라고 합니다. Root Set으로부터 시작한 참조 사슬에 속한 객체들은 도달할 수 있는 객체이며, 이 참조 사슬과 무관한 객체들은 도달하기 어렵기 때문에 GC에 대상이 됩니다.

개발자가 GC 대상 판단에 관여할 수는 없나요? 🤔

Origin o = new Origin();
WeakReference<Origin> wo = new WeakReference<>(o);

자바에서는 java.lang.ref 패키지의 SoftReference, WeakReference 클래스를 통해 개발자가 GC 대상 판단에 일정 부분 관여할 수 있습니다. 해당 클래스들의 객체(reference object)는 원본 객체(referent)를 감싸서 생성하는데요. 이렇게 생성된 객체는 GC가 특별하게 취급합니다. SoftReference 객체에 감싸인 객체는 Root Set으로부터 참조가 없는 경우에, 남아있는 힙 메모리의 크기에 따라서 GC 여부가 결정됩니다. 반면, WeakReference 객체에 감싸인 객체는 Root Set으로부터 참조가 없는 경우, 바로 GC 대상이 됩니다.

추가 학습 자료를 공유합니다.

• 네이버 D2 - Java Reference와 GC

테스트 주도 개발(Test Driven Development) 은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스입니다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성합니다. 그 이후에는 테스트 케이스를 통과하기 위한 최소한의 코드를 생성하고, 작성한 코드를 리팩토링하는 과정을 반복합니다.

테스트 주도 개발 사이클에는 다음과 같이 몇 가지 의식할 부분들이 존재하는데요.

• 일단 간단하고, 해보기 쉬운 것을 먼저 시도합니다.
• 실패하는 테스트를 통과하기 위해서는 최소한의 코드를 작성해야 합니다.
• 테스트를 점점 구체화할수록 프로덕션 코드는 점점 범용적으로 됩니다. (커버 가능한 케이스가 점점 많아집니다.)
• 실패하는 테스트가 있을 때만 프로덕션 코드를 작성합니다.
• 실패를 나타내는 데 충분한 정도의 테스트만 작성합니다.

위와 같은 부분들을 의식하면서, 테스트 주도 개발 사이클을 반복하다 보면, 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있습니다. 또한, 테스트 가능하며 결합이 느슨한 시스템을 점진적으로 만들어 나갈 수 있습니다. 하지만, 테스트 주도 개발이 오히려 비효율적인 경우도 존재하기 때문에 다른 모든 기술과 마찬가지로 비판적으로 사고하는 것도 중요하다고 생각합니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 더즈, 티키의 Classic TDD VS Mockist TDD
• 백명석님 클린 코더스 - TDD part 1
• if(kakao)2020 - kotest가 있다면 TDD 묻고 BDD로 가!
• [3월 우아한테크세미나] 우아한ATDD
• 우아콘2023 - 지속 가능한 인수 테스트 주도 개발

평문을 암호화하고 복호화하는 경우 키를 사용할 수 있는데요. 이때, 암복호화에 사용하는 키가 동일한 경우 대칭키 암호화(Symmetric Key Cryptography) 라고 하며, 암복호화에 사용하는 키가 서로 다른 경우를 비대칭키 암호화 혹은 공개키 암호화(Asymmetric Key Cryptography) 라고 합니다.

대칭키 암호화는 비대칭키 암호화에 비해서 속도가 빠르다고 알려져 있습니다. 하지만, 대칭키를 교환하는 과정에서 탈취 위험성이 존재할 수 있습니다. 또한, 대칭키 암호화 방식에서는 각 통신 참여자 쌍마다 다른 키가 필요할 수 있는데요. 이 경우 통신 대상이 많아질수록 대칭키의 수가 많아지므로 키 관리가 복잡해질 수 있습니다.

비대칭키 암호화에는 공개키와 개인키가 존재합니다. 일반적으로 이 방식에서 송신자는 수신자의 공개키를 이용해 암호화를 수행하고, 암호화된 데이터는 수신자에게 전달됩니다. 수신자에게 전달된 이후, 수신자는 개인키를 사용해 복호화를 수행합니다. 이 방식은 대칭키 암호화 방식에서 발생하는 키 교환 문제를 해결하지만, 상대적으로 대칭키 암호화에 비해 느린 것이 단점입니다.

비대칭키 암호화에서 개인키로 데이터를 암호화하고, 공개키로 복호화하는 경우도 존재하는데요. 이러한 방식은 암호화를 수행한 자에 대한 검증이나 서명을 위한 용도로 사용됩니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 알린의 암호

클래스풀 주소 체계(Classful Addressing) 은 IP 주소를 규격화된 크기별로 구분시키는 방식입니다. IP 주소를 클래스(A,B,C 등)별로 규격화(유형화)시켜, 쉽게 식별할 수 있도록 합니다.

IPv4 주소는 4바이트(32비트)이며, 1바이트씩 끊어서 표기합니다. 이때 각 바이트를 옥텟이라고 부르며, 각 옥텟은 0부터 255까지의 숫자를 표현할 수 있어요. ex) 0.0.0.0 ~ 255.255.255.255

• A 클래스는 초기 비트가 0(2진수)으로 시작하는 1옥텟을 네트워크 주소로 사용하며, 3옥텟을 호스트 주소로 사용합니다. 호스트 주소의 0과 255는 특수한 용도(전자는 네트워크 식별, 후자는 브로드캐스트 주소)로 사용되므로, A 클래스에는 2^7개의 네트워크 수와 2^24 - 2개의 호스트를 가질 수 있습니다.

• B 클래스는 초기 비트가 10(2진수)으로 시작하는 2옥텟을 네트워크 주소로 사용하며, 2옥텟을 호스트 주소로 사용합니다. 따라서, B 클래스에는 2^14개의 네트워크와 2^16 - 2개의 호스트를 가질 수 있습니다.

• C 클래스는 초기 비트가 110(2진수)으로 시작하는 3옥텟을 네트워크 주소로 사용하며, 1옥텟을 호스트 주소로 사용합니다. 따라서, C 클래스에는 2^21개의 네트워크와 2^8 - 2개의 호스트를 가질 수 있습니다.

클래스풀 주소 체계는 클래스별로 네트워크 크기가 고정되어 있기 때문에 다수의 IP 주소가 낭비될 수 있다는 한계점이 존재합니다. 예를 들어, 특정 조직에 컴퓨터가 255개라면 C 클래스 주소를 사용하지 못하고, B 클래스를 사용해야 하는데요. 이러한 상황에서 IP 주소의 낭비가 발생할 수 있습니다. 이러한 문제를 해결하고, 더욱 유동적인 방식으로 네트워크를 구획할 수 있도록 클래스리스 주소 체계가 등장했습니다.

클래스리스 주소 체계는 무엇인가요? 🤔

클래스리스 주소 체계는(Classless Addressing) 클래스가 아닌 서브넷 마스크를 이용해 네트워크 주소와 호스트 주소를 구분하는 IP 주소 체계입니다. 이때, 서브넷 마스크는 네트워크 구분을 위한 비트열을 의미합니다. 해당 비트열에서 네트워크 주소는 연속된 1(이진수), 호스트 주소는 연속된 0(이진수)으로 표현합니다. 특정 IP 주소와 서브넷 마스크를 비트연산을 수행하면, 네트워크 주소를 알아낼 수 있습니다. 예를 들어, 서브넷 마스크가 255.255.255.0, IP 주소가 168.168.168.168인 경우, 비트연산을 수행하면 네트워크 주소인 168.168.168.0 를 알아낼 수 있습니다. 이 경우, 1옥텟을 호스트 주소로 사용할 수 있습니다.

서브넷 마스크를 표기할 때는 CIDR(Classless Inter Domain Routing Notation) 표기법을 사용할 수 있는데요. IP 주소/서브넷 마스크 비트열의 1의 수 형식으로 표현합니다. IP 주소가 168.168.168.168이며, 서브넷 마스크가 255.255.255.0인 경우에는 168.168.168.168/24 와 같이 표기할 수 있습니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 에덴의 서버 네트워크
• [10분 테코톡] 에밀의 IP
• 널널한 개발자 - IP주소의 종류와 특징
• 네트워크 기초 강의 - IP 주소의 구조와 클래스풀 주소 체계
• 네트워크 기초 강의 - 클래스리스 주소 체계와 서브네팅

함수형 프로그래밍(Functional Programming) 은 객체지향 패러다임과 마찬가지로 하나의 프로그래밍 패러다임입니다. 객체지향 프로그래밍은 움직이는 부분을 캡슐화하여 코드의 이해를 도우며, 함수형 프로그래밍은 움직이는 부분을 최소화하여 코드 이해를 돕습니다. 이 둘은 상충하는 개념이 아니며, 함께 조화되어 사용될 수 있습니다. 함수를 합성하여 복잡한 프로그램을 쉽게 만들고, 부수 효과를 공통적인 방법으로 추상화하는 것이 함수형 프로그래밍의 핵심 개념입니다.

부수 효과(Side Effect) 는 값을 반환하는 것 이외에 부수적으로 발생하는 일들을 의미해요. 변수를 수정하거나, I/O 작업 등이 해당됩니다. 사람이 한 번에 인지할 수 있는 작업은 한정되어 있습니다. 부수 효과가 많은 코드는 이해하고 결과를 예측하기 어려울 수 있습니다. 함수형 프로그래밍은 부수 효과를 추상화하고 분리하여 코드를 이해하기 쉽게 만들 수 있습니다.

함수를 합성한다는 게 무슨 의미인지 궁금해요. 🤔

특정 함수의 공역이 다른 함수의 정의역과 일치하는 경우, 두 함수를 이어서 새로운 함수를 만드는 연산을 함수 합성(Function Composition) 이라고 해요. 프로그래밍에서 공역과 정의역은 타입에 해당됩니다. 쉽게 말씀드리자면, A 함수에서 int 타입을 반환하고, B 함수에서 int 타입을 인자로 받는다면, B(A())와 같은 형태로 호출하는 것을 함수 합성이라고 합니다.

함수형 프로그래밍은 함수를 합성하여 복잡한 프로그램을 쉽게 만듭니다. 함수는 입력이 들어오면 부수 효과의 발생과 함께 결과를 반환할 수 있습니다. 하지만, 부수 효과가 존재하는 함수는 합성하기가 까다롭습니다.

// 부수효과가 존재하는 sum 함수는 다른 함수와 합성하기 까다로울 수 있다.
//     1. 다른 함수에서 1부터 1,000까지 더하는 함수가 필요하다면?
//     2. 다른 함수에서 1부터 100까지 곱하는 함수가 필요하다면?
int sum() {
    int sum = 0;
    for(int i = 1; i <= 100; i++) {
        sum += i;
    }

    return sum;
}

순수 함수(Pure Function) 은 같은 입력이 들어오면, 항상 같은 값을 반환하는 함수를 의미하는데요. 순수 함수는 부수효과를 일으키지 않습니다. 함수형 프로그래밍에서 함수 합성은 순수 함수로 이뤄집니다.

class FunctionCompositionTest {

    @Test
    @DisplayName("함수 합성")
    void fp() {
        System.out.println(sum()); 
        System.out.println(factorial(10));
    }

    // 1부터 100까지의 합
    private int sum() {
        return loop((a, b) -> a + b, 0, range(1, 100));
    }

    // 팩토리얼
    private int factorial(int n) {
        return loop((a, b) -> a * b, 1, range(1, n));
    }

    private int loop(BiFunction<Integer, Integer, Integer> fn, int sum, Queue<Integer> queue) {
        if (queue.isEmpty()) {
            return sum;
        }

        return loop(fn, fn.apply(sum, queue.poll()), queue);
    }

    private Queue<Integer> range(Integer start, Integer to) {
        return IntStream.rangeClosed(start, to)
                .boxed()
                .collect(Collectors.toCollection(LinkedList::new));
    }
}

추가 학습 자료를 공유합니다.

• [10분 테코톡] 🍩도넛의 함수형 프로그래밍
• [10분 테코톡] 쿠마의 커링
• 얄팍한 코딩사전 - 함수형 프로그래밍 - 개발자 내공 업그레이드하기
• So You Want to be a Functional Programmer (Part 1)
• So You Want to be a Functional Programmer (Part 2)
• So You Want to be a Functional Programmer (Part 3)
• So You Want to be a Functional Programmer (Part 4)
• So You Want to be a Functional Programmer (Part 5)
• So You Want to be a Functional Programmer (Part 6)

연결 리스트(Linked List) 는 리스트 내의 요소(노드)들을 포인터로 연결하여 관리하는 선형 자료구조입니다. 각 노드는 데이터와 다음 요소에 대한 포인터를 가지고 있는데요. 이때, 첫 번째 노드를 HEAD, 마지막 노드를 TAIL 이라고 합니다. 연결 리스트는 메모리가 허용하는 한 요소를 계속 삽입할 수 있으며, 시각 복잡도는 탐색에는 O(n), 노드 삽입과 삭제는 O(1)라는 특징을 가지고 있습니다. 해당 아이디어로 파생된 자료구조는 단일 연결 리스트(Singly Linked List), 이중 연결 리스트(Doubly Linked List, Circular Linked List)가 존재합니다.

배열은 순차적인 데이터가 들어가기 때문에 메모리 영역을 연속적으로 사용합니다. 반면, 연결 리스트는 메모리 공간에 흩어져서 존재한다는 점에서 배열과 차이가 있습니다.

단일 연결 리스트의 탐색, 추가, 삭제에 대해서 더욱 자세히 설명해 주세요. 🤔

class SinglyLinkedList {

    public Node head;
    public Node tail;

    public Node insert(int newValue) {
        Node newNode = new Node(null, newValue);
        if (head == null) {
            head = newNode;
        } else {
            tail.next = newNode;
        }
        tail = newNode;

        return newNode;
    }

    public Node find(int findValue) {
        Node currentNode = head;
        while (currentNode.value != findValue) {
            currentNode = currentNode.next;
        }

        return currentNode;
    }

    public void appendNext(Node prevNode, int value) {
        prevNode.next = new Node(prevNode.next, value);
    }

    public void deleteNext(Node prevNode) {
        if (prevNode.next != null) {
            prevNode.next = prevNode.next.next;
        }
    }
}

단일 연결 리스트에서 탐색은 최악의 경우, 시간 복잡도는 O(n)입니다. 왜냐하면, 노드를 탐색하기 위해서 HEAD의 포인터부터 데이터를 찾을 때까지 다음 요소를 반복적으로 탐색하기 때문입니다.

삽입의 경우, 삽입될 위치 이전에 존재하는 노드와 신규 노드의 포인터를 조작하면 됩니다. 가령, 3번 위치에 신규 노드를 삽입해야 한다면 2번 위치에 있는 노드의 포인터를 신규 노드를 가리키도록 하고, 신규 노드의 포인터는 기존 3번 노드의 위치를 가리키도록 하면 됩니다. 삭제는 삭제할 노드의 이전 노드가 삭제 대상 노드의 다음 노드를 가리키도록 수정하고, 삭제 대상 노드를 메모리에서 지우면 됩니다. 삽입과 삭제 연산 자체의 경우 시간 복잡도는 O(1)이지만, 탐색이 필요한 경우 선형 시간이 걸립니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 🐻 중간곰의 선형 자료구조
• 널널한 개발자 - 단일 연결 리스트 구현 첫 번째

IP 주소는 공인 IP 주소(Public IP Address) 와 사설 IP 주소(Private IP Address) 가 존재합니다. 공인 IP 주소는 고유하며, 사설 IP 주소는 고유하지 않고 특정 사설 네트워크에서만 사용됩니다. 이때, 사설 네트워크는 외부 네트워크에 공개되지 않은 네트워크를 의미합니다. 사설 IP는 일반적으로 라우터가 할당하며, 할당받은 사설 IP 주소는 사설 네트워크 상에서만 유효합니다.

사설 IP 주소만을 가지고 외부 네트워크와 통신하기 어렵습니다. 이 문제를 해결하기 위해서 라우터 혹은 공유기의 NAT(Network Address Translation) 기능을 사용하는데요. NAT는 IP 주소를 변환하는 기술입니다. 해당 기능을 사용하면, 사설 IP 주소를 외부 네트워크에 사용되는 공인 IP 주소로 변환하여 외부 네트워크와 통신할 수 있습니다.

예를 들어, 사설 네트워크에서 출발한 패킷에 존재하는 사설 IP 주소(송신지)가 라우터를 거쳐 공인 IP로 변경됩니다. 그리고, 외부 네트워크로부터 출발한 패킷에 존재하는 공인 IP 주소(수신지)는 NAT 기능을 통해서, 사설 IP 주소로 변경되고 사설 네트워크 속 호스트에게 전달됩니다. NAT에서 주소 변환을 하기 위해서 내부적으로 공인 IP 주소와 사설 IP 주소가 대응되어 있는 NAT 변환 테이블을 사용합니다.

NAT 변환 테이블에서 공인 IP 주소와 사설 IP 주소는 일대일로 대응되어 있나요? 🤔

일대일 대응이라면 사설 IP 주소만큼 공인 IP가 필요하기 때문에 한계가 있습니다. 따라서, 일반적으로 공인 IP와 사설 IP가 일대일로 대응하지 않고, NAPT(Network Address Port Translation) 이라는 포트 기반의 NAT를 사용합니다. 해당 기능에서는 NAPT 변환 테이블에 IP 주소 쌍과 함께 포트도 함께 기록됩니다. 다음은 NAPT 변환 테이블의 예시입니다.

추가 학습 자료를 공유합니다.

• [10분 테코톡] 애쉬의 AWS 살짝 알은체 하기
• AWS Korea - AWS를 사용한다면 반드시 알아야 할 네트워크 기초 지식
• AWS - NAT 게이트웨이 사용 사례

사이트 간 요청 위조(Cross-site Request Forgery, CSRF) 공격은 사용자가 자신의 의지와 상관없이 공격자가 의도한 행위를 특정 웹사이트에 요청하도록 하는 것을 의미합니다.

예를 들어, 특정 사용자가 매일메일 서비스에서 로그인을 수행하고 서버는 해당 사용자에 대한 세션 ID를 Set-Cookie 헤더에 담아서 응답합니다. 그리고, 클라이언트는 쿠키를 저장하고 요청마다 자동으로 전달합니다.

이러한 사용자를 대상으로 공격자는 악성 스크립트가 담긴 페이지에 접속하도록 유도합니다. 유도하는 방법은 다양한데요. 악성 스크립트가 포함된 메일이나 게시글을 작성하거나, 악성 스크립트가 포함된 공격자 사이트 접속 링크를 전달하는 것이 대표적입니다.

사용자가 악성 스크립트가 포함된 페이지에 접속하게 되면 악성 스크립트가 실행됩니다. 이 스크립트는 사용자의 의도와 상관없는 특정한 요청(결제, 비밀번호 변경)을 공격 대상 서버로 보내도록 구현되어 있습니다. 해당 요청은 브라우저에 의해서 자동으로 쿠키에 저장된 세션 ID가 함께 전달됩니다.

예를 들어, 공격자가 만든 사이트 내부에는 다음과 같은 태그가 존재할 수 있습니다.

<img src ="https://maeil-mail.com/member/changePassword?newValue=1234" />

공격자 사이트에 방문한 사용자는 자신의 의지와 무관하게 img 태그로 인해 세션 ID가 포함된 쿠키와 함께 비밀번호 변경 요청을 매일메일 서버로 전달합니다.

CSRF 공격은 어떻게 방어할 수 있나요? 🤓

교차 출처인 상황에서의 요청을 막는 방식으로 CSRF를 방어할 수 있습니다.

첫 번째로, HTTP 헤더 중에 하나인 Referer 요청 헤더를 사용하는 방법이 있습니다. Referer 요청 헤더로 현재 요청을 보낸 페이지의 주소를 알 수 있는데요. 해당 주소와 Host(서버의 도메인 이름) 헤더를 비교하여 다른 경우, 예외를 발생시킬 수 있습니다. 하지만, Referer 요청 헤더는 조작될 수 있다는 점에서 한계가 있습니다.

두 번째로, 템플릿 엔진 기술을(JSP, 타임리프, Pug, Ejs 등) 사용하고 있는 경우라면 CSRF 토큰 방법을 사용해 볼 수 있습니다. 페이지를 생성하기 이전에 사용자 세션에 임의의 CSRF 토큰을 저장합니다. 그리고, 특정 API 요청에 대한 제출 폼을 생성할 때 해당 CSRF 토큰값이 설정된 input 태그를 추가합니다.

<input type = "hidden" name = "csrf_token" value = "csrf_token_12341234" />

실제로 요청이 전달될 때, 해당 input 태그의 CSRF 토큰과 사용자 세션 내부에 존재하는 CSRF 토큰의 일치 여부를 판단하여, CSRF 공격에 대해 방어할 수 있습니다.

이외에도 SameSite 쿠키를 사용하여 크로스 사이트에 대한 쿠키 전송을 제어하거나, 브라우저의 SOP(Same Origin Policy) 정책을 사용하고, CORS 설정으로 교차 출처 접근을 일부분 허용하는 방식으로도 CSRF 공격을 방어할 수 있습니다.

추가 학습 자료를 공유합니다.

• "Same-site" and "same-origin"
• MDN - 동일 출처 정책
• 레드팀 - CSRF Token에 관하여
• CSRF(Cross-Site Request Forgery) Attack and Defence
• 브라우저 쿠키와 SameSite 속성

트랜잭셔널 아웃박스 패턴(Transactional Outbox Pattern) 은 분산 시스템에서 단일 작업에 데이터베이스 쓰기 작업과 메시지 혹은 이벤트 발행이 모두 포함된 경우 발생하는 이중 쓰기 문제를 해결하기 위해서 사용할 수 있습니다. 예를 들어, 다음과 같은 코드가 존재한다고 가정하겠습니다.

@Transactional
public void propagateSample() {
   Product product = new Product("신규 상품");
   productRepository.save(product);
   eventPublisher.propagate(new NewProductEvent(product.getId()));
}

위와 같이 신규 상품을 생성하고, 이벤트를 발행하는 코드를 트랜잭션 AOP 로직이 적용된 간단한 의사코드로 작성한다면 다음과 같을 텐데요.

public void doInTransaction() {
   try {
     transaction.begin();
     Product product = new Product("신규 상품");
     productRepository.save(product);
     eventPublisher.propagate(new NewProductEvent(product.getId()));
     transaction.commit();
   } catch(Exception e) {
     transaction.rollback();
   }
}

위와 같은 코드에서 트랜잭션은 커밋됐지만 이벤트 발행은 실패할 수 있으며, 반대로 이벤트 발행은 성공했지만 커밋 연산이 모종의 이유로 실패하여 트랜잭션은 롤백 될 수 있습니다. 이러한 이중 쓰기로 인해 발생하는 문제는 전체 서비스의 데이터 정합성에 문제를 만들거나 서비스 장애로 이어질 수 있습니다. 이 문제를 해결하기 위해서 서비스 로직의 실행과 이벤트 발행을 원자적으로 함께 수행하는 것을 트랜잭셔널 메시징(Transactional Messaing) 이라고 하며, 트랜잭셔널 아웃박스 패턴의 사용 이유기도 합니다.

@Transactional
public void propagateSample() {
   Product product = new Product("신규 상품");
   productRepository.save(product);
   productOutboxRepository.save(new ProductEvent(product.getId()));
}

Product 발행 이벤트를 저장하기 위한 Outbox 테이블을 만들고, 같은 트랜잭션 내부에서 이벤트를 저장합니다. 원자성을 보장해 주는 데이터베이스 트랜잭션을 사용하기 때문에 이벤트와 신규 상품은 모두 저장되거나, 모두 저장에 실패합니다. 그리고, 별도의 프로세스가 Outbox 테이블에 저장된 레코드들을 주기적으로 폴링하여 외부 시스템에 성공할 때까지 이벤트를 발행하는 것이 트랜잭셔널 아웃 박스 패턴의 기본적인 구현 방식입니다.

추가 학습 자료를 공유합니다.

• AWS 클라우드 설계 패턴, 아키텍처 및 구현 - 트랜잭션 아웃박스 패턴
• 강남언니 공식 블로그 - 분산 시스템에서 메시지 안전하게 다루기
• 트랜잭셔널 아웃박스 패턴의 실제 구현 사례 (29CM)
• [NHN FORWARD 22] 분산 시스템에서 데이터를 전달하는 효율적인 방법
• 제미니의 개발실무 - 효과적인 이벤트 발송 방법 (feat. Transactional Outbox, Polling, Async)

JWT(Json Web Token) 은 통신 정보를 JSON 형식을 사용하여 안전하게 전송하기 위해 사용됩니다. JWT는 토큰 자체에 정보가 포함되어 있는 클레임 기반 토큰입니다. 일반적인 애플리케이션에서 JWT는 주로 인증과 인가를 구현하기 위해 사용됩니다. JWT는 헤더, 페이로드, 시그니처로 구분됩니다. 헤더에는 토큰의 암호화 알고리즘이나 타입을 가지며, 페이로드에는 데이터(만료일, 사용자 정보 등)을 가집니다. 시그니처는 헤더와 페이로드가 변조되지 않았는지 판단하기 위해 사용되는데요. 헤더와 페이로드를 비밀 키를 사용하여 헤더에 명시된 암호화 알고리즘으로 암호화하여 시그니처가 만들어집니다.