본문 바로가기
IT 정보

EC2를 그라비톤(Graviton)으로 옮기면서 느낀점 및 트러블 슈팅

by 완기 2022. 6. 4.
728x90
반응형

 

회사에서 RI를 진행하면서 기존에 x86 계열의 인스턴스들을

arm 기반의 그라비톤을 이전하는 작업들을 진행했다.

 

그라비톤 참고

 

그라비톤은 MacOs가 인텔 맥에서 M1 맥으로 이전하며 과도기를 거쳐 현재의 생태계를 구축한 것처럼.

차츰 많은 회사에서 도입을 시작하고 있는 듯하다.

 

사실 우리 회사도 그라비톤이라는 존재를 처음 들을 때만 해도 약 1년 전이었다.

 

그때도 메인 리포팅 솔루션을 테스트 겸 이전 작업을 진행해봤지만

당시 docker에서 arm 기반의 프로세서에서 빌드 오류였는지,

내가 docker에 대한 지식이 없어서인지 docker부분에서 막혀서 포기했었다.

(아마 docker 관련 지식이 없었던 것 같았다.)

 

테스트 이전 부분에서 시간 여유가 충분하지 않아서 그만뒀지만,

현재는 대대적인 인프라 개선 작업이 이루어질 시즌이라, 인프라 작업에 대한 시간이 많이 할애됐고,

 

이전이 성공적으로 이루어져 ELB에서 인스턴스도 잘 연결해두고

 

아! 이제 성공이구나 싶었다.

 

그러나 거대한 모놀리식 레거시 스프링 프로젝트는 이를 허용하지 않았다.

 

처음에는 메일 발송, 외부 API 등 외부 인터넷과 연결되는 라이브러리에서 지속적으로 오류가 났고,

버전업과 추가적인 보안설정들을 마치고 이 부분도 해결했다.

 

이후 주말 동안 잘 돌아가나 싶더니만....

 

 

아니나 다를까 인스턴스가 unhealthy 하다는 알림이 지속적으로 발생했다.

 

엔진엑스에 스프링 부트 프로젝트가 docker 컨테이너로 실행 중이었는데, 별 다른 로그 없이 계속 컨테이너가 내려가는 상황이 발생했다.

이 부분은 아직 해결하지 못해 일단은 기존 x86의 서버를 ELB에 연결해놨다.

 

프로젝트가 적용된 필터도 많았고, 메모리를 상당히 많이 사용하는 거대 프로젝트였기 때문에

메모리 문제인가?라는 의문을 가지고 문제를 해결하려고 했다.

 

당시 인스턴스의 메모리는 8GB였는데, 

VM 옵션에 최대 메모리가 5GB로 설정되어있어, 7GB로 바꾸고 실행을 했었음에도, 알 수 없이 컨테이너가 내려갔고,

 

로그를 살펴봐도 별 다른 이상이 보이지 않았다.

 

이 부분은 아직 미제로 남아있지만 이걸 해결한다면 내 개발 인생에 큰 도움이 될 것 같다.

끝내 욕심부려서 해결해보고 싶은 마음이 굴뚝같다.

 

300x250

앞서 언급했던 리포팅 솔루션과 달리 비교적(?) 최신 스프링 버전으로 된 다른 솔루션이 있었다.

 

해당 솔루션은 docker에서 실행되지 않고 프로세스를 실행시키는 형태였다.

이 솔루션도 자꾸 로그에서도 알려주지 않는 이유로 자꾸 프로세스가 죽었었는데,

 

마찬가지로 메일 발송 API에서 보안 관련 오류가 발생했었다.

이 부분도 마찬가지로 버전업과 추가 보안설정으로 잘 마무리했지만

 

인스턴스 교체 작업과 동시에 엘라스틱 캐시와 RDS 타입 변경 작업도 진행했던 탓인지(?)

 

RDS 연결 도중 오류가 발생했고, 드라이버 클래스를 mySQL에서 MariaDB로 바꾸면서 해결이 됐다.

 

엘라스틱 캐시에서 가장 어이없는 오류가 발생했는데,

기존에 엘라스틱 캐시를 연결하는 방식은 다음과 같았다.

 

//pseudocode
new MemcachedInstance(endPointURL:port , port);

인스턴스 생성자 첫 번째 인자에 엔드포인트 url : port를 함께 넣어줬다.

그러나 엘라스틱 캐시도 타입 변경을 하고 나서 이 부분에서 오류가 발생했는데

 

//pseudocode
new MemcachedInstance(endPointURL, port);

 

이와 같이 수정하면서 오류를 수정했다 (에이 xx...)

무엇이 바뀌었는지 단순히 보고서는 찾기 힘들다.

 

단순이 엔드포인트 url에 포트만 빼줬다...

뻈더니 귀신같이 연결이 잘 됐다..

(에라이 내 4시간....)

 

이외에도 어떤 런타임 오류로 서버가 죽을지 아직 아무도 모르는 초긴장 상태다..

물론 서버가 죽을 때를 대비해서 대비책은 다 세워놨지만... 아직 레퍼런스도 많이 없는 시점에선 긴장하고 있다.

 

요약이 편한 사람을 위해 내가 그라비톤 이전을 하며 문제점을 간단히 정리한다.

 

 


일단 주로 개발환경은

spring boot, java 8 (+때에 따라 docker)였다.

 

  • Java Mail관련 라이브러리 TLS/SSL 오류 -> 라이브러리 버전 업.
  • RDS driver class 오류 기존 MySQL -> MariaDB로 변경
  • EndPoint URL에서 포트 제거 endPointUrl:port (기존) -> endPointURL(변경 후)

 

앞으로 추가적인 케이스를 발견하면 추가해놓고 정리해야겠다.

 

728x90
728x90

댓글