최근 Drone(이후 드론) 관련 산업이 매우 활발하다. 새삼 수년전부터 FPV다, Hobbyking 이다 해서 포스팅 했던 것이 웬지 번져나가고 있는것 같아서 기분이 묘하다. 뭐 어쨌든 드론 관련 산업이라면 가장 앞서있는 군사 부분 부터, 의료, 과학, 정찰, 탐색, 물류, 농업등 셀 수 없을만큼 다양한 분야로 번져나가고 있다.
사실 나는 멀티콥터 보다는 비행기를 선호하는 편인데, 이유는 멀티콥터보다 운용시간이 길고, 항속 거리가 길고 그 제어가 비교적 간단한데다가 적재가능한 물량이 더 많기 때문이다. 뭐 작은 소망이라면 현용 항공 관제 및 운용 시스템을 비행기 드론에 맞게 구현하고, 이를 물류센터간 운송에 써보면 어떨까 하는 생각적인 느낌만.
어쨌든 오늘은 드론 관련 산업에서, 드론을 가지고 하는 사업도 있고 그에 반하는 모델도 있지 않을까 해서 생각을 해 보던중, 누가 우리집 마당에 드론을 날리면 어떻게 하나 하는 생각에서 출발한다. 뭔가 배달을 하는 반가운 아마존 드론이 아니라면, 다른 사람이 카메라를 달아서 날리고 있는 드론이 우리집을 기웃거린다면 매우 기분이 나쁜 일일 것이다. 따라서 우리집 마당 안에 들어온 (또는 아파트 베란다, 창문 등에 얼씬 거리는) 하늘에 떠 있는 드론을 떨구는 장치가 있다면 꽤 팔리지 않을까 (물론 미래에)
하늘에 떠있는 추적하는 방법은 여러가지가 있을 수 있는데, 가장 기본적으로 레이더의 원리를 운용하는 방법도 있고 카메라를 달았다면 분명이 드론에서 흘러나오는 시그널의 위치를 포착하는 방법이 있을수도 있겠다.
위의 영상에서 왼쪽의 보드와 Directional 안테나는 드론으로 부터 신호가 가장 강하게 나오는 위치를 검색한다. 그러면 오른쪽에 있는 안테나는 해당 드론으로 부터 신호를 가장 잘 받기 위해 드론 방향으로 다른 Directional 안테나의 위치를 조정한다. 여기서 오른쪽 안테나의 역할을 이걸로 바꾸면 어떨까.
현재는 보면 거의 대부분 아두이노와 서보 모터를 사용한 기본 트래킹 정도를 구현하고 있는 듯 하다. 오히려, 센트리가 어떻게 대상을 인지할 것인지 등에 대한 알고리즘을 공부하는 용도로 많이 사용되는 듯. 이걸 조금 더 빠른 프로세서가 달린 Raspberry PI 와 더 부드러운 브러시리스 모터나 스테핑 모터를 달면 더 빠르고 정교한 움직임을 만드는 것이 가능할 것 같다. 3D 프린터도 유행하는 시대니까 트레이를 만드는 것도 재미있을 듯. BB탄 쏘는 에어건 대신 EMP 쇼크나 적절한 출력의 레이저를 쏘는 방법도.
세상이 바뀌면서, 나라에만 영공이 있는게 아니라 각 개인 가정에도 영공이라는 개념이 생길 시대가 오고 있는것 같다. 오픈 하드웨어 기술과 이에 따른 다양한 센서, 그리고 부품등의 발전은 지당한 것이며, 개인의 프라이버시 보호 역시 중요한 개념이므로 아마도 CCTV 와 같은 피동적 시스템 보다는 센트리와 같은 보다 능동적 시스템을 요구하는 시대가 오지 않을까 한다.
회사의 공식 블로그 계정을 얻었는데, 아무래도 거기는 정식 교육을 다 마친후에 포스팅을 하는것이 좋을 것 같아서 일단 여기에. Pivotal 에 입사한 이후에 회사가 가진 다양한 제품에 대해 이리저리 살펴보다 보니, 이 PaaS 라고 불리는 물건이 꽤나 재미있어서 포스팅을 한번.
Pivotal 이라는데가 사실 제법 꽤 유명한 회사인데, 아직 잘 모르시는 개발자 분들을 많이 만남.
1. Pivotal Labs 라고 불리는 Software 컨설팅 조직. 고객의 개발자와 모니터를 함께 보며 나란히 앉아 합의한 scope 에 따라 8주 - 12주 정도로 개발을 함께 한다. 이를통해 고객은 빠른 속도로 소프트웨어를 개발하는 방법을 습득 가능.
2. PaaS. 다양한 클라우드 인프라 기반 위에서 쉽게 코드를 푸시하여 다양한 서비스와 함께 동작시킬 수 있는 서비스. Cloud Foundry 라 불리우는 플랫폼과 그 외의 Pivotal 이 지원하는 다양한 소프트웨어를 함께 구동하고, 서비스에 반영할 수 있다. 로컬 데이터센터 및 퍼블릭 클라우드, 프라이빗 클라우드 모두에서 동작이 가능.
3. 빅데이터 관련 제품들. 제법 유명한 Greenplum 과 HAWQ, Pivotal Hadoop 등이 있다. Big Data Suite (BDS) 라 불리우는 패키지로 존재하기도.
위의 세가지는, 빠르게 소프트웨어를 개발하는 플랫폼으로 PaaS 를 사용하고 -> 이를 통해서 얻어지는 로그 및 다양한 데이터를 분석해서 -> 다시 어플리케이션에 반영하는 구조에 최적화 되어 있다. 만약 IT 를 전문으로 하는 회사가 아니라면 Labs 과 함께 실제 어플리케이션 개발을 진행해 봄으로서 경험을 체득하는 형태로 구성된다.
- Gemfire : 이게 제법 엄청난 물건. 글로벌 레벨로 동기화가 가능한 인-메모리 NoSQL : http://pivotal.io/big-data/pivotal-gemfire
- Pivotal Hadoop
- Cassandra with Datasax
- Riak CS, S3 compatible storage
- MongDB
- Neo4j
- Jenkins
- Mobile 관련 : Data sync, App Gateway, Push Notifications, App Distribution
이것들은 모두 Pivotal 의 Cloud Foundry 라 불리는 PaaS 안에서 서비스의 형태로 자연스럽게 연동되며, 여기에 없는 서비스라도 service broker 라는 메커니즘을 통해 외부의 서비스와 연동이 가능하다. 따라서 개발자는 원하는 서비스를 입맛에 맞게 선택하고 이를 코드로 작성하여 바로 배포하여 사용할 수 있는, 그것도 우리 회사의 데이터센터와 AWS, 이후에는 Azure 및 GCE 등에도 코드 변경없이 그대로 푸시가 가능하다는 점.
Pivotal 은 역시 또 그 자체로 다양한 오픈소스의 공헌자이기도 하다. 아래는 Pivotal 이 씨게 지원하고 있는 OSS 리스트.
HP나 IBM의 PaaS 관련 제품들이 Cloud Foundry 기반이라는 것은 이미 널리 알려진 사실. 그리고 이 오픈 소스 버전의 Cloud Foundry 에 commit 되는 code 의 90% 이상이 Pivotal 에서 나온다는 점. 그리고 그 오픈소스에 대한 지원과 사용의 편의성을 구현한 것이 바로 Pivotal Cloud Foundry.
만약 VMware 기반의 vCenter 환경이 있거나, AWS에 계정이 있거나, 또는 OpenStack 을 구성했다면 Pivotal CF 를 다운받아서 설치해 볼 수 있다. 관련 제품의 다운로드는 https://network.pivotal.io/ 에서.
아니 그래서 그게 뭔데 라고 아직도 궁금해 하시는 분들을 위해 설명을 조금 보태자면.
코드는 일반적으로 어떤 서비스를 사용하느냐에 따라 종속성을 가지게 되는데, 이는 클라우드 서비스 공급자 별로 제공하는 SDK 는 물론이거니와 코드 내에서도 어떤 WAS 를 사용하는가, 또는 어떤 캐시클러스터를 사용하는가에 따라 어떠한 환경에 종속적이게 된다. 이러한 제약은 이전에는 뭐 그래, 우리가 그런 소프트웨어와 인프라를 구매 했으니까 라고 생각 될 수 있겠지만, 클라우드 시대에는 각 퍼블릭 클라우드가 제공하는 가격에 따라, 그리고 지역적인 요건, 네트워크의 성능등 다양한 사업 요구 조건에 따라 어플리케이션을 배포하고 구동할 수 있어야 한다는 것. 그러나 이럴때마다 매번 각 환경에 맞도록 코드를 다시 써야한다면 엄청난 수고가 아닐 수 없다.
단순히 멀티클라우드에 대한 요구 사항 뿐만 아니라, 작성된 코드의 동작 여부를 빠르게 확인하고, 이를 prod / stag / dev 환경의 변화에 따른 코드 변화 없이 바로 서비스에 반영할 수 있다는 장점을 얻을 수 있는것.
이 모든것은 '스피드'와 연관이 있으며, 개발이 빨라질 수록 사업의 혁신도 빨라진다는 이야기.
한가지 더 추가 하자면, Cloud Foundry 에 배포되는 앱은 컨테이너 기반이라는 것. - 재밌겠쥬?
아래는 PCF 의 화면. run.pivotal.io
그리고 이것은 AWS에 설치한 PCF.
Cloud Foundry 에 대한 더 쉬운 설명은... 흠.
"On-premise 와 AWS, GCE, Azure, OpenStack, VMware 를 지원하는 확장된 Heroku"
클라우드에 관심이 있으신 분이라면 한번쯤은 들어보셨을 법한 Cloud Foundry 의 한국 Community 를 만들어 보고자 합니다.
국내에서는 Spring Framework 이 매우 유명하고, 많이들 사용하시는 것으로 알고 있습니다만 그 Spring framework 을 만든 회사가 Pivotal 이라는 사실을 아시는 분은 많이 없으신 것 같더라구요. :)
Pivotal 의 경우, Spring framework 및 기타 다양한 Open source 에 기여하고 있으며 또한 소프트웨어 업계에서 유명한 컨설팅/외주 업체인 Pivotal Labs, 그리고 Big data 관련 제품을 담당하고 있는 Big data suite, 마지막으로 이번에 조직중인 Cloud Foundry 의 크게 세가지 제품을 주력으로 한국 고객들을 뵙고 있습니다. http://pivotal.io
Cloud Foundry 는 PaaS 서비스로서, 현존하는 다양한 퍼블릭/프라이빗 클라우드를 Platform level 에서 묶을 수 있는 강력한 도구 입니다. 백문이 불여 일견, 아래의 이미지로 대신 할게요.
아무튼 OSS Cloud Foundry 및 Pivotal Cloud Foundry 모두에 관심이 있으신 분들, 그리고 기존의 퍼블릭, 하이브리드, 엔터프라이즈 비지니스 등에 관심 있으신 많은 분들의 연락을 기다리고 있겠습니다. 물론 인프라 하시는 분들 뿐만 아니라 개발하시는 분들께도 좋은 내용을 많이 소개해 드릴 수 있을 것 같네요.
가격은 기절하게 비싼 수준은 아니므로, 뭔가 글로벌 레벨에서의 통신 단말을 생각하고 있다면 꽤 괜찮은 솔루션이 될 지도. 이걸 가지고 무엇을 할 수 있을까 고민을 아무리 때려봐도 나는 맨날 드론만 생각이나 응? 이 아니고 기상 관측이라던가, 산악 또는 오지에서 뭔가 응급적인 느낌이라던가 지구 반대편에 있는 무언가에 커맨드를 때리고 싶다던가 하면 생각 할 수 있을법한 장치. 물론 솔라셀 같은 솔루션과 덧붙이면 좋은 그림이 나올지도.
그럼 node.js 만 돌릴 수 있나요 하면 그것은 아니고, 64비트 리눅스 환경에서 동작 할 수 있도록 static 하게 컴파일된 바이너리 또는 external library 를 사용하는 경우에도 함깨 packing 해서 업르도 해 주면 동작할 수 있다. 단, 이 경우에도 trigger 는 node.js 가 되어야 하기 때문에, 이렇게 올라간 바이너리는 child_process 와 같은 도구로 spawn 을 하면 된다. Process 및 thread 를 사용하는 것이 가능하달까. http://aws.amazon.com/lambda/faqs/
어쨌든 preview 권한을 획득하면 다음과 같은 화면에 접근이 가능하다.
화면 왼쪽은 이벤트를 통해 Lambda 에 전달할 json 을 보여준다. 오른쪽의 경우에는 이 이벤트를 통해 트리거될 함수이며, 양쪽 모두 브라우저에서 직접 코드의 수정이 가능하다. 그 아래 보이는 화면은 함수를 invoke 한 경우 그 실행 결과로 출력되는 console output 을 보여주며, 이는 나중에 CloudWatch 를 통해 log stream 으로 확인이 가능하겠다.
왼쪽의 event 로 함수에 전달된는 json 은 S3 / Kinesis / DynamoDB stream 의 템플릿을 확인 할 수 있고, 원한다면 custom template 을 만들어서 전달하는것도 가능하다. 따라서 만약 S3에 어떤 파일이 업로드 된 경우, putObject 가 완료되면 lambda 로 이벤트가 전달되고, 이때 전달되는 json 에는 bucket 의 이름, key 와 같은 정보들이 함께 전달되어 thumbnail 을 생성한다던가 DynamoDB 의 table 에 link 를 업데이트한다던가 하는 동작을 수행 할 수 있겠다.
위에서 설명했듯이 이러한 동작을 node.js 로 할 수 있도록 했지만, 이를 반드시 node.js 로 할 필요는 없기 때문에 여기에 요새 유행하는 Go 를 사용해 보면 어떨까나. AWS에서 Golang 에 대한 SDK 를 정식 배포하고 있지는 않지만, 다음의 링크에서 남이 만들어 놓은 것을 거져 먹을수 참조해 볼 수 있곘다. https://github.com/mitchellh/goamz 일단 땡큐.
여기까지 생각하고 보니 이런 생각을 과연 나만했을까 하는 의심이 들어서 검색질을 했더니 얼씨구나 역시나.
로그를 확인하려면 "Execution results" 부분의 Click here 를 통해 CloudWatch log stream 으로 이동하면 된다.
그럼 compile 된 Go 코드가 수행되면서 argv[1] 로 받은 event json 이 예쁘게 print 되어 있는 모습을 확인 할 수 있다.
Lambda 는 Function 에 할당하는 메모리의 크기에 따라 코드를 수행하는 플랫폼의 성능이 달라진다고 볼 수 있겠다. 아래의 간단한 uname -a 정보를 통해 Linux 64bit, C코드던 뭐던 좌우당간에 native code 도 동작시킬 수 있다고 보면 될 듯.