Tag: MSA

마이크로서비스 아키텍처 구축 대용량 시스템의 효율적인 분산 설계 기법, 한빛미디어

몇달쯤 전에 처음 볼 때는 뭐 당연한걸 책으로 써놨네~ 하면서 대충 훑어보고 말았는데
최근 MSA 관련 작업을 하면서 다시 보게 됐다.

다시 보니까 전에 못 보던 부분도 보이고 전체적인 흐름도 잘 정리되서 좋았다.

MSA 관련기술

DevOps 관련 플로우

  • 빌드시 유닛테스트
  • CI/CD
    • pull request 하면서 유닛테스트
    • 통과시 container build
      – 이미지에 로깅 툴을 넣어서배포
    • stg(staging) 배포
  • 통합테스트(수동?또는자동)
  • prd(production) 배포

예전에 제대로 모르고 넘어간 요소들

API GW(zuul), CircuitBreaker(hystrix), ServiceDiscovery(eureka), ClientLoadbalancer(ribbon)

넷플릭스쪽이 관련 인프라가 잘 돼 있어서 spring쪽 개발자는 그걸 참고하면 편하다.

MSA적용실패사례 – MSA vs Monolith

예전에 O2O 서비스를 만들 때도 SOA를 시도했다가 실패했는데
모놀리스형태로 만들어야 할 규모의 서비스를 무리하게 분할한게 원인이었다.

처음에 사용자별로 서비스를 나눈 것 까지는 좋았다.

  • 사용자ROLE별로 구분된 웹서버
    • 일반사용자
    • 관리자
    • 사장님
  • 인증서버
  • APP api서버

그런데 여기서 일부 기능을 떼서 서비스 지역정보, 메일문자전송, 다국어관리, … 이렇게 넣다보니 일이 너무 많아졌다.

DevOps도 처음 적용해서 여기저기 오류 터지는데 서비스 개발까지 하려니 죽어났다.

MSA 적용 실패요인

인력부족, 기술부족, 자금부족

MSA를 제대로 이해하고 있고 관련기술을 구성할만한 사람이 있어야된다.
연구하면서 진행하려면 서비스 개발 이외에 최소 서너명이 더 있어야 하지 않을까

서비스 변화

MSA는 서비스 목표가 확실해진 이후에 해야되는 것 같다. 전체적인 서비스 구조는 고정 되어 있고 기능을 추가하기 좋다는거지 서비스의 큰 흐름이 변하는 경우에는 절대로 쓰면 안된다.

초기 스타트업은 서비스 하다가 버리고 다시 시작하기도 하고 메인 기능이 막 바뀌고 추가되고 하니까 MSA에 적합하지 않다.

~

개발자라면 한번쯤 보는게 좋을 것 같다.

요즘 대부분 서비스가 MSA화 되어가고 있고 이정도 속도면 10년안에 국가프로젝트도 MSA적용이 일반화될 것 같으니까

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

 

MSA – 의존성 관리 방법

Global Dependency Dictionary System 정도로 불러도 되려나

MSA로 서비스를 구성할 때 발생하는 문제가

어떤 서비스를 Deprecated를 시켰을 때 이전 버전을 언제까지 유지시켜야 할지가 애매하다.

즉각적으로?

한달이상 호출이 없을 때?

모니터링 툴 돌리다가 수동으로?

그냥 소스코드 내부에 /v1 /v2 /v20171001 같은식으로 계속 유지시켜버릴까?

이런 방법은 다 확살하지 않거나 관리가 불편하거나 다양한 문제가 있다.

디비를 변경해야 하는경우에 버전업을 할 때 오류발생 가능성도 있고

 

배포시에 사전을 만들고 의존성을 갖는 프로젝트간의 관계를 가지고 있는게 좋을 것 같다.

일반적인 형태의 라이브러리나 프레임워크로 만들기는 힘들 것 같고

규칙성을 갖게 버저닝을 하고 배포를 해야할 것 같다.

v{메인버전_호환안될수있음}-버그픽스

v1_20171001-1

v1_20171001-2

버전 표기방식으로 흔히 쓰는건 이정도 아닌가

 

버그픽스버전의 경우

3번째칸은 변경되도 호환성에 문제가 없어야하고 1,2번칸이 변경될 경우 호환이 안될 가능성이 생기는걸로

버그픽스 버전이 배포되는 경우 유닛테스트 실행. 이상이 없어야만 배포허용.

 

버전업이 되는 경우

배포시 의존성을 갖는 서비스의 관리자에게 알림이 가고

유닛테스트가 실행. 오류가 나면 오류알림(해당서비스와 의존성을 갖는 서비스의 담당자)

의존성을 갖는 서비스의 담당자는 일정시일(1개월?)이내에 업데이트 권장

긴급수정 사항은 바로 업데이트

 

이 경우 배포툴에 각 개발자의 정보가 담겨있어야한다.

 

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 주소만 알아도 가능할 것 같다.

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

Load Balancing

개요

부하분산 방법

MSA
하드웨어방식 vs 소프트웨어 방식
예전에는 L4하드웨어방식만 썼는데 클라우드. 그리고 글로벌화되면서 상황이 좀 바뀌었다.

DNS

L$

L4
좋기야 하지.. 그런데 비싸다.
예전에는 많이 썼는데 요즘은??
클라우드에서도 L4를 지원해주긴하는데
속에서 몰래 소프트웨어방식으로 처리하는거 아닐까

Iptables

안해봤는데 될것같아

HaProxy

많이쓰는방법

ApacheHttpd – Proxy

Nginx – Proxy

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 사용이 활발해질 것이다.

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