출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
페이스북의 Server Side Architecture Group(이하 SSAG)에서 2차 세미나를 해서 오랜만에 평일 저녁에 세미나에 참가했다. 나는 트위터를 위주로 사용하는 편이고 페이스북은 그 틈틈이 사용하는 편이라 여러 그룹에 가입되어 있지만, 그룹에 잘 들어가진 않는다. 사실 여러 그룹을 돌아보기 좋은 인터페이스도 아니긴 하지만 난 보통 글을 퍼블릭하게 쓰는 경향이 있어서 특정 그룹에 글은 잘 안 올리게 된다.(다른 사람은 반대인듯하다.) 어쨌든 SSAG는 꽤 큰 규모로 발전했고 얼마 전부터 세미나도 하기 시작했는데 이번이 그 2번째이다.
MongoDB, 이렇게 쓰세요 - 한대희
온라인 데이팅 서비스인 이음에서 글로벌 데이팅 서비스로 만든 hey를 만들면서 MongDB를 적용했던 경험을 공유한 시간이었다. 내용은 발표자료에 잘 나와있으므로 굳이 따로 정리하지는 않겠다.(SSAG에서 동영상도 공유 예정인 걸로 알고 있다.)나는 NoSQL 류에 관대한 입장을 가진 편이고 개인 프로젝트에서 MongoDB를 많이 쓰는 편인데 사실 이는 성능보다는(개인 프로젝트에서 스케일아웃 할 일이 있을 리가...) 개발 편의성 때문이다. 치밀한 계획하에 개발하지 않는 개인 프로젝트에서 MongoDB같은 스키마 없는 데이터베이스를 사용할 때의 편리함은 이루 말할 수 없다. 하지만 서비스로 나간다고 생각하면 글쎄... 쓰던 거니 고민은 하겠지만 덥석 쓰지는 않을 것 같다. 사실 이번 발표도 아주 깊은 내용이라기보다는 MongoDB는 사용 안 해봤지만 사용을 고려하는 입장에서는 미리 알면 도움될 부분이 상당히 많이 있다고 생각한다. 처음 발표한다고 하신 것 치고는 발표자료도 괜찮고 잘하신 듯...(나 처음 할 때 생각하면 덜덜덜)
이 발표의 결과에도 비슷한 얘기가 나오지만 조금 생각을 더하자면 난 기술을 좀 트랜디하게 쫓는 편이지만 새로운 기술을 사용할 때도 사람들이 너무 익숙한 기술의 결과와 수준을 비교한다고 생각하는 편이다. 오랫동안 잘 쓴 기술이 아무래도 더 잘 튜닝해서 쓰게 되어 있고 새로운 기술은 그러한 노하우가 없으므로 문서나 공유된 수준의 내용만 가지고 사용할 수밖에 없으므로 내부에 경험이 쌓이기 전까지는 아무래도 성능, 생산성 등의 저하를 경험할 수밖에 없는데 사람들은 종종 그런 단계를 한 번에 뛰어넘고 싶어하는 것 같다.(발표자분이 그렇다는 의미는 아니다.) 그리고 자주 나오듯이 NoSQL은 RDBMS를 대체하기 위해서 나온 것이 아니라 RDBMS가 커버하지 않는 부분을 커버하기 위해서 나온 것이다. 그럼에도 RDBMS의 대체재로 너무 1:1 비교개념으로 다가가면 자칫 망하기 쉽다.(DB에 대해 잘 아는 것이 아니므로 여기까지...)
발표 후 질답시간에 몇몇 질문에 대해서 청중에서 대신 답변을 하게 되면서 청중끼리 반박, 재반박이 이어지는 재미있는 토론이 있었다. 발표자 입장에서는 약간 곤혹스러운 상황일 수도 있겠지만 이렇게 자유로운 분위기(다양한 질문을 하고 그에 대해서 의견 있으면 서로 얘기하는...) 아주 좋다. 난 사실 발표 중에도 궁금한 게 있으면 손들고 묻고 그런 스터디스러운 발표를 더 좋아하는 편이다.
모바일 서비스 AWS 구축 경험 공유 - 김민태
NC Soft에서 소규모 팀으로 Chekit이라는 글로벌 서비스를 AWS에 구축한 경험을 공유한 발표로 AWS 기반 백앤드 구축에서 공유한 내용의 확장판이라고 볼 수 있다. 전에도 김민태님의 발표를 들은 적이 있는데 이번 발표도 세련된 발표자료에 능숙한 발표를 보여주셨다.(발표 중 여유로운 자세로 자연스러운 개그가 참 좋다.) 사용하는 개인 서버도 있고 AWS같은 확장성이나 유연성이 필요한 서비스를 만들어 본 적이없어서(혹은 AWS를 쓸 수 있는 환경이 아니거나) 주로 가상서버를 사용하고 있다. 그래서 AWS의 서비스들을 사용해 본적은 한 번도 없다. AWS의 인기가 워낙 좋으므로 관심은 상당히 있었지만 쓸 일이 없었던 탓에 관련 세미나도 별로 참여해보지 못했고 자세히 알지 못한다.그런 면에서 나같이 AWS의 경험이 없는 사람에게는 아주 유용한 발표였다. AWS를 사용해 보지 않은 입장에서 서비스까지 구축하면서 고민한 부분과 삽질한 내용을 그대로 공유 받을 수 있었기 때문이다. 특히 AWS 서비스들의 가격(아무래도 가장 신경 쓰일 부분이니...)을 계산에 볼 수 있는 CloudMix의 서비스나 AWS에 구축할 때 사용할 수 있는 아키텍처 레퍼런스를 볼수 있는 페이지를 포함해서 Checkit이 어떤 아키텍처로 구성했는가 하는 내용은 나중에 AWS를 사용할 때 많이 도움이 될 것 같다.
AWS Cost Optimization: A journey to AWS cost optimization - 정유진
마지막에 미니 세션 비슷하게 AWS의 엔지니어분이 오셔서 AWS를 쓸 때 비용을 최적화해서 쓰려면 어떻게 해야 하는 가에 대해서 공유를 해주셨다. 나중에 AWS도 이제 한국에 들어와서 작년부터 세미나나 커뮤니티 등에서 이런 홍보를 많이 하는 듯한데 처음 듣는 나에겐 꽤 유용한 내용이었다. AWS를 사용할 때 가장 많이 하는 실수 중에 하나가 기존에 사내에서 사용하던 물리 서버와 같은 스펙으로 AWS를 같게 구축하는 것이다. 예시로 로드밸런서 1대, 웹서버 10대, 데이터베이스 서버 2대로 구성하면 한 달에 17,000불 정도가 나올 수 있다. 이렇게 구성한 경우 서버 대부분이 Idle 상태가 되는데 AWS의 비용은 "사용한 만큼 과금한다"는 개념이므로 이렇게 쓰는 것은 AWS를 제대로 쓰는 것이 아니다. EC2에는 "change instance type"라는 것이 있는데 이를 사용하면 5-10분 내에 원하는 대로 서버의 성능을 변경할 수 있다.그래서 AWS를 사용할 때는 불필요하게 좋은 성능을 사용하지 않아야 한다. m3.xlarge를 m1.small로 바꾸고 db.m2.xlarge를 db.m1.small로 바꾸면 월 8,000불 정도로 줄일 수 있다. 여기에 EBS를 PIOPS에서 Standard 50GB로 바꾸고 RDS 볼륨을 1TB PIOPS에서 Standard 50GB로 바꾸면 월 700불까지로 내릴 수 있다. 보통의 서비스는 인바운드보다 아웃바운드 트래픽이 더 많은데 아마존은 아웃바운드 트래픽에 대해서만 과금을 하므로 AWS의 서비스를 적절히 이용하면 비용을 줄일 수 있다. 그리고 트래픽에 맞춰서 서버사양을 늘리는 오토 스케일링을 될 수 있으면 사용해라. 서비스 대부분은 시간별로 트래픽이 다른데 계속 좋은 사양을 유지하지 않고 트래픽 증가에 따라 자동으로 변경되게 설정하면 비용을 월 450불 정도까지 낮출 수 있다. 마지막으로 Reserved Instances를 사용하는 것이 좋다. Reserved Instances는 장기간(1년, 3년 등)의 비용을 미리 내면 할인을 해주는 과금체계인데 3개월 이상 쓰게 되면 웬만하면 Reserved Instances를 사용하는 것이 더 낮다. 서버의 최소 트래픽에 맞춘 사양 정도를 Reserved Instances로 사용하고 나머지는 오토스케일링으로 확장해서 쓰면 비용을 더 낮출 수 있다.
