MSA 그리고 API Gateway

내가 웹 서버 개발에 어렵지 않게 적응 할 수 있었던 데에는 웹과 게임 서버간에 의외로 비슷한 요소가 많았던 것이 크게 작용했다.

클라이언트와 서버의 연동이 어떻게 이루어지는가, 사용자에게 개방되는 요소가 무엇 인가, 이벤트를 어떻게 주고 받을 것인가 등등 사실상 이질감이 느껴지는 요소가 아주 많지는 않았다.

또 한가지 비슷한 요소가 있었는데, 백엔드 서비스간의 연동이다. 그 연동 관계를 서비스 아키텍쳐라고 부른다.

네트워크 모델과 유사한 면이 있는데, 이는 피어와 피어간의 통신 구조에 따라서 관리 이슈, 통신 코스트, 예외 상황, 장애 대응 등의 다양한 면에서 비슷한 접근이 가능하다.

이런 과정에서, MSA(Micro Service Architecture)가 대두되었는데, SOA (Service Oriented Architecture)의 발전형이라고 봐도 무방하다.

기본적으로 일체형 아키텍쳐(Monolithic Architecture)와 상반되는 개념으로써, 기능을 한 수레에 담지 않는 모델의 장점을 기반으로 설득력을 얻어가는 구조다.


일체형 아키텍쳐의 장점은 구현이 쉽다. 모든 데이터를 내가 보유하고 있으므로, 애초에 모든 일을 할 수 있다.

반면 성능 이슈 발생시 해결이 어렵다. 어떠한 기능으로 인한 성능 문제가 발생했는지 측정하기가 상대적으로 어려울 뿐더러, 특정 기능에 한정해 성능 개선이 필요할 때 유연하게 대비하기 어렵게 구현되기 쉽다. 또한 배포와 변경, 기동 시간에 단점이 있기 때문에 확장이 상대적으로 어려운 편에 속한다.

뿐만 아니라 로직의 결합도가 생기기 쉽고, 이는 스팟 포인트 증가, 블러킹 포인트 증가로 인한 성능 저하로 이루어지기 쉽고, 자연스레 버그 발생 확률이 증가하는 단점이 있다.

일체형 아키텍쳐와 MSA 비교

출처: martinfowler.com

이를 개선하기 위해 MSA는 서비스 단위로 서버를 구성하고, 수평 확장에 유연하므로 서비스 단위별로 스케일 인/아웃을 유연하게 구성하며, 결합도가 낮으므로 버그 발생 확률이 줄어들며, 테스트 단위도 작아질 수 있다.

성능 측정, 개선도 기능단위로 이루어지므로 명확하며, 필요한 만큼만 성능 확장을 할 수 있고 아키텍쳐 구축 과정에서 이뤄진 동적 스케일링 대비로 인한 안정적 서비스는 덤이다.

다만 여러 개 서비스의 데이터를 조합해서 사용해야 될 때의 문제, endpoint 관리의 문제, 적정한 서비스 단위를 규정하는 문제, 인증/인가 로직을 서비스마다 구현해야 되는 문제 등이 존재한다.

이를 해결하기 위해서 API Gateway를 사용하게 되는데, endpoint 관리 문제, 진입점 일치로 인한 인증/인가 처리의 유연함, 통계/로그 기록이 편해지는 장점, 과도한 트래픽 방지를 위한 Ratelimit 처리 등으로 인한 쪼개진 각 서비스의 이슈를 해결 하는 데에 집중한다.

API Gateway

단점으론 대다수의 서비스가 API Gateway를 통해 통신하게 되므로, API Gateway 자체에 장애가 발생하면 서비스 전체에 지장을 준다. 그래서 이를 대비하기 위한 여러가지 대안이 마련되고 있고, 그 중 최근 화두가 되고 있고, 가장 유명한 것은 Circuit Breaker 패턴을 기반으로 구현된 Netflix Hystrix라고 할 수 있다.


NetflixHystrix에 대해서 간단히 설명하고 넘어가자면, API Gateway의 구현 자체는 HTTP Request 응답을 대행하는 Proxy 역할을 담당하게 되므로 Request Proxy처리하는 동안 Request 요청을 잡고 있어야 한다.

대신해서 호출한 대행 요청이 오래 걸리게 된다면, 요청에 대한 처리속도가 저하되게 된다. 이렇게 밀리는 현상이 지속 되다 보면 전체적으로 응답 시간 저하가 이뤄지고 서비스에 지장을 주는 문제가 발생한다.

그래서 Timeout을 작게 잡아서, 특정 서버의 처리 시간 지연이 다른 요청에 영향을 주지 않게 처리해야한다.

이를 위해서 Timeout이 일정 수준 이상 발생한 서버는 요청 대상에서 격리 시킨다거나, Timeout 자체를 작게 설정해야 해서 영향을 덜 받게 만든다거나 하는 작업을 통해 API Gateway 자체의 Throughput 저하를 막아야 한다.

이 역할을 Hystrix가 담당해준다고 생각하면 된다. API Gateway에는 치명적인 단점인 장애의 전파지점이 SPOF (=Single Point Of Failure)가 되는 문제가 있으나, 이를 극복하기 위한 Netflix의 보완책이라고 볼 수 있다.


이와 별개로, API Gateway를 운용해보니 여러가지 생각이 들었다. 별개의 글에서 좀 더 자세히 설명하게 되겠지만, API Gateway에서 중요한 부분은 정확한 계측을 통해 안정적인 환경을 각 서비스에 전달하는 역할이다.

이를 위해서는 Public API Gateway는 사용자 요청을 수행하고 (Frontend 단에서 호출되게 처리. 인증/인가를 담당), Private API Gateway (내부 서버간 통신에서만 사용. ACL등의 최소화한 보안 처리. 통계의 분리)를 구성하는 것도 하나의 방법이라는 생각이 든다.


API Gateway가 해주면 좋은 역할

  • 인증
  • 인가
  • Ratelimit (사용자별, 서비스간 별개로 관리)
  • Endpoint 관리 (Routing, LoadBalancer, Dynamic Endpoint Management)
  • API 통계
  • API 로깅
  • API Request, Response 형식 검사 및 일관성 유지

이외에도 공통적으로 처리되어야 할 작업들을 API Gateway가 처리해주면 좋다.

다른 글에서 좀 더 자세히 다루겠지만, Netflix API Gateway 4종 세트 (Zuul, Ribbon, Eureka, Hystrix)는 API Gateway 모델의 장점 극대화, 단점 최소화를 이뤄냈다는 점에서 어떻게 구성했는지 배워볼 필요가 있다.

Netflix API Gateway의 핵심 기능

  • Zuul : Router and Filter
  • Ribbon : Load Balancer
  • Eureka : Registry Service
  • Hystrix : Latency and fault tolerance

Netflix Zuul

이 모듈들은 특별한 편집 없이 Annotation과 설정 파일만으로도 구축할 수 있다는 점이 더 큰 장점이다. 위에 언급한 대다수의 역할은 Zuul을 연동하고 동작 시킬 API Gateway 서버의 Filter에서 처리할 수 있다.

Zuul Filters


MSA에서 자주 겪는 문제는 모든 서비스에 같은 기능이 필요할 때의 중복 문제가 크게 발생한다. 이에 대한 버전별 서비스 이슈도 있고, endpoint 변경에 대해 유연한 대처도 어렵다.

이를 해결하기 위한 대안이 바로 API Gateway였고, 다양한 시도와 경험을 바탕으로 장단점이 밝혀졌다. 그리고, 그 것들을 극복하기 위한 대안들이 마련되며 MSA의 마스터 피스가 되었고, 현재로썬 Netflix Zuul이 안정적인 MSA 서비스 모델의 이상향으로 여겨지고 있다.

특히 Netflix의 어마어마한 사용자를 MSA로써 소화하는 모델에서 이용된 핵심 컴포넌트이기에, 그 노하우를 배우고 개선할 만 하다고 여겨진다.

모르긴 몰라도 많은 회사들이 내부적으로 자체적인 API Gateway를 개발하고, 운용할 것이다. 실제로 언어별로 다양하게 API Gateway 모듈이나 서비스가 존재하는 걸 보면, MSA에서 가장 중요한 역할은 API Gateway를 잘 구성하고 운용하는 데에 있다고 보는 듯 하다.

SOA에서 이어진 MSA의 확산, API Gateway 등장, API Gateway의 단점 개선으로 계속 진화하고 있는 MSA가 앞으로 어떻게 진화할지 궁금해진다.

윈도우 10 앱 추천

RSS

Note

To do list

Pocket

Database

  • HeidiSQL
  • NoSQLBooster (Mongodb)
    • https://nosqlbooster.com/
      • 사용해본 MongoDB 툴 중 가장 좋았음.
      • 리스트 관련해서 잔버그가 좀 있고, 페이징 처리시마다 쿼리를 다시 날리므로 무거운 쿼리를 수행하기에 적합하지 않음.
      • 소량 데이터 익스포트에선 편하나, 대량 데이터 익스포트는 유료 버전을 사용해야하는데, 익스포트쪽 잔버그가 꽤 보여서 불안 요소라 아직 안사봤음. 가격이 싸지도 않고…
  • Redis

Office

Sketch

CommandLine

  • Cmder
    • http://cmder.net/
      • cmd 창을 파워풀하게 만들어주는 프로그램.
      • ll, ls -al을 비롯한 각종 리눅스 like alias를 설정 가능하므로 여러모로 생산성을 높일 수 있다.

Capture

  • LightShot
    • https://app.prntscr.com/en/index.html
      • 캡쳐 프로그램 중 가장 간결함. 필요한 기능은 다 있다.
      • 캡쳐 후 간단한 메모 기능도 지원하며, 클라우드 저장 기능도 제공해 더할 나위 없이 편리한 캡쳐 툴.
  • PicPick
    • https://picpick.app/ko/
      • 좀 더 다양한 기능을 원할 경우에 선택지
      • 편집 기능도 좀 더 방대해서, 캡쳐 후 편집 기능을 쓰고 싶거나, 다양한 캡쳐 모드가 필요할 시 선택하면 좋다.

Web Dev

  • Postman
    • https://www.getpostman.com/
      • API 테스트에 이만한 툴이 없음.
      • 자동 동기화도 되고, 옵션도 디테일하고, 메뉴도 직관적인 편.
      • 환경 변수 기능, 파라미터, 바디, 쿠키 편집 등 안되는 기능이 없음.
      • 콜렉션 & 폴더 기능으로 테스트 셋 관리에도 유연함.
      • 다들 잘 모르는 기능이지만 환경 변수 기능 까지 더하면, 관리 이슈를 매우 낮출 수 있다.

Terminal

  • WinSSHTerm
    • https://winsshterm.blogspot.com/
      • windows 기반의 무료 SSH 툴 중 최고봉
      • 은근히 SSH 툴들이 비싸서…조금 싸면 직접 사서 쓰려고 했는데, 무료 툴 중에서 고르게 됨.
      • putty, pageant, VcXsrv, WinSCP 등의 툴을 별도로 다운받아야 하는게 번거로움.
      • ssh 설정만 해두면 같은 설정으로 scp와 연동이 되어있고, 클러스터 모드로 동일한 작업을 쉽게 처리할 수 있는 장점이 있다.
  • SmartTTY
    • https://sysprogs.com/SmarTTY/
      • Auto Completion 기능이 있어 아주 편하게 사용 가능.
      • SCP 파일 업로드/다운로드도 지원하고, 현재 폴더의 파일 목록도 편하게 보여주는 장점이 있다.

크롬 확장 프로그램 추천

테마

생산성

웹 개발

안드로이드 앱 추천

멀티미디어

생산성

정보

내가 다양한 언어를 익힌 이유

최근에 이런 질문을 여러 차례 받았다.

왜 그렇게 다양한 언어를 하세요?

나는 C언어로 프로그래밍을 시작했고 자연스레 C++을 하게 됐다.

내가 프로그래밍을 배우던 시기나, 그리고 처음 취업을 했던 2005년 게임 업계에서 게임 개발을 위해선 차선이 없었다. C++을 제외한 언어는 툴 개발이나, 일부 스크립팅에 제한적으로 사용했을 뿐이다.

compile 환경을 통한 성능 차이, native 언어라는 성능상 장점을 배제하기 힘든 당시 상황적 제약 때문이었다.

네트웍 기반의 온라인 게임이 활성화 되면서 붉어진 서버 개발에서도 정확한 성능 측정과 임계치 파악, 베이스 라인 설정 등이 아주 중요하다.

즉, 많은 어플리케이션 메트릭들을 최대한 계산된 영역으로 끌어내려야 하는데, managed언어도 잘 쓰려면 깊은 공부가 필요한데다가 양쪽 다 깊은 공부가 필요하다면 게임 업계에선 성능도 무척이나 중요하다고 보고 C++을 선택해온 것이라고 생각한다.

추가로 클라이언트와 유틸리티성 코드나 로직 코드를 공유할 수 있다는 점도 크게 작용했을 것이다.

그렇게 C++만 잘하면 될 것 같았던 나의 미래가, 모바일 시장이 열리면서 조금 달라졌다.


클라이언트 베이스의 게임이 다수 등장하고, 결과 저장을 위한 심플한 서버만 필요했던 시기가 되면서 웹서버가 도입됐다.

이전에는 GM툴 정도만 가동하던 웹서버로 게임 서비스를 진행하면서 다양한 언어가 게임 서버 개발 시장에 도입됐다.

자바, PHP, Node.js, Ruby on Rails 등… 다양한 언어로 구현된 웹서버로 게임이 서비스 되기 시작했다.

이 과정에서, 사내 스터디와 간단한 로그 분석 웹서버로 이용했던 Ruby on Rails를 나는 스타트 업에서 이용해서 서비스를 했고, 이후에는 Django를 통한 게임 서버를 구현하게 됐고, 성능상 이슈로 ASP.NET CORE로 포팅하게 됐었다.

이후 타의반 자의반으로 자바를 통한 게임 서버 개발을 하게 됐는데, 그 과정에서 자바를 익혔고 이후 웹 개발을 Spring Boot로 진행하면서 자바에 익숙해졌다.

사실 취미로 go랑 rust를 간단히 써보고 있었으나, 국내 개인 개발자 분들의 오픈소스가 워낙에 node.js, python, java에 편중되어 있다보니 포킹해서 작업 할 때는 해당 언어로 진행하면서, 더 익숙해진 감도 있다.

이렇게 익숙해진 일부 언어는 업무에서 사용할 기회로 이어지도록 노력하거나, 혹은 지속적으로 데브 토이로만 쓰게 되는 경우도 있다.


이렇게 다양한 언어에 대한 관심과 사용을 하는 이유는, 현대 언어는 서로 영향을 주고 받고 있는지, 어떠한 부분은 언어의 근본적 한계인지, 또 무엇에 대해 아쉬움을 느끼는지 알아야 내가 기술선정을 하게 될 때, 혹은 폴리글랏 프로그래밍을 해야 할 때 인지를 이해하고 싶어서였다.

이런 고민에 도움이 된 책은 임백준씨가 번역해주신 브루스 테이트의 세븐 랭귀지다.

그렇게 배우고나니 확실히 인사이트가 넓어졌다. 특히 C++만 파고들던 시기보다 훨씬 유연해졌다.

현대 개발은 바퀴를 재발명 하진 않지만, 자동차를 조립하기 위한 부품을 얼마나 잘 고르는지가 아주 중요한 문제다.

이는 유연함이 필요하다는 의미고, 그를 위해선 다양한 언어를 이해하고 있는 것이 필요하다.

그를 위해서 시작했던 다양한 언어에 대한 이해, 기술에 대한 편견을 내려 놓는 데에 큰 도움이 됐다.

그 것들이 앞으로의 내 발전에 큰 보탬이 될 요소라고 생각한다.

내가 종종 언급하는 얘긴데, 한국에서는 자바가 한국어 같은 느낌이다. 특정 업계 (게임, 보안, 네트워크 등)에서는 C++ 혹은 C언어지만, 그 비율이 다르다고나 할까?

하지만 내가 존경하는 대다수의 프로그래머는 자바만 (혹은 C++만) 잘하지 않는다. 잘 가져다 쓴다는 의미에는 상황에 따라 적합한 언어를 선정해야 한다는 의미도 큰 가치를 갖는다.

결국 상황에 따라 폴리글랏 프로그래밍 해야 한다는 얘기다.

자동화를 위해선, 혹은 서비스 로직을 위해선 가끔은 결합도가 낮게 작성한 스크립트 언어가 필요할 수 있다.

AWS 람다같은 서비스가 이에 대한 반증 중 하나라고 본다. 상황에 맞는 적절한 기술적 도입을 위해선, 기술에 대한 유연한 사고가 필요하다.

기술의 발전이 어떠한 메커니즘과 기술적 가치를 중점에 두고 발전하고 있는지는 알아야 한다. 그래야 더 적은 코스트로 더 안정적인 서비스를 구축할 수 있고, 그게 더 현명하고 더 합리적인 판단이다.

그래서 나는 다양한 언어를 익히려 시도했고, 큰 도움이 되고 있다. 내가 언급한 이런 부분에 대한 갈증과 아쉬움이 존재한다면 나와 같은 시도를 해보는게 어떨까?