개발하다 보면 Security, Filter, Validation 등 DDD의 관점에서 말하자면 어그리거트 별로 서로 다른 조건이 필요할 때가 있다. 이러한 부분을 세밀하게 관리하자면 Monolithic에서는 복잡한 조건 절로 분기하여 처리하게 될 것이고 이러면 유지보

이글은 공식 문서, https://esbook.kimjmin.net/07-settings-and-mappings/7.2-mappings/7.2.5-object-nested 를 참조하였다.ES는 역인덱스 구조를 가지고 있다. 따라서 인덱스의 Document Ma

모든 Setting은 Static이거나 DynamicPath, Cluster name, Node name, Network host, Discovery, jvm, Cluster backups등Transient: 1회성 설정Persistent: 영구 설정elasticsea

우리 회사는 System.out.println을 로거로 쓰고 있다. 그로 인해 생기는 불편한 사항을 한번 정리해 보자.로그가 계층화 되어있지 않음모든 로그가 catalina.out 하나의 파일에 찍힘후속적인 작업(로그를 Kafka나 Elastic로 보낸다던가 백업을 한

시작 왜 테스트를 해야할까?

layer는 presentation, application, domain, 로 나눔 보통사실 인프라라고 해봤자 mysql 밖에 안써봐서 마지막 2개는 거의 같이 쓰는거 같다.이부분은 사실 DB 설정이 복잡해지면 분리하는 것도 좋을 듯 하다.혹은 DB외에 많은 인프라적인

톰캣만 올린 상태커널 파라미터Xmx2G Xms2G메모리 총 사용량 14%톰캣만 올린 상태커널 파라미터open files 수정메모리 총 사용량 18%톰캣만 올린 상태커널 파라미터open files 수정max user processes 수정메모리 총 사용량 16%CPU 리

mod_jkTomcat Connector(별도의 모듈)를 사용하는 방식JKMount 옵션을 이용하면 URL이나 컨텐츠 별로 유연한 설정 가능ajp 프로토콜 사용mod_proxyReverse Proxy 기능을 사용하는 방식별도의 모듈 설치 불필요특정 WAS에 의존적이지

개발자는 회고를 통해 성장한다.항상 프로젝트가 끝난 후에 자신을 되돌아보며 문제점, 배운점, 나아진점을 회고해 보자.커뮤니케이션은 매우 중요한 요소이다.팀원과 좋은 관계를 형성하기 위해 나름의 노하우가 필요하다.팀원이 어려움에 처했을 때 솔직하게 말할 수 있는 환경을

TCP의 동작을 이해한다.TIME_WAIT 상태의 소켓 재사용으로 성능 향상goLang으로 다수의 Client 생성VMware로 서버 및 클라이언트 생성

SYN -> SYN + ACK -> ACKClient: SYN을 보내고 SYN-SENT 상태가 됨Server: ACK + (flag가 설정된 SYN)을 보내고 SYN-RECEIVED 상태가 됨Cleint: ACK를 보내고 ESTABLISHED 상태가 됨FIN -> AC

각 프로젝트 코드는 각 BRANCH에서 볼 수 있습니다.프로젝트 자료는 docs 패키지에서 볼 수 있습니다.목적 : 2022 스마일게이트 윈터 데브 캠프의 팀 프로젝트입니다인원 : 김성윤(BE),남정진(BE),이다혜(FE),김근범(AOS)기간 : 2022.01~2022

Signal 서버와의 모든 통신은 websocket을 통해 이루어 집니다.모든 유저의 접속 상태를 알 수 있음.초기에 로그인을 하면 모든 유저의 목록 & 상태를 불러옴누군가 로그인을 하면 signal 서버에서 연결된 모든 유저에서 someone_login을 보내 use

InnoDB 클러스터를 mysql 셸을 통해 생성할 수 있다.MySQL 3대를 준비하고 이를 하나의 클러스터로 묶는 작업이 모든 작업은 real mysql 8.0이라는 책을 참고 하였다.과정은 이미 책에 나와 있으므로 하면서 생긴 문제와 결과를 중심으로 포스팅 하겠다.

지난번의 LOLJOA 프로젝트의 실험을 통해 POD 개수와 1초 안에 늘어난 동시 접속자의 수의 상관관계를 알아봤다. 하지만 결과는 실망스러웠다. Auto Scaling하는 과정조차 Pod가 올라가고 liveness-Probe와 Readiness 프로브가 Pod가 완료

webRTC

Architecture: MSAAPIGateway: Spring Boot GraphQl(Webflux)Language: BackEnd: ( Kotlin, Java ) => Reactor3FrontEnd: Thymleaf(Html, css...)WebServer: Web

support for interaction models beyond request/response such as streaming responses and pushapplication-level flow control semantics (async pull/push o

HTTP/2란