총 104개 글 · 원본 블로그 방문 →
이커머스 지마켓의 개발 이야기와 기술 경험
MSA 환경에서의 장애 양상 우리는 장애를 피할 수 없습니다. 아무리 실력이 좋은 소프트웨어 개발자라 할지라도 완전무결한 시스템을 만들 수 없습니다. 물론 우리도 여러 방법으로 장애에 대응하고 있었습니다. 서버를 클러스터링하여 일부 서버에 문제가 발생하더라도 클라이언트는 정상 동작중인 다른 서버를 이용할 수 있습니다. 인프라를 분산 구축하는 것도 이러한 전통적인 장애 대응방식 중 하나입니다. 우리는 서버 클러스터링, 인프라 분산 구축과 같은 기존의 장애 대응 방식은 시스템의 완전한 실패를 대비하여 설계되었다는 것에 주목해야 합니다. 하드웨어 장비에 문제가 생겨 서버에 전원 공급이 안되거나 자연재해로 인해 데이터 센터의 데이터가 유실된 경우라면 이런 기존의 장애 대응 방식으로 우리는 큰 도움을 받을 수 있..
적은 리소스 적당한 효과 개발자는 종종 레거시 시스템이나 코드를 마주할 때가 있습니다. "레거시" 는 양면적이어서 잘 돌아가고 있는 시스템이면서도 앞으로의 요구사항 변경에 수용력이 부족해 보이는 시스템이기도 합니다. 이러한 레거시와의 공존은 필연적이면서도 효과적인 공존을 위한 부단한 아이디어들을 필요로 하기도 합니다. 보통 레거시 시스템을 대할 때면 이런 문장을 머리에 두고 생각합니다. "적은 리소스만 들여서 적당한 효과를 얻을 방법이 없을까?" 항상 이런 접근만이 답이 되진 않지만 레거시 시스템은 우리에게 친절하지만은 않습니다. 조금 까탈스러운 제약이나 조건들을 가지고 있죠. 조금 지난 미션이지만 재미있게 해결했던 사례를 한번 소개하고자 합니다. 레거시 시스템 소개 우리 팀의 주요 역할은 주문 시스템의..
안녕하세요 Data Platform Engineer 조광진입니다.2019년에 지마켓 Data Platform 팀에 합류하여 데이터 플랫폼에 관련된 다양한 업무를 진행하고 있습니다.저희 팀에서 하는 업무에 대해 간단하게 설명드리면 글 전반적인 내용에 도움이 될 것 같아 먼저 소개하도록 하겠습니다.Hadoop 기반의 빅데이터 플랫폼인 Data Lake 활용을 통해 전사에서 활용되는 데이터의 수집, 적재, 분석에 대해 직 간접적으로 도움을 드리고 있으며, 비정형 데이터를 다양하게 활용하기 위한 Redis, Elastic Search, MongoDB 데이터 플랫폼도 운영하고 있습니다. Data Platform 팀이 사용하는 기술 스택은 아래와 같습니다.팀 목표는 사용자들에게 안정적이고 편리한 데이터 플랫폼을 제..
안녕하세요. 지마켓에서 개발자분 업무의 편의를 도모하기 위한 클라우드 플랫폼 업무를 담당하고 있는 김지형입니다.저희 지마켓 개발 플랫폼으로서 몇 가지가 존재하는데 Fusion이라는 Openshift, Kubernetes 기반의 컨테이너 플랫폼을 개발자 분들께서 주로 이용하시지만, API 통합 관리 도구로서 API Gateway 플랫폼도 존재합니다. Nginx 프로그램을 붙여서 로드밸런싱이나 페이지 요청을 처리하는 팀이 많겠지만, Nginx Controller까지 붙여서 API 관리까지 하기에는 다소 벅찰 수 있다고 생각합니다. 본 API Gateway 이용도 API 관리의 한 가지 선택지로서 이용해볼 수 있다는 것을 알리기 위해, 또한 타사에서도 API Gateway를 적용하고자 하는 팀을 대상으로 글을..
소개안녕하세요:) 지마켓에서 데이터로 여러 가지 흥미로운 개발을 하고 있는 한한주입니다.이번에 소개해 드릴 내용은 Databricks Community Edition에 대한 기본적인 설정과 사용법에 대한 내용입니다.Databricks Community Edition에서 제공하는 클라우드 환경을 사용하면 간단하게 Spark 작업환경을 만들 수 있어 Spark를 공부하고자 하거나 간단하게 테스트를 할 때 매우 유용합니다. (사실 제가 유용하게 사용했습니다^^;; 독자분들도 유용하게 사용하시기를 바라며..)이번 블로그에서는 Databricks Community Edition을 사용하여 무료로 간단히 Spark환경을 만들어 보도록 하겠습니다.그럼 Start!Databricks들어가기 앞서 먼저 Databrick..
안녕하세요. SmilePay Engineering 팀 문한국입니다. 저는 이번 포스팅을 통하여 Junit Test 코드 작성시 유용한 몇 가지 팁을 공유하려고 합니다. 우선적으로 꿀팁 테스트 코드를 작성하기 위한 적당한 코드가 필요했습니다. (TDD로 테스트 코드를 먼저 작성해보면 좋았겠지만 이해를 돕기에는 적당한 코드를 제공하고 순서대로 테스트 코드를 작성해 보는 게 도움이 되겠다고 생각했습니다.) 홀짝 게임 어떤 프로그램을 짜보는게 간단하면서 테스트 코드를 소개하기에 적당할까 고민하다가 저는 어릴 적 동네 문방구에서 했던 홀짝 게임이 떠올랐습니다. 게임의 룰은 간단합니다. 1. 사용자는 홀과 짝 중 하나를 선택하고 게임을 시작합니다. 2. 게임기에서는 랜덤으로 홀과 짝이 나옵니다. 3. 내가 선택한 ..
KafkaItemReader 적용기안녕하세요 VIP & Vertical 팀 김윤제입니다.VIP 파트에서 상품 상세 페이지 및 리뷰 업무를 맡고 있습니다.최근 리뷰 개편 작업에 Kafka 도입을 해보며 주니어 개발자로서 겪고 배운 내용을 공유드리기 위해 작성했습니다.부족하게 쓴 내용일지라도 도움이 되었으면 좋겠습니다. Kafka를 선택한 이유제가 속한 VIP & Vertical팀 (VIP 파트)에서 Kafka를 사용하게 된 이유는 크게 다음과 같이 두 가지 이유가 있었습니다.RDB의 부하 조절을 위해 미들웨어인 메시징 플랫폼을 두어 데이터를 처리Review 등록 이후에 같은 데이터를 가지고 여러 가지 작업(Junk 판독, Review Summary) 등의 배치 작업을 하는 병렬 프로세싱을 원했습니다. (..
안녕하세요. 저는 지마켓에서 백엔드 시스템을 개발하고 있는 양승권이라고 합니다. 이번에 저희 시스템 중 Maven으로 개발되어있는 시스템들에 Spock framework를 적용한 경험을 공유하고자 합니다. 하고 싶었던 것 신규 프로젝트를 진행하게 되면서 새로운 기능을 개발할 일이 생겼는데, Maven 프로젝트 라서 그런지 Test 쪽이 좀 부족한 상황이었습니다. 그래서 이 참에 한번 이 프로젝트에 적용해보고 다른 Maven 프로젝트에도 적용해보자고 생각했습니다. 아래와 같은 내용을 해보고 싶은 내용들을 도출하였습니다. Spock library를 활용하여 좀 더 직관적인 테스트를 해보자. Spock의 Groovy로 Test code를 작성해보자. 프로필 별로 구분하여 단위/통합 테스트를 구분하여 수행해보자..
안녕하세요. Fulfillment Engineering 팀의 입사한 지 1년이 얼마 지나지 않은 싱싱한(?) 주니어 개발자 백정현입니다. 최근 들어 JAVA를 기반으로 한 Spring boot + JPA 또는 Spring Data JPA를 이용한 프로젝트가 많이 보입니다. JPA는 쿼리를 지원하는 다양한 방법들이 있는데, 그중 QueryDSL에 대해서 살포시 찔러보도록 하겠습니다. QueryDSL은 무엇인가요? QueryDSL은 정적 타입을 이용해서 SQL과 같은 쿼리를 생성할 수 있도록 해 주는 오픈소스 프레임워크입니다. 쿼리를 문자열로 작성하거나 작성하는 것이 아닌, QueryDSL이 제공하는 Fluent API를 이용해 코드 작성의 형식으로 쿼리를 생성할 수 있게 도와줍니다. Gradle 설정 Qu..
안녕하세요 Post-tx & Accounting 팀 권우석입니다. 회사에 처음 입사했을 때 저에게 '객체 지향 프로그래밍'은 인터넷에 검색하면 나오는 몇 가지 특성과 설계 원칙으로 대변되는 단어였습니다. 하지만 당장에 프로젝트를 진행한다고 상상했을 때 "어떤 객체가 필요하지?", "객체는 어떻게 구현해야 하지?"와 같은 질문을 마주할 것 같았고, 질문에 대한 답을 명확히 할 수 없는 느낌에 공부를 했었는데요. 이때 공부했던 내용을 아래의 순서로 간단히 정리해보려 합니다. (1) 객체를 식별하는 방법 (2) 객체를 구현하는 방법 (3) 객체들이 협력할 수 있는 구조 객체 지향은 현실의 모방이다? 위 사진을 보면 "배달원이 고객에게 택배를 전달하는 상황"이라는 사실을 어렵지 않게 파악할 수 있습니다. 아마 ..
오랜만에 Java Generic 포스팅으로 돌아왔습니다.이번에는 Java Generic에서 주의해야 하는 심화 개념들을 몇 가지 다뤄보겠습니다.1. Type ErasureJava Generic 을 관통하는 주요 개념 중에 Type Erasure라는 개념이 있습니다.이론적으로는 Generic 을 운영하기 위해 부가적으로 들어간 소스코드들이 바이트코드 레벨에서는 모두 제거되는 것을 의미하는데요.개념편에서 다루었던 예제를 기반으로 좀 더 상세히 알아보겠습니다.public class Tv { private String title; public Tv(String title) { this.title = title; } public String getTitle() { r..
빅데이터라는 시대의 요구에 맞추어 NoSQL이 등장한 지 십 년이 넘는 세월이 흘렀습니다. 하지만, 아직 RDB에 비해서 스키마 설계를 위한 참고 자료가 부족하다고 생각되는데요. 저 또한 MySQL만 사용해오던 백엔드 개발자로서 신규 프로젝트에서 갑작스럽게 MongoDB 스키마를 설계하게 되어 꽤 당혹스러웠던 경험이 있습니다. 저처럼 NoSQL, 그중에서도 MongoDB를 처음 사용하게 된 개발자들을 위해서 빠르게 기본 개념을 훑고 바로 스키마 설계가 가능하도록 도움을 줄 수 있는 글을 써보려 합니다. 그래서 MongoDB를 도대체 왜 쓰는데? NoSQL/MongoDB 이름만 들어본 분들을 위해 특징 및 사용목적을 간단하게만 짚고 넘어가는 게 좋을 것 같습니다. 인터넷 서비스가 점점 많은 곳에 보급되고..
안녕하세요. Seller & SD Engineering 팀 박명훈입니다. 기존에는 프로젝트나 기술적인 내용에 중점을 주어 글을 작성했는데 오늘은 내용을 좀 환기하여 개발자의 글쓰기에 대해 이야기합니다. 회사에 와서 2년 동안 개인 위키 페이지 500개 이상을 썼으며, 팀 위키나 개발 문서, 개발 블로그를 운영하며 여러 글을 쓰고 있습니다. 글이나 문서를 쓰며, 신경 썼던 부분 그리고 어떻게 하면 더 글을 잘 쓸 수 있을까에 대해 공부한 내용에 대해 공유합니다. 너무 자세하게 설명하면 내용이 길어질 것 같아 핵심만 작성합니다. 글쓰기는 중요하다. 신입 입사자 혹은 다른 팀에서 어떤 정보를 확인할 때는 문서를 확인합니다. 팀이나 비즈니스를 파악할 때 가장 중요한 요소 중 하나가 문서이고, 문서가 없다면 하나..
카프카와 확장성 카프카를 사용하여 환경을 구성하는 과정에서 확장성이 필요한 서비스를 운영하기 위한 고민이 있었습니다. 일면의 가용성이나 확장성에 대해서는 카프카는 아주 훌륭한 도구였으나 또 다른 측면에서 딱딱하게 구는 부분도 있었습니다. 리파티셔닝과 리밸런싱 카프카가 제공하는 기능의 몇 가지는 파티션이라는 구조를 기반하고 있습니다. 일단 카프카는 기본적으로는 메시지의 순서를 보장하지 않지만 메시지의 순서를 일부 보장하며 해당 순서를 기반으로 commit과 offset을 제공하는 기반은 파티션입니다. 따라서, 파티션에 의해 좌우되는 요소들이 많습니다. 예를 들면 파티션은 메시지의 동시처리의 상한을 만듭니다. 파티션 수 보다 많은 컨슈머의 수는 메시지 처리 속도 측면에서 의미가 없습니다. 더 많은 컨슈머를 ..
안녕하세요. Seller 팀에서 판매자 대상으로 업무를 진행하고 있는 개발자 박명훈입니다. 오늘은 지난 회고록에서 이야기했던 업무에 대해 좀 더 정리해서 이야기해보려고 합니다. 아직까지 부족한 부분이 많지만 나름의 발전 정도라고 생각해주시면 감사하겠습니다. Gmarket과 Auction에서 쓰는 상품 리스트, 상품 상세 페이지에서 사용하는 브랜딩 서비스에 대해 서술합니다. 저는 뒷단의 백엔드 서비스를 담당하여 개발하였습니다. 브랜딩 정책은 비지니스 룰이 많아서 규칙이 까다롭기 때문에 여러 테이블을 조인해서 기준을 판단하며, 요청마다 이러한 테이블을 조인해서 응답을 주게 되면 이는 곧 성능 저하로 연결됩니다. Gmarket과 Auction의 상품에서 브랜드 정보 요청은 모든 사용자들이 사용하므로 많은 요청..
Linger Kafka 에 보면 linger 라는 개념이 나옵니다. 프로듀서가 메세지를 전송할 때, 전송을 위한 통신 오버헤드를 줄이기 위해 메세지를 어느 정도 모아서 보내는 방식입니다. 네트워크 비용은 대체적으로 큰 비용에 속하기 때문에 이를 줄이기 위한 방법입니다. 이 컨셉은 kafka 의 여러 곳에서 등장합니다. 기능만큼이나 성능 측면에서 비용을 낮추기 위해 여러 방안을 사용한 듯 싶습니다. 네트워크 비용만큼이나 비싼 비용은 바로 DB 비용입니다. 특히 RDB 에서는 원하는 목표를 위한 큰 비용을 마주하곤 합니다. 도메인의 특이한 제약은 종종 겪곤 하는데 저도 이번 경우에 몇몇 제약적인 상황 하에 RDB 의 비용을 효율적으로 다뤄보기 위해 linger 전략을 도입한 사례를 소개합니다. Linger ..
Data 모으기 사용할 다건의 data 목록을 마련할 때 상황에 따라 서로 다른 source 에서 조회해야 하는 경우가 있습니다. 예를 들면 data 가 일부 캐싱되는 경우를 들어봅시다. 10개의 data 를 조회하는데 일부는 캐시에서 조회가 가능할지도 모릅니다. 그리고 나머지는 DB 에서 조회해서 채워야 할 것 입니다. 이런 경우 캐시와 DB 라는 두 개의 data source 로 부터 필요한 data 목록을 조회하게 됩니다. 꼭 이런 경우가 아니더라도 우리의 data 아키텍쳐 상으로 여러 이유를 들어 data source 여러 곳에서 data 조회가 필요한 경우는 쉽게 생각할 수 있습니다. Data Source 우선순위 너무 복잡한 상황을 전제하지는 않을 예정이지만 기본적인 요구사항들은 짚어보려고 합..
실패한 작업 가끔 일련의 작업을 하나의 트랜잭션 마냥 수행해야 하는 경우가 있습니다. 분산처리나 분산 트랜잭션 등의 주제라면 또 다른 얘기가 되지만, 좀 더 단순하게 코드 레벨의 문제들을 마주할 경우가 있죠. 각 작업은 실패할 수 있고 하나라도 실패하는 경우 지금까지 수행한 작업들에 실패 처리를 하는 코드를 어떻게 짜면 좋을까요? 일단 하나의 작업에 대해서 실패를 대비하고 실패 시 처리방안을 마련하는 방법은 바로 try-catch 일 것입니다. 그러면 쉽게 생각해서 일련의 작업을 위한 try-catch 를 여러 번 사용하면 되지 않을까요? 중첩 Try Catch 하나의 작업은 다음과 같이 실패를 다룰 수 있습니다. try { // 실패할 가능성이 있는 작업 } catch (Exception e) { //..
페이지 5 / 6 (총 104개)
