DO MY BEST

기본적인 흐름

1. 서버에서 ssh-keygen -t rsa -m pem 명령어로 key pair를 생성함
2. 특정 이름을 지어주지 않는한 id_rsa, id_rsa.pub 이렇게 두 개가 생성될 것이다. 각각 private key, public key 이다.
   public key인 id_rsa.pub을 mv id_rsa.pub authorized_key 로 등록 해준다.
   그리고 private key인 id_rsa를 mv id_rsa id_rsa.pem 으로 pem 키를 만들어준다. 만들어진 pem키는 접속할 때 필요한 키이다.
3. ssh-add {key가 존재하는 경로와 key명} 로 해당 key를 등록해준다. 그리고 ssh-add -l 으로 잘 등록 되었는지 확인이 가능하다.
4. ssh 로 원하는 서버에 접속한다.

삽질

 
1. 

WARNING: UNPROTECTED PRIVATE KEY FILE!
혹시 이런 에러 뜨면 다음 명령어 입력 하면 된다.

chmod 600 {key 명}

 
 
 
2. ssh 로 서버에 접속할 때 비밀번호입력을 요구하면 ~/.ssh/ 에 id_rsa.pem 혹은 id_rsa.pub 키가 없다는 뜻이다.
 
 
3. enter passphrase for key”가 뜨는 이유는 키 페어를 생성할 때 Phrase를 입력해서이다. 이걸 안뜨게 하고 싶으면 해당 구문을 입력하는 단계에서 그냥 엔터를 치면 된다.
 
 

느낀점

개인 클라우드 서비스를 만들어 보려고 NAS용 컴퓨터를 구입해서 이것저것 시도중이다.
이번 서버접속하는 단계를 조작해보면서 예전에 학부때 들은 시스템클라우드보안 수업에서 들은 RSA, Diffie-hellman 등 수업 내용들이 다는 아니지만 생각나고 추억들이 떠올랐다. 기분 좋은 옛 생각이 떠오르는 시간이었다.
그리고 지금껏 AWS, NCP 등 이미 만들어진 클라우드 서비스만 사용해오다가, 이런 클라우드 서비스를 직접 만들어 보니 평소에 사용하고 있던 서비스들이 어떤 방식으로 만들어 졌을거고, 해당 서비스들을 처음 개발하고 관리하는 사람들은 어떤 고민을 하면서 만들었고 유지보수 하고 있는지 더 깊게 상상해보고 고민해보는 시간이었다.
 

회사에서 꽤 크고 중요한 프로젝트를 맡았다.

회사에서 최초로 JPA를 도입했다. (회사에서는 Mybatis만 사용하고 있었다)

ORM이 확실히 객체지향적으로 코드가 깔끔하게 나오는 느낌이었다. 그런데 문제가 있었다.

기존에 Mybatis만 사용하고 있어서 단일로 DataSourceTransactionManager를 사용중이었는데, JPA를 도입하면서 JpaTransactionManager 를 추가 해야 했다.

기존에 DataSourceTransactionManager에 JpaTransactionManager bean을 @Primary 로 하고 테스트 코드로 Mybatis와 JPA 혼합해서 DML을 해보았다.

• 1. Mybatis로 select
  2. JPA로 insert
• 1. JPA로 select
  2. Mybatis로 insert

잘 되었다.

그러나 롤백에서 문제였다.

• 1. Mybatis로 select
  2. (예외 throw)
  3. JPA로 insert
• 문제
  1. JPA로 select
  2. (예외 throw)
  3. Mybatis로 insert

Mybatis로 insert할 때 롤백이 안되는 문제였다.

프로젝트에 기존에 있던 로직들이 다 Mybatis로 되어 있는데, 현재 상태로는 @Primary로 되어 있어 있는 JpaTransactionManager를 사용하고 있어서 기존 로직들이 롤백이 안됐다.

그래서 JPA에는 JpaTransactionManager를 사용 해야 하고, Mybatis에는 DataSourceTransactionManager를 사용 하여 트랜잭션을 관리 하게끔 해야 했다.

여러 대안이 있었다.

• ChainedTransactionManager
• JtaTransactionManager
• @Primary를 DataSourceTransactionManager 로 변경하고 JPA 로직에만 @Transactional 에 트랜잭션 매니저 명시

ChainedTransactionManager는 후 순위로 커밋하는 트랜잭션에서는 예외가 발생하면 이전 트랜잭션에서 커밋된 부분은 롤백이 안되는 한계가 있었고, 어느 한 쪽의 커넥션 갯수가 부족해서 타임아웃이 발생할 가능성도 우려 됐다. 무엇보다 해당 트랜잭션 매니저는 단순 순차적으로 커밋하는 것일 뿐 2PC가 아니라 도입하기 걱정스러웠다.

JtaTransactionManager는 XA 프로토콜을 사용한 완벽한 2PC로 구현되어 있었다. 그러나 락이 잡히는 시간이 길어질 것 같고, 여러번 디비랑 커넥션을 맺어 퍼포먼스에 이슈가 있을 것 같았다.

그래서 @Primary를 DataSourceTransactionManager 로 변경하고 JPA 로직에만 @Transactional 에 트랜잭션 매니저 명시를 해서 처리했다.

마무리

이번 이슈로 더 성장한 느낌이 들어 좋다. 

고민하는 스펙트럼이 넓어졌다.

현재 회사에서 한 프로젝트에서 spring framework 4.2.8을 사용하고 있다.

해당 프로젝트에서 @RequiredArgsConstructor 으로 빈 주입을 했는데 아래와 같은 에러가 났다.

Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field:

그래서 찾아보니 4.3 버전 부터 가능한 방법이었다.

결국엔 @Autowired로 대체할 수 밖에 없었다.

결론

해당 프로젝트 버전업을 해야겠다.