삽질기록

Gradle 의존성 이해하기

copcat — Tue, 21 Jul 2026 16:31:38 +0900

build.gradle에 의존성을 추가하다 보면 다음과 같은 설정을 자주 보게 됩니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-webmvc'
    runtimeOnly 'com.mysql:mysql-connector-j'
    testImplementation 'org.testcontainers:mysql'
}

그런데 다음과 같은 의문이 생깁니다.

왜 Spring MVC는 implementation일까요?
MySQL 드라이버는 왜 runtimeOnly일까요?
Testcontainers는 왜 testImplementation일까요?
compileOnly는 정확히 언제 사용하는 걸까요?

이 글에서는 Gradle configuration을 단순히 외우기보다, 어떤 기준으로 선택하는지 이해해보겠습니다.

1. 컴파일과 런타임의 차이

먼저 컴파일과 런타임을 구분해야 합니다.

컴파일

Java 소스 코드를 JVM이 실행할 수 있는 바이트코드로 변환하는 과정입니다.

.java 파일 → 컴파일러 → .class 파일

이때 소스 코드에서 사용하는 클래스와 인터페이스를 컴파일러가 알아야 합니다.

예를 들어 다음 코드가 있습니다.

import org.springframework.web.bind.annotation.RestController;

@RestController
public class TicketController {
}

컴파일러는 RestController가 어떤 타입인지 알아야 합니다. 따라서 Spring MVC 라이브러리가 컴파일 classpath에 있어야 합니다.

런타임

컴파일된 애플리케이션을 실제로 실행하는 시점입니다.

./gradlew bootRun

런타임에는 다음과 같은 작업이 발생할 수 있습니다.

데이터베이스 연결
JDBC 드라이버 탐색
리플렉션
ServiceLoader 기반 구현체 탐색
Spring Boot 자동 구성
설정 파일을 통한 구현체 선택

컴파일할 때 직접 타입을 사용하지 않았더라도 실행 중에 필요한 라이브러리가 있을 수 있습니다.

2. Gradle configuration은 의존성의 출입증입니다

implementation, runtimeOnly, testImplementation은 단순한 라벨이 아닙니다.

Gradle에 다음 정보를 알려주는 설정입니다.

언제 필요한가?
어떤 소스에서 사용하는가?
다른 프로젝트에 공개해야 하는가?

Gradle은 선언된 configuration을 바탕으로 작업별 classpath를 만듭니다.

의존성 선언
    ↓
Gradle이 작업별 classpath 계산
    ↓
컴파일·실행·테스트가 classpath 사용

대표적인 classpath는 다음과 같습니다.

Classpath	사용 시점
`compileClasspath`	main 코드 컴파일
`runtimeClasspath`	애플리케이션 실행
`testCompileClasspath`	테스트 코드 컴파일
`testRuntimeClasspath`	테스트 실행

Configuration과 실제 classpath의 관계를 단순화하면 다음과 같습니다.

implementation
    ├─ compileClasspath
    └─ runtimeClasspath

runtimeOnly
    └─ runtimeClasspath

testImplementation
    ├─ testCompileClasspath
    └─ testRuntimeClasspath

3. `implementation`

implementation은 현재 애플리케이션의 컴파일과 실행에 필요한 기본 configuration입니다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-webmvc'
}

다음과 같이 애플리케이션 코드에서 직접 Spring 타입을 사용한다고 가정해보겠습니다.

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TicketController {

    @GetMapping("/tickets")
    public String tickets() {
        return "tickets";
    }
}

이 코드를 컴파일하려면 Spring MVC가 필요합니다.

또한 애플리케이션을 실행하려면 Spring MVC의 실제 구현체도 필요합니다.

컴파일: Spring 타입을 직접 사용
실행: Spring MVC 애플리케이션 실행

따라서 implementation을 사용합니다.

`implementation`을 선택하는 기준

다음 질문에 “예”라고 답할 수 있다면 implementation을 우선 고려하면 됩니다.

main 코드에서 직접 import하는가?
어노테이션이나 인터페이스로 사용하는가?
컴파일할 때 필요한가?
애플리케이션 실행에도 필요한가?

현재처럼 하나의 Spring Boot 애플리케이션을 만드는 경우에는 대부분의 일반적인 라이브러리가 implementation으로 들어갑니다.

4. `runtimeOnly`

runtimeOnly는 컴파일할 때 직접 타입을 사용할 필요는 없지만, 애플리케이션 실행 중에는 필요한 의존성입니다.

대표적인 예가 MySQL JDBC 드라이버입니다.

dependencies {
    runtimeOnly 'com.mysql:mysql-connector-j'
}

애플리케이션 코드에서 보통 다음과 같은 코드를 직접 작성하지 않습니다.

import com.mysql.cj.jdbc.Driver;

대신 Spring Boot와 JDBC가 설정된 JDBC URL을 바탕으로 실행 중에 드라이버를 찾습니다.

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/ticketing

MySQL 드라이버의 사용 시점은 다음과 같습니다.

컴파일: 애플리케이션 코드에서 드라이버 타입을 직접 사용하지 않음
실행: MySQL 연결을 만들기 위해 드라이버 필요

따라서 runtimeOnly가 적절합니다.

`implementation`으로 넣으면 안 되는가?

다음과 같이 선언해도 애플리케이션은 동작할 수 있습니다.

implementation 'com.mysql:mysql-connector-j'

하지만 runtimeOnly가 의도를 더 정확하게 표현합니다.

이 애플리케이션 코드는 MySQL 드라이버 구현 타입을 직접 사용하지 않지만, 실행할 때는 드라이버가 필요합니다.

즉, runtimeOnly는 의존성의 사용 범위를 더 좁게 선언하는 방법입니다.

5. `testImplementation`

testImplementation은 테스트 코드의 컴파일과 실행에만 필요한 의존성입니다.

dependencies {
    testImplementation 'org.testcontainers:mysql'
}

Testcontainers를 사용하는 테스트는 다음과 같이 작성할 수 있습니다.

MySQLContainer<?> mysql =
        new MySQLContainer<>("mysql:8.4");

이 타입은 운영 애플리케이션 코드가 아니라 테스트 코드에서만 사용합니다.

운영 애플리케이션: Testcontainers 불필요
테스트 코드: MySQLContainer 타입 필요

따라서 testImplementation을 사용합니다.

중요한 점

testImplementation은 테스트 컴파일에만 사용된다는 뜻이 아닙니다.

테스트 코드에서 직접 타입을 사용해야 하므로 다음 두 시점에 필요합니다.

테스트 컴파일: MySQLContainer 타입을 알아야 함
테스트 실행: 실제 컨테이너를 실행해야 함

다만 운영 애플리케이션의 main runtime classpath에는 포함되지 않습니다.

6. `compileOnly`

compileOnly는 컴파일할 때는 필요하지만, 애플리케이션 실행 시에는 해당 실행 환경이 제공한다고 가정하는 의존성입니다.

dependencies {
    compileOnly 'jakarta.servlet:jakarta.servlet-api:버전'
}

의미는 다음과 같습니다.

컴파일: 필요
애플리케이션 실행 classpath: 포함하지 않음

예를 들어 애플리케이션 서버가 Servlet API를 제공한다고 가정할 수 있다면, 소스 코드를 컴파일하기 위한 타입 정보만 필요할 수 있습니다.

`compileOnly`를 잘못 사용하면?

실행할 때 실제로 필요한 라이브러리를 compileOnly로 선언하면 문제가 발생합니다.

컴파일 성공
    ↓
애플리케이션 실행
    ↓
ClassNotFoundException
또는 NoClassDefFoundError

따라서 compileOnly를 사용할 때는 반드시 다음을 확인해야 합니다.

실행 환경이 정말 이 라이브러리를 제공하는가?

실행 환경이 제공하지 않는다면 implementation을 사용해야 합니다.

7. Lombok은 왜 `compileOnly`인가?

Lombok은 조금 특수한 예시입니다.

dependencies {
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

다음과 같은 코드를 작성한다고 가정해보겠습니다.

@Getter
public class Ticket {
    private Long id;
}

Lombok은 컴파일 과정에서 getter 메서드를 생성합니다.

public Long getId() {
    return id;
}

실행 시점에는 이미 getter 코드가 생성되어 있으므로 Lombok 라이브러리 자체가 필요하지 않습니다.

각 설정의 역할은 다음과 같습니다.

설정	역할
`compileOnly`	컴파일러가 Lombok 어노테이션 타입을 알 수 있게 함
`annotationProcessor`	컴파일 중 실제 코드를 생성

즉 Lombok은 다음과 같습니다.

컴파일: 필요
코드 생성: 필요
실행: 불필요

8. `testRuntimeOnly`

testRuntimeOnly는 테스트 소스 코드에서 타입을 직접 사용하지 않지만, 테스트 실행 순간에 필요한 의존성입니다.

dependencies {
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

테스트 코드에서 직접 junit-platform-launcher의 타입을 import하지는 않지만, 테스트 실행 엔진이 동작하려면 필요할 수 있습니다.

테스트 코드 컴파일: 불필요
테스트 실행: 필요

이런 경우 testRuntimeOnly를 사용합니다.

9. `api`와 `implementation`

api는 여러 프로젝트가 함께 사용하는 라이브러리 모듈에서 중요합니다.

plugins {
    id 'java-library'
}

dependencies {
    api 'com.fasterxml.jackson.core:jackson-databind:버전'
    implementation 'org.apache.commons:commons-lang3:버전'
}

내 라이브러리의 public API에 외부 라이브러리 타입이 등장한다면 api를 고려합니다.

public interface TicketPolicy {

    ExternalTicketType findTicket(Long ticketId);
}

ExternalTicketType이 외부 라이브러리의 타입이라면, 이 라이브러리를 사용하는 프로젝트도 해당 타입을 알아야 컴파일할 수 있습니다.

이때 api를 사용합니다.

반대로 외부 라이브러리를 내부 구현에서만 사용한다면 implementation이 적절합니다.

현재처럼 하나의 Spring Boot 애플리케이션을 만드는 단계에서는 api보다 다음 설정을 먼저 이해하는 것이 좋습니다.

implementation
runtimeOnly
testImplementation
compileOnly

10. configuration 선택 순서

새로운 의존성을 추가할 때는 다음 순서로 판단하면 됩니다.

1. main 코드가 라이브러리 타입을 직접 사용하는가?

   ├─ 실행에도 필요하다
   │   └─ implementation

   └─ 실행 환경이 제공한다
       └─ compileOnly


2. main 코드에서 직접 사용하지 않지만
   실행 중 프레임워크가 찾는가?

   └─ runtimeOnly


3. src/test에서만 사용하는가?

   ├─ 테스트 코드가 타입을 직접 사용한다
   │   └─ testImplementation

   └─ 테스트 실행 순간에만 필요하다
       └─ testRuntimeOnly

더 쉽게 요약하면 다음과 같습니다.

질문	선택
애플리케이션 코드가 직접 사용하고 실행에도 필요한가?	`implementation`
컴파일에는 필요하지만 실행 환경이 제공하는가?	`compileOnly`
코드에서 직접 사용하지 않지만 실행 중 필요한가?	`runtimeOnly`
테스트 코드에서 직접 사용하는가?	`testImplementation`
테스트 실행 순간에만 필요한가?	`testRuntimeOnly`

애매할 때는 implementation을 기본값으로 선택하고, 실제 사용 범위가 명확해졌을 때 configuration을 좁히면 됩니다.

11. Gradle classpath 직접 확인하기

Gradle이 실제로 어떤 의존성을 넣었는지 확인할 수 있습니다.

컴파일 classpath

./gradlew dependencies --configuration compileClasspath

애플리케이션 실행 classpath

./gradlew dependencies --configuration runtimeClasspath

테스트 실행 classpath

./gradlew dependencies --configuration testRuntimeClasspath

특정 의존성이 왜 포함됐는지 확인하려면 dependencyInsight를 사용합니다.

./gradlew dependencyInsight \
  --dependency mysql-connector-j \
  --configuration runtimeClasspath

확인할 때는 다음 질문을 던져보면 됩니다.

MySQL 드라이버가 compileClasspath에는 없는가?
MySQL 드라이버가 runtimeClasspath에는 있는가?
Testcontainers가 운영용 runtimeClasspath에는 없는가?
테스트 의존성이 testRuntimeClasspath에는 포함되어 있는가?
예상하지 못한 전이 의존성이 추가되지는 않았는가?

마무리

Gradle configuration은 의존성을 아무 곳에나 넣는 문법이 아닙니다.

누가, 언제, 어디까지 이 라이브러리를 볼 수 있어야 하는지를 선언하는 규칙입니다.

새로운 의존성을 추가할 때는 다음 순서로 생각하면 됩니다.

1. main 코드가 타입을 직접 사용하는가?
2. 실행에도 필요한가?
3. 실행 환경이 대신 제공하는가?
4. 테스트에서만 사용하는가?
5. 테스트 코드가 직접 타입을 사용하는가?

최종적으로 다음처럼 기억하면 됩니다.

직접 사용 + 실행에도 필요
    → implementation

컴파일에는 필요하지만 실행 환경이 제공
    → compileOnly

직접 사용하지 않지만 실행 중 필요
    → runtimeOnly

테스트 코드에서 직접 사용
    → testImplementation

테스트 실행 순간에만 필요
    → testRuntimeOnly

참고 자료

AWS Network Firewall 쓰면 NAT Gateway가 공짜라고? 근데 비용을 곁들인..

copcat — Wed, 11 Mar 2026 18:11:31 +0900

AWS에서 Private Subnet의 인스턴스가 인터넷에 나가려면 NAT가 필요하고, 트래픽을 검사하려면 방화벽이 필요합니다.

보통은 NAT Gateway와 방화벽을 각각 구성하고 각각 비용을 지불합니다.

그런데 AWS 문서를 보다 보면 이런 문구가 하나 보입니다.

"Network Firewall과 NAT Gateway를 같은 service chain에 두면 NAT Gateway 비용이 면제된다."

"진짜로 NAT Gateway가 공짜?"

그래서 실제 구조와 비용을 조금 더 자세히 파봤습니다.
이번 글에서는 AWS Network Firewall과 NAT Gateway를 함께 사용했을 때 NAT Gateway 비용이 면제되는 구조와 함께, 각 서비스가 어떤 역할을 하는지, 그리고 대체 가능한 옵션은 무엇인지 정리해보겠습니다.

잠깐, NAT Gateway와 NAT Instance는 다릅니다

본론에 들어가기 전에 헷갈리기 쉬운 부분부터 정리하고 가겠습니다.

구분	NAT Gateway	NAT Instance
관리	AWS 완전관리형	직접 EC2 관리 (패치, 모니터링)
고가용성	AZ 내 자동 이중화	직접 구성 필요 (ASG 등)
대역폭	최대 100 Gbps 자동 확장	인스턴스 타입에 따라 제한
비용	$0.059/시간 + $0.059/GB (서울)	EC2 인스턴스 비용 (예: t3.micro $0.0104/시간)
Network Firewall 할인	✅ 적용됨	❌ 적용 안 됨

NAT Instance는 비용이 저렴하다는 장점이 있어 작은 서비스나 테스트 환경에서는 많이 사용됩니다.

하지만 이번 글에서 이야기하는 NAT Gateway 비용 면제 혜택은 NAT Gateway에만 적용됩니다.

즉, 이미 Network Firewall을 사용하는 환경이라면 NAT Instance 대신 NAT Gateway를 쓰는 것이 오히려 더 유리할 수도 있습니다.

각 서비스는 왜 쓸까?

AWS Network Firewall

AWS Network Firewall은 VPC 레벨에서 동작하는 관리형 방화벽 서비스입니다.

대표적인 기능은 다음과 같습니다.

L3~L4 중심 + 제한적인 L7 검사 (IP, 포트, 도메인, 콘텐츠 기반 필터링)
Suricata 기반 IPS / IDS 룰 지원
TLS 복호화 검사 (Advanced Inspection)
악성 도메인 및 IP 차단

한마디로 정리하면,

"이 VPC에서 나가는 트래픽 중 위험한 건 막겠다."

라는 목적의 서비스입니다.

NAT Gateway

NAT Gateway는 Private Subnet의 리소스가 인터넷과 통신할 수 있도록 해주는 서비스입니다.

대표적인 사용 사례는 다음과 같습니다.

EC2에서 외부 API 호출
패키지 다운로드 (apt, yum, npm 등)
외부 서비스와 통신

하지만 외부에서 내부로 직접 접근하는 것은 막습니다.

즉,

"인터넷은 나가게 하되, 들어오는 건 막겠다."

라는 역할을 합니다.

둘 다 쓰면 뭐가 좋은데? — NAT Gateway 비용 면제

여기가 이 글의 핵심입니다.

AWS 공식 문서에는 다음과 같이 명시되어 있습니다.

"If you create a NAT gateway and place it next to your AWS Network Firewall in a service chain within your AWS account, standard NAT gateway per-hour and data processing usage charges are waived."

— AWS Network Firewall Pricing

즉, Network Firewall과 NAT Gateway를 같은 네트워크 경로에 배치하면 NAT Gateway 비용이 자동 면제됩니다.

항목	원래 비용 (서울 리전)	Network Firewall과 함께 사용 시
NAT Gateway 시간당	$0.059/시간	$0 (면제)
NAT Gateway 데이터 처리	$0.059/GB	$0 (면제)

면제 조건

다음 조건을 충족해야 합니다.

NAT Gateway와 Network Firewall이 같은 리전
NAT Gateway가 Network Firewall endpoint와 같은 네트워크 경로
1:1 기준 적용

즉,

Firewall Endpoint 시간 = NAT Gateway 시간
Firewall 처리량 = NAT Gateway 처리량 이어야 합니다.

AWS Network Firewall 가격 인하 공지 (2026.02)

실제로 얼마나 아끼는 건데? — 서울 리전 기준 계산

시나리오

2개 AZ 배포
월 5TB 아웃바운드 트래픽

Network Firewall + NAT Gateway (할인 미적용)

항목	계산	월 비용
Network Firewall 엔드포인트	$0.395 × 2 AZ × 720시간	$568.80
Network Firewall 데이터 처리	$0.065 × 5,000 GB	$325.00
NAT Gateway 시간당	$0.059 × 2 AZ × 720시간	$84.96
NAT Gateway 데이터 처리	$0.059 × 5,000 GB	$295.00
합계		$1,273.76

Network Firewall + NAT Gateway (할인 적용)

항목	계산	월 비용
Network Firewall 엔드포인트	$0.395 × 2 AZ × 720시간	$568.80
Network Firewall 데이터 처리	$0.065 × 5,000 GB	$325.00
NAT Gateway 시간당	~~$84.96~~	$0 (면제)
NAT Gateway 데이터 처리	~~$295.00~~	$0 (면제)
합계		$893.80

즉, 월 $379.96 절감 (약 30% 비용 감소)

트래픽이 많을수록 절감 효과는 더 커집니다.

그럼 NAT Instance는 언제 쓰는 게 맞아?

NAT Gateway가 무료가 되는 것은 이미 Network Firewall을 사용하고 있을 때 이야기입니다.

Network Firewall을 사용하지 않는 환경에서는 NAT Gateway 비용이 그대로 발생합니다.

그래서 상황에 따라 NAT Instance를 선택하기도 합니다.

상황	추천
Network Firewall 사용 중	NAT Gateway
Network Firewall 미사용 + 트래픽 적음	NAT Instance
Network Firewall 미사용 + 트래픽 많음	NAT Gateway
개발 / 테스트 환경	NAT Instance

특히 작은 프로젝트에서는 NAT Gateway 비용이 생각보다 부담이 될 수 있습니다.

Network Firewall 안 쓰면 뭘로 대체해?

Network Firewall은 강력한 서비스지만 모든 환경에서 반드시 필요한 것은 아닙니다.

대안	보호 수준	비용	특징
Security Group + NACL	L3/L4	무료	기본 방화벽
AWS WAF	L7	요청 기반 과금	웹 트래픽 보호
VPC Endpoint	-	무료	NAT 우회 가능
3rd Party Firewall	L3~L7	라이선스 + EC2	Fortinet / Palo Alto

실전 팁

S3, DynamoDB 같은 AWS 서비스 접근은 Gateway VPC Endpoint를 사용하면 NAT Gateway를 아예 거치지 않습니다.

NAT 비용 없음
Network Firewall 여부와 무관

이라서 항상 추천하는 구성입니다.

NAT Gateway 안 쓰면 뭘로 대체해?

대안	비용	장단점
NAT Instance	약 $7.49/월	약 $7.49/월
VPC Endpoint (Gateway)	무료	S3, DynamoDB 전용
VPC Endpoint (Interface)	시간 + GB 과금	특정 AWS 서비스 전용

결론

정리하면 다음과 같습니다.

Network Firewall + NAT Gateway 사용 시 NAT Gateway 비용 전액 면제
이 혜택은 NAT Gateway만 해당
Network Firewall을 이미 사용한다면 NAT Gateway가 사실상 무료
Network Firewall이 없다면 NAT Instance도 여전히 유효한 선택

Network Firewall을 쓰고 있다면 NAT Gateway는 고민할 필요가 없다.

관리형 서비스이기 때문에 운영 부담도 줄어들고, 고가용성 구성도 따로 고민할 필요가 없습니다.

감사합니다.

참고 링크
AWS Network Firewall Pricing
https://aws.amazon.com/network-firewall/pricing/
NAT Gateway vs NAT Instance 비교 - AWS 공식문서
https://aws.amazon.com/vpc/pricing/
Network Firewall 아키텍처 가이드 (IGW + NAT GW)
https://repost.aws/knowledge-center/network-firewall-set-up-with-nat-gateway
AWS 공식 블로그 - Network Firewall 배포 모델
https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/
AWS re:Post - Network Firewall + NAT Gateway 설정 가이드
https://docs.aws.amazon.com/network-firewall/latest/developerguide/arch-igw-ngw.html
Amazon VPC Pricing (NAT Gateway)
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
AWS Network Firewall 가격 인하 공지 (2026.02)
https://aws.amazon.com/about-aws/whats-new/2026/02/aws-network-firewall-new-price-reduction/

초기 세팅시 스프링부트 메인을 실행했는데 꺼지는 이유

copcat — Thu, 10 Apr 2025 16:47:31 +0900

스프링부트(Spring Boot) 프로젝트를 새로 세팅하고, Application 클래스를 실행해보면 8080 포트에서 서버가 실행되기를 기대하게 됩니다. 별다른 에러 없이 애플리케이션이 곧바로 종료되는 경험을 한 적이 있으신가요?

이번 글에서는 Spring Boot가 자동으로 종료되는 이유와 톰캣(Tomcat) 서버가 JVM을 유지시키는 메커니즘, 그리고 Non-Daemon Thread의 역할에 대해 간단하게 정리해보겠습니다.

1. Spring Boot 애플리케이션이 곧바로 종료되는 이유는?

Spring Boot는 실행 시 프로젝트에 포함된 의존성 등을 바탕으로 애플리케이션이 Web 환경인지, Non-Web 환경인지 자동으로 판단합니다.

예를 들어 다음과 같은 경우에는 Spring Boot는 Web 환경이 아니라고 판단합니다

spring-boot-starter-web 또는 spring-boot-starter-webflux가 포함되어 있지 않음
유지되어야 할 백그라운드 서비스가 없음

하지만 중요한 포인트는 이것입니다

Spring Boot 애플리케이션이 종료되는 직접적인 원인은 Web 환경이 아님이 아니라, JVM 내에 Non-Daemon Thread가 존재하지 않기 때문입니다.

즉, Web 여부가 아닌 Thread의 상태가 애플리케이션 생존을 결정합니다.

2. JVM과 Non-Daemon Thread란?

JVM(Java Virtual Machine)은 내부에 실행 중인 모든 Non-Daemon Thread가 종료되었을 때, 전체 애플리케이션을 종료시킵니다.

Daemon Thread: 백그라운드에서 동작, JVM이 자동 종료되어도 함께 종료됨 (예: GC, Timer)
Non-Daemon Thread: 주요 작업을 수행, 하나라도 살아있으면 JVM은 종료되지 않음

즉, 스프링부트 애플리케이션이 자동 종료되었다는 것은 Non-Daemon Thread가 존재하지 않았다는 의미입니다.

3. 톰캣이 JVM을 종료되지 않게 막는 방식은?

Spring Boot는 spring-boot-starter-web 의존성을 통해 톰캣(Tomcat) 웹서버를 내장합니다.

톰캣은 내부적으로 Non-Daemon Thread, 특히 main thread 역할을 하는 ‘Acceptor’, ‘Poller’, ‘Executor’ 등을 통해 HTTP 요청을 수신하고 처리합니다.

이러한 쓰레드가 동작함으로써 JVM이 종료되지 않으며, SpringApplication.run(…) 이후에도 애플리케이션이 계속 살아있는 이유가 됩니다.

4. 예제로 보는 Non-Daemon Thread

톰캣을 포함하지 않은 순수 Spring Boot 프로젝트에서는 다음과 같이 Non-Daemon Thread를 명시적으로 생성하면 JVM을 종료시키지 않을 수 있습니다:

public class NonDaemonThreadTest {
    public static void main(String[] args) {
        Thread thread = new Thread(() -> {
            try {
                Thread.sleep(100000); // 100초 동안 대기
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        thread.setDaemon(false); // 명시적으로 Non-Daemon 설정
        thread.start();
    }
}

위 코드는 메인 메서드가 종료된 이후에도 Non-Daemon Thread가 살아 있으므로, JVM은 종료되지 않습니다.

5. 결론 및 요약

Spring Boot 애플리케이션이 자동 종료되는 이유는 Non-Daemon Thread가 없기 때문입니다.
톰캣은 Non-Daemon Thread를 실행하여 JVM이 종료되지 않도록 합니다.
Web 서버가 포함되지 않은 프로젝트에서는 JVM이 실행과 동시에 종료될 수 있습니다.
JVM의 종료 조건을 이해하면, 백그라운드 작업 처리나 커스텀 런타임 애플리케이션 설계에 도움이 됩니다.

[AI] Ollama 찍먹해보기

copcat — Thu, 22 Aug 2024 23:50:20 +0900

Ollama가 무엇인가요?

요즈음 ChatGPT, Calude 등 대형 LLM이 주목받고 있습니다. 하지만 비용이 만만치 않습니다. 내 PC에서 이런 LLM을 사용하려면 클라우드를 사용하거나 앞서 설명한 대형 LLM을 구독하여 사용해야 합니다. 이러한 문제를 해결해주는 오픈소스 프로젝트가 바로 Ollama 입니다.

Ollama는 오픈소스 LLM을 로컬 PC에서 쉽게 실행할 수 있게 해주는 도구입니다.

Mistral, Llama 3 등 다양한 오픈소스 LLM을 지원하죠. 모델 가중치, 설정, 데이터셋을 하나의 패키지로 묶어서 Modelfile로 관리합니다.

https://ollama.com/

Ollama

Get up and running with large language models.

ollama.com

macOS

다운로드 페이지(Ollama)에서 macOS용 파일을 다운로드 합니다.
다운로드한 zip 파일의 압축을 풉니다.
터미널을 열고 압축 해제한 폴더로 이동합니다.
./ollama 명령어로 실행합니다.

혹은 brew를 사용합니다!

brew install ollama

https://formulae.brew.sh/formula/ollama

ollama

Homebrew’s package index

formulae.brew.sh

모델 선택하기

ollama 에서 지원하는 모델을 그냥 사용할 수 있지만 저는 한국어 모델이 필요했습니다. 이유는 재미용!!

한국어 모델은 "야놀자" 에서 만든 모델이 있습니다. 기본 모델인 EEVE-Korean-10.8B의 파인 튜닝된 버전입니다.

이 모델에 대해서 간단히 소개해드리겠습니다.

이 모델은 upstage/SOLAR-10.7B 모델을 기반으로 한국어 처리에 최적화된 확장된 어휘를 사용하여 개선되었습니다.

또한, EEVE-Korean 모델은 108억 개의 파라미터를 가지고 있으며, 이는 GPT-3(1,750억 개)보다 적기 때문에 감안하여 사용하시면 됩니다.

로컬 AI 만들어서 사용해보는 것이 목적이기 때문에 이 모델을 활용해봅니다.

https://huggingface.co/yanolja/EEVE-Korean-Instruct-10.8B-v1.0#about-the-model

yanolja/EEVE-Korean-Instruct-10.8B-v1.0 · Hugging Face

EEVE-Korean-Instruct-10.8B-v1.0 Join Our Community on Discord! If you're passionate about the field of Large Language Models and wish to exchange knowledge and insights, we warmly invite you to join our Discord server. It's worth noting that Korean is the

huggingface.co

Hugging Face CLI를 통해 Hugging Face Hub에 있는 모델을 쉽게 다운로드하고 관리할 수 있습니다.

brew install huggingface-cli

모델 다운로드받기

huggingface-cli download heegyu/EEVE-Korean-Instruct-10.8B-v1.0-GGUF ggml-model-Q5_K_M.gguf --local-dir /Users/jiwoo/Downloads/ai --local-dir-use-symlinks False

이 명령어는 다음과 같은 의미를 가집니다:

huggingface-cli: Hugging Face의 명령줄 인터페이스(CLI)를 사용합니다. Hugging Face는 주로 자연어 처리 모델을 제공하는 플랫폼입니다.
download heegyu/EEVE-Korean-Instruct-10.8B-v1.0-GGUF: ‘heegyu’ 사용자가 제공하는 ‘EEVE-Korean-Instruct-10.8B-v1.0-GGUF’라는 모델을 다운로드합니다.
ggml-model-Q5_K_M.gguf: 다운로드한 모델을 ‘ggml-model-Q5_K_M.gguf’라는 파일 이름으로 저장합니다.
–local-dir /Users/jiwoo/Downloads/ai: 모델 파일을 로컬 디렉토리 ‘/Users/jiwoo/Downloads/ai’에 저장합니다.
–local-dir-use-symlinks False: 심볼릭 링크를 사용하지 않고 실제 파일을 사용하여 저장합니다. 심볼릭 링크는 파일 시스템 내에서 다른 파일이나 디렉토리에 대한 참조를 만드는 것입니다.

프롬프트 템플릿 작성

한국어 모델 설치가 완료되었다면 다음 순서로는 모델파일을 만들어서 Ollama에게 적용시켜보는 단계입니다.

# 파일이름 Modelfile

FROM ggml-model-Q5_K_M.gguf

TEMPLATE """{{- if .System }}
<s>{{ .System }}</s>
{{- end }}
<s>Human:
{{ .Prompt }}</s>
<s>Assistant:
"""

SYSTEM """A chat between a curious user and an artificial intelligence assistant. The assistant gives helpful, detailed, and polite answers to the user's questions."""

PARAMETER stop <s>
PARAMETER stop </s>

위 코드에서 SYSTEM은 원하는 프롬프트(글쓴이의 배경이라든지 원하는 조건)를 넣으면 됩니다.

ollama create EEVE-Korean-10.8B -f Modelfile

# 모델 확인하기
ollama list

# ollama 실행하기
ollama run EEVE-Korean-10.8B:latest

이 명령어는 “Ollama”라는 툴을 사용하여 “EEVE-Korean-10.8B”라는 이름의 한국어 모델을 “Modelfile”이라는 파일을 기반으로 생성하는 작업을 실행하라는 의미입니다.

작업 과정

모델파일 적용시키는 모습

이미지 확인 및 실행

프롬프트 작업 진행

메모리

메모리는 최대 약 2GB 정도 잡히는 것을 확인해볼 수 있습니다.

메소드 파라미터마다 Final 하는 이유

copcat — Sat, 21 Oct 2023 21:37:53 +0900

개발하면서 깃허브 코드를 참고하다보니 가끔씩 함수의 파라미터에 final 키워드가 들어가는 것을 확인했습니다.

왜 사용하는지? 사용하면 어떤 이점이 있는지 알아보겠습니다.

Final은 변경불가능하다는 키워드 입니다.

그렇다면 메소드 파라미터에 사용하는 것은 해당 파라미터가 변경불가능하다는 뜻인데, 어떤 이점이 있을까요?

장점

재할당되서 발생할 수 있는 문제는 컴파일 타임에 바로 잡아 줄 수 있습니다.
- 변수의 상태 변화를 추적할 필요가 없으므로 코드가 더 쉽게 읽힙니다.
불변성 강조: final 키워드가 붙은 파라미터는 메소드 내에서 수정할 수 없습니다. 이는 코드를 읽는 사람에게 해당 변수가 변경되지 않을 것임을 명확하게 알려줍니다.

그렇다면 Final이 불변성을 의미하는 것일까요?

->아닙니다.

찾아보니, Final 키워드가 변수에 적용될 때, 그 변수는 재할당을 할 수 없는건 맞지만, 해당 객체의 불변성을 의미하는 것이 아닙니다.

1. 재할당 금지

final String str = "hello";
str = "world";  // 컴파일 에러

2. 객체 상태 변경 가능

final List<String> list = new ArrayList<>();
list.add("hello");  // 가능
list.add("world");  // 가능

final: 변수가 한 번 초기화된 후에는 다른 값으로 재할당할 수 없습니다.
불변성: 객체의 상태가 생성 후에 변경되지 않습니다.

따라서 final은 변수 재할당을 금지할 뿐, 객체의 불변성을 보장하지는 않습니다.

EC2 AMI 와 Snapshot 의 차이,, 근데 비용을 곁들인..

copcat — Sat, 5 Aug 2023 11:30:18 +0900

AWS EC2를 사용하다보면 백업을 하기위해서 이미지(AMI)를 생성하거나, Snapshot을 사용하기도 합니다.

이 포스팅에서는 EC2 AMI 와 Snapshot 의 차이와 비용발생에 대해 간단하게 알아보겠습니다.

AMI 이미지 생성방식과 EBS 생성방식의 차이

AMI 이미지 생성방식은 EC2 인스턴스의 전체 백업(인스턴스와 + 저장소) 을 생성하는 것이고,

이미지를 복원할 때는 새로운 인스턴스와 EBS 볼륨이 생성되어 복원됩니다.

EBS 스냅샷 생성방식은 EBS볼륨을 백업하는 방식입니다.

스냅샷은 생성하는 시점 그대로 저장이 됩니다. EBS만 백업하는 것입니다.

그래서 복원할 때는 새로운 인스턴스가 생성되지 않습니다.

서울리전(ap-northeast-2)기준으로 비용에서는 어떤 차이가 있을까요?

AMI과 EBS 스냅샷 비용에 대해서 각각 알아보겠습니다.

AMI 비용

EC2 인스턴스를 기반으로 AMI를 생성하는 데는 비용이 들지 않습니다.

즉, AMI 생성 자체에는 비용이 청구되지 않습니다.

다만, AMI 생성 중에 소비한 리소스 비용(예: EC2 인스턴스 사용 시간, EBS 스토리지 비용)과 EBS 스냅샷 비용은 고려해야 합니다.

EBS 스냅샷 비용

EBS Snapshots 스토리지 요금
스탠더드	0.05 USD/월별 GB당
아카이브	0.0125 USD/월별 GB당
EBS Snapshots 복원 요금
스탠더드	무료
아카이브	검색된 데이터 GB당 0.03 USD
빠른 Snapshots 복원 요금	해당 기능이 활성화된 각 스냅샷 및 각 AZ에서 1 DSU 시간당 0.86 USD

요금은 스토리지 티어에 따라 다릅니다.

스탠다드 티어의 경우 저장된 후 변경된 블록에 대해서만 요금이 청구됩니다.

아카이브 티어의 경우 저장된 모든 스냅샷 블록에 대해 요금이 청구됩니다. 아카이브 티어에서 스냅샷을 검색하는 비용도 청구됩니다.

다음은 각 스토리지 티어에 대한 예제 시나리오입니다.

스탠다드 티어: 100GB의 데이터를 저장하는 볼륨이 있습니다. 첫 번째 스냅샷(스냅 A)의 경우, 전체 데이터 100GB에 대한 요금이 청구됩니다. 다음 스냅샷(스냅 B)에서는 105GB의 데이터가 있습니다. 그러면 증분 스냅 B에 대한 추가 5GB 스토리지에 대해서만 요금이 청구됩니다. <AWS EBS 증분 스냅샷 작동 방식>

EBS Snapshots 스토리지 요금 계산
- 주요 스냅샷 요금 : $0.05 /월별 GB 당, 100GB x 0.05 = $5
- 추가 스냅샷 요금 : 5 GB x $0.05 = $0.25
- 합계 : $5 + $0.25 = $5.25
아카이브 티어: 스냅 B를 아카이빙합니다. 그런 다음 스냅샷이 아카이브 티어로 이동되고 전체 105GB 스냅샷 블록에 대한 요금이 청구됩니다.

참고 링크

https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/backup-recovery/ec2-backup.html

[Spring] 프록시 객체를 이용하는 이유

copcat — Mon, 29 May 2023 19:52:56 +0900

프록시 객체는 실제 객체를 대신하여 요청을 처리하는 객체입니다.

실제 객체와 같은 인터페이스를 구현하여 실제 객체를 대신하여 요청을 처리할 수 있습니다. 프록시 객체는 실제 객체를 보호하거나, 실제 객체의 기능을 확장하거나, 실제 객체의 로직을 변경하는 데 사용할 수 있습니다.

프록시 객체를 사용하는 이유

프록시 객체를 사용하는 이유는 다음과 같습니다.

실제 객체 보호
- 프록시 객체는 실제 객체를 대신하여 요청을 처리할 수 있습니다. 따라서 실제 객체가 직접 요청을 받지 않으므로 실제 객체를 보호할 수 있습니다.
실제 객체의 기능 확장
- 프록시 객체는 실제 객체의 기능을 확장할 수 있습니다.
- 예를 들어, 프록시 객체는 실제 객체의 요청을 기록하거나, 실제 객체의 요청을 캐싱할 수 있습니다.
실제 객체의 로직 변경
- 프록시 객체는 실제 객체의 로직을 변경할 수 있습니다.
- 예를 들어, 프록시 객체는 실제 객체의 요청을 필터링하거나, 실제 객체의 요청을 변환할 수 있습니다.

CGLIB 프록시 VS JDK 프록시

Spring 프록시는 CGLIB 프록시와 JDK 프록시 두 가지 유형의 프록시 객체를 제공합니다.

간단하게 알아보자면,

JDK Dynamic Proxy는 인터페이스를 기반으로 프록시를 생성합니다. 따라서 프록시를 생성하려면 타겟 객체가 인터페이스를 구현해야 합니다. JDK Dynamic Proxy는 타겟 객체가 인터페이스를 구현하지 않은 경우에는 사용할 수 없습니다.
CGLIB Proxy는 타겟 객체의 바이트 코드를 조작하여 프록시를 생성합니다. 따라서 타겟 객체가 인터페이스를 구현하지 않아도 사용할 수 있습니다. CGLIB Proxy는 JDK Dynamic Proxy보다 성능이 좋습니다.

Spring Boot 2.3 버전부터는 CGLIB 라이브러리가 Spring Core 패키지에 기본적으로 포함되어있기 때문에 따로 의존성을 추가하지 않아도 됩니다.

도커

copcat — Sat, 6 May 2023 17:36:59 +0900

Docker란?

도커는 컨테이너 기술을 기반하여 만든 오픈소스 가상화 플랫폼입니다. (도커 ≠ 컨테이너)

컨테이너?

사전적 의미

화물을 담아 나르기 위해 주로 쓰는, 쇠로 만들어진 큰 상자.

기술적 의미

이미지 목적에 따라 생성되는 프로세스 단위의 독립 환경입니다.
환경을 제공하며 프로세스의 생명주기를 관리합니다.

왜 컨테이너를 사용할까요?

HOST와 격리를 통하여 독립된 개발환경을 보장하기 위해 사용합니다.

컨테이너의 역사

FreeBSD Jail

오픈소스 Unix인 FreeBSD의 기술입니다.

특징

프로세스의 구획화
네트워크의 구힉화
파일 시스템의 구획화

(구획이란? 경계를 갈라 정하는 것 또는 그 구역)

Solaris Containers

Oracle의 상용 Unix인 Solaris 의 기술입니다.

특징

Solaris 존 기능
Solaris 리소스 매니저 기능

Linux Containers (LXC)
Linux 커널의 컨테이너 기능을 이용하기 위한 툴이나 API를 제공합니다.

가상화??

하나의 물리적 서버 호스트에서 여러개의 서버 호스트를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍쳐

이런 서버 가상화를 구현해주는 기술이 바로 Hypervisor 이라고 합니다.

하이퍼바이저는 하나의 호스트 OS 위에 여러 개의 게스트 OS를 사용할 수 있게 도와주고 또한 이렇게 생성된 게스트OS는 각각 가상머신이라는 단위로 구별됩니다.

하이퍼바이저는 게스트 운영체제를 실행하고 관리할 수 있게끔 돕는 역할과 호스트 머신들이 자원들을 VM들에게 분배할 수 있도록 도와주는 역할을 합니다.

위 그림을 보면 하이퍼바이저와 컨테이너의 방식은 유사해보이지만 큰 차이는 아래와 같습니다.

VM 은 호스트 os 위에 게스트 os 가 구동되기 때문에 이미지로 만들 때 무겁고 가상화 작업에서는 무조건 하이퍼바이저를 거쳐야합니다.

컨테이너는 애플리케이션을 구동하는 데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 가볍고 이식성이 좋습니다.

다시 강조하지만 컨테이너 ≠ 도커는 아닙니다.

도커의 기능

이미지를 만듬 (Build)
이미지를 공유 (Ship)
컨테이너를 작동 (Run)

이미지를 만드는 기능 - Build

애플리케이션의 실행에 필요한 프로그램 본체, 라이브러리, 미들웨어 , OS나 네트워크 설정 등을 하나로 모아서 이미지로 만듭니다.

즉, 실행환경에서 움직이는 컨테이너의 바탕이 됩니다.

도커에서는 하나의 이미지 - 하나의 애플리케이션 만 넣어두는 것을 권장합니다.

이미지는 겹쳐서 사용할 수 있기 때문에 OS 용 이미지에 웹 애플리케이션용 이미지를 겹쳐 다른 새로운 이미지 또한 만들 수 있습니다. ( 변경한 부분(이미지 레이어) 차분으로 관리합니다)

이미지를 공유하는 기능 - Ship

이미지는 Docker 레지스트리(ex. docker hub) 에서 공유할 수 있습니다.

깃허브와 연계하여 dockerfile을 관리하고 자동으로 docker 이미지를 생성하여 hub 에 공개하는 것도 가능합니다.

컨테이너를 작동시키는 기능 - Run

Linux 상세어 컨테이너 단위로 서버 기능을 작동시킵니다.

vm 같은 경우 서버 기능을 실행시키려면 os 의 실행 부터 해야하기 때문에 오래 걸리지만

도커는 이미 동작되는 os 상에서 프로세스를 실행시키는 것과 같은 속도로 빨리 실행 시킬 수 있습니다.

하나의 Linux 커널을 여러 개의 컨테이너에서 공유하고 있습니다.

Linux 커널 기능 기술 (namespace, cgroups 등) 을 사용하여 컨테이너를 독립된 공간으로서 관리할 수 있습니다.

Docker 컴포넌트

Docker Engine

도커의 이미지를 생성하고 컨테이너를 가동시키기 위한 핵심 기능입니다.

Dokcer Registry

도커 이미지를 공개 및 공유하기 위한 레지스트리 기능입니다.

실제 도커 공식 레지스트리 서비스인 도커 허브도 이 도커 레지스트리를 사용하고 있습니다.

Docker Compose

여러 개의 컨테이너로부터 이루어진 서비스를 구축, 실행하는 순서를 자동으로 하여, 관리를 간단히하는 기능입니다.

Docker Machine

더이상 지원되지 않습니다. https://docs.docker.com/machine/

Docker Swarm

여러 도커 호스트를 클러스터화 하기 위한 툴입니다. → 쿠버네티스와 비슷

도커의 작동 구조

도커는 Linux 커널의 기술이 베이스로 되어 있습니다.

컨테이너를 구획화하는 장치 (namespace)

도커가 컨테이너라는 독립된 환경을 만들고 그 컨테이너를 구획화하여 어플리케이션의 실행 환경을 만들 수 있도록 하게끔 해준 기술입니다.

개념

한 덩어리의 데이터를 이름을 붙여 분할함으로써 충돌 가능성을 줄이고, 쉽게 참조할 수 있게 함

독립된 환경

PID
Network
UID
MOUNT
UTS
IPC

릴리스 관리 장치 (cgroups)

도커가 물리 머신의 자원을 여러 컨테이너가 공유하여 작동할 수 있게 하게끔 해준 기술입니다.

→ 예를 들면, 어떤 컨테이너가 호스트 os 의 자원을 모두 사용해 다른 컨테이너의 영향을 주는 일을 막아줌.

cgroups의 부모자식 관계에서는 자식이 부모의 제한을 물려받습니다.

네트워크 구성

서버의 물리 NIC가 docker0 이라는 가상 브리지 네트워크로 연결됩니다. (docker0 은 기본 값입니다)

도커 컨테이너와 외부 네트워크가 통신을 할 때는 가상 브리지 docker0 과 호스트 os 의 물리적 NIC에서 패킷을 전송하는 장치가 필요합니다. → NAPT 기능 사용

도커 이미지의 데이터 관리 장치

데이터를 복사하고 변경이 없다면 그 복사는 쓸데 없이 점점 공간 낭비가 발생하는 문제가 있습니다.

하지만 도커는 복사를 요구받아도 바로 복사하지 않고 원래 데이터를 그대로 참조시켜, 원본 또는 복사 어느 쪽에 수정이 가해진 시점에 비로소 새로운 빈 영역을 확보하고 데이터를 확보합니다.

→ Copy on Write 라고 부릅니다.

위 방식으로 도커는 컨테이너의 이미지를 관리합니다.

이미지를 관리하는 스토리지 디바이스

AUFS
Btrfs → 롤백, 스냅샷 기능
Device Mapper
OverlayFS

궁금했던 것들

왜 하필 도커?

주관적인 생각
1. 편리성
2. 클라우드와 친화적
3. 거대한 커뮤니티
4. 이식성
5. 등등..
  
  많은 장점들로 하여금 사용하지 않았을까요?

Linux 커널 기능 - namespace, cgroups ?

구글링

커널 →컴퓨터 자원을 관리

namespace ?

→ 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능

쉽게 말해 한 덩어리 데이터를 네이밍하여 서로 충돌을 방지하고 쉽게 참조할 수 있게 해주는 기능입니다.

cgroups ?

→ 프로세스들이 사용할 수 있는 컴퓨터 자원을 제한하고 격리시켜주는 기능

제한 가능한 자원리스트
- 메모리
- CPU
- 네트워크
- 장치
- I/O

AWS S3 URL 다운로드 제한을 IP로 할 수 있을까?

copcat — Sun, 26 Mar 2023 22:35:11 +0900

문득 S3 미리 정의된 URL로 다운로드하거나 액세스하는 것을 퍼블릭하게 노출시키지 않는 방법이 뭐가 있을까?고민하다가 IP기반으로 액세스를 허용하고 제한할 수 있을까 하고 간단하게 테스트해본 내용입니다.

테스트를 위해 버킷과 객체를 준비해줍니다.

1. 버킷 생성

2. 객체를 선택하고 미리 서명된 URL 과 공유를 선택합니다.

S3 버킷 정책에 내 IP 만 접근할 수 있도록 버킷정책을 꾸려보자

테스트는 내 현재 IP와 VPN 사용해서 다른 IP를 획득하여 액세스가 가능한지 여부에 대해 확인해볼 예정이다.

3. S3 버킷 정책 설정 - IP

내 IP 주소

S3 버킷 정책

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowIPs",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::testforjiwoo/*",    # <<< your S3 Bucket
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "210.95.62.154"   # <<< your IP
                    ]
                }
            }
        }
    ]
}

해당 버킷 정책을 저장하고 미리 정의된 URL로 접근해보자

4. TEST

버킷정책에 설정한 IP 로 URL 접근 시 모습

잘 접근되는 모습

써드파티의 툴 VPN을 사용해서 IP를 변환시켜 접근시도해본다.

변환된 내 IP

변환된 IP로 URL 접근 시 모습

접근 실패되는 모습

그 외 다른 방법으로 안전하게 S3 액세스하는 방법들이 있다.

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-3

참고

https://repost.aws/ko/knowledge-center/block-s3-traffic-vpc-ip

AWS Lambda로 RDS 와 외부 인터넷 접근하기

copcat — Fri, 24 Feb 2023 23:17:53 +0900

API를 통해 데이터를 가져와 AWS RDS 적재하는 역할의 Lambda를 사용하면서 겪은 삽질기(경험 부족)입니다.

제가 만든 Lambda 는 위의 캡쳐 사진처럼 간단합니다. 또한 다음과 같은 역할을 수행하고자 합니다.

외부 인터넷을 통해 API를 호출하여 데이터를 가져온다.
AWS RDS에 접근하여 데이터를 적재한다.

이 Lambda 에는 1) 외부 인터넷을 접속할 수 있는 인터넷 게이트웨이가 필요하며, 2) RDS과 같은 AWS 리소스를 사용하기 위해선 해당 VPC 망에 존재해야합니다.

Lambda 의 VPC 활성화 옵션을 통해 RDS 와 같은 VPC 로 지정하였고, 서브넷 또한 퍼블릭 서브넷으로 지정하였습니다.

람다는 기본적으로 인터넷과 통신이 되기 때문에 당연히 될거라 배제하고 진행했었습니다.

하지만 API 를 호출하는 데 있어 NetworkConnection Error 가 반복되면서 인터넷 접속이 불가능하다고 오류를 마구 뱉습니다.

공식문서 에서는 인터넷의 사용이 필요한 경우 해당 Lambda가 이용하는 VPC의 서브넷에 NAT 나 NAT 인스턴스를 할당해야한다고 합니다. 따라서 저는 NAT Gateway와 람다의 고가용성을 위해서 가용영역이 다른 서브넷 2개를 만들었습니다.

NAT Gateway의 경우는 인터넷 게이트웨이가 있는 퍼블릭 서브넷에 위치시켰고, 앞서 만든 서브넷 2개는 라우팅 테이블을 만들어 연결하고 그 라우팅 테이블 규칙에는 NAT Gateway 를 추가하여 외부 인터넷을 액세스할 수 없었던 문제를 해결하였습니다.

NAT Gateway 의 경우 서울리전 기준-시간당 0.059 USD입니다.

정리

기본적으로 Lambda 함수는 AWS 서비스를 포함하여 인터넷에 액세스할 수 있지만 VPC의 프라이빗 리소스에는 액세스할 수 없습니다.

Lambda를 VPC의 프라이빗 서브넷에 연결하면 VPC의 프라이빗 리소스에 액세스할 수 있지만 인터넷이나 AWS 서비스에는 액세스할 수 없습니다.

모두 원한다면 VPC의 프라이빗 서브넷에 함수를 연결하고 퍼블릭 서브넷에 NAT 게이트웨이를 생성한 다음 트래픽을 GW로 라우팅해야 합니다.

Internet Gateway

인터넷 게이트웨이는 AWS VPC와 인터넷을 연결해주는 논리적인 커넥션
1 VPC에 1 IGW 만 할당할 수 있고 통신 대역폭의 제한은 없음
VPC에 인터넷 게이트웨이가 연결되어 있지 않으면, 외부에서 VPC 내부로 접근 할 수 없음
적어도 1개의 퍼블릭 서브넷이 IGW로 접근하는 것을 라우팅 테이블에서 허용해 줘야 함
라우팅 테이블에서 트래픽이 인터넷 게이트웨이를 향하게 된다면, 퍼블릭 서브넷으로 간주함.