System Compleat.

'옛날과 지금'에 해당되는 글 1건

  1. 웹 서비스의 해외 진출 시 고려 사항 (2)

웹 서비스의 해외 진출 시 고려 사항

Techs


(younjin.jeong@gmail.com, 정윤진) 

최근 풍요로운 모바일 및 웹 시장을 바탕으로 글로벌 진출 시도를 하는 기업 및 서비스가 많아지고 있다. 이들 서비스 중 일부는 국내에서의 성공을 바탕으로 누적된 자본을 사용하여 진출 시도를 하려는 경우와, 기획 초기 단계부터 애초에 국내 시장만을 대상으로 하지 않고 글로벌 서비스를 준비하는 경우 등 서비스의 종류에 따라 그 사례가 다양하게 존재한다. 서비스가 성공한다는 가정 하에 국내에서만 성공했을 때와 글로벌에서 성공 했을 때의 매출 규모는 상식적인 수준에서 당연히 글로벌이 훨씬 유리 할 수 밖에 없다. 

Image from: http://www.technologyreview.com/photoessay/511791/smartphones-are-eating-the-world/


하지만 지난날의 글로벌 서비스를 위해서는 수많은 자본의 투자가 필요해야 했다. 이는 당연히 서비스 종류별로 사전에 염두해 두어야 할 서비스 대상 지역의 관련 법규를 기반으로 한 적절한 구성과 e-commerce 비지니스와 같은 경우 물류를 위한 창고 및 배송을 위한 현지 업체들과의 파이프 라인 등 쉽사리 엄두가 나지 않는 것들, 그리고 진행하려면 a부터 z 까지 모두 비용이 소요되는 그래서 큰 규모의 기업들만이 시도 할 수 있었던 것이 당연시 되었다. 

이들 중 일부 사항들은 현재 전산으로 대체 할 수 있으며 이 대체를 위해 글로벌 지향의 서비스를 사용하게 되면 상당한 비용을 절약 할 수 있다. 오늘의 포스팅은 바로 어떠한 부분을 염두해 두어야 하는지, 또 보다 좋은 고객 경험과 초기 인프라 자원 투자 비용을 어떻게 줄일 수 있는지에 대한 내용을 중점으로 한다. 물론, 여기에 소개되는 내용을 즉각 사업에 반영하여 초래되는 위험을 바라고 쓰는 글이 아니므로 하나의 의견 정도로 찬찬히 살펴보면 어떨까 한다. 

Image from: http://www.welovedates.com/blog/2013/06/how-to-flirt-on-instagram/


최근의 거의 대부분의 글로벌 비지니스는 웹을 기반으로 한다. 웹의 특성상 서비스 대상 지역에서 네트워크 적으로 가까운 곳에 위치 할 수록 빠른 응답시간을 보장 받으며 이로 인해 고객이 물건을 구매하거나 게임을 즐기거나 또는 컨텐츠를 감상하는데 있어 보다 좋은 서비스 품질을 경험 할 가능성을 높일 수 있다. 당연히 필자가 EMS 나 Paypal 과 같은 배송 결재 시스템 및 서비스에 대한 전문가가 아니라 인프라 관련 업을 하는 사람이므로 이 인프라에 대한 논의를 주축으로 삼도록 한다. 


글로벌 서비스를 시작하겠다고 결심하면 인프라를 준비하는데 보통 다음의 세가지 방법 중 하나를 선택하게 된다. 

1. 사업 대상 지역에 설비 구축 
2. 기존 영업관계 및 이미 사이트가 구축 되어 있는 국내의 데이터 센터와 ISP 를 사용 
3. 글로벌 public cloud 사업자를 이용 



이 세가지 방법은 당연하게도 다음과 같은 부가적 요소가 따르게 된다. 

a. 1번의 방법은 시간과 비용 그리고 인력의 소모가 최대가 된다. 따라서 구현을 위한 비용(시간포함), 즉 투자 비용이 상당하다. 
b. 2번의 방법은 1번 보다는 저렴 할 수 있지만 네트워크 지연으로 인한 서비스 품질이 문제가 된다. 따라서 고객의 서비스 경험 수준이 낮을 가능성이 높다. 
c. 3번의 방법은 학습해야 할 내용이 많다. 아울러 사업자간 어떤 서비스를 제공 하는지 확인이 필요하기도 하다. 



국내 굴지의 대기업인 경우라면 모르되, 보통 b와 c의 방법을 고려하게 되는 경우가 대다수라 할 수 있다. 일반적인 웹 형태의 서비스인 경우를 기준으로, 결정을 위해서 필요한 1차적인 주요 선택지는 다음과 같은 내용이 될 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 
2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 
3. 데이터베이스 및 스토리지 비용 



이를 조금 더 해부 해 보면, 다음과 같은 리스트를 얻을 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 

- CDN 서비스 제공 여부
- CDN 서비스 제공 지역 및 가격
- CDN 서비스 약정 또는 그와 유사한 계약 필요 여부
- 데이터 트래픽 발생 비용
- 각 지역에 인접한 DNS 서비스 제공 여부
- DNS 서비스에서 제공하는 기능 - 예외 상황 발생시 서비스 운용에 대한 제어권 확득 방법  


2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 

- 미주, 유럽, 아시아등 지역에서 리소스 준비 시간 
- 서비스 유입 증가로 인한 새로운 리소스 조달 시간 
- 서비스 유입 하락으로 인한 기존 리소스 감축 및 이에 따른 비용 
- 과금의 단위에 따른 비용 절감 방안 존재 여부 
- 별도의 운영 인력 필요 여부 
- 로드 밸런서와 같은 부가 기능 지원 여부 


3. 데이터베이스 및 스토리지 비용 

- 지원하는 데이터베이스의 종류 
- 각 데이터베이스의 가격 
- 데이터베이스 백업, 복구, 확장에 대한 지원 범위 
- 저장 가능한 스토리지의 크기 (확장)
- 데이터베이스 및 스토리지 준비에 필요한 시간 


4. 기타요소 

- 캐시 서비스 
- 검색 서비스
- 데이터 마이닝을 위한 서비스 
- 로그의 장기 보관을 위한 서비스 


일반적으로 대부분의 웹 서비스는 다음과 같은 과정으로 컨텐츠를 공급한다. 

DNS query > Page access > Get contents from ...

Image from: http://en.wikipedia.org/wiki/Domain_Name_System


따라서 1차적으로 만약 네임서버 서비스가 한국에 존재하는 경우 모든 글로벌 사용자는 한국으로의 트래픽 유입이 필요하다. 아니, 모든 사용자라 하는 경우에는 어폐가 있으므로 글로벌 각 지역의 recursive 로 동작하는 사용자 네임서버들은 모두 최초 1회는 한국에 위치한 네임서버로의 lookup 이 필요하다. 만약 여기에 짧은 서비스 downtime 을 위해 도메인에 대한 TTL 을 낮게 설정한 경우라면, 한국의 네임서버를 hit 하게 될 빈도는 더욱 높아지게 된다. 

이 말은 즉, 해외에 위치한 사용자가 페이지 접속 이전에 도메인 조회를 위해 상당한 시간을 허비해야 하는 것을 의미하며 여기에 낭비된 시간 만큼 첫 페이지에 대한 접속 시간은 증가하게 된다. 최근에는 이 첫 페이지에 들어가는 도메인이 1개인 경우가 매우 드문데, 별도의 reverse-proxy 를 사용하여 도메인을 통일한 경우가 아니라면 대부분 컨텐츠 전송을 위한 별도의 static 과 같은 추가 도메인을 사용하는 경우가 대부분이며 역시 이 도메인이 많을 수록 사용자는 지연을 경험하게 될 가능성이 높아진다. 

이것은 일반적인 상황이며, 만약 많은 사람이 걱정하는 한국의 국제망 트래픽의 포화 또는 이와 준하는 장애 상황이 발생하는 경우는 어떨까. 이러한 경우에는 조금 더 상황이 심각해져, DNS lookup 에 timeout 이 발생 할 가능성이 높아진다. 이 말은 곧 도메인 조회가 불가능한 상황을 말하며 도메인 조회가 불가능하다는 것은 아예 사이트에 접근이 불가능 해 진다는 말이 된다. 

아무리 사이트를 고객과 가까운 해외에 직접 구축하게 되더라도 네임서버가 한국에 있다면 이것은 상당한 지연시간을 야기하며 짧은 TTL 을 가지도록 설계 한 경우라면 더욱 더 크리티컬한 상황을 만들 수 있게 된다. 


결론적으로 글로벌 서비스를 위해서는 적어도 각 사용자에 가까운 지역에서 마치 CDN 처럼 DNS anycast 와 같은 방법을 통해 가장 근거리에 있는 네임서버 질의를 제공하는 서비스를 사용 할 필요가 있으며, 이는 서비스에 대한 사용자 지연시간을 줄이는 가장 첫 걸음이 될 것이다. 


Image from: http://blog.mailermailer.com/behind-the-scenes/improve-your-newsletter-reading-experience-with-faster-images


두번째로는 페이지에 접근하는 시간 및 페이지 정보 즉, html 을 구성하는데 필요한 서버에 대한 접근 또는 index.html 및 .js .jpg 와 같은 컨텐츠의 직접 전송이 얼마나 빠를 것인가 하는 부분이다. 당연하게 네트워크라는 것은 결국 위성을 제외하면 대륙과 대륙을 연결하는데 광섬유 케이블이나 구리선을 사용하게 마련이며 이 선의 길이가 길면 길수록, 거쳐가는 네트워크 장치가 많으면 많을수록 지연시간이 증가한다. 

이로인해 우리는 일반적으로 CDN 이라는 서비스를 사용하게 되는데, 고객과 가까이 있는 서버에 이런 컨텐츠를 캐싱 해 두고 그 서버로 고객을 유도 함으로서 보다 빠른 서비스 경험을 갖도록 하는 것이다. 고객과 가까운 지역의 위치 판별에는 다양한 방법이 사용되는데, 기본적으로는 IP 기반의 지리적 위치에 근거 하거나 고객이 사용하는 브라우저의 언어, 네트워크 기술로는 geocast 와 같은 방법이 사용되곤 한다. http://en.wikipedia.org/wiki/Geocast  

이 CDN 서비스를 사용함으로서 얻어지는 효용은 상당히 많으며 이미 오랜 기간에 걸쳐 검증되었기 때문에 별도의 추가 설명은 필요가 없지만, 중요한 것은 가격이다. 대부분의 CDN 서비스는 사전 계약을 필수로 하며, 필요한 때에 원하는 지역에 사용하기 위해서는 소정의 제약 조건이 필요한 경우가 대부분이다. 이 제약 조건들은 마치 약정과 같이 계약과 사용량에 대한 고정이 필요한 경우가 대부분이므로 사전에 잘 알아보고 적용하는 것이 필요하다. 




세번째로 데이터의 처리와 전송에 대한 부분이다. 이 부분이 바로 성능과 비용을 결정하는 지점이 된다. 이 부분은 기존의 인프라를 운용하며 적용 해 왔던 컨셉과 클라우드를 도입하게 되는 경우 고려해야 하는 컨셉이 상충되는 지점이기도 하다. 왜 그런지는 다음의 흐름을 생각 해 보도록 하자. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html


1. 기존 데이터 센터에 서버를 구축 하는 경우: 결과적으로 필요 수량 이상의 자원을 투입하는 것이 risk 및 무정지 운영에 중요 

- 사용자 유입량을 예측 + 20% 정도의 마진을 적용 하여 필요 리소스 규모 산정. 스펙, 수량 등 
- 서비스 증설 시점을 마크. 이 마크 지점에 도달하면 필요한 리소스를 추가 구매, 증설 
- 서비스에 대한 폭발적 요구 증가 대비 불가 - 하드웨어 배송, 국내 최소 3주  해외 최소 1.5개월 이상 
- 서비스에 대한 유입량이 기대에 못미치는 경우 투자비용 회수가 거의 불가능 
- 상당한 투자비용, 서비스 성공 또는 실패 하더라도 현재와 같은 모바일 중심의 폭발적 트래픽 증가에는 손실이 예상 

하지만 서비스의 성공/실패는 아무도 예측 불가능하며, 이 말은 즉 유입 트래픽에 대해 예측 하는 것 자체가 어불 성설이 된다. 
예측을 하는것이 불가능 하다면 초기 투자 비용을 넣는 것이 무의미 하며, 유입된 사용자 만큼의 비용을 지불하는 구조가 더욱 매력적일 수 있다는 개념을 정립하는 것이 필요하다. 

만약, 필요한 서버가 5분이면 조달 되고, 업그레이드 역시 10분내에 가능하며 다 쓰고 나면 렌트카 처럼 반납 할 수 있는 서비스가 있다면 어떨까. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html



2. 글로벌 public cloud 사업자를 사용하는 경우: 

- 필요한 서버를 5분내에 조달 할 수 있으므로 트래픽 유입이 증가하게 되면 그저 필요한 수량 만큼 늘리면 된다. (scale-out) 
- 필요 없으면 반납이 가능하므로 트래픽 유입이 줄어들면 필요 없는 수량만큼 줄이면 된다. (scale-in) 
- 사용한 서버의 "시간" 만큼만 지불하면 된다. 
- 서비스 사용량의 폭발적인 증가시 유입량에 따른 유연한 응대가 가능하다. 
- 서비스가 실패하게 되면 모두 종료하여 비용을 더 이상 지불 하지 않는다. 
- 사용한 만큼 지불한다는 말은 사용하기 전에는 낼 돈이 없다는 말과 같다. 즉, 투자비용이 없다. 
- 원하는 지역에 수시간 내로 동일한 형태로 배포가 가능하다. 


국내/국외를 막론하고 사업을 추진하기 위해서는 "예산"을 편성해야 하므로 2번의 방법은 종전의 업무 방식과 맞지 않는다. 하지만 이성적으로 생각해 보면 전기세와 같은 가변적인 금액을 기업에서는 지금도 처리하고 있다. 전화비, 전기세, 수도세 및 기타 가변적인 금액들. 기본적으로 사용한 만큼 지불하는 구조를 가질 수 있는 인프라에 대한 지불 구조를 도입하게 되면 종전의 예측 불가능한 것에 대한 억지 예측을 통해 모자르거나 부족한 부분이 발생할 여지를 없앨 수 있으므로 기업입장에서는 비용 관리에 매우 효율적이다. 

요새 사장님 타고다니실 의전 차량을 누가 구매하나. 리스하지. 



성능에 있어서는, scale-up 은 언제나 한계가 있다. 아무리 대기업이라도 수퍼돔이나 크레이를 들이는 것은 쉬운 의사결정도 아니거니와 비용도 만만치 않다. 최근의 서비스 전체 성능 개선은 '분산' 에서 이루어 지는 것이며, 서비스의 각 구성요소를 얼마나 잘 분산 했느냐에 따라 효과적인 장애 대응과 높은 수준의 서비스 성능을 구가 할 수 있는 것이다. 아울러 여기에 분산이 고정된 수량으로 획일적이지 않고, 유입량에 따라 그 크기를 조절 할 수 있다면 또 이렇게 조절하는 것이 비용과 직결되어 있다는 것을 인지 하는 순간 수퍼돔을 사용 할 서비스는 줄어든다. 




하여, 국내 기존 사업자와 global cloud 서비스 공급자간의 의사 결정 사항에서의 결론은 이제 다음과 같다. 

a. 두가지의 개념을 각각 적재 적소에 적용 했을때 과연 어떤것이 저렴하냐. 
b. 각 클라우드 서비스 공급자 중 그러면 어떤 서비스를 사용해야 할 것이냐. - 종량제를 하면서 성능 좋고 서비스 많은 공급자? 



서비스를 운용할 때 경험은 정말로 매우 중요하다. 경험있는 개발자와 기술자는 없어서는 안될 매우 중요한 자원이며 이들은 서비스에 지대한 공헌을 해 왔다. 하지만 최근에는 이들의 경험이 오히려 기업의 비용 절감에 방해가 되는 경우를 적지 않게 본다. 어쩌면, 어떤 기업은 이러한 비용을 절감해야 할 필요가 없을지도 모른다. 누군가는 이런 흐름이 필요없는 공부를 만들어 내고 종전에 지키고 있던 자리를 위협하고 있다고 느낄지도 모르겠다. 하지만 새로운 것에 대한 배척 보다는 이를 받아 들이고, 기존의 것과 대비하여 어떤 부분이 좋고 나쁜지를 판단하되 올바른 척도를 가지는 것이 중요하다고 생각한다. 경험을 새로운 것을 배우는데 사용하고, 그를 통해 더 나는 경험을 재창조 하는 것. 

이미 수많은 스타트업은 위의 내용에 대해 너무나 잘 알고 있으며, 글로벌을 향한 도전의 중심에 있다. 간혹 해외 서비스라 사용을 못하겠다거나 하는 이상한 애국심을 만나곤 하는데, 그럼 Linux 나 Windows, BSD, Oracle, 또 기타 다양한 하드웨어 벤더들은 왜 사용한다는 말인가. 그런 소리 할거면 커널 개발 트리에 공헌이라도 좀 하던가... 


길게 썼지만 어쨌든 핵심은 국내에서도 저렴한 비용으로 시작된 좋은 아이디어가 인스타그램이나 페이스북, 트위터 같은 서비스로 성장 하는 것이 아닌가 한다. 성공의 발판으로 삼는 도구는, 무조건 나에게 좋은 것이어야 하기 때문에 위에 길게 써놓은 흐름을 기준으로 여러분에게도 좋은 것이 무엇인지를 생각 해 보면 좋겠다. 그를 통해 대박나는 서비스가 사방에서 봇물 터지듯 터지기를 바라마지 않으며. 




Image from: http://www.businessweek.com/articles/2013-01-11/a-distributed-denial-of-service-attack-isnt-an-act-of-civil-disobedience



다 써놓고 보니 뭔가 산으로 간 것 같은 느낌. 

(>ㅇ_ㅇ)> 

(younjin.jeong@gmail.com, 정윤진)