List
- Postman
- Paw https://paw.cloud/
- soapUI
- HTTPie
- Postwoman
- RESTer
- RESTClient
- HttpRequester
Ref
- https://alternativeto.net/software/postman/
Category: API
MSA 시스템 구축에 필요한 기술들
시스템 분석
collectd : cpu, memory, hdd 수집 데몬
ganglia : 분산형 모니터링 시스템
네트워크 분석
cacti : 네트워크 snmp
로그분석
http://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html
scribe : c++, facebook legacy
flume : apache
fluentd : ruby, c
log stash : elastic search
보기Visualization
kibana
storm
로깅 시스템
ElasticSearch
Nagios
https://sensuapp.org/
Prometheus
Management tool
이걸 뭐라고 하는데.. 프로비저닝은 아니고
puppet
ansible
chef
salt
https://www.terraform.io/
Deployment
capistrano
https://github.com/capistrano/capistrano
Container
Docker
KVM
…
Test
Vagrant
pact, pacto??
https://github.com/presidentbeef/brakeman
sonar
설정 중앙화
Hashicorp – https://www.consul.io/
Debugging, Tracing
https://github.com/openzipkin/zipkin
https://github.com/StackExchange/Dapper
http://opentracing.io/
배치분석
Hadoop, Spark
Cache, Proxy
https://varnish-cache.org/
http://www.squid-cache.org/
redis
AWS
boto3 : python용 aws sdk – 배포시 사용
기타
zookeeper
hashicorp
https://github.com/Netflix/SimianArmy
기술개념
CQRS
Excel Rest Client
https://github.com/VBA-tools/VBA-JSON
https://github.com/VBA-tools/VBA-Web
VBA로 RestClient호출해야하는경우 사용하기 좋은 라이브러리
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)
- history
- plan
- deprecated 일정예고
- 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
- RESTful API를 쓰다보면
- 멱등성이 필요하고..
- 그러려면 Stateless 해야하고
- 그러기위해 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인증
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
와 같은 관계가 되야하지 않을까
일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.
restful 멱등성이 지원되도록 한다면
호출뻑할때가 많은데
멱등성이 필요할때가 많다.
unique조건. id값은 오차가 생길 수 있지만 unique를 활용하면 어느정도 처리할 수 있지 않을까
완전히 같을수는 없고
대신에 비슷한 요청이 올 때 update가 돼 버릴 수도 있다.
이게 상관없다면 이렇게 그냥 하는것도 괜찮지 않을까
상관없는 경우도 많으니
ajax호출이나 client에서 호출하는경우에 특히 중복호출이 많으니…
async로 한다면 더 심할 수 있다.
처리소요시간에 따라 적정 딜레이가 도움이 될 수도 있겠다.
cache처리하는것처럼 dynamic하게 관리되면 될 것 같다.
응답시간이 평균 5초정도라면 3초안에 중복요청은 무시해버리는식으로
사람이 많을때 서버성능을 향상시키는데도 도움이 될 것 같다.
설계는 다음에
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 사용이 활발해질 것이다.
이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…