devBlog
MSA 글 모음
기업 기술블로그의 MSA 관련 글 94개
Oozie/Sqoop에서 Airflow/Spark로: 데이터 파이프라인 전환기
대규모 데이터 인프라 환경에서 안정적이고 빠른 데이터 입수는 하위 분석 작업과 비즈니스 의사결정의 중요한 초석이라고 생각합니다. 기존 인프라에서는 1,200여 개의 데이터 파이프라인이 Oozie XML을 통해 관리되고, 데이터 입수 도구로 Sqoop…
이노크라스의 AWS HealthOmics 기반 임상 유전체 파이프라인 운영 효율화 방안
서론 정밀의료 시대에 바이오마커 기반 표적치료는 암 치료의 핵심 전략으로 자리 잡고 있습니다. 실제 임상에서는 유전체 분석 결과를 바탕으로 치료 방침이 결정되기 때문에, 유전체 분석 검사의 신뢰성(Reliability)과 신속한 결과 제공(Turnaround Time, TAT)은 단순한 운영 성과 지표(KPI)가 아닙니다. 이는 환자의 치료 일정과 의료진의 임상 의사결정에 직접적인 영향을 미치는 핵심 제약 조건입니다. 그 사이를 채우는 것은 시
배송최적화 시스템 구축기 Part 02. 복잡한 비즈니스 로직에 유연한 디자인 패턴 입히기
안녕하세요! 올리브영 배송최적화 스쿼드의 백엔드 개발을 담당하고 있는 로미입니다.🌠 지난 Part 01에서는 멀티 센터 체제 전환의 배경과 배송최적화 시스템의 전체 아키텍처를 소개했는데요. 이번 Part 0…
Amazon ECS 실행 구조와 선택 기준 – 1부: 컴퓨트와 실행 형태
AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch typ
Amazon ECS 실행 구조와 선택 기준 – 2부: 배포 전략과 네트워크, 설계 상한
이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다. 2부에서는 남은 선택지를 다룹니다.
Python의 멀티프로세싱과 Airflow, 그리고 관련된 문제 해결기 1편
저희 팀은 데이터 입수 플랫폼의 배치 워크플로를 Airflow 2.10.2로 운영하고 있습니다. 2025년 4월 Airflow 3.0이 릴리스되었고, UI 개선과 다양한 신규 기능이 포함되었습니다. 이 변화가 저희 운영 환경에 필요하다고 판단했고 도입을 위한 PoC(Proof of Concept)를 진행했습니다. 이 글은 그 PoC 과정에서 Python의 멀티프로세싱 방식 중 하나인 fork로 인해 발생한 문제를 발견해 해결하고 기여한 과정을
모놀리식인데, 도메인 하나만 따로 띄웁니다
모듈러 모놀리식에서 도메인 하나를 독립된 실행 단위로 만드는 방법
아임웹의 Amazon VPC Lattice 기반 서비스 네트워크 재설계와 비용 최적화 사례
들어가며 아임웹의 서비스 진입 경로는 AWS 계정과 VPC, 클러스터에 걸쳐 확장되어 왔습니다. 그 과정에서 로드밸런서 계층의 한도에 부딪혔는데, 상향 신청으로 해결되는 한도도 있었지만, ECS 서비스당 Target Group 5개 제한처럼 상향 대상이 아닌 것도 섞여 있었습니다. 이를 계기로 마이크로 프론트엔드(Micro-Frontends, MFE) 서빙 경로를 대상으로 서비스 네트워크를 재설계했습니다. 재설계의 골자는 외부 진입점(North
AWS Lambda의 4가지 실행 모델 – 구조와 선택 기준
Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크
AI 기반 SCTE-35 자동 삽입으로 라이브 스트리밍 광고 운영 자동화하기
AWS Elemental MediaLive의 썸네일 API와 Amazon Rekognition Custom Labels, AWS Step Functions를 결합하여 라이브 방송 화면을 AI가 실시간으로 인식하고, 하프타임 등 브레이크 진입 시 송출되는 필러(Filler) 영상을 감지하여 SCTE-35 광고 신호를 자동으로 삽입하는 아키텍처를 소개합니다. 소개 라이브 스트리밍과 광고 삽입 운영의 과제 라이브 스트리밍(특히 스포츠 중계)에서 SC
모노리포 희망편, 절망의 리포가 희망의 리포로 부활하기까지 걸린 1년
토스에서 100명이 넘는 엔지니어들이 모노리포에서 장점만을 누리기 위해 카탈로그를 도입한 이야기를 소개합니다.
A1Mobilsoft의 운영 문의 자동화 여정 (1): 문제 정의와 3-에이전트 아키텍처 설계
본 블로그 시리즈는 A1Mobilsoft, Megazone, AWS 가 공동 작성 하였으며, 두 편으로 이루어져 있습니다. 각 편의 구성은 다음과 같습니다. 1편 (0~3장, 현재 글): 문제 정의와 3-에이전트 아키텍처 설계 2편 (4~7장): 세 에이전트 구현 우여곡절과 사람 vs AI 검증 1편: 슬랙 #운영개발문의 채널의 고통에서 출발해, 왜 Knowledge·Code·DB 세 에이전트 구조로 갈랐는가 수 시간씩 늘어지던 운영 문의를 [
당근이 AWS CloudHSM으로 대규모 서명키 관리 시스템을 구축한 방법 – 3부: 서명 시스템 구현, 트러블슈팅, 무중단 키 전환
해당 포스트는 당근의 최용환님, 조승환님, 오현준님과 함께 작성했으며, AWS Summit Seoul 2026에서 발표한 세션 내용을 기반으로 합니다. 이 시리즈의 1부에서는 서명키 보안의 중요성과 당근이 하이브리드 전략을 선택한 과정을, 2부에서는 CloudHSM 아키텍처와 다계층 접근 제어 전략을 다루었습니다. 이번 마지막 글에서는 이 인프라 위에서 서명 시스템을 어떻게 구현했는지, PKCS#11 기반 시스템 운영에서 겪은 트러블슈팅, 그리
AWS Kiro를 활용한 바이브코딩 협업 및 관리 환경 구축
여러 개발자와 AI Agent가 동시에 하나의 제품을 개발하려면 코드 생성 속도뿐 아니라 공통 지침, 변경 관리, 작업 충돌 방지 체계가 필요합니다. AI-RE 팀은 AWS Kiro의 Spec 기반 개발 방식과 Steering, Hooks에 Notion의 실시간 협업성, Git의 형상관리를 결합해 멀티에이전트 바이브코딩 협업 환경을 구축했습니다. 이번 글에서는 기능 기획부터 구현, 검증, 진척·리스크 관리까지 이어지는 실제 운영 방식을 소개합니
AWS Transform for migrations, 이제 13개 언어에 대한 현지화 지원
이 글은 AWS Blog의 “AWS Transform for migrations now supports localization for 13 languages” by Jamie Vinciguerra and Jason Amaya 게시글을 번역한 글 입니다. 마이그레이션 프로젝트를 수행하는 조직이 항상 하나의 공통 언어로 운영되는 것은 아닙니다. 마이그레이션 팀은 여러 지역에 걸쳐 있으며, 워크로드에 가장 가까운 사람들이 종속성, 비즈니스 컨텍스트,
micro frontends가 미리캔버스 프론트엔드팀이 일하는 방식을 바꾸는 이유
MSA - 원칙, 아키텍처, 그리고 DB 분리
안녕하세요. 비브로스에서 백엔드 개발을 담당하고 있는 박진아입니다.
페이지 1 / 6 (총 94개)