티스토리 뷰

 3개월간 AWS를 적극 도입하여 단기 프로젝트를 수행했습니다.

 AWS를 사용하면서 느꼈던 사용기를 간략하게 적어봅니다.





 전체 작업은, raw JSON 데이터를 개별 파싱해서 MySQL에 넣고, 하루에 한 번씩 배치를 돌려서 최종 결과물을 S3에 저장하는 프로젝트였습니다. 이 과정에서 AWS의 서비스 중 S3, Lambda, DynamoDB, 관리형 MySQL, Node.js SDK, CloudWatch, AMI, AWS-CLI 등을 사용했네요.





S3

- 용량 걱정 없음

 용량 걱정이 없다는 것은 최고의 장점입니다. 돈은 내겠지만...

 EC2를 설정할 때 저장공간 설정하던 것 마저도 없으니 정말 편하네요.


- AWS Console 검색 버그

 버그가 좀 많네요....

 실제 파일보다 더 많은 수가 검색되기도 하고 추가 로딩에 따라서 최종 검색 개수가 달라지기도 합니다.

 전체 목록에서 몇 개 파일만 골라서 작업을 하기에는 불편합니다. 일괄 다운로드가 안되는 점도 불편하네요. 일일이 다운받기 귀찮아서 별개의 클라이언트를 사용했습니다.

 Bucket 두 개를 왔다갔다 하면서 필요한 파일을 복사하는 것도 탐색기를 사용하는 것처럼 생각하면 지루한 반복작업이 될 수 있습니다. 창 2개를 띄워서 복/붙 하고 싶지만 안되네요.


Lambda

- 서버 스펙 신경쓰지 않음

 EC2 설정할 때 처럼 CPU, 램, 저장 공간을 설정할 필요가 없다는 것에서 참 편합니다.

 서버를 구성하는 아키텍처가 바뀔만 하네요.


- Triggering

 S3 파일 업로드와 연결하면 자동 실행되기 때문에 따로 실행 작업이 없어서 정말 편합니다. S3에 쌓이는 raw 데이터를 처리하기에는 최적의 환경이네요.

 스케쥴을 지정하면 특정 시간에 반복되는 배치 작업도 편하게 설정해 놓을 수 있습니다.


CloudWatch

- 불편한 로그 확인

 로그를 보기에 그렇게 좋은 환경은 아닙니다. normal, warn, error 만이라도 색상 구별이 되면 좀 낫겠지만...

 페이지를 넘나들면서 원하는 로그를 찾기가 정말 귀찮았는데 최근에 업데이트가 되면서 연속 스크롤로 바뀌면서 좀 나아졌습니다.

 딱히 용도를 찾지 못한 해시 태그 같은 건 좀 없어졌으면 좋겠네요... 찍고 싶은 로그보다 훨씬 많아요....

빠른 시간 안에 lambda가 여러 번 실행되면 하나의 항목에 겹치는 경우가 있습니다. 찾기가 좀 귀찮아지죠.


AMI

- 개발 권한 설정 편함

 관리자가 개발 계정을 생성하고 권한을 주면, 비밀번호 생성부터 접속, 활용까지 신경쓰지 않아도 되니 편합니다.

 별도의 AMI가 있는 경우 루트 계정으로 들어가서 AMI에서 접속 주소를 활용하는 부분만 좀 나아지면 좋겠네요.


SDK - Node.js

- 편함

 Node 코드와 이질감이 없이 콜백 방식으로 잘 어울립니다. API 문서도 잘 되어 있고 각 인자에 대한 설명도 꽤 잘되어 있습니다.

 아직 AWS에 대한 포스팅이 많이 없어서 헤매기 시작하면 이래저래 삽질 해봐야 하긴 했네요.


DynamoDB

 이번 프로젝트에서 사용하고 싶었지만 최종적으로 사용하지 않았던 서비스입니다. 타사 NoSQL 대비 장점을 딱히 모르겠네요


- 문법 불편함, ORM (Object-relational mapping) 없음

 다른 프로젝트에서 mongoose를 사용해서 MongoDB를 돌리고 있습니다. ORM은 Node.js 코드에서도 이질감이 없고 객체지향 코드의 특성에도 잘 맞습니다만, DynamoDB에는 없네요.

 new AWS.DynamoDB.DocumentClient() 를 사용한 방식도 써보긴 했지만 편하진 않았습니다. 긴 키워드를 이용해서 파라미터를 설정하고 파라미터의 값을 String 타입으로 제어하는 방식은 왜 이렇게 하는지 모르겠습니다. 쿼리를 위한 파라미터는 아래와 같이 사용합니다.

 이 코드만 해도 수많은 불편함이 있었습니다.

 항목 이름이 일단 길어요. 항목마다 비슷해서 헷갈리기도 합니다. 오타 조심

 필드 항목 생성에는 아무 제한이 없었지만 사용할 때 필드 이름이 예약된 키워드라면 그대로 사용할 수 없습니다.  위 코드에서 date 가 예약된 키워드라서 '#d' 라는 문자로 변경해서 사용했습니다. 개수가 적으면 별 문제 아닐 수 있겠지만 찾아보니 573개로 꽤 많습니다. 일반적으로 많이 쓰는 단어들도 많네요. 예약 키워드 확인

 between 뒤에 들어간 ':변수명' 도 왜 이렇게 해야 하는지 모르겠네요. startDate와 endDate에 해당하는 값은 ExpressionAttributeValues (거봐요.. 이름 길잖아요...) 오브젝트로 일반 변수와 매칭시켜줘야 합니다. `date between ${startDate} and ${endDate}` 와 같이 간단하게 쓰고 싶은데 쭉 늘어놓는 느낌입니다.....

 between과 같이 범위 안의 데이터를 쿼리하는 동작은 query() 함수에서 동작하지 않았습니다. scan() 함수를 사용해야 했는데, 함수가 달라지면서 설정해야 하는 파라미터가 다릅니다. scan() 방식은 모두 들고 온 후 projection을 수행하는 방식이라 비효율적이기도 하죠. 쿼리 방식이 일관되지 않은 느낌입니다.

 자료형도 다양하지 않아서 저장이 어떻게 되었는지 꼭 확인해야 합니다. Date객체의 경우 그대로 저장되지 않아서 toISOString() 함수 결과를 String으로 저장했습니다. 에러가 나는 것이 아니라 항목이 빠진 채로 저장되더라구요.


- 최대 아이템 크기 제한 400KB

 MongoDB는 항목당 제한이 16MB로 상당히 자유롭게 사용할 수 있었고 방심하던 차에, DynamoDB의 아이템 최대 크기는 400KB였습니다. 저장이 안되는 경우가 있어서 확인해보니 용량이 넘더라구요.

 데이터에 배열이 있는 경우 항목 이름이나 데이터에 별도의 최적화가 필요할 수도 있습니다. 문제가 커지면 테이블과 필드 설계를 변경해야 할 수도 있죠. 제 경우에는 DynamoDB를 버리고 S3에 JSON 데이터를 저장하는 방식으로 변경했습니다.


- 클라이언트 불편

 DynamoDB의 데이터에 접근할 방법이 AWS Console을 통하는 방법이 있는데, 저장된 데이터가 큰 경우 브라우저가 멈춥니다.... 딱히 우회할 수 있는 방법도 없네요. 문제가 있는 경우 테이블을 날리고 데이터를 다시 구축하는 방법을 사용했습니다.


- 생각보다 빠르게 소진되는 read/write capacity

데이터가 큰 경우 read/write capacity가 꽤 빠르게 고갈되기도 했습니다. auto scaling까진 해보지 않았지만 개발 단계에서 사용량이 소진되면 몇 분 기다리다 다시 작업해야 했습니다.


관리형 MySQL

- MySQL + 관리형의 장점

 S3와 마찬가지로 용량 걱정이 없다는 것은 최고의 장점입니다. 업데이트도 지정된 시간에 AWS 측에서 자동으로 수행해줍니다.

 사용 방법이 일반 MySQL과 동일한 것도 딱히 어색함을 느끼지 않았던 점이네요. 기존에 MySQL을 사용한 적이 있으면 차이점을 느끼기 힘듭니다.

 관리형 DB를 사용하면 따로 DB서버를 구성하고 유지관리해야 할 이유가 전혀 없네요. 편합니다.



AWS-CLI

 Node.js 프로젝트에 npm script를 설정하면 기존 npm script와 이질감 없이 사용할 수 있습니다. 제 경우에는 lambda 함수 실행을 npm test에 연결해서 사용하니 정말 편했습니다.

 매개변수가 많아서 좀 복잡하긴 한데, AWS에 서비스가 많으니 어쩔수 없죠 ㅎ




 전반적으로 AWS 서비스들을 편하게 사용했으나 DynamoDB는 사용을 포기하고 S3에 JSON 데이터를 저장하는 방식으로 변경했습니다. MongoDB 대비해서도 장점은 잘 모르겠네요.

 아직은 AWS에 대한 사용자들의 경험이 많지 않아서 막힐 때 자료를 찾기가 쉽지는 않았습니다. 좀 더 다듬어지면 훌륭한 플랫폼으로 발전할 것 같습니다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함