IoT 클라우드 레퍼런스 모델



현재 IoT 디바이스들을 지원하는 클라우드 서비스들에는 몇가지 아키텍쳐 유형있다. 이들 아키텍쳐를 구현한 업체들의 실 서비스들은 모두 기술적인 요건이라기 보다는 해당 IoT 클라우드 서비스를 제공하는 업체의 철학과 전략이 반경되었다 할 수 있다. 


하기 내용을 좀 더 이해하기 위해서는 다음 포스팅을 참조해 주세요.


IoT 클라우드 전쟁http://wisefree.tistory.com/406



현재 다음 3가지 IoT 클라우드 구현을 위해 3가지 레퍼런스 모델로 크게 대별할 수 있다.



1) Mobile Device Centric


애플의 IoT 모델이다. 애플은 MFi 규격을 준수하는 디바이스들이 자동으로 iOS(iPhone,iPad)와  연동되도록 한다. 이 때, 지원하는 프로토콜은 BT와 Wifi이다. 


이렇게 연결된 디바이스들은 Healthkit이나 HomeKit , CloudKit 등을 통해 개발된 어플리케이션을 통해 제어된다. 이 때, 발생하는 모든 관련 데이타는 iCloud를 통해 처리된다. 


이 모델의 장점은 사용자들이 기존에 사용하던 모바일 디바이스를 중심으로 각종 디바이스를 통합하고 제어할 수 있다는 것이다. 그리고 서비스 제공자 입장에서는 그 동안 시장에 공급했던 기존 모바일 디바이스의 가치를 극대화할 수 있다는 데 있다. 애플같은 모바일 디바이스 업체 입장에서 가장 매력적인 모델이라 할 수 있다.



2) Pure Cloud Centric


구글의 IoT 모델이다. 사용자는 디바이스들을 연결하기 위해 별도의 디바이스를 필요로 하지 않는다. 사용자는 단지 구글 Nest를 지원하는 디바이스를 구매한 후 이를 On시키면 자동으로 Wifi를 통해 Nest 클라우드에 연결된다.


Nest 클라우드는 Nest 규약을 지원하는 디바이스들의 프로타일을 관리하고 이를 제어하기 위한 API 를 제공하여 다양한 조작이 가능하도록 한다.


이 모델의 장점은 언제 어디서나 Wifi가 지원되는 곳에서 손쉽게 해당  IoT 디바이스를 설치, 사용할 수 있다는 데 있다. 



3) Hybrid


SmartThing 등 신규 IoT전문 업체들이 선호하는 모델이다.  별도의 Hub 디바이스를 통해 디바이스들을 연결한다. 이 때,  Hub 디바이스는 다양한 프로토콜을 통해 디바이스를 연결하고 이 Hub는 외부의 IoT 클라우드와 연결되어 Hub에 연결된 디바이스들을 조작한다. 


실제 , SmartThings 의 경우 SmartThings Hub라는 별도 디바이스를 사용자가 설치하고 지원하는 디바이스를 연결한 후 Hub를 통해 SmartThings 클라우드에 접속하여 관련 디바이스를 조작하게 해준다. 


이 모델의 장점은 다양한 프로토콜을 지원가능한 Hub 통해 리거시 디바이스를 포함한 다양한 디바이스와 연결성이 가능하다는 장점이 있으나 사용자 입장에서 별도의 Hub 디바이스를 구매하고 설치해야 하는 부담이 발생한다.


위의 레퍼런스 모델을 보면 모바일 디바이스 등 직접 디바이스를 제조하는 회사의 경우 기존 모바일 디바이스를 Hub화 함으로써 기존 기득권을 유지하는 것이 가장 유리한 방법이라 할 수 있다. 


그러나 디바이스 제조사가 아닐 경우 비록 모든 디바이스가 Wifi에 연결되는 기능을 내장하고 있어야 하지만 직접 IoT 클라우드에 디바이스가 연결하는 모델이 유리하다 할 수 있다.  


반면에 Hub 모델의 경우 연결성면에서는 장점이 있으나 별도의 장치를 설치해야 하는 번거로움이 있어 과도기적인 접근 방법이라 할 수 있다. 혹자는 리거시 디바이스들을 연결시키위해서는 다양한 리거시 프로토콜을 지원하는 Hub 디바이스가 필요하다 할 지 모르나 사용자는 기존의 장치를 연결하기 위해 고생하는 것 보다 손쉽게 새로운 것을 이용하는 것을 선호한다.  


과거 4년 전 쯤 리거시 디바이스들을 연결해서 새로운 개발 플랫폼을 만들기 위한 제안을 한 적이 있었느데 그 때 많은 사람들이 과거 다 해 봤는데 안되더라 했었는데.. 시간이 흐르면 세상도 기술도 바뀌어 안되던 일도 되는 게 진리인데.. 



   






Posted by 박재현

댓글을 달아 주세요


최근 몇가지 관심있게 보는 몇가지 키워드를 풀어보기 위해 여러 기술 조사를 하던 중에 Ajax Framework들에 대해 벤치마킹을 한 유용한 자료가 있어 소개해 본다.

Ajax Framework은 웹 개발에 있어 필수적으로 사용하는 클라이언트측 프레임웍이다. 따라서 해당 프레임웍의 성능에 따라 클라이언트측 개발에 많은 영향을 미친다. 특히, 최근에 많은 이슈가 되고 있는 Realtime Web과 SOPEA(Service-Oriented Front-End Architecture) 구조의 개발을 위해서는 더욱이 중요하다 할 수 있다.
 
Matt Raible은 그의 블러그에서 주요한 Ajax 프레임웍을  주요한 내부 기준에 따라 실제 테스트하고 해당 결과를 정리하였다.  실제 결과를 떠나 Matt팀이 설정한 주요한 내부 기준도 Ajax 프레임웍을 바라보는 데 많은 도움을 준다. 관심있는 분은 한번씩 눈여겨 봐주면 좋을 것 같다.

결과만 간략히 소개하면 다음과 같다.

- 가중치를 주지 않은 경우 결과 : 거의 대부분의 Ajax 프레임웍이 동일함
사용자 삽입 이미지

- 가중치를 주었을 경우 결과 : GWT win
사용자 삽입 이미지

가중치의 기준은 Matt와 그의 팀 그리고 수행하는 프로젝트에 따라 다를 것이다. 그러나 한번 결정된 프레임웍을 변경하는 것은 아주 어렵기 때문에 많은 고민을 해서 프레임웍을 결정하는 것이 필요할 것이다.

Posted by 박재현

댓글을 달아 주세요


  서비스 플랫폼 구축을 위한 솔루션은?

새벽에 오랜만에 씩씩거리며 자료를 찾아 보고 정리하는 것 같다^-^.

웹 서비스 플랫폼을 구축할 때 여러분은 어떤 솔루션을 사용할 것인가? 상용 제품 또는 오픈소스. 이 두 대안중 하나를 선택할 때 어떤 기준으로 결정할 것인가? 가격,성능, 그리고 기술지원. 언듯 가격과 성능면에서 보면 오픈소스가 구미에 당겨도 실제 오픈소스 솔루션을 사용한다는 것은 쉽지 않은 결정이다. 왜냐하면 그만큼 오픈소스를 효과적으로 다루는 유능한 개발자가 확보돼야 하기 때문이다. 반대로 이야기하면 기술지원의 문제가 발생하기 때문이다. 그러나 찾아보면 의외로 오픈소스 커뮤니티의 집단지성이 기술지원을 해주고 , 오픈소스 컨설팅 회사와 전문가를 쇼셜 네트웍을 통해 쉽게 만날 수 있다.

현재 성공적으로 서비스를 운영하고 있는 서비스들의 구축 솔루션을 조사해 보았다 - 아마존, 구글, 유투브, 플리커 , 트위터. 이들 업체들이 공통적으로 사용하는 솔루션만 뽑아보면 - Linux , Java , Apache , MySQL ,Memcached 등이 자주 애용된다. 사용제품은 아마존의 DB가 오라클을 사용하고 있는데 아마 상품 DB에 사용되고 SimpleDB서비스에는 MySQL이 사용될 것으로 예상된다.

그리고 아마존 웹 서비스의 API 관리를 위해 Jboss를 사용하고 있는 것이 눈에 띠인다. 아마존의 경우 오픈 API만으로 플랫폼 사업을 하기때문에 오픈 API의 관리와 모니터링용으로 Jboss를 소프트웨어 버스로 이용하는 것으로 보인다.

상황이 이 정도면 오픈소스를 채택하는 데 있어 선입관을 가릴 필요가 없어 보인다. 국내 유력 통신사인 S사를 비롯하여 현재 많은 서비스 회사들이 엄청한 구축 및 유지보수 비용을 줄이기 위해 기존 상용 솔루션을 오픈소스로 전환하고 있다고 한다. 어차피 오픈소스가 피할 수 없는 선택이라면 빠른 도입과 준비야 말로 많은 경쟁력을 확보하는 지름길일 것이다.

마지막으로 첨언하면  기업들은 결사적으로 오픈소스 개발자와 엔지니어를 양성하고 이들에게 좋은 대우를 해주는 것이 바로 IT 관련 비용 절감을 이루는 첫번째 길이라는 사실을 기억하는 것이 좋을 것이다.

1. 아마존
Linux
Oracle
C++
Perl
Mason ( 멀티 에이전트 시뮬레이션 라이브러리)
Java
Jboss ( 서비스 버스 )
Servlets

2. 유튜브
Apache
Python
Linux (SuSe) 
MySQL
psyco(python to C 동적 컴파일러)
lighttpd ( 비디오용 ) 

3. 플리커
PHP
MySQL Shards
Memcached (캐쉬)
Squid ( HTML과 이미지를 위한 리버스 프록시 웹 캐쉬)
Linux (RedHat) Smarty
Perl PEAR (XML 과 Email 파싱용)
ImageMagick(이미지 프로세싱용)
Java(노드 서비스용)
Apache SystemImager (Deployment용)
Ganglia ( 분산 시스템 모니터링)
Sucon ( 손쉬운 Deply를 위해 subversion 레파지토리에 필수적인 시스템 설정 파일들을 저장하기 위해 사용)
Cvsup ( 네트웍상의 파일들을 분산하고 업데이트하기 위해 사용)

4. 구글
Linux
Python, Java, C++

5. 트위터(Twitter)
Ruby on Rails
Erlang
MySQL
Mongrel ( 하이브리드 Ruby/C HTTP 서버 - 작고,빠르고,보안에 중점을 둠)
Munin
Nagios
Google Analytics
AWStats( 실시간 로그 분석용 )
Memcached


Posted by 박재현

댓글을 달아 주세요


사용자 삽입 이미지
구글이 구글Gear를 지난 달 31일 발표하고 여러 곳에서 분석 기사들이 나오고 있습니다. 오래전부터 웹 애플릿케이션들의 단점으로 오프라인 지원이 주요한 문제로 지적되었고 이러한 문제 해결을 위한 노력들이 여러 방법들과 단체들을 통해 진행되어 왔습니다. 근본적으로 유웹 애플리케이션에서 오프라인 지원에 대한 문제와 방법에 대해 지적해 왔던 것 같습니다. 구글 Gears 이전에도 이미 Zimbra가 내부에서 자바 DBMS를 내장한 방법으로 오프라인을 지원하고 있고 , 차주 알파 테스트를 마치고 베타 오픈 예정인 씽크프리 웹 오피스의 프리미엄 버전에서  오프라인을 지원하고 있습니다.
   
구글 Gear는 여러 방법중 브라우져 플러그-인 방식으로 SQLite이라는 DBMS를 클라이언트상에 두고 이를 통해 오프라인 상태의 정보를 저장하고 이를 서버측과 온라인 상태에서 교환하는 구조입니다. 현재로서는 당연한 방법이죠. 아무래도 문제는 보안과 데이타 전송량의 최적화 등이 남아 있는 숙제 일 것 입니다.

이러한 오프라인 지원 상황의 이해를 돕기위해 전에 제가 발표한 자료를 하나 포스팅합니다. 자료를 넘기다 보면 오프라인 지원 문제와 현황에 대해 쉽게 이해하실 수 있을 것 입니다.
 


ThinkFree Docs.

Posted by 박재현

댓글을 달아 주세요

  1. Favicon of http://wafe.kr/ BlogIcon wafe 2007.06.09 13:08  댓글주소  수정/삭제  댓글쓰기

    Google Gears에서 사용하는 DB는 SQLite라고 들었습니다만... ^^

  2. Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.06.09 15:32 신고  댓글주소  수정/삭제  댓글쓰기

    네 맞습니다. SQlite죠.. 오타네요^-^Sqlite는 C로 만들어진 파일 시스템위에 SQL 프로세스가 있다고 생각하시면 됩니다. 수정해야 겠네요..


오늘 삼성동에서 열린 web2.0 korea 2007에서 "웹 플랫폼상에서의 애플리케이션 개발,관리"에 대해 발표를 했습니다. 300명이 넘는 분들이 참석하여 오랜만에 후끈한 열기를 느낄 수 있는 자리 였습니다.

사용자 삽입 이미지
포탈 업체에서 부터 웹 에이전시, 그리고 일반 업체의 웹 관련된 분들까지 다양한 곳에서 다양한 연령층의 분들이 모인 자리이고 모두 비싼 컨퍼런스 비용을 내고 참석하시는 분들이라 사실 여간 준비하면서 신경을 부쩍 쓴 컨퍼런스 였습니다. 물론 모든 발표때 마다 고민을 합니다. ^-^ 가급적 실제 실무 개발시 고민해야 할 사안들에 대해 정리해 보았습니다.

웹 플랫폼은 한마디로 웹 브라우져, 웹 서버 기반의 애플리케이션을 개발하여 H/W, OS 등과 무관하게 어디에서나 이용하게 하자는 것 입니다. 이러다 보니 실제 웹 애플리케이션은 웹 서버와 웹 클라이언트의 기술과 제약에 영향을 받습니다.  특히, 웹 브라우져가 더욱 영향이 크다 할 수 있습니다. 실제  그간 웹 브라우져는 단순히 HTML을 서버로 부터 받아와 뷰잉하는 역할이었습니다. 그러나 이러한 소즉적인 기능에서 벗어나 현재 웹 브라우져는 Ajax, DOM ,CSS, Flash, Java Appet 등 다양한 기술을 사용하여 동적인 메뉴 구성와 출력이 가능해졌습니다. 이러한 기술을 효과적으로 사용하기 위해서 7가지 기본 가이드와 아키텍쳐 패턴을 정리해 보았습니다.

1. Dynamic User interface
2. Real time event-driven programming

3. Light weight MVC programming on client side

4. Server is headless & open API serverp

5. Apply the agile web platform

6. Light weight system architecture6. Light weight system architecture

7. Software As A Service(SAAS)

그러나 현재에도 여러 제약들이 존재하고 있습니다.

- Offline 지원
- 대용량 데이타 처리

이러한 문제를 해결하는 방법은 현재로서는 웹 브라우져상에서 사용가능한 스토리지를 활용하는 것 입니다.

현재 웹 브라우져 상에서 이용할 수 있는 스토리지로는 Flash의 Local storage , IE의 userData behavior, FF의 DomStorage 등이 있습니다. 그러나 이들 스토리지는 작게는 1M에서 최대 10M 이상은 지원되지 않습니다.

따라서 이들 저장공간을 효과적으로 이용하기 위한 방법이 필요합니다. 씽크프리에서는 과거 DOS 시절에 많은 워드 프로세서 들이 사용했던 방법을 도입하여 이를 해결하였습니다. 과거 기본 메모리가 640K에 확장 메모리가 2M가 채 되지 않던 시절, 어떻게 10M가 넘는 파일을 편집하고 처리할 수 있을까요? 바로 여기에 아키텍쳐 그리고 운영체제 등의 기술이 필요합니다.

자세한 내용은 제 강의 자료를 참조해 주십시요.


제가 강조하고 싶은 부분은 사회를 이해하기 위해 역사를 공부하듯 아무리 현재가 웹 플랫폼 시대이지만 과거 DOS나 터미널 서버 시절의 기술들도 이해해야 하며 특히, 애플리케이션의 구조와 그에 따른 장.단점 들은 잘 파악하고 있어야 한다는 사실입니다.

저는 코더와 개발자는 다르다고 생각합니다. 코더는 말 그래로 주어진 스펙에 맞춰 코딩을 하는 사람이고 개발자는 주어진 문제를 풀기위해 최적화된 방법을 찾고 이를 해결해 나가는 사람이라고 생각합니다. 간혹 사람들이 이런 말을 합니다. "사람은 많은 데 쓸만한 사람은 없다." 현재 상황이 이런 것 같습니다. "코더는 많은 데 쓸만한 코더(개발자)가 없다." 모두 코더가 아니라 개발자가 되길 기원합니다.
 
저는 Web2.0이니 Enterprise2.0 이나 하는 것이 다분히  마케팅적이고 비지니스적인 욕구에 의해 만들어진 것임을 잘 이해 합니다. 물론 이러한 것들이 없는 것을 만들어 낸 것은 아닙니다. 그러나 좀 걱정스러운 것은 기본과 본질을 이해하려는 노력없이 유행만을 추구한다면 결국 이를 따라가다 지치게 될 것이라는 사실입니다.

이 짓을 오래하다 보니 돌고도는 기술을 보면서 느끼는 것을 주절주절 정리해 보았습니다. 저는 내일 제주도에 한국 커머스넷 춘계 Conference에 패널로 참가를 합니다. 모처럼 생각도 정리할 겸 그곳에 아는 지인들도 만날 겸 좋은 자리가 될 것 같읍니다.



 




Posted by 박재현

댓글을 달아 주세요

  1. Favicon of https://taoism.tistory.com BlogIcon 타오 2007.03.29 23:35 신고  댓글주소  수정/삭제  댓글쓰기

    발표하시느라 수고하셨어요^^ 글 잘보고 있습니다~

  2. 박재현 2007.03.30 17:51  댓글주소  수정/삭제  댓글쓰기

    별말을...수고

  3. 철이 2007.04.10 13:21  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘~ 읽고 가네요~