1. 코드카타

연결되지 않은 Directed Graph에서 가장 긴 경로를 찾는 문제였다. 다만, 문제 조건이 상당히 단순해서(모든 노드가 1개의 inbound 엣지와 outbound 엣지를 가져야 해서, 모든 노드가 루프를 구성한다) O(N)의 간단한 알고리즘으로도 문제가 해결되었다.

2. 최종 프로젝트

서버 로그인 및 인증 로직을 구현했다. 현재는 게스트 로그인(서버 발급, 클라이언트는 별도의 로그인 화면 없이 로딩 중에 백그라운드로 로그인 처리)만 구현했고, 이후 여유가 된다면 소셜 연동을 고려 중이다. 인증은 JWT를 사용하되, JWT의 유효 기간은 짧게 두고, 서버가 DB에 보관 및 명시적으로 폐기할 수 있는 리프레시 토큰을 별도로 두어 관리하도록 했다. 이러면 로그인 재시도 횟수를 줄일 수 있는데, 당장은 성능적인 이득이 크지는 않다. 게스트 로그인 방식은 무작위 문자열로 시크릿을 생성하고, 이는 레인보우 테이블 공격 등에 비교적 덜 취약하다. (많이 쓰이는 비밀번호라는 개념이 없으니까) 그래서 현재는 느린 bcrypt 해시를 쓰지 않아 로그인과 리프레시 토큰 검증 간에 퍼포먼스 차이가 크지 않다. 영구 자격 증명 도구인 시크릿이 통신을 타고 오가는 횟수가 줄어드는 것도, 어차피 HTTPS 통신을 사용하니 실질적인 위험은 아니다. 현재에는 성능이나 보안 상의 이점보다는, 로그인 상태가 유지될 수 있으며, 서버가 명시적으로 사용자의 로그인 상태를 끊을 수도 있는 구조라는 데에 의의가 있다. 다만, bcrypt를 굳이 안 쓸 이유는 없어 보여서 전환을 검토해보려고 한다. 느리기 때문에 공격을 어렵게 한다는 장점도 있으니까.

서버 저장 및 로드 로직을 일부 구현했다. 단계별로 나눠서 구현할 예정이며, 현재는 1단계: 클라이언트가 올려주는 진행도를 믿고 서버에 저장하는 방식이다. 즉, 데이터가 서버에도 저장되지만, 클라이언트도 가지고 있는 구조이다. 점진적으로 서버만이 원본을 가지고 있고, 클라이언트는 인증 토큰을 가지고 요청해서 값을 받아오는 구조로 변경할 예정이다.

JWT를 학습한 지 시간이 좀 지나서 많이 내용을 잊어버렸는데, 이번 작업을 통해 다시 복습하는 기회가 되었다.

내일 학습할 내용

• 서버 저장 및 로드 기능: 클라이언트 책임에서 점차 서버 책임으로 이동. 정보 원본을 서버가 갖고 있고, 클라이언트는 인증 토큰을 가지고 요청만 하는 방식
• 클라이언트 시크릿 저장 방식 검토: 현재는 평문으로 저장되는데, 보다 안전한 방식 조사
• 클라이언트 연동 테스트: Unity REST 살펴보기

제출 코드(통과)

using System;

public class Solution {
    public int solution(int[] cards)
    {
        var opened = new bool[cards.Length];
        var max1 = 0;
        var max2 = 0;
        for (var i = 0; i < cards.Length; i++)
        {
            if (opened[i]) continue;
            opened[i] = true;
            var j = cards[i] - 1;
            var count = 1;
            while (!opened[j])
            {
                opened[j] = true;
                j = cards[j] - 1;
                count++;
            }

            if (count > max1)
            {
                max2 = max1;
                max1 = count;
            }
            else if (count > max2)
            {
                max2 = count;
            }
        }
        return max1 * max2;
    }
}

카드에 중복이 없기 때문에, 상자 관계를 그래프로 그리면 모든 상자가 루프를 만든다. (연결된 그래프의 일부만 루프에 갇히는 경우가 존재할 수 없음. 그러기 위해선 한 상자를 가리키는 상자가 여러 개여야 하기 때문) 따라서 이미 열려있는 상자가 속한 경로의 길이는 루프의 길이로 고정되어 변하지 않기 때문에 다시 볼 필요가 없다. 루프의 길이를 재면서 가장 긴 두 개만 남긴다. 만약 루프가 하나면 max2가 0으로 남기 때문에 자연스럽게 0을 반환하게 된다.

내부 루프 진입을 좀 더 깔끔하게 수정(로직엔 차이 없음)

using System;

public class Solution {
    public int solution(int[] cards)
    {
        var opened = new bool[cards.Length];
        var max1 = 0;
        var max2 = 0;
        for (var i = 0; i < cards.Length; i++)
        {
            if (opened[i]) continue;
            var j = i;
            var count = 0;
            while (!opened[j])
            {
                opened[j] = true;
                j = cards[j] - 1;
                count++;
            }

            if (count > max1)
            {
                max2 = max1;
                max1 = count;
            }
            else if (count > max2)
            {
                max2 = count;
            }
        }
        return max1 * max2;
    }
}

1. 코드카타

BFS를 활용하는 문제였는데, 어렵게 생각하다가 다소 시간을 많이 잡아먹었다. '최단경로를 찾는다'는 목표에 매몰되어 A* 알고리즘을 사용해보았는데, 알고리즘을 정확히 구현하지 못해서 처음 제출은 실패했었다. 연결된 노드 간 가중치(거리)가 모두 1이기 때문에, 굳이 A* 알고리즘이 필요하지 않았고, BFS 트리 구축만으로도 최단 경로를 얻어낼 수 있었다. 제출 성공 이후 A* 알고리즘도 올바르게 구현하여 통과했지만, 성능면에서는 BFS보다 불리하기 때문에 이 문제에서 적절한 풀이는 아니다.

지금까지의 경향을 보면 그래프 기반 문제에 약한 것 같아서, 해당 유형의 문제들을 조금 더 집중적으로 풀어보려고 한다.

2. 최종 프로젝트

클라이언트는 거의 마무리 단계에 들어섰고, 나는 오늘부터 서버 설계를 맡게 되었다. 우리 게임에서, 서버가 맡아야 할 핵심 기능은 사용자 인증, 진행상황 저장/로드 기능 제공 및 클라이언트 조작 검증으로 잡아두었다.

현재 클라이언트와 비교적 무관한 사용자 인증 API를 구현 중이다. 계정은 명시적인 id/pw 입력 없이, 첫 접속 시 서버로부터 게스트 계정을 발급받아 클라이언트에 저장해두고, 이후부터 해당 계정으로 접속하는 방식을 택했다. 이렇게 하면 명시적인 로그인을 요구하지 않고 사용자를 구별할 수 있다. 추후 가능하다면 소셜 플랫폼 연동을 통한 로그인으로의 확장을 고려 중이다. (구글, 애플, 카카오 등)

저장 기능은 먼저 클라이언트에서 진행 상황 상태를 정의하는 방법을 결정짓고, 해당 구조에 맞게 서버가 값을 내려주는 방식으로 구현할 예정이다. 우리 게임에서의 핵심 정보는 업그레이드 노드 상태와 보유 골드량, 기존 최대 진행도(블랙홀 레벨) 정도로 구성된다. 노드 구매 요청 처리는 서버로 이관해야 하며, 구매 시점에는 "노드 구매 정보"만 반영되고, 실제 수치가 달라지지는 않는다. 수치 조립은 전투 시작 시 이루어진다. csv 파일 등 업그레이드 세부 정보 역시 서버가 원본을 가지고 있어야 하며, 클라이언트는 그걸 읽고 ui를 그리는 데에만 사용해야 한다.

클라이언트 조작 검증은 아직 그 강도를 확정짓지 못했다. 약하게는 전투 결과의 합리성 검증부터, 강하게는 결정론적 전투 시뮬레이션 재현까지 고려해볼 수 있다. 다만 후자의 경우 C#과 Java라는 환경 차이로 인해 두 세계에서 완벽히 동일한 결과를 재현하는 데에 한계가 있을 수 있고, 서버 부하가 커지며 싱글 플레이 게임에서 과한 구현이 될 수 있다. 지금은 전자와 후자의 중간 정도에 위치한, 이벤트 로그 검증 방식 정도가 적정선이라고 생각하고 있는데, 적정선에 대해서는 실무 경험이 있으신 튜터님들께 조언을 구해보는 게 좋을 것 같다.

내일 학습할 내용

• 최종 프로젝트 서버 API 명세 구축
  • 유저 로그인(인증) - 게스트 기반
  • 세이브 구조 확인 및 DB 저장 스키마 기획
• 외부 Unity 팀프로젝트 개발
  • 절차적 맵 생성기 개선

첫 제출(실패)

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(string[] maps)
    {
        (int x, int y) s = (-1, -1);
        (int x, int y) l = (-1, -1);
        (int x, int y) e = (-1, -1);

        for (var i = 0; i < maps.Length; i++)
        {
            for (var j = 0; j < maps[i].Length; j++)
            {
                switch (maps[i][j])
                {
                    case 'S': s = (i, j); break;
                    case 'L': l = (i, j); break;
                    case 'E': e = (i, j); break;
                }
            }
        }

        var toLever = Calc(maps, s, l);
        if (toLever == -1) return -1;
        var toExit = Calc(maps, l, e);
        if  (toExit == -1) return -1;
        return toLever + toExit;
    }

    private int Calc(string[] maps, (int x, int y) from, (int x, int y) to)
    {
        (int x, int y) size = (maps.Length, maps[0].Length);
        var nexts = new PriorityQueue<(int x, int y), int>();
        nexts.Enqueue(from, Manhattan(from, to));

        var visited = new bool[size.x, size.y];
        var dists = new int[size.x, size.y];

        while (nexts.Count > 0)
        {
            var now = nexts.Dequeue();
            visited[now.x, now.y] = true;
            if (now == to) return dists[now.x, now.y];

            var currentDist = dists[now.x, now.y];
            var candidates = new[]
            {
                (now.x - 1, now.y),
                (now.x + 1, now.y),
                (now.x, now.y - 1),
                (now.x, now.y + 1)
            };

            foreach (var (x,y) in candidates)
            {
                if (x < 0 || x >= size.x || 
                    y < 0 || y >= size.y || 
                    visited[x, y] ||
                    maps[x][y] == 'X') continue;

                dists[x, y] = currentDist + 1;
                var priority = dists[x, y] + Manhattan((x, y), to);
                nexts.Enqueue((x, y), priority);
            }
        }

        return -1;
    }

    private int Manhattan((int x, int y) from, (int x, int y) to)
    {
        return Math.Abs(from.x - to.x) + Math.Abs(from.y - to.y);
    }
}

A* 알고리즘으로 해결하려고 했는데, 단순히 알고리즘을 잘못 구현해서 실패했다. A* 알고리즘은 같은 위치를 한 번 방문한다고 끝나면 안되고, 더 짧은 경로가 발견되면 갱신해주어야 한다.

사실 이 문제는 굳이 최단 경로 알고리즘을 사용할 필요는 없었다. 가중치가 없기 때문에, 단순히 시작 지점을 기준으로 BFS 트리를 만들어주면 모든 칸까지의 최단 경로 트리가 완성이 된다.

수정된 코드(통과)

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(string[] maps)
    {
        (int x, int y) s = (-1, -1);
        (int x, int y) l = (-1, -1);
        (int x, int y) e = (-1, -1);

        for (var i = 0; i < maps.Length; i++)
        {
            for (var j = 0; j < maps[i].Length; j++)
            {
                switch (maps[i][j])
                {
                    case 'S': s = (i, j); break;
                    case 'L': l = (i, j); break;
                    case 'E': e = (i, j); break;
                }
            }
        }

        var toLever = Calc(maps, s, l);
        if (toLever == -1) return -1;
        var toExit = Calc(maps, l, e);
        if  (toExit == -1) return -1;
        return toLever + toExit;
    }

    private int Calc(string[] maps, (int x, int y) from, (int x, int y) to)
    {
        (int x, int y) size = (maps.Length, maps[0].Length);
        var nexts = new Queue<(int x, int y)>();
        var visited = new bool[size.x, size.y];
        var dists = new int[size.x, size.y];

        nexts.Enqueue(from);
        visited[from.x, from.y] = true;

        while (nexts.Count > 0)
        {
            var now = nexts.Dequeue();
            if (now == to) return dists[now.x, now.y];

            var candidates = new[]
            {
                (now.x - 1, now.y),
                (now.x + 1, now.y),
                (now.x, now.y - 1),
                (now.x, now.y + 1)
            };

            foreach (var (x, y) in candidates)
            {
                if (x < 0 || x >= size.x || 
                    y < 0 || y >= size.y || 
                    visited[x, y] || 
                    maps[x][y] == 'X') continue;

                visited[x, y] = true;
                dists[x, y] = dists[now.x, now.y] + 1;
                nexts.Enqueue((x, y));
            }
        }

        return -1;
    }
}

물론, A* 알고리즘도 올바르게 쓰면 통과할 수 있다. 더 이상 방문 기록은 없고, 대신 처음에는 거리가 무한(여기선 int를 사용하니 int.MaxValue로 대체)한 것으로 초기화하고, 더 짧은 경로가 나타날때마다 갱신해주는 방식을 써야 한다.

아래 코드로도 통과는 했지만, BFS보다 수행 시간이 오래 걸렸다. 알고리즘 자체가 더 무겁기 때문에 당연한 결과. 핵심적인 원인은 우선순위 큐가 단순 큐보다 삽입/삭제 복잡도가 높다는 것이다.

올바른 A* 알고리즘 코드

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(string[] maps)
    {
        (int x, int y) s = (-1, -1);
        (int x, int y) l = (-1, -1);
        (int x, int y) e = (-1, -1);

        for (var i = 0; i < maps.Length; i++)
        {
            for (var j = 0; j < maps[i].Length; j++)
            {
                switch (maps[i][j])
                {
                    case 'S': s = (i, j); break;
                    case 'L': l = (i, j); break;
                    case 'E': e = (i, j); break;
                }
            }
        }

        var toLever = Calc(maps, s, l);
        if (toLever == -1) return -1;
        var toExit = Calc(maps, l, e);
        if (toExit == -1) return -1;

        return toLever + toExit;
    }

    private int Calc(string[] maps, (int x, int y) from, (int x, int y) to)
    {
        (int x, int y) size = (maps.Length, maps[0].Length);

        var dists = new int[size.x, size.y];
        for (int i = 0; i < size.x; i++)
        {
            for (int j = 0; j < size.y; j++)
            {
                dists[i, j] = int.MaxValue;
            }
        }

        var nexts = new PriorityQueue<(int x, int y), int>();

        dists[from.x, from.y] = 0;
        int startPriority = dists[from.x, from.y] + Manhattan(from, to);
        nexts.Enqueue(from, startPriority);

        while (nexts.Count > 0)
        {
            var now = nexts.Dequeue();

            if (now == to) return dists[now.x, now.y];

            var candidates = new[]
            {
                (now.x - 1, now.y),
                (now.x + 1, now.y),
                (now.x, now.y - 1),
                (now.x, now.y + 1)
            };

            foreach (var (x, y) in candidates)
            {
                if (x < 0 || x >= size.x || 
                    y < 0 || y >= size.y || 
                    maps[x][y] == 'X') continue;

                int newDist = dists[now.x, now.y] + 1;

                if (newDist < dists[x, y])
                {
                    dists[x, y] = newDist;
                    int priority = newDist + Manhattan((x, y), to);
                    nexts.Enqueue((x, y), priority);
                }
            }
        }

        return -1;
    }

    private int Manhattan((int x, int y) from, (int x, int y) to)
    {
        return Math.Abs(from.x - to.x) + Math.Abs(from.y - to.y);
    }
}

1. 코드카타

최근 며칠 레벨 5 문제가 순조롭게 풀려서, 레벨 6의 첫번째 문제를 풀어봤다. 하노이탑 문제였는데, 난이도를 떠나서 너무 널리 알려진 문제라 그런지 오히려 더 쉽게 풀어낸 것 같다. 굳이 따지자면 신경썼던 부분은 재귀 호출마다 새 배열을 만들지 않고, 처음부터 총 시행 횟수를 미리 계산해서(점화식으로 일반항 도출) 한번만 할당한 점.

2. Spring 심화 완강

챕터 4까지 모두 들었다. 챕터 4는 전반적으로 실습보다는 클라우드 컴퓨팅, 운영 및 배포의 여러 요소들을 가볍게 소개하는 내용에 가까웠다. 최종 프로젝트 배포 환경을 구성하는 데에 활용할 수 있기를 기대하지만, 당장은 다소 막연한 느낌이라 서버 앱 개발 후 직접 실습해보며 배워가야 할 것 같다.

3. 최종 프로젝트 MVP 발표

다른 팀의 MVP 발표를 구경할 수 있었다. 뱀서라이크, 파티/보드게임이 많이 보였다. 우리 조의 진행 상황 및 클라이언트 완성도가 나쁘지 않다는 생각이 들었다. 아트 부담이 적은 추상적 미니멀리즘 그래픽을 레퍼런스로 택한 것이 좋았던 것 같다. 마피아 게임을 개발하는 팀은 서버를 벌써 구축하기까지 해서 인상적이었다.

내일(연휴간) 학습할 내용

• 최종 프로젝트 클라이언트 개발
  • 블랙홀 성장도 관련 시스템 구조 수정
  • 전투 세션 구축 구조 점검 및 개선
  • (가능하다면) 서버 구축 계획
• Unity 외부 팀 프로젝트 개발
  • 절차적 맵 생성 로직 구체화
    • 스폰 지점 근처 강제 지형 규칙
    • 여러 종류의 타일을 경계를 구분짓지 않고 이어지게 설치하는 오토타일 규칙
    • (선택) 인위적 지형 추가

지리적 제약 없이 전 세계 사용자에게 웹 콘텐츠를 빠르고 안전하게 전송하기 위해 분산 배치된 서버 네트워크

• 전 세계 분산된 서버에 콘텐츠를 복사해두고, 사용자와 가장 가까운 서버에서 응답
• 정적 파일(이미지 등)은 누가 요청해도 같은 내용
  • 미국, 유럽, 아시아 등 곳곳에 미리 복사해두면, 사용자는 가까운 서버에서 응답을 받아 물리적 거리에 따른 지연을 최소화

CloudFront

AWS의 CDN 서비스

• 전 세계 750개 이상 지역에 배치된 캐시 서버
• 일종의 프록시
  • S3에 직접 접근하지 못하고, CloudFront를 거쳐 접근하게됨
  • 보안에서의 이점
• 일반적으로, 같은 지역이라고 해도 S3에서 파일을 가져오는 것보다 CloudFront에서 데이터를 가져오는 것이 훨씬 빠르고, 비용도 효율적

AWS 리소스들의 상태를 수집하고 모니터링하는 서비스

핵심 개념

• Metric: 시간에 따라 변하는 숫자(CPU 사용률, 요청 수)
• Log Group: 로그 저장 단위
• Dashboard: 지표 시각화 화면

Alarm

특정 지표에 기준을 설정해두고 자동화된 대응 조치를 수행하는 것

예시

• 'CPU 사용률이 80%를 넘으면 즉시 담당자 슬랙이나 이메일로 경고를 보내라'
• '트래픽이 폭주하면 자동으로 서버를 여러 대 더 띄워라(Auto Scaling)'

CloudWatch 지표 확인 예

트래픽을 받아 서버에 분배하는 장치

(Target은 EC2 혹은 Fargate 등)

• EC2 IP를 직접 노출하지 않음 (프록시)
• HTTPS 처리
• 헬스체크
• 서버 확장 용이

ALB (Application Load Balancer)

AWS의 관리형 로드 밸런서(ELB, Elastic Load Balancer) 중 하나 HTTP를 이해하는 어플리케이션 전용 로드 밸런서

• 헬스체크: /actuator/health 등으로 수행
• HTTPS: ACM 인증서 연동으로 수행

개발자가 서버 인프라를 직접 관리하거나 설정할 필요가 없는 클라우드 컴퓨팅 모델 개발자는 코드 작성과 비즈니스 로직에만 집중할 수 있음 서버가 없다는 뜻이 아니다!

AWS Fargate

AWS의 서버리스 컴퓨팅 서비스 EC2처럼 인스턴스를 직접 프로비저닝/관리할 필요 없이 컨테이너를 바로 실행할 수 있게 해줌

• Docker가 내장되어 있음
• SSH(.pem)같은 방식으로 서버 내부에 접속할 수 없음
  • 서버가 존재는 하지만, 관리할 수 없음

반드시 Fargate가 더 좋은 것은 아님!

• 간편하게 백엔드 앱을 띄운다면: Fargate
• 게임 데디케이트 서버 등: EC2

다른 AWS 서버리스 서비스

• AWS S3
• AWS Lambda
• AWS DynamoDB
• Amazon Aurora Serverless
• AWS EventBridge
• ...

Launch Template 기반으로 EC2를 자동 생성/삭제/관리하는 서비스

Launch Template이란?

ASG가 EC2를 만들 때 사용하는 설계도

• 어떤 OS를 사용할지(Amazon Linux 2023)
• 어떤 사양인지(t4g.small)
• 어떤 트래픽을 허용할지(보안 그룹)
• 어떤 AWS 권한을 가질지(IAM)
• EC2 시작 시 실행할 스크립트(User Data)

핵심 설정

• Desired: 지금 유지하고 싶은 인스턴스 수(인스턴스 장애 시 새 EC2 생성)
• Min: 최소 인스턴스 수(트래픽 줄면 Min 수준까지 인스턴스 제거)
• Max: 최대 인스턴스 수(부하 발생 시 Max 범위 내에서 자원 추가)

프라이빗 서브넷 내의 인스턴스가 외부 인터넷과 통신할 수 있도록 네트워크 주소 변환(NAT)을 수행하는 클라우드 네트워킹 서비스

• 아웃바운드 전용: 프라이빗 서브넷 내부에서 외부 인터넷을 호출할 수는 있지만, 외부 이넡넷에서 프라이빗 서브넷 내부 인스턴스에 접속할 수는 없다.

Zonal Gateway, Regional Gateway

• Zonal NAT Gateway
  • 기존에 있던 방식
  • AZ마다 설정해주어야 함
• Regional NAT Gateway
  • 최신 버전
  • Region 전체를 커버하는 NAT Gateway
  • 하나만 만들면 별다른 설정 없이도 AWS가 AZ별로 알아서 확장해줌

ECR에서 Docker Image를 pull하기 위해서 NAT Gateway가 필요하다!

CI: 개발된 코드를 자동으로 빌드/테스트 (무결성 검증) CD: 완성된 앱을 실제 환경에 자동으로 배포

CI (Continuous Integration)

지속적인 통합 작업한 코드를 지속적으로 빌드 및 테스트하여 레포지토리에 통합(merge)하는 것

CD (Continuous Deployment)

지속적인 배포 통합된 코드를 지속적으로 릴리스하여 운영 환경에 배포(deploy)하는 것

• Continuous Delivery라고도 쓰인다

ECR (Elastic Container Registry)

AWS에서 제공하는 Docker 이미지 저장소

• 한 쪽에서 이미지 push, 다른 쪽애서 pull하여 실행

• Docker Hub 등 외부 저장소를 사용할 때와 달리, 별도의 인증(로그인) 없이 이미지를 가져올 수 있다. (IAM으로 권한 관리)

• 기존 실습: .jar를 직접 EC2로 옮김

• 실무: Docker 이미지를 통해 배포

• Docker 이미지 전용 S3라고 생각해도 된다.

  • 도커 이미지 전용 저장소가 없다면, S3에 이미지를 올리고 그걸 EC2에서 가져다 사용하는 방식도 가능할 것이다.

사실 ECR이 내부적으로는 S3와 같다. (S3를 래핑해서 도커 이미지 전용으로 만든 것)

Github Actions

코드 push를 트리거로 자동으로 무언가를 실행하도록 하는 도구 빌드/배포 자동화 가능

• 로컬에서 ./gradlew bootJar 실행
• docker build 실행
• docker tag 실행
• ECR 로그인
• docker push 실행

Github Actions를 사용하면 항상 일관된 절차로 실수 없이 테스트 및 배포를 진행할 수 있다.

코드를 push하면, GitHub Actions에서 자동 테스트, 빌드, Docker Image 생성, ECR에 Docker Image push까지 자동으로 이루어지도록 할 수 있다.

핵심 용어

• Workflow: 자동화 작업 전체를 정의한 파일
• Job: 워크플로우 안에서 독립적으로 실행되는 작업 단위
• Step: 잡 안에서 순서대로 실행되는 명령어
• Runner: 실제로 명령어를 실행하는 서버(Github 제공)

실행 흐름

1. 코드 push
2. GitHub이 Workflow 파일 발견
3. Runner (임시 서버) 생성
4. Job 시작 (Step 순서대로)
5. 결과 리포트 (성공/실패)
6. Runner 삭제

제출 코드(통과)

using System;

public class Solution {
    public int[,] solution(int n)
    {
        var size = Power(2, n) - 1;
        var answer = new int[size, 2];
        Iter(n, 0, 1, 3, answer);
        return answer;
    }

    private static int Power(int baseNum, int exp)
    {
        var result = 1;
        for (var i = 0; i < exp; i++)
            result *= baseNum;
        return result;
    }

    private int Iter(int n, int step, int from, int to, int[,] answer)
    {
        if (n == 1)
        {
            answer[step, 0] = from;
            answer[step, 1] = to;
            return step + 1;
        }

        var nextTo = 6 - from - to;
        var next = Iter(n - 1, step, from, nextTo, answer);
        answer[next, 0] = from;
        answer[next, 1] = to;
        next++;
        return Iter(n-1, next, nextTo, to, answer);
    }
}

전형적인 재귀 문제 중 하나인 하노이 탑이다. 총 시행 횟수의 점화식이 x(n+1) = 2x(n) + 1이므로 일반항은 x(n) = 2^n - 1이다. 크기부터 계산해 전체 배열을 한 번 할당하고, 내부를 채워나가는 방식으로 작성했다.

1. 코드카타

원형 큐 개념을 이용하는 문제였고, 큰 문제 없이 해결하였다. 최근 며칠간의 문제가 비교적 쉽게 해결되고 있는데, 5레벨 치고 쉬운 문제들이었던 건지 실력이 늘어서인건지 아직 잘 모르겠다. 우선 스택/큐를 메인으로 활용하는 문제는 어느 정도 해결이 가능한 것 같다. 순차적으로 계속 풀기보단, 6레벨로 넘어가거나 다른 유형의 문제를 더 찾아보는 것도 좋을 것 같다.

2. Spring 심화 챕터 3

챕터 3 마지막 항목인 Webcraft 배포 실습을 진행했다. EC2, RDS, Elasticache, Parameter Store를 모두 활용하여 배포 환경에 자바 서버 앱을 올리고, 환경변수를 분리하여 주입하도록 했다. 연결 과정에서 암호화 관련 작은 이슈가 있었다. 로컬 환경에선 암호화 없이 통신하더라도, 배포 환경에선 암호화를 반드시 사용하여야 한다.

챕터 4는 아직 듣지 못했다. 내일 발표 후 약간의 여유가 있으니 내일은 정말 수강하려고 한다.

3. 최종 프로젝트 MVP

게임의 겉모습은 어느 정도 완성되었다. 나는 git 병합 요청에 대한 리뷰 및, 적 파괴 특수 효과 구조화 및 시각화를 맡아 진행하였다.

반복 게임의 핵심이 되는 업그레이드 노드 구현이 필요하고, 핵심적인 시스템 구현에서 역기획 내용과 다른 점이 있어 해당 부분을 수정해야 한다.

내일 학습할 내용

• 클라이언트 개발 발표 준비
• 적 생성 구조 점검 및 수정
• Spring 심화 챕터 4까지 진행(완강)

jar 빌드 (로컬)

과제로 제출한 버전이 아닌 제공된 버전을 사용한다.

설정 파일 확인 (application.properties)

spring.application.name=webcraft
spring.datasource.url=jdbc:mysql://${DB_HOST:localhost}:${DB_PORT:3306}/${DB_NAME:webcraft}?createDatabaseIfNotExist=true
spring.datasource.username=${DB_USERNAME:root}
spring.datasource.password=${DB_PASSWORD:12345678}
spring.jpa.hibernate.ddl-auto=update
spring.data.redis.host=${REDIS_HOST:localhost}
spring.data.redis.port=${REDIS_PORT:6379}
spring.data.redis.ssl.enabled=${REDIS_SSL:false}

webcraft.chat.pubsub-enabled=true

• 기본적으로 로컬의 DB를 사용하도록 Fallback 설정이 되어있다.

보안그룹 생성

RDS 생성

이전 실습과 달리, 프라이빗 서브넷으로만 서브넷 그룹을 구성한다. 외부 액세스를 허용하지 않고, 앞서 생성한 db용 보안그룹을 할당해준다. 이렇게 하면 webcraft-app 보안 그룹을 할당받은 EC2에서만 RDS에 접근이 가능해진다.

Elasticache 생성

이전 실습과 동일한 세팅으로 생성(Elasticache는 이전에도 프라이빗 액세스만 가능하도록 생성하였음) 단, 보안그룹은 RDS와 마찬가지로 webcraft-app으로 지정해야 함

EC2 설정

자세한 방법은 이 글 참조

기존 설정 유지

• AMI: Amazon Linux 2023 (Arm)
• 인스턴스: t4g.small
• 퍼블릭 IP 자동 할당

보안 그룹 수정

키 페어 교체

1. 새로운 키페어 생성

2. 공개 키값 확인

3. 기존 키페어로 접속, 편집기로 .ssh/authorized_keys 열기

4. 기존 값 제거 후 새 공개키 값으로 교체

5. 기존 키로는 접속되지 않고, 새 키로 접속이 가능한 것을 확인

jar EC2에 올리기

자세한 방법은 이 글 참조

• 이전 실습에서 올린 app.jar는 삭제하였음

Parameter Store 설정

자세한 방법은 이 글 참조

• application.properties에 정의되어있던 모든 환경변수들에 대해 파라미터를 설정

앱 실행

파라미터를 Parameter Store에서 가져와 환경변수로 주입한 뒤 앱을 실행한다.

#!/bin/bash

# 1. AWS Systems Manager Parameter Store에서 설정값 불러오기
export DB_HOST=$(aws ssm get-parameter --name "/webcraft/prod/DB_HOST" --query "Parameter.Value" --output text)
export DB_PORT=$(aws ssm get-parameter --name "/webcraft/prod/DB_PORT" --query "Parameter.Value" --output text)
export DB_NAME=$(aws ssm get-parameter --name "/webcraft/prod/DB_NAME" --query "Parameter.Value" --output text)
export DB_USERNAME=$(aws ssm get-parameter --name "/webcraft/prod/DB_USERNAME" --query "Parameter.Value" --output text)
export DB_PASSWORD=$(aws ssm get-parameter --name "/webcraft/prod/DB_PASSWORD" --query "Parameter.Value" --output text)

export REDIS_HOST=$(aws ssm get-parameter --name "/webcraft/prod/REDIS_HOST" --query "Parameter.Value" --output text)
export REDIS_PORT=$(aws ssm get-parameter --name "/webcraft/prod/REDIS_PORT" --query "Parameter.Value" --output text)
export REDIS_SSL=$(aws ssm get-parameter --name "/webcraft/prod/REDIS_SSL" --query "Parameter.Value" --output text)

# 2. 불러온 환경 변수를 적용하여 애플리케이션 실행
java -jar webcraft.jar

결과

다중 접속까지 이루어지는 것을 확인할 수 있었다.

트러블슈팅: REDIS_SSL

• 위 스크립트로 스프링 앱 실행 시 Redis 연결 타임아웃이 발생했다.

RedisCommandTimeoutException: Connection initialization timed out after 1 minute(s)

• nc -zv 테스트 결과 EC2에서 ElastiCache 6379 포트로의 네트워크 통신은 정상이었으나, ElastiCache에 설정된 암호화 방식과 애플리케이션의 접속 방식이 일치하지 않아 핸드셰이크 단계에서 응답이 멈춘 것으로 파악되었다.

• 문제는 REDIS_SSL을 false로 주입했다는 것이다. 옵션을 false로 두면 일반 Plain TCP로 연결을 시도하고, true일 경우 TLS 기반 암호화 터널로 접속을 시도한다.

• Elasticache는 전송 중 암호화 옵션이 활성화 되어 있었다.

• 이 경우 Elasticache는 TLS 연결 요청만 수락한다. 따라서 클라이언트가 평문 패킷을 보내면 응답하지 않아 타임아웃이 발생했던 것이다.

• Parameter Store에서 해당 값을 true로 수정하여 문제를 해결하였다.

• 기존 Fallback은 로컬 환경을 상정한 것이라 암호화 없는 옵션으로 설정되어있던 것으로 보인다. 배포 환경에서는 암호화된 통신을 활성화하는 것이 일반적이다.

제출 코드(통과)

using System;

public class Solution {
    public int solution(int[] queue1, int[] queue2)
    {
        var queue = new int[queue1.Length + queue2.Length];
        queue1.CopyTo(queue, 0);
        queue2.CopyTo(queue, queue1.Length);

        long sum1 = 0;
        foreach (var i in queue1) sum1 += i;
        long sum2 = 0;
        foreach (var i in queue2) sum2 += i;
        var sum = sum1 + sum2;
        if (sum % 2 != 0) return -1;

        var index1 = 0;
        var index2 = queue1.Length;


        var answer = 0;

        while (sum1 != sum2 && answer < queue.Length * 2)
        {
            if (sum1 > sum2)
            {
                var num = queue[index1];
                sum1 -= num;
                sum2 += num;
                index1 = (index1 + 1) % queue.Length;
            }
            else
            {
                var num = queue[index2];
                sum1 += num;
                sum2 -= num;
                index2 = (index2 + 1) % queue.Length;
            }

            answer++;
        }

        return sum1 == sum2 ? answer : -1;
    }
}

한 쪽 큐에서 꺼낸 걸 즉시 다른 쪽 큐에 넣어야 하므로, 둘을 하나의 원형 큐로 이은 뒤 인덱스를 옮기는 것으로 작업 하나를 나타낼 수 있다. index1에서 index2-1까지는 첫 번째 큐, 나머지는 두 번째 큐로 간주된다. 완성될 수 없음을 판단하는 작업 상한은 두 인덱스가 한 바퀴를 돌아 원래 자리로 돌아오는 경우, 즉 전체 길이의 2배 횟수만큼 작업을 수행하는 경우로 설정했다. 더 타이트한 상한이 있을 수도 있겠지만, 우선은 이걸로 충분했다.

1. 코드카타

투포인터를 사용한 비교적 간단한 문제였고, 문제 조건(동일한 조건일 경우 가장 먼저 나온 답을 선택)을 놓쳐 한 번 실수한 것을 빼면 큰 시행착오 없이 해결할 수 있었다.

2. 최종 프로젝트

내가 맡은 부분은 플레이어 공격 효과(브레이커) 시각화였다. 스프라이트 없이 셰이더를 활용하였고, 시각화 자체는 큰 어려움 없이 진행되었다.

작업 중 버프 효과 구조 구현이 잘못되어있어 수정하였다. 중첩 가능하고, 각 효과가 갱신되지 않고 독립적으로 적용/종료되도록 큐 형태의 버프 홀더를 정의하였다. 버프 수치 책임을 적으로부터 플레이어로 옮기고, 수치 업그레이드 정의를 추가하였다.

Git 관련한 이슈가 있었고, 그나마 Git 협업에 익숙한 내가 협업 담당으로 작업 규칙 설정 및 관련 이슈 대응을 주로 맡았다.

우선 PR없이 dev 브랜치로 머지하는 것을 금지했다. 초기에 단순 merge로 병합하는 경우가 있었고, 브랜치 보호 규칙을 걸어 직접 수정을 금지하였다. 작업 인원이 많은 만큼, dev는 누가 언제 무엇을 수정했는지 명확한 기록을 남겨야 한다고 생각했기 때문이다. PR 템플릿은 레포 구축 시 함께 정의해두었기에 간단하게라도 작업 내용을 기록하도록 규칙을 정했다.

PR 시 반드시 본인의 브랜치에서 dev의 최신 상태를 받아와 충돌을 모두 해결한 뒤 커밋하도록 했고, 이를 통해 dev 브랜치에서 충돌이 발생하는 것을 막을 수 있었다.

다만 생각지 못한 문제가 있었는데, dev 병합 후 충돌 해결 과정에서 dev를 날리고 본인 코드만 반영해서 코드가 누락되는 사고가 있었다. 이후 팀원들에게 충돌 해결 원칙을 고지했다. (일반적인 코드 충돌의 경우 양측 다 적용, 한쪽을 지워야 한다면 명확한 이유를 보고할 것)

코드 리뷰를 제대로 하고 PR해야 한다는 점을 느꼈다. 기간이 촉박해 대강 확인하고 병합했고 사실상 코드 리뷰가 정상적으로 이루어지지 못했는데, 이번 사고는 결국 리뷰에서 잡아낼 수 있었던 문제였다.

내일 학습할 내용

• Spring 심화 챕터 4까지 진행(완강)
• 블랙홀 키우기 적 생성 구조 수정
• Unity 팀프로젝트(캠프와 별개) 내 담당 부분 작업하기 (스킬 효과 구현 등)

제출 코드(통과)

using System;

public class Solution {
    public int[] solution(int[] sequence, int k) { 
        var i = sequence.Length - 1;
        var j = sequence.Length - 1;
        var sum = sequence[j];
        while (i >= 0 && sum != k)
        {
            if (sum > k)
            {
                if (i == j)
                {
                    i--;
                    j--;
                    sum = sequence[i];
                }
                else
                {
                    sum -= sequence[j--];
                }
            }
            else
            {
                sum += sequence[--i];
            }
        }

        while (i > 0 && sequence[i - 1] - sequence[j] == 0)
        {
            i--;
            j--;
        }

        return [i, j];
    }
}

비교적 간단한 투포인터 문제였다. 문제 조건 덕에 예외처리를 고려할 필요가 없어서 더욱 쉬웠다. 비내림차순 배열이므로 뒤에서부터 구간을 탐색하면 첫 번째로 발견한 부분 수열이 곧 최소 길이가 된다. 거기서 구간 길이를 유지하면서 합이 일정하도록 앞으로 이동할 수 있다면 (그러려면 배열 내부 및 그 앞 칸 원소의 값이 모두 같아야 한다.) 구간을 앞으로 한 칸씩 당긴다.

1. 코드카타

특정 알고리즘/자료구조를 이용하기보다는 논리 수학 문제를 풀듯이 해결하는 문제였다. 달팽이 모양으로 나열한 숫자를 다시 일자 배열로 펼쳤을 때의 모습을 계산하는 문제였고, 나는 숫자 순서대로 일자 배열 속에서 들어갈 위치를 찾는 방식으로 문제를 해결했다. locality 관점에서는 효율적이지 못한 방식이지만, 배열 인덱스 순서대로 거기에 들어갈 숫자를 계산하는 방법을 떠올리지 못했다. 입력의 최대 크기도 1000으로 작기 때문에 문제 없이 통과할 수 있었다.

2. Spring 심화 챕터 3

챕터 3의 마지막 강의를 제외하고 완강했다. 마지막 강의는 그전에 다룬 AWS 활용법을 토대로 이전 프로젝트 과제였던 Webcraft를 배포해보는, 과제 성격의 강의였다. 캠프 시간 상 곧바로 수행하기 어려울 것 같아 내일 진행하려고 한다.

오늘은 AWS의 DB 서비스에 대해 배웠다. 후술할 컴퓨터공학 특강에서도 강조된 내용으로, Stateless한 서버를 만들기 위해 서버(EC2) 안에 DB를 두지 않고 별도의 DB 클라우드 서비스를 활용해야 한다. 서버와의 책임을 분리하고, 서버의 확장성을 용이하게 하여 유지 관리에도 이점이 있고, 장애 대응 역시 유연하게 가능하기 때문이다.

기존의 MySQL에 대응되는 서비스인 RDS와 Redis에 대응되는 서비스인 Elasticache를 Spring 서버에 연동해서 사용하는 방법을 배웠는데, 아직은 기초적인 실습만 해봤기에 내일 배포 실습을 통해 더 잘 이해해보려고 한다.

3. 컴퓨터공학 특강: 게임 서버 아키텍쳐

실제 온라인 게임을 운영할 때 서버 구조를 어떻게 설계하고 확장하는지에 대해 배울 수 있었다. 서버의 수평 확장성(스케일아웃)을 위해 무상태로 구현하는 것이 중요하고, DB는 데이터(상태)를 담고 있는 것이 필연적이라 서버와 달리 무한정 확장하는 것이 어렵다. 조회 성능을 위해 병렬로 배치하는 Replication에 대해서는 알고 있었는데, 아예 특정 기준으로 데이터를 나눠서 보관하는 Shading에 대해서는 새롭게 배웠다. 대규모 게임에서 서버를 나누는 방식이 샤딩이라는 걸 알게 되었고, 서버 간 통합 컨텐츠(거래 등)가 구현하기 어려운 이유가 물리적으로 별도의 DB에 있기 때문이라는 걸 이해할 수 있었다.

부수적으로 메시지 큐나 MSA, 모니터링, 장애 대응 등 대규모 게임을 운영하는 데 있어 필요한 지식들을 접할 수 있었다. 자세히 다루지는 않았지만, 이러한 개념이 있다는 걸 알고 있는 것만으로도 의미가 있다고 느꼈다. 우리 최종 프로젝트는 멀티 게임도 아니고 아주 규모가 작게 만들어지겠지만, 학습 목적으로 이런 요소들을 적용해볼 수 있을 것 같다.

4. 최종 프로젝트 주제 확정

최종 결정까지 난항이 있었지만, 결국 기존에 잡은 레퍼런스를 그대로 밀고 나가기로 했다. 규모가 작은 게임을 고른 대신, 완벽하게 해당 게임을 복제해내는 것을 목표로 잡았다. 클라이언트 레벨에서는 특히 시각적인 연출 요소를 다듬는 것이 중요할 것 같고, 서버 레벨에서는 클라이언트 검증을 핵심적인 기능으로 잡고 개발해나가면 좋을 것 같다. 만약 오늘 배운 서버 아키텍쳐 요소들을 작게나마 적용해볼 수 있다면 조금 더 포트폴리오로써 가치있는 결과물이 나올 것 같다. 적어도 서버의 무상태 유지 등 핵심적인 원칙만큼은 신경써서 개발해보려고 한다.

내일 학습할 내용

• Spring 심화 챕터 4까지 진행(완강)
• 블랙홀 키우기 브레이커 시각 효과 구현
  • 기본 및 타격 애니메이션
  • 달 버프 및 혜성 버프 시각 효과
• Unity 팀프로젝트(캠프와 별개) 내 담당 부분 작업하기 (스킬 효과 구현 등)

앱을 운영 환경에서 안정적으로 운영하려면 Stateless 패턴이 중요!

• 서버 유지 보수성
• 서버 확장성

Stateless 패턴의 핵심

1. 앱은 언제든지 교체 가능하게
2. 데이터는 외부에

S3와 RDS, Elasticache를 이용한 상태 분리

Stateful	Stateless

S3

Simple Storage Service

구조 예시

s3://my-app-bucket/
    ├── uploads/                       
    │   ├── profile/user1.jpg          
    │   └── docs/report.pdf            
    └── static/
        └── logo.png                   

• 버킷: 파일을 담는 저장소 컨테이너(폴더)
• 오브젝트: 저장된 파일 자체(파일)
• 키: 오브젝트의 고유 경로/이름(파일 경로)

user1.jpg에 접근할 때, uploads/profile/user1.jpg 전체가 하나의 키로 쓰인다.

버킷의 종류

• 범용 버킷
• 디렉터리 버킷
• 테이블 버킷
• 벡터 버킷

보편적으로 범용 버킷을 사용한다. (다른 버킷은 특수한 용도에 최적화된 형태라, 해당 목적 이외에는 거의 사용되지 않는다)

S3 보안

1. 퍼블릭 액세스 차단

기본적으로 모든 퍼블릭 접근을 차단

• 버킷 생성 시 기본값으로 적용 (따로 안건드려도 됨)
• 과거 퍼블릭 버킷으로 대량의 데이터가 유출된 사고 사례가 있음
  • 2017년: 미국 유권자 1억 9천만 명 데이터 노출
  • 2019년: 페이스북 사용자 5억 4천만 명 데이터 노출

ACL(Access Control List)

• 버킷/오브젝트별 접근 권한을 설정하는 기능
• 레거시 방식으로, 현재는 IAM 정책 사용 권장

2. 최소 권한

필요한 권한만 부여

• 기본적인 보안 원칙

버킷 생성 실습

• 버킷 이름: camp-health-p4ngmin-files
• 글로벌 네임스페이스로 생성
  • 계정 리전 네임스페이스는 비교적 최근에 추가된 새 방식
  • 큰 차이는 없고, 이름 규칙 관련한 내용이 다른 것으로 보임
  • 기존 방식인 글로벌 네임스페이스가 보다 널리 쓰이고 자료가 많아 이걸로 진행
• 모든 퍼블릭 액세스 차단
  • 이미 기본값으로 설정되어 있으니 건드리지 않고 확인만

• 이제 파일 수동 업로드 가능 (다른 클라우드 스토리지 서비스처럼 사용할 수도 있다)

Presigned URL

임시로 접근을 허용하는 서명된 URL

• 유효 시간 설정 가능
• 유효 시간 내에는 누구나 해당 URL로 접근 가능

S3 버킷은 기본적으로 퍼블릭 액세스 차단이 되어있어(프라이빗 버킷), URL로 직접 접근할 수 없다.

Spring 연동: AWS 의존성 통합 관리

이전에 Parameter Store를 연동할 때와 같이, S3도 의존성을 필요로 한다.

이때, Parameter Store와 S3는 모두 aws에서 제공하는 서비스인데, 의존성 버전을 따로 명시하면 관리가 번거롭다. 버전 업그레이드 시 여러 의존성을 함께 수정해야 하고, 실수할 경우 버전이 달라 충돌할 수도 있다.

// 버전을 각각 명시 - 관리가 어려움
implementation 'io.awspring.cloud:spring-cloud-aws-starter-parameter-store:0.0.0'
implementation 'io.awspring.cloud:spring-cloud-aws-starter-s3:0.0.0'

BOM (Bill Of Materials)

관련 의존성 라이브러리들의 버전을 한 곳에서 관리하는 명세서

// BOM으로 Spring Cloud AWS Starter 버전 통합 관리
implementation platform('io.awspring.cloud:spring-cloud-aws-dependencies:4.1.1-RC1')
implementation 'io.awspring.cloud:spring-cloud-aws-starter-parameter-store'
implementation 'io.awspring.cloud:spring-cloud-aws-starter-s3'

BOM을 불러와 버전을 명시해주면, 해당 명세서에 속한 의존성들은 자동으로 해당 버전으로 설정된다.

BOM도 Maven Repository에서 찾아서 사용하면 된다.

S3Template

Spring Cloud AWS가 S3Template를 빈으로 등록해주므로, DI해서 바로 사용 가능하다.

@RequiredArgsConstructor
public class XxxClass {
        private final S3Template s3Template; // DI
}

코드 한 줄로 간단히 파일을 업로드할 수 있다.

// 파일 업로드
s3Template.upload("my-bucket", "uploads/file.txt", inputStream);

실습용 사전 설정

• application.properties

  server.port=8080
  

AWS Region

spring.cloud.aws.region.static=ap-northeast-2

파일 업로드 크기 제한

spring.servlet.multipart.max-file-size=10MB

- `application-local.properties`
```yaml
# 버킷 이름
spring.cloud.aws.s3.bucket=camp-health-p4ngmin-files

• .gitignore에 application-local.properties 추가
  • 로컬 설정은 깃으로 관리되어선 안됨

    # properties
    application-local.properties

DTO 정의

@Getter
@RequiredArgsConstructor
public class FileUploadResponse {
    private final String key;
}

@Getter
@RequiredArgsConstructor
public class FileDownloadUrlResponse {
    private final String url;
}

서비스 클래스

@Service
@RequiredArgsConstructor
public class S3Service {
    private static final Duration PRESIGNED_URL_EXPIRATION = Duration.ofMinutes(10); // 서명 URL 유효 시간 10분

    private final S3Template s3Template; // DI해서 사용

    @Value("${spring.cloud.aws.s3.bucket}")
    private String bucket;

    public String upload(MultipartFile file) {
        try {
            String key = "uploads/" + UUID.randomUUID() + "_" + file.getOriginalFilename();
            // 파일명이 중복되지 않도록 랜덤한 UUID를 붙여서 사용
            // UUID는 긴 랜덤값을 O(1)로 생성할 수 있음
            // UUID 자체가 유일성을 보장하지는 않음
            // 이론상 겹칠 수도 있지만, 확률이 희박함
            s3Template.upload(bucket, key, file.getInputStream());
            return key;
        } catch (IOException e) {
            // 적절한 커스텀 예외로 바꾸고, GlobalExceptionHandler로 핸들링 필요
            throw new RuntimeException("파일 업로드 실패", e);
        }
    }

    public URL getDownloadUrl(String key) {
        return s3Template.createSignedGetURL(bucket, key, PRESIGNED_URL_EXPIRATION);
    }
}

컨트롤러 클래스

@RestController
@RequiredArgsConstructor
public class FileController {
    private final S3Service s3Service;

    @PostMapping("/files/upload")
    public ResponseEntity<FileUploadResponse> upload(@RequestParam("file") MultipartFile file) {
        String key = s3Service.upload(file);
        return ResponseEntity.ok(new FileUploadResponse(key));
    }

    @GetMapping("/files/download-url")
    public ResponseEntity<FileDownloadUrlResponse> getDownloadUrl(@RequestParam String key) {
        URL url = s3Service.getDownloadUrl(key);
        return ResponseEntity.ok(new FileDownloadUrlResponse(url.toString()));
    }
}

S3 연동 로컬 테스트

IAM 정책 생성

• S3CampHealthPolicy라는 이름으로 생성

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:PutObject", "s3:GetObject"],
            "Resource": "arn:aws:s3:::camp-health-p4ngmin-files/uploads/*"
        }
    ]
}

IAM 사용자 생성

• 생성 시 직전에 생성한 권한과 연결

액세스 키 생성

• 로컬 코드 용으로 생성

이 화면 이후 다시 확인할 수 없기에 복사해두어야 함

설정값(application-local.properties)에 액세스 키(환경 변수) 추가

spring.cloud.aws.credentials.access-key=AKIAROC57E2O6SYC3FF3
spring.cloud.aws.credentials.secret-key=...

Postman API 호출 테스트

트러블슈팅: 실행 프로필을 local로 설정해야 환경변수가 적용된다. 해당 설정을 누락하여 서버 앱 실행이 안되는 문제를 겪었다.

업로드할 파일

업로드 API 요청	다운로드 URL 요청

S3 확인

응답받은 서명 URL 접속	나중에(10분 이상 흐른 뒤) 재접속 시

RDS

EC2 DB vs RDS

MySQL RDS 인스턴스 생성

서브넷 그룹 생성

프라이빗 서브넷으로 설정해야 한다 현재는 로컬에서 해보는 간단한 실습이라 접근을 위해 퍼블릭 서브넷 그룹으로 생성한다

RDB 생성

• MySQL
• 퍼블릭 액세스 허용 (퍼블릭 서브넷과 별도로 설정해주어야 함)
• default 보안 그룹 (모든 트래픽 허용)
  • 여기서 모든 트래픽은 소스가 자기 자신인 경우에만 해당
  • MySQL 포트인 3306에 한해 모든 소스 허용하도록 규칙 추가
• 3306 포트 (기본 포트)
• 초기 데이터베이스 이름 (미리 CREATE DATABASE ... 하는 개념)

자바 프로젝트 생성, DB 접속 확인

이제 localhost가 아닌 aws rds 엔드포인트로 지정해주어야 함

트러블슈팅: AWS RDS 호스트 차단 에러 (Error 1129)

접속 시도 시 다음 에러 발생

Host '14.57.166.223' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'

원인 파악 아래는 AI가 파악한 문제 상황 시나리오이다.

• 드라이버 불일치로 인한 다량의 연결 실패: 최초 접속 시 IntelliJ에서 실제 RDS 엔진(일반 MySQL)과 맞지 않는 Amazon Aurora MySQL (AWS Wrapper) 드라이버를 선택한 상태로 접속을 시도했다. IntelliJ가 해당 드라이버를 제안했기에 해당
• 보안 임계값 초과: 호환되지 않는 드라이버와 잘못된 설정값으로 인해 단시간에 연속적인 접속 실패가 발생했다.
• 서버 측 IP 차단: MySQL은 보안을 위해 동일 IP에서 연속 실패 횟수가 임계값(max_connect_errors, 기본값 100회)을 넘으면, 해당 호스트를 비정상적인 공격 시도로 간주하고 자동으로 접속을 차단(Block)한다. 이후에 MySQL 드라이버로 접속을 시도했을 때도 동일한 에러가 발생한 것이 이 때문이다.

해결

• 드라이버 정상화: IntelliJ의 데이터베이스 드라이버를 일반 MySQL로 올바르게 수정했다.
• 호스트 캐시 초기화: AWS RDS는 OS CLI 접근이 불가능하므로, RDS 인스턴스를 재부팅하여 메모리에 남아있던 호스트 차단 블랙리스트 캐시를 초기화하여 해결했다.

RDS 연동 로컬 테스트

앱 실행은 로컬에서 하지만, 클라우드에 배포된 라이브 상황(prod 프로필)이라는 가정 하에 진행

환경 변수 주입

application.properties

spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQLDialect

application-prod.properties

• 각 항목에 실습용으로 생성한 RDS 정보를 입력

spring.datasource.url=jdbc:mysql://{RDS엔드포인트}:3306/{데이터베이스명}
spring.datasource.username={유저네임}
spring.datasource.password={비밀번호}
spring.jpa.hibernate.ddl-auto=validate

코드 작성

엔티티(User)

@Getter
@Entity
@Table(name = "users")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false)
    private String name;

    public User(String name) {
        this.name = name;
    }
}

UserRepository

public interface UserRepository extends JpaRepository<User, Long> {
}

UserService

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;

    @Transactional
    public void save() {
        User user = new User(
                UUID.randomUUID().toString()
        );
        userRepository.save(user);
    }
}

UserController

@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @PostMapping("/users")
    public void create() {
        userService.save();
    }
}

스키마 적용

• 라이브 환경에서는 spring.jpa.hibernate.ddl-auto를 create나 update가 아닌 validate로 둔다. 의도치 않은 테이블의 변경을 방지하기 위함이다.
• 현재 prod 프로필에서의 설정도 그렇게 되어 있으니, 이대로는 다음과 같은 에러 로그와 함께 실행이 멈춘다.

  SchemaManagementException: Schema validation: missing table [users]

따라서 다음 쿼리를 통해 User 엔티티에 맞는 스키마를 DB에 만들어줘야 한다.

CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL
);

개발 시 변경된 테이블 내역에 대해 운영 서버 DB에 변경분을 업데이트하는 것을 마이그레이션이라고 한다.

실행 후 Postman 테스트

헬스체크	유저 생성	생성된 유저 확인

Elasticache

RDS의 Redis 버전!

• AWS에서는 Redis와 호환되는 Valkey를 사용한다.
  • Redis는 구버전만 지원한다.

생성 실습

RDS와 다르게 퍼블릭 액세스 자체를 허용하지 않는다 따라서 이번엔 프라이빗 서브넷으로 그룹을 생성한다.

Elasticache 로컬 연동

실제 실습은 다음 강의에서 진행

환경 변수 주입

spring.data.redis.host={Valkey Endpoint}
spring.data.redis.port=6379
spring.data.redis.ssl.enabled=true