재밌는 코딩 공부

위 url은 ec2에 연결된 역할을 반환하는 url입니다. ec2에 연결된 역할이 없을 경우 해당 오류를 반환하게 됩니다.

해당 오류로 인해 프로그램이 실행되거나 프로세스를 진행할 때 문제가 되진 않습니다.

https://stackoverflow.com/questions/58378329/aws-instance-metadata-for-iam-is-not-found

원인

자바 entity와 DB의 table이 일치하지 않아서 발생

생각했던 영어 질문지의 형태가 영어 질문, 한국어 해석으로 구성된 다는 것을 만든 후에 알게 되어 추후에 수정후 ddl을 update로 두고

실행하였더니 위와같은 에러가 발생하였다. ddl이 update로 설정돼있기 때문에 알아서 업데이트될 거라 생각했지만 DB를 확인해보니 업데이트되지 않았다. 

해결 방법

DB가 자동으로 변경되지 않은 점으로 보아 DB를 수정한대로 변경하면 해결될 것으로 추측했고 해결되었다.

아래 코드처럼 파라미터로 넘어오는 2개의 클래스가 있고 해당 클래스에는 id 라는 변수가 둘다 존재합니다. 이럴 때

source = 해당클래스.id 이런식으로도 매핑이 가능합니다.

@Mapper(componentModel = "spring")
interface QuestionMapper {

    fun toEntity(request: RequestSaveQuestion, member: Member): Question

    @Mapping(source = "question.id", target = "question_id")
    fun toResponse(question: Question, member: Member): QuestionResponse
}

이번에 여러 문제를 담을 table을 개발하고 쿼리스트링으로 여러 조건을 건내받기를 원했다. 이번에 선택한 방법은 하나의 파라미터에

difficulty=HARD-NORMAL 이런식으로 담겨오면 -값을 기준으로 스플릿하여 배열처럼 사용하였지만 id =1, id=2, id=3 이런식으로 하여서 배열처럼 받아올 수도 있는 것 같다 해당 방식은 아래 블로그를 참조하였다.

https://webisfree.com/2017-03-28/쿼리스트링-파라미터를-배열로-전달하는-방법은-어떤게-있을까요

Database Navigator -> DB선택 후 우클릭 -> Connection view -> Advanced 클릭

JPA 특징

• JPA는 특정 데이터베이스에 종속되지 않는다.
• 객체지향적인 프로그래밍을 할 수 있도록 도와준다.

Entity Manager Factory

• 이름 그대로 Entity Manager를 생성하는 객체
• 싱글턴 방식으로 사용
• Entity Manager는 쓰레드간에 공유하면 안된다.
• JPA의 모든 데이터 변경은 트랜잭션 안에서 실행해야한다.

영속성 컨텍스트(Persistence Context)

• 엔티티를 영구 저장하는 환경
• EntityManager.persist(entity)
• 논리적인 개념
• 엔티티 매니저를 통해서 영속성 컨텍스트에 접근할 수 있다.
• 스프링 프레임워크 같은 컨테이너 환경에서는 엔티티 매니저와 영속성 컨텍스트가 N:1 관계를 가진다.

영속성 컨텍스트의 이점

• 1차 캐시
  • persist가 진행되면 바로 DB로 저장되지 않고 영속성 컨텍스트 내부의 1차 캐시에 저장된다. 그리고 해당되는 sql은 영속성 컨텍스트 내부의 쓰기 지연 SQL에 저장된다.
  • find를 사용해서 조회하면 또한 1차캐시에 저장된다.
  • find 사용시 이미 1차 캐시에 저장되있으면 해당 캐시가 사용된다.
• 동일성(identity) 보장
• 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
• 변경 감지(Dirty Checking)
• 지연 로딩(Lazy Loading)

Entity Manager를 사용한 업데이트 방법

• 업데이트 하기전 find를 통해서 해당 entity를 조회하게 된다. 그러면 영속성 상태가 되며 1차 캐시에 해당 엔티티가 올라가게 된다. 이 때 트랜잭션이 걸려있고 값을 변경하게 되면 트랜잭션이 끝나는 시점에 1차 캐시의 처음값이 담긴 스냅샷과 현재의 값을 비교하여 변경되면 update SQL을 쓰기 지연 SQL 저장소에 저장하게 되고 flush할때 DB로 update 쿼리가 실행되게 된다.

flush란?

• 영속성 컨텍스트의 변경내용을 데이터베이스에 반영하는 작업이다.
• 플러시가 발생되면 아래 동작이 실행된다.
  • 변경 감지
  • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송
  • (등록, 수정, 삭제 쿼리)

영속성 컨텍스트가 flush 되는 시점

• entityManager.flush()가 실행될 때
• 트랜잭션이 커밋 될 때
• JPQL 쿼리 실행될 때 (모드를 설정하여 트랜잭션 커밋 시점에 실행되도록 변경할 수 있다.)

엔티티의 생명주기

• 비영속 (new/transient)
  • 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
  • 단순히 객체를 생성한 상태
• 영속 (managed)
  • 영속성 컨텍스트에 관리되는 상태
  • Entity Manager를 통해 persist를 수행한 상태
• 준영속(detached)
  • 영속성 컨텍스트에 저장되었다가 분리된 상태
  • Entity manager의 detach, clear, close이 실행되면 영속 → 준영속이 된다.
• 삭제 (removed) - 삭제된 상태

JPA 어노테이션

• @Entity: JPA가 관리할 객체
• @Id: 데이터베이스 PK와 매핑
• @Table: 은 엔티티와 매핑할 테이블 지정 ex) @Table(name = “hello”)
• @Column 컬럼 매핑
• @Temporal 날짜 타입 매핑
  • 요즘은 LocalDate, LocalDateTime을 사용하기에 사용 x
• @Enumerated enum 타입 매핑
  • 결과적으로 value = EnumType.STRING으로 사용해야 된다.
• @Lob BLOB, CLOB 매핑
  • @Lob에는 지정할 수 있는 속성이 없다.
  • 매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
  • CLOB: String, char[], java.sql.CLOB
  • BLOB: byte[], java.sql.BLOB
• @Transient 특정 필드를 컬럼에 매핑하지 않음(자바에서만 사용되는 변수)
  • 필드 매핑 x
  • 데이터베이스에 저장 x, 조회 x
  • 주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용

데이터베이스 스키마 자동 생성

• DDL을 애플리케이션 실행 시점에 자동으로 생성한다.
• 테이블 중심 → 객체 중심으로 변경
• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL을 생성한다.
• 이렇게 생성된 DDL은 개발 장비에서만 사용한다.
• 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용된다.

hibernate.hbm2ddl.auto

• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행로직에는 영향을 주지 않는다.

@SequenceGenerator

• 아이디 값 위나 클래스 위에 사용
• 주의: allocationSize 기본값은 50이다.
• name : 식별자 생성기 이름
• sequenceName 데이터베이스에 등록되어 있는 시퀸스 이름
• initialValue DDL 생성 시에만 사용됨, 시퀸스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다.
• allocationSize 시퀸스 한 번 호출에 증가하는 수 (성능 최적화에 사용된다. 데이터베이스 시퀸스 값이 하나씩 증가하도록 설정되길 원하면 이 값을 반드시 1로 설정해야한다.)
  • 만약 위의 값을 1로 설정하면 데이터를 생성하고 db에 저장하고 조회하는 것을 하나의 데이터마다 수행하여 성능은 떨어질 수 있다.
• catalog, schema: 데이터베이스 catalog, schema 이름

Incorrect string value: '\xEC\x98\x81\xEC\x96\xB4...'

위와 같은 에러가 나며 maria db를 사용한다면

ALTER TABLE 테이블 이름 convert to charset utf8;

위 명령어로 해결 가능하다. 위 명령어는 테이블의 charset 을 utf8로 변경하는 것이다.

ec2 프리티어에서 만든 프로젝트를 빌드해보았다. 하지만 예상외로 시간이 많이 걸려 빌드를 실패하였다.

한 번에 50분이 넘어가는 경우도 있었다. 이를 해결하기 위해서 빌드를 빠르게 하는 방법과 해당 문제를 가진 사람들이 있는지 서치한 결과 gradle.properties 파일에 해당 값을 넣어주는 것으로 17분 만에 빌드에 성공하였다.

# for memory issue
org.gradle.daemon=false

# memory allotted to JVM
org.gradle.jvmargs=-Xmx1024m 

# configure on demand
org.gradle.configureondemand=true

# parallel builds
org.gradle.parallel=true

# build Cache
android.enableBuildCache=true

# gradle caching
org.gradle.caching=true

램 1기가를 최대한 빌드하는데 쏘다 부으라는 ? 명령어로 보인다. 만약 gradle.properties 파일이 없다면 build.gradle 파일이 위치한 경로로 gradle.properties 파일을 생성해서 사용하면 된다. 

1. ec2에 java 11 설치하기

현재 저의 프로젝트는 자바 11을 사용하고 있기 때문에 11을 설치합니다.

우선 yum으로 설치할 수 있는 자바 버전을 확인합니다.

yum list java*jdk-devel

저의 경우 자바 7, 8 버전만 가능하다고 나왔습니다. yum 버전 업그레이드를 해야겠습니다.

sudo yum update

업데이트해도 설치할 수 있는 버전은 같았습니다. 아무래도 다른 방법을 사용해야 할 것 같습니다.

찾아 보니 아래와 같은 방식으로 자바 11을 설치할 수 있었습니다.

# aws coreetto 다운로드
sudo curl -L https://corretto.aws/downloads/latest/amazon-corretto-11-x64-linux-jdk.rpm -o jdk11.rpm

# jdk11 설치
sudo yum localinstall jdk11.rpm

# jdk version 선택
sudo /usr/sbin/alternatives --config java

# java 버전 확인
java --version

# 다운받은 설치키트 제거
rm -rf jdk11.rpm

저같은 경우 이전 버전을 삭제 하려고 찾아보니 검색이 되지 않아서 위 과정으로 마무리 했습니다.

참조

https://pompitzz.github.io/blog/Java/awsEc2InstallJDK11.html#jdk-%E1%84%89%E1%85%A5%E1%86%AF%E1%84%8E%E1%85%B5

2. 타임존 변경

기본 서버의 시간은 미국 시간대입니다. 한국 시간대가 되어야만 우리가 사용하는 시간이 모두 한국 시간으로 등록되고 사용됩니다.

date

위와 같이 date를 명령어로 입력하면 현재 사용하는 시간이 나타납니다. 예상한대로 저도 미국 시간대를 사용하고 있었습니다.

다음 명령어를 사용합니다.

sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

2번째 명령어의 l은 L입니다. i의 대문자와 해깔릴 수도 있으니 주의해주세요

참조

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

외부에서 ssh 접속을 하려면 매번 아래와 같이 IP 탄력 주소를 알고있어야 됩니다.

ssh -i pem 키 위치 EC2의 탄력적 IP 주소

하지만 조금만 설정을 해놓으면 아래와 같이 접근할 수 있습니다.

ssh config에 등록한 서비스명

그럼 이제 진행해보겠습니다.

이제 다운 받은 키페어 pem 파일을 ~/.ssh/로 복사합니다. 이렇게 해두면 ssh 실행시 pem 키 파일을 자동으로 읽어 접속을 진행합니다.

이후부터는 별도로 pem키 위치를 명령어로 지정할 필요가 없게 됩니다.

cp pem 키를 내려받은 위치 ~/.ssh/

pem 키가 잘 복사되었는지 ~/.ssh 디렉토리로 이동해서 파일 목록을 확인합니다.

cd ~/.ssh/
ll

복사되었다면 pem 키 권한을 변경합니다.

chmod 600 ~/.ssh/pem키 이름

~/.ssh디렉토리에 config파일을 생성 합니다.

vim ~/.ssh/config

config파일의 내용은 아래와 같이 설정합니다.

Host 본인이 원한는 서비스명
	HostName ec2의 탄력적IP 주소
    User ec2-user
    IdentityFile ~/.ssh/pem키 이름

작성이 끝났으면 :wq 명령어로 저장 종료합니다.

생성된 config 파일은 실행 권한이 필요하므로 권한설정을 합니다.

chmod 700 ~/.ssh/config

이제 실행해봅니다.

ssh config에 등록한 서비스명

참조

스프링 부트와 AWS로 혼자 구현하는 웹 서비스