삼성어카운트, 어떻게 클라우드 네이티브 전환했나

클라우드, 인공지능(AI) 등 첨단기술을 활용한 혁신 및 전 세계에 걸친 협업을 위해 많은 기업에서 클라우드 네이티브로 마이그레이션에 높은 관심을 보이고 있다. 삼성전자는 클라우드 네이티브 마이그레이션을 준비 중인 기업을 위해 내부 사례를 소개했다.

삼성전자 배주혁 데브옵스 엔지니어는 리인벤트2020 컨퍼런스에서 삼성어카운트를 클라우드 네이티브로 전환한 사례를 발표했다.

삼성어카운트는 다양한 삼성의 애플리케이션 인증을 담당하는 중앙인증서비스다. 전세계 12억개 이상의 누적 계정과 2억명의 활성 사용자를 가지고 있다.

삼성전자 배주혁 소프트웨어 엔지니어(이미지=리인벤트 2020)

삼성전자는 엔터프라이즈 자바 애플리케이션로 구축된 삼성어카운트의 전체 인프라를 클라우드 네이티브 아키텍쳐로 마이그레이션했다. 2018년 주요 서비스 중단 사고 발생 이후 안정성 확보가 중요해졌기 때문이다.

삼성어카운트는 컨테이너 이미지로 사용되는 다양한 리눅스 배포판 중 알파인 리눅스를 베이스로 사용했다. 다른 리눅스에 비해 가볍고 부팅이 빠르기 때문이다.

컨테이너 레지스트리는 기존 환경과의 연동, 보안적 측면을 고려해 AWS ECR을 선택했다. 아마존 기반 서비스인 만큼 IAM 폴리시를 통해 권한할당이 가능하고, 따로 계정을 추가할 필요 없이 IAM 계정 재활용이 가능하다.

또한 ECR의 스캔 기능을 활용해 현재 이미지에 있는 시큐리티 이슈를 확인할 수 있다. 취약점이 존재하는 패키지명과 위험 레벨까지 알려줘 현재 상황을 쉽게 파악할 수 있다.

삼성어카운트의 쿠버네티스를 위한 모든 설정은 코드화되어 관리한다. 코드화를 하는 이유는 환경구축에 필요한 시간과 업무를 최소화하기 위함이다.

쿠버네티스는 다른 런타임 환경에 사용하는 툴과 인프라가 비해 매우 많다. 모든 것을 환경마다 생성하려면 상당히 많은 시간과 노력이 필요하다. 코드화를 할 경우 재활용이 가능해 개발자가 반복 작업을 할 필요가 없다. 또한 모든 설정이 코드로 관리되고, 다른 엔지니어의 리뷰를 거쳐 실수로 인한 위험을 최소화할 수 있다.

삼성어카운트에서 쿠버네티스를 코드로 표현하는 부분은 쿠버네티스 오브젝트와 AWS인프라 두 가지로 나뉜다.

AWS인프라 부분의 코드화는 테라폼을 사용한다. 테라폼을 사용하는 이유는 다른 툴에 비해 가독성이 뛰어나고, 기존 삼성어카운트 인프라가 모두 테라폼으로 구성돼 코드 재활용이 용이했기 때문이다.

쿠버네티스 오브젝트는 헬름을 통해 코드화했다. 애플리케이션의 오브젝트가 많아지고, 배포해야 하는 환경이 늘어나면 단순 YAML 파일만으로 관리하기 힘들기 때문이다.

배주혁 엔지니어는 “인그레스나 디플로이먼트 등 오브젝트 파일을 템플릿팅해 생성한다. 이후 데브, 스테이지, 프로덕션 등 각 환경마다 변수파일을 하나씩 생성한다”며 “이 파일을 조합해 아르고를 통해 배포하면 하나의 템플릿 파일로 여러 환경에 배포할 수 있다”고 설명했다.

쿠버네티스 오브젝트에서 코드화 하기 어려운 부분이 시크릿이다. 시크릿은 베이스64로 YAML파일에 인코딩된다. 문제는 베이스64는 암호화된 값이 아니기 때문에 그대로 깃허브에 올릴 경우 크리덴셜이 노출될 수 있다.

삼성어카운트는 이를 해결하기 위해 큐브실을 도입했다. 큐브실은 비대칭 암호화 알고리즘을 사용해 공용저장소에서도 안전하게 시크릿을 저장할 수 있는 암호화 도구다.

또한 삼성어카운트는 서비스의 안정성을 최우선으로 갖추는 것이 필요하다. 그만큼 가혹한 환경에서 테스트를 진행할 필요가 있기 때문이다. 또한 수십 개의 모듈로 이뤄져 있어 변수가 생겼을 때 전체 시스템에 영향이 발생하는지도 사전에 파악해야 했다.

이를 위해 카오스 엔지니어링을 활용했다. 시스템의 신뢰성을 확인하기 위해 인위적인 혼돈을 가해 시스템의 취약한 부분을 찾고 보강하는 기법이다.

삼성전자는 카오스엔지니어링 도구로 그렘린을 선택했다. 무료버전도 파드킬, 네트워크블랙홀 등 다양한 테스트가 가능하며, 웹으로 테스트 명령을 수행해 대시보드를 지원하는 장점이 있기 때문이다.

보다 체계적인 테스트를 위해선 시나리오 작성이 필요하다. 시스템의 정상상태와 가설을 정의한 후, 그렘린에서 가설을 검증할 수 있는 테스트 파라메터를 정의한다. 파라미터값에는 영향을 미칠 포드나 노드, 실패의 종류, 시간 등이 포함된다.

파라미터 정의를 마치면 실제 카오스를 일으키고, 모니터링을 통해 시스템의 변화를 관찰하면 된다.

카오스 엔지니어링은 모니터링 시스템과의 연동이 필요하다. 시스템에 발생한 이슈가 카오스로 인한 것인지, 실제 시스템에 문제가 있는 것인지 파악이 어렵기 때문이다.

삼성어카운트는 모니터링 시스템으로 슬랙을 활용했다. 카오스 진행 상황에 따라 알림 메시지가 조직 전체에 전송돼 실시간으로 상황을 파악할 수 있다. 레이턴시 증가 등 카오스가 아닌 시스템 성능 문제가 발생했을 경우 대시보드를 통해 확인 가능하다.

삼성어카운트는 사용하는 인프라도 다양하고 툴도 여러가지기 때문에 모든 것을 코드화해야 한다. 코드화를 하더라도 배포 시 실제 클러스터와 최신 코드에 어떤 차이가 있는지 아는 것이 중요하다. 변경 사항을 명확히 알아야만 자신감 있게 새로운 오브젝트를 쿠버네티스에 적용할 수 있다.

배주혁 엔지니어는 “매쉬도입처럼 큰 아키텍쳐를 변경할 땐 점진적으로 변환하는 것이 안정성에 유리하다”며 “카오스가 더 큰 혼란을 일으키지 않도록 모니터링 시스템을 잘 연동해야 문제 원인을 잘 식별하고 빠르게 대처할 수 있다”고 말했다.