블록 체인은 이미 뜨거운 IT 화제 중 하나다. 

알아가면 알아갈 수록 이 기술에 대한 발전 가능성이 엄청나다는 사실을 깨닫고 있다.

 

블록 체인에 대해 이해하기 위해 필요한 개념들을 정리할 필요가 있다.

 

블록 체인을 이해하기 위해서는 분산 시스템을 이해해야한다.

 

분산 시스템

컴퓨터 패러다임 중 하나로, 둘 이상의 노드가 공동으로 결과를 얻기 위해 조율하며 함께 동작하는 방식이다.

 

여기서 노드란, 분산 시스템의 개별 참가자로 정의하며 쉽게 말해서 하나의 컴퓨터, 하나의 참여자를 뜻한다.

여러 참여자가 업무를 같이 나눠서 처리하는 것이다. 여기서 사람들을 쉽게 믿지 못하는 사람들은 자연스레 의문이 들 수 있다.

 

'일을 나눠서 한다고? 그러면 그 중 한 명이 나쁜 놈이면? 모든 일이 엉망이 되거나 결과가 그 나쁜 놈이 원하는 대로 만들어질 수 있지 않을까?'

 

아주 자연스러운 발상이고 이 문제가 오래 전부터 분산 시스템을 개발해오던 사람들이 늘 가지고 있던 고민이다. 이런 악의적인 노드(나쁜 놈)을 비잔틴 노드라고 부른다. 분산 시스템에서는 비잔틴 노드 문제를 해결하기 위해 다양한 알고리즘을 개발해왔다. (이런 알고리즘 종류와 개념들만 쭉 훑어봐도 사람들이 얼마나 진지하게 고민해왔는지 느낄 수 있다.)

 

분산 시스템에서 필요한 조건

그렇다면 좋은 분산 시스템에는 어떤 특징들이 있어야할까?

 

분산 시스템에서는 도달하고자하는 3가지 속성이 있다.

 

1. 정합성 (Consistency)

2. 가용성 (Availability)

3. 분할 허용성 (Partition tolerance)

 

와... 또 딱딱한 이야기한다. 생각하겠지만, 이는 이름일 뿐이다.

하나하나 쉽게 풀어서 알아보면 어찌보면 당연한 이야기들 뿐이다.

 

아주 빠르고 간단하게 풀어보도록 하겠다.

 

1. 정합성 (Consistency)

분산 시스템에 있는 모든 노드들이 같은 데이터를 가지고 있게 하는 것이다. 다 같이 해킹 스터디를 하는데, 혼자 국어책을 가지고 와서 공부하는 학생을 생각해보자. 다른 사람들은 해킹 책을 나눠가며 읽고 토의하는 와중에, 혼자만 딴 소리하게 될거고 스터디는 엉망이 될 것이다.

 

중앙 집중 방식의 시스템에서는 운영하는 서버가 이를 관리한다. 서버가 공통의 정보를 가지고 있고 클라이언트들이 그 정보를 받아서 사용한다. 즉, 최신화되어있는 데이터는 서버가 가지고 있다.

 

그런데, 분산 시스템은 이런 중앙 서버가 없이 서로서로 각자 알아서 최신화된 데이터를 가지고 있어야한다는 것이다.

 

2. 가용성 (Availability)

분산 시스템에서 각각의 노드가 정상적으로 요청을 처리하고 응답할 수 있어야한다는 말이다. 즉, 각각의 노드에서 데이터를 받아 사용할 수 있고 또한 각각의 노드들은 서로의 요청에 응답할 수 있다. 쉽게 말하면 각 노드가 띵가띵가 놀지 않고 열심히 일을 한다는 말이다!

 

3. 분할 허용성 (Partition tolerance)

분산 시스템은 네트워크 장애로 인해 통신이 안되거나 어떤 노드가 장애가 될 때 그 문제되는 부분을 제외하고 나머지 그룹들 끼리라도 계속 올바르게 동작해야한다는 것이다. 이 분할 허용성 또한 굉장히 중요한데, 만약 분산 시스템이 1000개의 노드로 이루어져있다고 생각하면 이 1000개가 모두 잘 동작해야한다는 건데, 하나라도 문제가 생기거나 인터넷이 끊겼을 때 전체 시스템이 동작을 못한다면 많은 사람들이 쓰지 못하게 된다. 분산 시스템에 많은 노드들을 포함시키려면 굉장히 중요한 성질 중 하나다.

 

분산 시스템은 이 3가지 속성을 만족시키기 위해 개발자들이 열심히 머리를 써왔다.

 

그러나 허무한 결과가 나왔는데, 바로 그게 CAP 정리다.

 

CAP 정리 (Consistency - Availability - Partition tolerance)

브루어의 정리(Brewer's theorem)이라고도 하는데, 에릭 브루어(Eric Brewer)가 1998년에 가설로 내세웠고, 그걸 2002년 세스 길버트(Seth Gilbert)와 낸시 린치(Nancy Lynch)에 의해 입증되었다.

 

[CAP Theorem]
어떤 분산 시스템이든 정합성과 가용성, 분할 허용성을 동시에 만족시킬 수 없다.

 

 

띠용..?

분산 시스템에서 만족해야할 성질 3가지를 선정하고 이를 향해 노력해왔건만...

이건 잡지 못하는 무지개와 같...

 

침착하게 살펴보자...

그 내용은 다음과 같다.

 

노드가 2개인 분산 시스템을 가정하고 설명이 시작된다.

 

CAP는 다음의 내용들이다.

- 정합성은 두 노드가 동일한 공유 상태인 경우, 즉 두 노드가 동일하게 데이터의 최신 사본을 갖고 있는 경우에 달성된다.

- 가용성은 두 노드가 모두 가동 중이고 최신 데이터 사본으로 응답하는 경우에 달성된다.

- 분할 허용성은 두 노드 간에 통신이 끊어지지 않고, 서로 통신 가능한 경우에 달성된다.

 

여기서 분할이 발생해서 두 노드가 서로 통신할 수 없는 경우를 생각해본다.

 

 

 

이때 하나의 노드에 새로운 데이터가 전달되면 엄청난 문제가 발생된다. 통신 두절이기 때문에 하나의 노드에만 업데이트 될 수밖에 없다.

 

 

이 경우에 해당 노드가 업데이트를 수용하면, 네트워크에서 이 노드 하나만 업데이트되므로 정합성을 잃게된다.

 

그런데 반대로 노드가 업데이트를 거절하면, 가용성을 잃는 결과를 초래한다.

 

즉 여기서 분할 가능성을 성립하는 순간 둘 중에 하나는 탈락이다.

 

하... 그렇다면 분산 시스템은 여기서 끝이란 말인가...

 

이때 블록 체인이 등장하는데..!

신기하게 이 블록 체인은 CAP를 모두 만족해버린다.

 

?! 아! 그러면 CAP 정리는 거짓이었구나!

 

또 그렇지 않다. 블록 체인은 CAP를 만족하기 위해 정합성을 아주 잠깐 포기한다.

정합성이란 모든 노드가 똑같은 최신 데이터를 가지고 있어야한다는 것이다.

 

그런데, 블록 체인의 경우 정합성이 깨지는 것을 잠깐 눈감아준다.

대신 시간이 지날 수록 모든 노드들이 같은 데이터를 가질 수 밖에 없게 되는 정말 신기한 마법 같은 일을 구현해냈다.

 

그렇게 인간들의 CAP를 향한 노력의 산물이 블록 체인이다.

 

 

 

* 추가할 기능 구현 (게시판)

- 조회수 조작 방지 기능



* 추가할 기능 구현 (인증)

- 소셜 인증


--------------------------------------------------------------------------------------


  조회수 조작 방지에 관해 어떻게 해결해야할까 고민하던 중 오늘 자료실의 좋아요 기능을 만들면서 해결책이 가늠이 잡혔다. 하지만 이번 일지에서는 구현하지 못하였다.


  이번 일지에서는 자료실을 추가하였다. 게시판과 똑같다. 다만 파일 업로드, 다운로드 기능이 새로웠고, 조회수 대산 좋아요 기능을 추가하였다.




  자료실 모델이다.


< model >


  게시판과 똑같다. 다른 점은 FileField 가 추가되었다.


< urls.py >


  게시판과 같고 다른점은 좋아요 기능 구현을 위한 url이 추가되었다.


자료실의 모습이다.


< 자료실 모습 >


  게시판과 같은 모습이지만 맨 오른쪽에 좋아요 수를 보여주고 있다.


자료실 업로드는 큰 어려움이 없었는데 업로드된 파일을 다른 사용자가 다운로드해주는 기능을 추가해야했다.


< 다운로드 기능 >


  DEBUG 모드에서는 단순히 URL 주소를 넘겨주면 직접 접근이 가능하다. 하지만 실제 배포하였을 때는 직접 접근이 안되기 때문에, 다운로드 기능을 추가해주어야한다. file_url 에서 맨 앞 글자를 지운 이유는 이상하게도 업로드된 사진을 웹에 보여주는 것과는 동작이 달랐기 때문인데 문제를 분석하다보니 url 다루는 차이가 있었다.


  file의 경우 앞에 / 문자가 없어야 잘 동작했고 사진의 경우 / 문자가 있어야 잘 동작했다. 그래서 / 문자를 settings.py 에서는 넣어서 설정을 하고 파일 다운로드 기능에서는 위와 같이 [1:] 을 사용해 맨 처음 문자를 빼고 넣어주었다.



< 다운로드 >


  다운로드를 클릭하니 다운로드 되었다.



< 다운로드 된 모습 >



  다음으로 좋아요 기능이다.


< like_tools 추가 >


  먼저 사용자의 프로필에 like_tools를 추가해주었다. 이는 ManyToMany 필드로 연결했다.



< 토글 기능 >


  토글기능은 현재 사용자의 좋아요 리스트에서 해당 포스트 자료가 존재하면 remove 해주고 존재하지 않으면 add로 해당 포스트 자료를 추가해준다.



< html >


  마찬가지로 좋아요 리스트에 있다면 좋아요를 누른것이므로 Unlike를 출력해주고 없으면 아직 누르지 않은 것으로 Like 를 출력하여 토글 버튼이 되도록 하였다.



< 좋아요 클릭 >



< 좋아요 클릭한 모습 >


  좋아요를 클릭하면 Unlike로 바뀐다.



< 좋아요 수 출력 >


  좋아요 수는 해당 자료를 좋아요 누른 사람들의 수를 count 하여 출력해준다.


* 서버 호스팅

- MySQL 연동

- AWS 구축 및 환경 구축

- 호스팅 및 DNS 등록


* 추가할 기능 구현 (게시판)

- 조회수 조작 방지 기능



* 추가할 기능 구현 (인증)

- 소셜 인증


* 추가할 기능 구현 (게시판)

- 댓글 수정기능 -> 댓글 삭제 기능

- 조회수 조작 방지 기능

- 게시글 삭제 기능


* 추가할 기능 구현 (인증)

- 소셜 인증


==========================================


  댓글 수정말고 댓글 삭제 기능을 넣었다. 댓글 같은 경우 수정할 바에 차라리 지우고 다시 쓰도록 의도하였다.


  먼저 작업 들어가기전에 갑자기 아이디어가 떠올라 개선한 점이 있다. 바로 리다이렉트부분이다. 기존 같은 경우 게시글을 수정하거나, 게시글에서 댓글을 작성한 후에 게시글 리스트로 리다이렉트 된다. reverse를 써서 제자리에 오도록 하려했으나 (F5기능) circular import 문제 때문에 구현하지 못했었다.


  그런데 그냥 템플릿에 넘겨주면 되지 않나? 라는 생각이 들어 이 부분을 해결하였다.


< render로 변경 >


  템플릿을 지정해주고 context 안에 post를 담아서 보내주었다.



< 개선된 게시글 >


  이제 이 자리에서 바로 글을 수정해도 이 페이지며, 댓글을 달아도 이 페이지로 남는다.


  그런데 이상한 점을 추가적으로 포착했다. 바로 개행이 안된다는 점이다. 위 사진을 보면 분명 내가 Update 마다 줄을 바꿔줘서 넣었는데 개행처리가 안됬다.


  이 점에 대해 검색을 해보니 HTML에서 개행을 처리 안해서 그렇다고 한다. 개행을 <br> 로 바꿔주면 된다. 여기서 linebreaksbr 을 사용하면 <br>로 바뀐다고 한다.



< linebreaksbr >


  확인해보면 다음과 같다.


< 개행처리 되는 모습 >



  이제 본격적으로 구현하고자 하는 기능 구현이다. 먼저 게시글 삭제 기능이다. 이 기능은 직접 구현하지 않고 CBV를 이용하여 구현하였다. 다만 함부로 삭제되면 안되므로 현재 로그인된 사용자가 게시글을 작성한 사람과 같은지 검증하기 위해 filter를 이용하여 검색된 쿼리만 삭제하도록 구현하였다.


< PostDeleteView >


  테스트해본다.!


< 삭제 테스트 >



< 삭제 확인 팝업 >


  정말 삭제할 것인지 물어본다.


  그 후 정말 삭제할 것인지 다시 한번 물어보는데 이는 DeleteView에 있는 기본 기능에서 템플릿만 만들어서 이어주었다.


< 재재확인 >



< 삭제된 글 >


  글이 정상적으로 삭제 되는 것을 확인하였다.



  다음으로 댓글 삭제이다. 댓글 삭제도 CBV를 이용하고 싶었으나, pk 종류가 두개가 들어오는데 이를 처리하는 부분에서 계속 에러가 나서 직접 view를 작성하였다.



< comment_delete view >


  post와 comment 둘 다 얻는다. 그 이유는 comment는 삭제하기 위한 것이고, post는 다시 원래 있던 페이지로 돌아가기 위해서이다.



< 댓글 삭제 테스트 >


  맨 위의 댓글을 지워보았다.



< 댓글 삭제 확인 >



  댓글이 정상적으로 삭제되었다. 




* 추가할 기능 구현 (게시판)

- 조회수 조작 방지 기능



* 추가할 기능 구현 (인증)

- 소셜 인증


+ Recent posts