3. 하지만 이미지 파일 서버와 이미지 전송은 AWS에서
츄카(https://chucar.co.kr) 서비스 오픈전에 마이메이크업스튜디오(http://mymakeupstudio.co.kr, 이하 마메스)라는 서비스를 개발했었습니다. 이 서비스도 NCloud기반으로 인프라를 구성했고 NCloud의 파일 스토리지를 사용했구요. 마메스가 두달정도 실운영되고 사용자가 증가되는 상황에서 큰 서비스 장애가 두번 발생했었습니다. 원인은 NCloud 파일 스트리지 장애였구요.물론 100% 완전 무결한 시스템은 없다고 생각합니다. 장애는 발생가능하고 그걸 빠르게 알고 복구할수 있고 프로세스적으로 장애상황이 발생하지 않도록 하는 것이 중요하다고 생각합니다만. NCloud의 경우는 문제가 많았다고 생각하고 있습니다.
첫 장애때 상황을 보면 그날 NCloud 공지로 콘솔 시스템 업그레이드를 한다고 했었습니다. 오후 6시로인가에 잠시 콘솔을 사용할수 없다고 공지가 되었고 실서비스는 문제가 없다고 했습니다.
하지만 그렇지 않았습니다. 파일 스토리지로 파일 업로드가 되지 않는 상황이 발생하였고 두시간여 동안 장애가 지속된 것으로 기억합니다. 당시 파악된 원인은 파일스토리지 API 서버에 문제가 있던 것이었고 콘솔 업그레이드를 하면서 파일스토리지 API 서버도 함께 변경이 된것이 문제였습니다.
어이없는 일이었죠. 1) 콘솔 업그레이드만을 공지하고 다른 시스템도 함께 건드린것. 2) 실서비스되고 있는 시스템을 오후시간에 건드린것. 도저히 네이버의 운영이라고 생각할수 없는 일이었습니다. 차라리 공지가 제대로 되었고 오후가 아닌 새벽시간에 작업이 이루어졌으면 저희도 대응을 했을텐데.
이일로 강력하게 항의를 했고 요금할인을 받는 것으로 마무리 했습니다. 담당자분에게 이런 프로세스적인 장애가 발생하지 않도록 노력하겠다는 다짐을 받았구요. 사용자에게 나쁜 서비스 경험을 준것은 어찌할수 없었지만요.
바로 다음주에 장애가 또 발생했습니다. 오후 9시 이후에 업로드된 파일이 일정시간후 삭제되는 그런 엄청난 장애였습니다. ㄷㄷㄷ. 시스템 변경 공지도 없었고 장애가 난지 일주일밖에 되지 않은 상황에서... 이번에는 NCloud의 API 서버에 로직이 잘못되어서 파일을 삭제하게 되었다고 하더군요. 제대로 테스트되지 않은 로직을 배포한 것도 문제지만 시스템 변경 공지도 없었다는 건 더 문제 였습니다. 정말 어이없지만 원인보고만 받고 바로 다음날 AWS S3로 바로 마이그레이션 했습니다.
저도 개발자이고 서비스를 만드는 사람으로써 장애는 일어날수 밖에 없다고 생각합니다. 대신 장애를 줄이는 노력을 해야하고 그것을 위해서 다양한 방법을 동원해야죠. 그런데 앞의 두 사건은 프로세스 그리고 그걸 운영하는 사람의 문제였다고 생각되어서 쉽게 해결될수는 없다고 봤습니다. 프로세스는 문화로 오랜시간 만들어진 것이기 때문에 쉽게 바꿀수 없고 바꾸려면 시간이 걸리는 것이라고 생각했기 때문입니다.
참고.
- 가상 서버는 여전히 NCloud를 잘 사용하고 있습니다.
- 얼마전에 NCloud를 파일 스토리지가 장애라면서 전화 연락이 왔었습니다.(두번의 장애로 먼저 연락을 주더군요.) S3로 바꾸길 잘했다고 속으로 생각했습니다.
4. 앱/웹 모두 단일 API 서버를 통해 서비스
요즘 서비스를 개발하면 앱은 기본으로 개발하고 웹서비스는 추가로 개발하곤 합니다. 그런데 츄카(https://chucar.co.kr)는 앱/웹을 모두 개발해야한다고 전략적으로 판단했고 두가지 클라이언트를 지원해야 했습니다. 그럼 앱용 API 서버, 웹서비스용 서버 이렇게 두가지가 개발되는 것이 일반적입니다. 이때 비지니스 로직은 API 서버와 웹서비스 서버 양쪽에 두거나 레이어를 하나더 만들어서 API, 웹서비스 - 비지니스 로직 - DB 이렇게 구성해야 할 것입니다.비지니스 로직을 두벌 만드는 건 서비스 유지보수나 일관성 측면에서 문제가 있고 레이어가 추가되는건 효율 측면에서 문제가 있습니다. 그래서 API 서버를 하나로 두고 웹/앱 모두에서 사용가능하도록 하고 싶었고 그러기 위해서 웹에서도 API 서버로 서비스 요청을 처리하도록 해야했습니다.
이때 사용할 수 있는 기술은 여러가지가 있을수 있습니다. 플래시, 실버라이트류의 기술 또는 ajax 를 이용한 기술. 당연히 플래시류의 기술은 검토 대상이 아니었고 ajax를 이용한 클라이언트를 생각했습니다. 그동안의 경험상 일부분이 아닌 전체를 웹페이지를 ajax를 통해 구성하는건 헬게이트를 제손으로 직접 여는 것이므로 javascript MVC framework 도입을 검토했고 다음과 같은 그래프로 쉽게 결론 내렸습니다.
http://www.google.com/trends/explore#cat=0-5&q=angularjs,%20backbone.js,%20ember.js,%20knockoutjs&date=today%2012-m&cmpt=q
그래프 상에서 파란선이 angularjs 입니다. 이 그래프만 봐도 다른것을 선택할 이유는 없어보입니다.
초반 세팅과정이 쉽지는 않았습니다. 처음 접해보는 것인데다가 requirejs에 엮어서 쓰려고 했더니 애로가 많았습니다. 다행히 https://github.com/mariussoutier/play-angular-require-seed 시드 프로젝트 도움을 받아서 세팅하고 하나씩 배우면서 개발을 진행했습니다. 이전에 jquery 만을 사용하던 방식에 비하면 이건 정말 신세계 였습니다. 안드로이드나 윈도우 애플리케이션을 개발하는 느낌으로 웹 프론트앤드를 개발할수 있다니. 특히나 인상적인건 angularjs는 html상에서 directive나 attribute로 표현되기 때문에 퍼블리셔와 협업이 이전보다 수월했고 데이터 바인딩 방식으로 인해서 코드량도 드라마틱하게 줄고 결국 생산성이 높아졌습니다.
개발하면서 문제가 없는건 아니었는데 새로운 프레임워크를 배워야 해서 발생하는 점은 제외하더라도 그동안 어려웠던 걸 쉽게 해준 대신에 쉽게 되었던걸 어렵게 만들어버렸다는 점입니다.
angularjs 모듈화가 되지 않은 외부 라이브러리/API 를 바로 사용하기가 힘들다는 것이었는데 이부분은 다른 글에서 좀더 자세하게 말씀드리겠습니다.
어째거나 angularjs를 도입해서 단일 API 서버로 웹/앱을 모두 지원하도록 했습니다.
5. 이중화는 서버가 놀고 있어도 해야 하는 것
서비스 시작시 트래픽은 특별한 서비스가 아니고서야 저사양의 서버 한대로 충분히 커버가 가능한 양일 것입니다. 츄카도 다르지 않아서 CPU가 올라가는 모습은 거의 볼수 없는데요.
혹시 모를 상황에 대비하기 위해 API 서버/DB 서버 모두 이중화했습니다.
API 서버는 NCloud의 로드밸런서를 이용해서 이중화했습니다. 클라우드 서비스를 사용하는 장점으로 값비싼 L4장비를 저렴하게 이용할수 있었고 서버 이미지를 떠서 저장할 수 있기 때문에 유사시 동일한 서버를 바로 생성해서 서비스에 투입할수 있습니다.(아직 그래본적은 없다는...)
DB 서버는 mysql replication을 이용해서 master-slave 구조로 이중화 했습니다. slave는 read only 로 설정해서 통계용 데이터 추출등에도 사용해서 실서비스에 영향을 주지 않고 내부적인 데이터 사용이 가능하도록 했습니다. 그리고 나중에 서비스가 커져서 DB 부하가 문제가 되는 경우 select query는 slave에서 읽도록 하는 등의 방법을 고려해 볼수도 있습니다.
by 치킨연구소 테리야끼
댓글 없음:
댓글 쓰기