니코니코 생방송 웹 프런트엔드의 쿠버네티스 마이그레이션 핸드북 2022 #

이 문서는 일본어 기술 글 “ニコニコ生放送 WebフロントエンドのKubernetes移行ハンドブック 2022“을 번역한 글입니다. 번역을 신뢰하지 마세요. 개인적으로 살펴보고 활용하기 위해 번역한 것으로 애매하거나 이해가 확실하지 않은 부분을 가볍게 넘어간 구간이 많습니다.

시작하며 #

2021년 6월 부터 2022년 3월, 9개월 간 니코니코 생방송의 프런트엔드와 관련된 마이크로서비스를 도커 스웜에서 쿠버네티스로 이전했다. 그리고 이번 기회에 이전 전 부터 이전 중, 이전 후 전체에 걸친 설계나 운영 방법을 실제 적용한 사례를 토대로 정리해 소개 하고자 한다.

배경 #

본론으로 들어가기 전에 니코니코 생방송 웹 프런트엔드 팀이 관리하고 있던 “개발부터 릴리스, 운용"까지의 과거(이전 전의) 인프라를 가볍게 소개한다.

• JS나 CSS의 정적 리소스 빌드
• 익스프레스(express.js) 기반의 웹 애플리케이션 서버 개발(Backend for Frontend)
• 도커 이미지 빌드
• 정적 리소스 디플로이
• 아파치(혹은 엔진엑스, OpenResty 등) L7 로드밸런서를 통한 트래픽 매니지먼트
• 젠킨스를 이용한 도커 스웜 클러스터 기반 Blue / Green 디플로이
• 로그 기록 및 송신
• 감시(DataDog 등)

이전에 주로 활동한 사람들 #

웹 프런트엔드 팀의 두 명 정도가 주로 이전 작업을 진행했다. 다른 마이크로서비스는 별도의 팀이 담당했으며 서로 지식과 리소스 사용 현황 등을 공유 하면서 작업을 실시했다. 배경에서 언급한 인프라의 역사적 경위나 이전 후에도 유지 돼야 하는 상태를 정리하면서 쿠버네티스로 빠르게 이전하기 위한 방법을 설계하고 실현해 나갔다.

이전 후 쿠버네티스의 대략적인 규모 #

쿠버네티스 상에서 동작하는 니코니코 생방송 프런트엔드와 관련된 마이크로서비스의 매니페스트 수는 (한 개의 클러스터 당) 다음과 같은 규모의 컴포넌트로 이뤄져 있다.

※ 대략적인 규모와 구체적인 용도를 알기 쉽도록 컴포넌트를 나열했다.

읽는 방법 #

BFF 서버를 관리하는 웹 프런트엔드의 개발자 관점을 바탕으로 쿠버네티스 상에 애플리케이션을 운영하기 위한 사례를 정리 했다. 기본적으로는 스테이트리스한 애플리케이션이며, 비기능 요건에 해당하는 부분이 이 글에서 주로 다루는 주제다. 주의할 점으로 백지 상태에서 구축한 게 아닌 전신이 되는 아키텍처 구성을 토대로 한 사례 이므로 자신 있게 베스트라고 할 수 없는 구성도 존재한다.

웹 프런트엔드 개발을 하고 있는 독자는 비기능 요건에 해당하는 부분의 운용이나 비용, 감각 등을 느껴보면서 이러한 비용을 낮추기 위해 애플리케이션 수준에서는 무엇을 할 수 있을지 생각하면 인프라를 구성할 때 도움이 될 것이다. 반대로 평소 인프라를 다루고 있는 독자라면 웹 프런트엔드의 인프라를 관리할 때에 고려해야 하는 것을 중점으로 살펴보면 참고가 될 것이다.