서버리스, 새로운 클라우드의 시작

[인터뷰] 마이클 베렌트 독일IBM 클라우드-왓슨 플랫폼 수석 엔지니어

“서버리스 컴퓨팅은 한층 더 고차원적으로 컴퓨팅을 추상화한 것이다. 베어메탈에서 돌아가던 IT가 가상머신을 통해 첫번째 추상화를 이뤄 집적도를 높였고, 몇년전부터 부상한 컨테이너로 더 높은 수준의 추상화를 달성했다. 서버리스는 컨테이너 없이도 함수만으로 작업이 가능한 가장 세밀한 수준의 관리단위 추상화를 이뤘다. 서버리스는 컨테이너 다음 세대의 논리적 기술이다.”

마이클 베렌트 독일IBM 클라우드 및 왓슨 플랫폼 개발 부문 수석 엔지니어는 최근 기자와 만나 서버리스 컴퓨팅에 대해 이같이 설명했다.

아마존웹서비스의 람다(Lambda)를 시작으로 마이크로소프트의 애저 펑션(function), 구글의 클라우드 펑션 등 퍼블릭 클라우드 업체들이 앞다퉈 서버리스 컴퓨팅 서비스를 내놓고 있다. IBM도 지난해 IBM 클라우드 펑션이란 서버리스 서비스를 내놨고, 서비스에 사용된 플랫폼인 ‘오픈위스크’를 오픈소스로 공유했다.

서버리스 컴퓨팅이란 소스코드 작동을 위한 기반 인프라를 별도로 설정하지 않고, 오로지 이벤트 발생 여부에 따라 동작하도록 하는 개념이다. 개발자는 코드 운영에 필요한 인프라 자원을 설치하고 설정할 필요가 없어진다. 소스코드를 클라우드 서비스 상에 등록하면 이벤트 발생 시에만 인프라를 사용한다.

마이클 베렌트 독일IBM 클라우드 및 왓슨 플랫폼 개발 부문 수석 엔지니어

마이클 베렌트는 “펑션을 도입함에 따른 가장 큰 차이와 변화는 더 이상 유효한 자원은 없다는 것”이라며 “코드가 있으면 되고, 시스템 요청 되면 (클라우드의) 자원이 사용된다”고 말했다.

그는 “서버리스 컴퓨팅과 펑션은 이벤트 프로세싱이나, 인모션 데이터 처리, 마이크로서비스, IoT 등에 사용되고 있다”며 “개발자는 비즈니스 로직에 더 집중할 수 있고, IBM 클라우드 펑션을 쓸 경우 성능과 비용 측면에서도 혜택을 얻을 수 있다”고 강조했다.

■ 하드웨어에 대한 고민 없애주는 서버리스 컴퓨팅

서버리스 컴퓨팅은 개발자의 하드웨어에 대한 고민을 제거한다. 더 이상 인프라 관리를 신경쓰지 않고, 소스코드에만 집중하면 된다. 기업 내 IT운영조직은 전과 다른 방식으로 일하게 된다.

마이클 베렌트는 “OS 모니터링이나 패칭, 보안패치, 자원 관리 등 인프라 관련 관리 작업을 더는 신경쓰지 않아도 된다”며 “신경써야 할 부분은 서버리스 기반으로 돌아가는 애플리케이션과 펑션을 관리하는 것”이라고 설명했다.

그는 “허용된 응답시간 내 제대로 펑션이 응답하는지 관련해 애플리케이션 모니터링을 지속해야 하고, 파이프라인을 확실히 보장하려는 노력도 해야 한다”며 “현 단계에서 서버리스란 규모가 점차 진화하는 운영환경에 적합한데, 관리 단위가 펑션으로 작아지므로 소규모 팀의 작업에 더 적합할 수 있기 때문”이라고 덧붙였다 .

그는 기존 PaaS 환경에서 오픈위스크 기반 환경으로 바꿀 경우 비용 측면에90% 이상 절감할 수 있다고 밝혔다. 내부 테스트 결과 애플리케이션 성능도 10배 빨라진다고 한다.

그는 기업 규모에 상관없이 서버리스 컴퓨팅을 활용할 수 있다고 밝혔다. 그는 “만약 기업들이 기존 인프라를 바꾸는 수고를 들이지 않고 기존 앱을 그대로 서버리스 환경으로 이전하길 바란다면 그런 기업에게 서버리스는 적합하지 않다”며 “전통적 아키텍처인 SAP 앱을 서버리스로 옮기는 건 적합하지 않지만, 많은 데이터를 처리해야 하는 경우나 이동하는 데이터나 레스트 데이터 처리를 많이 해야 한다면 서버리스에 적합한 워크로드”라고 설명했다.

그는 전통적인 애플리케이션의 코드 리팩토링을 통해 서버리스 환경으로 이전할 경우도 가치있는 일이라고 밝혔다.

그는 “앱이 20년 됐고, 이미 안정화돼 더 혁신적 기술을 도입할 여지가 없다면, 그냥 두는 게 나을 수 있다”며 “하지만, 만약에 로드가 크게 증가한다거나 확장 가능성 높은 앱이라면, 추가 피처를 빌드할 예정인 앱이라면, 시장에서 혁신 핵심이라 생각되는 부분은 충분히 리팩토링할 가치 있다”고 말했다.

그는 이어 “아니면 점차적으로 코드 변경을 하는 작업을 통해 모던한 클라우드 네이티브 한 성격으로 바꾸는 것도 좋다”며 “다만, 하룻밤 사이에 이뤄지는 작업은 아니므로, 많은 이용자들이 애플리케이션의 작은 서브셋을 서버리스로 옮기고 난 후 다른 앱은 초기 상태 그대로 두고 점차 시간가면서 바꿔가는 작업을 하는 선택한다”고 설명했다.

서버리스 컴퓨팅을 사용하게 되면 보안 측면을 간과할 수 있다는 지적이 있다. 개발자가 코드만 생각하므로, 인프라 운영의 이슈를 크게 신경쓰지 않게 된다. 이에 서버리스 컴퓨팅을 제공하는 클라우드 프로바이더가 보안과 각종 운영 이슈에 대해 더 많은 책임을 지게 되는데, 서버리스 인프라에 대한 충분한 IT 운영 역량을 갖춘 조직은 극히 제한적이다. 충분히 준비되지 않은 프로바이더에게 서버리스 컴퓨팅을 의존한다면, 그 자체가 리스크일 수 있다.

이에 대해 그는 “개인적 관점에서 리스크 증가라 보지 않고, 오히려 리스크가 줄어든다고 본다”며 “기존에 기저의 인프라와 관련된 보안은 전문성 없는 사람이 관리해야 했지만, 서버리스 환경은 클라우드제공업체가 보안과 관련해 더 광범위한 전문성을 가진 전문가로 보안 측면을 대신 관리하기 때문”이라고 밝혔다.

그는 “운영시스템이나 라이브러리의 통제를 더 원한다면 서버리스 기술 외에 추상화 수준은 덜 하지만 다른 IBM 컴퓨팅 기술을 이용하면 된다”며 “더 많은 제어력을 주는 컨테이너, 가상머신, 베어메탈 같은 기술을 쓰면 되는데, 다만 이럴 경우 보안 측면에서 기업 조직 내부에서 보안을 담당해야 해 더 약해질 수도 있다”고 덧붙였다.

서버리스 컴퓨팅은 퍼블릭 클라우드 업체에서 제공한다. 때문에 서비스 종속 우려가 기존 클라우드 모델 가운데 가장 크다. 그는 IBM에서 오픈위스크를 오픈소스로 내놓은 이유를 ‘종속 탈피’라고 강조했다.

그는 “오픈위스크 프로젝트 초기부터 명확하게 오픈소스로 진행해야 한다는 원칙이 있었다”며 “고객과 많은 언론이 클라우드업체나 서버리스업체 때문에 종속 현상 우려를 끊임없이 제기했고, 이를 해결하는 게 모든 걸 공개하는 오픈소스 접근법”이라고 말했다.

그는 “오픈소스 모델은 폐쇄적 방법보다 더 빠르게 개발할 수 있고, 더 많은 인력과 더 많은 지성을 결합해 더 빠르면서도 더 좋은 결과를 도출한다”고 강조했다.

■ IBM 컴포저, 서버시르 컴퓨팅 펑션 그룹화하는 역할

서버리스 컴퓨팅은 매우 뜨거운 신기술이지만, 자칫 모든 워크로드에서 비교우위를 갖는다는 오해를 준다. 현 기술 수준에서 서버리스 컴퓨팅의 한계점도 분명 있다.

이에 대해 그는 “많은 수의 펑션이 있을 수 있는데, 적게는 10개, 100개, 많게는 수천개까지 있을 수 있다”며 “각 펑션이 비동기식 혹은 동기식으로 상호작용할 때, 복잡한 앱을 만들 때 어떻게 앱을 더욱 일관되게 이해하는 수준으로 구축하고 개발할거냐가 문제”라고 설명했다.

그는 “이는 개발차원에서, 실제 운영 환경에서도 어려움이며, 수천개 이벤트가 생길 때 다른 펑션을 트리거할 때 어느 문제가 발생하고, 어디서 문제가 생기고, 병목이 어딘지 파악하고 식별하는데 어려워진다”며 “모니터링 차원에서도 펑션으로 구성된 로그 관리에서 성숙한 기술 수준을 갖게 노력해야 할 것”이라고 말했다.

그는 이같은 한계를 해결하기 위해 IBM에서 내놓은 ‘컴포저(composer)’ 기술을 소개했다. 컴포저는 여러 가지의 펑션을 하나의 그룹으로 묶고, 만약에 어떤 액션이 일어나면 다음 어떤 펑션이 실행되도록 하면서 순환되게 하는 기술이다.

서버리스 컴퓨팅 아키텍처의 업무 처리 흐름을 보면 실행 시 수많은 API 메시지가 발생한다. 이를 효율화하기 위한 대책이 필요하다. 구조가 복잡할수록 메시지 양이 많아지고, 병목 현상도 일어날 수 있다. 이를 위해 단일한 게이트웨이 활용이 조언된다.

그는 “API에 스웨거를 활용하고, API를 재활용하도록 스웨거 관련 인터페이스를 잘 정의, 정립해야 한다”며 “운영 차원에서 경고나 에러를 면밀히 주시하고 살펴야 하며, 상태 코드에 따라 어떻게 대처하고 응답해야 하는지 잘 따라 가야 한다”고 조언했다.

그는 “레이턴시 모니터링도 중요한데, 어느 정해진 수준 이상으로 레이턴시가 95% 이상이 나오면 대처해야 한다”며 “네트워크 레이턴시도 모니터링해서 서로 다른 API 사이의 인터페이스가 문제됐을 때 속도 저하가 코드 문제인지, 인터페이스된 다른 API 코드 때문인지 파악해야 한다”고 덧붙였다.