안녕하세요. HBase 팀 김영주, 김동의입니다. HBase 팀에서는 LY의 많은 서비스를 지원하기 위해 수천 대 규모의 HBase를 운영하고 있습니다. HBase는 Hadoop 기반 칼럼형 분산 데이터베이스로 확장이 용이해 대용량 데이터를 다룰 때 많이 사용하는데요. 회사가 성장하면서 많은 서비스에서 HBase를 사용하고자 하는 니즈가 생겼고, 이를 지원하기 위해 저희 팀에서 전문적으로 HBase를 운영하고 있습니다.HBase 도입 초기에는 Cloudera사의 Cloudera's Distribution for Hadoop(이하 CDH)을 솔루션으로 사용했습니다. CDH가 Hadoop 관련 운영 도구 중 주류였고 커뮤니티를 중심으로 많은 자료를 이용할 수 있었기 때문입니다.하지만 현재 이 솔루션을 탈피하기 위한 작업을 진행하고 있습니다. 몇 가지 이유가 있는데요. 첫 번째 이유는 라이선스 비용입니다. 초기에는 라이선스 비용이 크지 않았지만 서비스가 늘어나고 노드 수가 많아지면서 라이선스 비용이 점점 증가해 무시할 수 없는 수준이 되었습니다. 두 번째 이유는, 상용 배포판의 매니저와 에이전트가 프로세스를 관리하기 때문에 사내 프라이빗 클라우드 플랫폼인 Verda에서 제공하기가 어려울 것이라고 판단했기 때문입니다. 세 번째 이유는 상용 배포판을 계속 사용하면 Cloudera사의 기술 지원에 의존할 수밖에 없어서 팀의 기술력 향상 측면에서 부정적이라고 판단했기 때문입니다.이와 같은 이유로 HBase 팀에서는 CDH로 운영하고 있는 HBase 클러스터를 모두 오픈소스 HBase(이하 Apache HBase)로 이관하기로 결정하고, 내부적으로 HitBase라고 이름을 지었습니다. 또한 이관하기 위해서, Cloudera사의 클러스터 관리 도구인 Cloudera Manager(이하 CM)을 대체할 수 있는 HitBase Handler(이하 HBH)라는 관리용 도구를 만들기로 결정한 뒤 개발에 돌입해 2023년에 HBH v1 버전을 릴리스했습니다.개발 완료 후 실제 운영 중인 서비스를 순차적으로 HitBase로 이관했고, 현재 약 50%의 HBase가 HitBase로 운영되고 있습니다. 이번 글에서는 저희가 2023년 한 해 동안 HBH를 어떻게 개발했는지 공유하려고 합니다.팀 내에서 개발에 투자할 수 있는 시간과 인력을 고려했을 때 처음부터 CM에 포함된 모든 기능을 HBH에서 지원하도록 만드는 것은 어려울 것이라고 판단했습니다. 요구 사항을 분석하며 논의한 결과, 우선 필요한 기능부터 넣은 뒤 CM에서 제공하는 기본 기능을 구현했고, 그 외 그동안 운영하면서 필요하다고 판단했던 리전 복구 및 백업과 실시간 인스펙터 기능을 추가했습니다. 아래는 HBH와 CM의 기능을 비교한 표입니다.HBH 개발 과정은 다음과 같습니다. 각 과정을 하나씩 살펴보겠습니다.Apache HBase로 전환하기 위해서는 무엇보다도 문제없이 작동하는 HBase 바이너리 파일이 필요합니다. 이때 Hadoop 호환성 이슈를 피하려면 안정적이고 검증된 버전을 사용할 필요가 있는데요.

안녕하세요. 저는 아테나스랩에서 서버 챕터 리드를 맡고 있는 Leo입니다. 저희 서버챕터는 Python Django 프레임워크를 사용하여 140만 명이 사용하는 학교생활 필수 앱 오늘학교와 학원정보를 제공하는 오늘학교 아카데미 웹 서비스에 대한 백엔드 개발과 유지보수를 하고 있습니다.시장에 빠르게 제품을 선보이고 검증해야 하는 여러 스타트업의 상황이 동일하듯이 개발을 하다 보면 생산성과 안정성 사이 Trade-Off가 발생하는 상황을 자주 마주치게 됩니다.이 글을 통해 그러한 상황에서 저희들이 어떤 결정을 내렸는지, 그 과정에서 어떤 시행착오들이 있었고 어떻게 해결했는지, 또 앞으로의 방향성은 무엇인지에 대해 이야기 해보려 합니다.초기 제품 런칭 이후 서비스가 성장하면서 팀원들이 늘어나고 아키텍처 구조 변경에 대한 고민을 시작하는 분들께 이 글이 도움이 되었으면 좋겠습니다.어떤 문제가 있었나요?Django에서 제공하는 어드민, 보안, 템플릿 등의 빌트인 기능은 개발자가 신경 써야 하는 것들을 줄여 높은 생산성을 가질 수 있게 해주는 장점이 있습니다. 저희 팀은 그런 Django의 장점을 적극 사용하며 MTV(Model-Template-View) 패턴을 바탕으로 초기 애플리케이션 구조를 만들어 사용하고 있었습니다. 하지만 점점 팀의 규모가 커지고 서버 챕터의 개발자가 충원되는 과정에서 저희 서버 챕터는 아래의 문제에 직면하게 되었고, 높은 생산성이 장점이었던 Django는 오히려 개발 속도를 지연시키고 성능의 문제를 발생시키게 됩니다.[문제점]기능 개선 및 추가가 진행됨에 따라 Controller 역할을 하는 View단의 로직들이 절차지향적으로 늘어남으로써 View 클래스 하나가 스크롤을 해야 확인될 정도로 코드가 길어짐모듈별 역할이 정립되어 있지 않아 View, Model, ModelSerializer, ModelForm 등 서로 다른 위치에 비즈니스 로직을 구현함으로써 코드가 중복되고, 이에 대한 유지 보수가 어려워짐코드 컨벤션의 부재, 개발자마다 다른 코딩 스타일 차이로 인해 코드를 작성한 개발자만이 유지 보수가 가능해짐아테나스랩 서버챕터는 모두 주니어 개발자로 구성되어 있었고, 여전히 빠르게 제품 개발에 몰두하여 결과물들을 만들어내야만 하는 상황이었습니다. 이런 상황에서 저희에게 필요한 아키텍처는 확장성이 높고, 유지보수가 편리하며, 러닝커브가 높지 않은, 그리고 무엇보다도 생산성이 뛰어나야 했습니다. 이를 바탕으로 저희는 아키텍처 개선의 방향성을 아래와 같이 설정했습니다.[개선 방향성]적절한 아키텍처와 디자인 패턴을 도입하고 모듈별 역할을 정의하여 코드 일관성을 유지한다.혼재되어 있는 비즈니스 로직들을 통합하여 코드가 어떤 역할을 하는지 쉽게 파악하도록 한다.Django가 제공하는 생산성을 해치지 않는 측면에서 빌트인 기능 사용을 줄여 추후 높은 성능을 가진 경량화된 프레임 워크로의 전환을 용이하게 한다.여러가지 검증된 아키텍처와 설계방식이 존재하였지만 개발자가 적은 팀의 상황에서 만약 MSA(Micro Service Archit

1. 개요MSA로 개발하면서 템플릿 기반으로 작은 서비스를 많이 만들게 됐습니다.이 때 템플릿을 잘 만들어두면, 개발 효율이 올라가고 동료 개발자도 금방 프로젝트에 합류 가능합니다.이런 템플릿을 만드는 툴로 create-react-app , django-admin 이 있습니다.여기서 더 나아가 본인 조직만의 템플릿을 만들고 싶을 때, cookiecutter를 배우면 좋습니다 😃이번 포스팅에서는 cookiecutter로 Django 템플릿을 만들고 웹으로 배포하는 내용을 다뤄보겠습니다.cookiecutter 활용 예시: tiangolo의 FastAPI cookiecutter 프로젝트2. 결과물 미리보기 (소스코드 Repo)폼을 채우고 생성하기 버튼을 누르면, 장고 템플릿을 zip파일로 다운받을 수 있습니다.3. cookiecutter 프로젝트 만들기cookiecutter Hello world 예시cookiecutter 한국어 설명 블로그cookiecutter 공식문서cookiecutter 사용법에 대해서는 여러 포스팅이 작성되어 있습니다. 먼저 참고해보세요~이 프로젝트에서 cookiecutter 소스는 devocean-cookiecutter/web/maker/django-template 폴더에 있습니다.cookiecutter.json 에서 변수를 설정해주고 이 변수를 템플릿 내에서 {{cookiecutter.some\_variable}} 형식으로 이용합니다.템플릿 내에 { } 같은 문법을 이미 사용중인 경우 시작과 끝에 {% raw %} {% endraw %} 를 넣으면 됩니다.ex). web/templates/web/base.html4. CLI 대신 Web GUI, 압축 파일로 템플릿 배포하기cookiecutter 프로젝트를 만들었으면 이제 사용자 편의성을 늘릴 차례입니다.사용자 입장에서는 cookiecutter를 설치안해도 템플릿을 만들 수 있으면 좋습니다. 그래서 cookiecutter CLI대신 웹으로 배포해보려고 합니다.전체 코드는 devocean-cookiecutter repo 를 참고해보세요~4-1. make_template 함수 만들기make_template 함수는 cookiecutter API를 이용해 입력값을 바탕으로 템플릿을 만듭니다. 그리고 이를 압축파일로 만듭니다.import os import shutil from cookiecutter . main import cookiecutter BASE_PATH = os . path . dirname ( __file__ ) OUTPUT_DIR = os . path . join ( BASE_PATH , 'output' ) def make_template ( context , path ) : template = os . path . join ( BASE_PATH , path ) result = cookiecutter ( template , no_input = True , output_dir = OUTPUT_DIR , extra_context = context ) filename

개요이번 포스팅에서는 현대 앱 개발에 쓰이는 주요 아키텍쳐를 설명해보고자 합니다.저희 팀에서 올해부터 FastAPI, React 스택으로 평가 모니터링 시스템을 맡게 되었는데요.관련 입문 서적은 많지만, 전반적인 아키텍쳐를 설명해주는 자료는 없어서 직접 정리해봤습니다.아래 키워드 목록 봐보시고, 궁금하다 싶으면 읽어주세요~#Backend #Frontend #Model # View #Controller #MVC #Flux #Redux #Microservices #MSAService하나의 서비스는 백엔드 / 프론트엔드로 나눌 수 있습니다.예시: 날씨 정보를 제공해주는 서비스날씨 서비스를 만든다고 합시다. 이 서비스는 UI와 날씨 데이터, DB로 구성되어 있습니다.화면을 구성하는 UI 부분이 프론트엔드, 날씨 데이터는 백엔드가 담당합니다. 날씨 데이터를 데이터베이스에 쌓을 수 있습니다.데이터베이스는 간단히 엑셀시트를 떠올리면 됩니다. 기본적으로 테이블 형식입니다.백엔드에서는 프론트엔드에서 쓸 데이터를 만들어줍니다. 사용자 요청에 따라 DB에서 데이터를 찾고 프론트엔드에서 쓰기 쉽게 가공해 응답합니다. 주로 json 포맷으로 주고 받습니다. (Read)사용자 요청에 따라 데이터를 DB에 생성하고, 기존 데이터를 수정하거나 삭제도 가능합니다. (Create, Update, Delete)CRUD : Create Read Update Delete프론트엔드에서는 백엔드에서 받은 데이터를 가지고 화면(*UI)을 꾸며줍니다. 주로 웹 (HTML, CSS)으로 결과물을 만듭니다. 이외에도 MFC 나 QT, ATOM 등 다양한 UI를 활용해 만들 수 있습니다.UI : User InterfaceBackend백엔드에서는 주로 복잡한 로직을 처리하고, 프론트엔드에서 쓸 데이터를 관리합니다.날씨와 외출 관련된 서비스를 만들어 본다고 합시다. (외출몬 🌞☔👕 )외출몬 서비스를 예시로 들면, 백엔드에서는 아래 역할을 할 수 있습니다.1. 날씨와 의류 데이터를 이용해 날씨에 맞는 의류 추천하는 로직2. 이번 주 날씨를 바탕으로 세차 지수를 계산3. 이번주 날씨 데이터 기상청에서 파싱데이터와 관련된 작업을 하고, DB와 연결되어 CRUD 작업도 진행합니다.DB와 연결하는 방식은 SQL문을 직접 작성하거나, 각종 라이브러리에서 제공하는 ORM을 이용하면 됩니다.ORM은 프로그래밍 언어의 변수와 DB 데이터를 연결해주는 문법으로 이해할 수 있습니다.ORM : Object Relational Mapping백엔드를 구현할 수 있는 프레임워크로는 Spring Boot, Django REST Framework, FastAPI가 있습니다.Backend 구조는 MVC 패턴을 많이 이용합니다. MVC 개념을 이해하면 비슷한 패턴도 이해하기 좋습니다.Model현대 앱 개발에서는 데이터가 중심입니다. 모델은 이 데이터를 정의하는 부분입니다.엑셀 테이블을 만들 때, 첫번째 행에 열 정보를 입력하죠. Model은 축약하면 열 정보로 이해할 수 있습니다ㅎㅎ외출몬의 models.py 장고 코드를 예