[목차]310

• 

  [Java] HashSet의 비밀 개요 최근 코딩 테스트를 치룬적이 있는데 Set 자료구조에 값을 담고 추후 해당 데이터를 List에 담아서 오름차순 정렬을 해야하는 로직이 필요로 하였다. 하지만, 주어진 테스트 케이스는 Set에 들어있는 원소의 값을 List에 담고 반환해주더라도 정답으로 출력되었다. 그래서 오름차순 정렬을 잊은채 제출하고 다른 문제를 풀러 갔다. 만약 예제가 틀렸더라면, 바로 오름차순 정렬을 깜빡한 걸 인지하고 바로 수정하지 않았을까... 엄연히 내 실수긴 하다 ㅎ.. 하지만 조금 특이한게 Set에 삽입한 순서를 떠올려보면 정렬을 하지않으면 테스트 케이스도 틀려야했다. 지금까지 필자가 알고 있었던 HashSet은 중복을 허용하지 않고 정렬을 지원하지 않는다고 알고 있었는데 왜 오름차순으로 정렬된 테스트케이스를 맞출수 .. 개발 일지/Java 2023. 10. 4.

• 

  [기술적 선택] Spring Cloud Config & Spring Cloud Bus 개요 분산 시스템인 MSA 환경에서 구동되는 각 애플리케이션 서버(Spring Boot 기준)들의 설정 정보들은 application.yml에 기본적으로 세팅하게 된다. 만약, 이러한 설정 정보들을 변경하고 서버에 적용하기 위한 가장 간단한 방법은 서버를 다운시켰다가 재가동하면 된다. 쉽게 말하면, 인텔리제이를 활용하여 프로젝트를 많이 진행할텐데 application.yml 파일을 수정했을 때 해당 설정 정보들을 적용하기 위해서 인텔리제이의 우측 상단에 위치한 재생 버튼을 클릭하여 서버를 껐다가 다시 실행하면 된다는 것이다. 스프링 개발 경험이 있다면 남 얘기가 아니기 때문에 모두 경험해봤을 것이라고 생각한다. 필자 또한 프로젝트를 진행하면서 데이터베이스의 정보들이나 로깅 레벨을 설정하는 등 애플리케이션.. 프로젝트/기술적 선택 2023. 9. 9.

• 

  [기술적 선택] Spring Cloud Netflix Eureka & Spring Cloud Gateway 개요 프로젝트를 진행하면서 아쉬웠던 점은 조금 애매한 MSA 구조였다. 마이크로 서비스마다 서로 통신하는 것이 아니라 Front에서 A 서버로 요청을 진행하고 응답 데이터 반환 후 다시 Front에서 B 서버로 요청하면서 2번의 API 통신으로 비효율적으로 진행되었다. 즉, Front에서 A 서버의 요청 후 A 서버에서 B 서버로의 직접적인 통신은 없었다는 것이다. 또한, 프로젝트를 진행하면서 Nginx를 통해 로드밸런싱을 진행하였지만, upstream을 통한 라우팅 블록이 끝이였고, 구체적으로 어떠한 마이크로 서비스들로 로드 밸런싱을 할 것인지에 대한 구체적인 설계는 진행하지 않았다. 이번 포스팅은 이전에 진행했던 프로젝트를 다시 회고하면서 어떤 기술들을 도입하면 좀 더 유연한 아키텍처로 재탄생 시킬 .. 프로젝트/기술적 선택 2023. 9. 6.

• 

  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. 8. 25.

• 

  [Kafka] 고가용성과 리플리케이션 & 스프링 부트 테스트 개요 프로젝트를 진행하면서 ELK-Stack을 활용하여 로그 수집을 진행하였고 추가적으로 kafka를 도입하면서 안정화된 시스템을 구축하였다. 하지만, 프로젝트의 제한된 날짜 때문에 카프카의 큰 장점을 못살렸던 것이 너무 아쉽게 느껴졌다. 예를들면, 필자가 구성한 카프카는 단일 브로커로 구성하였기 때문에 카프카의 고가용성이라는 장점을 못살린 아키텍처가 된 것이다. 프로젝트 시즌이 끝나고 좋아하는 코딩 문제만 풀다보니 아쉽게 마무리했던 과거 프로젝트의 기억이 주마등처럼 지나가면서 '아차!' 하는 느낌을 받았다. 이전에 작업하던 카프카 관련 내용들은 이미 사라진 서버에서의 고대 작업물이 되었고, 개인 노션 저장소에 백업을 해두긴 하였지만 각 서버마다 복잡하게 얽혀있는 환경 설정 등으로 같은 세팅으로 로컬에 .. 개발 일지/Kafka 2023. 8. 9.

• 

  [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. 8. 8.

• 

  [대규모 시스템 설계] 5. 키-값 저장소 설계 - CAP 정리 이번 포스팅은 키-값 저장소 설계에 관한 주제이다. 자료구조 중 Map이라는 것을 활용을 해봤다면 Key-Value 구조라는 것이 무엇인지 이해가 갈것이다. 보통 키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스이며 memcached나 레디스 같은 것들이 존재한다. 키-값 자료구조 상 키는 유일해야하며 키를 통해서 값에 접근할 수 있다. 키는 일반 텍스트일 수도 있고, 해시 값일 수도 있다. 아무튼 성능상의 이유로 키는 짧을수록 좋다. 단일 서버 키-값 저장소 한 대 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다. 키-값 쌍 전부를 메모리에 해시 테이블로 저장하여 들고오면 되는 것이다. 하지만, 모든 데이터를 메모리에 두는 것은 불가능하다. 자원은 유한하기때문에 이러한 문제를 .. 개발 일지/대규모 시스템 설계 2023. 8. 7.

• 

  [기술적 선택] 무중단 배포 아키텍처 개념 및 Blue-Green 도입한 이유 개요 필자는 로컬 프로젝트를 4~5번 정도 진행을 해봤고 서비스 배포 프로젝트는 3번을 진행해봤다. 그 중 2번은 인프라를 직접 담당하며 CI&CD의 역할을 하였다. 첫 인프라를 담당하였을 때 EC2 서버 안에서 도커 가상화 환경의 이해와 컨테이너의 포트 연결, Nginx, Jenkins 등 여러 학습이 필요한 상태라 시간이 많이 소요되었다. 특히, 첫 인프라를 담당하였을 때 아키텍처 설계 완료 후 새로운 프로젝트가 빌드 될 때 웹 어플리케이션 서버(컨테이너)가 다운되고 새로 만들어진 프로젝트 기반의 도커 이미지를 가지고 컨테이너를 생성하게 된다. 이때 기존의 서버는 다운되고 새로운 서버가 로딩되는 그 시점에 서비스는 중단된다. 이러한 문제는 지속적인 서비스가 중단되고 사용자에게 불편함을 끼칠 수 있는 .. 프로젝트/기술적 선택 2023. 7. 24.

• 

  [대규모 시스템 설계] 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. 7. 24.

• 

  [기술적 선택] Top-10 인기 검색어 구현을 위한 레디스 도입 이유 필자가 진행한 프로젝트에서 Top-10 인기 검색어 서비스를 구현하기 위해서 어떠한 방식을 사용할지 고민을 했다. 사실 해당 서비스를 구현하기 위해 레디스에 대한 개념이 잡혀있지 않아서 데이터베이스에 접근을 해서 매번 카운팅 업데이트 쿼리문을 날려야 하는건가 생각을 했었다. 왜냐하면 지금까지 프로젝트를 진행하면서 여러 기술들을 사용해봤지만 메모리 기반의 분산 저장소를 직접 활용해본 경험이 없었기 때문이다. "Top-10 인기 검색어" 서비스는 개발자 커뮤니티에서 사용자가 요청한 검색 키워드를 이용해 타사용자들에게 실시간으로 인기 검색어를 시각적으로 제공해준다. 그렇다면 매번 사용자가 검색할 때마다 디스크에 접근하여 해당 키워드에 대한 카운팅 작업으로 갱신한다면 리소스 낭비가 매우 심할 것이라고 생각했다... 프로젝트/기술적 선택 2023. 7. 23.