웹 서버의 응답은 브라우저나 프록시, CDN 등 모든 계층에 있어서 중요한 값입니다. 특히 컨텐츠가 캐시되어야 하는 경우 혹은 캐시되지 말아야 하는 경우에 대하여 정확한 지시자(Directive)를 내려주지 않으면 잘못된 정보가 캐시되고 다른 사용자들과 공유되어 보안사고나 정보 유출이 있을수도 있고, 엉뚱한 컨텐츠가 캐시되어 제대로된 서비스가 제공되지 못할 수도 있습니다. 따라서, 정확한 헤더와 적절한 지시자를 내려주는 것이 중요합니다.


공개되어 있는 완성된 제품 (예: 워드프레스) 을 이용하는 경우에는 솔루션이 적절한 헤더 값으로 응답을 합니다만 직접 모든 것을 개발한 웹 서버, 웹 서비스라면 필요한 값을 적절히 지정해주어야 합니다. 단순한듯 복잡한 HTTP 헤더의 세계이기에 어떤 값을 어떻게 써야하는지 헷갈릴때가 많은데요 이럴때 도움이 될만한 의사결정차트(?)가 있어서 공유해 봅니다. 


출처 : 구글 개발자 문서 (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)



no-cache 와 no-store 가 항상 헷갈렸었는데요 no-cache 의 경우 Etag 등이 추가적으로 제공되어야 하며 이를 통해 컨텐츠를 "항상" revalidate 하는 작업이 필요하다는 이야기가 있습니다. 다소 복잡하다면 캐시하면 안되는 컨텐츠는 no-store 를 쓰도록 하는 것이 마음이 편할 것 같습니다 ^^ 캐시할 컨텐츠는 Cache-Contro: max-age=xxx 를 사용하되 private, public 중 어떤 추가 디렉티브를 쓸 것인지도 고민해봐야 겠습니다! Etag 는 이 모든 걸 떠나서 가능하면 넣어주는게 CDN, Proxy 를 대비하는 방법이 되겠습니다!


  • # 구글 개발자 문서 : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching


- NoPD -

저작자 표시 비영리
신고
Posted by 노피디
Cloud Tech.2015.10.02 10:45

세계적으로 클라우드 서비스를 제공하는 사업자들은 무척 많습니다. 각 사업자들은 각자의 컨셉과 목표를 가지고 클라우드 서비스를 만들고 제공하고 있는데요 아마존의 AWS, 마이크로소프트의 애져(Azure) 등이 대표적입니다. 아마존의 경우 인프라스트럭쳐(IaaS)에 대한 가상화와 클라우드화를 기치로 내걸고 사업을 시작하여 지속적으로 플랫폼의 영역(PaaS)으로 올라오는 중이며 마이크로소프트의 경우 개발자들이 보다 쉽게 개발된 서비스와 코드를 사용자에게 제공할 수 있도록 플랫폼에서 시작하여 인프라스트럭쳐의 영역으로 내려오는 전략을 가져가고 있습니다.


마이크로소프트는 자사의 제품들을 전반적으로 실물 제품에서 가상의 제품, 클라우드화를 지속적으로 진행하고 있기 때문에 이의 연장선상에서 애져의 시장 전략을 가져가고 있습니다. 엊그제 진행된 애져컨(Azure Con)의 키노트에서 마이크로소프트가 꿈꾸는 클라우드 서비스와 방향성을 볼 수 있는 좋은 내용들이 무척 많이 나왔습니다. 그 중에서도 가장 눈에 띄는 것은 아무래도 컨텐츠 전송 부문에서의 협력을 글로벌 CDN 1위 사업자인 아카마이(Akamai)와 한다는 발표가 아닐까 싶습니다.






키노트 세션이었기 때문에 기존의 CDN 을 유지하면서 아카마이의 글로벌 foot-print 를 활용하는 전략인지 아니면 기존의 협력관계였던 EdgeCast 와의 관계를 청산하고 아카마이를 전면에 내세우는 것인지는 자세히 소개되지 않았습니다. 다만 올해 하반기 까지는 제한적으로 고객들을 선별하여 애져 플랫폼 및 상품들과 아카마이를 통한 CDN 을 구현하는 작업을 진행하는 것으로 보이며 일반 고객들이 쓸 수 있는 GA (General Availability)는 내년 초가 되어야 할 것으로 보입니다.





마이크로소프트와 아카마이는 9월 29일 화요일 나란히 이러한 협력관계가 시작되었음을 알리는 공식 블로그 포스팅을 공개했습니다. 클라우드 환경으로 컴퓨팅 자원을 제공하는 회사들, 그 회사들의 서비스를 이용하는 고객들의 공통적인 고민은 "어떻게 글로벌 엔드유저들에게 전송을 빠르게 할 수 있을 것인가?" 입니다. 컴퓨팅 자원을 여러 리전(Region)에 나누어 서비스 하는 것은 쉬운 접근이겠지만 이들의 관리와 형상 유지, 라스트 마일(Last Mile)구간에서 발생하는 속도 이슈에 대한 해결은 쉽지 않은 문제입니다.


이를 위해서 아마존은 클라우드 프론트(Cloud Front)라는 자체 CDN 서비스를 제공하고 애져는 CDN 사업자와의 제휴를 통해 이를 해결하는 비즈니스 모델을 가지고 있습니다. 어떤 접근이 맞고 틀리는지, 혹은 더 좋고 나쁜지는 상황에 따라 다르겠지만 마이크로소프트 애져가 글로벌 1위 사업자인 아카마이와 제휴하여 서비스를 제공하는 것이 더 나은 모델이지 않나 하는 생각이 듭니다.





저작자 표시 비영리
신고
Posted by 노피디
Cloud Tech.2015.09.15 10:04

대규모의 사용자 트레픽을 소화하기 위해서는 고민해야 할 것들이 많습니다. 서비스 오리진(Origin) 인프라의 유연함과 적절한 스토리지(Storage)을 확보해야 하는 것은 물론이고 갑작스런 사용자 폭주에 대비하여 충분한 대역폭(Bandwidth)도 갖추어야 합니다. 큰 규모의 기업이라면 그나마 이러한 준비를 하기 위한 투자(CapEx)가 가능하겠지만 작은 규모의 기업(SMB, SOHO)이나 스타트업(Start-up)이라면 열악한 인프라를 이용하여 서비스를 시작하는 경우가 많습니다.


하지만 충분한 재원을 이용하여 인프라를 증식(?)하는 방법은 한계가 있습니다. 가장 단적인 예는 "충분한 대역폭" 에서 찾을 수 있습니다. 갑작스런 서비스의 인기몰이나 이슈가 생겼을 때 폭주하는 사용자 트레픽은 그 규모를 가늠하기가 힘듭니다. 또한 일시적으로 발생하는 이런 스파이크(Spike)를 대비한다고 평상시에 이용되지 않는 대역폭을 계약하여 사용하는 것은 운영 비용(OpEx) 관점에서 효과적이지 않습니다. 그렇다면 이런 문제는 어떻게 해결할 수 있는 것일까요?





흔히 컨텐츠 전송 네트워크(Content Delivery Network, CDN)이라 불리우는 서비스들이 그 해답이 될 수 있습니다. 글로벌 1위 사업자인 아카마이(Akamai)를 비롯하여 최근에는 아마존(Amazon)이나 마이크로소프트 애져(Azure) 등 클라우드 서비스들도 필수적으로 CDN 서비스를 제공하고 있습니다. CDN 전문 사업자들 뿐만 아니라 클라우드 인프라를 제공하는 사업자들까지 CDN 상품을 내놓고 있다는 것은 인프라와 전송 네트워크의 조합이 대규모의 사용자 트레픽을 소화하기 위해서 필수라는 의미로 해석해도 크게 틀리지 않다는 이야기입니다.


아카마이는 최근 마이리틀텔레비전의 컨셉으로 마이리틀CDN 이라는 인터렉티브 세션을 운영하고 있습니다. 다음주 화요일인 9월 22일 오후에 한시간동안 CDN 의 기본적인 동작 원리와 어떻게 활용하면 도움이 될지에 대한 프로그램이 방송될 예정이라고 합니다. CDN 서비스를 제공하는 사업자들 별로 저마다의 특징과 차별화 포인트를 가지고 있지만 기저에 깔려 있는 기본적인 스킴은 어느정도 비슷하기 때문에 CDN 에 대한 기본적인 소양을 쌓고 글로벌에서 성공할 미래의 내 서비스를 위해 지식의 폭을 넓힐 수 있는 기회가 될 수 있을거란 생각이 듭니다!


아카마이 마이리틀CDN - "CDN의 원리와 활용 기본" 무료 사전등록 [바로가기]



저작자 표시 비영리
신고
Posted by 노피디
Cloud Tech.2015.09.03 09:34

서비스를 제공하는 사람과 회사는 늘 악의적인 해커의 공격으로부터 서비스 인프라와 사용자들을 지켜야 하는 숙제를 안고 있습니다. 우리 회사의 웹 사이트는 안전한지, 공격이 발생했을 때 어떻게 사용자 정보를 보호할 것인지, 그리고 공격이 지속되는 상황에서 어떻게 서비스를 지속적으로 제공할 수 있도록 할 것인지에 대한 고민을 해야만 합니다. 세계 최대 CDN 공급 사업자인 아카마이(Akamai)는 이런 고민들 중 "지속적인 서비스의 제공" 관점에서 DDoS 공격 발생시 그 여파를 경감시킬 수 있는 보안 사업자를 선택하는 4가지 포인트를 인포그래픽으로 정리하여 공개했습니다.





#1. 위협에 대한 뛰어난 지식을 보유하고 있는가? (Maximal Threat Intelligence)


IT 기술이 발달하는 것과 보조를 맞추어 해커들의 공격 기술도 더욱 정교하게 바뀌고 있습니다. 다양한 계층에서의 공격 (e.g. OSI 7 Layer) 은 물론이고 서비스 인프라의 취약점을 발빠르게 캐치하여 진행하는 공격 등 해커들의 수준이 점점 높아지고 있습니다. 따라서 보안 사업자를 선정함에 있어 이러한 최신의 공격을 잘 이해하고 있는지, 그리고 어떻게 방어해야 할지를 알고 선제적인 조치를 취해줄 수 있는지를 검토해야 한다고 아카마이는 이야기하고 있습니다.





#2. 얼마나 많은 공격을 막아본 경험이 있는가? (Most Front-Line Experience)


음식도 많이 먹어본 사람이 맛집을 잘 찾는 것처럼 해커들의 공격 역시 많이 경험하고 막아본 사업자만이 잘 막을 수 있다는 것은 당연한 사실입니다. 하드웨어 기반의 DDoS 어플라이언스를 도입할때도 늘 중요하게 평가되는 것이 얼마나 많은 기업들이 장비를 도입 했고 사용하고 있는가 입니다. 시대가 클라우드 세상으로 바뀌면서 하드웨어 어플라이언스를 도입하는 것보다는 플랫폼을 이용하면서 플랫폼이 제공하는 방어 도구를 이용하는 경우가 많아지고 있습니다. 아카마이라던가 아마존처럼 글로벌 클라우드 인프라를 운영하는 회사들은 아무래도 이런 부분에서 경험치가 높을 수 밖에 없을 것 같습니다.





#3. 다양한 방법을 이용하여 DDoS 를 경감시킬 수 있는가? (Best Mitigation Capabilities)


해커들의 공격은 매년 규모가 더 커지고 있습니다. 제로데이 취약점을 이용하여 미처 보안 업체들이 패턴 업데이트를 하거나 취약점에 대한 패치가 공급되기 전에 공격이 시작되는 경우도 많습니다. 이런 공격들이 발생했을 때 얼마나 효과적으로 다양한 방법을 이용해서 DDoS 공격을 경감시키고 막을 수 있을 것이냐는 중요한 포인트입니다. 웹 방화벽으로 불리우는 7계층의 WAF 에서부터 IP / TCP 계층에서의 공격 등 다양한 형태의 공격을 대응 하나의 플랫폼으로 대응할 수 있는 기업은 아직 많지 않은 것 같습니다.





#4. DDoS 경감을 위한 인프라의 가용량이 충분한가? (Global Mitigation Capacity)


DDoS 공격이 무서운 것은 서비스 인프라의 자원이 정상적인 서비스를 할 수 없도록 만들기 때문입니다. IT 인프라의 수준이 발달하는 만큼 DDoS 공격의 규모가 커지는 것은 서비스 불가 상태를 만들기 위해 더 많은 공격 자원이 필요하다는 것과 일맥상통하는 부분입니다. 결국 그러한 공격을 받아낼 수 있는 인프라, 플랫폼을 가지고 있지 않은 사업자는 DDoS 에 대한 대비책으로 선택하기는 어려워 보입니다. 순간적으로 수백기가 혹은 테라급의 트레픽이 몰려왔을 때도 문제 없는 플랫폼을 가진 사업자의 선정이 중요한 포인트라 하겠습니다!





서비스를 기획하고 준비하는 단계에서부터 바야흐로 글로벌을 생각해야만 하는 시기입니다. 이는 언제든 대규모의 공격이 발생할 수 있고 이에 대한 대비도 같이 해야한다는 것을 의미합니다. 아카마이, 엣지캐스트, 아마존, 애져 등 많은 클라우드 사업자들은 근래에 보안에 대한 많은 상품과 전략을 발표하고 있습니다. 이는 고객들의 니즈가 보안에 많다는 것을 의미하고 이를 잘 처리할 수 있는 기업이 또 한번의 플랫폼 전쟁의 승자가 될 수 있다는 것을 암시합니다. 여러분의 선택은 어떤 플랫폼인가요...?





저작자 표시 비영리
신고
Posted by 노피디
Cloud Tech.2013.07.22 14:31
가변 비트레이트 스트리밍은 네트워크의 상태 혹은 전송속도등을 기반으로 대역폭이 소화할 수 있는 정도의 고화질(즉, 높은 비트레이트를 가진 소스를 이용하도록)의 부분 컨텐츠를 전송하는 방식을 이야기 한다. 물론 대역폭이 떨어지거나 네트워크 혼잡도가 높아지면서 전송 효율이 떨어지면 낮은 부분 컨텐츠로 변경하여 전송하는 민첩함을 가지고 있기도 하다.

이 같은 가변 전송을 하기 위해서는 가변 전송을 하고자 하는 컨텐츠를 다양한 비트레이트로 인코딩을 하는 과정이 선행 되어야 한다. 고화질의 원본 소스파일은 서비스 하고자 하는 비트레이트의 종류만큼 복수개의 파일로 인코딩이 되어야 하고 가변 스트리밍을 위하여 전체 길이의 파일을 2~10초 단위의 부분 동영상으로 나누어 저장하게 된다. 예를들어 1분짜리 동영상을 3개의 비트레이트로 가변 비트레이트 스트리밍을 한다면 10초 단위로 부분 동영상을 만든다고 할 때, 총 30개의 파일(각 비트레이트 별로 10개씩)로 나누어져야 하는 것이다

 
그렇다면 사용자, 즉 엔드유저는 파일이 이렇게 쪼개져 있다는 것을 어떻게 알 수 있을까? 가변 비트레이트 스트리밍이 시작되는 시점에 사용자의 플레이어는 인코딩된 파일들의 조각 정보가 담겨 있는 메니페스트(Manifest) 파일을 받게 되고 이 파일이 담고 있는 비트레이트의 종류, 부분 파일의 식별 방법에 따라 적절한 파일을 HTTP 로 요청하여 받게된다.

[ 가변 비트레이트 전송 프로토콜의 종류 ]
- MPEG_DASH (Dynamic Adaptive Streaming over HTTP)
- Adobe Dynamic Streaming for Flash (HDS)
- Apple HTTP Adaptive Streaming for iPhone/iPad/STB (HLS)
- Microsoft Smooth Streaming


참고 : http://en.wikipedia.org/wiki/Adaptive_bitrate_streaming

- NoPD - 
저작자 표시
신고
Posted by 노피디
Cloud Tech.2012.03.13 08:49
CDN(Content Delivery Network) 는 그리 오래되지 않았지만 상당히 진부한 느낌을 주는 소재입니다. 아카마이(Akamai), 라임라이트(LimeLight), 씨디네트웍스(CDNetworks)가 전세계 CDN 시장의 대부분을 장악하고 있으며 이 구도가 참 오랫동안 깨지지 않고 있는 시장이기도 합니다. 

네트워크 전송망 자체의 속도가 점점 빨라지고 주고 받는 컨텐츠에 대한 압축이나 경량화 등에 대한 기술적인 진보가 많아지면서 예전에 비해 CDN의 중요성이 상대적으로 덜 중요한게 아니냐는 분들도 많습니다. 하지만 알게 모르게 이런 기술적인 진보의 이면에 CDN이 여전히 자리잡고 있으며 대용량 컨텐츠 전송이 필요한 산업들은 그 규모가 더 커지고 있는 중입니다.

Cloud CDN 과 기존 CDN의 차이는 뭘까?

결론부터 이야기를 하자면 Cloud CDN 과 기존 CDN 의 차이는 없습니다. 스트리밍이던 다운로드던 Cloud 라는 이름이 붙은 CDN 과 그렇지 않은 CDN 의 큰 차이는 분명히 없습니다. 그렇지만 Cloud CDN 은 Cloud 라는 단어가 가지는 여러가지 의미들 중 "Pay As You Go" 의 개념을 탑재(?)했다고 보면 적절하지 않을까 싶습니다.

기존 CDN 들이 대부분 대역폭(Bandwidth) 단위로 약정 계약을 하고 있기 때문에 계약된 대역폭을 다 쓰지 못하더라도 비용을 내야하는 문제가 있었습니다. 또한 대역폭을 초과하는 경우 다음 약정 단위로 증가하기 때문에 비용 증가의 폭이 부담스러울 정도였지요. 하지만 Cloud CDN 은 전송량(Transfer)에 근간하여 과금을 하기 때문에 알차게 비용 지불을 할 수 있는 장점이 있습니다.

고속도로 차선을 임대할 것인가 아니면 톨비만 낼 것인가? (http://www.thestar.com)

 
T cloud biz 의 Cloud CDN
 
국내 기업형 클라우드 시장은 통신사 중심으로 여전히 현재 진행형으로 만들어 지고 있습니다. CDN 도 마찬가지 인데요, 시장에 상품을 먼저 내놓은 것은 KT 입니다. KT 는 ucloud CDN 이라는 상품을 이미 런칭하여 시장에 내놓은 상태입니다. 조금 늦은 듯 하지만 SKT도 Cloud CDN 상품을 어제 출시해서 시장에서 일전을 준비하고 있습니다.


SKT 가 내놓은 Cloud CDN 의 장점 중 하나는 다양한 소스 출처(Origin)를 사용하여 CDN 서비스를 구성할 수 있다는 점일 것 같습니다. 일반적인 서버에 위치한 파일을 Origin 으로 사용할 수 있는 것은 당연하고 아마존의 스토리지 서비스인 S3 에 올려둔 리소스의 버킷(Bucket)을 사용할 수도 있습니다. 거기에 더하여 최근에 출시한 SKT의 S3 호환 스토리지 서비스인 이지스토리지(Easy Storage)의 버킷도 사용할 수 있어 유연함을 보여주고 있습니다.

Cloud CDN 은 어떻게 동작하는 것일까?

Cloud CDN 은 일반 CDN과 구동 원리가 동일합니다. 사용자는 CDN 관리자 화면을 통해서 CDN 을 통해 빠르게 전송하고 싶은 컨텐츠의 위치를 지정합니다. CDN 서버는 등록된 위치에 있는 파일 혹은 버켓의 리소스들을 국내 ISP 별 데이터센터에 위치한 서버(이걸 엣지 서버라 부릅니다)에 복제하게 됩니다.

복제된 각 리소스들은 고유의 CDN URL 을 가지게 되는데요, 이 CDN URL 을 통해 사용자가 접속을 하면 CDN 서버는 사용자의 네트워크, 위치 등을 감안하여 가장 가까운 곳에 위치한 엣지 서버에서 리소스를 이용할 수 있도록 가이드를 해주게 됩니다. 이러한 원리로 CDN 은 사용자에게 빠른 속도로 컨텐츠를 제공할 수 있게 되는 것입니다

http://www.tcloudbiz.com

 
CDN 에 Cloud 라는 글자가 붙는 것에 대한 갑론을박은 참 많습니다. 하지만 Cloud 가 내포한 다양한 의미를 생각해 보면 Cloud 라 이름 붙이는 것도 그리 틀린 개념만은 아닌 것 같습니다. 아마존의 Cloud Front 에서 시작된 클라우드 서비스들의 CDN 전쟁은 이제 제대로 막이 오르는게 아닌가 싶네요~!

 
- NoPD - 
신고
Posted by 노피디

티스토리 툴바