Computation suite

최근 .csv, .tsv 등의 형태로 전송되는 로깅 파일을 저장하기 위한 시스템을 구축했다. 프로젝트를 진행하면서 사용한 기술에 대한 회고를 정리했다. (프레임워크에 종속되는 특성보다는 처리 로직에 초점을 맞추었다.) Before deploying Celery 테스트 서버에서 로깅 파일 처리 부하로 인해 서비스들이 멈추기 전까지는 메시지 큐를 활용하여 처리할 필요성을 느끼지 못했다. 그야 동시 요청 수도 없다시피하고 이상적인 환경이니까 그렇다. 이런 환경에서는 웹 애플리케이션 서버가 요청 검증, 파일 파싱, 데이터 전처리, DB I/O 모두 처리할 수 있다. 이 경우에는 파일로 만들어 저장하지 않고 Request 객체로 받은 binary를 파싱했다. 그러나 동시 요청수가 굉장히 많고 언제 Peak request를 찍을 지 알 수 없는 환경에서 안정적인 아키텍쳐는 아니다. 부하 발생 - 모니터링 툴 Locust를 사용하여 측정했을 때, 500명 동시 접속 환경까지 증가시키며 1초에 1번 계속해서 리퀘스트를 보냈을 때 WAS Worker가 2개인 환경에서 금방 리소스가 바닥나서 실패 응답을 받기 시작했다. 지연 응답이 아닌 실패 응답이 나타나기 시작하면 아키텍쳐든 코드든 효율성을 고려하여 수정해야한다. After deploying Celery 실시간에 가깝게 로그 파일을 처리하지 않고, 조금의 지연이 생기더라도 로그 파일을 제대로 처리한다는 보장이 있으면 파일 저장/파일 처리 로직을 담당하는 프로세스로 나누어서 각 프로세스의 작업의 무게를 줄일 수 있다. 이렇게 구성한다면 요청 인증/파일 저장/파일 처리 로직을 전부 맡아서 하던 WAS는 요청 인증/파일 저장까지만 하고 그 뒤의 일은 Background worker에게 맡긴다. 이렇게 한다면 메모리 누수와 같은 결함으로 시스템 전체의 자원이 동나지 않는 이상 WAS의 파일 처리량을 늘릴 수 있다. 그렇다면 Backgorund worker는 어떻게 자신이 처리해야 할 일을 알 수 있을까? 이 use-case에서는 자...

AWS에서 배치 프로세싱을 구현하는 방법은 batch를 이용하는 방법 lambda를 이용하는 방법 이 있다. Batch를 이용하는 방법 AWS Batch -> AWS EC2 Instance를 의미한다. 이 방법은 ec2를 사용하기 때문에 완전한 Serverless는 아니다. AWS Batch가 Batch 작업을 돌리기 위해 EC2 인스턴스를 Spin up 한다. * live 상태로 만듬을 뜻함 문제는 배치 작업을 하지 않을 때에도 EC2의 최소 공간을 live 상태로 유지해야한다. 이는 배치 작업을 하지 않을 때에도 돈이 나간다는 것을 의미하고 때문에 다음의 방법이 보다 효율적이다. Lambda를 이용하는 방법 Cloudwatch( -> EventBridge )가 스케줄링 엔진으로서 작동한다. AWS Lambda를 Trigger한다. ( cron trigger ) 1. AWS EventBridge console pannel에서 스케줄링 엔진 rule을 추가한다. 2. lambda function을 구현한다. 견고한 배치 작업을 만드는 방법 testing worker chain - 어떤 에러가 발생하는지 - worker chain이 끝까지 도달하는지 - edge 케이스 테스팅을 통해   끝나지 않는 무한 루프를 도는 runaway worker chain,   시작되지 않는 worker chain 방지한다.    무한 루프를 돌 경우 높은 aws bill이 나올 수 있음. retry attempt 조정 asynchronous invocation에서 retry attempt를 0으로 세팅하기. 기본값은 2이다. -> batch lambda가 fail 하더라도 2번 더 실행됨. -> 같은 유저에게 메일이 3번 갈 수도 있음. unprocessed items 처리 가장 요청이 많이 들어오는, 바쁜 production환경에서도 성공적으로 배치 작업이 수행할 수 있게 concurent worker chains 튜닝

제가 지원한 직군의 면접을 위해 참고했던 JD를 정리합니다. 자세한 기업명은 밝힐 수 없습니다. 동영상 컨텐츠 기업 A 서비스 - django/drf : 웹 애플리케이션  - elk + filebeat : 로그 수집/ 분석 / 시각화     [ elk ]    1. elastic search : 검색 엔진    2. logstash : 수집 및 가공    3. kibana : 데이터 시각화 대시보드    [ filebeat ]    4. filebeat : 로그 데이터 전달/중앙화 하기 위한 경량 Producer       - ffmpeg : 영상 인코딩 CI/CD - Github action Tool - drf-spectacular : API 문서 자동화 - black/isort : 코드 스타일링/ 포매터 Test - Postman(기능 테스트) DB - AWS RDS 인프라 - AWS EC2 - Route53 - docker/docker-compose 모니터링 - sentry : application 퍼포먼스 / error 트래킹 - datadog : saas 데이터 분석 플랫폼 외부 Solution - drm solution - vpn solution 관제 소프트웨어 기업 A 서비스 - FastAPI : 웹 애플리케이션 서버 - Typescript : FE Server - Node.js : FE Server - gstreamer/ffmpeg : 영상 인코딩 - Apache Airflow : 데이터 파이프라인 워크플로 DB - AWS RDS - MongoDB 인프라 - AWS EC2 - AWS S3

제가 지원한 직군의 면접을 위해 참고했던 JD를 정리합니다. 자세한 기업명은 밝힐 수 없습니다. 커머스 기업 A 서비스 - django / drf : 웹 애플리케이션 서버 - graphql : 상품 fetch 백오피스 - jupyter : business inteligence를 위한 데이터 시각화 인프라 - docker - k8s 지급 결제 대행 - 고객사 <-> PG API <-> VAN 사  메디 테크 / 디지털 헬스 케어 A 서비스 - Fast API : 웹 애플리케이션 서버 인프라 - AWS EKS(k8s) DB - RDBMS / NoSQL 혼합 에듀 테크 A 서비스 - django/ drf : 웹 애플리케이션 서버 문서화 - drf-yasg / drf-spectacular DB - postgres - mysql 인프라 - docker - aws - redis

배치 처리 배치 처리 프로그램 특징 - 사용자와 상호작용하지 않음 - 대량의 data를 처리하며 - 일련의 작업 묶음으로 이뤄져있다. 배치 프로그램의 주기 - 정기적으로 작업을 수행하거나 - 조건을 만족하는 이벤트가 발생 할 때 실행 - 사용자의 요구 조건에 따라 배치를 수행하는 경우는 on-demand 배치라고한다. on-demand 배치는 일반 배치프로그램처럼 테이블 전체에 대해 수행하거나 하지는 않고 제한적인 범위에 대해 수행한다. 예를 들어, 일반 사용자의 on-demand 배치가  전체 거래량에 대해 정산을 하지는 않는다.  배치 프로그램의 튜닝 대용량 배치 프로그램 튜닝에서 중요한 것은 전체 처리 속도를 낮추는 것이다. 기업에서는 배치 프로그램을 관리하는  "배치 윈도우"라는 설계도, 문서가 있는데 이는 배치 프로그램들의 튜닝과 플랜을 짜는데 도움이 된다. 일반적으로 배치 프로그램은 dbms 상에서 수행되는 일련의 sql 작업들로 구성되며 이 sql문의 튜닝이 전체 처리 속도에 큰 영향을 미친다. 배치 프로그램 구조 이 sql 작업들은 - one sql  = 하나의 sql문으로 전체 프로세스를 짜는 것 - 각 언어 구현체의 데이터베이스 커서를 사용하여 루프를 돌면서 실행한다. - one sql보다 성능적으로 권장되는 방법은 one sql을 여러 sql 집합으로 쪼개서 단계적으로 실행하는 것이다. commit시점이나 횟수가 완전 동일한 로직이라는 가정하에  one sql이 curosr loop보다 더 간편하고 관리하기가 용이하다고 생각한다. 배치 관리 프로그램 - .sh - .py - sql (1단계)                                    - .sh - .py - sql (2단계)    ...

 SPA란? Single page application. 과거의 웹에서는, 서버에서 클라이언트(사용자 입장에서는 웹 브라우저 프로그램)로 전달하는 데이터 양이 크지 않았다. 현재는 그 데이터양이 훨씬 크다. 보여주는 데이터양이 크지만, 매번 Page를 Refresh하고 로딩하는 것은 비효율적이다. 그렇기에 전체 Page내에서 제공되어야할 내용을 하나의 Page에서 바뀌어야할 데이터 부분만 동적으로 바꿔주는 로직을 반영한 구조가 SPA이다.  말 그대로 Single page에서 application이 운영된다. 예 최초의 Page가 로딩 될 때, 미리 로딩된 Javascript 코드가  사용자가 일으키는 Trigger, Event를 감지하여 바뀌어야 할 컴포넌트만 바꿔주는 것이 그 예라고 볼 수 있다. 유명한 SPA Framework Angular, React, Vue가 있다.   세 프레임워크의 구현은 다르나, 목적은 확장성있는 SPA의 구현에 있다. 세 프레임워크 모두 Virtual DOM 개념을 사용한다. SPA의 단점과 VirtualDOM SPA의 단점은 동적으로 로딩하는 코드가 많을 경우 자바스크립트의 DOM 조작이 빈번하게 일어나 브라우저의 성능 저하. -> 변경된 코드를 다시 브라우저가 렌더링하는 과정에서 발생하는 것으로 추정 Virtual DOM을 사용하는 프레임워크들은 실제 DOM 트리를 흉내 낸 가상의 객체 트리로 html 정보를 저장하고 있다가, 이 트리에 변경이 발생하면 모든 변화를 모아 단 한번 브라우저를 호출해 화면을 갱신하는 방법을 사용한다.  이렇게 하면 브라우저와의 불필요한 상호작용을 최소화하면서 인터렉티브한 웹 사이트를 만드는 것이 가능하다. Q. 트리에 변경이 발생하면 변화 내역을 모아서 한번에 브라우저를 호출하면서 갱신하다는데, 한번에 모아서 호출한다면, 실시간으로 Interaction이 안되지 않을까? 변화는 이미 생겼는데 변화를 모을 때까지 기다려야하니까.라는 의문이 생겼다....

프로비저닝 프로비저닝은 IT 인프라를 설정하는 프로세스다. 과거에는 물리적 서버의 설정, 하드웨어를 원하는 상태로 설정하는 행위가 수동으로 이뤄졌다. 최근에는 가상 인프라를 취급하는 벤더들이 많이 활성화되어 있다. AWS, GCP, Naver Cloud 등.. 이런 서비스들은 가상화, 컨테이너 기술이 발전하면서 하드웨어가 아니라 소프트웨어에 의해 정의되었기 때문에  - 프로비저닝 프로세스 속도 증가 - 프로비저닝 자동화 의 이점이 있다. 서버 프로비저닝 네트워크에서 사용될 서버를 설정하는 프로세스 - 서버 하드웨어 설치 - 소프트웨어 설치 및 설정 - 운영 체제 및 애플리케이션 포함 - 미들웨어와 네트워크 및 스토리지 연결 사용자 프로비저닝 액세스 권한과 인증 권한을 모니터링하는 Identity 관리 유형을 뜻합니다. 사용자 객체, 사용자 속성으로 특정된다. 각 사용자에게는 위와 같은 속성으로 분류되고 각각 어떤 자원에 접근할 수 있는지 정보가 부여된다. (db access, network access) EX) 사용자 프로비저닝의 예 Role-Based Access Control (권한, 롤, 그룹, 사용자) 네트워크 프로비저닝 사용자, 서버, 컨테이너, IoT 기기가 액세스할 네트워크를 설정하는 작업으로 구성된다. 유, 무선 환경 서비스 모두에 해당된다. 서비스 프로비저닝 서비스 설정 과 이와 관련된 데이터 관리 를 포함하는 프로비저닝을 뜻한다. 위와 달리 IT적인 요소보다는 비즈니스 로직에 더 가까운 프로비저닝이다. 프로비저닝 자동화와 IaC 개발자는 여전히 새로운 배포 각각에 대해 가상 인프라를 프로비저닝해야 하며, 수동 프로비저닝은 시간이 많이 소요되고 인적 오류가 발생할 확률이 크다. 각 배포에 대해 개발자가 직접 프로비저닝을 관리해야 하는 경우 변경 사항을 추적하고, 버전을 관리하며, 오류 및 비일관성을 방지하기가 어렵다. IaC는 벤더 전용 콘솔이나 커맨드창에서의 명령어 입력이 아닌 코드를 통해 인프라를 관리하고 프로비저닝한다. I...

마이크로 서비스 아키텍쳐, Microservices architecture, 이하 MSA는 모놀리식 아키텍쳐와 비교할 수 있다. 모놀리식 아키텍쳐가 서비스의 모든 기능들을 하나의 거대한 서비스 형태로 관리해왔다면, MSA는 이 거대한 서비스를 기능 및 하위서비스 단위로 나누어 관리한다. (당연하지만, 거대한 하나의 서비스를 기능 단위의 서비스로 나눌지라도 거대한 하나의 서비스와 동일한 기능을 해야한다.) MSA가 가지고 있는 장점 은 다음과 같다. 각 서비스의 개별 데이터베이스 를 가지고 동작한다.        -> 모놀리식 아키텍쳐처럼 하나의 DB에서 모든 데이터를 처리하지 않는다. 변경사항이 있는 서비스 영역에서만 개발하면 된다. 각 서비스는 개별 프로세스에서 실행되기 때문. -> 모놀리식 아키텍쳐는, 기능 서비스 한 곳에 수정사항이 생기면  모든 서버의 내용들을 다시 빌드하고 배포해야한다. -> 개발 용이, 추가 기능에 민첩하게 대응가능 확장이 용이하다. -> 모놀리식의 경우 사용자, 데이터, 트래픽이 늘어나서 물리적인 메모리 증설이     필요할 때는 수직적으로 용량을 증가시키는 방법 밖에 없다.     ( scale up : 하드웨어적으로 증설, 더 높은 사양 의 Instance로 교체 ) -> MSA의 경우     ( scale out : 비슷한성능의 머신을 여러대로 늘리는 것 )      ( 사용량이 많은 서비스만 scale out 할 수 있음 ) 기술스택의 자율성 인터페이스 만 만족하면 단위 서비스안의 기술스택은 자율적으로 선택할 수 있다. 단위 서비스는 서로 다른 언어, 데이터, 저장기술을 사용할 수 있다. 단위 서비스끼리는 http , api 와 같이 가벼운 수단을 사용해서 통신 하기 때문에 세션과 같은 상태정보를 가지지 않는다. 위와 같이 개발과 유지관리에 소요되는 시간과 비용을 줄...