Tagged: AWS

[AWS] Private Subnet 으로 서비스 구성하기.

AWS 는 전 세계적으로 가장 인기있는 Cloud Platform 이다. Web Console을 이용해서 원하는 자원을 구성하고 컴퓨터, 네트워크, 저장소등을 실시간으로 생성할 수 있으며 네트워킹 구성도 실시간으로 구성이 가능하다.

그래서 많은 IT 업체들이 AWS 클라우드를 사용하고 있다. 특히나 전 세계를 대상으로 인터넷 서비스를 하려는 업체들은 AWS 를 통해서 막대한 IT 인프라 구축비용 절감하고 있다.

오늘은 AWS 클라우드를 이용해서 가장 많은 구성이며 기본적인 구성인 Web Service 를 Private Subnet 을 이용해 구성해보도록 하겠다.

이 포스트는 AWS 클라우드에 대해서 어느정도 기초지식을 갖추고 있다고 가정하고 쓰여졌다. AWS 클라우드를 사용하기 위해서는 기본적인 개념들이 존재하는데, 예를들어 VPC, ELB, Security Group, Route Table, InterGateWay 등에 대해서 모두 알고 있다라고 가정한다.

목표

내가 목표로하는 전체적인 시스템 구성은 다음과 같다.

Private Subnet 서비스 구성도

위 구성도에서 눈여겨 봐야할 포인트는 다음과 같다.

  • 외부 인터넷과 연결을 위해서 반드시 Public Subnet 이 한개는 있어야 한다.
  • 서비스를 제공할 인스턴스들은 Private Subnet 에 있어야 한다.
  • Private Subnet 에 있는 인스턴스들에서 외부와의 인터넷 통신은 Public Subnet 에 있는 NAT 서버를 통해서 한다.
  • Private Subnet 에 Web Service 인스턴스들은 ELB(Elastic Load Balancer) 를 통해서 하며 ELB는 반드시 Public Subnet 에 있어야 한다.

 

VPC 생성하기

AWS 서비스에 가입하면 각 Region 마다 기본적인 사항들이 자동으로 생성된다. 그중에 VPC도 다음과 같이 기본으로 생성이 된다. Tokyo Region은 다음과 같다.

  • VPC CIDR: 172.31.0.0/16
  • Route table: rtb-ef0bcd8a
  • Network ACL: acl-3cef2859
  • Subnet: subnet-55d41722
  • Subnet Type: Public

Default VPC 은 인터넷과 자동으로 연결된 거대한 하나의 Public Subnet 기도 하다. 하지만 나는 이 Public Subnet 을 사용하지 않고 새롭게 VPC을 생성할 것이다. VPC 의 생성에서 고려해야할 사항은 얼마만큼의 IP 대역을 사용할 것인가에 있다.

Web Service VPC 생성
Web Service VPC 생성

Subnet 생성하기

이제 서브넷을 생성해야 한다. 중요한 것은 Public Subnet 1개와 Private Subnet 1개는 반드시 있어야 한다.

여기서 중요한 것도 IP 대역이다. 한 서브넷에 얼마만큼의 IP 대역을 쓸것인가 하는 것이다. 나는 다음과 같이 할당 했다.

  • Public Subnet: 10.31.0.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: JumpSubnet(NAT)
  • Private Subnet: 10.31.4.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: WebSubnet

여기서 한가지 Public Subnet, Private Subnet 을 구분하는 설정값은 존재하지 않는다. AWS 에서 이 둘의 구분은 Internet Gateway 와 연결이 되어진 네트워크이냐 아니냐에 따라 달라진다. Internet Gateway 에 연결되었다면 Public, 그렇지 않으면 Private 이라는 개념이다. 그럼 이러한 연결 설정은 어디서 하는가?

Subnet 에 대해서 Internet Gateway 연결을 하거나 기타 네트워크 경로 설정은 Route Table 에서 하기 된다.  Route Table 에서 생설할때에 고려해야 할 사항은 다음과 같다.

  • 어느 서브넷과 연결시킬 것인가?
  • 어떤 외부세계와 연결시킬 것인가?

Route Table 이 존재하면 수정을하고 없으면 생성을 하면 된다.

Public Subnet

Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 라우팅 테이블
Public 서스넷 Route Table 라우팅 테이블

Public Subnet 을 위한 Route Table 은 위와같이 연결할 서브넷과 라우팅 테이블을 정의해주면 된다. 여기서 핵심은 라우팅 테이블에서 Internet Gateway 연결을 해줘야한다. 위 화면에서 igw-98de5cfd 가 바로 그것이다.

Internet Gateway 가 연결되어 있다면 그것이 Public Subnet 이 된다.

Private Subnet

Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 라우팅 테이블
Private 서스넷 Route Table 라우팅 테이블

Private Subnet 을 위한 서브넷 연결과 라우팅 테이블은 위와 같습니다. 라이팅 테이블을 보면 Internet Gateway 연결이 없다. 그래서 이 라우팅 테이블과 연결된 Subnet 은 Private Subnet 이 된다.

Private Subnet 은 외부 인터넷과 연결이 안되기 때문에 Private Subnet 인스턴스에 접속하고 제어하고 Private Subnet 의 인스턴스들이 인터넷연결을 위한 NAT 인스턴스가 필요하다.

Security Group 생성

Security Group 은 인터넷 방화벽이라고 생각하면 편하다. Security Group 은 인스턴스마다 할당할 수 있다. Security Group 에도 NAT를 위한 것과 NAT 에 의존해야할 인스턴스를 위한 것 두개를 만든다.

Security Group 을 생성할대는 Inbound 프로토콜, 포트 와 Outbound 프로토콜, 포트 를 생각해야 한다.

NAT Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 보안상 외부로의 접속을 차단해야할 상황이라면 설정을 해야하면 된다.

Inbound 접속 제한을 해야함으로 다음과 같이 설정해준다.

NAT 를 위한 Security Group
NAT 를 위한 Security Group

중요한 사항은 80, 443, ICMP 에 대한 NAT 접속은 Private Subnet 으로부터 받는걸로 설정을 해야 한다는 것이다.

NAT 의존하는 인스턴스를 위한 Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 물론 보안상 문제가 된다면 제한을 걸고 싶은 포트를 지정해주면 된다.

NAT 에 의존하는 인스턴를 위한 Security Group
NAT 에 의존하는 인스턴를 위한 Security Group

SSH 서비스 접속포트는 NAT 서버 주소를 지정해준다. HTTP, HTTPS, ICMP 는 모든 영역에서 접속을 허용하도록 한다. 왜 이렇게 하냐하면 HTTP, HTTPS 는 AWS 의 Public ELB 를 통해서 외부로 서비스를 해야하는데 Public ELB -> private subnet 인스턴스에 접속이 이루어져야 하기 때문인데 문제는 접속할 IP를 알수가 없다. 그래서 접속하는 주소지를 모두 열어준다.

NAT Instance 생성

NAT Instance 가 필요한 이유는 다음과 같다.

  • Private Subnet 에 있는 인스턴스들을 제어하기 위해
  • Private Subnet 에 있는 인스턴스들이 인터넷을 하기 위해.

Private Subnet 에 있는 인스턴스들이 인터넷이 되어야 하는 이유는 OS 및 각종 소프트웨어의 자동 업데이트 때문이다. 보안 업데이트를 하기위해서는 업데이트 프로그램을 다운로드해야하는데 대부분 인터넷을 통해서 다운로드가 된다. 따라서 Private Subnet 도 인터넷이 되어야 한다.

또다른 이유는 AWS 의 S3 와 같은 외부 서비스를 이용하기 위해서다. S3 저장소는 HTTP 주소를 통해서 자원에 접근할 수 있도록 해주는데, 이를 Private Subnet 에서 이용하기 위해서는 인터넷이 되어야 한다.

NAT Instance 는 외부에서 연결을 해야함으로 EIP를 할당해준다. EIP가 없더라도 Public Ip를 할당해줘야 한다. 그리고 Subnet 은 Public Subnet 과 연결해 준다.

  • Instance: EC2 Linux System
  • Subnet: JumpSubnet(NAT)
  • Seucrity Group: NAT 를 위해 생성한 Security Group
  • EIP, Public IP 할당

중요한 것은 반드시 Public Subnet 에 인스턴스를 생성해 준다.

Private Subnet Route Table 조작

이제 앞에서 Private Subent 의 Route Table 을 조작할 때다. Private Subnet 의 Route Table 은 Local 외에 모든 연결을 NAT Instance 로 가게 설정 한다.

Private Subnet 을 위한 라우팅 테이블 조작
Private Subnet 을 위한 라우팅 테이블 조작

위와 같이 두번째 타켓으로 NAT 인스턴스를 지정해 준다. 그러면 이 라이팅에 연결된 Subnet 들은 외부와 통신을 위해서 NAT 인스턴스를 통해서 이루어지게 된다.

NAT 인스턴스 마스커레이딩 설정

지금까지의 내용은 인터넷을 찾아보면 나온다. 하지만 여기까지만 하면 절대로 Private Subnet 에 인스턴스에서 인터넷이 될수가 없다. 지금까지의 작업은 Network 단에서의 작업이였다. Security Group은 인스턴스단에서 이루어진 방화벽 작업일뿐 패킷의 경로를 조작해주는 것은 아니였다.

그런데, 이 모든 것을 다한다고 하더라도 OS에서 패킷의 경로를 원하는대로 조작해주지 않으면 Private Subnet 에 인스턴스들로부터 온 패킷과 받는 패킷들은 전송되지 않는다.

NAT 라는 것을 간단하게 설명하자면 우리가 가정에서 많이 쓰는 공유기와 같은 기능을 한다. 외부의 공인아이피를 가지고 내부의 사설 아이피를 할당해서 인터넷이 되게하는 것이 공유기의 역활인데, NAT 도 똑같다.

공유기가 없던 시절에 리눅스를 이용해서 공유기를 만들었었는데, 리눅스에 네트워크 카드를 두개 끼우고 하나는 외부망에 하나는 내부망에 연결하고 내부망에 허브를 두고 서로 통신이되도록 리눅스에서 설정을 해줬었다. 이 설정을 마스커레이딩(MASQUERADE) 이라 불렀다.

먼저 리눅스 커널에서 패킷을 포워딩 하도록 다음과 같이 설정해 준다.

그리고 iptables 에 nat 체인에 마스커레이딩 설정을 해준다.

Private 인스턴스 접속

Private 인스턴스를 접속하기 위해서는 다음과 같은 절차를 따른다.

  • 먼저 NAT 서버에 SSH 접속을 한다.
  • NAT 서버에서 Private 인스턴스로 접속을 한다.

Private 인스턴스에 접속한 후에 OS 업데이트 명령을 쳐보고 잘된다면 설정이 제대로 된 것이다.

ELB  설정.

Elastic Load Balancer 는 여러개의 서버들을 한대 묶어서 분산을 시켜주는 역활을 한다. 기존의 L4 스위치와 같은 역활을 하는 것인데 설정을 하게되면 ELB 접속을 위한 도메인이 생성된다. 이 도메인은 Amazon 에서 자동할당된 것으로 이것을 바꾸고 싶다면 DNS 서버에서 CNAME 으로 도메인을 등록하면 된다.

한가지 ELB의 제약 조건이 있는데, 그것은 반드시 Internet Gateway 와 연결되어야 한다. 이 말을 바꿔서 말하면 ELB는 반드시 Public Subnet 에 위치해야 한다는 뜻이다.

결국 ELB 때문이라도 반드시 하나의 Public Subnet 이 있어야 한다는 결론이 나온다.

ELB 설정
ELB 설정

위 그림을 보면 JumpSubnet(NAT)가 보이는데, 이게 바로 Public Subnet 이다. 반드시 1개의 Public Subnet 을 포함한다면 나머지 서브넷은 Private 이여도 상관이 없고 Private Subnet 에 있는 인스턴스들도 ELB를 통해서 서비스를 할 수 있게 된다.

ELB 에서 뒷단의 인스턴스들을 선택하기 위해서는 먼저 Subnet 을 반드시 선택해줘야 한다.

Private Subnet 의 인스턴스가 선택된 상태
Private Subnet 의 인스턴스가 선택된 상태

위와 같이 Private Subnet 의 인스턴스를 선택할 수 있다. ELB의 경우 대부분 HTTP 80 을 Inbound 로 받기 때문에 Private Subnet 안에 설치한 인스턴스에 웹서버를 올리기 되면 ELB를 통해서 서비스를 제공할 수 있게 된다.

 

이것으로 간단하게 Private Subnet 으로 서비스 구성하기 에 대해 간단하게 정리해 봤다.

AWS 2016 서울 후기

새해 첫주, 심심하던 차에 Amazon Web Service 2016 Seoul 행사가 1월 7일 있었다. 몇일전부터 문자 메시지로 바코드와 함께 9시부터 시작한다는 안내가 와서 까먹지는 않고 있었다. 하지만 눈떠보니 8시고 차를 끌고 행사장에 도착했을때에는 9시가 훌쩍 넘어 30분을 향하고 있어 지각했다는 자괴감으로 헐레벌덕 뛰어들어갔다.

간단한 요깃거리..

9시부터 생각했던건 착각이였다. 9시부터 현장등록과 행사장 입장을 하고 본 행사는 10시부터 였다. 고맙게도 AWS.KR 에서 아침 댓바람(?)부터 왔을 사람들을 위해서 간단한 요깃거리를 준비해 뒀다. 간단한 한입빵과 커피… 이 정도면 아침식사로는 충분했다.

AWS 2016 서울 현장등록

이번 행사는 세개의 클래스(Class)로 나뉘어 준비되었다. AWS Intro, AWS Advanced, AWS Gaming 으로 각각 행사장소를 달리해 자신이 흥미있고 알고자하는 사람들을 타킷으로 알맞게 나눈것이다. 이 세개의 클래스는 오후에 진행됐고 오전에는 본행사로 Andy Jassy 글로벌 총괄 사장이 직접 연사로 나와 AWS 에대한 소개와함께 그동안의 노력과 성과등을 설명하는 시간등으로 준비되었다.

AWS CLOUD 2016 Seoul

AWS Staff 에 문자메시지로 온 바코드를 보여주고 네임태그를 건내받았고 본 행사장 입구에서 안내 팜플렛과 들고 다니게 편하라고 종이가방도 함께 받아 행사장에 입장했다. 행사장에 들어서니 언듯봐도 꽤 사람들이 많았다. 본 행사가 시작됐을때에는 자리가 모잘라 뒤에 서 있는 사람도 생날 정도였다.

AWS 2016 Seoul 팜플렛과 종이가방

10시가 되자 본 행사가 시작되었다. 글로벌 총괄 사장 Andy Jassy 가 연사로 등장했다. 그 동안 AWS  가 어떻게 되었으며 작년 한해 얼마큼 노력하고 새로운 기능들을 추가했는지, 서비스 진화에 발맞춰 AWS CLOUD 가 무엇을 만들어내고 고객들에게 제공했는지등을 설명했다.

Andy Jassy 글로벌 총괄 사장

Andy Jassy 는 전 세계 AWS 행사에 빠지지 않고 참석하는 사람으로 유명한데, 그가 대한민국을 찾은 것은 이번이 처음이라고 한다. 작년에도 한국에서 행사를 했었는데 그땐 안오고 하필 올해 왜 왔을까?

Asia Pacific Seoul Region

드디어 세계 12번째로 한국에 AWS CLOUD 를 위한 데이터센터인 Region 이 오픈했다. 그가 이말을 했을때에 뒤에서 환호성이 들리기도 했다. (많은 사람들이 그들이 누군지 알거 같닸다는 눈초리를 보내기도 했다. ㅋㅋㅋㅋ) 그의 말에 맞춰 실제로 AWS Console 에 Seoul Region 이 나타났으며 한국 시장 진출을 타진했던 Netflix 의 서비스도 오픈되었다고 한다.

Andy Jassy 사장의 Seoul Region 오픈 선포(?)를 끝으로 그의 프리젠테이션은 끝이났고 뒤이어 AWS 한국 직원들이 프리젠테이션이 이어졌다. 그 첫번째로 세계 12번째로 오픈한 Seoul Region 을 기술적인 측면에서 소개했다. 어떤 서비스를 사용가능하고 어떤 장점을 가져다 줄지가 주요 내용이였다.

AWS Seoul 에서 사용가능한 서비스

새롭게 오픈한 Seoul Region 의 대한 정보는 매우 귀중했다. AWS 에서 선보이는 모든 서비스를 지금 다 사용할 수 있지는 않기 때문이다. 연사의 주된 목적은 바로 이러한 정보를 전달하는데 있었고 그의 프리젠테이션은 이 목적에 매우 충실했다.

그가 소개한 내용중에 Direct Connector 서비스, 그중에서 “상면임대”가 눈길을 끌었다. Direct Connector 서비스는 실제 물리적인 인프라를 AWS 에 연결할 수 있도록 하는 서비스로 쉽게 말해서 데이터센터간 인터넷 회선 연결이라고 보면 된다. 그동안 대한민국은 이것이 불가능했다. 아니 엄밀해 말해 가능하긴 했지만 그 효용성이 없었다. 하지만 오늘 Seoul Region 이 생기면서 그 효용성이 살아났고 그의 프리젠테이션에는 ‘상면임대’ 라는 새로운 서비스 서포트가 생겨난 것이다.

Director Connector 상면임대

Direct Connector 를 위해서, 다시 말해 데이터센터간 연결을 회선 연결을 위해서는 물리적으로 직접적인 연결이 가능해야 한다. 하지만 AWS 는 KINX(킹스)라는 업체를 통해서 이 문제를 해결했다.

우리는 많은 인터넷 데이터 회선을 사용한다. 예를들면 KT 회선, LG Dacom 회선, SK 회선등이 그것이다. 인터넷 데이터 회선 사업자, 아니 좀 더 정확하게는 ISP (Interner Service Provider) 들이 제공하는 인터넷 회선 라인을 사용한다. 문제는 이 각각의 ISP 업체간에도 회선을 연결해줘야 한다는 것이다. 안그러면 KT회선 사용자는 SK 회선 사용자와 연결을 할 수가 없을 테니까. 그래서 각 회선 사업자간을 연결해주는 인터넷 데이터 회선 교환 사업자가 필요한데 KINX 가 바로 그런 사업자다. 한국에서 가장 큰 사업자다.(아마 경쟁업체가 없다지?) 인터넷 데이터 회선 교환을 비유하자면 고속도록의 나들목(인터체인지) 라고 할 수 있겠다.

KINX Internet Exchange ConceptAWS.KR 은 바로 인터넷 데이터 회선 교환 사업자 KINX 를 협력 파트너로 정해 Director Connector 를 지원하게 된다. KT IDC 에 서버는 이제 KINX 나들목을 거쳐 AWS CLOUD 와 직접적으로 연결이 가능해진 것이다.

더군다나 KINX 자체의 IDC 에 물리적인 서버를 둔다면, 그것은 바로 AWS CLOUD 와 연결에 물리적으로 가장 근접한 위치에 놓이게 되어서 보다 쉽게 물리 인프라와 AWS CLOUD 간 연결이 가능해는데 이게 바로 ‘상면임대’ 라는 개념인 것으로 보인다.

AWS 한국 직원의 첫번째 세션 “2016 AWS 신규 서비스 소개” 는 매우 필요했고 중요했으며 유용했다. 이 세션을 마지막으로 Global 세션은 끝났고 오후부터는 Intro, Advanced, Gaming 으로 클래스가 나뉘어 진행될 예정이였다.

점심은 AWS.KR 에서 준비한 도시락을 제공 받아 맛있게 점심세션(?)을 진행했다. 마침 자리를 테이블 좌석으로 이동한 터라 편하게 도시락을 제공받아 점심을 해결할 수 있었다.

AWS CLOUD 2016 점심 도시락

점심시간이나 휴식시간에도 행사장 밖 부스에서는 미니 세션도 함께 진행되 AWS 2016 CLOUD Seoul 행사에 참가한 업체들의 홍보와 더불어 정보습득할 수 있는 기회이기도 했으며, IT 바닥(?)이 좁은 한국이다보니 오랜만에 만난 친구, 선후배들간의 명함교환하는 모습도 눈길을 끌었다. 또, 각 부스별 마련된 이벤트를 통해서 선물을 챙기는 솔솔한 재미도 함께 제공됐다.

AWS 2016 Seoul 이벤트 선물

나는 Advanced 클래스를 신청했기에 자리이동 없이 앉아 있었고 점시시간이 끝나자 세션이 시작되었다. “AWS를 활용한 글로벌 아키텍쳐 운용 전략” 제목이였지만 실상은 AWS Seoul Region 오픈으로 Region 별 이전이 필요로 할텐데, 어떻게 서비스를 이전할지에 대한 정보제공이 주 목적이였다.

컴퓨팅 및 네트워크 이전 AWS CLI

이 세션에서 느낀 것은 Security Group, Network ACL, S3 이전등은 될수 있으면 AWS CLI 를 이용해서 하는 것이 편하다는 것과 Route 53 의 Weight 방법을 이용해 서비스 이전후에 서비스 지역 교체를 할 수 있다는 것이 핵심이였다.

Route 53을 이용한 서비스 교체

또, 놀라웠던 새로운 서비스도 눈에 띄었는데 기존의 RDS 외에 EC2 에서 자체적으로 구축한 데이터베이스를 위한 것으로 두개의 EC2 인스턴스 데이터베이스간의 Replication 을 자동으로 해주는 서비스가 눈길을 끌었다. 원리는 Source EC2 인스턴스의 데이터베이스 접속정보와 Target EC2 데이터베이스 접속정보를 AWS Console 를 통해서 입력해주면 복제를 해주는 것이 주요내용인데, 서비스 이름이 기억이……. (치매.. ㅠㅠ. 공개된 프리젠테이션 참고하셔요..)

세션들은 계속 진행됐다. 세션이 끝날때마다 잠깐의 휴식시간이 주어지긴 했다. 그 와중에 내 스마트폰 배터리가 바닥을 들어내는 바람에 몇몇 세션을 찍지 못했다. 흥미로웠던 세션별로 몇가지만 찍어야하는 상황이 되고 말았다. ㅠ

“클라우드 기반 실시간 데이터 분석 및 예측 방법” 세션에서는 그간의 AWS 가 제공했던 Big Data 서비스를 소개하고 이들을 어떻게 조합하고 운영하는지등에 대해서 프리젠테이션이 진행됐다.

AWS Big Data Roadmap

눈길을 끈것은 AWS 의 QuickSight 서비스 였다. 이 서비스는 Big Data 로 분석된 내용을 SQL 문으로 즉각즉각 그때그때 필요한 것만 뽑아낼 수 있도록 했다는 것이다. 이에 그치지 않고 현재 AWS 는 시각화까지 제공할 목적으로 서비스 개발을 진행하고 있다고 한다. 파이차트, 꺽은선 그래프등으로 Kibana 서비스와 동급의 내용이였다.

이렇게 보면 Big Data 를 AWS 서비스만 가지고 조합하면 하나의 플랫폼이 나올 정도로 전 영역을 전부 AWS 내에 집약시키겠다는 전략을 보여준 세션이였다고 평가할 만 했다.

다음으로 관심을 가졌던 것은 “고급 AWS 클라우드 보안 및 규정 활용 방법” 세션이였다. 스마트폰 배터리가 나가는 바람에 사진한장 없지만 클라우드의 보안을 어떻게 해야하는지에 대한 기초보다 좀 더 나간 방법들이 주된 내용이였다. 눈길을 끈것은 바로 현실적인 문제인 약간의 법적인 문제에 대한 나름의 설명이 좋았다.

마지막으로 흥미로웠던 것은 “고급 클라우드 아키텍쳐 방법론” 세션이였다. 연사가 현장에서 청중들에게 앙케이트 조사를 요청하고 그것을 기반으로 자신의 프리젠테이션 내용을 전달하는 Interactive 한 프리젠테이션과 자신감 넘치는 목소리로 청중들을 이끌었다.

AWS 2016 앙케이트 조사

“Well-Architected Method” 에 대한 정의에서부터 시작해 주요한 요소 네가지를 펼치고 그 내용을 소개했으며 중간중간 앙케이트 조사등으로 청중의 참여를 이끌었다. 이를 위해서 자신만의 프리젠테이션 노트북을 세팅하느라 시작전에 약간의 작업이 필요했는데, 청중들을 위해서 많은 준비를 했다는 느낌을 많이 받았다. 개인적으로 AWS 2016 Seoul 의 최고의 연사는 바로 이분이라고 생각한다.

개인적인 평가

이번 AWS 2016 Seoul 행사는 Seoul Region 오픈 선언이 가장 큰 이슈였다. 이후 진행된 Advanced 세션들은 이 Seoul Region 에 관련된 내용들로서 서비스 소개, 이전 방법등으로 사용자가 궁금해 할것을 미리 대비라도 한듯한 것이였을만큼 기획에 짜임새가 돋보였다. 그 이후에 진행된 세션들도 평소에 대충알고 있던 내용을 정리하고 좀 더 심화해보는 것으로 흥미로웠고 꽤나 알찬 내용이였다. 연사 프리젠테이션 중간에 관련 업체들의 실제 적용사례들을 소개하는 것 또한 주입식 정보전달을 벗어나 실제적이고 실층적인 내용을 청중에게 전달함으로써 현실감을 더했다. 홈페이지에 관련 자료가 올라오면 꼭 보라고 권하고 싶다.

협력업체 부스와 이벤트로 선물을 주는 전략도 나름 괜찮아 보였다.

이번 행사를 보고 느낀 것은 ‘이거 준비하느라 고생 꽤나 했겠구나’ 하는 생각이였고 그런 고생이 헛되지 않을만큼, 그 이상으로 아주 좋았다.

Amazon Web service

 

  • Camera: iPhone 4S
  • Taken: 7 1월, 2016
  • Flash fired: no
  • Focal length: 4.28mm
  • ISO: 200
  • Shutter speed: 1/20s

AWS Kinesis

이 글은 AWS Kinesis 이 무엇인지에 대한 개념적인 글입니다.

다음의 자료를 기반으로 작성되었습니다.

  1. Introducing Amazon Kinesis (SlideShare)
  2. Introduction to Amazon Kinesis (Youtude)

Big Data

인터넷의 발전으로 인해서 하루에도 계산하기 힘든 데이터가 쏟아집니다. 과거와는 달라진 이러한 환경을 우리는 간단히 Big Data 시대라고 하지요. 어찌보면 과거에도 Big Data 는 있었지만 요즘과 구별되는 것은 누구든지 Data 를 생산할 수 있다는데에 있습니다. 그러다보니  과거와는 다르게 쏟아지는 데이터를 분석해서 유의미한 데이터를 뽑아내는 기술이 필요하게 되었는데 이게 바로 Big Data 의 진정한 의미 중에 하나 입니다.

누구나 생산해내는 데이터들을 유의미한 의미의 정보로 가공해내는 것이 바로 Big Data 기술이라고 할 수 있습니다.

Batch VS Streaming

과거 이야기를 좀 더 해보면, 과거에도 데이터를 분석해내는 방법이 있었습니다. 첫번째로는 데이터를 모우는 겁니다. 그리고 그것을 특정한 저장소에 저장을 합니다. 대부분 데이터베이스시스템에 저장을 했습니다. 그리고 그것을 이용해서 쿼리문을 이용해서 데이터를 뽑아 냈습니다.

그런데, 데이터를 모으고 데이터베이스에 저장하고 하는 부분은 특정 시간에 서버에 작업을 걸어놓아하는 경우가 많았습니다. 간단하게는 리눅스 시스템에서 크론(Cron) 을 이용해서 특정 배치 프로그램을 돌려서 데이터를 모우고 데이터베이스에 집어넣는 방법을 이용했지요.

하지만 Big Data 시대에 이 방법이 과연 유용한가 하는 문제가 있습니다. 몇분, 몇시간, 몇일간격으로만 배치작업을 돌리는건 쏟아지는 데이터 속도보다 빠르지 못하다보니 데이터분석을 할 수 없는 경우가 많습니다. 설사 분석을 해낸다고 해도 이미 시간이 많은 흐른뒤라서 시의성을 가지지 못하는 정보가 될 겁니다.

그래서 등장한 것이 스트리밍(Streaming) 입니다. 스트리밍, 물 흐르듯 그때그때 데이터를 분석해내면 유용한 정보를 얻기위해서 기달릴 필요가 없을 겁니다. 그때 그때 분석한 데이터를 데이터베이스에 저장하거나 파일로 저장하는것도 가능합니다.

그래서 현대의 Big Data 분석 소프트웨어들은 전부다 Streaming 을 지원하도록 발전되어 왔습니다.

현대의 BigData 구조
현대의 BigData 구조

많은 소프트웨어들이 이렇게 데이터 수집, 분석처리, 저장, 분석 및 리포트 영력으로 나뉘어 발전되어지고 있습니다.

위 그림에서 문제가 하나 있습니다. 데이터 수집 부분과 데이터 처리부분 입니다. 이 부분이 문제가 되는 이유는 데이터 수집하는 소프트웨어와 처리하는 소프트웨어간의 데이터 교환을 맞춰줘야 하고 둘이 동기화 되어 처리되어야 합니다. 어느 한쪽이 병목이 생기면 문제가 생길 수도 있습니다.

AWS Kinesis

AWS Kinesis 는 데이터 수집구간과 데이터 처리구간 중간에 위치합니다. 이렇게 중간에 위치하는 소프트웨어를 만든 이유는 다양한 데이터들을 수집하고 이것을 다양한 포맷으로 만들어 줍니다.

Kinesis 를 이해하는데 헷깔리는게 있는데, Kinesis 가 ‘스트리밍 데이터 처리’ 를 해준다는 것입니다. 여기서 스트리밍 데이터 처리라는 말은 스트리밍으로 데이터를 분석해준다는 이야기가 아닙니다.

다양한 형태로 들어오는 데이터를 가공해서 다양한 분석 소프트웨어가 사용가능하도록 다양한 출력물을 만들어내주거나 데이터 저장소에 저장하도록 해줍니다.

기본의 Streaming 처리
기본의 Streaming 처리

기존의 Streaming 처리구조 입니다. 수많은 다양한 데이터들이 들어오고 이것을 처리하는 가공하고 분석하는 도구들이 붙어 있습니다.

AWS Kinesis
AWS Kinesis

AWS Kinesis 는 다양한 데이터들을 빠르게 가공해줍니다. 그리고 이러한 데이터들은 다양한 포맷으로 출력줌으로써 다양한 소프트웨어서 사용해주게 해줍니다.

다어그램으로 표현하면 다음과 같습니다.

AWS Architecture
AWS Architecture

AWS Kinesis 는 다양한 입력 데이터와 출력을 해줍니다.

AWS Kinesis Sending & Reading Data from Kinesis Streams
AWS Kinesis Sending & Reading Data from Kinesis Streams

Amazon 에서는 Kinesis 를 다음과 같이 설명하고 있습니다.

Amazon Kinesis는 완전관리형 스트리밍 데이터 서비스입니다. 수십만 개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다. 그러면 몇 초 안에 Amazon Kinesis 애플리케이션에서는 스트림의 해당 데이터를 읽고 처리할 수 있습니다.

“Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다” 이 말의 의미를 잘 생각해본다면 이것이 무엇인지 감을 잡을 수 있을 겁니다.