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

끝.

어렵다 어려워

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

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

2022.04.19 - [코딩해/개발개발 이것저것] - [API] 일상 속 사물이 알려주는 웹 API 디자인 #3

위 글에서 이어집니다!

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

- REST API가 HTTP 프로토콜을 이용해서 목표를 표현한다.

읽다가 '흠 내가 언제 HTTP 를 제대로 이해한 적이 있나?' 하는 생각이 들었다. 그래서 HTTP부터 공부해보려고 잠시 스터디 중단하고 HTTP부터 공부해보기로 작정!

그래도 해당 장은 마무리하고 싶어서 내용을 요약하자면,

API 목표: 리소스 -> 다른 리소스 인 상황에서 REST API 로 전환하여 HTTP를 이용한 리퀘스트 액션을 구성한다.

어떤 관계로 리소스끼리 구조화되었는지 파악하고, 무엇을 리턴할 것인지 식별하는 과정이 필요하다.

API 목표 캔버스로 리소스와 리소스 사이 관계 식별

요약: 조금 더 세분화하여 누가/무엇을/어떻게/입력/출력/목표를 작성한다. 특히 목표는 동사로 적용되어 리소스에 연결한다.

API 목표 캔버스를 이용해 액션과 액션의 파라미터 그리고 반환값 식별

경로를 포함한 리소스 표현

경로 파라미터를 통해 리소스에 대한 접근과 구별을 할 수 있다.

이때 경로는 사용자 친화적이기만 하면 다양한 옵션이 있다.

HTTP로 액션 표현

GET 이냐 POST냐 DELETE 이냐 뭐냐의 쿼리 파라미터(리퀘스트)

REST API와 HTTP 치트시트

전체 그림에 대한 설명인데 그림을 인터넷에서 못 찾겠다 ㅠ

요약하자면,

입력(파라미터)와 출력(반환값), 목표(리소스를 사용하는 동사(액션))에 해당하는 목표 캔버스를 작성하고 

리소스 사이의 관계를 식별한 후 액션에 해당하는 파라미터, 반환값, 리소스 간의 관계를 식별한다.

그 이후 리소스 경로를 디자인하고 액션에 맞는 HTTP 메소드를 선택한다.

API 데이터 디자인하기

이제 큰 그림을 그렸으니 디자인을 해야 한다.

어떤 속성들을 포함하여 데이터를 표현할지 등의 컨셉을 디자인해야 한다.

응답에 대한 디자인, 응답의 파라미터에 대한 고려 등.

요청에 대한 파라미터들은 가능한 모두 컨슈머가 제공하는 데이터여야 한다.

디자인적 낙관에 봉착했을 때 균형 유지하는 법

-  REST 절충안(액션, 표현 변경) 찾기

- 사용자 편의성과 규칙 준수 균형잡기

API를 디자인할 때 REST가 중요한 이유

- REST API는 목표를 경로와 HTTP 메서드에 매핑할 수 있도록 고려되어야 한다.

- 결국 HTTP와 REST 덕에 모든 웹 서버에 요청을 할 수 있는 것.

간략하게 요약했지만 충분히 이해되었다.

이제 HTTP 공부 빠르게 1년 정도 하고 다시 돌아와야지! 그전에도 공부할 수 있으면 틈틈이 할 것이다.

일상 속 사물이 알려주는 웹 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 목표 목록은 포괄적이고 컨슈머 지향적이어야 하며 프로바이더 관점이 드어가서는 안된다.

카프카 아키텍처 생각해 보다가 갑자기 궁금한 점이 생겼다.

카프카는 같은 파티션 안에서 순서를 보장해주며 여러 파티션을 분산 처리할 수 있는 장점을 가지고 있기 때문에 사용한다.

근데 "같은 파티션 안에서 순서를 보장해준다면 같은 토픽의 다른 파티션 간의 순서는?" 이라는 의문이 들었다.

마침 우아한형제들에서 진행하는 우아한테크세미나에서 이 의문에 대해 의외로 간단한 답변으로 답을 듣게 되었다.

다른 파티션 간의 순서는 보장 안한다.

물론 아주 복잡하게 순서가 뒤바뀌어 들어와 처리 순서가 많이 뒤바뀌진 않기도 하겠지만, 다른 파티션 간의 순서까지 보장하려면 FIFO 쓰지 왜 카프카 쓰겠느냐는 것이다. 

음식 주문의 예시로 생각해보면 1분에 1000개 주문이 들어온다고 할 때, 그 안에서의 순서는 크게 서비스에 영향을 미치지 않는다는 것 같다.

파티션이 4개라면 그 안에서 250개의 주문들은 각 파티션 안에서 순서가 지켜질 것이다.

카프카를 나름 잘 안다고 생각하고 있는데, 공부하면 할수록 공부할 것들이 많다...!

카프카 스트림즈라는 카프카 내의 새로운 개념까지 최근에 알아버려 공부할 게 또 생겼다.

재미있기는 한데 나는 왜이리 모르는 게 많은 건지ㅠㅠ ㅋㅋㅋ 시간을 쪼개어 공부를 열심히 해야겠다!