개발자 배씨

Q&A 자유롭게 질문주시면 시간날 때마다 틈틈이 답변드리겠습니다. 카테고리 없음 2024.08.13  14
개발자로 취업하기 위한 7가지 개요안녕하세요. 정말 오랜만에 글을 쓰게 되었습니다. 한동안 블로그 포스팅을 하지 않았는데 사실, 그 사이에 취업에 대한 걱정과 몇 번의 최종 탈락 경험을 하면서 어떻게 살아야하나 스스로 고민을 많이 하게 되었습니다. 눈을 낮춰서 중소 기업을 가야하나, 교육을 또 한 번 더 들어야하나 뭐 이런저런 생각이 많이 들더군요. 이 글을 접하시는 분들은 아직, 학부생이거나 또는 프로그램의 교육생이거나 취업을 절실히 바라는 취준생 등 다양한 분들이 계실텐데요. 현재 저의 경험상 취업은 쉽지 않습니다. 코로나 시대가 열리면서 네이버는 1,000명을 뽑았던 시기가 있었지만, 지금은 채용 시장이 얼어붙었다는 얘기도 많이 들으셨을 겁니다. 저는 얼어붙은 시장이 되고나서야 취업을 준비하였고, 정말 많은 지원을 했습니다. 그.. 인터뷰 2024.05.31  14
[2024 카카오 채용연계형 겨울 인턴십] 최종 합격 및 전환 후기 카카오 인턴을 합격하기 위해 준비했던 과정과 그리고 전환을 위해 어떻게 달려왔는지 적어보려고 합니다. 22년 하반기에 공채가 한 번 열렸었는데 그때 당시 실력이 많이 부족했기 때문에 코테를 광탈했던 기억이 납니다. 23년 상반기에는 공채가 안열렸기 때문에 하반기를 기다리고 있었는데 2023년 11월 8일 자소설 닷컴에 카카오 채용 연계형 인턴 공고가 올라왔었어요. 그래서 바로 작성했었습니다. 서류 전형 (23.11.08 ~ 23.11.20)번호질문1[필수] 졸업(예정) 시기를 기재해주세요 (ex. YYYY년 MM월) 2본 포지션으로 지원을 결정하시게 된 계기와, 희망 포지션에 대한 본인만의 경쟁력(직무 관련 프로젝트, 교육, 경험 등을 토대로)을 자유롭게 작성해주세요 3자신의 열정과 전문성을 나타낼.. 인터뷰 2024.04.17  13
[kafka] 컨슈머 파티션 할당 전략 개요 이전 포스팅에서는 컨슈머 코디네이터를 통해 리밸런싱 동작이 발생하는 것을 확인할 수 있었다. 하지만, 리밸런싱은 무거운 작업이기 때문에 자주 진행하는 것은 문제가 된다고 강조하였다. 이를 해결하기 위해 스태틱 멤버십 기능을 적용하여 일정 시간동안 리밸런싱을 동작하지 않도록 설정할 수 있는 것을 확인하였다. 이전에 학습했던 내용 중 프로듀서와 관련된 포스팅에서 파티셔너라는 기능을 살펴보면서 특정 파티션으로 전송하기 전 배치 작업을 진행하는 내용을 살펴본 적이 있다. 이와 유사하게 컨슈머의 동작에서도 대상 토픽의 어느 파티션으로부터 레코드(메시지)를 받아올지를 결정하는 메커니즘이 존재하는데 어떠한 매칭 전략이 있는지 이번 포스팅을 통해 알아보려고 한다. 즉, 이번 포스팅에서는 컨슈머 파티션 전략을 정리.. Kafka 2023.10.31  0
[Kafka] 컨슈머의 리밸런싱 개요 지금까지 카프카의 내부 원리부터 프로듀서가 어떻게 신뢰성있게 메시지를 전송하는지에 대해서 자세히 살펴보았다. 이번 포스팅은 드디어 컨슈머라는 주제를 가지고 내부적으로 어떻게 동작하는지 자세히 살펴보려고 한다. 이전에 "정확히 한 번 메시지 전송" 포스팅에서 트랜잭션 코디네이터가 해당 로직에서 필수적인 존재라는 것을 알아본 적이 있었다. 컨슈머와 관련돼서도 비슷한 코디네이터가 존재하는데 이에 대해서 알아보고 추가적으로, 리밸런싱이 무엇인지도 학습해보자. 컨슈머 오프셋 관리 컨슈머에서 중요하게 처리하는 부분은 오프셋 관리인데 컨슈머가 컨슘하고 있는 토픽에서 메시지를 어디까지 들고왔는지 기록을 하고 있어야한다. 이때 활용하는 것이 오프셋인데 만약, 컨슈머가 일시적으로 장애가 발생하거나 일시적으로 동작을 .. Kafka 2023.10.25  2
[Kafka] 프로듀서가 정확히 한 번만 전송하는 방식 개요 이전 포스팅을 보면 카프카에서 멱등성 옵션을 이용해 중복 없는 전송을 할 수 있다고 언급하였다. 다만, 여기서 유의해야하는 점은 중복 없는 전송 방식이 정확히 한 번만 전송한다는 의미가 아니다. 두 번을 전송하더라도 중복된 데이터를 삽입하지 않는 로직을 의미한 것이며, 정확히 한 번 전송은 트랜잭션과 같은 전체적인 프로세스 처리를 의미한다. 즉, 이번 포스팅에서는 정확히 한 번만 전송하는 로직은 어떻게 흘러가는지 알아보려고 한다. 이유 전체적인 프로세스를 관리하기 위해 카프카에서는 정확히 한 번 처리하는 별도의 프로세스가 존재하는데 이를 트랙잭션 API라고 부른다. 우리는 이 과정을 자세히 살펴보려고 하는데, 전송을 두 번 하더라도 중복 데이터를 처리하면 되는 것이 아닐까라는 의문이 생기기도 한다... Kafka 2023.10.24  0
[Kafka] 프로듀서의 내부 동작 원리 파헤치기 개요 이번 포스팅에서는 프로듀서가 어떻게 동작하는지 내부 원리를 알아보려고 한다. 기존에 필자가 알고있었던 프로듀서의 역할은 메시지를 발행하여 카프카에 전송하는 것인데, 그 안에서도 파티셔너라는 친구가 중간에 개입하면서 어떠한 토픽으로 보낼지 나침반 역할을 하게 된다. 또한, 해당 메시지들은 즉시 카프카로 전송하는 것이 아니라 내부적으로 어떠한 조건이 충족되었을 때 수행된다고 한다. 추가적으로 카프카에서 중복 데이터를 처리하는 방식도 존재한다고 한다. 이러한 부분들을 깊게 학습하고 동작 흐름을 자세히 살펴보고자 한다. 파티셔너 카프카의 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 하기 위해 파티션으로 나뉘고, 최소 하나 또는 둘 이상의 파티션으로 구성된다. 그리고 프로듀서는 토픽으로 메시지를 보낼 때.. Kafka 2023.10.23  1
[Kafka] 내부 동작 원리 파헤치기(2) - 리더에포크 개요 이전 글에서는 리플리케이션의 동작 원리에 대해서 글을 작성하였고 예고한대로 이번글에서는 리더에포크가 무엇인지 알아보려고 한다. 추가적으로 컨트롤러, 세그먼트 로그 컴팩션에 대한 정리도 같이 진행한다. 리더에포크와 복구 리더에포크(LeaderEpoch)는 카프카의 파티션들의 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용되는데 복구 동작 시 하이워터마크를 대체하는 수단으로 활용한다. *하이워터마크 : 마지막 커밋 오프셋 위치 이번 예제에서의 파티션 수는 1, 리플리케이션 팩터는 2라고 가정하며 장애가 발생하는 가정을 설명하려고 한다. 아래의 표는 동작과정을 나타내며 마지막 8번 문항에서 장애가 발생하니 그 전에 동작된 과정을 그림을 보면서 이해해보자. 1. 리더는 프로듀서로부터 mes.. Kafka 2023.10.22  0
[Kafka] 내부 동작 원리 파헤치기(1) - 리플리케이션 개요 카프카는 브로커의 장애에도 불구하고 연속적으로 안정적인 서비스를 제공하면서 데이터의 유실을 방지하며 유연성을 제공한다. 이전에 게시한 포스팅을 보면 과거 프로젝트를 진행하면서 아쉬웠던 부분들을 회고하며 가용성을 유지하는 환경으로 재구성하였다. 이때 REPLICATION FARTOR라는 옵션을 설정을 하면서 복제 파티션을 만들도록 했던 것을 알고 있을 것이다. 이번 포스팅은 그 원리에 대해서 파헤쳐보는 시간이다. 즉, 어떻게 리플리케이션 동작되는지 알아보고 지금의 답답함을 해소해보려고 한다. 리더와 팔로워 카프카는 내부적으로 모두 동일한 리플리케이션들을 리더와 팔로워로 구분하고, 각자의 역할을 분담시킨다. 여기서 알아야하는 것은 리플리케이션들 중 리더를 하나 정하고 모든 읽기와 쓰기는 그 리더를 통해.. Kafka 2023.10.19  0
[대규모 시스템 설계] 6. MSA 분산 트랜잭션 관리 개요 이전에 진행했던 프로젝트는 분산 트랜잭션 처리 로직을 구현하지 않은 아쉬운 MSA 환경을 구축하였다. 각 마이크로 서비스들은 공유 DB를 바라보고 있었으며, 특정 서버가 트랜잭션을 처리하게되면, 단일 DB 환경에서 데이터의 일관성과 안정성을 보장하는 DB에 의존하여 ACID 특성을 보장할 수 있었다. 하지만, 이러한 방식은 왜 우리가 MSA 환경으로 구성했는지 의문을 품을 수도 있는 부분이다. 하나의 공유 DB를 바라보면서 서비스만 나눴다면 차라리 서비스를 나누지 않고 모놀리식 아키텍처로 구성하는 것이 더 낫지 않나 생각이 드는 것이다. 즉, MSA 환경을 구성하려고 했다면 MSA 답게 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 DB를 사용하여 다른 서비스 컴포넌트에 대한 의존성을 없.. 대규모 시스템 설계 2023.10.15  0
[Java] HashSet의 비밀 개요 최근 코딩 테스트를 치룬적이 있는데 Set 자료구조에 값을 담고 추후 해당 데이터를 List에 담아서 오름차순 정렬을 해야하는 로직이 필요로 하였다. 하지만, 주어진 테스트 케이스는 Set에 들어있는 원소의 값을 List에 담고 반환해주더라도 정답으로 출력되었다. 그래서 오름차순 정렬을 잊은채 제출하고 다른 문제를 풀러 갔다. 만약 예제가 틀렸더라면, 바로 오름차순 정렬을 깜빡한 걸 인지하고 바로 수정하지 않았을까... 엄연히 내 실수긴 하다 ㅎ.. 하지만 조금 특이한게 Set에 삽입한 순서를 떠올려보면 정렬을 하지않으면 테스트 케이스도 틀려야했다. 지금까지 필자가 알고 있었던 HashSet은 중복을 허용하지 않고 정렬을 지원하지 않는다고 알고 있었는데 왜 오름차순으로 정렬된 테스트케이스를 맞출수 .. Java 2023.10.04  4
[기술적 선택] Spring Cloud Config & Spring Cloud Bus 개요 분산 시스템인 MSA 환경에서 구동되는 각 애플리케이션 서버(Spring Boot 기준)들의 설정 정보들은 application.yml에 기본적으로 세팅하게 된다. 만약, 이러한 설정 정보들을 변경하고 서버에 적용하기 위한 가장 간단한 방법은 서버를 다운시켰다가 재가동하면 된다. 쉽게 말하면, 인텔리제이를 활용하여 프로젝트를 많이 진행할텐데 application.yml 파일을 수정했을 때 해당 설정 정보들을 적용하기 위해서 인텔리제이의 우측 상단에 위치한 재생 버튼을 클릭하여 서버를 껐다가 다시 실행하면 된다는 것이다. 스프링 개발 경험이 있다면 남 얘기가 아니기 때문에 모두 경험해봤을 것이라고 생각한다. 필자 또한 프로젝트를 진행하면서 데이터베이스의 정보들이나 로깅 레벨을 설정하는 등 애플리케이션.. 기술적 선택 2023.09.09  1
[기술적 선택] Spring Cloud Netflix Eureka & Spring Cloud Gateway 개요 프로젝트를 진행하면서 아쉬웠던 점은 조금 애매한 MSA 구조였다. 마이크로 서비스마다 서로 통신하는 것이 아니라 Front에서 A 서버로 요청을 진행하고 응답 데이터 반환 후 다시 Front에서 B 서버로 요청하면서 2번의 API 통신으로 비효율적으로 진행되었다. 즉, Front에서 A 서버의 요청 후 A 서버에서 B 서버로의 직접적인 통신은 없었다는 것이다. 또한, 프로젝트를 진행하면서 Nginx를 통해 로드밸런싱을 진행하였지만, upstream을 통한 라우팅 블록이 끝이였고, 구체적으로 어떠한 마이크로 서비스들로 로드 밸런싱을 할 것인지에 대한 구체적인 설계는 진행하지 않았다. 이번 포스팅은 이전에 진행했던 프로젝트를 다시 회고하면서 어떤 기술들을 도입하면 좀 더 유연한 아키텍처로 재탄생 시킬 .. 기술적 선택 2023.09.06  4
Softeer 7차 정기 역량 진단 취득 후기 23년 8월 11일에 Softeer 7차 정기 역량 진단 시험을 보게 되었다. Softeer 역량 진단을 보고 취득을 하게 되면 Level 3 인증서를 발급해주는데 해당 인증서가 있으면 다음과 같은 혜택이 있다. 현대자동차, 기아, 현대모비스, 현대오토에버, 현대차증권, 현대엔지비 SW 분야 지원 시, 코딩테스트 면제 (면제 혜택을 적용하는 채용의 경우 채용공고에 명시) 1) 참가 자격 : Softeer 회원 누구나 참여 가능 (단, Talent pool 내 기초 정보, 학력 정보를 입력해야 접수 가능) 2) 일정 (접수/평가 온라인 진행) : 2023년 8월 11일(금) 17:00 ~ 20:00 3) 세부 사항 (시험 참여 방법 안내는 접수 마감 후 8/10(목) 일괄 안내 예정) - 언어: C, C+.. 기타 2023.08.25  8
[Kafka] 고가용성과 리플리케이션 & 스프링 부트 테스트 개요 프로젝트를 진행하면서 ELK-Stack을 활용하여 로그 수집을 진행하였고 추가적으로 kafka를 도입하면서 안정화된 시스템을 구축하였다. 하지만, 프로젝트의 제한된 날짜 때문에 카프카의 큰 장점을 못살렸던 것이 너무 아쉽게 느껴졌다. 예를들면, 필자가 구성한 카프카는 단일 브로커로 구성하였기 때문에 카프카의 고가용성이라는 장점을 못살린 아키텍처가 된 것이다. 프로젝트 시즌이 끝나고 좋아하는 코딩 문제만 풀다보니 아쉽게 마무리했던 과거 프로젝트의 기억이 주마등처럼 지나가면서 '아차!' 하는 느낌을 받았다. 이전에 작업하던 카프카 관련 내용들은 이미 사라진 서버에서의 고대 작업물이 되었고, 개인 노션 저장소에 백업을 해두긴 하였지만 각 서버마다 복잡하게 얽혀있는 환경 설정 등으로 같은 세팅으로 로컬에 .. Kafka 2023.08.09  0
[Java] Integer.valueOf(127)==Integer.valueOf(127)은 True? 문제점 얼마전 백준에서 문제를 풀다가 도저히 이해가 안되는 상황이 발생하였다. Integer타입을 가진 어레이 리스트를 활용해서 "==" 비교 연산을 하였다. 참조형 타입 같은 경우 "==" 연산을 할 경우 메모리 주소 값을 비교하는 것으로 알고 있다. 하지만 다음과 같은 코드를 봤을 때 조금 의문이 발생하였다. ArrayList listA = new ArrayList(); ArrayList listB = new ArrayList(); listA.add(128); listB.add(128); if (listA.get(0) == listB.get(0)) { System.out.println("True"); } else { System.out.println("False"); } 위의 코드문을 봤을 때 출력 .. Java 2023.08.08  1
[대규모 시스템 설계] 5. 키-값 저장소 설계 - CAP 정리 이번 포스팅은 키-값 저장소 설계에 관한 주제이다. 자료구조 중 Map이라는 것을 활용을 해봤다면 Key-Value 구조라는 것이 무엇인지 이해가 갈것이다. 보통 키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스이며 memcached나 레디스 같은 것들이 존재한다. 키-값 자료구조 상 키는 유일해야하며 키를 통해서 값에 접근할 수 있다. 키는 일반 텍스트일 수도 있고, 해시 값일 수도 있다. 아무튼 성능상의 이유로 키는 짧을수록 좋다. 단일 서버 키-값 저장소 한 대 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다. 키-값 쌍 전부를 메모리에 해시 테이블로 저장하여 들고오면 되는 것이다. 하지만, 모든 데이터를 메모리에 두는 것은 불가능하다. 자원은 유한하기때문에 이러한 문제를 .. 대규모 시스템 설계 2023.08.07  0
[기술적 선택] 무중단 배포 아키텍처 개념 및 Blue-Green 도입한 이유 개요 필자는 로컬 프로젝트를 4~5번 정도 진행을 해봤고 서비스 배포 프로젝트는 3번을 진행해봤다. 그 중 2번은 인프라를 직접 담당하며 CI&CD의 역할을 하였다. 첫 인프라를 담당하였을 때 EC2 서버 안에서 도커 가상화 환경의 이해와 컨테이너의 포트 연결, Nginx, Jenkins 등 여러 학습이 필요한 상태라 시간이 많이 소요되었다. 특히, 첫 인프라를 담당하였을 때 아키텍처 설계 완료 후 새로운 프로젝트가 빌드 될 때 웹 어플리케이션 서버(컨테이너)가 다운되고 새로 만들어진 프로젝트 기반의 도커 이미지를 가지고 컨테이너를 생성하게 된다. 이때 기존의 서버는 다운되고 새로운 서버가 로딩되는 그 시점에 서비스는 중단된다. 이러한 문제는 지속적인 서비스가 중단되고 사용자에게 불편함을 끼칠 수 있는 .. 기술적 선택 2023.07.24  0
[대규모 시스템 설계] 4. 안정 해시 설계 수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 오늘의 포스팅 주제는 안정 해시와 관련된 내용이니 천천히 살펴보도록 하자. 해시 키 재배치 문제 레디스와 같은 N개의 캐시 서버가 있다고 가정하자. 이 서버들에 부하를 균등하게 나누는 보편적 방법은 아래의 해시 함수를 사용하는 것이다. 현재 N은 4라고 가정을 한다. serverIndex = hash(key) % N (N은 서버 개수) 키 해시 해시 % 4 (서버 인덱스) key0 18358617 1 key1 26143584 0 key2 18131146 2 key3 35863496 0 key4 34085809 1 key5 27581703 3 key6 38164978 2 key7 22530351 3 위의 표를.. 대규모 시스템 설계 2023.07.24  0
[기술적 선택] Top-10 인기 검색어 구현을 위한 레디스 도입 이유 필자가 진행한 프로젝트에서 Top-10 인기 검색어 서비스를 구현하기 위해서 어떠한 방식을 사용할지 고민을 했다. 사실 해당 서비스를 구현하기 위해 레디스에 대한 개념이 잡혀있지 않아서 데이터베이스에 접근을 해서 매번 카운팅 업데이트 쿼리문을 날려야 하는건가 생각을 했었다. 왜냐하면 지금까지 프로젝트를 진행하면서 여러 기술들을 사용해봤지만 메모리 기반의 분산 저장소를 직접 활용해본 경험이 없었기 때문이다. "Top-10 인기 검색어" 서비스는 개발자 커뮤니티에서 사용자가 요청한 검색 키워드를 이용해 타사용자들에게 실시간으로 인기 검색어를 시각적으로 제공해준다. 그렇다면 매번 사용자가 검색할 때마다 디스크에 접근하여 해당 키워드에 대한 카운팅 작업으로 갱신한다면 리소스 낭비가 매우 심할 것이라고 생각했다... 기술적 선택 2023.07.23  0
[기술적 선택] 카프카의 도입 이유와 ELK-Stack과 결합한 시스템 설계 프로젝트를 진행하면서 서비스의 API 기능을 구현하는 것뿐만이 아니라 '성능 개선', '트래픽 처리'를 주제로 어떤 기술을 도입을 할지 고민을 하는 시점이 있었다. 그때 당시 ELK-Stack을 활용한 로그 수집과 프로젝트 전체 인프라 구축 및 Top-10 인기 검색어 서비스와 알림 서버 구현 등 필자가 맡은 역할은 모두 완료한 상태였다. 어떠한 기술을 도입할 지 고민하고 있을 때 많은 기업 공채에서 'kafka를 적용해본 경험이 있는 분' 이라는 글을 상당히 많이 봤었다. 그게 대체 뭐길래? 기업들이 찾는건지 그때 당시에는 정확히 알지 못했다. 모놀리식 아키텍처가 아닌 MSA 환경의 아키텍처 설계를 현재 수많은 기업들이 채택하고 활용하고 있다. 카프카는 MSA 구조에서 상당히 효율적으로 활용할 수 있는.. 기술적 선택 2023.07.23  0
[대규모 시스템 설계] 3. 분산 시스템을 위한 유일 ID 생성기 설계 프로젝트를 진행해봤다면 DB를 하나 정도는 활용해봤을 것이다. 하지만, 같은 용도로 활용하는 DB 서버를 분산시켜서 트래픽을 분산시키는 작업을 진행하는 것은 실무가 아닌 이상 토이 프로젝트에 적용하는 것은 상당히 힘들 것이라고 생각한다. 'auto_increment' 속성이 설정된 관계형 데이터베이스를 통해 기본 키를 쓴다면 이것은 단일 서버에 한해서다. 분산 환경에서 이 접근법은 통하지 않는다. 분산 환경에서 여러 DB를 구축을 한다면, 어느 DB로 해당 PK 값으로 데이터 정보를 불러올 것인가가 문제다. 기본적으로 데이터베이스 하나를 이용한다면 PK 값으로 해당 데이터베이스에서 Select문을 날리면 된다. 그러나 데이터베이스 서버가 여러개라면 해당 PK값을 가진 데이터가 어느 데이터베이스에 존재하는.. 대규모 시스템 설계 2023.07.23  0
[기술적 선택] ELK-Stack 도입 이유 및 개념 협업 프로젝트를 하다보면 정해진 목표와 과제가 매일 주어지면서 각자 맡은 역할을 충실히 하는 것이 제일 중요하다. 특히나 프로젝트의 목표물을 만들기 위해 기본적인 API를 작성하고 로직을 설계하고 테스트를 하다보면 시간이 무척 빨리 지나간다. 프로젝트는 시간이 한정적이라 서비스를 만드는 것이 급급한 나머지 성능을 개선한다거나 새로운 기술에 도전하는 것은 상당히 힘든일이다. 필자는 그 시간을 쪼개고 쪼개서 새로운 기술 "ELK-Stack"을 활용한 로그 수집가로서 활동을 하게 되었다. 도입 이유 지금까지 프로젝트를 진행하면서 로그를 활용했던 경험은 단순히 데이터를 출력하기 위함이였다. 즉, 스프링 환경에서 로깅 레벨을 INFO로 설정하여 DTO의 값이 제대로 전달되었는지에 대한 확인차 체크하는 용도였던 것.. 기술적 선택 2023.07.22  0
[기술적 선택] Webflux의 적용한 이유와 동작 흐름 필자는 알림 서버를 활용하기 위해 WebFlux라는 웹 프레임워크를 활용하였다. 우리가 진행한 프로젝트는 개발자 커뮤니티 서비스를 만드는 것이였고, 내부적으로 여러 서비스를 제공한다. 해당 프로젝트는 옛 싸이월드 감성으로 제작된 프로젝트였기 때문에 일촌 신청, 방명록, 댓글, 일촌 수락 등 사용자의 커뮤니티를 활성화하기 위한 서비스가 주목적이다. 따라서 다른 사용자들이 요청한, 또는 작성한 컨텐츠들과 관련된 사람들에게 알림 서비스를 제공한다. 즉, 여러 클라이언트들이 동시다발적으로 컨텐츠 요청이 들어올 경우 이를 처리하기 위해선 동기적인 방식이 아닌 새로운 방식을 고민해봐야했다. 고민 끝에 blocking 방식보다는 적은 리소스로 동시성을 다루는 non blocking 방식을 생각하게 되었고, 일반적으로.. 기술적 선택 2023.07.22  0
[기술적 선택] SSE 웹 기술을 활용한 이유 (알림 기능) HTTP 프로토콜은 기본적으로 클라이언트가 요청을 보내고 서버에서 응답을 보내주면 연결을 끊어버린다. 채팅과 같은 서비스에서 계속 연결을 유지하고 응답 데이터가 지속적으로 이루어져야한다면? 서버가 전송하고 싶어도 연결이 되어있지 않기 때문에 보낼 수 없는 상황이 발생할 것이다. 그래서 이러한 문제점을 해결하기 위해 폴링, 긴 폴링, 소켓, SSE의 방식이 도입이 된 것이다. Polling 클라이언트가 주기적으로 서버에게 요청을 보내는 방식을 폴링이라고 한다. 즉, 일정시간마다 클라이언트가 서버에게 데이터가 새로 생겼는지 확인하고 새로운 데이터가 있으면 응답을 받는 것이다. 정말 단순한 방식이다. 하지만 단순한만큼 계속 요청을 한다는 점에서 리소스 낭비가 발생한다. 필자의 생각은 알림이 발생하지 않는 상황.. 기술적 선택 2023.07.22  1
[기술적 선택] Elasticsearch 데이터 구조와 설계 방안 엘라스틱 서치를 활용하여 로그 수집과 게시글 키워드 검색 기능을 구축하면서 의아한 부분이 있었다. 역색인 구조인 것은 알겠지만, 어떻게 데이터가 저장이 되고 데이터 다중화는 어떤식으로 진행이 되는지, 가용성은 어떻게 되는지 등이 개념이 잡히지 않았다. 이번 포스팅에서는 Elasticsearch의 데이터 구조가 어떤식으로 잡혀있는지 살펴보려고 한다. 개념 정리 위의 그림을 보면 클러스터, 노드, 샤드, 인덱스로 구성되어 있는 것이 보인다. 하나씩 살펴보자. 1. 클러스터 노드들의 묶음이라고 보면 된다. 클러스터로 묶인 노드들은 노드간 데이터 교환을 위해 http 포트 (9200-9299), tcp 포트 (9300-9399)를 열어둔다. 그러므로 노드 1로 입력된 데이터를 노드 2에서 읽을 수도 있고, 그 .. 기술적 선택 2023.07.22  0
[대규모 시스템 설계] 2. 처리율 제한 장치 필자는 처리율 제한 장치와 관련된 처리를 해본 경험이 없다. 프로젝트를 진행하면서 필수적으로 진행해야하는 것은 API 기능 명세에 작성된 주요 서비스 구현이 1순위이다. 그러다보니 트래픽에 대한 처리는 어느순간 후순위로 밀려나게 되었다. 하지만 이전 포스팅에서 언급한 것처럼 '성능 개선', '트래픽 처리' 등 개발자 관점에서 도전적으로 프로젝트에 접근하는 것을 권장한다. 물론, 하다보면 필자처럼 시간에 쫓겨 흐지부지될 때가 많지만 시간이 넉넉한 프로젝트를 한다면 새로운 기술에 접근해보자. 이번 장에서는 클라이언트와 웹 서버 사이에 로드밸런서가 아닌 또 다른 친구가 존재하는데 그 친구를 한 번 포스팅하고자 한다. 처리율 제한 장치가 무엇인가 네트워크 시스템에서 처리율 제한 장치는 클라이언트 또는 서비스가 .. 대규모 시스템 설계 2023.07.21  0
[대규모 시스템 설계] 1-3. 아키텍처 설계 무상태 (stateless) 웹 계층 오늘의 포스팅은 무상태 (stateless) 웹 계층을 시작으로 천천히 알아보자. 이전 포스팅에서 생각보다 많은 것을 배워봤다. CDN을 통해 정적 컨텐츠를 캐시하고 로드밸런서를 통해 웹 서버의 분산, 데이터베이스의 다중화 및 캐시 활용 등을 배웠다. 이제 웹 계층을 수평적으로 확장하는 방법을 배워볼 순서인데, 사용자 세션 데이터와 같은 상태정보를 웹 계층에서 제거해야한다. 예를들면, 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하여 필요시 가져오게 하는 방법으로 말이다. 이렇게 상태정보를 웹 계층에서 제거하여 설계한 웹 계층을 무상태 웹 계층이라고 부른다. 1. 상태 정보 의존적인 아키텍처 무상태 웹 계층을 배우기전에 상태를 저장하는 웹 계.. 대규모 시스템 설계 2023.07.21  1
[대규모 시스템 설계] 1-2. 아키텍처 설계 데이터베이스 다중화대규모 시스템 설계에 있어서 가장 중요한 것 중 하나는 데이터를 어떻게 보관을 하냐이다. 보통은 서버 사이에 주(master) - 부(slave) 관계를 설정하고 데이터 원본은 주서버에, 사본은 부 서버에 저장하는 방식이다. 쉽게 말하면, 나루토를 보신 분들은 아시겠지만 나루토가 주(master)이고 그림자 분신술을 써서 만들어진 복제본들이 부(slave)인 것이다. 쓰기 연산(write)은 주(mastser)에서만 지원을 하고 부(slave)에서는 master에서 사본을 전달받아 읽기 연산만을 지원한다. 필자가 프로젝트를 진행하면서 학습했던 내용은 데이터베이스에 데이터를 변경하고 삽입하는 연산보다는 읽기 연산의 비중이 훨씬 높다는 얘기들 들었다. 해당 포스팅을 보는 여러분들도 벌써 .. 대규모 시스템 설계 2023.07.20  2
[대규모 시스템 설계] 1-1. 아키텍처 설계 지금까지 여러 프로젝트를 진행해왔지만 서비스를 더 키우거나 많은 사용자들의 유입이 들어왔던 경험은 없었다. 사실, 실무에서의 개발 경험이 없었기 때문에 위의 사례는 극히 드물다고 생각한다. 특히, "서비스를 런칭해야지!" 라는 거대한 포부를 가지고 개인, 팀 프로젝트를 진행을 해본 분들이 계시다면 팀 동료를 제외한 실사용자 100명을 채우는 것은 상당히 힘든일이라는 것을 공감할 것이다. 즉, 트래픽을 처리하기 위한 대규모 시스템 설계는 실무 경험이 없는 신입 개발자들이 경험하기는 힘들다는 것이다. 그러면 어떻게 해야하는가? 개인적으로 학습이 필요하고 그 학습을 토대로 아키텍처를 구상해야한다고 생각한다. 최근 1년간 싸피 교육으로 개인 공부를 소홀히 하였기에 다시 포스팅을 꾸준히 시작해보려고 한다. 이번 .. 대규모 시스템 설계 2023.07.17  0
[2023년 상반기 다우기술 웹 어플리케이션 개발] 신입 최종 합격 후기 서류 지원 싸피 3차 프로젝트를 진행하던 시점에 '다우기술' 기업의 공고가 올라왔다. 다우 기술 신입 개발자 초봉이 5100만원 정도라고 들었고 개발 기술을 배울 수 있는 상당히 좋은 기업이라고 생각했다. 개발 직무로는 "백 오피스 및 경영지원 시스템 개발" 신입 하나만 올라와있었기 때문에 해당 직무로 지원을 하였다. 지원 문항은 [자기소개], [지원동기], [직무적합성], [희망업무]에 대해서 작성하였다. 또한, 깃허브, 블로그, 포트폴리오를 기재할 수 있는 칸이 있었기 때문에 그동안 내가 정리해놨던 자료를 제출하였다. 지원 문항[자기소개]본인 성격의 강/약점에 대해서 실제 사례를 포함하여 작성해주세요. [지원동기]본인이 회사를 선택하는 기준을 바탕으로 우리 회사를 선택한 이유를 작성해주세요 [직.. 인터뷰 2023.06.06  4
[기술적 선택] JPA - Optimistic Lock 도입 이유 및 적용 방법 '바꾸바꾸' 프로젝트는 Voda, HelloWorld 이전에 싸피에서 진행한 공통 프로젝트이다. 해당 프로젝트에서 담당했던 역할 중에 다음과 같은 문제가 발생하였다. 바꾸바꾸 프로젝트(물건 교환 플랫폼)에서 물건 교환 신청을 요청할 때 하나의 아이템은 최대 10명의 사용자가 요청이 가능하다. 만약 하나의 아이템의 요청 상태가 7명일 때 5명의 사용자가 동시 요청을 하게 된다면, 그 중 3명의 사용자는 요청이 완료돼야하고 2명의 사용자는 요청이 취소돼야한다. 하지만 프로젝트 코드에서는 이러한 동시성 이슈 문제를 해결할 수 있는 로직이 구현되어있지않았다. 즉, 하나의 아이템에 12명의 사용자가 요청 완료가 처리된다. 왜 이러한 문제가 발생했는지, 그리고 이를 해결하기 위해 어떠한 기술을 도입했는지에 대한 회.. 기술적 선택 2023.06.06  0
[기술적 선택] Elasticsearch 도입 이유 및 성능 측정 ELK-Stack의 E는 Elasticsearch를 의미한다. 필자는 해당 기술을 사용해 로그 수집의 기능을 구현하였고, 또 한가지가 더 있다. Elasticsearch를 이용하여 프로젝트의 핵심 기능인 검색 서비스를 추가한 것이다. 필자가 진행한 프로젝트는 '개발자 커뮤니티 사이트'이며 지금의 티스토리처럼 게시글을 업로드할 수 있다. 또한, 게시글을 업로드하게 되면 남들이 올린 게시글들이 모두 통합된 커뮤니티 페이지에서 보여진다. 해당 페이지에서 찾고자 하는 키워드로 검색을 하면 제목에 해당되는 글뿐만 아니라 내용에도 해당 키워드가 존재한다면 검색이 가능하다. 그냥 관계형 데이터 베이스에서 like문을 활용하여 키워드 검색을 하면 되는 거 아니냐는 질문이 들어올 수도 있다. 하지만 키워드 검색을 위해 .. 기술적 선택 2023.06.06  2
[기술적 선택] 쿼리 성능 개선을 위한 INDEX 적용 프로젝트에서 쿼리 성능을 높이기 위해 아래와 같은 방식을 도입하여 로컬에서 성능 테스트를 하였다. 해당 테스트를 통해 쿼리 성능의 차이를 보고 프로젝트에 적용하게 되었다. 저장 프로시저 사용하기 프로시저란 SQL 문장을 선언해서 MySQL에 저장하고 해당 SQL 을 마치 함수처럼 사용하는 것이다. 즉, 만들어 두면 함수 호출하듯이 편하게 사용하는 것이다. 프로시저 활용 create database academy; use academy; 먼저, academy 라는 데이터베이스를 만들고 해당 데이터베이스를 사용한다. create table user ( id int not null, name varchar(100), campus varchar(100), class int, gi int, PRIMARY KEY .. 기술적 선택 2023.06.06  0
[문제점] - HelloWorld Project 문제점 I. SSE 연결 지연 현상 HTTP1.1 - Http2.0 문제점 해결 Server-sent Events 기법은 Web Browser의 간섭없이 Server에서 Web Browser 단방향으로 Event를 전송하는 기법이다. 즉, Web Browser가 Server의 Event를 Subscribe를 통해서 Server의 Event를 전송받는 기법이다. Web Browser에서 Server로는 Event를 전송할 수 없다. 위의 그림은 Server-sent Events 기법을 나타내고 있다. Web Browser는 Server에게 특정 Event를 Subscribe하는 요청 전송한다. 이후에 Server에서는 해당 Event가 발생시 Web Browser에게 해당 Event를 전송한다. 하지만, .. 인프라 구축과정 2023.06.05  0

[운영체제 12편] 페이징 세그먼테이션 (불연속 할당 방식) 운영체제 2022.05.27  6

[운영체제 11편] 메모리 할당 (연속할당 방식) 운영체제 2022.05.11  3

[운영체제 10편] 메모리 접근 운영체제 2022.05.08  3

[네트워크 4편] DNS와 로드 밸런싱 네트워크 2022.09.25  3

[네트워크 3편] TCP 와 UDP 네트워크 2022.09.03  4

[네트워크 2편] IP 주소 체계 네트워크 2022.08.22  6

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

최신 글

운영체제

네트워크

티스토리툴바

개인정보

단축키

내 블로그

블로그 게시글

모든 영역