Chadoll

[AI] 제미나이(Gemini) API 키 발급받기

bu119 — Mon, 13 Oct 2025 18:00:58 +0900

AI 기능을 서비스에 적용하려면,

Google의 Gemini API를 통해 자연어 생성, 요약, 번역, 코드 생성 등 다양한 기능을 활용할 수 있습니다.

예를 들어, 음식점 메뉴 설명을 자동으로 만들어주거나, 고객 질문에 대한 자동 답변을 구성하는 등의 서비스가 가능합니다.

이때 Gemini API를 사용하려면 API 키(API Key) 를 발급받아야 합니다.
이 글에서는 제미나이(Gemini) API 키 발급 과정을 정리했습니다.

1️⃣ Gemini API란?

Gemini API는 Google이 제공하는 최신 인공지능 모델 API입니다.
텍스트, 이미지, 코드, 음성 등 다양한 형태의 입력을 이해하고, 결과를 생성할 수 있습니다.

제공 플랫폼: Google AI Studio
활용 예시
- 텍스트 요약 / 문서 생성
- 챗봇 구현
- 이미지 설명 생성
- 코드 자동 생성

2️⃣ Google AI Studio 접속 및 로그인

1. Google AI Studio 홈페이지 접속합니다.

https://ai.google.dev/aistudio?hl=ko

Google AI Studio | Gemini API | Google AI for Developers

Google AI Studio에서 Gemini API를 시작해 보세요.

ai.google.dev

2. Google 계정으로 로그인합니다.

3. 로그인 후 왼쪽 메뉴 하단의 “Get API key” (API 키 받기)를 클릭합니다.

3️⃣ Gemini API 키 발급하기

1. API 키 대시보드의 우측 상단 "API 키 만들기" 버튼을 클릭합니다.

2. 팝업창이 열리면, 키 이름을 지정하고, 프로젝트 선택 또는 새 프로젝트 생성합니다.

우리는 생성된 프로젝트가 없으므로 프로젝트를 생성합니다.

"Create project" 를 클릭합니다.

새 프로젝트 만들기 팝업 창이 열리면, 프로젝트 이름을 지정하고, 우측 하단의 "프로젝트 만들기" 버튼을 클릭합니다.

3. "키 만들기" 버튼을 클릭합니다.

4. 생성 완료 후, API 키 대시보드에 생성된 API 키가 표시됩니다.

5. API 키를 누르면, API 키 세부정보를 알 수 있습니다.

4️⃣ API 키 관리 및 보안

API 키는 비밀번호와 같은 민감 정보입니다.
절대 깃허브나 코드에 직접 노출되면 안 됩니다.

✅ 안전하게 관리하는 방법

구분	방법
로컬 개발 환경	.env 파일에 GEMINI_API_KEY=발급키 저장
Spring Boot (Java)	application-sample.yml에 ${GEMINI_API_KEY} 참조
배포 환경 (AWS 등)	환경 변수(Environment Variable)로 설정
공유 시 주의	협업자는 별도의 키를 발급받는 것을 권장

예시 (Spring Boot)

gemini:
  api-key: ${GEMINI_API_KEY}

5️⃣ Postman 으로 테스트하기

API 키가 정상 작동하는지 테스트해봅시다.

1. Gemini API 공식 문서를 통해 Gemini API 키 사용 방법을 확인합니다.

https://ai.google.dev/gemini-api/docs/api-key?hl=ko

Gemini API 키 사용 | Google AI for Developers

Gemini API 키를 가져와 5분 이내에 빌드를 시작하세요.

ai.google.dev

2. 다음은 Gemini API 공식 문서의 "API 키를 명시적으로 제공하는 방법의 예"입니다.

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent" \
  -H 'Content-Type: application/json' \
  -H "x-goog-api-key: YOUR_API_KEY" \
  -X POST \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Explain how AI works in a few words"
          }
        ]
      }
    ]
  }'

3. Postman을 활용하여 테스트하겠습니다.

요청

응답

정리하며

이제 Gemini API 키 발급이 완료되었습니다.
이 키를 이용하면 여러분의 서비스에서 Google의 AI를 자유롭게 활용할 수 있습니다.

참고 링크

[JPA] 영속성 컨텍스트의 기능

bu119 — Thu, 25 Sep 2025 18:20:11 +0900

TIL (Today I Learned) — 2025.09.25. 목요일
✍️ 내일배움캠프에서 Spring 학습 중 정리한 내용입니다.

왜 알아야 할까?

JPA의 핵심은 영속성 컨텍스트(Persistence Context) 입니다.

영속성 컨텍스트는 단순히 엔티티를 보관하는 공간이 아니라,

조회 최적화 (캐시 제공)
동일성 보장
SQL 실행 시점 제어 (쓰기 지연)
변경 자동 감지 (Dirty Checking)

와 같은 기능을 통해 개발자가 SQL을 직접 관리하지 않아도 안정적이고 효율적인 데이터 처리를 가능하게 합니다.
즉, 성능 최적화와 개발 생산성을 동시에 돕는 핵심 메커니즘입니다.

이번 글에서는 영속성 컨텍스트가 제공하는 주요 기능을 살펴보겠습니다.

1. 1차 캐시 (First-Level Cache)

영속성 컨텍스트는 내부적으로 Map<Id, Entity> 형태의 1차 캐시를 가집니다.

Key: @Id 로 매핑된 식별자 값
Value: 엔티티 객체

동작 방식

em.persist(entity); // 엔티티 → 1차 캐시에 저장
em.find(Entity.class, id); // 캐시에 있으면 DB 조회 없이 반환

예시:

Memo memo1 = em.find(Memo.class, 1L); // 캐시에 없으면 DB 조회 후 캐시에 저장
Memo memo2 = em.find(Memo.class, 1L); // 캐시에 있으므로 DB 조회 없음

System.out.println(memo1 == memo2); // true (동일 객체 보장)

같은 데이터를 반복 조회할 때 DB 부하를 줄이고, 항상 같은 객체를 반환하여 객체 동일성을 보장합니다.

2. 엔티티 저장과 조회

저장

Memo memo = new Memo();
memo.setId(1L);
memo.setUsername("Robbie");
memo.setContents("1차 캐시 테스트");

em.persist(memo); // 1차 캐시에 저장됨

조회

캐시에 없으면 DB 조회 후 캐시에 저장
캐시에 있으면 DB 조회 생략

Memo memo1 = em.find(Memo.class, 1L); // DB 조회 → 캐시에 저장
Memo memo2 = em.find(Memo.class, 1L); // 캐시에서 바로 조회

3. 엔티티 삭제

엔티티를 삭제할 때도 캐시를 활용합니다.

삭제 대상 엔티티 조회 (캐시에 없으면 DB에서 불러와 저장)
em.remove(entity) 호출 → 엔티티 상태가 DELETED로 변경
트랜잭션 commit 시 DELETE SQL 실행

Memo memo = em.find(Memo.class, 2L); // MANAGED 상태
em.remove(memo);                     // DELETED 상태
tx.commit();                         // DELETE SQL 실행

⚠️ 삭제하려는 엔티티는 반드시 MANAGED 상태여야 합니다.

4. 쓰기 지연 저장소 (Write-Behind)

JPA는 SQL을 곧바로 실행하지 않고, 쓰기 지연 저장소(Action Queue) 에 모아둡니다.

Memo m1 = new Memo(2L, "Robbert", "쓰기 지연 저장소");
em.persist(m1);

Memo m2 = new Memo(3L, "Bob", "SQL 모으기");
em.persist(m2);

// 아직 INSERT SQL 실행되지 않음
tx.commit(); // commit 시점에 INSERT SQL 2개 한 번에 실행

SQL을 모았다가 한 번에 실행함으로써 성능 최적화가 가능합니다.

5. flush()

flush()는 영속성 컨텍스트의 변경 내용을 쓰기 지연 저장소에 쌓인 SQL을 DB에 반영하는 역할을 합니다.

자동 실행 시점
1. 트랜잭션 커밋 직전
2. JPQL 실행 직전 (FlushModeType.AUTO일 경우)
수동 실행
필요하다면 em.flush()를 직접 호출할 수도 있습니다.
(단, 트랜잭션 내부에서만 호출 가능)

Memo memo = new Memo(4L, "Flush", "flush 직접 호출");
em.persist(memo);

em.flush(); // 즉시 INSERT SQL 실행

6. 변경 감지 (Dirty Checking)

JPA에는 em.update() 메서드가 없습니다.

대신 변경 감지(Dirty Checking) 로 UPDATE를 처리합니다.

동작 방식

엔티티를 영속성 컨텍스트에 저장할 때 최초 상태(Snapshot)를 함께 보관
트랜잭션 커밋 시 flush 실행
현재 상태와 스냅샷 비교
변경이 있으면 UPDATE SQL 생성

Memo memo = em.find(Memo.class, 4L); // 최초 상태 스냅샷 저장
memo.setUsername("Update");
memo.setContents("변경 감지 확인");

tx.commit(); // UPDATE SQL 자동 실행

엔티티의 값을 바꾸는 것만으로 SQL이 자동 실행되므로, 개발자가 직접 UPDATE SQL을 작성할 필요가 없습니다.

마무리

영속성 컨텍스트는 단순 저장소가 아니라,

1차 캐시, 동일성 보장, 삭제 관리, 쓰기 지연, flush, 변경 감지

를 통해 SQL 작성 부담을 줄이고 성능까지 최적화합니다.

Spring Boot 환경에서는 @Transactional만 올바르게 선언해도 이 모든 기능이 자동으로 동작하므로, 개발자는 비즈니스 로직에 집중할 수 있습니다.

[JPA] 영속성 컨텍스트란?

bu119 — Wed, 24 Sep 2025 21:45:18 +0900

TIL (Today I Learned) — 2025.09.24. 수요일

✍️ 내일배움캠프에서 Spring 학습 중 정리한 내용입니다.

왜 알아야 할까?

백엔드 개발에서는 항상 자바 객체와 데이터베이스 행(Row) 사이를 오가야 합니다.
매번 SQL을 직접 작성하면 코드가 복잡해지고 유지보수가 어려워집니다.

이 과정을 단순화해 주는 것이 JPA이며, 그 핵심에 영속성 컨텍스트(Persistence Context) 가 있습니다.

영속성 컨텍스트는 엔티티(Entity)를 보관하고 상태를 추적하는 공간입니다.
덕분에,

같은 데이터를 반복 조회해도 DB를 다시 찍지 않고 캐시에서 가져올 수 있고,
엔티티 변경을 자동으로 감지해서 SQL을 만들어주며,
여러 SQL을 모아 효율적으로 한 번에 전송할 수 있습니다.

1. 영속성 컨텍스트란?

한 문장으로 정리하면,

“JPA가 엔티티를 캐싱하고, 변경을 추적하며, DB 반영 시점을 관리하는 작업 공간”입니다.

영속성 컨텍스트 주요 기능

1차 캐시: 동일한 엔티티를 여러 번 조회해도 DB가 아닌 캐시에서 반환합니다.
동일성 보장: 같은 영속성 컨텍스트 내에서는 == 비교가 true입니다.
변경 감지(Dirty Checking): 엔티티의 필드를 바꾸면 커밋 시점에 자동으로 UPDATE SQL이 생성됩니다.
쓰기 지연(Write-Behind): INSERT, UPDATE, DELETE SQL을 모아 두었다가 트랜잭션 커밋 시 한 번에 실행합니다.

2. JPA와 데이터베이스 관계

JPA는 애플리케이션 ↔ 데이터베이스 사이의 중간 계층 역할을 합니다.
개발자는 엔티티만 다루면 되고, JPA가 SQL로 변환해 DB와 통신합니다.

3. EntityManager와 EntityManagerFactory

EntityManagerFactory (EMF)
- 무겁고 스레드 안전합니다.
- 보통 애플리케이션 시작 시 DB당 하나만 생성해서 전체에서 공유합니다.
EntityManager (EM)
- 가볍습니다.
- 요청/트랜잭션 단위로 생성합니다.
- 하나의 EntityManager는 하나의 영속성 컨텍스트를 가집니다.
- 스레드 안전하지 않으므로 사용 후 닫아야 합니다.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("memo");
EntityManager em = emf.createEntityManager();

Spring Boot에서는?
이 과정을 직접 하지 않습니다.
spring-boot-starter-data-jpa가 자동으로 EMF를 만들고, 요청마다 EM을 주입합니다.
개발자는 @Transactional만 선언하면 됩니다.

4. EntityManagerFactory 생성 과정

EntityManagerFactory는 persistence.xml 설정을 기반으로 생성됩니다.

<persistence-unit name="memo">
    <class>com.sparta.entity.Memo</class>
    <properties>
        <property name="jakarta.persistence.jdbc.driver" value="com.mysql.cj.jdbc.Driver"/>
        <property name="jakarta.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/memo"/>
        <property name="jakarta.persistence.jdbc.user" value="root"/>
        <property name="jakarta.persistence.jdbc.password" value="비밀번호"/>
        <property name="hibernate.hbm2ddl.auto" value="update"/>
        <property name="hibernate.show_sql" value="true"/>
    </properties>
</persistence-unit>

5. 트랜잭션과 쓰기 지연

트랜잭션은 "전부 성공하거나 전부 실패해야 하는 하나의 작업 단위"입니다.

JPA는 엔티티 변경 내용을 즉시 DB에 보내지 않고, 쓰기 지연 저장소(Action Queue) 에 쌓아둡니다.
그리고 트랜잭션이 커밋될 때 flush()가 발생하면서 SQL이 한 번에 실행됩니다.

flush가 발생하는 시점은 다음과 같습니다.

트랜잭션 커밋 직전 (자동)
명시적으로 em.flush() 호출 시
JPQL 실행 직전 (기본 AUTO 모드일 경우)

6. 저장과 롤백 예제

EntityTransaction tx = em.getTransaction();
tx.begin();

try {
    Memo memo = new Memo();
    memo.setId(1L); // @GeneratedValue 사용 시에는 직접 지정하지 않습니다.
    memo.setUsername("Robbie");
    memo.setContents("영속성 컨텍스트 테스트");

    em.persist(memo); // DB에는 즉시 반영되지 않음
    tx.commit();      // commit 시점에 INSERT SQL 실행
} catch (Exception e) {
    tx.rollback();    // 오류 발생 시 되돌림
} finally {
    em.close();
    emf.close();
}

em.persist() 호출만으로는 DB에 반영되지 않습니다.
tx.commit() 시점에 flush()가 실행되며, INSERT SQL이 DB에 전달됩니다.
오류가 발생하면 rollback()으로 모든 변경이 취소됩니다.

7. 실무에서는 이렇게 사용합니다

Spring Boot 환경에서는 @Transactional만 붙이면 영속성 컨텍스트와 트랜잭션이 자동으로 열리고 닫힙니다.

@Service
@RequiredArgsConstructor
public class MemoService {
    private final EntityManager em;

    @Transactional
    public void save(Memo memo) {
        em.persist(memo); // commit 시점에 DB 반영
    }
}

조회 전용 메서드에는 @Transactional(readOnly = true)를 붙이면 불필요한 flush 방지로 성능 최적화에 도움이 됩니다.

마무리

영속성 컨텍스트는 JPA의 가장 중요한 개념입니다.

“트랜잭션 동안 엔티티를 캐시하고, 변경을 추적하며, SQL 실행 시점을 조절하는 공간”

Spring Boot 환경에서는 @Transactional만 올바르게 사용해도 이 모든 기능이 자동으로 동작합니다.

[Spring] IoC 컨테이너와 Bean — 객체를 관리하는 Spring의 방식

bu119 — Tue, 23 Sep 2025 18:00:20 +0900

TIL (Today I Learned) — 2025.09.23. 화요일

✍️ 내일배움캠프에서 Spring 학습 중 정리한 내용입니다.

1. IoC 컨테이너와 Bean이란?

앞서 1편에서 IoC(제어의 역전)와 DI(의존성 주입)를 살펴봤습니다.
그렇다면 “필요한 객체를 누가 생성하고, 어디에 보관하며, 어떻게 주입해줄까?”라는 질문이 생깁니다.

이 역할을 담당하는 것이 바로 Spring IoC 컨테이너입니다.

Bean: Spring이 대신 생성하고 관리하는 객체
IoC 컨테이너: Bean을 모아두고 관리하는 공간

개발자가 직접 객체를 만들지 않아도, Spring이 알아서 Bean을 준비하고 필요한 곳에 주입해줍니다.

2. Bean 등록 방법

@Component

클래스 위에 @Component를 붙이면 Spring이 자동으로 Bean으로 등록합니다.

@Component
public class MemoService { ... }

서버가 시작될 때

Spring이 MemoService 객체를 생성
IoC 컨테이너에 memoService라는 이름으로 저장

// 1. MemoService 객체 생성
MemoService memoService = new MemoService();

// 2. Spring IoC 컨테이너에 Bean (memoService) 저장
// memoService -> Spring IoC 컨테이너

@ComponentScan

@ComponentScan을 사용하면 지정된 패키지와 그 하위 패키지를 뒤져서 @Component가 붙은 클래스를 모두 Bean으로 등록합니다.

@Configuration
@ComponentScan(basePackages = "com.sparta.memo")
class BeanConfig { }

Spring Boot에서는 @SpringBootApplication에 기본적으로 @ComponentScan이 포함되어 있습니다.
따라서 별도 설정이 없어도 com.sparta.memo 패키지 하위 클래스들은 자동으로 Bean으로 등록됩니다.

3 Layer Annotation

실무에서는 단순히 @Component 대신 역할에 맞는 애너테이션을 사용합니다.

@Controller / @RestController → Controller 계층
@Service → Service 계층
@Repository → Repository 계층

이들은 내부적으로 모두 @Component를 포함하고 있어, 자동으로 Bean으로 등록됩니다.
하지만 역할을 명확하게 구분할 수 있다는 점에서 더 권장됩니다.

3. Bean 사용 방법

@Autowired (DI 자동 주입)

Spring IoC 컨테이너에서 관리 중인 Bean을 자동으로 주입받을 수 있습니다.

@Service
@RequiredArgsConstructor
public class MemoService {

    private final MemoRepository memoRepository;

}

MemoRepository Bean이 IoC 컨테이너에 존재한다면, Spring이 자동으로 주입해줍니다.
@RequiredArgsConstructor는 Lombok을 이용해 생성자 코드를 줄여주는 방식으로, 실무에서 자주 사용됩니다.

ApplicationContext (직접 가져오기)

IoC 컨테이너에 저장된 Bean을 직접 꺼내올 수도 있습니다.

public MemoService(ApplicationContext context) {
    MemoRepository repo = context.getBean(MemoRepository.class);
}

하지만 Spring 철학은 “직접 가져오기보다 자동 주입(@Autowired) 사용”입니다.
ApplicationContext 접근은 **특수한 경우(예: 테스트, 동적 Bean 탐색)**에만 쓰는 것이 일반적입니다.

4. 정리

Bean: Spring이 대신 생성하고 관리하는 객체
IoC 컨테이너: Bean을 모아두고 관리하는 저장소
등록 방법: @Component, @ComponentScan, 3 Layer Annotation(@Service, @Repository 등)
사용 방법: @Autowired로 주입받는 것이 일반적, ApplicationContext로 직접 꺼내는 것은 특수한 경우에만 사용

결론적으로, 개발자는 객체 생성과 관리에 신경 쓰지 않고 비즈니스 로직에만 집중할 수 있습니다.

✨ 최종 한 줄

IoC 컨테이너와 Bean은 Spring의 심장과 같은 존재입니다.
이 덕분에 개발자는 “무엇을 만들까?”에 집중하고, “어떻게 만들지?”는 Spring에 맡길 수 있습니다.

[Spring] IoC와 DI — 좋은 코드의 핵심 원칙

bu119 — Mon, 22 Sep 2025 22:00:06 +0900

TIL (Today I Learned) — 2025.09.22. 월요일

✍️ 내일배움캠프에서 Spring 학습 중 정리한 내용입니다.

1. IoC와 DI란?

Spring을 배우면 가장 먼저 접하는 단어가 IoC와 DI입니다.
많은 분들이 “Spring에서만 쓰는 기능”으로 오해하지만, 사실은 객체지향 설계 원칙에서 비롯된 개념입니다.

IoC (Inversion of Control, 제어의 역전)
객체 생성과 제어 권한을 개발자가 아닌 외부(Spring IoC 컨테이너)에 맡기는 개념
→ Spring IoC 컨테이너가 객체 생성, 의존성 연결, 생명주기 관리까지 담당합니다.
“내가 직접 만들지 말고, 대신 해줄 사람에게 맡기자”
DI (Dependency Injection, 의존성 주입)
IoC 원칙을 구현하는 대표적인 방법
객체가 필요한 다른 객체를 직접 생성하지 않고, 외부에서 주입받아 사용합니다.
“필요한 걸 외부에서 갖다 넣어주자”

즉, IoC는 큰 설계 개념이고, DI는 이를 구현하는 방법입니다.

2. 왜 필요한가?

좋은 코드는

중복이 적고,
이해하기 쉽고,
유지보수가 편리하며,
다른 코드와의 결합도가 낮아야 합니다.

IoC와 DI는 이 중 결합도를 낮추는 핵심 기술입니다.

3. 의존성과 결합도

의존성이란 “A가 B 없이는 동작할 수 없는 상태”를 의미합니다.

아래 코드를 보면, Consumer는 Chicken에 강하게 의존합니다.

public class Consumer {
    void eat() {
        Chicken chicken = new Chicken();
        chicken.eat();
    }
}

문제점

Consumer는 무조건 Chicken만 먹습니다.
만약 피자를 먹고 싶다면 Consumer 코드를 수정해야 합니다.
즉, 코드가 특정 클래스(Chicken)에 강하게 결합되어 있습니다.

4. 결합도 낮추기 → 인터페이스 도입

이를 해결하려면 구체적인 클래스가 아니라 추상적인 개념(인터페이스)에 의존하도록 바꿔야 합니다.
Chicken, Pizza 같은 개별 음식 대신, 음식(Food)이라는 공통 인터페이스를 정의하는 방식입니다.

interface Food { void eat(); }

class Chicken implements Food {
    public void eat() { System.out.println("치킨을 먹는다."); }
}
class Pizza implements Food {
    public void eat() { System.out.println("피자를 먹는다."); }
}

public class Consumer {
    void eat(Food food) {
        food.eat();
    }
}

이제 Consumer는 Food라는 추상화에만 의존합니다.
Chicken이든 Pizza든 자유롭게 교체 가능하며, 새로운 음식 클래스를 추가해도 Consumer 코드를 수정할 필요가 없습니다.

결과

결합도 ↓
유연성 ↑
유지보수성 ↑

5. 주입(Injection)의 방법

외부에서 필요한 객체를 넣어주는 걸 주입(Injection)이라고 합니다.

필드 주입 (실무에서는 권장되지 않음)

consumer.food = new Chicken();

편리해 보이지만 테스트가 어렵고 순환 참조 문제도 발생하기 때문에 실무에서 거의 사용되지 않습니다.

Setter 주입

consumer.setFood(new Pizza());

선택적으로 교체 가능하지만, 객체가 불변하지 않게 됩니다.

생성자 주입 (Spring 권장 방식)

Consumer consumer = new Consumer(new Chicken());

불변성 보장 + 테스트 용이성 확보 → Spring에서 가장 권장되는 주입 방법입니다.

6. 제어의 역전(IoC)

원래는 Consumer가 직접 Chicken을 생성했지만,
이제는 외부에서 만들어진 객체(Food)를 주입받아 사용합니다.

즉, 객체 제어 흐름이

예전: Consumer → Food (내가 직접 만든다)
지금: Spring IoC 컨테이너 → Consumer (외부가 대신 넣어준다)

이것이 바로 제어의 역전(IoC)입니다.

✨ 정리

IoC = 객체 생성·관리 책임을 개발자가 아닌 Spring IoC 컨테이너에 위임
DI = IoC를 실현하는 대표적인 방법, 필요한 객체를 외부에서 주입받음
Spring 권장 주입 방식 = 생성자 주입
효과 = 결합도 ↓, 확장성 ↑, 유지보수성 ↑

Spring은 IoC와 DI를 기반으로, 개발자가 객체 생성이 아닌 비즈니스 로직에 집중할 수 있도록 돕습니다.

[Java] 문자열 다루기 — String, StringBuffer, StringBuilder 차이

bu119 — Fri, 19 Sep 2025 18:00:40 +0900

TIL (Today I Learned) — 2025.09.19.금요일

✍️ 이 글은 내일배움캠프에서 Java 알고리즘 학습 중 문자열 관련 개념을 정리한 TIL입니다.

1. 왜 문자열 처리가 중요할까?

Java에서 문자열은 단순 출력뿐 아니라 알고리즘 문제 풀이, 웹 개발, 실무 애플리케이션에서 가장 자주 쓰이는 데이터 타입입니다.
하지만 같은 문자열 연산이라도 어떤 클래스를 선택하느냐에 따라 성능과 안정성이 크게 달라집니다.

Java는 문자열 처리를 위해 크게 세 가지 클래스를 제공합니다:

String — 불변(Immutable) 문자열
StringBuffer — 가변(Mutable) + 스레드 안전
StringBuilder — 가변(Mutable) + 빠른 성능

2. String — 불변(Immutable)

String str = "Hello";
str += " World";  // 새로운 객체 생성

특징

불변(Immutable) → 수정 시마다 새로운 객체 생성
동일한 리터럴은 String Pool에서 재사용

장단점

✅ 안정적 (값 변경 불가 → 멀티스레드 환경에서 안전)
✅ Map / Set의 키로 적합
❌ 문자열 연결/수정이 잦으면 매번 객체 생성 → 성능 저하

언제 사용?
문자열 변경이 거의 없을 때, Map/Set의 키로 활용할 때

3. StringBuffer — 가변(Mutable) + 쓰레드 안전

StringBuffer sb = new StringBuffer("Hello");
sb.append(" World");  // 같은 객체 내부에서 수정
System.out.println(sb); // "Hello World"

특징

가변(Mutable) → 같은 객체 안에서 문자열 수정
synchronized 지원 → 멀티스레드 환경에서 안전

장단점

✅ 새 객체 생성 없음 → 효율적
✅ 멀티스레드 환경에서 안전
❌ 단일 스레드에서는 동기화 때문에 성능 손해

언제 사용?
멀티스레드 환경에서 여러 스레드가 같은 문자열을 수정할 때

4. StringBuilder — 가변(Mutable) + 빠른 성능

StringBuilder sb = new StringBuilder();
String result = sb.append("Hello")
                  .append(" ")
                  .append("World")
                  .toString();
System.out.println(result); // Hello World

특징

StringBuffer와 거의 동일하지만 동기화 미지원
단일 스레드 환경에서 최적화

장단점

✅ 불필요한 동기화 없음 → 가장 빠름
❌ 멀티스레드 환경에서는 안전하지 않음

언제 사용?
단일 스레드 환경에서 반복적인 문자열 조작이 필요한 경우

5. 성능 비교 테스트

public class StringPerformanceTest {
    public static void main(String[] args) {
        int iterations = 100000;

        // String 연결 테스트
        long start = System.currentTimeMillis();
        String str = "";
        for (int i = 0; i < iterations; i++) {
            str += "a";
        }
        long stringTime = System.currentTimeMillis() - start;

        // StringBuffer 테스트
        start = System.currentTimeMillis();
        StringBuffer sb = new StringBuffer();
        for (int i = 0; i < iterations; i++) {
            sb.append("a");
        }
        long stringBufferTime = System.currentTimeMillis() - start;

        // StringBuilder 테스트
        start = System.currentTimeMillis();
        StringBuilder sBuilder = new StringBuilder();
        for (int i = 0; i < iterations; i++) {
            sBuilder.append("a");
        }
        long stringBuilderTime = System.currentTimeMillis() - start;

        System.out.println("String: " + stringTime + "ms");
        System.out.println("StringBuffer: " + stringBufferTime + "ms");  
        System.out.println("StringBuilder: " + stringBuilderTime + "ms");
    }
}

실행 결과 (100,000회 반복)

클래스	실행 시간
String	1161ms
StringBuffer	3ms
StringBuilder	4ms

➡️ 문자열 연결이 많을 때 String은 압도적으로 느리다는 걸 확인할 수 있습니다.

따라서, 문자열 수정이 많은 상황에서는 String 대신 StringBuilder나 StringBuffer를 선택해야 합니다.

6. 언제 무엇을 써야 할까?

클래스	특징	스레드 안전성	성능	추천 시나리오
String	불변	✅ O	❌ 낮음	변경 거의 없음, Map/Set 키
StringBuffer	가변	✅ O	⚖️ 중간	멀티스레드 환경
StringBuilder	가변	❌ X	빠름	단일 스레드, 반복문에서 연결

선택 가이드라인

✅ 변경 거의 없음 → String
✅ 단일 스레드 + 성능 → StringBuilder
✅ 멀티스레드 + 안전 → StringBuffer

✨ 오늘의 인사이트

그동안 무심코 String을 사용했지만, 문자열 연결이 많은 경우 성능 저하가 발생할 수 있다는 걸 알게 되었습니다.

특히 알고리즘 문제를 풀 때 문자열 조작이 빈번하게 일어나는 경우, StringBuilder를 활용하면 시간 초과를 피할 수 있을 것 같습니다.

앞으로는 상황에 맞게 String, StringBuffer, StringBuilder를 선택해서 더 효율적인 코드를 작성하겠습니다.

[Spring] 자바 웹 개발 흐름 정리 — Servlet부터 Spring Boot까지

bu119 — Thu, 18 Sep 2025 23:30:30 +0900

TIL (Today I Learned) — 2025.09.18. 목요일

✍️ 이 글은 내일배움캠프에서 Spring 입문 강의를 들으며 학습한 내용을 정리한 TIL입니다.

자바 웹 개발의 발전 과정

오늘날 자바 웹 개발에서 Spring Boot는 사실상 표준입니다.
하지만 Spring Boot가 갑자기 등장한 것이 아니라, 기존 기술의 한계를 보완하고 발전한 끝에 나온 결과물이라는 점을 알면 훨씬 더 깊이 이해할 수 있습니다.

자바 웹 개발은 다음과 같은 단계를 거쳐 발전했습니다.

스파게티 코드 → JSP/Servlet → Spring MVC → Spring Boot

1. 스파게티 코드 (초기 웹 개발)

화면, 비즈니스 로직, 데이터베이스 코드가 한 파일에 뒤섞여 있던 시기
유지보수 어려움, 작은 수정도 큰 리스크
기능 확장이 사실상 불가능

코드가 얽히고설켜 “스파게티 코드”라는 이름이 붙었습니다.

2. JSP + Servlet 조합 → 사실상의 MVC

JSP: 화면을 렌더링하는 데 주로 사용 (View 역할)
Servlet: 요청을 받아 처리하는 데 사용 (Controller 역할)

MVC 패턴을 강제로 적용한 것은 아니었지만, 개발자들이 역할을 나누어 사용하면서 사실상의 MVC 구조가 자리잡기 시작했습니다.

3. Servlet 중심 개발 → 복잡성 증가

Servlet만으로 대규모 웹 애플리케이션을 만들다 보니 한계가 드러났습니다.

요청 파라미터를 일일이 처리해야 함
인증, 로깅 같은 공통 기능을 매번 직접 구현해야 함
Servlet 클래스가 기하급수적으로 늘어나 유지보수 악화

규모가 커질수록 불편함이 명확해졌습니다.

4. Spring MVC → 구조화된 MVC 프레임워크

이 문제를 해결하기 위해 등장한 것이 Spring MVC입니다.

핵심: DispatcherServlet (Servlet 기반)
요청을 표준화된 방식으로 처리
HandlerMapping, HandlerAdapter, ViewResolver 등과 협력
Controller / Service / DAO 계층 구조 지원
공통 기능(AOP, 트랜잭션, 의존성 주입) 제공

덕분에 개발자는 반복 작업에서 벗어나 비즈니스 로직에 집중할 수 있게 되었습니다.

5. Spring Boot → 설정 자동화 & 생산성 향상

Spring MVC도 강력했지만, 설정이 복잡했습니다. (특히 XML )
이 불편함을 해결하기 위해 Spring Boot가 등장했습니다.

자동 설정(Auto Configuration) → XML 대신 application.yml 중심
Starter 의존성 → 필요한 기능을 한 줄로 추가 가능
내장 서버(Tomcat, Jetty 등) → 실행만 하면 바로 서버 구동
운영 편의 기능(Actuator, 외부 설정 관리) 기본 제공

Spring Boot 덕분에 개발자는 환경 세팅보다 핵심 기능 개발에 집중할 수 있게 되었습니다.

오늘의 핵심 ✨

Servlet → Spring MVC → Spring Boot 는 “대체 관계”가 아닙니다.

Spring MVC = Servlet 기반 프레임워크
Spring Boot = Spring MVC 기반 자동화 도구

지금 사용하는 Spring Boot는 자바 웹 기술 발전의 집약체입니다.

정리하면,

스파게티 코드: 모든 코드가 뒤섞여 유지보수 불가
Servlet: 웹 요청 처리의 기반 기술
Spring MVC: 구조화된 MVC 프레임워크
Spring Boot: 설정 자동화 + 운영 편의 기능으로 생산성 극대화

오늘날 우리가 손쉽게 쓰는 Spring Boot는, 오랜 시간에 걸쳐 기술적 불편을 해결하며 발전한 결과물입니다.

[Spring] Spring MVC란? — MVC 패턴과 DispatcherServlet 동작 원리

bu119 — Wed, 17 Sep 2025 23:10:41 +0900

TIL (Today I Learned) — 2025.09.17. 수요일

✍️ 이 글은 내일배움캠프에서 Spring 입문 강의를 들으며 학습한 내용을 정리한 TIL입니다.

1. 자바 웹 개발의 발전 과정

자바 웹 개발은 시간이 지남에 따라 코드 구조와 생산성을 개선하는 방향으로 발전해 왔습니다.
초기에는 화면, 로직, 데이터베이스 코드가 한 파일에 뒤섞여 있었지만, 지금은 설정 자동화와 내장 서버까지 제공하는 Spring Boot가 사실상 표준이 되었습니다.

발전 단계 흐름

스파게티 코드 → JSP/Servlet → Spring MVC → Spring Boot

단계	특징	문제점
스파게티 코드	화면·비즈니스 로직·DB 코드가 한 파일에 섞임	유지보수 거의 불가능
JSP + Servlet	View(JSP)와 Controller(Servlet) 분리 → 사실상 MVC 구조	설정 번거롭고, 요청/응답 코드 중복
Spring MVC	DispatcherServlet 중심의 체계적 MVC (Front Controller 패턴)	초기에는 XML 설정이 복잡
Spring Boot	자동 설정 + 내장 서버 제공, 개발자가 비즈니스 로직에만 집중 가능	현재 사실상 표준

핵심 정리

Servlet → 자바 웹의 기반 기술 (HTTP 요청/응답 직접 처리)
Spring MVC → Servlet의 한계를 보완한 체계적 MVC 프레임워크
Spring Boot → 복잡한 설정을 자동화하여 개발 효율을 극대화

2. MVC 디자인 패턴이란?

MVC란?

MVC = Model + View + Controller
소프트웨어 설계 패턴 중 하나로, 코드를 역할별로 분리하여 유지보수성과 협업 효율을 높이는 방법입니다.

흐름도

사용자 요청 → Controller → Model → View → 사용자 응답

구성 요소와 역할

구성 요소	역할	예시
Model	데이터와 비즈니스 로직 처리	Service, Repository, DB
View	사용자 인터페이스(UI)	HTML, Thymeleaf, JSP
Controller	Model ↔ View 사이에서 흐름 제어	UserController, ShopController

✅ MVC 패턴의 필요성과 해결책

문제 상황 (MVC 도입 전)	✅ MVC 해결책	예시
로그인 화면 수정 시 DB 코드까지 건드려야 함	관심사 분리 (Separation of Concerns)	JSP/Thymeleaf 화면만 수정하면 되고, UserService 로직은 그대로 둠
버그 발생 시 원인 찾기 어려움	독립적 테스트 가능	Controller 단위 테스트로 요청 흐름만 확인, Service 단위 테스트로 로직만 확인
여러 개발자 동시 작업 시 충돌 발생	협업 효율 ↑ (View ↔ Model 분리)	프론트 개발자는 HTML/CSS만 작업, 백엔드 개발자는 Service/Repository만 작업
코드 재사용 불가능	Model 로직을 다른 View에서도 재활용 가능	UserService.findById() 로직을 웹 화면, API 응답, 관리자 페이지 모두에서 활용

핵심 정리

MVC 패턴은 “한 파일에 뒤섞인 코드”를 역할별로 나누어,
재사용성과 유지보수성을 높이고, 협업을 용이하게 합니다.

실제 코드 예시 (Spring MVC 기반)

Controller - 요청 처리 및 연결

@Controller
public class UserController {
    
    @Autowired
    private UserService userService;  // Model 영역과 연결
    
    @GetMapping("/users/{id}")
    public String getUser(@PathVariable Long id, Model model) {
        // 1. Model에서 데이터 가져오기
        User user = userService.findById(id);
        
        // 2. View에 데이터 전달
        model.addAttribute("user", user);
        
        // 3. View 이름 반환
        return "user-detail";  // templates/user-detail.html
    }
}

Model - 실제 데이터 처리

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    public User findById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException());
    }
}

View - 사용자 화면

<html>
<body>
    <h1>사용자 정보</h1>
    <p>이름: <span th:text="${user.name}"></span></p>
    <p>이메일: <span th:text="${user.email}"></span></p>
</body>
</html>

3. Servlet의 이해와 동작 원리

Servlet이란?

Servlet(서블릿)은 자바 기반 웹의 핵심 기술로,
HTTP 요청을 받아 처리하고 동적으로 페이지를 생성하는 서버 측 프로그램입니다.

톰캣(Tomcat) 같은 Servlet 컨테이너가 서블릿의 생명주기를 관리하고, 요청과 응답을 대신 처리합니다.

Servlet 동작 흐름

사용자가 웹 브라우저로 요청을 보냈을 때, Servlet이 동작하는 전체 과정은 다음과 같습니다:

Client → Servlet Container → Servlet → 응답 반환

세부 단계:

Client HTTP Request → Servlet Container
사용자가 브라우저에서 /hello 같은 요청을 보냄.
요청/응답 객체 생성
컨테이너가 HttpServletRequest, HttpServletResponse 객체를 생성해 요청/응답 정보를 담음.
Servlet 탐색
web.xml 설정 또는 애노테이션(@WebServlet)에 따라 어떤 Servlet이 처리할지 결정.
service() 메서드 실행
컨테이너가 해당 Servlet의 service() 메서드를 호출.
→ 내부적으로 HTTP 메서드(GET/POST 등)에 따라 doGet() 또는 doPost()로 분기.
doGet() / doPost() 실행
요청 방식(Method)에 따라 실제 메서드가 실행됨.
응답 반환
처리 결과를 HttpServletResponse 객체에 담아 브라우저로 전달.
객체 정리
요청이 끝나면 컨테이너가 요청/응답 객체를 메모리에서 정리 (GC 대상이 됨).

단계별 정리

단계	동작	설명
1단계	Client → Servlet Container	브라우저가 서버에 HTTP 요청 전달
2단계	요청/응답 객체 생성	HttpServletRequest, HttpServletResponse 생성
3단계	Servlet 탐색	매핑 정보(web.xml, @WebServlet) 확인
4단계	service() 호출	모든 요청의 진입점, 내부에서 HTTP 메서드 분기 처리
5단계	doGet/doPost 실행	HTTP Method에 따라 적절한 메서드 실행
6단계	응답 반환	결과를 HttpServletResponse에 담아 브라우저로 전송
7단계	객체 정리	요청 완료 후 컨테이너가 메모리 정리

Servlet의 핵심 특징

HTTP 규격 기반 : 요청과 응답을 표준 프로토콜에 맞게 처리
HttpServletRequest : 요청 데이터(파라미터, 헤더, 세션 등) 조회
HttpServletResponse : 상태 코드, 헤더, 응답 본문 작성
동적 페이지 생성 : 요청마다 다른 HTML/JSON을 생성해 반환 가능

코드 예시: HelloServlet (학습용)

import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        // 1. 요청 파라미터 가져오기
        String name = request.getParameter("name");

        // 2. 응답 타입과 인코딩 설정
        response.setContentType("text/html;charset=UTF-8");

        // 3. 응답 작성
        response.getWriter().write("<h1>Hello, " + name + "!</h1>");
    }
}

실행 결과

요청: http://localhost:8080/hello?name=차돌
응답: Hello, 차돌!

4. Servlet의 한계점

❌ 주요 문제점

Servlet만으로 개발할 때는 다음과 같은 문제가 발생합니다:

문제	설명
관리 복잡성	기능마다 별도의 Servlet 클래스 필요 → 규모가 커질수록 클래스 폭증
설정 번거로움	web.xml에 모든 매핑을 직접 작성해야 함
중복 코드	각 Servlet마다 요청/응답 처리 코드가 비슷하게 반복
유지보수 어려움	URL 하나만 변경해도 여러 파일 수정 필요

결론:
규모가 커질수록 Servlet 수백 개 + 설정 수백 줄이 필요해져서 유지보수가 사실상 불가능해집니다.

️ 실제 예시: 쇼핑몰 만들기 (Servlet 방식)

필수 기능

로그인 (/login)
회원가입 (/signup)
상품 목록 (/products)
장바구니 (/cart)
주문하기 (/order)

Servlet 파일 구조

src/main/java/servlets/
├── LoginServlet.java      
├── SignupServlet.java     
├── ProductServlet.java    
├── CartServlet.java       
└── OrderServlet.java

web.xml 설정 (매우 번거로움)

<servlet>
    <servlet-name>LoginServlet</servlet-name>
    <servlet-class>com.shop.LoginServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>LoginServlet</servlet-name>
    <url-pattern>/login</url-pattern>
</servlet-mapping>

<!-- 나머지 기능들도 모두 같은 방식으로 등록해야 함 -->

기능이 늘어날수록 Servlet과 web.xml 매핑이 기하급수적으로 늘어납니다.

해결책의 필요성

이런 불편함을 해결하기 위해, Spring MVC의 Front Controller 패턴이 등장했습니다.

중앙 진입점인 DispatcherServlet 하나가 모든 요청을 받아 처리 → 중복 제거
애노테이션(@GetMapping, @PostMapping 등) 기반 매핑 → 설정 간소화

5. Spring MVC와 Front Controller 패턴

Spring MVC란?

Spring Web MVC는 Servlet API 기반 웹 프레임워크입니다.

중앙의 DispatcherServlet이 모든 요청을 받아 적절한 Controller로 분배하는 Front Controller 패턴을 사용합니다.

덕분에 요청 처리 흐름이 일관되고, 개발자는 비즈니스 로직에 집중할 수 있습니다.

한 줄 요약

Spring MVC = Servlet의 한계를 보완한, DispatcherServlet 중심 MVC 프레임워크

️ Front Controller 패턴이란?

기존 방식 (Servlet): 요청마다 별도의 Servlet 클래스 필요 → 코드와 설정이 폭발적으로 증가
개선 방식 (Spring MVC): DispatcherServlet 하나가 모든 요청을 받아 내부적으로 Controller 메서드와 매핑

즉, 모든 요청이 하나의 입구(DispatcherServlet) 로 들어와서, 내부에서 여러 출구(Controller 메서드) 로 분배됩니다.
이 구조 덕분에 관리가 단순해지고, 새로운 기능 추가 시 확장성이 뛰어납니다.

Servlet vs Spring MVC 비교

구분	Servlet 방식	Spring MVC (Front Controller)
요청 처리	기능마다 Servlet 클래스 필요	DispatcherServlet 하나가 모든 요청 접수
매핑 방식	web.xml 직접 등록	애노테이션(@GetMapping 등) 자동 매핑
유지보수	URL 변경 시 여러 Servlet 수정	중앙에서 한 번에 관리
코드 관리	요청별 Servlet 분산	Controller 클래스 단위로 체계적 관리

요청 처리 흐름 비교

Servlet 방식

/login    → LoginServlet
/signup   → SignupServlet
/products → ProductServlet

Spring MVC 방식

/login    ┐
/signup   ├─→ DispatcherServlet → 적절한 Controller 메서드 호출
/products ┘

핵심: Servlet 여러 개 대신, DispatcherServlet 하나로 통합 관리

️ 쇼핑몰 예시 (Spring MVC 방식)

@RestController
public class ShopController {

    @PostMapping("/login")   // LoginServlet 대신
    public String login(@RequestParam String username,
                        @RequestParam String password) {
        // 로그인 처리 로직
        return "login-success";
    }

    @PostMapping("/signup")  // SignupServlet 대신
    public String signup(@RequestParam String email) {
        // 회원가입 처리 로직
        return "signup-success";
    }

    @GetMapping("/products") // ProductServlet 대신
    public String products(Model model) {
        List<Product> products = productService.findAll();
        model.addAttribute("products", products);
        return "product-list"; // View 이름
    }
}

✅ 개선 효과

Servlet 클래스 5개 → Controller 메서드 5개로 단순화
web.xml 설정 불필요 (애노테이션 기반 매핑)
기능별 Controller로 코드 구조화 → 유지보수 쉬움
✅ 생산성 향상 → 개발자는 설정보다 비즈니스 로직에만 집중 가능

6. DispatcherServlet 동작 원리

Front Controller 패턴의 핵심

DispatcherServlet은 모든 HTTP 요청의 진입점으로 동작합니다.

모든 HTTP 요청을 가장 먼저 받아서, 적절한 Controller로 전달하는 Front Controller 역할을 수행합니다.

즉, 클라이언트 요청을 가장 먼저 받아 적절한 Controller로 전달한 뒤, 응답이 만들어지는 전 과정을 중앙에서 관리합니다.

전체 요청 처리 흐름 (7단계)

다음은 Spring MVC에서 요청이 처리되는 전체 과정입니다:

단계별 상세 설명

단계	구성 요소	역할
1단계	Client → DispatcherServlet	HTTP 요청이 들어오면 DispatcherServlet이 가장 먼저 수신
2단계	DispatcherServlet → HandlerMapping	URL, HTTP Method를 기반으로 실행할 Controller 메서드 탐색
3단계	DispatcherServlet → Controller	찾은 Controller 메서드를 호출
4단계	Controller → DispatcherServlet	처리 결과(Model 데이터 + View 이름) 반환
5단계	DispatcherServlet → ViewResolver	반환된 View 이름을 실제 뷰 파일 경로로 변환
6단계	ViewResolver → View	View에 Model 데이터를 적용해 화면 완성
7단계	View → Client	최종 HTML(또는 JSON 등)을 클라이언트에 응답

Spring MVC는 이 흐름에서 web.xml 대신 애노테이션 매핑(@GetMapping 등)을 사용합니다.

️ 실제 예시: /products 요청 처리 과정

사용자가 http://localhost:8080/products에 접속했을 때:

1. 사용자: "상품 목록을 보여주세요" (/products 요청)
   ↓
2. DispatcherServlet: "이 요청을 누가 처리하지?"
   ↓  
3. Handler mapping: "@GetMapping('/products')를 가진 메서드를 찾았어요!"
   ↓
4. DispatcherServlet: "ShopController.products() 메서드를 실행할게요"
   ↓  
5. Controller: 비즈니스 로직 실행 → "product-list" + 상품 데이터 반환
   ↓
6. ViewResolver: "product-list → /templates/product-list.html 파일이네요"
   ↓
7. View: 상품 데이터를 HTML에 채워서 완성된 페이지 생성
   ↓
8. 사용자: 상품 목록이 표시된 페이지를 브라우저에서 확인

핵심 구성 요소 정리

DispatcherServlet: 모든 요청의 진입점, 중앙 관리자
HandlerMapping: URL과 Controller 메서드 연결
Controller: 비즈니스 로직 처리
ViewResolver: 논리적 View 이름 → 실제 파일
View: Model 데이터를 사용해 최종 응답 화면 생성

✨ 오늘의 결론

Spring MVC를 배우며 Servlet이 여전히 기반 기술임을 알게 되었습니다.
Spring은 단순한 새로운 프레임워크가 아니라, Servlet의 복잡함을 추상화해 개발자가 비즈니스 로직에만 집중할 수 있게 해주는 도구였습니다.

오늘의 핵심 정리

MVC 패턴은 역할을 분리해 협업 효율과 유지보수성을 높인다
Servlet은 HTTP 처리의 기반이지만, 직접 사용하면 관리가 복잡하다
Spring MVC는 DispatcherServlet을 중심으로 요청을 구조적으로 처리한다
Spring Boot는 이 과정을 자동화해 생산성을 크게 높였다

앞으로는 단순히 Controller 코드만 보지 않고,
HTTP 요청 → DispatcherServlet → HandlerMapping → Controller → ViewResolver
라는 흐름 전체를 이해하며 코드를 바라보려 합니다.

[Spring/Lombok] 생성자 애너테이션 알아보기 — @AllArgsConstructor, @NoArgsConstructor, @RequiredArgsConstructor

bu119 — Tue, 16 Sep 2025 21:00:53 +0900

TIL (Today I Learned) — 2025.09.16. 화요일

✍️ 이 글은 내일배움캠프에서 Spring 입문 강의를 들으며 학습한 내용을 정리한 TIL입니다.

Lombok을 왜 써야 할까요?

Java로 개발하다 보면 같은 패턴의 코드를 반복해서 작성하게 됩니다.

특히 클래스마다 생성자, getter, setter를 만드는 작업은 시간이 많이 들고, 가독성도 떨어집니다.

예를 들어, 간단한 상품 클래스를 하나 만든다고 해봅시다:

//   Lombok 없이 작성하면...
public class Product {
    private String name;
    private int price;
    
    // 기본 생성자
    public Product() {}
    
    // 모든 필드 생성자
    public Product(String name, int price) {
        this.name = name;
        this.price = price;
    }
    
    // getter, setter 등등...
}

하지만 Lombok을 사용하면 단 두 줄로 같은 결과를 만들 수 있습니다:

//   Lombok 사용하면...
@NoArgsConstructor
@AllArgsConstructor
public class Product {
    private String name;
    private int price;
}

Lombok은 이런 반복 코드를 애너테이션 한 줄로 해결해주는 라이브러리입니다.

️ @AllArgsConstructor — "모든 필드를 한 번에!"

모든 필드를 매개변수로 받는 생성자를 자동으로 만들어줍니다

@AllArgsConstructor
public class Product {
    private String name;
    private int price;
}

// 컴파일하면 이런 생성자가 자동 생성됩니다:
// public Product(String name, int price) {
//     this.name = name;
//     this.price = price;
// }

✅ 언제 사용하면 좋을까요?

DTO 클래스: REST API에서 데이터를 주고받을 때
불변 객체: 한 번 만들면 값을 바꾸지 않는 객체

@AllArgsConstructor
@Getter
public class ProductDto {
    private String name;
    private int price;
}

// 사용 예시
ProductDto dto = new ProductDto("맥북 프로", 2500000);

이렇게 하면 프론트엔드에서 받은 JSON을 객체로 변환하거나, 응답 DTO로 직관적으로 데이터를 담을 수 있습니다.

⚠️ 조심해야 할 경우

JPA 엔티티에는 사용하지 않는 것이 좋습니다.

DB가 자동으로 생성하는 id까지 생성자 매개변수로 받아야 해서 혼란스럽습니다.

// ❌ 이렇게 하면 안 됩니다
@AllArgsConstructor
@Entity
public class Product {
    @Id @GeneratedValue
    private Long id;      // DB가 만드는 건데 생성자로 받아야 함
    private String name;
}

// 사용할 때도 이상해집니다
Product product = new Product(null, "맥북");  // id에 null을 넣어야 함

@NoArgsConstructor — "빈 생성자가 필요합니다!"

매개변수가 하나도 없는 기본 생성자를 만들어줍니다.

@NoArgsConstructor
public class Product {
    private String name;
    private int price;
}

// 컴파일하면 이런 생성자가 자동 생성됩니다:
// public Product() {}

✅ 언제 반드시 필요할까요?

1️⃣ JPA 엔티티 (DB와 연결되는 클래스)

DB와 연결되는 객체는 JPA가 내부적으로 자동 생성해야 하기 때문에 반드시 기본 생성자가 필요합니다.
즉, 개발자가 직접 new로 만드는 것이 아니라, JPA가 알아서 객체를 만들 수 있도록 준비해두는 것입니다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Product {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

왜 PROTECTED를 사용할까요?

JPA는 내부적으로 리플렉션(자바가 몰래 객체를 생성하는 기술)을 이용합니다.

이 과정에서는 접근 제어자가 크게 중요하지 않아서 PUBLIC, PROTECTED, PACKAGE, PRIVATE 모두 동작합니다.

하지만 실무에서는 PROTECTED를 가장 많이 사용합니다.

JPA는 객체를 만들 수 있도록 열어두면서,
외부에서 new Product()로 무분별하게 생성하는 것을 막기 위해서 사용합니다.

접근 제어자별 차이

PUBLIC : 어디서든 호출 가능
PROTECTED : JPA는 사용 가능, 외부 직접 호출 제한 (권장)
PACKAGE : 같은 패키지 내부에서만 호출 가능
PRIVATE : JPA는 사용 가능하지만 테스트나 별도 생성 메서드 없이는 불편

2️⃣ JSON 변환 - REST API 통신할 때

프론트엔드와 JSON 데이터를 주고받을 때도 빈 생성자가 필요합니다.

@AllArgsConstructor
@NoArgsConstructor
@Getter @Setter
public class ProductDto {
    private String name;
    private int price;
}

// JSON → 객체 변환 과정:
// 1. Jackson이 new ProductDto()로 빈 객체 만듦
// 2. setter로 JSON 값들을 하나씩 넣음

@RequiredArgsConstructor — "꼭 필요한 것만!"

final이나 @NonNull이 붙은 중요한 필드만 매개변수로 받는 생성자를 만들어줍니다.

@RequiredArgsConstructor
public class Product {
    private final String name;   // 필수 - 생성자에 포함 ✅
    private final int price;     // 필수 - 생성자에 포함 ✅
    private String description;  // 선택 - 생성자에 포함 ❌
}

// 컴파일하면 이런 생성자가 자동 생성됩니다:
// public Product(String name, int price) {
//     this.name = name;
//     this.price = price;
// }

✅ 왜 좋을까요?

실수 방지: 중요한 값을 깜빡하고 안 넣는 실수를 막아줍니다
안전한 객체: final로 만들면 나중에 값을 바꿀 수 없어서 더 안전합니다
JPA 권장 패턴: DB 엔티티 만들 때 가장 많이 사용하는 방식입니다

실무에서 이렇게 활용합니다:

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)  // JPA용
@RequiredArgsConstructor                            // 개발자용
public class Product {
    @Id @GeneratedValue
    private Long id;
    
    private final String name;     // 상품명은 필수
    private final int price;       // 가격도 필수
    private String description;    // 설명은 나중에 추가해도 됩니다
    
    // 나중에 설명을 추가하는 메서드
    public void updateDescription(String description) {
        this.description = description;
    }
}

// 사용할 때
Product product = new Product("맥북", 2000000);  // 필수 정보만 넣어서 생성
product.updateDescription("Apple M3 chip");      // 부가 정보는 나중에

실무에서는 어떻게 조합할까요? (실무 조합 패턴)

상황별로 권장하는 Lombok 애너테이션 조합은 다음과 같습니다:

상황	추천 조합	이유
JPA 엔티티	@NoArgsConstructor(PROTECTED) + @RequiredArgsConstructor	JPA 호환성 + 필수값 강제
DTO 클래스	@AllArgsConstructor + @NoArgsConstructor	JSON 변환 호환성
Service 계층	@RequiredArgsConstructor	의존성 주입 자동화

예시 — JPA 엔티티

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@RequiredArgsConstructor
@Getter
public class Product {
    @Id @GeneratedValue
    private Long id;

    private final String name;
    private final int price;
}

이렇게 하면 JPA가 객체를 만들 때는 문제없고,
개발자는 new Product("맥북", 2000000)처럼 필수값만 넣어 깔끔하게 객체를 생성할 수 있습니다.

예시 — Service 계층

@Service
@RequiredArgsConstructor
public class ProductService {
    private final ProductRepository productRepository;

    public void save(String name, int price) {
        productRepository.save(new Product(name, price));
    }
}

이렇게 하면 Service 클래스에서 @RequiredArgsConstructor로 Repository가 자동 주입되고,
비즈니스 로직에서는 불필요한 setter 없이 new Product(name, price)로 필수값만 넣어 간결하게 객체를 생성할 수 있습니다.

자주 하는 실수들

1️⃣ final 필드와 @NoArgsConstructor만 사용

// ❌ 컴파일 에러 발생!
@NoArgsConstructor
public class Product {
    private final String name;  // final은 반드시 초기화해야 하는데...
}

✅ 해결: @RequiredArgsConstructor와 함께 사용합니다.

// ✅ 이렇게 해결하세요
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@RequiredArgsConstructor
public class Product {
    private final String name;
}

2️⃣ JPA 엔티티에 @AllArgsConstructor 사용

// ❌ 잘못된 패턴
@AllArgsConstructor
@Entity
public class Product {
    @Id @GeneratedValue
    private Long id;  // DB가 만드는 건데 생성자로 받습니다
    private String name;
}

✅ 해결: 필수 값만 받도록 @RequiredArgsConstructor 사용

// ✅ 올바른 패턴
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@RequiredArgsConstructor
public class Product {
    @Id @GeneratedValue
    private Long id;
    private final String name;  // 필수값만 생성자로
}

3️⃣ DTO에서 기본 생성자 누락

// ❌ JSON 변환 시 에러 발생
@RequiredArgsConstructor
public class ProductDto {
    private final String name;
}

✅ 해결: @AllArgsConstructor + @NoArgsConstructor 함께 사용

// ✅ 기본 생성자 추가
@AllArgsConstructor
@NoArgsConstructor
@Getter @Setter
public class ProductDto {
    private String name;  // final 제거
}

✨ 오늘의 결론

Lombok은 단순히 반복 코드를 줄여주는 도구가 아니라, 클래스의 역할과 객체 생성 방식을 어떻게 설계할 것인지 결정하는 중요한 도구라는 점을 배웠습니다.

특히 엔티티에서는 @NoArgsConstructor(PROTECTED)와 @RequiredArgsConstructor 조합이 사실상 표준처럼 사용되며, DTO나 서비스 계층에서는 다른 조합이 적절할 수 있다는 것을 알게 되었습니다.

앞으로는 “이 클래스는 어떤 역할을 맡고 있으며, 어떤 필드가 필수적인가, 외부에서 객체를 어떻게 생성해야 하는가” 를 먼저 고민한 뒤, 상황에 맞는 Lombok 애너테이션을 선택하겠습니다.

[AWS] Amazon S3 접근을 위한 IAM 사용자 액세스 키 만들기

bu119 — Wed, 3 Sep 2025 09:00:27 +0900

https://bu119.tistory.com/133

앞선 글에서 우리는 Amazon S3를 안전하게 사용하기 위해 IAM 사용자를 생성했습니다.
하지만 IAM 사용자만 만들어서는 CLI나 애플리케이션에서 S3에 접근할 수 없습니다.
이를 위해서는 액세스 키(Access Key) 를 발급받아야 합니다.

액세스 키는 두 가지 정보로 구성됩니다.

Access Key ID: 공개 키 (사용자 식별자)
Secret Access Key: 비밀 키 (비밀번호 역할, 절대 외부 공개 금지)

이번 글에서는 IAM 사용자 액세스 키 발급 과정을 단계별로 알아보겠습니다.

IAM 사용자 액세스 키 발급하기

1️⃣ IAM 서비스 접속

1. AWS Management Console 상단 검색창에 " IAM " 입력 후 이동합니다.

2. IAM 대시보드 좌측 메뉴에서 [ 사용자(Users) ] 탭을 클릭합니다.

2️⃣ 사용자 선택

1. 사용자(Users) 섹션에서 액세스 키를 발급할 사용자를 선택합니다.

예: s3-uploader

3️⃣ 액세스 키 생성

1. 사용자 상세 페이지에서 [ 보안 자격 증명(Security credentials) ] 탭을 선택합니다.

2. 액세스 키(Access keys) 섹션에서 [ 액세스 키 만들기(Create access key) ] 버튼을 클릭합니다.

3. 사용 사례 선택 단계에서는 [ AWS 외부에서 실행되는 애플리케이션 ]을 선택합니다.

Lightsail, 온프레미스 서버, 외부 클라우드 환경 등은 IAM Role을 붙일 수 없으므로 “외부”로 분류됩니다.
이 선택은 권한 차이를 만드는 것이 아니라, AWS가 보안 가이드를 안내하기 위한 용도입니다.

사용 사례별 의미

Command Line Interface(CLI) → 로컬/서버에서 AWS CLI 실행
로컬 코드 → 로컬 PC에서 실행되는 애플리케이션
AWS 컴퓨팅 서비스 → EC2, ECS, Lambda 등 IAM Role 연동 가능한 서비스
서드 파티 서비스 → GitHub Actions, Datadog 같은 외부 서비스
AWS 외부에서 실행되는 애플리케이션 → Lightsail, 외부 클라우드, 온프레미스 서버
기타 → 위에 해당하지 않는 경우

4. "설명 태그 값"은 선택 사항입니다.

운영 환경에서는 IAM-user-name-key 같이 사용자명과 연계된 명확한 이름을 작성하는 것을 권장합니다.

5. [ 액세스 키 만들기(Create access key) ] 버튼을 클릭합니다.

4️⃣ 키 확인 및 저장

1. 발급된 Access Key ID 와 Secret Access Key 를 확인합니다.

⚠️ Secret Access Key는 한 번만 확인 가능하므로 반드시 안전한 곳에 저장해야 합니다.
분실 시 새 키를 발급하고, 기존 키는 삭제하는 것이 보안상 안전합니다.

마무리

IAM 사용자에 액세스 키를 발급하면, 이제 해당 키를 이용해 애플리케이션에서 Amazon S3에 접근할 수 있습니다.
운영 환경에서는 항상 최소 권한 원칙(Principle of Least Privilege) 을 지키고, 발급된 키는 안전하게 보관하는 습관이 중요합니다.

참고 문서

https://velog.io/@jjinwo0/Spring-Boot-AWS-AWS-S3-bucket%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%97%85%EB%A1%9C%EB%93%9C

[AWS] Amazon S3 사용을 위한 IAM 사용자 생성하기

bu119 — Tue, 2 Sep 2025 09:00:19 +0900

Amazon S3는 파일을 저장하고 관리할 수 있는 AWS의 대표적인 스토리지 서비스입니다.
하지만 루트 계정(root account) 으로 직접 S3를 사용하는 것은 보안상 매우 위험합니다. 루트 계정은 AWS 전체 권한을 가지고 있어 유출되면 모든 리소스가 노출될 수 있기 때문입니다.

따라서 반드시 IAM(Identity and Access Management) 사용자를 생성하고, 필요한 권한만 부여해 사용하는 것이 안전합니다.

이번 글에서는 IAM의 개념을 간단히 살펴보고, S3에 접근할 수 있는 IAM 사용자를 생성하는 방법을 단계별로 알아보겠습니다.

Identity and Access Management(IAM)란?

IAM은 AWS 리소스에 대한 액세스 권한을 제어하는 서비스입니다.

IAM 사용자: IAM에서 생성된 개별 계정으로, 각 사용자마다 권한을 다르게 부여할 수 있습니다.
루트 계정: AWS 전체 권한을 가진 최고 권한 계정 (운영에서 직접 사용 금지)
IAM의 역할: 최소 권한만 부여하여 보안을 강화하고, 리소스별로 접근 권한을 세분화

즉, IAM 사용자는 리소스 접근 여부가 지정된 계정으로, 루트 계정 대신 안전하게 S3와 같은 리소스를 관리할 수 있게 해줍니다.

IAM 사용자 생성하기

1️⃣ IAM 서비스 접속

1. AWS Management Console 상단 검색창에 " IAM " 입력 후 이동합니다.

2️⃣ IAM 대시보드에서 사용자 추가

1. 좌측 메뉴에서 [ 사용자(Users) ] 탭을 클릭합니다.

2. 사용자 섹션 우측 상단 [ 사용자 추가(Add users) ] 버튼 클릭합니다.

3️⃣ 사용자 생성 단계

1단계: 사용자 세부 정보 지정

1. 사용자 이름을 입력합니다.

실제 용도에 맞는 이름을 입력하는 것이 좋습니다.
예: s3-uploader, s3-reader

2. [ AWS Management Console 액세스 권한 ]은 불필요하므로 체크하지 않습니다.

2단계: 권한 설정

1. "권한 옵션" 섹션에서 [ 직접 정책 연결 ]을 선택합니다.

2. "권한 정책" 섹션의 검책 창에 "AmazonS3FullAccess"을 검색하고, 체크 표시를 클릭합니다

AmazonS3FullAccess → 모든 S3 버킷 권한 (테스트용)
AmazonS3ReadOnlyAccess → 읽기 전용
운영 환경 권장 → 특정 버킷 전용 정책(JSON 직접 작성)

운영 환경 권장 정책 예시(JSON):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-s3-bucket/*"
    }
  ]
}

s3:GetObject: 파일 다운로드
s3:PutObject: 파일 업로드
arn:aws:s3:::my-s3-bucket/*: 특정 버킷 내 객체에만 허용

3. 우측 하단의 [ 다음 ] 버튼을 클릭합니다.

3단계: 검토 및 생성

1. 입력한 정보를 확인하고, [ 사용자 생성 ] 버튼을 클릭합니다.

2. S3 권한을 가진 IAM 사용자 생성이 완료되었습니다.

마무리

IAM 사용자를 생성하고 필요한 권한만 부여하는 것은 AWS 보안의 기본 원칙입니다.
특히 운영 환경에서는 최소 권한 원칙(Principle of Least Privilege) 을 지켜 특정 버킷에만 접근하도록 제한하는 것이 중요합니다.

이번 글에서는 Amazon S3 사용을 위한 IAM 사용자 생성 방법을 살펴보았습니다.

다음 글에서는 IAM 액세스 키 발급 및 AWS CLI 설정 방법을 이어서 다루겠습니다.

https://bu119.tistory.com/134

참고 문서

https://velog.io/@jjinwo0/Spring-Boot-AWS-AWS-S3-bucket%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%97%85%EB%A1%9C%EB%93%9C

[AWS] Amazon S3 버킷 정책(Bucket Policy) 작성 방법 (3가지)

bu119 — Mon, 1 Sep 2025 15:20:03 +0900

Amazon S3 버킷 정책은 버킷과 객체에 대한 접근 제어를 세밀하게 설정할 수 있는 핵심 보안 기능입니다. 기본적으로 S3 버킷은 외부 접근이 차단되어 있기 때문에, 웹사이트 호스팅, 특정 사용자 권한 부여, 내부 애플리케이션 접근 제어와 같은 상황에서 반드시 버킷 정책을 적절히 구성해야 합니다.

이번 글에서는 S3 버킷 정책을 작성하는 3가지 방법을 비교하고, 상황별로 어떤 방식을 선택해야 하는지 실무 관점에서 정리합니다.

3가지 방법 비교 분석

방법	장점	단점	추천 대상	적합한 상황
직접 JSON 작성	• 빠른 작성 가능 • 세밀한 제어	• JSON 문법 숙지 필요 • 오타/구문 오류 위험	개발자, 숙련자	복잡한 정책, 빠른 수정
시각적 편집기	• 직관적인 GUI • 실시간 JSON 미리보기	• 복잡한 조건 제한 • 다중 조건 설정 어려움	초급자, 일반 사용자	간단한 정책, 학습 목적
Policy Generator	• 문법 오류 방지 • 단계별 가이드 제공	• 별도 화면에서 작성 • 일부 최신 조건 미지원	모든 사용자	정확성이 중요한 정책, 템플릿 생성

방법 1: 직접 JSON 작성

️ 개요

SON 문법을 직접 작성하는 방식입니다. 가장 유연하고 빠르지만 문법 오류 발생 위험이 있으므로, 숙련된 개발자나 긴급 수정이 필요한 상황에서 권장됩니다.

기본 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PolicyIdentifier",
      "Effect": "Allow|Deny",
      "Principal": "* 또는 특정 ARN",
      "Action": "허용 작업",
      "Resource": "대상 리소스",
      "Condition": {
        "조건타입": {
          "조건키": "조건값"
        }
      }
    }
  ]
}

구성 요소 설명

Version: "2012-10-17" (고정값)
Statement: 정책 규칙들의 배열
Effect: "Allow" 또는 "Deny"
Action: 허용할 작업 (예: "s3:GetObject")
Resource: 적용 대상 리소스 ARN
- 버킷 자체: arn:aws:s3:::버킷명
- 객체 전체: arn:aws:s3:::버킷명/*
Principal: 접근 주체 (반드시 명시해야 함)
- * → 모든 사용자
- 특정 사용자: arn:aws:iam::계정ID:user/이름
- 특정 역할: arn:aws:iam::계정ID:role/역할명
Condition (선택): IP 제한, HTTPS 강제, 시간 제한 등
Sid (선택): 정책 문 단위 식별자 (관리·디버깅 목적)

실전 예제

예제 1. 웹사이트용 공개 읽기 (HTTPS 강제)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadOverTLS",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-website-bucket/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    }
  ]
}

⚠️ 주의: 퍼블릭 접근을 허용하려면 버킷의 ‘퍼블릭 액세스 차단(Block Public Access)’ 설정을 해제해야 정책이 적용됩니다. 보안상 권장되는 방식은 CloudFront + OAC(Origin Access Control)를 통한 공개입니다.

예제 2. 특정 사용자에게 전체 권한 부여

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UserFullAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/developer"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-dev-bucket",      // 버킷 수준
        "arn:aws:s3:::my-dev-bucket/*"     // 객체 수준
      ]
    }
  ]
}

버킷 수준(ListBucket)과 객체 수준(GetObject, PutObject 등)을 동시에 지정해야 정상적으로 동작합니다.

예제 3. 조건부 접근 제어 (보안 강화)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyOverTLS",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::secure-bucket/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" },
        "IpAddress": { "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"] },
        "DateGreaterThan": { "aws:CurrentTime": "2024-01-01T00:00:00Z" }
      }
    },
    {
      "Sid": "AllowUploadFromAppRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/WebAppRole"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::secure-bucket/uploads/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    }
  ]
}

⚠️ PutObject는 반드시 특정 IAM 사용자·역할로 제한해야 하며, 절대로 Principal: "*" 상태에서 허용하면 안 됩니다. (악성 업로드 위험)

⚡ 작성 팁 및 주의사항

ARN 형식: arn:aws:s3:::버킷명/* (콜론 3개 주의)
대소문자 구분: Action, Condition 키 값은 대소문자 정확히 입력해야 함
배열 문법: 단일 값이라도 배열로 작성 가능 → "Action": ["s3:GetObject"]

방법 2: 시각적 편집기 활용 (Edit statement)

개요

AWS 콘솔에 내장된 GUI 기반 편집기를 활용하여 정책을 작성하는 방법입니다. 직관적인 화면을 통해 JSON 문법을 몰라도 정책을 쉽게 작성할 수 있어, 초급자나 학습용으로 적합합니다.

단계별 사용 방법

1. 버킷 정책 편집 페이지에서 [ 새 명령문 추가(Add new statement) ] 버튼을 클릭합니다.

영어 버전

한글 버전

2. 시각적 편집기에서 다음 항목들을 단계별로 입력합니다.

Step 1. 기본 정보 설정

필드	예시	설명
Sid	PublicWebsiteAccess	정책 문 단위 식별자 (영문/숫자)
Effect	Allow / Deny	권한 허용 또는 거부 선택

Step 2. 접근 주체(Principal) 설정

옵션	입력 형식	사용 사례
모든 사용자	*	웹사이트 공개 읽기(주의 필요)
특정 AWS 계정	arn:aws:iam::123456789012:role/PartnerAccessRole	파트너 계정 권한 부여
특정 사용자	arn:aws:iam::123456789012:user/app-user	내부 개발자 전용
특정 역할	arn:aws:iam::123456789012:role/WebAppRole	애플리케이션 권한 위임

⚠️ root 계정(:root) 사용은 보안상 지양해야 하며, 반드시 Role/User ARN을 활용하는 것이 안전합니다.

Step 3. 작업(Actions) 선택

권한 그룹	Actions	용도
읽기 권한	GetObject, GetObjectVersion	파일 다운로드 및 메타데이터 조회
쓰기 권한	PutObject	파일 업로드
목록 권한	ListBucket, ListBucketVersions	버킷 내 파일 목록 조회
삭제 권한	DeleteObject, DeleteObjectVersion	객체 및 버전 삭제
전체 권한	s3:*	모든 S3 작업 허용 (주의)

⚠️ *Acl 계열 액션은 ACL 비활성(Object Ownership: Bucket owner enforced) 환경에서는 불필요합니다.

Step 4. 리소스(Resources) 지정

패턴	ARN 형식	적용 범위
버킷 자체	arn:aws:s3:::버킷명	ListBucket 같은 버킷 수준 작업
모든 객체	arn:aws:s3:::버킷명/*	버킷 내 모든 파일 접근
특정 폴더	arn:aws:s3:::버킷명/images/*	폴더 단위 권한 분리
특정 파일	arn:aws:s3:::버킷명/file.jpg	개별 객체 권한 지정

Step 5. 조건(Condition) 설정 (선택 사항)

조건 타입	키	예시	설명
IpAddress	aws:SourceIp	203.0.113.0/24	특정 IP 대역 제한
Bool	aws:SecureTransport	true	HTTPS 강제
StringLike	s3:prefix	user-uploads/*	ListBucket 결과 필터링 전용
DateGreaterThan	aws:CurrentTime	2024-01-01T00:00:00Z	시간 기반 제한

⚠️ s3:prefix 조건은 ListBucket 액션에서만 동작합니다. GetObject/PutObject 제한은 리소스 ARN을 통해 경로별로 지정해야 합니다.

2-1. "Sid", "Principal", "Effect"을 차례대로 입력합니다.

Sid: ObjectReadWriteAccesss
Principal: *
Effect: Allow

2-2. "Actions"에 GetObject, PutObject를 적용합니다.

우측 "작업 추가"에서 GetObject을 검색한 뒤, 선택합니다.

우측 "작업 추가"에서 PutObject을 검색한 뒤, 선택합니다.

2-3. "Resource"에 arn:aws:s3:::버킷명/*을 적용합니다.

버킷 내 모든 파일 접근할 수 있게 할 것입니다.

우측 "리소스 추가"에서 추가 버튼을 클릭하여, 아래와 같이 선택합니다.

2-4. 조건은 선택 사항이므로 추가하지 않겠습니다.

3. JSON 미리 보기에서 생성된 정책을 확인하고, [ 변경 사항 저장(Save changes) ] 버튼을 클릭합니다.

필요시 추가 statement를 더 생성할 수 있습니다.

4. 정책 적용이 완료됩니다.

실시간 미리 보기 활용

편집기 좌측의 JSON 미리보기 영역에서

설정 즉시 JSON 코드 확인 가능
문법 오류 실시간 감지
완성된 JSON 코드 복사하여 재사용 가능

방법 3: AWS Policy Generator 활용

️ 개요

AWS Policy Generator는 공식적으로 제공되는 정책 생성 도구로, JSON 문법에 익숙하지 않은 사용자도 쉽게 정책을 만들 수 있습니다.
문법 오류를 방지할 수 있다는 점에서 안전하지만, 최신 조건 키나 세부 기능은 모두 지원하지 않을 수 있으므로 생성 후 반드시 검증이 필요합니다.

접근 방법

S3 콘솔에서: 버킷 정책 편집 화면 → 정책 생성기(Policy Generator) 버튼 클릭
직접 접근: AWS Policy Generator

AWS Policy Generator

awspolicygen.s3.amazonaws.com

단계별 사용 방법

1. 버킷 정책 편집 화면에서 [ 정책 생성기(Policy Generator) ] 버튼을 클릭합니다.

2. 새 탭에서 열린 AWS Policy Generator에서 정책을 설정합니다.

Step 1. 정책 유형 선택

Select Type of Policy → S3 Bucket Policy 선택

Step 2. 권한 상세 설정

기본 설정

필드	값	설명
Effect	Allow / Deny	권한 허용/거부
Principal	* 또는 ARN	접근 주체 (*는 모든 사용자 공개 → 주의 필요, 일반적으로 IAM Role/User ARN 사용)

Actions 선택

용도	Actions
읽기 전용	GetObject
업로드 전용	PutObject
업로드+읽기	GetObject, PutObject
목록 조회	ListBucket
전체 권한	s3:* (모든 S3 작업)

ARN 입력 예시

범위	ARN 형식	설명
버킷 자체	arn:aws:s3:::버킷명	버킷 수준 작업
모든 객체	arn:aws:s3:::버킷명/*	버킷 내 모든 파일
특정 폴더	arn:aws:s3:::버킷명/folder/*	폴더 단위 접근 제어
특정 파일	arn:aws:s3:::버킷명/file.jpg	개별 객체 제어

ARN을 잘못 입력하면 정책이 적용되지 않으므로, 반드시 정확한 형식으로 작성해야 합니다.

Step 3. 조건 설정 (선택 사항)

Generator는 제한된 조건만 제공합니다. (IP, HTTPS, Date 등)
복잡한 조건은 생성된 JSON을 직접 수정해야 합니다.

예시:

IP 제한 → IpAddress: aws:SourceIp = 203.0.113.0/24
HTTPS 강제 → Bool: aws:SecureTransport = true
시간 제한 → DateGreaterThan: aws:CurrentTime = 2024-01-01T09:00:00Z

3. [ Add Statement ]를 클릭하여 규칙을 추가합니다.

4. [ Generate Policy ]를 클릭하여 JSON 정책을 생성합니다.

5. 생성된 JSON을 복사합니다.

6. JSON을 S3 콘솔 정책 편집기에 붙여넣고, [ 변경 사항 저장 ] 버튼을 클릭합니다.

7. 정책 적용이 완료됩니다.

✅ Policy Generator 장점과 한계

장점

JSON 문법 오류 방지 (완벽한 JSON 생성)
단계별 가이드 제공 → 초보자도 쉽게 작성 가능
생성된 정책을 템플릿으로 재사용 가능

한계

최신 IAM/S3 조건 키 일부 미지원
복잡한 정책은 생성 후 직접 JSON 수정 필요

정책 생성기에 대한 자세한 설명은 아래 글을 읽어보세요.

https://bu119.tistory.com/159

[AWS] Amazon S3 버킷 정책 생성기 사용 가이드

AWS Policy Generator는 복잡한 JSON 정책을 직접 작성하지 않고도 GUI를 통해 쉽게 AWS 정책을 생성할 수 있는 공식 도구입니다. 특히 S3 버킷 정책 생성에 매우 유용합니다. 1. AWS Policy Generator 접근 방법AW

bu119.tistory.com

상황별 추천 워크플로우

긴급 수정 (빠른 대응 필요)

방법 추천: 직접 JSON 작성
이유: 빠르게 정책을 수정할 수 있고, 복잡한 조건도 즉시 반영 가능

예시:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::urgent-bucket/*"
    }
  ]
}

학습 목적 (정책 구조 이해)

방법 추천: 시각적 편집기
이유: JSON 문법을 몰라도 GUI로 쉽게 작성 가능, 실시간 JSON 미리보기 제공

️ 프로덕션 환경 (정확성 최우선)

방법 추천: Policy Generator → JSON 검증 → 동료 리뷰 후 적용
이유: 문법 오류 방지 + 팀 내 표준화된 정책 관리 가능

팀 작업 표준화

Policy Generator로 표준 템플릿 생성
팀 정책 라이브러리 관리 (Git 저장소 등)
필요 시 직접 JSON 수정으로 커스터마이징

권장 학습 경로

수준	추천 순서	목적
초급자	Policy Generator → 시각적 편집기 → 직접 JSON	안전하게 학습, 단계적 성장
중급자	시각적 편집기 → 직접 JSON → Policy Generator(검증용)	효율성과 정확성 균형
고급자	직접 JSON → (복잡한 경우만) Policy Generator	최대 효율성 추구

실무 모범 사례

보안 기본 원칙

최소 권한 원칙(Principle of Least Privilege)
명시적 거부(Explicit Deny) 활용 → 불필요한 권한 확장 방지
HTTPS 전송 강제 (aws:SecureTransport) → 평문 HTTP 차단
퍼블릭 액세스 차단(Block Public Access) 설정 확인

️ 정책 관리 팁

Sid 규칙: 작업_대상_환경 형태 권장 (예: Allow_WebApp_Read_Prod)
문서화: 정책에 주석은 불가능하므로, JSON 외부에 설명 파일을 반드시 관리
버전 관리: Git 저장소에 정책 파일 보관

결론

초급자: Policy Generator 또는 시각적 편집기부터 시작
실무 운영: Policy Generator + JSON 수동 수정 + Access Analyzer 검증
항상 확인할 것: 최소 권한, HTTPS 강제, 퍼블릭 액세스 차단

각 방법은 고유한 장점과 적절한 사용 상황이 있습니다. 처음에는 안전한 도구를 활용해 구조를 익히고, 점차 직접 JSON 작성으로 발전하는 것을 권장합니다.

무엇보다 “보안과 정확성”을 최우선으로 두고, 상황에 맞는 방법을 선택하는 것이 S3 버킷 정책 작성의 핵심입니다.

[AWS] Amazon S3 버킷 정책(Bucket Policy) 설정하기

bu119 — Tue, 26 Aug 2025 09:00:54 +0900

Amazon S3 버킷 정책은 버킷과 객체에 대한 접근 제어를 JSON 형식으로 정의하는 보안 기능입니다.
S3는 기본적으로 외부 접근이 차단되어 있기 때문에, 웹사이트 호스팅, 파일 업로드/다운로드, 특정 사용자 권한 부여 등의 상황에서 반드시 버킷 정책을 설정해야 합니다.

이번 글에서는 AWS 콘솔에서 버킷 정책을 단계별로 설정하는 방법과 실무에서 자주 사용하는 정책 예제를 정리합니다.

️ 사전 준비사항

퍼블릭 액세스 차단 확인

새로 생성된 S3 버킷은 기본적으로 퍼블릭 액세스 차단(Block Public Access) 이 활성화됩니다
외부 접근이 필요한 경우 이 설정을 해제해야 합니다
⚠️ 주의: 보안 위험을 충분히 검토한 후 해제하세요

필요 권한 확인

버킷 정책 설정을 위해서는 s3:PutBucketPolicy 권한이 필요합니다
버킷 소유자 또는 해당 권한이 있는 IAM 사용자만 수정 가능합니다

⚙️ 버킷 정책 설정 방법

1️⃣ S3 콘솔 접속 및 버킷 선택

1. AWS 콘솔에서 S3 서비스로 이동합니다.

2. 정책을 적용할 버킷을 선택합니다.

2️⃣ 퍼블릭 액세스 차단 해제 (공개 정책이 필요한 경우)

1. 버킷 상세 페이지에서 [ 권한(Permissions) ] 탭을 클릭합니다.

2. 퍼블릭 액세스 차단(버킷 설정) 섹션에서 "비활성화" 상태로 설정되어있는 지 확인합니다.

⚠️ 주의: 퍼블릭 액세스 차단을 해제하면 보안 위험이 증가할 수 있습니다. 신중하게 설정하세요.

3. 공개 정책이 필요한 경우 "편집" 버튼을 클릭하여 차단 해제합니다.

3️⃣ 버킷 정책 편집 - 시각적 편집기 사용 (Edit statement)

버킷 정책 편집 화면에서 시각적 편집기를 사용하여 정책을 설정하는 실습을 진행하겠습니다.

1. 버킷 정책(Bucket policy) 섹션에서 [ 편집(Edit) ] 버튼을 클릭합니다.

2. [새 명령문 추가(Add new statement)] 버튼을 클릭합니다.

영어 버전

한글 버전

3. 시각적 편집기에서 다음 항목들을 순서대로 설정합니다.

Statement 설정 항목:

항목	항목 설명	예시	예시 설명
Sid	정책 식별자	ObjectReadWriteAccesss	읽기/쓰기 권한을 통합해서 부여하므로 직관적으로 작성
Effect	허용/거부 선택	Allow	허용 선택
Principal	접근 주체	*	모든 사용자에게 허용
Actions	S3 작업 선택	GetObject, PutObject	읽기, 쓰기 권한 부여
Resources	적용 대상	arn:aws:s3:::버킷명/*	버킷 내 모든 객체
Conditions	추가 조건 설정	설정 안함

Sid / Principal / Effect을 설정합니다.

Actions에서 GetObject를 설정합니다.

Actions에서 PutObject를 설정합니다.

Resources를 설정합니다.

4. JSON 미리보기에서 생성된 정책을 확인합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ObjectReadWriteAccess",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

5. [ 변경 사항 저장(Save changes) ] 버튼을 클릭합니다.

필요 시 추가 statement를 더 생성할 수 있습니다.

6. 정책 적용이 완료됩니다.

정책 작성 방법 3가지

실습에서 사용한 시각적 편집기 외에도 다른 방법들도 알아두면 유용합니다:

방법 1: 직접 JSON 작성

장점: 빠른 작성, 세밀한 제어 가능
단점: JSON 문법 숙지 필요
추천: JSON에 익숙한 개발자

기본 JSON 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "정책식별자",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::버킷명/*"
    }
  ]
}

JSON 구성 요소

Version: 정책 버전 (고정값: "2012-10-17")
Sid: Statement 식별자 (선택사항)
Effect: Allow(허용) 또는 Deny(거부)
Principal: 접근 주체 ("*"는 모든 사용자)
Action: 허용할 S3 작업 목록
Resource: 정책 적용 대상 ARN

방법 2: AWS 정책 생성기 (Policy Generator)

장점: GUI 기반, 문법 오류 방지
단점: 별도 도구 사용 필요
추천: 정확한 문법이 중요한 경우

버킷 정책 편집 화면에서 [정책 생성기(Policy Generator)] 버튼을 클릭하여 외부 도구로 정책을 생성한 후 복사하여 사용할 수 있습니다.

실전 정책 예제

예제 1: 정적 웹사이트용 공개 읽기 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForWebsite",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-website-bucket/*"
    }
  ]
}

예제 2: IP 제한이 있는 읽기/쓰기 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OfficeIPOnlyAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-private-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

예제 3: HTTPS 연결 강제 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureConnections",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-secure-bucket",
        "arn:aws:s3:::my-secure-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

⚠️ 문제 해결 및 보안 모범 사례

자주 하는 실수와 해결법

ARN 형식 오류
- ❌ 잘못된 예: arn:aws:s3::my-bucket/*
- ✅ 올바른 예: arn:aws:s3:::my-bucket/* (콜론 3개)
Resource 타입 혼동
- 버킷 자체: arn:aws:s3:::my-bucket (ListBucket 작업 시)
- 버킷 내 객체: arn:aws:s3:::my-bucket/* (GetObject/PutObject 시)
정책이 적용되지 않는 경우
- 퍼블릭 액세스 차단 설정 확인
- JSON 문법 오류 검증
- 필요 권한 보유 여부 확인

정책 테스트 방법

브라우저 직접 접근: https://버킷명.s3.amazonaws.com/파일명
AWS CLI 테스트: aws s3 ls s3://버킷명/
IAM 정책 시뮬레이터: AWS 콘솔에서 정책 동작 검증

보안 모범 사례

최소 권한 원칙 적용
- 필요한 최소한의 권한만 부여
- 정기적으로 불필요한 권한 제거

조건부 접근 제어 활용

"Condition": {
  "IpAddress": {"aws:SourceIp": "허용할IP대역"},
  "Bool": {"aws:SecureTransport": "true"},
  "DateGreaterThan": {"aws:CurrentTime": "2024-01-01T00:00:00Z"}
}

정기적인 정책 검토
- 분기별 정책 검토 및 업데이트
- CloudTrail 로그를 통한 접근 모니터링
- 불필요한 공개 권한 제거

✅ 정책 설정 체크리스트

설정 완료 후 다음 사항들을 반드시 확인하세요:

퍼블릭 액세스 차단 설정 검토
JSON 문법 오류 없음
실제 접근 테스트 수행
최소 권한 원칙 준수
조건부 제어 적용 (필요시)
정책 문서화 및 버전 관리

S3 버킷 정책은 누가, 언제, 어떤 조건에서, 어떤 리소스에 접근할 수 있는지를 제어하는 핵심 보안 도구입니다. 정책 설정 후에는 반드시 실제 테스트를 통해 의도한 대로 동작하는지 확인하고, CloudTrail을 통해 지속적으로 모니터링하는 것이 중요합니다.

참고 문서

[AWS] Amazon S3 버킷 정책(Bucket Policy) 이해하기

bu119 — Sat, 23 Aug 2025 19:00:06 +0900

Amazon S3는 파일(객체)을 저장하는 AWS의 대표적인 클라우드 스토리지 서비스입니다. 하지만 기본적으로 S3 버킷은 보안을 위해 외부에서 접근할 수 없도록 잠겨 있습니다.

실제 서비스 운영에서는 상황에 따라 접근 권한을 세밀하게 제어해야 할 때가 있습니다. 이때 필요한 것이 바로 S3 버킷 정책(Bucket Policy)입니다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html

Bucket policies for Amazon S3 - Amazon Simple Storage Service

You can't use a bucket policy to prevent deletions or transitions by an S3 Lifecycle rule. For example, even if your bucket policy denies all actions for all principals, your S3 Lifecycle configuration still functions as normal.

docs.aws.amazon.com

언제 버킷 정책이 필요할까요?

정적 웹사이트 호스팅: 이미지, CSS, JS 파일을 누구나 볼 수 있게 공개
팀 협업: 특정 IAM 사용자나 그룹에게만 업로드/다운로드 권한 부여
보안 강화: 특정 IP 주소나 VPC에서만 접근 가능하도록 제한
교차 계정 액세스: 다른 AWS 계정과 안전하게 리소스 공유

S3 버킷 정책이란?

Amazon S3를 인터넷상의 거대한 창고라고 생각해보세요.

여기서 버킷(Bucket)은 창고 안의 각각의 방이고, 버킷 정책(Bucket Policy)은 누가 이 방에 들어올 수 있는지, 무엇을 할 수 있는지를 정하는 세부 규칙입니다.

핵심 특징

JSON 형식으로 작성되는 권한 제어 문서
버킷 단위로 적용되는 보안 규칙
"누가" → "어떤 작업" → "어떤 리소스"에 → "허용/거부"할지를 정의
IAM 정책과 유사하지만 버킷 자체에 직접 연결되는 정책

왜 버킷 정책이 중요한가?

보안: 민감한 데이터를 무단 접근으로부터 보호
접근 제어: 세밀한 권한 관리로 최소 권한 원칙 구현
비용 최적화: 불필요한 접근 차단으로 데이터 전송 비용 절약
규정 준수: 기업 보안 정책 및 컴플라이언스 요구사항 충족

️ 버킷 정책의 구조

S3 버킷 정책은 JSON 형식으로 작성되며, 다음과 같은 기본 구조를 가집니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

주요 구성 요소

요소	역할	설명	예시
Version	정책 언어 버전	AWS 정책 문법 버전 지정	"2012-10-17" (고정값)
Statement	규칙 집합	하나 이상의 권한 규칙 포함	배열 형태
Effect	허용/거부	명령의 최종 결과	"Allow" 또는 "Deny"
Principal	접근 주체	누가 접근할 수 있는지	"*" (모든 사용자)
Action	허용할 작업	어떤 S3 작업을 허용할지	"s3:GetObject"
Resource	대상 리소스	어떤 버킷/객체에 적용할지	"arn:aws:s3:::bucket/*"
Condition	추가 조건	언제, 어떤 상황에서 적용할지	IP 제한, 시간 제한 등

각 요소 상세 설명

Version (버전)

항상 "2012-10-17" 사용 (최신 정책 언어 버전)
다른 값 사용 시 일부 기능 제한 가능

Effect (효과)

"Allow": 권한 허용 (일반적 사용)
"Deny": 권한 거부 (명시적 차단)

⚠️ 중요: Deny가 Allow보다 항상 우선순위가 높음

Principal (주체)

// 모든 사용자 (공개 액세스)
"Principal": "*"

// 특정 AWS 계정
"Principal": {"AWS": "arn:aws:iam::123456789012:root"}

// 특정 IAM 사용자
"Principal": {"AWS": "arn:aws:iam::123456789012:user/username"}

// 특정 IAM 역할
"Principal": {"AWS": "arn:aws:iam::123456789012:role/rolename"}

Action (작업)

읽기 권한

s3:GetObject: 파일 다운로드
s3:ListBucket: 버킷 내용 목록 조회

쓰기 권한

s3:PutObject: 파일 업로드
s3:DeleteObject: 파일 삭제

관리 권한

s3:*: 모든 S3 작업 (주의해서 사용)

Resource (리소스)

// 버킷 자체 (ListBucket 등)
"Resource": "arn:aws:s3:::your-bucket-name"

// 버킷 내 모든 객체
"Resource": "arn:aws:s3:::your-bucket-name/*"

// 특정 폴더만
"Resource": "arn:aws:s3:::your-bucket-name/images/*"

// 여러 리소스
"Resource": [
  "arn:aws:s3:::your-bucket-name",
  "arn:aws:s3:::your-bucket-name/*"
]

Condition (조건)

IP 주소 제한

"Condition": {
  "IpAddress": {
    "aws:SourceIp": "203.0.113.0/24"
  }
}

시간 제한

"Condition": {
  "DateGreaterThan": {"aws:CurrentTime": "2025-01-01T00:00:00Z"},
  "DateLessThan": {"aws:CurrentTime": "2025-12-31T23:59:59Z"}
}

HTTPS 강제

"Condition": {
  "Bool": {
    "aws:SecureTransport": "true"
  }
}

실무에서 자주 사용하는 정책 예제

https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html

Examples of Amazon S3 bucket policies - Amazon Simple Storage Service

We recommend that you use caution when using the aws:Referer condition key. It is dangerous to include a publicly known HTTP referer header value. Unauthorized parties can use modified or custom browsers to provide any aws:Referer value that they choose. T

docs.aws.amazon.com

1. 정적 웹사이트 공개 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-website-bucket/*"
    }
  ]
}

2. 특정 IP에서만 접근 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"]
        }
      }
    }
  ]
}

3. HTTPS 연결 강제

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket",
        "arn:aws:s3:::your-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

4. 특정 사용자에게 전체 권한 부여

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/developer"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket",
        "arn:aws:s3:::your-bucket/*"
      ]
    }
  ]
}

⚠️ 주의사항 및 베스트 프랙티스

보안 주의사항

공개 액세스 최소화: "Principal": "*" 사용 시 신중하게 검토
최소 권한 원칙: 필요한 최소한의 권한만 부여
Deny 정책 우선: 보안상 중요한 리소스는 명시적으로 Deny 규칙 추가

정책 작성 팁

Sid 추가: 각 Statement에 설명적인 Sid(Statement ID) 포함
조건 활용: IP, 시간, 암호화 등 추가 보안 조건 적극 활용
정기 검토: 정책을 주기적으로 검토하여 불필요한 권한 제거

문제 해결

정책 충돌: IAM 정책과 버킷 정책이 충돌할 때는 더 제한적인 정책이 우선
JSON 문법 오류: AWS Policy Generator 활용으로 문법 오류 방지
권한 테스트: 정책 적용 후 실제 접근 테스트로 동작 확인

마무리

S3 버킷 정책은 클라우드 보안의 핵심 요소입니다. 올바른 정책 설정을 통해 데이터를 안전하게 보호하면서도 필요한 접근성을 확보할 수 있습니다.

이 글에서 다룬 기본 구조와 예제들을 참고하여 여러분의 요구사항에 맞는 버킷 정책을 작성해보세요. 항상 최소 권한 원칙을 기억하고, 정기적인 정책 검토를 통해 안전한 AWS 환경을 유지하시기 바랍니다.

다음 글에서는 AWS 콘솔에서 실제로 이러한 정책들을 설정하는 방법을 스크린샷과 함께 자세히 알아보겠습니다.

https://bu119.tistory.com/132

[AWS] Amazon S3 버킷 정책(Bucket Policy) 설정하기

Amazon S3는 파일(객체)을 저장하는 AWS의 대표적인 클라우드 스토리지 서비스입니다. 하지만 기본적으로 S3 버킷은 보안을 위해 외부에서 접근할 수 없도록 잠겨 있습니다.실제 서비스 운영에서는

bu119.tistory.com

참고 문서

[AWS] Amazon S3 버킷 정책 생성기 사용 가이드

bu119 — Wed, 20 Aug 2025 19:00:08 +0900

AWS Policy Generator는 복잡한 JSON 정책을 직접 작성하지 않고도 GUI를 통해 쉽게 AWS 정책을 생성할 수 있는 공식 도구입니다. 특히 S3 버킷 정책 생성에 매우 유용합니다.

1. AWS Policy Generator 접근 방법

AWS Policy Generator는 https://awspolicygen.s3.amazonaws.com/policygen.html에서 접근할 수 있으며, AWS 콘솔 로그인 없이도 사용 가능합니다.

2. 정책 생성기 구성 요소 설명

1️⃣ Step 1: 정책 유형 선택 (Select Policy Type)

Type of Policy (정책 유형)

정책 생성기에서 지원하는 정책 유형들과 각각의 사용 목적:

1. S3 Bucket Policy

용도: S3 버킷과 객체에 대한 접근 권한 제어
적용 대상: 특정 S3 버킷
주요 사용 사례:
- 정적 웹사이트 퍼블릭 액세스
- 특정 사용자/역할에게만 버킷 접근 허용
- CloudFront와 연동한 원본 버킷 보안

2. IAM Policy

용도: 사용자, 그룹, 역할에 부여할 권한 정책
적용 대상: IAM 엔터티
주요 사용 사례:
- 개발팀별 리소스 접근 권한 분리
- 최소 권한 원칙 적용

3. SNS Topic Policy

용도: SNS 주제에 대한 구독/발행 권한
적용 대상: SNS 주제
주요 사용 사례:
- 다른 AWS 계정과 알림 공유
- 애플리케이션 간 메시징

4. SQS Queue Policy

용도: SQS 대기열 접근 권한
적용 대상: SQS 대기열
주요 사용 사례:
- 서비스 간 비동기 통신 권한 관리

5. VPC Endpoint Policy

용도: VPC 엔드포인트를 통한 서비스 접근 제어
적용 대상: VPC 엔드포인트
주요 사용 사례:
- 프라이빗 네트워크에서 AWS 서비스 접근 제어

2️⃣ Step 2: 정책 명령문 구성 (Add Statements)

Effect (효과)

정책의 기본 동작을 결정하는 핵심 요소:

1. Allow (허용)

"Effect": "Allow"

명시적으로 작업을 허용
기본적으로 모든 작업이 거부되므로 필요한 작업만 허용
사용 예시: 읽기 전용 액세스, 특정 폴더 업로드 권한

2. Deny (거부)

"Effect": "Deny"

명시적으로 작업을 거부
Allow보다 우선순위가 높음
사용 예시: 특정 IP 차단, 삭제 작업 금지, 민감한 폴더 접근 차단

Principal (보안 주체)

정책이 적용될 대상을 지정하는 중요한 필드:

1. 모든 사용자 (퍼블릭 액세스)

"Principal": "*"

주의사항: 인터넷의 모든 사용자가 접근 가능
사용 사례: 정적 웹사이트, 공개 다운로드 파일

2. 특정 AWS 계정

"Principal": {
  "AWS": "arn:aws:iam::123456789012:root"
}

사용 사례: 다른 AWS 계정과 리소스 공유

3. 특정 IAM 사용자

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/username"
}

4. 특정 IAM 역할

"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/rolename"
}

5. AWS 서비스

"Principal": {
  "Service": "cloudfront.amazonaws.com"
}

Actions (작업)

S3에서 수행할 수 있는 주요 작업들:

1. 객체 관련 작업

s3:GetObject: 객체 읽기/다운로드
s3:PutObject: 객체 업로드/생성
s3:DeleteObject: 객체 삭제
s3:GetObjectAcl: 객체 ACL 조회
s3:PutObjectAcl: 객체 ACL 설정

2. 버킷 관련 작업

s3:ListBucket: 버킷 내용 목록 조회
s3:GetBucketLocation: 버킷 위치 정보 조회
s3:GetBucketVersioning: 버킷 버전 관리 상태 조회

3. 와일드카드 사용

s3:Get*: 모든 읽기 작업
s3:Put*: 모든 쓰기 작업
s3:*: 모든 S3 작업

Amazon Resource Name (ARN)

정책이 적용될 리소스를 정확히 지정:

1. 버킷 자체

arn:aws:s3:::my-bucket

버킷 속성 관련 작업에 사용 (ListBucket 등)

2. 버킷 내 모든 객체

arn:aws:s3:::my-bucket/*

객체 관련 작업에 사용 (GetObject, PutObject 등)

3. 특정 경로의 객체

arn:aws:s3:::my-bucket/uploads/*
arn:aws:s3:::my-bucket/public/images/*

4. 복수 리소스 지정

arn:aws:s3:::my-bucket
arn:aws:s3:::my-bucket/*

조건 추가 (Add Conditions) - 선택사항

조건을 통해 더욱 세밀한 접근 제어가 가능합니다. Policy Generator에서는 세 개의 필드로 조건을 설정합니다:

조건 설정 구성 요소

1. Condition (조건 연산자)

StringEquals: 문자열 정확 일치
StringLike: 와일드카드 패턴 매칭
IpAddress: IP 주소 범위 내
DateGreaterThan: 지정 날짜 이후
Bool: 불린 값 (true/false)
NumericLessThan: 지정 값보다 작음

2. Key (조건 키)

aws:CurrentTime: 현재 시간
aws:SourceIp: 요청자 IP 주소
aws:SecureTransport: HTTPS 사용 여부
s3:x-amz-server-side-encryption: S3 암호화 방식

3. Value (조건 값)

조건과 비교할 실제 값 입력
복수 값은 쉼표로 구분

주요 조건 활용 예시

예시 1: IP 주소 기반 제어

Condition: IpAddress
Key: aws:SourceIp
Value: 192.168.1.0/24,203.0.113.0/24

"Condition": {
  "IpAddress": {
    "aws:SourceIp": ["192.168.1.0/24", "203.0.113.0/24"]
  }
}

예시 2: 시간 기반 제어

Condition: DateGreaterThan
Key: aws:CurrentTime
Value: 2024-01-01T00:00:00Z

"Condition": {
  "DateGreaterThan": {
    "aws:CurrentTime": "2024-01-01T00:00:00Z"
  }
}

예시 3: HTTPS 연결만 허용

Condition: Bool
Key: aws:SecureTransport
Value: true

"Condition": {
  "Bool": {
    "aws:SecureTransport": "true"
  }
}

예시 4: 특정 암호화 요구

Condition: StringEquals
Key: s3:x-amz-server-side-encryption
Value: AES256

"Condition": {
  "StringEquals": {
    "s3:x-amz-server-side-encryption": "AES256"
  }
}

3. 실용적인 정책 예시

1. 정적 웹사이트 호스팅 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-website-bucket/*"
    }
  ]
}

2. CloudFront OAC (Origin Access Control) 정책 - 권장

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-private-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

3. CloudFront OAI (Origin Access Identity) 정책 - 레거시

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123456789"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-private-bucket/*"
    }
  ]
}

참고: OAI는 더 이상 권장되지 않으며, OAC(Origin Access Control) 사용을 권장합니다.

4. 개발팀 전용 업로드 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/DeveloperRole"
      },
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::dev-bucket/uploads/*"
    }
  ]
}

5. 읽기 전용 + IP 제한 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::secure-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

6. 멀티파트 업로드 지원 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/UploadRole"
      },
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::upload-bucket/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/UploadRole"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::upload-bucket"
    }
  ]
}

4. 정책 생성 및 적용 과정

정책 생성: "Generate Policy" 버튼 클릭
JSON 복사: 생성된 정책 JSON을 복사
S3 콘솔 이동: AWS S3 콘솔로 이동
버킷 선택: 정책을 적용할 버킷 선택
권한 탭: "Permissions" 탭 클릭
버킷 정책: "Bucket Policy" 섹션에서 "Edit" 클릭
정책 붙여넣기: 생성한 JSON 정책 붙여넣기
저장: "Save changes" 클릭

5. 보안 모범 사례

1. 최소 권한 원칙

꼭 필요한 권한만 부여
와일드카드(*) 사용 최소화
정기적인 권한 검토

2. Principal 설정 주의사항

"Principal": "*"는 신중히 사용
특정 계정이나 역할로 제한 권장
서비스 간 통신에는 역할 기반 접근

3. 조건 활용

IP 주소 제한으로 보안 강화
SSL/HTTPS 강제로 데이터 보호
시간 기반 접근 제어로 임시 권한 부여

4. 정책 테스트

AWS IAM Policy Simulator로 사전 테스트
단계적 적용으로 영향도 확인
CloudTrail 로그 모니터링으로 정책 효과 검증

5. 버킷 퍼블릭 액세스 설정

S3 버킷의 "Block Public Access" 설정과 정책이 상충되지 않도록 주의
퍼블릭 정책 적용 시 해당 설정 해제 필요

6. 문제 해결

1. 접근 거부 오류 (Access Denied)

버킷 퍼블릭 액세스 차단 설정 확인: 버킷 레벨의 "Block Public Access" 설정
정책 구문 오류 검사: JSON 형식 및 구문 확인
ARN 형식 정확성 확인: 버킷명, 경로 등 정확성 검증
Principal과 Actions 일치 여부 확인: 권한 주체와 작업의 논리적 일치성

2. 정책 적용 안 됨

정책 저장 후 전파 대기: 정책 변경 사항 전파에 수 분 소요
CloudFront 캐시 무효화: CDN 캐시로 인한 이전 정책 적용
브라우저 캐시 삭제: 클라이언트 측 캐시 문제

3. 조건부 정책 작동 안 함

조건 키 정확성 확인: AWS에서 지원하는 조건 키인지 확인
대소문자 구분: 조건 연산자와 값의 대소문자 정확성
데이터 타입 일치: 문자열, 숫자, 불린 등 데이터 타입 정확성

7. 고급 사용 팁

1. 다중 명령문(Statement) 활용

하나의 정책에 여러 명령문을 포함하여 복잡한 권한 구조 구현 가능

2. 정책 크기 제한

버킷 정책 최대 크기: 20KB
복잡한 정책의 경우 IAM 정책 분할 고려

3. 정책 버전 관리

"Version": "2012-10-17" 사용 권장
이전 버전 사용 시 일부 기능 제한 가능

4. 조건 연산자 활용

StringLike, StringNotLike: 와일드카드 패턴 매칭
NumericLessThan, NumericGreaterThan: 숫자 범위 조건
DateLessThan, DateGreaterThan: 시간 범위 조건

AWS Policy Generator를 활용하면 복잡한 S3 버킷 정책도 GUI를 통해 쉽게 생성할 수 있으며, 다양한 보안 요구사항을 효과적으로 구현할 수 있습니다. 정책 생성 후에는 반드시 테스트를 통해 의도한 대로 작동하는지 확인하는 것이 중요합니다.

[AWS] Amazon S3 Bucket 생성하기

bu119 — Wed, 13 Aug 2025 18:00:33 +0900

1. 버킷(Bucket)이 필요한 이유?

Amazon S3에서 버킷(Bucket)은 모든 파일(객체)을 담는 최상위 폴더이자 저장 공간입니다.

쉽게 말해 "S3에서 나만의 클라우드 하드디스크 폴더"라고 생각하면 됩니다.

왜 버킷을 사용해야 할까?

이미지, 동영상, 문서, 백업 파일 등을 안전하게 보관
프로젝트별·서비스별로 독립 관리 가능 → 환경(개발/운영) 별로 분리해서 관리하기 좋음
접근 권한, 버전 관리, 암호화 등 보안 설정을 버킷 단위로 적용 가능

2. 버킷 생성 절차

S3 버킷을 만드는 순서는 다음과 같습니다.

AWS S3 콘솔 접속
버킷 만들기(Create bucket)
이름 / 리전 설정
객체 소유권(ACL) 설정
퍼블릭 접근 차단 여부 선택
버전 관리·태그·암호화 설정
버킷 생성 완료

3. 버킷 생성 방법

1️⃣ S3 콘솔 접속

1. AWS Management Console 상단 검색창에 S3 입력 후 서비스에서 [ S3 ]를 클릭합니다.

2. S3 콘솔에서 [ 버킷 만들기 (Create bucket) ]를 클릭합니다.

2️⃣ 버킷 만들기

1. 일반 구성

전 세계에서 유일한 버킷 이름을 입력합니다.

AWS 리전

데이터를 저장할 물리적 위치
한국 서비스 → Asia Pacific (Seoul) ap-northeast-2 권장
이유: 사용자와 가까울수록 속도가 빠르고 데이터 전송 비용이 절감됨

버킷 이름

전 세계에서 유일해야 함 → S3는 전 세계적으로 이름이 겹치면 안 되기 때문
소문자, 숫자, 하이픈(-)만 가능 → 예) my-service-bucket, project2025-storage

2. 객체 소유권 (ACL)

[ ACL 비활성화 (AWS 권장) ]을 선택합니다.

ACL 비활성화 (AWS 권장) ✅

모든 객체를 버킷 소유 계정이 소유하게 하여 권한 관리가 단순해짐
권한 부여는 IAM 정책 / 버킷 정책으로만 제어

2ACL 활성화

업로드하는 계정이 객체를 소유해야 하는 특수 상황(레거시 시스템)에서 사용

3. 이 버킷의 퍼블릭 액세스 차단 설정 (퍼블릭 접근 차단)

모든 퍼블릭 액세스 차단: 체크해제
현재 설정으로 인해 이 버킷과 그 안에 포함된 객체가 퍼블릭 상태가 될 수 있음을 알고 있습니다.: 체크✅

퍼블릭 액세스 차단을 모두 해제하면, 직접 S3에 접근할 수 있는 URL을 입력하여 이미지가 정상적으로 업로드될 수 있도록 할 수 있습니다.

모든 퍼블릭 액세스 차단 (기본: 체크)

기본 상태(체크)
외부(인터넷)에서 버킷과 객체에 접근 불가능 → 보안 안전
체크 해제 시
버킷과 객체가 퍼블릭 상태가 될 수 있음
URL로 직접 접근해 이미지를 불러올 수 있게 됨
→ 정적 웹사이트, 이미지 CDN 등 공개 파일 제공 시 사용

체크 해제 후 나타나는 확인 옵션

체크를 해제하면 AWS가 보안 경고 문구를 보여줍니다.
이때 [ 현재 설정으로 인해 퍼블릭 상태가 될 수 있음을 알고 있습니다 ]에 체크해야 계속 진행할 수 있습니다.

모든 퍼블릭 액세스 차단 – 4가지 세부 옵션 상세 설명

핵심 개념

ACL (Access Control List) → 객체나 버킷 단위로 접근 권한을 주는 오래된 방식.
버킷 정책 (Bucket Policy) / 액세스 지점 정책 → JSON 형식으로 접근 권한을 정의하는 방식.
“퍼블릭” → AWS 계정이 없는 익명 사용자도 접근 가능하다는 뜻.

옵션	의미	예시
새 ACL을 통한 퍼블릭 액세스 차단	새로 설정하는 ACL에서 퍼블릭 권한(AllUsers 또는 AuthenticatedUsers)을 주지 못하게 막음	새 파일을 올리면서 ACL을 퍼블릭 읽기로 주려고 하면 자동 차단
기존/임의 ACL을 통한 퍼블릭 액세스 차단	이미 있는 ACL이나 외부에서 설정된 ACL도 퍼블릭 권한이 있으면 무시	다른 AWS 계정이 ACL을 변경해 퍼블릭 권한을 주더라도 적용 안 됨
새 퍼블릭 버킷/액세스 지점 정책 차단	새로 만드는 버킷 정책이나 액세스 지점 정책에서 퍼블릭 허용 조건이 들어가면 거부	누군가 정책을 만들어 Principal: *(모든 사용자) 허용하려 하면 차단
기존/임의 퍼블릭 버킷/액세스 지점 정책 차단	이미 있는 정책이나 외부에서 만든 정책이 퍼블릭 허용이면 무시	예전에 만든 퍼블릭 정책을 그대로 두더라도 접근 불가

정리

"모든 퍼블릭 액세스 차단"을 켜면 위 4가지가 전부 활성화됩니다.
"모든 퍼블릭 액세스 차단"을 끄고, 세부 옵션만 골라서 켜면 더 유연하게 제어할 수 있습니다.
예: ACL 기반 퍼블릭은 막지만, 버킷 정책 기반 퍼블릭은 허용.

4. 버킷 버전 관리

버킷 버전 관리 [ 비활성화 ]를 선택합니다.

비활성화 (기본) ✅

장점: 비용 절감

활성화

장점: 파일이 실수로 삭제/덮어쓰기 된 경우 복원 가능
단점: 파일 버전이 누적되므로 저장 용량이 늘어나 비용 증가

5. 태그 - 선택사항

버킷이 많아졌을 때 검색·그룹화·비용 분석에 활용할 수 있습니다. → 예) project: pomorodo, env: production

6. 기본 암호화

[ Amazon S3 관리형 키(SSE-S3)를 사용한 서버 측 암호화 ]를 선택합니다.

암호화 유형

Amazon S3 관리형 키(SSE-S3)를 사용한 서버 측 암호화 ✅
- 설정이 간단하고 추가 비용 없음
AWS Key Management Service 키를 사용한 서버 측 암호화(SSE-KMS)
- 키 접근 권한까지 제어해야 하는 보안·규제 환경에서 사용
AWS Key Management Service 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS)
- 매우 민감한 데이터의 이중 암호화

버킷 키 (Bucket Key)

SSE-KMS/DSSE-KMS 사용 시 KMS 호출 비용 절감용 옵션

비활성화
활성화 ✅

7. [ 버킷 만들기 버튼 ] 클릭

3️⃣ 버킷 생성 완료

이제 S3에서 파일을 업로드하고 관리할 수 있습니다.

https://celdan.tistory.com/36

https://velog.io/@leeeeeyeon/AWS-S3%EB%A1%9C-%ED%8C%8C%EC%9D%BC-%EC%84%9C%EB%B2%84%EB%A5%BC-%EB%A7%8C%EB%93%A4%EC%96%B4%EB%B3%B4%EC%9E%90

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-S3-%EB%B2%84%ED%82%B7-%EC%83%9D%EC%84%B1-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%8B%A4%EC%A0%84-%EA%B5%AC%EC%B6%95

[인프라 구축] AWS Lightsail 서버에 가비아 도메인 연결하기 - 2025년 최신 가이드

bu119 — Tue, 12 Aug 2025 15:30:35 +0900

가비아에서 구매한 도메인을 AWS Lightsail 서버에 연결하면, IP 주소 대신 내가 원하는 주소(www.example.com)로 접속할 수 있습니다.
이 글에서는 가비아에서 구매한 도메인을 AWS Lightsail 서버에 연결하는 방법을 단계별로 설명합니다.

✅ 준비물

가비아에서 구매한 도메인 1개 (예: mydomain.com)
→ 인터넷 주소 이름입니다. 도메인 등록기관(가비아 등)에서 구매합니다.
AWS Lightsail 인스턴스 1개 (예: Ubuntu + Nginx, Apache 등 서버 환경)
→ 웹사이트나 앱이 실행되는 가상의 서버입니다.
Lightsail에서 고정 IP가 이미 생성되어 인스턴스에 연결되어 있어야 합니다.

https://bu119.tistory.com/112

[인프라 구축] 가비아 도메인 구매하기

가비아 사이트에 접속하여 도메인을 구매하기1. 가비아 사이트에 접속한다.https://www.gabia.com 웹을 넘어 클라우드로. 가비아그룹웨어부터 멀티클라우드까지 하나의 클라우드 허브www.gabia.com 2. 도

bu119.tistory.com

https://bu119.tistory.com/105

[인프라 구축] Amazon Lightsail 인스턴스 생성하기

토이프로젝트인 만큼 개발 비용을 최대한 아끼기 위해Amazon Lightsail의 "처음 3개월은 무료" 인스턴스 중 사양이 가장 높은 것을 선택할 것이다.Amazon Lightsail 인스턴스 생성하기 https://aws.amazon.com/ko/

bu119.tistory.com

1️⃣ Lightsail에서 고정 IP 생성

https://bu119.tistory.com/106

[인프라 구축] Amazon Lightsail, Networking 설정

고정 IP 주소 생성하기우선.. 네트워크 설정부터 하자. 고정 IP 주소를 생성할 것이다. 1. Create static IP을 클릭한다. 2. 인스턴스 연결 설정을 작성한다.인스턴스를 연결하고 고정 IP 이름을 지어

bu119.tistory.com

왜 고정 IP를 써야 하는가?
Lightsail 서버는 기본적으로 "임시 IP"를 부여합니다. 서버를 재부팅하면 이 IP가 변경될 수 있습니다.
고정 IP를 사용하면 언제나 동일한 주소로 접속할 수 있어 안정적인 서비스 운영이 가능합니다.

설정 방법

1. Lightsail 콘솔 접속 → 좌측 메뉴에서 [ 네트워킹(Networking) ] 을 클릭합니다.

2. 우측 상단에서 [ 고정 IP 생성(Create static IP) ] 을 클릭합니다.

3. 고정 IP를 연결할 인스턴스를 선택합니다.

4. 리소스 이름을 입력합니다. (예: pomorodo-ip)

→ 해당 고정 IP를 식별할 수 있도록, 리전 내에서 고유한 리소스 이름을 입력합니다.

5. [ 생성(Create) ] 버튼을 클릭합니다.

→ 예시: 13.124.56.78 (고정 IP)

2️⃣ Lightsail DNS 영역 생성

DNS 영역이란?
DNS(Domain Name System)는 사람이 기억하기 쉬운 도메인 이름(example.com)을 컴퓨터가 이해하는 IP 주소(13.124.56.78)로 변환하는 “전화번호부” 역할을 합니다.
DNS 영역을 생성하면 AWS에서 이 전화번호부를 직접 관리하게 됩니다.

설정 방법

1. Lightsail 콘솔 접속 → 좌측 메뉴 [ 도메인 및 DNS ] 를 클릭합니다.

2. [ DNS 영역 생성(Create DNS Zone) ] 을 클릭합니다.

3. 구매한 도메인 정보 입력하고, DNS 영역을 생성합니다.

도메인 소스: 다른 도메인 대행업체의 도메인 사용 선택
도메인 이름: 가비아에서 구매한 도메인 (예: mydomain.com)

4. 생성이 완료되면 도메인이 목록에 표시됩니다.

5. AWS에서 제공하는 네임서버(NS) 4개를 확인합니다.

이 네임서버를 가비아에 등록해야 합니다.

ns-123.awsdns-45.com
ns-234.awsdns-56.net
ns-345.awsdns-67.org
ns-456.awsdns-78.co.uk

3️⃣가비아에서 네임서버 변경

네임서버 변경이란?
도메인이 어느 DNS 서버를 참조할지를 지정하는 작업입니다.
AWS에서 제공한 네임서버로 변경해야 브라우저가 내 도메인을 입력했을 때 Lightsail 서버의 IP를 찾아올 수 있습니다.

설정 방법

1. 가비아 홈페이지 로그인 → [ My가비아 ] 로 이동합니다.

2. 상단 메뉴에서 [ 서비스 관리 ] 를 클릭합니다.

3. 하단의 이용중인 도메인 목록에서, 연결할 도메인을 선택하고 [ 관리 ]를 클릭합니다.

4. 네임서버 [ 설정 ]을 클릭합니다.

5. Lightsail에서 받은 네임서버 4개를 입력하고 저장합니다.

6. 변경 사항은 전 세계 DNS 서버에 전파되기까지 최대 24시간이 걸릴 수 있습니다. (일반적으로 1~2시간 내 적용됩니다)

4️⃣ Lightsail DNS에 레코드 추가

DNS 레코드란?
도메인 이름이 어떤 IP 주소를 가리킬지를 정의하는 규칙입니다.
예: www.mydomain.com → 13.124.56.78

설정 방법

도메인을 인스턴스에 연결하는 방법은 크게 두 가지가 있습니다.

AWS Lightsail > [ 인스턴스 ] > [ 도메인 ] > [ 도메인 할당 ]에서 연결하는 방법
AWS Lightsail > [ 도메인 및 DNS ] > [ DNS 레코드 ] > [ 레코드 추가 ] 에서 연결하는 방법

방법 1: 인스턴스 화면에서 도메인 할당 (간단 설정)

1. Lightsail 콘솔에서 [ 인스턴스 ] 탭으로 이동합니다.

2. 해당 인스턴스의 [ 관리 ] 버튼을 클릭합니다.

3. 상단 메뉴에서 [ 도메인 ]을 선택한 뒤 [ 도메인 할당 ]을 클릭합니다.

4. 사용할 도메인을 선택합니다.

5. 도메인 이름 및 주소 선택합니다.

mydomain.com을 이 인스턴스에서 사용할 도메인으로 선택했다면,

도메인 이름 선택: "mydomain.com" 루트 도메인(최상위) 선택
주소 선택: " 고정 IP 주소(IPv4) " 선택

① 도메인 이름 선택

mydomain.com: 루트 도메인(최상위)만 연결
mydomain.com의 하위 도메인: 특정 서브도메인 하나만 연결
mydomain.com의 모든 하위 도메인: 와일드카드(*) 방식으로 모든 하위 도메인 연결

정리

루트 도메인만 연결 → mydomain.com 선택
특정 서브도메인만 연결 → www.mydomain.com 또는 api.mydomain.com 등 선택
모든 하위 도메인 연결 → www.mydomain.com, api.mydomain.com, blog.mydomain.com 등 여러 개 서브도메인을 전부 연결 (루트는 별도 설정 필요)

선택 옵션	설명	✅ 연결 성공 예시	❌ 연결 실패 예시
mydomain.com	루트 도메인(최상위)만 연결	mydomain.com	www.mydomain.com api.mydomain.com
mydomain.com의 하위 도메인	특정 하위 도메인 하나만 연결	특정 하위 도메인으로 www.mydomain.com 선택 시, www.mydomain.com	mydomain.com blog.mydomain.com api.mydomain.com
mydomain.com의 모든 하위 도메인	와일드카드(*) 방식으로 모든 하위 도메인 연결	www.mydomain.com api.mydomain.com test.mydomain.com	mydomain.com (루트는 별도로 설정 필요)

② 주소 선택

실제로 연결할 서버 주소(IP 주소)를 선택합니다.

고정 IP 주소(IPv4) : Lightsail에서 생성한 고정 IPv4 주소 (권장) → 예: 13.124.56.78
IPv6 주소 : IPv6 환경에서만 필요 → 예: 2406:da1c:1234:abcd::1

권장
일반적인 웹사이트 운영이라면 고정 IP(IPv4) 만 선택해도 충분합니다. IPv6는 추가 지원이 필요할 때만 설정합니다.

선택 옵션	설명	예시	권장 여부
고정 IP 주소 (IPv4)	Lightsail에서 미리 생성하여 인스턴스에 연결한 IPv4 주소입니다. 도메인을 안정적으로 연결하려면 반드시 고정 IP를 선택하는 것이 좋습니다.	13.124.56.78	✅ 일반적인 웹서비스에서 기본 선택
IPv6 주소	IPv6 기반 네트워크 주소입니다. IPv6를 사용하는 환경(일부 해외 네트워크 등)에서만 필요합니다.	2406:da1c:...	⚠️ 특수 환경에서만 사용

6. 할당 완료 후 연결 상태를 확인합니다.

방법 2: 도메인 및 DNS에서 직접 레코드 추가 (세부 설정)

1. Lightsail 콘솔에서 [ 도메인 및 DNS ] 메뉴로 이동합니다.

2. 해당 도메인을 클릭합니다.

3. [ DNS 레코드 ] 탭의 [ 레코드 추가 (Add Record) ]를 클릭합니다.

4. 레코드 상세정보를 입력합니다.

레코드 유형: "A 레코드" 선택
레코드 이름: "@" 입력
확인: "고정 IP 주소" 입력

① 레코드 유형 (Record type)

도메인을 어떤 방식으로 연결할지 선택합니다.

A : IPv4 주소로 연결 (가장 일반적) → 예) 13.124.56.78
AAAA : IPv6 주소로 연결 → 예) 2406:da1c:1234:abcd::1
CNAME : 다른 도메인으로 연결 (별칭)
- IP 주소 대신 다른 도메인 이름을 가리킵니다.
- 예시 1 — @ 사용
  - www.mydomain.com → CNAME → @ → 루트 도메인(mydomain.com)과 같은 서버로 연결
- 예시 2 — 다른 도메인 직접 지정
  - blog.mydomain.com → CNAME → target.example.net → target 서버로 연결
- ⚠ 주의 : 루트 도메인(@)에는 CNAME을 설정할 수 없습니다. (www 등 서브도메인에서만 사용)
MX : 메일 서버 지정 → 예) 10 mail.example.com
- 우선순위(숫자) + 메일 서버 주소를 함께 입력
TXT : 소유권 인증, SPF/DKIM 설정 등 텍스트 값 저장 → 예) "google-site-verification=xxxx"

② 레코드 이름 (Record name / Host / Subdomain)

연결할 호스트 이름(서브도메인)을 입력합니다.

@ : 루트 도메인 → 예) mydomain.com
www : 예) www.mydomain.com
api : 예) api.mydomain.com

③ 값(Value / IP address or Target)

선택한 레코드 유형에 따라 연결 대상을 입력합니다.

A : IPv4 주소 → 예) 13.124.56.78
AAAA : IPv6 주소 → 예) 2406:da1c:1234:abcd::1
CNAME : 다른 도메인 이름 → 예) @ 또는 target.example.net
TXT : 인증 문자열 → 예) "google-site-verification=xxxx"
MX : 메일 서버 주소와 우선순위 → 예) 10 mail.example.com

주의
CNAME, MX 등 도메인 이름을 값으로 쓰는 레코드는 DNS 표준에서 끝에 점(.)을 붙여 mail.example.com. 형태로 작성하기도 합니다.
하지만 Lightsail DNS에서는 점이 없어도 자동으로 처리하므로 생략해도 됩니다.

레코드 유형	설명	예시 입력값	사용 예
A	IPv4 주소를 입력합니다.	13.124.56.78	Lightsail 고정 IPv4로 연결
AAAA	IPv6 주소를 입력합니다.	2406:da1c:1234:abcd::1	IPv6 네트워크에서 접속 허용
CNAME	다른 도메인 이름을 입력합니다. (@는 루트 도메인 의미)	@ 또는 target.example.net	www.mydomain.com을 mydomain.com으로 연결
TXT	인증용 문자열을 입력합니다.	google-site-verification=abc123xyz	구글 검색 소유권 인증, SPF/DKIM 설정
MX	메일 서버 주소와 우선순위를 입력합니다.	10 mail.example.com.	도메인 메일 서비스 연결

가장 많이 쓰는 기본 설정 예시

@ → A 레코드 → 고정 IPv4 주소 (13.124.56.78)
www → CNAME 레코드 → @ (www를 루트로 연결)

5. 추가된 레코드를 확인합니다.

연결 완료

이제 가비아에서 구매한 도메인을 AWS Lightsail 서버에 연결하여, IP 주소 대신 도메인으로 웹사이트에 접속할 수 있습니다.
네임서버 변경 후 바로 접속이 되지 않는다면, DNS 전파가 완료될 때까지 기다린 뒤 다시 시도합니다.

[AWS] MySQL Workbench로 Lightsail DB에 접속하기

bu119 — Thu, 7 Aug 2025 09:00:08 +0900

AWS Lightsail에서 MySQL DB 인스턴스를 만들었다면, 이제 로컬 PC에서 접속해 직접 쿼리를 실행하는 방법을 알아보자.
이 글에서는 MySQL Workbench를 사용해 Lightsail DB에 접속하는 방법을 설명한다.

MySQL Workbench는 MySQL 공식 GUI 도구로, SQL 쿼리 작성 및 테이블 관리 등을 시각적으로 처리할 수 있는 프로그램입니다.

✅ 사전 준비

작업을 시작하기 전에 아래 항목을 준비해야한다.

항목	설명
MySQL Workbench	https://dev.mysql.com/downloads/workbench/
Lightsail MySQL DB 인스턴스	생성 완료 상태 (사용 가능)
DB 접속 정보	엔드포인트, 포트, 사용자 이름, 비밀번호

1️⃣ Lightsail에서 접속 정보 확인

1. AWS Lightsail 콘솔에 접속한 뒤, 좌측 메뉴에서 Databases를 클릭한다.

2. 생성한 DB 인스턴스가 "사용 가능(Available)" 상태인지 확인한다.

3. 인스턴스 오른쪽 상단의 햄버거 메뉴(☰) 를 클릭한다.

4. "관리(Manage)" 버튼을 클릭한다.

5. 연결 세부 정보(Connection Details) 항목에서 다음 정보를 확인한다:

사용자 이름 (User name)
사용자 암호 (Master password)
DB 엔드포인트 (Endpoint)
포트 번호 (Port)

2️⃣ 퍼블릭 접속 허용 설정

MySQL Workbench는 로컬 PC에서 원격 DB에 접속하므로,
Lightsail DB 인스턴스에 퍼블릭 접근을 허용해야 한다.

1. DB 인스턴스 관리 페이지에서 Networking 탭을 클릭한다.

2. 퍼블릭 모드 활성화 버튼을 클릭한다.

⏳ 퍼블릭 모드 전환에는 약간의 시간이 소요된다.

완료되면 상태가 다시 "사용 가능"으로 표시된다.

3️⃣ MySQL Workbench에서 접속 설정

1. MySQL Workbench 실행한다.

2. 상단 메뉴에서 " + " 아이콘을 클릭해 새 커넥션을 생성한다.

3. 아래 정보를 입력한다.

항목	값
Connection Name	예: Lightsail DB
Hostname	Lightsail의 엔드포인트
Port	Lightsail의 포트 (기본값 3306)
Username	DB 생성 시 지정한 사용자 이름 (예: pomouser)
Password	DB 생성 시 지정 또는 제공된 비밀번호

Password 항목에서는 Store in Vault... 버튼을 클릭하여 암호를 입력한다.

모든 입력이 완료되면 OK 버튼을 클릭한다.

새 커넥션이 생성된 것을 확인할 수 있다.

4️⃣ DB 연결 확인

1. 방금 생성한 커넥션을 클릭하면 경고 메시지가 나타날 수 있다. (신뢰 여부 확인) → Continue Anyway 클릭

2. 접속에 성공하면 좌측 패널에 데이터베이스 목록이 표시된다.

예: dbpomo 등 마스터 DB 이름이 나타난다.

[AWS] Lightsail에서 MySQL DB 인스턴스 생성하기

bu119 — Tue, 5 Aug 2025 18:00:35 +0900

AWS Lightsail은 복잡한 설정 없이도 서버나 데이터베이스를 쉽게 만들 수 있는 서비스이다.

이 글에서는 AWS Lightsail에서 MySQL DB 인스턴스를 생성하는 방법을 단계별로 간단하게 설명한다.

DB 인스턴스란?

DB 인스턴스 = 실행 중인 MySQL 데이터베이스 서버

즉, 단순히 "MySQL을 설치했다"는 의미가 아니라, 실제로 접속하고 사용할 수 있는 상태의 MySQL 서버를 말한다.

AWS Lightsail에서는 복잡한 설치 과정 없이, 몇 번의 클릭만으로 이 DB 인스턴스를 자동으로 생성할 수 있다.

1️⃣ Lightsail에서 MySQL DB 생성 시작하기

1. AWS Lightsail 콘솔에 접속한다.

2. 좌측 메뉴에서 "Databases(데이터베이스)" 탭을 클릭한다.

3. "데이터베이스 생성" 버튼을 클릭한다.

2️⃣ 데이터베이스 기본 설정

1. 데이터베이스 위치 확인: 리전(Location) 선택

DB가 배포될 지역(Region)을 확인하고, 가까운 리전을 선택한다.

2. 데이터베이스 선택: 플랫폼 및 버전 선택

MySQL을 사용하며, 버전은 2025년 현재 기준 최신 LTS 버전인 8.4.6을 선택한다.

Platform: MySQL
MySQL version: 8.4.6 (2025년 기준 최신 LTS 버전)

버전 선택 팁

MySQL 8.4.6은 2024년 출시된 장기 지원(LTS) 버전으로, 신규 프로젝트에 추천된다.
MySQL 8.0.43은 기존 환경과의 호환성이 필요한 경우에 선택할 수 있으며, 공식 지원은 2026년까지이다.

3️⃣ 로그인 자격 증명 설정

DB에 접속할 기본 관리자 계정의 사용자 이름과 비밀번호를 설정한다.

1. "로그인 자격 증명 지정" 영역을 클릭한다.

2. 사용자 이름과 암호를 직접 입력하거나, 기본값을 사용할 수 있다.

항목	기본값	설명
사용자 이름	dbmasteruser	직접 변경 가능 (예: pomouser)
사용자 암호	자동 생성	생성 후 화면에서 확인 가능

"강력한 암호 생성" 체크박스를 해제하면 암호를 직접 입력할 수 있다.

사용자 이름과 사용자 암호를 직 지정한다.

4️⃣ 마스터 데이터베이스 이름 지정

MySQL 인스턴스가 생성될 때, 기본으로 하나의 데이터베이스가 함께 생성된다.
이때 그 이름을 지정하는 항목이 바로 "마스터 데이터베이스 이름"이다.

1. "마스터 데이터베이스 이름 지정"영역을 클릭한다.

1. 해당 입력란에 원하는 이름을 입력한다.

입력하지 않으면 기본값 dbmaster로 자동 설정된다.

2. 이름은 항상 db로 시작되며, 뒤에 붙는 이름만 지정할 수 있다.

예를 들어 chadoll을 입력하면, 실제 생성되는 DB 이름은 dbchadoll이다.

5️⃣ 데이터베이스 플랜 선택

DB 인스턴스의 사양을 선택하는 단계이다.

90일 무료 체험 플랜을 선택한다. (메모리 1GB, SSD 40GB 등 기본 사양)

요금이 부과되지 않도록, 생성 후 사용이 끝난 인스턴스는 삭제하는 걸 잊지 말자.

6️⃣ 데이터베이스 리소스 이름 지정

해당 DB 인스턴스를 식별할 수 있도록, 리전 내에서 고유한 리소스 이름을 입력한다.

예시: pomorodo-db-main, chadoll-db-01
추후 관리나 검색 시 유용하므로, 서비스명을 포함한 직관적인 이름을 추천한다.

7️⃣ 데이터베이스 인스턴스 생성

1. 모든 설정이 완료되면 하단의 "Create database(데이터베이스 생성)" 버튼을 클릭다.

2. 인스턴스가 "Creating(생성 중)" 상태로 나타난다.

약 3~10분 후 인스턴스가 준비된다.

3. 상태가 "Available(사용 가능)" 으로 변경되면, DB 인스턴스가 정상적으로 생성된 것이다.

[인프라 구축] Docker로 MySQL 초기 설정 자동화하기 (루트 접속 없이 DB·계정까지)

bu119 — Fri, 1 Aug 2025 19:30:24 +0900

루트 접속 없이 DB와 계정까지 자동 생성하는 방법

기존 방식: 루트 계정으로 수동 설정

Docker로 MySQL 컨테이너를 생성한 뒤,
다음과 같이 루트 계정으로 직접 접속해서 수동으로 설정했습니다:

# MySQL 컨테이너 실행
docker run --name my-mysql \
  -e MYSQL_ROOT_PASSWORD=root1234 \
  -p 3306:3306 \
  -d mysql:8.4

컨테이너가 실행되면 루트 계정으로 접속합니다:

docker exec -it my-mysql mysql -u root -p Enter password: root1234

접속 후에는 직접 SQL 명령어를 입력해야 했습니다:

-- 1. example_db 라는 이름의 데이터베이스 생성
CREATE DATABASE example_db;

-- 2. example_user 계정 생성, 비밀번호는 example1234
--    @'%'는 어디서든 접속 허용(IP 제한 없음)을 의미
CREATE USER 'example_user'@'%' IDENTIFIED BY 'example1234';

-- 3. 권한 부여: example_user에게 example_db 전체 권한 부여
--    (읽기, 쓰기, 삭제 등 모든 작업 가능)
GRANT ALL PRIVILEGES ON example_db.* TO 'example_user'@'%';

❌ 단점

루트 계정으로 접속해야 하므로 보안상 위험
명령어를 매번 기억하거나 복사해야 함
반복 작업 시 비효율적이고 실수 가능성 높음

새 방식: 명령어 한 줄로 자동 설정

Docker는 환경변수 설정만으로 DB와 사용자 계정을 자동 생성할 수 있습니다.
아래와 같이 단 한 줄로 모든 초기 설정을 마칠 수 있습니다:

docker run --name my-mysql \
  -e MYSQL_ROOT_PASSWORD=root1234 \
  -e MYSQL_DATABASE=example_db \
  -e MYSQL_USER=example_user \
  -e MYSQL_PASSWORD=example1234 \
  -p 3306:3306 \
  -d mysql:8.4

✅ 명령어 설명

항목	값	설명
MYSQL_ROOT_PASSWORD	root1234	루트 비밀번호 설정
MYSQL_DATABASE	example_db	자동 생성할 DB 이름
MYSQL_USER	example_user	새로 만들 사용자 계정
MYSQL_PASSWORD	example1234	해당 계정의 비밀번호

위 명령을 실행하면 다음이 자동으로 이루어집니다:

example_db 데이터베이스 생성
example_user 사용자 생성
example_user에게 example_db에 대한 모든 권한 부여

기존 방식 vs 자동 설정 방식 비교

항목	기존 방식 (수동)	새 방식 (자동)
루트 접속	필요	불필요 ✅
DB 생성	SQL 명령 입력	환경변수로 자동
사용자 생성	SQL 명령 입력	환경변수로 자동
권한 부여	수동 입력	자동 처리
보안 측면	루트 사용 위험	일반 계정으로 안전 ✅
실수 가능성	있음	거의 없음 ✅
반복 작업	비효율적	재사용 가능 ✅

MySQL 초기 설정은 꼭 루트 계정으로 들어가야만 가능한 작업이 아니었습니다.
Docker의 환경변수 옵션을 잘 활용하면,
보안은 높이고 실수는 줄이며 반복 작업까지 간편하게 해결할 수 있습니다.

[AWS] 무료 플랜에서 유료 플랜으로 업그레이드하는 방법

bu119 — Thu, 31 Jul 2025 15:00:23 +0900

1. 콘솔 화면에서 "Cost and usage" 찾기

2. Cost and usage 에서 "Upgrade plan" 클릭

3. "Upgrade plan" 클릭하면 아래 창이 뜬다. 업그레이드 계획을 누른다.

4. 계속을 누르면 콘솔 화면으로 돌아간다.

5. 유료플랜으로 전환하니, 콘솔 화면 구성이 바꼈다.

[AWS] AWS Billing Budget 설정하기

bu119 — Wed, 30 Jul 2025 16:00:32 +0900

AWS 비용 관리

1. AWS Bugets (예산)

1-1. 주요 기능

예산을 지정하고 비용과 사용량을 추적하는 서비스
비용 또는 사용량이 사용자가 지정한 임계값을 초과할 때 이메일 등으로 알람을 받거나 AWS RDS / EC2 등의 서비스를 중지하는 작업을 연결할 수 있음
비용 할당 태그를 사용하면 AWS 특정 리소스에 태그를 지정해 태그에 대한 리소스 보고서만 생성 가능
- 특정 App을 실행하는 서비스 비용과 사용량에 대해서 보고서 생성

1-2. 실습

1. 서비스 > AWS 비용관리 > AWS Budgets

아래와 같은 창이 뜬다.

2. 좌측 "예산 및 계획"의 "예산" 탭 > 우측 상단의 "예산 생성"

3. 기본 템플릿으로 제로 지출 예산 템플릿을 선택합니다.

4. 예산 이름과 이메일 수신자를 입력합니다.

5. 생성된 예산을 확인합니다.

참고자료

https://velog.io/@jiseok/AWS-%EB%B9%84%EC%9A%A9-%EA%B4%80%EB%A6%AC

[Troubleshooting] GitHub Actions에서 발생한 "denied: requested access to the resource is denied" 오류 해결하기

bu119 — Sat, 29 Jun 2024 22:00:31 +0900

"denied: requested access to the resource is denied"라는 오류 메시지는 Docker Hub에 이미지를 푸시할 때 권한 문제가 발생했음을 나타낸다. 이는 로그인 자격 증명이 잘못되었거나 저장소에 대한 권한이 부족할 때 발생할 수 있다.

이 문제를 해결하기 위해 다음 단계를 수행해야한다.

1. Docker Hub 로그인 확인

Docker Hub에 올바른 자격 증명으로 로그인했는지 확인한다.

docker login

로그인하면 Docker Hub 사용자 이름과 비밀번호를 입력하라는 메시지가 표시된다.

2. 저장소 이름 확인

docker push 명령에서 저장소 이름이 올바른지 확인한다.

예를 들어, Docker Hub 사용자 이름이 tico인 경우 명령은 다음과 같아야 한다.

docker push tico/nginx

3. 권한 확인

저장소에 푸시할 수 있는 권한이 있는지 확인한다.

저장소가 비공개이거나 조직에 속한 경우 적절한 권한이 필요하다.

트러블슈팅

문제

도커 이미지 이름을 "팀(회사)명/nginx"로 설정했다.

하지만 Docker Hub에 이미지를 푸시할 때 권한 오류가 발생했다.

원인

Docker Hub에 이미지를 푸시할 때 사용자 이름을 이미지 이름 앞에 두어야한다.

사용자 이름이 없으면 Docker Hub는 어느 사용자나 조직의 저장소에 이미지를 푸시할지 알 수 없다.

해결 방법

도커 이미지 이름을 "도커 허브 사용자명/nginx"로 설정해야 한다.

해결 방법

1. Docker Hub 로그인

Logging into Docker Hub...

Login Succeeded!

2. 도커 이미지 이름 변경

이미지를 빌드할 때 Docker Hub 사용자 이름을 포함하도록 태그를 수정한다.

docker build -t 도커허브사용자명/nginx:latest .

3. 도커 이미지 푸시

사용자 이름을 포함한 이미지 이름으로 Docker Hub에 이미지를 푸시한다.

docker push 도커허브사용자명/nginx:latest

해결 코드

#!/usr/bin/env bash
set -e  # 명령 실패 시 스크립트 종료

# nginx 디렉토리로 이동
cd nginx

# Docker 이미지 빌드
docker build -t $DOCKER_USERNAME/nginx:latest .

# Docker Hub에 이미지 푸시
docker push $DOCKER_USERNAME/nginx:latest

이전 코드

# nginx 디렉토리로 이동
cd nginx

#!/usr/bin/env bash
set -e  # 명령 실패 시 스크립트 종료

# Docker 이미지 빌드
docker build -t tico/nginx:latest .

# Docker Hub에 이미지 푸시
docker push tico/nginx:latest

[인프라 구축] Let’s Encrypt, SSL/TLS 인증서 발급하기

bu119 — Sun, 16 Jun 2024 09:00:41 +0900

우리는 호스트 시스템에 Certbot을 활용하여 Let’s Encrypt SSL/TLS 인증서를 발급받을 것이다.

그 이유는,

우리는 토이 프로젝트이고 서버 자원을 최대한 아껴야 한다. 이렇게 하면 Docker 컨테이너에 의해 추가되는 오버헤드를 피하고, 시스템 자원을 절약할 수 있다. 따라서, Certbot을 호스트 시스템에 직접 설치하는 것이 더 적합할 수 있다.

Docker로 실행을 권장하는 경우:

다양한 서버 환경에서 일관된 설정이 필요할 때
DevOps 관행에 따라 컨테이너화된 환경을 선호할 때
시스템 격리와 독립성이 중요한 경우
Certbot 설치 및 업그레이드의 간편함이 필요할 때

호스트 시스템에 직접 설치를 권장하는 경우:

Docker를 사용하지 않거나 Docker 사용이 복잡한 경우
시스템 자원을 최소화하고자 할 때
단일 서버에서 간단한 설정이 필요한 경우
종속성 관리가 용이하고, Certbot이 서버의 다른 소프트웨어와 충돌할 가능성이 없을 때

1. 패키지 인덱스 업데이트하기

시스템이 최신 패키지 정보를 갖도록 업데이트한다.

sudo apt update

패키지 인덱스는 시스템에서 사용할 수 있는 패키지와 그 버전에 대한 데이터베이스이다.
업데이트를 하면 최신 소프트웨어 정보와 버전을 확보할 수 있다.

실습

ubuntu@ip-000-000-000-000:~$ sudo apt update

Hit:1 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelea   se
Hit:3 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-backports InRel   ease
Hit:4 https://download.docker.com/linux/ubuntu jammy InRelease
Get:5 http://security.ubuntu.com/ubuntu jammy-security InRelease [129 kB]
Fetched 129 kB in 1s (117 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
99 packages can be upgraded. Run 'apt list --upgradable' to see them.

2. Certbot 설치하기

Certbot은 Let's Encrypt SSL/TLS 인증서를 얻고 관리하는 도구이다.

apt를 통해 Certbot 도구를 시스템에 설치한다.

sudo apt install certbot -y

-y 옵션은 설치 중 묻는 질문에 자동으로 "예"라고 답한다.

실습

ubuntu@ip-000-000-000-000:~$ sudo apt install certbot

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  python3-acme python3-certbot python3-configargparse python3-icu python3-josepy
  python3-parsedatetime python3-requests-toolbelt python3-rfc3339
  python3-zope.component python3-zope.event python3-zope.hookable
Suggested packages:
  python-certbot-doc python3-certbot-apache python3-certbot-nginx
  python-acme-doc
The following NEW packages will be installed:
  certbot python3-acme python3-certbot python3-configargparse python3-icu
  python3-josepy python3-parsedatetime python3-requests-toolbelt python3-rfc3339
  python3-zope.component python3-zope.event python3-zope.hookable
0 upgraded, 12 newly installed, 0 to remove and 99 not upgraded.
Need to get 958 kB of archives.
After this operation, 4915 kB of additional disk space will be used.

Do you want to continue? [Y/n] Y

Get:1 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-josepy all 1.10.0-1 [22.0 kB]
Get:2 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 python3-requests-toolbelt all 0.9.1-1 [38.0 kB]
Get:3 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 python3-rfc3339 all 1.1-3 [7110 B]
Get:4 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 python3-acme all 1.21.0-1ubuntu0.1 [36.4 kB]
Get:5 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-configargparse all 1.5.3-1 [26.9 kB]
Get:6 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-parsedatetime all 2.6-2 [32.9 kB]
Get:7 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-zope.hookable amd64 5.1.0-1build1 [11.6 kB]
Get:8 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-zope.event all 4.4-3 [8180 B]
Get:9 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-zope.component all 4.3.0-3 [38.3 kB]
Get:10 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 python3-certbot all 1.21.0-1build1 [175 kB]
Get:11 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 python3-icu amd64 2.8.1-0ubuntu2 [540 kB]
Get:12 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy/universe amd64 certbot all 1.21.0-1build1 [21.3 kB]
Fetched 958 kB in 0s (21.9 MB/s)
Preconfiguring packages ...
Selecting previously unselected package python3-josepy.
(Reading database ... 94226 files and directories currently installed.)
Preparing to unpack .../00-python3-josepy_1.10.0-1_all.deb ...
Unpacking python3-josepy (1.10.0-1) ...
Selecting previously unselected package python3-requests-toolbelt.
Preparing to unpack .../01-python3-requests-toolbelt_0.9.1-1_all.deb ...
Unpacking python3-requests-toolbelt (0.9.1-1) ...
Selecting previously unselected package python3-rfc3339.
Preparing to unpack .../02-python3-rfc3339_1.1-3_all.deb ...
Unpacking python3-rfc3339 (1.1-3) ...
Selecting previously unselected package python3-acme.
Preparing to unpack .../03-python3-acme_1.21.0-1ubuntu0.1_all.deb ...
Unpacking python3-acme (1.21.0-1ubuntu0.1) ...
Selecting previously unselected package python3-configargparse.
Preparing to unpack .../04-python3-configargparse_1.5.3-1_all.deb ...
Unpacking python3-configargparse (1.5.3-1) ...
Selecting previously unselected package python3-parsedatetime.
Preparing to unpack .../05-python3-parsedatetime_2.6-2_all.deb ...
Unpacking python3-parsedatetime (2.6-2) ...
Selecting previously unselected package python3-zope.hookable.
Preparing to unpack .../06-python3-zope.hookable_5.1.0-1build1_amd64.deb ...
Unpacking python3-zope.hookable (5.1.0-1build1) ...
Selecting previously unselected package python3-zope.event.
Preparing to unpack .../07-python3-zope.event_4.4-3_all.deb ...
Unpacking python3-zope.event (4.4-3) ...
Selecting previously unselected package python3-zope.component.
Preparing to unpack .../08-python3-zope.component_4.3.0-3_all.deb ...
Unpacking python3-zope.component (4.3.0-3) ...
Selecting previously unselected package python3-certbot.
Preparing to unpack .../09-python3-certbot_1.21.0-1build1_all.deb ...
Unpacking python3-certbot (1.21.0-1build1) ...
Selecting previously unselected package python3-icu.
Preparing to unpack .../10-python3-icu_2.8.1-0ubuntu2_amd64.deb ...
Unpacking python3-icu (2.8.1-0ubuntu2) ...
Selecting previously unselected package certbot.
Preparing to unpack .../11-certbot_1.21.0-1build1_all.deb ...
Unpacking certbot (1.21.0-1build1) ...
Setting up python3-configargparse (1.5.3-1) ...
Setting up python3-requests-toolbelt (0.9.1-1) ...
Setting up python3-parsedatetime (2.6-2) ...
Setting up python3-icu (2.8.1-0ubuntu2) ...
Setting up python3-zope.event (4.4-3) ...
Setting up python3-zope.hookable (5.1.0-1build1) ...
Setting up python3-josepy (1.10.0-1) ...
Setting up python3-rfc3339 (1.1-3) ...
Setting up python3-zope.component (4.3.0-3) ...
Setting up python3-acme (1.21.0-1ubuntu0.1) ...
Setting up python3-certbot (1.21.0-1build1) ...
Setting up certbot (1.21.0-1build1) ...
Processing triggers for man-db (2.10.2-1) ...
Scanning processes...
Scanning candidates...
Scanning linux images...

Restarting services...
Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart docker.service
 systemctl restart getty@tty1.service
 systemctl restart networkd-dispatcher.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

3. 도메인의 SSL/TLS 인증서 발급하기 - Let’s Encrypt

Certbot을 사용하여 도메인의 SSL/TLS 인증서를 얻는다.

# certbot을 사용하여 SSL 인증서 발급
sudo certbot certonly --standalone -d 도메인주소

certonly 옵션은 인증서만 얻고 설치하지 않음을 의미한다.
-d 옵션은 도메인 이름을 지정한다.

이 명령어를 통해

자체 임시 웹 서버를 사용하여 도메인 소유권을 증명한다.
Let's Encrypt 서버와 통신하여 인증서를 얻는다.
인증서와 키 파일을 시스템에 저장한다.
- 일반적으로 /etc/letsencrypt/live/도메인/ 디렉토리에 저장된다.

명령어를 실행하면 이메일 주소를 입력하고, Let's Encrypt 서비스 약관에 동의하는 등의 절차가 진행된다.

실습

발급된 인증서는 /etc/letsencrypt/live/pomorodo.shop/ 경로에 저장된다.

ubuntu@ip-000-000-000-000:~$ sudo certbot certonly --standalone -d pomorodo.shop

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): tico240516@gmail.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in
order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

Account registered.
Requesting a certificate for pomorodo.shop

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/pomorodo.shop/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/pomorodo.shop/privkey.pem
This certificate expires on 2024-09-13.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le

추가 참고 사항

권한: 소프트웨어 설치 및 인증서 획득에는 관리자 권한이 필요하므로 sudo 명령어가 필요하다.
DNS 레코드: 도메인(pomorodo.shop)이 명령어를 실행하는 서버로 올바르게 포워딩되어 있는지 확인해야 한다. 이는 도메인 검증 과정에 필요하다.
방화벽: 방화벽이 도메인 검증이 원활하게 진행되도록 80번 포트(HTTP)와 443번 포트(HTTPS) 트래픽을 허용하는지 확인해야 한다.

이 단계를 따라가면 도메인에 대한 SSL/TLS 인증서를 성공적으로 얻을 수 있으며, 이를 통해 HTTPS로 웹사이트를 안전하게 보호할 수 있다.

참고 자료

https://www.kamatera.com/knowledgebase/how-to-secure-nginx-with-lets-encrypt/

[인프라 구축] Ubuntu 현재 시스템의 시간대를 한국 시간으로 변경하기

bu119 — Sat, 15 Jun 2024 18:30:32 +0900

우분투에서 터미널을 통해 현재 시스템 시간대를 한국 시간으로 변경할 것이다.

시스템의 현재 시간 및 날짜 관련 설정 상태 확인하기

이 명령어를 통해 시간 및 날짜 관련 시스템 상태를 자세히 확인할 수 있다.

timedatectl

초기상태에는 현재 시스템의 시간대가 UTC(협정 세계시)로 설정되어 있다.

Time zone: Etc/UTC (UTC, +0000)

실습

ubuntu@ip-000-000-000-000:~$ timedatectl
               Local time: Sat 2024-06-15 08:45:50 UTC
           Universal time: Sat 2024-06-15 08:45:50 UTC
                 RTC time: Sat 2024-06-15 08:45:50
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

이 출력 결과에는 다음과 같은 정보가 포함되어 있다.

로컬 시간 (Local time)
협정 세계시 (Universal time)
하드웨어 시계 시간 (RTC time)
현재 시간대 (Time zone)
NTP(Network Time Protocol) 동기화 상태 (NTP enabled, NTP synchronized)
하드웨어 시계와 시스템 시계의 동기화 여부 (RTC in local TZ)
일광 절약 시간(DST) 활성화 여부 (DST active)

이를 통해 시스템의 현재 시간 및 날짜 관련 설정 상태를 한눈에 확인할 수 있다.

시스템의 시간대를 한국 시간으로 변경하기

이 명령어를 통해 시스템 시간대를 한국 서울 시간대로 변경할 수 있다.

sudo timedatectl set-timezone Asia/Seoul

sudo를 통해 관리자 권한으로 실행
timedatectl은 시간 및 날짜 설정을 관리하는 명령어
set-timezone으로 시간대를 변경
Asia/Seoul은 한국 서울 시간대를 의미

실습

ubuntu@ip-000-000-000-000:~$ sudo timedatectl set-timezone Asia/Seoul
ubuntu@ip-000-000-000-000:~$ timedatectl
               Local time: Sat 2024-06-15 17:46:13 KST
           Universal time: Sat 2024-06-15 08:46:13 UTC
                 RTC time: Sat 2024-06-15 08:46:13
                Time zone: Asia/Seoul (KST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

시스템의 시간대가 Asia/Seoul로 한국 서울 시간대로 변경된 것을 확인할 수 있다.

Time zone: Asia/Seoul (KST, +0900)

현재 시간확인하기

이 명령어를 통해 현재 날짜와 시간을 확인할 수 있다.

date

시간대가 정상적으로 변경되었다면 한국 시간이 표시될 것이다.

실습

ubuntu@ip-000-000-000-000:~$ date

Sat Jun 15 17:56:32 KST 2024

KST는 한국 표준시(Korea Standard Time)를 의미하므로, 이를 통해 우분투 PC의 시간대가 한국 시간으로 정상적으로 변경되었음을 확인할 수 있다.

실습

ubuntu@ip-000-000-000-000:~$ timedatectl

               Local time: Sat 2024-06-15 08:45:50 UTC
           Universal time: Sat 2024-06-15 08:45:50 UTC
                 RTC time: Sat 2024-06-15 08:45:50
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
          
ubuntu@ip-000-000-000-000:~$ sudo timedatectl set-timezone Asia/Seoul

ubuntu@ip-000-000-000-000:~$ timedatectl

               Local time: Sat 2024-06-15 17:46:13 KST
           Universal time: Sat 2024-06-15 08:46:13 UTC
                 RTC time: Sat 2024-06-15 08:46:13
                Time zone: Asia/Seoul (KST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
          
ubuntu@ip-000-000-000-000:~$ date

Sat Jun 15 17:56:32 KST 2024

[CICD 구축] GitHub Actions 워크플로우 구성하기

bu119 — Fri, 14 Jun 2024 18:00:04 +0900

워크플로우 개요

이 GitHub Actions 워크플로우는 Java, Spring Boot, Ubuntu, Docker를 사용하여 CI/CD(Continuous Integration/Continuous Deployment)를 자동화하는 설정이다.
이 워크플로우는 develop-be 브랜치에 push 또는 pull request 이벤트가 발생할 때 실행된다.
두 개의 작업(Job) build, deploy 로 구성되어 있다.
Docker를 사용하기 때문에 Docker 이미지를 빌드하는 단계에서 Dockerfile이 필요하다.

Dockerfile 준비하기

Dockerfile은 애플리케이션의 실행 환경을 코드로 정의하여, 어디서나 동일한 환경에서 애플리케이션을 실행할 수 있도록 한다. Dockerfile을 사용하여 Docker 이미지를 빌드한다.

FROM openjdk:17-alpine
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENV TZ=Asia/Seoul
ENTRYPOINT ["java","-jar","/app.jar","-Duser.timezone=Asia/Seoul"]
# -Duser.timezone=Asia/Seoul 옵션: 기본 타임존을 Asia/Seoul로 강제 설정

Dockerfile은 애플리케이션을 컨테이너화하는 데 필요한 명령어들을 포함하고 있다.
여기에는 베이스 이미지를 설정하고, 필요한 종속성을 설치하고, 애플리케이션 코드를 추가하고, 실행 명령을 정의하는 내용이 포함된다

워크플로우 구성

# deploy.yml

name: CI/CD with Gradle, Docker, AWS

# develop-be 브랜치에 push 또는 PR 이벤트가 발생하면 워크플로우가 실행된다.
on:
  push:
    branches: [ "develop-be" ]
  pull_request:
    branches: [ "develop-be" ]

# 해당 Workflow의 Job 목록
jobs:
  build:
  # 이 작업이 실행되는 환경을 정의: 최신 Ubuntu 환경
    runs-on: ubuntu-latest
    # 리포지토리에 대한 읽기 권한을 부여한다.
    permissions:
      contents: read
      
    # build Job 내의 step 목록
    steps:
    ### CI
    # 레포지토리 체크아웃하여 레포지토리에 접근할 수 있게 한다.
    - name: Checkout Repository
      uses: actions/checkout@v4
      
    # JDK 버전 17 설정 (temurin 배포판 사용)
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        
    # Gradle 캐싱 설정으로 의존성 다운로드 시간을 줄인다.
    - name: Gradle Caching
      uses: actions/cache@v3
      with:
        path: |
          ~/.gradle/caches
          ~/.gradle/wrapper
        key: ${{ runner.os }}-gradle-${{ hashFiles('backend/pomoro-do/**/*.gradle*', 'backend/pomoro-do/**/gradle-wrapper.properties') }}
        restore-keys: |
          ${{ runner.os }}-gradle-
          
    # Gradle 래퍼 스크립트에 실행 권한 부여
    - name: Grant Execute Permission For Gradlew
      run: chmod +x backend/pomoro-do/gradlew
    
    # 테스트를 제외한 Gradle 빌드 수행 (CI 단계)
    - name: Build with Gradle
      run: cd backend/pomoro-do && ./gradlew build -x test

    ### CD
    # Docker Hub에 로그인 (보안) (CD 단계 준비)
    - name: Log in to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    # SpringBoot 어플리케이션의 Docker 이미지를 빌드하고 Docker Hub에 푸시 (CD 단계 준비)
    - name: Build and Push Docker Image for SpringBoot
      run: |
        cd backend/pomoro-do
        set -e # 명령 실패 시 스크립트 종료
        # 현재 디렉토리에 있는 Dockerfile을 사용하여 Docker 이미지를 빌드
        docker build -t ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest .
        # Docker Hub에 이미지 푸시
        docker push ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest

  deploy:
    # 이 작업은 build 작업이 성공적으로 완료된 후에만 실행다.
    needs: build
    runs-on: ubuntu-latest
    steps:
    # SSH를 통해 원격 서버에서 명령을 실행하여 Docker 컨테이너 배포
    - name: Docker Run
      uses: appleboy/ssh-action@v0.1.8
      with:
        host: ${{ secrets.SSH_HOST }}  # 원격 서버의 호스트명
        username: ${{ secrets.SSH_USERNAME }}  # 원격 서버의 사용자명
        key: ${{ secrets.SSH_PRIVATE_KEY }}  # 원격 서버의 비밀 키
        port: 22  # SSH 포트
        sync: false
        use_insecure_cipher: false
        timeout: 30s
        command_timeout: 10m
        debug: true  # 디버그 모드 활성화
        script: |
          docker stop pomorodo-server || true  # 실행 중인 pomorodo-server 컨테이너 중지
          docker rm pomorodo-server || true  # 기존 컨테이너 삭제
          docker rmi ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest || true # 기존 이미지 삭제
          docker pull ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest # 최신 이미지 다운로드
          docker run -d -p 8080:8080 --name pomorodo-server -e DB_URL=${{ secrets.DB_URL }} -e DB_USERNAME=${{ secrets.DB_USERNAME }} -e DB_PASSWORD=${{ secrets.DB_PASSWORD }} ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest

CI (Continuous Integration)

CI 단계에서는 코드의 변경사항이 빌드되고 테스트된다.

여기서는 주로 코드가 정상적으로 동작하는지 확인하는 작업이 이루어진다. 여기서 코드를 빌드하여 문제가 없는지 확인한다.

워크플로우 설정

워크플로우 이름을 정의한다.

name: CI/CD with Gradle, Docker, AWS

name: CI/CD with Gradle, Docker, AWS - 워크플로우의 이름이다.

이벤트 트리거

develop-be 브랜치에 push되거나 pull request가 생성될 때 워크플로우가 실행된다.

on:
  push:
    branches: [ "develop-be" ]
  pull_request:
    branches: [ "develop-be" ]

on: - 워크플로우를 트리거하는 이벤트를 정의한다.
push: branches: - 해당 브랜치로 푸시 이벤트가 발생하면 워크플로우가 실행한다.
pull_request: branches: - 해당 브랜치를 대상으로 한 풀 리퀘스트 이벤트가 발생하면 워크플로우가 실행한다.

Job 1: build

기본 설정

이 작업은 최신 Ubuntu 환경에서 실행된다. 리포지토리에 대한 읽기 권한을 부여한다.

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read

runs-on: ubuntu-latest - 최신 버전의 Ubuntu 가상 머신에서 작업이 실행한다.
permissions: contents: read - 저장소 내용에 대한 읽기 권한을 부여한다.

Steps (단계)

1. 레포지토리 체크아웃 (Checkout Repository)

레포지토리의 코드를 체크아웃하여 접근할 수 있게 한다.

- name: Checkout Repository
  uses: actions/checkout@v4

actions/checkout 액션을 사용하여 저장소를 러너에 클론한다.

2. JDK 17 설정 (Set up JDK 17)

JDK 17을 설정한다.

- name: Set up JDK 17
  uses: actions/setup-java@v4
  with:
    java-version: '17'
    distribution: 'temurin'

actions/setup-java 액션을 사용하여 JDK 17 (Temurin 배포판)을 설치한다.

3. Gradle 캐싱 (Gradle Caching)

Gradle 캐싱을 설정하여 빌드 시간을 줄인다.

- name: Gradle Caching
  uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('backend/pomoro-do/**/*.gradle*', 'backend/pomoro-do/**/gradle-wrapper.properties') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

actions/cache 액션을 사용하여 Gradle 종속성을 캐싱하여 빌드 속도를 높인다.
path - 캐싱할 디렉토리를 지정한다.
key - OS 및 Gradle 파일의 해시를 기반으로 한 고유한 캐시 키를 정의한다.
restore-keys - 기본 키가 없을 때 사용할 대체 키를 정의한다.

4. Gradlew 실행 권한 부여 (Grant Execute Permission For Gradlew)

Gradle 래퍼 스크립트에 실행 권한을 부여한다.

- name: Grant Execute Permission For Gradlew
  run: chmod +x backend/pomoro-do/gradlew

5. Gradle로 빌드 (Build with Gradle)

- name: Build with Gradle
  run: cd backend/pomoro-do && ./gradlew build -x test

Gradle 빌드 명령을 실행하여 테스트를 제외한 빌드를 수행한다.

CD (Continuous Deployment)

CD 단계에서는 빌드된 애플리케이션을 실제 환경에 배포한다.

6. Docker Hub에 로그인 (Log in to Docker Hub)

Docker Hub에 로그인한다.

- name: Log in to Docker Hub
  uses: docker/login-action@v2
  with:
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}

docker/login-action 액션을 사용하여 Docker Hub에 로그인한다.
GitHub Secrets에 저장된 자격 증명 사용한다.

7. SpringBoot용 Docker 이미지 빌드 및 푸시 (Build and Push Docker Image for SpringBoot)

- name: Build and Push Docker Image for SpringBoot
  run: |
    cd backend/pomoro-do
    set -e
    docker build -t ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest .
    docker push ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest

이 단계에서는 backend/pomoro-do 디렉토리에 있는 Dockerfile을 사용하여 Spring Boot 애플리케이션의 Docker 이미지를 빌드한다.
빌드된 Docker 이미지를 Docker Hub에 푸시한다.

Job 2: deploy

기본 설정

deploy:
  needs: build
  runs-on: ubuntu-latest

needs: build - 이 작업은 build 작업이 성공적으로 완료된 후에만 실행된다.
최신 Ubuntu 환경에서 실행다.

Steps (단계)

1. Docker 실행 (Docker Run)

SSH를 통해 원격 서버에 접속하여 Docker 컨테이너를 배포한다.

기존 컨테이너와 이미지를 중지하고 삭제한 후, 최신 이미지를 다운로드하여 새로운 컨테이너를 실행한다.

이 단계에서는 Docker Hub에서 최신 이미지를 풀(pull) 한 후, 컨테이너를 실행한다.
이 이미지도 Dockerfile을 통해 빌드된 것이므로, 이전 단계에서 만든 Dockerfile이 중요하다.

- name: Docker Run
  uses: appleboy/ssh-action@v0.1.8
  with:
    host: ${{ secrets.SSH_HOST }}
    username: ${{ secrets.SSH_USERNAME }}
    key: ${{ secrets.SSH_PRIVATE_KEY }}
    port: 22
    sync: false
    use_insecure_cipher: false
    timeout: 30s
    command_timeout: 10m
    debug: true
    script: |
      docker stop pomorodo-server || true
      docker rm pomorodo-server || true
      docker rmi ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest || true
      docker pull ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest
      docker run -d -p 8080:8080 --name pomorodo-server -e DB_URL=${{ secrets.DB_URL }} -e DB_USERNAME=${{ secrets.DB_USERNAME }} -e DB_PASSWORD=${{ secrets.DB_PASSWORD }} ${{ secrets.DOCKER_USERNAME }}/pomorodo:latest

appleboy/ssh-action 액션을 사용하여 SSH를 통해 원격 서버에서 명령을 실행한다.
실행 중인 pomorodo-server 컨테이너를 중지하고 삭제한다.
기존 Docker 이미지를 삭제한다.
Docker Hub에서 최신 이미지를 다운로드한다.
환경 변수를 설정하고 새로운 Docker 컨테이너를 실행다.

CI/CD

CI는 코드의 품질을 보장하고 빌드 과정을 자동화하며,

CD는 빌드된 애플리케이션을 실제 운영 환경에 배포하는 과정을 자동화한다.

CI (지속적 통합): 코드 체크아웃, JDK 설정, Gradle 캐싱, Gradle 빌드
CD (지속적 배포): Docker Hub 로그인, Docker 이미지 빌드 및 푸시, Docker 컨테이너 배포

이 워크플로우는 코드가 develop-be 브랜치에 푸시되거나 PR이 생성될 때 자동으로 빌드와 배포 과정을 수행하여, 최신 버전의 애플리케이션이 원격 서버에 배포되도록 설정되어 있다.

docker-compose 사용하기

docker-compose.yml 파일은 Docker Compose를 사용하여 여러 컨테이너 서비스를 정의하고 설정할 수 있는 구성 파일이다.

docker-compose.yml

# docker-compose.yml

# Docker Compose 파일의 버전을 지정
version: '3.8'

services:
  app:
    build:
      context: ./backend/pomoro-do
      dockerfile: Dockerfile
    image: ${DOCKER_USERNAME}/pomorodo:latest
    ports:
      - "8080:8080"
    environment:
      DB_URL: ${DB_URL}
      DB_USERNAME: ${DB_USERNAME}
      DB_PASSWORD: ${DB_PASSWORD}
      S3_ACCESS_KEY: ${S3_ACCESS_KEY}
      S3_SECRET_KEY: ${S3_SECRET_KEY}
      REGION: ${REGION}
      BUCKET_NAME: ${BUCKET_NAME}
      JWT_ACCESS_SECRET: ${JWT_ACCESS_SECRET}
      JWT_REFRESH_SECRET: ${JWT_REFRESH_SECRET}

버전

version: '3.8'

version: Docker Compose 파일의 버전을 지정합니다. 여기서는 버전 3.8을 사용합니다. 이는 Docker Compose의 여러 기능을 사용할 수 있게 합니다.

서비스 정의

services:
  app:

services: 여러 컨테이너 서비스를 정의할 수 있는 섹션입니다.
app: 서비스의 이름입니다. 여기서는 app이라는 이름을 사용하여 Spring Boot 애플리케이션을 정의하고 있습니다.

빌드 설정

    build:
      context: ./backend/pomoro-do
      dockerfile: Dockerfile

build: Docker 이미지를 빌드하는 설정을 정의합니다.
- context: Docker 빌드 컨텍스트를 지정합니다. ./backend/pomoro-do 디렉토리를 기준으로 빌드가 수행됩니다. 이 디렉토리에는 Dockerfile과 소스 코드가 있어야 합니다.
- dockerfile: 사용할 Dockerfile을 지정합니다. 기본적으로 context 내의 Dockerfile을 사용합니다.

이미지 설정

    image: "${DOCKER_USERNAME}/pomorodo:latest"

image: 빌드된 Docker 이미지를 태그할 이름을 지정합니다. 여기서는 환경 변수 ${DOCKER_USERNAME}를 사용하여 Docker Hub의 사용자 이름과 pomorodo:latest 이미지를 결합하여 이름을 설정합니다. 예를 들어, 사용자 이름이 exampleuser인 경우 exampleuser/pomorodo:latest로 태그됩니다.

포트 설정

    image: "${DOCKER_USERNAME}/pomorodo:latest"

ports: 호스트와 컨테이너 간의 포트 매핑을 설정합니다.
- "8080:8080": 호스트의 포트 8080을 컨테이너의 포트 8080에 매핑합니다. 이렇게 하면 호스트의 8080 포트로 접근할 때 컨테이너의 8080 포트로 요청이 전달됩니다.

환경 변수 설정

    environment:
      DB_URL: "${DB_URL}"
      DB_USERNAME: "${DB_USERNAME}"
      DB_PASSWORD: "${DB_PASSWORD}"

environment: 컨테이너에서 사용할 환경 변수를 설정합니다. 환경 변수는 주로 애플리케이션의 설정 값을 지정하는 데 사용됩니다.
- DB_URL: 데이터베이스 URL을 지정합니다.
- DB_USERNAME: 데이터베이스 사용자 이름을 지정합니다.
- DB_PASSWORD: 데이터베이스 비밀번호를 지정합니다.

요약

이 docker-compose.yml 파일은 Spring Boot 애플리케이션을 정의하고, Docker 이미지를 빌드하고, 환경 변수를 설정하며, 포트 매핑을 통해 컨테이너가 호스트의 특정 포트에서 접근 가능하도록 합니다. 이를 통해 애플리케이션을 손쉽게 배포하고 관리할 수 있습니다. 각 구성 요소는 다음과 같은 역할을 합니다:

version: Docker Compose 파일의 버전 지정
services: 여러 컨테이너 서비스를 정의
app: 서비스 이름
build: Docker 이미지를 빌드하는 설정
image: 빌드된 이미지의 태그 이름
ports: 호스트와 컨테이너 간의 포트 매핑
environment: 컨테이너 내에서 사용할 환경 변수 설정

deploy.yml

# deploy.yml

name: CI/CD with Gradle, Docker, AWS

# develop-be 브랜치에 push 또는 PR 이벤트가 발생하면 워크플로우가 실행된다.
on:
  push:
    branches: [ "develop-be" ]
  pull_request:
    branches: [ "develop-be" ]

# 해당 Workflow의 Job 목록
jobs:
  build:
  # 이 작업이 실행되는 환경을 정의: 최신 Ubuntu 환경
    runs-on: ubuntu-latest
    # 리포지토리에 대한 읽기 권한을 부여한다.
    permissions:
      contents: read
      
    # build Job 내의 step 목록
    steps:
    ### CI
    # 레포지토리 체크아웃하여 레포지토리에 접근할 수 있게 한다.
    - name: Checkout Repository
      uses: actions/checkout@v4
      
    # JDK 버전 17 설정 (temurin 배포판 사용)
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        
    # Gradle 캐싱 설정으로 의존성 다운로드 시간을 줄인다.
    - name: Gradle Caching
      uses: actions/cache@v3
      with:
        path: |
          ~/.gradle/caches
          ~/.gradle/wrapper
        key: ${{ runner.os }}-gradle-${{ hashFiles('backend/pomoro-do/**/*.gradle*', 'backend/pomoro-do/**/gradle-wrapper.properties') }}
        restore-keys: |
          ${{ runner.os }}-gradle-
          
    # Gradle 래퍼 스크립트에 실행 권한 부여
    - name: Grant Execute Permission For Gradlew
      run: chmod +x backend/pomoro-do/gradlew
    
    # 테스트를 제외한 Gradle 빌드 수행 (CI 단계)
    - name: Build with Gradle
      run: cd backend/pomoro-do && ./gradlew build -x test

    ### CD
    # Docker Hub에 로그인 (보안) (CD 단계 준비)
    - name: Log in to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    # SpringBoot 어플리케이션의 Docker 이미지를 빌드하고 Docker Hub에 푸시 (CD 단계 준비)
    - name: Build and Push Docker Image for SpringBoot
      run: |
        cd backend/pomoro-do
        set -e # 명령 실패 시 스크립트 종료
        # 현재 디렉토리에 있는 Dockerfile을 사용하여 Docker 이미지를 빌드
       	docker-compose build
        # Docker Hub에 이미지 푸시
        docker-compose push
        
  deploy:
    # 이 작업은 build 작업이 성공적으로 완료된 후에만 실행다.
    needs: build
    runs-on: ubuntu-latest
    steps:
    # SSH를 통해 원격 서버에서 명령을 실행하여 Docker 컨테이너 배포
    - name: Docker Run
      uses: appleboy/ssh-action@v0.1.8
      with:
        host: ${{ secrets.SSH_HOST }}  # 원격 서버의 호스트명
        username: ${{ secrets.SSH_USERNAME }}  # 원격 서버의 사용자명
        key: ${{ secrets.SSH_PRIVATE_KEY }}  # 원격 서버의 비밀 키
        port: 22  # SSH 포트
        sync: false
        use_insecure_cipher: false
        timeout: 30s
        command_timeout: 10m
        debug: true  # 디버그 모드 활성화
        script: |
          cd /path/to/deploy
          docker-compose down # 기존 컨테이너 중지 및 제거
          docker-compose pull # 최신 이미지 가져오기
          docker-compose up -d # Docker Compose를 사용해 컨테이너 시작

[CICD 구축] GitHub Actions 시작하기

bu119 — Wed, 12 Jun 2024 09:00:08 +0900

https://docs.github.com/ko/actions

GitHub Actions 설명서 - GitHub Docs

GitHub Actions를 사용하여 리포지토리에서 바로 소프트웨어 개발 워크플로를 자동화, 사용자 지정 및 실행합니다. CI/CD를 포함하여 원하는 작업을 수행하기 위한 작업을 검색, 생성 및 공유하고 완

docs.github.com

GitHub Actions workflow 생성하기

https://docs.github.com/ko/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

Gradle을 사용하여 Java 빌드 및 테스트 - GitHub Docs

GitHub Actions CI(연속 통합) 워크플로를 만들어 Gradle을 사용하여 Java 프로젝트를 빌드하고 테스트할 수 있습니다.

docs.github.com

1. Github Repositorie 에서 Actions 클릭한다.

2. 검색 창에 우리 프로젝트에서 사용하는 Java with Gradle 을 검색한다.

3. Java with Gradle의 Configure를 클릭하면, Gradle wrapper 스크립트를 사용하여 Java 프로젝트를 빌드하고 테스트할 수 있는 workflow를 생성할 수 있다.

참고 자료

https://www.youtube.com/watch?v=R4KMDWzN3XE&t=1976s

https://white-world.tistory.com/411

https://velog.io/@jmjmjmz732002/%E5%AE%8C-Github-Action-Docker-EC2-Nginx-%ED%99%9C%EC%9A%A9%ED%95%9C-Springboot-CICD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-7-Github-Actions-CICD-docker-compose

[인프라 구축] Nginx 설치하기

bu119 — Sun, 9 Jun 2024 22:00:32 +0900

Nginx를 설치하는 방법에는 두 가지가 있다.

호스트 시스템에 Nginx를 직접 설치하기
Nginx를 Docker 컨테이너로 실행하기

Docker를 사용하면 서비스와 그 환경을 격리할 수 있기 때문에 호스트 시스템에 영향을 덜 줄 수 있다. 또한, Docker 컨테이너는 환경을 쉽게 복제하고 배포할 수 있으며, 여러 환경에서 일관되게 실행될 수 있도록 도와준다. 따라서 특히 복잡한 환경이나 여러 서비스를 함께 사용하는 경우에는 Docker를 사용하는 것이 유용하다.

즉, Docker를 사용하면 서비스와 해당 환경을 격리하여, 호스트 시스템에 미치는 영향을 최소화하고, 환경을 쉽게 복제하고 배포할 수 있으며, 관리를 단순화할 수 있다.

이러한 이유로, 우리 프로젝트에서는 Docker 컨테이너로 Nginx를 관리할 것이다.

두 가지 방법 모두 작성해놓겠다.

1. Nginx를 Docker 컨테이너로 실행하는 방법

1. Nginx 이미지 다운로드

Docker Hub에서 Nginx 이미지를 다운로드다.

docker pull nginx

이 명령어는 최신 버전의 Nginx 이미지를 다운로드한다.

즉, nginx:latest와 같은 이미지를 다운로드하는 것이다.

docker pull nginx:latest

실습

ubuntu@ip-000-000-000-000:~$ docker pull nginx

Using default tag: latest
latest: Pulling from library/nginx
09f376ebb190: Pull complete
5529e0792248: Pull complete
9b3addd3eb3d: Pull complete
57910a8c4316: Pull complete
7b5f78f21449: Pull complete
b7923aa4e8a6: Pull complete
785625911f12: Pull complete
Digest: sha256:0f041234098765asdfghjklxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest

ubuntu@ip-000-000-000-000:~$ docker images

REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
nginx         latest    4fxxxxxxxxxx   11 days ago     188MB

2. Nginx 컨테이너 실행

Nginx 컨테이너를 실행하여 포트 80과 443을 호스트에 연결한다.

이를 통해 외부에서 HTTP 및 HTTPS 요청을 처리할 수 있다.

docker run --name nginx -d -p 80:80 -p 443:443 nginx

사용된 옵션 의미 보기

--name nginx: 컨테이너의 이름을 nginx로 설정합니다.
-d: 컨테이너를 백그라운드에서 실행합니다.
-p 80:80 -p 443:443: 호스트의 80번 포트와 443번 포트를 컨테이너의 80번 포트와 443번 포트로 매핑합니다.

이렇게 하면 Nginx 서버가 Docker 컨테이너로 실행되며, 호스트의 80번 및 443번 포트로 들어오는 HTTP 및 HTTPS 트래픽이 컨테이너 내의 Nginx로 전달된다.

3. Nginx 설치 확인하기

Nginx를 설치했다면, 해당 서버의 ip 주소 또는 도메인 주소의 80포트로 접속한다.

Nginx가 정상적으로 실행되고 있다면 아래의 페이지가 보여진다.

실습

ubuntu@ip-000-000-000-000:~$ docker run --name nginx -d -p 80:80 -p 443:443 nginx
78000xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx000000000000

ubuntu@ip-000-000-000-000:~$ docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS                                             PORTS                                                                                                         NAMES
780000000000   nginx          "/docker-entrypoint.…"   11 minutes ago   Up 11 m                                   inutes   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/t                                   cp   nginx
460000000000   mysql:latest   "docker-entrypoint.s…"   2 days ago       Up 2 da                                   ys       0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp                                                          mysql-server

2. Nginx를 호스트 시스템에 직접 설치하는 방법

1. Nginx 설치

# Ubuntu 패키지 목록 업데이트
sudo apt update

# Nginx 설치
sudo apt install nginx -y

-y 옵션의 의미

명령어에 -y 옵션이 포함된 경우, 이는 설치 도중 "예"라고 자동으로 응답하겠다는 뜻이다.

예를 들어, sudo apt install nginx -y는 Nginx 설치 과정에서 사용자에게 확인을 요구하는 메시지에 자동으로 "예"라고 응답하여 설치를 진행하게 한다.

2. Nginx가 제대로 설치되었는지 확인

# Nginx 상태 확인
sudo systemctl status nginx

이 명령어는 Nginx가 실행 중인지 확인하고, 웹 브라우저에서 서버 IP 주소를 입력하여 기본 Nginx 환영 페이지가 나타나는지 확인한다.

[인프라 구축] Amazon Lightsail에 가비아 도메인 연결하기

bu119 — Sat, 8 Jun 2024 18:00:30 +0900

Amazon Lightsail 도메인 설정하기

1. Domains & DNS 탭에 접속한다.

AWS Lightsail > Domains & DNS 를 클릭한다.

2. Lightsail DNS zone을 생성한다.

Amazon Route 53에 새 도메인을 등록하려면 Register domain을 선택하고,

다른 곳에 등록된 도메인을 사용하는 경우에는 Create DNS zone을 선택하여 도메인을 등록할 수 있다.

다른 곳에 등록된 도메인을 사용하는 경우, DNS 영역을 생성하여 Lightsail에 추가할 수 있다.

가비아에 등록된 도메인을 사용하므로 Create DNS zone 버튼을 클릭한다.

3. Domain configuration 입력한다.

Domain source
- Use a domain from another registrar을 체크한다.
- 다른 등록기관의 도메인 사용을 의미한다.
Domain name
- 가비아에서 구매한 도메인 이름을 입력한다.
입력 완료 후 Create DNS zone를 클릭한다.

4. 도메인이 정상적으로 등록되면 DNS zones에 추가된 도메인이 보인다.

Lightsail 네임서버 확인하기

1. 도메인 관리에 접속한다.

2. 등록한 도메인에 할당된 Lightsail 네임서버를 확인한다.

Domains 탭을 누르면 아래의 창이 나온다. 4개의 네임서버를 할당 받았다.

가비아에 Lightsail 네임서버 등록하기

1. 가비아 사이트에 접속한다.

2. 가비아 도메인 관리에 접속한다.

가비아 > My가비아 > 서비스 관리 를 클릭한다.

사용할 도메인을 선택하고 관리를 클릭하면 도메인 관리로 접속된다.

3. 가비아 네임서버 설정으로 접속한다.

네임서버 설정에 접근하는 방법은 두 가지가 있다.

전체 도메인 탭에서 네임서버 옆 설정 버튼을 누른다.
도메인 정보 변경 탭에서 변경할 도메인을 선택하고 상단에 네임서버 탭을 누른다.

안전 잠금 서비스를 신청했다면 인증을 통해 안전 잠금을 풀어야 한다. 네임서버 설정으로 접속할 수 있다.

1번 방법.

2번 방법.

4. 네임서버 설정에서 Lightsail에서 할당해준 네임서버를 등록한다.

Lightsail에서 할당해준 네임서버를 입력하고 소유자 인증을 해야 적용된다.

Lightsail 네임서버가 정상적으로 등록되면 아래와 같은 창이 보인다.

Lightsail 인스턴스에 도메인 할당하기

모든 준비가 끝난 도메인을 Lightsail 인스턴스에 할당한다.

도메인 할당은 AWS Lightsail > Instance > Domains 에서 할 수 있다.

1. Ubuntu-Pomoro-Do 인스턴스 Manage를 클릭한다.

2. Ubuntu-Pomoro-Do 에 대한 다양한 정보와 함께 아래와 같은 창이 뜬다.

3. Domains 탭을 누르면 아래의 창이 나온다.

4. Assign domain 버튼을 클릭하여 할당 도메인을 설정한다.

5. AWS Lightsail > Domains & DNS 에서도 확인 가능하다.

AWS Lightsail > Instance >Domains 에서 해당 인스턴스에 도메인을 할당하면,

AWS Lightsail > Domains & DNS 보다 덜 복잡하게 설정을 할 수 있다.

참고 자료

https://bluescoder.com/amazon-lightsail%EC%97%90-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0/

https://gogowithsoo.tistory.com/entry/%EC%9B%8C%EB%93%9C%ED%94%84%EB%A0%88%EC%8A%A4-AWS-lightsail-%EC%97%90-%EA%B0%80%EB%B9%84%EC%95%84-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0

https://velog.io/@yeonju0511/AWS-lightsail-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0

[인프라 구축] 가비아 도메인 구매하기

bu119 — Sat, 8 Jun 2024 09:00:01 +0900

가비아 사이트에 접속하여 도메인을 구매하기

1. 가비아 사이트에 접속한다.

https://www.gabia.com

웹을 넘어 클라우드로. 가비아

그룹웨어부터 멀티클라우드까지 하나의 클라우드 허브

www.gabia.com

2. 도메인 검색창에 원하는 도메인을 입력한다.

사용가능한 도메인 목록이 가격과 함께 나타난다.

3. 마음에 드는 도메인을 선택하여 신청한다.

우리 프로젝트가 안드로이드 앱이기 때문에 사용자는 도메인을 직접 볼 수 없다.

그래서 '오늘의 도메인'에서 할인된 가격의 도메인 중에서 선택하여 구매할 것이다.

4. 도메인 서비스 신청하기

서비스 신청을 위한 정보 입력과 선택을 필요로 하는 창이 나온다.

서비스 관리 정보
- 추후에 변경가능하기 때문에, 일단 가비아 네임서버 사용을 등록한다.
부가서비스 추가
- 무료 서비스
동시 신청 가능 서비스
- 유료 서비스

[인프라 구축] MySQL 새로운 계정 만들기

bu119 — Fri, 7 Jun 2024 16:00:39 +0900

MySQL 새로운 계정 생성하기

MySQL 데이터베이스에 접속할 때 root 계정을 사용하는 것은 일반적으로 보안상 권장되지 않는다.

MySQL에서 root 계정 대신 사용할 새로운 계정을 생성하는 것은 좋은 보안 관행이다.

1. MySQL에 root 계정으로 로그인하기

먼저, root 계정 또는 다른 관리자 권한을 가진 계정으로 MySQL 서버에 로그인한다.

mysql -u root -p

사용된 옵션 의미 보기

-u root : 사용자 이름이 root임을 나타낸다.

-p : MySQL에 로그인할 때 비밀번호를 입력하라는 프롬프트가 나타나게 한다.

실습

ubuntu@ip-000-000-000-000:~$ docker exec -it mysql-server bash

bash-5.1# mysql -u root -p

Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 8.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

2. MySQL 사용자 계정 조회하기

다음 SQL 명령어를 실행하여 현재 존재하는 사용자 계정을 조회할 수 있다.

SELECT User, Host FROM mysql.user;

mysql 데이터베이스의 user 테이블에서 사용자 이름(User)과 호스트(Host) 정보를 가져온다.
결과는 현재 MySQL 서버에 존재하는 사용자 계정 목록을 보여준다.

위의 명령어를 나누어 실행하면 아래와 같이 된다.

mysql> use mysql;
mysql> select host, user from user;

실습

mysql> SELECT User, Host FROM mysql.user;
+------------------+-----------+
| User             | Host      |
+------------------+-----------+
| root             | %         |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
+------------------+-----------+
5 rows in set (0.00 sec)

3. 새로운 사용자 계정 생성하기

새로운 사용자를 생성하려면 다음과 같은 SQL 명령어를 사용하여 새 사용자 이름과 비밀번호를 설정해야한다.

새로운 사용자를 어떤 호스트에 생성할지 지정할 수 있다. localhost, 특정 호스트, 모든 호스트 크게 3가지로 구분된다.

1. localhost에서만 접속할 수 있도록 제한

데이터베이스 서버를 로컬 컴퓨터에서 운영할 때, localhost를 사용하여 그 서비스에 접근할 수 있다.

CREATE USER '새사용자이름'@'localhost' IDENTIFIED BY '비밀번호';

`새사용자이름` 칸에 입력하는 이름을 가진 사용자를 생성하고,
해당 사용자에게 로그인시 사용할 비밀번호를 설정한다.

예를 들어, MySQL 데이터베이스 서버를 자신의 컴퓨터에 설치하고 운영 중이라면, localhost를 사용하여 해당 데이터베이스 서버에 접속할 수 있다. 이 경우, localhost는 바로 그 컴퓨터를 가리키며, 다른 컴퓨터나 외부 네트워크를 통하지 않고 직접 로컬에서 접근하는 것을 의미한다.

2. 특정 호스트에서만 접속할 수 있도록 제한

CREATE USER '새사용자이름'@'특정호스트' IDENTIFIED BY '비밀번호';

특정 호스트에서만 접속하도록 제한하고 싶다면, 해당 호스트의 IP 주소나 도메인을 입력한다.

2. 모든 호스트에서 접속할 수 있도록 설정

외부에서의 접속을 허용하려면 'localhost' 대신 '%'를 사용한다.

CREATE USER '새사용자이름'@'%' IDENTIFIED BY '비밀번호';

%는 모든 주소를 나타내며, 모든 호스트에서 접속할 수 있도록 설정한다.

실습

새로운 사용자 계정을 생성한다.

mysql> CREATE USER 'admin'@'%' IDENTIFIED BY '비밀번호123';
Query OK, 0 rows affected (0.03 sec)

현재 존재하는 사용자 계정을 조회한다.

mysql> SELECT User, Host FROM mysql.user;
+------------------+-----------+
| User             | Host      |
+------------------+-----------+
| admin            | %         |
| root             | %         |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
+------------------+-----------+
6 rows in set (0.00 sec)

4. 새 사용자에게 데이터베이스 권한 부여하기

새 사용자가 데이터베이스에 대해 수행할 수 있는 작업을 정의하려면 권한을 부여해야 한다.

1. 새 사용자가 특정 데이터베이스의 모든 테이블에 대해 모든 권한을 갖기를 원한다면 '특정 데이터베이스 이름'.*을 사용한다.

GRANT ALL PRIVILEGES ON mydb.* TO '새사용자이름'@'localhost';

GRANT ALL PRIVILEGES ON mydb.* TO '새사용자이름'@'%';

mydb 데이터베이스의 모든 테이블에 대해 새 사용자가 모든 작업을 수행할 수 있는 권한을 부여한다.
즉, 해당 사용자에게 mydb 데이터베이스의 모든 권한을 부여한다.

2. 새 사용자가 모든 데이터베이스의 모든 테이블에 대해 모든 권한을 갖기를 원한다면 *.*를 사용한다.

GRANT ALL PRIVILEGES ON *.* TO '새사용자이름'@'localhost';

GRANT ALL PRIVILEGES ON *.* TO '새사용자이름'@'%';

사용된 옵션 의미 보기

PRIVILEGES ON : 모든 DB 권한을 준다
GRANT SELECT, INSERT, UPDATE ON : 특정 권한(CRU)을 준다.

실습

admin 계정에 pomodoro 데이터베이스에 대한 모든 권한을 부여한다.

mysql> GRANT ALL PRIVILEGES ON pomorodo.* TO 'admin'@'%';
Query OK, 0 rows affected (0.00 sec)

5. 변경사항 적용하기

변경된 권한을 즉시 적용하기 위해 아래 명령을 실행한다.

FLUSH PRIVILEGES;

실습

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

6. 새 사용자 권한 확인하기

MySQL에서 특정 사용자에게 부여된 권한을 확인하는 쿼리이다.

SHOW GRANTS FOR '새사용자이름'@'hostname';

SHOW GRANTS FOR '새사용자이름'@'%';

실습

1. 권한 부여 이전

mysql> SHOW GRANTS FOR 'admin'@'%';
+-----------------------------------+
| Grants for admin@%                |
+-----------------------------------+
| GRANT USAGE ON *.* TO `admin`@`%` |
+-----------------------------------+
1 row in set (0.00 sec)

2. pomorodo DB에 대한 권한 부여 후

mysql> SHOW GRANTS FOR 'admin'@'%';
+-----------------------------------------------------+
| Grants for admin@%                                  |
+-----------------------------------------------------+
| GRANT USAGE ON *.* TO `admin`@`%`                   |
| GRANT ALL PRIVILEGES ON `pomorodo`.* TO `admin`@`%` |
+-----------------------------------------------------+
2 rows in set (0.00 sec)

3. 모든 권한을 부여하면

mysql> SHOW GRANTS FOR 'admin'@'%';
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for admin@%                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO `admin`@`%`                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| GRANT ALLOW_NONEXISTENT_DEFINER,APPLICATION_PASSWORD_ADMIN,AUDIT_ABORT_EXEMPT,AUDIT_ADMIN,AUTHENTICATION_POLICY_ADMIN,BACKUP_ADMIN,BINLOG_ADMIN,BINLOG_ENCRYPTION_ADMIN,CLONE_ADMIN,CONNECTION_ADMIN,ENCRYPTION_KEY_ADMIN,FIREWALL_EXEMPT,FLUSH_OPTIMIZER_COSTS,FLUSH_STATUS,FLUSH_TABLES,FLUSH_USER_RESOURCES,GROUP_REPLICATION_ADMIN,GROUP_REPLICATION_STREAM,INNODB_REDO_LOG_ARCHIVE,INNODB_REDO_LOG_ENABLE,PASSWORDLESS_USER_ADMIN,PERSIST_RO_VARIABLES_ADMIN,REPLICATION_APPLIER,REPLICATION_SLAVE_ADMIN,RESOURCE_GROUP_ADMIN,RESOURCE_GROUP_USER,ROLE_ADMIN,SENSITIVE_VARIABLES_OBSERVER,SERVICE_CONNECTION_ADMIN,SESSION_VARIABLES_ADMIN,SET_ANY_DEFINER,SHOW_ROUTINE,SYSTEM_USER,SYSTEM_VARIABLES_ADMIN,TABLE_ENCRYPTION_ADMIN,TELEMETRY_LOG_ADMIN,TRANSACTION_GTID_TAG,XA_RECOVER_ADMIN ON *.* TO `admin`@`%` |
| GRANT ALL PRIVILEGES ON `pomorodo`.* TO `admin`@`%`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

7. 새 사용자 접속 테스트

mysql -u 새사용자이름 -p

실습

bash-5.1# mysql -u admin -p
Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 8.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

8. 사용자 삭제하기

DROP USER '새사용자이름'@'localhost';

DROP USER '새사용자이름'@'%';

실습

mysql> DROP USER 'admin'@'%';
Query OK, 0 rows affected (0.01 sec)

9. 권한 회수하기

권한을 회수하려면 REVOKE 문을 사용한다.

1. 'admin' 사용자에게 부여한 모든 권한 회수한다.

REVOKE ALL PRIVILEGES ON *.* FROM 'admin'@'%';

2. 'admin' 사용자에게 부여한 'pomorodo' 데이터베이스에 대한 모든 권한 취소한다.

REVOKE ALL PRIVILEGES ON pomorodo.* FROM 'admin'@'%';

실습

1. 모든 권한 회수

mysql> REVOKE ALL PRIVILEGES ON *.* FROM 'admin'@'%';
Query OK, 0 rows affected (0.01 sec)

2. 권한 확인

mysql> SHOW GRANTS FOR 'admin'@'%';
+-----------------------------------+
| Grants for admin@%                |
+-----------------------------------+
| GRANT USAGE ON *.* TO `admin`@`%` |
+-----------------------------------+
1 row in set (0.00 sec)

[인프라 구축] Docker로 MySQL 데이터베이스 구축하기

bu119 — Fri, 7 Jun 2024 15:00:05 +0900

Docker에 MySQL 컨테이너 띄우기

1. Lightsail에서 MySQL을 연결할 서버 포트 열기

2. Docker Hub에서 MySQL Image 다운받기

https://hub.docker.com/_/mysql

mysql - Official Image | Docker Hub

Quick reference Supported tags and respective Dockerfile links 8.4.0, 8.4, 8, lts, latest, innovation, 8.4.0-oraclelinux9, 8.4-oraclelinux9, 8-oraclelinux9, lts-oraclelinux9, oraclelinux9, innovation-oraclelinux9, 8.4.0-oracle, 8.4-oracle, 8-oracle, lts-or

hub.docker.com

docker pull mysql

다음 명령어로 MySQL Docker 이미지를 다운로드한다.
특정 버전을 적지 않으면, 최신 버전을 설치한다.

실습

ubuntu@ip-000-000-000-000:~$ docker pull mysql

Using default tag: latest
latest: Pulling from library/mysql
07bc88e18c4a: Pull complete
1a9c1668bf49: Pull complete
1021dda8eecf: Pull complete
fb61b56acac1: Pull complete
0bca83908a5b: Pull complete
165e8b3d37ca: Pull complete
3e1b086f1295: Pull complete
dba651668484: Pull complete
ed90f5355e12: Pull complete
0412f59ab2b5: Pull complete
Digest: sha256:aa0123456789asdfghjklxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Status: Downloaded newer image for mysql:latest
docker.io/library/mysql:latest

ubuntu@ip-000-000-000-000:~$ docker images

REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
mysql         latest    fcaaa1234xxx   5 weeks ago     578MB

3. 다운받은 Image로 MySQL Docker 컨테이너 생성하기

sudo docker run --name 컨테이너이름 -e MYSQL_ROOT_PASSWORD=비밀번호 -d -p 3306:3306 mysql:latest

사용된 옵션 의미 보기

sudo docker run : Docker 컨테이너를 실행
-d : 컨테이너를 백그라운드에서 실행 (detached 모드)
-p : 포트 (외부포트 : Docker 내부포트)
-p 3306:3306 : 호스트의 3306 포트를 컨테이너의 3306 포트로 연결.
- MySQL 서버에 호스트에서 접속할 수 있도록 한다.
-e : 환경변수 (PASSWORD) 설정
-e MYSQL_ROOT_PASSWORD=P@ssw0rd : 테이너의 환경 변수를 설정
- MySQL 루트 사용자의 비밀번호를 설정한다.
-name : 생성할 컨테이너 이름
-name mysql-container : 컨테이너에 이름을 지정 ("mysql-container"라는 이름을 사용)
mysql:latest : 실행할 도커 이미지의 이름
- 여러 버전의 mysql이 있다면, 'Tag'로 구분할 수 있다.

실습

ubuntu@ip-000-000-000:~$ docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

ubuntu@ip-000-000-000:~$ docker run --name mysql-server -e MYSQL_ROOT_PASSWORD=pomoro-d0@0517 -d -p 3306:3306 mysql:latest
1234567asdfghj??????????????????????????????????????????????

Docker에서 MySQL로 접속하기

4. Docker MySQL 컨테이너에 접속하기

sudo docker exec -it ${mysql-container 이름} bash

root@{containerName}:/# 으로 진입한다.

5. MySQL에 관리자로 접속하기

mysql -u root -p

MySQL 루트로 접속

실습

ubuntu@ip-000-000-000:~$ docker exec -it mysql-server bash

bash-5.1# mysql -u root -p

Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 8.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Enter password: 에 비밀번호 입력 (입력이 보이지 않음)
명령어를 입력한 후, 패스워드를 입력하면 mysql> 로 진입한 것을 확인할 수 있다.

6. 현재 Database 리스트 확인하기

mysql> SHOW DATABASES;

mysql> show databases;

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.00 sec)

위와 같이 자동으로 생성된 4개의 Database가 보인다. MySQL Container는 생성하였지만 Database를 만들지 않았다.

우리가 직접 사용할 새로운 Database를 생성해보도록 하자.

7. 새로운 Database 생성하기

CREATE DATABASE [DB이름]

create database [DB이름];

실습

mysql> CREATE DATABASE pomorodo;
Query OK, 1 row affected (0.01 sec)

'pomorodo'라는 이름을 가진 Database를 생성한다.
추후 프로젝트의 application.yml에서 Database 환경설정을 변경해야한다.

8. 생성된 새로운 DB 확인하기

mysql> SHOW DATABASES;

mysql> show databases;

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| pomorodo           |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

실습

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.01 sec)

mysql> CREATE DATABASE pomorodo;
Query OK, 1 row affected (0.00 sec)

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| pomorodo           |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

mysql>

[인프라 구축] 현재 사용자에게 Docker 접근 권한 부여하기

bu119 — Wed, 5 Jun 2024 23:00:40 +0900

현재 사용자에게 도커 접근 권한 주기

1. 현재 사용자 Docker 그룹에 추가하기

현재 사용자를 Docker 그룹에 추가하여 Docker 소켓에 액세스할 수 있는 권한을 부여한다. 이렇게 하면 sudo를 사용하지 않고도 Docker 명령을 실행할 수 있다.

sudo usermod -aG docker $USER

이 명령어는 현재 로그인한 사용자를 docker 그룹에 추가한다.

$USER는 현재 로그인한 사용자를 가리킨다.
docker 그룹은 Docker 명령어를 실행할 수 있는 권한을 가지고 있다.

사용된 옵션 의미 보기

sudo : 리눅스나 맥 OS에서 관리자 권한으로 실행할 때 사용하는 명령어
usermod : 사용자 계정을 수정하는 명령어
-aG docker : 사용자를 "docker" 그룹에 추가하는 옵션
$USER : 현재 로그인한 사용자 이름

따라서, 위의 명령어는

“ 현재 로그인한 사용자 ($USER)" 를 Docker 그룹에 추가하여,
일반 사용자 권한으로도 Docker 명령어를 실행할 수 있도록 한다.

이렇게 함으로써, Docker 명령어를 실행하기 위해 항상 root 계정으로 로그인하지 않아도 되므로, 보안 상의 이점이 있다.

2. Docker 그룹의 변경 사항을 반영하기

현재 사용자(ubuntu)를 로그아웃한 다음 다시 로그인하거나, 새로운 터미널 세션을 시작하면 변경 사항이 적용된다.

즉, 현재 사용자(ubuntu)로 로그인된 상태에서 sudo를 사용하지 않고도 Docker 명령을 실행할 수 있게 된다.

특정 사용자를 Docker 그룹에 추가하기

사용자 ubuntu 가 현재 로그인되어 있지만, sudo 없이도 특정 작업을 수행하려면 사용자 ubuntu 를 Docker 그룹에 추가하여 Docker 명령을 실행할 수 있도록 권한을 부여할 수 있다.

이렇게 하면 sudo 를 사용하지 않고도 Docker 명령을 실행할 수 있다.

1. 특정 사용자 Docker 그룹에 추가하기

sudo usermod -aG docker 특정사용자이름

실습

ubuntu@ip-000-000-000-000:~$ sudo usermod -aG docker bu

usermod: user 'bu' does not exist

에러 발생

'bu' 사용자가 존재하지 않는다는 메시지가 나타났다.

user 'bu' does not exist

이는 사용자를 잘못 입력했거나 해당 사용자가 시스템에 존재하지 않는 경우 발생할 수 있다.

사용자를 Docker 그룹에 추가하려면 실제로 존재하는 사용자를 대상으로 명령을 실행해야 한다.

의문 발생

2. 현재 사용자 이름 확인하기

sudo whoami

실습

ubuntu@ip-000-000-000-000:~$ sudo whoami

root

의문 해결

❗여기에서 로그인된 사용자는 ubuntu인데 실제 사용자가 root로 나타나는 이유는?

사용자 ubuntu 는 현재 시스템에서 로그인된 사용자이다.

sudo 명령어는 일시적으로 root 권한을 얻어 특정 명령어를 실행할 수 있도록 하는 도구이다.

사용자 ubuntu 는 일반 사용자이며, 시스템 관리 작업과 같은 특정 작업을 수행하기 위해서는 일반적으로 root 권한이 필요하다.

따라서, sudo whoami를 실행하면 현재 사용자인 ubuntu 가 sudo 를 통해 일시적으로 root 권한을 얻어서 whoami 명령어를 실행한 것이다.

에러 해결

3. 현재 로그인한 실제 사용자의 정보 확인하기

실제 사용자 이름을 확인하려면 다음 명령을 사용하여 현재 로그인한 사용자의 정보를 확인할 수 있습니다.

whoami

실습

ubuntu@ip-000-000-000-000:~$ whoami

ubuntu

4. 현재 사용자를 명시적으로 Docker 그룹에 추가하기

현재 로그인한 실제 사용자 이름은 ubuntu이다.

ubuntu를 명시적으로 Docker 그룹에 추가하여 Docker를 사용할 수 있다.

sudo usermod -aG docker ubuntu

실습

ubuntu@ip-000-000-000-000:~$ sudo usermod -aG docker ubuntu

5. Docker 그룹의 변경 사항을 반영하기

현재 사용자(ubuntu)를 로그아웃한 다음 다시 로그인하거나, 새로운 터미널 세션을 시작하면 변경 사항이 적용된다.

즉, 현재 사용자(ubuntu)로 로그인된 상태에서 sudo를 사용하지 않고도 Docker 명령을 실행할 수 있게 된다.

ubuntu@ip-000-000-000-000:~$ docker ps

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

의문 발생

새로운 사용자를 생성하는 것과 현재 사용자인 ubuntu를 그대로 사용하여 Docker 접근 권한을 부여하는 것 간의 차이는?

새로운 사용자를 생성하고 해당 사용자를 Docker 그룹에 추가하여 Docker를 사용할 수 있도록 권한을 부여하는 것과

현재 사용자인 ubuntu를 Docker 그룹에 추가하는 것 간의 차이는 크게 없다.

두 경우 모두 Docker를 사용할 수 있는 사용자를 생성하고 권한을 부여하는 것이며, 이를 통해 보다 세분화된 사용자 관리 및 보안을 구현할 수 있다.

해당 사용자를 Docker 그룹에서 제거하기

사용자를 Docker 그룹에서 제거하려면 gpasswd 명령을 사용할 수 있다.

sudo gpasswd -d ${USER} docker

그러나 주의해야 할 점은,

Docker 그룹에서 사용자를 제거하더라도 해당 사용자가 이미 Docker 컨테이너를 실행하고 있는 경우에는 여전히 해당 컨테이너에 대한 접근이 허용될 수 있다.

따라서, Docker 그룹에서 사용자를 제거한 후에는 사용자가 이미 실행 중인 Docker 작업을 모니터링하고 관리해야 한다.

실습

ubuntu@ip-000-000-000-000:~$ sudo gpasswd -d ubuntu docker

현재 사용자 ubuntu를 Docker 그룹에서 제거할 수 있다.

[인프라 구축] Ubuntu에 Docker 엔진 설치하기

bu119 — Wed, 5 Jun 2024 22:00:52 +0900

Docker Docs 를 참고하여 Amazon Lightsail Ubuntu에 Docker를 설치합니다.

Install Docker Engine on Ubuntu

Jumpstart your client-side server applications with Docker Engine on Ubuntu. This guide details prerequisites and multiple methods to install Docker Engine on Ubuntu.

docs.docker.com

1. Uninstall old versions (이전 버전 제거)

Docker Engine을 설치하기 전에 충돌하는 패키지를 제거해야 합니다.

Linux 배포판에서 비공식 Docker 패키지를 제공할 수 있으며, 이는 Docker에서 제공하는 공식 패키지와 충돌할 수 있습니다. Docker Engine 공식 버전을 설치하기 전에 이러한 패키지를 제거해야 합니다.

다음 명령을 실행하여 충돌하는 모든 패키지를 제거합니다.

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done

2. Install using the apt repository (apt 저장소를 사용하여 설치)

새 호스트 머신에 Docker Engine을 처음 설치하기 전에 Docker apt저장소를 설정해야 합니다.

그런 다음 해당 저장소에서 Docker를 설치하고 업데이트할 수 있습니다.

1. Docker apt저장소를 설정합니다.

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

3. Install Docker Engine (docker 엔진 설치)

2. Docker 패키지를 설치합니다.

최신 버전을 설치하려면 다음을 실행하세요.

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. 이미지를 실행하여 설치가 성공적으로 완료되었는지 확인하세요 "hello-world".

sudo docker run hello-world

이 명령은 테스트 이미지를 다운로드하여 컨테이너에서 실행합니다.

컨테이너가 실행되면 확인 메시지를 출력하고 종료됩니다.

4. Docker 버전 확인

sudo docker version

[인프라 구축] Lightsail 인스턴스에 SSH로 액세스

bu119 — Wed, 5 Jun 2024 18:00:49 +0900

MobaXterm을 활용하여 Lightsail 인스턴스에 SSH로 접속할 것이다.

MobaXterm 다운로드하기

MobaXterm을 공식 홈페이지에서 다운로드한다.

https://mobaxterm.mobatek.net/download.html

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing - includes X server, enhanced SSH client and much more!

mobaxterm.mobatek.net

Lightsail 개인키 다운로드하기

개인키는 AWS Lightsail > Instance > Connect 하단에서 다운로드할 수 있다.

1. Ubuntu-Pomoro-Do 인스턴스 Manage를 클릭한다.

2. Ubuntu-Pomoro-Do 에 대한 다양한 정보와 함께 아래와 같은 창이 뜬다.

3. Connect 탭을 누르면 아래의 창이 나온다.

4. Download default key를 클릭하여 pem 키를 다운로드한다.

MobaXterm을 사용하여 Lightsail 인스턴스에 SSH로 접속하기

1. MobaXterm 실행한다.

2. Session을 클릭한다.

3. SSH를 클릭한다.

아래와 같은 창이 나타난다.

4. SSH settings를 작성한다.

Remote host* 에 고정 IP를 작성한다.
Advanced SSH settings를 클릭한다.
Use private key를 선택하여 우측의 파일 모양을 클릭한다.
다운로드하여놓은 Lightsail의 pem키를 넣어준다.

Lightsail 인스턴스에 SSH로 접속 성공

참고 자료

https://backendcode.tistory.com/270

https://velog.io/@turret1234/AWS-Lightsail-nginx-React-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-1

https://thesse.tistory.com/101

[인프라 구축] Amazon Lightsail, Networking 설정

bu119 — Wed, 5 Jun 2024 09:00:15 +0900

고정 IP 주소 생성하기

우선.. 네트워크 설정부터 하자. 고정 IP 주소를 생성할 것이다.

1. Create static IP을 클릭한다.

2. 인스턴스 연결 설정을 작성한다.

인스턴스를 연결하고 고정 IP 이름을 지어준다.

연결된 인스턴스가 있다면 고정 IP 연결은 무료!!

앞서 만든 Ubuntu-Pomoro-Do 인스턴스를 연결해 준다.
고정 IP 이름은 StaticIp-Pomoro-Do 로 지어준다.

3. Create를 누르면 고정 IP 주소에 연결된 것을 볼 수 있다.

방화벽 설정 (사용 포트 번호 열기)

우선, 기존 포트에 MySQL, HTTPS , SpringBoot 서버 포트를 추가로 생성할 것이다.

1. Ubuntu-Pomoro-Do 인스턴스 Manage를 클릭한다.

2. Ubuntu-Pomoro-Do 에 대한 다양한 정보와 함께 아래와 같은 창이 뜬다.

3. Networking을 누르면 아래의 창이 나온다. IPv4 Firewall 에서 Add rule 을 클릭하여 사용할 포트를 열어준다.

4. 열려는 포트와 프로토콜을 지정한다.

0 - 65535와 같이 대시를 사용하여 포트 범위를 지정한다.

5. MySQL, HTTPS , SpringBoot 서버로 사용할 포트 번호를 열어준다.

DB로 사용하는 MySQL 포트로 사용할 3306 포트를 연다.

HTTPS 포트로 사용할 443 포트를 연다.

SpringBoot 서버 포트로 사용할 8080 포트를 연다.

6. 필수적으로 필요한 MySQL, HTTPS , SpringBoot 서버 포트 생성을 완료했다.

[인프라 구축] Amazon Lightsail 인스턴스 생성하기

bu119 — Tue, 4 Jun 2024 23:00:15 +0900

토이프로젝트인 만큼 개발 비용을 최대한 아끼기 위해

Amazon Lightsail의 "처음 3개월은 무료" 인스턴스 중 사양이 가장 높은 것을 선택할 것이다.

Amazon Lightsail 인스턴스 생성하기

https://aws.amazon.com/ko/lightsail/?nc2=h_ql_prod_fs_ls

가상 프라이빗 서버 및 웹 호스팅–Amazon Lightsail—Amazon Web Services

WordPress, Magento, Prestashop, Joomla와 같은 사전 구성된 애플리케이션을 통해 단 몇 번의 클릭으로 블로그, 전자 상거래 또는 개인 웹 사이트를 구축합니다.

aws.amazon.com

위의 사이트에서 Amazon Lightsail 을 시작한다.

AWS에 로그인을 하고 Lightsail을 누르면 아래의 창이 나타난다.

1. Lightsail 인스턴스 생성를 생성하기 위해 Create Instance를 클릭한다.

2. 우분투 선택하고, 버전은 상관없기 때문에 최신버전으로 쓰겠다.

3. 선택 사항의 "SSH 키" 부문에서 "사용자 지정 키 생성" 버튼을 누른다.

3-1. 리전 선택 창이 뜨면, 확인하고 생성 버튼을 누른다.

3-2. 새 SSH 키 페어 생성 창이 뜨면, "키 페어의 이름"을 정하고 "키 페어 생성" 버튼을 누른다.

3-3. 키 페어가 생성되었다는 창이 뜨면, 프라이빗 키 다운로드를 누른다.

다시 다운로드 할 수 없기 때문에 잃어버리면 안된다!!!!! 보안 중요!!!!

4. 퍼블릭 IPv4 주소가 필요하니까 Dual-stack로 선택한다.

비용을 최대한 줄이기위해 처음 3개월은 무료라고 적혀있는 instance를 구매할꺼예요. 그중에서 사양이 가장 좋은 instance를 쓸거예요!!

5. Lightsail 리소스에는 고유한 이름이 필요하다.

Lightsail에서는 각 리소스(인스턴스, 디스크 등)에 고유한 이름을 지정해야 한다.

그래서 나는 앱과 관련 있으면서도 내가 기억하기 쉬운 이름으로 인스턴스를 만들었다.

6. 모든 설정을 마쳤으면 인스턴스 생성 버튼을 누른다.

7. 생성된 인스턴스가 "시작중" 상태로 보인다.

8. 생성된 인스턴스가 "실행중" 상태로 바꼈다. 이제 사용 가능하다!

인스턴스 생성 버튼을 눌렀는데, 오류 메시지가 뜰 수도 있습니다.

이 경우 실제로는 생성 요청이 정상적으로 처리된 상태일 수 있으므로, 페이지를 새로고침하여 인스턴스 목록을 확인해보는 것이 좋습니다.

[MSA 구축하기] 9. API Gateway와 Eureka 서버 연동하기 (API Gateway)

bu119 — Fri, 22 Mar 2024 09:00:22 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

이번에는, API Gateway를 Eureka 클라이언트로 등록하여 API Gateway와 Eureka 서버를 연동할 것이다.

API Gateway와 Eureka 서버 연동 프로세스

클라이언트가 API Gateway에 요청을 하면 API Gateway 가 Eureka server에 등록된 서비스들을 조회하고 해당 서비스로 라우팅을 해준다.

예를 들어, 로그인을 한다는 가상의 시나리오에 대해 어떻게 동작하는지 살펴보자.

①: 각 인스턴스를 실행하여 유레카 서버에 등록한다.
- 새로운 인스턴스는 시작할 때 유레카 서버에 IP, 호스트 주소, 포트 정보 등을 전달한다.
- 유레카 서버는 등록된 인스턴스들을 주기적으로 상태를 체크하면서 해당 인스턴스를 관리한다.
②: 클라이언트에서 로그인 요청이 API 게이트로 온다.
③④: API 게이트웨이에서 받은 로그인 요청을 어떤 인스턴스에서 처리할 수 있을지 서비스 디스커버리에서 찾는다.
- 매번 질의하지 않고 인스턴스 정보를 캐싱한다.
⑤: API 게이트웨이는 로그인 처리 요청을 Auth Service에 한다.
⑥: Auth Service의 응답 결과를 클라이언트에 전달한다.

게이트웨이와 Eureka 서버 연동

Eureka 서버는 각각의 비즈니스 로직 처리를 담당하는 스프링 부트 애플리케이션 목록들을 가지고 있다.

MSA를 구성하는 요소는 자동으로 오토 스케일링되기 때문에 새로 생긴 서버의 IP를 게이트웨이가 알지 못한다.

따라서 Eureka 서버가 해당 목록들을 관리하며 Gateway에게 전달한다.

스프링 클라우드 게이트웨이 Eureka 클라이언트 설정

1. Eureka 클라이언트 설정을 위한 의존성 추가

(1) 기존 apigateway-service의 build.gradle에 의존성 추가하기

// build.gradle

ext {
  set('springCloudVersion', "2023.0.0")
}

dependencies {
  implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}

dependencyManagement {
  imports {
    mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
  }
}

(2) 처음 부터 Spring Initializr에서 apigateway-service를 생성할 때 의존성 같이 등록하기

3. Eureka 서버와 연결

apigateway-service의 application.yml 파일에서 변수 설정을 통해 Eureka 서버에 등록할 수 있다.

# application.yml

# eureka 클라이언트 설정 (eureka 서버와 연결)
eureka:
  client:
    # eureka 서버에 등록할지 여부
    register-with-eureka: true
    # eureka 서버로 부터 인스턴스들의 정보를 가져올 것인지 설정하는 속성
    fetch-registry: true
    # eureka 서버 주소에 마이크로서비스 정보 등록
    service-url:
      defaultZone: http://admin:1234mst@localhost:8761/eureka

apigateway-service의 application.yml 파일 전체

# application.yml

server:
  port: 8000

# eureka 클라이언트 설정 (eureka 서버와 연결)
eureka:
  client:
    # eureka 서버에 등록할지 여부
    register-with-eureka: true
    # eureka 서버로 부터 인스턴스들의 정보를 가져올 것인지 설정하는 속성
    fetch-registry: true
    # eureka 서버 주소에 마이크로서비스 정보 등록
    service-url:
      defaultZone: http://admin:1234mst@localhost:8761/eureka

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081/
          predicates:
            - Path=/user-service/**
          filters:
            - RewritePath=/user-service/(?<segment>.*),/$\{segment}
        - id: beverage-service
          uri: http://localhost:8082/
          predicates:
            - Path=/beverage-service/**
          filters:
            - RewritePath=/beverage-service/(?<segment>.*),/$\{segment}
        - id: community-service
          uri: http://localhost:8083/
          predicates:
            - Path=/community-service/**
          filters:
            - RewritePath=/community-service/(?<segment>.*),/$\{segment}

Spring Cloud Eureka 서버 실행

참고자료

https://covenant.tistory.com/251

https://covenant.tistory.com/252

https://wonit.tistory.com/497

https://velog.io/@boo105/MSA-EUREKA-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

[MSA] Spring Cloud Gateway Filter (API Gateway)

bu119 — Thu, 21 Mar 2024 18:00:11 +0900

Spring Cloud Gateway를 사용한 요청/응답 프로세스

Spring Cloud Gateway는 다음과 같이 마이크로서비스들과 클라이언트단의 라우팅 역할을 해준다.

클라이언트는 원하는 서비스를 호출하기 위해 Spring Cloud gateway로 요청을 보낸다.
Spring Cloud gateway에서는 어떤 서비스로 가야 하는지 분기처리를 해준다.
이때 Filter 기능을 통해 조건을 분기한다.

점선 네모 박스는 Spring Cloud gateway안에서 일어나는 일을 확대한 것이다.

Spring Cloud Gateway Filter 란?

Spring Cloud Gateway의 필터는 클라이언트의 요청을 가로채고 수정하거나, 다양한 작업을 수행하여 마이크로서비스 아키텍처에서의 라우팅, 보안, 모니터링 등을 처리한다.

즉, Http 요청, 응답에 대한 내용을 추가/수정할 수 있도록 한다.

Pre Filter: 요청 전 처리하는 필터, 사전에 정의
Post Filter: 요청 후 처리하는 필터, 사후에 정의,

따라서, API Gateway가 담당하고 있는 라우팅이라는 기능뿐만 아니라 부가기능을 추가할 수 있다.

Spring Cloud Gateway 동작 과정

클라이언트가 Spring Cloud Gateway에 요청을 하게 되면 Spring Cloud gateway 내부의 Predicate에서 어떤 서비스로 갈지 판단 후 요청을 전달한다.

Spring Cloud gateway에 요청이 들어오면 Gateway Handler Mapping을 통해 클라이언트로부터 어떤 요청이 들어왔는지 정보를 받고 있다.
그 후사전 Filter와 사후 Filter를 통해 요청정보를 구성할 수 있습니다.
- Pre Filter :Http 요청에 대해 과정을 수행한다.
- Post Filter : Http 응답에 대해 과정을 수행한다.

Spring Cloud Gateway Filter의 동작 순서

클라이언트가 Spring Cloud Gateway에 요청을 하면, Spring Cloud Gateway Filter는 아래의 순서로 동작한다.

Client Request
Gateway Handler (진입점)
predicate 영역에서의 분기
pre-filter 처리
서비스에서의 요청 처리
post-filter
Gateway Handler
Client

1. Gateway Handler Mapping

클라이언트가 요청이 Gateway에 도달하면 Handler Mapping을 통해 적절한 Route로 매핑된다.

Gateway Handler Mapping은 들어오는 요청이 어떤 Route에 매핑되는지를 결정합니다.
이를 통해 클라이언트가 요청한 URI, 헤더, HTTP 메서드 등과 일치하는 Route를 찾아냅니다.
Route에는 실제로 요청을 처리할 서비스의 위치 및 추가 구성이 포함될 수 있습니다.

2. Predicate

요청에 대한 사전 조건을 분기하여 적절한 Filter를 거쳐 서비스로 라우팅 되도록 한다.

Predicate은 Handler Mapping을 통해 선택된 Route에 대한 추가적인 요청 조건을 검사합니다.
이 조건들은 주어진 요청이 특정한 Route로 전달되어야 하는지를 결정합니다.
예를 들어, 특정 URI 패턴, 특정 헤더의 존재 여부, 혹은 요청이 특정한 호스트로부터 오는지를 확인할 수 있습니다.

3. Pre Filter

HTTP 요청에 대한 사전 처리를 담당한다.

Pre Filter는 실제 요청이 핸들러로 전달되기 전에 실행됩니다. 이 단계에서는 요청에 대한 사전 처리를 수행합니다.
주로 인증, 권한 부여, 요청 수정 등의 작업을 수행할 수 있습니다.
예를 들어, JWT 토큰을 확인하고, 요청에 특정 헤더를 추가하거나 수정할 수 있습니다.

5. Post Filter

HTTP 응답에 대한 후속 처리를 담당한다.

Post Filter는 핸들러에서 응답이 생성되고 클라이언트로 반환되기 전에 실행됩니다.
이 단계에서는 응답에 대한 후속 처리를 수행합니다.
주로 응답에 대한 로깅, 헤더 수정, 캐싱 등의 작업을 수행할 수 있습니다.
예를 들어, 응답에 특정 헤더를 추가하거나 수정하고, 응답을 로깅하여 추적 및 모니터링에 활용할 수 있습니다.

Spring Cloud Gateway Filter 적용 방법

Filter를 정의하는 방법은 크게 2가지가 있다.

yml 또는 properties 파일에 정의
Java 코드로 정의

참고자료

https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/

https://velog.io/@sungjin0757/Spring-Cloud%EB%A1%9C-%EA%B0%9C%EB%B0%9C%ED%95%98%EB%8A%94-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-API-GATEWAYFilter

https://velog.io/@ychxexn/Spring-Cloud-Gateway-Filter-%EC%A0%81%EC%9A%A9

https://yarisong.tistory.com/m/46

https://velog.io/@korea3611/Spring-Boot-Spring-Cloud-Gateway%EC%97%90%EC%84%9C-filter-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-MSA3

https://spring.io/blog/2022/08/26/creating-a-custom-spring-cloud-gateway-filter

[MSA 구축하기] 8. Spring Cloud Gateway에 필터 적용하기 (API Gateway)

bu119 — Thu, 21 Mar 2024 09:00:28 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

이번에는, Spring Cloud Gateway Routes의 Filters를 설정할 것이다.

API Gateway 파트 4

https://bu119.tistory.com/94

[MSA 구축하기] 6. Spring Cloud Gateway 라우팅 설정하기 (API Gateway)

우리는 Spring Cloud를 활용하여 MSA를 구축한다. 이번에는, API Gateway의 라우팅을 설정할 것이다. API Gateway 파트 2 마이크로서비스 서버를 2개 이상 준비하자. 라우팅을 설정하는 방법에는 3가

bu119.tistory.com

Spring Cloud Gateway 라우팅을 설정했지만 서버를 실행했을 때 제대로 연결되지 않았다. 이러한 문제는 Gateway 설정 경로 및 프록시 설정과 실제 서비스 코드 간의 불일치 때문에 발생했다.

https://bu119.tistory.com/97

[MSA 구축하기] 7. Spring Cloud Gateway를 활용한 경로 수정 (API Gateway)

우리는 Spring Cloud를 활용하여 MSA를 구축한다. 앞서, API Gateway의 라우팅을 설정했는데 실행했을 때 결과 값이 다르게 나타났다. 그 이유에 대해 알아보자. API Gateway 파트 3 우선, 작성한 코

bu119.tistory.com

Gateway 설정 경로와 서비스 경로 일치를 위해 user-service의 컨트롤러 경로를 수정했다. 이 경우는 필터를 사용하지 않고, 단순히 경로를 라우팅 대상으로 전달하는 것으로 문제를 해결했다.

❓경로 수정으로 문제를 해결하면, user-service의 모든 컨트롤러에 @RequestMapping("/user-service") 을 추가해야 하는 상황이 발생한다. 다른 마이크로서비스들도 각 서비스의 이름으로 @RequestMapping을 추가해야 히고 이러한 부분이 상당히 비효율적이라고 느껴졌다. 구글 검색을 통해 다른 방법을 찾을 수 있었다. Gateway의 Filter를 사용하여 URI 경로를 재작성하여 요청을 백엔드 서비스로 라우팅 하는 방법이 있다.

⭐API Gateway 라우팅 필터 설정을 해야 하는 이유?

클라이언트가 http://localhost:8000/user-service/으로 요청을 보냈을 때 http://localhost:8081/user-service/로 프록시하기 위해서는 user-service의 모든 컨트롤러에@RequestMapping("/user-service")을 추가해줘야 하는 상황이 발생한다.

그러나 이러한 접근 방식은 많은 양의 코드를 수정해야 하고, 유지보수에 어려움을 줄 수 있다. 또한, 서비스를 추가하거나 제거할 때마다 코드를 변경해야 하므로 유연성이 떨어진다.

따라서, Gateway의 Filter를 사용하여 URI 경로를 재작성하여 요청을 백엔드 서비스로 라우팅 할 수 있다.

클라이언트가 http://localhost:8000/user-service/로 요청을 보내면, Gateway의 Filter가 요청의 URI를 수정하여 http://localhost:8081로 프록시 하게 된다.

다시 말해, 아래의 형태로 라우팅 하려면 Gateway의 Filter를 사용하여 URI 경로를 재작성해야 한다.

http://localhost:8000/user-service/name ➡️ http://localhost:8081/name

Spring Cloud Gateway Filter 적용 방법

Filter 를 정의하는 방법은 크게 2가지가 있다.

yml 또는 properties 파일에 정의할 수 있다.
Java 코드로 정의할 수 있다.

현재, 우리는 yml 파일을 통해 Spring Cloud Gateway Filter를 정의할 것이다.

우리의 서비스에는 3개의 마이크로서비스가 있다.

user-service
beverage-service
community-service

2. application.yml를 통한 경로 설정

apigateway-service의 application.yml에 filters 추가

RewritePath 필터를 사용하여, 게이트웨이가 요청을 프록시할 때 백엔드 서비스가 요구하는 경로로 요청을 재작성한다.

# apigateway-service: application.yml

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081
          predicates:
            - Path=/user-service/**
          filters:
            - RewritePath=/user-service/(?<segment>.*),/$\{segment} # 추가

RewritePath 필터는 요청의 경로를 재작성한다.
=/user-service/(?<segment>.*)는 정규 표현식을 사용하여 경로를 다시 쓰는 패턴을 정의한다.
- 여기서 /user-service/ 다음에 오는 모든 것을 포함하는 부분을 캡처하여 $\{segment}에 할당한다.
- 이것은 URI 경로에서 /user-service/ 부분을 캡처하지 않고 그 뒤의 모든 것을 캡처한다.
/$\{segment}는 재작성된 경로를 나타낸다.
- ${segment}는 앞서 캡처한 새로운 경로 세그먼트를 나타낸다.
- 따라서, 이 필터는 /user-service/ 뒤에 오는 모든 것을 끝에 슬래시가 없는 경로로 재작성한다.

다시 말해,

RewritePath 필터는 요청이 게이트웨이를 통과할 때 /user-service/로 시작하는 모든 경로를 해당 경로 뒤에 슬래시가 없는 형태로 재작성한다. 예를 들어, /user- service/profile은 /profile로 재작성된다.

이러한 필터는 라우터가 백엔드 서비스에 전달되기 전에 요청을 변경하거나 수정할 필요가 있는 경우에 유용하다.

apigateway-service의 application.yml 전체 코드

# apigateway-service: application.yml

server:
  port: 8000

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081/
          predicates:
            - Path=/user-service/**
          filters:
            - RewritePath=/user-service/(?<segment>.*),/$\{segment}
        - id: beverage-service
          uri: http://localhost:8082/
          predicates:
            - Path=/beverage-service/**
          filters:
            - RewritePath=/beverage-service/(?<segment>.*),/$\{segment}
        - id: community-service
          uri: http://localhost:8083/
          predicates:
            - Path=/community-service/**
          filters:
            - RewritePath=/community-service/(?<segment>.*),/$\{segment}

user-service의 UserController.java

// user-service: UserController.java (8081 포트 사용)

package com.caffeinedoctor.userservice.controller;

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

@RestController
public class UserController {

    @GetMapping("/")
    public String getServiceName(){
        return "user-service";
    }
}

각 마이크로서비스 서버 실행

http://localhost:8081/

user-service

http://localhost:8082/

beverage-service

http://localhost:8083/

community-service

apigateway-service 서버 실행

http://localhost:8000/user-service/

apigateway-service

http://localhost:8000/beverage-service/

apigateway-service

http://localhost:8000/community-service/

apigateway-service

정리하자면,

첫 번째 "7. Spring Cloud Gateway를 활용한 경로 수정" 방법은 요청된 경로를 변경하지 않고 그대로 전달하고,

두 번째 "8. Spring Cloud Gateway에 필터 적용하기" 방법은 요청된 경로를 수정하여 서버로 전달한다.

참고자료

https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/

[MSA 구축하기] 7. Spring Cloud Gateway를 활용한 경로 수정 (API Gateway)

bu119 — Wed, 20 Mar 2024 09:00:41 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

앞서, API Gateway의 라우팅을 설정했는데 실행했을 때 결과 값이 다르게 나타났다. 그 이유에 대해 알아보자.

API Gateway 파트 3

우선, 작성한 코드를 살펴보자.

1. user-service의 UserController.java 파일

// user-service: UserController.java (8081 포트 사용)

package com.caffeinedoctor.userservice.controller;

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

@RestController
public class UserController {

    @GetMapping("/")
    public String getServiceName(){
        return "user-service";
    }
}

user- service 서버 실행

http://localhost:8081/

2. apigateway-service의 application.yml 파일

# apigateway-service: application.yml

server:
  port: 8000

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081/
          predicates:
            - Path=/user-service/**
        - id: beverage-service
          uri: http://localhost:8082/
          predicates:
            - Path=/beverage-service/**
        - id: community-service
          uri: http://localhost:8083/
          predicates:
            - path=/community-service/**

apigateway-service 서버 실행

http://localhost:8000/user-service/

404 에러 발생

❓라우팅 연결을 했는데 두 주소의 결과가 다르게 나타난다. 다시 말해, API Gateway service의 라우팅 설정을 마쳤는데 각 서비스로 연결이 되지 않는 문제가 발생했다. apigateway-service의 yml 파일에 설정을 했는데 8000번 포트에서 8081, 8082, 8083 포트로 연결이 안 된다.

http://localhost:8000/user-service/에서 http://localhost:8081/로 연결이 안된다.
http://localhost:8000/beverage-service/에서 http://localhost:8082/로 연결이 안된다.
http://localhost:8000/community-service/에서 http://localhost:8083/으로 연결이 안된다.

왜 그럴까? 그 이유를 찾기 위해 또 열심히 구글 검색을 했다.

결론적으로, 이 문제는 Gateway 설정 경로와 실제 서비스 코드 간의 API 통신 경로 불일치로 인해 발생한다는 것을 알아냈다. 위의 코드 설정에 따르면 http://localhost:8000/user-service/로 들어오는 요청이 http://localhost:8081/로프락시되는 것을 예상했으나 실제로는 http://localhost:8081/user-service/로 전달되는 것이었다.

이 문제를 해결하기 위해 두 가지 방법을 찾았다.

첫 번째 방법은 간단히 경로를 수정하여 서비스 코드와 일치시키는 것이다.
두 번째 방법은 Spring Cloud Gateway에서 URI 경로를 재작성하는 필터를 적용하는 것이다. Gateway는 이러한 필터를 통해 들어오는 요청과 나가는 응답을 수정할 수 있으며, 이를 통해 Gateway와 서비스 간의 일관성을 유지할 수 있다.

⭐API Gateway에서 마이크로서비스로 라우팅 연결이 제대로 되지 않은 이유?

결론부터 말하자면,

Gateway 구성에서 정의된 경로 및 프락시 설정과 실제 서비스 코드 간의 불일치 때문에 문제가 발생했다.

Gateway 설정 경로
- http://localhost:8000/user-service/** 으로 요청하면
- http://localhost:8081/user-service/** 으로 요청이 넘어간다.
user-service 서비스 경로
- user-service 서비스 API @GetMapping("/") 으로 설정되어있다.
- http://localhost:8081/ 으로 API 통신을 하고있다.
- 즉, http://localhost:8000/user-service/ 에 대해서는 API가 설정되어 있지 않아 404에러가 발생한다.

상세히 설명하면,

먼저, Spring Cloud Gateway 설정을 살펴보면 라우터 설정이 다음과 같다.

# apigateway-service: application.yml

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          # 어디로 갈꺼니?
          uri: http://localhost:8081/
          # 조건절
          predicates:
            - Path=/user-service/**

이 설정은 Gateway에 들어오는 /user-service/로 시작하는 요청을 http://localhost:8081/user-service/로 프록시 하라는 의미이다.

현재 Spring Cloud Gateway 설정은 http://localhost:8081/에 user-service/**가 추가되어 http://localhost:8081/user-service/**로 요청된다.

http://localhost:8081/ + user-service/**

http://localhost:8000/user-service/** 으로 요청하면 http://localhost:8081/user-service/** 으로 요청이 넘어간다.

user-service의 컨트롤러의 API 통신 코드는 다음과 같다.

// user-service: UserController.java (8081 포트 사용)

@RestController
public class UserController {

    @GetMapping("/")
    public String getServiceName(){
        return "user-service";
    }
}

user-service의 컨트롤러는 "/" 경로에 대해서만 응답하고 있다. 따라서 실제로는 http://localhost:8081/에서 대해서만 동작한다. 하지만, Gateway는 /user-service/로 시작하는 요청을 기대하고 있기 때문에 이 요청을 처리하지 못한다.

정리하자면,

이 문제는 Gateway 설정 경로와 실제 서비스 코드 간의 API 통신 경로 불일치로 인해 발생한다.

현재 설정에 따르면, Gateway에서 요청이 http://localhost:8000/user-service/** 으로 들어오면 실제로는 http://localhost:8081/user-service/** 으로 전달된다.
그러나 실제 서비스 코드에서는 http://localhost:8081/user-service/가 아닌 http://localhost:8081/에서만 API가 설정되어 있다.
이 불일치로 인해 요청이 올바른 엔드포인트로 전달되지 않고 서비스 코드의 다른 경로로 이동하게 되어 404에러가 발생한다.

다른 API 주소로 예를 들면,

@GetMapping("/welcome") 으로 되어있을 때,

Gateway에서 http://localhost:8000/user-service/welcome로 요청이 전달되면 실제로는 http://localhost:8081/user-service/welcome로 전달되어야 한다. 그러나 실제 서비스 코드에서는 http://localhost:8081/welcome 경로에 API가 설정되어 있다.

1. API Gateway 라우팅 경로 수정하기

이 문제를 해결하기 위해서는 user-service의 컨트롤러가 /user-service/ 경로에 대해서 응답하도록 수정해야 한다. 이렇게 하면 Gateway 설정과 실제 서비스의 경로가 일치하게 되어 요청이 올바르게 프락시 될 것이다.

user-service의 UserController.java 파일 수정

// user-service: UserController.java (8081 포트 사용)

@RestController
@RequestMapping("/user-service")
public class UserController {

    @GetMapping("/")
    public String getServiceName(){
        return "user-service";
    }
}

클라이언트가 http://localhost:8000/user-service/로 요청을 보내면, API Gateway는 이 요청을 http://localhost:8081/user-service/로 프락시한다.

user- service 서버 실행

user-service

apigateway-service 서버 실행

apiateway-service

이 경우는 필터를 사용하지 않고, 단순히 경로를 라우팅 대상으로 전달한 것이다.

경로 예시

http://localhost:8000/user-service/name ➡️ http://localhost:8081/user-service/name
http://localhost:8000/beverage-service/10 ➡️ http://localhost:8082/beverage-service/10
http://localhost:8000/community-service/feed ➡️ http://localhost:8083/community-service/feed

참고자료

https://spring.io/blog/2022/08/26/creating-a-custom-spring-cloud-gateway-filter

[MSA] API Gateway

bu119 — Tue, 19 Mar 2024 09:00:24 +0900

최근 많은 서비스들이 독립적인 기능을 수행하는 작은 단위의 서비스들로 구성된 마이크로 서비스 아키텍처(Micro Service Architecture) 형태로 구축되면서 서비스의 복잡도를 줄일 수 있게 되었고, 변경에 따른 영향을 최소화하면서 개발과 배포를 할 수 있다는 장점도 얻게 되었다.

하지만 여기서 말하는 작은 단위의 서비스가 50개, 100개가 되었을 때, 이 많은 서비스들의 엔드포인트를 관리하는 데 있어서 어려움이 생기고, 또 각각의 서비스마다 공통적으로 들어가는 기능(ex 인증/인가, 로깅 등)들을 중복으로 개발해야 한다는 문제점이 발생한다.

이러한 문제점을 해결하기 위해 등장한 것이 바로 API Gateway이다.

API Gateway란?

API Gateway Service는 사용자가 설정한 Routing 설정에 따라 각 endpoint로 클라이언트를 대신해서 요청하고, 응답을 받으면 다시 클라이언트에게 전달해 주는 역할을 한다.

다시 말해,

클라이언트는 각 서비스의 엔드포인트 대신에 API Gateway로 요청을 보내게 되며, 요청을 받은 API Gateway는 설정에 따라 각 endpoint로 클라이언트를 대신하여 요청하고, 응답을 받으면 다시 클라이언트에게 전달하는 프락시(proxy) 역할을 한다.

API Gateway는 클라이언트와 각각의 서비스들 사이에 위치한다.
시스템의 내부 구조는 숨기고 외부의 요청에 대해 적절한 형태로 가공해서 응답할 수 있는 장점이 있다.

API Gateway Service가 없을 경우,

클라이언트에서는 microservice를 호출할 때, 클라이언트 쪽에서 endpoint를 설정하게 된다. 그런데 만약 microservice의 설정이 변경되어 endpoint가 변경되거나, 새로운 microservice가 추가되어 이에 해당하는 endpoint를 클라이언트에 추가할 때 클라이언트도 관련해서 수정 및 재배포가 이뤄저야 한다. 이러한 불편함을 없애고자 단일 진입점이 존재하는 개발이 필요하게 되었다.

API Gateway의 주요 기능

인증 및 권한 부여
서비스(마이크로서비스 등) 검색 통합
응답 캐싱
정책, 회로 차단기 및 QoS 다시 시도
- 클라이언트가 요청한 Micro Service에 문제가 생기면 그 회로를 차단한다.
속도 제한
부하 분산
- 예를 들면, A라는 Micro Service가 3개의 인스턴스로 나누어졌을 경우에도 판단 가능하다.
로깅, 추적, 상관관계
- 하나의 서비스가 다른 서비스를 호출하는 경우도 많은데 진입점 및 중간 단계를 거치고 그다음 단계는 어디인지도 추적 가능하다.
- 이를 위해서는 Logging 하는 작업 필요하다.
- Api Gateway는 어떤 클라이언트가 어느 서비스에 요청했는지 로그 파일을 처리 가능하다.
헤더, 쿼리 문자열 및 청구 변환
IP 허용 목록에 추가
- 목록에 추가 허용할 수 있는 IP와 차단 IP를 처리한다.
- 일종의 방화벽처럼 사용 가능하다.

1. 인증/인가 및 토큰 발급

인증/인가의 경우, 각 서비스마다 공통으로 구현되어야 하는 필수적인 기능이다.

각각의 서비스마다 인증/인가 처리를 구현하는 것은 매우 비효율적이다. 따라서, API Gateway에서 이를 처리하게 된다.

인증 서버

Spring으로 예를 들면, 각각의 서비스에 Spring Security 의존성을 추가하여 해당 기능을 구현하는 것을 말한다.

또한, API 사용을 위한 토큰 발급 기능도 마찬가지 이유로 API Gateway에서 처리된다. 실제로 토큰 발급 기능은 인증을 위한 서비스(= 인증 서버)를 하나 두고 거기에서 처리된다.

인증(Authentication) : 해당 사용자가 본인이 맞는지를 확인하는 절차
인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지를 확인하는 절차

2. 공통 로직 처리

인증/인가 외에도 여러 서비스에서 공통적으로 처리해야 할 기능들이 있다.

공통되는 기능을 각각의 서비스마다 구현하는 것은 번거로울 일일뿐더러 코드 수정이 필요할 때, 각각의 서비스를 다 수정해야 하는 등, 유지보수 측면에서의 어려움도 존재한다.

공통 로직 처리

따라서, 공통적으로 사용되는 로직의 경우 API Gateway에서 구현되는 것이 효율적이며, 개발 중복을 줄이는 것뿐만 아니라 표준 준수도 쉽다는 장점을 가지고 있다.

최근에는 API 호출 로깅을 통한 클라이언트의 API 호출 패턴을 분석하여 활용하는 것이 빅데이터의 특면에서 중요한 자산으로도 다뤄지고 있다.

3. 로드밸런싱

대용량 처리 서비스에 있어서 로드밸런싱은 필수적이다.

기본적으로는 여러 개의 API 서버로 부하를 분산하는 기능이 주가 되겠지만, API 서버에 장애가 발생했을 때 이를 감지해서 로드밸런싱 리스트에서 빼고, 복구되었을 때 다시 로드밸런싱 리스트에 넣는 기능들이 필요하다. (health-check)

4. 메디에이션 기능(Mediation)

메디에이션 기능 중에는 메시지 호출 변화(Message Exchange Pattern)가 있다.

메시지 호출 패턴은 동기(Sync), 비동기(Async)와 같은 API를 호출하는 메시지 패턴을 정의하는 것인데, API Gateway를 이용하면 아래와 같이 동기 호출을 비동기 호출로 바꿀 수 있다.

API Gateway에서의 Message Exchance Pattern

또한, 클라이언트의 요청을 하위 서비스가 처리할 수 있도록 데이터 형식을 변형하거나, 하위 서비스의 응답 표준 포맷으로 데이터 형식을 변형하는 메시지 포맷 변환(Message format transformation) 기능도 있다.

Spring과 API Gateway의 역사

1. RestTemplate와 Feign Client

과거에는 Spring Cloud에서의 MSA 간 통신을 위해 RestTemplate, Feign Client를 주로 사용했었다.

RestTemplate
- 전통적인 사용법이다.
- 하나의 웹 애플리케이션에서 다른 애플리케이션을 사용하기 위해 사용된 API이다.
- 다른 애플리케이션을 호출할 때 접속하고자 하는 서버의 주소, port 번호 등을 기재해야 했다.
Feign Client
- Spring Cloud에서 사용하는 API이다.
- interface를 생성하고 외부 microservice 이름만으로 다른 microservice를 호출할 수 있다.

하지만, RestTemplate와 Feign Client는 단일 인스턴스의 서비스를 호출할 때는 잘 동작하지만, 마이크로서비스 아키텍처와 같이 많은 수의 서비스 인스턴스가 있는 환경에서는 부족한 점이 있었다. MSA 환경에서는 서비스 인스턴스의 동적인 변화, 로드 밸런싱, 장애 처리 등을 고려해야 했다.

Netflix의 Ribbon은 이러한 문제를 해결하기 위해 개발되었다.

2. Netflix Ribbon

Spring Cloud는 Load Balancer를 해주는 별도의 서비스를 위해 Netflix의 Ribbon을 채택하여 제공했다.

Ribbon은 클라이언트 측 로드 밸런싱을 지원하고, 서비스 디스커버리와 통합하여 동적으로 서비스 인스턴스를 찾고 호출하는 기능을 제공한다. 또한, 장애 처리와 재시도 메커니즘을 내장하고 있어서, 네트워크 문제나 서비스 장애 시 적절히 대응할 수 있다. (Health Check)

클라이언트 측 내부에 Ribbon을 구축해서 사용한다.
클라이언트 안에서 이동하고자 하는 주소값을 직접 관리한다.
ip:port를 명시 안 해도 서비스를 이름만으로 호출 가능하다.

하지만, Netflix Ribbon도 리액트와 같이 비동기를 사용하는 기술들과의 호환이 잘 안 되는 문제가 발생했고 최근에는 잘 사용하지 않는다.

Spring Boot 2.4에서 Maintenance 상태가 되었다. 즉, Spring boot 2.4 이상 버전에서는 지원하지 않는다.

Maintenace : 다음 버전에서 사용할지 이 기술을 빼거나 보완하려는 상태

3. Netflix Zuul

Netflix OSS(Open Source Software) 프로젝트의 일부로 개발되었으며, Netflix에서 제공하는 API Gateway 또는 API Service 기술이다. 마이크로서비스 아키텍처에서 여러 클라이언트 요청을 적절한 서비스로 프락시 및 라우팅 하기 위한 서비스이다.

JVM-based router 및 Server-side load Balancer이다.
내부적으로 Eureka 서버를 사용하고, 부하 분산을 위해 Ribbon을 사용한다.
Eureka Client이다.
Eureka 및 Ribbon과 함께 사용할 수 있도록 만들어진 기술이다.

Ribbon과 마찬 가지로 maintenance 상태이며, Spring boot 2.4 이상 버전에서는 지원하지 않는다.

4. Spring Cloud Gateway

Spring 생테계를 기반으로 하는 API Gateway를 제공해 준다.
Spring Cloud Gateway는 간단하지만 효율적인 방법으로 API를 라우팅 하는 방법을 제공한다.
그 외에도 security, monitoring/metrics, resiliency 등과 같은 공통 관심사를 처리해 준다
최신의 버전은 Spring 6, Spring Boot 3 and Project Reactor를 기반으로 동작한다.
비동기 처리가 가능하며, 동기 방식인 Tomcat 서버가 아닌 비동기 방식인 Netty 서버로 실행된다.

비동기 방식이란?

비동기 방식은 작업을 동기적으로 기다리지 않고, Reactive Programming을 통해 blocking process로 동작하는 애플리케이션을 non-blocking process로 변환하는 프로그래밍 방식이다.

기존 Spring - Blocking 방식

Web에서 서버에 요청이 왔을 때 서버는 요청에 대한 적절한 응답을 보내야 하는데 만약 작업이 오래 걸릴 경우에는 요청에 대한 응답이 모두 종료될 때까지 Blocking 됐다.
이런 이유로, Spring에서는 동시 요청 처리를 위해서 멀티 Thread를 지원하였고 Thread마다 다른 요청을 할당받아서 처리한다.
물론 요청을 동시에 처리하니 비동기처럼 보일 수 있겠지만, Thread가 늘어날수록 Thread할당에 필요한 Resource가 늘어나게 되어 비효율적이다!

Spring 5 - Non-Blocking

Spring 5가 도입되면서 클라이언트 요청에 별도의 Thread를 생성하지 않고 buffer를 사용해서 요청을 받고 요청을 Back단에서 처리하는 Thread를 둔다.

그럼 왜 Non-blocking 방식이 사용될까?

만약, 수 천 개의 Stream Data 가 초 당 계속 Update 되는 시스템이라면, 적절하게 응답을 해야 하는 경우 기존의 Blocking 방식은 상당한 부하가 걸린다. 따라서, 부하를 효율적으로 처리하는 목적을 가지고 있다.

Spring Cloud Gateway

1. Spring Cloud Gateway의 동작 순서

Client는 Spring Cloud Gateway 서버로 요청을 보낸다.
Gateway Handler Mapping에서 요청이 매핑된다고 판단하면 Gateway Web Handler로 요청을 보낸다.
Gateway Web Handler는 매핑되는 요청을 위한 필터 체인을 거쳐 요청을 실행한다.

동작 방식

2. Spring Cloud Gateway 장점과 단점

장점

요청을 다른 서버로 라우팅 시키는 부분을 간단한 yaml 파일로 완성할 수 있다
Non-Blocking 기술 기반이라 라우팅에 집중된(I/O 작업이 많은) 프로젝트에 최고의 성능을 보일 수 있다
라우티 전/후에 손쉽게 부가 기능을 추가할 수 있다.
- GatewayFilter를 등록할 수 있고, 이미 많은 필터를 제공해주고 있다.
- 예시) 헤더 추가 필터, RateLimit 필터 등

단점

추가 기능의 구현을 WebFlux 기반(리액티브)으로 작성해야 하므로 어려울 수 있다.
라우팅 대상 서버가 많아진다면 관리가 어려울 수 있다.

참고자료

https://mangkyu.tistory.com/230

https://velog.io/@jkijki12/Zuul%EC%9D%B4%EB%9E%80

https://wildeveloperetrain.tistory.com/205

[MSA 구축하기] 6. Spring Cloud Gateway 라우팅 설정하기 (API Gateway)

bu119 — Mon, 18 Mar 2024 09:00:26 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

이번에는, API Gateway의 라우팅을 설정할 것이다.

API Gateway 파트 2

마이크로서비스 서버를 2개 이상 준비하자.

라우팅을 설정하는 방법에는 3가지가 있다.

application.properties를 통한 경로 설정
application.yml를 통한 경로 설정
Config 클래스를 활용한 경로 설정 (직접 Java 코드 작성)

Spring Cloud Gateway 공식문서의 5번째 카테고리 5. Route Predicate Factories에 다양한 라우팅전략이 있다.

Spring Cloud Gateway 공식문서

https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#the-between-route-predicate-factory

Spring Cloud Gateway

This project provides an API Gateway built on top of the Spring Ecosystem, including: Spring 6, Spring Boot 3 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them

docs.spring.io

우리는 application.yml 설정을 통해 Path기반의 라우팅을 설정할 것이다.

준비된 마이크로서비스 확인하기

앞서 생성한 3개의 마이크로서비스가 있다.

user-service
beverage-service
community-service

각 서비스에 랜덤포트를 지정했지만 API Gateway 테스트를 위해 각 서비스에 포트를 지정한다.

1. user-service의 포트번호는 8081번으로 지정

# user-service - application.yml

# 현재 프로젝트 포트 지정
server:
  port: 8081

# 현재 프로젝트 이름 지정
spring:
  application:
    name: user-service

2. beverage-service의 포트번호는 8082번으로 지정

# beverage-service - application.yml

server:
  port: 8082

spring:
  application:
    name: beverage-service

3. community-service의 포트번호는 8083번으로 지정

# community-service - application.yml

server:
  port: 8083

spring:
  application:
    name: community-service

Spring Cloud Gateway 라우팅 설정하기

API Gateway의 포트 번호는 8000번으로 지정한다.

# apigateway-service - application.yml

server:
  port: 8000

spring:
  application:
    name: apigateway-service
  cloud:
    gateway:
      routes:
        - id: user-service
          # 어디로 갈꺼니?
          uri: http://localhost:8081/
          # 조건절
          predicates:
            - Path=/user-service/**
        - id: beverage-service
          uri: http://localhost:8082/
          predicates:
            - Path=/beverage-service/**
        - id: community-service
          uri: http://localhost:8083/
          predicates:
            - Path=/community-service/**

spring: cloud: gateway: routes:
- 라우팅 설정
spring: cloud: gateway: routes: - id:
- 애플리케이션 고유 이름
- 구분하기 위한 id값으로 임의로 작성해도 무관하다.
spring: cloud: gateway: routes: - uri:
- 진입 주소
spring: cloud: gateway: routes: - predicates:
- 라우팅 조건 (조건절)
spring: cloud: gateway: routes: - predicates: - Path =
- Path를 기반으로 라우팅을 설정
- ex) - Path = /user-service/**
- http://localhost:8000/user-service/ 으로 요청이 들어오면 유레카 서버에서 uri에 해당하는 주소를 찾아 그곳으로 요청을 보낸다.

Spring Cloud Gateway 서버 실행

각 마이크로서비스 서버를 먼저 실행한 후에 API Gateway 서버를 실행해야 한다.

이대로 라면 "http://localhost:8081/"과 "http://localhost:8000/user-service/"를 실행했을 때 같은 결과가 나타나야 한다.

1. user-service 서버 실행

user-service의 "http://localhost:8081/"의 주소로 실행하면 "user-service"라는 글자가 나타난다.

2. apigateway-service 서버 실행

apigateway-service의 "http://localhost:8000/user-service/"의 주소로 API를 실행하면 "user-servicer"라는 글자가 보이지 않는다.

"http://localhost:8081/"과 "http://localhost:8000/user-service/"를 실행했을 때 같은 결과가 나타나야 하는데 위의 결과값을 보면 다르다. 그 이유를 알아보자.

https://bu119.tistory.com/97

[MSA 구축하기] 7. Spring Cloud Gateway를 활용한 경로 수정 (API Gateway)

bu119.tistory.com

[Spring] Spring MVC 와 Spring Webflux의 차이점

bu119 — Sun, 17 Mar 2024 09:00:24 +0900

Spring Framework에는 대표적인 프로그래밍 모델이 있다.

첫 번째는 가장 널리 알려지고 대중적으로 사용되는 Spring MVC 모델이고,

두 번째는 Spring WebFlux 모델이다.

Spring WebFlux란?

Spring WebFlux는 Spring 5에서 새롭게 도입된 모듈이며, 비동기 및 리액티브 프로그래밍을 지원한다. Spring MVC와는 다르게 Servlet API를 기반으로 하지 않고, 리액티브 프로그래밍 모델을 채택하여 작동한다.

이전에는 Servlet API를 기반으로 한 Spring MVC를 사용하여 동기적인 처리 방식으로 웹 애플리케이션을 개발했다. 동기적인 처리 방식은 한 번에 하나의 요청을 처리하는데, 이는 높은 트래픽과 데이터 양을 효과적으로 처리하기 어렵다.

최근에는 더 많은 트래픽과 데이터량을 효율적으로 처리하기 위한 필요성이 증가했고 리액티브 프로그래밍이 등장하게 되었다.

리액티브 프로그래밍은 데이터 스트림과 변화의 전파를 중심으로 하는 프로그래밍 패러다임으로, Spring WebFlux는 Reactor라는 리액티브 스트림 스펙을 기반으로 개발되었다. 이를 통해 비동기적이고 논블로킹 방식으로 동작하여 더 많은 동시 요청을 처리하고, 데이터 스트림을 효율적으로 처리할 수 있게 되었다.

따라서, Spring WebFlux는 현대적이고 확장 가능한 웹 애플리케이션을 개발하는 데 유용한 도구이다. 이 모듈을 사용하면 개발자는 비동기적이고 효율적인 방식으로 작업할 수 있다.

Spring WebFlux와 Spring MVC를 비교할 때 가장 큰 차이는 리액티브 프로그래밍의 도입이다.

리액티브 프로그래밍이란?

리액티브 프로그래밍은 변화에 반응하여 동작하는 프로그래밍 모델로서, 비동기적이고 이벤트 기반의 접근 방식을 통해 데이터 스트림과 변경 사항을 처리하는 것이 핵심이다. 이 패러다임은 데이터의 흐름에 따라 프로그램의 흐름이 결정되며, 데이터가 변경될 때마다 자동으로 관련 코드를 실행하여 응답한다.

예를 들어,

블로킹 코드에서는 함수 호출 후 결과를 기다리는 것이 자연스러운 형태이다. 반면, 논블로킹 코드에서 데이터를 전송하는 쪽의 전송속도가 수신자의 처리속도를 앞지르지 않게 이벤트 속도를 제어하는 것이 중요하다. reactive stream은 이런 비동기성 컴포넌트 간의 상호작용에 정의된 작은 스펙이다. 이런 기능을 Back Pressure라고 한다.

Spring WebFlux의 특징

리액티브 프로그래밍 모델을 기반으로 한다.
Spring MVC와 마찬가지로 어노테이션 기반의 프로그래밍을 한다.
- 대표적으로 @Controller, @RestController, @GetMapping 등을 사용하여 엔드 포인트를 정의하고 요청을 처리할 수 있다.
함수형 프로그래밍을 지원한다
- Spring WebFlux는 함수형 엔드포인트 정의와 리액티브 데이터 흐름을 표현하기 위해 Java8의 도입된 람다식을 활용할 수 있다.
비동기 및 논블로킹 기반으로 동작하기 때문에, 대량의 동시 요청에 대한 빠른 응답과 서버의 확장성을 향상하는 개발이 가능하다.
Spring과 완벽한 통합을 이루고 netty를 지원한다.

Spring MVC란?

웹 계층의 서블릿 API를 기반으로 클라이언트의 요청을 처리하는 모듈 개발 영역을 MVC(Model-View-Controller)로 구분하여 각 역할에 맞게 코드를 작성하는 개발 방식이다.

MVC 패턴을 도입하면서 UI 영역과 도메인(비즈니스 로직) 영역이 구분되어 서로에게 영향을 주지 않으면서 개발과 유지보수를 가능한 방향으로 설계되었다.

Model
- Spring MVC 기반의 웹 애플리케이션이 클라이언트의 요청을 전달받으면 요청 사항을 처리하기 위한 작업이다.
- 처리한 작업의 결과 데이터를 클라이언트에게 응답을 돌려주어야 하는데, 클라이언트에게 응답으로 돌려주는 작업의 처리 결과 데이터를 Model이라고 칭한다.
- 클라이언트의 요청을 구체적으로 처리하는 영역을 서비스 계층이라 하며, 요청 사항을 처리하기 위해 Java 코드로 구현한 것을 비즈니스 로직이라고 한다.
View
- Model을 이용하여 웹 브라우저와 같은 애플리케이션의 화면에 보이는 리소스를 제공하는 역할이다.
- HTML 페이지 등을 출력하는 것 뿐만이 아닌 PDF, Excel 등의 문서 형태 출력 그리고 자주 사용되는 XML, JSON 등 특정 형식의 포맷 변환까지 View가 담당한다.
Controller
- 클라이언트 측의 요청을 직접적으로 전달받는 엔드포인트로 Model과 View의 중간에서 상호작용을 해주는 역할이다.
- 클라이언트의 요청을 전달받아 비즈니스 로직을 거친 후, Model 데이터가 만들어지면 이 Model을 View로 전달하는 역할을 수행한다.

Spring MVC의 구조

동작 순서

핸들러 조회 : URL에 매핑된 핸들러(컨트롤러)를 조회
핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회
핸들러 어댑터 실행
핸들러 실행
ModelAndView 반환 : 핸들러 어댑터는 핸들러가 반환하는 정보를 변환하여 반환
viewResolver 호출 : 뷰의 논리 이름을 물리 이름으로 변경
View 반환 : 렌더링 역할을 담당하는 뷰 객체 반환
View 랜더링 : 뷰를 통해 뷰를 렌더링

Spring MVC와 Spring WebFlux 비교

공통점

MVC와 Webflux 모두 Spring Framework에서 웹 애플리케이션을 개발하기 위한 프레임워크로 공통적으로 @Controller, Reactive Client이 존재한다.
둘 다 Tomcat, Jetty, Undertow와 같은 서버에서 실행할 수 있다.

차이점

Spring MVC

동기적 처리
- 기본적으로 동기적인 방식으로 HTTP 요청을 처리한다.
- 요청이 들어오면 해당 요청을 처리하기 위한 스레드를 할당하고, 해당 요청에 대한 응답을 준비할 때까지 기다린다.
서블릿 기반:
- 서블릿 API에 의존하여 구현되어 있다.
- 이는 전통적인 서블릿 기반의 웹 애플리케이션 개발 방식을 따르며, 서블릿 컨테이너를 기반으로 동작한다.
전통적인 프로그래밍 모델
- Spring MVC는 전통적인 웹 애플리케이션 개발 모델을 따른다.
- 컨트롤러, 서비스, DAO 등의 구성 요소를 사용하여 비즈니스 로직을 처리하고, 서블릿 기반의 요청-응답 사이클을 처리한다.
스레드 모델
- 각각의 요청에 대해 별도의 스레드를 할당하여 처리하므로, 스레드 당 요청 처리량이 제한될 수 있다.

Spring WebFlux

비동기 및 논블로킹 처리
- Reactive Streams API를 기반으로 하여 비동기 및 논블로킹 방식으로 HTTP 요청을 처리한다.
- 이는 요청이 들어오면 해당 요청을 블로킹하지 않고 비동기적으로 처리하며, 응답을 기다리는 동안 다른 요청을 처리할 수 있다.
비서블릿 기반
- WebFlux는 서블릿 API에 의존하지 않으며, 서블릿 컨테이너를 기반으로 동작하지 않는다.
- 대신에 Netty나 Undertow와 같은 비서블릿 기반의 웹 서버를 사용하여 동작한다.
함수형 및 반응형 프로그래밍 모델
- WebFlux는 함수형 및 반응형 프로그래밍 모델을 채택하여 비동기적으로 데이터를 처리한다.
- 이는 Reactive Streams를 기반으로 하여 데이터 스트림을 처리하고 변환할 수 있다.
적은 수의 쓰레드 사용
- 적은 수의 쓰레드로 더 많은 요청을 처리할 수 있는 비동기 및 논블로킹 모델을 사용한다.

결론

Spring MVC는 전통적인 동기적인 방식으로 웹 애플리케이션을 개발하는 데 사용되는 반면, Spring WebFlux는 비동기 및 논블로킹 방식으로 개발되어 있어 대량의 요청을 효율적으로 처리할 수 있다. 선택은 프로젝트의 요구 사항과 개발자의 선호도에 따라 달라진다.

마지막으로 Spring WebFlux에 대해 자세히 정리하자면,

Spring WebFlux는 비동기 및 리액티브 프로그래밍의 개념을 익히고 높은 동시성을 필요로 하는 웹 애플리케이션을 개발하는 데 유용하다.

대규모 트래픽 처리
- Non-blocking I/O 모델을 사용하여 단일 쓰레드에서 많은 요청을 처리할 수 있다.
- 이는 리소스의 효율적인 활용을 가능하게 하며, 대규모 트래픽을 처리하는 데 효과적이다.
데이터 스트리밍 처리
- Reactive Streams API를 기반으로 한 WebFlux는 데이터 스트리밍 처리에 적합하다.
- 이는 데이터를 비동기적으로 처리하고 변환하는 데 유용하며, 실시간 데이터 처리나 이벤트 기반 애플리케이션에서 특히 유용하다.
다양한 데이터베이스 처리
- NoSQL 데이터베이스나 비동기적인 데이터베이스 처리가 필요한 경우 Spring WebFlux는 적합하다.
- 이는 비동기적으로 데이터베이스 호출을 수행하고, 동시성을 높일 수 있다.
높은 확장성
- WebFlux는 비동기 및 논블로킹 방식을 사용하여 높은 확장성을 제공한다.
- 이는 애플리케이션의 부하에 따라 쉽게 확장될 수 있음을 의미한다.

참고자료

https://mumomu.tistory.com/176

https://medium.com/@jooomOut/spring-webflux-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC-1902af1c88bf

https://mooonstar.tistory.com/entry/SpringMVC%EB%AA%A8%EB%8D%B8%EA%B3%BC-%EB%B9%84%EA%B5%90%EB%90%98%EB%8A%94-WebFlux%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

https://clairdelunes.tistory.com/158

https://velog.io/@jaehyunup/Srping-Webflux%EC%9D%98-%ED%83%84%EC%83%9D-%EB%B0%B0%EA%B2%BD%EA%B3%BC-MVC%EC%99%80%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://devuna.tistory.com/108

https://pearlluck.tistory.com/726

[MSA] Spring Cloud Gateway와 Netflix Zuul의 차이점 (API Gateway)

bu119 — Sat, 16 Mar 2024 09:00:01 +0900

Spring Cloud Gateway를 활용하여 API Gateway를 구축할 때 Spring Initializr에서 의존성으로 Gateway를 추가하면 안 되고 Reactive Gateway를 추가해야 하는 이유는 무엇일까?

❓ API Gateway 프로젝트를 생성하기 위해 Spring Initializr에서 의존성으로 Gateway를 추가했다가 이후에 설정들이 잘 되지 않았다. 그래서 이유를 찾아봤더니 Reactive Gateway를 추가했어야 했다. 왜?!!! Gateway가 아닌 Reactive Gateway를 추가해야 할까? 그 이유에 대해 알아보자!!

⭐ 의존성에 Gateway가 아닌 Reactive Gateway를 추가해야 하는 이유?

마이크로서비스 아키텍처에서 API Gateway를 구축하기 위한 도구에는 Spring Cloud Gateway와 Netflix Zuul가 있다. Spring Cloud Gateway를 사용해서 API Gateway를 구축하기 위해서는 Spring Initializr에서 " Reactive Gateway"를 추가해야 한다.

"Gateway"를 추가하게 되면, Spring Cloud Gateway가 아닌 Netflix Zuul 방식의 API Gateway 솔루션을 의미한다.

Netflix Zuu은 Netflix에서 지원하는 API Gateway 방식인데 최근에는 지원이 중단되었고, Spring Cloud Gateway와 같은 다른 대안을 선호하는 추세이다.

즉, Netflix Zuu은 더 이상 권장되지 않는 접근 방식이며, Spring Cloud Gateway가 더 현대적이고 유연한 대안으로 간주된다.

API Gateway 란?

API Gateway라는 것은, Reverse Proxy처럼 클라이언트 요청의 앞단에 위치한다. 마치 ‘도어 맨' 역할처럼 들어온 요청들에게 어디로 가야 할지 ‘라우팅’해줄 수 있고 들어오고 나가는 명단을 ‘로깅’할 수도 있다.

구체적으로는 다음과 같은 역할들이 있다.

API 라우팅
인증 및 권한 부여
속도 제한
부하 분산 (로드밸런싱)
로깅 (모니터링)
오케스트레이션

마이크로서비스 아키텍처에서 API 게이트웨이를 구축하기 위한 도구에는 Spring Cloud Gateway와 Netflix Zuul가 있다.

Spring Cloud Gateway는 비동기 처리에 유리한 반면, Zuul은 그렇지 않기 때문에 더 이상 Zuul을 지원하지 않고 Spring.io 는 Spring Cloud Gateway를 권장한다.

Netflix Zuul 이란?

Netflix Zuul은 Netflix OSS 프로젝트의 일부로서, 서블릿 기반의 동기식 아키텍처를 사용한다. Spring 기반의 애플리케이션에서 사용하기 위해 Spring Cloud Netflix 모듈을 사용하여 통합된다.

Zuul은 Netflix에서 지원되었으나, 최근에는 지원이 중단되었고, Spring Cloud Gateway와 같은 다른 대안을 선호하는 추세이다.

의존성

  implementation 'org.springframework.cloud:spring-cloud-starter-gateway-mvc'

Spring Cloud Gateway 란?

Spring Cloud 프로젝트의 일부로서, Spring Boot와 Spring WebFlux를 기반으로 한다. 따라서 리액티브 스프링 프레임워크를 사용하여 비동기 및 논블로킹 방식으로 요청을 처리한다.

의존성

  implementation 'org.springframework.cloud:spring-cloud-starter-gateway'

Spring Cloud Gateway와 Netflix Zuul의 차이점

Spring Cloud Gateway는 각각의 요청을 처리하기 위해 적은 수의 스레드를 사용하는 Event-loop 방식을 채택한다. 이는 Node.js와 비슷한 접근 방식으로, 각 작업을 작은 단위로 쪼개어 동시에 처리하려고 한다. 이를 통해 적은 수의 스레드로도 많은 작업을 처리할 수 있다.

반면에 Netflix Zuul은 전통적인 방식으로, 각 요청을 처리하기 위해 Thread pool을 사용한다. 각 요청은 별도의 스레드에서 처리된다.

두 방식의 선택은 서비스의 요구사항과 사용하는 기술에 따라 다를 수 있다. 현재 잘 동작하고 있는 서비스에 대해서는 변경할 필요가 없다. 그러나 비동기 작업이 많거나 리소스를 효율적으로 사용해야 하는 경우에는 Spring Cloud Gateway와 같은 Reactive 한 접근 방식을 고려할 수 있다.

Spring Cloud Gateway

기술 스택
- Spring Cloud 프로젝트의 일부로서, Spring Boot와 Spring WebFlux를 기반으로 한다.
- 따라서 리액티브 프로그래밍 모델을 사용하여 비동기 및 논블로킹 방식으로 요청을 처리한다.
동작 방식
- 비동기적이고 논블로킹 방식으로 동작하여 적은 스레드로도 많은 요청을 처리할 수 있다.
- 이벤트 루프(Event Loop) 방식을 사용하여 고부하 상황에서도 효율적으로 동작할 수 있다.
적합한 사용 사례
- 고성능 및 확장성이 필요한 경우에 적합하다.
- 비동기적이고 논블로킹 방식으로 요청을 처리하여 서버 자원을 효율적으로 사용할 수 있다.
Spring Webflux 예시
- 여러 사용자가 웹 애플리케이션에 접속하여 요청을 보낸다.
- 각 요청은 이벤트 루프(Event Loop) 방식으로 처리된다.
- 이는 적은 수의 스레드로 많은 요청을 처리하는 방식이다.
- 예를 들어, 사용자 A의 요청이 도착하면 하나의 이벤트 루프가 해당 요청을 처리하고, 사용자 B의 요청이 도착하면 다른 이벤트 루프가 해당 요청을 처리한다.
- 각 요청은 작은 단위로 쪼개어 비동기적으로 처리되므로, 많은 요청이 동시에 들어오더라도 적은 수의 스레드로 효율적으로 처리할 수 있다.

Netflix Zuul

기술 스택
- Netflix에서 만든 도구로, 서블릿 기반의 동기식 아키텍처를 사용한다.
- 이는 요청을 처리하는데 스레드(Thread)를 많이 사용하고, 요청마다 스레드를 할당하여 처리한다.
동작 방식
- 동기식 아키텍처를 사용하여 요청마다 스레드를 할당하여 처리한다.
- 쓰레드 풀의 크기에 따라 확장되므로 많은 스레드를 사용하게 되며 높은 부하 상황에서 확장성이 제한될 수 있다.
적합한 사용 사례:
- 기존의 서블릿 기반 아키텍처를 사용하는 서비스에 적합하다.
- 또한 동기식 방식으로 요청을 처리하는 것을 선호하는 경우에 사용할 수 있다.
Spring MVC 예시
- 이 방식은 서버에서 각각의 요청을 처리할 때마다 새로운 스레드(Thread)를 생성하여 작업을 처리한다.
- 예를 들어, Spring Boot 웹 애플리케이션에서 요청이 들어오면 새로운 스레드를 사용하여 해당 요청을 처리한다.
- 이 방식은 각각의 요청마다 스레드를 할당하기 때문에 동시에 처리할 수 있는 요청의 수가 제한된다.
- 또한, 스레드를 관리하는데 복잡성이 증가할 수 있다.

따라서, Spring Cloud Gateway는 비동기적이고 효율적인 요청 처리를 위한 도구이며, Netflix Zuul은 기존의 방식을 사용하는 경우에 적합한 도구입니다. 요청의 처리 방식과 성능, 확장성에 따라 적절한 도구를 선택해야 한다.

참고자료

https://velog.io/@jaehyunup/Srping-Webflux%EC%9D%98-%ED%83%84%EC%83%9D-%EB%B0%B0%EA%B2%BD%EA%B3%BC-MVC%EC%99%80%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://devuna.tistory.com/108

https://velog.io/@gowjr207/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4%EB%A5%BC-%EC%84%A4%EB%AA%85%ED%95%B4%EB%B3%B4%EB%8B%A4

https://stir.tistory.com/375

https://sky-h-kim.tistory.com/67

https://corono.tistory.com/33

[MSA 구축하기] 5. Spring Cloud Gateway 프로젝트 생성하기 (API Gateway)

bu119 — Fri, 15 Mar 2024 21:00:09 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

이번에는, Spring Cloud Gateway를 사용하여 API Gateway를 구축할 것이다.

API Gateway 파트 1

API Gateway란?

사용자가 설정한 Routing 설정에 따라 각 endpoint로 client를 대신해서 요청하고, 응답을 받으면 다시 client에게 전달해주는 역할을 한다.

Spring Cloud에서는 Spring Cloud Gateway가 API Gateway의 역할을 수행한다.

Spring Cloud Gateway란?

스프링 클라우드 게이트웨이는 MSA 가장 앞단에서 클라이언트들로 부터 오는 요청을 받은 후 경로와 조건에 알맞은 마이크로서비스 로직에 요청을 전달하는 게이트웨이이다. 게이트웨이는 개념적으로는 아주 단순하지만 가장 앞단에서 무중지 상태로 모든 요청을 받아야하기 때문에 설정하기에 까다롭다.

Spring Cloud Gateway의 특성

기존에 제작했던 스프링 부트, Eureka, Config와 같은 서비스들을 블로킹 기반으로 모두 톰캣 엔진을 사용했다.

하지만 게이트 웨이의 경우 비즈니스 로직 처리 보단 단순하게 지나가는 통로 즉, I/O 처리를 중점적으로 진행하기 때문에 논 블로킹 방식으로 동작하는 WebFlux와 네티엔진을 사용한다.

WebFlux는 기존에 스프링 부트에서 사용했던 JPA와 같은 블로킹 방식의 의존성들을 모두 사용하지 못하기 때문에 구현에 앞서 많은 학습이 필요하다.

Spring Cloud에서 제공하는 Spring Cloud Gateway를 활용하여 API Gateway를 구축할 것이다.

Spring Cloud Gateway 프로젝트 생성하기

1. 프로젝트 생성

Spring Cloud Gateway 설정을 위한 의존성 추가

필수 의존성

Reactive Gateway

// build.gradle

ext {
	set('springCloudVersion', "2023.0.0")
}

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-gateway'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'io.projectreactor:reactor-test'
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

Spring Initializr에서 의존성으로 Reactive Gateway를 추가해야한다. Gateway를 추가하면 안된다!!!!

그 이유가 궁금하다면 아래 포스팅을 읽어보자.

https://bu119.tistory.com/92

[MSA] Spring Cloud Gateway와 Netflix Zuul의 차이점 (API Gateway)

Spring Cloud Gateway를 활용하여 API Gateway를 구축할 때 Spring Initializr에서 의존성으로 Gateway를 추가하면 안 되고 Reactive Gateway를 추가해야 하는 이유는 무엇일까? ❓ API Gateway 프로젝트를 생성하기

bu119.tistory.com

참고 자료

https://velog.io/@korea3611/Spring-Boot-Spring-Cloud-Gateway-%EB%A7%8C%EB%93%A4%EA%B8%B0-MSA2

https://substantial-park-a17.notion.site/8-84d3a62b9a214035a42ab49aae704a34

[MSA 구축하기] 4. Eureka 클라이언트에 랜덤 포트 할당하기 (Service Discovery)

bu119 — Thu, 14 Mar 2024 09:00:46 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

Service Discovery 파트 3

Service Discovery의 역할을 간략하게 정리하자면,

Service Discovery란?

마이크로서비스의 정보(위치 등)를 등록할 수 있다.
외부의 요청이나 서비스가 마이크로서비스의 정보를 검색하기 위해 사용된다.

Spring Cloud에서는 Spring Cloud Netflix Eureka가 Service Discovery의 역할을 수행한다. Eureka는 Eureka Server와 Eureka Client로 구성된다.

Eureka 클라이언트란?

MSA를 구성하는 요소들 중 Eureka 서버에서 모니터링 및 관리를 원하는 요소를 Eureka 클라이언트 설정을 진행해서 등록할 수 있다.

이번에는, 로드밸런싱을 사용하기 위해 Eureka Client에게 랜덤 포트를 부여할 것이다.

❓ Service Discovery의 Eureka Client를 구축하기 위해 구글 검색을 통해 많은 블로그의 자료를 찾아봤다. 포트번호를 랜덤 포트로 설정하는 블로그 글들이 많이 있었는데 그 이유에 대해서는 명확하지 않았다. 이유를 모르고 그대로 적용할 수는 없기 때문에 왜 랜덤포트를 적용하여 구현했는지 그 이유에 대해 더 파헤쳤다. 그 결과, 로드밸런싱을 사용하기 위해 랜덤포트를 설정한다는 것을 알 수 있었다.

⭐ 각 애플리케이션에 랜덤 포트를 부여하는 이유?

랜덤포트의 사용 여부는 마이크로서비스가 독립적으로 사용되는지, LB(로드밸랜서)로 구성되어 사용되는지, 사용 시 문제가 되었을 때 복귀해야 하는 구조는 어떻게 되어 있는지 등에 따라 결정할 수 있다.

이 프로젝트에서 랜덤포트(port: 0)에 대한 설정은 LB사용을 보이기 위함이고, 포트를 고정(port: 8081)으로 설정한 상태에서 진행해도 문제는 없다.

다만, Service Discovery에서 등록된 서비스들이 포트 간의 충돌이 발생할 경우, 해당 서비스를 우회할 수 있는 포트를 지정하여 새롭게 실행하지 않고, 충돌이 발생한 서비스는 중지시켜 버리게 된다. 포트를 잘 구분하여 서비스들을 배포한다고 했을 때는 문제가 없을 수도 있다.

그런데, 서비스에서 LB를 사용하도록 되어 있다면, LB에 연결되는 다수의 동일 서비스들은 같은 형태(코드)로 작성된 애플리케이션인데, 매번 실행할 때마다 포트를 변경하는 작업을 하기에는 번거로울 수 있다. 이때 랜덤포트로 실행하며 임의의 사용가능한 포트가 할당되고, Service Discovery에 등록될 때는 서비스명으로 사용되기 때문에, 여러 개의 서비스가 연결되어 있어도 하나의 서비스명이 요청을 받아 해당 서비스들에 요청처리를 배분해 줄 수 있게 된다.

실제로 MSA 형태로 구성된 애플리케이션들은 컨테이너 가상화 형태로 운영되는 경우가 대부분인데, Docker나 Kubernetes에서 컨테이너를 기동 할 때는 외부와 연결되기 위한 포트를 랜덤포트로 설정(범위는 지정할 수 있습니다)되어 사용된다. 컨테이너 자체는 독립적인 IP를 가지고 있는 VM이라고 보시면 되고, 이 안에서 사용되는 포트는 어떠한 포트로 지정되어 있더라도 상관없이, 컨테이너 외부하고의 연결만 잘 되어 서비스되는 구조라고 이해하면 좋을 것 같다.

Eureka 클라이언트 랜덤 포트 지정하기

존재하는 마이크로서비스 모두에게 동일하게 설정한다.

user-service
baverage-service
community-service

일반적인 환경에서는 지정된 PORT를 사용하여 애플리케이션을 운영한다. 그러나 MSA와 같이 LB 환경을 위해 여러 서비스를 등록하거나 자동으로 서비스가 증가되어야 하는 상황에서는 random port를 이용한다. 동일한 서비스를 여러 개 실행하는 경우라면, 관리자가 매번 PORT 번호를 지정하는 것도 한계가 존재하기 때문이다.

아래의 실습을 통해 확인해 보자.

만약, user-service 인스턴스를 여러 개 띄운다면 아래와 같 매번 포트번호를 바꾸고 실행하기 불편하다.

4. Eureka 클라이언트에 랜덤 포트 할당

yml 파일에서 port번호를 0번으로 설정하면 같은 서비스가 실행될 때마다 랜덤으로 포트 번호가 할당된다.

# application.yml

# 포트번호를 0으로 두면 포트번호가 매번 랜덤으로 할당된다.
server:
    port: 0

server port 설정을 랜덤 포트로 지정해 주면 실행할 때마다 spring boot가 50,000 이상인 랜덤 한 port 번호를 할당해 준다.

Spring Cloud Eureka 서버 실행

Status에 포트번호가 0으로 보이지만, 마우스로 이 주소에 커서를 올려놓으면 왼쪽 하단에

http://desktop-4v4j52s:51873/actuator/info 즉, 51873 포트가 랜덤으로 할당된 것을 볼 수 있다.

그러나, 위와 같이 설정할 경우 eureka 서버의 인스턴스 이름은 0으로 고정되어 서버를 여러 개 띄우더라도 ESKTOP-4V4J52S:user-service:0 로 인스턴스가 한 개만 등록되게 된다.

포트번호가 0인 user-service를 3개 띄웠지만 eureka 서버에는 1개로 나온다.

즉, 동일한 service application이 여러 개 실행될 때 yml에서 설정한 port인 0으로 인식이 되기 때문에 각각의 서비스를 구분하기 어렵다. 따라서, 인스턴스 id 값을 재정의 해야 한다.

5. 인스턴스 ID 값 재정의

random port 지정 시 서비스를 구분하기 위해 각각의 서비스를 instance-id로 구분한다.

eureka 클라이언트들의 instance-id 값을 랜덤으로 부여한다.

# application.yml

# eureka 설정
eureka:
  instance:
    # 여러 개의 프로젝트를 실행할 때 유레카 서버에서 각각의 인스턴스를 식별하기 위해 설정
    # 'random.value를 활용하여 랜덤 값을 생성해 각 인스턴스를 고유하게 식별
    instance-id: ${spring.cloud.client.hostname}:${spring.application.instance_id:${random.value}}

eureka: instance: instance-id:
- 프로젝트를 eureka 서버에 등록하고 유레카 서버로 접속해 보면 위와 같이 등록된 서비스를 확인할 수 있다.
- 하지만, 같은 프로젝트를 여러 개 띄우게 되면 포트번호가 같기 때문에 여러 개 띄워지더라도 eureka 서버에 1개만 표시되는 현상이 발생한다.
- 따라서, 실행되는 프로젝트마다 구분해 주기 위해 표기되는 instance-id 값을 변경해서 적용해 주는 설정이다.
${spring.cloud.client.hostname}
- 호스트 이름 (ip 표시)
${spring.application.instance_id:${random.value}}
- 인스턴스 id 값을 랜덤으로 설정

6. 현재까지 최종 application.yml 파일

# application.yml

# 현재 프로젝트 랜덤 포트로 지정
server:
  port: 0

# 현재 프로젝트 이름 지정
spring:
  application:
    name: user-service

# eureka 설정
eureka:
  client:
    # eureka 등록 여부
    register-with-eureka: true
    # eureka 서버로 부터 인스턴스들의 정보를 가져올 것인지 설정하는 속성
    fetch-registry: true
    # eureka 서버 주소에 마이크로서비스 정보 등록
    service-url:
      defaultZone: http://admin:1234mst@localhost:8761/eureka
  instance:
    # 여러 개의 프로젝트를 실행할 때 유레카 서버에서 각각의 인스턴스를 식별하기 위해 설정
    # 'random.value를 활용하여 랜덤 값을 생성해 각 인스턴스를 고유하게 식별
    instance-id: ${spring.cloud.client.hostname}:${spring.application.instance_id:${random.value}}

Spring Cloud Eureka 서버 실행

instance-id를 랜덤으로 부여하면 Eureka server에서 설정한 instance-id로 인스턴스가 각각 보이게 된다.

3개의 user-service를 실행시키면 각각 instance-id 가 랜덤으로 생성되어 Eureka server에서 정상작동한다.

user-service 3개 실행

참고 자료

https://www.inflearn.com/questions/193571/instance-id-%EB%8C%80%EC%8B%A0-port%EB%A5%BC-%EB%B3%B4%EC%97%AC%EC%A3%BC%EB%8A%94-%EB%B0%A9%EB%B2%95%EC%9D%80-%EC%97%86%EC%9D%84%EA%B9%8C%EC%9A%94

https://www.inflearn.com/questions/681124/%EA%B0%81-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%97%90-%EB%9E%9C%EB%8D%A4%ED%8F%AC%ED%8A%B8%EB%A5%BC-%EB%B6%80%EC%97%AC%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

https://yarisong.tistory.com/42

https://m.blog.naver.com/qjawnswkd/222307979571

https://velog.io/@boo105/MSA-EUREKA-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

https://devhan.tistory.com/m/260

https://substantial-park-a17.notion.site/6-Eureka-057c942a7a4041bf87ab5cd3043af021

[MSA 구축하기] 3. Eureka 클라이언트 설정 (Service Discovery)

bu119 — Wed, 13 Mar 2024 09:00:19 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

Service Discovery 파트 2

Service Discovery의 역할을 간략하게 정리하자면,

Service Discovery란?

마이크로서비스의 정보(위치 등)를 등록할 수 있다.
외부의 요청이나 서비스가 마이크로서비스의 정보를 검색하기 위해 사용된다.

Spring Cloud에서는 Spring Cloud Netflix Eureka가 Service Discovery의 역할을 수행한다. Eureka는 Eureka Server와 Eureka Client로 구성된다.

Eureka 클라이언트란?

MSA를 구성하는 요소들 중 Eureka 서버에서 모니터링 및 관리를 원하는 요소를 Eureka 클라이언트 설정을 진행해서 등록할 수 있다.

이번에는, 이전에 생성한 각각의 마이크로서비스들에게 Eureka Client 설정을 할 것이다.

마이크로서비스 Eureka 클라이언트 설정하기

생성한 모든 마이크로서비스들에게 동일하게 설정한다.

user-service
beverage-service
community-service

1. Eureka 클라이언트 설정을 위한 의존성 추가

필수 의존성

Eureka Discovery Client

// build.gradle

ext {
  set('springCloudVersion', "2023.0.0")
}

dependencies {

  implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}

dependencyManagement {
  imports {
    mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
  }
}

2. Main 클래스 어노테이션 등록

Eureka 클라이언트로 동작하기 위해 @EnableDiscoveryClient 어노테이션을 등록해야 한다.

// UserServiceApplication 

package com.caffeinedoctor.userservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient // 유레카 클라이언트로 등록
public class UserServiceApplication {

	public static void main(String[] args) {
		SpringApplication.run(UserServiceApplication.class, args);
	}

}

3. Eureka 서버와 연결

application.yml 변수 설정을 통해 Eureka 서버에 등록할 수 있다.

# application.yml

# 현재 프로젝트 포트 지정 (user-service)
server:
  port: 8081

# 현재 프로젝트 이름 지정
spring:
  application:
    name: user-service

# eureka 설정 (eureka 서버와 연결)
eureka:
  client:
    # eureka 서버에 등록할지 여부
    register-with-eureka: true
    # eureka 서버로 부터 인스턴스들의 정보를 가져올 것인지 설정하는 속성
    fetch-registry: true
    # eureka 서버 주소에 마이크로서비스 정보 등록
    service-url:
      defaultZone: http://admin:1234mst@localhost:8761/eureka

spring: application: name:
- 프로젝트의 애플리케이션 이름을 정한다.
- 해당 이름으로 Gateway에서 호출하므로 필수적으로 입력한다.
eureka: client: register-with-eureka (디폴트 true)
- eureka 서버에 등록 설정
eureka: client: fetch-registry (디폴트 true)
- 외부에서 Client가 검색 가능 여부 설정
eureka: client: service-url: defaultZone:
- eureka 클라이언트가 마이크로서비스를 등록할 eureka 서버 주소를 지정하기 위해 사용한다.
- 즉, 마이크로서비스를 등록할 eureka 서버 주소를 작성한다.

Spring Cloud Eureka 서버 실행

참고 자료

https://covenant.tistory.com/251

https://devhan.tistory.com/m/260

https://substantial-park-a17.notion.site/6-Eureka-057c942a7a4041bf87ab5cd3043af021

[MSA 구축하기] 2. Eureka 서버 구축 (Service Discovery)

bu119 — Tue, 12 Mar 2024 18:00:33 +0900

우리는 Spring Cloud를 활용하여 MSA를 구축한다.

이번에는, Service Discovery를 구축할 것이다.

Service Discovery 파트 1

Service Discovery의 역할을 간략하게 정리하자면,

Service Discovery란?

마이크로서비스의 정보(위치 등)를 등록할 수 있다.
외부의 요청이나 서비스가 마이크로서비스의 정보를 검색하기 위해 사용된다.

Spring Cloud에서는 Spring Cloud Netflix Eureka가 Service Discovery의 역할을 수행한다. Eureka는 Eureka Server와 Eureka Client로 구성된다.

Eureka 서버란?

Eureka 서버는 단순하게 MSA를 구성하는 마이크로 서비스들을 모니터링하는 감시자 서버의 역할을 한다고 볼 수 있지만. 깊게 보면 현재 존재하는 마이크로 서비스들을 Gateway에게 알려주어 시간과 부하에 따라 유동적으로 스케일 아웃되는 서버들을 모두 가용할 수 있도록 하는 역할을 수행한다. 따라서, Eureka 서버는 가동되는 서버를 확인 후 Gateway에게 그 목록을 알려주는 역할을 수행한다.

먼저, Service Discovery의 Eureka Server를 구축할 것이다.

Spring Cloud Eureka 서버 구축하기

1. 프로젝트 생성

Eureka 서버 설정을 위한 의존성 추가

필수 의존성

Eureka Server
Spring Security

// build.gradle

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-security'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.security:spring-security-test'
}

2. Main 클래스 어노테이션 등록

Eureka 서버로 동작하기 위한 어노테이션을 등록해야 한다.

// EurekaServerApplication

package com.caffeinedoctor.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer // EurekaServer로 등록
public class EurekaServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(EurekaServerApplication.class, args);
	}

}

main메서드에 @EnableEurekaServer 어노테이션을 추가하면 Discovery 서버로의 역할을 수행할 수 있게 된다.

3. Eureka 서버 설정

application.properties 파일을 삭제하고 application.yml 파일을 생성하여 설정을 통해 Eureka 서버를 생성한다.

# application.yml 

# 현재 프로젝트의 포트 번호 지정
# 유레카 서버 포트 번호는 보통 8761번 사용
server:
  port: 8761
  
# 현재 프로젝트의 이름 지정
spring:
  application:
    name: eureka-server

# 현재 프로젝트의 eureka 설정
eureka:
  client:
    # eureka 등록 여부
    # 유레카 서버가 자기자신을 등룍하는 것을 막음
    register-with-eureka: false
    # Eureka 서버로부터 인스턴스들의 정보를 주기적으로 가져올 것인지 설정하는 속성
    fetch-registry: false

포트 번호: 8761
Service 이름: eureka-server
register-with-eureka (디폴트 true)
- 레지스트리에 자신을 등록할 건지에 대한 여부이다.
- 즉, 유레카 서버에 등록하겠냐는 뜻이다.
- 지금 Service는 Eureka Server이니 등록이 필요 없어서 false로 설정한다.
fetch-registry (디폴트 true)
- 레지스트리에 있는 정보를 가지고 올건지에 대한 여부이다.
- true 설정 시 검색할 때마다 Eureka server를 호출하는 대신 레지스트리가 로컬로 캐싱된다.
- 즉, Client가 검색 가능하도록 하는 설정이다.
- 지금 Service는 Eureka Server이니 검색이 필요 없어서 false로 설정한다.

4. 시큐리티 설정

Eureka 서버는 내부망에서만 존재해야 된다. 하지만 외부망에 구축하거나 내부망에서도 보안을 중요시해야 하기 때문에 스프링 시큐리티 설정을 진행한다. 시큐리티는 httpBasic 방식 코드를 작성한다.

// SecurityConfig

package com.caffeinedoctor.eurekaserver.security;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;


// 시큐리티 커스텀 config를 작성하여 특정 경로에 대해 접근을 막는다.
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    // 암호화 시키기
    @Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {

        return new BCryptPasswordEncoder();
    }

    // 특정 경로에 대해서 보안 설정하기
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        // csrf 무시
        http.csrf((auth) -> auth.disable());

        // 모든 경로에 대해 권한이 필요하게 한다.
        http.authorizeHttpRequests((auth) -> auth.anyRequest().authenticated());

        // 로그인 방식은 http 베이직 방식
        http.httpBasic(Customizer.withDefaults());

        return http.build();
    }

    // 서버에 접속할 수 있는 비밀번호와 아이디 등록하기 (인 메모리 타입)
    @Bean
    public UserDetailsService userDetailsService() {
        // 시용자1 생성
        UserDetails user1 = User.builder()
                .username("아이디")
                .password(bCryptPasswordEncoder().encode("비밀번호"))
                .roles("ADMIN")
                .build();

        return new InMemoryUserDetailsManager(user1);
    }
}

Spring Cloud Eureka 서버 실행

참고 자료

https://covenant.tistory.com/251

https://devhan.tistory.com/m/260

https://substantial-park-a17.notion.site/6-Eureka-057c942a7a4041bf87ab5cd3043af021

[MSA] Service Discovery

bu119 — Tue, 12 Mar 2024 09:00:33 +0900

Service Discovery

마이크로서비스 아키텍처(MSA)로 구성되어 있는 서비스들은 각자 다른 IP와 Port를 가지고 있다.

이러한 서로 다른 서비스들의 IP와 Port 정보에 대해서 저장하고 관리할 필요가 있는데 Service Discovery라고 한다.

즉, MSA에서는 Service의 IP와 Port가 일정하지 않고 지속적을 변화한다. 그렇기 때문에 Client에 Service의 정보를 수동으로 입력하는 것은 한계가 분명하다. Service Discovery란 이런 MSA의 상황에 적합하다.

서비스의 인스턴스가 생성 혹은 소멸되거나 신규 서비스들이 지속적으로 증가하는 등 서비스의 정보가 지속적으로 바뀔 수 있다. 디스커버리 서버는 이러한 가변적인 모든 서비스의 정보들은 각 서비스의 고유 ID(거의 변하지 않는)에 매핑하여 관리한다. 그리고 각 서비스들은 지속적으로 1) 자신의 정보를 디스커버리 서버에 등록하며 2) 다른 서비스들의 정보를 조회한다. 그럼 각 서비스들은 다른 서비스의 IP와 PORT를 몰라도 서비스의 고유 ID만 가지고 연계가 가능해진다.

정리하자면, Service Discovery는

마이크로서비스의 정보(위치 등)를 등록할 수 있다.
외부의 요청이나 서비스가 마이크로서비스의 정보를 검색하기 위해 사용된다.

이러한 서비스 디스커버리의 구현을 쉽게 도와주는 것이 Spring Cloud의 Eureka이다.

Spring Cloud Netflix Eureka

Spring Cloud Netflix Eureka는 Service Discovery의 역할을 수행한다.

Eureka의 구성 요소

Service Discovery : 외부에서 마이크로서비스를 찾아주는 기능
Service Registry : 각각의 서비스가 자신의 위치 정보를 특정 서버에 등록하는 작업

즉, Eureka는 Eureka Server와 Eureka Client로 구성된다.

Eureka Server (서버 라이브러리) : 서비스들의 정보를 관리, 제공
Eureka Client (클라이언트 라이브러리) : 서버에 자신의 정보를 제공, 다른 서비스의 정보를 조회

말 그대로 Eureka Server는 디스커버리 서버에 탑재되며, Eureka Client는 각각의 서비스들에 탑재된다.

위의 그림과 같이 각 서비스들이 기동 될 때 혹은 가동 중에도 지속적으로 자신의 정보를 디스커버리 서버에 등록(갱신)하며, 서버는 이 정보들을 캐싱하여 관리한다.

이와 동시에 각 서비스들은 디스커버리 서버로부터 다른 서비스들의 정보를 지속적으로 조회한다.

(이 정보들 또한 기본적으로 서비스들이 캐싱하여 관리한다.)

그리고 각서비스 들은 서로의 고유 ID만 가지고 연계가 가능하다.

예를 들어, 상품 서비스가 주문 서비스로 REST API 요청을 할 때 IP와 PORT 대신 고유 ID로 통신이 가능해진다.

참고 자료

https://junhyunny.github.io/spring-boot/spring-cloud/msa/spring-cloud-netflix-eureka/

https://cloud.spring.io/spring-cloud-netflix/reference/html/#service-discovery-eureka-clients

https://mangchhe.github.io/springcloud/2021/04/07/ServiceDiscoveryConcept/

https://wonit.tistory.com/m/495

https://enjoy-dev.tistory.com/10

Chadoll

[AI] 제미나이(Gemini) API 키 발급받기

목차

1️⃣ Gemini API란?

2️⃣ Google AI Studio 접속 및 로그인

1. Google AI Studio 홈페이지 접속합니다.

2. Google 계정으로 로그인합니다.

3. 로그인 후 왼쪽 메뉴 하단의 “Get API key” (API 키 받기)를 클릭합니다.

3️⃣ Gemini API 키 발급하기

1. API 키 대시보드의 우측 상단 "API 키 만들기" 버튼을 클릭합니다.

2. 팝업창이 열리면, 키 이름을 지정하고, 프로젝트 선택 또는 새 프로젝트 생성합니다.

3. "키 만들기" 버튼을 클릭합니다.

4. 생성 완료 후, API 키 대시보드에 생성된 API 키가 표시됩니다.

5. API 키를 누르면, API 키 세부정보를 알 수 있습니다.

4️⃣ API 키 관리 및 보안

✅ 안전하게 관리하는 방법

5️⃣ Postman 으로 테스트하기

1. Gemini API 공식 문서를 통해 Gemini API 키 사용 방법을 확인합니다.

2. 다음은 Gemini API 공식 문서의 "API 키를 명시적으로 제공하는 방법의 예"입니다.

3. Postman을 활용하여 테스트하겠습니다.

정리하며

참고 링크

[JPA] 영속성 컨텍스트의 기능

왜 알아야 할까?

1. 1차 캐시 (First-Level Cache)

2. 엔티티 저장과 조회

저장

조회

3. 엔티티 삭제

4. 쓰기 지연 저장소 (Write-Behind)

5. flush()

6. 변경 감지 (Dirty Checking)

마무리

[JPA] 영속성 컨텍스트란?

왜 알아야 할까?

1. 영속성 컨텍스트란?

2. JPA와 데이터베이스 관계

3. EntityManager와 EntityManagerFactory

4. EntityManagerFactory 생성 과정

5. 트랜잭션과 쓰기 지연

6. 저장과 롤백 예제

7. 실무에서는 이렇게 사용합니다

마무리

[Spring] IoC 컨테이너와 Bean — 객체를 관리하는 Spring의 방식

1. IoC 컨테이너와 Bean이란?

2. Bean 등록 방법

@Component

@ComponentScan

3 Layer Annotation

3. Bean 사용 방법

@Autowired (DI 자동 주입)

ApplicationContext (직접 가져오기)

4. 정리

✨ 최종 한 줄

[Spring] IoC와 DI — 좋은 코드의 핵심 원칙

1. IoC와 DI란?

2. 왜 필요한가?

3. 의존성과 결합도

4. 결합도 낮추기 → 인터페이스 도입

5. 주입(Injection)의 방법

6. 제어의 역전(IoC)

✨ 정리

[Java] 문자열 다루기 — String, StringBuffer, StringBuilder 차이

1. 왜 문자열 처리가 중요할까?

2. String — 불변(Immutable)

특징

장단점

3. StringBuffer — 가변(Mutable) + 쓰레드 안전

특징

장단점

4. StringBuilder — 가변(Mutable) + 빠른 성능

특징

장단점

5. 성능 비교 테스트

6. 언제 무엇을 써야 할까?

선택 가이드라인

✨ 오늘의 인사이트

[Spring] 자바 웹 개발 흐름 정리 — Servlet부터 Spring Boot까지

자바 웹 개발의 발전 과정

1. 스파게티 코드 (초기 웹 개발)