1. 동기 연동 (Synchronous Integration) 방식

동기 방식은 코드가 순차적으로 실행되며, 한 작업이 끝날 때까지 다음 작업이 진행되지 않는 방식입니다. 이는 코드의 흐름을 직관적으로 이해하고 디버깅하기 쉽다는 장점이 있습니다.

동기 방식 연동의 문제점

그러나 외부 서비스 연동 시 동기 방식을 사용하면 여러 문제가 발생합니다.

1. 전체 기능 실패 위험: 외부 연동이 실패하면 해당 연동이 필수적이라고 가정했을 경우, 전체 기능(예: 포인트 지급 실패 시 로그인 실패)까지 사용할 수 없게 되어 전체 서비스가 마비될 수 있습니다.
2. 응답 시간 증가: 연동 서비스의 응답 시간이 길어지면 전체 응답 시간이 느려지며, 심한 경우 외부 연동 서비스로 인해 전체 서비스가 먹통이 되기도 합니다.

비동기 연동의 필요성

다음 작업을 진행하기 위해 반드시 외부 연동 결과가 필요한 것이 아니라면, 동기 방식 대신 비동기 방식을 고려해야 합니다.

• 비동기 연동 (Asynchronous Integration): 한 작업이 끝날 때까지 기다리지 않고 바로 다음 작업을 처리하여, 외부 연동이 끝날 때까지 기다리지 않고 다음 작업을 진행할 수 있습니다.
• 주요 이점: 사용자는 연동 시간에 소요되는 시간만큼 더 빠르게 응답을 받을 수 있으며, 연동 서비스에 문제가 생겨도 메인 서비스의 응답 시간은 증가하지 않습니다.

2. 비동기 연동 구현 5가지 방식

5장에서 다루는 비동기 연동 구현 방식은 다음과 같습니다:

1. 별도 스레드로 실행하기
2. 메시징 시스템 이용하기
3. 트랜잭션 아웃박스 패턴 사용하기
4. 배치로 연동하기
5. CDC 이용하기

(1) 별도 스레드로 실행하기

가장 쉽고 간단하게 비동기 연동을 구현하는 방법입니다.

• 구현: 새로운 스레드를 생성하여 연동 코드를 실행하거나, 스레드 풀(ExecutorService)을 사용하거나, 스프링 프레임워크의 @Async 애너테이션 같은 프레임워크 기능을 이용할 수 있습니다.
• 주의 사항:
  • @Async 사용 시, 해당 메서드가 비동기로 실행된다는 사실을 호출하는 쪽에서 알기 어려울 수 있으므로, 메서드 이름에 비동기 실행과 관련된 단어를 추가하여 가독성을 높이는 것이 좋습니다.
  • 익셉션 전파 불가: 별도 스레드로 실행되는 코드는 익셉션이 전파되지 않기 때문에, 연동 과정에서 발생한 오류를 코드 내부에서 직접 처리해야 합니다 (예: 재시도, 실패 로그 남기기).
  • 메모리 및 CPU 부하: 대량의 작업을 처리할 때 순간적으로 많은 스레드를 생성하면 메모리 사용량이 증가하고 CPU 스케줄링 부하가 발생할 수 있습니다. 스레드 풀을 사용하거나, 가상 스레드 또는 Go 언어의 고루틴 같은 경량 스레드를 고려할 수 있습니다.

(2) 메시징 시스템 이용하기

서로 다른 시스템 간에 비동기로 연동할 때 주로 사용되는 방식입니다. 메시징 시스템이 두 시스템 사이에 위치하여 메시지를 주고받습니다.

• 작동 방식: 시스템 A(생산자)가 메시지를 생성하여 메시징 시스템에 전송하면, 메시징 시스템은 이 메시지를 시스템 B(소비자)에 전달합니다.
• 주요 이점:
  • 버퍼 역할: 시스템 A의 트래픽이 증가하더라도 메시징 시스템이 메시지를 저장하는 버퍼 역할을 하므로, 시스템 B의 성능 저하가 시스템 A에 영향을 미치지 않습니다.
  • 확장 용이성: 시스템 A의 코드를 수정하지 않고도 메시징 시스템에 새로운 시스템 C를 연결하여 데이터를 수신하게 할 수 있어 확장이 용이합니다.
• 생산자 (Producer) 고려 사항:
  • 트랜잭션 연동: DB 트랜잭션이 완료된 (커밋/롤백된 후) 메시지를 전송해야, 트랜잭션 롤백으로 인해 잘못된 메시지가 발송되는 문제를 방지할 수 있습니다.
  • 메시지 전송 실패 처리: 타임아웃 등으로 전송에 실패할 경우, 오류를 무시하거나, 재시도(중복 메시지 전송 위험이 있음)하거나, 실패 로그를 남겨 후처리해야 합니다.
• 소비자 (Consumer) 고려 사항:
  • 중복 처리 방지: 생산자의 재시도나 소비자의 재수신으로 인해 중복 처리가 발생할 수 있으므로, 메시지마다 고유 식별자(ID)를 부여하여 이미 처리한 메시지는 무시해야 합니다.
  • 멱등성 (Idempotent): 메시지 재수신에 따른 중복 처리에 대응하기 위해 API를 멱등성을 갖도록 구현해야 합니다.
• 메시지 종류:
  • 이벤트 (Event): 어떤 일이 발생했음을 알려주는 메시지 ('주문함', '배송을 완료함'). 정해진 수신자가 없으며, 소비자 확장에 적합합니다.
  • 커맨드 (Command): 무언가를 요청하는 메시지 ('포인트 지급하기', '로그인 차단하기'). 메시지를 수신할 기능(시스템)이 정해져 있습니다.

(3) 트랜잭션 아웃박스 패턴 (Transactional Outbox Pattern) 사용하기

메시지 데이터 유실을 방지하고 DB 트랜잭션과 메시지 전송을 안전하게 분리하는 패턴입니다.

• 핵심 원리: 실제 업무 로직의 DB 변경 작업과 메시지 데이터를 아웃박스 테이블(Outbox Table)에 추가하는 작업을 하나의 DB 트랜잭션 내에서 수행합니다.
• 동작 과정:
  1. 업무 로직 수행 및 메시지 데이터를 아웃박스 테이블에 저장 (DB 트랜잭션 내).
  2. 트랜잭션 커밋. (트랜잭션 롤백 시 메시지 데이터도 함께 롤백되어 잘못된 메시지 전송 방지).
  3. 별도의 메시지 중계 프로세스가 주기적으로 아웃박스 테이블을 조회하여 메시징 시스템에 전송.
  4. 전송에 성공하면 아웃박스 테이블에 발송 완료 상태를 표기합니다.
• 순서 보장: 메시지 전송 순서가 중요하다면, 메시지 중계 프로세스가 특정 메시지 발송에 실패했을 때 루프를 멈추고 다음 재시도를 기다려야 합니다.

(4) 배치 전송 (Batch Transmission)

일정 간격으로 데이터를 전송하는 전통적인 비동기 연동 방법입니다. 메시징 시스템이 실시간 연동을 목표로 한다면, 배치는 특정 간격(예: 다음 날, 1시간 간격)으로 데이터를 전송합니다.

• 전형적인 과정:
  1. DB에서 전송할 데이터를 조회합니다.
  2. 조회 결과를 파일(CSV, JSON 등)로 기록합니다.
  3. FTP/SFTP/SCP와 같은 프로토콜을 이용해 파일을 연동 시스템에 전송합니다.
• 협의 사항: 파일 전송 시 송수신 주체, 시간, 경로 및 파일 이름 규칙 등을 사전에 협의해야 합니다.
• 소비자 시스템 동작: 소비자 시스템은 처리 완료 후 같은 파일이 중복 처리되는 것을 막기 위해 파일을 다른 폴더로 이동(백업)해야 합니다.
• 대안: 데이터 크기가 작거나 처리 항목이 적을 경우, 파일 대신 API를 이용해 일괄 전송하는 방식을 고려할 수 있으며, 같은 조직 내에서는 보안이 덜 엄격할 경우 읽기 전용으로 DB에 직접 접근하게 하는 방법도 있습니다.
• 오류 대응: 전송에 실패하면 일정 시간 후에 재전송하는 기능을 구현해두는 것이 수작업을 줄이는 데 도움이 됩니다.

(5) CDC (Change Data Capture) 이용하기

DBMS가 제공하는 데이터 변경 통지 기능을 활용하여, 변경된 데이터를 추적하고 대상 시스템에 전파하는 소프트웨어 설계 패턴입니다.

• 동작 원리: DB 데이터가 변경되면 (INSERT, UPDATE, DELETE), DB는 커밋된 변경분 데이터를 순서에 맞게 CDC 처리기에 전송합니다. CDC 처리기는 이 변경 데이터를 가공하거나 변환하여 대상 시스템(DB, 메시징 시스템, API 등)에 전파합니다.
• 이점:
  • 코드 수정 최소화: 기존 시스템의 연동 코드를 추가하거나 수정하기 부담스러울 때 유용합니다.
  • 데이터 동기화: DB 간 데이터 동기화가 목적이라면 DB와 DB 사이에 CDC를 두어 데이터를 복제할 수 있습니다.
  • 확장성: 변경 데이터를 메시징 시스템에 전파하면 여러 시스템에 데이터를 전달할 수 있어 확장에 유리합니다.
• 참고: CDC는 데이터의 변경 분을 전달하며, 이는 이벤트 메시지와 유사하지만 변경 분을 통해 의미를 도출해야 하므로 이벤트처럼 정확하게 의미를 전달하지는 못합니다.

• 블로킹이란 작업이 완료될때까지 스레드가 대기하는 것을 의미한다.
• 주로 데이터의 입출력 과정에서 블로킹이 발생하기 때문에 블로킹 IO 라고도 한다.

컨텍스트 스위칭

• 운영체제는 여러 스레드를 번갈아 가면서 CPU에 할당한다.
• CPU가 스레드를 전환하려면 현재 실행중인 스레드의 상태를 기록하고 다음에 실행할 스레드의 상태 정보를 불러와야 한다.

트래픽이 증가하면 다음 2가지 이유로 자원 효율이 떨어진다.

• IO대기와 컨텍스트 스위칭에 따른 CPU 낭비
• 요청마다 스레드를 할당함으로써 메모리 사용량이 높음

→ 톰캣과 같은 요청마다 스레드를 할당하는 서버를 사용하면 CPU나 메모리 낭비가 많을 수 있음.

하지만 이정도의 트래픽을 일으키는 서버는 많지 않이게 현재에도 많이 쓰인다.

서버 성능을 높이는 다른 방법은 자원 효율을 높이는 것이다. IO 대기로 인한 CPU의 자원 낭비를 줄이고 요청을 처리하는데 드는 메모리를 줄이는 것이다.

• 가상 스레드나 고루틴같은 경량 스레드 사용
• 논블로킹 또는 비동기 IO 사용

가상스레드 사용하기

1. 자바의 가상 스레드나 GO 언어의 고루틴을 사용하면 입출력동안 스레드가 대기하지 않고 다른 일ㅇ르 할 수 있다.
2. 경량 스레드를 사용하면 OS가 사용하는 스레드가 아니라 런타임이 관리하는 스레드를 사용하기 때문에 OS가 관리하는 스레드보다 더 적은 자원을 사용한다.
3. JVM은 기본적으로 풀에 CPU 코어 개수만큼 플랫폼 스레드를 생성한다.
4. 가상 스레드는 수백 바이트에서 수 KB, 수십 KB 까지 힙 메모리를 사용한다. 호출 스택의 깊이에 따라 사용하는데 메모리를 동적으로 늘렸다가 줄인다.
5. 스레드를 생성하는 시간도 차이가 많이난다.
6. 그렇기에 톰캣처럼 요청별 스레드를 생성하는 서버에서 가상 스레드를 사용하면 획기적으로 많은 메모리를 아낄수 있다.
   • 한개의 캐리어 스레드가 여러 가상 스레드를 실행하게 된다. 특정 가상 스레드가 캐리어 연결되는 것을 마운트, 연결이 해제되는 것을 언마운트 라고 한다.

네트워크 IO 와 가상 스레드

1. 가상 스레드는 실행하는 과정에서 블로킹되면 플랫폼 스레드와 언마운트되고 다른 실행 대기중인 플랫폼 스레드와 연결된 뒤 실행을 재개한다.
2. 블로킹 연산에는 IO 기능, ReentrantLock, Thread.sleep() 등이 포함된다. 이들 연산을 사용해서 가상 스레드가 블로킹되면 플랫폼 스레드는 대기 중인 다른 가상 스레드를 실행한다.
3. 반면에 자바 23 또는 이전 버전에서 synchronized 인해 블로킹되면 가상 스레드는 플랫폼 스레드로부터 언마운트 되지 않는다.
4. 이렇게 가상 스레드가 플랫폼 스레드까지 블로킹할 때 이를 가상 스레드가 플랫폼 스레드에 고정됐다 라고 한다.

가상 스레드와 성능

1. IO 중심 작업과 CPU 중심 작업이 있을 수 있으나 가상 스레드가 효과를 볼 수 있는 작업은 IO 중심 작업임.
2. IO 중심 작업일 때 플랫폼 스레드가 CPU 낭비 없이 효율적으로 가상 스레드를 실행할 수 있음
3. 반면에 CPU 중심 작업에 가상 스레드가 쓰이면 성능 개선 효과를 얻을 수 없음 오히려 나빠짐
4. 또한 IO 중심 작업이라고 해서 무조건 성능에 이점을 가지는 것은 아님.
5. 스케줄링에 사용되는 플랫폼 스레드 개수보다 가상 스레드의 개수가 많아야 효과를 기대할 수 있음.
6. 가상 스레드가 이점을 얻을 수 있는 부분은 처리량임.

가상 스레드의 장점

• 가상스레드의 장점은 기존 코드를 크게 수정할 필요가 없다는 것임.

논블로킹 IO 로 성능 높이기

• 사용자가 폭발적으로 증가하면 어느 순간 경량 스레드로는 한계가 온다. 이때에는 서버의 IO 구현 방식을 논블로킹 IO 로 변경해야한다.

논블로킹 IO 의 동작과정

1. 논블로킹 IO는 입출력이 끝날때까지 스레드가 대기하지 않는다.
2. 논블로킹 IO 를 사용하는 코드는 대기하지 않고 다음 줄의 코드가 바로 실행된다.
3. 그렇기에 논블로킹 IO 를 사용할 때에는 데이터 읽기를 바로 시도하기 보다 어떤 연산을 수행할 수 있는지 확인 후 해당 연산을 실행하는 방식을 사용한다.
   1. 실행 가능한 IO 연산 목록을 구한다.
   2. a에서 구한 IO 연산 목록을 차례로 순회한다.
      1. 각 IO 연산을 처리한다.
   3. 이 과정을 반복한다.
4. 논블로킹 IO 를 스레드 1개로 구현하면 동시성이 떨어진다.
5. 보통 1개 채널에 대한 읽기 처리가 끝나야 다음 채널에 대한 읽기 처리를 진행하기 ㄸ매ㅜㄴ이다.

리액터 패턴

리액터 패턴은 논블로킹 IO를 이용해서 구현할 때 사용하는 패턴 중 하나이다.

논블로킹 IO 로 구현된 네트워크 프레임워크의 문서를 읽다보면 보이는 리액터라는 단어가 이 패턴에서 말하는 리액터에 해당한다.

리액터는 이벤트를 대기하고 핸들러에 전달하는 과정을 반복하는데 이를 이벤트루프라고 한다.

논블로킹에 기반한 Nettty, Nginx, Node.js 등의 프레임워크나 서버는 이러한 리액터 패턴을 사용하고 있다.

리액터 패턴에서 이벤트 루프는 단일 스레드로 실행한다.

언제 어떤 방법을 사용할까?

논블로킹 IO 나 가상 스레드를 적용할 때는 먼저 다음을 검토해야한다.

• 문제가 있는가?
  • 문제가 없는데 구현을 변경하는 것은 시간을 낭비하는 것이다.
  • 게다가 논블로킹 IO/비동기IO 방식으로 구현하면 코드가 복잡해지고 유지보수난이도도 올라간다.
• 문제가 있다면 네트워크 IO 관련 성능 문제인가?
• 구현 변경이 가능한가?

우선 순위에 밀려 구현 변경이 불가능한 상황에는 구현 방식을 바꾸는 대신 서버 확장으로 문제를 해결해야한다.

서버와 동시실행

서버가 동시에 여러 클라이언트의 요청을 처리하는 방식에는 크게 두가지가 있다.

1. 클라이언트 요청마다 스레드를 할당해서 처리
   • 이 경우에는 경쟁 상태 등 여러 동시성 문제가 발생 할 수 있다.
2. 비동기 IO ( 또는 논블로킹 IO) 를 사용해서 처리
   • 해당 방법을 사용하더라도 단일 스레드 하나만을 사용하는 경우는 드물다.

→ 어떤 방식이던 서버는 동시 실행이 기본이므로 동시성 문제를 염두해두고 설계하자

경쟁상태

경쟁 상태는 여러 스레드가 동시에 공유 자원에 접근 할 때 접근 순서에 따라 결과가 달라지는 상황을 말한다.

→ 동시성 문제는 프로세스 수준, DB 수준에서 동시에 발생한다. 두 가지의 경우 어떻게 접근해야하는지 알아보자.

프로세스 수준에서의 동시 접근 제어

Lock 을 이용한 접근 제어

Lock 을 사용하면 공유 자원에 접근하는 스레드를 하나로 제한할 수 있다.

로직은 다음과 같다.

1. 잠금을 획득

2. 공유 자원에 접근 ( 임계 영역 )

   임계영역이란? 임계영역은 동시에 둘 이상의 프로세스나 스레드가 접근하면 안되는 공유자원에 접근하는 코드 영역

3. 잠금을 해제함.

4. JAVA 의 HashMap 은 다중 스레드 환경에서 안전하지 않다. ( 동시에 여러 스레드가 put() 과 같은 메서드를 호출하면 데이터의 유실이 일어날 수 있으므로)

5. 이런 문제를 방지하려면 ReentrantLock 을 사용해서 임계 영역에 한번에 한 스레드만 접근할 수 있도록 제한하여야 한다.

6. synchronized 또한 고려할 수 있다. @synchronized 하면 해당 어노테이션이 있는 코드 블록을 제어하고 코드 블록이 끝나면 자동으로 잠금을 풀어주기 때문이다.

7. 하지만 ReentrantLock 은 잠금 획득 대기 시간을 지정하는 기능 등의 기능이 있따.

8. 또한 JAVA 21 버전에 가상 스레드가 ReentrantLock 만 지원하고 synchronized는 자바 24 버전부터 지원한다.

9. 다만 두 방식을 섞어 쓰지는 말자. 가능하면 하나만 사용하자

동시 접근 제어를 위한 구성 요소

1. ReentrantLock 은 한 번에 하나의 스레드만 잠금을 할 수 있다.
2. 잠금 외에도 동시 접근을 제어하는 수다능로 세마포어와 읽기 쓰기 잠금이 있다.

세마포어

1. 세마포어는 동시에 실행할 수 있는 스레드 수를 잠금한다.
   1. 이진 세마포어와 counting 세마포어가 있는데 이진 세마포어는 동시 접근할 수 있는 스레드가 1개, 계수 세마포어는 지정한 수만큼 동시에 접근 가능
2. 자바 세마포어 구현체는 퍼밋이라고 표현한다.
3. 로직은 다음과 같다
   1. 세마포어에서 퍼밋 획득 ( 허용 가능 숫자 1 감소 )
   2. 코드 실행
   3. 세마포어에 퍼밋 반환 ( 허용 가능 숫자 1 증가 )
4. 세마포어의 남아있는 퍼밋 개수가 0인 상태에서 퍼밋을 획득하려는 스레드는 다른 스레드가 퍼밋을 반환할 때 까지 대기한다.

읽기 쓰기 잠금

읽기 쓰기 잠금 (Read-Write Lock)이란?

일반적인 잠금(Lock이나 synchronized)은 공유 자원에 접근하는 스레드를 한 번에 단 하나로 제한합니다. 이 방식은 데이터의 무결성(integrity)을 보장하지만, 데이터를 변경하지 않는 단순한 읽기 작업마저도 동시에 수행될 수 없게 합니다.

문제점: 만약 데이터에 대한 쓰기(변경) 빈도보다 읽기(조회) 빈도가 훨씬 높다면, 한 번에 하나의 스레드만 읽기를 수행할 수 있으므로 전체적인 읽기 성능이 떨어지는 문제가 발생합니다.

해결책: 읽기 쓰기 잠금은 이러한 성능상의 단점을 없애기 위해 고안된 동시 접근 제어 방식입니다. 이 잠금은 쓰기(데이터 변경)와 읽기(데이터 조회) 작업을 분리하여 동시성을 관리합니다.

읽기 쓰기 잠금의 핵심 특징 (성능 개선 원리)

읽기 쓰기 잠금은 다음과 같은 규칙을 가집니다:

1. 쓰기 잠금 (Write Lock):

◦ 배타적 접근: 한 번에 하나의 스레드만 쓰기 잠금을 획득할 수 있습니다. (데이터를 변경할 때는 오직 혼자서만 작업해야 데이터가 꼬이지 않기 때문입니다.)

2. 읽기 잠금 (Read Lock):

◦ 공유 접근: 한 번에 여러 스레드가 읽기 잠금을 획득할 수 있습니다. (데이터를 조회만 하는 경우 여러 명이 동시에 봐도 문제가 되지 않습니다.)

3. 상호 배제 (쓰기/읽기 충돌 규칙):

◦ 어떤 스레드가 쓰기 잠금을 획득한 상태라면, 이 잠금이 해제될 때까지 다른 스레드는 읽기 잠금을 구할 수 없습니다. (쓰는 동안에는 읽을 수 없음).

◦ 어떤 스레드라도 읽기 잠금을 획득한 상태라면, 모든 읽기 잠금이 해제될 때까지 쓰기 잠금을 구할 수 없습니다. (읽는 동안에는 쓸 수 없음).

이러한 특징 덕분에 읽기 쓰기 잠금을 사용하면 동시에 여러 스레드가 데이터를 읽을 수 있게 되어, 일반 잠금을 사용했을 때 발생하는 읽기 성능 저하 문제를 완화할 수 있습니다

원자적 타입

1. Lock 을 사용하면 카운팅 변수 와 같은 공유 자원에 동시성 문제를 방지시킬 수 있다.
2. 하지만 이를 사용하면 단일 스레드가 해당 자원을 점유하는 동안 다른 스레드가 대기하기에 CPU 효율이 낮아진다.
3. 이를 해결하기 위한 방법으로 AtomicInteger, AtomicLong, AtomicBoolean 과 같은 원자적 타입을 사용하면 동시성 문제 없이 여러 스레드가 공유하는 데이터를 변경할 수 있다.
4. ㅇ이러한 타입은 내부적으로 CAS( 비교 후 교체 연산) 을 사용한다.
5. 이를 통해 스레드를 멈추지 않고도 다중 스레드에서 동시성 문제를 해결할 수 있다.

동시성 지원 컬렉션

스레드에 안전한지 않은 컬렉션을 여러 스레드에 공유하면 동시성 문제가 발생한다.

자바에서는 Collections.synchronized 와 같이 동기화된 컬렉션을 생성하는 메서드를 제공한다.

단, 자바 23 또는 이전 버전 기준으로 가상 스레드를 사용한다면 해당 동기화 컬렉션 변환 메서드를 사용하면 안된다. 내부적으로 synchronized 를 사용해서 동시 접근을 동기화 하기 때문이다. → 성능에 문제가 생길 수 있다.

다른 방법으로는 동시성 자체를 지원하는 컬렉션 타입을 사용하는 것이다.

ConcurrentHashMap 과 같은 타입은 잠금 범위를 최소화하므로 키의 해시 분포가 다르고 동시 수정이 많으면 더 나은 성느을 제공한다.

DB 와 동시성

선점 잠금

• 데이터에 먼저 접근한 트랜잭션이 잠금을 획득하는 방식

  • 분산 잠금?

    분산 잠금은 여러 프로세스가 도시에 동일한 자원에 접근하지 못하도록 막는 방법

    보통 레디스를 활용해서 구혀낳ㄴ다.

비선점 잠금

• 명시적으로 잠금을 사용하지 않고 데이터를 조회하려는 시점에서의 값과 수정하려는 시점에서의 기준값(버전 컬럼)이 비교하는 방식으로 동시성 문제를 처리하는 방식
  • 잠금을 획득하기 위한 대기 시간이 없기 때문에 실패할 경우 사용자에게 더 빠르게 결과를 응답할 수 있음

외부 시스템과 연동해야한다면?

• 선점 잠금을 고려하는게 좋음
• 만약 비선점 잠금을 사용해야한다면

증분 쿼리

잠금 사용 시 주의사항

1. 잠금 해제하기

잠금을 해제 하지 않으면 잠금을 시도하는 스레드가 무한정 대기하게 되므로 try-finally 형태의 코드를 사용하여 작므을 해제하는 코드를 넣는 습관을 들이자

2. 대기 시간 정하기

잠금 해제 시간을 정하면 사용자에게 잠금 획득 실패 에러를 빠르게 전달할 수 있다.

3. 교착 상태 피하기

대기 시간은 교착 상태를 피하는데도 효과를 볼 수 있다.

또한 지정한 순서대로 잠금을 획득하게 할 수 도 있다. 모든 스레드가 트랜잭션에서 같은 순서로 잠금을 획득한다는 규칙을 만들면 교착상태를 피하는데 도움을 준다.

• 라이브락 : 아무것도 하지 않고 대기하는 교착 상태와는 다르게 지속적으로 대기상태를 빠져나가기 위해 진행되나 그것이 교착을 만들어내는 것 → 중재자 우선순위를 둬서 해결 가능
• 기아 상태
  • 우선순위를 두면 우선순위가 낮은 작업이 지속적으로 순위가 밀리므로 기아상태에 빠짐 → 작업의 우선순위를 높이거나 여러 프로세스나 스레드가 공유하는 자원을 독점하는 시간에 제한을 두어 가능한 작업을 실행할 수 있도록 해야함

단일 스레드로 처리하기

동시성이 발생하는 이유는 여러 스레드가 동시에 동일 자원에 접근하기 때문이므로 차라리 한 스레드만 상태를 관리하게 하고 그 스레드를 사용할 수 있는 큐를 만드는 것이 더 나을 수 있음

두 스레드의 데이터 공유가 필요하면 콜백이나 큐와 같은 수단을 이용해서 데이터 복제본을 공유하게 할 수 있음

→ 성능에 문제가 될 수 있으나 임계 영역의 실행 시간이 짧고 동시 접근 스레드 수가 적을수록 잠ㄱ믕르 사용하는 구현 성능이 좋을 가능성이 높음

왜냐하면 큐나 채널을 사용하는데 드는 시간보다 잠금 획득과 해제에 드는 시간이 더 짧기 때문에

하지만 동시에 실행되는 작업이 많고 임계 영역의 실행 시간이 길어지면 큐나 채널을 이용한 방식이 더 비슷하거나 나은 성능을 낼 가능성이 있음

1. 타임아웃 설정을 하자

다음과 같은 상황이 있다고 생각해보자.

• A 서비스가 있고 이 서비스가 호출하는 B 서비스가 있다.
• A 서비스의 스레드 풀은 100개이다.
• B 서비스에 성능 문제가 생겨 응답 대기 시간이 60초를 넘기기 시작한다.

A 서비스에 100명의 사용자가 요청을 보내면 톰캣은 A 서비스의 요청을 처리하기 위해 B서비스를 호출한다.

10초 후 새로운 100명의 사용자가 요청을 보낸다. 하지만 B 서비스의 요청에 응답이 오지 않았기 때문에 대기는 끝나지 않는다. 이렇게 서비스가 마비된다.

→ 연동 서비스에 대한 타임아웃을 설정하지 않으면 연동 서비스의 응답이 느려질 때에 처리량이 급격히 떨어진다.

타임아웃을 설정하여 사용자에게 지정 시간 이후 에러 화면을 보게 하자. 반응 없는 무한 대기 화면보다는 에러 화면이라돋 보는 게 낫다. 또한 서비스의 자원이 포화되기 전에 응답하게 되므로 연동 서비스 문제가 다른 기능에 주는 영향도 줄어든다.

타임아웃의 종류

1. 연결 타임아웃(Connection Timeout)

   커넥션을 요청할때에 커넥션 수락을 얼마나 기다릴지 기다리는 시간

2. 읽기 타임아웃(Read Timeout)

   커넥션이 되고 응답을 받기까지의 시간

처음 연동하는 서비스라면 보통 이렇게 타임아웃을 설정해둔다.

• 연결 타임아웃 : 3초 ~ 5초
• 읽기 타임아웃 : 5초 ~ 30초

소켓 타임아웃과 읽기 타임아웃

• 읽기 타임아웃을 지정할 때에는 실제로 설정되는 값이 무엇인지 보고 결정해야함.

1. 아파치의 HTTPClient 의 경우 소켓 타임아웃을 설정함
   1. 소켓 타임아웃은 네트워크 패킷 단위를 기준으로 하므로 전체 응답 시간에 대한 타임아웃을 의미지는 않는다.
2. OkHttp 는 읽기 타임아웃과는 별개로 호출 타임아웃을 설정 가능
   1. 요청 시작부터 응답까지의 전체 시간 기준으로 설정
3. 소켓 타임아웃을 설정하면 패킷은 계속 수신되지만 전체 처리 시간이 오래 걸리는 경우 타임아웃 발생시킬 수 잇음.

OkHttp란?

OkHttp는 HTTP 및 HTTP/2 클라이언트 라이브러리로, 안드로이드 및 자바 애플리케이션에서 네트워크 요청을 처리하는 데 널리 사용되는 오픈소스 라이브러리입니다. Square사에서 개발했으며, 효율적인 연결 관리와 다양한 타임아웃 설정 옵션을 제공합니다.

"소켓 타임아웃은 네트워크 패킷 단위를 기준으로 하므로 전체 응답 시간에 대한 타임아웃을 의미하지는 않는다"의 의미

이 문장은 소켓 타임아웃의 작동 방식을 설명하는 중요한 개념입니다:

• 소켓 타임아웃의 특성: 소켓 타임아웃은 각 네트워크 패킷이 도착하는 간격을 측정합니다. 즉, 패킷과 패킷 사이의 대기 시간을 기준으로 합니다.
• 전체 응답 시간과의 차이: 만약 서버가 데이터를 천천히 보내더라도, 패킷이 계속해서 도착하기만 한다면 타임아웃이 발생하지 않습니다. 예를 들어, 소켓 타임아웃을 10초로 설정했다고 가정해봅시다. 서버가 총 5분 동안 응답을 보내는데, 매 5초마다 패킷을 보낸다면 타임아웃이 발생하지 않습니다. 전체 응답 시간은 5분이지만, 패킷 간 간격은 10초 미만이기 때문입니다.
• 문제점: 이로 인해 전체 처리 시간이 매우 길어질 수 있습니다. 클라이언트는 서버로부터 느리게 전송되는 데이터를 계속 기다리게 되어, 의도하지 않게 매우 긴 시간 동안 연결이 유지될 수 있습니다.

OkHttp의 해결책

OkHttp는 이러한 문제를 해결하기 위해 읽기 타임아웃과는 별개로 "호출 타임아웃(Call Timeout)"을 제공합니다. 호출 타임아웃은 요청 시작부터 응답 완료까지의 전체 시간을 기준으로 작동하므로, 서버가 아무리 패킷을 계속 보내더라도 전체 처리 시간이 설정된 시간을 초과하면 타임아웃이 발생합니다.

2. 외부 설정 실패 시 재시도 설정법

재시도 시 문제가 없는 서비스만 재시도를 할 것.

1. 재시도를 할 때에는 재시도 해도 문제 없는 서비스인지 확인해야한다.
2. 예를 들어 API 를 호출해 포인트가 차감되는 서비스의 경우 포인트 차감 처리가 여러번 될 수 있다.
3. 재시도 해도 되는 조건은 다음과 같이 3가지가 있다.
   1. 단순 조회 기능
   2. 연결 타임 아웃 (연결 타임 아웃의 경우 아직 연동 서비스에 연결되지 않았다는 의미이므로 재시도 괜찮다. 하지만 읽기 타임아웃의 경우에는 재시도 시 문제가 발생할 수 있다.)
   3. 멱등성을 가진 변경 기능 ( 상태 변경되는 API 를 재시도할 때에는 멱등성을 고려해야한다. )

재시도 횟수와 간격을 생각할 것.

1. 재시도 할 때에는 재시도 횟수와 간격을 생각해야한다.
2. (대부분의 경우) 재시도의 횟수는 1~2회가 이상적이다.
3. 재시도 간격의 경우에는 여러 차례 재시도 할 경우 간격을 늘리면서 한다.

재시도 폭풍(Retry Storm) 의 안티패턴

1. 재시도는 성공 가능성을 높일 수 있지만 반대로 연동 서비스에는 더 큰 부하를 줄 수 있다.

3. 동시 요청 제한

1. 연동 서비스의 최대 처리량을 초과하는 트래픽을 감당하면 기하급수적으로 응답시간이 늘어나기 시작한다.
2. 이러한 최대 처리량을 늘릴 수 없을 때에 연동 서비스에 임계치 이상의 요청을 보내는 방법은 최대 처리량을 초과하는 요청을 보내지 않는 것이다.
3. 연동 서비스의 트래픽을 초과하는 요청은 503 상태 코드를 사용하여 과부하 상황임을 클라이언트에 알려 오류 메시지를 출력할 수 있다.

벌크 헤드 패턴

동시요청을 제한하는 방식은 벌크페드 패턴이라고 한다. 벌크헤드 패턴은 각 구성요소를 격리하여 한 구성요소의 장애가 다른 구성요소에 영향을 주지 않도록 ㅅ하는 설계 패턴이다.

4. 서킷 브레이커

1. 앞서 연동 서비스에 시간이 걸릴 경우에는 타임아웃을 설정하여 지정 시간 이상 걸릴 경우에는 에러 화면이 보여지는 방법을 설명했다.

2. 하지만 연동 서비스가 정상 상태가 아님을 알 수 있다면 연동 서비스에 요청을 보내지 않고 바로 에러를 응답하는 것이 낫다.

3. (왜냐하면) 서버 입장에서는 읽기 타임아웃 시간동안 발생하는 응답시간을 줄일 수 있고 처리량도 감소시킬 수 있고 사용자 입장에서는 몇초 기다리는 것 보다 바로 에러 화면을 보는 것 보다 바로 에러화면을 보는 것이 낫기 때문이다.

4. 서킷 브레이커가 작동하는 방식이 이와 같다.

5. 서킷 브레이커는 누전 차단기처럼 과도한 트래픽이 발생하면 연동을 중지시키고 바로 에러를 응답한다.

6. 서킷 브레이커는 닫힘, 열림, 반 열림 의 3가지 상태를 갖는다.

   

   1. 서킷 브레이커는 닫힘 상태로 시작한다. 닫힘 상태일 때에는 모든 요청을 연동 서비스에 전달한다.
   2. 외부 연동 과정에서 오류가 발생하기 시작하면 지정한 임계치를 초과했는지 확인하고 초과했다면 열림 상태가 된다.
      1. 임계치 기준
         • 시간 기준 오류 발생 비율 : 10초동안 오류 비율이 50% 초과
         • 개수 기준 오류 발생 비율 : 100개 요청 중 오류 비율이 50% 초과
   3. 열림 상태가 되면 연동 요청은 수행하지 않고 바로 에러 응답을 리턴한다. 이는 지정된 시간동안 진행된다.
   4. 이 시간이 지나면 일정 개수, 일정 기간 동안 반 열림 상태로 전환된다. 일부 요청에 관해 연동을 시도한다.
   5. 이 기간 연동에 성공하면 다시 열림 상태로 전환되어 연동을 차단한다.

5. 외부 연동과 DB 연동

외부 연동과 트랜잭션 처리

1. DB 연동과 외부 연동을 함께 처리할 때에는 오류 발생 시 DB 트랜잭션을 어떻게 처리할지 알맞게 판단해야한다.

   1. 예시 1. 외부 연동에 실패했을 때 트랜잭션을 롤백

      1. 이 상황에서는 외부 연동에 실패했을 때 트랜잭션이 롤백되면 변경 데이터가 DB 에 저장되지 않는다.
      2. 하지만 읽기 타임아웃이 발생했을 경우에는 외부 서비스가 실제적으로 성공적으로 처리되었을 가능성을 염두해 둬야 한다.
      3. 이 경우 2가지 방법 중 하나를 검토해야한다.
      4. 첫 번째로 일정 주기로 두 시스템의 데이터가 일치하는 지 확인하고 보정하는 방법
      5. 성공 확인 API 를 호출하는 방법 ( 이 방식은 외부 서비스가 성공 여부를 알려주는 API 를 제공할 때만 사용할 수 있다.
      6. 이 방식의 형으로 취소 API 를 호출하는 방식도 있다. 읽기 타임아웃이 발생한 뒤 일정 시간 후에 취소 API 를 호출하는 식이다.
      7. 하지만 이것은 연동 서비스가 지원해야 하고 후속 API 호출에도 읽기 타임아웃이 발생할 수 있으므로 두 시스템간 일관성이 중요하다면 정기적으로 데이터 일치를 확인하는 프로세스를 갖추는 것이 바람직하다.

   2. 예시 2. 외부 연동은 성공했지만 DB 연동에 실패해 트랜잭션을 롤백

      외부 연동은 성공했지만 DB 연동에 실패된 경우에는 취소 API를 호출해서 외부 연동을 이전 상태로 되돌리는 것이 필요하다.

외부 연동이 느려질 때 DB 커넥션 풀 문제

1. DB 트랜잭션 범위 안에서 외부 연동을 수행할 때에 트랜잭션 처리 외에도 주의해야할 점이 하나 더 있다.
2. 바로 커넥션 풀 부족 현상이다.
3. DB 연동과 무관하게 외부 연동을 실행할 수 있다면 DB 커넥션을 사용하기 전에나 후에 외부 연동을 시도하는 방안을 고려해보면 좋다.
4. 단 이 방식은 외부 연동이 트랜잭션 범위 밖에서 실행되기 때문에 롤백이 불가능ㅎ아다. 실패한 외부 연동에 대한 후처리가 이루어져야함을 주의하자

6. HTTP 커넥션 풀

1. 전체 처리 시간에서 연결 시간이 차지하는 비중이 크다.

2. DB 도 DB 커넥션 풀을 통해 dB 연결 시간을 줄이는 것 처럼 HTTP 연결도 커넥션 풀을 사용하면 연결 시간을 줄일 수 있어 응답속도 향상에 도움이 된다.

3. HTTP 커넥션 풀을 사용할 때는 다음 3가지 를 고려하자

   1. HTTP 커넥션 풀 크기

      풀의 크기는 연동할 서비스의 성능에 따라 결정한다. 커넥션풀 크기를 무작정 늘리면 연동 서비스의 성능 저하가 우리 서비스 전체의 응답시간에 영향을 끼친다. 그렇기에 반드시 연동 서비스의 처리 능력을 고려하자

   2. 풀에서 HTTP 커넥션을 가져올 때까지 대기하는 시간

      커넥션 풀의 크기가 10개라면 11개의 외부 연동요청이 들어온 경우 10개는 커넥션을 확보해 실행되고 나머지 1개는 대기하게 된다. 대기 시간은 수 초 이내의 짧은 시간으로 설정하는 것이 좋다.

   3. HTTP 커넥션 유지 시간

      끊어진 커넥션을 사용하면 에러가 발생하ㅡ로 연동 서비스에 맞춰 유지 시간을 적절히 설정하자.

7. 연동 서비스 이중화

1. 서비스가 대량 트래픽을 처리할 만큼 성장했담녀 연동 서비스의 이중화를 고려하자.
2. 연동 서비스를 이중화해두면 장애 시 대응할 수 잇다.
3. 하지만 비용이 크기에 결정시 다음 2가지를 따져봐야한다.
   1. 해당 기능이 서비스의 핵심 기능인지
   2. 이중화 비용이 감당 가능한 수준인지

1. 테이블의 모든 데이터를 순차적으로 읽는 것을 풀스캔이라고 한다.
2. 보통 데이터가 많을 때에 풀스캔이 발생하면 조회가 느려지므로 인덱싱을 잘 해둬야한다.
3. 일반적인 시스템의 경우에는 조회 기능의 실행 비율이 높다.
4. (그러므로) 조회 패턴을 기준으로 인덱스를 설계하는 것이 중요하다.
5. (예를 들면) 게시판의 경우 카테고리별로 게시글을 조회하는 패턴이 존재하므로 category 컬럼에 인덱스를 걸면 성능 개선이 일어날 수 있다.
6. (내가 작성한 글 보기 기능이 있는 경우에도) 풀스캔 방지를 위해 writerId 컬럼에 인덱스가 필요할 것이다.

FULLTEXT 인덱스

• 게시글 제목 검색 등의 기능을 위한 쿼리는 다음과 같다.

    SELECT id, category, writerId, title, content FROM article
    WHERE title like '%검색어%' order by id DESC limit 10

• 허나 이러한 like 조건은 풀스캔을 유발한다.

• (이를 사용하지 않기 위해) 엘라스틱 서치 와 같은 검색엔진을 사용하면 DB 를 사용하지 않고 검색 기능을 구현할 수 있다.

• (만약 이와 같은 도구를 사용하는 것이 힘들다면) DB 가 제공하는 FULLTEXT 검색 기능을 활용하자.

• FULLTEXT 인덱스를 고려하면 풀스캔 없이 문자열 검색 쿼리를 실행할 수 있다

단일 인덱스와 복합 인덱스 결정은 데이터 기반으로

1. 인덱스를 단일로 할지, 복합으로 할지는 해당 테이블에 얼마나 많은 데이터가 쌓이는지를 기준으로 정해야한다.
2. 하루에 50만건의 데이터가 쌓이는 경우에는 (요즘 기준으로) 많은 데이터는 아니지만 인덱스가 없는 경우 문제가 발생할 수 있는 규모다.
3. 만약 사용자 활동 로그를 저장하는 log 테이블이 있고 userId 와 activitiDate 를 기준으로 조회하는 기능이 있다고 하면 둘다 인덱싱 할지 userId 만 인덱싱 할지 고민될 수 있다.
4. 이럴때에는 사용자당 가질 수 있는 데이터가 얼마나 될지 가늠해보면 어떤 인덱스를 사용해야 할지 판단하는 데 도움이 된다.
5. 개별 사용자가 일주일에 하루정도 방문하고 평균 활동 데이터가 5건이면 1년 활동해야 260건이다.
6. 하지만 매일 방문하고 30번 이상의 활동을 하는 회원은 1년이면 1만 건이 넘는 활동 로그 데이터를 생성한다.
7. 이럴때에는 userID 와 activityDate 칼럼을 복합인덱스로 생성해야 조회 성능 문제가 발생하지 않는다.

선택도를 고려한 인덱싱을 하라. (항상은 아니고)

1. 선택도란 인덱스에서 특정 칼럼의 고유한 값의 비율을 뜻한다.
2. 고유한 값이 적어지면 그만큼 조회할때에 스캔할 내용이 많아짐으로 인덱스 효율이 낮아진다.
3. (하지만) 항상 선택도가 높아야하는 것은 아니다.
4. 만약 실제 사용하는 기능의 쿼리가 하나의 컬럼을 항상 조회한다면 선택도에 상관없이 인덱싱하는게 좋다.

커버링 인덱스를 활용해라

커버링 인덱스는 특정 쿼리를 실행하는데 필요한 모든 쿼리를 포함하는 인덱스를 뜻한다.

실제 데이터를 읽어오는 과정이 생략되므로 쿼리 실행 시간이 빨라진다.

과다 사용은 금물 아래글을 보라.

인덱스는 필요한 만큼만 만들 것.

1. 효과가 적은 인덱스를 만들면 오히려 데이터 추가, 변경, 삭제 시 인덱스 관리에 따른 비용이 발생하기에 안좋을 수 있다.
2. (또한) 인데스가 많아질수록 메모리와 디스크 사용량도 함께 증가한다.
3. (그러므로) 새로 추가할 쿼리가 기존에 존재하는 인덱스를 사용하지 않을 때에는 요구사항을 일부 변경할 수 있는지 검토해보자

성능 개선 방법

1. 미리 집계하기

1. 조회수 같은 기능이 필요하다면 sum 이나 count 같은 집계 쿼리를 조회시점에 실행하면 문제가 있을 수 있다.
2. 이러한 집계 데이터는 미리 계산해서 별도 컬럼에 저장하자.

2. 페이지 기준 목록 조회 대신 ID 기준 목록 조회 사용하기

1. 만약 id 가 AI라면 offset 기준으로 조회하는 것이 아닌 ID 기준으로 조회하는 것이 좋다.

    select id, subject, writer, regdt
    from article
    order by id desc
    limit 10 offset 99990;

2. 만약 위와 같은 쿼리가 있다면 DB 는 99,991 부터 10개 세면 좋겠지만 어떤 값이 99,990인지 모르므로 데이터를 세는 시간만큼 실행 시간이 증가한다.

3. 그러므로 특정 ID 를 기준으로 조회하면 좋다.

꿀팁

만약 프론트 개발자가 다음에 읽어올 데이터가 존재하는지 알려주는 속성을 응답 결과에 포함시켜 달라고 요청한다면 1개만 더 읽어 판단하면 된다.

예를 들어 10개를 조회하는 페이징이 있으면 11개를 조회하고 만약 조회한 데이터가 11개이면 다음에 읽을 데이터가 존재하므로 추가 데이터 존재 여부를 true 로 응답하면 된다.

JPA 의 pagenation 도 그렇게 동작하나? NO

🧩 책에서 제안한 방식

• 1페이지에 10개씩 조회
• 실제 쿼리: limit 11 offset 0
• 결과가 11개면 → 다음 페이지 존재 (hasNext = true)
• 결과가 10개 미만이면 → 마지막 페이지

➡ 장점: count 쿼리를 안 쳐서 빠름

➡ 단점: 전체 개수를 알 수 없음(total count 불명)

---

🧩 JPA의 기본 방식

• 1페이지에 10개씩 조회
• 실제 쿼리: limit 10 offset 0
• 별도로 select count(*) 실행
• count 결과와 현재 offset으로 다음 페이지 존재 여부 계산

➡ 장점: 전체 페이지 수(total count) 를 알 수 있음

➡ 단점: count 쿼리 비용이 큼 (특히 큰 테이블에서)

---

⚙️ 3. 정리

구분	방식	장점	단점
JPA 기본 Page	limit + count(*)	전체 개수, 페이지 수 알 수 있음	count 쿼리 부담
limit+1 방식 (프론트 제안)	limit + 1	빠름, 단순함	전체 개수 불명

---

💡 4. 실무 팁

성능 이슈로 count(*) 쿼리를 피하고 싶다면

Slice<T> 를 사용하는 방법이 있습니다.

Slice<Post> posts = postRepository.findAllByOrderByCreatedAtDesc(PageRequest.of(0, 10));

➡ Slice 는 count 쿼리를 날리지 않고,

내부적으로 limit+1 방식으로 다음 페이지 존재 여부(hasNext())를 판단합니다.

조회 범위를 시간 기준으로 제한하기

1. 뉴스를 보면 월별, 일별로 데이터를 분류해서 보여준다.
2. 즉, 기사 조회 범위를 일자 기준으로 제한하는 것이다.
3. 조회 범위를 제한하는 또 다른 방법은 최신 데이터만 조회하는 것이다.
4. 특히 공지사항의 경우에는 며칠 또는 몇 달 이내의 공지는 읽을 수 있지만 3년 전 공지사항은 (거의) 아무도 읽지 않는다. (구글의 경우 보안활동 데이터는 최근 28일 데이터만 보여준다.)

전체 개수 세지 않기

1. 목록을 표시하거나 조건에 해당하는 데이터 개수를 구하기 위해서는 count 함수를 사용해야한다.
2. 데이터가 적을때에는 count 함수를 사용해도 된다.
3. (하지만) 데이터가 많을때에는 count 함수를 실행할 경우 문제가 된다.
4. 커버링 인덱스를 사용하더라도 (조회된) 전체 인덱스를 스캔해야하고 만약 인덱싱이 되어있지 않은 경우 실제 데이터를 전부 읽어야한다.

APM 프로그램 항상 쉽게 볼 수 있는 곳에 띄워두기

1. 서비스를 진행할 경우 서비스가 정상일 때 으답시간 분포가 어떤 형태를 띠는지 감을 잡을 수 있다.

오래된 데이터 삭제 및 분리 보관하기

1. 과거 데이터를 삭제하면 데이터 개수를 일정하게 유지할 수 있어 성능 또한 일정 수준으로 유지된다.
2. 하지만 과거 데이터를 삭제할 수 있는 케이스는 많지는 않다.
   1. 로그인 시도 내역
      • 로그인 시도 내역은 장기간 보관할 필요 없기에 최근 180일 치 이상 된 데이터들만 분석에 사용한다면 이후 데이터들은 삭제하여 성능을 유지시킨다.
      • 만약 더 많은 일자가 내부 관리 시스템에서 필요할 경우 서비스 DB 와 분석 DB 를 분리하여 180일 이전 데이터는 별도 DB 로 분리 보관하면 된다.

단편화, 최적화

• DELETE 쿼리를 사용해도 실제 사용하는 디스크 양은 같다.

• 하지만 데이터가 반복적으로 추가되고 변경되고 삭제되는 과정에서 데이터가 흩어져 저장되ㅗㄱ 빈 공간이 생기는 단편화 현상이 발생할 수 있다.

• 이를 방지하기 위해 최적화 작업을 한다.

• 질문답변.

  질문 1.

  서적에서 추가 데이터 페이징 처리를 구현할때에

    만약 프론트 개발자가 다음에 읽어올 데이터가 존재하는지 알려주는 속성을 응답 결과에 포함시켜 달라고 요청한다면 1개만 더 읽어 판단하면 된다.
  
    예를 들어 10개를 조회하는 페이징이 있으면 11개를 조회하고 만약 조회한 데이터가 11개이면 다음에 읽을 데이터가 존재하므로 추가 데이터 존재 여부를 true 로 응답하면 된다.
  

  라고 했는데 JPA 의 pagenatnion 또한 count 쿼리를 활용하지 않고 동일하게 동작할까요?

  질문 2

  테이블 단편화를 해결하기 위해 OPTIMIZE TABLE 명령어(서적에서 언급한 최적화)를 사용할 수 있다고 알고 있습니다. 하지만 운영 중인 서비스의 테이블에 이 명령어를 바로 실행하기 어려운 이유는 무엇이며, 어떤 대안을 고려할 수 있을까요?

  힌트 : 서적에서 DML 을 운영중인 테이블에 사용하면 안된다고 한 이유와 같다.

DB 장비 확장하기

• 수직 확장의 경우

  스케일 업을 통해 DB 장비의 성능을 빠르게 보충할 수 있는 방법도 있다.

  클라우드를 사용하면 빠른 시간안에 성능을 높일 수 있다.

• 수평 확장의 경우

  1. DB 를 스케일 아웃하는 경우에는 DB 가 처리할 수 있는 트래픽을 늘릴 수 있다.
  2. 조회 트래픽의 비중이 높은 서비스의 경우 Primary-Replica 구조를 사용해 처리량을 증가시킬 수 있다.

별도의 캐시 서버 구성하기

1. 트래픽이 급격히 증가할 경우 DB 만으로 트래픽을 처리하기 어려움으로 캐시 서버를 기본적으로 사용한다.
2. 다만 캐시를 도입하면 코드를 수정해야할 수 있다. 하지만 코드수정에 드는 비용이 더 작다

주의사항

쿼리 타임아웃

1. 응답 시간은 처리량에 큰 영향을 준다.
2. 응답 시간이 길어지면 처리량은 반비례해 감소한다.
3. 하지만 응답지연으로 인해 사용자는 재시도 하기에 서버 부하를 더욱 가중시킨다.
4. 그러므로 쿼리 실행 시간을 제한하는 것이 합리적이다. (timeout)
5. Time out 시간은 서비스의 기능의 특성에 따라 다르게 설정해야 한다. (결제 처리 등의 경우에는 특히)

상태 변경 기능은 replica DB 에서 조회하지 않기

1. 주 DB 는 상태 변경을 복제 DB 는 상태 조회 기능을 담당한다.
2. 하지만 그렇다고 해서 모든 SELECT 쿼리를 복제 DB 에서 실행하면 안된다.
3. 주 DB 와 복제 DB의 데이터가 일치하지 않을 수 있기 때문이다. (복제 지연으로 인한 실시간 일관성이 깨질 수 있기 때문에)
4. 트랜잭션 문제가 일어날 수도 있다.
5. 그러므로 변경 대상 데이터를 조회해야한다면 복제 DB가 아닌 주 DB 에서 조회하자.

배치 쿼리 실행 시간 증가

1. 배치 프로그램은 데이터를 일괄로 조회, 집계, 생성하는 작업을 수행한다.
2. 한번에 처리하는 데이터가 많아질수록 배치 쿼리의 실행 시간도 함께 증가한다.
3. 이 문제를 예방하려면 배치 쿼리의 실행 시간을 지속적으로 모니터링해야 한다. 이를 통해 병목 지점을 찾아 해결할 수 있다.
4. DB 사양을 증설하여 처리 성능을 높일 수 있다.
5. 커버링 인덱스를 활용하여 쿼리 성능을 개선할 수 있다.
6. 데이터를 일정 크기로 나누어 처리하는 방법도 효과적이다. 쿼리를 시간대별로 분할 실행하면 결과를 안정적으로 얻을 수 있다.

타입이 다른 컬럼 조인 주의

1. 타입이 다른 경우 인덱스를 활용할 수 없다.
2. 타입 변환이 이루어지기 때문이다.
3. 그러므로 비교 대상 칼럼의 타입을 맞추면 쿼리 실행 중 발생하는 불필요한 타입변환을 줄일 수 있고 인덱스도 활용할 수 있다.

테이블 변경은 신중하게

1. MySQL은 타입을 테이블을 변경할 때 새 테이블을 생성하고 원본 데이터를 복사한 뒤 복사가 완료되면 새 테이블로 대체한다.
2. 이 과정에서는 DML 을 허용되지 않는다.

DB 최대 연결 개수

• 다음과 같은 상황을 상정해보자

  • api 서버는 3대
  • 트래픽이 증가하고 있고 수평확장이 필요하다.
  • DB 서버의 CPU 사용률은 20% 수준으로 여유가 있다.

• 트래픽 증가를 감당하기 위해 API 서버를 추가할 수 있다.

• 그런데 새로 추가한 API 서버에서 DB 커넥션 생성에 실패한다면?

  → DB 의 최대 연결개수를 확인해보자.

  하지만 DB 서버의 CPU 사용률이 70% 이상으로 높다면 연결 개수를 늘리면 안된다.

클라이언트→ 서버 데이터 요청 과정

1. 서버에 연결 : TCP를 이용해서 서버에 연결한다.
2. 데이터 전송: 정해진 규칙(프로토콜) 에 따라 데이터를 서버에 전송한다.

응답시간

• 응답 시간의 측정 방법

  • TTFB : 응답 데이터 중 첫번째 바이트가 도착할 때까지 걸린 시간
  • TTLB : 응답 데이터 중 마지막 바이트가 도착할 때까지 걸린 시간

• 응답시간의 구성 요소

  • 로직 수행 시간 (if, for 등)

  • DB 연동(SQL 실행)

  • 외부 API 연동

  • 응답 데이터 생성(전송)

    → 보통 외부 API 를 연동하거나 DB를 연동하는 시간이 응답시간에 많은 부분을 차지하기 때문에 응답시간을 줄일 때 DB 연동과 API 연동 시간에 집중한다.

처리량(Throughput)

단위 시간당 시스템이 처리하는 작업량

• 처리량 표현법

  • TPS
    • 초당 트랜잭션의 수 해당 초 동안 완료된 트랜잭셔느이 개수를 의미한다.
    • 최대 TPS 는 시스템이 처리할 수 있는 최대 요청 수를 의미한다.
      • 요청이 최대 TPS 를 초과하면 최대 TPS 수를 처리한 이후 나머지 트랜잭션이 실행된다.
  • RPS
    • 초다 요청의 수

• 처리량을 늘리는 법.

  1. 트래픽이 많은 시간대에 TPS 와 응답시간을 측정하기

  2. 목표 TPS 와 응답시간을 설정하기

     → 이를 가장 쉽게 알 수 있는 방법은 모니터링 시스템을 활용하는것임

• 트래픽 모니터링 시스템

서버 성능 개선 기초

서비스 초기에는 성능 문제가 잘 발생하지 않으나 점차 사용자가 늘면서 성능문제가 발생하기 시작함.

그때 보이는 지표는 다음과 같음

• 순간적인 모든 사용자 요청에 대한 응답시간이 심각하게 느려짐
• 서버를 재시작하면 잠시 괜찮았다가 다시 응답시간이 느려짐
• 트래픽이 줄어들 때까지 심각한 상황이 계속됨

이러한 지표가 보이는 이유는 시스템이 수용할 수 있는 최대 TPs 보다 더 높은 트래픽이 유입되기 때문

→ 보통 이러한 성능 문제는 주로 DB 연동이나 API 연동 과정에서 발생한다.

• 수직확장과 수평확장

  수직확장(scale-up) : CPU, 메모리, 디스크 등의 자원을 증가시키는 것

  수평 확장(scale-out) : 서버를 추가로 투입해 TPS 를 높이는 방법, 로드밸런서가 필요하다.

> 로드밸런서
> 
> 
> 사용자의 트래픽을 각 서버에 골고루 분배해서 한 서버에 사용자 트래픽이 몰리지 않도록 하는 것
> 
> - 로드밸런서의 트래픽 분산 방식
> - 로드밸런싱 알고리즘 종류
>     - 정적인 방식
>         - 해쉬 알고리즘
>             - 특정 기준을 잡아 특정 서버에 매핑하고 고정적으로 트래픽을 분산해주는 방식
>             - 일반적으로 사용되는 기준은 출발비의 IP가 됨.
>         - 라운드 로빈 (RR) : 트래픽이 순차적으로 들어올때 서버에 순차적으로 하나씩 분산
>             - 들어오는 트래픽을 서버 순서대로 배치하는 방식
>             - 연결된 세션이 비교적 오래 사용되지 않은 경우에 채택하는 것이 좋음.
>     - 동적인 방식
>         - Leat Connection 알고리즘
>             - 현재 매핑되어있는 커넥션이 가장 적은 서버로 세션을 연결해주는 방식
>             - Keep Alive로 오랫동안 연결이 지속될경우 문제 발생 가능성 있음.
>         - Weighted Round Robin
>             - 서버의 가중치를 따라 요청을 더 분배하기도 하는 알고리즘

→ 무턱대고 서버 추가만 한다고 해결되진 않음

DB 에서 문재가 일어나는지, 외부 API 가 문제인지 등의 문제 발생 지점을 파악하는것이 우선

DB 커넥션 풀

DB 를 사용하는 3단계

1. DB 에 연결한다
2. 쿼리를 실행한다
3. 사용이 끝나면 연결을 종료한다.

이때 네트워크 연결을 생성하고 종료하는데 걸리는 시간의 80% 이상이 DB 연결 및 종료에 쓰이게 되는것이 일반적.

이를 방지하기 위해 DB 커넥션 풀을 사용한다. 스프링 부트는 HikariCp를 사용

• 커넥션 풀 연결 과정

  2️⃣ Connection Pool 추가된 상세 과정

  1. MySQL 서버 소켓 생성 & 연결 요청

  • 기존과 동일하게 MySQL 서버는 3306 포트에서 연결을 대기.
  • 클라이언트가 연결 요청을 하면 Connection Pool이 먼저 기존 연결을 확인.
  • 사용 가능한 연결이 있으면 즉시 할당하고, 없으면 새로운 연결을 생성 후 추가.

  ---

  2. MySQL 서버의 프로세스/스레드 생성

  • MySQL은 기본적으로 Thread-Per-Connection 방식으로 작동하여 클라이언트 요청이 오면 새로운 스레드 또는 프로세스를 생성하지만, Connection Pool을 사용하면 기존 연결을 재사용하여 불필요한 스레드/프로세스 생성을 방지.

    변경점

  • 기존 방식: 새로운 요청이 오면 새로운 스레드/프로세스 생성.

  • 커넥션 풀 도입 후: 기존 연결을 재사용하여 서버 부하 감소.

  ---

  3. SQL 데이터 송수신

  • SQL 쿼리 송수신 과정은 동일하지만, Connection Pool을 사용할 경우 클라이언트가 작업을 끝낸 후 연결을 즉시 닫지 않고 다시 풀에 반환.
  • 기존 방식에서는 클라이언트가 연결을 종료하면 MySQL 서버가 이를 해제하지만, Connection Pool이 있으면 클라이언트가 close()를 호출해도 물리적인 연결이 닫히지 않고 풀에 반환됨.

• 1️⃣ 기존 SQL 연결 방식의 단점

  과거에는 클라이언트가 DB 서버에 접속할 때마다 새로운 연결을 생성하는 방식(Thread-Per-Connection 또는 Fork-Per-Connection)을 사용했음.

  하지만 이 방식은 성능 저하와 자원 낭비 문제를 발생시켰고, 이를 해결하기 위해 Connection Pool 개념이 등장하게 됨.

  ✅ 기존 방식의 문제점

  1. 연결 생성 오버헤드 (Connection Overhead)
     • 클라이언트가 DB에 연결할 때마다 TCP/IP 연결을 맺고(TCP 3-Way Handshake), 인증 과정을 거쳐야 함.
     • 이 과정에서 CPU, 메모리, 네트워크 자원을 불필요하게 소모함.
  2. 동시 연결 한계 (Connection Limit)
     • DB 서버는 동시에 처리할 수 있는 연결 수에 한계가 있음.
     • 예를 들어, MySQL의 max_connections 기본값은 151개인데, 이 이상 연결하면 DB 접속 거부(Connection Refused)가 발생.
  3. 메모리 사용 증가 (Memory Consumption)
     • 많은 클라이언트가 동시에 접속하면, DB 서버가 과부하 상태가 됨.
     • PostgreSQL처럼 Fork-Per-Connection 방식을 쓰는 경우, 클라이언트가 많아질수록 메모리 사용량이 급증함.
  4. 연결 종료 시 오버헤드 (Disconnect Overhead)
     • 클라이언트가 요청을 마치고 연결을 끊으면, TCP 4-Way Handshake를 수행하고 해당 프로세스 또는 스레드를 정리해야 함.

1. 커넥션 풀 튜닝 🏊‍♂️

데이터베이스 커넥션을 맺는 과정은 비용이 많이 드는 작업입니다. 커넥션 풀은 미리 일정 개수의 커넥션을 만들어두고 재사용함으로써 이 비용을 줄여주는 핵심 기술입니다.

동적 크기 조절 (Min/Max 설정)

서비스 트래픽은 항상 변동합니다. 예를 들어, 은행 서비스는 낮에, 게임 서비스는 저녁에 트래픽이 집중됩니다. 이런 패턴에 효율적으로 대응하기 위해 커넥션 풀의 크기를 동적으로 조절합니다.

• minimum-idle (Min): 트래픽이 적을 때도 유지할 최소 커넥션 개수입니다. 유휴 커넥션을 너무 많이 유지하면 DB 서버에 불필요한 부하를 줍니다.
• maximum-pool-size (Max): 트래픽 급증 시 최대로 생성할 수 있는 커넥션 개수입니다. 이 값을 초과하면 클라이언트는 커넥션을 할당받기 위해 대기해야 합니다.

주요 시간 설정

• 커넥션 대기 시간 (connection-timeout): 풀에 가용한 커넥션이 없을 때, 클라이언트가 커넥션을 얻기 위해 대기할 수 있는 최대 시간입니다. 이 시간을 초과하면 오류가 발생합니다.
• 최대 유휴 시간 (idle-timeout): 커넥션이 풀에서 사용되지 않고 대기할 수 있는 최대 시간입니다. 이 시간이 지나면 커넥션은 풀에서 제거되어 불필요한 자원 낭비를 방지합니다.
• 최대 유지 시간 (max-lifetime): 커넥션의 최대 수명 시간입니다. 이 시간이 지나면 사용 중이더라도 반납 시 풀에서 제거됩니다. MySQL의 wait_timeout(기본 8시간) 때문에 발생하는 커넥션 단절 문제를 예방하기 위해, 이 값을 DB의 wait_timeout보다 짧게 설정하는 것이 매우 중요합니다.

2. 서버 캐시 전략 ⚡

스케일 아웃/업은 비용이 많이 들기 때문에, 응답 시간을 줄이기 위한 효과적인 대안으로 캐시를 사용합니다. 캐시는 자주 조회되는 데이터를 키-밸류(Key-Value) 형태로 빠른 저장소(주로 메모리)에 보관하여 느린 DB 조회를 피하게 해줍니다.

캐시 효율성 측정: Hit Rate

캐시의 효과성은 캐시 히트율(Cache Hit Rate)로 측정합니다.

• Cache Hit Rate (%) = (캐시에서 데이터를 찾은 횟수 / 총 조회 횟수) * 100
• 히트율이 높을수록 DB 부하를 효과적으로 줄이고 있다는 의미입니다.

캐시 교체(삭제) 정책

캐시의 메모리는 한정적이므로, 새로운 데이터 저장 공간이 부족할 때 어떤 데이터를 삭제할지 결정하는 규칙이 필요합니다.

• LRU (Least Recently Used): 가장 오랫동안 사용되지 않은 데이터를 삭제합니다. "한번 액세스한 데이터는 가까운 미래에 다시 액세스될 것이다"라는 시간 지역성(Temporal Locality)에 기반한 가장 일반적인 정책입니다.
• LFU (Least Frequently Used): 가장 적게 사용된(액세스 빈도가 낮은) 데이터를 삭제합니다.
• FIFO (First-In, First-Out): 가장 먼저 들어온 데이터를 순서대로 삭제하는 가장 간단한 방식입니다.

캐시의 종류: 로컬 캐시 vs 리모트 캐시

캐시 사전 적재

트래픽이 순간적으로 급등한다면 해당정보를 미리 캐시애두는 것도 고려 가능

캐시 무효화

유효하지 않은 데이터를 적절한 시점에 캐시에서 삭제하는 것이 중요함

변경에 민감한 데이터는 로컬 캐시가 아니라 리모트 캐시에 보관

오늘은 SECS 메시지들을 TCP 로 통신할때 필요한 전송 표준인 HSMS 에 대해 알아보겠다.

HSMS(High Speed SECS Message Service) 란?

기존에 SECS 통신은 RS-232라는 직렬 시리얼 통신 위에서 SECS-I를 통해 SECS-II 메시지들을 주고받으며 통신이 이루어졌다.

하지만 점점 이더넷 기술 규격이 발달하고 널리 퍼짐에 따라 TCP/IP 프로토콜을 사용해서 통신을 하는 시대가 됐다.

그래서 이러한 TCP/IP 위에서도 안정적으로 SECS-II 메시지들을 사용해서 통신을 주고받을 수 있도록 규약을 만든 것이 HSMS 프로토콜이다.

→ HSMS란? TCP/IP 네트워크 상에서 SECS-II 메시지를 안정적으로 주고받기 위한 전송 프로토콜 이다.

이제 HSMS 프로토콜의 구조를 살펴보자.

HSMS 프로토콜의 구조

기본적으로 SECS-I 프로토콜에서 크게 구조가 변하지 않았다.

• A 영역(Length) : 4 byte, B 영역과 C 영역의 길이를 나타낸다.
• B 영역 (Header) : 10 byte (Session Id, Heder Byte 2, Header Byte 3, Ptype, Stype, System Byte)
• C 영역 (Data) : 가변적 , SECS-II 메시지가 존재.

Header (B영역)

HSMS 메시지의 헤더는 크게 Session Id, Heder Byte 2, Header Byte 3, Ptype, Stype, System Byte 로 나뉘어져 있다.

• Session ID

  Device ID, Host ID 각 통신 객체간의 관계를 규정하는 영역

• Header Byte 2

  HSMS 메시지는 크게 Data Message와 Control Message로 나뉜다.

  메시지 유형은 SType 값으로 구분함 (0: Data Message, 그 외: Control Message)

  • 1. Data Message (데이터 메시지)

       실제 생산 장비와 호스트 간의 SECS-II 메시지를 전송할 때 사용

       • 구성 요소
         • W-Bit (MSB): 응답 필요 여부를 표시
         • 1: 응답 필요
         • 0: 응답 불필요
       • Stream Number (하위 7비트): SECS-II 메시지의 Stream 번호
       • 용도
         • 장비 상태 보고
         • 명령 실행
         • 데이터 수집
  • 2. Control Message (제어 메시지)
       • 특징
         • 일반적으로 Header Byte 2는 0으로 설정
         • 특수한 경우 상태 코드 포함 가능
       • 용도
         • 연결 설정
         • 연결 해제
         • 링크 테스트

• Header Byte 3

  • Data Message일 경우:

    • Function Number (8비트 전체 사용)

      → SECS-II 메시지에서 사용하는 Function 코드 번호를 의미.

      → 즉, 특정 Stream 안에서 어떤 기능(명령/응답)인지를 구체적으로 지시하는 값.

  • Control Message일 경우:

    • Control Type (8비트 전체 사용)

      → 제어 메시지의 종류를 지정함. (예: 연결 요청, 연결 종료, 링크 테스트 등)

• PType (Protocol Type)

  • 항상 0으로 설정 (Reserved)
  • HSMS에서 통신 프로토콜 타입은 고정값을 가지며, 추가 정의 없이 0을 사용함.

• SType (Session Type)

  • 이 메시지가 어떤 종류의 통신 세션 메시지인지를 나타낸다.
  • 대표적인 SType 예시:
    • 0: Data Message (SECS-II 데이터 전송용)
    • 1: Select.req (연결 요청)
    • 2: Select.rsp (연결 응답)
    • 5: Linktest.req (링크 상태 테스트 요청)
    • 6: Linktest.rsp (링크 상태 테스트 응답)
    • 9: Separate.req (연결 종료 요청)

• System Bytes (4 Byte)

  • 송신자가 임의로 설정하고, 응답 시 동일하게 복사되어 돌아오는 값.
  • 요청-응답을 매칭하기 위한 용도로 사용됨.
    • 예를 들어, 송신자가 메시지를 보낼 때 System Byte를 1234로 설정했다면, 그 응답 메시지에도 1234가 붙어 와야 한다.
    • 이렇게 해서 요청과 응답 쌍을 구분하고 관리할 수 있다.

Control Message 와 Data Message

1. Data Message (데이터 메시지)

• 목적: 실제 생산장비와 호스트(서버) 간에 업무용 데이터를 주고받기 위한 메시지.
• 특징:
  • SType = 0.
  • SECS-II 메시지를 담고 있음. (장비 상태 보고, 명령 수행, 데이터 수집 등)
  • Header Byte 2의 상위 1비트(W-Bit)가 응답 필요 여부를 표시:
    • 1 → 이 메시지에 대해 응답이 필요함.
    • 0 → 이 메시지에 대해 응답이 필요 없음.
  • Header Byte 2의 하위 7비트는 Stream Number (SECS-II Stream 번호).
  • Header Byte 3는 Function Number (SECS-II Function 번호).
• 구성 예시:

- Stream 2, Function 17 : 특정 명령 전송
- Stream 3, Function 1 : 상태 요청

2. Control Message (제어 메시지)

• 목적: 통신 상태를 관리하기 위한 메시지. (연결, 해제, 유지 등)
• 특징:
  • SType ≠ 0 (0이 아닌 값들: 1, 2, 5, 6, 9 등)
  • SECS-II 데이터는 포함되지 않음 (C 영역이 없음 또는 아주 짧음).
  • 통신 자체를 유지하거나 제어하기 위한 간단한 명령을 보내는 것.
  • Header Byte 2는 보통 0으로 설정.
  • Header Byte 3는 Control Type을 나타냄. (어떤 제어 명령인지를 지정)
• 주요 Control Message 종류 (SType 기준):

즉 정리하자면 Control Message냐 Data 메시지냐는 아래에 따라 알 수 있다.

오늘은 SECS-I 나 HSMS 위에서 상위 계층으로써 메시지의 구조를 약속한 규약인 SECS-II에 대해 알아보자...

SEMI E5 : 실제 송수신되는 메시지의 통신 내용(Content), Data 영역에 대한 프로토콜인 SECS-II 에 대한 표준

SECS-II는 SECS-I나 HSMS 통신 위에서 캡슐화되는 메시지의 구조와 표현 방식을 정의하는 포맷 규약이다

처음 메시지 구조를 봤을 때 xml 이나 JSON 과 비슷하다는 생각을 했다.

XML이나 JSON과 유사하지만, 중요한 차이점이 있다면 XML이나 JSON은 단순히 메시지의 구조만 정의하는 반면, SECS-II의 메시지는 사전에 정의된 특정한 의미를 포함한다.

✅ SECS-II와 JSON/XML 비교

그렇다면 왜 JSON/XML 같이 널리 쓰이는 포맷으로 통신하고 특정한 의미. 즉 시스템 정의만 따로 해서 사용하면 되는데 왜 SECS-II 라는 표준 규약을 사용할까?

그거야 secs I 와 secs II가 같은 시기에 개발되어서….라고도 할 수 있지만

적은 오버헤드와 고밀도로 데이터를 전송할 수 있기 때문에.. 가 될것같다.

의미를 포함한 데이터 포맷을 지정해뒀기에 하드웨어 수준에서 이를 해석하는데 오버헤드가 적다.

아래 블로그에 이러한 비교가 잘 되어있음.

애초에 SECS 프로토콜을 설계할때에 밀접하게 설계해뒀기에 SECS-I 위에서 오버헤드가 가장 적다.

SECS/GEM series: Protocol Layer SECS / GEM 시리즈 : 프로토콜 레이어

보통 osi 7 layer에서 캡슐화를 할때에는

이런식으로 상위 레이어의 헤더 + 데이터 = 하위 레이어의 데이터 가 되는 경우가 많다. 그래서 캡슐화 시에 상위 레이어로부터 받은 헤더, 데이터 정보들은 하위 레이어들의 해석에 아무런 의미가 없다. 하지만 HSMS + SECS II 나 SECS I + SECS II 는 다르다. 얘는 HSMS의 헤더와 데이터가 SECS- II 의 포맷에 포함되어있음. 그래서 SECS - II 메시지를 파싱하려면 HSMS의 헤더랑 데이터 둘다 봐야한다.

1. Stream / Function

SECS-II 메시지는 스트림과 펑션에 의해 구분된다.

• Stream : 유사한 특성을 갖는 메시지의 그룹, 예약영역 + 사용자 영역 합쳐서 S1 ~ S127 까지 있다.
• Function : 각 스트림 내에서 특정한 기능을 하는 메시지, 예약영역 + 사용자 영역 합쳐서 F1 ~ F255 까지 있다
  • Stream 안에서 각 세부 기능에 관련된 개별 Msg
  • Primary Msg는 항상 홀수의 Function 번호를 갖는다.
  • Reply (Secondary) Msg는 Primary Msg Function 번호에 1을 더한 수로 모두 짝수이다.
  • Function 번호는 '0'은 Message Transaction 취소를 위해 예약되어 있다.

SEMI 에서는 특정한 의미를 갖는 SECS-II 메시지들을 이미 많이 만들어 두고 사용하고 있고 사용자 정의도 가능

이전에 공부한 SECS-I 10 Byte 헤더의 3번, 4번 Byte가 Stream과 Function을 가리킵니다. Stream이 예약영역과 사용자 영역을 합쳐 S1S127까지 2^7개 사용 가능하고, Function이 F1F256까지 사용 가능한 이유는 SECS-I 헤더의 3번 Byte에 W-bit(전송되는 메시지에 대한 송신측의 응답 여부를 표시하는 비트)가 할당되었기 때문으로 보입니다.

2. SECS 프로토콜의 Data 형식과 구조

SECS 프로토콜에서 통신되는 데이터들은 일반적으로 다음과 같은 구조를 가진다.

1. Block 의 구조

• SECS -I 의 경우 Block 구조

  

  

이전글 참고 : https://velog.io/@junr_65535/SECS-I-%EB%B6%80%ED%84%B0-HSMS-%EA%B9%8C%EC%A7%80-01-SECS-I-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC

checksum : RS-232 시리얼 통신 위에서 돌아가기 때문에 Checksum 으로 Header와 Data 영역의 바이트 값을 이진 덧셈처리하여 CheckSum을 통해 오류 검출한다.

• HSMS의 경우 Block 의 구조는 아래와 같다.

![](https://velog.velcdn.com/images/junr_65535/post/5fe0ff2c-5c74-49db-af68-1fe42701648a/image.png)

HSMS 의 경우 TCP/IP 위에서 돌아가기 때문에 (TCP가 체크섬을 통해 무결성을 체크해주잖슴~ 참고: [6~9](https://www.notion.so/6-9-1a394635e71680038907f3d259b3734a?pvs=21) ) CheckSum 을 가지지 않는다. 

2. Data의 구조

• Data는 Header에 정의된 Stream과 Function 정보에 의해 정의되며 여러개의 List와 Item이 트리구조로 구성되어있다.
• 다만 SECS-II Msg는 항상 Data 영역을 포함하고 있진 않다. Header 의 스트림과 펑션으로만 정의되는 예약된 메시지들이 존재하기 때문이다.

3. List와 Item 의 구조

• LIST

  • 다른 ITEM을 포함하는 컨테이너 역할

  • 어떤 값을 가지는게 아니라 다른 ITEM들을 담는 그릇이라고 생각하면 됨

  • LIST 안에는 또 다른 LIST를 넣을 수 있다. (재귀적으로 트리 구조 형성 가능)

  • 예시

    // list 안에 두개의 아이템이 들어있음.
    <L [2]
    <U1 1>   // = 부호 없는 1바이트 정수 1
    <A "OK"> // = ASCII 문자열 OK
    >

• ITEM

  • 실제 데이터를 가지는 최소단위

  • 항상 "형식(Type)" + "길이(Length)" + "값(Value)" 구조로 구성되어 있음

  • 데이터 구조

    

    - #of Length Bytes : Length Bytes의 개수 (1 - 3)
    - Item Format Code : Item의 종류
    - Length Bytes :
    1. List : Sub Item의 개수
    2. Item : Item Body의 바이트 수
        - 1 Byte = ~ 255 Bytes
        - 2 Byte = ~ 65,536 Bytes
        - 3 Byte = ~ 16,777,215 Bytes

3. Data Item Dictionary

SECS-II에서 사용되는 데이터 구조(Item)의 이름, 형식, 의미 등을 정의한 공식 문서 또는 표준 사전

SECS-II 메시지(SxFy)는 <L[2] <U1 3> <A "READY">>와 같은 데이터 구조만으로는 그 의미를 파악하기 어려움.

따라서 "S6F11의 첫 번째 필드는 CEID이고, 두 번째는 Report List이다"와 같이 각 필드의 의미를 표준화하여 문서화한 것이 Data Item Dictionary이다...

아래와 같이 정의되어있다고 한다.

• 필드명 설명
  • Name: CEID, RPTID, VID 등 데이터 item의 이름
  • Format: SECS-II 포맷 A, U1, I2, F4, L 등 데이터 형식
  • Description: 항목의 의미 (예: Collection Event ID)
  • Optional/Required: 해당 필드가 필수인지 여부
  • Where Used: 이 항목이 포함되는 메시지(SxFy) 목록
  • Constraints: 길이, 값의 범위 등 제약 조건

느낀점.

SECS - I 과 SECS - II 가 진짜 밀접하게 설계되어있다고 느꼈다.. HSMS 개발할때 호환성 맞추기 위해 고생 꽤나 했을듯

• 더 공부할점

  1. SECS-II의 스트림(S)과 펑션(F) 조합에 대한 상세 학습

     • 각 SxFy 메시지의 구체적인 용도와 의미
     • 일반적으로 많이 사용되는 메시지 패턴

  2. Data Item Dictionary 심화 학습

     • CEID, RPTID, VID 등 주요 데이터 아이템의 상세 의미와 용례

     GEM공부를 하면 아마 1번은 실제적인 용례들과 함께 공부하게 될듯 싶다.

참고.

https://www.cimetrix.com/blog/secs-gem-series-protocol-layer

https://m.blog.naver.com/posionsnake/222147003877

https://developer-kus.tistory.com/22

CIM 과 AMHS 서비스 사이에서 HSMS 프로토콜로 통신이 이루어진다는데 해당 프로토콜에 대해 공부하면서 알게 된 점을 정리한 페이지입니다.

반도체 공장 자동화를 위해 SEMI에서는 다양한 국제 표준과 가이드라인을 제정했다.

반도체 공정에는 여러 종류의 장비와 호스트 간의 통신이 필요하다. 이러한 장비들 간의 원활한 통신을 위해 SEMI는 국제 표준 통신 규약을 수립했다.

“SEMI”는 반도체, 광전지 (PV), 전자 및 기타 첨단 기술 산업 등의 제조 공급망을 지원하는 글로벌 산업 협회

그중 SEMI 가 만든 표준 프로토콜은 다음과 같은 종류가 있다.

SEMI E4 : 호스트와 설비의 통신을 주고받기 위해서 RS-232로 이루어지는 시리얼 통신 위에서 동작하는 프로토콜인 SECS-I 에 대한 표준

SEMI E5 : 실제 송수신되는 메시지의 통신 내용(Content), Data 영역에 대한 프로토콜인 SECS-II 에 대한 표준

SEMI E37 : TCP/IP 통신 위에서 이루어지는 통신 프로토콜인 HSMS(High Speed SECS) 에 대한 표준

이러한 SECS 표준은 SECS-I, SECS-II, GEM, HSMS, EDA 순으로 발전해왔음.

SECS-I (SEMI E4)

RS-232C 라는 시리얼 통신 물리 계층 매체 위에서 송수신하는 규약을 정의

• 특징
  • 1 Start Bit(0) - 8Data bits - 1 Stop Bit (1) 구성
  • 비동기 / 양방향 통신
  • Block을 통한 데이터 전송
    • 1 Block = Header(10bytes) + Data (1block은 최대 254 바이트)
    • 1 Message 는 1~32,767 Block 으로 구성 (1 Msg는 최대 7,995,148 바이트의 Data로 구성)

Transaction 과정

SECS-I 프로토콜은 시리얼 통신 위에서 데이터를 주고받기 위해 handshake 과정을 주고받습니다.

이러한 단계의 통신 과정을 BLOCK 이라고 부릅니다.

만약 Message가 길어서 다중 Block 으로 전송하게 될 경우 해당 과정을 반복하여 데이터를 보내게 됩니다.

Block 의 구조

• 1 Block = Header (10Byte) + Data (Max 254Byte)

Header 의 구조

• 만약 메시지의 길이가 길어서 다중 블록으로 구성된다면 해당 헤더의 Block No Byte 에 각 블록에 대한 정보가 포함된다.

참고

1. SECS Message Code Generation Tool - SECS 메시지 코드 생성 도구
2. [SescGem] 반도체 통신 프로토콜 SEMI E5 (SECS-I, SECS-II, HSMS) - SEMI 표준과 프로토콜에 대한 상세 설명
3. SECS #2 - SECS-I(SEMI E4) - SECS-I 프로토콜의 정의와 특징
4. [SECS] Semiconductor Equipment Communication Standard -Ⅰ(SECS-Ⅰ) - RS-232를 통한 통신 방법
5. secs-I 프로토콜 이란? - SECS-I 프로토콜의 기본 개념

OSI 7계층에 대해 설명해 주세요.

OSI 7계층은 ISO에서 표준으로 정의된 네트워크 참조 모델임.

왜 OSI 7계층을 사용해야 할까?

1. 네트워크의 구성과 설계가 용이

   • 각 계층의 목적에 맞게 프로토콜과 장비를 설계할 수 있음.

2. 효율적인 문제점 파악과 해결

   • 다른 시스템 간에 계층별 원인을 빠르게 파악할 수 있음. 또한 호환성 체크도 가능함.

💡 OSI 7계층 정리

1. 물리 계층 : 1,0으로 표현되는 비트 신호를 주고받는 계층
2. 데이터 링크 계층 : 네트워크 내 주변 장치 간의 정보를 올바르게 주고받기 위한 계층
3. 네트워크 계층 : 메시지를 다른 네트워크에 속한 수신지까지 전달하는 계층
4. 전송 계층 : 신뢰성 있고 안정성 있는 전송을 해야 할 때 필요한 계층
5. 세션 계층 : 세션(통신을 주고받는 호스트의 응용 프로그램 간 연결 상태)을 관리
6. 표현 계층 : 문자를 컴퓨터가 이해할 수 있는 코드로 변환하거나 압축, 암호화
7. 응용 계층 : 사용자 및 사용자가 이용하는 응용 프로그램에 다양한 네트워크 서비스

Transport Layer와 Network Layer의 차이

네트워크 계층(Network Layer)

• 데이터를 다른 네트워크에 전달하는 역할을 함.
• 주로 IP 주소를 사용하며, 데이터를 목적지까지 전달하는 경로 설정에 중점을 둠.

전송 계층(Transport Layer)

• 데이터를 송신지와 수신지 간에 신뢰성 있게 전달하는 역할을 함.
• 데이터 전송의 신뢰성 보장과 오류 제어, 흐름 제어 등의 기능을 제공함.

🧠 요약

• 네트워크 계층: 데이터 경로 설정 담당
• 전송 계층: 데이터 전송의 신뢰성 보장

💡 더 알아보기 💡

1. 네트워크 계층

LAN에 한정된 물리, 데이터링크 계층의 통신 범위의 한계를 해결하기 위해 사용하는 계층.

• 왜 물리, 데이터링크 계층이 LAN을 넘어서 통신하기 어려울까?

  1. 다른 네트워크까지의 도달 경로를 파악하기 어려움 → 네트워크 계층이 있어야 네트워크 간의 라우팅이 가능하다.

     • 라우팅 : 패킷이 이동할 최적의 경로를 결정하는 것.

     • 라우터 : 라우팅을 수행하는 대표적인 장비

       2. MAC 주소만으로는 모든 네트워크에 속한 모든 호스트의 위치를 특정하기 어려움

       MAC 주소와 IP 주소는 함께 사용되고, 기본적으로 IP 주소를 우선 활용

       

    IGP : AS 내부에서 수행 RIP, OSPF

    - 거리벡터 활용 RIP, 즉 홉의 수가 가장 적은 경로를 최적의 경로라고 판단.
        - 홉 수가 적을수록 라우팅 테이블 상의 메트릭 값도 적어짐
        - 주기적으로 인접 라우터끼리 경로 정보 교환 및 라우팅 테이블 갱신, 특정 수신지까지 홉 수 계산
    - 링크 상태

    EGP : AS 외부에서 수행 

2. 전송계층

• 네트워크 계층과 표현-응용계층 사이에 존재.

1. IP 한계 보완: 신뢰할 수 있는 통신과 연결형 통신 기능 제공

   • IP의 특징

     • 신뢰할 수 없는 프로토콜

       • 패킷이 수신지까지 제대로 전송되었다는 보장을 하지 않음
       • 통신 과정에서 패킷이 잘못 전송되어도 이를 확인하지 않고 재전송도 하지 않으며 순서대로 패킷이 도착할 것이라는 보장도 하지 않는다.

     • 비연결형 프로토콜

       • 송수신 호스트간에 사전 연결 수립 작업을 거치지 않음.
       • 그저 수신지를 향해 패킷을 쏘기만 할 뿐.

       그렇다면 IP는 왜 이러한 신뢰할 수 없는 비 연결형 통신을 할까?

     • 주된 이유는 신뢰할 수 있는 연결형 통신이 성능에 악영향을 끼치기 때문이다.

     • 신뢰성 있는 전송이 모든 경우에 필요한 것은 아니다.

     TCP

   • 연결형 통신을 가능하게 함

     송수신 동안에는 연결을 유지하고 송수신이 끝나면 연결을 종료

   • 신뢰성 있는 통신을 가능하게 함.

     • 재전송을 통한 오류 제어, 흐름제어, 혼잡 제어 등 다양한 기능 활용

     UDP

   • 신뢰할 수 없는 통신, 비연결형 통신을 가능하게 함.

   • TCP보다 비교적 빠른 전송이 가능

2. 응용 계층의 프로세스(실행중인 프로그램) 식별: 포트 번호 활용

   • 포트 : 네트워크 상의 애플리케이션 식별 정보

     

     • well-known port

       0~1023번까지의 포트

       시스템 포트, 범용적으로 사용되는 애플리케이션 프로토콜이 일반적으로 사용되는 포트 번호

     • registered port

       1024~49151번까지의 포트

       잘 알려진 포트에 비해서는 덜 범용적

       흔히 사용하는 애플리케이션 프로토콜에 할당하기 위해 사용

     • dynamic port

       특별히 관리되지 않은 포트 번호 범위: 자유롭게 사용 가능

       서버는 대부분 잘 알려진 포트와 등록된 포트 사용

       클라이언트(웹브라우저)는 대부분 동적 포트 사용

       

(출처: 강민철, "혼자서 공부하는 네트워크")

L3 Switch와 Router의 차이

🧠 정리

• L3 스위치: 빠른 성능과 비용 효율적, 내부 네트워크 최적
• 라우터: 다양한 프로토콜과 안정성, 보안 기능 제공

참고

OSI 7계층 개념 설명 (IT BEST-PATH)

각 Layer의 데이터 명칭

🧠 패킷 이름을 달리하는 이유

• 각 계층에서 처리하는 데이터의 단위가 다르기 때문임.
• 계층별로 데이터의 캡슐화(Encapsulation)와 역캡슐화(Decapsulation)를 거침.

각각의 Header의 Packing Order에 대해 설명해 주세요.

데이터가 송신될 때는 다음과 같은 순서로 헤더가 추가됩니다:

1. 응용/표현/세션 계층: 원본 데이터 생성
2. 전송 계층: TCP/UDP 헤더 추가 (세그먼트/데이터그램 생성)
3. 네트워크 계층: IP 헤더 추가 (패킷 생성)
4. 데이터 링크 계층: 이더넷 헤더와 트레일러 추가 (프레임 생성)
5. 물리 계층: 비트 단위로 변환하여 전송

수신측에서는 이 과정이 역순으로 진행되어 각 계층에서 해당 헤더를 제거하며 데이터를 처리합니다. 이런 과정을 캡슐화(encapsulation)와 역캡슐화(decapsulation)라고 합니다.

데이터 링크 계층은 헤더 + 페이로드 정보가 추가됨!

대표적인 이더넷 네트워크에서 주고받는 프레임의 헤더와 패킹 오더를 설명하자면

상위 계층의 캡슐화를 거쳐 송신된다.

• 헤더 - 프리앰블, 수신지 MAC 주소, 송신지 MAC 주소, 타입/길이

  • 프리앰블 : 이더넷 프레임의 시작을 알리는 8 바이트 (64비트) 정보

    • 첫 7바이트는 10101010 값을 가지고 마지막 바이트는 10101011 값을 가짐

      • 송수신지 간의 동기화

      • MAC 주소

      • 물리적 주소, 일반적으로 고유하고 변경되지 않음

      • 네트워크 인터페이스마다 부여되는 6바이트 길이의 주소

        • LAN내의 송수신지 특정
        • 일반적으로 NIC 장치가 네트워크 인터페이스를 담당
        • 한 컴퓨터에 MAC 주소 여러개 가능

      • 타입/길이

      • 필드에 명시된 크기가 1500 이하일 경우 - 이 필드는 프레임의 크기

      • 필드에 명시된 크기가 1536 이상일 경우 이 필드는 타입

• 페이로드 - 데이터

  • 상위 계층에서 전달받거나 전달해야 할 내용
  • 최대 크기 1500byte, 최소 크기 46 byte
  • 46 byte 보다 작다면 크기 맞추기용 padding 이 채워짐.

• 트레일러 - FCS(Frame Check Sequence)

  

  • 오류 검출용 정보 : 수신한 이더넷 프레임에 오류가 있는지 체크하는 필드
  • CRC라는 오류 검출용 값이 명시됨

ARP(Address Resolution Protocol)에 대해 설명해 주세요.

• IP 주소를 통해 MAC 주소를 알아내는 프로토콜임.
• 동일 네트워크 내의 송수신 대상의 IP 주소를 통해 MAC 주소를 알아낼 수 있음.

🧠 동작 과정

1. ARP 요청: 브로드캐스트 메시지를 통해 MAC 주소를 요청함.
2. ARP 응답: 해당 호스트가 자신의 MAC 주소를 담아 응답함.
3. ARP 테이블 갱신: ARP 테이블에 IP와 MAC 주소를 매핑하여 저장함.

• 다른 네트워크의 MAC 주소를 모를 경우, 각 네트워크별로 ARP가 수행됨.

한국에서 진행되는 노션의 가장 큰 행사중 하나인 Notion Innovators Summit 2024 에 다녀왔다. 행사는 경희대학교에서 진행되었으며 이번 회차의 주제는 비즈니스, 스타트업, 교육 이었다. 행사는 12월 7일 10시부터 18시까지 진행되었으며 주제가 비즈니스, 스타트업, 교육인만큼 여러 도메인이 계신 분들의 사례 공유 및 템플릿들을 볼 수 있었다.

행사 참여 전.

나같은 경우 위와 같이 기존의 노션 페이지 관리에서 PARA 기법에 따라 기록을 나누고 관리하려고 준비중인데 다른 사람들은 개발자나 PM으로서 이런 자신의 대쉬보드들을 어떻게 관리하는지 알아갈 수 있으면 좋겠다고 생각했다.

행사 세션별 후기

각 세션별 느낀 점

1. 교직에서의 Notion 활용법 (원정민)

• 초등 교사라는 도메인에 맞춘 노션 활용이 현실적이고 실용적이었다.
• 픽셀아트나 기행문 작성 같은 활동으로 학생들과 협업하는 방식이 인상적.
• 노션 캘린더의 UI 한계점을 보며 개선 아이디어도 떠올랐다.

2. Notion 고객 성공 Manager가 톺아주는 Notion

• 노션의 새로운 기능(폼, 메일)과 향후 계획(JIRA 연동, 팀즈 지원)을 들을 수 있었다.
• 커뮤니티 기반 성장의 중요성을 다시 느꼈다.
• B2B 영역에서 노션의 영향력과 활용도가 크게 확장될 가능성이 보였다.

3. bati.ai를 활용한 Notion 자동화 (류장현 대표님)

• 카카오톡, 메일, 캘린더와 실시간 연동되는 자동화 솔루션은 활용도가 높아 보였다.
• 맞춤형 메시지 발송같은 기능들이 충분히 활용하기 쉽다면 부모님과 함께 했던 커튼 사업에 적용하기 좋아보인다.
• 자신의 회사 서비스가 Notion 기반으로 사용되고 있고 다른 도메인 지식이 없다면 간편하게 도입하기 좋은 서비스일 것 같다.
• 개인 프로젝트에서 아이디어를 도입할 가능성을 생각해봤다.

4. 노션으로 나다운 삶을 향해 나아가는 법 (기록가 연)

• 노션을 활용해 자기 개발과 성장의 흔적을 남길 수 있다는 점이 인상적이었다.
• 나만의 스토리를 기록하며 동기부여 도구로 활용 가능.
• 실용적인 템플릿 제작 아이디어를 얻었다.

5. 노션을 활용한 교실 (임세범)

• 노션에서 mermaid를 활용한 도식화 기능은 처음알았다.
• 확실히 교사들의 Notion 커뮤니티가 잘 활성화 되어있는 것 같다.
  • 노션은 컴퓨터와 가까이에서 일하는 사람일수록 더욱 잘 활용할 수 있게 된다 는 생각이 맞는듯.

6. Notion으로 Personal AI persistant 만들어보기

• 비구조화된 데이터를 활용한 personal AI 구성 아이디어가 흥미로웠다.
• 임베딩과 데이터 적재의 중요성을 깨달았다.
• 또한 Storm Parse 툴은 꽤나 유용하다. 흠. Notion의 마크다운 추출을 사용해서 임베딩하고 해당 임베딩한 툴을 Storm Parse AI 를 통해서 이미지와 함께 프롬프팅 해두고 이를 RAG 체인의 한 파트로 채용시킬 수 있다.
  • 하지만 Notion AI 가 사용자의 Personal AI Asistant 지향하고 점점 발전중인데 일반인이 이걸 구현시키는 노력보다 큰 아웃풋이 있을지 궁금하다.
• 그래도 Storm Parse 사이트를 알게된건 아주 좋다.

7. 사용자 경험을 고려한 노션 템플릿 제작 프로세스 (노션 너굴)

• 더블 다이아몬드 프로세스를 노션 템플릿 제작에 적용한 방식이 신선했다.
• 스터디를 진행하면서 여러 템플릿을 커스텀하고 만들었던 경험이 있는데 해당 프로세스를 사용하면 어떨까?
• "템플릿 하단에 원본 데이터베이스를 삽입" 한다는 것이 인상적이었다.

8. Notion AI로 남들보다 1시간 먼저 퇴근하는 비법

• 노션은 DB로 AI, 자동화(Make 와 같은 툴) 세가지가 삼위일체로 있어야 자동화이다.

• 회사 일이나 여러 업무에서 아이젠아워 메트릭스의 C 항목들을 이 삼위일체로 해결할 수 있다면?

  

• 부모님이 커튼일에 대한 프로세스를 생각했을 때에 해당 부분을 적용해서 최적화할 수 있을듯.

• 흠. 과연 내가 내년에 이러한 세션을 맡게됐을 때에 인원을 파악하고 레벨을 파악해서 강의를 준비하고 배우고 싶은 점을 분석하는 과정을 꼭 거쳐야겠다.

• 아니 그런데 이러한 Make 자동화를 만드는 과정이 사실 가장 어렵고 반복적인 일 아닌가?

  • 이런 자동화 툴을 구성하는 것을 자동화하는 건 안되나? 흠….

9. Notion으로 사이드 프로젝트 런칭하기 (노션 남매의 헌트님)

• 개발 중심이 아닌, 콘텐츠의 힘으로 브랜드와 비즈니스를 만들어가는 사이드 프로젝트들을 볼 수 있었다.
• 노션 활용에는 본인의 이해도뿐만 아니라 팀원들의 이해도도 중요하다는 것을 깨달았다.
• 앞으로 기업들에게 노션을 비롯한 협업 도구에 대한 이해도를 높이는 것이 중요할 것 같다.
• 블로깅을 하면서 단순한 정보 전달과 생동감 있는 콘텐츠 사이의 차이를 이해하게 되었다.

10. 스타트업 비즈니스를 위한 노션 데이터베이스 설계 (Keep Code)

• KeepCode라는 노션 컨설팅 업체에서 다른 여러 케이스들의 최적화했던 경험과 노하우를 배웠다

• 노션 페이지를 만들었을 때

  • 고객과의 라포가 많이 필요한것 → 자동화보다 관계가 중요

• 노션으로 이런 것도 가능하구나 하는 걸 실감했다

• 수제 케이크 주문 및 레시피 관리, 치과 기기 관리, 피티 내부 직원 성과 관리 등 실제 사례들을 보니 정말 다양한 분야에서 활용되고 있다는 게 놀라웠다

• 웹사이트 구축보다 이런 맞춤형 노션 솔루션이 소규모 비즈니스에 더 실용적일 것 같다는 생각이 들었다. 가격대가 궁금할 정도로...

11. Make Story with Notion (차지영 님)

• 40대 후반의 연사가 노션 엠베서더가 된 여정이 감동적이었다.
• 나이와 상관없이 배움을 지속하는 열정을 배울 수 있었다.
• 우리 부모님도 사용하실 수 있을지 생각하며 연사의 발표를 지켜봤다.

12. 사랑은 노션을 만들고, 노션은 사랑을 만듭니다. (한바름 님)

• 커플 노션을 4년간 꾸준히 이어온 비결이 궁금했다.
• 공통의 기록 공간을 유지하는 데 필요한 노력과 창의성이 대단했다.

아쉬웠던 점들

1. 운영상의 문제

• 기존 발표 시각보다 1시간 정도 지연되었고 연사들의 특강이 있을 때에 화면의 밝기나 마이크 배터리 없음 등 크고 작은 이슈들이 있었다.

  2. 개발자 대상 세션 부족

• 전체적으로 개발자분들의 참여도가 높아보였음에도 불구하고 이러한 분들을 윟나 깊이 있는 세션이 부족했떤 것들이 아쉬웠다.
• 예를 들어, Notion API를 활용한 웹사이트 구축이나 개인 프로젝트를 위한 고급 활용법 등이 추가되면 좋았을 듯하다.

취준생 개발자로서 느낀 점

• 노션은 도구 이상이다. 단순한 협업과 기록 툴을 넘어 비즈니스 관리, 심지어 퍼스널 브랜드 구축까지 가능하다는 걸 알게 됐다
• 교사분들의 발표를 보며 커뮤니티의 활성화와 정보공유가 아주 활발하다는 것이 인상깊었다.
• 내년에는 노션 사용자의 파이가 큰 개발자 입장에서 내가 잘하는 스터디 템플릿 제작, 공유 및 운영 프로세스를 체계화하여 내년에는 나도 이런 자리에 설 수 있도록 준비해보고 싶다.

ps. 사은품 양보해주신 노션 남매의 헌트님, 앞자리 말동무해주시고 취준생이라고 칼국수 사주신 선생님 감사합니다.

노션 서밋 행사에서 얻은 경희대 노션서밋 사진 피크민과 함께 이 글을 마칩니다.

CS_Study를 진행하면서 커널스택과 유저스택에 대한 이해도가 부족한 것 같아 다시 톺아보았다.

시스템 메모리 구조

인텔 8086 32비트 시스템은 다음과 같이 구성되어 있다.

메모리는 크게 유저 공간(User Space)과 커널 공간(Kernel Space)으로 구분된다.

• 유저 영역(2GB): 사용자 프로그램이 실행되는 공간으로, 일반적으로 프로세스마다 세그먼트라는 논리적인 섹션으로 나누어 독립적인 메모리 공간을 제공한다.
• 커널 영역(2GB): 운영체제가 관리하는 보호된 메모리 공간으로, 사용자 모드에서는 접근할 수 없다.

유저 영역 (User Space)

1. Null Pointer 할당 영역 (64KB)

   • Null 포인터 접근을 방지하기 위한 보호 영역으로, 잘못된 메모리 접근 시 Segmentation Fault를 발생시킨다.
   • 해당 영역은 어떠한 데이터도 저장되지 않으며, 프로세스의 오류를 조기에 감지하는 역할을 한다.

2. 유저 영역 (2GB)

   유저 영역은 프로그램 실행에 필요한 메모리를 제공하며, 다음과 같은 구성 요소로 나뉜다

   • 코드 섹션: 실행 가능한 기계어 코드가 저장된다.
   • 데이터 섹션: 초기화된 전역 변수 및 정적 변수가 포함된다.
   • BSS 섹션: 초기화되지 않은 전역 변수 및 정적 변수가 저장된다.
   • 힙(Heap): 동적으로 할당되는 메모리 공간으로, 실행 중 프로그램이 메모리를 요청할 때 사용된다.
   • 스택(Stack): 함수 호출 시 매개변수, 복귀 주소, 지역 변수 등을 저장하는 공간으로, LIFO(Last-In, First-Out) 방식으로 관리된다.

3. OFF-Limit 영역 (64KB)

   • 유저 영역과 커널 영역 사이에 위치한 보호 공간으로, 유저 모드에서 커널 영역으로의 잘못된 접근을 방지한다.

커널 영역 (Kernel Space)

커널 영역은 다음과 같이 8가지 주요 영역으로 구성되어 있다:

1. 커널 코드와 데이터
   • 커널 텍스트(segment): 커널의 실행 코드가 위치하는 영역. 읽기 전용으로, 일반적으로 수정되지 않음.
   • 커널 데이터: 커널의 전역 변수와 정적 변수.
     • 초기화된 데이터와 초기화되지 않은 데이터(BSS 세그먼트) 포함.
2. 페이지 테이블
   • 전역 페이지 테이블: 사용자 공간과 커널 공간 모두에 대한 페이지 매핑 정보가 포함됨.
   • 공통 매핑: 모든 프로세스가 공통으로 커널 공간을 참조할 수 있도록 페이지 테이블에 매핑.
3. 커널 힙
   • kmalloc API: 커널에서 사용하는 동적 메모리 할당 영역.
   • vmalloc 영역: 비연속적인 가상 메모리를 동적으로 할당받는 영역.
4. I/O 메모리 맵핑
   • 장치 메모리 매핑(Device Memory Mapping): 하드웨어 장치와 상호작용하기 위해 사용되는 영역.
   • 메모리 매핑 파일: 하드웨어 레지스터를 참조.
5. 고정된 매핑(Fixed Mapping)
   • 특정 물리 메모리 또는 하드웨어를 커널 공간에 고정적으로 매핑.
   • 예: APIC(Advanced Programmable Interrupt Controller)와 같은 프로세서 장치.
6. 스택 영역
   • 커널 스택: 프로세스가 커널 모드로 전환될 때 사용.
   • 프로세스 또는 스레드마다 별도로 할당되며, 컨텍스트 스위칭 시 작업 기록을 저장.
7. 모듈(Module) 영역
   • 동적으로 로드된 커널 모듈(예: 장치 드라이버)의 코드와 데이터가 저장됨.
   • 커널 실행 중 동적으로 할당 및 해제.
8. 예약되지 않은 영역
   • 하드웨어 의존적이거나 특수 목적으로 사용될 수 있는 영역.
   • 예: 커널 디버깅 데이터 또는 특정 장치와 관련된 데이터.

유저 스택과 커널 스택

자 이제 커널 허옇게 보이던 커널스택과 유저스택이 보인다. 시스템 메모리의 유저영역의 프로세스마다 독립적인 세그먼트에 올라가는 스택 섹션이 유저스택이고 커널스택은 커널 공간의 프로세스마다 독립적으로 존재하는 섹션이었다. 다시 정리해보자.

유저 스택 (User Stack)

• 위치: 프로세스의 사용자 주소 공간 내에 존재하며, 각 프로세스마다 독립적으로 할당된다.
• 용도:
  • 함수 호출 시 매개변수, 복귀 주소, 지역 변수 등을 저장한다.
  • 함수 호출과 복귀를 관리하며, 프로세스가 사용자 모드에서 실행되는 동안 사용된다.
• 특징:
  • 프로세스마다 고유하며, 가상 메모리 상에서 동적으로 크기가 조정될 수 있다.
  • 사용자 프로세스의 코드 실행 흐름을 보조한다.

커널 스택 (Kernel Stack)

• 위치: 커널 메모리 영역(32비트 시스템 기준 3GB~4GB)에 위치하며, 각 프로세스마다 고정된 크기로 할당된다.
• 용도:
  • 커널 모드에서 함수 호출, 로컬 변수 저장, 인터럽트 처리 등에 사용된다.
  • 프로세스 생성 시 프로세스별로 고정 크기로 할당되며, 일반적으로 8KB(32비트 기준)로 설정된다.
• 특징:
  • 커널 스택은 커널 모드에서만 접근 가능하며, 보안성과 안정성을 보장한다.
  • 재귀 호출이나 과도한 지역 변수 사용은 커널 스택 오버플로우를 초래할 수 있으므로 제한적으로 사용해야 한다.

유저 스택과 커널 스택의 연관성

유저 스택과 커널 스택은 프로세스 실행 중 시스템 호출이나 인터럽트가 발생할 때 상호작용한다.

1. 모드 전환:
   • 시스템 호출이나 인터럽트 발생 시, CPU는 유저 모드에서 커널 모드로 전환된다.
   • 이 과정에서 스택 포인터가 유저 스택에서 커널 스택으로 변경된다.
2. 정보 저장:
   • 전환 시, 프로세스 상태(예: 프로그램 카운터, CPU 레지스터 등)는 커널 스택에 저장된다.
   • 이를 통해 유저 스택과 독립적으로 커널 작업이 안전하게 수행될 수 있다.
3. 보안 및 안정성:
   • 유저 스택은 사용자 코드에 의해 수정될 가능성이 있으므로, 커널 작업은 커널 스택에서 보호된 환경에서 수행된다.
4. 주소 공간 분리:
   • 커널 스택은 모든 프로세스에서 동일한 물리적 주소를 참조하며, 커널 코드가 일정한 메모리 주소에서 실행되도록 보장한다.

컨텍스트 스위칭과 커널 스택

컨텍스트 스위칭(Context Switching)

컨텍스트 스위칭은 CPU가 실행 중인 프로세스 또는 스레드의 상태를 저장하고, 다른 프로세스 또는 스레드로 전환하는 작업이다. 이는 멀티태스킹 환경에서 필수적인 작업으로, 다음과 같은 과정을 포함한다.

1. 현재 프로세스 상태 저장:
   • 실행 중인 프로세스의 CPU 레지스터, 프로그램 카운터(PC), 스택 포인터(SP) 등의 상태 정보를 커널 스택에 저장한다.
   • 이 정보는 해당 프로세스의 PCB(Process Control Block)에 보관된다.
2. 운영 체제 커널로 전환:
   • 하드웨어 인터럽트, 시스템 호출, 또는 스케줄러 호출로 인해 CPU 제어가 커널로 넘어간다.
3. 새로운 프로세스 상태 복원:
   • 스케줄러는 다음 실행할 프로세스를 선택하고, 해당 프로세스의 커널 스택에 저장된 정보를 복원한다.
4. 프로세스 실행 재개:
   • 새로운 프로세스가 선택되고, 복원된 상태 정보로 실행을 시작한다.

컨텍스트 스위칭 중 커널 스택 활용

컨텍스트 스위칭 시, 커널 스택에는 다음 정보가 저장된다.

1. CPU 레지스터 상태:
   • 프로그램 카운터(PC), 스택 포인터(SP), 범용 레지스터 값 등.
2. 프로세스 상태:
   • PCB에 저장된 프로세스 상태 정보와 연계.
3. 메모리 관리 정보:
   • 페이지 테이블, 세그먼트 테이블 등 메모리 매핑 관련 정보.
4. I/O 상태 정보:
   • 열려 있는 파일, 사용 중인 I/O 장치의 상태 정보.
5. 스케줄링 정보:
   • 우선순위, CPU 사용 시간 등 스케줄링 결정에 필요한 정보.

결론.

커널 스택과 유저 스택에 대해 다시 톺아보며, 각각의 역할과 구조를 명확히 이해할 수 있었다.

공부할수록 운영체제가 얼마나 정교하게 설계되어있는지 느낄 수 있었다…

KOCW도 하나 등록했다. 너무 깊게 파는건 아니겠지

참고.

• 리눅스 커널 내부구조 - 메모리 관리

• 리눅스 커널 메모리 관리 훑어보기

• Linux Kernel Memory Addressing

운영체제는 사용자와 하드웨어 사이의 인터페이스 역할을 하는 소프트웨어의 집합이다.

여기서 인터페이스 라는 단어를 사용한 이유는 사용자가 하드웨어를 직접 조종하지 않고 운영체제를 통해 하드웨어 자원의 사용을 제어하고 조종하는 중개자 역할을 하기 때문

운영체제의 구조

운영체제는 크게 커널과 인터페이스로 이루어져 있다. 커널은 자원의 추상화와 관리가 이루어지는 공간이고 인터페이스는 각 커널과 상호작용하는 소프트웨어 계층 사이를 중개해주는 연결 장치를 말합니다.

커널

커널은 운영체제의 핵심으로 하드웨어의 자원을 자원을 추상화하여 필요한 프로세스들에게 나눠주는 운영체제의 핵심 자원 관리자이다.

여기서 추상화를 사용한다는 것은, 하나의 하드웨어 자원을 논리적인 단위로 변환하여 여러 프로세스나 태스크들이 하드웨어를 직접 제어하지 않고도 사용할 수 있도록 중재자 역할을 한다는 의미이다.

하드웨어 자원의 추상화

커널은 각 하드웨어 자원들을 특정 관리자를 통해 추상화한다.

이러한 관리자를 통해서 컴퓨터의 하드웨어에 대한 세부 사항들을 몰라도 사용자는 쉽고 일관된 방식으로 컴퓨터를 사용할 수 있게 된다.

커널의 종류

커널의 구조에 따라 하드웨어 자원을 관리하고 시스템 호출을 처리하는 방식이 달라진다.

커널의 종류는 구조에 따라 크게 모놀리식 커널, 계층형 커널, 마이크로 커널, 하이브리드 커널로 나눌 수 있다.

1. 모놀리식 커널

   

- 특징 :
    - 커널 내에 운영체제의 모든 주요 기능을 포함한다.
    - 단일 큰 블록으로 동작하고 커널 모드에서 모든 작업을 수행한다.
    - **`시스템 콜` : 시스템 콜이 호출되면 커널 내부에서 직접 처리된다.**
        - 예를 들어, `read()` 시스템 콜을 호출하면 파일 시스템 모듈이 커널 내부에서 동작하여 파일을 읽는 작업을 수행한다.
- 장점:
    - 커널 내부에서 모든 작업이 이루어지므로 모듈간 통신 비용이 적어져 오버헤드가 적다.
- 단점:
    - 하나의 오류가 커널 전체에 영향을 미칠 가능성이 높고 수정이 어려움.
- 예시 : Linux 커널 (전형적인 모놀리식 커널이다. 단, 해당 구조의 단점을 보완하기 위해 모듈화를 도입하여 모듈형 모놀리식 커널로 발전했다.), Unix 커널

2. 계층형 커널(Layered kernel)

   

- 특징:
    - 커널이 가진 모듈을 묶어 계층으로 나누고 계층간 인터페이스를 통한 통신을 통해 운영체제를 구현하는 방식이다.
    - 일반적으로 하위 계층은 하드웨어와 가깝고 상위 계층은 사용자와 가까운 추상화 수준을 가진다.
    - **`시스템 콜` : 시스템 콜이 호출되면** 해당 요청은 **계층적으로 전달되며 처리**된다.
        - 예를 들어, read() 시스템 콜은 파일 시스템 계층을 통해 디스크 I/O 계층으로 전달되어 최종적으로 하드웨어에 접근한다.
- 장점:
    - 모듈화: 각 계층별로 독립성이 보장되어 특정 계층을 수정하거나 교체해도 다른 계층에 영향을 주지 않는다.
    - 추상화: 하드웨어 세부사항을 상위 계층에서 숨길 수 있다.
- 단점:
    - 계층간 호출이 많아질수록 오버헤드가 증가하여 성능이 저하될 수 있다.
- 예시:
    - THE 운영체제: 1960년 다익스트라가 설계한 최초의 계층형 커널 운영체제
    - Windows NT(초기버전): HAL(Haredware Abstraction Layer)를 통해 하드웨어와 커널 간 계층화 구현

3. 마이크로 커널

   

- 특징 :
    - 커널은 최소한의 기능(프로세스 관리, 메모리 관리, IPC 등)만을 포함하여 kernel mode 에서 실행하고 나머지 기능(파일 시스템, 네트워크 등)은 **User mode**에서 실행한다.
    - 커널 모드와 유저 모드 사이의 통신에는 시스템콜을 사용하고 유저 모드 사이의 통신은 IPC를 사용함.
    - **`시스템 콜` :** 시스템 콜은 **커널에서 최소한의 작업**(예: IPC로 요청 전달)을 수행하고, 실제 작업은 **유저 모드 서비스에서 처리**된다.
        - 예를 들어 `read()` 시스템 콜을 호출하면 **파일 시스템 서버(유저모드)**로 요청을 전달하고 해당 서버가 작업을 처리한 후 결과를 반환한다.
- 장점:
    - 각 기능이 독립적으로 실행되어 오류가 전체에 미치는 영향이 적다.
- 단점:
    - 커널모드와 사용자 모드 간 빈번한 통신으로 성능이 떨어질 수 있다.
- 예시: Minix, QNX

4. 하이브리드 커널

   

- 특징:
    - 모놀리식 커널과 마이크로커널의 장점을 결합한 구조
    - 일부 기능은 커널 모드에서 실행되지만, 독립적인 모듈로 관리되어 유연성을 제공
    - **`시스템 콜` :** 시스템 콜은 커널 내부에서 처리되거나, 필요한 경우 일부 작업이 **사용자 모드 서비스로 전달**된다.
        - 예를 들어, read() 시스템 콜은 하드웨어와 직접 관련된 작업은 커널 내부에서 처리하고, 복잡한 파일 시스템 작업은 사용자 모드 서비스로 위임될 수 있다.
- 장점:
    - 성능과 안정성 사이의 균형 제공
- 단점:
    - 설계가 복잡하고, 모듈 간 통합 문제가 발생할 수 있음
- 예시: Windows NT, macOS

Dual Mode

운영체제는 시스템의 안전성과 보안을 위해 CPU 실행 모드를 사용자 모드(User Mode)와 커널 모드(Kernel Mode)로 구분하여 관리한다. 이를 Dual Mode라고 한다.

왜 이렇게 구분할까?

만약 이러한 듀얼 모드를 지원하지 않을 경우 (여러 응용 프로그램들이 CPU, 메모리 등의 자원에 직접적으로 접근하고 조작할 경우) 자원의 공유가 무질서하게 관리될 것이고 응용 프로그램들이 조금만 실수해도 컴퓨터 전체에 악영향을 끼칠 수 있을 것이다. 그렇기에 모드를 논리적으로 나누고 이 사이에 시스템 콜 인터페이스를 둠으로써 이를 막을 수 있다.

사용자 모드 (User Mode)

• 일반적인 응용 프로그램이 실행되는 모드
• 하드웨어 자원에 직접 접근 불가능
• 커널 영역의 코드를 실행할 수 없음

커널 모드 (Kernel Mode)

• 운영체제가 실행되는 모드
• 모든 종류의 명령어 실행 가능
• 하드웨어 자원에 직접 접근 가능

모드 전환

• 슈퍼바이저 플래그로 현재 모드 구분
  • 0: 사용자 모드
  • 1: 커널 모드
• 사용자 모드에서 실행 중인 프로그램이 시스템 자원을 필요로 할 때, 반드시 커널 모드로 전환되어야 한다.
• 이때 시스템 콜을 통해 모드의 전환이 이루어진다.

시스템 콜

시스템 콜은 커널이 사용자나 프로그램이 커널에 직접 접근하는 것을 막기위해 만들어진 인터페이스이다.

시스템 콜 인터페이스는 User Space와 Kernel Space의 경계에서 동작하며, 커널 내부의 적절한 모듈로 요청을 전달하는 역할을 한다.

앞서 User 모드 와 Kernal Space의 사이에 시스템 콜을 통해 모드의 전환이 이루어진다고 했다.

즉, User Interface의 작업들이 커널이 관리하는 자원에 접근해야 할 때, System Call Interface를 통해 Kernel Space의 자원 관리자에게 요청이 전달되어 처리되는 것이다.

시스템 콜의 처리 위치

시스템 콜은 모든 커널에서 기본적으로 커널 모드에서 실행되지만, 커널의 구조에 따라 시스템 콜의 처리 위치와 방식이 약간씩 달라진다.

• 모놀리식 커널: 시스템 콜은 커널 내부에서 직접 처리됨 (가장 빠름).
• 마이크로커널: 커널은 시스템 콜을 유저 모드 서비스로 전달함 (더 안전하지만 느림).
• 계층형 커널: 계층적으로 시스템 콜이 처리됨.
• 하이브리드 커널: 필요에 따라 커널 또는 유저 모드 서비스에서 처리됨.

우리가 사용하는 대부분의 상용 운영체제(예: Linux, Windows, macOS)는 모놀리식 커널 또는 하이브리드 커널 기반으로 시스템 콜을 처리한다.

시스템 콜의 유형

시스템 콜은 커널에서 지원하는 서비스에 따라 유형이 나뉜다. 크게 프로세스 제어, 파일 조작, 장치 관리, 정보 유지, 통신 등으로 조작할 수 있다.

서로 다른 시스템 콜의 구분.

• 시스템 콜 번호로 구분 운영체제는 각 시스템 콜에 고유한 번호를 부여한다. 시스템 콜 인터페이스는 이 번호를 통해 어떤 호출인지 식별할 수 있다. (ex. read() 는 시스템 콜 번호 3 으로 식별 가능)
• 시스템 콜 이름 으로 구분 시스템 콜 인터페이스가 호출된 함수 이름으로 해당 작업을 구분 가능하다.
• 인자(파라미터) 로 구분 전달된 인자(파일 디스크립터, 크기 등)를 통해 작업의 세부 사항을 파악한다.

Shell 은 무엇인가?

• 정의: 사용자가 운영체제와 상호작용할 수 있도록 명령 해석기(CI)를 포함한 인터페이스

  명령 해석기 ( Command Interpreter )

  사용자가 입력한 명령어를 해석하고 그에 따라 작업을 수행하는 프로그램

  역할: 명령어를 파싱(parse)하고, 해당 명령어에 맞는 작업을 시스템에 요청하거나 프로세스를 실행.

  명령 인터프리터의 구현 방식 두가지

  1. 명령 인터프리터 자체가 명령을 실행하는 방식:
     • 명령 인터프리터 자체가 각 명령어를 처리하는 로직을 가지고 있음.
     • 이 경우 명령어와 처리 로직이 인터프리터에 포함되어있어 새로운 명령어를 추가하려면 인터프리터 자체의 변경이 필요
     • 예) echo
  2. 시스템 프로그램이 명령을 실행하는 방식:
     • 명령 인터프리터가 명령을 실행할 코드 자체를 가지고 있는 대신 명령을 입력받으면 해당 명령어가 가리키는 쉘 스크립트 파일이나 바이너리 파일을 통해 실행됨.
     • 예) rm {파일이름} : /bin/rm 경로의 바이너리 파일이 {파일이름} 같은 파일을 삭제하는 수행.

• 기본적으로 커널은 쉘로 감싸져있음

• 운영체제의 필수 구성 요소 중 하나이며, 다양한 종류의 쉘이 존재.

• 또한 쉘 커맨드 라인들의 묶음인 쉘 스크립트를 통해 반복적인 작업을 자동화하고, 복잡한 시스템 작업을 간단히 수행할 수 있음.

• 종류:

  • Bash (Bourne Again Shell): 리눅스에서 기본적으로 많이 사용되며, 강력한 스크립트 기능과 명령어 자동 완성을 제공한다.
  • Zsh (Z Shell): 사용자 맞춤형 설정과 강력한 자동 완성 기능을 제공하며, 플러그인 시스템으로 확장 가능하다.

결론.

CS 스터디를 하면서 조사했던 운영체제 부분을 정리해보았다. 아티클과 책들을 읽으며 정리하는 과정에서, 각 저자마다 커널과 시스템 콜의 역할을 다르게 설명하는 부분이 많아 교차검증에 시간이 많이 소요되었다. 알고 보니 실제로 커널마다 시스템 콜의 동작 방식과 구조가 달랐기 때문이었다.

이를 통해 개념적인 이해와 실제 구현의 차이를 이해하는 것이 얼마나 중요한지 다시 한번 깨달았다.

참고

https://www.quora.com/What-is-the-difference-between-an-interpreter-and-a-shell https://imbf.github.io/computer-science(cs)/2020/09/03/Operating-System-Structures.html https://wikidocs.net/230921 https://hongong.hanbit.co.kr/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EB%9E%80-%EC%BB%A4%EB%84%90%EC%9D%98-%EA%B0%9C%EB%85%90-%EC%9D%91%EC%9A%A9-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8-%EC%8B%A4%ED%96%89%EC%9D%84-%EC%9C%84%ED%95%9C/

1. POJO 기반의 구성
2. 의존성 주입을 통한 객체간의 관계 구성
3. AOP 지원
4. 편리한 MVC 구조
5. WAS 에 종속적이지 않은 개발 환경

POJO 기반의 구성

스프링은 객체간의 관계를 구성할 때에 별도의 API를 사용하지 않고 POJO의 구성만으로 가능하다.

즉. 일반적인 JAVA코드를 사용하여 객체간의 관계를 구성하기에 JAVA를 배울 때에 썼던 가장 일반적인 형태의 코드를 그대로 실행할 수 있다는 것이 장점이다.

POJO 객체를 사용하면 좋은점.

특정한 라이브러리나 컨테이너의 기술에 종속적이지 않기에 가장 일반적인 JAVA코드로 실행할 수 있어 생산성과 테스트코드 작업에 유리하다.

의존성 주입(DI)

한 객체가 다른 객체를 필요로 할 때에 해당 객체를 직접 생성하는 것이 아닌, 외부로부터 주입을 받을 수 있다.

이 경우 각 객체는 자신의 역할에 집중할 수 있다. 어떤 객체에 의존하든 자신의 역할은 변경되지 않는다는 것이다.

스프링에서는 Application Context 가 필요한 객체들을 생성하고 필요한 객체들을 주입하는 역할을 한다.

Application Context 가 객체들을 관리하고 해당 객체와 객체사이의 의존관계를 설정할 수 있다. (이 객체를 Bean이라고 부른다.)

해당 Bean을 등록하는 방식으로

1. XML 설정
2. 어노테이션 설정
3. JAVA 설정

방식이 있다. 각 객체들은 기본적으로 싱글톤 객체로 생성이 되며 객체들의 의존성을 Application Context 가 관리하게 된다.

스프링 Bean의 종류

AOP 지원

기본적으로, 프레임워크는 개발자가 비즈니스 로직에만 집중할 수 있게 발전해왔다.

이를 실현하기 가장 좋은 방법이 반복적인 코드의 제거 이다.

스프링에서는 대부분의 시스템이 공통으로 가지고 있는 보안, 로그, 트랜잭션과 같은 비즈니스 로직이 아니지만 반드시 처리가 필요한 부분들을 가지고 있고 이를 횡단 관심사 라고 부른다.

이러한 횡단 관심사를 모듈로 분리해서 제작하는 것이 AOP(관점 지향 프로그래밍) 이다.

스프링에서는 AspectJ의 문법을 통해서 AOP 를 작성할 수 있다.

장점

• 핵심 비즈니스 로직에만 개발자가 집중할 수 있음
• 각 프로젝트마다 다른 관심사를 적용할 때 코드의 수정을 최소화 시킬 수 있음
• 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있음

1. AspectJ:

• 모든 Join Point(메서드 실행, 필드 접근, 객체 생성 등)를 지원한다.
• 컴파일 시 위빙이 가능해 실행 성능이 우수하다.
• 객체지향 프로그래밍의 모든 부분에 AOP를 적용할 수 있다.

1. Spring AOP:

• 메서드 실행 Join Point만 지원하며, 필드 접근이나 객체 생성에는 적용할 수 없다.
• 프록시 기반 런타임 위빙만 지원해 실행 성능이 AspectJ보다 다소 낮다.
• Spring의 DI 컨테이너와 통합되어 AOP 사용이 간편하다.

AspectJ 의 작동 방식

1. 포인트컷(Pointcut) 정의: 어떤 메서드에 관심사를 적용할지 지정

   • 횡단 관심사가 실행되는 실행 시점을 선택한다.

       // com.example.service 패키지의 모든 메서드 실행 시점을 포인트컷으로 정의하는 예시
       @Pointcut("execution(* com.example.service.*.*(..))")
       public void serviceLayerMethods() {}

   • 주요 포인트컷 유형

     • execution() : 메서드 실행 시점 지정
     • within() : 특정 클래스나 패키지 내부의 모든 메서드 지정
     • this/target : this는 프록시 객체 기준, target은 실제 대상 객체 기준으로 포인트컷을 적용
     • args() : 특정 파라미터 타입에 대해 적용

2. 어드바이스(Advice) 정의: 적용할 공통 기능(관심사)을 정의

   • 즉 포인트컷부터 선택된 지점에 실행할 횡단 관심사의 기능을 정의하는 부분이다.
   • AspectJ는 어드바이스의 실행 시점을 기준으로 5가지 유형으로 분류한다.
     • @Before(): 메서드 실행 전에 어드바이스를 실행
     • @After(): 메서드 실행 후에 어드바이스를 실행 (예외 발생 여부와 관계없이)
     • @AfterReturning(): 메서드가 정상적으로 실행된 후에 어드바이스를 실행
     • @AfterThrowing(): 메서드 실행 중 예외가 발생했을 때 어드바이스를 실행
     • @Around(): 메서드 실행 전후에 어드바이스를 실행, 가장 강력한 어드바이스 유형

3. 위빙(Weaving): 포인트컷에 지정된 지점에 어드바이스를 삽입하는 과정

   • AspectJ는 컴파일 시점, 클래스 로드 시점, 런타임 시점으로 위빙을 수행한다.

   • 컴파일 시 위빙(Compile-time Weaving):

     • AspectJ 컴파일러(ajc)를 사용하여 소스 코드 컴파일 시 어드바이스를 삽입한다.
     • 결과적으로 바이트코드에 AOP 로직이 포함된다.

   • 로드 시 위빙(Load-time Weaving):

     • 클래스 로더가 클래스 바이트코드를 JVM에 로드하는 시점에 어드바이스를 삽입.

     • Spring AOP는 기본적으로 로드 시 위빙을 지원하지 않으며, AspectJ를 통합해야 사용 가능합니다.

     • javaagent 옵션을 사용해 위빙을 수행.

       javaagent 옵션이 뭐지? (gpt)

       javaagent는 Java 애플리케이션의 실행 시 JVM에 전달되는 옵션으로, 클래스 로딩 시점에 바이트코드를 조작할 수 있게 해주는 기능입니다. 주요 특징은 다음과 같습니다:

       • 클래스 로딩 시 바이트코드 변경: 클래스가 JVM에 로드될 때 해당 클래스의 바이트코드를 동적으로 수정할 수 있습니다.
       • 비침투적인 코드 변경: 원본 소스 코드를 수정하지 않고도 애플리케이션의 동작을 변경할 수 있습니다.
       • AOP 구현에 활용: 로드 시 위빙을 구현하는 데 사용되어, 횡단 관심사를 효과적으로 분리할 수 있습니다.

   • 런타임 위빙(Runtime Weaving):

     • 런타임 시 프록시 패턴을 사용해 동적으로 어드바이스를 삽입.
     • Spring AOP는 AspectJ의 런타임 위빙 방식을 사용하며, 실제로는 프록시 객체를 생성해 어드바이스를 적용.

트랜잭션 지원

DB를 사용할때 가장 신경써야할 경우는 트랜잭션 처리이다. 스프링에서는 이런 트랜잭션의 관리를 어노테이션이나 XML로 설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없도록 설정되어있다.

스프링의 Bean 생명주기

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(); 
    ac.register();//빈 추가로 등록
    ac.referesh();//등록하기 위한 갱신
    ac.close();//소멸 메서드, 이때 빈도 같이 소멸

스프링의 Bean 생명주기는 크게 4단계로 나눌 수 있다: 빈 생성, 의존관계 주입, 초기화, 소멸. 각 단계에서 일어나는 일을 살펴보겠다.

1. 빈 생성

1. 스프링 컨테이너가 시작되면 먼저 컨텍스트라는 메모리 영역을 만든다. 이것이 Application Context이다.

2. 스프링은 설정 파일(XML, Java Config, 어노테이션)에서 정의된 Bean들의 정보를 읽어 스프링 컨테이너에 등록한다.

3. Bean 정의에 따라 객체를 생성한다. 이 때 기본적으로 싱글톤 스코프가 적용되며, 필요에 따라 프로토타입, 요청(Request), 세션(Session) 등의 다른 스코프도 적용될 수 있다.

2. 의존관계 주입 (DI)

1. 스프링은 설정 정보를 기반으로 객체(Bean) 간의 의존관계를 주입한다.
2. 생성자 주입, 세터 주입, 필드 주입 등의 방식으로 의존성이 주입된다.

3. 초기화

1. 의존관계 주입이 완료된 후, Bean 초기화 작업을 수행한다.
2. @PostConstruct 어노테이션이 붙은 메서드가 호출된다.
3. InitializingBean 인터페이스의 afterPropertiesSet() 메서드가 호출된다.
4. Bean 설정에서 지정한 사용자 정의 초기화 메서드가 호출된다.
5. AOP가 적용되는 경우, 이 시점에서 프록시 객체가 생성된다.

4. 사용

1. 초기화가 완료된 Bean은 애플리케이션에서 사용 가능한 상태가 된다.
2. 필요에 따라 getBean() 메서드로 Bean을 요청하거나, 의존성 주입을 통해 다른 Bean에서 사용한다.
3. 싱글톤 Bean의 경우 애플리케이션 종료 시까지 계속 사용된다.

5. 소멸

1. 애플리케이션 종료 시, 컨테이너는 Bean의 소멸 과정을 시작한다.
2. @PreDestroy 어노테이션이 붙은 메서드가 호출된다.
3. DisposableBean 인터페이스의 destroy() 메서드가 호출된다.
4. Bean 설정에서 지정한 사용자 정의 소멸 메서드가 호출된다.
5. 이 과정에서 리소스 해제, 연결 종료 등의 정리 작업이 수행된다.

이러한 생명주기 관리를 통해 스프링은 Bean의 안전한 생성, 초기화, 사용, 그리고 소멸을 보장하며, 개발자는 비즈니스 로직에 집중할 수 있게 된다.

1. 싱글톤 스코프 (Singleton)

• 기본값(Default Scope): 별도로 설정하지 않으면 Singleton 스코프가 적용된다.
• 특징:
  • 스프링 컨테이너 내에서 단 하나의 인스턴스만 생성된다.
  • 컨테이너가 초기화될 때 빈이 생성되고, 애플리케이션 종료 시까지 유지된다.
  • 애플리케이션 전체에서 공유되므로 상태를 가지는 필드는 사용에 주의해야 한다.
• 사용 예:
  • 주로 무상태(Stateless) Bean으로 사용한다.
  • Service, Repository 등 공유 가능한 객체에 적합하다.
• 설정 방법:
  • XML:
  • 어노테이션: 기본값으로 적용됨 (명시 필요 없음).

2. 프로토타입 스코프 (Prototype)

• 특징:
  • 요청마다 새로운 객체를 생성한다.
  • 컨테이너가 빈을 생성만 하고 이후의 생명주기는 컨테이너가 관리하지 않는다.
  • 의존성 주입으로 사용된 경우: 주입된 시점에 새로운 인스턴스가 생성된다.
• 사용 예:
  • 상태를 가지는 객체(예: 사용자별 데이터, 단기 객체) 생성에 적합하다.
  • 동일한 클래스를 필요에 따라 여러 번 생성해야 할 때 사용한다.
• 설정 방법:
  • XML:
  • 어노테이션: @Scope("prototype")

3. 요청(Request) 스코프

• 특징:
  • HTTP 요청이 들어올 때마다 새로운 인스턴스를 생성하고, 요청이 종료되면 소멸한다.
  • 웹 애플리케이션에서만 사용 가능하며, Spring MVC 컨텍스트에서 동작한다.
  • 각 요청마다 별도의 빈 인스턴스를 제공한다.
• 사용 예:
  • 요청마다 다른 데이터를 저장하거나 처리해야 하는 경우.
  • 예: HTTP 세션과 별개로 요청별 사용자 데이터를 저장.
• 설정 방법:
  • XML:
  • 어노테이션: @Scope("request")

4. 세션(Session) 스코프

• 특징:
  • HTTP 세션과 생명주기가 동일하다.
  • 세션이 유지되는 동안 같은 빈 인스턴스를 제공한다.
  • 웹 애플리케이션에서만 사용 가능하며, 주로 사용자별 데이터 저장에 활용한다.
• 사용 예:
  • 로그인한 사용자별 데이터를 유지해야 하는 경우.
  • 예: 인증 정보, 사용자 설정 등.
• 설정 방법:
  • XML:
  • 어노테이션: @Scope("session")

5. 애플리케이션(Application) 스코프

• 특징:
  • 서블릿 컨텍스트(ServletContext)와 생명주기가 동일하다.
  • 웹 애플리케이션 전체에서 공유되는 빈 인스턴스를 제공한다.
• 사용 예:
  • 전역적으로 사용할 데이터를 저장하거나 관리해야 할 때.
  • 예: 애플리케이션 설정 값, 공통 리소스.
• 설정 방법:
  • XML:
  • 어노테이션: @Scope("application")

6. 웹소켓(WebSocket) 스코프

• 특징:
  • 웹소켓 세션과 생명주기가 동일하다.
  • 각 웹소켓 연결별로 별도의 빈 인스턴스를 생성한다.
• 사용 예:
  • 웹소켓 통신에서 사용자별 데이터를 저장하고 관리할 때.
• 설정 방법:
  • 어노테이션: @Scope("websocket")

정리

스코프 생명주기 사용 예

Singleton 컨테이너 시작부터 종료까지 공통 서비스, Repository 등

Prototype 빈 요청 시마다 새로 생성 상태를 가지는 객체, 비공유 객체

Request HTTP 요청 시작부터 종료까지 요청별 데이터

Session HTTP 세션 시작부터 종료까지 사용자별 데이터

Application 애플리케이션(ServletContext) 시작부터 종료까지 전역 설정, 공통 리소스 관리

WebSocket 웹소켓 세션 시작부터 종료까지 웹소켓 연결별 사용자 데이터

Java 8에서는 대량의 데이터를 효율적으로 처리하기 위해 Stream API가 도입되었다. 이는 데이터를 선언형 프로그래밍 방식으로 처리할 수 있게 하며, 다양한 데이터 연산을 간결하고 효율적으로 수행할 수 있는 기능을 제공한다.

Stream과 for 루프의 성능 비교

1. Stream의 성능

Stream은 대용량 데이터를 처리할 때 더 효율적이다. 특히 병렬 처리가 가능하기 때문에 성능상의 이점을 제공한다. 또한 종단 연산이 호출될때에 실행하고 (지연 연산) 중간 연산 과정에서 조건에 맞지 않는 데이터들이 추려지기 때문에 조건에 맞지 않는 데이터들은 이후 계산에 쓰이지 않으므로 대규모 데이터셋에 효율적일 수 있따.

2. for 루프와의 비교

그에 비해 for 루프는 작은 데이터셋이나 단순 연산을 수행할 때 빠르다. 이유는 오버헤드가 적기 때문이다.
for 루프는 별도의 객체 생성이나 함수 호출이 없어 실행 비용이 Stream보다 낮다.

오버헤드가 적다? 왜?

for 루프는 별도의 추가 객체 생성이나 함수의 호출 없이 작동하기 때문에 실행시의 부가적인 비용이 stream에 비해 덜든다. ← 컴파일 시점에서 적용

Stream은 스트림객체를 생성하고 연산 체인을 설정하여 내부적으로 람다나 함수형 인터페이스를 사용하므로 초기세팅 비용에서 오버헤드가 발생할 수 있다는 뜻이다.

Stream의 병렬 처리

Stream은 parallel() 메서드를 통해 병렬 처리가 가능하다. 그러나 병렬 처리를 사용할 때는 몇 가지 주의사항이 있다.

1. 스레드풀 공유 문제

parallel() 메서드는 별도의 스레드풀을 생성하지 않고, 공유 스레드풀(ForkJoinPool.commonPool)을 사용한다.
여러 병렬 스트림이 하나의 스레드풀을 공유하면 병목 현상이 발생할 수 있다.

2. 최적의 데이터 구조

병렬 처리 성능을 극대화하려면 다음과 같은 참조 지역성이 높은 자료구조를 사용하는 것이 좋다:

• ArrayList, HashMap, HashSet, ConcurrentHashMap
• 원시 타입 배열(int[], long[] 등)

이들은 메모리에서 연속적으로 저장되므로, 캐싱 효율이 향상되어 처리 속도가 빨라진다.

캐싱 효율 향상된다? 메모리에서 연속적임으로 Cache HitRate 가 높다는 뜻이다. CPU 캐시 메모리는 인접한 메모리 공간을 함께 불러오기 때문에 배열 요소에 순차적으로 접근할 때에 메모리 접근 속도가 더 빠르다는 뜻이다.

3. 잘못된 병렬 처리

parallel 사용 시 잘못된 병렬 처리를 할 경우 성능 향상은 커녕 성능이 내려갈 수 도 있다. 특히 limit() 메서드를 함께 사용하는 경우 병렬 처리 성능이 저하될 수 있다. 그 이유는 parallel로 병렬 작업 수행 시 limit(n)이 n개의 결과만 가져오지 않기 때문이다.

예를 들어 메르센 소수 문제 를 둘 수 있다. 메르센 소수가 무엇인지는 궁금한 사람이 찾아보시라. 우리는 n번째 메르센 소수를 찾는 일이 1부터 n-1까지 메르센 소수를 찾는 일보다 훨씬 많은 비용이 드는 연산임을 알고만 있으면 된다.

아래는 20개의 메르센 소수를 구하는 JAVA코드이다.

public static void main(String[] args) {
    primes()
        .map(p -> TWO.pow(p.intValueExact()).subtract(ONE)) // 메르센 수 생성: 2^p - 1
        .filter(mersenne -> mersenne.isProbablePrime(50)) // 메르센 수가 소수인지 확인
        .limit(20) // 상위 20개의 메르센 소수만 선택
        .forEach(System.out::println); // 결과 출력
}

해당 코드에서 성능을 높이기 위해서 스트림 파이프 라인의 parallel() 을 호출하면 병렬로 코드를 진행하여 성능이 좋아질까?

public static void main(String[] args) {
    primes()
        .parallel() // 병렬 스트림으로 변환
        .map(p -> TWO.pow(p.intValueExact()).subtract(ONE)) // 메르센 수 생성: 2^p - 1
        .filter(mersenne -> mersenne.isProbablePrime(50)) // 메르센 수가 소수인지 확인
        .limit(20) // 상위 20개의 메르센 소수만 선택
        .forEach(System.out::println); // 결과 출력
}

아쉽게도 성능은 좋아지지 않는다. 오히려 CPU자원을 더 많이 잡아먹으면서 결과물은 나오지 않는다. 이유는 스트림 파이프 라인을 병렬화할때에 CPU코어가 남는다면 원소를 몇 개 더 처리한 후에 제한된 개수 이후의 결과를 버리는 알고리즘으로 돌아가기 때문이다.

해당 문제를 해결하려면 스레드에 분배하기 좋은 앞서 말했던 참조지역성이 좋은 자료구조를 채택하면 좋다. 또한 Spliterator 를 사용하면 작업할 스레드를 병렬적으로 나눌 수 있다.

import java.util.Spliterator;
import java.util.stream.IntStream;
import java.util.stream.Stream;
import java.util.stream.StreamSupport;

public class ParallelSpliteratorExample {
    public static void main(String[] args) {
        // 1부터 100까지의 숫자를 포함하는 스트림 생성
        Stream<Integer> stream = IntStream.range(1, 101).boxed();

        // 스트림에서 Spliterator 객체를 가져옴
        Spliterator<Integer> spliterator = stream.spliterator();

        // Spliterator를 사용하여 데이터를 병렬로 나누기
        Spliterator<Integer> split1 = spliterator.trySplit(); // 첫 번째 분할
        Spliterator<Integer> split2 = spliterator.trySplit(); // 두 번째 분할

        // 각 분할된 Spliterator로 병렬 스트림 생성
        Stream<Integer> parallelStream1 = StreamSupport.stream(spliterator, true);
        Stream<Integer> parallelStream2 = StreamSupport.stream(split1, true);
        Stream<Integer> parallelStream3 = StreamSupport.stream(split2, true);

        // 병렬 스트림의 각 요소를 처리하며 스레드 이름 출력
        System.out.println("Processing with spliterator 1:");
        parallelStream1.forEach(i -> System.out.println("Thread " + Thread.currentThread().getName() + " is processing number: " + i));

        System.out.println("\nProcessing with spliterator 2:");
        parallelStream2.forEach(i -> System.out.println("Thread " + Thread.currentThread().getName() + " is processing number: " + i));

        System.out.println("\nProcessing with spliterator 3:");
        parallelStream3.forEach(i -> System.out.println("Thread " + Thread.currentThread().getName() + " is processing number: " + i));
    }
}

Stream에서 사용 가능한 함수형 인터페이스

Stream API는 함수형 인터페이스를 통해 다양한 연산을 지원한다. 주요 인터페이스는 다음과 같다:

1. Predicate

   • 입력값을 테스트하여 boolean 결과를 반환한다.
   • filter() 메서드에서 사용된다.

2. Function<T, R>

   • 입력값을 다른 타입으로 변환한다.
   • map() 메서드에서 사용된다.

3. Consumer

   • 입력값을 소비하고 반환값이 없다.
   • forEach() 메서드에서 사용된다.

4. Supplier

   • 입력 없이 값을 생성한다.
   • Stream 초기화 시 사용된다.

5. BiFunction<T, U, R>

   • 두 개의 입력값을 받아 결과를 반환한다.

6. UnaryOperator

   • 같은 타입의 입력값을 변환한다.

7. BinaryOperator

   • 같은 타입의 두 입력값을 연산한다.
   • reduce() 메서드에서 사용된다.

Stream에서 외부 변수 사용: final 키워드

Stream이나 람다식에서 외부 변수를 사용할 때는 반드시 해당 변수가 final 또는 사실상 final(effectively final)이어야 한다.
이는 스레드 안전성과 클로저(Closure) 개념 때문이다.

이유:

람다 표현식이 외부 변수를 사용할 경우, 해당 변수는 변경되지 않아야 한다. 변경될 가능성이 있다면 스레드 간 데이터 경합이 발생할 수 있다.

꼭 final을 붙여야 할까?

• 명시적으로 final을 붙이지 않아도, 변수가 변경되지 않으면 사실상 final로 간주되어 사용 가능하다.

예시 코드:

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");

// 사실상 final인 변수
String prefix = "Hello, ";

names.stream()
    .map(name -> prefix + name) // prefix 사용
    .forEach(System.out::println);

위 예시에서 prefix는 변경되지 않으므로 람다식에서 안전하게 사용할 수 있다.

결론

Java Stream은 대량 데이터를 효율적으로 처리할 수 있는 강력한 도구이다. 성능을 극대화하려면 데이터 구조, 스레드에 대한 이해, 함수형 인터페이스를 잘 활용해야 한다. 또한 외부 변수를 사용할 때는 final 키워드와 스레드 안전성을 고려하는 것이 중요하다.

Stream API를 적절히 활용하면 간결하면서도 성능이 뛰어난 코드를 작성할 수 있을 것이다.

참고

1. Java 스트림과 병렬 스트림
2. 스레드의 구조와 병렬 처리
3. 프로세스와 스레드 차이
4. ArrayList vs Vector 동기화 차이
5. Effective JAVA - 람다와 스트림

이때 Synchronized는 공유자원을 생성하여 해당 자원에 대한 동기화 영역을 생성하는데 도움을 준다.

1. Synchronized 키워드란?

Synchronized : 자바에서 동기화 영역을 생성하는 키워드이다.

Synchrosized 처리된 객체나 메서드는 두 개 이상의 쓰레드가 동시 접근하는 것을 막는다.

즉 하나의 스레드가 해당 객체나 메서드를 사용하는 동안 다른 스레드가 접근하지 못하도록 Lock을 거는 것.

그런데 두 개 이상의 스레드가 synchronized 처리된 객체나 메서드에 동시에 접근을 시도할때 어떤 스레드가 우선순위를 가지게 될까?

Java 스레드 스케줄러가 다음과 같은 원칙에 따라 어떤 스레드가 먼저 실행할지를 결정한다.

1. 스레드 우선순위

   • 자바 스레드는 우선순위를 가질 수 있음.
   • 우선순위가 높은 스레드가 낮은 스레드보다 실행될 가능성이 큼.

2. JVM 스케줄링 정책

   • JVM 스레드 스케줄러가 운영체제의 스케줄러와 협력하여 실행 순서를 결정함.
   • 타임 슬라이싱(Time Slicing)과 우선순위 기반 스케줄링 방식이 일반적.

3. Fairness 옵션

   • ReentrantLock 클래스의 공정성 설정을 통해 대기 순서대로 접근 제어 가능.

       ReentrantLock lock = new ReentrantLock(true); // 공정성 설정

2. Synchronized 키워드 사용 위치별 동기화 방식 비교

1. 인스턴스 메소드 동기화

• 설명: synchronized 키워드를 메소드 선언에 붙이면, 해당 메소드를 호출한 인스턴스(객체)를 기준으로 동기화가 이루어진다.

• 특징:

  • 한 인스턴스에서 한 번에 한 스레드만 메소드를 실행할 수 있다.
  • 다른 non-synchronized 메소드는 동시에 실행될 수 있다.

• 예제:

    public synchronized void add(int value) {
        this.count += value;
    }
  

• 사용 시 주의점:

  • 객체당 한 스레드만 메소드를 실행하도록 보장한다.
  • 클래스의 여러 인스턴스는 서로 독립적으로 동작한다.

2. 스태틱 메소드 동기화

• 설명: static synchronized 메소드는 해당 클래스 자체를 기준으로 동기화가 이루어진다.

• 특징:

  • 클래스 레벨에서 동기화가 이루어진다.
  • 해당 클래스의 모든 인스턴스가 공유하는 리소스에 대한 동기화가 필요할 때 사용한다.
  • 한 번에 한 스레드만 static synchronized 메소드를 실행할 수 있다.

• 예제:

    public static synchronized void add(int value) {
        count += value;
    }
  

• 사용 시 주의점:

  • 클래스 객체는 JVM 내에서 하나만 존재하므로, 클래스 간 자원을 보호해야 할 때 적합하다.

3. 인스턴스 메소드 내부 블록 동기화

• 설명: 메소드 내부의 특정 코드 블록을 synchronized 키워드로 동기화할 수 있다.

• 특징:

  • 동기화가 필요한 코드만 블록으로 지정할 수 있다.
  • 동기화 기준은 this 객체(메소드를 호출한 객체) 또는 다른 객체로 설정할 수 있다.

• 예제:

    public void add(int value) {
        // 동기화되지 않은 코드
        synchronized(this) {
            this.count += value; // 이 부분만 동기화
        }
        // 동기화되지 않은 코드
    }
  

• 사용 시 주의점:

  • 메소드 전체 동기화보다 더 세밀한 동기화가 가능하다.
  • 다른 객체를 기준으로 동기화하면, 여러 스레드 간 독립적인 동작이 가능하다.

4. 스태틱 메소드 내부 블록 동기화

• 설명: 스태틱 메소드 내부의 특정 코드 블록을 동기화하며, 클래스 객체를 기준으로 동기화가 이루어진다.

• 특징:

  • 동기화 기준은 클래스 객체 (ClassName.class)이다.
  • 클래스의 모든 스레드에 대해 동기화를 보장한다.

• 예제:

    public static void add(int value) {
        synchronized (MyClass.class) {
            count += value; // 이 부분만 동기화
        }
    }
  

• 사용 시 주의점:

  • 클래스의 다른 스태틱 메소드와 동시 실행을 방지할 수 있다.

종합 비교

3. Synchronized의 효율성

Synchronized는 데이터의 일관성을 보장해 주지만, 코드의 실행 시간이 길어질수록 다른 스레드의 대기 시간이 늘어나면서 시스템의 효율성이 떨어질 수 있다.

따라서 공유 객체를 사용하는 임계 영역(critical section)은 꼭 필요한 부분에만 최대한 작게 유지하는 것이 중요하다.

CleanCode 13.동시성

p236, 동기화하는 부분을 최대한 작게 만들어라.임계 영역을 줄인다고 임계 영역의 크기를 키우지는 마라. 그러면 스레드간의 경쟁도 늘고 성능도 떨어진다.

4. Synchronized 의 대체 기법.

Java 5부터는 스레드 안전한 java.util.concurrent 패키지가 제공되면서 보다 정교한 동기화 제어가 가능해졌다.

ReentrantLock, ReadWriteLock, Semaphore, Atomic 클래스들이 대표적이다.

• ReentrantLock
  • synchronized보다 더 세밀한 제어 가능
  • 락의 획득과 해제를 명시적으로 관리
  • 공정성 설정 가능
• ReadWriteLock
  • 읽기와 쓰기를 구분하여 동기화 적용
  • 다수의 스레드가 동시에 읽기 가능
  • 쓰기 작업 시에만 쓰기 락 적용
• Semaphore
  • 스레드 수를 제어
  • 특정 리소스에 접근 가능한 최대 스레드 수 제한
• Atomic 클래스들 (AtomicInteger, AtomicLong 등)
  • 원자적인 연산 제공
  • 동기화 없이 안전한 연산 수행 가능

CleanCode 13.동시성

p233, 언어가 제공하는 스레드 안전한 클래스를 검토하고 자바에서는 해당 클래스들을 익혀라.

5. Thread Local?

Synchronize 가 스레드의 공유자원을 설정하는 키워드라면 ThreadLocal은 Java에서 각 스레드가 독립적으로 자원을 보유할 수 있도록 도와주는 클래스이다.

ThreadLocal 사용법

1. ThreadLocal 객체 생성

    private ThreadLocal<String> myThreadLocal = new ThreadLocal<>();
   

   각 스레드는 이 객체를 통해 독립된 값을 설정하고 가져올 수 있다.

2. 값 설정

    myThreadLocal.set("Thread-specific value");
   

   현재 스레드에 특정 값을 저장한다.

3. 값 가져오기

    String value = myThreadLocal.get();
   

   현재 스레드에 설정된 값을 반환한다.

4. 값 제거

    myThreadLocal.remove();
   

   현재 스레드의 값을 초기화한다.

특징

• 독립적인 변수 관리: 각 스레드가 독립적으로 값을 보유하므로 변수 간섭이 없다.

• 초기값 설정 가능: ThreadLocal의 initialValue() 메소드를 오버라이드하여 기본값을 제공할 수 있다.

    private ThreadLocal<Integer> threadLocal = new ThreadLocal<>() {
        @Override
        protected Integer initialValue() {
            return 0;
        }
    };
  

InheritableThreadLocal

• 기본적으로 ThreadLocal은 부모 스레드의 값을 자식 스레드가 참조하지 못한다.

• InheritableThreadLocal을 사용하면 부모 스레드의 값을 자식 스레드에 전달할 수 있다.

    private InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
  

• 부모 스레드의 초기값을 자식 스레드가 물려받지만, 자식 스레드가 값을 변경해도 부모 스레드에는 영향을 미치지 않는다.

장점

1. 스레드 안전성: 각 스레드가 고유한 값을 보유한다.
2. 사용 편의성: 스레드별로 데이터를 저장하고 관리하는 코드를 간결하게 작성할 수 있다.
3. 유연성: initialValue()와 InheritableThreadLocal을 활용해 초기값과 상속 관계도 커스텀하여 설정 가능하다.

사용 예시

1. 각 스레드에 고유 값 부여

    private ThreadLocal<Integer> threadLocal = new ThreadLocal<>() {
        @Override
        protected Integer initialValue() {
            return 0;
        }
    };
   
    public void increment() {
        threadLocal.set(threadLocal.get() + 1);
    }
   
    public Integer getValue() {
        return threadLocal.get();
    }
   

2. InheritableThreadLocal 사용

    private InheritableThreadLocal<String> threadLocal = new InheritableThreadLocal<>();
   
    public void setParentValue(String value) {
        threadLocal.set(value);
    }
   
    public String getValue() {
        return threadLocal.get();
    }
   

주의점

1. 메모리 누수: 스레드가 종료되면 ThreadLocal에 저장된 값을 반드시 remove()로 제거해야 한다.
2. ThreadLocal 변수 관리: 관리되지 않는 ThreadLocal 객체는 값이 참조되지 않더라도 GC에 의해 수거되지 않을 수 있다.

참고

• 자바 스레드 로컬 - ParkCheolu
• Clean Code. 13 동시성

사이드 프로젝트 중에 IAM 을 통해 협업해야할 일이 생겼다.

AWS Identity and Access Management(IAM) 이란?

AWS 에서 사용자의 접근권한을 관리하는 서비스

IAM을 통해서 사용자는 root 계정의 암호나 액세스 키를 공유하지 않고도 AWS root 계정 내 자원을 사용하는 모든 공유 사용자들에게 세분화된 권한을 부여할 수 있다.

어떤 것을 할 수 있나?

• AWS 계정 관리 및 리소스, 사용자, 서비스의 권한 제어

• root 계정을 공유하려는 IAM 사용자 생성 및 관리 & 해당 계정의 보안-

  → 심지어 해당 IAM 사용자의 비밀번호 정책까지 수정 가능하다.

• 다른 계정과 리소스 공유

  • Identity Federation (외부 인증 시스템과 연동하여 AWS 리소스에 접근할 수 있게 연동 가능)

• 계정에 별명 부여 가능, 로그인 주소 생성 가능

  → 계정에 쉽게 기억할 수 있는 별명을 지정하고, 사용자 정의 로그인 URL을 만들 수 있다.

• IAM은 글로벌 서비스

  • 모든 IAM 계정은 전체 리전에서 유일하다.

IAM 구성

사용자 (User)

• 실제 AWS 를 사용하는 사람과 서비스 (EC2 그 자체도 사용자가 될 수 있다.)

그룹 (Group)

• 사용자의 집합
  • 그룹에 속한 사용자는 그룹에 부여된 권한 행사 가능
  • 하나의 사용자는 최대 10개의 그룹에 속할 수 있다!

역할 (Role)

기존 그룹이 너무 많아져 임시적인 해당 권한을 행사하는 역할이라는 새로운

• AWS 리소스에 부여하여 AWS 리소스가 무엇을 할 수 있는가를 정의
• 혹은 다른 사용자의 역할을 부여받아 사용가능
• 다른 자격에 대해 신뢰관계 구축 가능
• 역할을 바꾸어 가며 서비스를 사용 가능

정책 (Policy)

• 사용자와 그룹, 역할이 무엇을 할 수있는지에 관한 문서

  • JSON 형식으로 정의

  • 어떤 주제로 권한을 줄지에 따라 여러가지 정책 유형이 있을 수 있음.

    AWS IAM 정책 유형

    • 자격 증명 기반 정책: IAM 사용자, 그룹 또는 역할에 직접 연결되는 정책이다.
      • 관리형 정책: AWS에서 사전 정의한 정책이나 사용자가 생성한 재사용 가능한 정책이다.
      • 인라인 정책: 특정 사용자, 그룹, 역할에 직접 포함된 정책이다.
    • 리소스 기반 정책: AWS 리소스(예: S3 버킷, IAM 역할 신뢰 정책)에 직접 연결되는 정책이다.
    • 권한 경계: IAM 엔터티(사용자 또는 역할)에 대해 최대 권한을 설정하는 고급 기능이다.
    • 조직 SCP (서비스 제어 정책): AWS Organizations에서 조직 또는 조직 단위(OU)의 권한을 관리하는 정책이다.
    • 액세스 제어 목록 (ACL): 주로 S3 버킷에서 사용되며, 리소스에 접근할 수 있는 주체와 작업을 정의한다.
    • 세션 정책: 역할을 수임하거나 사용자를 위해 임시 세션을 생성할 때 권한을 추가로 제한하는 정책이다.

IAM 리소스

IAM 을 구성하는 리소스는 다음과 같다. 해당 리소스들은 IAM 콘솔에서 추가, 편집, 제거할 수있다.

1. Principal (주체)

   AWS 리소스를 요청할 수 있는 주체이다.

   • Root user: AWS 계정 소유자의 계정으로 모든 권한을 가진다.
     • 관리 목적 이외에 다른 용도로 사용하면 안된다!
       • 탈취되었을 때 복구가 매우매우매우매우 어렵기 때문에 MFA(일회용 패스워드) 사용하여 로그인하는 것을 권장
   • IAM user : 리소스에 접근할 수 있는 사용자. 어플리케이션도 포함된다.
     • 설정 시 콘솔 로그인 권한 부여 가능
       • 어플리케이션 같은 경우에 콘솔 로그인은 필요 없다.
     • 설정 시 Root 계정의 AWS 서비스 이용 가능
       • Access Key
       • Secret Access Key
     • Admin Access 권한을 설정하더라도 별도의 설정을 하지 않으면 Billing 기능을 사용할 수 없
   • IAM role: 리소스에 접근할 수 있는 역할

2. Entity (엔티티)

   주체 중에서 실제 AWS에서 리소스에 액세스하는 역할을 하는 요소들이다.

   • IAM user: AWS 계정 내에서 생성된 사용자로, 인증 후 리소스에 접근할 수 있다.
   • IAM role: 특정 역할을 수행하도록 부여된 권한이다. 다른 계정의 서비스나 애플리케이션이 이 역할을 통해 AWS 리소스에 접근할 수 있다.

3. Identity (아이덴티티)

   AWS 내에서 인증을 통해 리소스에 접근할 수 있는 모든 엔티티이다.

   • IAM group: 여러 사용자를 묶어 동일한 정책을 부여할 수 있도록 만든 그룹이다.

4. Resource (리소스)

   AWS에서 관리되는 모든 리소스를 포함하는 큰 영역이다.

   • Policy: IAM 엔티티나 리소스에 접근할 수 있는 권한을 정의한 문서이다.
   • Instance profile: EC2 인스턴스가 역할을 통해 리소스에 접근할 수 있게 하는 프로파일이다.
   • OIDC provider: OpenID Connect 프로토콜을 사용하여 IAM 역할과 외부 ID 제공자 간 신뢰 관계를 설정할 때 사용된다.
   • 기타 등등

IAM 권한 검증 절차

실제로 사용자가 AWS 에 접근할 때 어떤 과정으로 권한 검증이 이뤄질까?

다음으로는 IAM 설정 과정에 대해 설명하겠다.

참고

• AWS Identity and Access Management 왜 IAM을 사용해야 하나요? - AWS Identity and Access Management
• 인파 - [AWS] IAM 개념 원리 & IAM 계정 · 정책 생성하기
• AWS 강의실 쉽게 설명하는 AWS 기초 강좌 5: IAM 기초

• 어떤 것을 하려다가 문제가 발생했는가?

  간단한 프로젝트를 Actions로 브런치를 생성하여 푸시하는 과정에서 문제가 일어남.

• 발생한 환경, 프로그램

  Vue.js , Github Actions

• 발생한 문제(에러)

  

```bash
Push the commit or tag
  /usr/bin/git push origin gh-pages
  remote: Permission to lee-JunR/LuckyDraw.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/lee-JunR/LuckyDraw.git/': The requested URL returned error: 403
  Error: Action failed with "The process '/usr/bin/git' failed with exit code 128"
```

원인

• 원인

  403 에러면 권한 문제이므로 해당 프로젝트 설정의

최종 해결

• 해결방법

  

해당 Repo의 `Settings` > `Actions` > `General` > `Workflow permissions` 에서 

**Read and write permissions 를 체크해준다.**

4. Workflow permissions (워크플로우 권한)

이 설정은 워크플로우가 실행될 때 GITHUB_TOKEN에 부여되는 기본 권한을 정의한다.

• Read and write permissions (읽기 및 쓰기 권한):

  워크플로우는 리포지토리 내에서 모든 범위에 대해 읽기 및 쓰기 권한을 가집니다. 이 옵션은 더 많은 제어 권한이 필요한 경우에 사용됩니다.

• Read repository contents and packages permissions (리포지토리 내용 및 패키지 읽기 권한):

  워크플로우는 리포지토리의 내용 및 패키지 범위에 대해 읽기 권한만 가집니다. 보다 제한적인 권한이 필요한 경우에 사용됩니다.

결과

https://lee-junr.github.io/LuckyDraw/ 잘된다.

CS 스터디를 시작했다. 기본부터 시작하는 CS 스터디... 알고 있다고 생각한 개념도 설명하려니 알고 있는게 아니었다는 생각이 들었다. 휘발되기전에 정리해두자.

High Level Programming Language 들의 실행 방식

세상에는 크게 두 종류의 프로그래밍 언어가 있다.

1. 인터프리터 언어 - Python

• 장점:
  • 빠른 개발 및 디버깅
  • 시스템 이식성 좋음
• 단점:
  • 상대적으로 느린 실행 속도
  • 소스 코드 노출 위험

2. 컴파일러 언어 - C, JAVA

• 장점:
  • 빠른 실행 속도
  • 코드 최적화 가능
  • 소스 코드 보호
• 단점:
  • 긴 개발 및 테스트 시간
  • 플랫폼 종속성

하지만 Java는 단순한 컴파일러 언어가 아니다. Java는 코드를 바이트 코드로 변환하는 컴파일러와 JVM 실행 엔진 내의 인터프리터를 동시에 갖추고 있다.

JVM이란 무엇인가?

과거에는 윈도우에서 C 언어로 작성된 코드를 서버 컴퓨터나 다른 운영체제에서 실행하려면 각 운영체제에 맞는 기계어로 번역해주는 컴파일러가 필요했다. 이로 인해, “내 컴퓨터에서는 작동하지 않는데?“라는 문제가 빈번하게 발생했다.

이 문제를 해결하기 위해 Java는 컴파일러와 운영체제 사이에 JVM이라는 한층의 레이어를 추가했다.

1. 기존 언어의 실행 방식:

• 소스코드 → OS에 맞는 컴파일러 → 기계어 → 해당 OS에서 실행

2. Java의 실행 방식:

• 소스코드 → 컴파일러 → 바이트코드 → JVM → 해당 OS에서 실행

Java는 소스 코드를 바이트 코드로 컴파일한 후, JVM이 이 바이트 코드를 읽어 각 OS에서 실행될 수 있는 형태로 해석한다. JVM 덕분에 Java는 플랫폼 독립적인 실행 환경을 제공할 수 있다.

프로그램을 실행하기 위해 JVM이라는 가상 머신으로 각 OS위에 한층의 가상화를 쌓아서 플랫폼 독립적인 실행 환경을 제공한 것이다.

JVM의 주요 기능

• 바이트코드 해석 및 실행: Java 컴파일러가 생성한 바이트코드를 해석하고, 각 OS에 맞는 기계어로 변환해 실행한다.
• 메모리 관리: 힙(Heap)과 스택(Stack) 메모리를 관리하며, 가비지 컬렉터(GC)를 통해 불필요한 메모리를 해제한다.
• 보안 및 로드: 프로그램을 안전하게 로드하고 실행하기 위한 보안 메커니즘을 제공한다.

그럼, 자바 말고 다른 언어는 JVM 위에 올릴 수 없나요?

자바뿐만 아니라 Kotlin, Groovy 등도 JVM 위에서 실행 가능하다. 이들 언어는 Java와 마찬가지로 바이트 코드로 컴파일되어 JVM에서 실행된다.

반대로 JVM 계열 언어를 일반적으로 컴파일해서 사용할 순 없나요?

가능할 것으로 생각된다. 만약 다른 프로그래밍 언어처럼 기계어 수준으로 일반적인 컴파일을 진행한다면, Java의 플랫폼 독립성과 동적 최적화의 장점을 잃게 되어 비효율적일 수 있다.

VM을 사용함으로써 얻을 수 있는 장점과 단점에 대해 설명해 주세요.

• 장점:
  • 플랫폼 독립성: JVM 덕분에 Java 프로그램은 다양한 운영체제에서 동일하게 실행될 수 있다.
  • 메모리 관리: 가비지 컬렉터를 통해 개발자가 직접 메모리 해제 작업을 하지 않아도 된다.
• 단점:
  • 성능 오버헤드: 가상 머신 위에서 실행되기 때문에 네이티브 언어에 비해 성능이 떨어질 수 있다.
  • 시작 시간: JVM 초기 구동 시간이 다소 길어질 수 있다.

JVM과 내부에서 실행되고 있는 프로그램은 부모 프로세스 - 자식 프로세스 관계를 갖고 있다고 봐도 무방한가요?

부모 프로세스 - 자식 프로세스 관계가 무엇인가?

운영체제의 프로세스 관계에서 부모 프로세스는 다른 프로세스를 생성하고, 자식 프로세스는 부모의 메모리와 환경을 복사하여 독립적으로 실행된다. (각각 고유한 메모리 공간과 PID를 가짐)

하지만 JVM은 운영체제 내에서 독립적인 프로세스로 실행되며, Java 프로그램은 JVM 프로세스 내부에서 스레드로 동작한다. JVM이 실행하는 각 Java 프로그램의 스레드들은 동일한 메모리 공간(Heap)을 공유한다. 따라서 JVM과 프로그램은 프로세스-스레드 관계로, 부모-자식 프로세스 관계가 아니다.

고도화를 하기 전에 KPT 회고를 진행했고 해당 회고를 바탕으로 고도화를 설계했다.

Keep (유지할 점)

프로젝트에서 내가 해야할 과제가 주어지면 해당 과제를 풀어가는 과정을 연구노트 및 트러블 슈팅 페이지로 정리하며 문서화를 진행했다.

내가 한 일을 문서화하면서 자신이 뭘 알고 있는지 다시 한번 확인할 수 있었고 다른 팀원에게 설명할때도 진행상황을 명확히 공유할 수 있어 좋았다.

Problem (문제점)

프로젝트 진행 중 겪었던 주요 어려움은 팀원 간의 능력과 가용 시간 차이로 인한 공정하고 효율적인 업무 배분이었다. 구체적으로 다음과 같은 문제점들이 있었다.

• 팀원별 기술 숙련도와 프로젝트 투자 가능 시간의 차이로 인한 업무 처리 시간과 효율성의 불균형
• 제한된 가용 시간을 가진 팀원들로 인한 일정 지연 발생
• 팀원들의 포트폴리오 요구사항을 고려한 업무 배정의 어려움
• 업무 분배의 형평성과 프로젝트의 효율적 진행 사이의 균형 유지의 어려움

이러한 문제점들로 인해 전체 프로젝트 일정 관리에 문제가 생겼다.

Try (시도할 점)

그래서 우리팀은 일주일의 고도화 기간을 진행하기 전에 투표를 진행해서 해야할 일을 난이도 별로 세분화하여 리스트업하고 가용시간을 투표를 받아 업무를 분배하기로 했다!

1. 해야 할 일과 가용 시간을 명확히 확인하고 공정하게 분배하기
2. 모든 팀원이 연구 노트를 작성하고, 이를 서로 읽고 공유하는 시간을 갖기

이러한 노력을 통해 우리 팀은 고도화 기간 동안 더욱 효율적이고 공정한 프로젝트 진행을 할 수 있었습니다. 각 팀원의 강점을 살리면서도 모두가 참여할 수 있는 환경을 만들어 프로젝트의 질을 높일 수 있었습니다.

고도화 기간 동안의 주요 개선 사항

1. 동시성 개선 : 기존 Redis 기반으로 되어있던 코드를 레코드락으로 전환시켜서 어느정도의 성능차이가 있는지 알아보았음.
2. 코드 리팩토링: 테스트 코드 최적화 및 중복 코드를 제거하고 모듈화를 개선하여 코드의 가독성과 유지보수성을 높였음

결론

다른 프로젝트를 할 때에도 고도화 기간을 따로 갖는것이 좋을 것 같다 발표 기한이 끝났다고 정말로 끝내는 프로젝트가 아니라 갈무리하는 경험을 통해서 프로젝트의 완성도를 챙길 수 있어 앞으로도 해당 기간을 갖고 진행할 예정이다.