링크드인이 전문가 네트워크 운영에 컨테이너를 사용하는 방법

2003년 창업 당시의 링크드인은 웹 서버 하나를 사용하는 단순한 자바 애플리케이션이었다. 현재 세계 최대의 전문가 네트워크임을 내세울 정도로 성장한 링크드인은 지난 여름 마이크로소프트에 262억 달러에 인수됐다.

링크드인의 엔지니어링 이사 스티브 아이디는 "이 사이트를 성장시킨 과정은 긴 여정이었다"고 말했다. 그 과정에서 최근에는 애플리케이션 컨테이너가 큰 역할을 했다.

아이디는 지난 몇 년 동안 인프라 엔지니어링과 애플리케이션 개발 관점에서 몇 가지 중대한 "변곡점"이 있었다고 말했다. 2011년을 전후해 링크드인은 단일체(monolithic) 앱이 관리하기가 너무 복잡해지고 있음을 느끼기 시작했다. 엔지니어링 팀은 2주마다 한 번씩 새 릴리스를 내놓기 위해 노력 중이었는데, 그로 인해 업데이트와 새로운 기능의 릴리스를 관리하기가 어려워졌다.

그래서 애플리케이션을 구성하는 서비스를 분산시키고 새 코드 개발을 다시 검토하기 위한 방편으로 프로젝트 인버전(Project Inversion)을 출범했다. 아이디는 "기본적으로 릴리스 프로세스를 완전히 해체한 것"이라고 설명했다.

프로젝트 인버전에 따라 링크드인은 세분화된 마이크로서비스 기반 접근 방식을 중심축으로 돌아갔다. 앱을 구성하는 1,000여 가지의 서비스 각각이 독립적으로 관리되면서 각 소유자와 개발 팀은 준비가 되면 새로운 기능을 릴리스했다. 아이디는 "모든 것을 분산시키고 나눴다"고 강조했다.

아이디는 관리하기 쉬운 환경이 아니라는 점은 인정했다. 많은 서비스가 상호 의존 관계에 있으므로 하나가 업데이트되면 다른 쪽에도 업데이트가 필요하다. 경우에 따라 수십 개의 서비스를 동시에 업데이트해야 할 때도 있다. 아이디는 "전체적인 작업을 조율하기가 복잡해진다"고 말했다. 아이디는 상호 의존하는 서비스가 너무 많아지면 이는 서비스의 경계를 다시 정의해야 할 필요성을 나타내는 신호일 수 있다고 말했다.

컨테이너 도입
최근 몇 년은 또 다른 변곡점이었는데, 이런 변화를 이끈 것은 애플리케이션 컨테이너다.

아이디는 "하드웨어 리소스를 효율적으로 사용하지 못하고 있음을 인식하기 시작했다. 리소스 할당을 위한 시스템을 수작업으로 관리했다"고 말했다. 팀이 하드웨어 리소스(예를 들어 컴퓨팅 용량)를 요청하는 티켓을 제출하면 리소스를 받는 구조였다. 아이디는 "이 방식은 비교적 무난하게 돌아갔지만 글로벌 효율성에 맞춰 최적화되지는 않았다"고 덧붙였다.

2014년 링크드인은 신규 애플리케이션 개발을 관리하고 이러한 애플리케이션을 운영하는 데 필요한 기반 하드웨어를 자동화하기 위해 '서비스 형태의 링크드인 플랫폼(LinkedIn Platform as a Service, LPS)'이라는 프라이빗 클라우드를 출범했다. LPS를 통해 전체 인프라가 하나로 풀링되어 필요한 서비스에 자동으로 할당되는 방식이다.

LPS에는 맞춤 개발된 중요한 두 가지 구성 요소가 있다. 하나는 레인(Rain)으로, API 기반 인프라 자동화 플랫폼이다. 개발자가 코드를 작성하고 API를 통해 필요한 메모리와 CPU 용량을 요청하면 레인이 이를 구성한다. 아이디는 올해 초 블로그를 통해 "레인을 사용함으로써 애플리케이션에서 더 이상 전체 시스템을 리소스 단위로 요청할 필요 없이 특정 분량의 시스템 리소스를 요청할 수 있게 됐다"고 설명했다.

LPS의 두 번째 중요한 구성 요소는(다른 구성 요소도 많지만) 아이디가 LPS의 "지휘자"로 지칭하는 마에스트로(Maestro)다. 마에스트로는 인프라에 집중하는 레인에 비해 더 높은 수준의 자동화 플랫폼이다. 마에스트로는 애플리케이션에 새 서비스를 추가하고, 이를 다른 서비스와 함께 구성하고, 필요한 위치로 트래픽을 라우팅하고, 더 넓은 범위의 시스템에 기능을 등록하고, 새로운 서비스가 주변 환경에 잘 맞는지 확인하는 프로세스를 조율한다.

레인과 마에스트로 모두 도커(Docker) 런타임을 사용해서 애플리케이션 컨테이너로 개발 및 패키징되는 코드를 관리하도록 설계됐다. 링크드인은 가상화되지 않은 베어 메탈 환경에서 컨테이너를 사용하여 LPS를 운영한다. 따라서 하이퍼바이저, 복수의 운영 체제 인스턴스, 가상 머신이라는 오버헤드가 없다.

또한 컨테이너는 링크드인의 엔지니어링 팀이 세분화된 보안 통제를 시행할 수 있게 해준다. 아이디는 "목표는 각 서비스 관점에서 볼 때 다른 것은 아무것도 없는 빈 호스트에서 실행되고 있다는 인상을 주는 것"이라고 말했다. 그렇게 되면 버그나 해킹으로 하나의 구성 요소가 손상되더라도 사고의 '폭발 반경'이 제한된다. 여기에 애플리케이션 컨테이너가 도움이 된다. 리눅스 커널에서 컨테이너의 네임스페이스를 구성하면 컨테이너 프로세스를 동일한 호스트의 다른 컨테이너로부터 숨길 수 있다. 또한 각 컨테이너는 자체 네트워크 네임스페이스와 IP 주소를 갖는다.

퍼블릭 클라우드는 사양
링크드인이 이런 모든 작업을 퍼블릭 클라우드에서 하지 않는 이유는 무엇일까? 최근 마이크로소프트가 링크드인을 인수한 만큼 앞으로 모든 인프라 플랫폼이 애저(Azure)로 이동될까? 링크드인 관계자는 마이크로소프트의 링크드인 인수와 관련된 사안에 대해서는 아무런 언급도 할 수 없다고 말했다. 그러나 아이디는 퍼블릭 클라우드 서비스 사용에 대해 조사해본 적은 있다면서 "링크드인과 같은 방대한 규모에서는 퍼블릭 클라우드의 비용 효율성이 떨어진다. 필요한 사항은 우리가 직접 충족할 수 있다"고 말했다.

아이디는 이것이 모든 회사에 적용되는 사례는 아닐 것이라고 말했다. 링크드인은 세계 각지에 4개의 데이터센터를 운영 중이며, 3,000여 명의 엔지니어링과 운영 담당 직원을 두고 있다. 이 정도 규모에서 이런 방법으로 효율성에 맞게 최적화하고 있는 것이다.  editor@itworld.co.kr