728x90

웹 서버의 응답은 브라우저나 프록시, 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 -

728x90
728x90
HTML 기반의 앱이나 하이브리드 앱을 개발하는 동안 공유 스토리지에 대한 요구사항은 상당히 많다고 알려져 있다. HTML5 가 도입되면서 로컬에서 데이터를 샌드박스 형태의 저장공간에 저장할 수 있는 방법이 생겼지만 다양한 장치에서 데이터를 공유해 사용하기에는 별도로 개발해야 하는 코드의 양이 상당히 많을 수 밖에 없었다.

구글의 오픈소스 기반 브라우저 프로젝트이자 구글 크롬의 모태이기도 한 크로미움(Chromuim) 프로젝트에서 최근 이런 니즈를 반영한 듯한 API 를 공개했다. HTML5 로 대동단결하고 있는 상황에서 특정한 플랫폼에서만 사용 가능한 API 를 이야기 한다는 것이 조금 엇박자인 듯 하지만 필요에 따라 이런 API 들이 HTML5 로 통합될 가능성도 있기 때문에 알아둬서 나쁠 것은 없어보인다.


SyncFileSystem API 는 구글 드라이브를 클라우드 기반의 스토리지로 활용하면서 사용자들이 다양한 기기에서 데이터를 동기화 할 수 있는 방법을 제공해 주는 형태이다. 주요 메서드는 4가지 정도로 정의 되어 있는데, 간단히 정리해보면 아래와 같다.

1) 동기화를 위한 파일 시스템 객체 얻기 (requestFileSystem)
2) 클라우드 스토리지 사용 현황 얻기 (getUsageAndQuota)
3) 클라우드 스토리지에 저장된 파일 상태 얻기 (getFIleStatus)
4) 클라우드 스토리지에 저장된 파일 변경 이벤트 얻기 (onFileStatusChanged)

무척 간단하고 사용하기 어렵지 않은 API 이다. 크로미움 환경 전용이라는 현재의 한계가 있긴 하지만 W3C 에 제안해 놓은 파일 API 상의 디렉토리와 파일 부분의 연장선상에 있다고 하니 HTML5 에서 채택될 수 있기를 기대해 볼 수 있을 것 같다. (자세히 살펴보기 : http://www.w3.org/TR/file-system-api/

- NoPD - 
728x90
728x90
프로젝트를 진행하다가 급하게 SMTP 서버를 구축하는 경우가 많습니다. 하지만 SMTP 서버로 사용할 자원이 없거나 다양한 이슈로 운영이 힘든 경우에는 외부의 메일서버를 사용하는 경우가 많습니다. 가장 대표적인 것이 구글에서 제공하는 SMTP 서버입니다. Gmail 계정만 있으면 사용할 수 있고 SSL 통신등도 지원하기 때문에 무척 사랑받고 있습니다.

그런데 Gmail 계정을 이용해서 smtp.gmail.com 을 사용하는 경우 문제가 하나 있습니다. 메일 헤더에 발신자(From)를 아무리 설정해도 인증을 받는 구글 계정으로 발신자가 표시되는 문제점이 바로 그것입니다. 한참동안 구글링을 하면서 해결 방법을 찾아보다가 너무 가까운 곳에서 해답을 찾았습니다. 같은 고민 하시는 개발자 분들을 위해 정리해 봤습니다.


Gmail 에 로그인 하신 다음 설정으로 먼저 들어갑니다. 설정의 여러가지 탭들 중 Accounts and Import 탭으로 이동해서 Send mail as 항목을 수정하는 것이 바로 해결책입니다. 기본적으로 gmail 계정이 등록되어 있는데 하단의 Send mail from another address 를 눌러 사용하는 이메일 계정을 추가해 주면 됩니다.

이메일을 추가한 다음 실제로 살아있는 정상 계정인지 확인을 위해 Verification 메일로 확인 코드를 전달해 줍니다. 해당 코드를 입력함으로써 이메일 추가가 완료됩니다. 이후 smtp.gmail.com 서버를 통해 메일 발송시에 새로 설정한 메일이 발신자로 기록되게 됩니다. 우측에 make default 버튼을 눌러서 꼭 default 로 설정하는 것 잊지 마시구요.

- NoPD -
 
728x90
728x90
최근 클라우드 컴퓨팅이 큰 화두입니다. 구글의 Back-end 시스템이 이미 클라우드로 구동되고 있다는 사실은 너무나 많이 알려진 사실이지요. 국내의 대기업들도 너도나도 클라우드 컴퓨팅에 뛰어 들고 있지만 세계적인 IT 벤더들의 발걸음을 따라가기는 무척 힘든 상황입니다.

마이크로소프트가 클라우드 컴퓨팅에 대응하기 위해서 제공하고 있는 서비스의 이름이 바로 Azure 입니다. Azure 는 웹 서비스로의 Role 뿐만 아니라 일반적인 어플리케이션을 위한 Worker Role 을 제공하고 Storage Service 를 통하여 Back-end 의 데이터베이스 기능까지 충실하게 제공하고 있는 클라우드 플랫폼 입니다.

시대적 흐름에 맞추어 닷넷 개발자 분들도 Azure 에 대응하는 스킬을 익혀둘 필요가 있을 것 같습니다. 저역시 이제 시작하는 단계이지만 Azure 에 올려 서비스 할 수 있는 웹, 워크의 개발을 하나씩 살펴보면서 실제 Azure 환경에 포팅하는 것까지 한번 포스팅을 통해서 공유해 볼까 합니다.

개발환경의 준비 : 비주얼 스튜디오 2010 또는 비주얼 스튜디오 2008 서비스팩 1

비주얼 스튜디오에는 Azure 개발환경이 기본적으로 포함되어 있지 않습니다. 비주얼 스튜디오에서 Azure 개발을 시작하기 위해서는 별도로 제공되는 플러그인을 설치하여 개발환경에 템플릿을 추가해 주어야 합니다. NoPD 는 비주얼 스튜디오 2010 을 사용하고 있으나 비주얼 스튜디오 2008을 쓰시는 분들도 서비스팩 1 으로 업데이트를 하면 동일하게 진행할 수 있습니다.


[ 다운로드 링크 : http://tinyurl.com/2a5qnrt ]

Azure 프로젝트 만들기

Azure Tools 를 다운로드 받아 설치하면 비주얼 스튜디오의 템플릿에 Cloud 라는 항목이 추가 된 것을 확인하실 수 있습니다. Cloud 항목 아래에는 Windows Azure Cloud Service 라는 하나의 템플릿만 존재하고 있습니다. Azure 개발은 Visual C# 으로만 제공하는 것일까요? NoPD 의 경우 Visual C# 만 설치한 상태라 이 부분은 잘 판단이 안됩니다만 다른 닷넷 언어가 안되지는 않을거라 생각됩니다.


프로젝트와 솔루션의 이름을 지정하고 확인을 누르면 아래와 같은 창을 만나게 됩니다. Azure 는 Role 이라는 이름으로 프로젝트를 구분짓고 있습니다. Role 이라는 것은 Azure 클라우드 플랫폼에서 구동되는 하나의 어플리케이션이라고 보면 됩니다. Web 형태의 서비스인지(Web Role) 아니면 데몬과 같은 백그라운드 어플리케이션인지(Worker Role) 등에 따라 Role 이 나뉘게 됩니다. 개발하려는 프로젝트의 성격에 따라 항목을 선택해 주면 됩니다.


우리는 솔루션 단위로 프로젝트를 생성하고 개발하기 때문에 솔루션 안에는 여러가지의 Role 이 있을 수 있습니다. 왼쪽에 나열된 항목들 중 필요한 Role 을 모두 우측의 빈 리스트 박스로 이동시켜 주면 프로젝트에서 해당 Role 을 사용할 수 있게 됩니다.

- NoPD -
728x90

+ Recent posts