과금된 내역은 이러하다. 두 가지 부분에서 과금이 된 걸 확인할 수 있다.

• Amazon Virtual Private Cloud Public IPv4 Addresses
• EBS

Public IP 릴리즈 하기

기존 인스턴스 서버에 Public IP를 연결해서 쓰고 있었다면, 인스턴스만 삭제한다고 해서 Public IP가 저절로 삭제되지 않는다. Public IP는 따로 릴리즈 해주어야 한다.

콘솔 > VPC > 탄력적 IP 탭에서 본인이 사용하고 있는 탄력적 IP 주소를 확인할 수 있다. 리전 선택에 따라 달라지니, 본인이 사용하고 있는 리전에서 조회하자.

존재하던 IP를 릴리즈한 직후의 모습이다. 이미 인스턴스는 삭제한 후라 콘솔 화면에 빠르게 반영이 되었다.

EBS 스냅샷 삭제

인스턴스를 삭제할 때, 인스턴스 스냅샷은 함께 삭제되지 않는다. 인스턴스를 삭제하면서 혹시 몰라 스냅샷을 저장했던 것 같은데 해당 스냅샷이 계속 남아있어서 과금이 되었다.

콘솔 > EC2 > Elastic Block Store > 스냅샷 에서 저장된 스냅샷들을 확인할 수 있다.

남아있는 스냅샷을 삭제하려 했는데 아래처럼 메세지가 떴다. 스냅샷이 AMI에 연결이 되어있어 삭제가 되지 않았다. 문제가 된 ami-099...를 클릭하면 자동으로 페이지가 이동된다.

해당 AMI를 삭제해준다.

AMI를 삭제할 때, 연결된 스냅샷도 자동으로 삭제할 수 있게 해준다.

이제 지긋지긋한 AWS와도 이별이다..ㅎㅎ

• 크롤링한 가게 데이터들을 추가하고 나서 인덱스를 작업하지 않았다. (4만건 정도)

• 추가로 distange_range라는 값을 추가로 주어야했다.

  ex.) 가게는 250m/500m/750m 단위로 검색할 수 있게 해둔 상황. sorting을 위해 현재 위치와 100m 떨어져있으면 "distance_range": "250", 현재 위치와 450m 떨어져있으면 "distance_range": "500" 이런 식으로 값을 추가로 보내야 했다.

• 쿼리를 수정하니 원래 1~2초 단위로 실행되던 api가 15초 이상이 걸렸다.

해결방법

1. 서비스 단에서 계산해서 반환하기

• 쿼리에서 distance를 계산하지 않고, 서비스 단에서 계산하는 것으로 수정했다.

  return stores.stream()
            .map(store -> {
                int distance = store.getDistance();
                int distanceRange = distance <= 250 ? 250 
                              : distance <= 500 ? 500 
                              : distance <= 750 ? 750 
                              : 0;

• 속도에 큰 변화가 없었다.(여전히 10초 대)

2. 시간 측정 추가하기

• 근본적으로 어디 부분에서 시간이 많이 소요되는지를 알아야했다.

  long totalStart = System.currentTimeMillis();
  

long start = System.currentTimeMillis(); List storeIds = findStoreService.메서드명1(변수...); System.out.println("메서드명1: " + (System.currentTimeMillis() - start) + "ms");

start = System.currentTimeMillis(); List storeDetails = findStoreService.메서드명2(변수...); System.out.println("메서드명2: " + (System.currentTimeMillis() - start) + "ms");

System.out.println("Total time: " + (System.currentTimeMillis() - totalStart) + "ms");

이런 식으로 실제 시간을 측정하는 로그를 추가했다.
이 방법으로 서비스 단에서 객체 변환이 아닌 DB 조회가 오래 걸리는 것임을 확인했다. (객체 변환에서는 2ms 정도밖에 소요되지 않았다.)


## 3. 쿼리 개선
### 3-1) CTE 절에서 조건 추가하여 전부 스캔하지 않도록 변경
- CTE 절에서 모든 건수를 조회하지 않도록 조건을 추가했다.
```sql
-- 원래 사용하던 CTE절
WITH menu_counts AS (
    SELECT store_id, COUNT(*) AS cnt
    FROM menu
    WHERE represent = 'Y'  -- 전체 menu 테이블 스캔!
    GROUP BY store_id
)

-- 개선한 CTE 절
WITH menu_counts AS (
    SELECT store_id, COUNT(*) AS cnt
    FROM menu
    WHERE represent = 'Y'
      AND store_id IN (N개)  -- 해당하는 N개만 조회
    GROUP BY store_id
)

3-2) 불필요한 서브쿼리를 직접 JOIN으로 수정

• store 테이블을 2번 조회 (메인 쿼리 + 서브쿼리) 하던 것을 직접 JOIN으로 바꾸어 한번만 조회하도록 수정했다.

  LEFT JOIN
    (SELECT st.store_id, f.type1, f.food_type_id
     FROM store st
     JOIN food_type f ON st.category = f.type2
     WHERE st.store_id IN (N개)  -- store 테이블 또 조회
    ) f ON s.store_id = f.store_id
  
  

LEFT JOIN food_type f ON s.category = f.type2 -- 직접 JOIN

-> 2초대로 줄었다.

## 4. 인덱스 추가
- 가게 테이블의 가게 PK
- 메뉴 테이블의 가게 FK
- 방송 테이블의 가게 FK
- 음식 타입 테이블의 타입 ID
- ... 등 JOIN 이나 WHERE 에서 자주 쓰일 컬럼에 인덱스를 추가하였다.
- 인덱스가 없으면 `TABLE FULL SCAN`이 일어나 데이터 조회에 많은 시간이 소요될 수 있다.
> 가게를 조회할 때 마다, 메뉴/방송/가게/음식 타입 테이블을 전부 조회한다.  

```sql
-- 인덱스가 있는지 확인하고 없으면 만든다.
CREATE INDEX IF NOT EXISTS idx_store_id ON store(store_id);

-- 인덱스가 있는지만 확인한다.
SELECT indexname, indexdef 
FROM pg_indexes 
WHERE tablename = 'store';

-> 실행시간이 30ms 대로 줄었다.

5. 쿼리 개선2

다른 메서드에서도 병목현상으로 3초 정도로 실행되고 있어서 쿼리를 개선했다.

5-1) 현재 상황

• 가게 영업시간 테이블에 저장된 값이 시간만 들어가 있거나 정기 휴무<이런 식으로 텍스트가 들어가 있는경우도 있었다. (매일 달라지는 시간을 어떻게 관리하는게 좋을지 모르겠어서 이렇게 시작했으나 더 좋은 방법이 있다면 알려주실 분...)

• where 절에서 영업시간이 텍스트인 행들을 먼저 필터링 했어도 PostgreSQL 옵티마이저가 실행 순서를 바꿔서 hh24:mi 부분에서 에러가 났었던 적이 있었다.

5-2) 문제점1. 3개의 중첩된 EXISTS = 테이블을 3번 스캔

• 그래서 텍스트인 행들을 필터링 하겠다고 테이블들을 반복해서 접근 하고 있었다.

  SELECT DISTINCT bh.store_id
  FROM business_hours bh
  WHERE ...
  AND EXISTS (
      SELECT 1 FROM business_hours bh2  -- 1번째 스캔
      WHERE bh2.store_id = bh.store_id
      AND bh2.business_type = 'O0001'
      ...
  )
  AND EXISTS (
      SELECT 1 FROM business_hours bh3, bh4  -- 2번째, 3번째 스캔
      WHERE bh3.store_id = bh.store_id
      AND bh4.store_id = bh.store_id
      ...
  )

5-3) 문제점2. 동적 컬럼명 (${currentDay}) - 인덱스 활용 불가

• 요일별로 동적인 컬럼명을 사용하고 있었는데 이 부분에서 인덱스 활용이 불가했다.

  WHERE bh2.${currentDay} IS NOT NULL  -- currentDay = 'mon', 'tue' 등

  5-4) 문제점3. LIKE 패턴 검색 - 인덱스 활용 불가

  WHERE bh2.${currentDay}::text NOT LIKE '%휴무%'

• %휴무%는 앞뒤에 와일드카드가 있어서 인덱스가 있어도 전체 스캔이 필요하다.

5-5) 해결책1. CTE로 한번에 조회하여 해결

WITH valid_stores AS (
    -- 폐업하지 않은 store만 먼저 필터링
),
dinner_hours AS (
    SELECT 
        store_id,
        MAX(CASE WHEN business_type = 'O0001' THEN ${currentDay} END) as open_time,
        MAX(CASE WHEN business_type = 'C0001' THEN ${currentDay} END) as close_time
    FROM business_hours
    WHERE store_id IN (SELECT store_id FROM valid_stores)
      AND business_type IN ('O0001', 'C0001')
      AND ${currentDay} IS NOT NULL
      AND ${currentDay} NOT IN ('휴무', '정기휴무', '')
    GROUP BY store_id  -- 핵심: 한 번에 집계!
)

• CTE절을 사용하여 1번의 조회로 모든 테이블을 가져오도록 수정했다.
• GROUP BY로 각 store의 open_time, close_time을 메모리에서 집계하고 있다.

5-6) 해결책2. CTE절 내에서 CASE 문으로 데이터 피봇

MAX(CASE WHEN business_type = 'O0001' THEN ${currentDay} END) as open_time,
MAX(CASE WHEN business_type = 'C0001' THEN ${currentDay} END) as close_time

## 개선 전:
-- O0001 찾기 위해 테이블 스캔
SELECT ... WHERE business_type = 'O0001'
-- C0001 찾기 위해 또 테이블 스캔  
SELECT ... WHERE business_type = 'C0001'

### 개선 후:
-- 한 번에 가져와서 메모리에서 분리
CASE WHEN business_type = 'O0001' THEN ... 
CASE WHEN business_type = 'C0001' THEN ...

5-7) 해결책3. CTE절 내에서 휴무 조건을 한번에 필터링

## 개선 전 :
EXISTS (
    SELECT 1 FROM business_hours bh2
    WHERE ... AND bh2.${currentDay} NOT LIKE '%휴무%'
)
-- 각 store마다 반복 검사!

## 개선 후 :
WHERE business_type IN ('O0001', 'C0001')
  AND ${currentDay} IS NOT NULL
  AND ${currentDay} NOT IN ('휴무', '정기휴무', '')
  AND ${currentDay}::text NOT LIKE '%휴무%'
-- 한 번만 검사!

6. 쿼리 개선3

6-1) 문제점 1. 인덱스 사용이 불가한ST_DistanceSphere

WHERE ST_DistanceSphere(location, ST_GeomFromText(...)) <= 750

• GIST 인덱스는 공간 범위 검색에 최적화되어 있다.
• 그러나 ST_DistanceSphere는 함수 실행 결과를 비교한다.
• 그러므로 PostgreSQL은 함수 실행 결과를 비교하려면 전체 스캔을 하게된다.

6-2) 해결책 1. ST_DWithin으로 공간 인덱스 직접 활용

WHERE ST_DWithin(
    s.location::geography,
    ST_SetSRID(ST_MakePoint(#{currentLong}, #{currentLat}), 4326)::geography,
    750
)

6-3) GIST 인덱스의 작동 원리

GIST (Generalized Search Tree):

• 범위 기반 또는 위치 기반 검색에 최적화된 트리 구조이다.
• 데이터의 일부만 빠르게 필터링하여 검색 시간을 단축하는 트리 구조를 구축할 수 있다.
• 공간 데이터를 직사각형으로 묶어 그룹화하여 데이터를 구성한다. 이를 MBR(Minimum Bounding Region) (최소 경계 영역)이라고 한다.
• 직사각형의 좌표를 알기 때문에 검색하려는 지점이 특정 그룹 내에 있는지 쉽게 확인할 수 있다.

6-4) geography 타입 -> geometry 타입

• geometry는 평면 좌표계 계산용
• geography는 지구 표면(위/경도) 기반 계산용으로, 보통 위도/경도 데이터를 다룰 때 더 적합하다.

## 원래 (geometry):
sqlST_DistanceSphere(location, ST_GeomFromText(...))
-- geometry 타입, 거리는 "도" 단위 → 미터로 변환 필요

## 개선 (geography):
sqlST_DWithin(s.location::geography, ...::geography, 750)
-- geography 타입, 거리가 바로 "미터" 단위

-- geometry: 1도 ≈ 111km (위도에 따라 다름)
WHERE ST_Distance(location, point) <= 0.0067  -- 750m를 도로 변환?

-- geography: 직관적!
WHERE ST_DWithin(location, point, 750)  -- 750미터

출처

ServBay에서 PostGIS 사용하기: PostgreSQL에 공간 기능 추가 [Postgresql] Gist 인덱스란?

서버 옮기면서 CORS 에러가 또 발생했다.. https://velog.io/@peace_e/Spring-boot-CORS-해결하기 ↑ 이전에 스프링부트 수정하여 해결했던 건은 여기 참고

CORS 요청의 종류와 테스트 방법에 대해 정리하고자 한다.

CORS 요청의 종류

1. Simple Request (단순 요청)

다음 조건을 모두 만족하면 preflight 없이 바로 실제 요청을 보낸다

메서드: GET, POST, HEAD 중 하나 헤더: Accept, Accept-Language, Content-Language, Content-Type 등 기본 헤더만 Content-Type: application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나

2. Preflight Request (사전 요청)

단순 요청에 해당하지 않으면 Preflight(OPTIONS) 요청을 먼저 보낸다.

메서드: PUT, DELETE, PATCH 등 커스텀 헤더: Authorization, X-Custom-Header 등 Content-Type: application/json 등

예비 요청으로 OPTIONS 메서드를 보내서 이 요청이 안전한지 판단한 후, 단순 요청을 요청한다.

Access-Control-Allow / Access-Control-Request 헤더

1. Access-Control-Allow-* 헤더

• 서버가 응답할 때 포함하는 헤더
• 모든 CORS 요청의 응답에 포함되어야 함

Simple Request(단순 요청)의 응답 ✅ Preflight Request(OPTIONS)의 응답 ✅ Preflight 이후 실제 요청의 응답 ✅

2. Access-Control-Request-* 헤더

• 브라우저(클라이언트)가 요청할 때 포함하는 헤더

Preflight Request(OPTIONS)에만 포함됨 ✅ 실제 요청(POST, GET 등)에는 포함 안 됨 ❌

CURL 명령어로 테스트하기

curl -i

curl -i "https://URL..." \
  -H "Content-Type: application/json" \
  -H "Origin: http://localhost:3000" \

CURL 요청은 메서드 지정하지 않을 시, 기본적으로 GET 요청이다.

※ 단, -d (또는 --data) 옵션을 사용하면 자동으로 POST 요청이 된다. 아래 두 요청은 동일한 POST 요청이다.

curl -i -X POST

curl -i "https://URL..." \
  -H "Content-Type: application/json" \
  -H "Origin: http://localhost:3000" \
  -d '{"test":"test1234"}'

curl -i -X POST "https://URL..." \
  -H "Content-Type: application/json" \
  -H "Origin: http://localhost:3000" \
  -d '{"test":"test1234"}'

curl -i -X OPTIONS

Preflight 요청을 테스트하고 싶다면 OPTIONS 메서드를 써야한다.

curl -i -X OPTIONS "https://144.24.86.170.nip.io/api/user/login" \
  -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

응답반환

성공적이라면 이런 응답을 받게 될 것이다.

HTTP/2 200
access-control-allow-credentials: true
access-control-allow-origin: http://localhost:3000
Date: Tue, 27 Jan 2026 15:01:02 GMT
...

여기서 Date의 경우 HTTP 프로토콜 표준(RFC 7231)에 따라서, Date 헤더는 반드시 GMT(UTC) 형식으로 표시된다. 이는 서버의 타임존 설정과 무관하다.

내가 겪은 상황

• CURL로 테스트했을 때, response 가 호출되고 있어서 정상적으로 되는 줄 알았다.
• 그러나 OPTIONS 요청에는 Access-Control-Allow-Origin 헤더에 http://localhost:3000이 있었지만
• POST 요청에는 Access-Control-Allow-Origin 헤더가 없었다.

해결방법

• setAllowedOrigins 대신 SetAllowedOriginPatterns 메서드로 바꿨다. (setAllowCredentials(true) 와 사용할 때 좀 더 안정적이라고 함.)
• setAllowedHeaders(Arrays.asList("*") 로 단순화하였다.

pg_dump -h ${RDS ENDPOINT} -U ${DB유저명} -d ${DB명} -Fc -f ${DUMP 파일명}

\ (역슬래시)를 사용해서 엔터를 칠 수도 있다. \를 사용하는 경우에는 한줄로 입력하면 제대로 인식이 안될 수도 있으니 주의

pg_dump \
 -h ${RDS ENDPOINT} \ 
 -U ${DB유저명} \ 
 -d ${DB명} \
 -Fc \
 -f ${DUMP 파일명}

역슬래쉬 사용하여 한 줄로 입력 시 pg_dump: error: too many command-line arguments ...

삽질의 기록

1. pg_dump

실제 DB 인스턴스에 깔려있는 PostgreSQL의 버전이 덤프를 뜰 인스턴스에 깔려있는 PostgreSQL의 버전보다 높거나 같아야한다. (당연하지만...)

기존 서버를 구현할 때, 서버에 PostgreSQL을 설치를 안하고, 로컬 DB로만 붙어서 모든 걸 하다보니 나중에 덤프를 뜰 때 굉장히 곤란한 상황이 발생했다.. PostgreSQL16을 쓰고 있었는데, Amazon-Linux23에는 PostgreSQL16버전이 없었다.(못 찾았음)

sudo dnf install postgresql16 # -> X
## postgresql16을 찾을 수 없다고 뜬다.

sudo dnf install postgresql15 # -> O
## 15버전까지는 가능하다.

sudo dnf search postgresql 
## 이 명령어로 설치 가능한 postgresql을 찾을 수 있다.

Linux 23 에서 PostgreSQL16 설치 시도

그래서 PGDG(RHEL용 PostgreSQL 공식 repo)를 그대로 설치하려고 했는데

Amazon-Linux23는 RHEL/CentOS 호환이 아니라서

• /etc/redhat-release 파일이 없다
• 그래서 PGDG 를 그대로 설치하면 깨진다

• AL2023에서는 PGDG repo 방식이 공식적으로 지원되지 않았다..

그래서 Docker로 우회하여 PostgreSQL16을 설치했다.

Ubuntu 에서 PostgreSQL16 설치 시도

# https://www.postgresql.org/download/linux/ubuntu/ 
# 공식 문서 참고
sudo apt install postgresql-16 # -> O

Docker를 사용한 dump 명령문

dump를 뜰 서버 인스턴스에서 실행

docker run --rm \
  -v "$PWD:/work" \
  -e PGPASSWORD='DB비밀번호' \
  postgres:16 \
  pg_dump \
    -h ${RDS의 ENDPOINT} \
    -U ${유저명} \
    -d ${DB명} \
    -Fc \
    -f /work/${덤프파일명} ## 출력 파일 경로

$PWD: 현재 작업 디렉토리 (Present Working Directory) /work: Docker 컨테이너 내부의 경로 :로 연결하여 호스트와 컨테이너를 연결

덤프 생성 후에는

ls -lh ${덤프파일명}

으로 파일이 제대로 생성되었는지 반드시 확인하자 (파일 용량이 0kb라면 제대로 생성되지 않은 것)

구 app 서버 -> 로컬 -> 신 app 서버 순으로 dump 파일을 옮겨준다.

내려받은 로컬에서 실행

scp -i [SSH키파일] [원본] [대상] ## 기본 구조

scp -i "C:/Users/.ssh/이전서버.key" ec2-user@[PUBLIC IP]:/home/ec2-user/[DUMP파일명] .

키파일 경로는 ""로 감싸준다. . : 현재 디렉토리

• ec2-user 및 ip에는 dump 파일이 존재하는 서버 인스턴스의 유저네임과 ip를 작성한다.
• 현재 로컬 디렉토리에 dump 파일이 복사된다.

로컬에 잘 복사되었다면 아래 명령어를 실행하여 덤프 파일이 필요한 서버에 다시 옮긴다.

scp -i "C:/Users/.ssh/현재서버.key" [DUMP파일명] ubuntu@[PUBLIC IP]:/home/ubuntu/

2. pg_restore

dump 파일이 준비가 되었으면, 파일을 토대로 restore를 해야한다.

단, postgis를 사용하고 있는 DB를 옮기는 경우 restore할 서버인스턴스에서도 postgis를 사용해야만 정상적으로 restore가 된다.

pg_restore: error: could not execute query: ERROR: could not open extension control file . .. No such file or directory Command was: CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA ...; pg_restore: error: could not execute query: ERROR: extension "postgis" does not exist Command was: COMMENT ON EXTENSION postgis IS 'PostGIS geometry and geography spatial types and functions';

sudo -i -u postgres psql -d [DB명] -c "CREATE EXTENSION IF NOT EXISTS postgis;"

sudo -i -u postgres psql -d [DB명] -c "SELECT postgis_full_version();" # 확인 쿼리

postgis가 설치되어있지 않다면 해당 DB에 설치를 postgres 유저로 진행한다.(PostgreSQL 설치 시 자동으로 생성되는 슈퍼유저(superuser))

  pg_restore \
    -h 10.0.0.114 \
    -U nnzz_user \
    -d nnzz \
    --clean \
    --if-exists \
    --no-owner \
    --no-privileges \
    /work/[dump파일명]

정리

pg_dump: 백업 명령어

데이터베이스를 파일로 저장하는 명령어 기본 구조

pg_dump [옵션] -d 데이터베이스명 -f 출력파일명

주요 옵션 1. 출력 형식 (-F) bash# 커스텀 포맷 (압축됨, 가장 많이 쓰임)

pg_dump -U postgres -d [db명] -Fc -f backup.dump

SQL 텍스트 포맷 (읽을 수 있음)

pg_dump -U postgres -d [db명] -Fp -f backup.sql

tar 포맷

pg_dump -U postgres -d [db명] -Ft -f backup.tar

2. 데이터만 / 스키마만 bash# 데이터만 백업 (테이블 구조 제외)

pg_dump -U postgres -d [db명] --data-only -f data.dump

스키마만 백업 (데이터 제외)

pg_dump -U postgres -d [db명] --schema-only -f schema.dump

3. 특정 테이블만 bash# users 테이블만 백업

pg_dump -U postgres -d [db명] -t users -f users_backup.dump

여러 테이블

pg_dump -U postgres -d [db명] -t users -t orders -f tables_backup.dump

pg_restore: 복구 명령어

커스텀 포맷(-Fc)으로 백업한 파일을 복구하는 명령어 기본 구조

bashpg_restore [옵션] -d 데이터베이스명 백업파일

주요 옵션 1. 기본 복구 bash# 전체 복구

pg_restore -U postgres -d nnzz backup.dump

2. 클린 복구 (기존 데이터 삭제 후 복구) bash# 기존 객체 삭제 후 복구

pg_restore -U postgres -d nnzz --clean backup.dump

데이터베이스까지 새로 생성

pg_restore -U postgres -d nnzz --clean --create backup.dump

3. 특정 테이블만 복구 bash# users 테이블만 복구

pg_restore -U postgres -d nnzz -t users backup.dump

4. 병렬 처리 (빠른 복구) bash# 4개의 작업을 동시에 실행

pg_restore -U postgres -d nnzz -j 4 backup.dump

https://velog.io/@peace_e/SSH-config-파일-여러-개-사용하기 위 내용에서 이어집니다. OCI 계정을 발급받고 인스턴스 두 개를 만든 이후의 상황을 전제로 하고 있으며, SSH 접속 설정을 끝내고 접속이 성공적으로 되어야 합니다.

1. 기본 세팅

업그레이드 및 timezone 설정

sudo apt update && sudo apt upgrade -y
sudo timedatectl set-timezone Asia/Seoul

기본사항 체크하기

git --version
curl --version

DB서버에서 PostgreSQL 설치 + APP 서버에서 PostgreSQL 명령어만 동작 가능하게 설치 진행중인 프로젝트의 DB가 PostgreSQL이다.

sudo apt install -y postgresql <- db 서버
sudo apt install -y postgresql-client <- app 서버
psql --version <- 버전 확인용

** db 유저 생성 및 권한 부여 **

sudo -i -u postgres psql -- 로컬접속

CREATE USER ${유저명} WITH PASSWORD '비밀번호'; -- 유저 생성

CREATE DATABASE ${db명} OWNER ${유저명}; -- db 생성


GRANT ALL PRIVILEGES ON DATABASE ${db명} TO ${유저명}; -- 권한부여
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO ${유저명};
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO ${유저명};

2. VCN 설정 및 OS 방화벽

OCI Ubuntu 서버는 오라클 클라우드 방화벽(VCN)과 Ubuntu OS 내부 방화벽 두 가지를 전부 설정해야 비로소 외부에서 접근할 수 있다.

2-1. VCN 설정

OCI는 국내에 사용하는 케이스가 많이 없어서 찾는데 애를 먹었다. 왼쪽 햄버거 메뉴 클릭 > Networking > Virtual cloud networks 여기서 VCN 목록이 아무것도 없다면 Create VCN 버튼을 클릭하여 새롭게 VCN을 만들어준다.

생성한 VCN을 클릭 > ** Security 탭 **

Security 탭의 Security List 및 Network Security Groups(NSG) 생성

생성했으면 각각 5432(PostgreSQL) 포트를 열어준다. Security List

Network Security

2-2. OS 방화벽

OCI에서는 Ubuntu OS의 경우, UFW(Uncomplicated Firewall)을 사용하지 않을 것을 권장한다.

/etc/iptables/rules.v4 파일을 수정하여 방화벽 권한을 제어할 수 있다.

Ubuntu 인스턴스가 UFW를 활성화한 이후 재부팅에 실패합니다. ... 해결 방법 방화벽 규칙을 수정하기 위해 UFW를 사용하지 마세요. 플랫폼 이미지는 인스턴스가 인스턴스의 부팅 및 블록 볼륨에 나가는 연결을 할 수 있도록 방화벽 규칙으로 미리 구성되어 있습니다. 자세한 내용은 필수 방화벽 규칙을 참조하십시오. UFW는 재부팅하는 동안 인스턴스가 부팅 및 블록 볼륨에 연결할 수 없도록 이러한 규칙을 제거할 수 있습니다. 방화벽 규칙을 수정하거나 새로 만들기 위해선, 대신 /etc/iptables/rules.v4 파일을 업데이트하세요. 여기에 수정된 방화벽 규칙은 재부팅 이후 적용될 것입니다. 규칙을 즉시 적용하기 위해서는 다음을 실행하세요:

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

nano 명령어를 사용해서 etc/iptables/rules.v4 파일을 수정했다.

sudo nano /etc/iptables/rules.v4

※ 자주 쓴 명령어

5432 포트를 허용하도록 설정했다.

-A INPUT -s ${허용해줄 ip} -p tcp -m tcp --dport 5432 -j ACCEPT

설정하고 즉시 적용되도록 저장한다.

sudo -i && iptables-restore < /etc/iptables/rules.v4

테스트를 위해 db 서버를 재시작했다. (재시작 시 iptables 설정이 초기화 되는 경우가 있음. 제대로 저장 된 건지 확인용)

sudo reboot

방화벽 설정이 제대로 적용되지 않았다면, app 서버에서 아래 명령어를 실행했을 때 db 서버에 접근할 수가 없다.

nc -zv ${db서버의 private ip} 5432

No route to host 또는 connection refused -> 연결 실패 X Connection to ... port ... succeeded! -> 연결 성공 O

succeeded 가 떴다면 app 서버에서 db 유저명과 db명을 넣어서 제대로 조회해보자.

psql -h ${db서버의 private ip} -U ${db 유저명} -d ${db명}

비밀번호를 입력하라고 뜬다면 설정해준 비밀번호를 입력하고

Password for user ${db 유저명}: 

성공적으로 db 연결 시 ubuntu 버전 및 Type "help" for help.가 표시된다.

3. 로컬 DBeaver에 db 서버 연결하기

Main 탭에서 DB 서버 기본 설정 SSH 탭에서 APP 서버 설정

test connection 시도 -> 연결 되는 지 확인 필요

참고 https://velog.io/@doubledeltas/OCI-서버가-잘-열렸는데-외부에서-접속이-안될-때

chmod 600 #{키 파일 경로}

600 : 파일 소유자만 읽기/쓰기가 가능하고, 그룹 및 다른 사용자는 접근할 수 없도록

이전에 사용하던 AWS 서버와, 새롭게 사용할 OCI 서버의 config 를 분리하고 싶었다.

• 메인 config 파일의 경로는 반드시 ~/.ssh/config 여야 한다.

0. 디렉터리 구조

~/.ssh/
 ├─ config          ← 메인 (Include만 있음)
 ├─ config_aws      ← aws 서버 config
 ├─ config_oci      ← oci 서버 config
 ├─ AWS KEY/        ← aws 서버 키가 저장된 폴더
 ├─ OCI KEY/        ← oci 서버 키가 저장된 폴더

각 서버당 config 파일을 별개로 작성하고 싶어서 이런 구조를 선택하게 되었다.

1. Include 사용

~/.ssh/config 수정하기

Include config_*

해당 디렉터리에서 이름이 config_ 로 시작하는 모든 파일을 읽으라는 명령이다.

2. 인스턴스 별 config 추가하기

2-1. ~/.ssh/config_aws aws 서버는 linux로 생성하여서 User가 ec2-user이다.

Host #{설정하고싶은 호스트명 작성}
  HostName #{각 public IP}
  User ec2-user
  IdentityFile ~/.ssh/AWS\ KEY/...key ← 키 파일 경로 

2-2. ~/.ssh/config_oci oci 서버는 ubuntu로 생성하여서 User가 ubuntu이다.

Host #{설정하고싶은 호스트명 작성}
  HostName #{각 public IP}
  User ubuntu
  IdentityFile ~/.ssh/OCI\ KEY/...key ← 키 파일 경로 

경로에 띄어쓰기가 포함된 경우에는 ** \ (역슬래쉬) ** 가 들어가야 한다. 되도록이면 경로에는 한글 또는 띄어쓰기를 안 쓰는 것을 추천한다.

2-3. ~/.ssh/config_oci_db 오라클 클라우드는 서버 인스턴스와 db 인스턴스를 분리했다. 그래서 각 인스턴스에 접근하기 위해서는 key 파일이 별도로 필요하다.

서버 인스턴스에는 public ip를 붙여주었지만, db 인스턴스는 외부에서 접속할 필요가 없으므로 서버 인스턴스를 통해서 접근하도록 설정했다. ※ 이 때, 반드시 서버 인스턴스와 db 인스턴스의 VCN이 같아야한다.

ProxyJump란 ?

• 중간 서버를 통해서 remote로 ssh에 연결할 수 있는 기능이다.
• 사용하면 두 번 연결을 하지 않아도 된다.
• ** 접속시 사용하는 IdentityFile 은 둘 다 Local 에 있어야 한다! **
• ProxyJump 는 아래처럼 작성할 수 있다.

Host oci-db
  HostName #{각 public IP}
  User ubuntu
  IdentityFile ~/.ssh/OCI\ KEY/...key ← 키 파일 경로
  ProxyJump #{서버 인스턴스의 호스트명}

위처럼 작성한 경우, ssh oci-db 로 한 번에 db 서버에 접속할 수 있다.

3. ssh 접속하기

ssh + #{등록한 호스트명} 으로 간단하게 접속할 수 있다.

사플 서버를 재부팅하면서 기존의 yml파일을 수정했었다. 그 이후로 3달 만에 새롭게 프로젝트를 커밋했더니 ci/cd에 실패했다.

원래 길어봐야 2분 안으로 완료되던 ci/cd가 10분이 넘어도 완료되지 못했다. SSH Action 기본 타임아웃은 10분이기에 Pull이 10분 넘게 오래 걸리면 Action이 실패하는 것이다.

원인

yml 파일을 수정하면서 CD 부분에 아래를 추가했었다.

sudo docker system prune -f

prune 란?

prune은 사용하지 않는 리소스를 삭제하는 명령어이다.

사용하지 않는 리소스의 기준

• 모든 멈춰있는 컨테이너
• 최소 한 개의 컨테이너에서 사용되지 않는 네트워크
• dangling(매달려있지 않은) 이미지
• dangling 빌드 캐시

prune은 볼륨을 삭제하지 않는다!

sudo docker system prune

prune 명령어를 사용하게 되면 기본적으로 진짜 정리할거냐는 경고 메세지가 뜬다. 그만큼 prune 명령어는 조심스럽게 사용해야한다. 그럼에도 삭제하길 원한다면 y를 입력하면 삭제가 진행된다.

※ -f를 붙이게 되면 확인 메세지 없이 강제로 실행하겠다는 뜻이다. ※ -af를 붙이게 되면 -a = -all dangling 이미지 뿐만 아니라 태그가 붙었지만 현재 어떤 컨테이너에서도 사용되지 않는 모든 이미지를 확인 메세지 없이 강제로 실행한다.

해결 방안

사용하지 않는 리소스들을 ci/cd 때마다 관리하면 좋을 것 같아서 추가한 부분이었다. prune은 그대로 유지를 하고 싶어서 이를 nohup을 사용하여 백그라운드로 돌리는 방향으로 수정하였다.

yml 파일 수정 후 ci/cd가 정상적으로 이루어진 모습이다.

1. 터미널에서 연동 중인 repo 확인

git remote -v

pycharm 내에 터미널을 열어서 위 명령어를 입력한다. 연동 중인 repo의 alias를 확인한다.

2. 연동 중인 repo를 해제

git remote remove 레포지토리명

레포지토리명에 아까 확인한 alias를 넣어주면 된다. 위처럼 명령어를 입력하여 연동 중인 레포지토리를 해제한다.

3. 연동 해제되었는지 다시 확인

git remote -v

연동 중인 repo를 다시 확인한다. 아래처럼 해제하지 않은 레포지토리만 보인다면 정상적으로 연동 해제된 것이다.

ERROR 상황

서버를 재부팅했더니 잘 되던 api들이 502 Bad Gateway가 발생했다. 502는 다른 서버로부터 유효한 응답을 받지 못했을 때, 발생한다.

github actions 와 docker를 사용해서 올려놨었는데, 컨테이너가 중단되어 있는게 아닐까 싶어서 아래의 명령어로 확인해보았다.

$ sudo docker ps -a

8일 전에 만들어진 컨테이너가 Exited 상태인 것을 확인할 수 있었다.

컨테이너 재시작하기

$ sudo docker restart {컨테이너 id}

restart 명령어를 사용하여 컨테이너를 재시작시켰다.

api가 정상적으로 작동되는 것을 확인했으나, CI/CD가 제대로 이루어지지 않았다. CI 단계에서 부터 문제가 생겨서 무한 로딩상태였다.

트러블 슈팅(Gradle 관련)

로그를 확인해보니 Gradle Setup 단계에서 “The operation was canceled” 에러가 발생했다.

Run gradle/actions/setup-gradle@v3 ... Restore Gradle state from cache Error: The operation was canceled.

Setup Gradle이라는 이름의 액션에 gradle/actions/setup-gradle@v3 을 사용하고 있었는데, gradle을 직접 커맨드라인에서 실행하도록 수정했다. 아래처럼 순서대로 명령어만 사용했다.

- name: Make gradlew executable
  run: chmod +x ./gradlew

- name: Build with Gradle
  run: ./gradlew clean build --stacktrace

이 부분 때문에 고민을 많이 했는데, GPT에게 물어봐서 해결했다..

※ gradle/actions/setup-gradle

• Gradle 환경 세팅과 캐싱을 자동으로 해준다.
• 그러나, 내부에서 네트워크 문제, 캐시 복원 문제, 혹은 환경 문제가 생기면 실패할 수 있다.

※ ./gradlew를 직접 실행

• Gradle Wrapper가 이미 repo 안에 포함되어 있다고 가정하기 때문에,
• 별도의 환경 설정 없이도 gradle 빌드가 가능하고,
• 네트워크나 캐시 이슈로부터 자유롭고,
• 단순 명령 실행이라 에러 발생 지점이 명확하다

그래서 yml 파일을 이처럼 수정하였고, 이후 push를 진행했을 때 CI/CD가 정상적으로 진행되었다.

0. shp 파일 구하기

지역정보를 shp 파일은 여러 곳에서 구할 수 있다. 필자는 GEOSERVICE_WEB 을 사용했다. 회원가입하면 코인이 충전되고 코인으로 shp 파일을 구매할 수 있다. 지역구 파일이 필요해서 시/군/구 파일을 다운로드 받았다. 자세한 사용법은 제작자의 블로그를 참고하자

1. postGIS 설치

shp 데이터베이스가 필요한 건 로컬이 아니고, AWS 에 올라가있는 서버였다. SSH로 연결하는 방식인데 postGIS나 qGIS에서 서버를 연결하는 방법을 모르겠어서 로컬에 일단 올리고, DBeaver를 통해서 DDL과 데이터베이스 내용을 서버로 가져오기로 했다.

그러려면 일단 로컬에 postGIS가 설치되어있어야 한다. 로컬에 postgreSQL 17버전이 세팅되어있었는데, postgis 익스텐션이 설치가 안되어있어서 postgis 설치만 다시 진행하려고 했다. 그런데 17 버전에서 postgis 익스텐션을 다운로드하려고 하면 계속 응답없음이 뜨길래 버전을 다운그레이드 하여 진행했다.

기존에 있던 17버전을 싹 지우고 16.7버전을 설치하니, postgis 익스텐션이 다운로드가 잘 되었다.

2. pgAdmin

이 과정은 생략해도 된다. 다들 pgAdmin을 쓰던데 한 번도 안써봐서 사용해봤다. 어차피 shp 파일을 변환해서 넣는 부분은 postGIS로 진행할 거라, 여기서는 새로운 서버를 연결하기만 할 것이다.

Servers -> Register -> server 순으로 진행하여 서버를 등록해준다.

서버를 등록할 때 필요한 정보는 아래와 같다.

• Name : 서버 이름
• Server group : 서버 그룹 설정
• Backgroud, Foregroupd : 색상 지정
• Connect Now : 설정 후 PostgreSQL에 접속
• Comments : 서버 설명

• Host name/address : PostgreSQL 서버의 주소
• Port : 포트 값 (postgreSQL 기본값 : 5432)
• Maintenance databse : 접속할 Database명
• Username : 사용자 이름
• Password : PostgreSQL 비밀번호

제대로 서버를 연결했다면 왼쪽에 이렇게 추가된다. 테이블은 Schemas > public 안에 있다.

※ 참고 이미 postgis 익스텐션이 실행된 상태에서 해당 쿼리를 작성하면 에러가 발생한다. postgis가 가능한 상태이면 spatial_ref_sys 테이블이 이미 생성되어 있을 것이다.

3. postGIS

VIEW CONNECTION DETAILS을 클릭하여 진행한다.

pgAdmin에서 만든 새 서버를 넣었다. shp 파일이 필요한 서버정보를 작성하여 연결한다.

연결이 완료되면 이렇게 뜰 것이다.

shp 파일에 한국어가 포함되어있다면 Options에서 UTF-8을 EUC-KR로 바꿔준다.

Options 설정이 끝났다면 add file을 클릭하여 파일을 추가하고 import를 클릭한다.

※ 참고 dbf file (.dbf) can not be opened. Shapefile import failed. 에러가 발생하면 파일의 경로 중 한글이 포함되어 있는 경로가 있을 수 있다. 필자도 이 에러를 겪었고, 이 경우에는 바탕화면/C 로 파일들을 빼서 해결했다.

SRID(공간 참조 식별자, Spatial Reference Identifier)는 필요시 설정해주는 것이 좋다. 사용한 shp 파일은 5179 좌표계를 사용하고 있다. 그래서 5179 좌표계로 설정하여 import 하였다.

4. DBeaver

import 가 정상적으로 완료되었다면 DBeaver를 비롯한 DB 툴에서도 테이블이 조회될 것이다. (DBeaver가 익숙해서 사용했다. 본인에게 맞는 툴을 사용하면 된다.)

gid : 지역구 인덱스 sig_cd : 지역구 아이디 sig_eng_nm : 지역구 영문명 sig_kor_nm : 지역구 한글명 geom : 지역구 범위 (Multipolygon, 5179)

제대로 테이블이 들어왔음을 확인했으면, 값을 실 사용하기 전에 중요한 과정이 남았다. 이 테이블은 5179좌표계를 사용하고 있으므로 필요한 좌표계가 다르다면 그에 맞춰 수정을 해줘야한다.

진행중인 프로젝트는 4326 좌표계를 필요로 했다. 좌표계 변경에 앞서 아래의 쿼리로 테스트를 했다.

SELECT ST_AsText(ST_Transform(ST_PointOnSurface(geom), 4326)) as transformed_coord,
       ST_AsText(ST_PointOnSurface(geom)) as original_coord
FROM sig_5179 LIMIT 1;

ST_PointOnSurface : 범위의 중앙점을 반환한다. ST_AsText : 지오메트리 값을 매개변수로 받으면 텍스트로 반환한다. ST_Transform(좌표, 좌표계) : 지오메트리 값을 특정 좌표계로 변환한다.

실행 결과가 이렇게 나왔다. 얼추 맞게 변환된듯 하다.

ST_Transform() 함수가 제대로 동작하는 걸 확인했으니 원래 테이블을 복사해서 4326 좌표계로 변환할 것이다.

-- 1. 기존 테이블 이름 변경 (백업용)
ALTER TABLE public.sig RENAME TO sig_5179;

-- 2. 새로운 테이블 생성 (EPSG:4326 좌표계 사용)
CREATE TABLE public.sig (
    gid serial4 NOT NULL,
    sig_cd varchar(5) NULL,
    sig_eng_nm varchar(40) NULL,
    sig_kor_nm varchar(40) NULL,
    geom public.geometry(multipolygon, 4326) NULL,
    CONSTRAINT sig_pkey2 PRIMARY KEY (gid)
);

-- 3. 데이터 변환하여 복사
INSERT INTO public.sig (sig_cd, sig_eng_nm, sig_kor_nm, geom)
SELECT sig_cd, sig_eng_nm, sig_kor_nm, ST_Transform(geom, 4326)
FROM sig_5179;

-- 4. 공간 인덱스 생성
CREATE INDEX sig_geom_idx2 ON public.sig USING gist (geom);

1. 기존 테이블 이름을 5179로 변경하고 4326좌표계를 사용하는 새로운 테이블을 생성했다.(구조는 같음)
2. 그리고 기존 테이블의 데이터를 ST_Transform() 함수를 사용해서 4326 좌표계로 변환하여 그대로 복사했다.
3. 공간 인덱스도 빠트리지 않고 똑같이 생성해주었다.

※ 참고 Multipolygon 타입은 이런 식으로 값이 들어가는데 굉장히 길기 때문에 DBeaver에서 컬럼값을 전부 명시해주는 INSERT 문을 복사해서 사용하지 않길 바란다. 무조건 렉이 걸린다.

MULTIPOLYGON (((956615.4532424484 1953567.1989686124, 956621.5787365452 1953565.2711694315, .... )))

5. 지역구 계산하는 쿼리 작성

유저의 위치가 특정 지역구에 속하는 경우에만 서비스 이용이 가능하게끔 제한해야했다. 그래서 쿼리를 아래와 같이 작성했다.

SELECT EXISTS (
    SELECT 1
    FROM sig
    WHERE (sig_cd = '11650' or sig_cd = '11680' or sig_cd = '11710' or sig_cd = '11740')
    and ST_Contains(geom, ST_SetSRID(ST_MakePoint(127.02800140627488, 37.49808633653005), 4326))
);

ST_MakePoint : x좌표, y좌표를 매개변수로 넣으면 공간 데이터로 반환한다. ST_SetSRID : 공간데이터에 원하는 좌표계값을 넣어준다. ST_Contains : 한 지오메트리가 다른 지오메트리에 완전히 포함되는지를 확인한다.

sig_cd값에 원하는 지역구를 넣었다. 필요한 sig_cd 조건을 or 로 연결하고 있으므로 괄호를 작성해주어야 한다. 그렇지 않으면 and 가 먼저 실행되어 다른 값이 나오게 되므로 유의하자.

지난 글에서 AWS EC2 서버를 만들고, RDS 와 연결하는 과정까지 진행했다. 개발 중인 Spring boot 프로젝트를 EC2 서버에서 실행시켜보자.

FileZila로 .jar 파일 직접 전달하기

서버에서 프로젝트를 직접 배포하는 것은 크게 두 가지가 있다.

1. 서버에서 git 레포지토리를 clone 하여 build 하는 방법
2. 서버에 jar파일을 직접 전달하는 방법

나는 이미 FileZila를 쓰고 있었기 때문에, jar 파일을 직접 전달하는 방법을 선택했다.

FileZila 사용자의 PC와 호스팅 서버 간 파일 송수신을 위한 위한 FTP(File Transfer Protocol) 소프트웨어

FileZila Client 는 여기서 다운받을 수 있다. https://filezilla-project.org/download.php?type=client

다운받은 FileZila를 실행하고 버튼을 클릭해서 EC2 서버와 연결한다.

1. 프로토콜 : SFTP - SSH File Transfer Protocol 선택
2. 호스트 : EC2의 퍼블릭 IPv4 주소 입력
3. 포트 : 비워도 된다
4. 로그온 유형 : 키 파일 선택
5. 사용자 : 사용자 이름 입력 (linux 서버의 경우 : ec2-user, ubuntu 서버의 경우 : ubuntu)
6. 키파일 : 앞서 저장한 .pem 키 파일이 저장된 경로를 선택
7. 연결 선택

정상적으로 연결이 되었다면 왼쪽엔 로컬PC 화면이, 오른쪽에는 FTP 서버가 보일 것이다.

1. Spring boot에서 파일을 빌드 한 후, libs 폴더의 빌드된 jar 파일을 더블클릭한다. (서버의 저장경로로 전송)
2. 전송이 완료되면 오른쪽 FTP 서버 화면에서도 jar 파일이 보인다.

서버에 jar 파일을 제대로 전송해주었다면, 아래처럼 입력해서 jar 파일을 실행한다.

nohup java -jar <프로젝트 이름>-0.0.1-SNAPSHOT.jar &

nohup 은 백그라운드에서 무중단으로 실행하기 위해 사용한다. 마지막에 & 도 붙여주어야 한다. nohup을 사용하지 않으면 bash 창을 닫고 종료할때마다 어플리케이션도 같이 종료된다.

이미 실행중인 어플리케이션을 중지시켜야한다면 아래처럼 입력한다.

ps -ef | grep .jar # 실행중인 .jar 파일을 조회
kill <pid> # 조회한 pid를 입력

이 방법으로 계속 사용했는데, 변경 사항이 생길때마다 종료하고 새로 실행시키는 과정이 매우 번거로웠다. 그리고 github push는 별개로 해주어야하기에 불편했다.

그래서 Docker와 Github Actions를 활용해서 CI/CD 를 구축하기로 했다.

Docker와 Github Actions로 배포하기

도커를 활용한 배포 흐름은 아래와 같다.

1. Dockerfile을 작성하여 build 시 docker image가 생성된다.
2. 생성된 docker image를 docker hub에 push 한다.
3. 서버(ec2)에 docker hub의 docker image를 pull 한다.
4. docker image를 실행시켜 docker container를 생성한다.(어플리케이션은 container 상에서 실행된다.)

이 과정을 자동화 할 것이고, CI/CD 파이프라인 구축에는 Github Actions를 사용할 것이다.

Github Actions Github 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화할 수 있는 도구. 특정한 브랜치에 대한 이벤트(트리거)를 통해 설정된 Workflow를 따라, 빌드, 테스트, 배포 등의 다양한 동작을 자동으로 실행되게 할 수 있다.

Github Actions의 Secrets 관리

프로젝트 레포의 Settings-Security-Secrets and Variables-Actions 경로에서 보안상의 이유로 Github에 올릴 수 없는 환경 변수들을 작성해준다.

등록한 환경변수들은 값을 볼 수 없고, 수정 또는 삭제만 가능하다.

1. APPLICATION : github에 올라가지 않은 application.properties 의 내용
2. AWS_EC2_HOST : EC2 인스턴스의 PUBLIC IP
3. AWS_EC2_KEY : 발급받은 .pem 키 파일
4. DOCKER_USERNAME : Docker Hub 로그인 시 사용하는 username
5. DOCKER_PASSWORD : Docker Hub 로그인 시 사용하는 password

Docker Hub 로그인 시 구글 로그인으로 가입하면 username과 password 만으로는 로그인이 불가능하다. 토큰 방식을 사용해야만 로그인이 가능한 듯 하다.

Workflow 파일 생성

프로젝트 레포의 Actions-New Workflow를 통해 workflow 파일 작성을 위한 양식을 선택할 수 있다.

Java with Gradle을 선택하면 Java-Gradle 환경에서 사용할 수 있는 Workflow 파일의 기본 양식을 보여준다. 이걸로 생성해도 되고, 직접 .github > workflows > 폴더 안에 workflow를 작성해도 된다.

Workflow 파일 작성

아래처럼 작성했다.

# Github Actions 에 표시되는 Workflow 이름
name: NNZZ CI/CD

# master 브랜치로 push, pull request 가 발생하면 workflow 를 실행
on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

permissions:
  contents: read

# workflow 에서 실행할 동작
jobs:
  CI:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # JDK 세팅
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      # gradle caching - 빌드 시간 향상
      - name: Gradle Caching
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

      # application.properties 파일 생성
      - name: Make application.properties
        run: mkdir ./src/main/resources |
          touch ./src/main/resources/application.properties

      - name: Deliver application.properties
        run: echo "${{ secrets.APPLICATION }}" > ./src/main/resources/application.properties

      # Gradle 설정 및 Build
      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v3

      - name: Change gradlew permissions
        run: chmod +x ./gradlew

      - name: Build with Gradle Wrapper
        run: ./gradlew clean build

      - name: List build/libs contents
        run: ls build/libs


      # Docker 로그인
      - name: Docker Login
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Docker 이미지 생성 및 Push
      - name: Docker build & Push
        run: |
          docker build -t ${{ secrets.DOCKER_USERNAME }}/nnzz .
          docker push ${{ secrets.DOCKER_USERNAME }}/nnzz


  CD:
    needs: CI
    runs-on: ubuntu-latest

    steps:
      # EC2 접근 후 docker 이미지 pull & run
      - name: Deploy to EC2 Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.AWS_EC2_HOST }}
          username: ec2-user
          key: ${{ secrets.AWS_EC2_KEY }}
          port: 22
          script: |
            sudo docker pull ${{ secrets.DOCKER_USERNAME }}/nnzz
            sudo docker stop $(sudo docker ps -qa)
            sudo docker rm $(sudo docker ps -qa)
            sudo docker run -d -p 8080:8080 \
            -v /etc/localtime:/etc/localtime:ro \
            -e TZ=Asia/Seoul \
            ${{ secrets.DOCKER_USERNAME }}/nnzz
            sudo docker system prune -f

하나씩 살펴보자.

# Github Actions 에 표시되는 Workflow 이름
name: NNZZ CI/CD

# master 브랜치로 push, pull request 가 발생하면 workflow 를 실행
on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

permissions:
  contents: read

• name : Github Actions에 표시되는 Workflow 이름이다. 자유롭게 설정 가능하다.
• on : Workflow 의 트리거가 될 이벤트를 설정한다. master 브랜치로 push, pull request가 발생하면 workflow를 실행하도록 작성했다.
• permissions: Workflow 작업에 적용되는 권한을 설정한다. 권한에 대한 자세한 사항은 공식문서 참조

jobs:
  CI:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # JDK 세팅
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      # gradle caching - 빌드 시간 향상
      - name: Gradle Caching
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

      # application.properties 파일 생성
      - name: Make application.properties
        run: mkdir ./src/main/resources |
          touch ./src/main/resources/application.properties

      - name: Deliver application.properties
        run: echo "${{ secrets.APPLICATION }}" > ./src/main/resources/application.properties

• jobs : job은 Workflow의 실행 단위이다. 각 job은 다시 step으로 순차적인 실행 단계가 구분된다. CI와 CD로 job을 나누어 작성했다. (job 과 step의 이름은 자유롭게 설정 가능)

• runs-on : Workflow를 실제로 실행하는 서버를 설정한다. GitHub-hosted runner(Github에서 자체적으로 제공)/ Self-hosted runner(사용자가 직접 설정하여 사용) 으로 나뉜다. 여기서는 GitHub-hosted runner를 사용하였다.

• Set up JDK 17 : 프로젝트에서 사용하는 것과 동일한 JDK 17을 사용하도록 설정하였다.

• Gradle Caching : 빌드 시간 향상을 위해 Gradle을 캐싱하도록 했다. 작성하지 않아도 Workflow를 실행하는데 문제는 없다.

• Make application.properties : 프로젝트 레포에서 제외된 application.properties 을 생성한다.

• Deliver application.properties : 생성된 application.properties에 Secrets에 등록한 APPLICATION의 값을 덮어씌운다.

      # Gradle 설정 및 Build
      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v3

      - name: Change gradlew permissions
        run: chmod +x ./gradlew

      - name: Build with Gradle Wrapper
        run: ./gradlew clean build

      - name: List build/libs contents
        run: ls build/libs


      # Docker 로그인
      - name: Docker Login
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # Docker 이미지 생성 및 Push
      - name: Docker build & Push
        run: |
          docker build -t ${{ secrets.DOCKER_USERNAME }}/nnzz .
          docker push ${{ secrets.DOCKER_USERNAME }}/nnzz

• Setup Gradle ~ : Gradle을 설정하고 권한 변경 후 프로젝트를 clean build 한다.
• Docker Login : Secrets에 등록된 DOCKER_USERNAME과 DOCKER_PASSWORD로 Docker에 로그인한다.
• Docker build & Push : Docker Image를 build 하여 생성 후 Docker Hub에 프로젝트를 push한다.

  CD:
    needs: CI
    runs-on: ubuntu-latest

    steps:
      # EC2 접근 후 docker 이미지 pull & run
      - name: Deploy to EC2 Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.AWS_EC2_HOST }}
          username: ec2-user
          key: ${{ secrets.AWS_EC2_KEY }}
          port: 22
          script: |
            sudo docker pull ${{ secrets.DOCKER_USERNAME }}/nnzz
            sudo docker stop $(sudo docker ps -qa)
            sudo docker rm $(sudo docker ps -qa)
            sudo docker run -d -p 8080:8080 \
            -v /etc/localtime:/etc/localtime:ro \
            -e TZ=Asia/Seoul \
            ${{ secrets.DOCKER_USERNAME }}/nnzz
            sudo docker system prune -f

• needs : 적어둔 작업(CI)이 완료된 후 실행된다.
• Deploy to EC2 Server : EC2 서버에서 Docker Image를 pull하여 실행하는 작업을 수행한다.
• uses : 원격 접속을 위해 appleboy 를 사용한다.
• script : Docker Hub에서 최신 Image를 pull 한 후 실행 중인 컨테이너를 중지, 삭제한다. 타임존을 한국시간대로 설정하여 image를 run하여 컨테이너를 실행시킨다. 마지막으로 불필요한 오래된 image는 삭제한다.

Docker 설치

윈도우 10 홈 에디션 기준

1. 제어판 > 프로그램 > 프로그램 및 기능 > Windows 기능 켜기/끄기 버튼을 클릭한다.

2. Linux 용 Windows 하위 시스템, 가상 머신 플랫폼에 체크하고 확인 버튼을 클릭한다. -> 체크한 기능을 활성화하려면 컴퓨터를 다시 시작해야한다.

3. https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi 에 접속하여 리눅스 커널을 다운받는다. 다운로드 받은 파일을 실행하여 리눅스 커널을 업데이트 할 수 있다.

4. https://docs.docker.com/desktop/install/windows-install/ 윈도우용 도커 데스크톱을 다운받는다.

5. 설치 중, Configuration 화면에서 모든 항목에 체크한 다음 OK 버튼을 진행한다.

6. 설치가 완료되면 Close and log out 버튼을 클릭해 윈도우에 다시 로그인한다. (컴퓨터가 재부팅된다.)

7. 바탕화면에 Docker Desktop이 추가되어있다.

EC2에서 Docker 설치

# 도커 설치
sudo yum install docker -y

# 도커 서비스 실행
sudo service docker start

# /var/run/docker.sock 파일 권한 변경
sudo chmod 666 /var/run/docker.sock

# ec2-user를 docker 그룹에 추가, sudo 명령어 없이 docker 사용가능
sudo usermod -a -G docker ec2-user

Docker Hub 레포지토리 생성

Docker Hub에 docker image를 push할 레포지토리를 생성한다. public으로 생성하자. (private의 경우 계정 당 1개까지만 무료로 생성이 가능하다.)

Dockerfile 생성

프로젝트 최상위 경로 아래에 Dockerfile을 생성한다. (※ src 아래에 생성하면 안 된다!)

Dockerfile

# jdk 17(amazoncorretto:17) 환경으로 구성
FROM amazoncorretto:17

# 인자 설정 :: 변수명 JAR_FILE
# build/libs(빌드 시 jar파일 생성 경로) 하위의 모든 jar파일
ARG JAR_FILE=build/libs/*.jar

# Docker Image 생성 시 JAR_FILE을 app.jar로 복사
COPY ${JAR_FILE} app.jar

# 실행 명령어
ENTRYPOINT ["java", "-jar", "app.jar"]

결과 확인하기

master 브랜치에 push 했을 때, 배포가 잘 되는지 확인해보았다.

트러블 슈팅

1. Docker build & Push 실패

      - name: Docker build & Push
      # 레포 명 뒤에 . 이 빠짐
        run: |
          docker build -t ${{ secrets.DOCKER_USERNAME }}/nnzz
          docker push ${{ secrets.DOCKER_USERNAME }}/nnzz
   
   

  - name: Docker build & Push
  # 변경 후
    run: |
      docker build -t ${{ secrets.DOCKER_USERNAME }}/nnzz .
      docker push ${{ secrets.DOCKER_USERNAME }}/nnzz

명령어 끝에 `.` 을 추가해준다. Dockerfile을 현재 디렉토리에서 찾을 수 있게 된다.


2. **Github Actions은 성공하나 테스트를 위해 api를 추가하여 푸시했는데 404 No static resource api/test. 라고 뜸**
(문제를 해결하는 데 도움을 주신 승등님께 감사의 인사를ㅎㅎ)

![](https://velog.velcdn.com/images/peace_e/post/c5c481ca-0392-4710-b8c8-62e879ae8997/image.png)

CI/CD job 전부 error 하나 없이 잘 실행된 터라 원인을 찾는데 오래 걸렸다.

파일을 빌드하는 부분을 Workflow에 넣었기 때문에, 
FileZila에서 조회할 때 갱신된 .jar 파일이 로컬이든 서버든 있어야 한다고 생각을 했는데
build 파일은 수동 배포할 때 것 그대로였다.
-> `./gradlew clean build`가 실행이 안 됐다고 생각했고 gradle build 부분에 문제가 있다고 여겨 그 부분을 계속 수정해봤는데 해결이 안 됐다.


> **사실 로컬과 서버 둘다 빌드 파일이 업데이트 안 되는게 맞다.**
Github Actions은 **가상머신** 위에서 돌아가기 때문에 로컬에선 빌드 안되는게 맞고,
EC2 서버에는 docker image를 docker hub 통해서 받아오는거니까 빌드 파일이 없는게 맞다.
파일이 있다면 이전에 파일질라로 직접 넘겼던 것뿐이어야 한다.

그래서
- **push 했을 때 docker hub에 image 가 올라갔는지 확인하기**
-> image는 잘 있었다.

- **push 전후로 ec2 서버에서 docker 컨테이너 id를 확인하기.**
``` bash
sudo docker ps -a

컨테이너 자체가 없었다..

이미 8080을 써서 어플리케이션이 실행되고 있는 와중에 별개의 도커 컨테이너를 같은 8080으로 실행시키려고 하니 포트 충돌 때문에 컨테이너 자체가 실행되지 않은 것이다.

별 생각 없이 도커 설정만 해주면 되겠거니라고 생각했다.. 반성

실행중이던 8080포트를 종료하고 push 하니 정상적으로 실행되었다. 혹시 나와 같은 오류를 겪는 분들이 있다면 도움이 되길 바란다.

레퍼런스

[프로젝트 배포] RDS, S3 설정 및 프로젝트 배포

[프로젝트 배포] Docker를 활용한 배포 및 CI/CD 구축

Docker 설치 및 기본 명령어

분명 Timestamp 컬럼으로 테이블을 만들었고 LocalDateTime으로 선언해서 시간을 넣어주었는데 시간 값이 이상하게 들어갔다. DBeaver에서 SHOW TIMEZONE; 실행해봐도 Asia/Seoul이라고 잘 뜨는데도 그랬다. 도대체 원인이 뭘까?

그런데, 테스트 용으로 돌리던 로컬 DB에서는, 시간 값이 정확했다.

원인은 AWS EC2였다...

EC2 기본 타임존

EC2의 기본 타임존은 UCT이다. 아시아 태평양, 서울 리전으로 개설했어도 똑같다. DB의 타임존이 한국시간으로 되어있더라도 서버의 기본타임존은 UCT다.

UCT는 한국시간과 9시간 차이난다. 이 기본 타임존을 한국 시간으로 바꾸지 않으면 Java에서 생성되는 시간도 모두 9시간 전으로 설정된다.

한국 시간으로 설정하는 법

EC2 서버 실행 하고 date로 시간대를 확인한다.

sudo timedatectl set-timezone Asia/Seoul

timedatectl 명령어를 사용해서 Asia/Seoul timeZone으로 바꾼다.

다시 date를 사용해서 시간대를 확인한다.

KST로 바뀐 모습을 확인할 수 있다.

Problem Details

Problem Details는 Spring boot 3.0.x (Spring Framework 6.0.x)부터 사용가능하다.

Problem Details는 RFC 7807를 따른다. RFC 7807 은 API 에러 응답에 대한 규약을 정의한 문서이다. https://www.rfc-editor.org/rfc/rfc7807.html

RFC 7807 의 내용은 에러 발생 시 안내할 응답 내용을 문서 세부 정보 개체 ("type", "title", "status", "detail", "instance")와 확장 멤버로 구성하자는 것이다.

이 구성을 Problem Details는 그대로 따르고 있다.

https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/http/ProblemDetail.java ProblemDetail의 클래스의 구조는 깃허브에서 확인가능하다.

public class ProblemDetail {

    private static final URI BLANK_TYPE = URI.create("about:blank");

    // 문제 유형을 식별하는 URI 참조
    private URI type = BLANK_TYPE;

    // 문제 유형에 대한 사람이 읽을 수 있는 간단한 요약
    @Nullable
    private String title;

    // 이 문제의 응답 Http status 코드
    private int status;

    // 문제 유형에 대한 사람이 읽을 수 있는 간단한 설명
    @Nullable
    private String detail;

    // 문제가 발생한 URI
    @Nullable
    private URI instance;

    // 위에 선언한 문서 세부 정보 필드 이외에 추가적으로 사용할 확장 필드를 저장하는 곳
    @Nullable
    private Map<String, Object> properties;

}

Problem Detail 사용하기

application.yml

spring:
  mvc:
    problemdetails:
      enabled: true

위처럼 true 값으로 설정해준다.

예외 핸들러 작성

예외도 처리하고, 객체도 리턴해야해서 @RestControllerAdvice를 사용했다.

핸들러는 @ExceptionHandler() 를 사용해서 구현할 수 있다.

@RestControllerAdvice
public class ExceptionHandler {
    @ExceptionHandler(UserNotExistsException.class)
        public ProblemDetail handleUserNotExistsException(UserNotExistsException ex) {
            ProblemDetail pd = ProblemDetail.forStatusAndDetail(
                    HttpStatus.NOT_FOUND, ex.getMessage());
            pd.setTitle("존재하지 않는 유저입니다.");
            pd.setProperty("timestamp", LocalDateTime.now());
            pd.setProperty("message", message);
            return pd;
    }

- forStatusAndDetail()

status와 detail을 지정할 수 있다. forStatus(), setDetail()로 따로 지정할 수도 있다.

- setTitle()

타이틀을 지정한다.

- setProperty()

추가적으로 확장필드를 지정할 수 있다.

- setType()

타입을 지정한다.

- setInstance()

인스턴스를 지정한다.

응답 확인

type은 따로 지정하지 않으면 기본값 "about:blank"가 출력된다. title의 경우 따로 설정하지 않아도 HttpStatus의 값에 맞게 가져온다. instance도 자동으로 에러가 발생한 uri를 가져온다.

참고 https://luvstudy.tistory.com/220

프론트와 협업하는 것도 처음이라 아무것도 모르는 상태였기에 해결하는 데 제법 오랜 시간이 걸렸다.

CORS 란?

CORS ( Cross-Origin Resource Sharing )는 서버가 브라우저가 로딩 리소스를 허용해야 하는 자체 출처가 아닌 다른 출처 (도메인, 스킴 또는 포트)를 나타낼 수 있도록 하는 HTTP 헤더 기반 메커니즘 https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

우리가 겪는 CORS 이슈는 모두 이 메커니즘을 위반했기 때문에 발생한다. 번거롭긴 하지만 CORS 덕분에 우리가 주고받는 리소스가 안전하다는 최소한의 보장을 받을 수 있다.

Cross-Origin

브라우저는 보안상의 이유로 cross-origin HTTP 요청을 제한한다. 여기서 cross-origin이란 다른 출처를 의미한다. 즉, 다른 출처로부터의 리소스 요청을 제한하고 동일한 출처에서만 리소스 요청이 가능하다는 것이다.

https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/What_is_a_URL

전체 URL에서 Scheme, Domain, Port만 동일하면 된다.

프론트엔드와 백엔드가 협업하는 경우, 각자 서버를 띄우게 되면 포트가 3000/8000으로 서로 다르다. 서로 다른 서버에서 리소스를 주고 받으려하기 때문에, CORS 이슈가 발생하는 것이다.

※ postman에서는 동작하는 이유 origin이 다른지 판단하는 것은 브라우저다. 서버는 cors를 위반하더라도 정상적으로 응답을 해준다. 응답의 파기 여부는 브라우저에 의해 결정된다. 즉, 브라우저는 통하지 않는 통신인 postman에서는 정상동작한다.

해결방법

Spring Security를 사용중이었기에 filterChain 메서드에 cors 관련 설정을 추가했다.

@Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.httpBasic(HttpBasicConfigurer::disable) // HTTP 기본 인증 비활성화
                .formLogin(AbstractHttpConfigurer::disable) // httpBasic 인증 방식 사용 x
                .csrf(AbstractHttpConfigurer::disable) // csrf 비활성화
                .sessionManagement(httpSecuritySessionManagementConfigurer -> httpSecuritySessionManagementConfigurer.sessionCreationPolicy(SessionCreationPolicy.STATELESS))

                .cors(corsCustomizer -> corsCustomizer.configurationSource(request -> {
                    CorsConfiguration config = new CorsConfiguration();
                    config.setAllowedOrigins(Collections.singletonList("http://localhost:3000"));
                    config.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE", "PATCH"));
                    config.setAllowCredentials(true);
                    config.setAllowedHeaders(Arrays.asList("Authorization", "Authorization-refresh", "Cache-Control", "Content-Type"));
                    config.setExposedHeaders(Arrays.asList("Authorization", "Authorization-refresh"));
                    config.setMaxAge(3600L); // 1시간
                    return config;
                })) // cors
                ;

        return http.build();
    }

• setAllowedOrigins() : 허용할 URL
• setAllowedMethods() : 허용할 Http Method
• setAllowCredentials() : 쿠키 인증 요청 허용
• setAllowedHeaders() : 허용할 Header
• setExposedHeaders() : 응답할 Header
• setMaxAge() : 허용 시간

맨 처음에는 setAllowedOrigins() 메서드를 제외하고 전부 "*" 와일드카드를 사용해서 전부 허용했었다.

그래도 안 되길래 구글링해보니 setAllowCredentials() 메서드를 true로 설정한 경우에는 와일드카드를 사용하면 안 된다는 얘기가 있길래, 값을 전부 수정했다.

그리고 WebConfig 에도 cors 설정을 적어주었다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://localhost:3000");
    }
}

이렇게 설정을 바꿔주니 정상적으로 api 통신이 가능했다!

PostgreSQL에서는 geometry 타입 컬럼과 공간 데이터 계산이 가능한 PostGIS 함수를 제공한다.

CREATE EXTENSION postgis; 

위 쿼리를 통해 postgis 확장 모듈을 설치해주어야만 geometry 타입 컬럼이 사용가능하다.

postgis 설치가 완료되면 아래처럼 테이블과 뷰가 생긴다. 삭제하면 postgis를 사용할 수 없으므로 주의하자.

Geometry 타입 컬럼 추가하기

이미 만들어진 테이블에 lat, lng 값이 있다. 그 값을 사용하여 Point 값을 업데이트 할 것이다.

ALTER TABLE 테이블명
ADD COLUMN 추가할컬럼명 GEOMETRY(Point, 4326);

좌표계는 4326을 사용한다.

UPDATE 테이블명
SET 추가한컬럼명 = ST_SetSRID(ST_MakePoint(lng, lat), 4326;

ST_SetSRID()함수와 ST_MakePoint()함수를 사용해서 값을 넣는다. lng(경도), lat(위도) 순으로 작성하지 않으면 오류가 발생하므로 유의

Geometry 타입 컬럼의 값을 검증하기

SELECT ST_IsValid(컬럼명) from 테이블명; 
UPDATE 테이블명 SET 컬럼명 = ST_MakeValid(컬럼명);

ST_IsValid() 함수로 값을 검증할 수 있다. 유효한 값이라면 true를 반환한다.

유효하지 않은 값이 있다면, ST_MakeValid() 잘못된 형식을 유효한 형식으로 변환할 수 있다.

업데이트해서 데이터를 잃을 수 있는데 괜찮냐고 묻는다. 확인을 눌러야 진행가능하다.

Geometry 타입 컬럼의 값을 수정하기

lng, lat 컬럼의 값이 잘못되어 있었다고 가정하자. 두 컬럼의 값은 수정하더라도 새로 생성한 geometry 타입 컬럼의 값은 수정되지 않는다.

update store
 SET 컬럼명 = ST_SetSRID(ST_MakePoint(lng,lat), 4326)
 where id = id값

ST_SetSRID()와 ST_MakePoint()함수를 사용해서 값을 다시 변경할 수 있다.

자동으로 Geometry 타입 컬럼의 값을 추가하기

위와 같은 테이블이 만들어진 상태에서 바로 새 행을 추가하려고 하면, 오류가 발생한다. geometry 타입 컬럼은 null을 허용하지 않기 때문이다.

lng, lat 값만 추가하면 자동으로 geometry 타입 컬럼에도 값이 등록되게끔 하고 싶다면 트리거 함수를 이용하면 된다.

CREATE OR REPLACE FUNCTION 함수명()
RETURNS TRIGGER AS $$
BEGIN
    NEW.컬럼명 := ST_SetSRID(ST_MakePoint(NEW.lng, NEW.lat), 4326);
    RETURN NEW;
END;
$$ LANGUAGE plpgsql; -- 트리거 함수 생성

'$$' 사이에 함수 내용을 작성한다. LANGUAGE plpsql은 PL/pgSQL(Procedural Language/PostgreSQL)을 사용하겠다는 뜻이다. 이를 사용해서 데이터베이스를 관리 및 조작할 수 있다.

CREATE TRIGGER 트리거명
BEFORE INSERT OR UPDATE ON 테이블명
FOR EACH ROW
EXECUTE FUNCTION 함수명(); -- 위에서 만든 트리거 함수를 호출

작성된 함수를 트리거를 지정해서 각 행이 INSERT 또는 UPDATE 될 때, 호출되도록 한다.

두 쿼리를 실행시켜주면 오류 없이 행을 추가할 수 있다.

mapper.xml

mapper.xml에서 useGeneratedKeys="true", keyProperty="" 를 추가해준다. keyProperty는 가져올 ID의 프로퍼티를 적어주면 된다.

<insert id="createCard" parameterType="SaveCardDTO" useGeneratedKeys="true" keyProperty="cardId">
        INSERT INTO card(user_id, store_id, food_type_id)
        VALUES (#{userId}, #{storeId}, #{foodTypeId})
</insert>

DTO

DTO에는 키프로퍼티가 반드시 포함되어있어야한다.

@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class SaveCardDTO {
    private Integer cardId; // keyproperty
    private Integer userId;
    private String storeId;
    private Integer foodTypeId;
}

올바른 예

값을 insert 후에, 생성된 객체에서 get프로퍼티() 를 통해서 값을 가져올 수 있다.

cardService.createCard(newCard);
System.out.println("cardId : " + newCard.getCardId());

잘못된 예

insert 이후의 int 값은 useGeneratedKeys 옵션에 따라서가 아닌, 결과 여부이다.(0 혹은 1)

Integer cardId = cardService.createCard(newCard);
System.out.println("cardId : " + cardId);

이렇게 하고 실행하니 계속 똑같은 결과만 storeId가 1로만 나왔다 (당연함)

참고

https://wwwnghks.tistory.com/170

DBeaver에서는 컬럼의 순서를 쉽게 바꿀 수 있다. 아래는 MySQL을 사용하는 테이블이다. 컬럼을 선택하면 순서를 바꿀 수 있는 아이콘이 뜬다.

아래는 PostgreSQL을 사용하는 테이블이다. 컬럼을 선택해도 순서를 바꿀 수 있는 아이콘이 뜨지않는다.

반드시 특정 위치에 있어야 하는 경우라면 테이블을 삭제하고 다시 생성해야 한다. 이 방법이 내키지 않는다면 뷰를 생성하는 것이 최선의 방법이지만 제약조건을 다시 설정해야 하므로 유의

참고 https://stackoverflow.com/questions/285733/how-do-i-alter-the-position-of-a-column-in-a-postgresql-database-table

Swagger 사용방법에 대해서는 추후에 정리할 예정이다.

Spring Security

프로젝트에서 카카오 Oauth를 통해 회원 로그인을 구현하기 위해 oauth 의존성을 build.gradle에 추가해주었다.

// oauth
implementation("org.springframework.boot:spring-boot-starter-oauth2-client")
implementation("org.springframework.boot:spring-boot-starter-security")
testImplementation("org.springframework.security:spring-security-test")

application.yml에도 정보를 추가해주었다.

spring:
    security:
        oauth2:
            client:
                registration:
                    kakao:
                        clientId: '{카카오 client-id}'
                        clientSecret: '{카카오 client-secret}'
                        client-authentication-method: post
                        authorization-grant-type: authorization_code
                        redirect-uri: "{url}"
                        ## 서버에서 인증을 마치고 돌아가는 callback uri
                        scope:
                              - account_email
                        client-name: Kakao
                provider:
                      kakao:
                        authorization-uri: https://kauth.kakao.com/oauth/authorize
                        token-uri: https://kauth.kakao.com/oauth/token
                        user-info-uri: https://kapi.kakao.com/v2/user/me
                        user-name-attribute: id

문제

당시, 서버와 로컬 두 곳에서 프로젝트를 돌리고 있었고 로컬에서 spring security 추가 이후에 실행이 잘 되는 것을 확인하고 서버에서도 똑같이 실행했다. (로컬에서는 swagger를 쓰지 않았다.)

서버에서도 문제 없이 api가 응답하는 것을 확인했고 swagger api문서를 들어갔는데 swagger api failed to load remote configuration. 라고 뜨면서 페이지가 로딩이 안 됐다...

해결방안

원인을 찾는 것은 어렵지 않았다. spring security 설정 시, 환경설정을 구성하기 위해 작성하는 SecurityConfig에서 requestMatchers()로 swagger에 관한 보안설정도 지정해줘야한다. 설정하지 않은 url 요청은 전부 거부된다.

requestMathcers()에 "/swagger-ui/**", "/v3/api-docs/**" 를 추가했다. swagger api failed to load remote configuration. 는 사라졌으나 swagger 페이지가 무한 로딩되는 상황에 빠졌다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable);

        http.authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/swagger", "/swagger-ui.html", "/swagger-ui/**", "/api-docs", "/api-docs/**", "/v3/api-docs/**").permitAll()
                .requestMatchers("/api/**").permitAll()
                .anyRequest().authenticated());

        http.oauth2Login(Customizer.withDefaults());

        return http.build();
    }
}

맨 위에는 swagger와 관련된 url을 전부 허용해주고, 그 아래에 프로젝트 내에서 사용하는 api url을 분리하여 허용해주었다.

그렇게 하니 swagger api 문서가 잘 보였다! spring security 사용 시에는 보안 설정을 꼼꼼히 해야겠다는 생각이 들었다.

EC2 생성

이미 사용중이라 화면 좌측에 프리티어 사용 중이라고 뜨는 상태이다. 좌측의 화면은 생성하고 바로는 표시되지 않는다. 나는 EC2 신청 직후, 사용 중인 프리티어가 없다고 뜨길래 프리티어로 생성이 제대로 안 되었을까봐 엄청 겁먹었는데 원래 하루 정도는 소요되는 것 같다. 청구서도 하루 뒤에 볼 수 있으니 유의하자. 처음 EC2를 개설할 때에는 상단바에서 리전 설정을 아시아 태평양(서울) 로 변경하고 인스턴스 시작 버튼을 눌러 인스턴스를 개설한다.

AMI(Amazon Machine Image) Amazon EC2 인스턴스를 설정하고 부팅하는 데 필요한 소프트웨어를 제공하는 이미지

인스턴스의 이름을 설정하고 AMI를 지정한다. 나는 Amazon Linux로 진행했으나 다시 개설한다면 Ubuntu로 진행할 것 같다. 각 AMI마다 유저명과 실행 가능한 명령어가 달라지므로 잘 알아보고 선택하는 것을 추천한다. (※ 예 : Linux 유저명 : ec2-user, Ubuntu 유저명 : ubuntu Linux 명령어 : yum, Ubuntu 명령어 : apt-get)

해당 AMI중에서도 프리티어 사용 가능이라고 적혀있는 것을 선택한다.

인스턴스 유형도 프리티어 사용가능한 것(t2.micro 뿐임)으로 선택해준다.

인스턴스 접속을 위해서는 키 페어가 반드시 필요하다. 새 키 페어 생성을 클릭하여 키 페어를 생성한다. 키 정보가 유출되지 않도록 주의해서 관리해야 한다.

기존에 생성해둔 보안그룹을 선택하거나, 새로운 보안그룹을 생성할 수 있다.

프리티어에서는 최대 30gb의 스토리지를 사용할 수 있다

고급 세부 정보는 변경하지 않고 인스턴스 시작을 눌러 새로 인스턴스를 생성한다.

처음 생성하고 몇 분정도 소요되며, 생성 중에는 인스턴스의 상태가 대기 중으로 표시된다.

EC2 보안그룹 편집

최초 생성 시, SSH 연결을 위한 22 포트만 존재하는데 Spring boot 연결을 위해 8080 포트와, HTTP 80 포트를 추가해준다.

탄력적 IP 할당

AWS EC2는 매번 서버를 시작하고 종료할 때마다 새로운 IP가 할당되므로 탄력적 IP를 할당받아야한다. EC2 서버 하나에 탄력적 IP 하나는 프리티어로 사용가능하다. 단, 탄력적 IP를 생성하고 EC2 서버에 연결하지 않는다면 요금이 부과되므로 주의하자.

EC2 탭 > 탄력적 IP > 탄력적 IP 주소 할당 을 눌러서 진행한다.

기본 설정대로 생성하고 탄력적 IP 주소 연결을 클릭한다.

앞서 생성한 인스턴스에 탄력적 IP를 연결한다. 그러고 EC2 인스턴스의 퍼블릭 IPv4 주소를 확인해보면 방금 생성한 탄력적 IP 주소로 연결되어 있는 것을 확인할 수 있다.

로컬에서 EC2 서버 접속

설치된 git bash로 접속을 진행한다. 우선 홈 디렉토리에 .ssh 디렉토리를 만들고 생성해둔 키 페어를 .ssh 디렉토리로 복사한다. 복사한 키 권한을 바꿔주고, vim 명령어로 config 파일을 생성한다.

vim 명령어 사용 시

• i키를 눌러 insert를 진행하고
• 입력이 끝났을 땐 esc 키를 누르고 :eq를 입력하여 종료한다.

config 파일에는 접속 시 필요한 호스트 정보가 들어간다.

Host nnzz
        Hostname 탄력적주소IP
        User  ec2-user(Ubuntu 사용자라면 ubuntu)
        IdentityFile ~/.ssh/nnzz-key.pem

ssh [설정한 호스트] 를 입력해서 접속하면 되는데, 첫 접속시에는 항상 신뢰여부를 묻는다. yes 를 입력하면 연결해주지만 known hosts에 등록해둘것을 경고한다.

ssh-keyscan 명령어를 통해 known_hosts 파일을 생성해서 등록한다.

ssh-keyscan -t rsa [탄력적IP주소] >> known_hosts

JDK 설치

프로젝트에서는 Amazon Corretto 17버전을 사용하고 있어서 동일한 버전으로 설치해주었다.

ec2 생성 시 선택한 AMI가 Amazon Linux 2023 버전인데 이 버전은 yum 명령어 뿐만 아니라 dnf 명령어도 사용 가능하다. 초기 세팅할 때, 명령어 때문에 애를 먹었는데 노트북에서 새롭게 해당 환경을 세팅하기 위해 다시 진행하면서 dnf 명령어를 사용하니 한번에 설치되었다.

ssh로 접속 후에 아래처럼 입력해서 Amazon Corretto 17을 설치한다.

sudo dnf install java-17-amazon-corretto-devel.x86_64

다운로드 받을 때 y/n으로 묻는데 y를 누르면 계속 진행한다. 사진처럼 뜨면 설치완료된 것.

RDS 생성

표준생성, PostgreSQL, 16.3버전을 선택했다. RDS 확장 지원 활성화는 유료 오퍼링이므로 선택하지 않았다.

템플릿을 프리티어로 선택하게 되면 가용성 및 내구성은 제한된다. 과금할 거 아니니 이렇게 진행한다.

데이터베이스 이름과 마스터 사용자 이름, 비밀번호를 설정한다. 설정한 이름과 비밀번호는 나중에 필요하므로 기억해둬야한다. 이름은 기본 설정인 postgres 그대로 진행했다.

인스턴스 구성의 경우 db.t4g.micro로 진행했다.

스토리지는 기본 설정이 범용 SSD(gp3)이라 이대로 생성했는데 다음날 청구서를 보니 $0.131 per GB-month of provisioned GP3 storage running PostgreSQL 로 청구된 것을 확인할 수 있었다..

gp2로 바꾸었더니 추가로 청구된 것은 없었다. 프리티어로 생성할 거라면 gp2로 생성하자.

스토리지 자동 조정의 경우 반드시 체크 해제해주어야 한다. 체크 시 프리티어여도 과금 대상이다.

EC2 서버와 RDS를 연결해서 사용할 것이므로 EC2 컴퓨팅 리소스에 연결을 체크하고 연결할 EC2 인스턴스를 선택해준다.

서브넷 그룹이나, VPC 보안 그룹은 미리 생성해둔 게 있다면 기존 항목을 선택할 수 있다. 새로 생성도 가능하다. 퍼블릭 액세스의 경우 EC2 컴퓨팅 리소스에 연결 선택 시 자동으로 아니오에 체크된다. 퍼블릭 액세스 못 하는 거 아니냐고 걱정할 필요 없다. 데이터베이스도 ssh 통해서 연결하면 된다.

가용영역의 경우, 이미 개설한 ec2 인스턴스와 연결하게 되면 ec2 인스턴스가 사용하는 리전 지역으로 연결해준다.

※ 주의 rds를 생성할 때, 아무리 서울 지역으로 생성했더라도 ec2에 연결하지 않고 생성을 끝내면, 가용영역이 달라져 나중에 ec2에 연결되지 않을 수 있으므로 반드시 생성할 때 연결하는 것을 추천한다.

인증기관과 데이터베이스 포트는 기본값으로 둔다. 데이터베이스 포트의 경우, 각 데이터베이스 별로 기본 포트 값이 표시된다. postgresql은 5432 포트를 사용한다.

따로 설정하지 않고 넘어간다.

모니터링과 추가구성의 자동 백업, 삭제 방지는 전부 체크 해제 해주었다.

월별 추정 요금을 알려주기는 하나, 나도 20gb의 범용 스토리지는 괜찮으니까 gp3도 무료구나 싶었는데 아니었다. 되도록이면 요금 페이지에서 자세한 설명을 보고 진행하는 것을 추천한다. 불안하다면 생성하고나서 매일 같이 청구서를 들여다보고 과금될 때마다 하나씩 변경하자. 내가 그랬다

설정을 완료하고 데이터베이스 생성을 클릭하고 완전히 생성될 때까지 기다린다.

DBeaver나 Intellij에 DB 연결하기

생성한 데이터베이스 종류의 맞게 선택하고 연결을 설정한다.

• 호스트에 생성된 RDS 인스턴스의 엔드포인트를 복사해 넣는다.
• Username과 Password에는 RDS 설정시 넣은 사용자명과 비밀번호를 넣어준다.

• SSH 탭으로 넘어와서 Host/IP 에 EC2에서 설정한 탄력적 IP를 넣어준다.
• 포트는 22, User Name은 EC2 인스턴스를 생성할 때, 선택한 AMI에 따라 유저명이 달라진다.
• Authentication Method는 Public Key를 선택하고 Private Key를 키 페어 파일로 지정한다.
• Test Connection 을 클릭해 연결이 잘 되는지 확인하고 필요한 드라이버를 다운받은 뒤, 최종적으로 연결한다.

Intellij에 DB를 연결할 때도, RDS의 엔드포인트를 호스트로 넣고, SSH로 통신할 때 키 페어를 사용하면 된다.

한국시간으로 바꾸기

EC2 의 기본 시간은 UTC이므로 한국 표준시인 KST로 바꾸고 작업해야한다. https://velog.io/@peace_e/EC2-linux-한국-시간으로-서버-시간-변경하기

사용자의 위치 정보를 받아서 DB에 저장된 근처에 있는 음식점들 중, 유저가 선택한 카테고리에 맞는 가게들만 찾아서 가게의 상세 정보들을 불러와야했다. 이 때, 유저가 선택할 수 있는 카테고리는 총 30가지다. "나는 한식만 먹고싶어"라고 확실히 마음을 정한 유저들도 있겠지만 아닌 경우들이 더 많다고 생각한다. 일단 나는 그렇다. 점심, 저녁 메뉴 정하기 고민을 줄여보자는 마음에서 계획한 프로젝트지만 분명히 이것도 좋고, 저것도 좋은데라고 생각할 유저는 있을 것이다. 그럼 30가지 카테고리를 전부 선택했을 때에도! 주변에 그 카테고리에 해당하는 가게가 많더라도! 최대한 빨리 정보를 불러와야지.

문제 상황

MySQL이 익숙하기에 이번 프로젝트에서도 사용했다. 데이터베이스에서 해당하는 가게의 리스트(가게의 ID 정보만)를 먼저 뽑고, 각 가게당 메뉴, 방송출연 여부 등 기타 정보를 가져오도록 코드를 작성했다. 이 과정에서는 결국 가게의 리스트의 길이만큼 반복문을 돌 수 밖에 없다. 이건 데이터베이스의 문제보다도 작성한 쿼리의 문제긴 하지만 2000여 곳의 데이터가 들어있는 환경에서 카테고리에 해당하는 470개의 리스트를 가져올 때, 기본적으로 30초가 넘는 시간이 소요되었다. 여러 번 실행해볼 때, 심하면 40초까지 걸리기도 했다.

해결 방안

https://steemit.com/kr-dev/@tmkor/db-2-mysql-vs-postgis-postgresql PostgreSQL + PostGIS를 사용하면 공간 검색 기능면에서 이점이 있다는 글들을 보았고 테스트를 해보기로 했다.

1. 반복문을 돌지 않고 조인을 통해서 한 번에 조인하게끔 쿼리를 수정한다.
2. PostgreSQL에서 PostGIS를 사용하고 똑같은 쿼리로 실행한다.

두 가지를 전부 테스트 해 보았다. 기존의 DB는 AWS 서버에 연결된 RDS였고, PostgreSQL 사용을 위해 로컬에 PostgreSQL을 설치하고 테스트를 진행했다. 설치시에는 StackBuilder를 통해 PostGIS도 추가로 설치를 진행해주었다.

1. PostgreSQL과 PostGIS 사용하기

https://velog.io/@peace_e/PostgreSQL-Geometry-사용하기 geometry 컬럼 사용법은 이 게시글에 정리해두었다.

build.gradle에 postgre 의존성을 추가하고,

dependencies {
    implementation 'org.postgresql:postgresql:42.7.3'
}

application.yml에도 postgre로 바꿔주었다.

spring:
  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://localhost:5432/postgres
    username: 유저이름
    password: 비번

※ MySQL 포트번호 : 3306 ※ PostgreSQL 포트번호 : 5432

PostGIS GiST 기반 R-TREE 공간 인덱스를 지원하고 GIS 객체의 분석 및 공간 처리를 위한 기능을 포함하고 있다. 다양한 공간 데이터 형식과 공간 쿼리를 지원한다는 이점이 있다.

PostgreSQL에서는 PostGIS 사용을 위해 아래처럼 작성하고 실행해줘야 한다.

CREATE EXTENSION postgis;

ST_DistanceSphere() 함수를 사용하여 거리를 계산했다.

SELECT store_id
  FROM store
 WHERE ST_DistanceSphere(location, ST_GeomFromText('POINT(경도 위도)', 4326)) <= 750

1. PostgreSQL에서 똑같이 반복문을 타는 쿼리로 실행했을 때, 7초 정도가 소요됐다.

2. 반복문 대신 JOIN을 통해서 다른 테이블에 저장된 가게의 정보값까지 전부 가져오기 위해 json_agg를 사용했다. 반복문을 사용할 때랑 별반 차이가 나지 않는다... 이게 아닌데..

3. PostgreSQL은 json 데이터를 저장하기위해 json뿐만 아니라 jsonb 타입을 제공한다. json 타입은 원본을 저장하고, jsonb 타입은 바이너리 형식으로 저장하기에 json 타입보다 속도가 빠르다. 또한 인덱싱을 지원한다는 이점도 있다. jsonb_agg와 with 절을 사용해 시간을 줄여보기로 했다.

결과는 성공적이었다. 100ms 내외로 응답이 나온다.

2. MySQL에서 쿼리만 변경하기

MySQL에서는 위/경도 값을 POINT형태로 location 컬럼 값에 넣었고, 공간인덱스를 추가했다. 공간 인덱스의 경우 ST_DistanceSphere() 함수를 지원하지 않아 거리를 측정하기 위해 ST_Distance() 함수를 사용했다. 750M 내에 있는 가게들만 우선 골라낸다.

SELECT store_id
  FROM store
 WHERE ST_Distance(ST_GeomFromText('POINT(경도 위도)', 4326)) <= 750

1. json을 사용해서 한번에 조회하도록 했다. 편차가 좀 있었지만 300ms ~ 2s 정도의 시간이 소요되었다.

2. 같은 json인데 쿼리를 with 절로 바꾸었다. 200ms ~ 300ms 정도로 걸렸다.

결론

쿼리를 바꾸는 것만으로도 성능은 크게 개선되었지만 가게 DB가 늘어나는 것도 고려하면 PostgreSQL로 마이그레이션 하지 않을 이유가 없었다. 게다가 추후 프로젝트를 확장시에 '00동', '00구' 단위로 해당하는 가게 리스트를 보여줄 계획도 있었기에, shp 파일을 db화 하기에는 PostgreSQL이 적합하다고 생각했다.

DB에서 넘긴 json형식의 데이터는 처음 받아봤는데, Mybatis로 json형식의 데이터를 조회하려면 타입핸들러를 구현해야한다는 것도 알게 되었다. 이점에 대해서는 추후에 기록할 예정이다.