[IoT] Thing Management 01_IoT Device의 관리 기준

AWS IoT에 대해 언급한 지난 포스팅에서 첨부한 그림과 함께 다시 한번 IoT Device 관리 관련 포스팅을 시작해보고자 한다.

2020/04/09 - [프로그래밍/IoT] - [IoT] AWS IoT로 IoT 서비스 개발 시작하기

 

Web Service와 IoT Service의 가장 큰 차이점은 "Device"라고 생각한다.

Application을 사용하는 End User의 존재는 동일하기 때문에 User를 관리하는 방법에 대해서는 Service의 종류와 무관하게 동일할 것이다.

 

하지만, IoT(Internet Of Things) Service는 그 이름에서도 알 수 있듯

Things(사물)를 자원(Resource)으로 여기고 이를 어떻게 관리(Management)할 것인지가 중요한 부분이 될 것이다.

 

Things in AWS IoT

AWS IoT에서는 Thing Registry를 지원함으로써 AWS IoT Cloud에 등록된 Thing(IoT Device)을 관리할 수 있도록 한다.

간단하게 말하면, Thing Registry에 등록된 사물이 인증 절차를 거친다면 Service Architecture와 통신이 가능하게 된다.

AWS에서는 Thing을 관리할 수 있는 방법으로 Thing(사물), ThingType(유형), ThingGroup(사물 그룹)을 제공한다.

사물 - Thing

Thing은 인터넷에 연결된 IoT Device를 지칭하는 것이자 AWS IoT의 Thing Registry에서 관리되는 사물의 기준이 되는 것이다.

Thing을 등록할 때에는 Thing Name(Required)과 Thing Attribute(Optional)를 입력값으로 한다.

 

Thing Name을 어떻게 관리할 것인가? 는 IoT Service에서 중요한 부분일 것이다.

IoT 서비스를 생각해보면, 기기를 등록하는 과정은 일반적인 유저의 등록 과정과 다르다.

즉, User Id의 중복 여부를 체크하는 것과 같이 한 건 한 건의 입력 과정을 거쳐서 등록이 이뤄지기 보다는 Bulk로 생성되는 경우가 일반적일 것이기 때문에 어떻게 Unique한 ThingName을 가져갈 수 있을 것인가에 다한 Naming Rule을 정립하는 것이 필요하다.

 

유형 - ThingType

각 사물은 하나의 사물 유형을 가질 수 있다.

사물 유형의 필요성은 사물이 유형을 가질 때, 사물은 최대 50개의 Attribute를 가질 수 있다.

여기에서 말한 Attribute가 Thing을 생성 또는 수정할 때 추가 및 변경 가능한 Thing Attribute를 의미한다.

 

Thing Attribute는 사물이 가지고 있는 속성의 Key-Value 쌍이다.

어떤 제조사가 만든 사물인지, 어떤 모델인지, 어떤 소프트웨어와 어떤 소프트웨어 버젼을 갖고 있는지 등, 각 사물에 대한 상태값의 snapshot이 표현되는 값이다.

 

Thing Attribute가 중요한 것은 수 없이 많이 생성될 IoT Device들 중에서 특정 Thing을 검색할 수 있는 기준이 되기 때문이다.

물론 추후 포스팅을 통해 소개할 Fleet Indexing 서비스는 검색 가능한 조건 절의 수를 최대 5개로 제한하고 있지만, Thing에 대한 검색 시 검색 가능한 조건이 Attribute이기 때문에 각 Thing에 ThingType을 부여하여 여유롭게 Attribute를 할당하도록 해야한다.

 

사물 그룹 - ThingGroup

사물 그룹이란 여러 사물을 범주화하여 관리할 수 있는 단위이다.

직접 API로 관리 가능한 Static ThingGroup과 지정된 쿼리(Fleet Indexing 기반)를 기반으로 관리 가능한 Dynamic ThingGroup이 있다.

 

사물 그룹의 중요한 부분은 Thing을 한꺼번에 관리할 수 있는 집단의 기준이라는 점이다.

다른 여러가지 특징과 중요한 부분은 AWS의 공식 문서를 통해 파악할 수 있으니, Thing Management의 관점에서 중요한 점을 한가지만 정리하자면, 각 그룹별로 정책(Policy)을 연결하여 Group에 포함된 사물들이 정책의 영향 하에 있을 수 있도록 한다는 점이다.

 

AWS IoT는 MQTT protocol에 기반하여 통신을 하게 되는데, 이 때 Server와 Client의 통신 Interface를 정리한 것이 Policy이다.

각 서비스별로 서로 다른 Interface를 갖게 될테니, 개별 인증서마다 서로 다른 정책(Policy)을 직접 연결하여 관리를 하는 것 보다는 Thing의 인증은 인증서 레벨에서 처리한 뒤 Interface는 서비스 별로 공통된 기준에 따라서 처리하는 것이 관리의 관점에서는 보다 효과적일 수 있다.

 

이 때 활용 가능한 것이 Static ThingGroup에 Policy를 연결하여, Thing Group에 속한 Thing들이 정책에 정의된 Interface를 수행 가능하도록 권한을 부여하는 방법일 것이다.

 

주의할 부분은 Policy가 연결 가능한 ThingGoup은 오직 Static Thing Group이다.

Dynamic ThingGroup의 경우 정책을 연결하는 것이 불가능하다. 만약 정책이 연결 가능하다면 개별 Attribute 값에 따라서 자동으로 Group에 포함 및 삭제되도록 함으로써 Thing과 Group을 관리하는 것이 보다 편리할 텐데, 한편으로 아쉬운 점인 듯 하다.

하지만, Dynamic ThingGroup의 주된 역할은 AWS Job의 Target이라는 점에서 Static Group과는 다른 관리의 목적과 방식이 있으니, 이 또한 추후 포스팅을 통해 다뤄보도록 하겠다.

---

Thing, ThingType, ThingGroup의 보다 기본적인 개념은 AWS Developer Guide에 보다 상세하게 설명되어있다 보니, 이를 블로그에서 다시 한번 언급하는 것은 불필요하다고 생각했다.

오히려 Thing의 관리 관점에서 중요한 개념들과 관리 과정에서 보다 중요하게 다뤄야 하는 핵심들을 설명해보고자 했다.

 

이번 포스팅의 제목을 Thing Management 01로 한 것 처럼,

기본적인 내용 외에 그 개념과 기준을 바탕으로 실제로 어떻게 Thing을 관리할 수 있는지 다음 포스팅에서 기록해보겠다.