Medium - The 10 Puzzle Pieces of an Effective Microservice Architecture
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - 효과적인 마이크로 서비스를 위한 10가지 퍼즐조각
작은 서비스는 누구나 만들 수 있습니다. 여러분이 “Hello World” express 서버를 만들 었을 때 처음 하는 것이죠. 만약 전에 헬로 월드 express 서버를 만든적이 있다면 축하드립니다, 여러분은 마이크로 서비스를 만드신겁니다.
하나에서 서비스가 점점 많아질 수록 질문들이 쌓여가기 시작합니다. 어떻게 서로 대화를 해야할까? REST? RPC? Messaging? 그리고 다른 것보다 왜 그 방법을 택해야 할까?
여러분이 몇개의 서비스를 묶어놓은 작은 서비스들을 관리해야 하고 가장 쉬워보이기에 REST를 선택했다고 가정합시다. 이제 어딘가에 배포할 때가 되었습니다. 여러분이 마이크로서비스를 Modulus, Heroku와 같은 PaaS에서 돌리면 시간도 꽤 소비되고 꽤 비용이 나갈겁니다.
내부 private 네트워크 대신에 외부 네트워크를 통해 통신을 하는 지연은 말할 것도 없습니다. 그건 좋지 않죠. 그리고 환경 변수를 제공해서 어떤 엔드포인트가 ping을 날렸는지 알아야 할 필요가 있습니다.
그리고 배포에 대해서 생각을 하죠. 배포작업은 항상 고통스러운데 그걸 7번이나 더 해야합니다. 이런 시나리오는 제가 처음 시도했을 때 겪은 것입니다. 로깅은 무엇이고 모니터링은 뭐고, 보안정보는 어디다 저장해야하고 오토 스케일링은 뭐지?
마지막에 가서야 알아차리시겠지만 처음 여러분이 하고 싶으셨던 것은 작은 서비스를 만드는 것입니다, AWS를 이용해서 여러분의 인프라를 구축하는 방법에 대해서 알아봅시다.
다음의 도구들은 조합해서 사용하면 서비스 개발의 속도를 향상시켜주고 배포작업 및 다양한 환경에서 빠르고 쉽게 작업할 수 있습니다. 게다가 추가적으로 한번 코딩을 하면 재사용성이 꽤나 높습니다.
1. Containeriaztion
컨테이너화를 사용하지 않고는 효과적인 마이크로서비스를 만들 수 없습니다. 너무나도 많은 조각들이 있기 때문이죠. 그러니까 컨테이너 없이 작업을 할 수야 있겠지만 부수적인 작업이 매우 많을 것입니다. 여러분이 오레오 과자를 사는데 조각이 따로따로 온다고 생각해보세요, 문제야 없겠지만 매우 불편하겠죠.
서비스에서는 컨테이너들이 개발, 테스트, 배포, 실행과 같은 작업들을 단순화 시킵니다. 매일마다 이런 작업을 해야하는만큼 컨테이너를 사용하면 더욱 쉬워지겠죠. 서비스는 오레오처럼 컨테이너가 필요합니다. 여기에 사용되는 도구는 도커입니다.
2. A Cluster
여러분은 그냥 오레오만 원하지는 않을 것입니다. 아마 구운 치즈와 토마토 수프도 필요하겠죠, 왜냐면 밖이 추우니까요. 비사회적인 사람처럼 악취가 나지 않으려면 치약과 데오도란트도 있어야겠죠, 물론 맥주도 함께 말이죠.
여러분이 모든 생활용품을 개별적으로 따로따로 집으로 가져온다고 생각해봅시다. 전혀 말이 안될 것입니다. 그것들은 모두 장바구니에 넣어서 가져와야죠, 가장 무거운 것을 바닥에 놔야 빵이 안찌그러질 것이고 차가운 것은 차가운 것끼리 모으고, 어떤 것은 여분을 위해 더큰 가방이 필요할 수도 있습니다. 가방은 도커와 같습니다. 하나 이상을 가질 수 있고 그안에 서비스들을 넣을 수 있죠
하나 이상의 도커를 가지는 것은 특정 zone이 다운되었을 때처럼 실패 시나리오를 피할 수 있게 해줍니다. 대형 클라우드 제공자로부터 서버를 가져올 수 있습니다. 여기서 중요한 것은 인프라를 묶는 것입니다. 이것을 수행하는 방법은 여러가지가 있습니다. 과거에 사람들은 이것이 쓸데없다고 생각했지만 빠른 확장성을 위해서는 서버를 가져오고 공급되기까지 기다리는 것은 말도 안되는 것이죠. 대신에 모든 도구가 설치된 머신의 이미지를 구워놓고 해당 이미지를 클라우드 환경에 사용하는 것입니다. 일단 한번 클러스터를 탄력적으로 설계하면 새로운 AMI의 롤링업데이트가 전체 인프라스트럭쳐를 업데이트 해줄 것입니다.
Servers: AWS, Azure, Digital Ocean
Tools: Cloudformation, Terraform, Packer
3. An Orchestrator
이제 여러분은 짐을 꾸리는데 익숙해졌습니다. 그러나 여러분은 뉴욕에 살고있고 82달러에 구운 치즈들과 맥주를 샀는데 포장도 스스로 해야하나요? 잊어버리세요, 여러분은 이미 집에서 요리하는 것으로 돈을 절약하고 계시잖아요. 매일마다 짐을 싸주는 사람이 있습니다. 매일매일 하루도 쉬지 않고 말이죠, 정말 잘된 일입니다. Orchestrator는 식료품 포장담당원과 같습니다.
Orchestrator는 여러분 서비스의 메모리 요구사항을 포함해서 CPU가 얼마나 할당되어야 하는지, 각 서비스가 어떤 서버에 적절히 배치되어야 하는지 알고 있습니다.
Tools: Docker Swarm, Kubernetes
4. Continuous Deployment
배포작업은 시간이 걸리는 작업이고 이것을 더욱 잘 수행할 수 있는 방법이 있습니다. 바로 자동화입니다. 이것은 비즈니스가 돈을 버는데 직접적으로 기여를 합니다. 모든 린 스타트업은 빌드하고 측정하고 배우고 반복하는 것이 사이클입니다. 지속적인 배포는 이러한 것을 더욱 빨리 할 수 있도록 해주죠, 더욱 빠르게 결과물을 얻을 수록 여러분이 측정과 학습을 빨리할 수 있고 다음 빌드할 것을 빨리 알 수 있는 것입니다.
개인적으로 여러분이 마스터에 커밋하는 것까지 자신있게 자동화되도록 노력해야 한다고 생각합니다. 깃 플로우는 작은 서비스들 마다 한 15번쯤 반복하다보면 매우 성가셔집니다. 필요하다면 브랜치를 만드셔야 하지만 적절하게 검증이 되었다면 마스터에 커밋을 해도 괜찮습니다.
Tools: Jenkins, TravisCI, CircleCI
5. Proxy
여러분의 작업은 안전해야 할 것입니다. 가장 안전한 방법이 무엇일까요? 여러분의 서비스를 직접적으로 외부 인터넷에 노출하지 않는 것입니다 대신에 뒤쪽에 프록시가 노출되도록 하세요. 그러나 프록시는 설정하기 쉬워야하고 이상적으로는 서비스에 대한 옵션 설정의 정의되어 있어야 합니다. 그래서 서비스를 개발하는 팀은 ssh 접속없이 프록시와 소통하는 최선의 방법을 결정할 수 있어야합니다.
Tools: HAProxy, nginx, docker-flow-proxy
6. Message Queue
서비스들은 전체적인 언어로 통신되어야 합니다. 메시지큐는 모든 구독중인 클라이언트에게 메시지를 보낼 때 접착제처럼 사용될 수 있습니다. 또한 서비스는 다른 서비스들이 인터넷 어디서 동작하고 있어야 하는지 알고 있어야 할 책임이 있으면 안됩니다. 만약 그들이 움직인다면 여러분은 그것들을 알아야 하기 때문이죠.
물론 Consul같은 것을 사용해서 분산키를 저장해서 여러분의 서비스가 끊임없이 재설정되는 것을 피할 수 있습니다. 아니면 orchestrator의 DNS 능이나 REST를 사용할 수도 있지만 거기에는 추가적인 책임과 설정이 필요합니다. 그리고 이런 것은 여러분의 서비스를 강하게 결속되게 합니다. 단방향으로 메시지를 발송하고 잊어버리는 것이 여러분 서비스의 결속도를 낮게 만들고 확장하기 쉽게 만듭니다.
대신에 메시지큐를 사용하면 fire and forget 형태로 쉼게 메시지를 보내거나 발행할 수 있습니다. 다른 서비스들은 쉽게 추가되거나 제거될 수 있으며 오리지널 퍼블리싱 서비스에 영향을 주지 않습니다. 이것이 여러분에게 쉬운 확장성을 제공해줍니다. 또한 재시도나 에러큐와 같은 피처에서도 서비스 크래싱에 대한 부담이 줄어듭니다. 메시지는 서비스가 살아나면 단순하게 재전송 될 것입니다.
Tools: RabbitMQ, ActiveMQ, AWSMQ, ZeroMQ
7. Centralized Logging
메시지들은 많은 노드와 레플리카들 그리고 잠재적으로 orchestrator 근처에서 발생하기 때문에 서버의 ssh에 접속해서 로그를 확인할 수 있는 것이 아닙니다. 메시지들이 쉽게 검색될 수 있고 코드의 기능이 제대로 동작하는 지 인사이트를 얻을 수 있는 곳으로 중앙집결 시켜야할 필요가 있습니다. 모든 것을 한곳에서 봐야합니다. 추가적으로 서비스에게 로그를 옮기도록 하는 책임을 주어서는 안됩니다. 대신에 항상 로그를 stdout/stderr로 기록하고 여러분의 클러스터 내에 모든 노드에 대해 전역적으로 수집을 하는 도구를 사용해야 합니다. 로그 수집 도구는 여러분의 중앙 로깅 시스템으로 로그를 옮겨줄 것입니다.
Tools: ELK Stack
8. Monitoring and Alerting
로깅과 마찬가지로 서비스 사용 통계를 보기위해서 서비스들을 추적하는 것도 하고싶지 않을 것입니다. 대신에 사용통계도 중앙화된 장소로 옮겨져야 합니다. 사람에게 알림이 가기전에 스케일링이나 복구 이벤트가 동작하도록 알림을 사용하세요 여러분은 가능하다면 분석 정보를 드릴다운 하고 싶지도 않을 것입니다. 이상적으로 여러분은 뭔가 잘못되었을 때 비프음을 들을 수 있어야합니다. 이 말은 알림도구가 모니터링을 통해 수집된 메트릭에 반응을 할수 있어야하고 사용자에게 알림을 줘야하는 것이죠. 더욱 나은 것은 스케일링 작업을 실행하거나 사림의 인터랙션이 필요없는 방식으로 문제를 해결할 수 있는 마이크로 서비스를 실행하는 것입니다.
Tools: Prometheus, Alertmanager, Grafana
9. A meta repository
대부분의 사람들은 단일저장소나 다중 저장소에 대해 들어봤을 겁니다, 둘다 특정 요구사항을 충족하죠. 그러나 마이크로서비스에서는 많은 것을 처리할 수 있는 수많은 저장소들을 가져야 합니다. 메타 저장소는 부모 저장소를 만들고 많은 저장소에서 동시에 명령어를 실행할 수 있는 커맨드라인 도구를 이용해서 이문제를 해결합니다.
Tools: meta, gitslave
10. A Microservices Mindset
아키텍처를 짜는 일은 인프라가 구성되었다고 끝나는 것이아닙니다. 아키텍쳐의 이익을 얻기 위해서는 팀이 마이크로 서비스를 적극적으로 수용해야 합니다. 아키텍쳐의 모든 도구의 목적은 해당 작업에 최적인 모든 언어를 지원하도록 유연하게 해주고 메시지 버스덕분에 결합도를 낮추고 컨테이너화 하는 것입니다. 만약 여러분의 팀이 그냥 하나로 만들어서 마이크로 서비스라고 부른다면 제대로 동작하지 않을 것입니다. 그러니까 팀원들은 마이크로서비스 디자인패턴과 장점에 대해 교육받아야 합니다.
Summary
- 마이크로서비스 구조(MSA)에 대한 개요
- 컨테이너화가 중요하다; 마이크로서비스를 컨테이너에 담아야 스케일업이 편하다
- 마이크로서비스는 매우 많은 수의 서비스를 처리해야 하므로 메시징큐, 로깅, 모니터링도 도구를 사용하면 한번에 일괄적으로 관리할 수 있다.
- 해당 도구를 사용하여 결합도를 낮추고 컨테이너화를 하는 것이 마이크로서비스의 설계 목적(확장성)의 장점을 최대한으로 활용할 수 있다.
