O's Of The Day

Jest private method mocking

5linesys — Wed, 11 Dec 2024 21:38:57 +0900

Object.getPrototypeOf()

Object.getPrototypeOf() 를 사용하면 인스턴스의 원형에 접근할 수 있어 private 메서드도 mocking 할 수 있다.

class MyClass {
  private myPrivateMethod(): string {
    return 'Original Private Method';
  }

  public callPrivateMethod(): string {
    return this.myPrivateMethod();
  }
}

describe('MyClass', () => {
  it('should mock private method using `Object.getPrototypeOf`', () => {
    const myInstance = new MyClass();
    const prototype = Object.getPrototypeOf(myInstance);

    const spy = jest.spyOn(prototype as any, 'myPrivateMethod').mockReturnValue('Mocked Private Method');

    const result = myInstance.callPrivateMethod();

    expect(spy).toHaveBeenCalled();
    expect(result).toBe('Mocked Private Method');
  });
});

장점: 타입 시스템을 유지하며, 프로토타입 체인을 이용해 안정적으로 접근할 수 있다.
단점: 약간의 복잡함이 있다.

DI

nestjs 의 경우 class 가 모듈화 되어있어 DI 를 활용하여 해결할 수 있다.

import { Injectable } from '@nestjs/common';

@Injectable()
class HelperService {
  myHelperMethod(): string {
    return 'Original Helper Method';
  }
}

@Injectable()
class MyService {
  constructor(private readonly helperService: HelperService) {}

  public callPrivateMethod(): string {
    return this.helperService.myHelperMethod();
  }
}

import { Test, TestingModule } from '@nestjs/testing';
import { MyService } from './my-service';
import { HelperService } from './helper-service';

describe('MyService', () => {
  let myService: MyService;
  let helperService: HelperService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [MyService, HelperService],
    }).compile();

    myService = module.get<MyService>(MyService);
    helperService = module.get<HelperService>(HelperService);
  });

  it('should call myHelperMethod and return the mocked result', () => {
    // 모킹 (mocking) 처리
    jest.spyOn(helperService, 'myHelperMethod').mockReturnValue('Mocked Helper Method');

    const result = myService.callPrivateMethod();

    expect(helperService.myHelperMethod).toHaveBeenCalled();
    expect(result).toBe('Mocked Helper Method');
  });
});

설명
- HelperService 는 MysSevercie 의 private 메서드에 해당한다.
- DI 로 주입한 HelperSevice 는 독립된 서비스이므로, 재사용이 가능하고 직접 모킹이 가능하다.
장점: 타입 시스템을 깨뜨리지 않으며 유지보수가 쉽다.
단점: 의존성을 추가해야 하므로 구조에 따라 코드 리펙터링이 필요하다.

gRPC

5linesys — Mon, 9 Dec 2024 22:54:18 +0900

gRPC 는 Google 에서 개발한 오픈 소스 원격 프로시저 호출(Remote Procedure Call) 프레임워크로, 기존의 RPC 시스템을 현대화하여 다양한 환경에서 효율적인 통신을 지원한다. gRPC는 HTTP/2 를 기반으로 하며, 프로토콜 버퍼(Protocol Buffers) 를 사용하여 데이터를 직렬화한다.

전통적인 RPC 시스템과 gRPC 의 차이

데이터 직렬화 방식
- RPC: 일반적으로 XML이나 JSON 같은 텍스트 기반의 직렬화 형식을 사용한다.
- gRPC: 프로토콜 버퍼라는 이진 직렬화 형식을 사용하여 데이터의 크기를 줄이고, 직렬화 및 역직렬화 속도를 향상시킨다.
전송 프로토콜
- RPC: 주로 HTTP/1.1 을 사용하며, 요청-응답 방식으로 통신한다.
- gRPC: HTTP/2 를 기반으로 하여 멀티플렉싱, 헤더 압축, 서버 푸시 등 향상된 기능을 제공한다.
스트리밍 지원
- RPC: 일반적으로 단방향 통신을 지원하며, 스트리밍 기능이 제한적이다.
- gRPC: 클라이언트 스트리밍, 서버 스트리밍, 양방향 스트리밍을 모두 지원하여 실시간 데이터 전송에 유리하다.
다양한 언어 지원 및 코드 생성
- RPC: 언어별로 상이한 구현이 필요하며, 코드 생성 도구의 지원이 제한적이다.
- gRPC: 프로토콜 버퍼를 통해 서비스와 메시지의 계약을 정의하고, 이를 기반으로 다양한 언어의 클라이언트 및 서버 코드를 자동으로 생성할 수 있다.

gRPC 의 주요 장점

고성능: 이진 직력화와 HTTP/2의 효율적인 전송 방식을 통해 낮은 지연 시간과 높은 처리량을 제공한다.
다양한 언어 지원: 하나의 프로토콜 버퍼 정의로 여러 언어의 클라이언트와 서버 코드를 생성할 수 있어, 이기종 시스템 간의 통신이 용이히다.
스티리밍 기능: 다양한 스티리밍 방식을 지원하여 실시간 데이터 처리에 적합하다.
엄격한 계약 기반 개발: 프로토콜 버퍼를 통한 명확한 인터페이스 정의로, 개발 단계에서오류를 줄이고 유지보수성을 높인다.

gRPC 의 주요 상태 코드 목록

코드	상태	설명
0	OK	성공
1	CANCELLED	취소됨
2	UNKNOWN	알려지지 않은 오류
3	INVALID_ARGUMENT	잘못된 인수
4	DEADLINE_EXCEEDED	타임아웃
5	NOT_FOUND	리소스를 찾을 수 없음
6	ALREADY_EXISTS	리소스 이미 존재
7	PERMISSION_DENIED	권한 없음
8	RESOURCE_EXHAUSTED	리수소 부족
9	FAILED_PRECONDITION	작업 수행 불가 상태
10	ABORTED	작업 중단(충돌 발생 가능)
11	OUT_OF_RANGE	허용범위 벗어남
12	UNIMPLEMENTED	서버에서 구현되지 않은 메서드 호출
13	INTERNAL	예기치 못한 오류
14	UNAVAILABLE	서비스 다운
15	DATA_LOSS	중요 데이터 손실
16	UNAUTHENTICATED	인증 실패(권한 없음)

구현 코드(Nestjs)

https://github.com/O-Seonsik/grpc-test/tree/release/1.0.0

GitHub - O-Seonsik/grpc-test: grpc 테스트를 위한 저장소입니다.

grpc 테스트를 위한 저장소입니다. Contribute to O-Seonsik/grpc-test development by creating an account on GitHub.

github.com

마샬링(Marshalling)과 직렬화(Serialization)

5linesys — Sat, 7 Dec 2024 18:40:13 +0900

마샬링(Marshalling)과 직렬화(Serialization)은 모두 데이터를 특정 형식으로 변환하는 과정이지만, 그 목적과 범위에서 차이가 있다.

직렬화(Serialization)

직렬화는 객체의 상태를 저장하거나 전송하기 위해 객체를 바이트 스트림과 같은 원시 데이터 형식으로 변환하는 과정이다. 이를 통해 객체를 파일에 저장하거나 네트워크를 통해 전송할 수 있으며, 나중에 이 바이트 스트림을 역직렬화(Deserialization)하여 원래의 객체로 복원할 수 있다. 직렬화는 주로 동일한 시스템 내에서 데이터를 저장하거나 전송할 때 사용된다.

마샬링(Marshalling)

마샬링은 직렬화와 유사하지만, 주로 서로 다른 시스템이나 프로그래밍 언어 간의 통신을 위해 데이터를 변환하는 과정이다. 이는 원격 프로시저 호출(RPC)에서 함수의 매개변수나 반환 값을 전달할 때 사용되며, 복잡한 객체를 단순한 원시 데이터로 변환하여 전송한다. 마샬링의 반대 과정은 언마샬링(Unmarshalling)으로, 전송된 데이터를 원래의 객체 형태로 복원한다.

차이점

목적: 직렬화는 주로 데이터를 저장하거나 동일한 시스템 내에서 전송하기 위한 것이며, 마샬링은 서로 다른 시스템이나 언어 간의 통신을 위함
범위: 직렬화는 객체를 바이트 스트림으로 변환하는데 중점을 두지만, 마샬링은 데이터의 구조와 의미를 유지하면서 다른 형식으로 변환하는 것을 포함한다.
사용 사례: 직렬화는 파일 저장, 메모리 버퍼, 네트워크 전송 등에 사용되며, 마샬링은 원격 프로시저 호출, 이기종 시스템 간의 데이터 교환 등에 사용된다.

따라서, 직렬화는 객체를 저장하거나 전송하기 위한 변환 가정이며, 마샬링은 주로 이기종 시스템 간의 통신을 위해 데이터를 변환하는 더 포괄적인 과정으로 볼 수 있다.

RPC(Remote Procedure Call)

5linesys — Sat, 7 Dec 2024 18:27:52 +0900

RPC(Remote Procedure Call)는 네트워크를 통해 분산 시스템에서 서로 다른 컴퓨터 간의 프로시저(함수)를 호출할 수 있도록 하는 통신 메커니즘이다. RPC는 로컬 함수 호출처럼 보이지만, 실제로는 원격 서버에서 실행되는 프로세스다. 이를 통해 부산 시스템 간의 통신을 쉽게 구현할 수 있다. 이를 통해 개발자는 네트워크 통신의 복잡성을 신경 쓰지 않고도 원격 서버의 기능을 사용할 수 있다.

주요 특징

투명성: 개발자는 원격 함수 호출을 로컬 함수 호출처럼 수행할 수 있으며, 네트워크 통신의 복잡성을 숨겨준다.
언어 및 플랫폼 독립성: RPC 는 다양한 언어와 플랫폼 간의 통신을 지원하여 이기종 시스템 간의 상호 운용성을 높인다.
계층 구조: 클라이언트와 서버는 서로 계층적으로 구성되며, 클라이언트와 서버가 명확히 구분된다.

구성 요소

클라이언트(Client): 원격 프로시저를 호출하는 주체
클라이언트 스텁(Client Stub): 클라이언트 측에서 원격 프로시저 호출을 대리하며, 매개변수를 직렬화하고 서버로 전송하는 역할을 한다.
서버 스텁(Server Stub): 서버 측에서 클라이언트로부터 수신한 데이터를 역직렬화하고 실제 프로시저를 호출하며, 결과를 다시 직렬화하여 클라이언트로 전송한다.
RPC 런타임(RPC Runtime): 클라이언트와 서버 간의 통신을 관리하며, 메시지의 전송, 재전송, 라우팅 등을 처리한다.

동작과정

클라이언트 호출: 클라이언트는 원격 프로시저를 호출하듯이 클라이언트 스텁을 호출한다.
마샬링(Marshalling): 클라이언트 스텁은 전달받은 매개변수를 네트워크를 통해 전달할 수 있도록 직렬화한다.
메시지 전송: 직렬화된 데이터는 네트워크를 통해 서버로 전송된다.
언마샬링(Unmarshalling): 서버 스텁은 수신한 데이터를 역직렬화 하여 원래의 매개변수 형태로 복원한다.
서버 프로시저 실행: 서버 스텁은 실제 프로시저를 호출하여 작업을 수행한다.
결과 반환: 서버 프로시저의 결과를 클라이언트로 전송하기 위해 다시 직렬화하고, 클라이언트는 이를 수신하여 역직렬화 후 최종 결과를 획득한다.

이러한 구성 요소와 동작 과정을 통해 RPC는 분산 시스템에서의 통신을 효율적으로 처리하며, 개발자는 네트워크 통신의 복잡성을 신경 쓰지 않고 원격 함수를 호출할 수 있다.

RPC와 HTTP API 의 차이

RPC(Remote Procedure Call)
- 개념: 클라이언트가 원격 서버의 함수를 로컬 함수처럼 호출하여 실행 결과를 얻는 방식
- 통신 방식: 일반적으로 TCP/IP를 통해 통신하며, 데이터 직렬화 형식에 따라 성능이 달라진다. 전통적인 RPC 시스템에서는 텍스트 기반의 직렬화 방식을 사용할 수 있어 데이터 크기가 커지고, 이로 인해 전송 속도가 느려질 수 있다.
- 데이터 형식: 이진 데이터 형식을 사용하여 효율적인 통신을 지원함
HTTP API
- 개념: HTTP 프로토콜을 기반으로 클라이언트와 서버가 요청과 응답을 주고받는 방식
- 통신 방식: HTTP/1.1 또는 HTTP/2 를 사용하며, RESTful API 가 일반적이다.
- 데이터 형식: JSON 이나 XML 과 같은 텍스트 기반의 데이터를 주로 사용

전통적인 RPC 시스템에서는 직렬화 방식과 통신 프로토콜에 따라 HTTP API보다 성능이 떨어질 수 있다. gRPC와 같은 현대적인 RPC 프레임워크는 효율적인 이진 직렬화와 HTTP/2의 장점을 활용하여 높은 성능을 제공한다. 그러나, 웹 기반의 공개 API나 브라우저와의 호환성이 중요한 경우에는 여전히 RESTful API가 널리 사용되고 있다. 따라서, 시스템의 요구사항과 환경에 따라 적합한 통신 방식을 선택하는 것이 중요하다.

함께 보기 좋은 글

https://5linesys.tistory.com/34

마샬링(Marshalling)과 직렬화(Serialization)

마샬링(Marshalling)과 직렬화(Serialization)은 모두 데이터를 특정 형식으로 변환하는 과정이지만, 그 목적과 범위에서 차이가 있다. 직렬화(Serialization)직렬화는 객체의 상태를 저장하거나 전송하기

blog.oseonsik.com

Terraform nonsensitive

5linesys — Thu, 28 Nov 2024 22:16:05 +0900

Terraform에서 nonsensitive 함수는 민감한(Sensitive) 값의 민감성 표시를 제거하여 해당 값을 일반 값처럼 취급할 수 있게 한다.

이 함수는 Terraform 버전 0.15부터 사용 가능하다.

사용 목적

Terraform은 민감한 정보를 보호하기 위해 변수나 리소스의 값을 민감한 값(Sensitive Value)으로 표시할 수 있다. 이렇게 설정된 값은 Terraform의 출력이나 로그에 노출되지 않도록 처리한다. 그러나 특정 상황에서는 이러한 민감성 표시를 제거하고 값을 일반 값처럼 사용해야 할 필요가 있다. 이때 nonsensitive 함수를 사용하여 민감성 표시를 제거할 수 있다.

사용 예시

variable "secret_value" {
  type      = string
  sensitive = true
}

output "exposed_value" {
  value = nonsensitive(var.secret_value)
}

주의사항

보안 위험: 민감한 값을 일반 값으로 변환하여 출력하거나 로그에 노출하면 보안 위험이 발생할 수 있다. 따라서, 정말 필요한 경우에만 사용해야 하며, 사용 시 민감한 정보가 노출되지 않도록 주의해야 한다.
의도적인 사용: nonsensitive 함수는 Terraform의 기본 민감성 처리 동작을 무시하고 값을 노출시키는 기능이므로, 의도적으로 사용해야 한다. 불필요한 사용은 보안 사고로 이어질 수 있다.

Nestjs Request Lifecycle

5linesys — Sun, 24 Nov 2024 18:41:06 +0900

Nestjs Request Lifecycle

1. Middleware (미들웨어)

위치: 요청 처리의 가장 첫 단계
역할: HTTP 요청/응답을 가로채어 수정하거나 처리 여부를 결정
주요 기능:
- 요청 로깅
- 헤더 조작
- 요청 본문 파싱
- CORS 설정

// Interceptor 구현
@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`Request ${req.method} ${req.url}`);
    next();
  }
}

// Interceptor 적용
import { Module, NestModule, MiddlewareConsumer } from '@nestjs/common';
import { LoggerMiddleware } from './common/middleware/logger.middleware';
import { CatsModule } from './cats/cats.module';

@Module({
  imports: [CatsModule],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('cats');
  }
}

2. Guards(가드)

위치: 미들웨어 다음, 라우트 핸들러 이전
역할: 인증/인가 등 요청의 실행 허가 여부를 결정
주요 기능:
- 인증 상태 확인
- 권한 체크
- 접근 제어
- IP 기반 필터링

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return !!request.headers.authorization;
  }
}

3. Interceptors (인터셉터)

위치: 가드 다음, 라우트 핸들러 전후
역할: 요청/응답 변환, 추가 로직 실행
주요 기능:
- 응답 데이터 변환
- 성능 모니터링
- 캐시 처리
- 로깅

@Injectable()
export class TimingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const start = Date.now();
    return next.handle().pipe(
      tap(() => console.log(`Request took ${Date.now() - start}ms`))
    );
  }
}

4. Pipes (파이프)

위치: 인터셉터와 라우트 핸들러 사이
역할: 데이터 변환 및 유효성 검사
주요 기능:
- 입력 데이터 유효성 검사
- 데이터 타입 변환
- DTO 검증
- 기본값 설정

@Post()
createUser(@Body(new ValidationPipe()) createUserDto: CreateUserDto) {
  return this.usersService.create(createUserDto);
}

5. Controller (컨트롤러)

위치: 파이프 다음, 비즈니스 로직 이전
역할: 요청 라우팅 및 요청/응답 처리
주요 기능:
- 요청 경로 매핑
- 요청 파라미터 추출
- 서비스 계층 호출

@Controller('users')
export class UsersController {
  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(id);
  }
}

6. Service (서비스)

위치: 컨트롤러 다음
역할: 비즈니스 로직 실행
주요 기능:
- 데이터 처리
- 외부 서비스 통신
- 데이터베이스 작업

@Injectable()
export class UsersService {
  async findOne(id: string): Promise<User> {
    return this.usersRepository.findOne(id);
  }
}

7. Exception Filters (예외 필터)

위치: 전체 요청/응답 사이클에서 예외 발생 시
역할: 예외 처리 및 에러 응답 생성
주요 기능:
- 에러 로깅
- 사용자 정의 에러 응답
- 예외 변환

@Catch(HttpException)
export class HttpExceptionFilter implements ExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const status = exception.getStatus();

    response.status(status).json({
      statusCode: status,
      timestamp: new Date().toISOString(),
      message: exception.message,
    });
  }
}

통합 사용 예시

@UseGuards(AuthGuard)
@UseInterceptors(LoggingInterceptor)
@UseFilters(HttpExceptionFilter)
@Controller('users')
export class UsersController {
  @Post()
  @UsePipes(ValidationPipe)
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

Nestjs Lifecycle 과 Event hooks

5linesys — Tue, 19 Nov 2024 22:52:22 +0900

1. 라이프사이클

NestJS는 애플리케이션 시작과 종료 시 다양한 이벤트를 발생시킨다. 이를 통해 초기화 작업, 리소스 설정, 클린업(종료 작업) 등을 수행할 수 있다.

전체 수명 주기를 초기화, 실행 및 종료의 세 단계로 나눌 수 있다.

nestjs 공식 문서에 나와있는 라이프사이클 이벤트 설명

2. 라이프사이클 이벤트

NestJS 의 Lifecycle Events 는 애플리케이션 또는 특정 구성 요소(module, provider, controller)의 수명 주기 동안 특정 시점에 실행되는 메서드이다.

명시적으로 각 훅의 인터페이스를 implements 해야 훅이 정상적으로 트리거된다.

2.1. 애플리케이션 초기화 관련 이벤트

이벤트	대상	설명
OnModuleInit	모듈, 프로바이더	모듈이나 프로바이더가 생성되고 의존성이 주입된 후 호출된다.
OnApplicationBootstrap	애플리케이션, 프로바이더	애플리케이션의 모든 초기화가 완료된 후 호출한다.

예제: OnModuleInit

import { Injectable, OnModuleInit } from '@nestjs/common';

@Injectable()
export class AppService implements OnModuleInit {
  onModuleInit() {
    console.log('Module has been initialized');
  }
}

예제: OnApplicationBootstrap

import { Injectable, OnApplicationBootstrap } from '@nestjs/common';

@Injectable()
export class AppService implements OnApplicationBootstrap {
  onApplicationBootstrap() {
    console.log('Application has been bootstrapped');
  }
}

2.2 애플리케이션 종료 관련 이벤트

이벤트	대상	설명
OnModuleDestory	모듈, 프로바이더	모듈이 종료되기 전에 호출된다.
BeforeApplicationShutdown	애플리케이션, 프로바이더	애플리케이션 종료 전 호출된다.
OnAppliationShutdown	애플리케이션, 프로바이더	애플리케이션 종료 후 호출된다.

종료 훅(hook) 리스너는 시스템 리소스를 소모하므로 기본적으로 비활성화된다.

위 테이블의 종료 관련 훅(OnModuleDestory, BeforeApplicationShutdown, OnApplicationShutdown)은 명시적으로 app.close() 를 호출하거나 특수 시스템 신호(예: SIGTERM) 를 수신하고 애플리케이션 부트스트랩에서 enableShutdownHooks 를 올바르게 호출한 경우에 트리거된다.

종료 훅(hook) 리스너 활성화 예시

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Starts listening for shutdown hooks
  app.enableShutdownHooks();

  await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

분산 락(Distributed lock)

5linesys — Sun, 17 Nov 2024 20:19:30 +0900

1. 분산 락의 상세 개념

정의: 분산 시스템에서 공유 자원에 대한 동시 접근을 제어하는 동기화 메커니즘입니다.
작동 방식:
- 모든 서버/프로세스가 접근할 수 있는 공유 저장소(Redis, ZooKeeper 등)에 락을 저장
- 락을 획득하려는 프로세스는 원자적 연산으로 락 생성을 시도
- 락을 획득한 프로세스만 공유 자원에 접근 가능
- 작업 완료 후 락을 해제하여 다른 프로세스가 사용할 수 있게 함

2. 분산 락의 핵심 요구사항

상호 배제(Mutual Exclusion): 특정 시점에 하나의 프로세스만 락을 보유할 수 있음
데드락 방지(Deadlock Prevention):
- 락 획득 실패 시 적절한 타임아웃 설정
- 락 보유자가 비정상 종료된 경우를 대비한 자동 해제 메커니즘
고가용성(High Availability):
- 락 서비스 자체의 안정성 보장
- 장애 상황에서도 시스템 전체가 마비되지 않도록 설계
성능(Performance):
- 최소한의 네트워크 통신으로 락 획득/해제
- 적절한 락 밀도(Granularity) 설정

3. 활용 예시

다중 서버/인스턴스 환경
- 여러 서버가 동일한 리소스에 접근하는 MSA(Microservice Architecture) 환경
- 오토스케일링으로 인스턴스가 동적으로 증감하는 클라우드 환경
- 서버가 물리적으로 다른 위치에 분산되어 있는 경우
다중 database 사용환경
- 글로벌 트랜잭션 관리의 어려움
  - 여러 DB간의 트랜잭션 정합성 보장이 필요
  - Two-Phase Commit의 성능 오버헤드가 큼
- DB간 동기화 시점 관리
  - 각 DB의 복제 지연 발생 가능
  - Master-Slave 구조에서의 지연 시간 차이
- 단일 DB의 락으로는 전체 시스템의 동시성 제어가 불가능
  - 각 DB는 자신의 트랜잭션만 관리 가능
  - DB간 상호 락 인지 불가능
외부 api 요청
- 같은 요청을 2번 이상 하면 안되는 경우

4. 분산 락의 구현

각 프로세스는 임계구역에 접근하는 작업시에 락 획득을 요청
락 획득 실패(다른 프로세스에서 이미 점유 중)시에는 락 획득 요청 재시도(spin lock)
락 획득 제한 횟수 초과시에 작업 실패 처리 후 프로세스 종료
락 획득 시에는 프로스에서 임계구역 접근하여 작업처리
- 최대한 짧은 단위로 작업을 수행하여 빠르게 락을 반환해야 한다.
락 반환

위와같이 특정 임계구역에 동시에 접근하여 중복된 작업이 생기는 것을 방지하기 위해 분산 락(Distributed Lock)을 활용할 수 있따.

Redis 를 통해 분산 락을 구현한 코드는 다음 링크에서 확인 가능하다.

https://github.com/O-Seonsik/lock-test/tree/master/src/modules/distributed-lock

분산 락 테스트를 위한 모듈을 같은 프로젝트의 다른 모듈에 구성해두었다. 다음 링크에서 확인 가능하다.

https://github.com/O-Seonsik/lock-test/tree/master/src/modules/products

낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)

5linesys — Thu, 14 Nov 2024 20:51:54 +0900

1. 낙관적 락(OPtimistic Lock)

낙관적 락은 충돌이 잘 발생하지 않는다고 가정하고 자원을 제어하는 방식이다. 자원을 사용하는 동안 락을 거는 대신, 작업을 끝내기 직전에 충돌이 발생했는지 검사한다. 낙관적 락은 다음과 같은 과정으로 동작한다.

자원을 사용할 때 락을 걸지 않고, 다른 프로세스도 동시에 접근할 수 있도록 허용한다.
자원 사용이 완료되면, 그 동안 자원이 변경되지 않았는지 확인한다.
만약 다른 프로세스가 자원을 변경한 것이 확인되면, 작업을 취소하고 다시 시도한다.

이 방식은 자원을 사용하는 동안 락이 걸리지 않기 때문에 성능이 높으며, 충돌이 거의 발생하지 않는 환경에서 효과적이다. 하지만 충돌이 빈번하다면 작업을 반복해야 할 수 있어 비효율적이다.

2. 비관적 락 (Pessimistic Lcok)

비관적 락은 충돌이 발생할 가능성이 높다고 가정하여 자원에 접근하기 전에 락을 거는 방식이다. 락을 건 프로세스가 작업을 완료하기 전까지 다른 프로세스는 자원에 접근할 수 없다. 비관적 락의 동작 과정은 다음과 같다.

자원에 접근할 때 락을 걸고, 다른 프로세스가 접근하지 못하도록 막는다.
자원 사용이 끝난 후 락을 해제하여 다른 프로세스가 자원에 접근할 수 있도록 한다.

비관적 락은 충돌이 빈번하게 발생하는 환경에서 유리하며, 충돌이 발생할 가능성이 낮아도 확실하게 자원을 보호할 수 있따. 그러나 항상 락을 거는 동작이 있어 자원 사용에 따라 성능에 부담이 될 수 있따.

낙관적 락: 충돌 가능성이 낮은 경우에 유리하며, 충돌이 발생하지 않을 것이라고 가정. 작업 종료시 변경 검증.
비관적 락: 충돌 가능성이 높은 경우에 유리하며, 자원을 사용할 때 락을 걸어 안전하게 보호.

이 두 방식은 시스템의 특성에 따라 선택되며, 서로 다른 상황에서 적합하게 사용될 수 있다.

nestjs + typeorm 으로 구현한 간단한 코드를 다음 링크에서 확인 가능

https://github.com/O-Seonsik/lock-test/tree/master/src/modules/seller

DB - 블로킹(Blocking)과 데드 락(Deadlock)

5linesys — Mon, 11 Nov 2024 22:27:25 +0900

블로킹(Blocking)

정의:

한 트랜잭션이 자원(테이블, 행 등)을 Lock 하고 있을 때, 다른 트랜잭션이 해당 자원에 접근하지 못하고 기다리는 현상

특징:

일시적인 현상으로, Lock 이 해제되면 자연스럽게 해결됨
정상적인 데이터베이스 동작의 일부
데이터 일관성을 보장하기 위한 매커니즘

예시 코드)

-- 블로킹 예시

-- 트랜잭션 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 여기서 잠시 멈춤 (아직 COMMIT하지 않음)

-- 트랜잭션 2 (동시 실행)
BEGIN;
UPDATE accounts SET balance = balance + 50 WHERE id = 1;  
-- 트랜잭션 1이 COMMIT할 때까지 대기 (블로킹)

데드 락(Deadlock)

정의:

두 개 이상의 트랜잭션이 각각의 자원을 점유한 상태에서 상대방의 자원을 요청하며 무한히 기다리는 상태

특징:

자연스럽게 해결되지 않음
시스템의 개입이 필요함
순환 대기가 발생

발생조건

상호 배제(Mutual Exclusion)
- 자원은 한 번에 하나의 트랜잭션만 사용 가능
- 다른 트랜잭션은 해당 자원 사용 불가
점유와 대기(Hold and Wait)
- 트랜잭션이 최소한 하나의 자원을 보유
- 다른 트랜잭션이 사용 중인 자원을 추가로 요청
비선점(No Preemption)
- 이미 할당된 자원을 강제로 빼앗을 수 없음
- 자원을 가진 트랜잭션이 자발적으로 해제하기 전까지 계속 사용
순환 대기(Circular Wait)
- 트랜잭션들이 순환 형태로 자원을 요청
- 각 트랜잭션은 다음 트랜잭션이 가진 자원을 요청

예시 코드)

-- 데드락 예시

-- 트랜잭션 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 여기서 id=2인 레코드의 락을 기다림
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

-- 트랜잭션 2 (동시 실행)
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 2;
-- 여기서 id=1인 레코드의 락을 기다림
UPDATE accounts SET balance = balance + 100 WHERE id = 1;

데드락 해결 방안

1. 예방(Prevention)

-- 1. 순서 기반 접근
BEGIN;
SELECT * FROM accounts 
WHERE id IN (1, 2) 
ORDER BY id FOR UPDATE;  -- 항상 작은 ID부터 잠금

-- 2. 한 번에 모든 자원 획득
BEGIN;
SELECT * FROM accounts 
WHERE id IN (1, 2, 3) FOR UPDATE;

2. 회피(Avoidance)

-- 타임아웃 설정
SET innodb_lock_wait_timeout = 50;  -- 50초 후 타임아웃

-- 트랜잭션 격리 수준 조정
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

3. 감지 및 복구(Detection & Recovery)

-- 데드락 정보 확인
SHOW ENGINE INNODB STATUS;

-- 데드락 발생 시 자동으로 롤백되는 트랜잭션 처리
BEGIN;
DECLARE EXIT HANDLER FOR DEADLOCK
BEGIN
    ROLLBACK;
    -- 재시도 로직
END;

데드락 방지를 위한 Best Practices

애플리케이션 레벨
1. 트랜잭션 범위를 최소화
2. 일관된 순서로 데이터 접근
3. 대량 처리 시 배치 처리 활용
4. 적절한 인덱스 설계
데이터베이스 레벨
1. 적절한 격리 수준 설정
2. 인덱스 최적화
3. 주기적인 모니터링
4. 타임아웃 설정
운영관리
1. 데드락 로그 모니터링
2. 성능 지표 관리
3. 주기적인 테이블 유지보수

결론

블로킹과 데드락은 모두 동시성 제어 과정에서 발생하는 현상이지만, 블로킹은 정상적인 동작의 일부로 볼 수 있는 반면, 데드락은 비정상적인 상황으로 보고 적극적인 방지가 필요하다. 효과적인 데이터베이스 설계와 모니터링을 통해 두 현상 모두 최소화할 수 있다.

특히 실제 운영환경에서는 데드락 발생 시 자동으로 재시도하는 로직을 구현하는 것이 중요하다.

서버측에서 재시도 관련 처리를 테스트를 진행한 코드를 다음 링크에서 확인 가능

https://github.com/O-Seonsik/lock-test/tree/master/src/modules/products