(참고: https://iot-sitewise.workshop.aws/en/introduction/what-you-are-going-to-build.html)

CloudFormation 스택 생성 (도쿄)

• Cloud9 환경
• SageMaker 노트북 인스턴스 등..

SiteWise gateway가 AWS IoT Greengrass에서 실행되고 Greengrass는 AWS IoT Core에 연결한다.

(IoT Core의 Rule Engine으로 데이터를 수집할 예정!)

→ 실습의 흐름 맛보기 랄까...

IoT에 대한 로깅 활성화

• IoT 서비스가 계정의 CW에 쓸 수 있도록 허용하려면 서비스 역할이 필요하다.
  • CloudFormation 콘솔 상 IoT ServiceRoleName 출력 세션에서 역할 이름 확인 가능하다.

AWS IoT SiteWise 설정

• 자신의 속성이 데이터 스트림과 일치하는 경우에만 데이터가 SiteWise로 수집된다.
• 데이터 수집 방법
  • OPC-UA 서버에 연결하고 이러한 서버에서 데이터를 검색하는 SiteWise 게이트웨이를 통해
  • AWS IoT Core의 MQTT 항목에 메시지를 게시하고 AWS IoT 규칙을 사용하여 데이터를 AWS IoT SiteWise로
  • BatchPutAssetPropertyValue API를 사용하여 SiteWise로 직접

먼저 SiteWise gw를 만들자.

(Greengrass 구성 요소로 게이트웨이가 실행된다.)

(data collection pack: 데이터를 수집하고 클라우드로, data processing pack: 게이트웨이가 에지에서 데이터 처리)

진행할 실습 상에서 게이트웨이는 cloud9 환경이다.

엣지 기능에서 데이터 처리팩은 비활성화!

게시자 구성의 경우는 디폴트

승인을 누르면 설치 파일이 PC에 다운로드 된다.

다운로드된 파일을 cloud9으로 업로드 한다. (/home/ec2-user/sitewise/)

cd ~/sitewise
chmod +x sitewise-workshop-Gateway.deploy.sh
sudo ./sitewise-workshop-Gateway.deploy.sh

# greengrass 상태 확인
systemctl status greengrass.service

# greengrass process 실행 확인
ps aux |grep green

# 로그 파일
sudo su -
cd /greengrass/v2/logs/

• 로그 확인
  • greengrass.log : AWS IoT Greengrass에 대한 로그
  • aws.iot.SiteWiseEdgeCollectorOpcua.log : OPC-UA 서버에서 데이터를 수집하는 SiteWise 구성 요소
  • aws.iot.SiteWiseEdgePublisher.log : 클라우드의 SiteWise 데이터 저장소로 데이터를 전송하는 SiteWise 구성 요소

OPC-UA 서버 시작을 해보자.

cd ~/sitewise/
./start-node-opcua.sh

• OPC-UA 서버가 SiteWise 데이터 수집기(aws.iot.SiteWiseEdgeCollectorOpcua) 에서 연결을 수신했다.
• 수집기의 경우 OPC-UA 서버에서 데이터를 검색하여 스트림에 기록한다.
• SiteWise Publisher는 이 스트림을 읽고 데이터를 AWS cloud의 AWS IoT SiteWise로 전달한다.

 AWS IoT SiteWise 데이터 수집

• SiteWise는 데이터를 소비하고 데이터 스트림을 자산 속성에 일치 시킨다.
  • 자산 모델 및 자산을 생성하고 데이터 스트림을 자산 속성과 연결한다.

먼저 AWS IoT SiteWise 데이터 스토리지를 확인해보자.

aws iotsitewise describe-storage-configuration

연결 해제된 데이터 저장소가 활성화 되면 위의 출력이 뜬다. → disassociated mode

(데이터 저장소가 설정된 모드는 데이터 스트림을 자산 속성과 연결하는 방식에 영향을 준다.)

데이터 수집의 경우 (실습 기준)

• Generators 1 and 2: through a SiteWise gateway
• Generators 3 and 4: through the SiteWise PUT API
• Generators 7 and 8: by using AWS IoT’s rules engine

[자산 모델링]

SiteWise 자산을 사용해 산업 운영의 가상 표현을 생성할 수 있다.

(자산: 디바이스, 장비 또는 하나 이상의 데이터 스트림을 IoT SiteWise로 보내는 프로세스)

실습의 예로 /DayOneEnergyCorp/1/Generator/Power 의 경우 1번 발전기에서 생성된 에너지 측정값이다.

(측정값을 기반으로 메트릭 생성 가능)

Asset model → Asset → Asset property

[Generator 표현]

(실습: 각 발전기는 분당 생산된 에너지와 발전기의 내부 온도를 보고, 분당 20와트의 에너지 생산 예상)

생성기 템플릿에서 아래의 측정 및 지표 정의할 예정!

• 측정: 생산된 분당 와트, 온도 및 rpm
• 지표: 5분당 총 와트, 5분당 평균 온도 및 5분당 평균 rpm

자산 모델(Asset model)을 생성해보자.

자산의 경우 템플릿을 기반으로 생성된다.(정보의 일관성 보장)

위 이미지와 같이 모델을 생성한다. (상태가 active 될 때 까지 기다리기!)

자산(Asset)을 만들어 보자.

얘도 상태가 active 확인이 되어야 한다.

데이터 스트림 연결 및 알림을 구성해보자.

(자산이 생성된 뒤 SiteWise에 수집되는 데이터 스트림을 자산 속성과 연결하는 과정이 필요하다.)

SiteWise가 IoT에 데이터를 게시하도록 하려면 관련 속성에 대한 알림을 활성화 해야한다.

나의 경우 연결 해제 모드 인 것을 위에서 확인했다.

데이터 스트림 관리를 통해 속성을 선택해 업데이트 한다.

위와 같이 데이터 스트림이 Generator-1(자산)의 속성과 연결된 것을 확인할 수 있다.

자산에 들어가 Generator-1의 모든 측정 및 지표에 대한 MQTT 알림 상태를 ENABLED로 설정

데이터 플로우를 확인해보자.

(SiteWise 게이트웨이는 OPC-UA 서버에서 스트림을 가져와 SiteWise에 업로드해야 한다.

3개의 데이터 스트림이 자산(Generator-1)에 연결된다. 알림이 활성화되어 있기에 IoT Core에 게시된다.)

SiteWise는 알림의 데이터를 토픽에 게시한다.

$aws/sitewise/asset-models/+/assets/+/properties/+

아니면 자산에서 측정 및 지표에서 최신값에 값이 표시가 되어야 한다!

데이터 생성기를 시작하려면,

# AWS IoT Core로 수집 시작
cd ~/sitewise
./sitewise-iot-ingest.py

# AWS IoT SiteWise로 수집 시작
cd ~/sitewise
./sitewise-direct-ingest.py

(추가 자산을 만들어 더 많은 데이터를 수집하려면 Generator-2는 SiteWise gw, Genterator-3는 PUT API, Generator-7은 IoT Core Rule Engine을 통해 수집된다.)

대충 이런 흐름이다...(어렵다😥)

AWS IoT SiteWise Monitor

이제 마지막으로 모니터링을 할 수 있는 환경을 만들어보자.

자산의 데이터를 모니터링하려면 포털을 생성한 뒤 프로젝트와 대시보드를 만든다.

(AWS 계정 없이도 포털을 다른 사용자와 공유가 가능하다.)

계층 구조를 위한 자산 모델 생성 가이드

너무 길어지니까.. 모니터링을 위한 포털 생성의 경우 다음 포스팅에서 진행하도록 하자...

위의 실습을 이어서 진행할 것이다.

https://realyun99.tistory.com/192

AWS Cloud에서 component를 배포하려면 먼저 recipe 파일을 확장해 S3의 component artifact를 참조한 다음 component artifact를 S3로 업로드 해야한다.

배포가 구성되면 디바이스가 S3에서 아티팩트를 다운로드 한다.

버킷을 만들고 다음 명령을 사용해 버킷 이름을 검색하는 명령어를 입력한다.

EPOCH_TIME=$(date +"%s") && S3_BUCKET=ggcv2-workshop-$HOSTNAME-$EPOCH_TIME && aws s3 mb s3://$S3_BUCKET

아래 코드 중 버킷이름을 위에서 검색했던 이름으로 변경하고 json 파일을 업데이트 해준다.

{
   "RecipeFormatVersion": "2020-01-25",
   "ComponentName": "com.example.HelloWorld",
   "ComponentVersion": "1.0.0",
   "ComponentDescription": "My first AWS IoT Greengrass component.",
   "ComponentPublisher": "Amazon",
   "ComponentConfiguration": {
      "DefaultConfiguration": {
         "Message": "world"
      }
   },
"Manifests": [
      {
         "Platform": {
            "os": "linux"
         },
         "Lifecycle": {
            "Run": "python3 -u {artifacts:path}/hello_world.py '{configuration:/Message}'\n"
         },
         "Artifacts": [
            {
               "URI": "s3://[YOUR BUCKET NAME]/artifacts/com.example.HelloWorld/1.0.0/hello_world.py"
            }
         ]
      }
   ]
}

component artifact를 업로드 해준다.

aws s3 cp --recursive /home/ubuntu/environment/GreengrassCore/ s3://$S3_BUCKET/

IoT Greengrass의 Component에서 Component 정의를 생성하는 과정이다.

cd /home/ubuntu/environment/GreengrassCore/recipes && aws greengrassv2 create-component-version  --inline-recipe fileb://com.example.HelloWorld-1.0.0.json --region $AWS_DEFAULT_REGION

# component 목록 확인
aws greengrassv2 list-components --region $AWS_DEFAULT_REGION

Pub/Sub IPC

Greengrass V2는 프로세스 간 통신을 위한 IPC SDK를 제공한다.

(custom component의 각 프로세스 간 Pub/Sub 통신이 가능하다.)

• 센서 데이터를 읽고 토픽에 계속 pub하는 component, 해당 토픽 로그를 sub하고 메시지를 수신하는 component 및 IPC를 사용하는 custom component 를 만드는 과정

먼저 Publisher를 만들어보자.

데이터를 토픽에 pub하기 위해 더미 센서를 생성해야한다.

mkdir -p ~/environment/GreengrassCore/artifacts/com.example.Publisher/1.0.0 && cd ~/environment/GreengrassCore/artifacts/com.example.Publisher/1.0.0
touch example_publisher.py dummy_sensor.py

생성된 빈 스크립트 파일을 열고 아래 언급된 파일 이름에 따라 붙여 넣는다.

# dummy_sensor.py
from random import gauss

class DummySensor(object):
    def __init__(self, mean=25, variance=1):
        self.mu = mean
        self.sigma = variance
        
    def read_value(self):
        return float("%.2f" % (gauss(1000, 20)))

if __name__ == '__main__':
    sensor = DummySensor()
    print(sensor.read_value())


# example_publisher.py
import time
import datetime
import json
import awsiot.greengrasscoreipc
from awsiot.greengrasscoreipc.model import (
    PublishToTopicRequest,
    PublishMessage,
    JsonMessage
)
from dummy_sensor import DummySensor


TIMEOUT = 10
publish_rate = 1.0

ipc_client = awsiot.greengrasscoreipc.connect()

sensor = DummySensor()

topic = "my/topic"


while True:
    message = {"timestamp": str(datetime.datetime.now()),
               "value": sensor.read_value()}
    message_json = json.dumps(message).encode('utf-8')

    request = PublishToTopicRequest()
    request.topic = topic
    publish_message = PublishMessage()
    publish_message.json_message = JsonMessage()
    publish_message.json_message.message = message
    request.publish_message = publish_message
    operation = ipc_client.new_publish_to_topic()
    operation.activate(request)
    future = operation.get_response()
    future.result(TIMEOUT)

    print("publish")
    time.sleep(1/publish_rate)

recipe 폴더와 빈파일 생성

touch ~/environment/GreengrassCore/recipes/com.example.Publisher-1.0.0.json

해당 빈파일에 아래 내용 붙여 넣기

{
  "RecipeFormatVersion": "2020-01-25",
  "ComponentName": "com.example.Publisher",
  "ComponentVersion": "1.0.0",
  "ComponentDescription": "A component that publishes messages.",
  "ComponentPublisher": "Amazon",
  "ComponentConfiguration": {
    "DefaultConfiguration": {
      "accessControl": {
        "aws.greengrass.ipc.pubsub": {
          "com.example.Publisher:pubsub:1": {
            "policyDescription": "Allows access to publish to all topics.",
            "operations": [
              "aws.greengrass#PublishToTopic"
            ],
            "resources": [
              "*"
            ]
          }
        }
      }
    }
  },
  "Manifests": [
    {
      "Lifecycle": {
        "Install": "pip3 install awsiotsdk numpy",
        "Run": "python3 -u {artifacts:path}/example_publisher.py"
      }
    }
  ]
}

다음 명령을 실행해 component를 배포하자.

sudo /greengrass/v2/bin/greengrass-cli deployment create \
  --recipeDir ~/environment/GreengrassCore/recipes \
  --artifactDir ~/environment/GreengrassCore/artifacts \
  --merge "com.example.Publisher=1.0.0"

이젠 Subscriber의 차례다. 위 과정과 비슷하니 명령어와 코드만 적어 두겠다...

# 아티팩트 폴더, 빈 스크립트 파일 생성
mkdir -p ~/environment/GreengrassCore/artifacts/com.example.Subscriber/1.0.0 && cd ~/environment/GreengrassCore/artifacts/com.example.Subscriber/1.0.0
touch example_subscriber.py

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
import time
import json
import awsiot.greengrasscoreipc
import awsiot.greengrasscoreipc.client as client
from awsiot.greengrasscoreipc.model import (
    SubscribeToTopicRequest,
    SubscriptionResponseMessage
)

TIMEOUT = 10

ipc_client = awsiot.greengrasscoreipc.connect()


class StreamHandler(client.SubscribeToTopicStreamHandler):
    def __init__(self):
        super().__init__()

    def on_stream_event(self, event: SubscriptionResponseMessage) -> None:
        message_string = event.json_message.message
        with open('/tmp/Greengrass_Subscriber.log', 'a') as f:
            print(message_string, file=f)

    def on_stream_error(self, error: Exception) -> bool:
        return True

    def on_stream_closed(self) -> None:
        pass


topic = "my/topic"

request = SubscribeToTopicRequest()
request.topic = topic
handler = StreamHandler()
operation = ipc_client.new_subscribe_to_topic(handler)
future = operation.activate(request)
while True:
    time.sleep(1)

operation.close()

# 레시피 폴더와 빈파일 생성
touch ~/environment/GreengrassCore/recipes/com.example.Subscriber-1.0.0.json 

{
  "RecipeFormatVersion": "2020-01-25",
  "ComponentName": "com.example.Subscriber",
  "ComponentVersion": "1.0.0",
  "ComponentDescription": "A component that subscribes to messages.",
  "ComponentPublisher": "Amazon",
  "ComponentConfiguration": {
    "DefaultConfiguration": {
      "accessControl": {
        "aws.greengrass.ipc.pubsub": {
          "com.example.Subscriber:pubsub:1": {
            "policyDescription": "Allows access to publish to all topics.",
            "operations": [
              "aws.greengrass#SubscribeToTopic"
            ],
            "resources": [
              "*"
            ]
          }
        }
      }
    }
  },
  "Manifests": [
    {
      "Lifecycle": {
        "Install": "pip3 install awsiotsdk",
        "Run": "python3 -u {artifacts:path}/example_subscriber.py"
      }
    }
  ]
}

# 구성요소 배포
sudo /greengrass/v2/bin/greengrass-cli deployment create \
  --recipeDir ~/environment/GreengrassCore/recipes \
  --artifactDir ~/environment/GreengrassCore/artifacts \
  --merge "com.example.Subscriber=1.0.0"

받은 메시지가 계속 표시되면 성공한 것!

tail -f /tmp/Greengrass_Subscriber.log

Local MQTT Broker

여기까지는 Greengrass 디바이스가 데이터 공급자 역할을 할 수 있도록 허용하는 로컬 Pub/Sub 개념이였다.

그러나 데이터 공급자가 Greengrass 장치 외부에 있는 경우 MQTT 형식으로 게시 대상을 도입할 수 있다.

(Greengrass 장치를 로컬 MQTT 게이트웨이로 바꾸는 브릿지)

MQTT 브로커 구성 요소 배포를 진행하면 된다..

(배포 → 개정)

위의 구성요소 구성을 클릭한 뒤 아래의 코드를 넣어주면 된다.

# Auth
{
  "deviceGroups": {
    "formatVersion": "2021-03-05",
    "definitions": {
      "MyDeviceGroup": {
        "selectionRule": "thingName: MyClientDevice* OR thingName: MyOtherClientDevice*",
        "policyName": "MyClientDevicePolicy"
      }
    },
    "policies": {
      "MyClientDevicePolicy": {
        "AllowAll": {
          "statementDescription": "Allow client devices.",
          "operations": [
            "mqtt:connect",
            "mqtt:publish",
            "mqtt:subscribe"
          ],
          "resources": [
            "*"
          ]
        }
      }
    }
  }
}

# Bridge
{
   "mqttTopicMapping": {
     "HelloWorldIotCoreMapping": {
       "topic": "clients/+/hello/world",
       "source": "LocalMqtt",
       "target": "IotCore"
     }
   }
 }

이 실습에선 Mosquitto 클라이언트를 사용해 장치를 시뮬레이션 할 예정이다.

인증 구성 요소는 AWS IoT Core에서 AWS IoT 사물로 등록되고 사물과 연결된 동일한 인증서를 제공하는 디바이스를 지원한다.

Auth component 구성을 보면 이름이 MyClientDevice 로 시작하는 장치를 허용하고 있다.

cloud9 에 아래의 내용을 입력하자.

cd ~/environment
mkdir -p devices
cd devices
THING_NAME=MyClientDevice1
aws iot create-thing --thing-name $THING_NAME
CERTIFICATE_ARN=$(aws iot create-keys-and-certificate --private-key-out $THING_NAME.key --certificate-pem-out $THING_NAME.crt --query "certificateArn" --out text --set-as-active)
aws iot attach-thing-principal --thing-name $THING_NAME --principal $CERTIFICATE_ARN

cd ~/environment
mkdir -p devices
cd devices
THING_NAME=MyOtherClientDevice1
aws iot create-thing --thing-name $THING_NAME
CERTIFICATE_ARN=$(aws iot create-keys-and-certificate --private-key-out $THING_NAME.key --certificate-pem-out $THING_NAME.crt --query "certificateArn" --out text --set-as-active)
aws iot attach-thing-principal --thing-name $THING_NAME --principal $CERTIFICATE_ARN

MQTT를 통한 기기 통신 테스트를 해보면,

동일한 터미널에서 Mosquitto 클라이언트를 설치한다.

sudo apt install mosquitto-clients

다음으로 로컬 브로커 서버 인증서엥 서명하는 CA 인증서를 검색

(클라이언트가 브로커 엔드포인트를 확인하는데 사용됨)

cd ~/environment/devices
sudo cp /greengrass/v2/work/aws.greengrass.clientdevices.Auth/ca.pem .
sudo chmod 444 ca.pem

토픽 Subscribe를 해보자.

cd ~/environment/devices
mosquitto_sub -h localhost -p 8883 -q 0 -t clients/+/hello/world --cafile ca.pem --cert MyOtherClientDevice1.crt --key MyOtherClientDevice1.key -i MyOtherClientDevice1

메시지 publish (새 터미널 열고)

cd ~/environment/devices
mosquitto_pub -h localhost -p 8883 -q 0 -t clients/test/hello/world --cafile ca.pem --cert MyClientDevice1.crt --key MyClientDevice1.key -m "{\"message\": \""$2" @ "$(date +"%m-%d-%Y-%H-%M-%s")"\"}" -i MyClientDevice1

mosquitto_sub 명령을 실행하는 터미널에 메시지가 표시되어야 한다.

(참고: https://catalog.us-east-1.prod.workshops.aws/workshops/5ecc2416-f956-4273-b729-d0d30556013f/en-US)

Greengrass 란?

• 디바이스 소프트웨어를 구축, 배포 및 관리하는데 도움이되는 IoT 오픈 소스 엣지 런타임 및 클라우드 서비스
• 디바이스가 생성하는 데이터에 따라 로컬로 작동, 기계 학습 모델 기반 예측 실행, 데이터 필터링 및 집계, 필요한 정보만 클라우드로 전송하도록 프로그래밍 가능
  • 로컬 처리, 메시징, 데이터 관리, ML 추론을 지원하는 지능형 디바이스 소프트웨어 쉽게 구축

Components

• ML 추론, 로컬 처리, 메시징 및 데이터 관리와 같은 복잡한 워크플로를 쉽게 생성할 수 있는 빌딩 블록
• Stream Manager: 로컬 및 클라우드 대상으로의 데이터 내보내기 지원
• Greengrass Core device
  • Greengrass core software를 실행하는 디바이스
  • Core device는 AWS IoT 사물, 여러 Core device를 IoT 사물 그룹에 추가해 Greengrass Core device 그룹 생성
• Greengrass Component
  • Greengrass Core device에 배포되고 실행되는 소프트웨어 모듈
  • Recipe: component 세부 정보, 구성 및 매개 변수를 정의하여 소프트웨어 묘듈을 설명하는 JSON/YAML 파일
  • Artifact: 디바이스에서 실행될 소프트웨어를 정의하는 소스 코드, 바이너리 또는 스크립트
  • Dependency: 종속 구성 요소의 자동 업데이트 또는 다시 시작을 강제할 수 있는 구성 요소 간의 관계

Deployment

• 단일 Greengrass Core device 또는 Greengrass Core device group이 될 수 있는 destination target device(엣지)에 구성 요소를 보내고 원하는 component 구성을 적용하는 프로세스
• 업데이트된 모든 component를 대상에 자동으로 적용하고 종속성으로 정의 된 다른 모든 구성 요소들을 포함
• deployment의 component 또는 component 구성에 대한 모든 업데이트가 자동으로 모든 destination targets 으로 전송됨

실습의 목표는 AWS IoT Greengrass Core software V2를 실행하는 Edge Gateway 구축하기!

• AWS IoT Greengrass Core software V2 배포 및 설정
• 에지에서 IPC(프로세스 간 통신)을 위한 사용자 지정 구성 요소 만들기
  • Publisher component 개발 및 배포
  • Subscriber component 개발 및 배포
• Lambda를 사용해 사용자 지정 component를 생성하여 IPC에서 AWS IoT Core로 엣지 데이터 가져오기
• AWS IoT Greengrass V2에서 MQTT 브리지 설정

(리전의 경우 워크숍 기반으로 진행할 것이기 때문에 도쿄(ap-northeast-1)에서 진행한다!)

CloudFormation 스택 실행

Cloud9 인스턴스 구성

: Greengrass edge runtime을 실행하기 위한 환경

임시 자격 증명을 비활성화 해준다.(cloud9 아이콘 선택 후 Preferences 클릭)

IAM user를 생성해서 해당 사용자로 AWS CLI 설정을 해준다.

나는 오류가 발생해 sudo aws configure 를 사용했다.

세부정보로 환경 변수 설정을 해주자.

# 환경 변수 설정
export AWS_DEFAULT_REGION="Region you want to use, e.g.for Ireland: eu-west-1" 
export AWS_ACCESS_KEY_ID="The AccessKeyId value of the result above"
export AWS_SECRET_ACCESS_KEY="The SecretAccessKey value of the result above"

# 환경 변수 확인
echo $AWS_DEFAULT_REGION
echo $AWS_ACCESS_KEY_ID
echo $AWS_SECRET_ACCESS_KEY

Greengrass 설정

• AWS IoT Core의 초기 설정을 수행하고 AWS IoT Greengrass V2 설치 프로그램을 사용해 Cloud9(emulating edge gateway)에 Greengrass V2 설치
  • 설치 프로그램은 사물, 정책, 디바이스 인증서를 프로비저닝
  • IoT Core에서 Greengrass 코어 디바이스 설정 및 AWS IoT Core 연결을 완료

Greengrass Core device로 들어가 코어 디바이스를 1개 생성해보자.

3단계에 보이는 명령어를 cloud9에 입력해주자.

스크립트 완료 후 Greengrass CLI 명령을 실행하고 버전이 표시되면 성공한 것!

/greengrass/v2/bin/greengrass-cli -V

Greengrass의 상태 확인을 하고 싶으면 아래와 같은 명령어를 입력하자.

# 서비스 상태 확인
sudo systemctl status greengrass.service

# 부팅 시 서비스 시작
sudo systemctl enable greengrass.service

추가적인 IAM 정책 허용이 필요하다.

• Publish your custom component (using S3)
• MQTT Bridge

위에서 생성한 정책을 GreengrassV2TokenExchangeRole에 연결 한다.

첫번째 Component 만들기

• component의 단위로 모듈식 소프트웨어를 임의로 개발하고 배포할 수 있다.
• 디바이스에 샘플 애플리케이션을 만들고 이를 구성 요소로 배포할 예정~

component artifact 생성을 먼저 진행한다.

mkdir -p ~/environment/GreengrassCore/artifacts/com.example.HelloWorld/1.0.0 && touch ~/environment/GreengrassCore/artifacts/com.example.HelloWorld/1.0.0/hello_world.py

위의 명령어를 실행하면 아티팩트 폴더와 빈 스크립트 파일이 생성될 것이다.

(아티팩트의 경로의 경우 항상 artifacts/componentName/componentVersion/. 의 형식을 따라야 한다!)

파이썬 파일에 아래의 코드를 붙여 넣는다.

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
import sys
import datetime
import time

while True:

    message = f"Hello, {sys.argv[1]}! Current time: {str(datetime.datetime.now())}."

    # Print the message to stdout.
    print(message)

    # Append the message to the log file.
    with open('/tmp/Greengrass_HelloWorld.log', 'a') as f:
        print(message, file=f)

    time.sleep(1)

component recipe 생성을 진행한다.

mkdir -p ~/environment/GreengrassCore/recipes && touch ~/environment/GreengrassCore/recipes/com.example.HelloWorld-1.0.0.json

(레시피를 넣을 폴더와 빈파일을 생성해주는 명령어)

위 단계와 비슷하게 해당 파일에 아래의 코드를 넣고 저장하자.

{
   "RecipeFormatVersion": "2020-01-25",
   "ComponentName": "com.example.HelloWorld",
   "ComponentVersion": "1.0.0",
   "ComponentDescription": "My first AWS IoT Greengrass component.",
   "ComponentPublisher": "Amazon",
   "ComponentConfiguration": {
      "DefaultConfiguration": {
         "Message": "world"
      }
   },
   "Manifests": [
      {
         "Platform": {
            "os": "linux"
         },
         "Lifecycle": {
            "Run": "python3 -u {artifacts:path}/hello_world.py '{configuration:/Message}'\n"
         }
      }
   ]
}

Component 실행 및 테스트

터미널을 새로 열어주고 아래의 로그 확인 명령어를 넣고 열린 상태로 유지하자.

sudo tail -F /greengrass/v2/logs/greengrass.log

대충 요론 느낌

Component를 Greengrass 코어 디바이스에 배포하자.

sudo /greengrass/v2/bin/greengrass-cli deployment create \
  --recipeDir ~/environment/GreengrassCore/recipes \
  --artifactDir ~/environment/GreengrassCore/artifacts \
  --merge "com.example.HelloWorld=1.0.0"

# 배포 성공 확인 로그
tail -F /tmp/Greengrass_HelloWorld.log

여기까지는 테스트를 위해 개발하는 동안 component의 로컬 배포를 만드는 과정이었고,

이제는 component의 특정 버전에 만족하면 현장에서 디바이스에 배포할 구성 요소를 준비하는 과정에 대해 실습할 예정이다.

글이 너무 길어지니 이 내용은 다음 블로그 글에서 다룰 예정~

이번에 컨설팅 할 고객 측에서 Firebase를 사용 중이고 이를 Amplify와 같은 서비스를 활용해서 AWS로 마이그레이션이 가능한지에 대한 정보를 원했다...

해당 사항과 관련한 내용을 정리해보고자 한다!

일단 마이그레이션이 가능하긴 하다.. 단지 공수가 많이 들어갈 뿐이다;;

먼저 Firebase, Amplify 두 서비스 모두 Backend 개발에 도움을 주는 느낌이다.

Firebase

• 모바일 애플리케이션 개발 플랫폼

Firebase - Amplify 기능 매치

(참고: https://bejamas.io/compare/aws-amplify-vs-firebase/#continuous-deployment)

[차이점]

• Google UI Toolkit Flutter의 경우 아무래도 같은 Google 생태계라 Firebase에 유리
  • 물론 Amplify에도 Flutter 있음
• CI/CD의 경우 Amplify가 유리
  • Firebase의 경우 delivery → deployment 과정에서 개입이 필요함(실제 배포의 경우)
  • Amplify는 알아서 실제 배포까지 적용 시켜줌
• 비용의 경우 Amplify가 조금 더 비쌀 수 있음...(계산 필수)

[관련 workshop]

https://catalog.us-east-1.prod.workshops.aws/workshops/c2c0b179-6b4e-4133-8ea7-989fd2ba71a1/en-US/prepare

결국엔 다 코드 단 작업이 필수적으로 들어가게 됨.. 공수가 많이 든다.

Google의 SDK와 AWS SDK는 다르기 때문에 이 점도 생각 해봐야한다...😅

해당 과정을 간단히 정리해보자.

마이그레이션 과정

• Firebase Auth → Cognito
  • Cognito의 사용자 마이그레이션 기능 사용
  • 사용자가 Cognito로 처음 로그인 시도할 때 Lambda를 사용해 사용자를 대신해 Firebase 인증으로 로그인 하는 방식
    • Firebase에 성공적으로 로그인하면 사용자의 자격 증명이 Cognito에 복사된다.
• Data Layer: DB, Storage를 Cloud Firestore와 동기화 상태로 유지
  • Firestore Data → DynamoDB
    • 데모용으로 작은 문서 지향 스키마를 마이그레이션 해볼 것
    • 실제 상황의 경우
      • Step Functions를 사용해 인프라 배포 중 자동으로 수행되게..
      • Lambda 함수를 오케스트레이션하여 Firestore 데이터를 일괄적으로 읽고 SQS를 사용해 대기열을 통해 DynamoDB에 대한 쓰기를 하게끔
  • Google Cloud Storage → S3
    • Google Cloud SDK를 사용해 S3에 동기화
  • Firestore listener service
    • 변경사항을 DynamoDB에 전파 및 AppSync no-op 변형을 트리거 해 연결된 클라이언트에 업데이트 푸시
  • 동기화, 리스너의 경우 Docker를 사용해 컨테이너화 후 Fargate를 활용해 실행할 것
• App Tier
  • AppSync는 GraphQL을 통한 실시간 구독 지원 → Firestore Listener 사용하던 곳에 AppSync 구독

결론적으론, 마이그레이션은 가능하지만 생각보다 귀찮은 과정이 필요하다.

Amplify와 Firebase에 익숙치 않다면 각각의 서비스 공부 과정도 필요하다.

 내가 걱정되는 부분은 Data Migration 과정에서 데이터 양이 많다면... 시간과 복잡도가 증가할 듯

(중간 중간 체크 과정이 필요하며 신중하게 진행할 것)

또, Amplify API 및 SDK로의 코드 변경이 필수.. 해당 과정 공수가 많이 들 듯?

❗ 그냥 Amplify에서 새로 구축하는 것도 하나의 방법일 듯 싶다...ㅎㅎ ❗

2022.11.28 ~ 12.02 까지 라스베이거스에서 진행된 re:Invent에서 다룬 내용들 중 내가 관심 있는 것들만 정리해볼까 한다.

Lambda SnapStart

https://aws.amazon.com/ko/blogs/aws/new-accelerate-your-lambda-functions-with-lambda-snapstart/?did=ap_card&trk=ap_card 

• 특정 Lambda 함수에 대해 Lambda SnapStart를 활성화한 후 함수의 새 버전을 게시하면 최적화 프로세스 트리거
• 프로세스는 Init 단계에서 실행되며 메모리 및 디스크 상태의 변경할 수 없는 암호화된 스냅샷을 가져와 재사용을 위해 캐시
• 이후 함수가 호출되면 필요에 따라 캐시에서 chunk로 상태를 검색하여 실행 환경을 채우게 됨
• → 해당 프로세스를 통해 새로운 실행 환경을 만드는데 더이상 전용 Init 단계가 필요 없음(호출 시간이 더 빨라진다)
• Coreoot(java11) 런타임을 사용하는 Java 기능을 지원

Amazon CodeCatalyst

https://aws.amazon.com/ko/codecatalyst/?did=ap_card&trk=ap_card 

https://codecatalyst.aws/explore?trk=cb9f568a-9476-40f7-92d7-71dcaa59c9fc&sc_channel=newsletter 

• 애플리케이션을 신속하게 구축하고 제공하기 위한 통합 소프트웨어 개발 서비스
  • (이슈 관리 + 코딩 + 빌드 + 테스트/배포) - 이와 같은 과정을 연결하고 자동화
• CodeCatalyst project blueprints: CI/CD, deployable code, issue tracking 등 자동으로 셋업
• CodeCatalyst Dev Environments: 사전 설치된 종속성 및 언어별 패키지로 자동 생성

Amazon CloudWatch Internet Monitor

https://aws.amazon.com/ko/cloudwatch/features/?did=ap_card&trk=ap_card 

• 인터넷 문제가 AWS 에서 호스팅되는 애플리케이션과 사용자 간의 성능 및 가용성에 미치는 영향에 대한 가시성을 제공, 이러한 문제를 진단하는데 걸리는 시간을 줄여줌
  • ex) 다른 AWS 서비스로 전환하거나 다른 AWS 리전을 통해 워크로드 트래픽 경로를 재지정
• EventBridge로도 상태 이벤트 전송해 알림 설정 가능
• AWS 네트워크 문제 발생 시 Health Dashboard 알림 수신 되는데 문제에 대해 AWS 측에서 진행 중인 단계 확인 가능

Amazon VPC Lattice

https://aws.amazon.com/ko/blogs/korea/introducing-vpc-lattice-simplify-networking-for-service-to-service-communication-preview/

https://aws.amazon.com/ko/vpc/lattice/?did=ap_card&trk=ap_card 

• 서비스 간의 통신을 지속적으로 연결, 모니터링 및 보호하는 애플리케이션 계층 서비스
  • 네트워크 액세스, 트래픽 관리 및 모니터링에 대한 정책을 정의
• 모든 AWS 컴퓨팅 유형(인스턴스, 컨테이너, 서버리스 함수)에 배포 일관성을 제공 → 서비스(소프트웨어) 연결
• 세분화되고 자세한 트래픽 제어를 적용해 blue/green, canary 스타일 배포 지원
• 요청 유형, 트래픽 볼륨, 오류 발생률, 응답 시간 등을 수집하는 자세한 액세스 로그와 지표로 서비스 간 통신을 모니터링하고 문제 해결 가능

AWS Verified Access

https://aws.amazon.com/ko/verified-access/?did=ap_card&trk=ap_card 

• VPN을 사용할 필요가 없어 최종 사용자의 원격 접속 경험을 간소화, 관리 복잡성 감소
• 각 액세스 요청을 실시간으로 확인하고 액세스가 허용된 애플리케이션에만 사용자를 연결

AWS Application Composer

https://aws.amazon.com/ko/application-composer/?did=ap_card&trk=ap_card 

• 배포 가능 IaC로 지원되는 AWS 서비스에서 서버리스 애플리케이션을 시각적으로 작성하고 구성 가능
• CloudFormation 또는 AWS SAM 지원

Bastion Host에서 Private EC2 Windows로 접속하는 과정 정리를 해보려 한다..

위와 같이 구성을 먼저 해두자.

 EC2 Windows 의 SG를 바꿔주자.

(소스의 경우 bastion-sg로 지정)

MobaXterm으로 접속

Remote host의 경우엔 windows server의 private ip를 적으면 된다.

SSH gateway에는 만들어두었던 bastion host의 public ip와 key pair를 넣어주자.

RDP 접속 비밀번호의 경우 인스턴스 연결에서 RDP 클라이언트를 통해 key pair를 넣고 비밀 번호를 받자..

접속 성공!

위의 방법 말고도 Fleet Manager를 사용해 연결이 가능하다!

https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-rdp.html

• SSM agent 설치가 필요하고 최대 세션 시간은 60분이다! (아니면 세션 종료 전에 갱신을 선택해 타이머를 다시 시작한다)
• 기본적으로 동일한 AWS 계정 및 AWS 리전에서 최대 5개의 동시 Fleet Manager RDP 연결을 가질 수 있으며 추가 사용을 위해선 할당량 증가를 요청해야함!