Haonly's Blog

Python Fast API 활용하여 간단한 알람 기능을 수행하는 API를 개발중인데,
점점 알람을 보내는 endpoint 가 증가하며 API에 기능이 추가됨에 따라 상태 코드를 세분화할 필요성을 느꼈다.

200 번대 response가 OK인 것은 알겠는데,,

{a요청, b요청} --> 처리 --> {a: 실패, b: 성공} 

위와 같이 두가지 요청 중 한가지만 성공 했을 때 HTTP response 상태코드는

200이어야할지 400, 500 대의 에러코드여야할지 고민이 들었다.

Multi-Status Response: 207
200대 OK 에도 multi-status response 번호인 207 response를 사용하면 partial 한 failure에 대해 응답을 줄 수 있다.
참고: https://datatracker.ietf.org/doc/html/rfc4918#section-13

HTTP response 더 공부해야겠다..

에러

org.apache.spark.SparkException: Job aborted due to stage failure: Total size of serialized
results of XXXX tasks (X.0 MB) is bigger than spark.driver.maxResultSize (X.0 MB)

원인

나와있는데로 rdd로 분산되어 있던 데이터가 spark job 을 통해 driver로 합쳐지면서 driver 최대 메모리 크기를 초과해서 발생한 에러이다.

해결

메모리 최대 크기 늘려주면 된다.

resource 설정을 하면 되는데 SparkConf를 통해서 하거나 conf 파일을 수정하거나 spark-shell 실행 시 매개변수를 통해 설정을 할 수 있다.

나는 spark-shell 실행 시 매개변수를 주었다.

spark-shell --conf spark.driver.maxResultSize=6G

끝.

어렵다 어려워

몇 개월 만이지만 다시 돌아온 주간회고.

1. 기록

오늘 아침 출근길에 이런 생각을 했다.

"열심히 사는 건 뭘까. 왜 나는 자꾸 더 열심히 살아야 한다고 생각하는 걸까

지금의 나는 열심히 사는 게 아닌 걸까?"

사실 열심히는 살고 있는 것 같다. 아래 열심히 하고 있는 것들을 정리하면

1. 사내 스터디 2개, 개인 스터디 1개, 사이드 프로젝트 1개

  - 마이크로 서비스 스터디, 클라우드 기술 솔루션 스터디

  - HTTP 스터디

  - 카프카-앱-서비스 사이드 프로젝트

2. 운동

  - 최소 주 3회는 하고 있다.

3. 영어모임

  - 내년이면 햇수로 10년째!

이렇게나 열심히 살고 있는데, 블로그에 정리를 안 했더니 열심히 살고 있지 않다고 느낀 건 아닐까 생각했다.

열심히 사는 만큼 기록을 해야 할 것 같은데 자꾸 안 하니까 뭔가 놓친 느낌이 들었던 것 같다.

충분히 열심히 살고 있으니 주간회고든, 공부한 내용들이든 다시 기록을 잘해보자.

2. 제천 여행

대전 이후로 처음으로 해 본 왕복 6시간 운전이었다.

연휴 동안 무엇을 할까 하다가 제천 여행을 다녀왔다.

의림지도 한 바퀴 걷고, 곤드레밥 먹고

다음날은 청풍호에 케이블카 타고 올라갔다.

힐링 목적으로 간 여행이라 힐링 코스이긴 했지만 운전이 너무 힘들었고 전날 과로와.. 끝나지 않은 일 때문에 신경도 쓰이고 많이 피곤해서 제대로 즐기지 못했던 것 같다 ㅠㅠ

다음에는 컨디션 생각해서 조금 가까운 곳에 힐링하는 느낌으로 연휴를 보내야겠다.

아 그래도 마지막 덩실분식에서 사 온 찹쌀떡과 도넛이 정말 정말 맛있었다!

찹쌀떡 사진이라도 찍을걸 입에 다 넣어버렸다(ㅋㅋㅋㅋ)

돌아오는 고속도로에서는 앞에 달리던 차가 그 앞 차를 박아버리는 사고가 있었다...!

물론 나는 급정거해서 잘 멈췄지만 그래도 너무 무서워서 손이 떨렸다...

다시 한번 운전의 무서움과 안전 운전해야겠다는 걸 느꼈다.

3. 클라이밍

주 3회 이상 클라이밍을 하고 있다.

요즘에는 실내 볼더링보다는 실외 인공 암벽에 더 진심이다. 

파트너가 있어야 해서 시간이 맞을 때 일주일에 한두 번 정도 간다. 

파트너를 믿는 그 느낌과 더 높이 올라가는 그 떨림, 못 깨던걸 깨는 성취감이 실내 볼더링보다 더 중독적이다.

다치지 말고 오래오래 클라이밍 하고 싶다!

4. 일

하루의 가장 많은 시간을 쏟아붓고 있으며, 나름 진심인 내 일에 관해서도 할 말이 많다.

여전히 열심히 일을 하고 있고, 가끔씩 마주치는 어려운 일들과 하고 싶은데 못하는 일들이 있지만 나름 맡은 업무들을 잘잘 쳐내고 있다.

작년과 비교했을 때 업무 지식도 많이 늘었다.

카프카 스터디가 업무 이해에도 도움이 많이 되어서 다른 공부들도 계속해야겠다고 느낀다.

물론 노는 게 더 재미있지만 하루 중 가장 많은 시간을 쏟는 이 일에 열정을 더 가져보자는 그런 마음가짐이다.

오랜만의 주간회고이지만 앞으로의 열심(기록)인 삶과 조금 더 부지런해질 수 있는 동기가 되었으면 한다!

화이팅 기매연~~!

일상 속 사물이 알려주는 웹 API 디자인이라는 책을 읽으며 정리한 내용입니다. 

프로그래밍 인터페이스 디자인하기

내용

• API 목표를 프로그래밍 인터페이스로 변형하기
• REST 리소스와 액션을 식별하고 매핑하기
• 컨셉으로 API 데이터 디자인하기
• REST API와 REST 아키텍처 스타일의 차이점
• API 디자인에서 REST 아키텍처 스타일이 중요한 이유

REST: Representational State Transfer

GET, /products/{productId}, 200 OK 라는 용어들의 의미를 이해해야 프로그래밍 인터페이스를 디자인할 수 있다.

REST API는 REST 아키펙처 스타일에서 기반하고 있다.

REST API 소개

REST API 호출 분석

p123이라는 상품 카탈로그 정보를 REST 쇼핑 API를 통해 가져오고자 한다면 HTTP 프로토콜을 이용하여 커뮤니케이션해야 한다.

이 목표가 GET /products/{productId} 로 표현되므로 컨슈머가 위와 같이 리퀘스트를 보내야 하며 서버가 HTTP response로 응답(200 OK)을 반환한다.

경로: 서버상의 리소스를 식별할 수 있는 주소

HTTP 상태코드: request에 대한 응답

response 바디: 응답에 대한 콘텐츠

응답은 JSON 형태이나 단순히 JSON 데이터를 가져오려는 목적으로만 만들어진 것이 아님

HTTP의 기초사항

HTTP는 World Wide Web의 기초.

다양한 상황에서 HTTP 프로토콜을 사용한다. - GET/POST/DELETE 등

HTTP 요청에는 목적이 무엇이든 HTTP 메서드와 리소스 경로가 포함된다.

• HTTP 메서드: GET / POST / DELETE / 등
• 리소스 경로: 어떤 리소스에 접근하는지

REST API의 기초원리

상품 정보를 가져오는 목표를 실행하는 REST 쇼핑 API의 예에서, 

컨슈머는 HTTP 리퀘스트를 API 호스팅 서버에 보내야 한다.

이 리퀘스트는 GET HTTP 메서드를 사용해, /products/{productId} 경로로 식별되는 상품을 찾는다.

서버는 상품 데이터와 이를 나타내는 HTTP 상태 코드가 포함된 response를 함께 리턴한다.

결국! REST API는 HTTP 호출 그 이상의 행위를 하지 않는다. 

API 목표를 REST API로 변형하는 과정

(to be continued..)

사용자를 위한 웹 API 디자인하기

주제

• 어떤 관점으로 API를 디자인해야 하는가?
• 사용자 인터페이스를 디자인하듯 API 디자인하는 법
• API의 실제 목표를 정확하게 결정하는 법

API를 사용하는 사람들이 원하는 것이 무엇인지의 관점.

소셜 네트워크의 API는 사진 공유, 친구 추가, 친구 리스트 표시 등이 API의 목표이며 이러한 목표들이 효과적인 API를 디자인하는데 필요한 기능적 청사진 역할을 함

그렇기 때문에 목표 식별이 중요하며 서로 연관된 포괄적인 요구사항들을 정리할 수 있도록 컨슈머의 관점에 중점을 두어야 한다.

사용자가 얻을 결과에만 집중하는 것이 중요하다. 즉, 컨슈머 관점에서 사용하기 쉽도록 개발해야 한다.

API의 목표 식별 과정

API를 디자인할 때 고려해야 하는 점

• 누가 API를 사용하는가?
• 무엇을 할 수 있는가?
• 어떻게 하는가?
• 하기 위해서 무엇이 필요한가?
• 끝나면 무엇을 반환하는가?

-> 사용자들의 요구사항을 수집하고, 그 요구사항을 깊이 파고 들어가 정확히 이해하며, 마침내 그 목표를 조금이라도 효율적이며 정확하게 달성해야 한다.

이때 누락된 목표나 사용자는 없는지 잘 확인해야 한다.

API 목표 캔버스를 사용하여 "누가", "무엇을", "어떻게", "입력", "출력" 목표"를 설정.

누가 사용자인지와 흐름들로부터 새로운 목표를 찾아내는 과정들이 중요하다.

API 디자인에서 피해야 할 프로바이더 관점

API는 근본적으로는 컨슈머와 프로바이더라는 두 개의 다른 소프트웨어 간의 데이터를 교환하는 방법을 의미한다.

프로바이더 관점에서 데이터의 체계와 이름을 그대로 API 목표와 데이터에 매핑하는 실수를 하기도 하는데, 이는 이해하기도 어렵고 사용하기도 어렵게 만든다.

데이터 모델과 조작에 관한 내용은 노출되면 안 된다.

내부 비즈니스 로직의 노출은 API의 컨슈머가 이해하기도 어렵게 하며 프로바이더에게도 위험하다.

숨겨야 하는 인적 조직을 API 디자인에 매핑시키지 않아야 한다.

요약

API 목표 목록은 포괄적이고 컨슈머 지향적이어야 하며 프로바이더 관점이 드어가서는 안된다.

Kafka 정의

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

메시지 발행과 구독

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

초기의 발행/구독 시스템

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

카프카 사용 이유

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

메시지와 배치

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

스키마

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

토픽과 파티션

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

프로듀서와 컨슈머

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

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

브로커와 클러스터

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

카프카를 사용하는 이유

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

이용 사례

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