Open Infra Days Korea 2018을 통한 인프라 흐름 읽기

안녕하세요. LINE Developer Relations 팀의 윤인성입니다. 2018년 6월 28일부터 29일까지 2일 동안 Open Infra Days Korea 행사에서 부스를 운영했습니다. 부스는 채용 부스로 운영되었으며, LINE의 인프라 팀에서 대학생부터 다른 회사에 계신 분들까지 다양하게 채용 상담을 진행했답니다. 또한 이번 LINE 부스에서는 LINE Friends 캐릭터 스티커 등도 드렸답니다. 귀여운 스티커 덕분인지 많은 분들이 참여해주셨습니다.

또한 LINE 인프라 플랫폼 팀의 이어형 님께서 “딥다이브 : immutable Kubernetes architecture”라는 주제로 LINE의 기술을 발표하셨습니다.

이번 행사를 보면 Kubernetes, Docker, Microservice, OpenStack, Immutable Infrastructure 등의 다양한 키워드가 등장했습니다. 이번 글에서는 이러한 키워드가 무엇을 의미하는지 매우 간단하게 알아보도록 하겠습니다.

마이크로서비스(Microservice)

과거에는 서비스를 하나의 거대한 집처럼 만들었습니다. 하나의 집 안에 검색 시스템도 넣고, 블로그 시스템도 넣고, 이미지 저장 시스템 등도 넣었습니다. 이러한 개발 방법론을 모놀리식 아키텍처(Monoilithic Architecture)라고 부릅니다. 이는 개발, 배포, 확장을 단순하게 만드는 장점을 가지고 있었습니다.

하지만 서비스의 규모가 점점 커지면서, 코드를 이해하고 수정하는 것이 어려워졌습니다. 또한 어떤 기능에서 문제가 발생할 경우, 그 문제가 다른 기능에까지 영향을 주었습니다. 그래서 서비스를 조금 더 작게 만드는 방법이 고안되었습니다. 이를 마이크로서비스 아키텍처(Microservice Architecture)라고 부릅니다.

하지만 서비스를 작게 만들어도 같은 서버 안에서 실행될 경우, 어떤 서비스가 프로세스 등의 자원을 많이 소비하면, 다른 서비스가 사용할 수 있는 프로세스 등의 자원이 줄어드는 문제 등이 발생했습니다.

이러한 영향을 줄이고자 “거대한 서버를 가상으로 분할하고, 이렇게 분할된 가상의 서버 내부에서 서비스를 실행하면 어떨까?”라는 의견이 나왔습니다. 이처럼 서버를 가상으로 분할하는 과정 등을 가상화(Virtualization)라고 부릅니다. 초기에는 가상화 기술이 굉장히 무거워서 적용하기 힘들었지만 KVM, XEN, Hyper-V 등의 하이퍼바이저 기반의 가상화 기술과 Docker, LXC 등의 컨테이너 기반의 가상화 기술이 발달하면서, 가상화가 널리 사용되기 시작했습니다.

클라우드 서비스(Cloud Service)

가상화 기술을 기반으로 서버를 나누고, 이를 각각의 서비스를 위해 제공하는 일이 활발하게 이루어졌습니다. 하지만 기업에서 새로 인프라 관련 직종의 사람을 고용하고, 이를 관리하기에는 비용이 많이 들었습니다. 이에 아마존, 마이크로소프트 등의 회사들은 가상화 기술을 기반으로 나눈 서버를 다양한 용도로 제공해주는 클라우드 서비스(Cloud Service)를 시작했습니다(아마존 AWS, 마이크로소프트 Azure 등). 클라우드 서비스는 굉장히 큰 성공을 거두었습니다.

이처럼 초기의 아마존 AWS와 마이크로소프트 Azure처럼 인터넷으로 접속해서 사용하는 클라우드 서비스를 퍼블릭 클라우드(Public Cloud)라고 불렀습니다.



지금의 AWS는 프라이빗 클라우드 서비스도 제공합니다.

하지만 보안적으로 중요한 정보를 위탁하는 것이 위험하다고 생각하는 기업도 있었고, 인프라를 최대한 기업 내부에서 전용선으로 운용하려는 경우도 있었습니다. 이에 클라우드 서비스를 개별적으로 구축할 수 있게 해주는 오픈소스인 OpenStack이 등장했습니다. OpenStack을 사용하면 클라우드 서비스를 사내에 구축할 수 있습니다. 이처럼 인터넷을 통하지 않고, 사내의 전용선 등을 통해 연결해서 사용하는 클라우드 서비스를 프라이빗 클라우드(Private Cloud)라고 부릅니다.

퍼블릭 클라우드와 프라이빗 클라우드의 등장으로 가상화를 쉽게 할 수 있게 되자, 마이크로 서비스를 쉽게 만들고, 확장(Scale-out)하고, 축소(Scale-in)하고, 제거하는 일도 가능해졌습니다.

클라우드 서비스를 사용하면서, 기본적인 개발과 운영의 문턱이 굉장히 낮아졌습니다. 원래 어떤 일이 너무 힘들면, 그 일에 밖에 집중할 수 없지만, 조금 쉬워지면 주변을 둘러볼 수 있게 됩니다. 이에 개발(Development)과 운영(Operation)을 비롯한 QA(Quality Assurance)의 협업을 강조하는 DevOps 개발 환경과 문화도 함께 발전했습니다.

코드로서의 인프라(Infrastructure as Code)

일반적으로 서비스가 커지면 추가적으로 (1) 서버 구입, (2) 서버 설치, (3) 운영체제 설치, (4) 미들웨어 설치(필요한 프로그램 설치), (5) 애플리케이션 설치라는 과정을 계속 반복합니다. 하지만 이러한 과정이 그렇게 쉬운 일이 아닙니다. 서버 구입과 설치까지 몇 달이 소모되기도 하고, 운영체제와 미들웨어를 설치하면서도 매뉴얼이 완벽하게 쓰여 있지 않으면 조금씩 다른 환경이 만들어지기도 합니다(매뉴얼이 완벽해도 사람이 실수를 하는 경우도 있습니다).

(1) 서버 구입, (2) 서버 설치는 가상화를 통해 해결되었습니다. 버튼 몇 번을 누르면 10분 내로 서버를 받고, 서비스를 확장할 수 있게 되었습니다. 그럼 그러한 서버 위에 (3) 운영체제 설치, (4) 미들웨어 설치, (5) 애플리케이션 설치는 어떻게 자동화할까요?

이때 등장한 방법이 바로 Infrastructure as Code(IaC)입니다. 운영체제 설치부터 애플리케이션 설치까지의 과정을 코드로 적어 두고, 이를 자동으로 실행되게 하는 것을 Infrastructure as Code라고 부릅니다. Infrastructure as Code는 설정을 자동화한 것이라고 생각하면 쉽습니다. 사람이 할 때보다 실수가 적고, 매뉴얼을 안 적을 일도 없으므로 서비스의 파편화를 막을 수 있었습니다.

참고적으로 하늘에서 내리는 눈송이는 모든 눈송이가 그 모양이 다르다고 합니다. 이처럼 파편화가 일어나서 조금씩 차이가 발생한 서버를 스노우 플레이크 서버(Snowflake Server)라고 부릅니다. 스노우 플레이크 서버 문제를 어느 정도 해결하게 된 것입니다.

오케스트레이션(Orchestration)

이러한 Infrastructure as Code를 도와주는 도구가 바로 Chef, Puppet, Ansible, SaltStack 등의 “설정과 관련된 오케스트레이션 도구”입니다. 이처럼 여러 서버를 운영할 때 여러 서버들을 관리하는 것을 오케스트레이션(Orchestration)이라고 부릅니다. 말이 조금 어렵지만 “수많은 바이올린, 첼로, 베이스, 비올라 등의 현악기들과 관악기와 타악기들이 어울려 음악을 만드는 오케스트라”처럼, 수많은 서버들을 관리해서 어울리게 만들어 서비스를 제대로 운영하게 하는 과정이 “오케스트레이션”이라고 생각하면 됩니다.






다양한 설정 관련 오케스트레이션 도구

인프라는 굉장히 큰 것이므로 관리해야 하는 대상이 꽤 많습니다. 설정 관리 이외에도 CI/CD를 관리할 때는 Travis CI, Jenkins, Circle CI 등의 오케스트레이션 도구를 활용하며, 컨테이너를 관리할 때는 Docker swarm, Kubernetes 등의 오케스트레이션 도구를 사용합니다.

여러 도구들이 엮이면서 굉장히 쉽고 편리하게 인프라를 관리할 수 있게 되었습니다. 지금까지 설명한 도구들을 조합하는 수많은 방법론이 등장하기 시작했습니다.

Immutable Infrastructure

대표적인 방법론을 몇 가지 추가로 살펴보겠습니다. 여러 가상화된 서버를 사용하고 있을 때, 미들웨어를 업데이트해야 한다고 해봅시다. 어떻게 해야 할까요? 100대의 서버를 사용하고 있다면 일단 10대 정도의 서버에서 미들웨어 패치를 추가로 설치합니다. 문제가 없다면 조금씩 이를 늘려 나가면서 100대의 서버를 모두 업데이트합니다.

큰 문제가 없어 보이는 방법이고, 많이 사용되는 방법입니다. 하지만 만약 “업데이트된 미들웨어의 특정 기능의 변경을 예측하지 못해서 문제가 발생해서 되돌려야 한다”라는 상황이 발생했다고 합시다.

레고를 조립하는 방법은 레고를 구매할 때 들어 있는 매뉴얼에 적혀 있지만, 레고를 분해하는 방법은 매뉴얼이 없습니다. 마구잡이로 분해하는 수 밖에 없습니다. 이것이 바로 Infrastructure as Code의 문제로 지적되는 “롤백(rollback)이 힘들다”입니다. 롤백을 수동으로 해주면, 다시 스노우 플레이크 서버 문제가 발생합니다.

어떤 서버에 패치를 직접 설치하고, 이를 제거할 때 문제가 발생한다면, 이러한 과정을 없애면 어떨까요? “변경을 가할 수 있는 서버”를 Mutable Infrastructure라고 부른다고 할 때, 이와 반대되는 “변경을 가하지 않는 서버”를 사용하면 어떨까요? 이것이 바로 Immutable Infrastructure의 개념입니다.

피닉스 서버

Immutable Infrastructure는 과거부터 있던 방법론이지만 이를 구현하는 것이 굉장히 힘들었습니다. 패치가 모두 완료된 서버를 이미지 형태로 만들어 두고, 기존의 서버를 제거한 뒤에, 다시 생성하는 과정은 굉장히 복잡하기 때문입니다. 참고적으로 이처럼 기존의 서버를 제거하고, 다시 생성하는 것의 반복이 마치 불사조가 소멸했다가 부활하는 모습 같다고 해서 피닉스 서버(Phoenix Server)라고 부릅니다.

이번에 LINE 인프라 팀에서는 LinuxKit과 Kubernetes를 활용해 이러한 Immutable Infrastructure를 구현해보았답니다. 관련된 내용은 추후에 올라오는 이어형 님의 발표와 글을 참고해주세요.

※ Kubernetes를 짧게 k8s라고 부르기도 합니다. 이후에 인프라 관련 글을 보실 때 헷갈릴 수 있어서 추가 언급합니다.

Related Post