The Yellow Lion King 데이터와 함께 살아가기

 안녕하세요

지난 주 AWS Partner Tech Grue Community Meet-up 에 다녀 왔습니다. 

TGC는 AWS 에서 Partner Engineer를 대상으로 기술 관련 공유 토의하는 모임 입니다.
올해 그 첫번째 모임으로 지난주 강남 센터필드에서 열렸어요. 오신 분들 모두 파트너사의 기술 관련 업무를 (한가닥?) 하시는 분들이었어요. 조건이 파트너사의 직원이고 AWS 자격증 요건 또는 AWS Ambassador 등 여러가지가 있었습니다. 어려울 것 같았는데 저도 운 좋게 참여하게 되었습니다.

이번은 올해 첫 모임으로 전반적인 계획을 공유하는 시간이었고요, 기술 모임인 만큼 Ambassador 분들의 발표도 있었습니다.

저녁 퇴근후에 모임이다보니 출출함을 달래줄 피자와 치킨, 맥주와 음료 등도 제공해 주셨습니다.

새로운 기술과 트랜드 그리고 이에 대한 AWS의 새로운 기능 들을 먼저 만나볼 수있을 것 같아서 기분이 설래입니다.
앞으로 따끈따끈한 소식 전하겠습니다.
감사합니당~~~

아래는 Google CoLab에서 AWS RDS MySQL DB에 접속하려고 할때 작성한 코드와 발생 에러 메세지입니다.

---------------------------------------------------------------------------
TimeoutError                              Traceback (most recent call last)
/usr/local/lib/python3.10/dist-packages/pymysql/connections.py in connect(self, sock)
    612                         try:
--> 613                             sock = socket.create_connection(
    614                                 (self.host, self.port), self.connect_timeout, **kwargs

44 frames
TimeoutError: timed out

During handling of the above exception, another exception occurred:

OperationalError                          Traceback (most recent call last)
OperationalError: (2003, "Can't connect to MySQL server on 'dev.cluster-czafliq9kcwp.ap-northeast-2.rds.amazonaws.com' (timed out)")

The above exception was the direct cause of the following exception:

OperationalError                          Traceback (most recent call last)
/usr/local/lib/python3.10/dist-packages/pymysql/connections.py in connect(self, sock)
    662                 if DEBUG:
    663                     print(exc.traceback)
--> 664                 raise exc
    665 
    666             # If e is neither DatabaseError or IOError, It's a bug.

OperationalError: (pymysql.err.OperationalError) (2003, "Can't connect to MySQL server on 'dev.cluster-czafliq9kcwp.ap-northeast-2.rds.amazonaws.com' (timed out)")
(Background on this error at: https://sqlalche.me/e/14/e3q8)

아무리 찾아봐도 연결이 안될 이유가 없었습니다.

먼저 AWS Sagemaker Jupyter Notebook에서 연결을 확인해보니 잘 되었습니다.

이로 확실한 것은 Sagemaker에서는 접속이되니 DB 문제는 아니라는 것,

그래서 가능한 원인은 두가지 중 하나 입니다.

1. 네트워크 문제  또는 2. 롤(권한)의 문제

1. 네크워크 문제는 Colab에서 IP를 확인하여 AWS VPC에서 Colab의 IP가 연결 오픈 되어있는지 확인하면 됩니다. 안되어있으면 추가해주어야 겠지요.

2. 롤문제는 접속시 AWS CLI를 통해 임시 권한을 받고 이를 통해 접속해 보면 확인 됩니다. 이역시 안되어있을 경우 IAM Role을 만들어서 해결 가능 합니다.

세이지메이커 주피터 노트북 터미널에서 파이썬 스크립트 실행시, 잘 수행되다가 갑자기
Killed
메시지 하나만 달랑 나오는 경우가 있습니다. 많이 당황 스러웠습니다. ㅠㅠ

나중에 알고보니 이런 혐상의 원인 중 하나는 메모리 부족입니다.
실행중인 인스턴스의 메모리보다 처리하려는 데이터가 많아서 Out of memory 가 발생하는 것 입니다.
따라서 해결 방법으로는 메모리 사이즈를 늘려주면 됩니다.
배치 인스턴스의 메모리 크기는 AWS Batch 메뉴중 작업정의(Job Definitions)에서 해당하는 작업정의의 내용을 수정할 수 있습니다.

기본 단위는 Mega Byte 이며 숫자로 입력하면 됩니다.

사용비용을 내지 않기 위해서 모든 서비스를 삭제 했다고 생각했는데 계속해서 비용이 청구/결제 되었습니다. Cost Explorer를 보니 EC2-기타 라는 항목으로 비용이 나가고 있었습니다. 정확지는 않지만 EIP 가 생성되어있어서 이 비용으로 나가고 있는 것 같았습니다.

그래서 이를 삭제하고자 시도했습니다. 그러나, 아무리 인터넷을 검색해서 따라해 봐도 EIP 삭제가 되지 않았습니다. 아니 따라할 수가 없었습니다.  왜냐하면 일반적인 삭제 경우가 아닌 것 같았습니다. 즉, 작업 버튼의 릴리즈 기능이 아예 활성화 되지 않았습니다.

탄력적IP 메뉴에들어가서 삭제할 EIP를 선택하고 작업 버튼을 클릭해 봐도 '탄력적 IP 주소 연결해제' 또는 릴리즈라는 메뉴는 아예 활성화 되지도 않았습니다.

삭제가되지 않은 예상 원인은 EIP에 NAT 게이트웨이가 연결되어 있어서 그런것 같습니다.

그래서 해결 방법인 결론을 말씀드리면,

먼저 NAT 게이트웨이를 삭제하시고 나서 EIP 삭제(릴리즈)를 시도하시면 됩니다.

연결된 NAT 케이트웨이를 삭제하고, EIP 메뉴에서 작업 버튼의 기능 리스트를 보면, 이제는 릴리즈 기능이 활성화 되고 삭제 가능합니다.

'탄력적 IP 주소 릴리즈"와 '탄력적 IP 주소 연결 해제" 기능이 아래 처럼 안보였는데....

NAT 게이트웨이 삭제 후에는 아래와 같이 보였습니다.

사실 이 방법은 VPC삭제를 시도하다가 NAT게이트웨이 등 먼저 삭제해야할 서비스가 있다는 것을 알게되었습니다. 

비용을 안나오게 하기 위해서는 해당 VPC를 삭제하는 것이 더 좋은 것 같아 삭제 하였습니다.

참고하세요.

비용이 계속나와서 삭제하려고 했는데... 일단 서비스 삭제 작업을 했으니 한달 더 지켜봐야겠습니다.

(지켜봤더니 추가 비용이 나오지 않았습니다. ㅋ)

감사합니다.