Lob!

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글이며 기존에 작성했었던 CI / CD 글을 수정한 것입니다. 자동화되지 않은 개발 프로세스의 문제점 상용 서비스, 소프트웨어는 일반적으로 여러 명의 개발자가 협업을 진행하기 때문에 코드의 관리와 배포 후 발생하는 장애 대처 용도로 Git과 같은 버전 관리 도구를 사용하여 각 코드에 대한 이력과 메시지를 남기고 병합하는 과정을 거치게 됩니다. 이러한 프로세스를 계속 수행되다 보면 기존 코드(테스트, 스키마 설정 값, 충돌)와 문제가 발생할 수 있지만 이를 빨리 식별하지 못해 운영 환경에서 서비스 장애가 발생하는 경우가 있을 수 있습니다. 또한 개발, 운영팀이 수동으로 코드를 빌드하고 테스트 및 FTP 등의 프로토콜을 통한 패키지 전달 및 실행..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 복제가 필요한 이유? 우리가 제공하는 API 서비스는 일반적으로 Stateless 한 형태를 준수하여 개발하여야 합니다. 이는 State를 다른 서비스(RDBMS, Global Session Storage - Redis 등)에서 관리하게 하고, API 서비스는 필요에 의해 조회하도록 하여 Stateful로 개발하였을 때 발생하는 API 서비스 간의 상태 동기화 이슈나 확장성 저하 문제를 최소화할 수 있기 때문입니다. 이러한 구조는 트래픽 급증에 대응하는 Scale-out을 가능케 합니다. 이런 형태로 개발하게 되면 결국 다수의 API 서비스가 조회하는 State를 관리하는 서비스에는 대량의 부하가 전달되어 자연스레 해당 서비스에 장..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 장애 감지 알고리즘이 필요한 이유? 우리가 개발하는 서비스가 단일 시스템이 아닌 분산 시스템 구조를 지닌다면 특정 서비스에 장애가 발생하더라도 모든 서비스 노드에게 전파되지 않기 때문에, 사용자 요청으로 인해 식별되기 전까지 모를 수 있습니다. 장애가 발생한 서비스에 따라서 시스템에 잘못된 값을 설정하거나 중복이 발생할 수 있고 (Index Sharding Service) 사용자가 보는 캐싱된 데이터가 소실되는 경우도 발생할 수 있습니다. (Feed Cache Service 등) 물론 모든 장애가 서비스 종료, 충돌과 같은 완전 중단 상태를 의미하는 것은 아니며, 상황에 따라 부하로 인한 응답 지연, 네트워크 지연 이슈 혹은 데드락..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 그림에는 Redis가 표시되어 있지만 Ehcache, Memcached, Hazelcast, Caffeine Cache 등 다양한 구현체로 이를 구현할 수 있습니다. Read Cache Strategy Look Aside Cache 서비스에 사용자 조회 요청이 들어오면 우선 Cache에 저장된 데이터가 있는지 확인하는 전략입니다. 초반 Cache 성능 향상 및 트래픽 급증 대비를 위해 (Cache miss 감소) cache warm up을 수행하는 것이 좋습니다. 이 방식은 Cache에 장애가 발생하더라도 데이터베이스에 요청을 전달함으로써 Cache 장애로 인한 서비스 중단 발생을 대비할 수 있습니다. 하지만 조회 요청이 많을 경우..

현재 회사에서 운용하고 있는 Galera Cluster 관련 이슈를 해결하기 위해 학습했던 내용을 공유하는 글입니다. 개인의 이해도 부족으로 인하여 잘못된 내용이 포함되어 있을 수 있으며 트러블 슈팅이 아닌 원론적인 이야기만 나열하더라도 감안해주시고 피드백 부탁드립니다. Galera Cluster? Galera Cluster는 Mutl Master Cluster 구조를 지원하는 MySQL, MariaDB 등의 계열에 호환되는 Open Source입니다. 복제 구성시 Origin node와 Replica node 사이의 Eventual consistency로 일정 시간 동안의 데이터 부정합 문제를 해결하기 위해 적용할 수 있는 방법인 Synchronous replication에는 몇 가지 문제점이 존재합니..

대학이라는 울타리에서 나와 첫 직장을 가지고, 또 다른 직장으로 이직하고, 제가 공부했던 방법들을 회고하고 그것을 발표하는.. 인생 사에서 제일 뜻깊을 것 같은 한 해가 지나갔습니다. 올 한 해를 돌아보며 저는 “역동적”이었다고 표현하고 싶습니다. 변화를 위해 생각하고, 행동하고 준비해온 이 기간을 쉽게 잊지 못할 것 같습니다. 나는 얼마나 공부했나? 중점으로 공부했던 것들 : Spring Core, Security, Oauth, Mybatis, JPA, Docker, Kotlin, Redis, Database Concepts, Infra Concepts, Nginx, Prometheus, Grafana, JOOQ 아이디어, 개념, 도입 수준으로 공부했던 것들 : Spring Cloud, Batch, N..

금일 온라인으로 1시간 40분(Q&A 포함) 정도 진행했던 "(내가) 성장할 수 있었던 공부 방법 발표" 내용을 공유합니다. 개인 학습 방법을 공유하는 것이기 때문에 모두에게 맞지 않을 수 있습니다. 또한 말로써 전달된 부분은 누락되어 있기 때문에 참고해주시기 바랍니다. 목차 저는 이랬던 사람입니다. 대학 입학 전까지 컴퓨터 공학이라는 것을 몰랐습니다. 고등학생 때에는 수학, 영어보다 문학, 사회, 역사를 좋아했고 고3 때에는 일러스트레이터, 포토샵 등을 이용하는 그래픽스 디자인 작업을 1년 동안 공부하고 자격증을 취득했습니다. 저와 맞지 않아서 진로 고민을 하게되었고 고등학교 선생님을 통해 컴퓨터 학과를 알게되어 제 수시 성적으로 갈 수 있는 수도권 전문대학의 컴퓨터 정보학과로 무작정 입학했습니다. 소..

이 글은 Java 환경에서 Dynamic Proxy 기반의 기능들을 사용할 때 주로 발생하는 문제인 Self-Invocation을 Lambda를 통해 어떻게 회피할 수 있는지에 대한 내용을 담고 있는 글입니다. Dynamic Proxy, AOP에 대한 이론적인 부분(발생 원인, 호출 흐름 등)들은 다루지 않을 것이기 때문에 다른 글들을 참고하시길 바랍니다. https://www.slideshare.net/MoonGyeom1/2019-springaop https://blog.outsider.ne.kr/846 https://lob-dev.tistory.com/entry/Spring-AOP와-요청-인터셉트-개념 Lambda와 관련해서는 학습을 진행하며 작성한 글이기 때문에 잘못된 내용이 있을 수도 있습니다. ..

(2022-10-23 build.gradle.kts 포맷 및 써볼만한 기능 예시 추가) 이 글은 Service, Repository와 Test code만 가지는 간단한 예제만 포함합니다. (회사에서 도입된 것을 공부하고 있는 중이라 복잡한 예제를 글로 쓰기는 어렵네요. ㅎㅎ;) 상세한 내용은 JOOQ Document와 https://github.com/jOOQ/jOOQ/tree/main/jOOQ-examples 등의 링크를 참고하시길 바랍니다. JOOQ 란? Compile 시점에서 구문 오류를 파악 가능한 Type Safe 한 Native Query를 만들 수 있고, DB의 Table 정보를 기준으로 Entity를 생성하는 상용 소프트웨어 라이브러리입니다. 활발한 컨트리뷰트 활동과 질문이 이루어지고 있으..

이 글은 간단한 구현 예제만을 포함하고 있습니다. AOP에 대한 이론적인 부분은 기존에 포스팅한 https://lob-dev.tistory.com/entry/Spring-AOP와-요청-인터셉트-개념 을 참고해주시길 바랍니다. 프로젝트 구성 Web과 Lombok을 추가합니다. (해당 예제에서는 Web 관련 로직을 사용하진 않고, 통합 테스트만 작성합니다. ) 추가적으로 implementation 'org.springframework.boot:spring-boot-starter-aop' 의존성을 추가합니다. 우선 GreetingAspect를 통해서 Aspect를 적용할 수 있는 각 시점들을 확인해보겠습니다. Spring AOP는 xml를 통한 기본적인 설정 방식과 AspectJ에서 제공하는 Annotatio..