Category Archives: API

MSA서비스에서의 API

개요

MSA는 API를 이용해 통신을 한다.
그런데…. 의존성이 생기니까 관리가 힘들다.
버전관리가 필요.

버전관리 방법

동시배포

의존성이 있는 모든것을 동시배포
그냥 전체배포라고 보면 된다.
* 서비스가 작을 때 가능
* 오류가 나면 매우 난감함
* DB스키마가 변경됐을 가능성이 크기 때문에 rollback도 쉽지가 않다.

소스코드 내에서 버전을 관리

컨트롤러, 라우터 등등에서
/v1/
/v2/
이런방법으로 버전을 표시
* 버전업이 자주 발생하면?
* 헷갈리겠지

배포시 태깅

jenkins, git-tag, docker, kubernetes 등등 사용해서 해결할 수 있는 부분
해놓으면 편하긴 하겠지만… 구현자체가 복잡하다.

결론은…

어떻게 배포를 해도 오류가능성이 존재하겠지만… 관리가 쉬운편이 더 낫지 않을까
적절한 방법을 골라서 정책을 정하고 지키는게 중요.

MSA에 필요한 API Doc의 종류

Human – Machine

API Doc은 Hunam, Machine – 두가지 버전이 필요하다.

Human

swagger

Machine

Hataoes
그리고 json형태의 doc???
에러로깅 방식..??
등 지원

Versioning(API Change log doc)

  1. history
  2. plan
    1. deprecated 일정예고
  3. current
    세가지 정보를 모두 표현해야한다

검증테스트

build runtime 버전 check
의존성 api들을 모두 기록해놓는다.
depends on – (auth-1.1)
depends on – (gis-201610)
….
기록해놓은 부분은 내가 참조했 버전이 맞는지 버전만 호출해서 확인.
의존성이 있는 MS들의 test 인스턴스가 떠있거나
docker-compose, kubernetes 등으로 관리되고 있어야 가능한 부분.
아닌가.. 버전만 확인하니까 git 주소만 알아도 가능할 것 같다.

유닛테스트일수도 있는데 좀 더 강하게 빌드시 확인을 해야한다.

API호출방법 – RESTful -> 멱등성Idempotent -> Stateless -> JWT

개요

멱등성 관련 : http://memo.polypia.net/archives/2505

  1. RESTful API를 쓰다보면
  2. 멱등성이 필요하고..
  3. 그러려면 Stateless 해야하고
  4. 그러기위해 JWT(JSON Web Token)를 지원하면 좋다.

JWT간략

JWT참고
http://bcho.tistory.com/999
https://jwt.io/
https://blog.outsider.ne.kr/1160

Claim기반 호출

HMAC을 이용한 보안
PPK필요

PPK(PublicPrivateKey)를 이용한 API인증

PlantUML Syntax:
== authentication setting ==
ResourceClient -> ResourceClient : when(deploy) generate ppk
ResourceClient -> AuthDirector : send public key and target(ResourceProvider)
AuthDirector -> ResourceProvider : push public key
ResourceProvider -> AuthDirector : response success/fail
AuthDirector -> ResourceClient : response success/fail
== call resource ==
ResourceClient -> ResourceProvider : call resource with JWT
ResourceProvider -> ResourceClient : response resource

JWT을 적용해서 쓴다면 대략이정도 느낌이 되면 될것같다.
gradle, maven 테스트, 배포 타이밍에 적절한 조치가 필요할 것 같다.

local에서 할 때는 auth가 제역할을 못해줄 것 같으니

auth서버도 push를 하려면 ppk(auth-ppk)가 있어야하고 ResourceProvider은 auth-ppk(public key)를 가지고 있어야한다.

종이에 그릴땐 간단해보였는데 다시보니 좀 복잡해보인다. 좀 더 간소화 필요.

Hateoas – 왜 쓰는거지

개요

rest api 사용할 때 관련있는 api의 목록을 제공한다는 컨셉

참고 :
https://spring.io/understanding/HATEOAS
https://en.wikipedia.org/wiki/HATEOAS

그런데… 근본적으로 이해가 안간다.
보통 뭔가 기술적으로 정립된것들을 보면 나도 필요하다고 생각했던 경우가 많은데
이건 왜 스는건가 의아하다
이건 도큐먼트 아닌가
기계가 알아봐야하는 도큐먼트
generated doc의 일종이 되어야 할 것 같다.
/rest/api/user
/rest/doc/user
와 같은 관계가 되야하지 않을까

일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.

gRPC 적용기 with JPA,Spring

gRPC

RPC기술인데 시리얼라이징 기능은 protocol buffer을 사용하고
gRPC는 strema 서버동작에 집중되어 있다.
아쉬운점은 protocol buffer에서의 아쉬운점 그대로다.
protocol buffer에 너무 의존적이 된다.
restful/json/bson/xml처럼 프로토콜만 맞추면 뭘 써도 되는 그런 라이브러리와는 다르다.

protocol buffer의존성에서 좀 벗어나서 thrift를 사용할 수 있게 변경하려는 것 같은데
다른것들도 적용이 되려나 모르겠다.

JPA와의 궁합

매핑지옥이 시작된다.
API가 실행될 때 마다 리플렉션을 사용하기는 싫고
몇몇 해결방안으로 제시된 것들을 보면

  • jpa를 xml로 생성한다는데… protocol buffer로 생성된 클래스에 xml로 생성된 코드를 오버랩핑한다는건가? 잘 이해가 안가고 솔루션이 제시된것도 아니라서 패쓰
  • .proto 파일이 아닌 어노테이션을 기반으로 protocol buffer의 객체를 사용할 수 있게 해준다는 것 같은데… 괜찮은 솔루션같은데 공식 라이브러리가 아니라 개인프로젝트가 아닌곳에 적용하긴 겁난다
    https://github.com/BAData/protobuf-converter

같이 쓰기 썩 좋지는 않다. 매핑노가다나 리플렉션 매핑을 좀 이용해야할 것 같다.

Spring과의 궁합

없다. 그냥 별도라고 봐야할 것 같다.
현재 SpringBoot를 이용하고 있는데 아직 별로 나온게 없어 보인다.

알수없는 오류

컴파일러 플러그인을 다운받는데 백신이 exe파일을 자꾸 지워버린다.
exe어쩌고 하면서 실행이 안될때 확인하자

결론은

아직 완전히 적용한것은 아니지만..

쓸만하긴한데 생태계가 완벽하지 않아서 신경쓸게 좀 많다.

MessageQueue를 이용한 비동기 RPC방식보다 나은지 잘 모르겠다.
아직 고민만 해보고 테스트는 못해봐서… 아예 안쓸지도 모르겠다.

RPC vs RESTful API

개요

약간 고민하게 되는데 생각보다 간단한 결론은

RPC는 내부 프로토콜로 사용 – 인프라 내부가 아닌 내부 서비스간의 통신.
APP의 API로도 사용가능.

REST API는 외부공개용.

끝.

요약

RPC

내부 서비스간 통신

RESTful

외부 공개용

ex)ample

ModileApp은 외부에 있지만 내부 서비스이다. API와 RPC통신
외주사가 회사 내부망에 설치한 GIS솔루션은 내부 서비스가 아니다. RESTful 방식사용

MSA의 시대, 다시 주목받을 RPC

RPC : Remote Process Call 진영은

몇년째 딱 대표적인 기술이 떠오르지 않고 고만고만하게 유지되고 있다.

개인적으로 RPC가 더 편하다고 생각하는데, RestAPI가 너무 대세가 되서 인기를 잃어버려 아쉽다.

아니 먼 RestAPI 데이터를 브라우저로 봐서 뭐한다고?!?~!

지금당장 기억나는것은 이정도….

Thrift
Avro
gRPC
ProtocolBuffer
BSon

완전 RPC라고 하기는 좀 그런 시리얼라이징 기술도 넓게 보면 RPC아닐까…
아니 그냥 RPC인가? 그냥 다 포함시켰다.

아직까지는 연동 API 제공 한다고 하면 당연하다는 듯이 RestAPI를 제공한다.

API는 다양한 문제점을 가지고 있고 기술적으로 열등하기 때문에 점점 사용률이 낮아질거라고 본다.

표준기술로 사랑받아왔던 RestAPI의 문제점들

  • 무거운 http api만드는데 http를 돌리는데 코스트낭비가
  • 너무 자유로운 설계 json을 ?params=%XX%XX 형태로 받는 경우도 있고
  • http1 프로토콜에서 낭비되는 네트워크 리소스 http2로 사용하면 좀 더 낫긴하겠지만..

웹기반 기술에서는 계속 사용되겠지만 MicroService가 등장하며 내부 네트워크 부하가 더 심해지는판에.. 이걸 계속써야할까?

아니

여태까지는 아키텍처/UX까지 Request후 Response를 기다리는 형태로 설계가 되었으니 RestAPI를 써도 불편한줄을 몰랐다

async환경으로 변화는… 패러다임의 변화다. 설계까지 변경된다.

변화의 조짐은 보인다.

요즘 유행하는 기술 트렌드를 보면

MSA, Async, Functional Programming

이정도… 그리고 이런 트렌드가 지속/확대 된다고 봐도 될 것 같다.

왜냐? 작은조직의 효율적 개발, 클라우드환경, 늘어나는 네트워크 트래픽 등등의 상화을 봤을때 방향성이 그쪽을 향하고 있으니까…

새로운 트렌드는

MicroService사이의 통신을 위한 가벼운 프로토콜 + MQ(MessageQueue) 클러스터를 이용한 내부 통신채널 일원화 + Functional Programming을 통한 Async방식 개발

이 될 것이고

MQ를 이용한 Async프로그래밍을 도와주는 프레임워크이 등장하면서 RPC 사용이 활발해질 것이다.

이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…

Facebook API. 그래프 API 탐색기 사용

탐새끼 : https://developers.facebook.com/tools/explorer

왜 이걸 쓰는가?

보통 OAuth Client샘플코드나 라이브러리를 만들어서 데이터를 확인하는데 그 과정을 거치려면 시간낭비도 심하고

코딩에 익숙하지 않거나 … 익숙하더라도 소셜API 호출에 익숙하지 않은 사람은 고생스럽다. OAuth가 표준이라고는 하지만 사이트마다 호출구조가 묘하게 다르기도 하고

facebookapiexplorer2

형광펜 표시한 부분만 API파라미터 넣어서 호출하면 된다. 예를들어

https://developers.facebook.com/docs/graph-api/reference/v2.8/user/feed

여기있는 feed호출을 보면

/{user-id}/feed

The feed of posts (including status updates) and links published by this person, or by others on this person’s profile. There are other edges which provide filtered versions of this edge:

  • /{user-id}/posts shows only the posts that were published by this person.
  • /{user-id}/tagged shows only the posts that this person was tagged in.

All of these derivative edges share the exact same reading structure, however /feed sh

 

라고 나와있으니 요즘 열받는 피자헛코리아 아이디를 넣어주고 feed를 넣고 호출 하면 결과가 출력된다.

 

API 뽑고 쓰고 별로재미도 없는데 요즘 자주 하게 되네