가지가지하네

context-path와 Security: 예상과 다른 경로 매칭 문제

가지코딩 — Tue, 15 Jul 2025 11:26:46 +0900

Spring Boot 프로젝트에서 REST API 경로에 공통 prefix(/api)를 적용하기 위해 context-path 설정을 사용하는 경우가 많다.

하지만 이렇게 설정한 뒤, Spring Security에서 특정 경로를 허용하려 할 때, 의도한 대로 매칭되지 않고 403 혹은 401 에러가 발생하는 경우가 있다.

문제 상황

다음과 같이 context-path를 설정하고

server:
  servlet:
    context-path: /api

그리고 Security 설정에서는 아래와 같이 /api/login을 허용하도록 구성했다

http
    .authorizeHttpRequests(auth -> auth
        .requestMatchers("/api/login").permitAll()
        .anyRequest().authenticated()
    );

이 경우

클라이언트에서 /api/login으로 요청을 보내면 403 Forbidden 또는 401 Unauthorized 오류가 발생한다.

원인 분석

Spring Boot에서 server.servlet.context-path는 DispatcherServlet 레벨에서 모든 API 경로 앞에 /api prefix를 붙이게 된다.

예를 들어, 컨트롤러의 매핑이 다음과 같다면:

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginRequest request) {
    ...
}

실제 호출 가능한 경로는 /api/login이 된다.

하지만,

Spring Security는 context-path를 제거한 경로 기준으로 경로 매칭을 수행한다.

즉, requestMatchers("/api/login")는 실제 Security filter chain에서 존재하지 않는 경로로 간주된다.

Spring Security의 경로 매칭은 HttpServletRequest.getServletPath() 기준으로 이루어지며,

이 값은 context-path가 제외된 상태이다.

String servletPath = request.getServletPath(); // "/login"

해결 방법

Security 설정 시 context-path(prefix)를 포함하지 않고 경로를 지정

실제 요청은 /api/login이지만,
Security 설정에서는 /login으로 매칭해야 한다.

http
    .authorizeHttpRequests(auth -> auth
        .requestMatchers("/login").permitAll() // "/api/login" 아님
        .anyRequest().authenticated()
    );

@Cacheable 사용 시 역직렬화 오류 해결

가지코딩 — Tue, 15 Jul 2025 11:15:45 +0900

문제 상황

@Cacheable(value = "books", key = "...")
public PagedResponse<BookResponseDto> findAllCached(...) {
    return bookService.findAll(...);
}

PagedResponse<BookResponseDto> 와 같은 제네릭 타입으로 캐싱할 때

캐시에서 조회된 데이터가 LinkedHashMap으로 역직렬화되어 아래와 같은 오류가 발생

java.lang.ClassCastException: class java.util.LinkedHashMap cannot be cast to class cohttp://m.example.book_api.global.dto.PagedResponse (java.util.LinkedHashMap is in module java.base of loader 'bootstrap'; cohttp://m.example.book_api.global.dto.PagedResponse is in unnamed module of loader 'app')

java.lang.ClassCastException: class java.util.LinkedHashMap cannot be cast to class com.example.book_api.global.dto.PagedResponse (java.util.LinkedHashMap is in module java.base of loader 'bootstrap'; com.example.book_api.global.dto.PagedResponse is in unnamed module of loader 'app')

2. 원인 분석

@Cacheable 내부에서 Jackson이 객체를 JSON으로 직렬화하고 역직렬화하는 과정에서 제네릭 타입 정보가 손실된다.
Java의 타입 소거(Type Erasure) 특성 때문에 런타임에 제네릭 타입을 정확히 알 수 없어,
역직렬화 시 기본적으로 LinkedHashMap 타입으로 변환하게 된다.

3. 해결 방법

직접 캐시 로직 구현 및 TypeReference 사용

자동 캐시 대신 RedisTemplate 등으로 직접 캐시를 관리한다.
ObjectMapper에 TypeReference를 명시해 정확한 타입으로 역직렬화한다.

// 역 직렬화 문제로 수동 캐싱
public PagedResponse<BookResponseDto> findAllCached(...) {

    // key 조회
    String key = ...;
    Object cached = redisTemplate.opsForValue().get(key);
    PagedResponse<BookResponseDto> cachedResponse = objectMapper.convertValue(
            cached,
            new TypeReference<PagedResponse<BookResponseDto>>() {}
    );

    // 저장된 캐시가 있으면, 캐시 값 출력
    if (cachedResponse != null) {
		...
        return cachedResponse;
    }

    // 저장된 캐시가 없으면, DB 조회 + 캐시 생성
    PagedResponse<BookResponseDto> result = bookService.findAll(...);
    redisTemplate.opsForValue().set(key, result, 30, TimeUnit.MINUTES);

    return result;
}

EXPLAIN ANALYZE 활용법

가지코딩 — Fri, 4 Jul 2025 01:15:56 +0900

EXPLAIN ANALYZE란?

MySQL에서 쿼리 실행 계획뿐만 아니라, 쿼리를 실제로 실행해 본 후 실제 실행 시간과 처리된 행 수 같은 실행 통계까지 함께 보여주는 명령어

단순 EXPLAIN과 달리, 쿼리를 실제 실행하므로 정확한 성능 정보를 알 수 있다.
옵티마이저가 예측한 실행 계획과 실제 수행 결과를 비교해, 실행 계획의 적절성을 검증할 수 있다.

EXPLAIN ANALYZE 활용법 및 개선 방향

실제 실행 시간과 옵티마이저 예상 비용을 비교한다.
조인 방식(Nested Loop, Hash Join 등)과 인덱스 활용 여부를 확인한다.
불필요한 컬럼 조회를 피하고, 필요한 컬럼만 선택한다. (커버링 인덱스 유도)
통계 정보를 최신으로 유지해 옵티마이저가 정확한 계획을 세우도록 한다.
변경 전후 성능을 수치로 비교해 튜닝 효과를 검증한다.

EXPLAIN ANALYZE 활용 예제

EXPLAIN ANALYZE
SELECT o.order_id, o.total_price, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.total_price > 1000000
AND c.region = 'Seoul';

예상 결과 예시

orders 테이블이 테이블 스캔을 수행하고 있음 (cost=15000, 실제 120ms 소요)
customers 테이블 인덱스 조회는 인덱스가 있으나, orders 테이블에서 4800건을 모두 스캔한 후 각각에 대해 4800번 조회 수행 (loops=4800)

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop join                                                                                                                                                |
|    -> Table scan on orders  (cost=15000 rows=5000) (actual time=120.500..122.700 rows=4800 loops=1)                                                                |
|    -> Index lookup on customers using idx_customers_region (region = 'Seoul')  (cost=100 rows=50) (actual time=0.5..0.6 rows=48 loops=4800)                         |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.130 sec)

결과 해석

Nested loop join 방식으로 두 테이블을 조인함을 확인할 수 있다.
- 두 테이블을 조인할 때, 외부 테이블(orders)을 한 행씩 순회하면서 내부 테이블(customers)에서 해당 조건에 맞는 행을 찾는 방식
orders 테이블에 대해 풀 테이블 스캔을 수행하고, 그 행(4800개) 각각에 대해 customers 테이블에서 region='Seoul' 인덱스를 이용해 고객을 찾는다.
내부 테이블 인덱스 조회가 외부 테이블의 모든 행마다 반복되므로, 비용이 많이 든다.

쿼리 튜닝 방법

1. 조인 방식 변경

MySQL 기본 조인 방식은 Nested Loop Join이다.
큰 테이블을 먼저 필터링하거나 작은 테이블을 먼저 탐색하도록 조인 순서를 조정하여 성능 개선 가능
STRAIGHT_JOIN 키워드로 조인 순서를 강제할 수 있다.
서브쿼리, 윈도우 함수 등 MySQL 8+ 기능을 활용해 복잡한 조인을 간결하게 표현하고 최적화 시도 가능

2. 인덱스 추가

조인 조건 컬럼(customer_id 등)과 WHERE 절 필터 컬럼(total_price, region)에 인덱스를 추가
복합 인덱스 생성으로 다중 컬럼 조건을 한 번에 커버해 디스크 I/O 감소
인덱스 컬럼 순서도 중요, WHERE와 JOIN 조건 우선순위에 맞게 설계
불필요한 인덱스는 제거해 쓰기 성능 저하 방지

3. 쿼리 리팩토링

필요한 컬럼만 조회 (SELECT * 지양)
복잡한 쿼리는 뷰(View)나 임시 테이블로 분할해 가독성 및 유지보수성 향상
서브쿼리를 조인으로 변환해 옵티마이저가 더 좋은 계획 선택하도록 유도
불필요한 함수 호출, 계산 제거로 비용 절감
LIMIT, OFFSET 등 페이징 조건 최적화 (예: keyset pagination)

4. 기타 팁

ANALYZE TABLE로 통계 정보 갱신
실행 계획과 실제 실행 시간 간 차이가 크면 데이터 분포 및 통계 문제 의심
대용량 데이터는 파티셔닝도 검토

리팩토링 후 쿼리 예시

orders 테이블에 total_price에 대한 인덱스 추가
서브쿼리로 필터링된 고객만 조인

EXPLAIN ANALYZE
SELECT o.order_id, o.total_price, c.customer_name
FROM orders o
JOIN (
  SELECT customer_id, customer_name
  FROM customers
  WHERE region = 'Seoul'
) c ON o.customer_id = c.customer_id
WHERE o.total_price > 1000000;

예상 결과 예시

orders 테이블이 Index lookup을 수행해 필터링 비용이 크게 줄었음 (cost=500, 실제 5ms)
customers 테이블도 인덱스 조회를 하고, orders에서 필터링된 190건에 대해서만 190번 루프 실행 (loops=190)

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop join                                                                                                                                                |
|    -> Index lookup on orders using idx_orders_total_price (total_price > 1000000)  (cost=500 rows=200) (actual time=5.0..5.5 rows=190 loops=1)                      |
|    -> Index lookup on customers using idx_customers_region (region = 'Seoul')  (cost=100 rows=50) (actual time=0.5..0.6 rows=48 loops=190)                          |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.008 sec)

결과 해석

Nested loop join 방식 사용
- MySQL 에서는 조인 알고리즘을 직접 지정하기 어렵다...
- 특정 DBMS 에서는 조인 힌트(Hint) 를 통해 조인 방식을 명시하거나 유도할 수 있다
orders 테이블에서 total_price > 1000000 조건으로 인덱스를 통해 190개 정도의 행만 필터링해서 가져옴 → 훨씬 효율적이다.
이후 각 190개의 주문 행마다 customers 테이블에서 region='Seoul' 조건으로 인덱스 조회를 수행함.
orders 테이블에 인덱스를 활용해 필터링 후 조인하여, 외부 루프가 훨씬 줄어든 덕분에 쿼리가 더 빠르게 실행되었다.

Index Lookup vs Covering Index Lookup

가지코딩 — Fri, 4 Jul 2025 00:58:28 +0900

Index Lookup 이란?

인덱스로 조건에 맞는 row를 찾고, 그 뒤에 실제 테이블(클러스터드 인덱스)에서 필요한 데이터를 가져오는 방식

예시 쿼리

SELECT * FROM users WHERE nickname = 'nickname999999';

* EXPLAIN ANALYZE

+-------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                         |
+-------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Index lookup on users using idx_user_nickname (nickname = 'nickname999999')  (cost=0.37 rows=1) (actual time=0.0349..0.0372 rows=1 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------------------------------------------+

작동 방식

nickname 인덱스에서 해당 값을 찾는다.
인덱스에는 nickname만 있으므로,
실제 테이블로 이동하여 나머지 컬럼 데이터를 가져온다.

특징

추가적인 테이블 접근 비용이 존재
쿼리 대상 컬럼이 인덱스에 없으면 반드시 테이블 접근이 필요

Covering Index Lookup 이란?

쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 있어, 테이블을 전혀 읽지 않고 인덱스만으로 결과를 반환하는 방식

예시 쿼리

SELECT nickname FROM users WHERE nickname="nickname999999";

* EXPLAIN ANALYZE

+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                |
+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on users using idx_user_nickname (nickname = 'nickname999999')  (cost=1.1 rows=1) (actual time=0.012..0.0135 rows=1 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------------------------+

작동 방식

인덱스에서 nickname = 'nickname999999'을 찾음
쿼리에 필요한 정보가 인덱스에 모두 존재
테이블로 접근하지 않고, 인덱스만으로 결과를 반환

특징

테이블 접근 생략 → 디스크 I/O 최소화
빠른 응답속도, 특히 읽기 많은 서비스에서 매우 유리
조건 + SELECT 대상 컬럼이 인덱스에 모두 포함되어야 가능

Index Lookup vs Covering Index Lookup

구분	Index Lookup	Covering Index Lookup
테이블 접근	인덱스 + 테이블 row	인덱스만 사용
속도	보통	더 빠름 (I/O 적음)
인덱스에 필요한 컬럼	일부만 있어도 됨	쿼리 사용 컬럼 전부 포함되어야 함
활용 조건	WHERE에만 인덱스 컬럼 사용	WHERE + SELECT 컬럼 모두 인덱스 포함
단점	테이블 접근 필요 → I/O 증가	인덱스에 모든 컬럼을 포함해야 함 → 인덱스 크기 증가
실전 예시	SELECT *	SELECT nickname

Index Lookup: 일반적인 인덱스 조회 → 테이블 row 접근 필요
Covering Index Lookup: 인덱스만으로 완전 처리 → 더 빠름

Covering Index 사용 판단 기준

상황	Covering Index 적합도
읽기 비중이 높고, 자주 조회되는 컬럼만 조회	✅ 매우 적합
쓰기(UPDATE/INSERT) 비중이 높고, 자주 수정되는 컬럼 포함	❌ 부적합 (오히려 성능 저하 우려)
자주 쓰이는 컬럼이 제한적이고, 쓰기 비중도 적당한 경우	⚠️ 선택적으로 사용 가능

실무 팁

SELECT *는 피해야 한다
필요한 컬럼만 명시적으로 선택하여 커버링 인덱스를 활용할 수 있도록 한다.
커버링 인덱스 설계 전에 조회 패턴을 분석해야 한다
자주 사용하는 WHERE 조건과 SELECT 컬럼 조합을 파악하여 인덱스에 포함할 컬럼을 신중하게 결정한다.
쓰기 작업이 많은 테이블은 인덱스 크기와 갱신 비용을 반드시 고려해야 한다
커버링 인덱스는 인덱스 크기를 키우고 쓰기 시 인덱스 갱신 비용을 증가시켜 무분별한 인덱스 추가는 피하는 것이 좋다.

* 읽기 성능 vs 쓰기 비용 균형

읽기 성능 향상은 쓰기 비용 증가로 이어지는 상호 연관 관계가 있다
읽기 중심 시스템에서는 커버링 인덱스가 매우 효과적이나, 쓰기 중심 시스템에서는 오히려 성능 저하를 유발할 수 있으므로 신중히 설계할 것

[ Docker + CI/CD] 4. AWS 연동

가지코딩 — Thu, 3 Jul 2025 01:01:58 +0900

1. AWS 회원 가입 & 로그인

https://portal.aws.amazon.com/billing/signup

AWS Console - Signup

portal.aws.amazon.com

이메일 인증, 주소 등록, 카드 등록, 본인 인증 등의 절차를 거쳐 회원가입을 진행한

로그인 한다 !

2. EC2 설정

왼쪽 위 검색창에서 ec2 를 입력 후 선택

ec2 화면에서 ‘인스턴스’ 를 선택

인스턴스 시작 버튼 클릭

인스턴스 생성

이름 : my-server
Amazon Machine Image(AMI) : Amazon Linux 2023 AMI
인스턴스 유형 : t2.micro

키 페어 생성

‘새 키 페어 생성’ 클릭
- 키 페어 이름 : my-server-keypair
- 키 페어 유형: RSA
- 프라이빗 키 파일 형식: pem
- ‘키 페어 생성’ 후 다운로드

네트워크 설정

보안 그룹 생성 선택
Allow SSH traffic from , ‘위치 무관’ 선택
인터넷에서 HTTPS 트래픽 허용 선택
인터넷에서 HTTP 트래픽 허용 선택

인스턴스 시작 클릭 !

3. 서버 설정

ec2 접속

.pem 파일 권한 설정 (chmod 400)
ssh 로 접속

ssh -i test-server.pem ec2-user@{퍼블릭 IPv4 DNS 주소}

ec2 에 jdk 설치

sudo yum install -y java-17-amazon-corretto-devel

ec2에 docker, docker-compose 설치

sudo yum install docker

# Docker 서비스 시작
sudo systemctl start docker

# Docker 서비스 작동 상태 확인
sudo systemctl status docker

# Docker 서비스를 운영체제 부팅시 자동 시작하도록 설정
sudo systemctl enable docker

# docker 명령어를 sudo 없이 사용하기 위해 계정을 docker 그룹에 소속 (계정 재접속 필요)
sudo usermod -aG docker ec2-user

# docker-compose 설치
sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose

# 권한 부여
sudo chmod +x /usr/local/bin/docker-compose

4. github repository 설정

새로운 repository 생성 !

Settings > Secrets and variables > Actions 로 이동
Repository secrets 에 key 추가
- SSH_KEY: .pem 파일 내용 복사
- SSH_HOST: 퍼블릭 IPv4 DNS 주소 복사

5. 프로젝트 설정

https://github.com/gajicoding/cicd-aws/tree/11f4a77a9db8cb029a07f870be1f329dcd704a6d

GitHub - gajicoding/cicd-aws

Contribute to gajicoding/cicd-aws development by creating an account on GitHub.

github.com

.github/workflows/deploy.yml 파일 추가

name: Deploy

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'adopt'
          
      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew
        
      - name: gradlew bootJar
        run: ./gradlew bootJar
        
      - name: copy jar to server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ec2-user
          key: ${{ secrets.SSH_KEY }}
          port: 22
          source: "./build/libs/*.jar"
          target: "~"
          strip_components: 2

      - name: SSH Commands
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ec2-user
          key: ${{ secrets.SSH_KEY }}
          port: 22
          script_stop: true
          script: |
            sudo yum update -y && sudo yum install -y java-21-amazon-corretto
            for pid in $(pgrep java); do
              if ps -p $pid -o args= | grep -q 'java -jar'; then
                echo "Java process with 'java -jar' found (PID: $pid). Terminating..."
                kill -9 $pid
              fi
            done
            echo "nohup java -jar ~/*.jar > ~/app.log 2>&1 &" | at now

* 작업 순서

코드 checkout
JDK 설정
gradlew 실행
jar 파일 전송
jar 파일 실행

6. EC2 인바운드 규칙 설정

인스턴스 > 보안 > 보안 그룹 > 인바운드 규칙 편집

7. 배포 확인

8. 인스턴스 중지

AWS를 사용하는 것은 비용이 발생할 수 있으니 주의해야 한다 !!!

사용하지 않는 EC2 서버는 ‘중지’ 상태로 변경. 서버를 없애려면 위해선 ‘종료’ 선택

번외

docker 로 배포하기 !

강의에서 ec2 에 docker 환경 설정은 해주었지만, docker 를 사용하여 배포하지는 않았다...

궁금한건 직접 해보기

https://github.com/gajicoding/cicd-aws/tree/cad62e7622af1fae48c4a3db98017bdae13f2339

GitHub - gajicoding/cicd-aws

Contribute to gajicoding/cicd-aws development by creating an account on GitHub.

github.com

Windows에서 EC2 SSH 접속 시 WARNING: UNPROTECTED PRIVATE KEY FILE! 오류 해결

가지코딩 — Thu, 3 Jul 2025 00:02:33 +0900

문제 상황

AWS EC2 인스턴스에 SSH로 접속을 시도했는데 다음과 같은 오류가 발생했다:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'test-server.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "test-server.pem": bad permissions
ec2-user@ec2-xx-xxx-xx-xxx.compute.amazonaws.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

원인 분석

이 오류는 SSH에서 사용하는 비공개 키(.pem) 파일의 권한이 너무 널널할 때 발생한다.

리눅스 기반에서는 chmod 400으로 쉽게 해결되지만, Windows에서는 NTFS 파일 시스템을 사용하기 때문에 chmod가 제대로 적용되지 않는다.
특히, Windows의 기본 사용자 그룹인 BUILTIN\Users, Everyone, Administrators가 해당 파일에 접근 권한을 가지고 있으면 SSH 접속이 거부된다.

SSH로 접속 시도 전, git bash 로 권한 설정을 해주었지만, 적용되지 않은 듯 하다

해결 방법

Windows PowerShell로 파일 권한 재설정

PowerShell 실행 (관리자 권한 권장)
아래 스크립트 실행
(본인의 .pem 경로에 맞게 수정)

$PemPath = "C:\Users\KNG\Desktop\key\aws_key\test-server.pem"

# 1. 상속 제거
icacls $PemPath /inheritance:r

# 2. 불필요한 사용자 권한 제거
icacls $PemPath /remove:g "Users"
icacls $PemPath /remove:g "Administrators"
icacls $PemPath /remove "NT AUTHORITY\SYSTEM"
icacls $PemPath /remove "BUILTIN\Users"
icacls $PemPath /remove "BUILTIN\Administrators"

# 3. 현재 사용자에게만 읽기 권한 부여
$CurrentUser = "$env:USERNAME"
icacls $PemPath /grant:r "$CurrentUser:R"

적용 여부 확인

icacls "C:\Users\KNG\Desktop\key\aws_key\test-server.pem"

현재 사용자: (R) 만 남아있다면 성공 !

SSH 접속도 잘 되는 것을 확인했다 !

[ Docker + CI/CD] 3-2. Docker 모니터링과 로깅

가지코딩 — Wed, 2 Jul 2025 23:08:32 +0900

학습 목표

Docker 컨테이너를 모니터링하고 로깅을 확인할 수 있습니다.

1. Docker 모니터링

Docker 모니터링

컨테이너가 현재 어떤 상태로 실행되고 있는지 확인하는 활동
확인 가능한 정보
- CPU 사용량
- 메모리 사용량
- 네트워크 트래픽
- 디스크 I/O
모니터링의 중요성
- 과도한 자원 사용 감지
- 병목 현상 파악
- 시스템 최적화 및 안정성 확보

2. Container 리소스 모니터링

docker stats: 컨테이너 실시간 모니터링

docker stats

실행 중인 모든 컨테이너의 자원 사용 현황을 실시간으로 표시
출력 정보:
- CPU %
- 메모리 사용량 / 제한
- 네트워크 I/O
- 디스크 I/O

* 특정 컨테이너만 보고 싶다면?

docker stats <컨테이너 이름 또는 ID>

htop: 시스템 리소스 모니터링

리눅스 시스템 전체의 자원 사용 상태를 직관적으로 보여주는 CLI 도구

docker run --name test-tools -ti -d ubuntu:22.04
docker exec -ti test-tools /bin/bash
apt update && apt install -y htop
htop

df와 du: 디스크 사용량 확인

df: 시스템 전체 디스크 사용량

docker exec -ti test-tools /bin/bash
df -h
exit

du: 디렉토리별 디스크 사용량

docker exec -ti test-tools /bin/bash
du -sh              # 현재 디렉토리 총 사용량
du -h --max-depth=1 # 하위 디렉토리 1단계까지 사용량
exit

3. Container 로깅

기본 로깅 방식

Docker는 모든 컨테이너의 stdout / stderr 출력을 캡처하여, 기본적으로 json-file 로깅 드라이버를 사용해 로그 파일에 기록한다.

/var/lib/docker/containers/<컨테이너ID>/<컨테이너ID>-json.log

로그 확인 예제

docker run --name logs-test --rm -d ubuntu:22.04 /bin/bash -c 'while true; do date; sleep 1; done'
docker logs logs-test                   # 전체 출력
docker logs -f logs-test                # 실시간 로그 보기
docker logs -f --tail 10 logs-test      # 마지막 10줄부터 보기

# 로그 파일 경로 확인:
docker inspect logs-test --format "{{.LogPath}}"

로그 파일 관리: 로테이션 설정

실제 운영 환경에서는 로그가 계속 쌓이기 때문에, 크기 제한 및 파일 개수 제한이 필요하다.
- max-size: 개별 로그 파일의 최대 크기
- max-file: 보관할 최대 파일 개수

docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=10 \
  --name nginxtest \
  --restart always \
  -p 80:80 -p 443:443 \
  nginx:latest

[ Docker + CI/CD] 3-1. Dockerfile 과 Docker Compose

가지코딩 — Wed, 2 Jul 2025 22:46:17 +0900

학습 목표

Dockerfile 을 활용하여 나만의 이미지를 만들 수 있습니다.
Docker Compose 를 활용하여 여러 개의 컨테이너를 관리할 수 있습니다.

1. Dockerfile

Dockerfile

Docker 이미지 생성을 위한 빌드 명세 파일
텍스트 형식의 스크립트 파일로, 도커가 이미지를 생성할 때 따라야 하는 지시어(instruction)들을 포함한다.
Dockerfile은 사용자가 정의한 명령어들을 기반으로 새로운 도커 이미지를 생성하는 데 사용된다.
해당 명령어들은 계층(layer) 단위로 실행되며, 각 계층은 캐시될 수 있다.

주요 특징

비결정적 상태 방지: 명령어 순서와 내용을 명확하게 기술하여 빌드 과정의 재현성을 보장한다.
Immutable Image 정의: 컨테이너는 Dockerfile로 정의된 이미지로부터 동일한 상태로 실행 가능하다.
Layered Filesystem: 각 명령어는 파일시스템 레이어를 생성하며, 변경된 레이어만 캐시 무효화된다.

주요 명령어 (Instruction)

명령어	설명
FROM	베이스 이미지 지정. 모든 Dockerfile은 이 명령어로 시작해야 함.
RUN	빌드 시 실행할 명령어. 예: 패키지 설치, 빌드 작업 등
CMD	컨테이너가 실행될 때 기본으로 실행될 명령 지정.
COPY	호스트 시스템의 파일을 이미지에 복사.
ADD	COPY와 유사하나 URL 및 압축 해제 지원.
WORKDIR	이후 명령어가 실행될 작업 디렉토리 설정.
ENV	환경 변수 설정.
EXPOSE	컨테이너에서 열 포트를 명시. 네트워크 연결 용도로 사용.
ENTRYPOINT	실행 파일 및 인자를 고정적으로 설정할 때 사용.
ARG	빌드 시점에 사용할 변수 정의. ENV와 달리 런타임에서는 무효.

기본 구조 예시

# 1. 베이스 이미지 선택 (예: node.js 환경)
FROM node:18

# 2. 작업 디렉토리 설정
WORKDIR /app

# 3. 로컬 파일을 이미지에 복사
COPY package.json ./
COPY . .

# 4. 의존성 설치
RUN npm install

# 5. 앱 실행
CMD ["npm", "start"]

사용 흐름

Dockerfile 작성
docker build 명령어로 이미지 생성
생성된 이미지를 바탕으로 컨테이너 실행

Dockerfile 예제

FastAPI 앱을 실행하는 예제

FROM python:3.11

RUN pip install pipenv

WORKDIR /app

ADD . /app/

RUN pipenv --python 3.11
RUN pipenv run pip install poetry
RUN pipenv sync
RUN pipenv run pip install certifi

ARG STAGE

RUN sh -c 'echo "STAGE=$STAGE" > .env'
RUN sh -c 'echo "PYTHONPATH=." >> .env'
RUN chmod +x ./scripts/run.sh
RUN chmod +x ./scripts/run-worker.sh

CMD ["./scripts/run.sh"]

nginx 이미지를 생성하는 예제

실제로는 nginx:latest 이미지를 사용하면 되지만, 예제를 위해 만들어 보았다.

# Dockerfile
FROM ubuntu:22.04
MAINTAINER your-name <your-email@example.com>
LABEL purpose=Web Server

# nginx 패키지 설치
RUN apt-get update && apt-get install -y nginx

# nginx 설정 파일 복사
COPY nginx.conf /etc/nginx/nginx.conf

# Nginx 실행
CMD ["nginx", "-g", "daemon off;"]

# nginx.conf
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    gzip  on;
    gzip_disable "msie6";

    include /etc/nginx/conf.d/*.conf;
}

2. Docker Compose

Docker Compose

여러 개의 Docker 컨테이너를 정의하고 동시에 실행하기 위한 도구
애플리케이션을 구성하는 여러 서비스(예: 웹 서버, DB 등)를 하나의 설정 파일(docker-compose.yml)에 선언하고,
명령어 하나로 일괄적으로 빌드, 생성, 네트워크 연결, 시작할 수 있게 해준다.

핵심 역할

멀티 컨테이너 환경 구성
컨테이너 간의 의존성 정의 및 관리
통합된 빌드/실행/종료 관리
프로젝트별 고립된 네트워크 자동 구성

구성 요소

docker-compose.yml 파일
- services: 컨테이너 단위 구성
- web: 사용자 정의 서비스 이름
- depends_on: 실행 순서 정의 (의존 관계)
- environment: 환경 변수 전달

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: example

명령어 인터페이스

명령어	설명
docker-compose up	정의된 모든 서비스를 빌드 및 실행
docker-compose down	실행 중인 모든 서비스 중지 및 네트워크 제거
docker-compose build	이미지 빌드만 실행
docker-compose logs	서비스별 로그 출력
docker-compose ps	실행 중인 서비스 목록 확인

Compose가 내부적으로 하는 일

docker network를 생성하여 서비스 간 통신 가능하게 함
각 서비스에 대해 docker build 또는 docker run 수행
컨테이너 이름을 고유하게 지정 (프로젝트_서비스_순번)
depends_on, restart, volumes, environment 등의 설정 반영

Docker Compose 예시

Spring + MySQL 구성 예시

app은 로컬에서 빌드되는 Spring 애플리케이션
mysql은 MySQL 공식 이미지 사용
app은 mysql 서비스에 연결 (mysql은 내부 DNS 호스트명)

version: '3.8'
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - mysql
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/testdb

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: testdb
    ports:
      - "3306:3306"

fastapi app

# Dockerfile
FROM python:3.10

RUN pip install pipenv

WORKDIR /app

ADD . /app/

RUN pipenv --python 3.10
RUN pipenv run pip install poetry
RUN pipenv sync
RUN pipenv run pip install certifi


ARG STAGE

RUN sh -c 'echo "STAGE=$STAGE" > .env'
RUN sh -c 'echo "PYTHONPATH=." >> .env'
# ENV PYTHONPATH=/app
RUN chmod +x ./scripts/run.sh
RUN chmod +x ./scripts/run-worker.sh

# ENV PYTHONPATH=/app
CMD ["./scripts/run.sh"]

# docker-compoe.yaml
version: "3"
services:
  channel-api:
    image: xxxx.dkr.ecr.ap-northeast-2.amazonaws.com/reaction-channel:${AWS_ENV_STAGE:-dev}-${TAG:-latest}
    build:
      context: .
      dockerfile: dockerfile
      args:
        STAGE: ${STAGE:-develop}
    ports:
      - "8000:8000"
    environment:
      - NEW_RELIC_CONFIG_FILE=newrelic.ini
      - NEW_RELIC_ENVIRONMENT=ecs-${STAGE:-develop}
    logging:
      driver: awslogs
      options:
        awslogs-stream-prefix: channel
        awslogs-group: /ecs/reaction/${AWS_ENV_STAGE:-dev}/channel-api
        awslogs-region: ap-northeast-2

  reverseproxy:
    image: xxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/reverseproxy:prod-channel-latest
    ports:
    - "80:80"
    - "81:81"
    logging:
      driver: awslogs
      options:
        awslogs-stream-prefix: reverseproxy
        awslogs-group: /ecs/reaction/${AWS_ENV_STAGE:-dev}/reverseproxy
        awslogs-region: ap-northeast-2

3. Docker Compose 실습

https://github.com/gajicoding/docker-compose-sample

GitHub - gajicoding/docker-compose-sample

Contribute to gajicoding/docker-compose-sample development by creating an account on GitHub.

github.com

docker-compose 로 실행

cd ~/docker-compose-sample
docker-compose up -d
docker-compose logs -f

redis 연결 테스트

http://localhost:8080/test-cache 에 redis 를 사용한 5초 단위 캐시 적용 확인

[ Docker + CI/CD] 2. Github actions를 활용한 CI/CD 파이프라인

가지코딩 — Tue, 1 Jul 2025 23:16:40 +0900

학습 목표

Github Actions를 이해합니다.
간단한 CI/CD 파이프라인을 구성합니다.

1. Github Actions

GitHub Actions

GitHub에서 제공하는 CI/CD 자동화 도구
코드 변경(pull request, push 등)에 반응하여 자동으로 테스트, 빌드, 배포 등의 작업을 수행할 수 있다.
GitHub 저장소 내부에서 실행되며, 외부 서비스 연동 없이 GitHub 환경에서 직접 워크플로우를 구성할 수 있는 점이 특징이다.

주요 구성 요소

Workflow
- 자동화하고 싶은 전체 작업 정의
- .github/workflows/main.yml 등의 형식으로 저장
Job
- 워크플로우 안에서 병렬 혹은 순차적으로 실행되는 작업 단위
- 예: build, test, deploy
Step
- 각 Job 안에서 순차적으로 실행되는 세부 작업
- 예: 코드 체크아웃, 패키지 설치, 테스트 실행
Action
- Step 안에서 재사용 가능한 명령 집합 (GitHub 커뮤니티나 직접 만든 것도 사용 가능)
- 예: actions/checkout, actions/setup-java

트리거 종류

트리거	설명
push	특정 브랜치로 푸시될 때 실행
pull_request	PR이 열리거나 업데이트될 때 실행
schedule	크론 표현식을 사용해 주기적으로 실행
workflow_dispatch	수동 실행 트리거 (버튼 클릭)

2. Github Actions CI

GitHub Actions에서 CI

test를 통과한 코드만 develop 브랜치와 main 브랜치에 merge되도록 하여 오류를 방지하고 안정적인 코드가 배포되고 버그를 빠르게 발견

Github Actions로 CI 구성하기

develop, feature/* 브랜치 푸시나 PR 발생 시 실행
Java 17 설치 후 ./gradlew test로 테스트 자동 수행

name: Run Test

on:
  push:
    branches: [ develop, feature/* ]
  pull_request:
    branches: [ develop ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: setup java
        uses: actions/setup-java@v2
        with:
          distribution: 'adopt'
          java-version: '17'

      - name: run test
        run: |
          chmod +x ./gradlew
          ./gradlew clean test

실습

https://github.com/gajicoding/ci-sample

GitHub - gajicoding/ci-sample

Contribute to gajicoding/ci-sample development by creating an account on GitHub.

github.com

3. Github Actions CD

GitHub Actions에서 CD

배포를 자동화하는 작업을 기술해서 빠르고 간편하게 배포

전체 흐름

feature/* → PR 생성 → gradle test 수행
test 성공 시 → 리뷰 → merge
main 브랜치로 merge → 자동 배포

실습

https://github.com/gajicoding/cicd-sample

GitHub - gajicoding/cicd-sample

Contribute to gajicoding/cicd-sample development by creating an account on GitHub.

github.com

[ Docker + CI/CD] 1. CICD와 Docker 이해

가지코딩 — Tue, 1 Jul 2025 20:32:19 +0900

학습 목표

CI/CD 사용 이유를 이해합니다.
Docker 사용 이유를 이해합니다.
윈도우11 이나 MacOS에서 도커 실행 환경을 구성합니다.
간단한 Container 서비스 구현 실습을 통해 앱을 실행합니다.

1. CI/CD란 무엇인가?

CI/CD

Continuous Integration(지속적 통합)과 Continuous Delivery 또는 Continuous Deployment(지속적 제공 또는 지속적 배포)의 약자
소프트웨어 개발에서 개발 → 테스트 → 배포의 과정을 자동화하여 더 빠르고 안정적으로 서비스를 제공하기 위한 DevOps의 핵심 개념

CI (지속적 통합, Continuous Integration)

개발자들이 작은 단위로 자주 코드를 통합(merge)하고, 그때마다 자동으로 빌드 및 테스트하는 프로세스
목적
- 코드 통합 시 충돌 방지
- 자동화된 테스트를 통해 버그를 초기에 발견
- 개발자 간 협업 효율 증대
예시
1. 개발자가 GitHub에 코드를 push하면
2. Jenkins/GitHub Actions 등이 코드를 자동으로 빌드하고 테스트 수행
3. 테스트 통과 여부에 따라 병합 여부 결정

CD (지속적 제공/배포, Continuous Delivery / Deployment)

Continuous Delivery (지속적 제공)
- CI 이후의 단계로, 테스트를 통과한 코드를 자동으로 staging 서버에 배포 가능한 상태로 만들어 둠.
  하지만 실제 프로덕션 배포는 수동으로 진행.
- 수동 승인만 하면 바로 운영 서버로 배포 가능
- 안정성과 배포 준비성 확보
Continuous Deployment (지속적 배포)
- 테스트까지 통과하면 자동으로 운영 서버에 배포까지 수행하는 방식
- 사람이 개입하지 않아도 코드 → 운영까지 자동화됨
- 빠른 피드백 루프 가능 (ex: A/B 테스트, 빠른 롤백 등)

CI/CD 도입 시 이점

배포 속도 향상
버그 조기 발견 및 수정
코드 품질 향상
반복 작업 감소 → 개발자는 핵심 로직에 집중 가능

관련 도구들

영역	도구 예시
버전 관리	Git, GitHub, GitLab
CI/CD 파이프라인	Jenkins, GitHub Actions, GitLab CI/CD, CircleCI
빌드 도구	Maven, Gradle
테스트 자동화	JUnit, Mockito, Selenium
배포 자동화	Docker, Kubernetes, ArgoCD

2. 왜 Docker인가

Docker는 현대 소프트웨어 개발에서 널리 사용되는 컨테이너 기반 가상화 기술이다.
개발, 테스트, 배포 환경을 표준화하고 자동화할 수 있다는 점에서 많은 개발자와 기업이 도입하고 있다.

Docker 사용 이유

개발과 배포가 편리하다
- Docker 컨테이너는 애플리케이션 실행에 필요한 모든 요소를 포함하므로, 환경 설정이 간단하다.
- 컨테이너 내부에서 다양한 소프트웨어를 설치하더라도 호스트 운영체제에 영향을 주지 않는다.
- 어떤 서버에서 실행하더라도 항상 동일한 환경을 보장하기 때문에 배포 오류를 줄일 수 있다.
- CI/CD 파이프라인에서 테스트 및 빌드 환경으로 자주 활용된다.
독립성과 확장성이 뛰어나다
- 애플리케이션을 서로 다른 컨테이너에 배포함으로써 각 애플리케이션이 서로 영향을 주지 않는다.
- 컨테이너 단위로 수평 확장이 가능하므로, 트래픽 증가에 유연하게 대응할 수 있다.
- 컨테이너는 가볍고 빠르게 실행되므로, 리소스 효율성도 높다.
컨테이너 기술의 사실상 표준이다
- Docker는 기존의 가상 머신에 비해 경량화되어 있으며, 실행 속도도 빠르다.
- 클라우드, DevOps, MSA 환경에서 사실상 표준으로 자리잡고 있다.
- 다양한 개발 도구 및 플랫폼과의 연동성이 뛰어나며, 생태계도 활발하다.

3. Docker 설치 - Window11

4. Docker 설치 후 Docker Test

Docker 엔진과 구성 확인

docker info

Container 실행 테스트

# nginx 이미지 다운받기
docker image pull nginx:1.25.3-alpine

docker images

docker image history nginx:1.25.3-alpine

docker run -d -p 8001:80 --name webserver01 nginx:1.25.3-alpine

docker ps | Select-String "webserver01"

docker port webserver01

curl http://localhost:8001

5. Docker Image

Docker Image

Docker 이미지는 컨테이너 서비스를 위한 실행 환경을 정의한 읽기 전용 템플릿
애플리케이션 실행에 필요한 바이너리, 라이브러리, 설정 파일 등을 포함한다.
특징
- 상태 저장 없음 (Stateless)
  - Docker 이미지는 애플리케이션 실행에 필요한 모든 파일과 라이브러리를 자체적으로 포함한다.
  - 실행 환경에 영향을 받지 않고, 어디서든 동일한 애플리케이션을 실행할 수 있다.
  - 이미지는 변경되는 상태값을 보유하지 않는다.
- 불변성 (Immutable)
  - Docker 이미지는 한 번 생성되면 변경할 수 없다.
  - 이미지를 수정하고 싶다면 기존 이미지를 기반으로 새로운 이미지를 생성해야 한다.
  - 불변성은 배포 환경의 안정성과 일관성을 높이는 데 기여한다.
- 경량성
  - 이미지는 필요한 파일만 포함하고 있기 때문에, 전통적인 가상 머신에 비해 용량이 작고 전송 속도도 빠르다.
  - 버전 관리 및 캐싱이 용이하며, 레이어 구조로 인해 중복 없이 효율적으로 관리된다.

Docker Image 명령어

목적	명령어	설명
로컬 이미지 목록 확인	docker image ls 또는 docker images	로컬에 저장된 이미지 목록을 출력한다.
이미지 다운로드	docker image pull <이미지>	Docker Hub 또는 다른 레지스트리에서 이미지를 다운로드한다.
이미지 업로드	docker image push <이미지>	로컬 이미지를 Docker Hub 등 원격 레지스트리에 업로드한다.
이미지 빌드	docker image build -t <이름>:<태그> <경로>	지정된 Dockerfile을 기반으로 이미지를 빌드한다.
이미지 삭제	docker image rm <이미지>	지정한 로컬 이미지를 삭제한다. (-f 옵션으로 강제 삭제 가능)
태그 추가	docker image tag <원본> <새이름>:<태그>	기존 이미지에 새 이름(태그)을 부여한다.
이미지 메타 정보 확인	docker image inspect <이미지>	이미지의 상세 정보를 JSON 형식으로 출력한다.
이미지 히스토리 확인	docker image history <이미지>	이미지의 레이어별 생성 내역을 확인한다.
사용하지 않는 이미지 정리	docker image prune	태그가 없는(dangling) 이미지들을 일괄 삭제한다.
이미지 내보내기	docker image save -o <파일>.tar <이미지>	이미지를 tar 파일로 저장한다. (백업/전송용)
이미지 불러오기	docker image load -i <파일>.tar	저장된 tar 파일로부터 이미지를 불러온다.

자주 사용하는 명령어

# 1. 이미지 빌드
docker image build -t myapp:1.0 .

# 2. 빌드된 이미지 확인
docker image ls

# 3. 이미지의 레이어 히스토리 확인
docker image history myapp:1.0

# 4. 이미지 메타 정보 조회
docker image inspect myapp:1.0

# 5. 사용하지 않는 이미지 정리
docker image prune -f

6. Docker Container

Docker Container

Docker Image를 실행한 인스턴스이며, 애플리케이션과 그 실행 환경을 격리된 상태로 실행하는 단위

이미지와 컨테이너의 관계

이미지(Image): 읽기 전용 템플릿 (설치본, 실행 파일 등)
컨테이너(Container): 이미지에서 실행된 프로세스 (실행 중인 프로그램)

컨테이너 동작 원리

Dockerfile을 통해 이미지 생성
이미지를 기반으로 컨테이너 생성 및 실행
컨테이너는 이미지 위에 쓰기 가능한 레이어를 추가하여 동작

Docker Container 명령어

목적	명령어	설명
컨테이너 실행	docker container run	새로운 컨테이너를 생성하고 실행한다. (docker run 과 동일)
실행 중인 컨테이너 목록 확인	docker container ls	현재 실행 중인 컨테이너 목록을 출력한다.
모든 컨테이너 목록 확인	docker container ls -a	중지된 컨테이너를 포함한 전체 목록을 출력한다.
컨테이너 내부 명령 실행	docker container exec -it <컨테이너> <명령>	실행 중인 컨테이너 내부에서 명령을 실행한다 (예: bash 진입).
컨테이너 상태 상세 조회	docker container inspect <컨테이너>	컨테이너의 설정, 네트워크, 볼륨 등 상세 정보를 JSON 형식으로 출력한다.
로그 확인	docker container logs <컨테이너>	해당 컨테이너의 stdout/stderr 로그를 출력한다.
프로세스 확인	docker container top <컨테이너>	컨테이너 내부에서 실행 중인 프로세스 목록을 출력한다.
리소스 사용량 확인	docker container stats	컨테이너의 CPU, 메모리, 네트워크 사용량 등을 실시간으로 확인한다.
컨테이너 일시 중단	docker container pause <컨테이너>	컨테이너의 모든 프로세스를 일시 중단한다.
일시 중단 해제	docker container unpause <컨테이너>	pause 상태의 컨테이너를 다시 실행 상태로 전환한다.
컨테이너 중지	docker container stop <컨테이너>	컨테이너를 정상 종료(SIGTERM → SIGKILL)한다.
컨테이너 강제 종료	docker container kill <컨테이너>	즉시 SIGKILL 신호로 컨테이너를 종료한다.
컨테이너 재시작	docker container restart <컨테이너>	컨테이너를 중지한 뒤 다시 시작한다.
컨테이너 삭제	docker container rm <컨테이너>	중지된 컨테이너를 삭제한다.
사용하지 않는 컨테이너 일괄 정리	docker container prune	중지된 모든 컨테이너를 한 번에 삭제한다. (확인 메시지 있음)

자주 사용하는 명령어

# 1. nginx 컨테이너 실행
docker run --name web01 -d -p 8080:80 nginx

# 2. 실행 중인 컨테이너 목록 확인
docker container ls

# 3. 컨테이너 내부에 접속
docker exec -it web01 bash

# 4. 컨테이너 중지 및 삭제
docker stop web01
docker rm web01

가지가지하네

context-path와 Security: 예상과 다른 경로 매칭 문제

문제 상황

클라이언트에서 /api/login으로 요청을 보내면 403 Forbidden 또는 401 Unauthorized 오류가 발생한다.

원인 분석

하지만,

해결 방법

Security 설정 시 context-path(prefix)를 포함하지 않고 경로를 지정

@Cacheable 사용 시 역직렬화 오류 해결

문제 상황

PagedResponse<BookResponseDto> 와 같은 제네릭 타입으로 캐싱할 때

캐시에서 조회된 데이터가 LinkedHashMap으로 역직렬화되어 아래와 같은 오류가 발생

2. 원인 분석

3. 해결 방법

직접 캐시 로직 구현 및 TypeReference 사용

EXPLAIN ANALYZE 활용법

EXPLAIN ANALYZE란?

EXPLAIN ANALYZE 활용법 및 개선 방향

EXPLAIN ANALYZE 활용 예제

Index Lookup vs Covering Index Lookup

Index Lookup 이란?

Covering Index Lookup 이란?

Index Lookup vs Covering Index Lookup

Covering Index 사용 판단 기준

[ Docker + CI/CD] 4. AWS 연동

목차

1. AWS 회원 가입 & 로그인

2. EC2 설정

3. 서버 설정

4. github repository 설정

5. 프로젝트 설정

6. EC2 인바운드 규칙 설정

7. 배포 확인

8. 인스턴스 중지

번외

docker 로 배포하기 !

Windows에서 EC2 SSH 접속 시 WARNING: UNPROTECTED PRIVATE KEY FILE! 오류 해결

문제 상황

원인 분석

해결 방법

[ Docker + CI/CD] 3-2. Docker 모니터링과 로깅﻿

목차

학습 목표

1. Docker 모니터링

2. Container 리소스 모니터링

3. Container 로깅

[ Docker + CI/CD] 3-1. Dockerfile 과 Docker Compose

목차

학습 목표

1. Dockerfile

2. Docker Compose

3. Docker Compose 실습

[ Docker + CI/CD] 2. Github actions를 활용한 CI/CD 파이프라인

목차

학습 목표

1. Github Actions

2. Github Actions CI

3. Github Actions CD

[ Docker + CI/CD] 1. CICD와 Docker 이해

목차

학습 목표

1. CI/CD란 무엇인가?

2. 왜 Docker인가

3. Docker 설치 - Window11

4. Docker 설치 후 Docker Test

5. Docker Image

6. Docker Container

[ Docker + CI/CD] 3-2. Docker 모니터링과 로깅