리플과 같이 최초 발행 이후 추가발행이 불가능한 암호화폐도 있지만 대부분은 채굴방식을 통해 추가발행이 진행됩니다. 채굴방식은 대표적으로 POW, POS, DPOS가 있습니다. 

한마디로 어떤 방식으로 채굴을 해서 보상을 받을것인지에 대한 약속 이라고 보면 됩니다. 명칭은 채굴 증명방식합의 프로토콜합의 메카니즘 등 여러 용어로 부르기도 합니다.

POW (Proof of Work)

대표코인: 비트코인, 라이트코인, 제트캐시, 모네로 등

작업증명으로 부르기도 하며 해시연산을 처리하는 하드웨어(GPU, ASIC채굴기) 등을 사용해서 증명하는 방식입니다. 간단하게 말해 하드웨어 장비를 사용해 코인을 채굴하는 것입니다. 

자세하게..

IT전공자가 아니라면 아래의 내용은 어려울 수도 있습니다. 위의 간단한 설명으로도 충분하니 넘어가도 상관없습니다.

PoW의 방식은 노가다라고도 볼 수 있습니다. 해시함수에서 나온 출력값을 채굴자들이 하드웨어 장비 (GPU, CPU와 같은 컴퓨팅 파워)를 통해 결과를 도출하는 것입니다. 여기서 해시는 단방향 암호화 기술이므로 결과값을 가지고 역으로 입력값을 찾아낼 수가 없습니다 (한마디로 복호화가 불가능). 따라서 무차별 대입으로 출력값과 똑같은 결과가 나올때까지 실행하는 방법밖에 없습니다. 이렇게 초당 해시를 처리하는 것을 해시레이트(h/s)라 부르기도 합니다.

이러한 방식으로 문제를 해결하면 가장 빨리 채굴된 블록만 인정을 받고 나머지는 버려지게 되기 때문에 이중지불 문제가 해결되게 됩니다.


여기서 의문점은 거대 자본가가 슈퍼컴퓨터를 구입하여 연산을 돌린다면 분산된 장부작성 방식이 아닌 중앙집권적 방식이 되지 않을까 할 수 있습니다.

첫 번째로 과반수의 해시파워를 가진 컴퓨터를 구매하는 건 엄청나게 많은 돈이 들어갑니다. 만약 천문학적인 돈을 투자하여 구매했다 하더라도, 거래가 위조되고 부당한 장부라고 느낀다면 해당 블록체인의 가치가 급락할 것이기 때문에 정당한 방식으로 네트워크를 운영하는 것이 훨씬 큰 이득입니다.

장점

  • 최소 가격대 형성이 확실하게 정해져 있음
  • 강력한 보안성
  • 서비스 남용을 쉽게 방지

단점

  • 채굴난이도가 높아지면서 연산에 필요한 고사양 장비가 많이 필요하고, 과도한 전력소모로 인한 에너지 낭비가 커짐
  • 채굴난이도가 높아지면서 개인 채굴자는 채굴을 할 수 없는 수준까지 옴
  • 지속적으로 해시파워를 유지해야함
  • 채굴하는 업자끼리의 단합 문제

POS (Proof of Stake)

대표코인: 퀀텀, 네오, 스트라티스

지분증명이라 부르기도 하며 채굴기 없이 본인이 소유한 코인의 지분으로 채굴되는 방식입니다. 위 POW의 단점을 극복하기위해 등장하였습니다.

자세하게..

IT전공자가 아니라면 아래의 내용은 어려울 수도 있습니다. 위의 간단한 설명으로도 충분하니 넘어가도 상관없습니다.

validator가 현재 보유하고 있는 자산(stake) 양에 비례하여 블록을 생성할 권한을 더 많이 부여되는 방식입니다. 마치 이자와 같은 방식으로 코인이 지급되며, 일정 수 이상의 코인을 보관하고 있는 지갑을 블록체인 네트워크에 연결시켜놓기만 하면 보상을 받을 수 있습니다. 

블록 생성자와 지분 생성자의 이해관계를 일치시킴으로써 블록을 나쁜 의도로 생성할 동기부여를 없애며, 잘못 생성할 경우 패널티를 부여합니다. 이더리움은 PoW에서 PoS로 컨센서스 알고리즘(코인을 보유한 지분율에 따라 새롭게 생성하는 코인을 분배받는 방식)을 변경하려 하고 있습니다. 

만약 fork가 일어나 체인이 갈라지더라도 더 많은 자산(검증)을 보유하는 체인이 살아남고 나머지는 버려지게 되는 것이 (이건 POW와 동일) PoS 합의 메커니즘의 운영방식입니다.


이러한 설명으로는 컴퓨팅파워 없이 이자를 받게 되니 좋을 것 같지만 코인을 보유하고 있는 사람 누구나가 DB를 업데이트 할 수 있게 되는 방식은 위험하다고 볼 수 있습니다. 해당 코인 지분이 많은 사람이 악의적인 공격을 가하게 된다면 해당 블록체인은 위험할 수 밖에 없기 때문입니다.

예를 들어, 퀀텀의 51% 지분을 갖고 있는 A라는 사람이 데이터 업데이트의 권한을 쥐고 흔들 수 있다고 볼 수 있습니다. 따라서 맘에 안드는 사람 B의 자산을 A가 악의적으로 기록을 삭제하여 0원으로 만들 수도 있기 때문입니다.


기존 PoW 방식은 블록체인의 정당성을 확인할 수 있지만 채굴노드의 경우 하드웨어를 직접적으로 갖춰야 하고 에너지 소모가 굉장히 클뿐더러 대량의 채굴기를 돌리는 경우 지리적으로도 넓은 평지를 가지고 있어야 가능하다 왜냐하면 채굴기 자체에서 발생하는 열과 소음이 상당하기 때문이다. 

  • PoW에서 51%의 해시파워를 가지는 비용 = 약 2500억원
  • PoS에서 전 세계 자산의 51% = 약 25조원

이렇게 100배 가량의 차이가 나기 때문에 PoS방식이 중앙집권화가 더 어렵고 코인을 가진 누구나 네트워크에 허가없이 참여하기 때문에 오히려 분산화가 더 잘된다고 볼 수 있습니다. 

장점

  • 해시파워가 많이 필요하지 않아 경제적이며 친환경적
  • 블록 생산자의 탈중앙화로 안정성 확보
  • 블록을 생성하기 위해서는 지분을 담보로 잡아야 하기 때문에 덤핑 방지

단점

  • 모두 이자를 받으려고 코인을 묶어놓기 때문에 시중 코인의 유통량 감소로 이어질 수 있음
  • 검증이 되지 않았기 때문에 보안성이 강한지 확신할 수 없음
  • 코인을 많이 보유한 사람이 권력을 지게되는 구조 (부익부 빈익빈)

DPOS (Delegated Proof-of-Stake)

대표코인: 스팀, 이오스, 아크, 라이즈

위임지분증명이라 부르기도 하며 말그대로 위임된 POS입니다. POS가 자산을 가진 사람들이 전부 참여할 수 있는 방식이라면 DPOS는 특정 인원에게만 POS를 할 수 있도록 권한을 위임하는 것입니다. 즉 특정인 몇 명만이 블록을 생성하여 증명할 수 있습니다.

자세하게..

IT전공자가 아니라면 아래의 내용은 어려울 수도 있습니다. 위의 간단한 설명으로도 충분하니 넘어가도 상관없습니다.

DPoS 네트워크는 구성하는 모든 노드들의 투표 결과로 정한 상위 노드에게 권한을 위임하여 일종의 대표자가 되는 것입니다. PoS의 경우, 일정 지분을 소유한 모든 노드에게 블록 생성 권한이 주어지기에 오랜 시간이 필요하지만 DPoS의 경우, 투표 결과로 정한 상위 노드 라는 비교적 적은 숫자로 인해 합의 시간과 비용을 줄일 수 있습니다. 합의시간과 비용이 줄어든다는 것은 전송처리가 굉장히 빠르다는 것과 밀접한 관련이 있습니다.

DPoS는 PoS와 달리 소규모 참여자에게는 꿀단지 입니다. PoS는 참여하기 위해 최소 코인을 (말이 최소지 어마어마한 돈) 가지고 있고 블록생성을 위해 24시간 네트워크를 유지하며 하드포크마다 알고리즘 업데이트를 할 필요가 없습니다. 소규모 참여자는 권한을 위임하고 위임한 상위노드로부터 이자를 받거나 송금 수수료를 감면받을 수 있습니다.


상위 노드로서 뽑힌 사용자는 PoS에서와 같이 블록생성을 진행할 수 있습니다. 상위노드로 뽑히는 기준은 본인을 투표한 구성원의 코인 총 합 순위로 매기는 것이 보통의 방법입니다.

장점

  • 소규모 참여자도 이득을 볼 수 있음
  • 송금속도가 빠름

단점

  • 상위 노드만 블록생성에 참여하기 때문에 탈중앙화가 맞는지 애매함
  • 상위 노드만 블록생성에 참여하기 때문에 보안이 취약함
  • 코인 보유량이 적어도 상위 노드로 뽑힐 수 있음

마치며

이외에도 POI, Zero-Knowledge Proof 등등 여러 채굴방식이 존재하긴 하는데 저 3개가 가장 대표라 생각되어 정리했습니다.

'블록체인' 카테고리의 다른 글

채굴방식(마이닝) POW, POS, DPOS 란?  (0) 2018.03.18
블록체인이란?  (0) 2018.03.18

블록체인(block chain)이란?

블록체인은 관리 대상 데이터를 블록이라고 하는 소규모 데이터들이 P2P 방식을 기반으로 생성된 체인 형태의 연결고리 기반 분산 데이터 저장환경에 저장되어 누구도 임의로 수정될 수 없고 누구나 변경의 결과를 열람할 수 있는 분산 컴퓨팅 기술 기반의 데이터 위변조 방지 기술입니다. 이는 근본적으로 분산 데이터 저장기술의 한 형태로, 지속적으로 변경되는 데이터를 모든 참여 노드에 기록한 변경 리스트로서 분산 노드의 운영자에 의한 임의 조작이 불가능하도록 고안되었습니다. 잘 알려진 블록체인의 응용 사례는 암호화폐의 거래과정을 기록하는 탈중앙화된 전자장부로서 비트코인이 있습니다. 이 거래 기록은 의무적으로 암호화되고 블록체인 소프트웨어를 실행하는 컴퓨터상에서 운영되고 비트코인을 비롯한 대부분의 암호화폐들이 블록체인 기술 형태에 기반하고 있습니다.

출처: 위키백과

다시말해 블록체인은 데이터 분산 처리 기술입니다. 네트워크에 참여하는 모든 사용자가 모든 거래내역 등의 데이터를 분산하여 저장하는 기술을 뜻합니다. 이렇게 저장된 데이터를 블록이라 칭하며 여러 블록들을 시간의 순서대로 묶는 형태를 가져 블록체인이라 불리게 됩니다. 이 모든 사용자가 거래내역을 보유하고 있어 거래 내역을 확인할 때는 모든 사용자가 보유한 장부를 대조하고 확인해야 합니다. 이러한 이유로 블록체인은 공공거래장부, 분산거래장부 로 불리기도 합니다.


기존 거래와 블록체인의 차이점

출처: SW 중심사회

기존의 거래방식은 중앙기관 즉, 은행에서 모든 거래 내역을 저장하고 있습니다. 개인 간 거래사실을 저장하여 증명 해야 하기 때문입니다. 

블록체인은 은행과 다르게 해당 네트워크에 참여한 인원이 거래내역을 나눠서 저장하게 됩니다. 만약 한 네트워크에 100명이 참여하고 있다면 개인간 거래 내역을 100개의 블록을 생성해 100명 모두에게 전송한 뒤 저장을 합니다. 후에 거래내역을 확인할 때는 블록으로 나눠 저장한 데이터들을 연결해 확인합니다.

블록체인 특장점

위에서 말한것 처럼 블록체인은 분산저장을 한다는 점이 특징입니다. 기존 거래방식에서는 데이터를 위,변조 하기 위해선 중앙서버를 공격하면 됐습니다. 그러나 블록체인의 경우 여러 명이 동일한 데이터를 저장하기 때문에 위, 변조가 어렵습니다. 블록체인 네트워크를 위, 변조하기 위해서는 참여자의 거래 데이터를 모두 공격해야 하기 때문에 사실상 해킹이 불가능하다고 여겨집니다. 

블록체인은 중앙 관리자가 필요없습니다. 중앙기관이나 관리자 없어도 다수가 데이터를 저장, 증명할 수 있기 때문에 탈중앙이 가능합니다. 

블록체인, 비트코인

비트코인과 같은 암호화폐가 등장한 것도 위에서 설명한 블록체인의 특장점 덕분입니다. 비트코인을 원하는 사람들이 직접 채굴을 통해 발행할 수 있습니다. 일각에서는 블록체인이 중앙기관과 은행을 대체할 것이라는 전망을 보여주기도 하지만 제 생각은 어려울 것으로 보입니다.


암호화폐에서는 이중지불방지를 위해 아래와 같은 다양한 시간표시 방법들을 사용합니다. 이중지불이란 100만원의 잔고에서 돈을 100만원 출금을 한 뒤, 잔고가 0원으로 갱신되기 전 재빨리 100만원을 또 출금하는 시간차 공격을 말합니다.

  1. 작업증명 (POW : proof-of-work)
  2. 지분증명 (POS : proof-of-stake)
  3. 위임지분증명 (DPOS: delegated proof-of-stake)

대표적으로 위와 같은 방법으로 이중지불 문제를 해결하고 있습니다.


암호화폐 간략한 개발과정

비트코인을 시작으로 성능개선, 익멱성, 저장기능과 스마트 컨트랙트 기능 등 다양한 기능들이 개발되었습니다.

'블록체인' 카테고리의 다른 글

채굴방식(마이닝) POW, POS, DPOS 란?  (0) 2018.03.18
블록체인이란?  (0) 2018.03.18


import psycopg2.extras
self.conn = psycopg2.connect(host='127.0.0.1', dbname='postgres', user='postgres', password='postgres', port=5432)
self.cur = self.conn.cursor(cursor_factory=psycopg2.extras.DictCursor)


PhantomJS란?

헤드리스 브라우저로 요즘 유명한 브라우저

Headless browser란?

헤들리스 브라우저는 그래픽 유저 인터페이스가 없는 웹브라우저를 뜻합니다. 헤들리스 브라우저는 웹 브라우저와 유사한 환경을 가졌지만 커맨드 라인 인터페이스를 통해 실행하고 제어할 수 있는 브라우저들을 말합니다. 헤들리스 브라우저엔 자바로 작성된 HtmlUnit이라는 것도 많이 사용됐었습니다.

사용용도

PhantomJS와 같은 헤들리스 브라우저는 아래와 같은 용도로 사용됩니다.

Jasmine, QUnit, Mocha와 같은 테스트 프레임워크에서 함수를 테스트 할 때 사용

웹사이트의 스크린샷, 썸네일 프리뷰 등을 만들 때 사용. SVG, Canvas를 포함한 웹 컨텐츠도 캡쳐가 됨

DOM api, jQuery와 같은 라이브러리로 웹 페이지를 조작할 때 사용

HAR 파일을 만들어 웹 페이지의 성능 측정을 할 때 사용. Jenkins나 YSlow를 통해 자동화 할 수도 있음.

DDOS 공격

광고 노출횟수 늘리기


설치

http://phantomjs.org/download.html

예제

http://phantomjs.org/examples/index.html

'' 카테고리의 다른 글

Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20

내장 @property 데코레이터를 이용하면 더 간결한 방식으로 인스턴스의 속성에 접근하게 할 수 있습니다. 고급 기법이지만 흔히 사용하는 @property 사용법 중 하나는 단순 숫자 속성을 즉석에서 계산하는 방식으로 변경하는 것입니다. 호출하는 쪽을 변경하지 않고도 기존에 클래스를 사용한 곳이 새로운 동작을 하게 해주므로 매우 유용한 기법입니다. 또한 시간이 지나면서 인터페이스를 개선할 때 중요한 임시방편이 됩니다.


예를 들어 구멍 난 양동이의 할당량을 일반 파이썬 객체로 구현하려 한다고 가정합니다. 다음 Bucket 클래스는 남은 할당량과 이 할당량을 이용할 수 있는 기간을 표현합니다.

import datetime


class Bucket:
    def __init__(self, period):
        self.period_delta = datetime.timedelta(seconds=period)
        self.reset_time = datetime.datetime.now()
        self.quota = 0

    def __repr__(self):
        return 'Bucket(quota=%d) ' % self.quota
# 구멍난 양동이 알고리즘은 양동이를 채울 때마다 할당량이 다음 기간으로 넘어가지 않게 하는식으로 동작

def fill(bucket, amount):
    now = datetime.datetime.now()
    if now - bucket.reset_time > bucket.period_delta:
        bucket.quota = 0
        bucket.reset_time = now
    bucket.quota += amount
# 할당량을 소비하는 쪽에서는 매번 사용할 양을 뺄 수 있는지부터 확인해야 함

def deduct(bucket, amount):
    now = datetime.datetime.now()
    if now - bucket.reset_time > bucket.period_delta:
        return False
    if bucket.quota - amount < 0:
        return False
    bucket.quota -= amount
    return True

bucket = Bucket(60)
fill(bucket, 100)
print(bucket)
# 결과
# Bucket(quota=100)

if deduct(bucket, 99):
    print('Had 99 quota')
else:
    print('Not enough for 99 quota')
print(bucket)
# 결과 이용할 수 있는 양보다 많이 뺴려해서 진행이 중단, 이 경우 양동이의 할당량은 그대로 남음
# Had 99 quota
# Bucket(quota=1)

if deduct(bucket, 3):
    print('Had 3 quota')
else:
    print('Not enough for 3 quota')
print(bucket)
# 결과
# Not enough for 3 quota
# Bucket(quota=1)

이 구현에서 문제는 양동이의 할당량이 어떤 수준에서 시작하는지 모른다는 점입니다. 양동이는 0이 될 때까지 진행 기간 동안 할당량이 줄어듭니다. 0이 되면 deduct가 항상 False를 반환합니다. 이때 deduct를 호출하는 쪽이 중단된 이유가 Bucket의 할당량이 소진되어서인지 아니면 처음부터 BBucket에 할당량이 없어서인지 알 수 있다면 좋을 것입니다. 


__repr__ 함수의 용도 ( vs __call__ 차이)


간단하게 print 역할을 함.

아래는 __repr__함수와 __call__함수의 차이를 나타냄

class Test:
    def __call__(self, *args, **kwargs):
        return '__call__ 호출'
    def __repr__(self):
        return '__repr__ 호출'


test = Test()

print(test) # __repr__ 호출
print(test()) # __call__ 호출


__repr__

  • 디버깅할 떄 사용
  • 객체에서 선언되있는 공식적인 값을 출력

__call__

  • 인스턴스가 함수로 사용될 때 사용
  • __init__함수와 쓰임새가 비슷?????!!
  • __call__ vs __init__ 차이



    __init__은 클래스를 인스턴스로 생성 할 때 맨 처음 사용.

    __call__은 생성된 인스턴스를 호출할 때 사용

    class foo:
        def __init__(self, a, b, c):
            # ...
    
    x = foo(1, 2, 3) # __init__


    class foo:
        def __call__(self, a, b, c):
            # ...
    
    x = foo()
    x(1, 2, 3) # __call__



문제를 해결하려면 클래스에서 기간동안 발생한 max_quota와 quota_consumed의 변경을 추적하도록 수정하면 됩니다. 

# import datetime
# import time
#
# now_dt = datetime.datetime.now()
# print('현재 시간: ', now_dt)
#
# now_t = time.mktime(now_dt.timetuple()) + now_dt.microsecond / 1E6
# c_now_dt = datetime.datetime.fromtimestamp(now_t, datetime.timezone.utc)
#
# print('datetime-> time -> datetime 변환시간: ', c_now_dt)
#
# print('replace() 변환시간: ',now_dt.replace(tzinfo=datetime.timezone.utc))
# print('astimezone() 변환시간: ',now_dt.astimezone(datetime.timezone.utc))

# 결과
# 2017-10-15 18:45:32.357988
# 1508060732.357988
# 2017-10-15 09:45:32.357988+00:00

import datetime


class Bucket:
    def __init__(self, period):
        self.period_delta = datetime.timedelta(seconds=period)
        self.reset_time = datetime.datetime.now()
        self.max_quota = 0
        self.quota_consumed = 0

    def __repr__(self):
        return 'Bucket(max_quota=%d, quota_consumed=%d) ' % (self.max_quota, self.quota_consumed)

    # 현재 할당량의 수준을 계산하려고 생성
    @property
    def quota(self):
        return self.max_quota - self.quota_consumed

    @quota.setter
    def quota(self, amount):
        delta = self.max_quota - amount
        if amount == 0:
            # 새 기간의 할당량을 리셋
            self.quota_consumed = 0
            self.max_quota = 0
        elif delta < 0:
            # 새 기간의 할당량을 채움
            assert self.quota_consumed == 0
            self.max_quota = amount
        else:
            # 기간동안 할당량을 소비함
            assert self.max_quota >= self.quota_consumed
            self.quota_consumed += delta

def fill(bucket, amount):
    now = datetime.datetime.now()
    if now - bucket.reset_time > bucket.period_delta:
        bucket.quota = 0
        bucket.reset_time = now
    bucket.quota += amount
# 할당량을 소비하는 쪽에서는 매번 사용할 양을 뺄 수 있는지부터 확인해야 함

def deduct(bucket, amount):
    now = datetime.datetime.now()
    if now - bucket.reset_time > bucket.period_delta:
        return False
    if bucket.quota - amount < 0:
        return False
    bucket.quota -= amount
    return True

bucket = Bucket(60)
print('Init', bucket)
fill(bucket, 100)
print('Filled', bucket)

if deduct(bucket, 99):
    print('Had 99 quota')
else:
    print('Not enough for 99 quota')
print('Now', bucket)


if deduct(bucket, 3):
    print('Had 3 quota')
else:
    print('Not enough for 3 quota')
print('Still', bucket)

# 결과
# Init Bucket(max_quota=0, quota_consumed=0) 
# Filled Bucket(max_quota=100, quota_consumed=0) 
# Had 99 quota
# Now Bucket(max_quota=100, quota_consumed=99) 
# Not enough for 3 quota
# Still Bucket(max_quota=100, quota_consumed=99)


이처럼 property를 사용해 bucket클래스가 변경된 사실을 몰라도 되는 장점이 있습니다.

쿼리를 실행했다가 에러가 발생했다던지 너무 오래걸려 강제종료를 했다던지 등의 행동을 했는데 쿼리가 계속 돌고 있어서 테이블에 대한 transaction lock이 걸린 경우, 실행 중인 쿼리를 종료해야 할 때 유용하게 쓰입니다.

현재 실행 중인 쿼리 및 pid 확인

SELECT * FROM pg_stat_activity ORDER BY query_start ASC;

실행 중인 쿼리 종료

SELECT pg_cancel_backend(pid값); -- 성공하면 true, 실패하면 false 반환


검색하고자 하는 테이블을 참조하고 있는 테이블 및 컬럼 리스트 확인

SELECT kcu.table_name AS child_table,
	kcu.table_schema AS child_schema,
    kcu.column_name AS child_column,
    kcu.constraint_name AS child_constraint
 FROM information_schema.table_constraints tc
   JOIN information_schema.key_column_usage kcu ON tc.constraint_name = kcu.constraint_name
   JOIN information_schema.constraint_column_usage ccu ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY' and ccu.table_name = '테이블명';
GROUP BY kcu.table_name, kcu.table_schema, kcu.column_name, kcu.constraint_name;

현재 테이블이 참조하고 있는 테이블 및 컬럼 확인

 SELECT tc.table_name AS child_table,
    kcu.column_name AS child_column,
    ccu.table_name AS foreign_table,
    ccu.column_name AS foreign_column
   FROM information_schema.table_constraints tc
     JOIN information_schema.key_column_usage kcu ON tc.constraint_name::text = kcu.constraint_name::text
     JOIN information_schema.constraint_column_usage ccu ON ccu.constraint_name::text = tc.constraint_name::text
  WHERE tc.constraint_type = 'FOREIGN KEY' and tc.table_name = '테이블명';


위의 FOREIGN KEY 대신 PRIMARY KEY 라던지 제약조건을 작성하면 해당하는 결과가 떨어짐

Jupyter Notebook이란?

Jupyter Notebook은 오픈소스 웹 애플리케이션으로 라이브 코드, 등식, 시각화와 설명을 위한 텍스트 등을 포함한 문서를 만들고 공유하도록 할 수 있습니다.

주로 데이터 클리닝과 변형, 수치 시뮬레이션, 통계 모델링, 머신 러닝 등에 사용할 수 있습니다. 

Jupyter Notebook은 파이썬, R, Scala 등 데이터 과학 분야에서 인기있는 프로그래밍 언어를 지원합니다. 가장 큰 장점은 실시간으로 인터렉티브하게 데이터를 조장하고 시각화할 수 있도록 해준다는 점입니다.



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

Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27

ansible이란?

  • 테스트 환경을 구축하는데 사용되는 툴 Provision & configuration management tool
  • python으로 개발되고 YAML이라는 언어를 통해 정의할 수 있고 json으로 통신
    • python Github project 중 상위 랭킹 (6위)
  • 해커 뉴스 분석을 보면 ansible이 많이 Mention 되어지고 있음
  • 오픈 소스 버전 (GPL)

ansible 장점 및 지원

  • 빠른 SSH통신, 빠른 provision이 가능
  • 추후 상용 환경에서 사용할 때 agent 기반이면 방화벽 이슈, agent 데몬 관리라는 불편한 점이 존재 (agent 방식은 확장성, 대규모 provision을 할 경우 매우 효과적이지만 서버와 통신하는 부분이 고도화되기 때문에 빠르고 간단한 provision을 할 수 없음)
  • 자동 배포 환경이 쉬움
  • 개발 가능성이 높은 오픈소스
  • 대부분이 멱등성을 제공
  • playbook
  • ad-hoc 지원.
  • 병렬 provisioning 지원.
  • vagrant
  • jinja2

멱등성(Idempotency)

  • 여러 번 적용해도 결과는 바뀌지 않음
  • 바뀌는 것이 없으면 당연히 배포되어도 바뀌지 않음
  • 바뀌는 부분이 있으면 그 부분만 반영
  • shell, command, file module은 보장 안됨

Ansible에서의 멱등성이란?

여러 번 ansible 툴을 사용하더라도 동일한 결과 값을 나올 수 있도록 제공되는 형태여야 합니다. 매번 다른 결과가 나오거나 에러가 나온다면 비 멱등성하다고 할수 있습니다. ansible 툴의 거의 대부분의 모듈은 멱등성을 제공합니다. 또한 멱등성을 제공하기 위해서 조건절을 제공하고 있습니다. 예를 들면, 처음 ansible 스크립트를 실행 후 다시 실행을 하면 상황에 따라서는 파일이 append가 될 수 있습니다. 그러나 멱등성의 원칙은 언제나 실행은 해도 결과가 동일하게 나옵니다. 또한 파일/디렉터리를 생성 또는 삭제하는 ‘create’ , ‘remove:’ 같은 ansible 모듈을 실행 할 때 ‘when;’ 조건절을 이용할수 있습니다. 대부분의 ansible 모듈이 멱등성을 보장한다는 의미는 상태를 파악할 수 있다는 의미를 가지게 됩니다.


ansible의 기본개념

ansible의 환경설정, 배포를 가능케 하는 언어입니다. 리모트 서버에 접속해서 무언가를 시행시키는 정책을 기술합니다. yaml 문법으로 정책이 기술되어 있으며 좀 더 고급 단계에서는 로드밸런서를 모니터링하는 복잡한 환경에서 사용할 수 있도록 합니다. 각 playbook은 하나 또는 하나 이상의 ‘play’를 두게 됩니다. Play의 목적은 여러 호스트들에 잘 정의된 ‘role’과 ‘task’를 매핑하는 역할을 합니다. Task는 ansible 모듈의 호출을 의미합니다. Role을 좀 더 편하게 관리하기 위해서 미리 정의된 yaml 파일을 include을 하는 것이 가능 합니다. 또한 host inventory 파일에 정의한 서버 그룹별로 각각 나누어 provision 할 수 있도록 할 수 있습니다. 서버당 디렉터리를 나누어서 각각의 설정 정보가 정의된 파일을 읽어 설치하게 합니다.

playbook

플레이북은 애드혹 테스트 실행 모드와는 완벽하게 다른 사용방법이며 특히 강력한 사용 방법입니다. 간단히 말해 플레이북은 정말 간단하게 설정을 관리하고 다수의 머신에 대한 배포 시스템에 대한 기본적인 단위입니다. 기존에 존재해왔던 것과 달리 복잡한 어플리케이션 형태의 배포에 매우 적합합니다. 플레이북은 설정을 정의할 수 있으며 특정 머신의 집합을 오가며 다른 작업을 수행하도록 수동으로 작업 순서를 설정하는것도 가능합니다. 이때에 작업은 동기 또는 비동기로 수행할 수 있습니다. /usr/bin/ansible 명령을 통한 애드혹 테스크를 실행하는 것에 반해 플레이북은 소스 컨트롤을 통해 보관하거나 사용자의 설정을 내보내거나 원격 시스템을 구성, 보장되는데 더욱 적합합니다. 플레이북을 통해 이러한 기술들을 구현하는 방법은 [Ansible-Example 저장소]에 정리가 되어있습니다.

ad-hoc

Adhoc 이라는 의미는 임시적으로 수행하는 의미. ansible의 playbook을 작성하여 수행하는 것이 아니라 임시적으로나 또는 특별하게 어떤 작업을 수행하기 위해서 사용할 수 있는 실행방법이라고 할 수 있음. 

Inverntory

리모트 서버에 대한 meta 데이터를 기술하는 파일입니다. Ansible에서는 inventory 파일에는 yaml을 적용하지 않았습니다. 기본 파일은 /etc/ansible/hosts를 읽게 하거나, 따로 inventory 파일을 만들고 옵션을 주어 동작하게 할수 있습니다. 만약 고정 ip를 가지고 있고 gosts 파일 안에 들어가 있지 않는 서버가 있다면 설정 파일을 만들수 있고 테스트 환경을 만들때 유용합니다.

Ansible의 한계

  • 시스템의 초기 설치 수행은 불가능 (kickstart, pxe 등을 사용하여야 함)
  • 시스템 모니터링은 지원하지 않음
  • 시스템 변경사항은 추적하지 않음


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

Jupyter Notebook이란?  (0) 2017.10.18
Ansible이란?  (0) 2017.10.18
WSGI, WAS, CGI 이해  (0) 2017.04.19
호스트 네임  (0) 2017.04.19
[Linux] SSL (Secure Socket Layer)  (0) 2017.03.27
[Linux] SSH (Secure Shell)  (0) 2017.03.27

시작하기 전에 hipchat, jenkins 계정은 모두 있다고 가정하고 설명합니다.

Hipchat

먼저 방을 생성한 다음, ... 버튼을 눌러 Integrations를 누른 후 Install new integrations를 선택합니다.



다음 Build your own integration 버튼을 클릭합니다.



다음 적당한 별칭 (bot의 이름)을 정해줍니다. 여기선 Deployment Bot이라 생성했습니다. (아래 스크린샷과 다름..)



Create버튼을 누르면 아래와 같은 화면과 


Send messages to this room by posting to this URL의 값이 있는데 여기서 room/252352 와 같이 room 번호와 auth_token=Hcr8hO8Hihoph8P 와 같은 api tocken을 따로 저장해둡니다. (jenkins에 등록할 때 필요함)


Jenkins



Jenkins > Credentials > System > Add Credentials을 눌러 아래와 같은 화면에서 Secret text를 선택한 후, Scope에 아까 적어놓은 api tocken을 붙여 넣습니다. id와 description은 jenkins에서 확인하는 용도로 아무 이름이나 지으면 됩니다.



다음 젠킨스 잡을 생성한 다음 '빌드 후 조치' 탭에서 HipChat notifications를 선택해 활성화 시킵니다.



마지막으로 Credentials부분에 아까 설정한 Credentials을 선택하고 미리 저장해놓은 프로젝트 방번호를 입력합니다.  다음 아래와 같이 언제 HipChat notifications을 발생할 지를 선택해주면 끝입니다.

'저장소' 카테고리의 다른 글

Jenkins - Hipchat 연동  (0) 2017.10.16
SourceTree 설치방법 및 용어  (0) 2016.07.08

+ Recent posts