프로그램을 작성시 테스트를 통해 수많은 에러를 겪으며 프로그램을 작성한다.  

단위 테스트, 통합 테스트 등 수많은 테스트를 겪었으니 해당 프로그램은  에러가 없을까?

세상에 완벽한 프로그램이 없듯이 자의든 타의든 프로그램엔 에러가 있을 수 밖에 없다. 

에러 발견을 메신져 알림을 통해 바로 확인하게 할수도 있고, 디비에 해당 내역을 기록할수 도 있다. 

수많은 프로그램이 난무 하는 가운데 그중 하나인 sentry.io를 소개 한다. 


사용법이 간단하고(아마도??) 통합적으로 관리할수 있는 뷰가 있어서 sentry.io를 선택했다. 


먼저 회원가입을 하면 사용하는 언어/프레임워크를 선택한다. 

저의 경우 python을 선택했다.

sentry-sdk 라는 패키지 설치 및 해당 프로젝트에 해당 api key를 선언해 준다.

sentry.io로 에러 부분을 보내는 방법은 exception 부분으로 감싸져 있는 부분만 보내진다. (설치한 패키지가 exception이 발생하면 에러를 전송한다.)


파이썬엔 데코레이션이라는 아주 좋은 기능이 있으므로 logging을 데코레이션으로 한후 해당 데코레이션 함수에 try로 감싸서 해결했다.

import logging

import functools

logger = logging.getLogger()


def log_error(logger):
def decorated(f):
@functools.wraps(f)
def wrapped(*args, **kwargs):
try:
return f(*args, **kwargs)
except Exception as e:
if logger:
logger.exception(e)
raise
return wrapped
return decorated

위와 같이 데코레이션을 선언후 함수 상단에 데코레이션을 선언해주면 된다.

@log_error(logger)
def solution(n):
pass .....


일부러 에러를 발생시켜 보면 (ret_arr의 max값은 100이다. 해당 배열은 참조없으므로 에러가 발생한다.) 실행시켜 보면


@log_error(logger)
def solution(n):
ret_arr = [x for x in range(1, n+1)]
ret_arr[999999999]

위와 같이 에러가 전송된것을 확인할수 있다. 


강제 메시지 전송 및 캡쳐는 다음의 링크를 참조 하자. 

https://docs.sentry.io/error-reporting/capturing/?platform=python


sentry.io는 개인 보다는 회사나 프로젝트 단위로 관리되어야 하며, 여러 사람이 과거에 어떤 에러가 발생했었고, 어떻게 해결 했는지를 관리 할수 있는 툴이다. ( 에러에 대한 기록 내역 서비스) 개발자 회의에서 에러에 대해 확인하고, 향후 개발해야 하는 방향을 정할수도 있으며,  효과적인 에러 관리를 통해 프로젝트의 관리 및 서비스 품질을 높힐 수 있을 것이다.



WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

1. 요구사항의 명확화 - 정확히 무엇을 할것인지를 정의할것

2. 파라미터 정의 - int / array / date / timestamp 인지 파라미터를 명확히 한다. 

3. 기능의 순서 설계 - 요구사항을 진행하기 위해서 어떤 순서로 코드를 작성할 것인가? 
    UML / 다이어그램  / 순서도 등을 통해 순처리/예외처리를 확인 을 통해 간결해 진다.

4. 코드 작성 및 리팩토링 (코드를 짜면서 기능을 추가 할수도 있으며, 기능 단위로 다시 묶음으로써 리팩토링이 가능해 진다. )

5. 추가 사항이 있는가 확인. 있다면 다시 1번으로 

- 버그나 에러는 1, 2번에서 빠진게 있는것. 만일 이게 아니라면 기능상의 오류
   (기능정의부터 잘못됨)
- 코드부터 작성하지 말자. 기능과 파라미터를 명확히 하면 더 시간을 아낄수 있다
- 내가 하는 일을 말로 설명할수 있어야 한다. 만일 이것을 못한다면 코딩을 하는게 아니라 버그를 만드는것이다.  


'server > 아키텍쳐' 카테고리의 다른 글

코딩을 하기전 해야할 일들  (0) 2018.12.28
web developer roadmap  (0) 2018.12.20
DSR ( direct server return )  (0) 2018.12.11
서버 구조 생각하기  (0) 2018.11.29

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

 No such file or directory: 'geckodriver': 'geckodriver'

selenium.common.exceptions.WebDriverException: Message: 'geckodriver' executable needs to be in PATH.

혹시 selnium 패키지를 이용하여 테스트를 할시 위와 같은 에러가 발생한다면 selenimu에서 사용하는 gecko 브라우져의 드라이버를 추가해줘야 한다. 


https://github.com/mozilla/geckodriver/releases


자신의 OS에 맞는 드라이버를 다운로드 한후 


MAC의 경우 /usr/local/bin/ 폴더에 복사 해주면 정상 작동한다.


WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

출처 :  https://github.com/kamranahmedse/developer-roadmap



눈에 띄는 것은 

1. 테스트 작성 및 TDD가 최상단에 있다는것. (6번)

2. Docker / GraphQL을 배워야 한다는것 (19 / 21 번)




자신이  스타트업같이 개발자가 10명 이내의 회사라면 프론트엔드 + 백엔드 + 데브옵스 까지 기본적인 것은 다 해야 한다. (위의 것은 한번쯤은 건들어봐야 한다... 그게 스타트업이다....아무것도 없으니 만들어야됨.. 누가? 네가!)

규모가 있는 회사라면 백엔드와 데브옵스 팀이 구분되어 있다. (데브옵스가 인프라팀으로 세분화 된다)

게임에서만 케릭터 스킬 뭐 찍을까 몇일씩 고민하지 말고 자신의 테크트리도 잘 보고 찍자.

- 단 천재는 알아서 다 잘한다. 저걸 전부 스킬로 찍어서 하는 사람을 난 봤어......

'server > 아키텍쳐' 카테고리의 다른 글

코딩을 하기전 해야할 일들  (0) 2018.12.28
web developer roadmap  (0) 2018.12.20
DSR ( direct server return )  (0) 2018.12.11
서버 구조 생각하기  (0) 2018.11.29

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

5.5.0 이상 버전에서 아래와 같은 에러 발생 시


{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}


curl의 헤더에 content-type을 추가해 줘야 한다. 

-H 'Content-Type: application/json'

ex)


$ curl -XPOST "http://localhost:32769/board/guest"

-H ‘Content-Type: application/json’

-d

'{

  "name": "test",

  "title": "title",

  "content": "content content"

}'


WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

http/2 는 무려 2015년동에 이미 공식 프로토콜로 승인되어 많은 웹서버에서 지원하고 있다. 

( 설정하는것은 나중에 따로 포스팅으로..)

기존 http보다 무려 2배 이상 빠르다. 만일 전송해야 될 파일이 많으면 많을수록(크기는 중요치 않다, 양이 중요하다) 이론상으론 더 빨라진다. 기존 브라우저에서 6개만의 소켓으로 통신하는 프론트엔드 파일을 한꺼번에 던져 줄 뿐더러, 압축률까지 좋다. 

http1에서의 클라이언트 <-> 서버는 6개의 차가 도로를 모두 차지 하므로 나머지 차량은 대기 해야 한다. 

(저 소켓 6개의 한계 때문에 리소스 서버는 도메인을 바꾼다 던지, gzip 압축을 추가 / 스프라이프이미지 /  minify로 용량 줄이기 등 수많은 짓을 하지 않았는가!!) 

http2에서는 한차량으로 여러 차량이 자나갈수 있다.

이미지 : https://www.distilled.net/resources/an-introduction-to-http2-for-seos/


사실 http2가 적용되기 까진 서버보단 클라이언트에서의 개발이 중요했고, 2015년4월 공식프로토콜로 승인되면서 거의 모든 브라우져에서 지원하게 된다. 

그래서!! 이제 서버에서 http2를 설정 안하면 바보가 되는것이다.(아니 공짜로 속도가 빨라지는걸 왜안해?!)


서론이 길었다. 그러면 각 포탈들은 과연 http2를 지원하는가? ( 크롬 브라우저에서 확인, 네트워크창의 프로토콜에 h2로 뜬다면 서버에서 http2를 지원하는 것이다. )


1. 네이버 : 역시 네이버. 이미 지원하는중


2. 다음 : 앗..앗...아직도 http/1.1 이다


3. 구글 :  http/2 프로토콜 (SPDY)를 만든애들이라... 역시나...


4. 네이트 :  앗...앗...


5. 줌 : 앗...앗...


6. 쿠팡 : 오호! 역시 최적화를 잘해놨다


7. 11번가 : 앗...앗.. (의외네.. 프론트엔드 최적화는 되게 잘해놓던데...)


8. 리디북스 : ?? 신기하게도 index.html만 http/1.1 이며 나머지 모든 리소스는 http/2로 전송한다. 


9. 배달의 민족 : 실망이군..... ( 뭐 서비스자체가 앱이다 보니 그럴수 있다)


10. 왓차 : 오~


11. 여기어때 : 의외군?! 


외국애들을 볼까?

12. 트위터 : 역시 짹짹군


13. 페이스북: 역시


14. 인스타그램: 굳



15. 깃허브 : 어? 안하네?




결론 :  트렌드에 민감하거나, 혹은 신생회사일수록 더 빨리 잘 적용하는듯 하다. 

근데 국내 포탈, 특히 카카오쪽은 다른 서비스들을 봐도 전혀 지원을 하지 않는다...흠...


WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

SSL / TLS

server/http 2018.12.14 02:48

SSL(Secure Sockets Layer) / TLS(Transport Layer Security) 는 통신상의 패킷에 암호화를 통한  보안을 제공.


1. SSL

보안 소켓 계층의 약자로, 1990년대 넷스케이프가 처음 개발한 것으로 데이터를 안전하게 전송하기 위한 인터넷 통신 규약 프로토콜.  1.0 (비공개) -> 2.0 (결함으로 빠른 칼퇴) -> 3.0을 1996년 표준으로 지정.


2. TLS

전송 계층 보안의 약자로 1999년 SSL 프로토콜의 다음 버전으로  출시. IETF( Internet Engineering Task Force)에서 표준화. SSL 3.0과 큰 차이가 없다. 

TLS프로토콜은 모든 종류의 인터넷 통신을 암호화 한다. URL의 https  / 이메일 / 유즈넷 등에서 사용된다. 


3. 작동 (핸드쉐이크)

지원 가능한 알고리즘 서로 교환

- 클라이언트가 서버에 보안 연결을 요청. 서버는 사용가능한 암호 모음을 클라이언트에 알려준다. 
   클라이언트는 자신의 암호 목록과 비교 하여 하나를 선택, 서버에 어떤 암호를 선택 했는지 알려준다. 

키 교환, 인증

- 서버는 클라이언트에게 자신의 신원을 확인 해줄 서드파티 기관이 발급한 인증서를 제공. 인증서엔 퍼블릭 암호화 키를 내장, 클라이언트는 서버의 인증서를 받아 그 진위를 서드파티 기관에 확인.

   

대칭키 암호로 암호화하고 메시지 인증

- 클라이언트와 서버는 퍼블릭 키를 사용해 세션키를 설정.  해당 키값의 교환 및 확인으로 인증 확인. 세션키의 설정은 아래 동영상 참조 



'server > http' 카테고리의 다른 글

SSL / TLS  (0) 2018.12.14
http 통신  (0) 2018.12.07
http 동작 방식  (0) 2018.12.06

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

http://novatechservices.com/use-dsr-to-take-a-load-off-your-load-balancer/


보통의 서버 앞 단에 있는 로드밸런스(L4)에서 사용할수 있는 기능으로 기본적인 통신에서의 클라이언트와 서버의 응답은 

client -> load balancer -> server -> load balancer ->client 

의 형식으로 로드밸런서가 응답에 대해서도 작동을 하게 된다. ( Inline(proxy) mode 라 한다. )

만일 요청이 많아지면 로드밸런서의 처리 때문에 서버가 놀게 되는 현상이 일어날수 있다.

이를 막기 위해 응답은 로드밸런서를 거치지 않고 서버가 바로 클라이언트에 응답을 준다. (상단의 그림 참조 )

client -> load balancer -> server -> client



+ 대용량 파일 업로드의 경우 클라이언트의 요청이 load balancer를 타는것부터 부담이 될수 있다. 

대용량 파일 업로드의 경우 로드밸런스를 거치지 않고 다이렉트로 서버에 올리도록 수정하는게 좋다. 



참고 


http://travelc.tistory.com/82


http://blog.daum.net/_blog/BlogTypeView.do?blogid=05q6N&articleno=12760768&categoryId=159208&regdt=20100909172114


http://tech.kakao.com/2014/05/28/l3dsr/

'server > 아키텍쳐' 카테고리의 다른 글

코딩을 하기전 해야할 일들  (0) 2018.12.28
web developer roadmap  (0) 2018.12.20
DSR ( direct server return )  (0) 2018.12.11
서버 구조 생각하기  (0) 2018.11.29

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

http 통신

server/http 2018.12.07 16:35

1. content-type

클라이언트와 서버의 통신시  리소스를 보낼때 해당 리소스가 어떤 컨텐츠 유형인지 알려준다.

content-type 설정을 위해 MIME타입 목록 파일을 사용한다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types


2. multipart/form-data post 제출 

브라우저에서 서버로 HTML form 내용을 전송시 사용.

데이터간의 경계를 '--' 로 구분하며, 가가 파트의 content-type은 다를수 있다.

또한 너무 큰 데이터일 경우 --를 경계로 재전송을 시도할수 있다. (3번 참조)


3. 엔터티 재요청



4. 리다이렉트


5. 캐시

expires : 해당 날짜까지만 캐시 유효

cache-control : 데이터를 받은 시점으로 부터 카운트 시작


6. https

https를 사용할때 모든 http요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. https는 http의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작, ssl(secure socket layer) 로 구현


7. ssl 핸드쉐이크

암호화된 대이터를 보내기전 클라와 서버는 핸드세이크를 실행.
. 프로토콜 버전 교환
. 양쪽이 알고있는 암호 선택
. 양쪽의 신원인증
. 채널 암호를 위한 임시 세션키 생성


참고 목록:

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types

https://developer.mozilla.org/ko/docs/Web/HTTP/Caching


'server > http' 카테고리의 다른 글

SSL / TLS  (0) 2018.12.14
http 통신  (0) 2018.12.07
http 동작 방식  (0) 2018.12.06

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret

http 동작 방식

server/http 2018.12.06 17:16

1. http ?

- 클라이언트와 서버 사이에 이루어지는 요청(request)/응답(response) 프로토콜.

  클라이언트가 HTTP를 통해 서버로부터 웹페이지나 그림을 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 클라이언트에 전달


2. METHOD

  •  GET            지정한 리소스 요청
  •  PUT            리소스 업데이트
  •  DELETE      지정한 리소스를 서버에서 삭제
  •  POST          지정된 서버의 업무를 실행
  •  PATCH       지정된 리소스 업데이트
  •  HEAD         지정한 리소스에 대한 응답에서 HTTP 헤더만을 요청
  •  OPTION      해당 URL의 사용할수 있는HTTP 메소드리스트 반환
  •  CONNECT  서버 연결 확인 


3. 웹브라우저 연결의 기본적인 절차  

1) 웹브라우저는 서버의 URL에서 호스트 명을 추출한다.
2) 추출한 호스트명을 IP로 변환한다. (DNS서버 이용)
3) 웹브라우저는 URL에서 지정한 포트번호가 있다면 추출한다.
4) 웹브라우저는 웹서버와 TCP 커넥션을 맺는다.
5) 웹브라우저는 서버에 HTTP 요청을 보낸다.(http 메소드들 포함) 
6) 서버는 웹브라우저에 HTTP 응답을 돌려준다.
7) 커넥션이 닫히면 웹브라우저는 문서를 보여준다. 


4. 요청에 의해 서버가 하는 일 

1) 커넥션을 맺는다

2) 요청을 받는다 

3) 요청을 처리한다. (http의 메소드에 따름)

4) 리소스에 접근한다. (DB / 이미지 / 파일 등)

5) 응답을 만든다. (헤더 및 바디)

6) 응답을 보낸다

7) 트랜잭션 로그를 남긴다.





참고자료 

https://ko.wikipedia.org/wiki/HTTP

도서 : HTTP 완벽 가이드

'server > http' 카테고리의 다른 글

SSL / TLS  (0) 2018.12.14
http 통신  (0) 2018.12.07
http 동작 방식  (0) 2018.12.06

WRITTEN BY
No.190
세계정복의 시작점

트랙백  0 , 댓글  0개가 달렸습니다.
secret