문자열로 되어 있는 시간을 Datetime 객체로 변경하는 방법은 많이 찾아 볼 수 있습니다. 여기서는 기존에 존재하는 방법과 추가 설치 모듈로 좀 더 간편하게 사용하는 방법을 설명하겠습니다.

1. Datetime

파이썬에 내장되어 있는 Datetime 패키지를 사용하여 아래와 같이 변환을 할 수 있습니다.

import datetime

date_time_str = '2018-06-29 08:15:27.243860'  
date_time_obj = datetime.datetime.strptime(date_time_str, '%Y-%m-%d %H:%M:%S.%f')

print('Date-time:', date_time_obj)


# Date-time: 2018-06-29 08:15:27.243860


흔히 사용하는 포맷은 ISO 8601으로  YYYY-MM-DDTHH:MM:SS.mmmmmm 와 같이 표현하고 있습니다. 이와 같은 포맷만 들어온다면 그대로 사용해도 무방하지만 아래와 같이 여러 타입이 존재한다면 고려할 사항이 많아집니다.

"Jun 28 2018 at 7:40AM" -> "%b %d %Y at %I:%M%p"
"September 18, 2017, 22:19:55" -> "%B %d, %Y, %H:%M:%S"
"Sun,05/12/99,12:30PM" -> "%a,%d/%m/%y,%I:%M%p"
"Mon, 21 March, 2015" -> "%a, %d %B, %Y"
"2018-03-12T10:12:45Z" -> "%Y-%m-%dT%H:%M:%SZ"

timezone 지정

위처럼 문자열을 datetime 객체로 변환하거나 현재 날짜+시간을 호출하면 현재 로컬시간을 기준으로 호출이 됩니다.

now = datetime.datetime.now()
print(now)


# 2019-02-02 15:54:07.244639


여기서 구한 현재 시간을 뉴욕시간대로 변경하고자 하면 아래와 같이 복잡한 절차를 거치게 됩니다. 또한 현재 시간이 뉴욕시간대로 변환되지 않고 timezone만 추가된 형태를 확인할 수 있습니다.

import datetime as dt
import pytz

date_time_obj = dt.datetime.now()

print('now:', date_time_obj)

timezone = pytz.timezone('America/New_York')
timezone_date_time_obj = timezone.localize(date_time_obj)

print(timezone_date_time_obj)
print(timezone_date_time_obj.tzinfo)


# now: 2019-02-02 15:56:15.197103
# 2019-02-02 15:56:15.197103-05:00
# America/New_York


datetime 패키지로만 충분히 변환하거나 시간대를 바꿀 수 있지만 다른 모듈을 설치하면 좀 더 간편하게 사용할 수 있습니다.

2. dateutil

dateutil 모듈을 설치하여 사용하면 문자열의 시간 포맷을 걱정할 필요가 없습니다.

from dateutil.parser import parse

date_array = [
    '2018-06-29 08:15:27.243860',
    'Jun 28 2018  7:40AM',
    'Jun 28 2018 at 7:40AM',
    'September 18, 2017, 22:19:55',
    'Sun, 05/12/1999, 12:30PM',
    'Mon, 21 March, 2015',
    '2018-03-12T10:12:45Z',
    '2018-06-29 17:08:00.586525+00:00',
    '2018-06-29 17:08:00.586525+05:00',
    'Tuesday , 6th September, 2017 at 4:30pm'
]

for date in date_array:
    print('Parsing: ' + date)
    dt = parse(date)
    print(dt.date())
    print(dt.time())
    print(dt.tzinfo)
    print()



# Parsing: 2018-06-29 08:15:27.243860
# 2018-06-29
# 08:15:27.243860
# None

# Parsing: Jun 28 2018  7:40AM
# 2018-06-28
# 07:40:00
# None

# Parsing: Jun 28 2018 at 7:40AM
# 2018-06-28
# 07:40:00
# None

# Parsing: September 18, 2017, 22:19:55
# 2017-09-18
# 22:19:55
# None

# Parsing: Sun, 05/12/1999, 12:30PM
# 1999-05-12
# 12:30:00
# None

# Parsing: Mon, 21 March, 2015
# 2015-03-21
# 00:00:00
# None

# Parsing: 2018-03-12T10:12:45Z
# 2018-03-12
# 10:12:45
# tzutc()

# Parsing: 2018-06-29 17:08:00.586525+00:00
# 2018-06-29
# 17:08:00.586525
# tzutc()

# Parsing: 2018-06-29 17:08:00.586525+05:00
# 2018-06-29
# 17:08:00.586525
# tzoffset(None, 18000)

# Parsing: Tuesday , 6th September, 2017 at 4:30pm
# 2017-09-06
# 16:30:00
# None


위 예시처럼 시간포맷을 알 필요가 없다는 장점이 있지만 timezone을 지정하지 않으면 로컬 시간을 바라보고 있는 것을 확인할 수 있습니다.

3. maya

마야 또한 위의 dateutil 모듈과 같이 시간 포맷에 상관없이 변환할 수 있습니다.

import maya

date_array = [  
    '2018-06-29 08:15:27.243860',
    'Jun 28 2018  7:40AM',
    'Jun 28 2018 at 7:40AM',
    'September 18, 2017, 22:19:55',
    'Sun, 05/12/1999, 12:30PM',
    'Mon, 21 March, 2015',
    '2018-03-12T10:12:45Z',
    '2018-06-29 17:08:00.586525+00:00',
    '2018-06-29 17:08:00.586525+05:00',
    'Tuesday , 6th September, 2017 at 4:30pm'
]

for date in date_array:  
    print('Parsing: ' + date)
    dt = maya.parse(date).datetime()
    print(dt)
    print(dt.date())
    print(dt.time())
    print(dt.tzinfo)
    print()


# Parsing: 2018-06-29 08:15:27.243860
# 2018-06-29 08:15:27.243860+00:00
# 2018-06-29
# 08:15:27.243860
# UTC

# Parsing: Jun 28 2018  7:40AM
# 2018-06-28 07:40:00+00:00
# 2018-06-28
# 07:40:00
# UTC

# Parsing: Jun 28 2018 at 7:40AM
# 2018-06-28 07:40:00+00:00
# 2018-06-28
# 07:40:00
# UTC

# Parsing: September 18, 2017, 22:19:55
# 2017-09-18 22:19:55+00:00
# 2017-09-18
# 22:19:55
# UTC

# Parsing: Sun, 05/12/1999, 12:30PM
# 1999-05-12 12:30:00+00:00
# 1999-05-12
# 12:30:00
# UTC

# Parsing: Mon, 21 March, 2015
# 2015-03-21 00:00:00+00:00
# 2015-03-21
# 00:00:00
# UTC

# Parsing: 2018-03-12T10:12:45Z
# 2018-03-12 10:12:45+00:00
# 2018-03-12
# 10:12:45
# UTC

# Parsing: 2018-06-29 17:08:00.586525+00:00
# 2018-06-29 17:08:00.586525+00:00
# 2018-06-29
# 17:08:00.586525
# UTC

# Parsing: 2018-06-29 17:08:00.586525+05:00
# 2018-06-29 12:08:00.586525+00:00
# 2018-06-29
# 12:08:00.586525
# UTC

# Parsing: Tuesday , 6th September, 2017 at 4:30pm
# 2017-09-06 16:30:00+00:00
# 2017-09-06
# 16:30:00
# UTC


dateutil과 다르게 maya는 로컬시간을 바라보지 않고 기본적으로 UTC로 지정합니다.

dateutil과 maya의 차이점

두 모듈은 비슷해 보이지만 timezone에 대해 아주 큰 차이가 있습니다.

import maya
import dateutil.parser

date_array = [  
    '2018-06-29 17:08:00.586525+05:00',
    '2018-06-29 17:08:00.586525',
]


for date in date_array:  
    print('Parsing: ' + date)
    maya_dt = maya.parse(date).datetime()
    dateutil_dt = dateutil.parser.parse(date)

    print('maya: ')
    print(maya_dt)
    print(maya_dt.tzinfo)

    print('dateutil: ')
    print(dateutil_dt)
    print(dateutil_dt.tzinfo)

    print()


# Parsing: 2018-06-29 17:08:00.586525+05:00
# maya: 
# 2018-06-29 12:08:00.586525+00:00
# UTC


# dateutil: 
# 2018-06-29 17:08:00.586525+05:00
# tzoffset(None, 18000)

# Parsing: 2018-06-29 17:08:00.586525
# maya: 
# 2018-06-29 17:08:00.586525+00:00
# UTC


# dateutil: 
# 2018-06-29 17:08:00.586525
# None


maya의 경우는 문자열에 존재하는 +05:00을 계산하여 timezone을 UTC로 세팅합니다. 위의 경우 17시에 +05:00가 존재하여 5시간을 뺀 후, timezone을 UTC라고 보여주고 있습니다. 반면 dateutil은 시간계산을 하지 않고 +05:00을 저장하게 됩니다. 

또한 timezone을 변경하거나 세팅할 때도 큰 차이가 존재합니다.

import maya
import dateutil.parser
import pytz
import dateutil

date = '2018-06-29 17:08:00.586525'

print('maya: ')
maya_dt = maya.parse(date)
print('parsing: ', maya_dt.datetime())
maya_dt = maya_dt.datetime(to_timezone='America/New_York', naive=False)


print('(timezone) America/New_York: ', maya_dt)
print(maya_dt.tzinfo)

print('------------------')

print('dateutil: ')
dateutil_dt = dateutil.parser.parse(date)
print('parsing: ', dateutil_dt)

timezone = pytz.timezone('America/New_York')
dateutil_dt = timezone.localize(dateutil_dt)

print('(timezone) America/New_York: ', dateutil_dt)
print(timezone)




# maya: 
# parsing:  2018-06-29 17:08:00.586525+00:00
# (timezone) America/New_York:  2018-06-29 13:08:00.586525-04:00
# America/New_York
# ------------------
# dateutil: 
# parsing:  2018-06-29 17:08:00.586525
# (timezone) America/New_York:  2018-06-29 17:08:00.586525-04:00
# America/New_York


maya의 경우, 파싱한 시간대에서 지정한 timezone의 시간만큼 계산하여 보여주지만 dateutil의 경우 datetime과 같이 시간은 계산하지 않고 timezone만 붙여서 보여주고 있습니다.

결론

문자열에서 datetime 객체로 변환하는 것은 third-party인 maya나 dateutil을 사용하는 것이 좋습니다. 또한 timezone을 변경하거나 각 다르게 사용할 경우, UTC로 변환하여 실행하는 서버 및 로컬의 시간대를 사용하지 않도록 하는 것이 중요합니다.

클라우드 컴퓨팅 탄생 이후 문제점이 발생하여 이를 해결하고자 엣지 컴퓨팅 개념이 탄생했습니다. 아래에서 클라우드 컴퓨팅의 문제점과 엣지 컴퓨팅의 정의에 대해 설명하겠습니다.

클라우드 컴퓨팅 문제점

클라우드 컴퓨팅이란 인터넷을 통해 서버, 저장소, 소프트웨어, 분석 등의 컴퓨팅 서비스를 제공하는 것입니다. 네이버의 NDrive, 구글 Docs 등이 클라우드 컴퓨팅의 대표적인 예로 볼 수 있습니다. 클라우드 컴퓨팅이 탄생한 이후, 각광 받으며 여러 기업들이 클라우드 환경으로 전환하였습니다.

그러나 최근 들어 이런 클라우드 컴퓨팅에도 여러 문제점이 있습니다. 클라우드 서비스를 이용하는 사람들이 기하급수적으로 늘어나면서 서버 및 데이터 센터에서 처리할 수 있는 데이터의 양을 넘어서기 시작했고 수집한 데이터를 분석하고 송신하는 과정에서 발생하는 데이터 지연 현상도 문제점으로 발생했습니다. 또한 클라우드 컴퓨팅의 통신 과정에서 보안 문제도 발생했습니다.

데이터 처리 속도, 용량 및 보안 등의 문제를 해결하기 위해 탄생한 것이 엣지 컴퓨팅입니다.

엣지 컴퓨팅이란?

말단 기기에서 컴퓨팅을 수행하는 것을 엣지 컴퓨팅이라 합니다. 클라우드 컴퓨팅은 데이터를 처리하는 곳이 데이터 센터에 있는반면 엣지 컴퓨팅은 스마트폰과 같은 장치에서 데이터를 처리합니다. 더 자세하게 정리하자면 엣지 컴퓨팅은 분산된 개방형 아키텍처로서 분산된 처리 성능을 제공하여 모바일 컴퓨팅 및 IoT 기술을 지원합니다. 

클라우드 컴퓨팅 VS 엣지 컴퓨팅

엣지 컴퓨팅이 필요한 이유


엣지 컴퓨팅은 대기 시간 없이 실시간 데이터 처리를 지원합니다. 클라우드 컴퓨팅을 이용했을 때, 생성된 데이터를 클라우드로 전송하고 전송받은 클라우드에서 데이터를 가공했다면 엣지 컴퓨팅은 스마트 애플리케이션 및 장치에서 데이터가 생성될 때, 즉각적으로 데이터에 대응하여 전송 시간을 줄여줍니다. 엣지 컴퓨팅을 사용하면 아래와 같은 장점 3가지를 보장할 수 있습니다.

데이터 부하 감소

클라우드 컴퓨팅을 사용했을 때, 처리해야 할 데이터 양이 많을수록 시스템에 부하가 생기는 반면, 엣지 컴퓨팅은 해당 기기에서 발생되는 데이터만 처리하기 때문에 부하를 줄일 수 있습니다.

보안

클라우드 컴퓨팅은 중앙 서버 아키텍처로 데이터 전송/전달 부터 보안을 강화해야 하는 반면, 엣지 컴퓨팅은 데이터 수집과 처리를 자체적으로 처리하기 때문에 클라우드 컴퓨팅에 비해 상대적으로 보안이 좋다고 할 수 있습니다. 

장애대응

클라우드 컴퓨팅을 사용했을 때 서버가 마비되면 치명적인 타격을 입지만 엣지 컴퓨팅을 사용하면 자체적으로 컴퓨팅을 수행하기 때문에 효과적으로 장애를 대응할 수 있습니다.


엣지 컴퓨팅 VS 클라우드 컴퓨팅

위 설명한 것만 보면 클라우드 컴퓨팅과 엣지 컴퓨팅 간 비교로 엣지 컴퓨팅이 무조건 좋아보입니다. 하지만 엣지 컴퓨팅의 장점을 두각시키기 위해선 클라우드 컴퓨팅과 혼합하여 사용해야 합니다. IoT의 경우, 클라우드 컴퓨팅으로 모든 디바이스의 데이터를 받아 연산처리를 진행했다면, 엣지 컴퓨팅을 접목시켜 각 디바이스 내에서 연산처리를 진행한 후, 해당 결과만 클라우드 컴퓨팅으로 전송하는 방식으로 진행하는 것이 두 컴퓨팅 아키텍처의 장점을 전부 살릴 수 있습니다.

'서버' 카테고리의 다른 글

crontab 초 단위 실행하기  (0) 2019.02.02
프로비저닝(Provisioning)이란?  (1) 2019.02.02
엣지 컴퓨팅(Edge Computing) 이란?  (0) 2019.01.29
Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (1) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19

파이썬에서 어떤 값을 더할 때 +를 사용하여 새로운 변수에 결과값을 담을 수도 있고 기존에 사용하던 변수에 +=로 값을 대체할 때가 있습니다. 더 나아가 각 리스트를 합칠 때도 사용됩니다. 아래는 리스트를 합치는 예시입니다.

a = [1,2]
b = [3,4]
c = a+b
print(c)
# [1, 2, 3, 4]




a += b
print(a)


# [1, 2, 3, 4]


위 결과만 봤을 때 +와 +=의 차이가 없는 것처럼 확인됩니다. 그러나 아래 예시를 보면 똑같다 라는 가정이 틀렸다는 것을 볼 수 있습니다.

a = [1,2]
b = (3,4)
c = a+b

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list


a += b
print(a)

# [1, 2, 3, 4]


리스트와 튜플로 선언 후 + 연산자로 결과를 새로운 변수 c에 담으려 하면 에러를 반환하는 반면, += 연산자를 사용하여 a 변수에 결과를 반영하면 의도한대로 합쳐진 리스트가 나오는 것을 볼 수 있습니다.


여기서 + 는 __add__ 함수를 호출하고 +=는 __iadd__ 함수를 호출하게 됩니다. 

여기서 + 연산자는 대칭입니다. 대칭이라는 의미는 a+b와 b+a는 항상 같은 결과를 가져와야 합니다. 위와 같이 타입이 다른 경우, 연산자의 좌변과 우변의 선언 순서에 따라 타입이 변경되기 때문에 오류를 발생시킵니다. 

반면 += 연산자는 비대칭입니다. 선언문 왼쪽의 변수타입에 의해 결정이 됩니다. 따라서 a+=b는 a 타입을 유지하게 됩니다.


만약 b+=a 일 경우면 아래와 같은 결과를 반환합니다.

a = [1,2]
b = (3,4)
b += a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate tuple (not "list") to tuple


이처럼 +와 +=는 비슷해 보이지만 동작하는 방식이 다르므로 사용할 때 유의하여 사용해야 합니다.

특정 패키지 또는 라이브러리를 여러 람다 함수에서 공유하여 사용하는 경우가 자주 있습니다. 이러한 공유되는 패키지는 비즈니스 로직의 구현을 간소화하기 위해 추가하는 사용자 정의 코드이거나, 하나 이상의 함수가 사용하는 코드이거나, 표준 라이브러리일 경우가 많습니다. 람다 레이어의 출시 이전에는 공유되는 패키지와 해당 패키지를 사용하여 실제 동작을 원하는 코드를 패키징하여 람다에 배포해왔습니다. 이러면 패키징의 사이즈가 커진다는 점과 다른 람다함수에서 해당 공유 패키지를 사용할 수 없다는 단점이 있었습니다. 

람다 레이어는 이러한 불편한 점을 해소하기 위해 나왔습니다. 공통적으로 사용할 패키지 또는 라이브러리를 압축 파일에 담아 하나의 람다 레이어로 업로드한 다음, 사용자는 함수 코드를 변경할 필요 없이, 람다 레이어 안의 라이브러리를 참조하여 사용하면 됩니다.

람다 레이어란?

  • 공통으로 사용되는 패키지 또는 라이브러리를 압축하여 업로드 함으로써 여러 람다함수에서 접근하여 코드 수정 없이 사용할 수 있음
  • 람다 함수는 최대 5개의 레이어를 참조할 수 있음
  • 업로드 할 패키지를 실행할 런타임을 직접 선택할 수 있음
  • 업로드가 성공하면 새로운 람다 레이어가 생성되고 각각의 레이어는 버전별로 수정이 불가능. 만약 수정이 필요하다면 zip파일을 다시 올리고 새로운 리비전이 생성
  • 람다 함수를 호출하면 제공한 순서대로 레이어가 /opt 폴더에 생성
    • 레이어는 모두 동일한 경로에 생성되므로 이전에 생성한 레이어와 다음 생성된 레이어의 이름이 같을 경우, 덮어씌워지는 문제가 발생할 수 있음. → 레이어 호출 순서 중요

람다 레이어 장점

  • 종속성과 사용자 정의 비즈니스 로직 사이에서 우려 요소를 강제로 분리
  • 함수 코드를 더 작고 제작 목적에 더 집중하도록 만듦
  • 패키징 및 업로드해야 할 코드가 더 적고 종속성을 재활용할 수 있으므로 배포 시간이 단축

마치며

람다 레이어를 사용하여 람다에 올릴 패키지의 용량을 줄일 수 있지만 람다는 250MB 크기 제약은 여전히 “한 함수의 소스코드 크기 + 레이어 크기 합”으로 되어 있기 때문에 레이어로 쪼개더라도 총 합이 250MB로 제약이 걸려 있습니다. 따라서 람다 레이어를 단순히 람다 함수의 패키지 용량을 줄이는 목적이 아닌 비즈니스 로직 분리 및 다른 람다 함수에서 공통적으로 사용하는 패키지를 업로드 하는 점에 집중 해야 람다 레이어를 쓰는 목적성을 뚜렷하게 볼 수 있을 것입니다.

'AWS' 카테고리의 다른 글

[AWS] 람다 레이어(Lambda Layer)란?  (0) 2019.01.27
[AWS] 람다(Lambda)란?  (0) 2019.01.27
[AWS-EC2] 리눅스, 맥 터미널로 EC2 Instance 접속하기  (0) 2016.09.23

AWS람다를 찾아보면 서버리스(serverless) 라는 단어를 볼 수 있습니다.  처음 접했을 때 서버가 없는데 어떻게 요청을 받고 실행할 지 햇갈렸는데 여기서 서버리스는 내가 요청받고 처리하는 서버가 없는 것을 뜻합니다. 한 마디로 내 서버가 필요없이 AWS 서버가 알아서 처리해준다는 것입니다. 간략하게 람다를 사용하는 목적은 서버에 대한 걱정 없이 코드를 실행하고 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 아래에서 좀 더 자세하게 설명하겠습니다.

AWS Lambda 란? 

  • 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행
  • 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 별도의 관리 없이 실행 가능
  • 코드를 업로드하면 Lambda에서 높은 가용성으로 코드를 실행 및 확장하는 데 필요한 부분을 처리함
  • 다른 AWS 서비스에서 코드를 자동으로 트리거하도록 설정하거나 웹 또는 모바일 앱에서 직접 코드를 호출할 수 있음

프로비저닝이란?

사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말합니다. 서버 자원 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있고 수동으로 처리하는 '수동 프로비저닝'과 자동화 툴을 이용해 처리하는 '자동 프로비저닝'이 있습니다.

Lambda 의 주요 장점

  • 인프라에 대한 걱정 없이 코드 실행 가능 -> NoOps 실현
  • 트리거를 이용해 애플리케이션을 자동으로 확장/축소 가능.
  • 코드가 병렬로 실행되고 각 트리거는 개별적으로 처리되어 정확히 워크로드 규모에 맞게 조정됨.
  • 100ms 단위로 코드가 실행되는 시간 및 코드가 트리거되는 회수를 측정하여 요금을 부과하고, 코드가 실행되지 않을 때는 요금이 부과되지 않음.

Lambda 사용 사례

람다를 AWS의 다른 서비스들과 조합하여 사용하면 더 큰 시너지를 낼 수 있다는 것이 람다의 또 다른 장점인 것 같은데요, 이런 방법으로 람다를 이용하면 어떤 것들을 구축할 수 있는지 사용 사례를 보겠습니다.

  • 실시간 파일 처리
    • Amazon S3를 사용하여 업로드하는 즉시 데이터를 처리하도록 AWS Lambda를 트리거할 수 있음. Lambda를 사용하여 실시간으로 이미지를 썸네일하고, 동영상을 트랜스코딩하고, 파일을 인덱싱하고, 로그를 처리하고, 콘텐츠를 검증하고, 데이터를 수집 및 필터링할 수 있음
  • 실시간 스트림 처리
    • AWS Lambda 및 Amazon Kinesis를 사용하여 애플리케이션 활동 추적, 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 정리, 지표 생성, 로그 필터링, 인덱싱, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 및 측정을 위한 실시간 스트리밍 데이터를 처리할 수 있음.
  • 추출, 변환, 로드
    • AWS Lambda를 사용하여 DynamoDB 테이블의 모든 데이터 변경에 대한 데이터 검증, 필터링, 정렬 또는 기타 변환 작업을 수행하고 변환된 데이터를 다른 데이터 스토어로 로드할 수 있음.
  • IoT 백엔드
    • AWS Lambda 및 Amazon Kinesis를 사용하여 사물 인터넷(IoT) 디바이스 데이터 텔레메트리 및 분석을 위한 백엔드를 구축할 수 있음.
  • 모바일 백엔드
    • AWS Lambda 및 Amazon API Gateway를 사용하여 API 요청을 인증 및 처리하도록 백엔드를 구축할 수 있음.
  • 웹 애플리케이션
    • AWS Lambda를 다른 AWS 서비스와 결합하면, 확장성, 백업 또는 여러 데이터 센터 중복에 필요한 별도의 관리 작업 없이 개발자가 자동으로 확장 및 축소되고 여러 데이터 센터에 걸쳐 가용성이 높은 구성에서 실행되는 강력한 웹 애플리케이션을 구축할 수 있음.


'AWS' 카테고리의 다른 글

[AWS] 람다 레이어(Lambda Layer)란?  (0) 2019.01.27
[AWS] 람다(Lambda)란?  (0) 2019.01.27
[AWS-EC2] 리눅스, 맥 터미널로 EC2 Instance 접속하기  (0) 2016.09.23

고스트 프로토콜(GHOST Protocol)은 비트코인의 성능 향상과 보안성 향상을 위해 나온 알고리즘입니다. 이더리움은 고스트 프로토콜을 수정하여 적용한 결과, 빠른 블록 생성 속도를 가지면서 보안성도 높이는 결과를 얻었습니다. 비트코인은 블록 생성 속도가 느리기 때문에 stale 블록의 생성확률이 낮고 보안성이 높습니다. 반면, 이더리움은 블록 생성 속도가 빠르기 때문에 stale 블록의 생성확률이 높고 보안성이 낮습니다. 이러한 문제를 보안하기 위해 이더리움은 고스트 프로토콜을 적용하여 stale 블록을 잘 처리하고 보안성도 높였습니다.

고스트 프로토콜은 stale 블록의 처리에 대한 알고리즘이라고 볼 수 있습니다. 고스트 프로토콜은 bitcoin을 위해 생성됬습니다. 비트코인은 블록생성시간이 약 10분으로 느리기 때문에 stale 블록의 생성확률이 매우 낮습니다. 만약, stale 블록이 발생하면 가장 긴 블록을 메인 블록체인(Canonical Blockchain)에 연결하고 나머지 stale 블록은 버립니다. 하지만 이를 위해 10분을 기다리므로 비트코인은 매우 느립니다. 이를 보완하기 위해 이더리움은 블록생성 시간을 약 12초 정도로 매우 빠르게 만들었습니다. 그러나 블록이 빠르게 생성되면 그만큼 stale 블록이 생성될 확률이 높아지므로 안정성이 떨어집니다. 이를 보완하기 위해 이더리움은 수정된 고스트 프로토콜을 적용한 이유입니다.

상관관계

블록 크기, 블록 생성 시간, 트랜잭션 처리 성능, fork 수, 보안성은 서로 상관관계를 갖고 있습니다. 

블록 사이즈와 블록생성속도가 커지면 트랜잭션 처리율이 올라가고 fork되는 블록의 수가 늘어납니다. 결과적으로 블록체인 네트워크의 보안성이 떨어집니다.

비트코인의 경우 블록생성속도는 약 10분으로 느립니다. 느린 블록생성속도 때문에 트랜잭션 처리 성능도 낮아지는 대신 fork되는 블록의 수는 줄어듭니다. fork의 수가 줄어들기 떄문에 stale 블록이 발생하는 빈도 또한 줄어서 자연스럽게 보안성이 늘어납니다. 하지만 블록생성속도가 매우 느리다는 치명적인 단점을 갖고 있습니다. 이더리움에서는 이것을 개선하여 블록생성속도를 약 12초 정도로 매우 빠르게 유지합니다. 하지만 블록생성속도를 올리면 상관관계에 의해 fork의 수가 늘어납니다. 즉 늘어난 fork의 수 때문에 네트워크의 보안성을 낮춥니다. 이를 해결하기 위해 이더리움은 수정된 고스트 프로토콜을 사용합니다. stale 블록에 대해 보상을 주고 가장 긴 것이 아닌 가장 무거운 것을 사용합니다. 수정된 고스트 프로토콜을 적용함으로써 네트워크의 보안성을 올리고 트랜잭션 처리율을 유지하면서 블록생성속도도 빠르게 할 수 있는 것입니다.

왜 빠른 블록생성이 좋지만은 않을까?

현재 블록체인의 빠른 승인 시간은 높은 stale 생성 비율로 인해 보안성이 낮아진다는 문제가 있습니다. 왜냐하면 블록이 네트워크를 통해 전파되기 위해서는 일정 시간이 필요하기 때문입니다. 예를 들어, 마이너 A가 블록을 채굴하고, 이 블록이 전파되기 전에 마이너 B가 블록을 채굴한 경우, 마이너 B의 블록은 버려지고(stale) 이는 네트워크의 안정성에 기여하지 못합니다. 또한 중앙화 이슈가 있는데, 만약 마이너 A가 마이닝 풀이며 30%의 해시 파워를 가지고 있고 마이너 B가 10%의 해시 파워를 가진다면, A는 전체 시간 중 70%의 시간에서 stale 블록을 생성할 가능성이 있지만 (30%로 자신이 생성한 블록은 즉시 전파될 것이므로) B는 90%의 시간동안 리스크를 가지게 됩니다.

그러므로 블록 인터벌이 높은 stale 생성 비율을 가지게 될 만큼 짧다면 A는 실질적으로 단순히 그 규모로 인해 훨씬 효율적이 될 수 있습니다. 이런 이유로 블록을 빠르게 생성하는 블록체인은 많은 해시 파워를 가진 한 마이닝 풀이 마이닝 프로세스에 있어서 실질적인 통제력을 가지게 될 수 있습니다.

고스트 프로토콜이란?

고스트 프로토콜은 Greedy Heaviest Object subTree의 약자로 '가장 큰 무게를 가진 subtree'를 선택하는 알고리즘입니다. 비트코인의 경우, fork가 발생했을 때 길이가 더 길게 연결된 블록을 메인 블록체인으로 하고 stale블록은 버립니다. 이더리움의 경우, fork가 발생했을 때 더 무거운 쪽을 선택하게 됩니다. 이더리움은 비트코인의 고스트 프로토콜을 살짝 수정하여 사용하고 있습니다.

이더리움의 고스트 프로토콜 알고리즘을 간단하게 설명하면 '제네시스 블록에서 출발하여 각 subtree들이 얼마나 블록을 포함하고 있고, 그 블록들의 개수가 많은 체인을 메인체인의 블록으로 선택하겠다' 입니다.

예시


이더리움 고스트 프로토콜을 위 그림으로 다시 예시를 들어보면 시작은 제네시스 블록인 0에서 시작합니다. 0를 부모로 가지는 노드는 1B와 1A입니다. 1B를 루트로 한 subtree의 노드 개수는 12개이고 1A는 6개입니다. 따라서 메인체인에 붙게 되는 것은 1B입니다. 다음으로 1B를 부모로 가지는 노드는 2D, 2C, 2B입니다. subtree의 노드개수는 각각 4개, 5개, 2개이므로 메인에 붙게 되는 노드는 2C입니다. 이러한 방식을 subtree에 전부 적용하면 선택되는 메인체인은 0-1B-2C-3D-4B 입니다. 비트코인의 경우, 위 그림에서 동그라미로 표시되어 있는 것을 메인체인으로 선택합니다.



수정된 GHOST Protocol의 내용은 다음과 같습니다.

  • 하나의 블록은 반드시 하나의 부모 블록을 지정하며, 0 또는 그 이상의 엉클 블록을 지정. 현재 2개까지 지원하고 있다.
  • 블록 A의 K번째 조상의 직접적인 자손이어야 한다.
  • 블록 A의 조상이어서는 안된다.
  • 엉클블록 마이너 보상은 블록 생성 시에 받는 보상의 93.75%를 보상으로 받고, 엉클 블록이 포함된 정상블록의 마이너는 엉클블록 1개당 3.125%의 추가 보상을 받게 됩니다.


요약

블록생성속도를 올리는 것은 블록체인 네트워크 전체의 처리율과 비례관계를 갖지만 보안성과는 반비례 관계를 갖습니다. 고스트 프로토콜을 이용하여 이를 보완할 수 있습니다. 따라서 이더리움의 고스트 프로토콜은 전체 성능과 보안에 아주 중요한 역할을 한다고 할 수 있습니다.



+ Random Posts