스프링부트, Datagrip과 EC2의 mongoDB 연결하기

ZEDY·2024년 5월 13일
0

개발

목록 보기
5/11

gradle 의존성 추가

	implementation ('org.springframework.boot:spring-boot-starter-data-mongodb-reactive')

reactive의 의미 : 다른 DB를 추가적으로 사용한다면 reactive를 사용

설정 파일 작성

아.. 여기서 많이 헤맸다.

# MongoDB 연결 설정
spring:
  data:
    mongodb:
      host: <MongoDB 호스트>
      port: <MongoDB 포트>
      database: <데이터베이스 이름>
      username: <사용자 이름>
      password: <비밀번호>

오류

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.

Reason: Failed to determine a suitable driver class

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.

Reason: Failed to determine a suitable driver class

프링 부트 애플리케이션에서 데이터베이스에 연결할 때 발생하는 문제로 보입니다. 스프링 부트는 애플리케이션을 실행할 때 데이터베이스와의 연결을 자동으로 설정하는 기능을 제공하는데, 이 오류는 데이터베이스 연결 설정이 부족하여 발생합니다.

해결 방법

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class })
public class MobbyApplication {

	public static void main(String[] args) {
		SpringApplication.run(MobbyApplication.class, args);
	}

}

저 어노테이션을 달아주면 된다.

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class })은 스프링 부트 애플리케이션의 주요 설정을 정의하는 애노테이션 중 하나입니다. 이 애노테이션은 주로 애플리케이션의 메인 클래스에 사용됩니다.

DataSourceAutoConfiguration은 스프링 부트의 자동 설정 중 하나로, 데이터베이스와 관련된 설정을 자동으로 구성합니다. 이 설정은 스프링 부트 애플리케이션이 실행될 때 DataSource 빈을 자동으로 생성하고 구성합니다. 그러나 일부 애플리케이션은 DataSource가 필요하지 않을 수 있습니다. 예를 들어, MongoDB와 같은 NoSQL 데이터베이스를 사용하는 애플리케이션은 DataSourceAutoConfiguration을 비활성화할 수 있습니다.

따라서 @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class })은 스프링 부트 애플리케이션이 시작될 때 DataSourceAutoConfiguration을 비활성화하도록 지시합니다. 이를 통해 애플리케이션에서는 DataSource를 사용하지 않고 다른 유형의 데이터베이스 또는 저장소와 연동할 수 있습니다.

탄력적 IP 설정하기

탄력적 IP(Elastic IP)를 AWS EC2 인스턴스에 적용하는 것을 하려고 한다.

필요성

  1. 고정된 공용 IP 주소 : EC2 인스턴스는 기본적으로 임시적인 공용 IP 주소를 할당받습니다. 그러나 이 주소는 인스턴스를 중지하고 다시 시작하면 변경될 수 있습니다. 탄력적 IP를 사용하면 인스턴스에 고정된 공용 IP 주소를 할당할 수 있어서 외부에서 항상 동일한 IP 주소로 인스턴스에 접속할 수 있습니다.

  2. 네트워크 설정의 안정성 : 탄력적 IP를 사용하면 인스턴스를 중지하고 다시 시작해도 IP 주소가 변하지 않으므로 네트워크 설정을 다시 구성할 필요가 없습니다. 이는 네트워크 구성의 안정성을 높여줍니다.

  3. DNS 처리의 용이성 : 탄력적 IP를 사용하면 인스턴스의 IP 주소가 변경되더라도 DNS 레코드를 업데이트할 필요가 없습니다. 이는 DNS 관리를 간소화하여 운영 및 유지 보수를 용이하게 합니다.

장점

  1. 고가용성과 확장성 : 탄력적 IP를 사용하면 인스턴스를 중지하고 다시 시작하여도 IP 주소가 변경되지 않으므로 고가용성이 높아집니다. 또한, 여러 개의 EC2 인스턴스를 사용하여 애플리케이션을 확장할 때 탄력적 IP를 사용하면 각 인스턴스에 고정된 IP 주소를 할당할 수 있어서 확장성을 갖추게 됩니다.

  2. 보안 강화 : 탄력적 IP를 사용하면 인스턴스에 대한 외부 접속을 제한할 수 있습니다. 보안 그룹 설정 등을 통해 특정 IP 주소 범위에서만 접속할 수 있도록 제어할 수 있습니다.

  3. 블랙리스트 방지 : EC2 인스턴스가 악의적인 행위로부터 블랙리스트에 추가되어야 할 경우, 탄력적 IP를 사용하면 새로운 IP 주소를 할당하여 블랙리스트를 우회할 수 있습니다.

  4. 서비스 및 도메인 매핑 : 탄력적 IP는 서비스를 특정 고정 IP 주소에 매핑할 때 사용할 수 있습니다. 도메인과 탄력적 IP를 연결하여 사용자가 쉽게 서비스에 접근할 수 있도록 할 수 있습니다.

따라서, 탄력적 IP를 사용하면 EC2 인스턴스의 안정성과 보안성을 높이고, 네트워크 구성 및 DNS 처리를 간소화할 수 있습니다.

쉽게 말해서, 고정 IP를 사용하고 싶어서 쓰는 것이다.

방법

AWS -> EC2 -> 탄력적IP -> 탄력적 IP 주소 할당

저러고 맨 아래에 할당 버튼을 누르면 탄력적 IP가 할당된다.

그리고 할당된 탄력적 IP 주소를 AWS EC2의 인스턴스에 연결해주면 된다.

저기서 인스턴스 맞게 골라주면 된다.

그리고 연결을 누르면 끝이 난다.
인스턴스 들어가서 확인이 가능하다.

mongoDB 확인 : datagrip

EC2에 설치한 mongoDB를 Datagrip을 연결해서 사용할 것이다.

아 근데.. 내가 mongoDB에서 데이터베이스를 만들었는데 이름이 잘 기억이 안났다.

DB 접속

mongosh

이걸로 접속한다.

DB에서 어떤 Role이 있는지 확인하는 명령어

db.getRoles({showBuiltinRoles: true})
{
  roles: [
    {
      role: 'readWrite',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    },
    {
      role: 'userAdmin',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    },
    {
      role: 'dbOwner',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    },
    {
      role: 'dbAdmin',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    },
    {
      role: 'enableSharding',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    },
    {
      role: 'read',
      db: 'mobby',
      isBuiltin: true,
      roles: [],
      inheritedRoles: []
    }
  ],
  ok: 1
}

각 역할의 설명은 다음과 같습니다:

  1. readWrite: 이 역할은 데이터베이스의 읽기 및 쓰기 작업에 대한 권한을 부여합니다. 사용자가 데이터를 읽고 쓸 수 있습니다.

  2. userAdmin: 이 역할은 사용자 및 권한을 관리할 수 있는 권한을 부여합니다. 사용자를 추가, 수정, 삭제하고 사용자에게 역할을 할당할 수 있습니다.

  3. dbOwner: 이 역할은 데이터베이스의 소유자입니다. 해당 데이터베이스에 대한 모든 작업을 수행할 수 있습니다. 따라서 모든 권한을 가지고 있습니다.

  4. dbAdmin: 이 역할은 데이터베이스를 관리할 수 있는 권한을 부여합니다. 데이터베이스의 인덱스 생성, 삭제, 데이터 관리 등을 수행할 수 있습니다.

  5. enableSharding: 이 역할은 샤딩을 사용하여 데이터베이스를 확장할 수 있는 권한을 부여합니다. 샤드 클러스터를 관리하고 데이터베이스를 샤딩할 수 있습니다.

  6. read: 이 역할은 데이터베이스에서 읽기 작업만 허용합니다. 사용자가 데이터를 읽을 수 있지만 쓰기 작업은 허용되지 않습니다.

이러한 역할은 MongoDB에서 기본적으로 제공되는 역할이며, 사용자에게 이러한 역할을 할당하여 데이터베이스에 대한 적절한 권한을 부여할 수 있습니다.

사용자를 생성하면 dbAdmin을 부여해야 한다. (백엔드에서 직접적으로 사용할 DB 접속 사용자.)

사용자 생성하기

db.createUser({user: "zetawayv", pwd: "zetawayv1234", roles: ['dbAdmin']});

뒤에는 자신이 원하는 권한을 적으면 된다.

mongoDB 다시 시작하기

sudo service mongod restart

자.. 이렇게 하면 failed가 된다.

오류 해결

참고했습니다.~

sudo service mongod restart, start 해도 반응 없을 때


이렇게 뜨는 것이다. 원래 저기 Active에 초록색으로 running? 암튼 잘 떠야 하는데 failed가 떴다..
된장

sudo tail -f /var/log/mongodb/mongod.log

확인해보니 문제가 되는 로그는 다음과 같았다.

{"t":{"$date":"2024-05-13T01:42:20.609+00:00"},"s":"E",  "c":"NETWORK",  "id":23024,   "ctx":"initandlisten","msg":"Failed to unlink socket file","attr":{"path":"/tmp/mongodb-27017.sock","error":"Operation not permitted"}}
{"t":{"$date":"2024-05-13T01:42:20.609+00:00"},"s":"F",  "c":"ASSERT",   "id":23091,   "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":40486,"file":"src/mongo/transport/transport_layer_asio.cpp","line":1130}}
{"t":{"$date":"2024-05-13T01:42:20.609+00:00"},"s":"F",  "c":"ASSERT",   "id":23092,   "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"}

Failed to unlink socket filed 에러가 발생했다.

"Failed to unlink socket file" 에러는 MongoDB가 시작될 때 소켓 파일을 제거할 수 없는 경우 발생합니다. 일반적으로 MongoDB는 시작할 때 이전에 사용한 소켓 파일을 제거하려고 시도합니다. 그러나 소켓 파일을 제거하는 동안 해당 파일에 액세스할 수 없거나 파일 시스템 권한 문제가 발생하면 이러한 에러가 발생할 수 있습니다.

이 에러의 일반적인 원인은 다음과 같습니다

  1. 권한 문제: MongoDB 프로세스가 소켓 파일을 제거할 수 있는 충분한 권한이 없는 경우에 발생할 수 있습니다. 소켓 파일이 다른 사용자나 그룹에 속해 있거나, 소켓 파일의 디렉토리에 쓰기 권한이 없는 경우에 이러한 문제가 발생할 수 있습니다.

  2. 이전 프로세스의 종료: MongoDB가 이전에 비정상적으로 종료되었거나 제거되지 않은 프로세스가 여전히 실행 중인 경우, 이전 소켓 파일이 제거되지 않아 이러한 에러가 발생할 수 있습니다.

이러한 문제를 해결하기 위해서는 다음과 같은 조치를 취할 수 있습니다:

  • MongoDB 프로세스가 실행되는 사용자에게 충분한 권한 부여
  • 이전에 실행된 MongoDB 프로세스를 종료하고 소켓 파일을 수동으로 제거
  • 소켓 파일이 생성되는 디렉토리에 대한 쓰기 권한 확인

이러한 단계를 따라 소켓 파일을 제거할 수 있으면 해당 에러를 해결할 수 있습니다.

여기서 내가 해당하는 원인은 Operation not permitted 이었다.

해결 방법

감사하게도 다른 블로그를 참고해서 해결을 하였다.

mongodb-27017.sock 파일의 접근 권한을 변경하거나 파일을 삭제한 후
서비스를 재시작 하면 되는거였다.

sudo rm -rf /tmp/mongodb-27017.sock
sudo service mongod start
sudo systemctl status mongod


이러한 정보를 Datagrip에 잘 기입하면 잘 연결이 된다.

느낀 점

나는 지금까지 mariaDB, mySQL을 썼기 때문에 mongoDB가 정말 아직도 조금 낯설다.
새로운 도전은 항상 설렘을 동반하긴 하지만, 개발에 지체가 될까봐 많이 걱정이 되곤 한다.
그래도 아자아자 화이팅이다 !!

profile
Spring Boot 백엔드 주니어 개발자

0개의 댓글