AWS Greengrass Lamdba

IoT는 현재 일어나고 있는 일들을 알 수 있는 기술

 

AWS IoT Core : 디바이스가 연결되고 메시지들을 받고 메시지를 보내는 역할, 들어온 메시지를 AWS 백엔드에 라우팅해주는 역할

 

AWS Greengrass : IoT를 디바이스까지 확장하고 생성된 데이터를 로컬에서 처리할 수 있다.

데이터들이 클라우드 AWS 사이트로 갈 필요가 없다->지연속도를 줄일 수 있음

데이터를 로컬에서 저장하고 로컬에서 처리할 수 있다

 

사물과 사물 사이에 메시지를 모으거나(aggregation) 메시지 일부를 필터링해서 클라우드까지 보내서 분석을 해야하거나 외부 데이터와 견주해보아서 인사이트(결과)를 얻어야하는 경우에 사용

 

∴ AWS에서 나온 소프트웨어 설치 배포본

 

메세지 브로커 : publisher(송신자)로부터 전달받은 메시지를 subcriber(수신자)에게 전달해주는 중간 역할, 응용 소프트웨어 간에 메시지를 교환 할 수 있게 해준다. 메시지가 적재되는 공간이 message queue이고 메시지의 그룹을 topic이라고 한다.

예를 들어 A와 B라는 서버가 있을 때, A는 실시간으로 데이터를 수집하고 관리하는 서버이고, B는 데이터를 가공하여 사용하는 서버라고 하자. B에서 A에 있는 데이터를 사용하기 위해서는 어떻게 해야할까?

일반적으로 A에 오라클, mysql같은 데이터베이스를 적재하고 B에서 이 db를 조회해서 쓰는 것인데, 실시간으로 처리하기 위해서는 적합하지 않다.

그래서 메세지 브로커를 사용해 A에서 수집한 데이터를 바로 메세지 큐에 publish(출판, 적재)하고 B는 메시지를 subcribe(구독, 소비)하여 바로 사용하게 된다. B에서 별도의 조회과정 없이, 메시지 큐에 적재되는 메시지를 감시하고 있다가 메시지가 적재되면 바로 가져다가 사용할 수 있다.

- 그린그래스는 설치되는 요소가 라즈베리파이나 pc급 이상 디바이스에 설치가 됨->로컬에 있는 여러가지 센서나 컴퓨팅 파워를 자유자재로 사용하는 파일 시스템 등을 엑세스 할 수 있다

- 트레이닝 되어 있는 모델을 그린그래스에 배포하여 실제 엣지에서 예측하는 것도 가능

- MQTT뿐만 아니라 산업 표준 프로토콜을 전환(translate)해주는 프로토콜 어뎁터 기능

 

MQTT : 저전력 기반의 IoT 또는 M2M(machine-to-machine) 커뮤니케이션을 위해 나온 프로토콜

MQTT 세상에서 디바이스들은 Client ID 같은 걸로 식별 된다 둘 간의 커뮤니케이션 하는 채널을 토픽이라고 이야기함

메시지 브로커는 Client ID들이 브로커에 붙어있다는 것을 알고 있다->대충 그린그래스가 알고있다는 의미

 

기본 컨셉은 sensing 데이터에 받는 것에 집중을 한다. 그런데 이 데이터가 sensing 데이터에만 한정되어 있는 것이 아니라 control signal이 있을 수도 있다. 예를 들어 바람의 풍속과 같은 것 = control data

control data 같은 경우에도 디바이스 자체도 그 데이터를 가지고 있어야한다. 단순히 메시지를 주고받는 sensing data와 다르게 control data는 관리가 달라져야한다. thing에 대한 attribute 때처럼 관리할 수 있어야한다. 그래서 나온 것이 device shadow이다

 

디바이스 섀도우 : 디바이스가 오프라인이 되어있다고 하더라도 최종적으로 reporting한 status 정보들을 클라우드가 가지고 있는데 그 정보들만 조회하면 된다. 디바이스의 정보를 조회하기 위해서 디바이스까지 갈 필요 없이 클라우드만 한 번 갔다오면 디바이스 정보를 확인할 수 있다.

 

뿐만 아니라, 디바이스는 자기의 정보를 계속 reporting 하는데, local에서 선풍기 파워를 조절하는 것도 방법일 수 있지만, 모바일 디바이스를 가지고 선풍기 파워를 조절할 수 있다. 그렇게 선풍기의 파워를 조절할 때 내가 원하는 정보 자체가 desired라는 형태로 클라우드에 전달이 된다. reporting된 정보와 사용자가 원하는 정보를 비교하고 만약 차이가 있다면 디바이스에 명령을 내려줄 수도 있다. desired와 reported가 차이가 났을 때 delta라는 이벤트가 발생한다. 

thing에서 어플리케이션을 개발한다고 했을 때 delta라고 하는 이벤트를 트랩해서 거기에 대한 thing의 정보를 업데이트하는 수준으로 개발하면 우리가 아는 디바이스의 상태정보를 가지고 control할 수 있다.

버전 관리도 할 수 있는데, incremental(증가)하게 또는 시퀀스가 중요한 경우에 delta 메시지를 받는 thing의 입장에서 버전 정보를 보면서 이러한 요소를 incremental하게 반영시킬 수 있는 기능을 제공한다.

 

클라이언트에서는 변경이 있을 때마다 상태 보고(cloud에 reporting)를 해야한다. 단순히 thing에 대한 상태를 본다고 하면 클라우드로부터 그 정보를 조회하는 것만으로 모든 액션들이 끝날 것이다.

클라이언트 사이드에서 delta가 발생했을 때 그 delta를 트랩해서 thing의 상태를 변경해주는 것 -> IoT사이드가 아닌 thing 사이드로 개발해야한다.

 

이러한 정보들은 MQTT프로토콜에 기반하고 있다. 그래서 디바이스 섀도우와 관련되어 있는 다양한 토픽들이 존재 한다. delta라는 이벤트도 디바이스의 정보 브리지가 발생해서 토픽에다 메시지를 던져주는 것

(subcription) 메시지를 던져주게 되면 디바이스가 온라인인 경우에는 실시간으로 받아서 메시지를 디바이스에 전달할 수 있고, 아니라면 디바이스가 온라인이 될때까지 iot가 그 메시지를 캐싱하고 들고있다.

 

디바이스 섀도우의 업데이트 토픽에 '공기청정기를 종료시키라고 선언'해 두었을 때 내가 원하는 desired 상태가 공기청정기를 끄는 상태이고, 만약 디바이스에서 올라온 데이터가 공기청정기가 켜져있다고하면 공기청정기를 종료하라고 delta 메시지가 발생할 것이고, 그것들을 구현하면 된다(?)

 

코어 : 그린그래스는 어떠한 서버에 설치가 될 것 그 서버를 그린그래스 코어(core)라고 부른다

센서 동작, 파일시스템에 있는 파일, 그린그래스 전체 세팅 등이 그린그래스 그룹의 리소스(resources) 항목으로 디파인된다. 

흔히 그린그래스라고 하면 그린그래스 코어를 지칭한다고 생각하면 됨

greengrass core = ggc!!!!!!!!

 

코어의 엔드포인트 그린그래스를 aware(인식)하는 디바이스는 코어의 엔드포인트에 접속이 가능해야한다 -> 이 정보는 클라우드에 들어와있는 정보이기도 하지만, 사물(thing)이 붙고자할 때 접속한 실질적인 정보이기 때문

그린그래스를 놓고 실제 디바이스들이 있는 구역 자체는 프라이빗 네트워크이다. 그린그래스는 무조건 인터넷에 연결되어야 하는데 thing 자체는 인터넷 연결이 필요없다. 그린그래스 구역은 퍼블릭 대역이다. 그럼 그린그래스는 엔드포인트 ip로 두 개를 갖게된다. -> 프라이빗 네트워크 대역에서도 그린그래스 활용 가능

 

그린그래스에 붙어있는 디바이스 = greengrass aware device : ggad

디바이스와 디바이스 간의 통신은 클라우드까지 가지 않고 그린그래스 코어를 브로커로 활용해서 서로간의 통신을 한다

섀도우 지원 - local shadow, shadow syncing to cloud

섀도우가 클라우드에 싱크 된다는 것-그린그래스를 aware하는 디바이스에 대한 상태 정보를 변경하고자 할 때 aws iot쪽에 상태 변경 업데이트를 알리면 그린그래스를 통해 ggad까지 전달됨. local shadow는 상태 정보를 업데이트 해달라고 IoT에 메시지를 전송해도 해당 정보는 없다고 뜬다. 그래서 그린그래스 코어에 메시지를 전송해야 상태가 업데이트된다.

 

람다 : 다양한 비즈니스 로직을 수행할 수 있는 코드 

 

Subcription : 디바이스와 디바이스가 서로간의 브로커를 통해 통신하는데, 제대로 된 통신 채널을 여기에 선언

 

 

람다(Lamdba)

- command나 control을 위한 명령어 수행

- AWS 클라우드와 연결 여부 관계없이 필요한 Operation 수행

- Data Filtering 및 Aggregation

- 파이썬, 자바, 노드js, C, C++ 지원

AWS 서비스에 대한 직접 호출이 가능하다

예를 들어, mqtt로 s3에 어떤 파일을 올리는 것이 아니라 그린그래스를 쓴다면 벡엔드에 있는 람다 함수로 이런 데이터를 전송하거나 가져올 때 벡엔드에 있는 aws의 서비스에 직접 붙어서 데이터를 쏘거나 받을 수 있다.

TES(Token Exchange Service) : 그린그래스 자체에 role을 할당하고 그 롤을 기반으로 실제 aws의 백엔드 서비스와 커뮤니케이션 할 수 있다. 람다 코드 내에서 aws 백엔드 서비스와 원할하게 통신할 수 있으며, 람다 코드에 api key와 같은 정보를 넣을 필요가 없다. 

 

컨테이너 : "모든 컴퓨팅 환경에서 빠르고 안정적으로 실행하게 만드는 표준화된 프로그램"으로서 애플리케이션을 실행하는데 필요한 모든것을 포함한다.

람다가 실행이 되면 트리거가 돼서 실행되는 구간 자체는 핸들러 구간이다

컨테이너 하나를 실행시켜 놓고 계속 유지하는 방법, 호출이 되면 컨테이너를 만들어서 실행을 시킨 다음에 내부 코드를 실행시키고 일정시간 이후 다시 컨테이너를 destroy 하는 방법이 있다.

핸들러 내에는 실제 로직을 구현하고, 전역변수 설정이나 커넥션 초기화는 핸들러 바깥에 선언을 해야한다. -> 핸들러가 호출이 되었을 때 다시 핸들러를 만들 필요없이 이미 만들어진 핸들러를 다시 사용하면 된다. 트리거를 통해 해당 토픽에 메시지가 들어오면 핸들러 구간이 실행된다.

 

실제 해당 토픽에 데이터가 들어가 있는데 이 데이터는 이벤트라고 하는 항목에 들어가있다. thing이 보낸 메시지라면 그 메시지의 데이터를 조회할 때는 이벤트에서 데이터를 조회하면 된다.

 

그린그래스에서는 트리거 없이 람다를 사용할 수 있다.

on-demand function의 경우 요청이 되었을 때 컨테이너를 만들고 일정시간 유지한 뒤에 컨테이너를 destroy시키는 것.

Make this function long-lived and keep it running indefinitely의 경우 컨테이너 하나가 계속적으로 메시지를 처리한다. 핸들러에 아무것도 없지만, greengrass hello world라는 특정 토픽에 메시지를 쏘기만 한다. thing들과 통신하거나 그린그래스 자체에서 데이터를 수집할 때에 있어 파일 시스템의 데이터를 10분 단위로 조회해서 s3에 올릴 때 쓰면 된다. 핸들러와 관계 없고, 컨테이너가 계속 올라와 있으면서 10분 단위로 파일 시스템을 읽어서 업로드하는 코드이다. 

람다 자체가 리소스에 엑세스할 수 있기 때문이다. GPIO, USB, Serial, GPU 등등

 

---

 

MQTT 메시지를 보내는 람다 함수를 만들고 배포하는 과정을 시작 중..

 

모듈3

https://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/create-lambda.html

Lambda 함수 생성 및 패키징 - AWS IoT Greengrass

https://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/config-lambda.html

Lambda 함수를 구성하려면AWS IoT Greengrass - AWS IoT Greengrass

 

 

Lambda 콘솔에서 함수 생성 클릭

 

새로작성 - 함수이름 설정

실행 시간에서 python3.7 선택

 

코드는 입력해도 되고 zip 파일로 업로드 할수도 있다.

zip 파일을 업로드하고,

 

아래로 스크롤 해서 런타임 설정에서 편집(edit)을 눌러준다

그리고 위와 같이 편집을 한 뒤 저장을 누른다

 

람다 함수를 게시한다. 작업(Actions)에서 새 버전 발행(Publish new version)을 클릭한다.

 

 

별칭이나 버전을 기준으로 Greengrass 그룹이 람다 함수를 참조할 수 있다. 코드 관리를 더 쉽게 할 수 있다.

별칭 생성(Create alias) 클릭

 

version을 1로 하여 별칭을 생성해준다.

 

1. AWS Greengrass - Group(v1) 클릭

2. 모듈2에서 만든 그룹 선택

3. 그룹 구성 페이지에서 Lamdba를 선택한 다음 Lambda 추가 선택

 

기존 Lambda 사용(Use existing Lambda function) 클릭

 

 

이전 단계에서 생성한 Lambda 이름 검색

 

그러면 이렇게 추가가 된다

오른쪽 상단의 점 세개를 클릭한 뒤 구성편집을 클릭한다

 

제한 시간과 수명 주기를 위와 같이 바꿔준다

그리고 밑으로 스크롤 해서 하단의 업데이트를 누른다

 

그룹 구성 페이지에서 [Subscriptions] 선택 - [Add your first Subscription] 선택

 

소스와 대상을 각각 위와 같이 선택하고 다음을 누르면 주제 필터 칸이 나온다

주제필터를 입력한 후 다음을 눌러준다

구독을 확인하고 완료를 누른다

 

그룹 구성 페이지 - 설정 - 로컬 로그 구성에서 편집을 누른다

 

다른 로그 유형 추가를 누른다

 

위와 같이 체크해준 뒤 업데이트를 누른다

 

ps aux | grep -E 'greengrass.*daemon'

코어 디바이스가 인터넷에 연결되어 있는지 확인하고, 위 문장으로 코어 디바이스에서 Greengrass 데몬이 실행 중인지 확인한다.

 

cd /greengrass/ggc/core/
sudo ./greengrassd start

데몬을 시작하기 위한 코드

 

작업(Actions)에서 배포(Deploy) 클릭하면 위와 같이 배포가 시작된다

 

---

하란대로 했는데도 안된다

 

그룹을 새로 생성했음에도 불구하고 안된다

runtime.log 오류가 계속 뜬다 슬프다

 

runtime.log라는 명령어? 파일?이 어디있는지 모르겠다