반응형

AWS SSH를 접속하기 위해 보통 Putty라는 SSH 접속 프로그램을 사용하게 되는데,

AWS에서 SSH 접속을 위해 제공해주는 키 페어 파일은 확장명이 pem파일인데 Putty에서는 ppk 파일을 요구한다.

즉, pem파일을 ppk파일로 변환하는 과정을 거쳐야 한다.

 

변환하기 위해서는 puttygen.exe 파일을 다운로드 받고 실행한다.

(https://www.puttygen.com/ 에서 다운로드 가능하다.)

위와 같이 프로그램이 실행되었으며, 위의 Load 버튼을 클릭한다.

먼저 pem 파일을 불러와야 하므로 확장자를 All Files(*.*) 로 변경해준 뒤 키 페어 파일(.pem)을 불러온다.

성공적으로 불러왔다는 메세지가 뜬다.

'Save private key' 버튼을 클릭한다.

위의 경고창에서는 '예' 버튼을 클릭한다. 

그리고 원하는 파일명의 ppk 파일로 저장하기만 하면 된다.

최종적으로 ppk 파일이 생성되며 해당 파일을 Putty에 지정하여 사용하면 된다.

 

참고로 Putty에서 ppk 파일 설정하는 영역은 아래와 같다.

Connection->SSH->Auth의 Private key file for authentication 부분을 생성한 키페어 파일로 설정해주고

접속하면 정상적으로 접속될 것이다.

반응형
반응형

 

오늘은 AWS에서 가장 많이 쓰는 EC2의 T계열 인스턴스의 특성을 설명한다.

EC2를 사용할 때 가장 흔하게 t2.micro 프리티어를 사용한다.

처음 사용할 때만 해도 특별한 생각 없이 사용했었는데 cpu 성능을 제공하는 방식이 조금 특별하다.

일반적으로 CPU 성능이 정해져있어서 24시간 같은 성능을 제공할 것이라 생각하지만,

T계열 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준 이상의 성능이 필요할 경우 버스트 기능이 동작하게 된다. 물론, 공짜는 아니고 인스턴스 사양마다 제공되는 크레딧이 다르고 그 크레딧이 남아있는 동안 버스트 기능을 사용할 수 있다.

 

기준 이하 성능 사용을 지속할 경우 크레딧이 쌓이고(한계치 있음), 그 이상의 성능을 사용할 경우 크레딧을 소모시킨다.

크레딧이 다 소모되면, 기준 이상의 성능을 발휘하지 못하고 성능은 급격히 떨어지게 된다.

이러한 특성은 평소에는 CPU사용률 저조하다가 특정 시간대에 높은 사용률을 사용해야 할 경우 매우 효율적이다.

 

그렇지 않고, 24시간 내내 부하가 존재하는 서버의 경우 m4, m5 계열의 인스턴스를 사용하는 것이 바람직하다.

이 계열의 경우는 T계열처럼 크레딧 개념을 사용하지 않고 항상 같은 성능을 제공해준다.

다만, 가격이 비싸다는 장점이 있기 때문에 자신의 서버가 어느 특성에 적합한지를 판단하여 사양을 결정하는 것이 좋다.

 

T계열 인스턴스 사용시 크레딧의 상태는 CloudWatch에서 확인할 수 있다.

추가로 무제한 모드라는 것이 존재하는데, 이는 크레딧을 모두 소모하고 난 후에도 기준 이상의 성능을 사용할 때 비용을 추가하여 기준 이상의 성능을 사용할 수 있는 모드이다.

t2 인스턴스는 무제한 모드가 기본으로 꺼져있지만, t3 인스턴스의 경우 무제한 모드가 기본으로 옵션이 켜져있으므로 참고하기 바란다.

 

프리티어를 쓰는게 아니라면 t2보다는 t3 계열 인스턴스 사용하는 것을 추천하며,(아무래도 성능 향상, 비용 절감 등의 효과가 있다)

t3 계열의 경우 t3와 t3a가 나눠지는데, 두 계열 성능은 크게 다르지 않고 가격은 t3a가 싸다.

t3는 intel cpu, t3a는 amd cpu를 쓰는데, 가성비를 따져보면 t3a가 더 나은 것으로 생각된다.

 

반응형
반응형

 

EC2를 처음 세팅하고 SSH로 접속하여 date 명령을 실행해보면 시간이 한국 시간과 다르게 표시되어있다.

UTC라고 하는 세계 표준 시간을 사용하기 때문인데 한국 시간에서 9시간을 빼주면 해당 시간이 된다.

좀 더 편하게 시간을 관리하기 위해 시간을 바꾸는데, 보통 여기서 실수를 많이 할 것 같다.

 

sudo date -s "2021-04-07 20:10:36" 

위와 같이 date명령을 이용해서 날짜와 시간을 변경할 수 있지만 위와 같이 한국 시간으로 바로 변경하면 문제가 된다.

EC2 타임존이 기본적으로 UTC(세계 표준시)로 지정되어있으니, 시간 기준은 세계 표준시로 되어있고 날짜와 시간 값만 한국 시간으로 바뀌게 되는 것이다. 이렇게 되면 다른 서비스와 시간 동기를 맞출 경우 시간이 다르다고 판단하여 인증 등의 문제가 발생할 수 있다.

 

즉, 제대로 변경하기 위해서는 타임존을 한국 시간으로 변경하면 별도의 시간을 지정하지 않아도 된다.

 

sudo cat /etc/localtime

 

위 명령어로 읽어보면 UTC0라는 텍스트가 보일 것이며 이것이 UTC 기준으로 시간이 지정된다는 의미이다.

 

sudo rm /etc/localtime

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

 

위 두 명령을 차례로 입력해준다.

기존의 UTC기준 타임존 세팅 파일을 제거하고, 서울 기준 타임존 세팅 파일을 적용하는 것이다.

 

sudo cat /etc/localtime 명령으로 확인해보면 KST-9라는 문구가 확인이 된다.

date 명령으로 바로 날짜와 시간을 확인해보면 한국 시간 기준으로 변경된 것을 확인할 수 있다.

 

반응형
반응형

Error: Credential implementation provided to initializeApp() via the "credential" property failed to fetch a valid Google OAuth2 access token with the following error: "Error fetching access token: invalid_grant (Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim.)". There are two likely causes: (1) your server time is not properly synced or (2) your certificate key file has been revoked. To solve (1), re-sync the time on your server. To solve (2), make sure the key ID for your key file is still present at https://console.firebase.google.com/iam-admin/serviceaccounts/project. If not, generate a new key file at console.firebase.google.com/project/_/settings/serviceaccounts/adminsdk.  

 

AWS EC2에 노드JS 서버를 올려서 푸시 서비스를 사용하고 있는데 어느 순간 푸시를 보낼 때마다 위와 같은 메세지가 뜨면서 푸시 서비스가 제대로 작동하지 않았다. 위에 의심되는 원인이 나열되어있듯이 나의 문제는 (1)번에 해당했다. 

내가 서버의 시간을 실수로 전혀 다른 시간으로 변경하면서, 푸시를 위해 파이어베이스 인증하는 과정에서 OAUTH 토큰의 유효 시간 체크에 대한 문제가 발생한 것이었다. 이 문제는 다시 서버의 시간을 정상적으로 돌리면서 해결되었다.

위와 같은 문제가 발생했을 때 서버의 시간을 확인하여 실제 시간과 오차가 많이 발생하지 않는지 확인해보도록 한다.

 

반응형

+ Recent posts