Haonly's Blog

Kafka 정의

• Distributed commit log
• 데이터를 지속해서 저장하고 읽을 수 있으며 확장에 따른 성능 저하를 방지하여 데이터가 분산 처리될 수 있다.

메시지 발행과 구독

• publish/subscribe 관계로 데이터 발행자가 발행/구독 시스템에 전송하면 구독자가 특정 부류의 메시지를 구독할 수 있도록 함
• 메시지를 저장하고 중계하는 역할은 브로커가 수행
• 메시지 발행 시스템에서즌 데이터 발행자가 직접 구독자에게 보내지 않는다!

초기의 발행/구독 시스템

• 발행자와 구독자가 직접연결된 시스템에서 발전하여
• 중간 브로커(서버)를 둔 아키텍쳐가 만들어졌다.
• 모든 애플리케이션의 메트릭을 하나의 애플리케이션이 수신하고, 하나의 서버로 제공하여 해당 메트릭이 필요한 어떤 시스템에서도 쉽게 조회 가능

카프카 사용 이유

• 중앙화된 전송 영역이 없어 end to end 연결이 복잡해진다
• 데이터 파이프라인 관리가 어려워지고
• 연결 시스템마다 다른 방식으로 구현 수 있다

메시지와 배치

• 데이터의 기본단위: 메시지
• 바이트 배열의 데이터로 특정 형식이나 의미를 갖지 않음
• 카프카 메시지 데이터는 topic으로 분류된 partition에 수록되는데 이때 데이터를 수록할 파티션을 결정하기 위해 일관된 해시 값으로 키를 생성한다.
• 카프카는 메시지가 생길때마다 보내는 게 아닌 효율성을 위해 모아 전송하는 형태의 배치로 파티션에 전송할 수 있다.
  • 배치의 크기가 증가하면 → 단위 시간당 처리되는 메시지 양이 증가하지만 메시지의 전송 시간도 증가함

스키마

• 메시지의 구조를 나타내는 스키마를 사용
• Json / XML 등을 사용
• 스키마 버전 간의 호환성이 떨어져 아파치 Avro를 많이 사용(Apache에서 만듦)

토픽과 파티션

• 카프카의 메시지는 토픽(topic)으로 분류하며 토픽은 DB의 테이블이나 파일 시스템의 폴더와 유사
• 하나의 토픽은 여러개의 파티션(partition)으로 구성됨
• 메시지는 파티션에 추가되는 형태로만 수록
• 맨 앞부터 끝까지 순서대로 읽힌다
• 메시지의 처리 순서는 토픽이 아닌 파티션 별로 유지 관리
• 각 타피션은 서로 다른 서버에 분산되어 단일 서버로 처리할 때보다 훨씬 성능이 우수하다.

프로듀서와 컨슈머

• 데이터를 쓰는 프로듀서(producer) - 데이터를 읽는 컨슈머(consumer)
• 오프라인으로 대량의 데이터를 처리하도록 설계된 프레임워크인 하둡의 방법과 대비된다.
• 프로듀서: 새로운 메시지를 생성하며 메시지는 특정 토픽으로 생성되고 기본적으로 메시지가 어떤 파티션에 수록되는지는 관여하지 않음
  • 프로듀서가 특정 파티션에 메시지를 직접 쓰는 경우가 있음 - 파티셔너 사용(키의 해시 값을 생성하고 그것을 특정 파티션에 대응시켜 지정된 키를 갖는 메시지가 항상 같은 파티션에 수록되게 함)
• 컨슈머: 메시지를 읽는 주체
  • 하나 이상의 토픽을 구독하여 메시지가 생성된 순서대로 읽는다.
  • 메시지의 오프셋을 유지하여 메시지의 읽는 위치를 알 수 있다.
  • 오프셋은 지속적으로 증가하는 정수값이며 메시지가 생성될 때 카프카가 추가해준다.
  • 파티션에 수록된 각 메시지는 고유한 오프셋을 갖는다.
  • 주키퍼나 카프카에서는 각 파티션에서 마지막에 읽은 메시지의 오프셋을 저장하고 있으므로 컨슈머가 메시지 읽기를 중단했다 다시 시작해도 언제든 다음부터 읽을 수 있다.

• 컨슈머는 컨슈머 그룹의 멤버로 동작
• 한 토픽을 소비하기 위해 같은 그룹의 여러 컨슈머가 함께 동작
• 한 토픽의 각 파티션은 하나의 컨슈머만 소비할 수 있다.
• 한 컨슈머가 자신의 파티션 메시지를 읽는데 실패해도 같은 그룹의 다른 컨슈머가 파티션 소유권을 재조명받고 실패한 컨슈머의 파티션 메시지를 대신 읽을 수 있다.

브로커와 클러스터

• 브로커: 하나의 카프카 서버
• 프로듀서로부터 메시지를 수신하고 오프셋을 저장한 후 해당 메시지를 디스크에 저장
• 클러스터의 일부로 동작하도록 설계되었다
• 컨트롤러의 기능을 수행
• 각 타피션은 클러스터의 한 브로커가 소유하며, 그 브로커를 파티션 리더라고 한다.
• 일정 기간 메시지를 보존하는 기능도 있다
• 각 파티션을 사용하는 모든 컨슈머와 프로듀서는 파티션 리더에 연결해야 한다.
• 다중 클러스터
  • 데이터 타입에 따라 구분 및 처리
  • 요구사항에 따라 분리 처리
  • 다중 데이터 센터 처리
  • 다중 클러스터를 지원하기 위해 미러 메이커를 사용한다.

카프카를 사용하는 이유

• 다중 프로듀서, 컨슈머
  • 다중 프로듀서, 컨슈머가 상호 간섭 없이 어떤 메시지 스트림도 읽을 수 있다.
• 디스크 기반 보존
  • 메시지를 보존할 수 있어 컨슈머를 항상 실시간 실행시키지 않아도 된다.
  • 처리가 느리거나 접속이 폴주해서 메시지 읽는데 실패해도 데이터가 유실될 위험이 적다
• 확장성
  • 브로커 1대부터 시작하여 규모에 따라 브로커를 수백대로 증가시키기고 대규모 클러스터로 묶어 사용할 수 있다.
  • 동시에 여러 브로커에 장애가 생겨도 복제 팩터를 더 큰 값으로 했다면 대응할 수 있다.
    
    

이용 사례

• 활동 추적
• 메시지 전송(메일, 푸시 알림)
• 메트릭 로깅
• 커밋 로그
• 스트림 프로세싱

첫 글 쓰기 전에...

API 개발이야 여러 번 해 봤지만 제대로 설계를 하고 개발한 적은 거의 없다고 본다.

그저 개발하기 급하게 개발한 못난이 API 투성이.. ㅠㅠ 

그러다가 한 반년 전에 개발한 API를 봤는데 너무나도 엉망이라 ㅋㅋㅋㅋㅋ 진짜 너무나도 거지 같아서 새로 설계하고 다시 짜렸는데 반년 전의 나와 지금의 나의 다른 점은.. 크게 없으므로 제대로 공부를 좀 해보고 개발하려고 공부하려고 한다!

책은 그냥 이 전에 개발 잘하시는 책임님이 사시던거 기억해두고 따라 샀던 책이라 어디 구석탱이에 있던 게 생각나 꺼내왔다.

고럼 화이팅 하매~~~

1부. API 디자인의 기초

1장. API 디자인이란 무엇인가

API는 인터페이스로 시스템 간 통신을 위한 인터페이스로 작용한다.

스마트폰의 예시를 들어봤을때,

스마트폰 UI와 비교를 들었는데, 스마트폰 화면을 터치하여 모바일 애플리케이션과 사람 간의 상호작용하는 역할을 하는 UI가 애플리케이션이 다른 애플리케이션과 상호작용을 하기 위해 작용하는 프로그래밍 인터페이스인 API와 비교할 수 있다.

모바일 애플리케이션이 백엔드와 커뮤니케이션하기 위해 인터넷을 사용하는데 HTTP를 사용 -> 그래서 웹 API라는 것

예를 들어 소셜 네트워크에 사진과 글을 올리는 과정을 설명하는데,

소셜 네트워크 백엔드가 사진과 텍스트를 수신하면, 사진은 서버의 파일 시스템에 저장되고, 텍스트는 사진의 식별자와 함께 데이터베이스에 저장된다. 

하진을 저장하기 전에 직접 만들어 둔 얼굴 인식 알고리즘을 이용해 사진 속에 친구가 포함되어 있는지 확인할 수도 있다.

위 과정을 확장하면 애플리케이션 하나가 여러 독립된 애플리케이션을 다루는 상황도 상상해 볼 수 있다고 한다.

API를 통해 사진과 텍스트를 저장하고, sns 백엔드에서는 얼굴인식 API, 저장 API, 타임라인에 추가 API 등을 호출하여 작업이 이루어진다고 이해했다. 이런 과정이 레고와 같다고 한다.

API로 접근이 가능해 어디서든 실행 가능하니 동시에 여러 곳에서 사용 가능하며 이러한 점이 API의 성능과 확장성을 관리하는데 유리하다.  

API 디자인이 중요한 이유

API를 사용하는 consumer 입장에서 사용하기 쉬워야 하기 때문인 것이 내가 생각하는 첫 번째 이유인 듯하다.

외부 API를 사용하는 경우라면 누가 개발한 지 모른 채 사용하게 되는데 이때 사용에 어려움이 없어야 좋은 API라고 할 수 있기 때문이다. 

이러한 API를 사용하는 개발자의 경험을 Developer Experience라고 한다. 사용하기 유용하고 쉽도록 개발하는 것이 API 개발의 키라고 한다.

API는 구현을 숨긴다

API 내부가 어떻게 구현되는지 consumer는 알 필요가 없다.

음식점에서 음식을 주문하는 경우와 비교를 했는데, 우리가 음식점에 가서 음식을 주문할 때 요리가 어떻게 되는지는 알지 못하고 점원을 통해 음식 주문과 서빙을 받는다.

이 점이 API를 통해 상호작용하는 점과 비슷하다. API에게 요청한 결과가 구현되고 수행되는 것은 provider 애플리케이션에서 일어난다.

어설픈 API 디자인은 끔찍한 결과를 초래

형편없이 디자인된 제품들은 잘못 쓰이거나 제대로 쓰이지 않거나 아예 쓰이지 않는다. 사용자들에게만 위험한 것이 아니라 제품을 만든 조직에도 위험하다.

(내가 만든 API가 이런 상황.. ㅠㅠㅠ)

상황이 어찌 됐든 간에 API 디자인 결함은 이 API를 사용하는 소프트웨어가 들이는 시간과 노력과 비용을 증가시킨다,

그러므로 API를 적절하게 디자인하는 법을 학습하면 된다.

모든 API가 이해하기 쉽고 사용하기 쉽게 만들어져야 한다.

라는 것이 결론이며 내가 개발해왔던 API를 생각해보면 그때는 reasonable 하다고 생각했던 것들이 전혀 그렇지 않고 내가 놓치고 개발한 점들도 참 많다. 이제라도 다시 개발해 볼 생각을 한 것만으로도 기특하다고 해야 할까.. ㅎㅎ

도커 알 못이 파이썬 스크립트를 서버에서 돌려야 해서 도커로 이미지 빌드하고 올리는 과정 정리

(한 3개월 전에 도커로 올렸었는데 오늘 다시 하려니 까먹어서 정리해 놓기로 마음먹음)

1. 파이썬 스크립트를 작성한다.

2. 도커파일을 작성한다.

  -> 도커파일에 무슨 내용을 적어야 할 지부터 일단 의문이었던 기억.

3. 도커 빌드.(이미지 만들기)

  -> 그냥 도커 빌드 명령어를 쓰면 됨

4. 도커 푸시

5. 원하는 서버에서 도커 풀 받아서

6. 원하는 포트를 지정해 도커 런!

일단은 위와 같은 단계로 도커 이미지를 만들고 빌드를 시키고 서버에서 작동을 시켰다.

각 과정에서 사용한 명령어 정리 한 후 '와당탕탕' ㅋㅋㅋ을 정리해보려고 한다.

1. 파이썬 스크립트 작성

이건 그냥 원하는 스크립트를 뚝딱뚝딱 작성하면 되는 것이니 패스! 

나는 fastapi로 api를 만들었다.(?)

2. 도커파일을 작성한다

스크립트가 실행되는 위치에 Dockerfile <-- 이 이름으로 된 파일을 작성한다.

나는 파이참 IDE를 사용해서 코드를 짜서 그냥 New File 눌러서 Dockerfile로 이름 적어 파일을 생성했다. .yaml 파일 작성하듯이 내용을 작성하면 된다.

다양한 명령어가 있고 효율 좋게(?) 돌아가게 하는 기능도 있지만 나는 아래와 같이 간단하게 작성했다.

# 베이스 이미지 명시
FROM python:3.7.8

# 컨테이너 실행 전 수행할 쉘 명령어
RUN mkdir -p /opt/myservice
WORKDIR /opt/myservice
COPY . .
RUN pip install -r ./requirements.txt


# 컨테이너가 시작되었을 때 실행할 쉘 명렁어
# 도커파일 내 1회만 실행할 수 있음
EXPOSE 8802
CMD python main.py

3. 도커 빌드

> docker build --tag server:port/myservice:0.1 .

위 명령어로 도커 빌드를 하고 나는 업무용 서버에 이미지를 빌드할 것이기 때문에(?) 일단 저렇게 이미지를 빌드하였다.

저렇게 빌드하고 '> docker images' 명령어를 치면 이미지가 생성된 것을 확인할 수 있다.

4. 도커 푸시

위에서 생성한 도커 이미지를 서버에 푸시하기 위한 과정이다.

> docker push server:port/myservice:0.1

지정된 서버에 해당 이름으로 이미지가 푸쉬되었다.

5. 도커 풀

작동하기 원하는 서버에서 이미지를 올린 서버로부터 이미지를 내려받는 과정이다.

> docker pull server:port/myservice:0.1

위 명령어로 도커 이미지를 pull 받았고 docker ps 해보면 이미지가 받아진 것을 확인할 수 있다.

이제 하나 남음!!!

6. 도커 런

이미지를 받았으니 이제 컨테이너 실행을 시켜주면 된다.

도커 런을 시키면 되는데 이 때 옵션을 다양하게 붙이면 원하는 대로 뭔가 해볼 수 있는 듯 하다 ㅋㅋ

나는 그냥.. 필요한 것만 아래와 같이 사용했다.

 > docker run -d -it -p 8802:8802 --name myservice0.1 server:port/myservice:0.1

참고: https://docs.docker.com/engine/reference/commandline/run/

불러오는 중입니다...

위 링크에서 여러가지 옵션들을 확인할 수 있다.

와당탕탕 1. 도커 빌드가 안된다!

일단 스크립트를 작성해서 도커 빌드를 해보려고 했음

스크립트야 그냥 api 개발한 거고 도커 빌드를 해보려는데 이상한 에러들이 뜸

=> ERROR [internal] load metadata for docker.io/library/python:3.7.8

= failed to fetch oauth token: unexpected status: 401 Unauthorized

요런 에러들...

그래서 찾아봤더니 도커 로그아웃하고 다시 로그인 하면 된단다!!

> docker logout
> docker login

위와 같이 명령어를 하나씩 쳐 주고 도커 빌드를 하니 성공!

물론 login 할 때 username과 password를 알고 있어야 한다. ㅋㅋㅋㅋ 기억 안나서 뇌정지 온 사람(나)

와당탕탕 2. 포트 지정 (feat. Dockerfile)

도커 빌드하고 이미지 push 이후 원하는 서버에서 pull 받아 run을 할 때 포트 지정을 해 주려고 한다.

두번째 도커 개발이라 도커파일 작성조차 익숙하지 않아 이 전에 개발했던 Dockerfile을 복사해서 설정값을 그냥 아무 생각 없이 띵가띵가 바꿨다.

그러고 서버에서 이미지 pull 받아 아래 명령어로 run 시키는데 돌긴 돌아도 테스트가 안되는 것이었다!!

> docker run -d -it -p 8802:8802 --name name0.2 myserver2:5000/name:0.2

 '> doekr ps' 해보면 포트가 자꾸 8800를 가리키게 되어 있었다.

뭘까뭘까 엄청 고민해 보다가 하.. 내가 이 전에 올린 api의 포트를 8800으로 해놨는데 해당 Dockerfile 그대로 복사해서 쉽게쉽게 가려다가 그 8800 포트 적은게 그대로 이미지로 만들어져 버렸던 거구나... 싶었다.

그래서 Dockerfile의  EXPOSE 값을 내가 원하는 포트번호인 8802로 수정하고 위 명령어로 런 시키니 잘 작동하는 것 확인!

사내 스터디 세미나로 준비한 자료 정리

Go 언어를 활용한 마이크로서비스 개발

2장 좋은 API 디자인하기

api 규약 작성이 매우 중요하며 어려움

RESTful API

• REpresentational State Transfer(표현적 상태 전송)
  • 컴포넌트(서비스 단위) 간 상호작용의 확장성, 범용적인 인터페이스, 컴포넌트의 독립적인 배포를 강조하며 응답 지연시간 감소, 보안 강화, 레거시 시스템의 캡슐화를 위한 중간 컴포넌트 역시 강조한다.

URI, URN, URL

• RFC 3986

• 

• URI 형식 지정의 규칙
  • 슬래시(/)는 리소스 사이의 계층적 관계를 나타내는 데 사용
  • URI의 마지막에 슬래시가 포함되어서는 안된다.
  • 하이픈(-) 사용, _ 사용 x
  • 대소문자 구분하므로 소문자 사용 권장

URI 경로

표현설명비고

REST URI 디자인

• DELETE /cats/1234: 좋은 예
• GET /deleteCat/1234: 나쁜 예
• POST /cats/1234/delete: 나쁜 예
• HTTP 동사
  • GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS

응답코드

• 요청의 성공이나 실패를 클라이언트에게 알려주기 위한 HTTP 응답 코드
• 즉각적으로 요청의 상태를 알 수 있게 설계

나쁜 응답

POST /kittens RESPOSNE HTTP 200 OK { "status": 401, "statusMessage": "Bad Request" }

POST /kittens RESPOSNE HTTP 200 OK { "id": "123434jvjv4564", "name": "Fat Freddy's Cat" }

• 좋은 응답은 HTTP 상태 코드를 문자 그대로 사용하는 것

실패 응답의 좋은 예

POST /kittens RESPONSE HTTP 400 BAD REQUEST { "errorMessage": "Name should be between 1 and 256 characters...." }

성공한 응답의 좋은 예:

POST /kittens RESPONSE HTTP 201 CREATED { "id": "123434jvjv4564", "name": "Fat Freddy's Cat" }

• IBM HTTP 요청과 응답 예제

HTTP 상태 코드

• 구글에 더 자세하게 나와있지만 간략하게 정리
• 200 OK: 요청이 성공했음을 나타내는 일반적인 응답 코드
• 201 Created(생성): 요청이 성공하고 새 엔티티가 생성된 경우의 응답
• 204 No Content: 내용 없음. 클라이언트의 요청이 잘 처리되었지만 본문은 없음. DELETE 요청에 대한 응답이 될 수 있음
• 3xx: 경로 재지정.
• 4xx: 클라이언트 에러
  • 400 Bad Request / 401 Unauthorized / 404 Not Found / ...
• 5xx: 서버 오류

mozilla 상태코드 참고 사이트

HTTP 헤더

• 표준에 맞추면 모두에게 도움이 된다!
• 표준 요청 헤더
  • 요청에 대한 메타 데이터 개념
  • 요청 및 API 응답에 대한 추가 정보 제공
• Authorization - 문자열
  • 권한 부여: Authorization key 요청
  • 이런 표준 접근 방식을 따르면 클라이언트가 알아서 구현알 수 있다는데
  • 사실 이걸 어떻게 부여하는지는 잘 모르겠습니다!
• Date
  • 요청의 타임스탬프
• Accept - 콘텐츠 타입
  • application/xml
  • text/xml
  • application/json
• Accept-Encoding - gzip, release
  • REST 엔드 포인트는 가능한 경우 gzip과 deflate 인코딩을 항상 지원해야 한다.
  • gzip 지원은 간단함: 표준 라이브러리의 일부인 compress/gzip 패키지 사용
  • 뉴욕타임즈 오픈소스
  • 비손실 압축을 위한 인코딩,,
• 에러 리턴
  • API 사용자는 에러가 발생했을 때 여러 앤드 포인트에서 발생한 에러를 처리하는 하나의 코드를 작성할 수 있어야 하는데
  • 표준 에러 엔티티를 제공함으로써 클라이언트 또는 서버로 인한 에러가 발생할 때 클라이언트를 도와줄 수 있음
  • 마이크로소프트의 API 가이드라인 자료

API 버전 관리

• 초기부텉 고려해야하는 사항, 피할 수 있으면 피하는 것이 좋다!
• 버전 관리가 필요한 상황
  • 주요 변경 사항이 생기면 API 버전 번호를 증가시키는데 주요 변경사항은
    1. API나 API 매개 변수의 제거 또는 이름 변경
    2. API 매개 변수의 타입 변경(정수 -> 문자열)
    3. 응답 코드, 에러 코드 또는 실패 규약 변경
    4. 기존 API 의 동작 변경
• 시맨틱 버전 관리
  • 메이저 버전과 마이너 버전: 1.0 에서 1은 메이저, .0은 마이너
  • 마이너의 변경은 클라이언트가 API와 상호작용하는 데 영향을 주지 않음
• REST API의 버전 관리 형식
  • https://myserver.com/v1/helloworld :URI의 일부로 버전을 선택
  • https://myserver.com/hellowirld?api-version=1 : 쿼리 문자열의 매개 변수로 선택
  • GET https://myserver.com/helloworld api-version:2 : HTTP 헤더를 사용해 선택

객체 타입 표준화

• 클라이언트에서 객체를 쉽게 처리할 수 있도록 고려
• JSON을 사용하는 경우 기본 타입으로 날짜 개념이 없다! --> ISO 표준을 사용하는 것이 도움이 된다
• 예
  • {"date": "2021-07-08T04:52:57Z"}
  • {"date": {"kind": "U", "value": 1625719977221}

API 문서화

1. Swagger

• YAML로 작성
• 배책임님께서 이전에 소개해주신 API 문서 자동화 도구!

1. API Blueprint

• 마크다우능로 작성돼 중첩된 레이어를 다루는 것보다 좀 더 자연스럽게 문서 작성 가능

1. RAML

• RESTful API Modeling Language의 약자
• YAML로 작성

API 문서 자동화 오픈소스(https://github.com/swaggo/swag)

여러가지 참고 링크

• GO 오픈소스 참고 github
• Go REST API 프레임워크 추천

변수 이름이 'type' 이어야 하는 경우가 생겼다.

Json 파싱 해야하는데 key 이름이 'type'이다. 난감..

스칼라는 대소문자를 구분하니 'type'의 t라도 대문자였으면 문제가 없는데...

알아보니 backticks(`) 를 쓰면 된다!

아래와 같이 사용하면 된다는 것!

var `type` = 10


case class Policy (
		Name:		String,
                `type`: 	String,
                Versions: 	Int )

오늘은 2회차 고랭 강의!

자꾸 미뤄서 듣게 된다.. ㅎㅎ 5분도 안되는 영상들인데 뭔가 다른 일들에 밀려 듣게 됨.. ㅎㅎ

오늘은 Go syntax 재목의 강의를 요약해 보았다.

Go syntax

Case sensitive 함 => 대소문자 구별을 한다는 것

Function, 변수명, 타입이름 등의 Identifier 들은 모두 document에 나와있는 그대로 써야함 

변수와 package 이름들은 소문자거나 대소문자 합쳐져있음

그러나 public fields의 첫 글자는 대문자임

여기서 첫 글자가 대문자라는 것은 그 symbol은 exported 라는 것!

반대로 말하면 첫 글자가 소문자라는 것은 private이고 대문자면 public.

go는 타이핑을 줄임

; <- 와 같은 세미콜론 입력하지 않아도 됨

lexer라는 애가 필요하면 알아서 추가함

그러나 탭이나 띄어쓰기와 같은 whitespace에는 민감하니 조심!

Code bloc은 괄호나 대괄호와 같은 braces 로 묶임

코드에서 언제나 쓸 수있는 package가 있는데 이것을 builtin package라고 부름

자바에서는 import 해야했던 것을 그냥 쓸 수 있다는 말!

예를 들어 len(string), panic(error),  recover() 과 같은 것들

더 참고할 만한 builtin package 설명은 공식문서를 참고!

https://golang.org/pkg/builtin

자바나 다른 언어와 달리 builtin 을 import 없이 쓸 수 있다는 점을 알아차리지 못하고 있었는데 알아차리니 신기하군.. 

깊게 들어가면 어려우니 일단 쓸 수 있게만 써봐야지 ㅎㅎ