'aws'에 해당하는 글 4건

회사에 람다신봉자가 있다. 

 

ec2에 서버를 올리면 관리는 어떻게 하며, 트래픽과 확장까지 람다가 다 관리해주지 않느냐며, 서버 아키텍쳐를 람다로 만들어놨다. 

 

결국 람다신봉자는 서버를 하지 않는다. (...그럼 왜..이렇게 하고 갔나요??)

 

람다를 프로젝트에 사용하면서 문제점을 몇가지 써 보려 한다. 

 

1. 람다의 용량이 간당간당하다.

현재 서버 프레임워크는 django이며, 서비스의 특성상 많은 통계 패키지를 사용한다. (numpy, scipy, scikit-learn 등등...)

패키지 배포에 50MB라는 한도가 있지만 /tmp 꼼수와 람다의 다른 계층의 용량을 포함하면 250MB까지 올릴수 있다. 

 

"250MB이면 많은거 아냐? "라고  생각하시는 분은....위의 패키지를 로컬에 설치해 보시길 바란다. 

정말 용량이 간단간당하다. 또한 연구팀에서 배포한 모듈이 너무 커서 직접 배포 버전(다이어트 버전)을 만들기 까지 했다. 

용량이 큰 서비스는 그냥 서버(ec2, 혹은 fargate)를 통해서 하시길. 

 

- 위의 람다신봉자는 자신의 코드가 람다에 못올라간다고 fargate쓴다. 

 

2.  DB connection 문제

람다는 하나의 요청에 하나의 람다가 응답하는 구조이다. 

그러면 해당 요청에 RDS를 써야 한다면, 람다 하나당 커넥션 하나를 물고 있는게 된다. 

aws RDS에서 커넥션풀 == 돈이다. RDS 비싼거 쓸수록 커넥션풀이 늘어난다. 

해결!! 이면 좋겠지만, 돈이 없는걸? RDS도 가장 싼걸 쓰고 있다.

람다에서 바깥계층에 커넥션 풀을 둬서 커넥션을 계속 이용하는 방법도 있지만,  ( https://www.slideshare.net/awskorea/aws-lambda-aws-aws-summit-seoul-2019 )

서비스가 django에 zappa로 람다로 올리는 형식이다.  ==  바깥 계층을 사용을 못한다.

결국 람다 요청이 동시에 많은 요청이 오면 람다가 실행하다가 django에서 커넥션 에러를 뱉고 죽는다.

( 테스트 결과 200개 정도 동시 요청하면 사망 )

디비를 사용하면서 요청이 많은 서비스라면 람다를 쓰는것은 재고해보자

 

 

3. 스레딩 문제

메일을 보내는 로직이 필요했다. 문제는 메일을 보내는데 대략 8초 정도의 딜레이가 생긴다. (메일서버연동시)

사용자가 10초 동안이나 멈춘 화면을 볼수는 없기에 리턴값을 바로 주기 위해서 비동기식이 필요했고 

비동기식으로 처리하기 위해서 스레딩을 사용했었다. 

 

(왜 async를 사용하지 안했나고 물어보신다면, async를 사용하려면 내부까지 모두 비동기함수로 채워져야 한다. 

만일 block I/O 함수를 사용하면 비동기를 사용하나 마나 동기식으로 작동한다. django send_mail은 동기 함수이다.)

 

로컬에서 잘 돌아가길래 문제 없겠지~~~했는데 역시나...

메일이 갔다, 안갔다를 반복하면서도 에러가 없어서 이상하다 했는데

람다에서의 리턴은  람다가 cold 상태가 되므로 스레딩도 사라진다!!!!!!!!!!!!!

람다에서 스레딩을 사용할 경우 잘 생각해보자, 리턴하면 스레딩도 사라진다

 

 

 

aws lambda는 서버를 대신하지 않아

 

람다에 서버리스라는 말이 붙어서 많은 사람들이 기존의 서버를 대신하는 서비스 정도로 생각하고 있다. 

(ex : 함수 하나만 만들면 서버를 대신한다고?! 좋은데?!)

 

하지만 정확하게는 서비스간의 api 통신을 위해서 만들어 진게 lambda 이다. ( aws에서 서비스간의 통신을 위해서 만든 서비스라고 했다. )

 

단지 api 통신이 가능하기 때문에 서버로 사용가능 한 것일 뿐 본질은 아니다.

 

람다의 많은 예제들이 이미지 리사이즈, cron에 따른 배치 잡, 간단한 백그라운드 처리 인 이유는 위의 상황들을 겪어 보면 알게 된다. 

 

"아!! 서버로 사용하면 큰일나는구나.."

 

람다는 좋은 물건이다. 의도에 맞게 잘  사용한다면, 

 

 

추가

2019.08.22.  드디어 람다 신봉자도 람다는 api 서버와는 맞지 않다고 말했다!! 만세!!!

 

'aws' 카테고리의 다른 글

aws lambda는 서버를 대신하지 않아  (0) 2019.08.14
route53 s3 no targets available  (0) 2018.08.11
aws s3 권한 설정  (0) 2018.08.10
aws cloudWatch 알림 설정  (0) 2018.08.09

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Create Record Set -> Alias Target ->  s3 no targets available


route53을 통해서 s3버킷을 연동하려 할때  무슨 짓을 해도 s3의 end point 가 no targets available가 나온다면 


1. 진지하게 브라우져 캐쉬를 날려보길 바란다. (cmd + shift + r // ctrl + shift + r)


2. route53의 A레코드에 입력한 서브도메인과 s3버켓에 입력한 도메인이 같아야 한다. 


그러면 보인다.... (이걸로 2시간 날렸다... 시발 아마존..이걸 캐쉬를 거냐..)


'aws' 카테고리의 다른 글

aws lambda는 서버를 대신하지 않아  (0) 2019.08.14
route53 s3 no targets available  (0) 2018.08.11
aws s3 권한 설정  (0) 2018.08.10
aws cloudWatch 알림 설정  (0) 2018.08.09

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

aws s3 권한 설정

aws 2018.08.10 20:14


* 해당 과정은 프리티어에서 작성하였습니다. 


1. 먼저 s3의 버킷을 생성 합니다. (버킷 만들기 클릭)


2. 버킷의 이름을 적어 줍니다. (다음)


3. 해당 버킷의 권한을 추가해 줍니다. ( 버킷 소유에 대한 권한 입니다.)


4. 버킷 만들기 완료!!


5. 해당 버킷에 파일을 올리고 해당 파일의 링크로 들어가 보면 아래와 같이  AccessDenied 으로 접근 권한이 없습니다.


6. 버킷의 권한 -> 버킷 정책 -> 하단의 정책 생성기를 클릭 


7. 해당 옵션들을 지정해 주면 버킷에 사용할 권한을 생성해 줍니다. 

- select type of policy : s3 bucket policy

- effect : allow

- principal : *

- aws service : amazon s3

- actions : GetObject

를 선택해 줍니다. 


8. 이제 ARN를 지정해 줘야 합니다. 

설명에 나온 것처럼 arn::aws:s3:버킷이름/키로 구분 됩니다. 

저의 경우 arn:aws::s3:::testbucket201808/* 

로 지정하고 add statement 를 클릭하면 아래 화면과 같습니다. 

마지막으로 Generate Policy를 클릭하면 사용할 권한 정책이 생성됩니다. 


9. 생성된 policy josn를 복사합니다. 


10.  다시 권한의 버킷 정책에 복사한 정책을 붙여 넣기 후 저장을 눌러주면 



11. 권한에 막혀 있던 파일에 접근이 가능합니다.


12. 추가로 쓰지 않을 버킷은 s3 화면에서 해당 버킷 선택 후 버킷 삭제를 눌려주면 됩니다. 


'aws' 카테고리의 다른 글

aws lambda는 서버를 대신하지 않아  (0) 2019.08.14
route53 s3 no targets available  (0) 2018.08.11
aws s3 권한 설정  (0) 2018.08.10
aws cloudWatch 알림 설정  (0) 2018.08.09

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret




프리티어(무료)로 할경우 3번부터 시작하세요!!


1. EC2인스턴스 화면에서 인스턴스를 선택후 오른쪽 마우스 -> CloudWatch 모니터링  -> 세부 모니터링 활성화 


2. 세부 모니터링은 활성화시 추가 요금이 적용됩니다.  활성화!


3. 서비스 -> 관리도구 -> CloudWatch 선택


4. 경보 -> 경보 생성


5. EC2 지표를 선택 


6. EC2에서 알수 있는 경보 리스트 중 CPUUtillzation 선택


7. 관측 시간을 설정 합니다. (5분을 선택) -> 다음 


8. 경보에 대한 이름과 설명 / 조건을 넣어줍니다. 

이름 :  CPU WATCH

설명 : 알람 테스트

조건 : >= 20 (20보다 클경우 경보 알림)


9. 작업에 해당 조건이 넘을 경우 이벤트를 등록해 줍니다. 

이 경보가 발생할 경우 항상 : ALARM 상태 (알림을 보냄)

알림 보내기                        : CPU_ALARM  ( 새로 만들기 클릭 )

이메일 목록                       :  알림 받을 이메일 


10. 경보 생성을 하면 해당 이메일이 맞는지 확인 메일을 보냅니다. 

메일에 접속 후 확인 링크를 클릭 합니다. 


11. 이제 ec2로 접속후 cpu를 20%를 넘겨야 합니다. 

bash 실행으로 간단히 cpu를 달리게 합니다. 


$ yes > /dev/null



12. 이제 인스턴스 리스트에서 CPU 사용량이 증가하는것을 기다리면 됩니다. ( 프리티어일 경우 5분 정도 소요 됩니다. )


13. cloudWatch의 화면세 경보가 활성화 된것을 확인 가능합니다. 


14. 지정한 이메일로 설정한 알람이 온것도 확인 가능 합니다. 


15. EC2의 알림의 경우 CPU / 디스크 사용량  / 네트워크 / EC2의 상태 등으로 알림을 설정 할수 있습니다. 



'aws' 카테고리의 다른 글

aws lambda는 서버를 대신하지 않아  (0) 2019.08.14
route53 s3 no targets available  (0) 2018.08.11
aws s3 권한 설정  (0) 2018.08.10
aws cloudWatch 알림 설정  (0) 2018.08.09

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret