heidisql 등의 원격 접속 툴을 이용해도 접속이 안 됐다. 포트, 방화벽 설정 등등 모두 확인해 봤고 로컬에서 잘 돌아가는 데도 원격 접속이 안됐다. 사실 원격 접속만 안 되면 상관 없는데, codeigniter에서도 똑같이 로그인을 못해서 자꾸 에러가 났었다.
일단, MariaDB는 10.4부터 root 권한 소유자에게 따로 비밀번호를 물어보지 않는다. 즉, 루트 계정으로 로그인했으면 그냥 콘솔에 mysql 치면 접속이 된다. 물론 다른 유저는 전처럼 비밀번호를 물어본다. 나는 이 root 계정으로 로그인을 며칠째 계속 시도해 봤는데 계속 안됐다.... 포트 문제도 아니었고 딱히 통신 문제도 아니었다. 심지어 SSH 접속 계정도 root 였다.
해답은 새로운 계정을 파서, 그 계정으로 접속을 하니까 잘 됐다. 계정 만드는 SQL 문이야 검색하면 바로 나올 거니까 따로 적진 않겠다.사실 별 내용 없는 건 아는데 새 계정을 파서 시도하란 말을 며칠 내내 구글을 뒤진 다음에야 본 것 같아서, 혹시 같은 어려움을 겪는 사람들이 있다면 빨리 해결할 수 있었으면 좋겠다.
EC2 프리 티어를 사용하는 사람이라면, 월 750시간의 t2.micro가 제공되는데 한 달 내내 쉬지 않고 돌려도 750시간을 다 못 쓴다. 그래서 그냥 켜놓고 방치하는 사람이 많고, 나 역시 그런 사람들 중 한명이다. 하지만, 프리 티어를 벗어나게 되면, EC2 인스턴스를 켜 놓은 시간에 비례하여 과금이 되기 때문에 최대한 안 쓸때는 꺼 놓는 게 현명하다. 특히 회사에서 운용하는 개발 서버 같은 경우, 주말에도 짬을 내서 개발을 하거나 야근을 하는 게 아니라면 출근 시간에 맞춰서 켜지고, 퇴근 시간에 맞춰서 끄는 게 현명하다.
하지만, EC2 인스턴스가 그냥 크롬 탭 끄고 켜듯이 바로바로 껐다 켜지지도 않고, 무엇보다 이걸 매일 하려면 당연히 귀찮다. 그래서, 아마존에서 Instance Scheduler라는 솔루션을 내놓았다. 이 기능을 활용하여 정해진 시간, 정해진 요일에 인스턴스를 껐다 켰다 하는 작업을 자동화할 수 있다.
요금은 일단 프리 티어의 이용자라면 무료라고 봐도 좋다. AWS의 CloudFormation과,위 사진처럼 AWS의 lambda, CloudWatch, DynamoDB 등을 활용하는 서비스인데, 이 서비스들 모두 프리 티어에서 일정량의 처리량을 무료로 제공하기 때문이다. 물론, 학생 수준에서 공부용으로 이용하는 정도로는 차고 넘치는 정도로 용량을 제공한다. 자세한 요금은 위의 각 제품의 요금을 확인하자. 전부 친절하게 계산기까지 구비되어 있다.
이 글은 위의 두 링크에 나온 방법과 시행착오를 통해 이뤄낸 방법을 기록해 뒀으며, 혹시 이 글대로 했을때 문제가 생기면 위의 링크들을 참고하자.
1. CloudFormation에서 Stack 생성
AWS CloudFormation은 클라우드 환경에서 AWS나 타사의 애플리케이션을 조작하고 제어...한다는데 솔직히 어떻게 쓰는 지는 잘 감이 안 잡힌다. 내가 이해한 바로는, 쉽게 말해 여러 개의 애플리케이션을 조작해야 하는 업무를 한꺼번에 스크립트를 통해 할 수 있도록 만들어주는 솔루션 같다.
다음을 누른다. 스택 이름을 입력하라는 데 이 값이 나중에 EC2 설정에 쓰이니, 잘 알아볼 수 있는 이름으로 짓자.
EC2를 쓴다면 당연히 서비스할 대상으로 EC2를 지정한다.
나는 Schedule이라는 이름으로 지었다.
이외에도 아래에 이것저것 엄청 많은데 다 건드리지 않아도 되고, 중요한 건 몇 군데 정도다.
영어로 각 항목에 대한 설명이 있으니 딱히 부연 설명은 하지 않아도 될 것이다.
이 값은 우리의 스케쥴러가 몇 분마다 돌아갈지를 결정한다. 나는 하루에 한 번만 정해진 시간에 인스턴스를 끄도록 만들었기 때문에 30분으로 정했다. 사실 하루에 언제 끄고 언제 켜는지만 정해두는 정도면 10분 이하의 Frequency는 필요하지 않을 것이다. 오히려 너무 간격이 짧으면 그 만큼 lambda 등의 서비스에 트래픽이 많이 생길 것이다.
맨 아래에 있는 항목들은 다음과 같이 입력해 두자.
이제 다음 다음 하다보면 마지막 페이지에 다음과 같은 문구가 보일 것이다.
여기는 체크를 하자. 쉽게 말해, 클라우드를 통한 접근 권한을 주는 것이라고 보면 된다.
여기까지 하고 스택을 생성하자. 이 스택 생성도 시간이 걸리기 때문에 좀 기다려야 한다.
대시 보드에서 CREATE_COMPLETE라고 뜨면 생성이 완료된 것이다.
2. AWS DynamoDB 에서 설정 생성
이제 기본적인 준비는 마쳤고, 원하는 대로 세팅을 할 차례다. 이미 템플릿을 통해 lambda에도 못 보던 애플리케이션이 생겼을 것이고, DynamoDB도 마찬가지다. DynamoDB는 아마존에서 서비스하는 NoSQL DB인데, 여기에 설정값들이 저장되고 이 값을 fetch해서 스케쥴러로 이용하는 구조다. DynamoDB로 들어가 보자.
다음과 같이 테이블 탭을 눌러보면 처음 보는 테이블들이 만들어져 있다. Ec2instanceScheduler는 내가 스택 이름으로 지은 거고, 아마 사람마다 다른 이름이 있을 것이다. 중요한 건 뒤의 ConfigTable과 StateTable이다. StateTable은 함부로 바꾸면 안 되고, 우리는 ConfigTable만 건드리면 된다.
ConfigTable을 열어보면 이미 여러 개의 항목들이 예시로 만들어져 있을 것이다. 각 항목들은 json의 구조와 거의 동일하다. type에 config/schedule/period가 각각 있는데, 나중에 열어보면 알겠지만 간단히 설명하자면, schedule 항목에서 기본적인 스케쥴 설정(각종 설정들)을 하고, 시간을 지정하는 항목을 따로 항목으로 분리하여 둔 것이다. 즉, schedule 타입의 항목에서 period 행을 이름을 통해 참조하는 형식이 된다.
config 행은 건들 필요 없고, 나머지 schedule/period type의 행들은 삭제하자. 다 삭제하면 config 타입의 행 하나만 남을 것이다. 이제 우리가 원하는 대로 설정을 할 차례다. '항목 만들기'를 누르자.
처음 창을 열면 이 형태로 나와있진 않을 것이다. Tree->Text로 바꿔주고 DynamoDB JSON에도 체크해주자.
period 항목을 생성한다. 이제 원하는 대로 설정을 할 차롄데, 각 파라미터는 다음과 같다.
여기는 주로 설정값이 모여있다. type이나 description은 위에서 언급했고, timezone 역시 서울 리전이라면 다음과 같이 설정한다. retain_running이나 stop_new_instances 등등은 특수한 설정이다. 예를 들어, retain_running은 인스턴스가 예정된 종료 시간 이후로 사용자가 임의로 다시 시작했을 떄, 이 실행을 막을지를 설정하는 여부이다. 이 각각의 설정값에 대한 설명은 역시 아까 언급한 https://docs.aws.amazon.com/solutions/latest/instance-scheduler/components.html
-> Schedule Definitions에 자세하게 설명되어 있으니 참고하자.
중요한 곳은 periods랑 name이다. periods에 office-hours라고 되어 있는데, 이건 아까 내가 정의했던 period 항목의 이름이다. 혹시 다른 이름을 썼다면 이 부분은 그걸로 바꿔주자. name은 인스턴스에서 스케쥴을 설정할 때 이 이름을 쓰게 되니까 잘 지어주자. 나는 autostop이라고 지었다. 자동으로 인스턴스를 중지해 주니까!
역시 위 코드를 본인 필요한 대로 잘 지지고 볶아서 저장한다.
3. 인스턴스에 설정한 스케쥴 적용하기
이제 거의 끝났다. EC2 -> 인스턴스 로 들어간다. 대시보드에 들어가자.
결론적으로 만들어지는 결과값은 다음과 같다. 태그는 키:값으로 이루어져 있는데, 키에는 위에서 입력했던 CloudFormation의 스택 이름, 값에는 아까 dynamoDB에서 만들었던 schedule 항목의 이름으로 해 주자! 헷갈릴거 같아서 내가 지었던 이름엔 위에서 모두 밑줄을 쳐 놨으니 참고하자. 태그를 추가하는 방법은 일단 만들어진 인스턴스를 아무거나 눌러보자.
태그 창에 가서 태그 추가/편집을 누르면 UI가 직관적이라 금방 수정이 가능할 것이다.
사실 다 하고 보면 별 게 아닌데, 나 같은 학생이나 AWS에 갓 입문한 사람이라면 난생 처음 들어보는 서비스 여러 개를 서로 상호작용 하도록 만드는 거라 좀 복잡해 보인다. 그래도, 막상 해보니까 그냥 생소한 게 많아서 그렇지 복잡한 로직이 아니고, 진짜 귀찮은 건 이미 AWS에서 만들어준 스크립트들이 알아서 해 주고 있기 때문에 비교적 편하게 할 수 있었던 것 같다.
일단 글을 읽기 전에, 이 문제는 정말 여러 가지 원인일 수 있다. 한 마디로 요약하자면 가장 가능성이 높은 요인은 CUDA랑 Cudnn 라이브러리를 제대로 못 불러온 건데, 이걸 못 불러오는 원인이 천차만별이다. 심지어 아예 안깔렸을수도 있고. 내 경우에는 다른 텍스트 에디터(주피터 노트북 등등)에서 import tensorflow로 구동을 확인했고, 오직 pycharm 18.2 버젼에서만 저 오류가 떴었다. 심지어 내장된 파이썬 콘솔에서도 오류 없이 정상 작동했었다. ㅡㅡ;
CUDA,cuDnn을 깔고 환경 변수까지 제대로 설정하고, cmd든 vscode든 다른 에디터로 일단 구동을 확인하면 좋겠다.
밑에서 설명할 해결법은 일단 정상적으로 타 환경에서는 작동한다는 것을 전제로 하기에, 이 단계에서 막히면 여기서는 아마 답을 찾기 힘들 것이니 이 블로그를 끄고 열심히 구글에서 검색하는 게 빠를 것이다.
그리고 이제 본인이 파이참을 쓴다면 파이참의 버젼을 확인해보자. 19.1 이하의 버젼이라면 새로 업데이트 해 주자.
19.7월 기준으로 19.2 버젼이 나와있다.
18.x ->19.x는 바로 업데이트가 안 되고 19.x 인스톨러를 실행해서 구버젼을 지우고 새로 설치하게 된다. 물론 내부 설정은 그대로 연동할 수 있다. 구버젼 삭제 때 slient uninstall에 체크하고, 새 버젼 설치 때 기존 설정 폴더(아마 자동으로 선택되어 있을 것)을 선택하면 그 설정 그대로 설치된다.
설치가 끝나면 프로젝트를 열고, 설정값을 불러오도록 좀 기다린 후 문제가 됐던 파일을 다시 실행시켜보니 잘 됐다.
그럼 문제해결인데...
왜 이런 문제가 생겼냐, 그건 구 버젼 파이참에서 버그가 있었기 때문이다.
conda 가상환경을 사용할 때, 시스템 환경변수 중 PATH의 값이 정상적으로 불러와지지 않는 문제가 있었다.
tensorflow-gpu는 환경변수를 통해 cuda 같은 관련 라이브러리의 위치를 불러오니, 당연히 관련 dll이 정상적으로 import 될 리가 없다.
