[AWS Dev Day SEOUL 2019] keynote

AWS 행사에는 참 많은 개발자들이 모인다.
2019년 9월 26일 목요일, 서울대학교 글로벌공학교육센터에서 개최된 Dev Day는 더더욱 그랬다.

이번 행사는 Dev Day로 말그대로 '개발자'를 위한 행사이기 때문에, 특히나 더 개발세션의 난이도가 높고 지난 AWS Summit 세션에서 다뤘던 내용을 그대로 들고나온 경우에도 좀 더 심화된 내용을 다뤘다.

 

다양한 부스에서 주제별 세션들이 열려서 적용사례도 안내하고 실습 워크샵도 4개나 개설되었다.
물론 다양한 세션을 다 들을 수도 없거니와 관심있는 세션은 한정적이지만... 그래서 AWS 행사에 오면 기조연설은 꼭 집중도있게 듣고자 한다. 

소개하는 기술에 대해 내가 알고있지 않고 잘 모르는 개념이라고 하더라도, 보고 듣는 것만큼 큰 경험은 없다.
이런 기회가 아니었다면 새롭게 출시된 기술에 대해 내가 알 수 있는 방법은 하나하나 찾아보지 않는 이상 없다고 봐야지.
기조연설을 듣다보면 현재 어떤 기술까지 클라우드 환경에서 구축이 되어있는지, 중점적으로 밀고 있는 기술이 어떤것인지. 현재와 어느정도의 미래를 내다볼 수 있다는 점에서 좋은 시간이라고 본다.

 

특히 이번 기조연설을 맡은 AWS 신기술 부문 책임자인 Olivier Klein는 10년 이상의 실무 경험을 토대로 다양한 데모를 직접 시연해줬기에 기술의 개념적인 부분과 실 사용 사례까지 볼 수 있어서 굉장히 유익한 시간이었다.

AWS Summit 만큼 열정넘치게 작성하진 못하겠지만, AWS Dev Day keynote 내용에 대해 간략하게 정리해본다.

 

 

 

[AWS Dev Day SEOUL 2019] keynote

 

 

- 다양한 디바이스가 출시. 서비스는 여러 디바이스에서 사용이 가능해야하며, 디바이스별로 소통이 가능해야 함.
- 매일 새로운 것이 생겨나고 있는 상황, 매우 빠른 속도로 혁신이 일어나고 있다.
- 속도를 따라가야 살아남을 수 있음. 혁신 = 생존
- Innovation Flywheel (혁신의 순환구조)
: 실험 > 피드백 > 새로운 아이디어 > 아이디어를 기반으로 다시 실험하는 과정의 반복

위와 같은 순환구조를 보듯이, 실험을 통해야만 발명이 가능하다.
실험비용을 낮추기 위해, 앱 디자인을 모던하게 구성한다면 실험 비용을 낮출 수 있다.

기존의 앱 디자인 구조 중 Hard한 업무는 Cloud native한 방식으로 변경해서 업무 부담을 줄일 수 있다.

 

1) Microservices
기존의 전통적인 방식의 Monolith한 개발 방식은 'Does everything' 하나에서 모든 것을 처리했다면, 작은 단위로 쪼개진 구성의 Microservices는 'Does one thing' 각 단위별로 목적했던 한 가지의 업무를 처리한다.
개발자는 독립적으로 microservice를 만들 수 있고, 각 서비스들은 API, Event Messaging 서비스 등을 통해 소통이 가능하다.

* Integration options from AWS
AWS에서 제공하는 통합 옵션은 세 가지 형태로 구성된다.

- Client to Service
- Service to Service
- AWS Step function을 이용한 오케스트레이션 : 마이크로서비스 간의 통신을 조율할 수 있음

* Microservice Architecture
- CODE + SDKs + Datastores
- 완벽한 DB란 없기 때문에, 별도의 datastores를 선택해서 각 Microservice 별로 구현 (AWS에서 제공하는 다양한 DB 방식을 선택할 수 있음)
- 기존의 모놀리틱 서비스가 하나의 DB 형태를 사용했다면, 마이크로서비스는 각각의 구현하는 기능에 맞춰 DB를 다르게 쓸 수 있음. 

 

2) Serverless?

- 인프라에 대해서 관리하지 않음
- 자동으로 스케일 업/다운이 가능함
- 사용한만큼만 돈을 지불함
- 높은 가용성

Serverless는 적은 노력으로 민첩하게 변화에 대응할 수 있다.
운영하는 인원들은 인프라에 대한 고민없이 Business Logic + API에 대해서만 고려하면 됨
기존에 고려해야 했던, 메시징, 오케스트라 등 인프라 관련내용은 고민할 필요없이 AWS가 관리할 수 있음.

 

• AWS Lambda
  - 서버리스 환경에서 이벤트 중심 코드 수행 
  - Lambda layer를 통해, 하나를 만들어서 여러 마이크로서비스에서 구현 가능해짐
• AWS Fargate
  - 컨테이너를 위한 서버리스 컴퓨팅 엔진
  - 순수하게 코드에만 집중할 수 있음

 

3) 코드 배포

배포를 위한 수행순서인 Pipeline은 동일하나, 하나의 단위의 큰 서비스를 배포하는 것과 달리 각 마이크로서비스 별로 배포 Pipeline을 따르게 됨

평균적으로 초당 1.5건의 배포가 일어날 정도로 매우 자주, 잦은 배포가 일어나고 있음.
잦은 배포에 대한 부담이 있을 수 있는데 AWS CodePipeline의 경우 배포 서비스 자체가 자동화되어있음. 해당 프로세스는 자동으로 롤아웃 그리고 문제가 생겼을 경우, 롤백까지 가능함.

 

(정말 화질구지다. 핸드폰을 하루빨리 바꾸도록 하겠다 ^_ㅜ)

배포 뿐 아니라, AWS는 보안 측면에서도 부족함이 없도록 다양한 서비스를 제공함.
특히 Detective Control 측면을 중요하게 생각함. 변경사항에 대해 이력 관리를 하고, 룰에 대한 검증을 거칠 수 있음.

 

 

DEMO 

1. Photogrammertry

사진 측량, 여러 각도에서 찍은 사진을 기반으로 실제 대상의 크기를 측량할 수 있는 기능
이 기능을 AWS의 기술을 이용해서 구현해서 보여주겠다고 한다.

DEMO 시연자가 본인 얼굴 사진을 다양한 각도에서 찍고, 해당 사진들을 이용해서 측량을 진행한다.
측량방식은 사진에 표현된 거리를 계산하고 렌더링 진행, 와이어 프레임 구성. 어느 정도의 모양이 완성되면 얼굴처럼 보이도록 텍스쳐를 추가해주면 실제 측량이 가능한 형태가 된다.

이러한 과정을 거쳐서 미리 준비해 온 데모를 시연했는데, AWS Sumerian에서 HTML5, Web GL 스탠다를 기반으로 화면을 만들어서 각자 접속해볼 수 있도록 URL을 제공해주었다.

물론 PC, 핸드폰 관계없이 열어볼 수 있었음. 아래의 URL은 당시 공유했던 내용인데 계속 열려있을지는 의문...

http://bit.ly/oli-3d

Oli-Meshed

 

 

 

Edge and Robotics

IoT에 대해 이야기할 때, 이제는 Robot을 빼고 얘기할 수 없다. 많은 산업에 걸쳐서 로봇이 일을 대신하고 있음.

AWS에서 만든 드론은 이제 조종 없이 자율비행이 가능한 수준에 이름. 해당 드론은 물류업에 투입할 계획
로봇을 위한 OS인 ROS가 있기 때문에, 과거에 비해 개발이 손쉬워짐

AWS Robomaker : 개발, 테스트, 시뮬레이션까지 가능하도록 기능을 제공

 

DEMO

아래 첨부한 사진을 보면 웹캠을 장착한 작은 로봇을 이용해서 데모를 진행하는 모습이다.

해당 로봇이 사방으로 쏘는 레이더를 통해 거리를 측정하는 기능이 있다고 한다.
이 로봇을 미로 속에 넣어두고 길을 찾아가는 네비게이션 기능을 시연해보였다.

 

 

로봇이 감지하는 거리 측정을 비쥬얼라이제이션 툴을 통해서 길을 찾아가면서 이동하는 것을 볼 수 있었고, 각 위치별로 측정된 거리가 어디까지인지를 볼 수 있었다.

최종적으로 로봇이 돌아다닌 공간의 영역에 대해서 뷰 할 수 있음 (첨부한 사진의 왼쪽 영역 참고)

 

 

 

Distributed Application - 분산형 애플리케이션

다양한 디바이스가 많아졌고, 서로 연결되고 같은 에코시스템을 공유하게 됨.
글로벌 사용자들은 상호연결하고자 하는 욕구가 있으나, 물리적인 환경 자체는 변화하지 않았기 때문에 새로운 방법이 필요함.

1. 분산 데이터 스토어
   관계형, 비관계형 등 각 DB를 사용함에 따라 리전간 데이터 복제, 이동이 가능해짐
   람다를 이용해서 코드 로직 공유가 가능해짐

2. 네트워크 커넥션 핸들링
   AppSync와 관련하여, 네트워크간 상호 연결이 필요해짐
   커넥션이 없어도 유연하게 연결될 수 있도록 함. 커넥션이 연결되어 있지 않더라도 로컬DB에 저장했다가 커넥션이 연결되면 다시 데이터 송수신을 진행하는 방식

   AWS Greengrass - 로직을 각 엣지에 해당하는 사용자 (농장) 에게 보냄. 네트워크 연결이 불량해도 관계 없음. 연결되었을 때 송수신을 다시 진행하면 됨

 

Data Centrity - 데이터 수집, 중앙화

이제는 데이터가 자산이다, 용량을 차지한다고 하더라도 이를 비용으로 인식하면 안된다.
데이터를 지우지 않고, 더 많은 사용자가 사용하게 하고 이 데이터를 분석/이용해서 새로운 것을 만들어낼 수 있어야 함.

AWS의 장기 보관 시스템인 Amazon S3 Glacier는 매우 저렴한 비용이므로, 이제 데이터 보관자체의 비용을 걱정하는 것보다 이를 활용할 방안을 생각하는 것이 중요하다.

그러나 지속적으로 사용중인 Hot data들이 쌓이게 되는 Datastorage는 비싸기 때문에 데이터 구조는 잘 설계 해야 함.

 

 

 

사진을 찍지 못했던 다른 데모들도 있었을 정도로, 실제 개발을 통해서 사례를 많이 준비했다는 게 느껴졌다.

실습 세션을 제외하고는 keynote에서 가장 많은 실제 적용사례를 보여주지 않았을까 싶다.
신기술 책임자 자리에 괜히 앉은게 아니구나. 오늘 제일 동기부여가 많이 되는 시간이었다. 연설자의 소개와 DEMO 시연에 다시 한 번 박수를 보내며, 나도 내일부터 다시 나의 일터로 돌아가서 정진해야지.