Amazon AWS 를 활용하여 개발을 하는 중입니다.
2013.09.29 03:25
요즘 프로그램에 온라인 로그나 통계 기능들을 집어넣고 있습니다.
그런데 문제는, 제가 서버 관리나 이런걸 무진장 싫어한다는거죠. 그런데 아직 서버 관리자를 별도로 둘 정도의 활용은 아니라서 사람을 뽑을수도 없구요. 더군다나 우리 제품이 팔리는 곳이 좀 월드와이드합니다. 한국 일본 중국이야 원래 하던거고, 거기에 미국, 동남아에도 좀 나가있는데다가, 이젠 멕시코랑 말레이시아에도 지원을 해야 합니다. 이거 다 감안해서 서버를 여러군데 둘수도 없는 노릇이고 말이죠..
결국 Cloud 서비스를 이용하기로 해서, Amazon AWS와 MS Azure 중에 고르다가 그냥 귀찮아서 예전부터 눈팅해온 Amazon으로 하기로 했습니다. MS Azure도 이젠 엄청 좋더군요. 장기적으로 활용시 가격도 더 저렴하다고 하고, mysql 같은 비 MS 계열의 서비스도 지원하구요. 단, REST API에 대한 문서 지원에서 Amazon AWS가 좀더 낫습니다. 아직 둘다 Maria DB는 지원하지 않는군요.
하다보니 참 잘 만들어놨더군요. 처음에 access key를 오타쳐놓고 오류난다고 삽질했지만요. ;;; 원래는 자체적으로 http server를 구현해서 로그 데이터를 받아 처리하도록 만들었는데, 주말에 Queue Service를 이용하는 방식으로 수정하였습니다. 서비스 신청하고 문서 보고 이틀동안 Server, Client를 다 만들수 있을 정도로 쉽네요. 거기다 로드밸런싱이나 Queue 꼬이는 등의 문제는 Amazon이 다 알아서 해줄 것이고, 혹시나 제가 만든 Server에 오류가 생겨 다운되었다 하더라도, Raw 로그는 Amazon의 Queue에 14일간 계속 저장이 됩니다. Queue Service와 EC2 위치를 같은 지역으로 두면, 비용도 0원이네요. (물론 EC2 비용은 내야 하지만요.)
아직은 EC2 서버에서 Polling 방식으로 구현하고 있지만, 향후에는 Amazon SNS 를 이용하여 Push 방식으로 구현도 가능할 거 같습니다. 특정 상황에서는 아이폰으로 실시간 Push를 받을 수 있을테구요. 이참에 NoSQL 쪽도 한번 봐봐야겠어요. 워낙 다양한 서비스를 제공하고 있다보니 여러가지 연계하면 쉽게 쉽게 확장이 가능할거 같습니다. 하다가 실수하면? OS건 DB건 다 날려버리고 클릭질 몇번으로 다시 새로 다 만들면 되니 부담없네요. ㅋㅋㅋ
코멘트 9
-
김강욱
09.29 09:27
-
1) 글쵸 흐흐~ 서버와 서비스를 직접 운영할땐, "혹시 중단되어 있으면 어떡하지?" 라는 생각에 아주 밤잠을 이루질 못하고 폐인이 되더라구요. 1인 관리 체계는 아주 진을 쏙 빼버리더라구요.
2) 제가 만드는게 웹서비스가 아닌지라, 접속주소에는 별 신경을 쓰지 않고 있어요. 그런데 Static IP를 제공해서 연동하는 서비스도 제공하고, AWS 서비스중 DNS 서비스도 있기 때문에, 웹서비스를 운영할 때도 문제는 안될거 같아요.
-
해색주
09.30 00:27
이러한 서비스를 운영하시는데 보안이나 기타 내부 규정과 상충되는 부분은 없나요? 이런 부분만 해결된다면 작은 서비스라도 이런 부분에서 시작했으면 하는데 쉽지가 않네요.
-
보안이라는게 어차피 귀에 걸면 귀걸이고 코에 걸면 코걸이라서요. 전 누가 보안 가지고 계속 딴지를 걸 경우, 서비스나 사업 자체를 그냥 내버려버립니다. 거기에 관여안해요. 누군가 그럴 경우, 그 서비스는 진행하는 동안 영원히 그 사람에게 딴지를 잡히고 약점을 잡힐 겁니다. 잘 되고 그럴거고, 잘 안되도 그럴겁니다. 보안관련 전문가나 몇명 할당해주고 그런 이야기를 하든가...
예를 들면, "우리 서비스에 대한 어떤 정보도 외부에 보관할 수 없다." 라고 정의한다면, 실제로 회사 내에 서버실을 두고 서버를 다 구입하지 않는다면 아무런 서비스도 할 수 없게 되죠. 이런 회사들 많이 봤습니다. 비전문가들이 보안 어쩌고 하면서 툴툴거리는 회사들.
아마존 AWS를 이용한다 친다면, 아마존의 엄청나게 많은 보안 인력이 우리 정보를 지켜줍니다. 오직 걱정해야 할 것은 아마존이 우리 정보를 뺴갈 것을 걱정하는거죠. 하지만 별도로 서버를 운영한다면, 아마존 및 모든 업체들, 그리고 모든 해커들의 공격에도 스스로 대비해야 합니다. 그게 클라우드 서비스를 이용하는 이유중 하나죠.
다른 말로 하자면, 은행에 돈을 넣는 이유중에 하나는, 도둑이 내 집에 들어와도 내 돈을 훔쳐가지 못하는거잖아요. 근데 은행이 내 돈을 꿀꺽 해버릴까봐, 15분이면 열리는 자기 집 열쇠를 더 믿고 집에 현금을 쟁여놓는걸 더 안전하다고 여기고 있다는거죠.
물론 아마존의 서비스를 이용한다고 하더라도 그에 상응하는 방식을 써야죠. 중요한 정보는 암호화해서 저장해야 하구요. 휘발되는 데이터와 저장되는 데이터간에 암호화 수준도 잘 결정을 해야 하고, 그에 따른 프로세서의 규모도 고민을 잘 해야겠죠. 아마존 EC2의 경우 뚫리면 아주 개판 5분 후가 되버리기 때문에, 공개키 기반으로 암호화시켜서 비밀번호를 제공합니다. 즉, 아마존에서도 제 인스턴스의 암호를 모른다는거죠.
엔간한 회사들은, 아마존의 운영으로 보안을 더 배우면 배웠지, 아마존때문에 보안에 문제가 되는 일은 거의 없을겁니다. 다음의 글을 참조하는 것도 좋은 방법이겠지요.
http://www.cloudsec.co.kr/blog.php/?p=250
-
김강욱
09.30 06:32
토달게 없는 정답이네요.
-
왕초보
10.01 02:14
이런 좋은 글은 글로 올라가야지 리플로 있으면 어떻하자는 겁니까 ?
우리가 외주줘서 쓰는 회사들이 이정도 보안 마인드가 되어있으면 불평할 일이 없을텐데.. 이메일에 패스워드가 덜렁 날라오는데 이게 뭐가 문제란 말이냐 라고 하는 IT애들이랑 얘기할려면.. ㄷㄷㄷ
-
조직 내부만을 대상으로 서비스를 하는 서버라면 모를까, 대외 서비스를 위한 서버는 클라우드 서비스를 사용하는 것이 여러모로 유리해보이더군요.
서버 H/W가 죽을까봐 걱정 안 해도 되고, 한번씩 IDC 찾아가서 점검 안해도 되고...
아직 아마존 클라우드나 MS Azure를 살펴보지는 않았는데, 회선 대역폭은 어떨까요?
저희 회사에서 장비를 구입한 고객에게 업데이트나 각종 정보를 제공하는 서버를 물리적인 서버에 구축해서 제공하고 있는데,
가끔 업데이트가 몰리면서 엄청나게 느려질 때가 있어서 고민이 좀 있거든요.
-
국내 고객이 많으시면 아마존보다는 MS, 그보다는 국내의 클라우드 서비스를 이용하시는게 좋을겁니다. 아마존은 서울에 CDN edge만 있어서, 단순 파일 업로드/다운로드만 보면 속도에 한계가 있어요. MS는 한국에도 서버가 있는걸로 알구요. KT 클라우드 서비스가 한국에서는 속도면에서 이득이 있구요.
-
조언 감사드립니다. :-) 정리해서 회사에 건의해봐야죠. ㅎㅎ
1) 저걸 구현해서 한 번 서비스 해보고 싶은데, 솔직히 겁나네요.
서비스가 중단되면 어떡하지? 이럴땐 어떡하지? 저럴땐 어떡하지?
2) 근데, 도메인은 어떻게 연결하나요?
아마존에서 제공하는 이상한 접속주소로 도메인 세팅을 못하겠던데~