<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>2010년대 모바일 시대에 맞추어 클라우드 컴퓨팅과 마이크로서비스 아키텍처와 같은 기술 트렌드가 주류가 되면서, 초기 오픈 API/매쉬업 기반 전략들을 모범 사례를 삼아 사내 API 기반 인터페이스 도입이 많아지고 있습니다. 즉, 요즘에는 외부 개발자 대상 오픈 API를 제공하는 것 보다는 사내 아키텍처를 API 통신을 기본으로 하는 마이크로서비스로 바뀌면서 API 활용도가 바뀌고 있다는 것입니다.</p>



<p>이 글에서는 마이크로서비스 시대의 왜 API가 중요하게 되었는지, 요즘 현대 애플리케이션에서 API 기반 서비스 구축 및 관리 트렌드가 어떻게 변화하고 있는지 살펴보려고 합니다.</p>



<p><strong>■ 오픈 API는 어떻게 변화했나?</strong><br>넷플릭스의 API 서비스를 담당하던 데이비드 제이콥슨(Daniel Jacobson)은 <a href="https://www.slideshare.net/danieljacobson/netflix-api-presentation-to-paypal-12931138">2012년 페이팔에서 행한 강연</a>에서 더 이상 외부 개발자를 위한 오픈 API 전략은 유효하지 않다는 뜻밖의 이야기를 합니다. 2008년 넷플릭스 API를 외부 개발자에 공개할 때와 달리, 당시 전체 트래픽에서 외부 업체가 사용하는 건 1% 뿐이며 나머지는 스마트폰, 태블릿, TV 등 넷플릭스 유료 사용자의 다양한 외부 기기에서 소비하고 있다는 것입니다.</p>



<figure><img loading="lazy" width="940" height="360" src="http://channy.creation.net/data/channy/2020/07/27212227/2012-Netflix-API-Daniel-Jacobson-940x360.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>넷플릭스 API 활용도의 변화</figcaption></figure>



<p>이는 회사 밖 외부 API의 제공 목적이 초기 개발자 생태계 확대에서 오히려 자체 서비스에 대한 유연한 확장에 두는 방향으로 바뀌고 있음을 반증합니다. 당시 트위터 및 에버노트 등도 서드파티 애플리케이션에 <a href="https://zdnet.co.kr/view/?no=20120818044517">오픈 API 지원을 서서히 중단하는 방향</a>으로 전략을 수정했습니다. 오픈 API 생태계 구축이 장기적으로 서비스의 ‘계륵’의 역할을 할 수 있다는 것을 보여 준 대표적 사례입니다. 즉, 엔드유저 서비스의 경우 오픈 API 전략이 초기 팬층을 늘이거나 외부 서비스와 연계를 통한 인지도 상승의 효과가 있으나, 장기적으로 트래픽 상승으로 인해 API 소비자가 뒤바뀌면서 팀의 역할이 바뀌거나 기존 비즈니스 모델과 상충될 수 있습니다. <em>(물론 <a href="http://channy.creation.net/blog/1371">1편</a>에서 언급한 바대로 지금도 여전히 많은 소프트웨어 서비스형(Software as a Service) 기업들은 외부 API를 통해 구독형 혹은 트래픽형 과금으로 주요 사업을 영위하고 있습니다만…)</em></p>



<p>그 당시 저도 Daum에서 API 전략을 담당하면서 <a href="http://channy.creation.net/blog/1199">비슷한 경험</a>을 했습니다. 외부 개발자에게 제공하던 오픈 API 소통 방식이 사내에서도 유용한 인터페이스라는 것이 입증되자, 사내 API 공개 및 재활용 트래픽이 기하 급수적으로 증가하였습니다. 이 때문에 외부 API 게이트웨이를 담당하던 저희 팀이 중심이 되어 사내 API 허브를 구축하는 프로젝트를 진행하게 되었습니다. 당시 외부 API 호출 건이 일 천만건 정도였는데, 내부 API 호출 건은 일 수억건이었습니다. (그 이후, 카카오와 합병하면서 두 회사의 API 플랫폼은 또 한번 통합 과정을 거친 것으로 압니다.)</p>



<p><strong>■ 마이크로서비스 아키텍처와 내부 API의 확대</strong><br>넷플릭스가 API를 보는 시각을 바꾸게 다른 계기는 바로 마이크로 서비스 (Microservices)라는 아키텍처 때문입니다. 사실 2002년에 <a href="http://channy.creation.net/blog/1260">아마존의 서비스 지향 (Service-oriented) 아키텍처</a>가 원조이지만, 넷플릭스의 사례가 훨씬 더 많이 알려져 있습니다. <em>(여기서 마이크로서비스가 무엇인지 반복해서 설명할 필요는 없을 것 같고, 자세한 것은 <a href="http://channy.creation.net/articles/microservices-by-james_lewes-martin_fowler">마틴 파울러의 마이크로서비스 정의</a>와 저의 강연을 참고하시길 권해드립니다.)</em></p>



<figure><p>
<iframe loading="lazy" title="마이크로서비스 기반 클라우드 아키텍처 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)" width="500" height="281" src="https://www.youtube.com/embed/Grf9IYuQMc4?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>
</p></figure>



<p>간단히 말해, 서비스의 규모가 성장해감에 따라 단일 코드, 단일 데이터베이스 기반의 통으로 된 모놀리식(Monolith)개발 방식에 비해 마이크로서비스는 개별 기능 별로 서비스를 잘게 쪼개고, 그 사이에 느슨한 연결의 API 통신을 연결함으로서 빠른 서비스 구현과 배포의 유연성을 얻는 방식입니다. 이게 가능해 진 것은 클라우드 컴퓨팅의 도입으로 인해 개별 서비스 배포를 위한 인프라의 설정과 배포가 과거와 달리 유연해졌다는 점, 작은 팀들이 자율성을 가지고 데브옵스(DevOps)를 통한 서비스 주도권을 확보할 수 있다는 점 때문입니다.</p>



<p>최근에는 가상 서버 기반의 서비스 배포 방식이 컨테이너와 서버리스로 급격하게 옮겨가면서 유연성은 더 커지고 있는 상태입니다. 멀리서 전체 서비스 아키텍처를 살펴 보면, 흔히 말하는 데스스타 <em>(Death Star, 아마 스타워즈의 부서진 데스스타 행성처럼 보인다해서 붙여진 이름) </em>다이아그램의 복잡한 모습을 띠게 됩니다.</p>



<figure><img loading="lazy" width="900" height="468" src="http://channy.creation.net/data/channy/2020/07/27213249/Microservices-Architecture-1.png" alt="" sizes="(max-width: 900px) 100vw, 900px"><figcaption>아마존닷컴과 넷플릭스의 마이크로서비스 아키텍처</figcaption></figure>



<p>일견 복잡도가 늘어나는 것처럼 보이지만 비동기적 API 유연성과 팀의 자율성을 통한 민첩성 그리고 서비스가 일시에 다운되는 일을 방지할 수 있다는 점에서 기존 모놀리식(Monolithic) 개발 방식과 차별됩니다. 따라서, 마이크로서비스 아키텍처를 도입하는 경우, 필연적으로 API 구현과 관리의 중요성이 높아지고 있습니다.</p>



<p>각각 마이크로서비스의 API들은 크게 내부의 다른 마이크로서비스의 요청을 받거나, 아니면 외부의 모바일 단말 혹은 서비스 업체의 요청을 받게 됩니다. 이 두 가지 특성을 처리하기 위해 크게 API 게이트웨이(Gateway) 와 서비스 메쉬(Service Mesh)를 나눠서 사용합니다.</p>



<p><strong>■ API 게이트웨이와 서비스 메쉬</strong><br>API 게이트웨이는 여러 API에 대한 권한 인증, 모니터링, 로드 밸런싱, 캐싱, 과금을 위한 측정 등을 통합적으로 제공하는 방식으로 초기 부터 많이 도입되었습니다. 대용량 요청을 처리하기 위해 <a href="https://netty.io/">Netty</a>, <a href="https://vertx.io/">Vert.x</a>, <a href="https://projectreactor.io/">Spring Reactor</a> 같은 비동기 방식 프레임워크와 이를 효율적으로 처리하기 위한 리액티브 방식으로 구현합니다. 외부 API 제공을 위한 방편일 뿐 아니라 어떤 경우에는 사내 API 포털을 구축할 때도 사용되기도 했습니다. 일부 API가 장애가 나면, 캐싱과 폴백(Fall-back) 등을 지원함으로서 각 서비스간 소통에 도움이 되기 때문인데요.</p>



<p>하지만, API 게이트웨이 자체가 장애가 나면 전체에 타격을 주는 경우가 생깁니다. 넷플릭스는 내부 서비스의 경우, API 게이트웨이 방식 보다는 각 서비스들이 직접 API 통신을 하도록 하는 방식으로 구현했습니다. 이를 외부에 <a href="https://netflix.github.io/">오픈 소스로도 공유</a>했는데, 외부용 API 게이트웨이는 Zuul을 사용하고, 내부 API는 <a href="https://github.com/Netflix/eureka/">Eureka </a>(타 API 서비스 레지스트리)와 결합한 <a href="https://github.com/Netflix/ribbon">Ribbon</a> (클라언트 기반 로드밸런싱 – 타 API 서비스 디스커버리 및 분배)과 <a href="https://github.com/Netflix/Hystrix">Hystrix</a> (서킷브레이커 – 타 API 장애시 대처) 같은 도구를 통해 각 서비스 API가 Gateway의 역할을 자체적으로 수행하는 것입니다.</p>



<figure><img loading="lazy" width="940" height="264" src="http://channy.creation.net/data/channy/2020/07/27215149/2020-apigateway-servicemesh-940x264.png" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>API Gateway vs. Service Mesh</figcaption></figure>



<p>이러한 모범 사례를 계승한 것이 바로 서비스 메쉬(Service Mesh)라는 개념으로 쉽게 말해 마이크로 서비스 간의 API 통신만을 담당하는 요소입니다. 각 서비스에서 API 통신은 필수 부분이 되었기 때문에 아예 통신 부분만을 비즈니스 로직과 따로 분리해서 각 서비스 API간 라우팅 설정, 로드 밸런싱, 장애 복구, 보안 및 모니터링할 수 있습니다. 원래 Lyft에 만들어진 오픈 소스인 <a href="https://www.envoyproxy.io/">Envoy</a>는 사이드카(Side-car) 방식의 프록시 서버로 또다른 오픈 소스인 <a href="https://istio.io/latest/docs/concepts/what-is-istio/">Istio</a>와 결합하면 “서비스 메쉬”를 구현할 수 있습니다.</p>



<figure><img loading="lazy" width="940" height="591" src="http://channy.creation.net/data/channy/2020/07/27220830/2020-istio-architecture-940x591.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>Envoy와 Istio를 함께 사용하면 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 자동 로드 밸런싱, 상세한 라우팅 규칙 구성, 장애 복구 및 주입 실험 등 현대적인 아키텍처 구성이 가능합니다. 또한, 서비스 간 접근 제어, 트래픽 제어, 모니터링 및 로그 추적을 통해 트래픽 동작을 세밀하게 제어합니다. 클라우드 서비스인 AWS에서도 <a href="https://aws.amazon.com/ko/app-mesh/">AppMesh</a>라는 서비스를 제공하고 있기도 합니다. </p>



<p><strong>■ 과연 둘다 필요한가요?</strong><br>API 게이트웨이의 주요 목적은 외부의 트래픽을 받아 처리하는 방식으로 역할을 담당하고, 서비스 메쉬는 내부 API 트래픽을 라우팅하고 관리하는 방식으로 분담하는 추세입니다. 이 두 가지를 조합하는 것이 효과적인 마이크로서비스 구현 방식입니다. 흥미로운 점은 서비스 메시 기술이 빠르게 발전하고 있으며 API 게이트웨이의 일부 기능을 수행하기 시작했다는 것입니다.</p>



<figure><img loading="lazy" width="940" height="322" src="http://channy.creation.net/data/channy/2020/07/27220846/2020-istio-v3alpha1-940x322.png" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>Istio의 v1alpha3 API 구조</figcaption></figure>



<p>예를 들어, 초기 Istio는 Kubernetes 기반 수신 제어를 사용했는데, 2018년부터 <a href="https://istio.io/latest/blog/2018/v1alpha3-routing/#configuration-resources-in-v1alpha3">v1alpha3 API</a>에 의해 도입하면서 외부의 트래픽 수용도 더 쉽게 되었습니다. 엔터프라이즈 서비스 메쉬 제품인 <a href="https://aspenmesh.io/">Aspen Mesh 1.0</a>에서 Istio v1alpha3 라우팅 API을 도입하기도 했습니다. 현재 대다수 기업들이 Docker 및 Kubernetes를 사용하여 마이크로서비스 아키텍처를 구현하는 추세이기 때문에 API 게이트웨와 서비스 메쉬 기능이 아예 병합 될 가능성이 높습니다. 그동안 독립형 API 게이트웨이에 대한 제품 수요와 기업들의 활용도가 낮아지는 것도 이런 이유입니다.</p>



<p>마이크로서비스 아키텍처로 인해 API를 바라보는 방식과 구현하는 방식도 꽤 많이 변화하였습니다. 다만, 이러한 변화는 API 서비스 구현에 있어 민첩성, 유연성과 API 소비자의 변화에 따른 비즈니스 요구에 따른 것입니다. 만약, 이 글을 읽고 새로운 트렌드를 그냥 막 따라할게 아니라 현재 여러분의 서비스의 단계가 어느 정도인지 파악하고, 적당한 솔루션을 선택하는 것을 추천드립니다. ‘뱁새가 황새 따라가다 가랑이가 찢어진다’라는 속담이 있죠. 몸에 맞지 않는 아키텍처를 섣불리 도입하기 보다 현재 상황에 맞게 선택하는 것이 가장 중요합니다.</p>



<p>다음 글에서는 국내 API 활용 현황을 외부에 API를 제공하고 있는 기업과 마이크로서 서비스 아키텍처를 도입한 기업들, 그리고 금융 기관 및 정부 기관의 현황 등을 살펴보겠습니다. </p>



<h4>연재 순서 </h4>



<ul><li><a href="http://channy.creation.net/blog/1371">API 이코노미를 살펴보다 (1) 최근 API 기술 및 사업화 동향</a></li><li><a href="http://channy.creation.net/blog/1382">API 이코노미를 살펴보다 (2) 마이크로서비스 시대의 API</a></li><li><a href="http://channy.creation.net/blog/1388">API 이코노미를 살펴보다 (3) 국내 API 활용 현황 및 제언</a></li></ul>




<div><h3>더 읽어 볼 글</h3></div>	

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)</p>

        <p><small>- ;</small></p>

	
	


	   </div></article>
</div></div>

Channy's Blog

2010년대 모바일 시대에 맞추어 클라우드 컴퓨팅과 마이크로서비스 아키텍처와 같은 기술 트렌드가 주류가 되면서, 초기 오픈 API/매쉬업 기반 전략들을 모범 사례를 삼아 사내 API 기반 인터페이스 도입이 많아지고 있습니다. 즉, 요즘에는 외부 개발자 대상 오픈 API를 제공하는 것 보다는 사내 아키텍처를 API 통신을 기본으로 하는 마이크로서비스로 바뀌면서 API 활용도가 바뀌고 있다는 것입니다.
이 글에서는 마이크로서비스 시대의 왜 API가 중요하게 되었는지, 요즘 현대 애플리케이션에서 API 기반 서비스 구축 및 관리 트렌드가 어떻게 변화하고 있는지 살펴보려고 합니다.
■ 오픈 API는 어떻게 변화했나?
넷플릭스의 API 서비스를 담당하던 데이비드 제이콥슨(Daniel Jacobson)은 2012년 페이팔에서 행한 강연에서 더 이상 외부 개발자를 위한 오픈 API 전략은 유효하지 않다는 뜻밖의 이야기를 합니다. 2008년 넷플릭스 API를 외부 개발자에 공개할 때와 달리, 당시 전체 트래픽에서 외부 업체가 사용하는 건 1% 뿐이며 나머지는 스마트폰, 태블릿, TV 등 넷플릭스 유료 사용자의 다양한 외부 기기에서 소비하고 있다는 것입니다.
이는 회사 밖 외부 API의 제공 목적이 초기 개발자 생태계 확대에서 오히려 자체 서비스에 대한 유연한 확장에 두는 방향으로 바뀌고 있음을 반증합니다. 당시 트위터 및 에버노트 등도 서드파티 애플리케이션에 오픈 API 지원을 서서히 중단하는 방향으로 전략을 수정했습니다. 오픈 API 생태계 구축이 장기적으로 서비스의 ‘계륵’의 역할을 할 수 있다는 것을 보여 준 대표적 사례입니다. 즉, 엔드유저 서비스의 경우 오픈 API 전략이 초기 팬층을 늘이거나 외부 서비스와 연계를 통한 인지도 상승의 효과가 있으나, 장기적으로 트래픽 상승으로 인해 API 소비자가 뒤바뀌면서 팀의 역할이 바뀌거나 기존 비즈니스 모델과 상충될 수 있습니다. (물론 1편에서 언급한 바대로 지금도 여전히 많은 소프트웨어 서비스형(Software as a Service) 기업들은 외부 API를 통해 구독형 혹은 트래픽형 과금으로 주요 사업을 영위하고 있습니다만…)
그 당시 저도 Daum에서 API 전략을 담당하면서 비슷한 경험을 했습니다. 외부 개발자에게 제공하던 오픈 API 소통 방식이 사내에서도 유용한 인터페이스라는 것이 입증되자, 사내 API 공개 및 재활용 트래픽이 기하 급수적으로 증가하였습니다. 이 때문에 외부 API 게이트웨이를 담당하던 저희 팀이 중심이 되어 사내 API 허브를 구축하는 프로젝트를 진행하게 되었습니다. 당시 외부 API 호출 건이 일 천만건 정도였는데, 내부 API 호출 건은 일 수억건이었습니다. (그 이후, 카카오와 합병하면서 두 회사의 API 플랫폼은 또 한번 통합 과정을 거친 것으로 압니다.)
■ 마이크로서비스 아키텍처와 내부 API의 확대
넷플릭스가 API를 보는 시각을 바꾸게 다른 계기는 바로 마이크로 서비스 (Microservices)라는 아키텍처 때문입니다. 사실 2002년에 아마존의 서비스 지향 (Service-oriented) 아키텍처가 원조이지만, 넷플릭스의 사례가 훨씬 더 많이 알려져 있습니다. (여기서 마이크로서비스가 무엇인지 반복해서 설명할 필요는 없을 것 같고, 자세한 것은 마틴 파울러의 마이크로서비스 정의와 저의 강연을 참고하시길 권해드립니다.)
간단히 말해, 서비스의 규모가 성장해감에 따라 단일 코드, 단일 데이터베이스 기반의 통으로 된 모놀리식(Monolith)개발 방식에 비해 마이크로서비스는 개별 기능 별로 서비스를 잘게 쪼개고, 그 사이에 느슨한 연결의 API 통신을 연결함으로서 빠른 서비스 구현과 배포의 유연성을 얻는 방식입니다. 이게 가능해 진 것은 클라우드 컴퓨팅의 도입으로 인해 개별 서비스 배포를 위한 인프라의 설정과 배포가 과거와 달리 유연해졌다는 점, 작은 팀들이 자율성을 가지고 데브옵스(DevOps)를 통한 서비스 주도권을 확보할 수 있다는 점 때문입니다.
최근에는 가상 서버 기반의 서비스 배포 방식이 컨테이너와 서버리스로 급격하게 옮겨가면서 유연성은 더 커지고 있는 상태입니다. 멀리서 전체 서비스 아키텍처를 살펴 보면, 흔히 말하는 데스스타 (Death Star, 아마 스타워즈의 부서진 데스스타 행성처럼 보인다해서 붙여진 이름) 다이아그램의 복잡한 모습을 띠게 됩니다.
일견 복잡도가 늘어나는 것처럼 보이지만 비동기적 API 유연성과 팀의 자율성을 통한 민첩성 그리고 서비스가 일시에 다운되는 일을 방지할 수 있다는 점에서 기존 모놀리식(Monolithic) 개발 방식과 차별됩니다. 따라서, 마이크로서비스 아키텍처를 도입하는 경우, 필연적으로 API 구현과 관리의 중요성이 높아지고 있습니다.
각각 마이크로서비스의 API들은 크게 내부의 다른 마이크로서비스의 요청을 받거나, 아니면 외부의 모바일 단말 혹은 서비스 업체의 요청을 받게 됩니다. 이 두 가지 특성을 처리하기 위해 크게 API 게이트웨이(Gateway) 와 서비스 메쉬(Service Mesh)를 나눠서 사용합니다.
■ API 게이트웨이와 서비스 메쉬
API 게이트웨이는 여러 API에 대한 권한 인증, 모니터링, 로드 밸런싱, 캐싱, 과금을 위한 측정 등을 통합적으로 제공하는 방식으로 초기 부터 많이 도입되었습니다. 대용량 요청을 처리하기 위해 Netty, Vert.x, Spring Reactor 같은 비동기 방식 프레임워크와 이를 효율적으로 처리하기 위한 리액티브 방식으로 구현합니다. 외부 API 제공을 위한 방편일 뿐 아니라 어떤 경우에는 사내 API 포털을 구축할 때도 사용되기도 했습니다. 일부 API가 장애가 나면, 캐싱과 폴백(Fall-back) 등을 지원함으로서 각 서비스간 소통에 도움이 되기 때문인데요.
하지만, API 게이트웨이 자체가 장애가 나면 전체에 타격을 주는 경우가 생깁니다. 넷플릭스는 내부 서비스의 경우, API 게이트웨이 방식 보다는 각 서비스들이 직접 API 통신을 하도록 하는 방식으로 구현했습니다. 이를 외부에 오픈 소스로도 공유했는데, 외부용 API 게이트웨이는 Zuul을 사용하고, 내부 API는 Eureka (타 API 서비스 레지스트리)와 결합한 Ribbon (클라언트 기반 로드밸런싱 – 타 API 서비스 디스커버리 및 분배)과 Hystrix (서킷브레이커 – 타 API 장애시 대처) 같은 도구를 통해 각 서비스 API가 Gateway의 역할을 자체적으로 수행하는 것입니다.
이러한 모범 사례를 계승한 것이 바로 서비스 메쉬(Service Mesh)라는 개념으로 쉽게 말해 마이크로 서비스 간의 API 통신만을 담당하는 요소입니다. 각 서비스에서 API 통신은 필수 부분이 되었기 때문에 아예 통신 부분만을 비즈니스 로직과 따로 분리해서 각 서비스 API간 라우팅 설정, 로드 밸런싱, 장애 복구, 보안 및 모니터링할 수 있습니다. 원래 Lyft에 만들어진 오픈 소스인 Envoy는 사이드카(Side-car) 방식의 프록시 서버로 또다른 오픈 소스인 Istio와 결합하면 “서비스 메쉬”를 구현할 수 있습니다.
Envoy와 Istio를 함께 사용하면 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 자동 로드 밸런싱, 상세한 라우팅 규칙 구성, 장애 복구 및 주입 실험 등 현대적인 아키텍처 구성이 가능합니다. 또한, 서비스 간 접근 제어, 트래픽 제어, 모니터링 및 로그 추적을 통해 트래픽 동작을 세밀하게 제어합니다. 클라우드 서비스인 AWS에서도 AppMesh라는 서비스를 제공하고 있기도 합니다. 
■ 과연 둘다 필요한가요?
API 게이트웨이의 주요 목적은 외부의 트래픽을 받아 처리하는 방식으로 역할을 담당하고, 서비스 메쉬는 내부 API 트래픽을 라우팅하고 관리하는 방식으로 분담하는 추세입니다. 이 두 가지를 조합하는 것이 효과적인 마이크로서비스 구현 방식입니다. 흥미로운 점은 서비스 메시 기술이 빠르게 발전하고 있으며 API 게이트웨이의 일부 기능을 수행하기 시작했다는 것입니다.
예를 들어, 초기 Istio는 Kubernetes 기반 수신 제어를 사용했는데, 2018년부터 v1alpha3 API에 의해 도입하면서 외부의 트래픽 수용도 더 쉽게 되었습니다. 엔터프라이즈 서비스 메쉬 제품인 Aspen Mesh 1.0에서 Istio v1alpha3 라우팅 API을 도입하기도 했습니다. 현재 대다수 기업들이 Docker 및 Kubernetes를 사용하여 마이크로서비스 아키텍처를 구현하는 추세이기 때문에 API 게이트웨와 서비스 메쉬 기능이 아예 병합 될 가능성이 높습니다. 그동안 독립형 API 게이트웨이에 대한 제품 수요와 기업들의 활용도가 낮아지는 것도 이런 이유입니다.
마이크로서비스 아키텍처로 인해 API를 바라보는 방식과 구현하는 방식도 꽤 많이 변화하였습니다. 다만, 이러한 변화는 API 서비스 구현에 있어 민첩성, 유연성과 API 소비자의 변화에 따른 비즈니스 요구에 따른 것입니다. 만약, 이 글을 읽고 새로운 트렌드를 그냥 막 따라할게 아니라 현재 여러분의 서비스의 단계가 어느 정도인지 파악하고, 적당한 솔루션을 선택하는 것을 추천드립니다. ‘뱁새가 황새 따라가다 가랑이가 찢어진다’라는 속담이 있죠. 몸에 맞지 않는 아키텍처를 섣불리 도입하기 보다 현재 상황에 맞게 선택하는 것이 가장 중요합니다.
다음 글에서는 국내 API 활용 현황을 외부에 API를 제공하고 있는 기업과 마이크로서 서비스 아키텍처를 도입한 기업들, 그리고 금융 기관 및 정부 기관의 현황 등을 살펴보겠습니다. 
연재 순서 
API 이코노미를 살펴보다 (1) 최근 API 기술 및 사업화 동향
API 이코노미를 살펴보다 (2) 마이크로서비스 시대의 API
API 이코노미를 살펴보다 (3) 국내 API 활용 현황 및 제언

API 이코노미를 살펴보다 (2) 마이크로서비스 시대 API

댓글