머 DynamoDB에 관심가지고 도입하려는 여러 이유가 있겠지만,
괜히 어설프게 도입해놓고 상처받고, 욕하고, 비슷한 짓거리 하는 오픈소스 EC2에 직접 설치하는 삽질을 하지 말라고 이런글을 씁니다.
결론부터 말하면 꽤 괜찮은 물건이고, 잘쓰면 주변에서 “오오! 어떻게 평균 응답시간을 10ms 로 맞추셨나요!! 오오!! TPS가 폭발하는 서버를 만드셨네요! 오오!!” 이딴 이야기 듣을 수 있다.
일단, 조심해야할것들을 먼저 나열한다.
- Throughput 재앙은 정말 지옥이다.
서비스가 성장하고 트래픽이 들어오는것은 예측하기 힘든 속성이다. 그런데 DynamoDB는 아주 타이트한 Throughput( 아-_- 영타치기 힘드네 ) 제한 정책이 있다.
만약 write: 1000을 지정했는데, 이 이상이 들어온다면, 그냥 서버 죽는다고 보면 된다. 나중에 이사태를 인지하고 write를 높이면 5초안에 해결된다-_-
이게 가끔 사람을 쪽팔리게 만든다. 머 결국 예상못한 내가 죄인이기는 하지만.. 쩝 ㅠ. 왠만하면 자동으로 쓰루풋(그냥 한글로 씁니다.) 조절하는 코드 만들어서 데몬 띄우는게
건강에도 좋고, 승진에도 좋을것이다. (그런데.. 함정은 쓰루풋을 올리는건 제한이 없지만, 쓰루풋을 내리는건 하루에 4번만 허락되는게 함정-_-)
tip) 이건 아마존 공식블로그에 이미 템플릿도 있다. 따라해~ ( https://aws.amazon.com/ko/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/ )
- DynamoDB에서 SQL처럼 쿨하게 조회가 안된다.
이건 정신차리고 DynamoDB 본 후, 몇시간안에 깨닫는 내용이다. 만약 No-SQL (음.. 정확히는 Key-Value DB)을 진작에 해봤다면 멘붕은 안오겠지만,
RDB하다가 넘어오셨다면, 머리가 하얘질 수 있다. 머 그래도 아주 조회가 안되는것은 아니다. GSI를 걸면 조회 가능하다.
그런데 돈내야되. 그리고 이놈도 쓰루풋 설정해줘야해. (내부적으로는 그냥 테이블 복사이기 때문;;)
그러니, 딱 서버와 통신하는 용도로만 써야한다.
쉽게 말해서, 운영팀에서 조건 대충 “어제 방문한 사람중에 500원 이상 있는 녀석들 ID좀 뽑아주세요!” 이렇게 던졌을때 RDB는 껌이지만,
DynamoDB는 어려울 수 있다. 게다가.. 콘솔도 없고, 프로그래밍 짜서 돌려야 될 수도 있다.
- No-sql이 멋있어 보이는가? 그만큼 생산성 잃을수도, 유지보수가 난감할 수 있다.
생산성은, 요즘 RDB는 ORM도구들 쓰면 코드 몇줄 안치고 데이타 조작은 끝날텐데..
(뭐, 성능상 난 네이티브가 좋아 이러면서 쌩짜 코드 다짜는 겉멋 프로그래머 제외 <- 요런짓하면 승진안되고 주변사람 괴롭게함 )이녀석은 아무리 하이랭귀지더라도.. 직접 DAO다 만들어야 한다. SDK도 Low-level, High-level 나뉘어져 있는데. 쓰다보면 Low-level에서만 되는것들이 있어서, 걍 Low-level로 짜야한다.
뭐 개발은 그렇다고 쳐도, 유지보수는 극혐이다.
일단, 테이블 이름 변경 안된다. ( 처음에 잘 정하자! 이거 정말 짜증남. 왠만하면 엄격한 이름 규칙 만들어서 정하시오.)
뭐 이건 당연한거지만, RDB쓰다가 넘어온사람들을 위해서 말을 하자면 컬럼 이름도 변경 안된다.
그리고 이건 정말 너무 짜증나는건데, 우리회사의 단독 서비스가 10개정도 되는데, Table들을 하나로 묶는 카테고리 개념이 없다.
즉, 다른 서비스의 Table도 같은 콘솔에 공존한다. 이건 빨리 만들어줬으면 좋겠다.
- 초보관리자가.. 실수로.. Delete Table을 하면 “bye bye~”
3번하고 이어진다.
EC2는 Delete Protection 기능이 있다. 근데 Dynamo는 없다. 그냥 생각없이 OK 누르는 작은 컨펌창하나 있고, 쿨하게 지워진다.
잘못지웠다면?? 끝. 방법없음.
더 재앙은.. 당신 옆 사무실에 이번에 입사한 김인턴이 날릴 수 도 있다.
라이브중인 서비스라면 정책상 콘솔에서 절대 지우지 못하게 하고(계정별 권한설정으로 막으시오), 그냥 별도 구축한 admin에 프로텍션 기능 넣어서 관리해라. 그게 가장 속편하다.
- 백업은 어떻게?
메뉴에 Export 클릭해서 따라하면 된다.
주기적으로 하고싶으면, Data Pipeline을 통해서 알아보면 된다.
솔찍히 이건, 아직 기술부채중이다. ㅠ 그냥 내깔려두고 있다. 좋고 쉬운 방법 있으면 포스팅하리~
- hashkey 잘 정의해야 한다. 이거 개념없이 만들었다가는 망한다.
일단, 중간에 못바꾼다-_- 그래서 잘 정해야 하고.
그리고 hashkey의 limit이 있다. 각 key별로 1000 read / 500 write를 넘을 수 없다.
만약 현재 쓰루풋 설정이 1000인데, 500정도에서 폭풍에러를 내고 있다면
버그가 아니고 hashkey 하나에 그 요청이 몰리고 있는것이다.
이건 짧은시간에 해결이 힘드니, 이것만큼은 머리빠지게 고민해서 잘 정해야 한다.
이제는 조금 좋은 이야기를 해보겠다.
- Expression 은 어려워도 꼭 알아두자. SP(stored procedure)처럼은 아니지만, atomic 연산을 개런티 해주신다!
- Throughput 재앙에서 벗어난다면, 그냥 꾸준히 빠르다. 쿨하다.
- DynamoDB의 내용을 검색하고 싶다고? 가장 쿨한 방법은 Redshift 쓰세요~
- 이건머, 요즘 이거 안되는 클라우드 서비스는 없으니. full managed 라서, 신경안써도 된다. ( Throughput만 신경쓰세요!! )
Empty-stack developer 