지난번에 읽었던 마이크로서비스 구축과 운영에 이어서 내가 실제로 운영하고 있는 Node.js로 설명해주고 있는 이 책을 통해 마이크로서비스를 다시 이해해보고자 빌려왔다.
사이드 프로젝트를 진행하면서 필요한 서버를 간단하게 구축하고자 시작하게된 노드 서버를 하다보니 여러 프로젝트에서 필요로하고 있다. 그러나 내가 사용하고 있는 EC2는 단 하나! 나름 프로젝트 별로 서버를 분리해서 사용하겠다고 하나의 서버에 엔드포인트를 다르게 적용해서 사용하고 있었는데 그럴 필요 없이 그냥 여러개의 노드서버를 띄우면 되는거였다.
그리고 나서 프로젝트 별로 로그 처리나 슬랙봇 처럼 공통적으로 사용하고 싶은 부분들을 각각의 서버에 넣어주기엔 귀찮고 그래서 하나의 분리된 서버를 띄우고 이걸 사용하는건 어떨까 생각하다보니 이게 마이크로서비스인가???
모놀리식
서버 하나에 통쨰로 이것, 저것 다 넣어서 개발하기 편하고 로드밸런서를 이용해 이 서버를 통째로 인스턴스 하나만 내렸다 올리고 하면 되니깐 배포도 간단하다. 그러나 회원, 상품, 구매 관리 등 여러 서비스가 있는데 이 중 구매 관리 기능만 부하가 걸려서 증설하고 싶은 경우에도 모든게 하나로 묶여있다보니 분산처리가 불가능하다.
마이크로서비스
모놀리식에서 회원, 상품, 구매 모든게 하나로 묶여있었다면 마이크로서비스에서는 각각 모듈로 분리가 되어있어 독립적으로 신기술을 접목한다거나 개발하고 배포를 할 수 있다. 그러나 각각 독립적으로 개발하고 배포를 하면서 데이터를 공유하고 있는 경우 이런 부분은 또 마음대로 수정할 수 없기에 오히려 묶여있다고 생각되어진다.
Node.js 마이크로아키텍처
마이크로서비스의 특징인 독립성을 유지하면서 다른 서비스와의 연관성을 지속적으로 유지하기 위해 빠른 배포와 실행이 되야한다. 시작해 -> 하고 있어 -> 키고 있다~ -> 켜지고 있어~~ -> 실행!하는 과정이 아니라 시작해 -> 완료!하는 가벼운 Node.js를 이용해 마이크로서비스를 구축해보았다.
Node.js는 싱글스레드로 동작하고 있는데 데이터를 조회하는 I/O이 동기적으로 작동한다면 아무도 이용하지 않을 것이다. 내가 요청하는동안 아무도 아무런 응답을 받지 못하고 있을테니깐... (여기부터 자바스크립트 코어를 제대로 알고 있지 못한 내가 안타깝다) 메세지큐에 담아서 보내고 이벤트 루프를 돌면서 응답을...
모놀리식에서는 회원 서비스가 오류가 나면 시스템 전체가 작동하지 않게 되지만 마이크로서비스에서는 회원 서비스를 이용하려고 하면 오류가 발생할뿐 다른 서비스는 정상 작동하는 장점이 있다. 마이크로아키텍처는 마이크로서비스와 게이트웨이, 분산처리서버로 구성되어있고 각각 서비스의 통신규약을 통일하여 사용하며 Distributor는 각각의 서비스를 노드로 연결하고 서비스들의 상태를 공유, 저장하고 있다. (그럼 이 Distributor에서 장애가 발생하면?)
클라이언트 <-> 게이트웨이 <-> 마이크로서비스
1. Distributor를 실행하고 대기
2. 게이트웨이를 Distributor에 연결하여 클라이언트 호출 대기
3. 마이크로서비스를 Distributor에 연결하고 게이트웨이에 등록하여 클라이언트 호출 대기
보안을 위해 HTTPS 적용된 API와 게이트웨이를 통해서는 Public망에만 접속하고 Private망에는 마이크로서비스 내부적으로만 접속 가능하도록 한다. 게이트웨이는 모든 API 호출을 받고 Distributor에 해당 마이크로서비스가 접속 가능한지 확인 후 호출하게 된다.
그 외 마이크로서비스를 위해
- 공유 자원 사용함에 각각의 서비스가 자원 요청을 하는 것보다 메모리를 캐싱해서 조회 (Redis)
- 마이크로서비스 각각 로그를 저장하는 것보다 로그 마이크로서비스를 따로 구축해서 사용 (Elastic Search)
- 각각의 서비스들의 배포를 자동화하고 모니터링 (게이트웨이에서 API모니터링하고 따로 구축한 모니터링 마이크로서비스 호출 + 각각의 마이크로서비스의 프로세스 모니터링)
결론
적고 나니깐 제대로 알고 있는지 의문이 들었다. 특히 자바스크립트라는 것에 대해 알고 있는 걸까? 너무 커다란 주머니 먼저 알려고 하다가 기본을 모르고 넘어가게 되면 안되는데...