2018년 말에 처음으로 마이크로서비스 아키텍처 프로젝트에 참여하게 됐을 때는 크리스 리처드슨의 저서 『마이크로서비스 패턴』을 통해 마이크로서비스 아키텍처의 개념적인 측면을 이해할 수 있었다. 그러나 마이크로서비스를 실제로 어떻게 구현할지는 흩어져 있는 여러 자료를 찾아보고 코드를 구현해보면서 조금씩 배워나갈 수밖에 없었다.
2019년 7월 무렵, 이 책의 번역을 시작한 후 전체적인 내용을 살펴봤을 때는 뒤통수를 세게 얻어맞은 느낌이 들었다. 내가 그동안 고민해왔던 내용과 앞으로 좀 더 알아보고자 했었던 내용이 이 책에 충실히 담겨 있을 뿐 아니라, 2018년 말 즈음에 이미 출간됐었다는 사실이 인상적이었기 때문이다. 개인적으로는 '프로젝트를 시작할 즈음에 이 책의 내용을 접했으면 어땠을까.'라는 아쉬움도 남았다.
책이 출간되고 나서 한참 후에야 번역을 시작한 만큼, 최대한 빠른 시간 내에 번역을 마치고 독자들이 영어의 압박에서 벗어나 이 책을 좀 더 편하게 읽을 수 있도록 하는 것이 목표였다. 비록 출간을 앞두고 냉정히 평가했을 때 그 목표가 제대로 달성되지 못한 것 같아 아쉽지만, 이 책에서 다루는 내용이 한국어판이 출간되는 시점에도 여전히 유효하다는 점에서 위안을 얻는다.
개념이나 디자인 패턴 등과 같은 고수준에서만 본다면, 마이크로서비스 아키텍처는 기존의 서비스 지향 구조 등과 크게 달라 보이지 않는다. 그러나 마이크로서비스 아키텍처를 구현하기 위해 구체적인 기술을 자세히 살펴보면 그 차이를 체감할 수 있다. 이러한 차이를 체감하고 체득하는 데는 많은 노력이 필요하지만, 이 책을 통해 그 기반을 단단히 다질 수 있을 것이다.
이 책은 마이크로서비스 아키텍처의 기본 개념을 기존의 서비스지향 구조, ESB 등과 비교해서 잘 설명하고 있다. 나아가 개념을 실제 구현에 어떻게 적용하고 어떤 오픈소스를 사용할 수 있는지도 자세히 알려준다.
마이크로서비스 아키텍처는 어렵다. 알아야 할 기술이 너무 많기 때문이다. 이 책은 국내에서 마이크로서비스 아키텍처를 구현하는 데 사용되는 거의 모든 오픈소스를 다루며, 비록 국내에서는 생소하지만 국외에서는 잘 알려진 오픈소스도 소개한다.
이 책에서 설명하는 오픈소스의 개요만 파악해도, 추후 마이크로서비스를 실무에 적용할 때 큰 도움이 될 것이다.
책을 번역하는 과정에서 깃허브에 공개된 예제가 일부 누락된 것을 발견하고, 출판사를 통해 저자들과 소통할 기회가 있었다. 비록 저자들이 너무 바쁘고 소스 코드를 찾지 못한 탓에 완벽하게 업로드해주지는 못했지만, 보완하기 위해 최대한 노력해준 저자들의 노고에 감사한다. 소스 코드가 완전하지 않은 부분에 대해서는 저자들을 대신해 양해를 구하고 싶다. 그러나 책의 내용을 끝까지 살펴보면, 저자들이 실제 개발에 도움이 되는 소스를 제공하고자 최선을 다했다는 점을 깨닫게 될 것이다.
이 책을 모두 읽고 나면, 400페이지 남짓한 원서에 많은 내용을 담아낸 저자들의 노력뿐 아니라 남다른 안목과 식견에도 감탄하게 될 것이다. 따라서 다소 힘들더라도 이 책의 모든 내용을 끝까지 한 번은 읽어볼 것을 권한다.
현재 서비스 메시는 마이크로서비스를 기반으로 클라우드 네이티브 애플리케이션을 개발하는 가장 진보된 아키텍처다. 물론 가장 발전했다고 해서 모든 문제점을 해결해주진 못한다. 최신 기술이기 때문에 해결해야 할 난제도 많다.
그러나 개인적으로 서비스 메시를 평가하자면 클라이언트 라이브러리 기반 로드 밸런싱 기능을 C++와 Java 두 가지 언어로 개발하면서 고생한 경험과 클라우드 네트워크의 모든 문제점을 해결해줄 것으로 기대했던 SDN이 풀지 못했던 문제에 대한 해답을 어느 정도 제시한다는 점에서 다른 이들보다 다소 높은 점수를 줄 수 있겠다.
이스티오는 서비스 메시를 가장 강력하게, 가장 쿠버네티스다운 방식으로 구현한 구현체라고 할 수 있다. 2018년 오픈스택 서밋에서 처음 이스티오를 알게 됐을 때의 신선한 충격은 아직도 생생하다.
이스티오는 쿠버네티스의 일부나 확장팩으로 보더라도 전혀 어색하지 않게 자연스럽게 쿠버네티스에 통합된다. 바꿔 말하면 이스티오를 제대로 이해하고 활용하기 위해서는 쿠버네티스를 잘 알아야 한다. 당장 이스티오를 사용하기 어렵다면 쿠버네티스나 가상 네트워킹을 조금 공부해보면 큰 도움이 될 것이다.
현재 이스티오에는 과도한 트래픽으로 인한 부하 등 여러 문제가 존재하지만, 빠른 개발 속도를 볼 때 이러한 문제점은 곧 개선될 것으로 보인다. 또 이러한 문제를 해결하는 과정에서 보여줄 통찰력은 서비스 메시를 직접 적용하지 않더라도 지켜볼 가치가 있을 것이다. 따라서 향후 몇 년 동안은 이스티오와 서비스 메시가 보여주는 발전에 주목해보기를 독자들께 당부 드린다.
한 가지 팁을 드린다면 이스티오를 잘 이해하려면 VirtualService, ServiceEntry,DestinationRule, Gateway 이 네 가지 리소스가 쿠버네티스를 어떻게 확장하는지, 서비스 메시의 제어판인 컨트롤 플레인을 구성하는 믹서와 파일럿의 차이는 무엇인지에 초점을 맞추는 것이 좋다.
VirtualService, ServiceEntry, DestinationRule, Gateway 네 가지 리소스의 이름은 번역할 수도 있지만, 이스티오의 리소스 타입이라기보다는 일반적인 개념으로 받아들여질 수도 있어 따로 번역하지 않고 그대로 뒀음을 밝힌다. 그러나 대문자로 시작하지 않고 일반적인 개념으로 사용된 경우는 '게이트웨이'와 같이 우리말로 번역했다.
클라우드 환경을 구성하는 컨테이너는 사용자가 개발한 HTTP 서비스일 수도 있고 데이터 베이스 서버일 수도 있으며 NoSQL 서버나 캐시 서버일 수도 있다. 쿠버네티스는 기본적으로 이런 것들을 모두 동일하게 파드와 배포, 서비스 수준에서 표현하며 개발과 배포, 운영 역시 이러한 수준에서 이뤄진다.
쿠버네티스는 컨테이너를 기반으로 클라우드 환경에 최적화된 애플리케이션을 개발할 수 있는 훌륭한 토대를 제공하지만, 필요한 모든 것을 제공해주지는 못한다. 이에 CR을 통한 확장 가능한 구조를 제공하는데, 쿠버네티스 오퍼레이터는 이러한 확장을 자동화하는 데 사용할 수 있다. 애플리케이션별 배포 및 운영에 필요한 내용은 오퍼레이터가 자동으로 처리하므로 사용자는 하부 내용의 변화에 관계없이 쿠버네티스의 표준 리소스 관리 방식을 그대로 사용할 수 있다.
만약 쿠버네티스를 확장해 데이터베이스 서버, 캐시 서버 등 좀 더 상위 수준의 리소스를 쿠버네티스의 기본 단위로 다룰 수 있다면 어떻게 될까? 설정 및 운영이 단순해지고, 좀 더 직관적이며 고수준으로 클라우드 애플리케이션을 다룰 수 있을 것이다. 성공적인 사례로 이스티오 등의 서비스 메시 구현과 API 게이트웨이 등의 쿠버네티스 통합이 존재한다. 또한 카프카, 레디스, 각종 관계형 데이터베이스 및 NoSQL 등이 쿠버네티스 오퍼레이터를 구현하고 발전시키면서 이러한 목표를 향해 나아가고 있다.
이 책은 분량이 적고 필요한 모든 것을 다루고 있지는 못하지만, 쿠버네티스 오퍼레이터를 통해 쿠버네티스를 실제로 확장할 수 있는 좋은 시작점이 될 수 있을 것이다. 또한 오퍼레이터를 직접 구현하지 않더라도 쿠버네티스 내부를 좀 더 잘 이해하는 데도 도움이 될 것이다.
2020년 3월경, 마이크로서비스의 권한 및 정책 부분을 설계하기 위해 기술 검토를 하던 중 처음으로 OPA를 접했다. 그 전에는 OPA를 쿠버네티스 환경에서 일부 검증을 할 때 사용할 수 있는 기술이라고 단편적으로 알고 있었다. 그러나 조사할수록 쿠버네티스 환경뿐만 아니라 마이크로서비스 기반 애플리케이션의 권한이나 정책을 구현할 때에도 범용으로 사용 가능한 기술임을 확실하게 느낄 수 있었다.
OPA를 적용하면서 OPA를 자세히 다룬 책이 있는지도 찾아봤지만 책의 한 장이나 부록으로 몇 페이지 다루는 책은 있어도 필요한 내용을 충분히 다룬 책은 찾을 수 없었다. 그래서 OPA 활용에 필요한 내용을 충분히 알려주는 책을 기획하게 됐다. 항상 최신 클라우드 기술에 관련된 책들은 해외에서 먼저 출판되는 사례가 많은데 OPA는 해외에서 책이 출판되기 전에 국내에 소개하겠다는 작은 목표를 세웠다.
처음에는 마이크로서비스 환경에서 애플리케이션의 정책/권한 부분에만 집중하려고 했다. 하지만 쿠버네티스 환경에서도 널리 활용되는 기술이므로 관련 내용을 꼭 포함하면 좋겠다는 의견을 주신 분이 많아 관련 내용을 보강했다. 결과적으로 옳은 의견이었고, 의견 주신 분들께 감사드린다.
OPA를 접하고 가장 놀라웠던 점은 커뮤니티 버전과 상용 버전의 기능이 차별화되는 일반적인 오픈소스들과 달리 OPA의 핵심 코드뿐만 아니라 OPA와 함께 사용할 수 있는 좋은 도구들도 함께 오픈소스로 공개된다는 점이었다. 이뿐만 아니라 OPA를 사용하다가 해결이 잘 되지 않는 문제가 있다면 Styra사에서 운영하는 OPA 슬랙 채널에서 물어보면 친절한 답변을 얻을 수 있을 것이다. 지면을 빌어 OPA와 관련 도구들을 자유롭게 사용할 수 있도록 공개해 준 Styra사에 감사를 전하고 싶다.
마이크로서비스 아키텍처의 관점에서 OPA를 논하자면, OPA는 정책/권한이라는 중요하고 특별한 도메인을 담당하는 기술이라고 할 수 있다. 마이크로서비스 아키텍처를 구성하는 모든 도메인에서 도메인 전용 언어(DSL)를 정의한다면 혼란스럽겠지만 정책이라는 도메인은 전용의 DSL을 가질 자격이 충분할 만큼 중요한 도메인이다. 정책의 별도 분리를 통해 서비스가 비즈니스 요건에 따라 계속 정책 변경을 요구하더라도 유연한 대처가 가능하다.
또 보안의 관점에서 보면 흔히 암호화와 통신 프로토콜 등에 우선 집중하게 되지만 많은 보안 사고는 정책의 설정이 잘못돼 발생한다. 수년 전 미국 트럼프 대통령의 당선 과정에서 문제가 됐던 캠브리지 애널리티카 사건의 경우도 페이스북의 보안 프로토콜이 해킹 당한 문제가 아닌 정보의 접근 권한이 잘못 설정된 문제였다.
클라우드 네이티브의 관점에서 일단 OPA 자체가 Go 언어로 개발돼 단일 바이너리로 컴파일되는 쿠버네티스 환경에서 컨테이너로 동작하기에 효율적인 형태로 개발됐다. OPA를 Go 클라이언트 라이브러로 사용할 수도 있고, 사이드카로 파드에 컨테이너와 함께 패키징할 수도 있으며, 별도의 REST 서버로도 동작시킬 수 있다. 또 정책을 번들로 패키징해서 여러 서비스에 효율적으로 동기화할 수 있는 수단도 제공한다.
클라우드 네이티브 애플리케이션과 마이크로서비스 아키텍처는 2~3년 전만해도 복잡하기만 하고 실용적이지 않다는 의심도 많이 받았지만, 현재는 그런 단계를 지나 안정적으로 정착되고 대세가 되고 있는 것 같다. 독자들이 OPA를 계속 배우다 보면 Policy as Code 개념을 배우고 있다는 것을 깨닫게 될 것이다. 결국 마이크로서비스와 클라우드 네이티브 환경에 적합한 권한 관리는 이런 형태일 수밖에 없겠다는 느낌도 받을 것이다.
책을 쓰는 과정에서 알 수 없는 버그를 만나 OPA 소스 코드를 살펴보기도 하고, 공식 문서의 내용과 다른 부분에 혼란스럽기도 했으며 자바를 위한 간단한 웹어셈블리 SDK도 만들어 봤다. 이런 힘든 과정을 마치고 책을 출판할 수 있었던 이유는 OPA가 유용한 기술인 이유도 있지만 무엇보다 배우고 적용해 보는 과정이 재밌고 흥미로웠기 때문이다.
독자들도 이러한 흥미를 느낄 수 있을 때까지 처음의 낯섦과 지루함을 조금만 견딜 수 있다면 많은 것을 얻을 수 있을 것으로 기대한다. 그 과정에서 이 책이 도움이 되기를 바란다.
