RSS

카테고리 보관물: 클라우드

무료 https/ssl인증서 startssl 소개

최근에 kt를 사직하고, 작은 스타트업에 합류해서,  웹 서비스를 하나 개발하고 있습니다. 작은 회사다 보니 모든 것을 개발자가 해야하는 특권을 누릴 수 있어 좋습니다. ^^

지난 주에는 ssl인증서를 구매해야 하는데, railscasts에서 소개해준 무료 ssl인증서를 제공하는 startssl를 이용해봤습니다. 후기를 적습니다.

요약:

  1. 무료 ssl 구매 방법 소개
  2. 약 2일 정도 시간이 걸렸음.

startssl.com 은 이스라엘 회사로 웹사이트 인증에 많이 쓰이는 ssl인증서 뿐만 아니라 이메일 보안을 위한 인증서도 발급하는 인증으로 먹고 사는 회사입니다.

startssl.com 홈페이지

startssl.com 홈페이지

 

보통 http로 접속해서 인터넷 사이트를 이용하는데, 인터넷의 모든 정보는 저 멀리 어딘가에 떨어져 있는 웹서버를 통해서 우리 브라우저까지 전해지는데요. 이 데이터가 평문으로 전송됩니다. 이말은 누군가 가로챌 경우에 그 내용이 무엇인지 다 알 수 있다는 것입니다. 보안으로 취약한 것이죠. 특히나 우리가 회원 인증을 위해서 암호를 입력하는데 ******* 이런 식으로 브라우저에 표시되지만 네트워크로 전송될 때는 평문으로 누가 보면 암호를 알아 낼 수 있게 됩니다. 그래서 https 라는 보안 프로토콜을 사용하는 데 이 때 ssl 인증서가 필요합니다.

SSL에 대한 소개 영상 (한글)

생활코딩에서 설명하는 SSL과 https

위 영상을 보면 이해가 될 것 입니다만, 요약하면, 인증서는 공인인증서 같이 이 인증서의 주인이 누구다란 것으로 인증해주고, 웹서버 주인인 서비스 공급자가 자기가 보내는 웹사이트 정보를 암호화 시켜서 보내면, 브라우저에서는 이 웹사이트 주인의 인증서를 인증기관에 조회해서 그 사람의 공개키를 가지고 주인이 암호화한 것을 복호화 시켜 읽게 됩니다.

그런데, 이 인증서를 발급해주고 누군가 이 사이트 주인이 확실하냐라고 물었을 때, ‘그렇다 혹은 아니다’ 이야기 해줄 수 있는 인증기관이 필요한데, ssl인증 기관이 무료로 해주진 않고 소정을 수수료를 받고 1년간 인증해주는 식으로 운영되고 있습니다. 공인인증서 갱신시 돈을 내고 하는 인증서와 같습니다.

그런데 가격이 정해진 것이 아니고 업체마다 다양합니다. 약 100불 정도에 형성되어 있는데, 무료로 제공해주는 startssl.com 같은 독특한 회사도 있습니다.

싼게 비지떡 아니냐하는 반신반의로 시작했고, 이틀에 걸쳐서 인증을 받게 됩니다. 나쁘지 않습니다. 무료 ssl은 StartSSL Free 상품입니다.

철차는 다음과 같습니다.

  1. startssl.com 에 접속해서 내 이메일을 인증 받는다. (이메일 등록하면 메일로 해시키가 전송되고 그럴로 인증함)
  2. 인증하는 과정에서 내 브라우저에 인증서가 설치되고 이것으로 이후 로그인을 하게 됨. (id/pw방식이 아님)
  3. 로그인 후에, 내가 ssl인증을 받고자 하는 domain name을 내가 소유하고 있는지 확인하는 절차를 진행함. domain name owner에게 메일로 해시키를 보내고 그걸 받아서 입력하면 인증됨.
  4. 인증된 domain name을 선택하고 시키는 대로 진행하면 개인키를 생성하고 그에 맞는 인증서를 생성해주는데, 이 때 서브 도메인을 하나 정할 수 있는데, 기본적으로 1차 도메인 즉, example.com 은 ssl인증이 되기 때문에, 2차(서브) 도메인으로 http://www.example.com 을 추가해주거나 api.example.com 중에 하나를 선택하면 될 것이다. 요즘은 웹사이트와 오픈API도 ssl로 서비스하는 경우가 많으므로 웹사이트는 example.com 으로 api서비스는 api.example.com 으로 제공하면 괜찮을 것 같다.

이 방식을 진행할 때, 한번에 쭈욱되는 것은 아닙니다. 이메인 인증하거나 도메인 인증을 할 때에 6시간 정도씩 대기가 필요한 경우가 있으니 적용을 위해서 이틀 정도 시간을 두고 진행하세요.

하나 더 관심이 있을 것 같은데요. 2차 도메인을 여러개 쓸 수 있도록 허용해주는 *.example.com (wild cards) ssl 인증서를 받으려면 StartSSL verified 를 구입하세요. 60불 정도 합니다.

Happy Coding 😉

 

 

Advertisements
 
댓글 3개

게시자: 켬 2014년 5월 28일 in 클라우드, OpenAPI, Uncategorized, web server

 

태그: , , ,

BaaS가 제공하는 가치

SaaS, IaaS, PaaS 등의 “as a service”로 끝나는 용어가 IT 필드의 사람들에게는 그다지 낯선 단어는 아닙니다. 하지만 ‘그게 뭔가요?’ 물어보면 어떻게 대답해야 할 지 당황스럽기도 한 단어이기도 합니다. 제 나름의 이해로 정리해보자면 다음과 같습니다.

  • SaaS (software as a service) 서비스로 소프트웨어를 ‘제공’한다는 의미는, 우리 웹 어플리케이션을 브라우저로 접속해서 소프트웨어를 사용하도록 서비스합니다는 것이죠. on demand software, asp 같은 것들이죠.
  • IaaS (infra as a service) 인프라는 IT인프라로 서버, 스토리지, 네트워크 등 ‘물리적’인 자원들을 서비스 형태로 제공하니, 그걸 직접 사서 “소유하지말고 이용하라”는 이야기네요. 아마존 AWS나 KT uCloudBiz 같은 게 이런 콘셉이 되겠습니다.
  • PaaS (platform as a service) 여기서 말하는 플랫폼은 Java VM이나 Ruby VM 같은 특정 소프트웨어 동작하기 위한 실행환경(runtime)을 가리키는 것 같네요. 소프트웨어를 개발할 때 소스코드의 저장소만 건내주면 서비스화 된 플랫폼이 그걸 가져가서 컴파일하고 빌드해서 실행까지 해주겠다는 의미로 보입니다. 예를 들면 구글의 app engine이나 heroku 같은 서비스가 이런 류인 것 같습니다.

간단할 뿐만 아니라 자의적인 개념 정리라서 수긍가지 않는 분들도 있겠습니다. 댓글로 의견 주시면 공부에 도움이 되겠습니다. 🙂

오늘 이야기 하려는 주제는 위 세가지 단어와 생김새가 비슷한 BaaS입니다. Backend as a service라고 풀어 쓰며 backend라는 것은 frontend라는 말과 대칭되는 개념입니다. 그럼 front와 back 어떻게 구분될까요? 그건 서비스를 제공받는 사용자입장에서 눈에 보여지는 면이 frontend이고 그 내부에 감춰진 것이 backend라고 보면 될 것 같아요. 예로 쉽게 전달하자면, 웹사이트를 생각해보면, html과 javascript, image같은 것으로 유저들의 웹브라우저에 보여지는 부분이 frontend이고 눈에 보이지 않는 웹서버, 어플리케이션서버, 데이터베이스 등은 backend 겠지요.

여기까지 읽으신 분들은 아마 “클라이언트-서버”라는 개념에서 클라이언트가 frontend고 서버가 backend라고 봐도 되는지 궁금하실 겁니다. 맞습니다. 그렇게 보면 될 것 같습니다. iOS나 android 앱을 개발한다고 칩시다. 그럼 이 단말에 들어가는 앱은 frontend 기술로 만들어 집니다. 하지만 iOS에서 로그인하거나 사진을 업로드하면 그걸 받아서 처리해주는 부분이 바로 backend 영역이고 java나 c#, php, python, ruby등 다양한 개발 환경이 존재합니다.

‘그래, 그럼 backend는 좀 알겠다. 눈에 안보이는 서버 쪽 프로그램들이란 말이지?’ 네 맞습니다. 이런 backend 프로그램을 ‘서비스’로 제공하겠다는 것이 바로 BaaS입니다. backend를 ‘소유’하지 말고 ‘사용’하라는 메시지가 담겨있는 것이죠. 소유하지 말고 사용하라는 말은 as a service 사업모델의 기저에 깔려있는 철학같은 것입니다. 이 말은 소유의 종말로 번역된 Jeremy Rifkin의 저서 ‘The Age of Access’의 주제와 맥을 같이 합니다. “서비스 제공자가 모두 준비해 두었으니 접속해서 사용하시면 됩니다.” 이게 BaaS사업자들이 돈벌기 위해 제공하는 ‘가치 제안’입니다.

그러면, 이런 backend 기능들이 뭐가 있는지 구체적으로 들어가 볼까합니다. 우리동네 착한 가게를 추천해주는 모바일 앱을 하나 만든다고 해봅시다. 그러면 만들어야 할 사용자 스토리를 생각해보면

  • 사용자는 우리 동네에서 착한 가게 목록을 볼 수 있어야 한다.
  • 로그인한 사용자는 우리 동네의 착한 가게를 등록할 수 있다.
  • 로그인한 사용자는 우리 동네 착한 가게에 대해서 평가를 할 수 있다.
  • 로그인한 사용자는 착한 가게에 체크인할 수 있다.
  • 관리자는 불량사용자들의 사용을 제한 할 수 있다.

이런 사용자 스토리가 있다고 가정해보면, 단말에서 처리할 부분이 있는 반면 서버에서 처리해줘야 할 내용들이 있습니다. 느슨하게 구분해보면 이렇게도 가능하겠지요.

  • 단말
    • 단말의 현 위치를 기준으로 서버에 착한 가게 목록을 요청한다.
    • 사용자들에게 로그인 정보를 받아서 서버에 요청한다.
    • 착한 가게 사진을 찍어서 서버로 업로드 요청한다.
    • 착한 가게에 체크인 정보를 서버로 요청한다.
  • 서버
    • 로그인 정보를 받아 합당한 유저인지 판단하여 로그인 성공여부를 알려준다.
    • 관리자인이 일반 사용자인 지 판단하여 권한을 제한한다.
    • 회원가입한다.
    • 특정 위경도 주변에 있는 POI 목록을 보내준다.
    • 업로딩 된 사진을 파일 저장소에 저장한다.
    • 체크인 정보를 DB에 저장한다

실제 상황에서는 이 보다 훨씬 다양한 내용들이 있을 수 있겠지만 이 정도로 정리하고 진도를 나가보겠습니다. 서버에 해당하는 스토리를 처리하기 위해서는 backend 프로그램을 개발해야 하는데, 보통 웹 개발자, 서버개발자들이 담당하게 됩니다. backend 개발에 소요되는 비용은 일반적으로 frontend 개발에 드는 비용을 훨씬 상회하지요. 유저의 증가에 따른 확장성까지 고려한다면 이 비용은 더욱 가파르게 상승하게 됩니다.

BaaS가 해결하고자 하는 것은 무엇일까요? 바로 위에서 말한 backend 개발 비용을 획기적으로 줄여보자 것이지요. backend 서버 로직 중에 공통으로 많이 쓰이는 것들이 뭐가 있을까요? 다음과 같은 것이 떠오르는 군요.

  • 회원관리
  • push notification
  • 클라우드 기반의 파일 시스템

이 외에도 더 많이 생각해볼 수 있겠습니다. BaaS가 이런 backend 기능을 모아서 비교적 쉽게 frontend에서 사용할 수 있는 API와 SDK를 제공한다면, 단말개발자들은 서버 개발자 없이도 풍부한 기능의 앱을 만들 수 있지 않을까요? 서버 개발자들도 매번 똑같은 바퀴를 새로 만들 필요 없이, 서비스별 차별화 요소에 더욱 집중할 수 있는 여유를 만들 수 있겠습니다.

parse.com website

parse.com website

parse.com 이라는 구글 출신의 엔지니어들이 만든 BaaS업체가 있습니다. 다양한 기능을 제공하고 SDK까지 제공하고 있기 때문에, iOS/Android 개발자라면 누구나 쉽게 push메시지를 보낼 수 있고, 간단한 key-value 형태의 데이터를 서버에 저장할 수 있으며, 파일을 공유할 수 있게 되었습니다. 이런 API 사용에 초반에는 비용이 없습니다. 무료로 시작할 수 있고, 특정 사용량을 넘어서게 될 때에 비로소 과금하게 되는데, 이 역시 쓴 만큼만 비용을 내는 합리적인 가격체계를 갖추고 있습니다.

BaaS는 단말 개발자들에게 서버개발자 없이도 멋진 앱을 만들 수 있는 자유를 줬습니다. UX/UI에 더욱 집중하고 나머지 뒷단의 일은 BaaS에게 맡기세요. 게다가 서비스가 어느 정도 커져서 시장에 반응이 나타날 때까지 무료로 해볼 수 있다는 점이 무척 매력적이네요.

국내에서도 이러한 BaaS서비스를 준비하고 있는 업체들이 있습니다. 이들에 대한 이야기는 다음 포스팅에서 이야기 해보겠습니다.

baas.io

baas.io

최피디 드림

 

 
댓글 21개

게시자: 켬 2012년 8월 16일 in BaaS

 

GAE용 python2.5 설치하기

OSX 사용자들에게는 이미 python이 설치되어 있는데 그 버전이 2.6.x입니다.  구글 앱엔진의 python runtime 2.5.x와 차이가 있어서, urllib같은 모듈을 사용할 때 ctype 모듈을 가져올 수 없다는 에러를 보신분이 계실겁니다. 그럼 내 맥북에도 2.5를 설치할 동기는 충분해졌다고 봐야겠죠?

어떻게 설치하는게 가장 빠른가 하면, macports입니다. mac port는 BSD계열의 유닉스에서 패키지를 아주 쉽게 설치할 수 있도록 해주는 유틸인데요. 리눅스의  yum, apt-get같은 것이라 보시면 됩니다. 맥포트가 기본으로 깔려 있지 않기 떄문에 설치를 해줘야 합니다. macport사용을 위해서는 개발툴인 Xcode가 깔려 있어야 합니다. 앱스 개발자분들이라면 이미 깔려있으리라 예상되니 pass! (ptyhon 문법이더군요)

설치방법은 정말 간단합니다.

sudo port install python25

이 한 줄이면 설치됩니다. 설치는 /usr/bin/ 아래에 되었군요. 그런데 terminal 에서 python이라고 치면 2.6x가 뜹니다. 아마도 관련 심볼릭 링크 때문인가보네요. 단순히 python 링크만 바꿔주는게 아니라 library도 2.6 이 아닌 2.5로 바꿔줘야 하는데 이것들이 귀찮습니다. 이때 쓰려고 python_select란 유틸이 있습니다. 이것도 macport를 써서 쉽게 설치할 수 있습니다.

sudo port install python_select

설치되었다면 실행시켜야지요~!

python_select python25

이제 python을 실행시키면 2.5.x가 뜹니다. (올레~!)

하지만 appengine launcher를 실행시켜서 앱스를 실행해봐도 여전히 2.6.x의 라이브러리를 참조하는 듯 에러를 내고 있습니다. 이럴 때는 appengine laucher의 preferences에서 Python Path:를 /usr/bin/python2.5 로 바꿔주고 리스타트 하면 해결됩니다.

이게 2.5.x 환경의 appengine 테스트 환경이 구성되었습니다.

즐프하세요~!

최피디 드림

 
댓글 남기기

게시자: 켬 2011년 4월 18일 in AppEngine, OSX, Python

 

태그: , , ,

Google App Engine 사용 후기

gae icon

구글 앱엔진으로 프로젝트 하나를 마쳤습니다.

간단한 이미지 콘텐츠 관리서버와 API를 앱엔진에서 구성하고, 아이폰에서 해당 API를 호출하여 이미지를 보여주는 형태의 서비스입니다.

처음으로 앱엔진을 이용해봤지만 간단한 후기를 적어 보고자 에어를 펼쳤습니다. 혹시 누군가에게 도움이 되길 바라며, 유리병에 넣고 바다에 던져보는 거지요. 🙂

처음 앱엔진을 접했던 것은 2008년 12월쯤 아이폰 앱스를 개발하면서 cocos2d라는 라이브러리를 이용할 때였습니다. 거기 글로벌 랭킹를 관리해주는 아이가 바로 앱엔진이었던 것이였죠. 벌써 2년이 훌쩍 넘었군요. 좀 더 호기심을 가지고 들여다 봤다면 클라우드를 먼저 접해볼 수 있었겠지만 그리 못했습니다. 아쉬움이 많이 남습니다.

2년사이에 간간히 앱엔진으로 뭔가를 해봐야겠다는 생각 뿐이었고 실행에 옮기지 못했습니다. 그 사이에 저는 전업 앱개발자가 되어가고 있었지요. 이전에 하던 서버쪽 개발은 별로 흥미를 끌지 못했던 시기였습니다. 전업 앱개발자로서 SNS를 개발해보고 나서 API서버의 역할과 앱과의 통신에 대해서 이해하게 되었지요.

그래서 개인 프로젝트에 적용해보기로 맘먹었고, 그래서 머리 속 기억 저편의 앱엔진을 다시 전두엽으로 불러냈습니다. 😉

2년이란 시간이 지나는 동안 앱엔진은 자바 런타임을 도입했다는 것 외에는 큰 변화가 없었습니다. 하지만 관련해서 사용자들의 리뷰는 넘쳐나고 있었지요. 이들의 리뷰와 간증 덕분에 쉽게 이것을 해보자는 결정과 함께 착수했습니다.

약 2달간의 짬짬이 공부가 시작된 셈입니다. 꾸준하진 못했지만 토요일마다 카페에서 앱엔진을 배우기 위해서 이런저런 코딩을 해보고 실제로 서비스를 구현해봤습니다.

결론적으로 서비스는 파이썬 기반의 앱엔진으로 구현이 되었습니다.

구현하기까지 삽질한 순서를 회고해보면,

1. 초기 샘플 코드 재구현해보기 (방명록 구현하기)
2. 사진 올리고 보여주기 구현
3. data model 구현
4. json출력하기 구현
5. 관리자 페이지 작성
6. API 페이지 작성
7. Memcache 적용

이렇게 꼽을 수 있겠네요.

이 정도로 앱엔진의 모든 기능을 써봤다고 말하기는 많이 부족하지만, 간단한 RESTful 웹서비스 구현은 할 수 있겠구나는 확신이 생기더군요. 각 단계에서 느꼈던 소회를 불어보려고 합니다.

1. 초기 샘플를 따라서 구현

앱엔진의 초기 화면에서 삐적 마른 아저씨가 보여주는 동영상을 몇 번 보면서 따라했습니다. 모방을 충분히 해보니까 이 동네가 어떻게 돌아가는 지 조금 알 거 같더군요. 이 방명록 샘플에 필요한 모든 게 다 들어있다고 해도 되겠습니다. webapp framework를 사용하여 request 처리하는 방법과 처리 결과를 django를 이용해서 response하는 방법 datastore Model를 만드는 방법 이것만으로도 기본적인 웹서비스를 만들기 위한 기초는 놓여졌다고 봐야겠더군요.

2. 사진 업로드하고 보여주기

사진데이터는 BLOB로 datastore에 저장됩니다. 마치 테이블의 한 필드에 저장되는 것 처럼 말이죠. BLOB처리도 매우 간단히 처리가 되더군요. 그런데 그 이미지를 보기 위한 핸들러가 필요했습니다. 각 이미지가 들어있는 row에 대해서 key값으로 blob데이터를 불러와서 이미지로 Content-Type를 이미지로 설정해서 뿌려주니 잘 되네요. 이것도 모두 앱엔진 문서화에 포함되어 있습니다.

3. Model 설계

데이터 모델을 서비스에 맞게 디자인하고 테이블을 설계하듯이 파이썬 클래스를 db.Model를 상속받아 만들면 모델이 만들어집니다. 그 모델을 get(), put(), delete()이런 메소드를 사용할 수 있게 됩니다.

4. json으로 출력하기

django.utils에 simplejson모듈을 그냥 가져와 쓰면 되더군요. 오히려 파이썬의 dictionary와 list에 대응하는 {}, [] 표기법이 익숙치가 않아서 조금 햇갈렸습니다만 곧 이해가 되었습니다. 아울러 json의 구조상 reculsion으로 구현해야하는 부분에서 살짝 고민스러웠는데 다른 사람들이 해놓은 패턴을 따라해서 곧 해결했습니다. 그럴듯한 json를 리턴해주는 API도 구현이 끝났습니다.

5. 관리자 페이지

사실 관리자 페이지에서 콘텐츠를 입력하기 때문에 초반부터 작업이 되었습니다만 효과적인 구현이 어려웠습니다. 관련해서 찾아보니 앱엔진의 Model을 기준으로 자동으로 admin페이지를 구성해주는 appengine-admin프로젝트가 있더군요. 그것을 이용하면 어땠을까 아쉬움이 남았습니다.

6. API 구현

이제 아이폰 앱스와 앱엔진 사이의 API를 구현했습니다. json으로 쉽게 만들 수 있어 쉽게 구현했습니다. 이때 Model사이의 join개념을 사용하기 위해서 ReferenceProperty를 사용하여 최종적으로는 tree형태의 자료구조가 json으로 출력되도록 했습니다. 뭔가 무거운 느낌이 들었지만 그냥 잘 작동 되는 것 같아(?) 넘어갔습니다.

7. Memcache 적용

API를 호출하면서 본격적인 테스트에 들어갔는데, 이상하게도 좀 무거운 API를 호출하면 앱엔진 어드민 콘솔에서 로그에 빨간색으로 경고가 떴습니다. cpu사용과 api호출이 과하다는 경고였습니다. 몇 번 사용하지 않았는데도 cpu가 쿼터의 90%에 육박하는 것이었죠. 실 서비스로 간다면 쿼터를 넘어서 서비스가 불가능했겠지요. 결국 같은 내용을 리턴해주는 쿼리를 매번 할 필요없이 특정 시간동안은 memcache에 저장한 다음 그것을 리턴해주는 방식으로 cpu와 api호출 과부하 문제를 해결했지요.

아직 앱 승인전이고 실 서비스가 진행됨에 따라 예기치 못한 문제가 발생할 수 있겠습니다. 그렇게 경험한 뒤에 그 경험을 나눌 것을 약속드립니다. 🙂

글을 마무리 하면서, 앱엔진은 독립 앱스 개발자들에게 날개를 달아주는 서비스라고 생각합니다. 클라우드 세상은 이미 도래했고 서로 나를 이용해달라고 아우성입니다. 앱엔진을 공부하는 동안 AWS(아마존 웹 서비스)에도 급 관심이 생기더군요. 특히 대용량 저장을 위한 S3는 먼저 써보고 싶어질 정도였죠. 앱스 개발자 여러분 클라우드에 도전해보십시오. 막연한 두려움 가질 필요가 없어요. 해보면 별거 없습니다.  주저하고 있다면 저질러보십시오. 이년전에 제가 주저하다가 말아버린 걸 후회하는 전철을 밟지 마시길 당부드립니다.

최피디 드림.

 

태그: , , , , , , ,

GAE에서 db키를 못 찾을 때 처리 방법

Google AppEngine으로 뭘 하나 만들고 있다.
db.get(aKeyString) 이런 식으로 가져와서 키를 가지고 해당 row를 가져올 수 있는데, 문제는 invalid 키가 왔을 때 어떻게 처리해줘야할지 헤매고 있다가 검색으로 답을 찾았다. http://www.paulcarvill.com/2010/06/how-to-handle-a-python-badkeyerror-exception-in-google-appengine/ 에서 알려준 방법은 다음과 같다.

articles = Article.all()

try:
	issue = db.get(self.request.get("issue_id"))
	if (issue):
		articles.filter("issue =", issue)
	
except db.BadKeyError:
	result = {}
	result["func"] = "getArticle"
	result["result"] = False
	result["errorMsg"] = "invalid issue id"
	self.response.out.write(json.dumps(result))
	return
 
댓글 남기기

게시자: 켬 2011년 3월 29일 in AppEngine