• 데이터 어노테이션은 훈련 데이터(텍스트, 이미지, 오디오, 비디오 등)의 개별 요소에 주석을 달아 기계가 데이터 내용과 중요한 부분을 이해하도록 돕는 과정입니다. 예를 들어, 이미지에 있는 사람이나 물체에 '이것은 사람', '이것은 자동차'와 같은 태그를 붙이는 것을 말합니다.

  Annotation vs Labeling

• 데이터 어노테이션은 데이터에 주석을 달아주는 작업을 의미합니다. 예를 들어, 이미지 데이터에 어노테이션을 하면 사람의 얼굴, 물체의 종류 등 이미지의 각 요소에 대한 상세한 정보를 제공합니다.
• 데이터 라벨링은 데이터를 특정 범주로 분류하는 작업을 의미합니다. 예를 들어, 이미지 데이터를 라벨링하면 이미지의 전체 또는 특정 부분을 '사람', '동물', '자연' 등의 범주로 분류할 수 있습니다.

  중요성

• 지도학습에서 입력 데이터의 품질이 머신 러닝 모델의 성능을 결정합니다.
• 데이터 유형의 이해: 데이터는 구조화된 데이터와 비구조화된 데이터로 분류됩니다. 예를 들어, 구조화된 데이터는 엑셀 시트에 나열된 고객 정보 같은 것이고, 비구조화된 데이터는 소셜 미디어의 텍스트나 이미지 같은 것입니다.

종류

텍스트 어노테이션

• Named Entity Recognition (NER): 텍스트 내 개별 엔티티를 식별합니다. 예: '서울은 도시입니다'에서 '서울'을 '도시'로 식별.
• Sentiment Tagging: 텍스트의 감정적 톤을 분류합니다. 예: '이 제품은 정말 좋아요!'는 긍정적 감정으로 분류.
• Semantic Annotation: 텍스트의 의도나 맥락을 이해하는 데 도움을 줍니다. 예: '나는 창문을 닫았다'는 행동을 설명합니다.

  이미지 어노테이션

• Image Bounding Boxes: 이미지 내 특정 객체를 식별하고 라벨을 붙입니다. 예: 공원의 사진에서 사람, 벤치, 나무에 박스를 그림.
• Image Classification: 이미지를 하나 이상의 범주로 분류합니다. 예: 산의 이미지를 '자연' 범주로 분류.

  비디오 어노테이션

• 비디오 프레임 내 객체 식별, 분류, 추적: 비디오 내의 객체를 식별하고, 분류하며, 필요한 경우 여러 프레임에 걸쳐 추적합니다. 예: 도로 위를 달리는 자동차를 비디오의 각 프레임에서 추적.

• https://www.einfochips.com/blog/autosar-in-automotive-industry/#:~:text=Basic%20Software%20Architecture%20(BSW),of%20engine%2C%20gearbox%2C%20etc.
• https://www.autosar.org/standards/classic-platform

  키워드 : 표준화, 확장성

AUTOSAR 개요

• AUTOSAR는 자동차 OEM(Original Equipment Manufacturer) 및 1차 공급업체들이 ECU(Electronic Control Unit) 소프트웨어의 품질을 향상시키고, 개발 비용을 줄이며, 동일한 차량 애플리케이션에 대해 유사한 ECU 소프트웨어 컴포넌트의 재개발을 방지하기 위해 지원하는 개방형 시스템 아키텍처입니다.

본문

자동차 산업의 트렌드

• 자율 주행, 차량 간 통신(V2X), OTA(Over-The-Air) 업데이트, 예측 유지 보수 등과 같은 혁신적인 기능들이 차량 내 소프트웨어 기능에 기반하고 있습니다. 이러한 기능들이 원활하게 작동하기 위해서는 각 ECU가 효율적으로 작동해야 합니다.

  과거의 문제점

• 과거에는 OEM이 사용하는 ECU 소프트웨어가 다양한 플랫폼에서 개발되었으며, 1차 공급업체와 그들의 벤더들이 OEM을 위한 ECU 소프트웨어를 설계할 때 사용되는 표준 소프트웨어 아키텍처가 없었습니다. 이로 인해 새로운 공급업체가 기존의 소프트웨어 아키텍처, 하드웨어 플랫폼, 그리고 ECU 소프트웨어 개발에 사용된 표준들을 이해하는데 큰 도전을 겪었습니다.
• 이 문제를 해결하기 위해, 2003년에 자동차 1차 공급업체, 반도체 제조업체, 소프트웨어 공급업체, 도구 공급업체 등이 모여 AUTOSAR 컨소시엄을 창설했습니다.

목적

• AUTOSAR은 개방형 및 표준화된 자동차 소프트웨어 아키텍처로, 애플리케이션 소프트웨어와 기본 차량 기능 간의 인터페이스 표준화를 지원합니다. 이는 멤버들에게 복잡한 전자/전기 차량 환경 관리에 있어 여러 혜택을 제공하며, 소프트웨어 아키텍처의 표준화를 통해 품질 향상과 개발 시간 및 비용 절감을 도모합니다.

아키텍쳐

• AUTOSAR 아키텍처는 소프트웨어 개발을 위한 개방형 시스템 아키텍처로, 다음 3개의 주요 계층으로 구성됩니다
  • 기본 소프트웨어 아키텍처(Basic Software Architecture -모든 AUTOSAR ECU 공통)
  • AUTOSAR 런타임 환경(AUTOSAR Runtime Enviroment)
  • 애플리케이션 계층(Application Layer)

BSW

• Basic Software Architecture
• 다양한 계층으로 구성된 수백개의 소프트웨어 모듈로 구성됩니다.
• 이를 통해 BSW를 설계한 공급업체가 엔진, 기어박스 등의 ECU를 작업하는 다른 공급업체와 이를 공유할 수 있습니다.

기본 소프트웨어 아키텍쳐 계층

• Microcontroller Abstraction Layer (MCAL)
  • 하드웨어 추상화 계층
  • 특정 MCU에 대한 인터페이스를 구현합니다
  • MCAL은 차량 내의 특정 마이크로컨트롤러와 소프트웨어 간의 연결 다리 역할을 합니다
  • 소프트웨어 계층이 마이크로컨트롤러와 레지스터를 통해 직접 소통할 수 있도록 해줍니다.
  • 시스템 드라이버, 진단 드라이버, 메모리 드라이버, 통신 드라이버(CAN, LIN, Ethernet 등), I/O 드라이버 등 다양한 드라이버를 제공합니다.
• ECU Abstraction Layer
  • 상위 SW 계층에 특정 ECU 서비스를 제공합니다.
  • 이 계층과 드라이버들은 MCU와 독립적이며, ECU 하드웨어에 의존성이 있습니다.
  • ECU의 모든 주변 장치 및 장치에 접근할 수 있게 해주며, 통신, 메모리, I/O 등의 기능을 지원합니다.
• Service Layer
  • AUTOSAR 기본 SW 아키텍쳐의 최상위 계층입니다
  • 서비스 계층에는 OS가 포함되어있으며, OS는 SW가 차량 내에서 어떻게 동작하는지를 관리합니다
  • 이 OS는 Application 계층부터 MCU까지 전 범위까지 모든 계층을 관리하고 조정합니다.
  • 역할: 마이크로컨트롤러와 애플리케이션 계층 사이의 인터페이스 역할을 하며, 애플리케이션 작업을 스케줄할 수 있습니다.
  • 담당 서비스: 네트워크 서비스, 메모리 서비스, 진단 서비스, 통신 서비스, ECU 상태 관리 등을 담당합니다.

    런타임 환경 (RTE 계층)

• BSW와 application 계층 사이의 미들웨어 계층으로 applicationSW에 대한 통신 서비스를 제공합니다

Application 계층

• AUTOSAR의 애플리케이션 계층는 소프트웨어 아키텍처의 최상위 계층이며 사용자 지정 기능 구현을 지원합니다.
• 이 계층은 특정 소프트웨어 구성 요소와 지침에 따라 특정 작업을 수행하는 다양한 애플리케이션으로 구성됩니다.
• 애플리케이션 소프트웨어 구성 요소, 소프트웨어 구성 요소의 포트 및 포트 인터페이스로 구성된 세 가지 구성 요소로 구성됩니다.
• AUTOSAR는 애플리케이션 계층의 소프트웨어 구성 요소에 대한 표준화된 인터페이스를 보장합니다.
• 애플리케이션 소프트웨어 구성 요소는 차량 기능을 지원하는 간단한 애플리케이션을 생성하는 데 도움이 됩니다.
• 소프트웨어 구성 요소 간의 통신은 가상 함수 버스를 사용하여 특정 포트를 통해 가능합니다.
• 이러한 포트는 또한 소프트웨어 구성 요소와 AUTOSAR 기본 소프트웨어(BSW) 간의 통신을 용이하게 합니다.
• 위에 설명된 AUTOSAR 아키텍처는 실시간 요구 사항과 안전 제약을 지원하는 클래식 플랫폼입니다.
• MCU를 기반으로 하는 클래식 플랫폼은 ECU가 차량 센서 및 actuator에 접근할 수 있도록 허용하여 네트워킹 및 보안 분야의 애플리케이션을 지원할 수 있습니다.

Adaptive AUTOSAR의 필요성

• 요약 : 표준화된 adaptive 프레임워크를 통해 혁신, 협업 및 최첨단 자동차 기능의 제공에 있어 중추적인 역할을 하고 있습니다.

Classic AUTOSAR의 한계

• 2003년부터 2015년까지 Classic AUTOSAR는 잘 확립된 플랫폼으로, 차량 내 60-80개의 ECU를 운영하는 데 적합했습니다.

  자동차 산업의 진화

• IoT 기반의 자동차 트렌드(예: V2X 연결성, 자동 운전)의 발전으로 인해 전기화가 급증하면서, 시장에서는 더 많은 기능과 장치를 지원할 수 있는 새로운 아키텍처의 필요성이 대두되었습니다.

  Adaptive AUTOSAR의 출현

• 기존의 Classic AUTOSAR 플랫폼은 이러한 메가 트렌드를 지원하기에 적합하지 않았기 때문에, 더 강력하고 유연한 E/E 아키텍처가 요구되었고, 이에 따라 Adaptive AUTOSAR가 2017년 3월에 출시되었습니다.

Adaptive AUTOSAR 아키텍처의 특징

• 고성능 중앙 애플리케이션 서버 : 이 시스템은 고성능 컴퓨팅을 지원하는 중앙 애플리케이션 서버를 포함합니다.
• 실시간 기능 지원: Ethernet 기반의 ECU는 실시간 기능을 지원합니다.
• 확장성과 동적 아키텍처: Adaptive AUTOSAR는 확장 가능하며, 차량의 수명 주기에 걸쳐 애플리케이션을 업데이트할 수 있는 동적 아키텍처를 가지고 있습니다.
• 미래 지향적 자동차 애플리케이션 지원: 인포테인먼트, V2X, 예측 유지보수, 자동차 앱, 카메라, 레이더, 라이다 센서를 사용하는 ADAS 기능, 지도 업데이트, 전기화 등을 지원합니다.

AUTOSAR 2023의 주요 트렌드:

• 사이버 보안 강화: 차량과 모든 것(V2X) 간의 안전한 통신을 가능하게 하는 사이버 보안에 대한 초점이 증가하고 있습니다.
• OTA 업데이트 지원 강화: 공중을 통한(Over-The-Air) 업데이트 지원을 강화하고 있습니다.
• AI 통합: ADAS 및 자율 주행 기능을 위한 인공 지능(AI) 통합이 진행되고 있습니다.

vector<vector<pair<int,int>>> tree; vector visited;

tree.resize(v+1) visited.resize(v+1,false);

• tag : #algorithm, # C++

  개요

• 문제 정의 : C++에서는 switch에서 문자열을 사용할 수 없습니다
• 대안 : if문, hash 함수

  본문

• cpp에서 switch는 정수형, 열거형 타입과만 함께 사용할 수 있습니다.

enum 타입은 정의한 값들을 열거하는 데 사용되며, 해당 값들은 기본적으로 0부터 시작하여 1씩 증가하는 값으로 초기화됩니다. 따라서 enum Color의 경우, RED는 0, GREEN은 1, BLUE는 2의 값을 갖게 됩니다.

• pyenv

  sudo apt-get update
  sudo apt-get install pyenv

export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

pyenv local 3.10

$ git push 
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:develop

To push to the branch of the same name on the remote, use

    git push origin HEAD

Solution

현재 브랜치의 Upstream 설정 변경

git push -u origin HEAD

• 현재 브랜치(HEAD)를 원격 저장소(origin)의 동일한 이름의 브랜치로 푸시하고, 이를 기본(upstream) 브랜치로 설정합니다.

git branch --set-upstream-to=origin/<브랜치 이름>

• 현재 브랜치의 upstream을 명시적으로 설정할 수 있습니다

예시

• 현재 브랜치가 feature이고 이를 원격의 feature 브랜치에 매핑하고 싶으면

  git branch --set-upstream-to=origin/feature feature

import mxnet as mx

오류 메세지

OSError                                   Traceback (most recent call last)
Input In [16], in <cell line: 2>()
      1 # import os
----> 2 import mxnet as mx

File ~/.local/lib/python3.9/site-packages/mxnet/__init__.py:23, in <module>
      1 #!/usr/bin/env python
      2 
      3 # Licensed to the Apache Software Foundation (ASF) under one
   (...)
     19 
     20 # coding: utf-8
     21 """MXNet: a concise, fast and flexible framework for deep learning."""
---> 23 from .context import Context, current_context, cpu, gpu, cpu_pinned
     24 from . import engine, error
     25 from .base import MXNetError

File ~/.local/lib/python3.9/site-packages/mxnet/context.py:23, in <module>
     21 import warnings
     22 import ctypes
---> 23 from .base import classproperty, with_metaclass, _MXClassPropertyMetaClass
     24 from .base import _LIB
     25 from .base import check_call

File ~/.local/lib/python3.9/site-packages/mxnet/base.py:356, in <module>
    354 __version__ = libinfo.__version__
    355 # library instance of mxnet
--> 356 _LIB = _load_lib()
    358 # type definitions
    359 mx_int = ctypes.c_int

File ~/.local/lib/python3.9/site-packages/mxnet/base.py:347, in _load_lib()
    345     lib = ctypes.CDLL(lib_path[0], winmode=0x00000008)
    346 else:
--> 347     lib = ctypes.CDLL(lib_path[0], ctypes.RTLD_LOCAL)
    348 # DMatrix functions
    349 lib.MXGetLastError.restype = ctypes.c_char_p

File /opt/tljh/user/lib/python3.9/ctypes/__init__.py:382, in CDLL.__init__(self, name, mode, handle, use_errno, use_last_error, winmode)
    379 self._FuncPtr = _FuncPtr
    381 if handle is None:
--> 382     self._handle = _dlopen(self._name, mode)
    383 else:
    384     self._handle = handle

OSError: libnccl.so.2: cannot open shared object file: No such file or directory

sudo 명령어를 사용할 수 없는 환경에서 dkpg 역시 불가능했고 다른 모델은 환경이었기 때문에 문제를 파악하기 어려웠습니다.

LLM에 물어봐도 도움이 되지 않는 대답 뿐이여서 문제를 해결하기가 더욱 어려웠습니다.

혹시 환경 자체에 문제가 생긴 것인지 테스트하고자 가상 환경에 torch를 install하였더니 문제가 해결되었습니다. '

어떻게 해결된 것인지 궁금하여 bard에게 질문하였고 응답을 기록하였습니다.

torch를 설치하기 전에 MXNet을 가져오려고 하면 MXNet이 NVIDIA GPU를 사용하기 위해 필요한 libnccl.so.2 공유 오브젝트 파일을 찾을 수 없습니다. 
이것이 OSError를 일으켰습니다.
torch를 설치하면 MXNet이 설치되어 있는지 감지합니다. 
torch는 MXNet이 libnccl.so.2 공유 오브젝트 파일을 필요로 한다는 것을 알고 있으므로 이 파일과 MXNet에 필요한 기타 누락된 라이브러리와 종속성을 자동으로 설치합니다.
torch를 설치한 후 MXNet을 다시 가져오려고 합니다. 
이번에는 MXNet이 libnccl.so.2 공유 오브젝트 파일과 기타 필요한 라이브러리를 찾을 수 있으므로 가져오기가 성공합니다.
요약하자면, torch 설치가 OSError를 해결한 이유는 MXNet이 제대로 작동하는 데 필요한 누락된 라이브러리와 종속성을 자동으로 설치했기 때문입니다.

용도

• 코드의 명시성과 유지보수성

내장 모듈이 아닌 typing모듈의 List와 Dict를 사용하는 이유

• 파이썬 내장 list와 dict 자료형은 타입을 구체적으로 명시하지 않습니다. 예를 들어, 어떤 함수가 리스트를 반환한다고 할 때, 그 안에 어떤 타입의 원소가 들어가는지는 기본적인 list 자료형만으로는 알 수 없습니다. 이는 dict에도 마찬가지로 적용됩니다.
• 반면, typing 모듈의 List와 Dict 제네릭 타입은 이러한 자료형들의 내부 원소에 대한 타입 정보까지 명시할 수 있게 해줍니다. 예를 들어, List[int]는 정수들의 리스트임을, Dict[str, float]는 문자열을 키로 하고 부동소수점 숫자를 값으로 하는 딕셔너리임을 명확히 합니다.

버전

• typing 모듈은 파이썬 3.5 이상에서 사용할 수 있습니다.

문제

bash: basename: command not found

basename

• UNIX 시스템에서 사용되는 명령어로, 주어진 파일 경로에서 디렉토리 부분을 제외하고 파일 이름만 출력합니다.
• 만약 확장자나 특정 접미사를 제거하고자 한다면, 다음과 같이 사용할 수 있습니다

  basename /usr/bin/basename.c .c

해결

path 변경

echo $PATH

현재 환경변수 확인 후

PATH = 

PATH=/usr/local/bin : 사용자가 수동으로 설치한 SW의 실행 파일들을 찾을 수 있는 표준 디렉토리 /bin : 필수 시스템 명령어들이 위치하는 표준 디렉토리 /usr/bin : 시스템 기본 사용자 명령어들이 포함된 표준 디렉토리

PATH=/usr/local/bin:/bin:/usr/bin

• BaseModel을 상속받은 클래스의 인스턴스를 리스트나 딕셔너리와 같은 방식으로 인덱실 할 때 발생하는 에러
• 필드에 접근할 때 속성(attribute)접근 방식을 사용해야 합니다.

주요 원인

• enumerate < 리스트나 튜플과 같이 순서가 있는(iterable) 객체에 사용 가능합니다
• 인스턴스는 일반적으로 이러한 방식으로 반복할 수 없습니다.

해결법

• 'Color' 클래스의 각 필드에 직접 접근해야 합니다.
• 인스턴스의 속성으로 리스트를 만들고 enumerate를 사용할 수 있습니다

오류가 발생한 코드

def func0(item_colors : Color):
    for idx, i in enumerate(item_colors):
        pass

개선된 코드

def func1(item_colors: Color):
    colors = [item_colors.outer, item_colors.top, item_colors.bottom, item_colors.item]
    for idx, color_name in enumerate(colors):
        pass

문제 정의

project/
│
├── main.py
└── a_dir/
    ├── __init__.py
    ├── a_run.py
    └── a_b.py

위와 같은 디렉토리 구조에서 main.py를 통해 a_run.py를 호출하고 여기서 다시 a_b를 참조하는 경우 a_run 파일에서 다음과 같이 절대 경로로 명시하였다면 오류가 생길 수 있습니다.

from a_b import a_b_function

해결 방법

이 경우 두 가지 방법으로 해결 가능합니다

1. 상대 경로 사용

from .a_b import a_b_function

위와 같이 경로에 .을 붙여 상대 경로로 사용합니다

2. 파이썬 스크립트가 실행될 때 'sys.path'에 프로젝트의 루트 디렉토리 추가

• 이 방법은 프로젝트 구조나 환경 설정에 따라 sys.path에 경로가 올바르게 설정되지 않아 절대 경로로 모듈을 찾을 수 없는 상황을 해결합니다.

import sys
import os

# 프로젝트의 루트 디렉토리 경로를 얻습니다.
root_path = os.path.dirname(os.path.abspath('main.py'))

# sys.path에 프로젝트 루트를 추가합니다.
if root_path not in sys.path:
    sys.path.append(root_path)

# 이제 a_dir 패키지 내부의 모듈을 절대 경로로 임포트할 수 있습니다.
from a_dir.a_b import a_b_function

• Concise Binary Object Representation
• “The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.”
• ref : https://cbor.io/

개요

• C.Bormann이 작성한 JSON을 기반으로 하는 이진 데이터 직렬화(serialization) 형식
• 가독성을 포기하고 처리 및 전송속도를 중가시켰습니다.

https://pypi.org/project/paho-mqtt/

class Shape:
    def __init__(self, sides):
        self.sides = sides

    @classmethod
    def get_class_info(cls):
        return f"This is a {cls.__name__} with {cls.sides} sides."

class Triangle(Shape):
    def __init__(self):
        super().__init__(3)

class Square(Shape):
    def __init__(self):
        super().__init__(4)

print(Triangle.get_class_info())  # 출력: This is a Triangle with 3 sides.
print(Square.get_class_info())    # 출력: This is a Square with 4 sides.

Class method

@classmethod decorator

• 함수가 정의된 이후 evaluated(표현식이나 코드가 실행되어 결과를 얻는 과정)되는 표현식인 built-in function decorator입니다.
• 인스턴스 매서드가 인스턴스를 받는 것처럼, 클래스 매서드는 implicit(암시적(값을 지정하지 않아도 컴파일러 등에서 자동으로 처리되는 경우)) 으로 첫번째 인자를 받습니다

    class Car:
        def func(cls, arg1, arg2, ...):
            pass

    func: classmethod로 변환해야 하는 함수
    returns:classmethod로 변환된 함수

• object 인스턴스가 아닌 (class를 가리키는 class parameter)를 갖기 때문에 class의 state에 access할 수 있습니다.

Static method

• Static method는 implicit first argument를 받지 않습니다.
• Static method 역시 object of class가 아닌 class에 bound되어있습니다.
• Static method는 class의 state에 access할 수 없습니다.
• method는 클래스 안에 정의되어 있지만, 클래스나 인스턴스와는 별개로 독립적으로 동작합니다.(method는 클래스에 존재하는 것이 합리적이라는 이유로 클래스 안에 정의되어 있을 뿐입니다.)

class Car(obj):
    @staticmethod
    def func(arg1, arg2, ...):
        pass
returns : 함수 func에 대한 staticmethod(즉 해당 함수를 정적 메서드로 변환하여 return)

이 메서드는 다이얼로그 창을 강제로 닫습니다. 다이얼로그가 열려 있는 상태에서 self.close()를 호출하면 창이 즉시 종료되며,
이후에 어떤 작업도 실행되지 않습니다. 이는 단순히 창을 닫을 때 사용됩니다.

self.accept()

이 메서드는 다이얼로그 창을 "수락" 상태로 닫습니다. 일반적으로 "확인"이나 "적용" 버튼과 연결되어 사용됩니다.
self.accept()를 호출하면 다이얼로그가 닫히면서 부모 창이나 호출한 코드에게 "수락"되었음을 알리는 신호가 전달됩니다.
이후에 수행할 작업을 부모 창이나 호출한 코드에서 처리할 수 있습니다.

terminate()-> 실행중인 작업을 중단하고 스레드 즉시 종료

• ref : aws-fanout

  fan-out

• 하나의 source에서 Data를 병렬로 전송하는 과정

Kinesis Data Firehose 전송 스트림으로 팬아웃

Lambda 함수로 팬아웃

Amazon SQS 대기열로 팬아웃

HTTP(S) 엔드포인트로 팬아웃

Amazon SNS 및 AWS 컴퓨팅, 스토리지, 데이터베이스 및 네트워킹 서비스를 사용한 이벤트 기반 컴퓨팅

Kinesis Data Firehose 전송 스트림으로 팬아웃:

특징 : 실시간 스트리밍 데이터를 다양한 대상으로 전달할 수 있는 서비스.

데이터를 수집하여 Amazon S3, Amazon Redshift, Amazon Elasticsearch 등으로 전송 가능. 스트리밍 처리와 함께 데이터 정리 및 변환 작업도 가능.

장점 : 실시간 처리로 신속한 데이터 전달이 가능.

스트림 처리 및 저장을 통해 유연한 데이터 유지 관리 가능.

단점 : AWS 서비스로 제한되며, 비용이 발생할 수 있음.

복잡한 데이터 처리가 필요한 경우에는 Lambda 함수와 함께 사용해야 할 수도 있음.

Lambda 함수로 팬아웃:

특징:

AWS Lambda를 사용하여 데이터를 처리하고 다양한 대상으로 분배하는 방식. Lambda 함수는 이벤트 기반으로 트리거될 수 있으며, 처리 로직을 자유롭게 구현 가능.

장점:

매우 유연한 방식으로, 다양한 데이터 처리 및 분배 작업 가능. 서버리스 아키텍처로 인프라 관리가 필요 없음.

단점:

함수 실행에 따른 지연이 발생할 수 있으며, 빠른 실시간 처리가 요구되는 경우에는 고려해야 함. 복잡한 데이터 처리 작업은 함수 구현 및 관리의 어려움을 초래할 수 있음.

Amazon SQS 대기열로 팬아웃:

특징:

메시지 대기열 서비스로, 데이터를 대기열에 넣고 여러 컨슈머가 비동기적으로 처리할 수 있음. 각 메시지를 독립적으로 처리하므로 분산 시스템에 유리함.

장점:

확장성이 높으며, 여러 컨슈머 간의 병렬 처리가 가능. 대기열에서 메시지 처리 실패 시 재시도가 가능하며, 신뢰성 있는 데이터 전달이 보장됨.

단점:

실시간 처리에 제한이 있을 수 있으며, 처리량이 대기열의 처리량에 영향을 받을 수 있음. 메시지 처리 지연이 발생할 수 있음.

HTTP(S) 엔드포인트로 팬아웃:

특징 : HTTP 또는 HTTPS를 통해 데이터를 다른 시스템 또는 엔드포인트로 전송하는 방식.

API 엔드포인트 또는 웹 서비스와 연결하여 데이터를 전달할 수 있음.

장점 : 다른 시스템과의 통합이 용이하며, 다양한 대상 시스템으로 데이터 전달 가능.

HTTP 프로토콜을 활용하므로 많은 언어 및 플랫폼에서 사용 가능.

단점 : 데이터 처리 및 안전성을 추가로 고려해야 하며, 일부 시스템에 따라 네트워크 문제 발생 가능성 있음.

대량 데이터 처리 시 성능 문제가 발생할 수 있음. Amazon SNS 및 AWS 서비스를 사용한 이벤트 기반 컴퓨팅:

특징 : Amazon SNS를 사용하여 이벤트를 발생시키고, 해당 이벤트를 처리하기 위해 다양한 AWS 서비스를 활용하는 방식.

이벤트에 대한 응답으로 Lambda 함수, AWS Step Functions, HTTP 엔드포인트 등을 활용 가능.

장점 : 이벤트 기반 아키텍처로, 다양한 서비스 간 연결과 처리가 용이함.

특정 이벤트에 대한 대응 및 처리를 유연하게 구현 가능.

단점 : 서비스 간의 복잡한 통합과 관리가 필요할 수 있음.

이벤트 발생 시간과 처리 시간 간의 딜레이가 발생할 수 있음.

• ref : https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

• consumer가 queue에서 메시지를 수신하고 처리할 때 메시지는 대기열에 남아있습니다

• 메시지는 소비자가 수신한 후 대기열에서 삭제합니다

• 받은 직후 메시지는 대기열에 남아있습니다

• SQS는 timeout 기간동안 다른 소비자들에게 보이지 않도록 만듭니다

• 이 기간동안 다른 소비자들은 해당 메시지에 접근할 수 없습니다

• default 30초, 0~12시간까지 설정 가능합니다

주의

• visibility timeout은 메시지의 중복 수신을 완벽하게 방지하지는 못합니다. (특히 표준 queue에서)

Inflight messages

• SQS 메세지에는 아래의 세가지 기본 상태가 있습니다

  1. producer가 queue로 보냅니다
  2. consumer가 queue에서 수신했습니다.
  3. queue에서 삭제되었습니다

• Infilght messages(2-3 사이) : 메세지가 소비자에게 받아진 후 아직 삭제되지 않은 상태

• Inflight message의 수에는 할당량이 있습니다 ( queue 유형에 따라 다릅니다 )

AWS IoT Core

- IoT 기기를 다른 기기에 연결하는 클라우드 서비스를 제공합니다.

• AWS IoT Core에서 지원하는 프로토콜들을 살펴보겠습니다

MQTT

• MQTT는 제약된 디바이스를 위해 설계된 경량의 메시징 프로토콜로서 광범위하게 사용되고 있습니다.
• Publish-Subscribe 패턴을 기반으로 하며, client는 주제(topic)를 구독하거나 메시지를 발행할 수 있습니다
• Pub와 Sub 사이의 Message Broker의 종류는 일반적으로 아래와 같습니다
  • Rabbit MQ
  • VernaMQ
  • HiveMQ
  • mosquitto

장점

• 저전력 디바이스와 효율적인 통신이 가능합니다
• 경량 프로토콜이므로 오버헤드가 적고, 다른 기기 간 통신 역시 쉽게 가능합니다.
• QoS(Quality of Service) 레벨을 통해 메세지의 신뢰성과 일관성을 보장합니다.

단점

• 보안성이 낮아 암호화와 인증이 별도로 필요할 수 있습니다 (AWS 이용시 암호화 제공)

  대용량 데이터 전송에 아래와 같은 이유로 적합하지 않을 수 있습니다

  • 메세지 크기 제한
  • 데이터 유실
    • QoS 레벨이 높을수록 처리량이 감소합니다
    • QoS 레벨이 낮을수록 유실될 확률이 증가합니다
  • 보안
    • MQTT는 보안 기능을 갖추고 있지 않습니다, 별도의 암호화가 필요합니다

      예시

• 스마트 팜에서 센서 데이터 수집 및 관리

• AWS IoT의 MQTT 지원 ver : MQTT v3.1.1을 기반으로 몇가지 차이점이 있습니다

• ref : (aws)[https://catalog.us-east-1.prod.workshops.aws/workshops/cdb1fb2e-9345-4c47-9831-026dad5870e6/ko-KR/4-iotcore]

MQTT over WSS

• MQTT 프로토콜을 웹 소켓 위에서 보안 연결을 사용하여 전송하는 방식입니다
• webapps(in page) 내에서 직접 메세지를 sub/pub 하는 경우 websocket을 통해 MQTT를 실행하는 방식을 추천 (ref : (stackoverflow)[https://stackoverflow.com/questions/30624897/direct-mqtt-vs-mqtt-over-websocket])

  장점

• 연결 유지를 위한 재접속 절차가 간소화됩니다
• 다수의 클라이언트간의 통신을 WSS와 비교하여 간편하게 활용할 수 있습니다
• QoS 레벨을 활용하여 신뢰성 있는 데이터 전송을 간편하게 구현할 수 있습니다
• 웹 브라우저와 서버간의 실시간 통신에 널리 사용되는 웹 소켓 덕분에 웹 생태계와 쉽게 통합 가능합니다

단점

• MQTT보다 전력소모가 많습니다

HTTPS

• Hypertext transfer Protocol
• application layer protocol
• 클라이언트가 요청을 하기 위해 연결을 연 다음 응답을 받을때 까지 대기하는 전통적인 클라이언트-서버 모델을 따릅니다

(ref:(mozila_http)[https://developer.mozilla.org/en-US/docs/Web/HTTP])

LoRaWAN

• 장거리 광역 네트워크
• LPWAN(저전력 광역 네트워크)의 하나로, 장거리 통신 및 저전력 기능을 제공합니다

장점

• 장거리, 저전력

  단점

• 제한된 대역폭 , 느린 데이터 전속 속도
• 실시간 통신이 어렵고 연결의 일관성이 보장되지 않을 수 있습니다.