TRACK 1 (5G Technology) 초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기 : 방영우 KT

1. 초초초 5G IoT 플랫폼 개발 이야기
(초고속, 초저지연, 초연결)

2. Contents
1 IoT 플랫폼이란?
2 5G 란?
3 5G IoT플랫폼 목표 모델
4 5G UseCase
5 도전 초초초
6 개발자 분들께 드리고 싶은 말

3. IoT 플랫폼이란?
IoT(Internet Of Things) : 각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술
수 많은 IoT 장치 들은 어디에 연결되는 것일까요 ?
2020
Y
“200억 개의 Things”

4. IoT 플랫폼이란?
국내외 많은 기업들이 다양한 형태의 IoT 플랫폼을 개발하고 있음
IoT 플랫폼 : IoT 서비스 기반 기술 제공 (IoT 장치 연결 및 데이터 관리 등)

5. IoT 플랫폼이란? - KT IoTMakers
IoT에 최적화된 아키텍처 구조로 다양한 IoT 서비스를 수용하고 확장할 수 있는 기반을 제공
다양한 프로토콜 연결 지원, 지능형 룰 엔진, 대시보드 등 IoT 핵심 서비스 기술 지원
손쉬운 디바이스 연결/관리
• 손쉬운 디바이스 연동표준/SDK
• 소물인터넷 경량 SDK 제공
• TCP, HTTP, MQTT, CoAP 지원
• 디바이스 인증 및 장애 관리
지능형 룰엔진 & Analytics
• 지능형 룰 엔진 기반 이벤트 및 워크플로우
• 머신러닝 기반의 IoT Data Analytics
대용량 데이터 프로세싱
• 대용량 데이터 실시간 분산 처리
• 실시간 수집데이터 모니터링 및
디바이스 실시간 제어
서비스 개발 지원
• 어플리케이션 개발을 위한 Open API 제공
• App SDK 및 개발 가이드 제공
• 레퍼런스 앱 및 튜토리얼 제공

6. 5G 란? – 상용화
5G 관련 서비스를 개발할 수 있는 네트워크 인프라 기반 마련

7. 5G 란? – KT 5G 서비스

8. 5G 란? – KT 5G 서비스
IoT기반 다양한 5G 서비스의 등장

9. 5G 란? – 5G Spec
ITU(국제전기통신연합)에서 5G 3대 서비스 시나리오와 8대 핵심 성능지표를 제시
3대 서비스 시나리오 별 요구되는 핵심 성능지표가 다름
출처 : ITU(International Telecommunication Union)
- ITU(국제전기통신연합) : 5G 비전 및 목표에 따른 요구사항을 제시
IoT플랫폼 관련 주요 서비스 시나리오
<3대 서비스 시나리오>
초연결 (mMTC)
Massive Machine Type
Communications
초저지연&초고신뢰 (URLLC)
Ultra-high Reliability
& Low Latency Communications
초고속 (eMBB)
Enhanced Mobile Broadband
<8대 핵심 성능지표>
최대 연결 수
106 devices/km2
전송지연
1ms
이동성
500km/h
주파수효율
3x
100Mb/s
사용자 체감
전송속도
20Gb/s
최대
전송속도
네트워크
에너지 효율
100x
면적당 용량
10Mbps/m2

10. 5G IoT 플랫폼 목표 모델
5G 네트워크만 도입되면
5G 서비스가 실현이 될까요?

11. 5G IoT 플랫폼 목표 모델 – 5G 서비스 이전의 플랫폼
5G 이전 서비스를 위한 플랫폼 성능은 이 정도면 충분 했습니다
- VM당 2만 Things 상시 연결
- 데이터 수집/응답 : 20ms
- 데이터 수집/룰 판단/제어 명령 전송 : 100ms
- 데이터 전송 실패 시 재전송

12. 5G IoT 플랫폼 목표 모델 – 5G 서비스를 위한 IoT 플랫폼
우선
순위
항목 5G 네트워크 요구사항 5G IoT 플랫폼 목표 모델 비고
1
초연결
초저지연
초고신뢰
5G IoT플랫폼 목표 모델
※ 기능/비기능 목표 원칙을 정하고 개발 합시다
- 지속적인 요구사항 추가/변경은 최초 시스템 개발의 목적을 희석 시킬 수 있음
- 시스템 개발 목적이 변질되지 않게 기능/비기능 목표(원칙)를 정립하고 개발하자
5G 네트워크의 성능을 뒷받침 할 수 있는 고성능의 IoT 플랫폼이 요구 됨
요구사항에 부합하는 기능/비기능 모델(원칙)을 정의

13. 5G Use Case
앞서 정의한 초초초 목표 플랫폼을 활용하고 검증할 수 있는 Use Case (활용사례) 도출 필요
NGMN 에서 제시하는 5G Use Case Family
출처 : NGMN(Next Generation Mobile Networks Alliance)
초초초 5G IoT플랫폼 관련 영역

14. 5G Use Case
다양한 5G Use Case 후보 군 중 플랫폼 적용 개발 대상 후보 선정

15. 5G Use Case
커넥티드 카 Use Case를 통해 초초초 5G IoT플랫폼을 활용하고 검증하도록 함
- 초연결, 초저지연, 초고신뢰 모두 요구됨
- 5G IoT 서비스를 가장 효과적으로 보여 줄 수 있음
- 다양한 상세 시나리오를 도출 가능
상세 활용 시나리오

16. 5G Use Case
커넥티드 카 관련 룰 판단 시나리오를 위해 Clean 한 데이터 디자인 및 세부 시나리오 도출

17. 도전 초초초
초연결, 초저지연, 초고신뢰를 가능하게 하는 기반 기술들
 오픈소스 벤치마킹 및 선정
 Local Memory Cache 활용 방안 (Distributed Cache)
 비동기 벌크 처리 방안
 Central-Edge 구조를 통한 I/O 부하 개선 방안
 부하테스트 방안 및 OS 설정 Tip
 성능 측정 결과

18. 도전 초초초 – 오픈소스 벤치마킹
오픈소스 사용 목적에 맞는 선정 기준 우선순위를 정하고 관련 벤치마킹 진행
오픈소스 도입할 때 선정 기준이 있나요?
- 사용하기가 편리해서?
- 지원하는 기능이 풍부해서?
- 안정적으로 동작해서?
- 성능이 빨라서?
- 대기업에서 사용해서? (Facebook에서 쓴다더라.. Twitter에서 쓴다더라..)
- 사람들이 많이 써서?

19. 도전 초초초 – 오픈소스 벤치마킹 (Cache 조회 성능비교)
플랫폼 내 초저지연을 필요로 하는 기능들은 1회 이상 Cache 조회를 하고 있음 -> 가장 빠른 Cache 필요
실 사용 데이터 기반으로 성능 측정 (필드 수, 데이터 크기, 데이터 분포도 등)
측정 기준
측정 대상 Redis, Redis+Json Parse, Apache JCS, Google Guava, Ehcache, Java HashMap
측정 기준
기준데이터 : 장치 데이터 100,000 건
: 필드 총 21개, row 당 약 1,000byte
10만 건 데이터 조회 총 소요시간측정
: 데이터 순차적 조회하여 시간 측정 (miss match 성능 고려 X)
측정 장비 사양 CPU : Intel Core i7 4Core @2.60GHz / RAM : 8GB / Storage : SSD
측정 결과
Redis
Redis
(+json parsing)
Apache JCS
Google
Guava
EHcache Java HashMap
평균 소요시간 4,196 5,745 64 56 45 37
TPS 23,834 17,406 1,562,500 1,785,714 2,227,171 2,732,240
23,834 17,406
1,562,500
1,785,714
2,227,171
2,732,240
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000

20. 도전 초초초 – 오픈소스 벤치마킹 (Geometry 연산 성능)
5G 커넥티드카 UseCase 에서는 Geometry 관련 룰 판단 처리가 필요
초저지연 룰판단 및 제어(5ms이내 처리)를 하기 위한 Geometry 오픈소스 선정 필요
기준데이터 서울 내 10,000 개 좌표(Point)
측정항목
1. 디바이스 간 거리계산
2. 특정 구역 진입 여부(Polygon within)
사양 CPU : Intel Core i7 4Core @2.60GHz / RAM : 8GB / Storage : SSD
거리계산
소요시간
특정 구간 진입 여부 판단 소요시간
비고
1만 디바이스
특정 구역 100개
(match 2)
특정 구역 1,000개
(match 2)
특정구역 10,000개
(match 3)
JTS 7.000567 3.43466 4.124746 6.259003
많은 오픈소스에서 JTS 활용(Spark, hadoo
p, Hbase, Avro, cassandra, Spatial4J, Ge
otools 등)
JTS (QuadTree) - 3.046023 3.597443 4.624223
Polygon 수가 늘어도 처리속도 크게 늘지
않음
Spatial4J 1.011477 3.77692 4.838948 6.532626
Polygon 계산 시 UTM 단위 미지원
(WGS84 처리)
ESRI 32.531882 51.709122 57.721864 95.603764
JTS (QuadTree) +
자체개발 Java Util
1.020288 0.7625 0.8006 0.8173
JTS의 QuadTree 를 통해 1차 필터링 후 자
체개발 Util 을 통해 연산
Java AWT 1.395012 0.521738 1.107012 4.268978 double 형 미지원으로 오차 발생
단위(ms
)
측정 기준
측정 결과

21. 도전 초초초 – 오픈소스 벤치마킹 (최대 세션 연결)
초연결 요소 기술 테스트 (VM당 10만 Things 연결 가능 여부 확인)
측정기준 : 일정 간격으로 신규 세션 체결 및 데이터 전송(Echo)
Connection 주기 10ms
Connection 설정 Connection timeout 2초, Read Timeout 2초
데이터 전송 주기(세션별) 60초
데이터 크기 500 byte
측정 장비 사양
CPU: Intel(R) Xeon(R) CPU E5-2609@2.40GHz 4Core
RAM: 32GB ( JVM 4GB 할당 )
OS: Ubuntu 12.04.4 LTS
TCP OpenSource Netty 4.1.2 (NIO Thread: 30)
네트워크 구성
60,000 Session
60,000 Session
60,000 Session
측정 결과 : 18만 세션 연결 시에도 안정적으로 유지 가능
120,000 세션 이하 안정적으로 동작
120,000 ~ 180,000 세션 안정적으로 동작
180,000 세션 이상 미테스트
CPU 사용량 각 Core 당 10~30% (4core 기준 45/400 % 이하 유지)
Client Server

22. 도전 초초초 – 오픈소스 벤치마킹 (Json Parsing 성능 비교)
데이터 수신/전송 시 총 2회 이상 Json Parsing 을 함 -> 가장 빠른 Json Parser 필요
실 사용 데이터 기반으로 성능 측정 (필드 수, 데이터 크기, Nested Object 여부, 재사용 등)
측정 대상
Gson 2.8.2
Jackson 2.9.4
측정 기준 각기 다른 Size Data를 100,000 회 Serialize / Deserialize 처리
측정 장비 사양 CPU : Intel Core i7 4Core @2.60GHz / RAM : 8GB / Storage : SSD
테스트 데이터 1 153byte (key 7) Single
Object테스트 데이터 2 297byte (key 13)
테스트 데이터 3 552byte (key 21) Nested Object
depth 2테스트 데이터 4 1,038byte (key 32)
1 Thread(소요시간 ms) 10Thread (소요시간 ms)
비고
153byte 297byte 552byte 1,038byte 297byte
GSON(reuse) 779 1,030 1,493 2,160 1,950
객체재사용O
JACKSON(reuse) 995 1,022 1,370 1,633 1,600
GSON 2,950 3,150 6,354 - -
객체재사용X
JACKSON 11,941 12,105 20,535 - -
측정 결과
- 300 byte 이하에서는 Gson이 빠르며, 300 byte 이상에서는 Jackson이 빠름
- 객체 재사용은 필수이며, 멀티 쓰레드 처리 시 Jackson이 성능 우위를 보임
측정 기준

23. 도전 초초초 – Local Memory Cache 활용 방안
Data Access 시 Network I/O를 대기하는 것은 초저지연 영역에서는 엄청난 지연을 초래
초저지연 성능 확보를 위해 Network I/O가 없는 Local Memory Cache 사용
RDBMS
Remote
Memory Cache
Local Memory Cache
(Distributed Cache)
4,704 23,834 17,406
1,562,500
1,785,714
2,227,171
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
Postgres Redis Redis
(+parse json)
Apache JCS Google
Guava Cache
EHcache
TPS
처리 성능 측정 결과
Network I/O 미발생Network I/O 발생

24. 도전 초초초 – Local Memory Cache 활용 방안
Local Memory Cache Data Clustering을 위한 Event Driven Architecture

25. 도전 초초초 – 비동기 벌크 처리 방안 (Async Non-Blocking Bulk Process)
In Memory Queue를 활용한 비동기 병렬 처리 방안
벌크 처리를 통해 효율적인 I/O 처리 (DB Batch, Network I/O, File Write I/O 등)
패킷 수신 복호화 패킷 파싱
이력
저장(DB)
Queue
적재 요청(단건)
적재 처리(묶음)
비동기 벌크 처리 구조
비동기 벌크 처리 예시) 데이터 라우팅 기능을 가진 모듈의 처리 시퀀스
… 라우팅
데이터 전송
Queue
데이터 전송 요청(단건)
데이터 전송 처리(묶음)
응답생성 암호화 응답전송
1 2
3
3 4 5 6 7 8
6

26. 도전 초초초 – 비동기 벌크 처리 방안 (구현 예시)
Java Blocking Queue를 이용한 벌크 처리 구현 (Consume -> 벌크 처리 구간)
private BlockingQueue<T> queue = new ArrayBlockingQueue<T>(MAX_QUEUE_SIZE);
@Override
public void run() {
while(!Thread.currentThread().isInterrupted()) {
List<T> objects = new ArrayList<>();
int bulkSize = 0;
while(queue.size() > 0) {// 벌크처리를 위한 묶음
T object = queue.poll();
if(object == null) break;
objects.add(object);
if(++bulkSize >= MAX_BULK_SIZE) break; // overflow 방지 Paging 처리
}
if(objects.size() > 0) {
bulkProcessor.processBulk(objects); // 묶음데이터 벌크 처리
}
if(queue.size() == 0) { // queue에 잔여 데이터가 있으면 sleep 하지 않음
try {
Thread.sleep(bulkIntervalMillis); // 묶음 처리를 위해 Sleep 상태로 대기
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
}

27. Engine LayerEngine Layer
도전 초초초 – Central-Edge 구조를 통한 I/O 부하 개선 방안
플랫폼 내 Central-Edge 구조를 통해 초저지연 룰 판단 처리
- 데이터 처리 유형에 따라 Central-Edge 간 유기적 처리
- Edge에서 처리할 경우 Network I/O 절감을 통해 초저지연 처리 가능
Connectivity Layer#01
시스템 코어
…
Connectivity
Layer#N
Edge
Engine
Message Queue
…
Connectivity
Layer#N
Message Queue
Engine Central Engine
Connectivity Layer#01
시스템 코어 시스템 코어
Central – Edge 구조 예시)
Edge
Engine
IoT 장치 IoT 장치
<AS-WAS : Engine Layer 에서 처리> <TO-BE : 데이터 유형에 따라 Connectivity Layer 에서 처리>

28. 도전 초초초 – 부하테스트 방안 및 OS 설정
초연결 & 초저지연 환경 구성 및 부하 테스트
부하테스트를 위한 Linux 커널 파라미터 설정 Tip
- threads-max : 시스템 전체의 최대 Thread 수 (cat /proc/sys/kernel/threads-max)
- net.ipv4.ip_local_port_range : 클라이언트 소켓을 할당할 수 있는 포트 범위 (sysctl
net.ipv4.ip_local_port_range)
- open files : 프로세스가 가질 수 있는 open된 파일(Network Socket포함) 수 (ulimit –an)
- max user processes : 유저 별 최대 생성 Thread 수 (ulimit –an)
부하테스트 환경 구성
- 총 100,000 Session 연결
- 부하테스트를 위한 Load Runner 자체 개발
(오픈소스로 TCP AlwaysOn 처리가 힘듦: Apache JMeter, Ngrinder 등)
- TCP AlwaysOn Load Runner Client 로직
1) 세션연결
2) 장치 인증
while(true) {
3) 수집 데이터 전송
4) Sleep
}

29. 도전 초초초 – 성능측정 결과 (초초초는 계속 진행 중...)
CPU 사용량
메모리 사용량
처리 성능

30. 개발자 분들께 드리고 싶은 말 – 첫 번째
기능/비기능 목표 원칙을 정하고 개발 하자
ex) 경로탐색엔진 설계 목표(원칙)
1. 목표 원칙 설정
하고 개발하자
Tips
- 지속적인 요구사항 추가/변경은 최초 시스템 개발의 목적을 희석 시킬 수 있다
- 목표가 변질되지 않게 하기 위해 기능/비기능 목표(원칙)를 정립하고 개발하자
우선순위 분류 목표(원칙)
1
응답시간 최대 1초 이내
동시처리 성능 100 TPS
지원 노드/링크 수 최소 1000만개
2
경로탐색 옵션 수 4개 이상
경로탐색 유형 자동차, 자전거, 도보 지원

31. 개발자 분들께 드리고 싶은 말 – 두 번째
비즈니스 관점의 Insight를 가지고 바라보자
- 비즈니스적으로 가치 있는 기능에 우선순위를 둘 것
- 개발자가 아닌 고객 입장에서의 Needs를 생각해보자
- 개발 공수에 얽매여 생각하지 말자
-> 틀에 갇힌 수준의 기능/비기능만 도출 될 수 있다
- 자원과 시간은 한정적이므로 가치 있는 곳에 투자하자
1. 목표 원칙 설정
하고 개발하자
2. 비즈니스 인사
이트 키우자
Tips

32. 개발자 분들께 드리고 싶은 말 – 세 번째
Domain Knowledge 의 중요성 인지하기
1. 목표 원칙 설정
하고 개발하자
2. 비즈니스 인사
이트 키우자
3. Domain 지식
습득하자
Tips
- 고객이 원하는 Domain에 대한 요구사항/기능을 수용해서 시장에서 플랫폼 가치를 확보 하자
- 개발자의 입장에서 공통 기능만을 처리하는 플랫폼을 만들고 싶고, 특정 도메인에 종속되는
요구사항이나 기능을 수용하고 싶지 않을 수 있지만 플랫폼의 가치를 높이기 위해 고객이 원하는
도메인을 습득하고 적극 수용하자
- 도메인 지식 습득을 꺼려하지 말고 적극적으로 공부하고 분석하여 적용하자

33. 개발자 분들께 드리고 싶은 말 – 네 번째
1. 목표 원칙 설정하
고 개발하자
2. 비즈니스 인사이트
를 키우자
3. Domain 지식 습
득하자
4. Project가 아닌
Product를 개발하자
Tips
일회성 Project Product
VS
일반화
국제표준 기반
확장성
- 지속적으로 업그레이드 가능한 확장성 있는 프로그램을 개발하자
- 본인이 만든 결과물이 곧 본인의 가치를 만들어 낸다
※ 모든 IT개발에 해당되는 것은 아닙니다
“어차피 안 쓸꺼야”
“솔루션도 아닌데 뭐”
“누가 보겠어?”
“돌아가기만 하면 돼”
경쟁력 있는 IT시스템 개발을 위해서는 일회성 Project가 아닌 Product를 만든다는 마인드로...

34. Q&A