• 일본어 학원 다니며 일본어 습득하기
• 난생 처음으로 코딩테스트 보기
• AI를 활용한 프로젝트 만들어보기

크게 에피소드를 나누면 이렇게 해온거 같습니다. 그래서 요즘은 과연 개발자로써 벌어먹고 살 수 있을지가 가장큰 걱정 입니다.

저는 지금까지 여러가지 기술 블로그와 AI관련 영상 및 매체를 접근하면서 가장많이 들은말이 xx 없으면 살아남을 수 없다. , 개발자 및 기타 디지털 직종은 종말한다. 이런말을 끊임없이 듣다보니 어느순간 부터 스스로 마음안쪽에는 공포심이 자라기 시작했습니다. 그래서 시대를 따라가고자 프로젝트를 만들었습니다.

AI 프로젝트

프로젝트로 웹 HTML파싱 방식 크롤링을 하면 그 데이터를 AI로 분석 및 검증을 하고 만약 찾고자하는 데이터가 크롤러에 없으면 AI 데이터를 추가하는 그러한 프로젝트를 만들었습니다. Claude Code를 활용하여 금방 만들 수 있었습니다. 하지만 온전히 나만의 프로젝트라는 느낌은 없었습니다. 그저 나의 생각을 AI로 나타낸 것 뿐 주인의식이 없었습니다. 그래도 만들면서 바이브 코딩이라는 것을 해본 좋은 경험 이었습니다.

AI에 대한 생각

AI는 이제 우리 시대에 없어서는 안 될 필수적인 존재가 되었습니다. 누군가는 이를 '전기의 발견'과 같은 혁명이라 칭송하고, 누군가는 기술의 범람 속에서도 변하지 않는 인간만의 가치를 수호해야 한다고 말합니다. 솔직히 말해, 현재의 AI 열풍 속에는 과도한 '공포 마케팅'이 섞여 있다는 인상을 지우기 어렵습니다. AI의 능력이 뛰어난 것은 사실이나, '도태'나 '생존' 같은 자극적인 표현을 서슴지 않는 것은 분명 과장된 측면이 있습니다.

PC의 등장 ----> 인터넷의 등장 ---> 스마트폰의 등장 --> AI의 등장

우리는 이미 PC, 인터넷, 스마트폰으로 이어지는 거대한 기술적 변곡점들을 거쳐왔습니다. 과거의 혁신들이 효율적인 '도구'나 무한한 '공간'의 확장에 머물렀다면, AI는 우리의 일상에 깊숙이 침투하여 '노동과 생존'이라는 근본적인 개념을 흔들고 있습니다. 우리가 일하고 가치를 창출하는 방식 자체를 재정의하고 있기에, 이전의 기술 혁명보다 훨씬 더 강력한 충격으로 다가오는 것입니다.

AI와 자연에 대한 외면

AI 기술이 등장하기 전, 우리 사회의 화두는 단연 기후와 환경 문제였습니다. 하지만 AI 시대가 도래하면서 기후 위기는 어느덧 뒷전으로 밀려난 듯합니다. 기존 데이터 센터보다 막대한 에너지를 소비하는 AI 데이터 센터가 우후죽순 들어서고 있음에도, 이에 따른 환경적 책임에 대한 목소리는 점차 희미해지고 있습니다. 불과 3년 전만 해도 쉽게 접할 수 있었던 ‘기후 위기 시계’에 대한 소식조차 이제는 찾아보기 어렵습니다. 눈부신 기술 발전의 대가로 우리가 과연 무엇을 희생하고 있는지 깊이 고민해 보게 되는 시점입니다.

정리하기

생각보다 길다면 길고 짧다면 짧은 글이 되었습니다. 제가 결론적으로 생각하는 건 하나 입니다. AI 시대가 와도 우리가 살아가는건 변함이 없고 앞으로도 변함이 없다는 것 입니다. 우리의 일하는 방식이 달라질 뿐 근본적인것은 달라지지 않을겁니다. 숨을쉬어야 살 수 있고 밥을먹어야 에너지를 쓸 수 있는것은 당연하지만 너무 당연한 나머지 우리는 잊어버리고 있는게 아닌가 생각합니다.

개인적으로 진행하는 프로젝트에 기존에는 없었던 CI/CD를 구축하던 와중에 발생한 문제였습니다. 젠킨스를 설치하고 스크립트를 작성도 되었고 다좋았지만 서버오류 때문에 서버를 재부팅하였습니다. 그러고 다시 젠킨스에 접속해보니 눈에띄게 느려지는 현상이 발생했습니다. 이번에는 해당 상황이 어째서 생겼고 어떻게 해결했는지 그리고 어째서 일어난 현상인지 적어보겠습니다.

📘 젠킨스 실행 환경

젠킨스는 일단 AWS EC2환경에서 실행하고 있습니다. 별도로 고정 IP는 주지 않았습니다. 그래서 서버를 재부팅하면 IP가 재할당됩니다.

📗 문제원인 및 해결방법

결론부터 말하면 문제는 등록된 IP가 문제였습니다. 그래서 환경설정에서 세팅되어있는 IP를 수정하니까 정상적으로 동작하게 되었습니다.

1. 먼저 젠킨스 설정의 System으로 접속합니다.

2. Jenkins URL에 http://[서버주소]:[젠킨스 포트번호]/ 이렇게 넣어주고 저장버튼을 클릭하면 다시 정상적으로 빠르게 돌아가는걸 볼 수 있습니다.

문제원인

그래서 원인은 무엇인가 생각해보니 아무래도 Jenkins Location은 젠킨스가 위치한곳이 어디인지 알려주는 설정이라고 생각됩니다. 그래서 제 예상으로는 내부적으로는 설정된 URL을 찾는중 timeout이 되었고 외부로 나가서 다시 찾는 작업을 한 번더 작업을 하니까 생기는 현상으로 판단됩니다. 정리하자면 한번만 찾으면 되는 행위를 2번 하니까 발생한 현상으로 판단됩니다.

IT업계 뿐만아니라 거의 모든 분야에서 AI 열풍이 불고 있고, 관련해서 여기저기서 사람들을 정리해고한다는 이야기는 이제 이상에서 일상으로 변한 지 오래라고 생각합니다. 그래서 얼마나 대단한지 실제로 사용해 보니 제 생각 이상으로 대단했습니다. 왜 개발자들이 이렇게 실직을 많이 하고 있는지 알게 되었습니다. 그래서 얼마나 대단했는지에 대해 공유하고자 이렇게 게시글로 남겨보기로 했습니다.

❓Claude Code 선택이유

지금은 수많은 바이브 코딩 도구가 존재합니다. 커서 AI, 이번에 사용한 Claude Code, 구글 제미나이 코드 어시스턴트 등등 정말 많습니다. 그중에서도 Claude Code를 선택한 이유는 어이없게도 가장 사고를 늦게 쳐서라고 말하고 다닙니다. 이게 무슨 말이냐면 제미나이와 Claude 중에 어떤 거를 쓸지 고민이었습니다. 그러다가 두 AI 중에 사고를 늦게 친 쪽을 구매해서 쓰기로 마음을 먹고 얼마 안 있고 제미나이에서 이슈를 냈습니다. 그래서 Claude를 사용하게 되었습니다. 지금 생각하면 Claude를 사용하길 잘한 거 같습니다.

📕 개발한 프로젝트

이번에 개발한 프로젝트는 해외 및 아티스트 들의 내한 콘서트 일정 정보를 수집하는 프로그램입니다. 지금은 폐쇄한 상태지만 그 당시 일본 가수 내한 일정 사이트를 운영하던 불편한 점이 있었습니다. 그것은 콘서트 일정을 하나하나 수기로 입력해야 했다는 점과 심지어 일정이 발표되는 것도 갑자기 나오는 경우가 많기에 일정을 실시간으로 확인하는 게 문제였습니다. 그래서 다음과 같은 문제를 해결하고자 했습니다.

• Docker로 동작하도록 만들기
• 수기작성에서 매일 오후 12시마다 자동으로 데이터가 입력되도록 하기

📗 프로젝트 실행

처음에는 모든게 막막했습니다. 파이썬도 조금다룰줄만 알았지 전문적으로 할줄은 몰랐으니까요 그래도 Claude Code 덕분에 그부분은 해결이되어서 올바르게 AI에게 명령을 내리는 부분에 집중했습니다. Claude Code는 실로 놀라웠습니다. 코드작성은 물론 Git의 Repository와 연결하면 알아서 PR도 만들어줄거라곤 생각도 못했습니다. 만약 저 혼자 했다면 이 글을 쓸시간에도 파이썬 크롤링부분에서 애를 먹고 있었을 것 입니다.

프로젝트 Repository

https://github.com/delight-HK3/gemini_concert_search

😊 바이브코딩 후기

프로젝트는 결과적으로 1주일 정도 걸렸던거 같습니다. 생산력이 말이 안되는 수준이었습니다. 테스트 해본결과 정상적으로 동작하는 것도 확인했습니다. 정말로 IT업계에서 개발자라는 직업이 사라질거라는 말이 나오는 것도 무리는 아니겠구나 싶었습니다. 하지만 한편으로는 좀 섬뜩했습니다. 어디서 들었는데 기술의 특이점이 2055년에 온다고 했는데 그것보다 빠르게 올거 같다고 생각했습니다. 그리고 이러한 편안함속에 우리는 무엇을 잃었는지에 대해 생각해보는 계기가 되었습니다.

예전에 DockerHub로 배포를 하려고 했는데 DockerHub에 접속이 안되는 이슈가 있었습니다. 그래서 확인해보니 DockerHub자체가 마비되서 일어난 이슈였고 그래서 현재 서비스가 AWS EC2위에서 동작하는점이 반영되어 이미지 업로드 저장소를 소프트웨어 이미지를 DockerHub에서 AWS ECR로 변경하기로 결정했고 그 역할을 제가 맏기로 했습니다. 해당 작업을 마치고 나중에 해당 에피소드를 써야지 했다가 여러가지 이슈로 인해 미루어졌다가 이제와서야 쓰게 됩니다.

🗒️ 기존 CI/CD 구조

이미지로 그리자면 대충 이러한 형태가 됩니다. 작업자가 GitHub에 Push 및 Merge를 하면 Jenkins에서는 해당 GitHub계정에 접근해 해당하는 Repository를 이미지로 만들고 그거를 DockerHub에 올린 후 지정된 서버로 업로드 하는 그런 형식입니다.

🗒️ 개선한 CI/CD 구조

구조는 단순히 DockerHub에 올리는 방식에서 AWS ECR에 업로드하는 방식으로 변경한 것 뿐이었습니다만 의외로 괜찮은 결과를 얻을 수 있었습니다.

• 얻은 것들
  • 개발서버 배포시간 51% 감소
  • 스크립트 과정 간결화
  • 기존 DockerHub 인증서 노출 보안 이슈 해결

🔗 젠킨스 인증서 등록

해당 작업을 하기전에 인증서를 등록해야하는데 그거는 하단의 주소를 참고하면 됩니다. https://fwani.tistory.com/29

🧑‍💻 기존 젠킨스 스크립트

pipeline {
    agent any

    environment {
        APP_NAME = '[프로젝트 명]' // 저장소 명
        DOCKER_CREDENTIALS = credentials('[Jenkins에 등록된 아이디와 비밀번호가 DockerHub 로그인 정보와 같은 인증키 이름]')
        DOCKER_IMAGE = '[이미지 명]' // Docker Image 이름
        SPRING_PROFILE = '[운영설정]'  // 운영 환경 프로필
        REMOTE_HOST = '[배포서버 IP]'  // 운영 서버 IP 또는 호스트명
        REMOTE_USER = '[접속 계정 명]' // SSH 접속 계정
        REMOTE_CREDENTIALS = credentials('[Jenkins에서 발급한 인증키 이름]')  // 비밀번호 자격증명 ID
    }

    stages {
        stage('Git Clone') {
            steps {
                git branch: '[브랜치 이름]',  // 운영 환경은 main 브랜치 사용
                    credentialsId: '[Jenkins에서 발급한 토큰 Key]',
                    url: "[깃허브 주소]/${APP_NAME}.git"
            }
        }

        // 가져온 chat-Repository에서 gradle에 등록된 application version 가져오기
        stage('get application version') {
            steps {
                script {
                    // Gradle 실행권한 부여
                    sh 'chmod +x ./gradlew'

                    // Gradle의 callVersion 태스크를 실행하여 버전 값 가져오기
                    def appVersion = sh(returnStdout: true, script: './gradlew -q callVersion').trim()

                    // 가져온 버전을 환경 변수로 설정합니다.
                    env.DOCKER_TAG = appVersion
                }
            }
        }

        stage('Build and Push Docker Image') {
            steps {
                // Docker Hub 로그인
                sh '''
                    echo $DOCKER_CREDENTIALS_PSW | docker login -u $DOCKER_CREDENTIALS_USR --password-stdin
                '''

                // Jib을 사용하여 도커 이미지 빌드 및 푸시 (태그와 프로필 전달)
                sh """
                    ./gradlew jib \
                        -Djib.to.tags=${DOCKER_TAG} \
                        -Djib.container.environment.SPRING_PROFILES_ACTIVE=${SPRING_PROFILE}
                """
            }
        }

        stage('Deploy to Production') {
            steps {
                withCredentials([
                    sshUserPrivateKey(credentialsId: '[Jenkins에서 발급한 인증키]', keyFileVariable: 'KEY_FILE'),
                    usernamePassword(credentialsId: '[Jenkins에 등록된 아이디와 비밀번호가 DockerHub 로그인 정보와 같은 인증키 이름]', passwordVariable: 'DOCKER_PASSWORD', usernameVariable: 'DOCKER_USERNAME')
                ]) {
                    sh '''
                        # 배포 스크립트 생성
                        cat > deploy.sh << EOF
#!/bin/bash
# Docker Hub 로그인
echo $DOCKER_PASSWORD | docker login -u $DOCKER_USERNAME --password-stdin
# 기존 컨테이너가 있으면 중지 및 삭제
if docker ps -a | grep -q ${APP_NAME}; then
    docker stop ${APP_NAME}
    docker rm ${APP_NAME}
fi
# 이미지 풀링
docker pull ${DOCKER_IMAGE}:${DOCKER_TAG}

# 컨테이너 실행
[컨테이너 실행 설정 및 명령어]

# Docker Hub 로그아웃
docker logout
EOF

                        # 스크립트에 실행 권한 부여
                        chmod +x deploy.sh

                        # 원격 서버로 스크립트 전송
                        scp -i $KEY_FILE -o StrictHostKeyChecking=no deploy.sh ${REMOTE_USER}@${REMOTE_HOST}:~/

                        # 원격 서버에서 스크립트 실행
                        ssh -i $KEY_FILE -o StrictHostKeyChecking=no ${REMOTE_USER}@${REMOTE_HOST} "chmod +x ~/deploy.sh && ~/deploy.sh"
                    '''
                }
            }
        }

        // 클린업을 위한 별도 스테이지 추가
        stage('Cleanup') {
            steps {
                sh 'docker logout || true'  // Docker Hub 로그아웃
                cleanWs()  // 워크스페이스 정리
            }
        }
    }

    post {
        success {
            echo 'Production deployment succeeded!'
        }
        failure {
            echo 'Production deployment failed!'
        }
    }
}

기존에는 DockerHub로그인 및 로그아웃 과정이 있어서 시간이 약간 오래걸렸던거 같습니다. 이 글을 쓰면서 새삼 보니까 어째서 DockerHub로그아웃을 2번 요청하는지는 모르겠습니다.

🧑‍💻 개선한 젠킨스 스크립트

pipeline {
    agent any

    environment {
        AWS_REGION = '[현재 서비스를 실행하는 리전]'
        ECR_REGISTRY = "[AWS 계정 12자리 일련번호].[ECR Repository 주소]"
        APP_NAME = ''

        CONTAINER_NAME = '[등록될 컨테이너 이름]'
        DOCKER_IMAGE = "${ECR_REGISTRY}/[ECR_Repository 이름]" // ECR에 등록된 Repository
        SPRING_PROFILE = '[운영설정]'  // 운영 환경 프로필
        REMOTE_HOST = '[배포서버 IP]'  // 운영 서버 IP 또는 호스트명
        REMOTE_USER = '[접속 계정 명]' // SSH 접속 계정
        SSH_CREDENTIALS_ID = '[Jenkins에서 발급한 인증키 이름]' // 비밀번호 자격증명 ID
    }

    stages {
        stage('Git Clone') {
            steps {
                git branch: 'develop',
                    credentialsId: 'github-lch-token1',
                    url: "https://github.com/store-labs/${APP_NAME}.git"
            }
        }

        stage('Get Version') {
            steps {
                script {
                    sh 'chmod +x ./gradlew'
                    def tag = sh(script: './gradlew -q callVersion', returnStdout: true).trim()
                    env.DOCKER_TAG = tag
                }
            }
        }

        stage('Build & Push to ECR') {
            steps {
                // 문자열 보간법을 사용하여 docker 명령어가 젠킨스 변수로 오해받지 않게 함
                sh "aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ECR_REGISTRY}"
                sh "./gradlew jib -Djib.to.image=${DOCKER_IMAGE} -Djib.to.tags=${env.DOCKER_TAG} -Djib.container.environment.SPRING_PROFILES_ACTIVE=${SPRING_PROFILE}"
            }
        }

        stage('Deploy to Production') {
                    steps {
                        withCredentials([
                            sshUserPrivateKey(credentialsId: "${SSH_CREDENTIALS_ID}", keyFileVariable: 'KEY_FILE')
                        ]) {
                            sh """
                            cat > deploy.sh << EOF
#!/bin/bash
# 1. ECR 로그인
aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ECR_REGISTRY}

# 2. 기존 컨테이너가 있다면 무조건 삭제
if docker ps -a | grep -q "${APP_NAME}"; then
    docker stop ${APP_NAME} || true
    docker rm ${APP_NAME} || true
fi
# 3. 이미지 작업
docker pull ${DOCKER_IMAGE}:${env.DOCKER_TAG}
# 4. 컨테이너 실행
[컨테이너 실행 명령어 및 설정]
EOF
                        chmod +x deploy.sh
                        scp -i \$KEY_FILE -o StrictHostKeyChecking=no deploy.sh ${REMOTE_USER}@${REMOTE_HOST}:~/
                        ssh -i \$KEY_FILE -o StrictHostKeyChecking=no ${REMOTE_USER}@${REMOTE_HOST} "bash ~/deploy.sh"
                    """
                }
            }
        }

        // 클린업을 위한 별도 스테이지 추가
        stage('Cleanup') {
            steps {
                cleanWs()  // 워크스페이스 정리
            }
        }
    }

    post {
        success {
            echo 'Production deployment succeeded!'
        }
        failure {
            echo 'Production deployment failed!'
        }
    }
}

전체적으로 스크립트가 간결해졌고 추가적인 로그인 및 로그아웃 과정이 생략되었습니다.

🖼️ 필요한 추가작업

단순히 스크립트만 바꾸면 안되고 AWS에서 추가작업이 필요합니다.

• 배포하는 서버에 AWS CLI설치
• ECR Repository 등록
• ECR이 접근가능하도록 IAM Role 생성
• EC2에 IAM 역할 연결

(AWS CLI 설치방법은 구글링으로 찾으면 방법은 쉽게 알 수 있습니다.)

ECR Repository 등록

1. 리포지토리 생성을 클릭합니다.

2. ECR Repository이름을 입력하고 생성합니다.

(저의 경우에는 임시로 tester라고 이름을 지었습니다.)

ECR이 접근가능하도록 IAM Role 생성

1. IAM 역할을 추가하는 방법은 일단 IAM > 역할 > 역할 생성 이렇게 진행합니다.

2. 역할 > 권한 추가 에서는 2가지만 필요합니다.

   • AmazonEC2ContainerRegistryReadOnly (ECR Pull)
   • AmazonEC2ContainerRegistryPowerUser (ECR Push/Pull)

(하나의 역할에 2개의 권한을 줘서 배포서버, 젠킨스 서버에 동시에 지정해도 되고 배포 서버는 AmazonEC2ContainerRegistryReadOnly 이것 젠킨스 서버는 AmazonEC2ContainerRegistryPowerUser를 가진 역할을 주면 됩니다.)

3. 역할 이름을 지정하고 역할 생성 합니다.

(이렇게 ECR_Test 이름의 역할이 만들어집니다.)

EC2에 IAM 역할 연결

EC2 > 인스턴스 > [인스턴스 아이디] > IAM 역할 수정

이렇게 넘어가면 방금 만든 ECR_Test라는 역할을 확인할 수 있고 지정한 후 IAM 역할 업데이트를 클릭하여 등록하면 됩니다.

📋 참고 사이트

https://fwani.tistory.com/29

이전에 Exchange를 종류대로 사용하는법을 설명하고 공부하면서 RabbitMQ와 같이 실시간 메세지 브로커에서 과연 연결이 안되는 상황에는 어떤걸 사용해야 하는가에 대해 생각해본 적이 있습니다. 다행히 관련해서 자료를 찾아보니 메세지가 안보내지는 상황에 어떻게 해야하는지 방법이 있었고 그부분을 공부하고 공유하고자 이렇게 글을 작성하게 되었습니다. 그리고 겸사겸사 TTL이 무엇이고 RabbitMQ에서는 이걸 어떻게 사용하는지 알아보는 시간을 가져보겠습니다.

https://velog.io/@half-phycho/RabbitMQ-Exchange-종류대로-사용해보기 이전에 작성한 게시글 입니다.

📕 TTL (Time-To-Live)

TTL은 간단히 말하면 유효시간 입니다. 의외로 TTL은 IT 여러분야에서 볼 수 있다고 생각하는데 대표적으로 네트워크, 데이터베이스가 있습니다. 그리고 RabbitMQ에서도 사용가능한데 메세지 자체에 TTL을 설정하여 시간을 다르게 하거나 아니면 Queue자체에 TTL을 설정해 들어오는 모든 메세지에 일관된 유효시간을 부여할 수 있습니다.

메세지에서 TTL 설정하고 Queue에서도 TTL 설정을 한다면 어떤결과가 나오는지 찾아보니 메세지 TTL이 짧은쪽을 기준으로 유효시간을 가진다고 합니다. 결국 Queue TTL보다 메세지 TTL이 짧게 설정되면 해당하는 메세지만 삭제되고 메세지의 TTL이 Queue TTL보다 길면 Queue TTL 수명이 다되면 Queue에 남아있는 모든 메세지가 삭제 됩니다.

🔎 메세지 TTL 사용하기

앞에서 말한대로 메시지 자체에 TTL을 설정할 수 있고 Queue에서도 TTL설정이 가능합니다.

메세지 레벨에서 TTL 설정하기

public String sendDirectTTLMessage(MessageDTO messageDTO) {
        ObjectMapper objectMapper = new ObjectMapper();
        try {
            // DTO -> String 직렬화 수행
            String objectToJSON = objectMapper.writeValueAsString(messageDTO);

            // 라우터를 기반으로 큐에 메시지 전송
            // ttl 시간은 5초 (5000) 으로 설정
            rabbitTemplate.convertAndSend(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_NAME()
                                        , rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_KEY()
                                        , objectToJSON
                                        , message -> {
                                            message.getMessageProperties().setExpiration("5000");
                                            return message;
                                        });
        } catch (JsonProcessingException ex) {
            log.error("parsing error : {}", ex.getMessage(), ex);
        }

        return "success_ttl_direct";
    }

Queue 레벨에서 TTL 설정

@Bean
public Queue directQueue() {
        // TTL 설정이 미포함된 Queue
        //return new Queue(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME(), true);

        // TTL 설정이 포함된 Queue
        // QueueBuilder에 durable 메서드 안에 Queue이름을 넣으면
        // RabbitMQ가 재부팅되도 Queue 대기열에 남는다.
        return QueueBuilder.durable(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME())
                .withArgument("x-message-ttl", 3000)
                .build();
}

📗 데드 레터링 (Dead Lettering)

메세지가 정상적으로 처리되지 못하고 RabbitMQ의 큐 레벨에서 제거될 때 발생하는 처리 방식을 말합니다. 메세지가 정상적으로 처리되지 못하면 데드 레터 큐로 보내집니다.

데드 레터링 발생 경우

• 메세지가 큐에서 거부(Reject)되거나 NACK 상태 혹은 다시 큐(requeue)로 돌아오는 경우

• 메세지가 큐에 있었던 시간이 메세지의 TTL을 초과하여 만료된 경우
• 메세지가 큐의 최대 길이를 초과하여 메시지를 추가할 수 없는 경우
• 큐가 가득 차서 메시지를 더 이상 저장할 수 없는 경우

(큐 전체가 만료되어도 큐에 있는 메세지는 데드 레터링 되지 않습니다.)

NACK(Negative Acknowledgement) 네트워크에서 사용하는 용어로 네트워크 기기 간에 데이터를 주고 받았을 때, 수신 장비에 데이터가 도착하지 않았을 때 보내는 신호 그 반대로 ACK(Acknowledgement)는 장비에 데이터가 도착했을때 보내는 신호이다.

데드 레터 Exchange

RabbitMQ에서 제공하는 익스체인지 유형으로 메세지가 큐에서 제거되는 경우에 사용됩니다. 기존 Exchange를 설정한다면 DirectExchange, FanoutExchange 이런 식으로 특정 Exchange를 설정했는데 데드 레터 Exchange를 설정하려면 Queue에 "x-dead-letter-exchange"라는 매개변수를 설정하고 메시지가 큐에서 제거될 때 메시지를 받을 익스체인지의 이름을 파라미터로 설정해주면 됩니다.

데드 레터 Exchange 처리과정

1. Producer가 생성한 메세지가 Exchange로 전달
2. Exchange는 처리방식별로 Queue에 메세지가 적재됩니다.
3. Queue를 수신하고 있는 Consumer에게 전달되는데 메세지 전송에 실패하면 데드 레터 Exchange를 거쳐 데드 레터 큐로 라우팅 합니다.
4. 데드 레터 큐에서는 전송 실패 메세지를 적재하여 관리합니다.

데드 레터 Exchange 구성하기

원래는 참고한 게시글을 기반으로 대부분 작업하려고 했으나 생각보다 잘 되지않았습니다. 그래서 방향을 틀어서 ttl 시간이 만료되면 dead Queue로 이동하는게 아닌 Exception을 의도적으로 발생시켜 dead Queue로 보내는 방법을 생각했습니다.

// RabbitMQ 설정

import lombok.RequiredArgsConstructor;
import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * RabbitMQ 설정 파일
 */
@Configuration
@RequiredArgsConstructor
public class RabbitmqConfig {

    private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

    /**
     * 메세지 성공을 못하는 경우 direct.queue로 라우팅하고 dead.queue로 이동
     */
    @Bean
    public DirectExchange deadExchange(){
        return ExchangeBuilder
                .directExchange(rabbitmqExchangeInfo.get_DEAD_EXCHANGE_NAME())
                .build();
    }

    /**
     * Direct Exchange 구성 : direct.queue를 라우팅 하는데 사용
     */
    @Bean
    public DirectExchange directExchange(){
        return ExchangeBuilder
                .directExchange(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_NAME())
                .build();
    }


    /**
     * deadQueue와 라우팅 키(Routing key)를 기반으로 바인딩 수행.
     *
     * @param deadQueue    성공적으로 처리하지 못한 메시지를 담는 공간
     * @param deadExchange 성공적으로 처리하지 못한 메시지를 라우팅
     */
    @Bean
    public Binding deadBinding(Queue deadQueue, DirectExchange deadExchange){
        return BindingBuilder
                .bind(deadQueue)
                .to(deadExchange)
                .with(rabbitmqExchangeInfo.get_DEAD_ROUTING_KEY());
    }

    /**
     * Direct Exchange 와 direct Queue 간의 바인딩을 수행합니다.
     *
     * @param directQueue    메시지를 담을 큐
     * @param directExchange 메시지를 담기 위한 라우팅
     */
    @Bean
    public Binding directBinding(Queue directQueue, DirectExchange directExchange){
        return BindingBuilder
                .bind(directQueue)
                .to(directExchange)
                .with(rabbitmqExchangeInfo.get_DIRECT_ROUTING_KEY());
    }


    /**
     * 만약 메세지 전송에 실패하면 해당 Queue(dead.queue) 로 이동
     *
     * @return dead Queue
     */
    @Bean
    public Queue deadQueue(){
        return new Queue(rabbitmqExchangeInfo.get_DEAD_QUEUE_NAME(), true);
    }

    /**
     * directQueue 이름의 큐를 구성
     * - 해당 큐에서는 속성 값으로 x-dead-letter-exchange가 발생시 rabbit.dead 로 라우팅
     * - 해당 큐에서는 속성 값으로 x-dead-letter-routing-key를 통해 Direct Queue의 라우팅 키를 전달하여 라우팅
     *
     * @return direct Queue
     */
    @Bean
    public Queue directQueue(){
        return QueueBuilder.durable(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME())
                .withArgument("x-dead-letter-exchange", rabbitmqExchangeInfo.get_DEAD_EXCHANGE_NAME())
                .withArgument("x-dead-letter-routing-key", rabbitmqExchangeInfo.get_DEAD_ROUTING_KEY())
                .build();
    }

}

// 주요 리스너 설정

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.AmqpRejectAndDontRequeueException;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

import java.nio.charset.StandardCharsets;

/**
 * 큐에 등록된 메세지 리턴 component
 */
@Slf4j
@Component
public class RabbitmqMessage {

    // direct Queue 메세지
    @RabbitListener(queues = "direct.queue")
    public void directMessage(Message message){
        String body = new String(message.getBody(), StandardCharsets.UTF_8);
        log.info("direct.queue 내의 메시지 반환 : {}", body);
        // 해당 Exception은 바로 해당 Queue에 등록된 Dead Queue로 이동시키는 Exception 입니다.
        throw new AmqpRejectAndDontRequeueException("Dead Queue 테스트");
    }

    // ttl이 적용된 direct Queue 메세지
    @RabbitListener(queues = "direct.queue.ttl")
    public void directTTLMessage(Message message){
        String body = new String(message.getBody(), StandardCharsets.UTF_8);
        log.info("direct.queue.ttl 내의 메시지 반환 : {}", body);
    }

    // dead Queue 메세지
    @RabbitListener(queues = "dead.queue")
    public void deadDirectMessage(Message message){
        String body = new String(message.getBody(), StandardCharsets.UTF_8);
        log.info("dead.queue 내의 메시지 반환 : {}", body);
    }

}

Service 혹은 Controller 파일은 기존과 동일하여 게시글에는 넣지는 않았습니다.

AmqpRejectAndDontRequeueException 이번에 새롭게 알게된 Exception 입니다. 해당 Exception은 다른 일반적인 Exception과는 다르게 만약 리스너에 해당하는 Queue에 등록된 dead queue로 이동 시킵니다.

spring.rabbitmq.listener.simple.default-requeue-rejected=false spring boot의 .properties 파일의 설정중 하나로 해당 설정을 추가하면 리스너에서 자동으로 예외 혹은 에러가 발생하면 자동으로 해당 queue에 둥록된 dead.queue로 이동 하도록 해줍니다. 그리고 해당 설정을 해주면 의도적으로 AmqpRejectAndDontRequeueException 을 따로 안해주어도 됩니다.

실행결과

만약 Exception을 해제한다면 direct.queue 리스너로 정상적으로 넘어가 다음과 같이 로그가 출력되는 것을 확인할 수 있습니다.

만약 의도적으로 Exception을 날렸다면 처음에는 direct.queue가 나오고 그 다음에는 의도한대로 Exception이 동작하고 dead.queue로 이동하는 것을 확인 할 수 있습니다.

📘 TTL 및 데드 레터링 Queue 설정 결과

만약 설정이 잘되었다면 Queue에는 다음과 같이 설정이 나오게 됩니다.

• DLX : 이동할 데드 레터링 Exchange 이름 입니다.
• DLK : 이동할 데드 레터링의 라우팅 키 입니다.
• TTL : 앞에서 설명한 Time To Live 약자 입니다.

😊 새롭게 알게 된 점

오히려 예시대로 안되었기에 AmqpRejectAndDontRequeueException 라는 새로운 Exception에 대해 알게 되었고 RabbitMQ의 추가 설정에 대해 알 수 있었습니다. 가끔은 실패해도 거기 안에서 본인이 몰랐던 새로운걸 알게되는 거는 더더욱 의미 있는거 같다고 생각합니다.

💾 Github 저장소

https://github.com/delight-HK3/rabbitmq-test

📋 참고 사이트

https://www.rabbitmq.com/docs/dlx

https://ko.wikipedia.org/wiki/%EB%B6%80%EC%A0%95_%EC%9D%91%EB%8B%B5

https://adjh54.tistory.com/501?category=1187853

https://www.cloudamqp.com/blog/when-and-how-to-use-the-rabbitmq-dead-letter-exchange.html

(항상 감사합니다.)

RabbitMQ를 공부하면서 현재 Queue에 어떤 메세지가 있는지 조회하고 싶었는데 이상하게 조회가 안되었습니다. 다행히 해결했고 이 에피소드를 기록으로 남기고 공유하면 좋을거 같아서 글을 써봅니다.

🔎 문제 및 해결

문제는 다음과 같았습니다. RabbitMQ로 메세지를 보내는건 성공했으나 이상하게 보낸메세지를 조회하려고 하니까 조회가 안되는 현상이었습니다. 하단에 작성한 코드는 RabbitMQ에서 조회하는 코드 입니다.

/**
 * Direct Queue에 등록되어 있는 메세지 Queue 불러오기
 */
public void receiveDirectMessage() {

    Object message = rabbitTemplate.receiveAndConvert(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME());
    if (message != null) {
        System.out.println("Received: " + message);
    }

}

이처럼 Direct Exchange 방식으로 보낸 Queue를 조회하려고 하니 null 값이 리턴되었습니다.

그런데 생각해보니 Message Queue에 어떤메세지를 보냈는지 확인하고 싶어서 @RabbitListener 를 설정한 클래스가 있는게 생각이 났습니다.

@RabbitListener(queues = "direct.queue")
public void directMessage(String message){
    log.info("direct.queue 내의 메시지 반환 : {}", message);
}

혹시 이부분 때문에 에러가 나는게 아닌가 싶어서 해당 리스너를 주석처리하고 실행시켜본 결과

이렇게 보낸 메세지를 조회할 수 있었습니다, 저는 지금까지 이렇게 진행된다고 생각했습니다.

하지만 실제로는 하단의 이미지에 작성한 순서대로 실행되었습니다.

❗깨달은 점

RabbitMQ에서 메세지를 보내고 해당하는 메세지를 Queue에 차곡차곡 저장한다고 생각했습니다. 하지만 RabbitMQ는 결국 단순 메세지 전달 브로커일뿐 자체적으로 저장하는 기능은 Delay Queue라도 사용하지 않는한 힘들다는걸 다시한번 깨달았습니다.

늘 그렇듯이 회사 업무가 바빠서 공부는 고사하고 새벽까지 일하는 경우가 많아져 공부를 소홀히 하게되었습니다. 하지만 틈틈히 조금씩이라도 자료를 수집하고 모으다보니 그래도 조금만 작업하면 되었기에 과거의 저에게 감사하다고 전하고 싶었습니다.

📚 사전준비 및 읽으면 도움되는 글

https://velog.io/@half-phycho/RabbitMQ-SpringBoot로-RabbitMQ-사용해보기 Spring Boot로 RabbitMQ기본 세팅하는 방법 입니다.

https://velog.io/@half-phycho/RabbitMQ-AMQP란-무엇인가 AMQP에 대해 정리한 글 입니다. 이번에는 Exchange를 다양하게 써볼 예정이라 도움이 되겠습니다.

💡RabbitMQ로 다양한 Exchange 써보기

지난번에는 RabbitMQ로 기본적인 Direct Exchange를 보냈습니다. 이번에는 Direct Exchange를 포함한 여러 Exchange를 보내보면서 비교해보는 시간을 가져보도록 하겠습니다.

❗ 변경된 프로젝트 구조

이전 게시글 에서는 RabbitMQ 연결세팅과 Queue, Binding을 모두 하나의 클래스에서 만들었지만 이번에는 역할을 분리하는 등 여러가지 부분이 변경되었습니다.

• RabbitMQ Connection 파일 별도로 관리
• Queue, Binding, Exchange에 사용될 이름을 오타 방지를 위해 properties에 등록하고 가져다 사용하는 형식으로 변경
• 기존 RabbitmqConfig.java 에는 Queue, Binding, Exchange 선언 및 생성을 집중으로 관리
• RabbitMQ에 Exchange별로 보낸 메세지를 출력하는 코드추가
• 자체적인 Exception Handler, ApiResponse 구축

RabbitmqConnConfig

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;
import org.springframework.amqp.rabbit.connection.ConnectionFactory;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * RabbitMQ 연결 설정
 */
@Configuration
public class RabbitmqConnConfig {

    @Value("${spring.rabbitmq.host}")
    private String host; // 접속 호스트

    @Value("${spring.rabbitmq.port}")
    private Integer port; // 접속 포트번호

    @Value("${spring.rabbitmq.username}")
    private String username; // 접속 아이디

    @Value("${spring.rabbitmq.password}")
    private String password; // 접속 비밀번호

    /**
     * RabbitMQ와 메시지 통신을 담당하는 클래스
     */
    @Bean
    public RabbitTemplate rabbitTemplate(){
        RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory());
        rabbitTemplate.setMessageConverter(messageConverter());

        return rabbitTemplate;
    }

    /**
     * RabbitMQ와 연결을 관리하는 클래스
     */
    @Bean
    public ConnectionFactory connectionFactory(){
        CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
        connectionFactory.setHost(host);
        connectionFactory.setPort(port);
        connectionFactory.setUsername(username);
        connectionFactory.setPassword(password);

        return connectionFactory;
    }

    /**
     * RabbitMQ 메시지를 JSON형식으로 보내고 받을 수 있다.
     */
    @Bean
    public Jackson2JsonMessageConverter messageConverter() {

        ObjectMapper objectMapper = new ObjectMapper()
                // 날짜 관련 타임스탬프 직렬화를 막고 ISO-8601 형태로 포맷된다.
                .configure(SerializationFeature.WRITE_DATE_KEYS_AS_TIMESTAMPS, true)
                .registerModule(dateTimeModule()); // Java에서 시간을 처리하기위한 모듈

        return new Jackson2JsonMessageConverter(objectMapper);
    }

    /**
     * 자바 시간 모듈 등록
     */
    @Bean
    public JavaTimeModule dateTimeModule() {
        return new JavaTimeModule();
    }

}

RabbitmqExchangeInfo

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

/**
 * RabbitMQ에서 사용하는 exchange이름과 Queue정보 모아둔 Component
 */
@Component
public class RabbitmqExchangeInfo {

    @Value("${rabbitmq.direct.exchange.name}")
    private String DIRECT_EXCHANGE_NAME; // direct Exchange

    @Value("${rabbitmq.direct.exchange.key}")
    private String DIRECT_EXCHANGE_KEY; // direct Exchange Key

    @Value("${rabbitmq.direct.queue.name}")
    private String DIRECT_QUEUE_NAME;   // direct Queue name

    public String get_DIRECT_EXCHANGE_NAME() {
        return DIRECT_EXCHANGE_NAME;
    }

    public String get_DIRECT_EXCHANGE_KEY() {
        return DIRECT_EXCHANGE_KEY;
    }

    public String get_DIRECT_QUEUE_NAME() {
        return DIRECT_QUEUE_NAME;
    }

}

RabbitmqConfig

import lombok.RequiredArgsConstructor;
import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * RabbitMQ 설정 파일
 */
@Configuration
@RequiredArgsConstructor
public class RabbitmqConfig {

    private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

    // 공통적으로 RabbitMQ가 재부팅되도 Exchange가 삭제안되고 동시에 대기열에 남도록 설정
    @Bean
    public DirectExchange directExchange() {
        // DIRECT_EXCHANGE_NAME 이름의 direct Exchange 구성
        return ExchangeBuilder
                .directExchange(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_NAME())
                .build();
    }

    // 공통적으로 RabbitMQ가 재부팅되도 Queue 대기열에 남도록 설정
    @Bean
    public Queue directQueue() {
        return new Queue(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME(), true);
    }

    /**
     * Queue와 DirectExchange를 바인딩
     */
    @Bean
    public Binding directBinding(DirectExchange directExchange, Queue directQueue) {
        // queue까지 가는 바인딩 Exchange 타입을 directExchange로 지정하고 test.key 이름으로 바인딩 구성
        return BindingBuilder
                .bind(directQueue)
                .to(directExchange)
                .with(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_KEY());
    }

}

RabbitmqMessage

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

/**
 * 큐에 등록된 메세지 리턴 component
 */
@Slf4j
@Component
public class RabbitmqMessage {

    @RabbitListener(queues = "direct.queue")
    public void directMessage(String message){
        log.info("direct.queue 내의 메시지 반환 : {}", message);
    }

}

(기타 Fanout, Topic, Header 방식은 업로드한 GitHub Repository를 참고하시기 바랍니다. 위의 코드는 게시글이 길어지는 것을 방지하고자 일부러 Direct Exchange관련만 코드에 남겼습니다.)

해당 프로젝트가 있는 Github 주소 입니다. https://github.com/delight-HK3/rabbitmq-test

▶️ 해당 프로젝트 실행

만약 해당 프로젝트를 실행시키면 자동으로 관련 Exchange와 Queue가 생성되는 것을 확인할 수 있습니다.

❗여기서 잠깐! 어째서 자동으로 Binding, Queue, Exchange가 생성되는 것 인가? Spring Boot에서 프로젝트를 만들때 Gradle에서 pring-boot-starter-amqp가 프로젝트에 있는경우 자동으로 AmqpAdmin 이라는 Bean을 구성하고 등록합니다. 그리고 @Configuration 클래스 내에서 @Bean으로 등록된 Queue, Exchange, Binding 설정들이 자동으로 AmqpAdmin의 자동 선언 대상이 됩니다.

📕 Direct Exchange

Direct Exchange는 이전에 간단하게 RabbitMQ에 대해 시연해본 방법으로 요청시 Exchange의 이름과 Exchange에 등록되어 있는 라우팅키가 일치하면 해당 Exchange와 연결된 Queue로 보내는 방식입니다.

Exchange, Queue, Binding 생성 과정

1. Exchange 생성 : Direct 타입의 Exchange를 생성합니다. 2. Queue 생성 : Direct Exchange로 받은 데이터를 적재할 Queue를 생성합니다. 3. Binding 생성 : 앞에서 생성한 Exchange와 Queue간 바인딩을 설정하고 Routing Key 기반으로 바인딩을 수행합니다.

코드예시

private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

@Bean
public DirectExchange directExchange() {
    // DIRECT_EXCHANGE_NAME 이름의 direct Exchange 구성
    return ExchangeBuilder
                .directExchange(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_NAME())
                .build();
}

@Bean
public Queue directQueue() {
    // 여기서 true는 RabbitMQ가 재부팅되도 Queue 대기열에 남도록 하는 설정입니다.
    return new Queue(rabbitmqExchangeInfo.get_DIRECT_QUEUE_NAME(), true);
}

@Bean
public Binding directBinding(DirectExchange directExchange, Queue directQueue) {
    // queue까지 가는 바인딩 Exchange 타입을 directExchange로 지정하고 test.key 이름으로 바인딩 구성
    return BindingBuilder
                .bind(directQueue)
                .to(directExchange)
                .with(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_KEY());
}

요청 및 결과

Controller

@PostMapping("/direct")
public ResponseEntity<ApiResponse> sendDirectMessage(@RequestBody MessageDTO messageDTO) {
    String resultMessage = messsageService.sendDirectMessage(messageDTO);

    return ApiResponse.success(resultMessage,200);
}

Service

/**
  * Direct Exchange 방식 메세지 전송
  *
  * @param messageDTO 메세지 DTO
  * @return 성공 시 "success_direct" 리턴
  */
public String sendDirectMessage(MessageDTO messageDTO) {
    try{
        ObjectMapper objectMapper = new ObjectMapper();
        String objectToJson = objectMapper.writeValueAsString(messageDTO);

        rabbitTemplate.convertAndSend(rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_NAME()
                                        , rabbitmqExchangeInfo.get_DIRECT_EXCHANGE_KEY()
                                        , objectToJson);
    } catch (JsonProcessingException ex) {
        log.error("parsing error : {}", ex.getMessage(), ex);
    }

    return "success_direct";
}

요청결과

1. 먼저 API 요청결과를 리턴 받습니다.

2. 해당 로그는 사전에 @RabbitListener로 Direct Exchange를 통해 direct.queue에 데이터가 들어오면 발동하는 이벤트인데 해당 로그가 나왔다는 의미는 데이터가 Queue 까지 전달이 잘되었다는 의미입니다.

📙 Fanout Exchange

Fanout Exchange는 Exchange에 라우팅 키와 관계없이 Exchange에 연결된 모든 Queue에 메세지를 보내는 방식입니다.

Exchange, Queue, Binding 생성 과정

1. Exchange 생성 : Fanout 타입의 Exchange를 생성합니다. 2. Queue 생성 : Fanout Exchange로 받은 데이터를 적재할 Queue를 2개 생성합니다. 3. Binding 생성 : 앞에서 생성한 Exchange와 Queue간 바인딩을 설정하고 Exchange는 연결설정된 Queue에게만 메세지를 보냅니다.

코드예시

private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

@Bean
public FanoutExchange fanoutExchange() {
    // FANOUT_EXCHANGE_NAME 이름의 fanout Exchange 구성
    return ExchangeBuilder
                .fanoutExchange(rabbitmqExchangeInfo.get_FANOUT_EXCHANGE_NAME())
                .build();
}


@Bean
public Queue fanoutQueueOne() {
    return new Queue(rabbitmqExchangeInfo.get_FANOUT_QUEUE_NAME_ONE(), true);
}

@Bean
public Queue fanoutQueueTwo() {
    return new Queue(rabbitmqExchangeInfo.get_FANOUT_QUEUE_NAME_TWO(), true);
}


/**
  * Queue(fanoutQueueOne)와 FanoutExchange 바인딩
  * Fanout 방식은 Exchange와 연결된 모든 Queue에 보내는 방식으로
  * FanoutExchange와 연결된 fanoutQueueOne, fanoutQueueTwo에게 메세지를 보낸다.
  */
@Bean
public Binding fanoutBindingOne(FanoutExchange fanoutExchange, Queue fanoutQueueOne) {
    return BindingBuilder
                .bind(fanoutQueueOne)
                .to(fanoutExchange);
}

/**
  * Queue(fanoutQueueTwo)와 FanoutExchange 바인딩
  * Fanout 방식은 Exchange와 연결된 모든 Queue에 보내는 방식으로
  * FanoutExchange와 연결된 fanoutQueueOne, fanoutQueueTwo에게 메세지를 보낸다.
  */
@Bean
public Binding fanoutBindingTwo(FanoutExchange fanoutExchange, Queue fanoutQueueTwo) {
    return BindingBuilder
                .bind(fanoutQueueTwo)
                .to(fanoutExchange);
}

요청 및 결과

Controller

@PostMapping("/fanout")
public ResponseEntity<ApiResponse> sendFanoutMessage(@RequestBody MessageDTO messageDTO){
    String resultMessage = messsageService.sendFanoutMessage(messageDTO);

    return ApiResponse.success(resultMessage, 200);
}

Service

/**
  * Fanout Exchange 방식 메세지 전송
  *
  * @param messageDTO 메세지 DTO
  * @return 성공 시 "success_fanout" 리턴
  */
public String sendFanoutMessage(MessageDTO messageDTO) {
    try{
        ObjectMapper objectMapper = new ObjectMapper();
        String objectToJson = objectMapper.writeValueAsString(messageDTO);

        rabbitTemplate.convertAndSend(rabbitmqExchangeInfo.get_FANOUT_EXCHANGE_NAME()
                                        , ""
                                        , objectToJson);
    } catch (JsonProcessingException ex) {
        log.error("parsing error : {}", ex.getMessage(), ex);
    }

    return "success_fanout";
}

요청결과

1. 먼저 API 요청결과를 리턴 받습니다.

2. 마찬가지로 해당 로그도 해당 Queue에게 전달 되었기 때문에 출력되는 로그 입니다. 다른점은 Direct Exchange와 다르게 Exchange와 바인딩 된 Queue에게 일괄적으로 메세지를 전송했다는 점 입니다.

📗 Topic Exchange

Topic Exchange 방식은 라우팅 키에 등록된 패턴에 따라 메세지를 보내는 방식으로 보통 키의 구분자를 *를 주로 사용하는 것 같은데 경우에 따라 !,#등 방법은 다양합니다.

Exchange, Queue, Binding 생성 과정

1. Exchange 생성 : Topic 타입의 Exchange를 생성합니다. 2. Queue 생성 : Topic Exchange로 받은 데이터를 적재할 Queue를 2개 생성합니다. 3. Binding 생성 : 앞에서 생성한 Exchange와 Queue간 바인딩을 설정하고 Exchange는 라우팅키 규칙과 맞는 Queue에게만 메세지를 보냅니다.

코드예시

private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

@Bean
public TopicExchange topicExchange() {
    // TOPIC_EXCHANGE_NAME 이름의 topic Exchange 구성
    return ExchangeBuilder
                .topicExchange(rabbitmqExchangeInfo.get_TOPIC_EXCHANGE_NAME())
                .build();
}


@Bean
public Queue topicQueue() {
    return new Queue(rabbitmqExchangeInfo.get_TOPIC_QUEUE_NAME(), true);
}

// 편의상 fanout 전용으로 사용한 Queue를 사용하겠습니다
@Bean
public Queue fanoutQueueTwo() {
    return new Queue(rabbitmqExchangeInfo.get_FANOUT_QUEUE_NAME_TWO(), true);
}


/**
  * topic Exchange 와 topicQueue간 바인딩
  * producer에서 topic.send. 으로 시작하는 라우팅 키를 보내주면 라우팅 키 규칙과 같은 Exchange와 연결
  */
@Bean
public Binding topicBinding(TopicExchange topicExchange, Queue topicQueue){
        return BindingBuilder
                .bind(topicQueue)
                .to(topicExchange)
                .with("topic.send.*");
}

@Bean
public Binding topicBinding2(TopicExchange topicExchange, Queue fanoutQueueTwo){
        return BindingBuilder
                .bind(fanoutQueueTwo)
                .to(topicExchange)
                .with("topic.send.tester");
}

요청 및 결과

Controller

@PostMapping("/topic")
public ResponseEntity<ApiResponse> sendTopicMessage(@RequestBody MessageDTO messageDTO){
    String resultMessage = messsageService.sendTopicMessage(messageDTO);

    return ApiResponse.success(resultMessage, 200);
}

Service

/**
  * Topic Exchange 방식 메세지 전송
  *
  * @param messageDTO 메세지 DTO
  * @return 성공 시 "success_topic" 리턴
  */
public String sendTopicMessage(MessageDTO messageDTO) {
    try{
        ObjectMapper objectMapper = new ObjectMapper();
        String objectToJson = objectMapper.writeValueAsString(messageDTO);

        rabbitTemplate.convertAndSend(rabbitmqExchangeInfo.get_TOPIC_EXCHANGE_NAME()
                                        , "topic.send.test"
                                        , objectToJson);
    } catch (JsonProcessingException ex) {
        log.error("parsing error : {}", ex.getMessage(), ex);
    }

    return "success_topic";
}

요청결과

1. 먼저 API 요청결과를 리턴 받습니다.

2. 마찬가지로 해당 로그도 해당 Queue에게 전달되었기 때문에 출력되는 로그입니다. 다른 점은 분명 2개의 Queue를 만들고 바인딩까지 해주었는데 topic.queue에만 메세지가 들어왔고 fanout.queue.two 에는 데이터가 안 들어왔습니다. 그 이유는 Service에서 설정한 라우팅 키 때문인데 sendTopicMessage에는 routingKey를 topic.send.test로 설정했습니다. Topic Exchange는 특성상 라우팅 키의 규칙을 따르거나 라우팅 키가 정확히 일치해야 통신이 됩니다. 그런데 fanoutQueueTwo에 설정된 라우팅키는 topic.send.tester입니다. 그래서 topicBinding2으로는 메세지가 전송이 안 된 것입니다.

📘 Header Exchange

Header Exchange는 요청 시 HTTP Header에 지정된 value와 키가 있으면 메세지를 보내는 Exchange 방식입니다. 지금까지는 Routing Key가 해왔던 역할을 Header가 대신해준다고 생각하면 됩니다. 그래서 RabbitMQ 관리자 페이지에서 Header Exchange를 조회하면 다음과 같이 조회됩니다.

여기서 (key):true 이렇게 되어있는게 이건 해당 키가 있으면 어떤 value여도 통과 시켜준다는 의미입니다.

Exchange, Queue, Binding 생성 과정

1. Exchange 생성 : Header 타입의 Exchange를 생성합니다. 2. Queue 생성 : Header Exchange로 받은 데이터를 적재할 Queue를 1개 생성합니다. 3. Binding 생성 : 앞에서 생성한 Exchange와 Queue 간 바인딩을 설정하고 Header Key를 지정해 줍니다, 만약 요청 시해당하는 key와 value 값이 있으면 연결된 Queue로 메시지를 전송합니다.

코드예시

private final RabbitmqExchangeInfo rabbitmqExchangeInfo;

@Bean
public HeadersExchange headersExchange() {
    // HEADER_EXCHANGE_NAME 이름의 header Exchange 구성
    return ExchangeBuilder
                .headersExchange(rabbitmqExchangeInfo.get_HEADER_EXCHANGE_NAME())
                .build();
}


@Bean
public Queue headersQueue() {
    return new Queue(rabbitmqExchangeInfo.get_HEADER_QUEUE_NAME(), true);
}


/**
  * headers Exchange 와 headersQueue간 바인딩
  * headersExchange 방식으로 headersQueue와 Header값을 조건으로 바인딩 수행
  */
@Bean
public Binding headerBinding(HeadersExchange headersExchange, Queue headersQueue){
        return BindingBuilder
                .bind(headersQueue)
                .to(headersExchange)
                .where("x-execute-key").matches(true);
                // x-execute-key에 들어온 모든 값을 허용한다는 의미
}

요청 및 결과

Controller

@PostMapping("/header")
public ResponseEntity<ApiResponse> sendHeaderMessage(@RequestBody MessageDTO messageDTO){
    String resultMessage = messsageService.sendHeaderMessage(messageDTO);

    return ApiResponse.success(resultMessage, 200);
}

Service

/**
  * Header Exchange 방식 메세지 전송
  *
  * @param messageDTO 메세지 DTO
  * @return 성공 시 "success_header" 리턴
  */
public String sendHeaderMessage(MessageDTO messageDTO){
    try{
        ObjectMapper objectMapper = new ObjectMapper();
        String objectToJson = objectMapper.writeValueAsString(messageDTO);

        rabbitTemplate.convertAndSend(rabbitmqExchangeInfo.get_HEADER_EXCHANGE_NAME()
                    ,""
                    ,objectToJson);
    } catch (JsonProcessingException ex) {
        log.error("parsing error : {}", ex.getMessage(), ex);
    }

    return "success_header";
}

요청결과

(Header Exchange는 Header Key 값이 들어가야 해서 요청형태가 다릅니다.)

1. 먼저 API 요청결과를 리턴 받습니다.

2. 마찬가지로 해당 로그도 해당 Queue에게 전달 되었기 때문에 출력되는 로그 입니다.

😊 직접 경험해보고 느낀점

이 글을 쓰기까지 비록 긴 시간이 걸렸지만 도움은 많이 되었습니다. RabbitMQ를 간단하게나마 써보니 왜 대용량 트래픽 제어에 사용하는지 알 수 있었습니다, 아직도 생소하지만, 이론적 지식과 실제로 프로젝트를 만들어 보면서 여러 가지 프로세스를 생각할 수 있게 해주었던 시간이었습니다, 만약 여러 요청이 들어와도 각기 다른 서버에서 병렬로 데이터를 처리할 수만 있다면 처리시간이 대폭 줄일 수 있겠다고 생각했습니다.

📋 참고 사이트

https://hoestory.tistory.com/85

https://adjh54.tistory.com/497?category=1187853#3

(항상 감사합니다.)

RabbitMQ로 메세지 큐를 구현하기에 앞서 이전에 작성한 RabbitMQ의 이론지식과 AMQP가 어떤의미인지 읽어보는걸 추천드립니다.

https://velog.io/@half-phycho/RabbitMQ-AMQP란-무엇인가

📒 예제 환경설정

RabbitMQ를 사용하기에 앞서 해당 예제에서 사용한 프레임워크 및 서버입니다.

IDE : intellij Ultimate
Framework : Spring Boot
Language : Java 17
Server : AWS EC2

이번에 만드는 예제는 Github에 등록해서 얼마든지 가져오실 수 있습니다.

https://github.com/delight-HK3/rabbitmq-test

❗주의사항

만약 본인 PC에 직접 RabbitMQ를 설치하셨으면 상관이 없지만 지금까지 게시글을 따라오셨다면 EC2의 보안 그룹에서 5672포트를 반드시 인바운드 규칙에 포함시켜야 합니다. 처음에 이걸 생각못해서 시간을 많이 낭비했습니다.

(해당 이미지에 나온 인바운드 규칙처럼 다른 포트는 몰라도 5672포트는 추가해야 합니다.)

📚 목차

• Spring Boot Gradle 설정
• properties 설정
• RabbitMQ config 파일 작성
• Mapping 설정
• 실제 Request 요청 보내기

1. Spring Boot Gradle 설정

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-amqp'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'

    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.amqp:spring-rabbit-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

1. amqp : Spring Boot에서 RabbitMQ를 사용하려면 amqp를 반드시 추가해야 합니다.
2. web : Request 요청하기위해 추가했습니다.
3. actuator : RabbitMQ의 연결상태를 확인하기 위해 추가 했습니다.
4. lombok : Getter, Setter를 편리하게 만들기위해 추가했습니다.

2. properties 설정

# spring boot port
server.port=8088

spring.application.name=rabbitmq-test

logging.level.root=info

# RabbitMQ setting
spring.rabbitmq.host=<localhost / 서버주소>
spring.rabbitmq.port=5672
spring.rabbitmq.username=<설정한 사용자 이름 / admin>
spring.rabbitmq.password=<설정한 비밀번호 / admin>
spring.rabbitmq.virtual-host=/

# application status check
management.endpoints.web.exposure.include=health,info

여기에서 중요한 부분은 RabbitMQ setting 부분인데 하나하나 해석하면 다음과 같습니다.

3. RabbitMQ config 파일

RabbitMQ 설정은 별도의 설명없이 주석으로 작성해놓았습니다.

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import lombok.RequiredArgsConstructor;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.DirectExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.rabbit.annotation.EnableRabbit;
import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;
import org.springframework.amqp.rabbit.connection.ConnectionFactory;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * RabbitMQ 설정 파일
 */
@EnableRabbit // RabbitMQ의 설정을 활성화 하기위해 필요
@Configuration
@RequiredArgsConstructor
public class RabbitmqConfig {

    @Value("${spring.rabbitmq.host}")
    private String host;     // 접속 호스트

    @Value("${spring.rabbitmq.port}")
    private Integer port;     // 접속 포트번호

    @Value("${spring.rabbitmq.username}")
    private String username; // 접속 아이디

    @Value("${spring.rabbitmq.password}")
    private String password; // 접속 비밀번호

    private static final String BINDING_KEY = "test.key";            // 바인딩 키 name
    private static final String EXCHANGE_NAME = "test.exchange";    // exchange name
    private static final String QUEUE_NAME = "queue";                // 목적지 queue name

    /**
     * direct Exchange 구성
     *
     * @return DirectExchange
     */
    @Bean
    public DirectExchange directExchange() {
        return new DirectExchange(EXCHANGE_NAME); // Exchange속성을 direct로 설정
    }

    /**
     * Queue 구성
     *
     * @return Queue
     */
    @Bean
    public Queue queue() {
        return new Queue(QUEUE_NAME);
    }

    /**
     * Queue와 DirectExchange를 바인딩
     * test.key라는 이름으로 바인딩 구성
     *
     * @param directExchange
     * @param queue
     * @return Binding
     */
    @Bean
    public Binding binding(DirectExchange directExchange, Queue queue) {
        // queue까지 가는 바인딩 Exchange 타입을 directExchange로 지정하고 test.key 이름으로 바인딩 구성
        return BindingBuilder
                .bind(queue)
                .to(directExchange)
                .with(BINDING_KEY);
    }

    /**
     * RabbitMQ와 메시지 통신을 담당하는 클래스
     */
    @Bean
    public RabbitTemplate rabbitTemplate(){
        RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory());
        rabbitTemplate.setMessageConverter(messageConverter());

        return rabbitTemplate;
    }

    /**
     * RabbitMQ와 연결을 관리하는 클래스
     */
    @Bean
    public ConnectionFactory connectionFactory(){
        CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
        connectionFactory.setHost(host);
        connectionFactory.setPort(port);
        connectionFactory.setUsername(username);
        connectionFactory.setPassword(password);

        return connectionFactory;
    }

    /**
     * RabbitMQ 메시지를 JSON형식으로 보내고 받을 수 있다.
     */
    @Bean
    public Jackson2JsonMessageConverter messageConverter() {

        ObjectMapper objectMapper = new ObjectMapper()
                // 날짜 관련 타임스탬프 직렬화를 막고 ISO-8601 형태로 포맷된다.
                .configure(SerializationFeature.WRITE_DATE_KEYS_AS_TIMESTAMPS, true)
                .registerModule(dateTimeModule()); // Java에서 시간을 처리하기위한 모듈

        return new Jackson2JsonMessageConverter(objectMapper);
    }

    /**
     * 자바 시간 모듈 등록
     */
    @Bean
    public JavaTimeModule dateTimeModule() {
        return new JavaTimeModule();
    }
}

4. Mapping 설정

Mapping 설정은 postman혹은 intellij에 내장되어있는 클라이언트 요청 기능으로 직접 메세지를 보내는 용도로 만든 Mapping 입니다.

controller Layer

import com.example.rabbitmqtest.common.codes.SuccessCode;
import com.example.rabbitmqtest.common.response.ApiResponse;
import com.example.rabbitmqtest.dto.MessageDTO;
import com.example.rabbitmqtest.service.MesssageService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@Slf4j
@RestController
@RequestMapping("/api/v1/publisher")
public class MessageController {

    private final MesssageService messsageService;

    public MessageController(MesssageService messsageService) {
        this.messsageService = messsageService;
    }

    @PostMapping("/send")
    public ResponseEntity<?> sendMessage(@RequestBody MessageDTO messageDTO) {

        messsageService.sendMessage(messageDTO);
        ApiResponse ar  = ApiResponse.builder()
                    .resultMsg(SuccessCode.SELECT.getMessage())
                    .resultCode(SuccessCode.SELECT.getStatus())
                .build();

        return new ResponseEntity<>(ar, HttpStatus.OK);
    }
}

Service Layer

import com.example.rabbitmqtest.dto.MessageDTO;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.stereotype.Service;

/**
 * MessageService 서비스 Layer
 */
@Slf4j
@Service
public class MesssageService {

    private final RabbitTemplate rabbitTemplate;

    public MesssageService(RabbitTemplate rabbitTemplate) {
        this.rabbitTemplate = rabbitTemplate;
    }

    private static final String BINDING_KEY = "test.key";
    private static final String EXCHANGE_NAME = "test.exchange";

    /**
     * 메세지 전송
     *
     * @param messageDTO 메세지 DTO
     */
    public void sendMessage(MessageDTO messageDTO) {
        try{
            ObjectMapper objectMapper = new ObjectMapper();
            String objectToJson = objectMapper.writeValueAsString(messageDTO);
            rabbitTemplate.convertAndSend(EXCHANGE_NAME, BINDING_KEY, objectToJson);
        } catch (JsonProcessingException ex) {
            log.error("parsing error : {}", ex.getMessage(), ex);
        }

    }

}

SuccessCode (Enum)

import lombok.Getter;

@Getter
public enum SuccessCode {

    SELECT(200,"SELECT SUCCESS");

    private final Integer status;
    private final String message;

    SuccessCode(Integer status, String message){
        this.status = status;
        this.message = message;
    }
}

MessageDTO (Request DTO)

import lombok.*;

/**
 * 메세지 전송하는 DTO
 */
@Getter
public class MessageDTO {
    private String title;
    private String content;
}

ApiResponse (Response DTO)

import lombok.Builder;
import lombok.Getter;

/**
 * API 결과를 저장하는 Response 객체
 */
@Getter
public class ApiResponse {

    private final String resultMsg;
    private final Integer resultCode;

    @Builder
    public ApiResponse(String resultMsg, Integer resultCode) {
        this.resultMsg = resultMsg;
        this.resultCode = resultCode;
    }

}

5. 실제 Request 요청 보내기

위와 같이 설정했으면 대부분의 경우 요청이 보내지고 RabbitMQ에 바인딩이 쌓이게 됩니다. 하지만 만일에 대비해 현재 RabbitMQ와의 연결상태를 확인해보겠습니다. (저의 경우에는 intellij Ultimate에서 제공하는 기능을 사용했습니다.)

GET http://localhost:8088/actuator/health

해당 주소로 GET요청을 보내면 현재 RabbitMQ가 동작하는지 확인할 수 있습니다, 만약 RabbitMQ가 정상적으로 올라왔으면 UP으로 나오고 아니면 DOWN으로 나옵니다.

POST http://localhost:8088/api/v1/publisher/send Content-Type: application/json { "title": "test", "content": "test" }

다음과 같이 주소를 작성하고 파라미터를 입력하여 보내면

요청이 성공하고 RabbitMQ에 Direct속성으로 test.exchange이름의 바인딩이 등록된 것을 확인할 수 있습니다.

😎 작성후기

회사업무도 많고 예제 프로젝트를 만드느라 시간이 많이 걸렸습니다. 하지만 처음으로 RabbitMQ를 실행시키고 나아가 SpringBoot와 처음 연결해보니 새삼 대학교에서 처음 배우던 시절이 떠올랐습니다. 이 게시글에는 direct 타입 Exchange만 전송했지만 다음 게시글에서는 topic이나 Fanout Exchange를 보내보고 비교해보는 게시글을 작성할 계획입니다.

참고 게시글

https://adjh54.tistory.com/292

(항상 감사합니다.)

원래는 RabbitMQ를 설치하는 방법만 설명하려고 했으나 제가 근무하고 있는 회사도 그렇고 타 기업들도 보면 RabbitMQ를 사용하는 방법이 다양했습니다. EC2에 docker 컨테이너로 운영하는 회사, AWS자체에 존재하는 Amazon MQ 라는 메시지 브로커를 사용하는 등 다양한 방법으로 사용하고 있었습니다. 이번 게시글에서는 EC2기반에 docker 컨테이너로 RabbitMQ를 운영하고 RabbitMQ 관리 페이지에 접속하는 시간을 가져보겠습니다. (docker 설치는 이전에 작성한 게시글이 있어서 그걸로 대체 하겠습니다.)

📚 목차

• Amazon EC2 서버 등록
• EC2에 Docker 설치
• Docker에 RabbitMQ 설치 및 설정
• RabbitMQ 테스트 해보기

1. Amazon EC2 서버 등록

해당 내용은 이전에 작성한 게시글을 사용하겠습니다.

https://velog.io/@half-phycho/AWS-Amazon-EC2-세팅

2. EC2에 Docker 설치

해당 내용 또한 이전에 작성한 게시글을 사용하겠습니다.

https://velog.io/@half-phycho/Docker-설치-및-사용법

3. Docker에 RabbitMQ 설치 및 실행

Docker 환경에서 RabbitMQ를 실행시키는 방법은 2가지가 있습니다.

• docker 명령어로 운영하는 방법
• Dockerfile을 사용하여 운영하는 방법

📗 docker 명령어로 운영 해당 방법은 명령어를 통해 RabbitMQ이미지 다운로드, 컨테이너 실행하는 방법입니다.

# latest RabbitMQ 4.x
docker run -d -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:4-management
# 기존 명령어에는 -d 없습니다, 백그라운드로 로딩시키기 위해 추가했습니다.

만약 RabbitMQ 컨테이너를 생성한다면 5672, 15672, 25672 포트와 함께 등록되는데 포트별로 의미는 다음과 같습니다.

• 5672 : AMQP 프로토콜 포트번호
• 15672 : RabbitMQ를 웹 UI로 접근하기 위한 포트번호
• 25672 : 클러스터기능 사용을 위한 포트번호

🖼️ 실행 이미지

docker ps -a 명령어를 실행시키면 다음과 같이 RabbitMQ가 실행되는 것을 확인할 수 있습니다.

Dockerfile을 사용하여 운영

직접 docker 명령어를 사용하면 빠르게 이미지를 다운로드하고 바로 실행시킬 수 있지만 상세 설정이 불편하다는 단점이 있습니다. 그렇기에 필요한 자잘한 설정들을 Dockerfile에 작성한 후 이미지로 빌드하여 컨테이너로 실행시키는 방법이 있습니다.

(해당 방법은 adjh54님의 방법을 사용했습니다.)

폴더구조는 다음과 같습니다.

rabbitmq.conf : 해당 파일에는 RabbitMQ 메세지 브로커의 설정을 담고 있습니다. 예를 들어 사용할 포트, 클러스터링 설정, 가상 호스트 설정 등이 있습니다.

1. rabbitmq.conf 설정파일 작성

# guest계정으로 접근 못하도록 막을 때 사용하는 설정입니다.
loopback_users.guest = false

# 해당 메세지 큐를 단일노드로 사용한다는 의미인데 경우에따라서 classic 혹은 milti로 설정이 가능합니다. (기본값은 single 입니다.)
distribution.mode = single

# 디스크 노드를 설정하는 의미 입니다.
# 만약 디스크와 메모리에 공간이 1GB만 남아있으면 메세지 발생을 중단시킵니다.
disk_free_limit.absolute = 1GB

# 디스크에 남은 여유 공간이 1.0배 정도면 메세지 발생을 중단시킨다는 의미입니다.
# 다른말로 하면 1.0으로 설정하면 여유 공간 한계를 두지않는다는 의미 입니다.
# 3.7.x 이전 버전은 0.5가 그런 이유 였지만 3.7.x 버전 이후 부터는 1.0이 비활성화를 의미합니다.
disk_free_limit.relative = 1.0

# 로깅설정 부분입니다.
log.dir = /var/log/rabbitmq # 로그 저장 경로
log.file = rabbitmq.log        # 저장할 로그 이름
log.file.rotation = daily    # 로그파일의 로테이션 (daily : 매일, weekly : 매주, size : 특정크기)
log.file.keep_count = 7        # 로테이션 된 로그파일의 최대 수량

# 클러스터 이름을 설정합니다.
cluster.name = rabbit@node1 

# TCP 리스너의 기본 포트를 지정합니다.
listeners.tcp.default = 5672

management.listener.port = 15672 # 관리 인터페이스 접근 HTTP API 포트 지정    
management.listener.ssl = false     # 관리 인터페이스 SSL 사용여부

위의 설정을 반드시 따를 필요는 없고 용도에 맞게 설정하면 됩니다.

2. Dockerfile 작성예시

# 관리형 이미지를 설정합니다. 여기서는 RabbitMQ 이미지를 선택했습니다.
FROM rabbitmq:4-management

# rabbitmq.conf에서 구성한 RabbitMQ 설정 파일을 복사합니다.
COPY ./conf/rabbitmq.conf /etc/rabbitmq

# RabbitMQ 플러그인을 활성화합니다.
RUN rabbitmq-plugins enable --offline rabbitmq_management
# or 플러그인 추가 가능
# RUN rabbitmq-plugins enable --offline rabbitmq_mqtt rabbitmq_federation_management rabbitmq_stomp

# RabbitMQ 관리자 계정, 비밀번호를 지정합니다.
ENV RABBITMQ_DEFAULT_USER dev
ENV RABBITMQ_DEFAULT_PASS dev1234

# 컨테이너가 시작될 때 실행될 명령을 설정합니다.
CMD ["rabbitmq-server"]

3. Docker image 빌드

docker build -t rabbitmq-test .

명령어를 실행하면 rabbitmq-test이름의 Docker 이미지가 생성되는 것을 확인할 수 있습니다.

4. Docker 컨테이너 생성 및 실행

docker run -d --name rabbitmq-dev-test -p 5672:5672 -p 15672:15672 rabbitmq-test

명령어를 실행하면 다음과 같이 컨테이너가 생성되는 것을 확인할 수 있습니다.

4. RabbitMQ 접속 해보기

컨테이너가 올라갔으면 RabbitMQ 관리 페이지에 접속이 가능해집니다.

만약 본인 Local PC가 아니라 AWS EC2로 접근했으면 해당사항을 주의해야 합니다.

• EC2 보안그룹에서 15672 포트를 인바운드 규칙추가
• 접속할 때에는 해당 서버주소 뒤에 포트 붙여서 접속하기

주의사항을 지켰다면 RabbitMQ 관리 페이지에 접속합니다.

이렇게 위와 같은 페이지가 로딩되었고 Dockerfile에 작성한 내용도 같으면 dev/dev1234 계정으로 로그인합니다.

접속하면 다음과 같은 페이지를 확인할 수 있겠습니다.

😎 작성후기

지난 글에서도 이야기했지만 처음 배운 기술이다 보니 익숙하지 않습니다. 하지만 이렇게 실제로 페이지를 구동시켜 보니 점점 익숙해지는 것 같은 기분이 듭니다, 다음 게시글에는 RabbitMQ 관리 페이지에서 메시지를 보내보는 실습을 진행해 보겠습니다.

📋 참고 사이트

https://adjh54.tistory.com/496#1.%20Dockerfile%20%EC%88%98%ED%96%89%EA%B3%BC%EC%A0%95-1-2

https://psychoria.tistory.com/541

https://printf-hellojudyworld.tistory.com/28

작성계기는 하단의 게시글에서 말했듯이 프로젝트에 현재 사용하고 있고 원리를 파악하고 실제로 적용해보고자 작성하게 되었습니다.

https://velog.io/@half-phycho/RabbitMQ-AMQP란-무엇인가

이전 게시글에서는 RabbitMQ의 상위 개념인 AMQP에 대해 학습을 해보았으니 이제는 본격적으로 RabbitMQ에 대해 이론적으로 알아보고 다음 게시글에서는 실제로 RabbitMQ를 설치하고 운영해보도록 하겠습니다.

📚 RabbitMQ란 무엇인가?

RabbitMQ는 간단히 이야기하면 AMQP의 구현 체중 하나로 AMQP 프로토콜 기반의 경량화된 메시지 브로커 시스템입니다. 주로 요청을 많은 사용자에게 전달하는 경우, 많은 작업이 요청되어 처리해야 할 경우, 요청에 대한 처리시간이 긴 경우에 주로 사용됩니다. 이러한 특징으로 마이크로 서비스, 분산 시스템, 서버리스 아키텍처 등 다양한 현대적인 애플리케이션에서 널리 사용되고 있습니다.

메시지 브로커
서로 다른 언어로 작성되었거나 다른 플랫폼에서 구현된 애플리케이션, 시스템, 서비스 간의 통신과 정보 교환을 가능하게 하는 소프트웨어를 부르는 말 입니다.

💡 AMQP의 구현체들

그렇다면 다른 AMQP의 다른 구현체도 있다는 이야기인데 AMQP의 구현체는 다음과 같습니다.

• RabbitMQ
• ActiveMQ
• IBM MQ
• Azure Service Bus

이거 외에 StormMQ, OpenAMQ등 다른 AMQP구현체들이 많습니다, 이중에서 가장 많이쓰고 익숙한거는 RabbitMQ라고 생각합니다.

👍 RabbitMQ의 장점

RabbitMQ의 장점에 대해서는 타 게시글을 인용했지만 제가 생각하는 장점만 적어보겠습니다.

1. 다양한 통합 옵션 지원 : 다양한 프로그래밍 언어와 프레임워크를 지원하며, REST API, WEB Socket등을 통한 다양한 통합이 가능합니다. (실제로 제가 다니는 회사에서는 RabbitMQ를 WEB Socket와 통합하여 사용합니다.)

2. 다중 프로토콜 지원 : 공부하면서 알게되었는데 RabbitMQ는 기본적으로 AMQP 프로토콜이지만 MQTT, STOMP와 같은 다양한 메시징 프로토콜을 지원합니다.

3. 높은 메시징 처리량 : 메모리와 디스크에 메세지 저장이 가능하여 높은 메시지 처리량과 함께 높은 가용성을 제공합니다. 이로 인해 RabbitMQ가 대규모 분산 시스템에서도 안정적으로 사용 될 수 있습니다.

4. 트랜잭션 지원 : 메시지 발생, 메시지 확인, 삭제 등의 작업을 하나의 트랜잭션으로 묶어서 처리가 가능하여 데이터의 일관성과 신뢰성을 높이는 데 도움이 됩니다.

😕 RabbitMQ의 단점

모든 기술이 그렇듯 장점만 있는 것이 아니라 반드시 단점도 존재합니다.

러닝커브 상승 : 아무래도 저는 학습 러닝 커브가 상승하는 것을 뽑을 거 같습니다. RabbitMQ는 다양하고 강력한 기능들이 있는 만큼 이해하고 사용하기까지 많은 시간과 노력이 필요합니다, 또한 메시지의 신뢰성을 보장하기 위한 다양한 설정(메시지 지속성, 메시지 확인 등)을 올바르게 구성하기 위해서도 공부가 필요하다고 느꼈습니다.

😎 이론지식을 보고 느낀점

RabbitMQ를 들어가기 전에 AMQP를 먼저 공부를 하고 RabbitMQ를 보면 어느 정도 이해할 수 있을 줄 알았는데 솔직히 이야기하면 아직도 이해 못 하는 용어투성이입니다. 하지만 지금까지 이러한 경우들은 수없이 있었습니다. 대학생 때 처음으로 Spring Boot을 배울 때에도 첫 직장에서 처음으로 복잡한 쿼리를 작성할 때도 그리고 지금 회사에 들어오기 위해 AWS를 공부할 때도 어려운 것, 이해가 힘든 것투성이였습니다. 그렇기에 이 RabbitMQ도 똑같이 어려워하고 지속적으로 공부하여 저의 것으로 만들기 위해 노력하다 보면 어느 순간 익숙해질 것으로 생각합니다.

📋 참고 사이트

https://www.ibm.com/kr-ko/think/topics/message-brokers

https://velog.io/@sdb016/RabbitMQ-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90

https://yuna-ninano.tistory.com/entry/%EB%A9%94%EC%8B%9C%EC%A7%80-%ED%81%90-RabbitMQ%EB%9E%80-%EA%B0%9C%EB%85%90-%ED%8A%B9%EC%A7%95-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%A9%B4%EC%A0%91-%EB%8C%80%EB%B9%84

(항상 감사합니다.)

제가 지금 하고 있는 프로젝트에서는 메시지를 보내고 비동기로 관리하기 위해 RabbitMQ를 사용하고 있습니다. 그런데 RabbitMQ는 말로만 들어봤지 실제로 어떻게 동작을 하는지 그리고 이걸 왜 그렇게 많은 기업에서 요구하는지 알고 싶었습니다. 그래서 RabbitMQ를 조금 알아봤는데 RabbitMQ이전에 상위개념인 AMQP를 먼저 알아보고자 이렇게 정리해 보고자 합니다.

📚 AMQP (Advanced Message Queue Protocol)란?

AMQP는 메시지 지향 미들웨어 (MOM)을 위한 표준 응용 계층 프로토콜입니다. 풀어서 이야기하면 메시지 통신을 위한 규약이라고 보면 되겠습니다. 서로다른 특히 플랫폼에 종속적인 제품들 사이에서 채팅해야 하는 경우가 있습니다. 이럴 때 메시지 교환을 위해 메시지 포맷을 변환 목적으로 메시지 Bridge를 사용하거나 서로 다른 두 시스템을 통합할 필요가 있었습니다.

그래서, 서로 다른 시스템 간의 최대한 효율적으로 메시지를 교환하기 위해 AMQP 프로토콜이 등장했습니다. 이러한 규약 기반으로 만들어진 구현체 중에 하나가 RabbitMQ입니다.

🖼️ AMQP 주요 구성요소

출처 : https://www.wallarm.com/what/what-is-amqp

💡 AMQP 특징

• 플랫폼에 종속적이지 않다.
• AMQP는 교환기(Exchange)와 큐(Queue)를 사용하여 메시지를 다양한 방법으로 라우팅이 가능
• 메시지를 확실히 전달하고 손실을 방지하기위해 메시지 전달보장 기능을 지원합니다.
• 메시지 순서보장 및 트랜잭션 처리로 안정적으로 메시징이 가능합니다.
• Exchange를 사용해 여러가지 방식의 라우팅을 제공합니다.
• SSL/TLS를 사용한 보안 및 사용자 인증을 지원하여 안전한 메세징이 가능합니다.

📗 Exchange 타입

AMQP는 메시지를 적절한 Queue에게 바인딩하기위해 다양한 타입의 Exchange속성이 존재합니다.

설명에 앞서 라우팅 키, 바인딩 키를 언급하는데 라우팅 키를 설정하는 주체는 Publisher고 바인딩 키를 설정하는 주체는 Consumer입니다. 여기서 (라우팅 키 = 바인딩 키) 의미를 가집니다.

Direct Exchange

Publisher가 메시지를 보낼 때 보내야할 Exchange의 명칭과 라우팅 키를 함께 보내면 Exchange에서는 라우팅 키와 바인딩 키가 일치하는 Queue에 메시지를 보내는 방식입니다.

다음과 같은 AMQP 구조가 있으면 Publisher가 Exchange E1과 라우팅 키 success를 보내면 먼저 Exchange E1으로 연결되고 라우팅 키 success와 일치하는 Q1 Queue로 메시지를 전달합니다.

Fanout Exchange

Publisher가 특정 Exchange에 라우팅 키와 상관없이 Exchange에 연결된 모든 Queue에게 메시지를 보내는 방식입니다. 이 Exchange 방식은 알림 시스템 등에 사용됩니다.

Topic Exchange

Publisher에서 보내는 라우팅 키의 패턴에 따라 메시지를 라우팅 하는 방식입니다. 만약 라우팅 키의 구분을 "/" 으로 지정하고 바인딩 시 와일드 카드로 "*","#"을 지정하여 사용할 수 있습니다.

위의 예시처럼 라우팅 키 요청을 check.* 로 설정하면 바운딩에서 check와 관계된 바인딩에만 메시지를 송신합니다.

headers Exchange

메시지의 헤더 정보를 기반으로 라우팅을 하는 Exchange입니다. 다른 Exchange와 다르게 라우팅 키를 사용하지 않고 메시지 자체의 헤더와 바인딩 된 Queue의 헤더 조건과 일치할 때 Queue로 전달됩니다. 특정 헤더를 가진 메시지만 큐에 전달하도록 만들 수 있습니다.

📘 AMQP의 계층 구조

AMQP의 계층 구조는 OSI 7 Layer 구조와 비슷한 부분이 있어서 OSI 7 Layer 구조를 알고있으면 이해가 쉬울거라고 생각합니다.

📙 AMQP의 프레임 종류

AMQP는 프레임 기반 프로토콜 입니다. 프레임은 AMQP의 전송 단위이며, 각 프레임에는 특정 작업에 대한 명령 혹은 데이터가 포함됩니다.

⛓️ AMQP의 통신 흐름

1. 연결 및 채널 생성
Publisher가 메시지 브로커에 연결을 요청하고 연결이 수립되면 여러개의 채널을 생성할 수 있습니다.

2. Exchange 및 Queue 선언 이때 Publisher는 Exchange 선언 후 라우팅 규칙을 정하고 Queue 선언시에는 Exchange와 Queue사이의 바인딩 규칙을 설정합니다.

3. 메시지 전송 Publisher는 특정 Exchange에 메시지를 전송합니다. 메시지에 라우팅 키가 포함할 수 있으며 Exchange는 라우팅 규칙에 따라 특정 Queue에 메시지를 전달합니다.

4. 메시지 소비 Queue에서 Consumer에게 메시지를 전달합니다. Consumer가 메시지를 성공적으로 전달받으면 확인 응답(ACK) 혹은 부정 응답(NACK)을 보냅니다.

❓ 왜 많이 사용하는가?

요즘 많은 소프트웨어가 확장 목적으로 마이크로서비스 아키텍처를 도입하게 되었습니다, 확장성은 좋아졌으나 모듈 간 안정적이고 효율적인 통신이 필요하게 되었고 이때 AMQP는 데이터의 손실이나 중복 없이 전달해야 하는 경우 그리고 라우팅이 복잡한 시스템에 적합한데 이러한 구조를 가진 소프트웨어는 대부분 비교적 최근에 나오는 소프트웨어들이고 그래서 기업들이 많이 요구하는 거 같다고 생각합니다.

📋 참고 사이트

https://velog.io/@holicme7/표준-메세징-프로토콜-정리-AMQP-STOMP-MQTT

https://jeongchul.tistory.com/812#AMQP%20%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-1

https://blog.naver.com/pjt3591oo/223363564670

(항상 감사합니다.)

작성 계기는 이직한 회사에 입사한 지 얼마 안 된 무렵이었습니다. 저희 회사는 CI/CD를 젠킨스로 운영하는데 기존에는 배포할 때 새롭게 반영이 되었는지 확인이 안 되는 문제와 기존 이미지가 업데이트되면 만일의 비상 상황에 이전 버전으로 롤백시킬 수도 없다는 단점이 있었습니다, 물론 새롭게 반영할 때마다 젠킨스 스크립트를 수정하면 되지만 작업도 결국 사람이 하기에 버전수정을 위해 매번 스크립트를 수정 및 반영하는게 매우 번거롭고 잊어먹는 경우가 발생했습니다. 그래서 저의 사수님은 이러한 문제를 해소하고자 기존 도커로 운영 중인 애플리케이션 버전관리 체제와 버전을 태그에 붙이는 방식을 설계하라는 업무를 받았습니다.

버전체계 변경

기존에는 단순히 X.Y 버전 체제로 배포버전과 수정버전만 확인 가능했습니다. 그래서 체제를 많은 소프트웨어 회사와 프로젝트들이 사용하는 X.Y.Z (시맨틱 버저닝)을 사용하기로 했습니다.

버전관리 방식 변경

기존에는 방식은 API를 수정하고 반영하고 추가로 젠킨스 스크립트도 변경해야 비로소 새로운 버전으로 컨테이너가 생성되었습니다. 이렇게 되니 API 수정과 별개로 젠킨스 스크립트도 수정해야 해서 좀 번거로운 부분이 있었습니다. 그래서 생각해 낸 방법은 Spring Boot Gradle의 version속성을 이용하여 버전관리를 해보자고 생각했습니다.

• 기존 버전관리 방식

• 설계한 신규 버전관리 방식

수정한 부분

• 애플리케이션(Spring Boot) 수정사항
  1. 버전을 젠킨스 스크립트에 직접입력하는 방식에서 Spring Boot API build.gradle파일의 version 변수를 사용
  2. 젠킨스에서 build.gradle에 설정되어있는 version 속성 값을 가져오는 태스크 함수 추가

// build.gradle
version = '{버전정보 X.Y.Z}'

// 중간생략

tasks.register('{태스크 함수 명}') {
    doLast {
        println version
    }
}

• 젠킨스 스크립트 수정사항
  1. 애플리케이션의 버전을 가져오는 stage추가
  2. stage 내부에서 Gradle 실행권한 부여
  3. 태스크 실행하여 버전값 가져오는 코드 추가
  4. 가져온 버전을 도커 태그에 반영

// 젠킨스 스크립트
stage('get version') {
    steps {
        script {
            // Gradle 실행권한 부여
            sh 'chmod +x ./gradlew'

            // Gradle의 callVersion 태스크를 실행하여 버전 값 가져오기
            def appVersion = sh(returnStdout: true, script: './gradlew -q callVersion').trim()

            // 가져온 버전을 환경 변수로 설정
            env.DOCKER_TAG = appVersion
        }
    }
}

개선결과

이러한 세팅을 선임님과 CTO분께 리뷰를 하고 이 방식이 좋겠다는 피드백을 받아 이방법을 사용하기로 결정했습니다. 결과적으로 애플리케이션의 API를 수정하고 build.gradle의 version만 수정하면 별다른 작업이 필요없어졌고 나아가 더이상 소프트웨어 버전수정을 위해 젠킨스 스크립트를 수정할 필요가 없어졌기에 API 배포과정을 많이 간소화 시킬 수 있었습니다.

취업은 했지만 그동안 정말 많은 고난과 역경들이 있었습니다. 그 사이에 어떤일들이 있었는지는 장문으로 적기에는 너무 길어서 간략하게 나열하면서 그동안 1년동안 무엇을 했고 어떻게 힘들었는지 나아가 긴 시간동안 어떻게 버텼는지 정리하고자 이렇게 간만에 (거의 3개월) 블로그를 작성해 봅니다.

고통과 고난들

• 모아둔 돈이 줄어들고 있다는 압박감을 항상 받음
• 취업이 안되어서 스스로 자책을 하면서 마음이 더욱더 망가짐
• 스트레스를 너무 받아서 응급실에 갈 정도로 흉통을 달고 살게 됨
• 주변에서는 괜찮다고 하지만 오히려 안심이 안되는 말할 수 없는 느낌
• 서류광탈만 수 백번을 하면서 자존감이 바닥을 뚫고 지하실까지 내려감
• 마지막 면접에 떨어져서 절망과 분노를 한번에 느낌
• 아침부터 잠들기 전까지 좋지않은 생각이 머리속을 지배
• 세상을 향한 무의미한 분노
• 주변인들의 취업소식에 자연스럽게 비교하면서 스스로 자존감을 하락

기타 등등 하나하나 나열하기도 힘들정도 였습니다. 특히 힘들었던거는 아무리 공부를해도 결과가 안나온다는 절망감과 포기하고 싶어지는 마음이 커졌고 스스로 노력해도 결과가 없으면 아무런 소용도 없다는 생각이 머릿속을 지배해서

과정을 종요시하는 나 VS 결과가 없으면 전부 소용없다라고 말하는 나

이렇게 자아가 서로 부딪히면서 매일마다 정신적으로 전쟁터에 있는 기분을 항상 느끼면서 살았던거 같습니다.

하지만 그럼에도 저라는 인간 성격상 절대로 포기하고 싶은 마음은 전혀없었기에 죽어라 노력을 했습니다. 만약 여전히 취업을 못했어도 여전히 저는 어떠한 방향이든 노력하고 있었을 것 입니다.

취업을 위해 노력 한 것들

• 항상 이력서 점검하고 주변 지인들 혹은 전문가에게 코칭받기
• 개인 포토폴리오 강화를 위해 velog 계정 개설 및 운영
• 정보처리기사 자격증 취득을 위해 학원수강
• 파이썬 기반 랭체인 신기술 공부
• 기술력을 강화하기 위해 개인 서비스를 구축하고 운영 (지금은 임시로 폐쇄했습니다.)
• 면접을 복기를 하면서 면접기술 강화

이렇게 주말도 낮도 밤도 없이 죽도록 노력해서 결국 취업했지만, 이런 생활을 하도록 유지하는 게 정말 힘들었습니다. 그리고 취업 활동을 하면서 느낀 게 저의 주변의 저를 생각해 주는 사람이 정말 많았고, 그들에게 도움을 많이 받은 덕분에 힘들어도 앞을 바라보고 걸을 수 있었습니다, 항상 그들에게 감사하고 있습니다.

취준생 시절 꾸준함을 유지할 수 있었던 비법

1. 항상 몸을 바쁘게 해라!

• 이건 정말 중요하다고 생각합니다, 간단히 말하면 몸이 바쁘면 잡생각도 안나고 우울감에 사로잡히기 쉽지가 않습니다.

2. 일단 밖으로 나가라!!!

• 이건 1번과 연결되는데 마찬가지로 집에 있으면 자연스럽게 혼자 있으니까, 우울감에 잡히고 결국 스스로 고통만 줍니다. 설령 아무것도 안 하더라도 밖으로 나가서 걷기라도 하는 게 충분히 도움이 됩니다.

3. 용모를 항상 단정히 해라!!!

• 제가 좋아하는 말 중에 이런 말이 있습니다. "복장의 흐트러짐은 마음의 흐트러짐이다." 저의 경우에는 해당한다고 생각하는 게 면바지를 입고 공부를 하는 것과 체육복을 입고 공부를 하는 거는 이상하게 긴장감의 무게가 다르고 공부하는 시간이 달랐습니다.

4. 쉴때는 반드시 휴식을 취해라!!!

• 정확히 말하자면 밖에서 활동적인 것을 하라는 이야기입니다. 한편으로 부끄럽지만 저는 이 취업 준비 기간 동안 틈틈히 신나게 놀았습니다.

  1. 보고 싶었던 아티스트 콘서트 관람
  2. 읽고 싶었던 책을 읽기
  3. 그림 그리기
  4. 가고 싶었던 게임 행사 관람
  5. 친구들과 처음으로 해외여행
  6. 서울에 있는 유명한 건축물이나 문화재 탐방

  이렇게 다양한 장소를 다니면서 스트레스 관리를 했고 서울에 있는 유명한 건축물을 탐방하면서 서울이라는 도시를 이해하는 시간을 가질 수 있었습니다. 이러한 경험들이 저의 취업활동을 지속하게 해준 연료가 되었습니다.

5. 힘들면 스스로 해결하지말고 주변에 도움을 요청해라!!!

• 앞에서 한 행동을 모두 하더라고 사람 마음이 그렇게 쉽게 치유되지는 않습니다. 저도 친구들과 해외여행을 다녀오고 한국에 도착한 직후에 우울감에 바로 휩싸였으니까요. 세상일은 스스로 해결할 수 있는 일은 별로 없다고 생각합니다. 그래서 저는 항상 주변인들에게 정말 힘들다고 내 이야기를 들어달라고 도움 요청을 많이 했습니다. 만약 본인의 이야기를 들어줄 상대가 없으면 자살 예방 전화든 뭐든 조금이나마 도움을 주는 게 있으면 도움을 받는 게 좋다고 생각합니다. 인생을 산 지 얼마 되지는 않았지만, 감정을 약간이라도 해소하는 게 얼마나 중요한지는 누구보다 잘 알고 있다고 말할 수 있습니다.

5. 조그마하고 사소한 일이라고 스스로 자랑스럽게 여겨라!!!

• 저는 취업 준비 기간 때 날마다 제가 해낸 일들을 사소한 것들이라도 적는 습관을 만들었습니다. 가령 매일 아침에 일찍 일어나고 이불 정리를 하고 독서를 하는 등 스스로 무언가를 했다면 전부 기록했고 반년 정도 하니까 다이어리의 내용이 꽉 차져 있었고 스스로 이렇게 많은 걸 했구나 라는걸 느낄 수 있었습니다.

과거의 나의 모습을 가진 사람들에게

솔직히 언젠가는 나아진다는 희망적인 말은 도저히 못 하겠습니다. 인생은 실전이기 때문이죠 하지만 이것만은 말해주고 싶습니다. 어디서 어떤 모습으로 어떤 일을 하더라도 스스로를 원망하고 심하게 자책하지 말아주세요. 현재 취업이 잘 안되는거는 여러분들 본인 잘못이 아니고 본인의 노력이 부족한거는 더더욱 아닙니다. 그렇기에 본인을 자책하지 말아주세요 본인을 몰아세우면 망가지는건 결국 본인입니다.

해당 게시글에서는 본격적으로 SpringBoot에 코드를 작성하여 실질적으로 s3에 이미지 혹은 파일을 업로드하는데 사전작업이 필요합니다.

• s3 버킷 생성
• IAM 사용자 생성

사전작업방법은 하단의 링크를 참고하시기 바랍니다.

https://velog.io/@half-phycho/AWS-Spring-Boot-S3-이미지-업로드-1

SpringBoot 코드 작성

사전작업을 마치셨다면 이제 본격적으로 코드를 작성해보겠습니다, SpringBoot에서는 다음과 같은 설정을 거쳐야합니다.

• application.properties 파일에 사용자 및 버킷 등록
• gradle에 Amazon S3 의존성 추가
• Amazon S3 config 파일 생성
• Amazon S3에 파일을 등록하는 기능 클래스 생성
• Spring Boot service layer에서 활용

이 게시글에서는 다음과 같은 환경에서 제작했습니다.

OS : window11
Framework : Spring Boot 3.4.5
gradle : 8.8

properties 파일 작성

제일먼저 application 파일에 사전에 만든 IAM사용자 정보와 S3 버킷의 정보를 등록해야 합니다.

# Amazon S3 config
cloud.aws.credentials.accessKey=
cloud.aws.credentials.secretKey=
cloud.aws.s3.bucket=
cloud.aws.region.static=
cloud.aws.stack.auto=false

# 파일이 업로드 되는 위치
file.upload.url=

• cloud.aws.credentials.accessKey : IAM 사용자 Access key를 입력합니다.
• cloud.aws.credentials.secretKey : IAM 사용자 Secret key를 입력합니다.
• cloud.aws.s3.bucket : 생성한 S3 버킷의 이름을 입력합니다.
• cloud.aws.region.static : 버킷을 생성한 리전을 입력합니다. 만약 한국리전인 경우 ap-northeast-2를 입력하면 됩니다.
• cloud.aws.stack.auto=false (선택) : 해당 설정은 EC2에 배포하는 용도인 경우에 설정하면 됩니다. EC2는 기본적으로 CloudFormation을 구성합니다. 그래서 사용할지 안할지를 선택하는데 해당 게시글에서는 사용하지 않기 때문에 false로 설정하겠습니다.

  CloudFormation : AWS 리소스를 생성하기 위한 각종 설정을 템플릿 파일로 만들어서 사용하는 도구입니다.

(IAM의 Access Key, Secret Key를 분실한 경우 사용자에서 액세스 키를 추가로 생성해야 합니다.)

Amazon S3 의존성 추가

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE'
}

해당 AWS를 연결하는 의존성을 추가합니다.

Amazon S3 config 파일 생성

import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;

import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;

@Configuration
public class s3SetConfig {

    @Value("${cloud.aws.credentials.accessKey}")
    private String accessKey;   // IAM Access Key

    @Value("${cloud.aws.credentials.secretKey}")
    private String secretKey;   // IAM Secret Key

    @Value("${cloud.aws.region.static}")
    private String region;      // S3 Location region

    @Bean
    public AmazonS3Client amazonS3Client() {

        // 임시로 자격증명
        AWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey); 

        return (AmazonS3Client) AmazonS3ClientBuilder // S3용 빌더
                .standard() // 기본 
                .withCredentials(new AWSStaticCredentialsProvider(credentials)) // IAM 사용자
                .withRegion(region)  // S3 버킷이 위치한 리전
                .build();
    }
}

해당 config파일을 보면 먼저 properies파일에 입력한 IAM의 accessKey, secretKey, region을 가져옵니다. 그리고 amazonS3Client Bean 객체를 등록하고 AWSCredentials 객체에 사용자를 등록한 후 리턴값으로 S3 빌더를 생성하는 코드 입니다.

S3에 파일을 등록하는 기능 클래스 생성

이제 S3에 파일을 저장하는 클래스를 만들어 보겠습니다.

import java.io.File;
import java.io.IOException;
import java.util.UUID;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;
import org.springframework.web.multipart.MultipartFile;

import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.model.CannedAccessControlList;
import com.amazonaws.services.s3.model.PutObjectRequest;

import lombok.extern.slf4j.Slf4j;

/**
 * S3 Bucket에 포스터 이미지 파일 업로드 class
 */
@Component
@Slf4j // 로그 기록 목적으로 추가한 lombok의 어노테이션 입니다.
public class awsfileUtil {

    // Amazon S3 버킷 이름
    @Value("${cloud.aws.s3.bucket}")
    private String filebucket;

    // 파일 업로드 경로
    @Value("${file.upload.url}")
    private String fileUrl;

    private final AmazonS3Client amazonS3Client;

    public awsposterfileUtil(AmazonS3Client amazonS3Client){
        this.amazonS3Client = amazonS3Client;
    }

    public String Upload(MultipartFile multipartFile){

        UUID uuid = UUID.randomUUID();

        // UUID 난수 + _ + 파일 원본 이름 
        String fileName = uuid + "_" + multipartFile.getOriginalFilename();
        String uploadImageUrl; // s3 저장경로
        File saveFile = new File(fileUrl, fileName); // 파일 위치정보

        if(!saveFile.getParentFile().exists()){ // 폴더 존재 여부 체크
            saveFile.getParentFile().mkdir(); // 폴더가 없으면 폴더 생성
        }

        try{
            multipartFile.transferTo(saveFile);// 생성한 파일 경로에 저장
            // 파일 업로드 후 S3경로 리턴
            uploadImageUrl = this.S3upload(saveFile, fileName);
        } catch(IOException e) { // 저장 실패
            saveFile.delete(); 
            uploadImageUrl = ""; 
            e.printStackTrace();
        }

        return uploadImageUrl; // s3 bucket에 올린 파일 URL 혹은 "" 리턴
    }

    /**
     * Amazon S3에 파일 업로드 후 폴더의 원본파일 삭제
     * 
     * @param uploadFile
     * @param fileName
     * @return String
     */
    private String S3upload(File uploadFile, String fileName){

        /**
         * 로컬 업로드 -> S3upload(저장한 로컬파일 위치, 새로 지정한 파일이름)
         * -> 로컬 업로드 파일 삭제
         */

        String uploadImageUrl = putS3(uploadFile, fileName); // s3 업로드

        if(uploadFile.delete()) { // 기존 로컬 환경에 업로드한 파일 삭제
            log.info("파일이 삭제되었습니다.");
        }else {
            log.info("파일이 삭제되지 못했습니다.");
        }

        return uploadImageUrl; // s3 bucket에 올린 파일 URL 리턴
    }

    /**
     * Amazon S3에 파일 업로드
     * 
     * @param uploadFile
     * @param fileName
     * @return String
     */
    private String putS3(File uploadFile, String fileName) {
        amazonS3Client.putObject( // s3 파일 업로드
                new PutObjectRequest(filebucket, fileName, uploadFile) 
                        .withCannedAcl(CannedAccessControlList.PublicRead)    
                        // PublicRead 권한으로 업로드 (사용자 모두가 접근 가능)
        );

        // s3 bucket에 올린 파일 URL
        return amazonS3Client.getUrl(filebucket, fileName).toString();
    }
}

저의경우에는 해당 기능을 다른 서비스에서도 활용이 가능하도록 작성했습니다, 해당 코드에서 중요한 부분중에 하나가 S3 CannedAccessControlList 권한 종류인데 권한 종류는 하단에 작성했으니 참고바랍니다.

S3 CannedAccessControlList 권한 종류

Amazon S3의 CannedAccessControlList(Canned ACL)는 버킷이나 객체에 대해 미리 정의된 권한을 설정할 수 있는 간단한 방식입니다. 각 Canned ACL의 권한은 다음과 같습니다.

추가 사항

1. 소유자: 버킷 또는 객체를 생성한 AWS 계정입니다.
2. 모두: 인증된 사용자와 비인증 사용자를 포함합니다.
3. 인증된 사용자: 유효한 AWS 자격 증명을 사용하여 로그인한 사용자입니다.
4. 계정 간 접근: 다른 AWS 계정과 객체 또는 버킷을 공유할 때 사용합니다.

Canned ACL은 S3 리소스에 대한 간단한 액세스 제어를 설정하는 데 유용하며, 상황에 맞게 적절한 ACL을 선택하는 것이 중요합니다.

Spring Boot service layer에서 활용

@Service
@Slf4j
public class fileService {

    private final awsfileUtil awsfileUtil;

    public fileService(awsfileUtil awsfileUtil){
        this.awsfileUtil = awsfileUtil;
    }

    public void fileSave(MultipartFile file) {
         String storedFileName = awsfileUtil.posterUpload(file);
    }

}

(단순사용은 이렇게 표현할 수 있지만 awsfileUtil에서 Exception을 발생할 수 있기 때문에 추가 설정사항이 필요할 수 있습니다.)

주의사항

만약 putS3 부분에서 Exception혹은 에러가 발생하면 properties파일을 제대로 작성했는지 그리고 IAM의 권한 부분을 확인하기 바랍니다.

참고 사이트

https://jojoldu.tistory.com/300

(항상 감사합니다.)

사이드 프로젝트를 진행하던중 이미지 업로드기능이 필요했고 그래서 초기에는 로컬PC에 이미지를 저장하는 방법을 썼고 브라우저에서 로컬PC로 파일을 저장하는 것 까지는 성공 했지만

로컬PC에 저장된 이미지를 브라우저에 출력하는 것은 성공하지 못했습니다.

그러던 와중에 Amazon S3에 파일을 저장하는 방식을 발견했고 예전에도 S3를 이용해 CI/CD를 구축하기 위해 S3를 사용한 경험이 있어서 S3에 업로드하는 방식으로 바꾸기로 했습니다. 또한 나중에 프로젝트를 현재는 로컬로 개발하고 있지만 운영은 AWS에서 할 생각이기에 나중에 파일 업로드 관련해서 별도 AWS환경에 맞게 수정을 많이 거칠 필요가 없기 때문에 이렇게 하기로 결정했습니다.

(해당 주제는 내용이 많기에 Amazon에서의 작업과 Spring Boot 코드작성 부분 이렇게 두 개로 나누어 작성할 계획입니다.)

Amazon AWS 준비목록

• S3 bucket 등록
• IAM 사용자 생성

S3 bucket 생성

S3 bucket은 이미지를 저장하는 저장소 입니다.

1. 버킷 생성

다음과 같이 Amazon S3으로 이동하고 버킷 만들기 버튼을 클릭하여 버킷 생성 준비를 합니다.

2. 버킷 이름 지정

버킷이름을 지정합니다.

3. 객체 소유권 지정

객체 소유권은 ACL 비활성화 시키는데 다른 계정은 접근하지 못하도록 하기위해 설정 한 것 입니다.

4. 퍼블릭 액세스 차단설정

만약 데이터가 중요도가 낮다면 퍼블릭 액세스를 차단하지 않아도 상관 없습니다. 하지만 뒤에서 설정할 IAM에서 허용한 사용자만 이미지를 입력하도록 하기위해 다음과 같이 설정합니다.

5. 버킷 버전 관리 / 기본 암호화 활성화

• 버킷 버전 관리 : 활성화하면 나중에 모든 객체의 보존, 검색 및 복원할 수 있습니다.
• 기본 암호화 : 서버 암호화는 기본으로 체크되어있는 것을 세팅합니다.

마지막으로 버킷 만들기버튼을 클릭하면 버킷이 생성됩니다.

IAM 사용자 생성

IAM(Identity and Access Management)은 AWS에서 사용자, 역할, 정책을 기반으로 리소스 접근을 제어하고, 안전하게 클라우드 환경을 구축하기위한 필수 서비스 입니다.

1. IAM 사용자 생성

먼저 사용자에서 사용자 생성버튼을 클릭하여 사용자를 생성합니다.

2. 사용자 이름 설정

생성할 사용자 이름을 입력하고 다음 버튼을 클릭합니다.

3. 권한 설정

권한을 설정하는데 2가지 방법이 있습니다. AWS에서 제공하는 권한 정책을 사용하거나 아니면 직접 정책을 생성하는 방법 이렇게 2가지가 있습니다.

첫 번째는 AmazonS3FullAccess 정책을 선택하는 방법입니다, 저는 개인적으로 이 방법을 선호하지 않고 있는데 AmazonS3FullAccess는 사용자가 S3의 모든 버킷에 접근을 가능하다는 의미이기에 보안 이슈가 생길 우려가 있습니다.

두 번째는 정책을 생성하는 방법입니다, 이 방법은 상세하게 create,delete,update,read 권한을 직접 지정할 수 있고 또한 특정 버킷에만 접근이 가능하도록 설정이 가능합니다.

3-1 권한 제작

스크립트 예시

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::{bucketname1}/*",
                "arn:aws:s3:::{bucketname2}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": [
                "arn:aws:s3:::{bucketname1}/*",
                "arn:aws:s3:::{bucketname2}/*"
            ]
        }
    ]
}

스크립트는 다음과 같이 작성 할 수 있겠습니다.

• Effect : 는 블록에 있는 권한을 허용할지 여부를 결정하는 내용 입니다. 그래서 Allow/Deny 이렇게 둘 중 허용하면 Allow 거부하면 Deny를 작성합니다.
• Action : 이 부분은 "문 편집" 이하는 부분의 작업추가 항목에 서비스를 검색하면 쉽게 추가할 수 있습니다.
• Resource : 여기는 접근할 영역을 선택하는 부분인데 여기서는 접근할 S3버킷을 입력하면 됩니다. 작성 규칙은 arn:aws:s3:::{버킷이름}/{접근할 리소스} 이런식으로 작성하는데 만약 접근할 리소스 부분에 *를 입력하면 해당 버킷의 모든 내용에 접근하겠다는 의미 입니다, 그리고 버킷을 여러개 설정하고 싶으면 위의 예시대로 ,을 붙이고 뒤에 버킷을 추가합니다.

만약 권한을 생성한다면 해당 스크립트를 참고 하시기 바랍니다.

사용자 생성완료

사용자 생성을 완료하고 사용자 목록 페이지에서 생성한 사용자로 이동하면 다음과 같이 확인할 수 있습니다.

액세스 키 생성

실제로 S3에 업로드를 하기위해서는 액세스 키가 필요합니다. 첫 번째로 액세스 키 대안을 선택해야하는데 위의 이미지처럼 맨 처음 사례를 선택하고 확인 부분을 체크 합니다.

액세스 키 생성 완료

선택적으로 태그를 입력하고 다음단계로 넘어가면 이렇게 액세스 키를 생성되는 것을 확인할 수 있습니다.

(액세스 키의 secret을 분실하면 다시 확인이 불가능하나 액세스 키는 추가적으로 생성이 가능합니다.)

참고 사이트

https://smilesharkhelp.zendesk.com/hc/ko/articles/6193081783823--IAM-IAM-S3-Access-Key-%EB%B0%9C%EA%B8%89-%EA%B0%80%EC%9D%B4%EB%93%9C

https://j-d-i.tistory.com/271

https://somaz.tistory.com/181

(항상 감사합니다.)

일단 크게 2가지 이유가 있다. 최근에 과제테스트를 하면서 Docker 파일을 만들고 Docker 파일만으로 프로젝트를 실행하라는 과제를 받았다. 과제를 무사히 수행했지만 부족한 부분이 있었고 어떻게 보면 이유가 가장 컸다. 최근에 만든 서비스인 JPBoard 서비스를 운영하면서 AWS로부터 영수증이 왔는데 금액이 60달러나 되었다.

여기서부터는 예상이 된다고 생각하는데 간단히 이야기하자면 돈으로 두들겨 맞고 정신 차린 것이다. 애초에 운영 Linux 서버를 Red Hat을 사용한 것이 문제점이라고 생각한다. 정확히는 Red Hat을 사용한 이유가 문제라고 할 수 있다. 내가 원하는 mariaDB버전이 없어서 Red Hat을 썼다. 만약 지금처럼 Docker를 사용하여 프로젝트를 운영했다면 비용이 최소한 지금보다는 적게 나왔을 것이다.

현재는 문제를 해결했으니 정리해보자는 차원에서 작성하게 되었다.

Docker 기본설명

Docker는 간단히 이야기 하면 컨테이너를 실행하기 위한 소프트웨어이다. 자세히 이야기 하면 Docker는 GO언어 기반으로 만든 리눅스 컨테이너 기반으로 하는 오픈소스 가상화 플랫폼이다.

Hypervisor, 컨테이너 특징 및 비교

Docker를 설명하기 이전에 Hypervisor와 컨테이너를 설명하고 넘어갈 필요가 있다.

가상화 물리적인 하드웨어를 추상화하여 여러 개의 가상 컴퓨터처럼 활용하는 기술

가상머신 가상머신은 물리적 하드웨어 시스템에 구축되어 자체 CPU, 메모리, 네트워크 인터페이스 및 저장공간을 갖추고 가상 컴퓨터 시스템으로 작동하는 가상환경이다.

Hypervisor

하이퍼바이저는 가상화 계층을 구현해 주는 소프트웨어로 위의 그림을 보면 하이퍼바이저 위에 Virtualzation으로 그려진 곳이 가상화 계층인데 원래는 가상화 구조에서 호스트 OS의 하드웨어 자원과 가상머신은 직접 연결을 해줄 수 없는데 여기서 하이퍼바이저가 가상머신에 자원 및 네트워크를 할당해 주어 일종의 가상머신 매니저 역할을 수행한다. 하이퍼바이저는 실제로 가상머신의 생성, 실행, 삭제 등 모든 환경을 관리하기에 (VMM : Virtual Machine Manager)으로 불리기도 한다.

컨테이너(Container)

컨테이너는 애플리케이션을 실행하는 데 필요한 모든 구성요소와 기능을 갖춘 소프트웨어 단위이다. 기존 OS를 가상화 시키는 것에서 OS레벨의 가상화로 프로세스를 격리시켜 동작한다. 가상머신과 비교했을 때 소프트웨어 단위이기에 용량이 적고 이식성이 뛰어나다. 대표적으로 MSA(Micro Service Architecture)기반 서비스에 많이 쓰인다.

가상머신 VS 컨테이너

Docker 설치

Docker는 앞에서 컨테이너를 운영하기 위한 소프트웨어의 일종이라고 했다. 실제로 컨테이너를 만드는 것만 보면 Docker가 필요없긴 하다. 하지만 컨테이너를 효과적으로 다루고 싶으면 Docker가 필요하다.

https://docs.docker.com/engine/install/

위의 사이트는 Docker를 설치하는 방법을 알려주는 사이트이다. 하지만 이 게시글에서는 Docker를 설치하는 OS환경은 Amazon 2023 AMI 이다.

yum 업데이트

시스템의 모든 패키지를 최신 버전으로 업데이트

> sudo yum update -y

Docker 설치

> sudo yum install docker -y

Docker 실행

Docker를 설치하는 순간 자동으로 실행이 된다.

> sudo service docker start

Docker 관련 명령어

컨테이너 생성 및 시작 (run)

> docker run [옵션] 이미지명[:태그명] [인수]

• 옵션들
  • --attach, -a : 표준 입/출력/오류 출력을 첨부한다.
  • --cidfile : 컨테이너 ID를 파일로 출력한다.
  • --detach, -d : 컨테이너를 생성하고 백그라운드에서 실행한다.
  • --interactive, -i : 컨테이너의 표준 입력을 연다.
  • --tty, -t : 단말기 디바이스를 사용한다.
  • --name : 컨테이너 이름을 지정한다.
  • --rm : 실행이 끝나고 즉시 제거한다.

컨테이너 생성 (create)

> docker create [이름]

컨테이너 시작 (start)

컨테이너 시작은 기본적으로 백그라운드로 실행된다.

> docker start [옵션] [컨테이너 식별자]

• 옵션들

  • --attach, -a : 표준 입/출력/오류 출력을 첨부한다.
  • --interactive, -i : 컨테이너의 표준 입력을 연다.

• 컨테이너 식별자

  • 컨테이너 고유 ID 혹은 Name

컨테이너 정지 (stop)

> docker stop [옵션] [컨테이너 식별자]

• 옵션들

  • --time, -t : 몇초 후 정지할 것인지 지정 (기본값은 10초)
  • 강제정지 명령어 : docker contianer kill

• 컨테이너 식별자

  • 컨테이너 고유 ID 혹은 Name

컨테이너 삭제 (rm)

> docker rm [옵션] [컨테이너 식별자]

• 옵션들

  • --force, -f : 실행 중인 컨테이너를 강제로 삭제
  • --volume, -v : 할당한 볼륨을 삭제
  • 도커 컨테이너 전부 삭제 : docker rm `docker ps -a --quiet`
  • 불필요한 이미지/컨테이너 전부 삭제 : docker system prune

• 컨테이너 식별자

  • 컨테이너 고유 ID 혹은 Name

컨테이너 로그 (logs)

> docker logs [옵션] [컨테이너 식별자]

모든 컨테이너 목록 보기

> docker ps -a

docker 이미지 목록 보기

> docker images

docker 이미지 삭제

> docker rmi [이미지 식별자]

• 이미지 식별자
  • 이미지 고유 ID 혹은 Name

참고 사이트

https://khj93.tistory.com/entry/Docker-Docker-%EA%B0%9C%EB%85%90

https://aws.amazon.com/ko/compare/the-difference-between-containers-and-virtual-machines/

https://www.redhat.com/ko/topics/containers/containers-vs-vms

https://selog.tistory.com/entry/%EA%B0%80%EC%83%81%ED%99%94-%EA%B0%80%EC%83%81%EB%A8%B8%EC%8B%A0VM%EA%B3%BC-%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

https://velog.io/@milkskfk5677/AWS-EC2에-Docker-설치하기

https://imjeongwoo.tistory.com/111

(항상 감사합니다.)

지난번 VSCode 게시글을 작성하고 오랜만에 작성하는 글입니다.

올 해 시작하고 지금까지 정신없이 바빴던거 같습니다, 현재는 회사를 그만두고 지금 열심히 구직활동을 하고있지만 연이은 실패에 스트레스로 응급실에 갈 정도로 심하기도 했습니다, 하지만 그럴때 마다. 여기서 절망하면 영원히 돌아오지 못할거라는걸 본능으로 알았는지 계속 무언가를 시도 한 거 같습니다. 면접도 꾸준히 보고 처음으로 과제테스트라는 것도 해보았는데 좋은 경험이었습니다.

결국 탈락했지만 그 회사에서 답변으로 기본기있게 세심하게 잘 만들었고 유닛테스트도 빠지지 않고 진행한 흔적을 보고 꼼꼼함을 느낄 수 있었지만 동시성 문제에 대한 고민이 없던 것에 아쉬움이 있어서 불합격을 시켰다고 한다. (뭐 어쩔수 없지~~)

그리고 면접을 계속봤지만 3번중에 2군데는 탈락하고 1군데 결과를 기다리고 있는 상태입니다.(합격했으면 좋겠다.) 현황이야기는 여기까지만 하고 서비스에 대해 설명드리겠습니다.

서비스를 만들게 된 계기

게시글 제목대로 서비스의 이름은 JPBoard인데 JPBoard는 간단하게 말하자면 일본의 아티스트들이 한국에 내한을 하게되면 그 일정을 하나의 달력에서 볼 수 있게하는 서비스입니다.

이 서비스를 만든 이유를 설명하자면 작년으로 거슬러 올라가야 합니다.

위의 사진은 작년에 YOASOBI라는 아티스트 그룹이 한국에서 공연했을때 거기서 찍은 사진입니다.

공연이 끝나고 인천에서 서울로 돌아가는 버스 안에서 새로운 서비스의 주제를 생각하던 중 일본에 내한하는 아티스트들의 일정을 한번에 확인하면 좋을텐데 라는 생각을 하게 되었고 그 날 버스에서 생각한 아이디어가 지금의 서비스를 만들게된 계기가 되었습니다.

서비스 설명

현재 AWS에서 동작하고는 있지만 현재 도메인을 등록하지 않아서 IP로 접속해야합니다. 향후 안정화가 되면 도메인을 신청고 정식적으로 운영및 홍보를 할 계획입니다.

https://jpboard.co.kr/main

메인화면

위의 화면이 메인화면으로 간단하게 달력에 일정을 표시하고 일정을 클릭하면 해당 콘서트의 상세정보가 modal창으로 출력하는 방식입니다.

회원가입

회원가입은 일단 아이디, 비밀번호, 닉네임은 필수입력이고 이메일 수신여부와 선호하는 아티스트를 선택입력으로 넣었습니다. 이메일 수신여부는 나중에 추가할 예정이지만 매달 1일마다 등록한 이메일로 월간 콘서트 및 예매 일정을 송신하기 위해 허가를 받는 것 입니다.

앞으로 추가할 기능들

현재는 단순하게 회원가입 및 콘서트 일정 확인만 있지만 앞으로 다음과 같은 기능 및 개편을 할 예정입니다.

• 메인페이지에 달력과 더불어 공연 포스터를 출력하고 마찬가지로 클릭하면 modal창으로 콘서트 정보 조회
• 웹사이트 소개 페이지
• 이메일 문의 페이지
• 도메인 등록
• 일본 아티스트 소개 페이지
• 자유게시판 기능
• 공연후기 페이지
• 이메일 전송 기능
• SNS로그인 도입
• 공지사항 페이지

프로젝트를 진행하는 과정에서 재부팅을 많이 해야하는 상황이 왔었다, 그래서인지는 몰라도 메모리를 많이 사용하게 되었다. 결과적으로 Gradle을 이용한 clean 및 Build가 되지 않았다, 결론부터 말하자면 메모리 부족으로 일어난 현상이었는데 나중을 대비해 이렇게 작성해둔다.

원인파악

확인해보니 Deamon을 실행할 수 없다는 메세지가 출력되었고 나아가 어째서 Deamon을 실행 할 수 없는지 원인을 검색해보니 다음과 같은 원인을 파악했다.

Deamon : Gradle에서 제공하고 있는 백그라운드 프로세서로 원래는 JVM이 실행되고 난 후에 Gradle이 실해되는데 그 과정에서 걸리는 시간을 줄여주고자 만들어진 프로세스이다.

• 메모리 부족
• Gradle과 java의 호환성 문제
• build.gradle 스크립트 오류

이렇게 일어날 수 있는 원인을 파악했다, Gradle과 java의 호환성 문제는 일단 가능성이 적다, 왜냐하면 Spring Initializr로 프로젝트를 구성했기에 버전 호환성은 알아서 맞춰준다, 그리고 build.gradle 스크립트 오류또한 문제가 없다. 애초에 스크립트 에러가 났으면 실행조차 되지 않았을 것이다. 그렇다면 이제 메모리 문제가 남는데 제일 까다로운 문제이기도 하다.

해결과정

1. IDE 재부팅

나는 작업을 VSCode로 하는데 재부팅을 해도 전혀 효과가 없었다.

2. PC 재부팅

PC 재부팅을 통해 메모리를 정리하고 여유공간을 만들어 주는 것도 시도했다. 하지만 마찬가지로 전혀 효과가 없었다.

3. 최대 Heap메모리 확장

Deamon은 기본적으로 아무런 세팅이 없으면 512mb로 세팅되어있다. 만약 변경하고 싶으면 프로젝트 root디렉터리에 gradle.properties파일을 생성하고 확장하는 설정을 넣어주어야한다.

파일을 추가했다면 하단의 설정을 properties파일에 작성하면 되는데 하단의 설정은 앞에서 말한대로 1GB로 확장하는 설정이다.

org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1g

다행히 문제를 해결할 수 있었다.

결론

다행히 문제를 해결할 수 있었지만 동시에 그런생각도 들었다, 대체 어디서 메모리를 많이 사용하길래 최대 Heap영역을 확장까지 해야 하는가 시간이 나면 필요없는 설정들을 정리해야겠다.

참고 게시글

https://docs.gradle.org/8.11.1/userguide/gradle_daemon.html

사이드 프로젝트를 진행하면서 동시성 문제 때문에 Redis를 사용하기로 결정했는데 Redis는 메모리기반 데이터베이스라는 것만 알았지 어떻게 사용하는건지 전혀 모르는 상태였다. 하지만 뭐든지 시작이 반이라고 Redis를 사용하는 방법을 찾아보니 직접 설치하는 방법부터 Docker를 사용하여 컨테이너로 실행시키는 방법이 있었다. 나는 기존에 Docker를 사용하고 있으니 Docker를 사용하여 Redis를 설치해보겠다.

docker에 Redis 가져오기

만약 내가 현재 작성하고있는 게시글대로 Redis를 설치한다면 나는 Window11 에서 세팅하고 있기에 주의바란다, 또한 WSL와 함께 Docker 그리고 Ubuntu도 설치되어있다는 가정하에 설명한다.

1. docker 설치확인

먼저 Docker가 설치되었는지 확인해야한다, 다음 명령어를 window Powershell에 입력하여 설치가 되었는지 확인한다.

docker --version

2. Redis Image 설치

Docker에 Redis를 정확히는 Image를 설치하는 방법인데 기호에 맞게 설치하도록 하자

// Redis image 최신버전 설치 명령어
docker pull redis

// Redis image 특정버전 설치 명령어
docker pull redis:[버전]

해당 명령어를 실행하면 다음과 같이 설치된다.

위의 명령어로 Redis 이미지 설치를 완료한 후 다음 명령어를 입력하여 제대로 설치되었는지 확인한다.

docker images

docker Desktop에서도 확인해보면 설치가 잘된 것을 볼 수 있다.

2. Redis Container 설치

이미지를 설치했으니 실제 동작하도록 이미지를 컨테이너로 실행해보도록 하자

docker run --name [컨테이너 이름] -d -p 6379:6379 [이미지 이름/이미지 ID]

-d : 컨테이너가 백그라운드로 실행하는 옵션 -p : <호스트 포트>:<컨테이너 포트>설정하는 옵션

해당 명령어를 실행하고 마찬가지로 Docker Desktop을 확인해보면 앞에서 입력한 명령어대로 실행되고 있는 것을 확인 할 수 있겠다.

3. Redis 접속해보기

현재 실행중인 Redis에 접속을 해보도록하자

// Docker에서 Redis가 설치되어있는 디렉터리 이동
docker exec -it [컨테이너 이름] /bin/bash

// Redis Server에 Redis-cli로 접속하기
redis-cli

이렇게 Redis Cli로 접속에 시도했고 접속되었다면 완료된 것이다.

4. 제대로 설치했는지 확인

설치라면 여기까지 설명하는것이 맞지만 위에서 봤듯이 나는 테스트 목적으로 Redis를 최신버전과 구 버전 이미지를 동시에 설치하고 컨테이너를 생성했다. 그래서 원하는 버전의 Redis를 설치했는지도 확인해야한다.

말은 이렇게 했지만 확인방법은 정말 간단하다. Redis-cli 입력에 info를 입력한 후 실행하면 설치된 Redis의 버전정보를 포함한 대부분의 정보를 확인할 수 있다. 보면 내가 원하는대로 6.2.6버전이 설치되있는 것을 확인 할 수 있겠다.

참고 사이트

https://msyu1207.tistory.com/entry/Redis-PubSub

https://velog.io/@juno0713/Windows-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-Docker%EC%97%90-Redis-%EC%84%A4%EC%B9%98

https://wooono.tistory.com/348

(항상 감사합니다.)

Spring Data JPA, QueryDSL, EntityManager를 쓰면서 실수 한 것들도 있었고 이거는 좀 괜찮은데? 라고 생각한 것들도 있었다, 실수를 줄이고 팁들을 공유하기위해 작성하기로 했다.

좋은 팁

1. QueryDSL와 JPARepository를 같이 쓰고 싶을 때

프로젝트를 진행하다가 기본적인 CRUD를 작성하자니 생산성이 떨어져 그냥 QueryDSL와 JPARepository를 같이 쓰면 어떨까? 라는 생각에서 찾아보니 방법이 간단했다.

https://jaehoney.tistory.com/230

간단히 기존의 인터페이스에 JPARepository, QueryDSL가 적용되어있는 인터페이스를 상속시켜주면 된다.

// JpaRepository : Spring Data JPA
// boardRepositoryCustom : QueryDSL을 사용하고 있는 인터페이스

@Repository
public interface boardRepository extends JpaRepository<Board, Integer>, boardRepositoryCustom{

}  

이렇게 작성하면 JPARepository와 QueryDSL을 동시에 사용하면서 SOLID규칙 중 DIP를 준수할 수 있다.

겪은 실수들

1. 이름작성 실수

사이드 프로젝트를 하면서 Spring Data JPA에 커스텀 메서드를 만들어야하는 경우가 있었는데 딱히 기능에 문제는 없어 보였지만 계속 컴파일 에러가 났다.

뭐라고 막 써있는데 likeRepository에서 문제가 났다고 한다, 하지만 거기에 있는 거는 JPARepository를 확장한 것과 커스텀으로 만든 메서드만 존재해서 처음에는 이상함을 느끼지 못했다, 그러다가 혹시 이름에 문제가 있는게 아닐까 싶어서 확인해보니 JPARepository를 추가하고 Keyword규칙기반으로 이름을 작성하니 정상적으로 동작하는 것을 확인했다.

https://velog.io/@633jinn/JPARepository-메소드-커스텀하기

그래서 기존에는 유저와 게시판하나를 선택하는 커스텀 메서드를 만들었는데 이렇게 이름을 지었었다.

@Repository
public interface likeRepository extends JpaRepository<Likes, Long>{
    Optional<Likes> findByUserBoard(User user, Board board);
} 

Keyword 규칙을 지키면서 이렇게 바꾸었다.

@Repository
public interface likeRepository extends JpaRepository<Likes, Long>{
    Optional<Likes> findByUserAndBoard(User user, Board board);
} 

2. Component로 생성되는 Bean 2개 동시에 사용하기

사용 팁 1번을 사용하면서 생긴 문제였다, JPARepository와 QueryDSL을 동시에 사용하다가 Bean주입을 2개를 하고말아 우선순위가 꼬여서 생긴 컴파일 에러였다.

그래서 방법을 찾아보니 방법이 2가지가 있었다.

@Primary방법을 사용하여 우선 순위를 지정하는 방법이고 다른 하나는 Bean의 이름을 다르게 지정하는 @Qualifier를 사용하는 방법이 있었다,

타입당 주입을 받는 클래스가 2개 였기에 @Primary방법을 사용했다. 하지만 @Primary에 주의사항이 있다, 동일한 타입당 한 번만 사용해야한다.

@Repository
@Primary
public interface mainRepository extends JpaRepository<Test, Integer>, subRepository {

}

...

@Repository
public class subRepositoryImpl implements subRepository {
    @Override
    public String getManagerName() {
        return "Department manager";
    }
}