developer h1 developer h1

ElasticsearchException는 인덱스 명 불일치, 매핑 정보 불일치, 샤드 상태 손상, 쿼리 생성 불가, 클라이언트 연결 문제 등 다양한 원인이 존재할 수 있다.대부분 Elasticsearch 명령어를 사용해 원인을 찾을 수 있지만, 그렇지 못한 경우를 발견해 기록을 남긴다. Kotlin과 Java의 차이로 인해 발생Elasticsearch는 데이터를 조회할 때 클래스의 생성자를 확인하고, 생성자가 없다면 기본 생성자를 통해 객체를 생성한 뒤, 리플렉션을 통해 메모리에 로드한다.하지만 코틀린은 리플렉션을 기본적으로 지원하지 않기에, 생성자를 통해 객체를 생성하지 못했다면 위 예외가 발생한다. 또한 null 가능성이 서로 충돌하는 경우에도 발생할 수 있다.Elasticsearch는 데이터가 n..

이번 글에서는 지금까지 프로젝트를 분석하기 위해 사용해 온 도구들의 종류와 용도를 소개한다.  ELK - 로그 수집 및 분석 ELK Stack은 프로젝트에서 발생하는 로그를 수집하고 시각화하여 장애, 에러 패턴, 성능 문제를 파악하는 데 사용되는 도구이다. 구성 요소Elasticsearch : 저장과 검색을 위한 저장소.Logstash : 로그 데이터를 수집하고 Elasticsearch에 전달.Kibana : Elasticsearch에 저장된 데이터를 시각화하고 대시보드로 구성하여 모니터링.서버에 에러가 발생했을 때 발생 지점과 빈도를 파악하거나, 성능 저하의 원인을 특정 이벤트에서 찾고자 할 때 유용하다.  Prometheus + Grafana - 메트릭 기반 모니터링 및 시각화 이 조합은 시스템 메트..

ElasticSearch: 검색 엔진, 로그 저장소LogStash: SpringBoot의 Logback에 저장된 로그를 ElasticSearch로 전송Kibana: ElasticSearch에 저장된 로그를 시각화 테스트 편의성을 위해 세가지 스택을 Docker-Compose를 통해 실행networks: elk: driver: bridge services: # Elastic search 설정 elasticsearch: container_name: elasticsearch image: docker.elastic.co/elasticsearch/elasticsearch:8.15.3 ports: - 9200:9200 - 9300:930..

API-Gateway API-Gateway는 MSA가 떠오르며 그와 함께 필요성에 의해 탄생한 솔루션이다.API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고, API에 대한 인증/인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능 까지 많은 기능을 담당할 수 있다. API-Gateway는 다양한 활용 방법이 존재한다.이 글에서 모두 설명하지는 않고, 실제로 Potatalk 프로젝트에서 적용한 방식과 그 외의 기능을 간략히 소개한다.API 서버들의 엔드포인트를 단일화 MSA 아키텍처는 각각의 마이크로서비스 마다 별도의 엔드포인트에서 실행된다.API-Gateway를 적용하지 않을 경우, 클라이언트는 그러한 마이크로서비스의 정보를 확인해야 하는 번거로움이 있다.API-G..

WebSocket WebSocket은 HTTP와 같은 통신 규약이다.단방향 연결을 지원하는 HTTP와 호환되어, 실시간 양방향 연결을 지원한다.실시간으로 데이터 교환이 빠르게 이루어지는 서비스에서 주로 사용된다. WebSocket만으로도 저수준의 채팅 서비스를 개발하는 것은 가능하다.하지만 메시징 패턴(Pub/Sub)이나 고수준 핸들링을 구현할 클래스는 부재하다.간단히 말하면 채널이 단 한 개만 존재하며, 서버가 세부적인 핸들링을 구현하기 어렵다. STOMP STOMP는 위와 같은 WebSocket의 부족한 점을 보충해 주는 메세지 브로커이다.클라이언트에게 진입점을 제공하여 채널을 구독(SubScribe)하거나 그 채널에 메시지를 발행(Publish)하는 과정을 관리하고, 발행된 메시지를 구독자들에게 전..

프로젝트 링크 이번엔 다소 느슨하게 프로젝트를 진행할 예정이었던지라 타임라인을 올릴 생각이 없었지만, 지난 1달간 생각 이상으로 꾸준히 진행한 것이 뿌듯하여 업로드를 한다.1차적인 기능은 완성되었으나 API-Gateyway를 통한 인증/인가와 코드 리팩터링, 테스트 범위 확대 등 해야할 것들이 많이 남았다.개인적으로 타임라인은 계속 갱신하겠지만, 이 글이 갱신될지는 앞으로의 내 부지런함에 달렸다... 08.19주제 선정프로젝트 초기 구상도기능 목록 설계기능 마인드맵ERD 설계유저 플로우 차트 설계08.20WebSocket, STOMP, Pub/Sub 기술 이해WebSocket 통신 구조 학습 및 설계프로젝트 구조화08.21API 다이어그램 설계(1/3)Member-Service 회원가입 API 구현08...

요구 사항카카오톡 같은 경우 번호나 아이디를 알고 있다면 친구가 아니더라도 1:1 채팅방을 생성할 수 있으며, 요청-승인 과정도 필요하지 않다.디스코드와 같은 경우 아이디를 알고 있더라도 설정에 따라 친구 요청-승인이 필요하다.상대적으로 카카오톡은 개방적이고, 디스코드는 보수적인 정책을 띄고 있다고 볼 수 있다.이런 성격은 단체 채팅방에서도 느낄 수 있다.카카오톡은 초대자가 주도적으로 채팅방에 초대를 하면, 피대상자는 선택의 여지 없이 채팅방에 입장한다.디스코드는 초대를 받더라도 피대상자가 승인/거절을 선택할 수 있다.만약 카카오톡과 같은 개방적인 설계를 한다면 난이도가 쉬워지고 유저 플로우가 간단해 지겠지만, 내 성격 상 디스코드와 같이 피대상자가 주도적인 애플리케이션이 더 마음에 들었기에 위와 같이 ..

프로젝트 주제선정이번 프로젝트의 주제는 오래 전부터 관심 있었던 실시간 채팅 애플리케이션이다.해당 주제에 관심을 갖게 된 계기는 다음과 같다.채팅 서비스를 경험하지 못한 사람을 찾기 힘들 정도로 대중적인 서비스이다.주 기능이 아니더라도, 많은 도메인에서 보조 기능으로서 사용될 수 있다.아직 미경험인 Pub/Sub 통신 구조를 경험하기에 적합한 도메인이다.이번 프로젝트 또한 가벼운 범위의 애플리케이션으로 설계 할 것이며, 채팅과 회원 기능을 제외한 부가 기능은 아직까지 생각하고 있지 않다. 이전 프로젝트와 마찬가지로 MSA 구조를 채택해 지속적인 성장과 확장이 가능하도록 만들 것이다.범용성이 넓은 도메인인 만큼, 이전 프로젝트들과의 통합도 긍정적으로 보고 있다.프로젝트를 통해 이루고자 하는 것실시간 통신설..