개요? 최근에 프로젝트를 진행하면서, 리눅스 커널단의 설정에 의해 이슈가 발생하였다. 그래서 이번 기회에 TCP_TW 설정에 대해 알아보고자 한다. 이전에 이슈가 된 설정은 , 옵션이었는데, 이 옵션들은 상태의 소켓을 재사용하는 옵션이다. TIME_WAIT? TIME_WAIT 상태는 TCP 연결이 종료된 후, 일정 시간 동안 유지되는 상태이다. 이슈 최근 azure 의 를 세팅하면서 외부 요청에 대한 타임아웃이 발생하는 이슈가 있었다. 환경 AKS에 하나의 파드에 두개의 컨테이너를 띄운 상태 NAT 게이트웨이를 사용 이슈 시나리오 A컨테이너에서만 외부API를 호출하면 바로바로 응답이 옴 B컨테이너에서만 외부API를 호출하면 바로바로 응답이 옴 A컨테이너에서 외부API호출 후 바로 B컨테이너에서 외부API를 호출하면 타임아웃이 발생함 AKS초기 구성시에는 해당 현상이 발생하지 않았었다. 그런데, 어느 순간 해당 현상이 발생하기 시작했다. 서버 구축을 해주던 인프라팀에서 “tcp…

레디스를 적용해보자 시나리오 1. Coupon 이 생성 될때, 발행갯수만큼 CouponTicket(userId가 null 상태)을 DB에 저장한다. 2. 쿠폰 발급, CouponTicket의 ID를 Redis에 쌓는다. 3. 쿠폰 배급 Redis에 쌓이 CouponTicket을 가져온다. 가져온 CouponTicket이 이미 userId가 정해져있는지 DB에 확인하고 정해져 있지 않다면 userId를 맵핑하고 저장한다. 쿠폰티켓 결과를 반환해준다. 구현 1. Coupon 이 생성 될때, 발행갯수만큼 CouponTicket(userId가 null 상태)을 DB에 저장한다. 2. 쿠폰 발급, CouponTicket의 ID를 Redis에 쌓는다. 여러 방법이 있겠지만, 스케쥴러를 적용해보기로 했다. 일정 갯수 이하일때 Redis에 쌓기. Redis 설정하기 스케쥴러 적용 1초에 한번씩 체크 2000개 이하일때 10000개씩 밀어 넣게 구현 3. 쿠폰 배급 Redis에 쌓이 CouponT…

새로운 요구사항 팀장: 잘 구현 해주셨군요. 대략적인 쿠폰 발행에 대해 이해도가 높아진것 같네요. 서버로 이제 구현해주세요. 세팅하기 발급 서비스 동시 요청 테스트 오래걸리는 작업은 까지 나왔다. 좀 더 빨리 할 수 없을까? 고민이 되었다. 이미 발급이 종료되었다면 빠르게 리턴하면 좋지 않을까? 테스트 결과 로 절반 정도 시간이 단축되었다. 중간점검 쿠폰이 발급해야되는 양만큼 정확히 발급 테스트 완료 100ms 이하 처리 속도 테스트 완료 서버 부하 테스트를 위한 준비 컨트롤러 CouponTicket 또한 발급하고 데이터 베이스에 저장 코드를 추가하였다. 부하 테스트 API 부하 테스트를 진행하고자 한다. 부하 테스트는 응답시간만 간단하게 체크 할 것이기 떄문에, K6 부하 테스트를 활용한다. k6.io K6 테스트 스크립트 높은 트래픽에서의 속도만 측정할것이기 때문에 시간은 길게하지 않았다. 응답시간이 만족스럽지 않다. 어디에서 지연이 되는걸까? 아무래도 “CouponTic…

요구사항 팀장 : 다음주에 99% 할인 쿠폰 발행 행사를 하려고하는데, 다음주 까지 개발해주세요. 요구사항은 다음과 같습니다. 쿠폰은 최대 발행 갯수를 가지고 있습니다. 쿠폰은 발행 갯수 만큼 발급 할 수 있습니다. 쿠폰 발행 갯수 보다 쿠폰티켓을 초과 발급 할 수 없습니다. 대규모 트래픽에서도 쿠폰 발행 갯수를 초과해서는 안된다. 응답시간은 요청당 100ms이하로 한다. 정의 쿠폰 최대 발행 갯수를 가진다. 쿠폰티켓 발행된 갯수를 가진다. 쿠폰티켓 발행 갯수는 최대 발행 갯수를 초과 할 수 없다. 쿠폰 티켓 발행한 쿠폰이 존재한다. 쿠폰 티켓을 소유한 유저ID 를 가지고 있다. 도메인 우선 도메인 부터 파악해보고자 한다. 쿠폰은 쿠폰티켓을 발급 할 수 있다. 쿠폰 티켓이 발급될때 발급 카운터를 증가시킨다. 동시요청 호출에도 안전할까? 쿠폰 발행은 동시에 여러 요청이 들어올 수 있다. 이때 동시에 여러 요청이 들어오면 어떻게 될까? 동시요청 테스트 시나리오 100개 발급 제한 쿠…

1. IoC(Inversion of Control)란? 의존성 관리를 외부에 하여 객체의 생성과 관리를 제어하는 개발 패턴 2. 누가? 왜? 누구한테 위임하는가? 주로 프레임 워크에 위임합니다. 대표적으로 Spring 프로레임워크라고 볼 수 있겠습니다. 왜 위임하는가? 개인적으로 생각하는 위임하는 주요 장점중 하나는 개발자가 비즈니스 로직에 집중할 수 있다는 것입니다. 그렇다면, 정도로 보면 되겠네요. 3. 예시 DI에서 활용했던 코드를 사용해서 탐구해보겠습니다. 일반적으로 개발자가 객체를 생성관리 한다면 다음과 같을 것입니다. 그렇다면, 객체생성을 프레임워크에 위임하다고 하는데 그러한 패턴을 코드로 우선 보겠습니다. 란 객체에게 의 을 달라고 하네요 🤔 그런데 여기서 중요한 부분은 확실하게 를 사용하지 않은것으로 봐서는 객체 생성을 프레임워크에 위임한 것으로 볼 수 있습니다. 🚫그런데 실행했더니 에러가 발생하네요 🤔 Spring 의 마법을 보기위해서 무언가 설정이 더 필요한가…

1. DI(Dependency Injection)란? 의존성 관리를 위해 사용되는 디자인 패턴입니다. DI의 핵심 아이디어는 “제어의 역전(Inversion of Control)“입니다. 일반적으로 객체는 자신이 사용할 의존성을 직접 생성하거나 찾아내는 책임을 갖고 있습니다. 하지만 DI에서는 객체는 의존성을 요청하기 위해 컨테이너 또는 프레임워크에 의존합니다. 이렇게 함으로써 객체는 자신이 사용할 의존성을 외부에서 제공받게 되고, 의존성의 생성과 관리는 외부에 됩니다. DI를 통해 객체 간의 결합도를 낮출 수 있으며, 유닛 테스트 작성과 코드 재사용을 쉽게 할 수 있습니다. 또한 DI 컨테이너를 사용하면 의존성의 라이프사이클 관리와 의존성 간의 관계 설정을 자동화할 수 있습니다. DI 프레임워크로는 Spring, Nest 등이 있습니다. 좋은 DI 설계는 모듈화와 확장성을 개선하며, 코드를 더 테스트 가능하고 유지보수하기 쉽게 만들어줍니다. 2. 예시를 통해 알아보는 DI 장점.…

kafka connect란? Confluent 카프카 설명 인용 링크 Kafka Connect Kafka Connect는 Apache Kafka와 다른 데이터 시스템간에 데이터를 확장 가능하고 안정적으로 스트리밍하기위한 도구입니다. 대규모 데이터 세트를 Kafka 안팎으로 이동하는 커넥터를 간단하게 정의 할 수 있습니다. Kafka Connect는 전체 데이터베이스를 수집하거나 모든 애플리케이션 서버의 메트릭을 Kafka 토픽으로 수집하여 짧은 대기 시간으로 스트림 처리에 데이터를 사용할 수 있습니다. 내보내기 커넥터는 Kafka 주제의 데이터를 Elasticsearch와 같은 보조 인덱스 또는 오프라인 분석을 위해 Hadoop과 같은 배치 시스템으로 전달할 수 있습니다. Kafka Connect 및 Kafka 커넥터의 기초 인용 Kafka Connect는 커넥터를 사용하여 데이터베이스, 키-값 저장소, 검색 색인 및 파일 시스템과 같은 외부 시스템 과 Kafka를 연결하기위한 프…

CSRF(사이트 간 요청 위조(Cross-Site Request Forgery)? 웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 해서 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법이다. 2008년에 발생한 옥션의 개인정보 유출 사건에서도 관리자 계정을 탈취하는 데 이 방법이 사용되었다. 공격의 난이도가 높지 않아 흔히 사용된다. -나무위키- 사례 2006 년 Netflix 웹사이트에는 CSRF에 대한 수많은 취약점이 있었습니다. 이 취약점으로 인해 공격자는 피해자의 대여 대기열에 DVD를 추가하거나, 계정의 배송 주소를 변경하거나, 계정을 완전히 손상시키기 위해 피해자의 로그인 자격 증명을 변경하는 등의 작업을 수행할 수 있었습니다. ING Direct 의 온라인 뱅킹 웹 애플리케이션은 불법 자금 이체를 허용하는 CSRF 공격에 취약했습니다. 인기 동영상 웹사이트 YouTube 도 2008년에 C…

XSS? XSS(Cross-site Scripting)란 SQL injection과 함께 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말한다. 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되며, 보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취한다. 공격방법 Stored XSS Stored XSS는 사이트 게시판이나 댓글, 닉네임 등 스크립트가 서버에 저장되어 실행되는 방식 Reflected XSS Reflected XSS는 보통 URL 파라미터(특히 GET 방식)에 스크립트를 넣어 서버에 저장하지 않고 그 즉시 스크립트를 만드는 방식 대부분은 Stored XSS라고 생각하면 된다. Reflected XSS의 경우 브라우저 자체에서 차단하는 경우가 많아 상대적으로 공격을 성공시키기 어렵다. -나무위키- 대응방법 문자입력을 작성한 그대로 입력하지 않는다 문자를 필…

“Unit Testing - 블라디미르 코리코프 지음” 책을 학습하여 일부 내용을 요약하였습니다. 단위 테스트의 목표 테스트로 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다. 새로운 요구 사항에 더 잘 맞게 리팩터링한 후에도 기존 기능이 잘 작동하는지 확인하는데 도움이 된다. 테스트 초반에 (상당한)노력이 필요하다. 그러나 프로젝트 후반에도 잘 성장할 수 있도록 하므로 장기적으로 보면 그 비용을 메울 수 있다. 지속성과 확장성이 핵심이며, 이를 통해 장기적으로 개발 속도를 유지 할 수 있다. 잘못 된 테스트 잘못된 테스트는 초반에 코드가 나빠지는것을 늦출 수는 있다. 테스트가 없는 상황에 비해 개발 속도가 덜 느려진다. 그러나, 잘못 된 테스트로 진행한다면 시간이 지남에 따라 프로젝트 침체단계를 필할 수는 없다. 제품 코드 대 테스트 코드 제품코드와 테스트 코드는 다르다고 생각하지만 다르지 않다. 테스트 코드가 많을수록 좋다고 생각하지만, 그렇지 않다. 코드는 자산이 아…

개발 하던중 이벤트 발생 서버와 처리하는 서버가 다를 경우 이벤트 전달에 대해서 고민을 한적이 있습니다. 그때에, “마이크로서비스 이렇게 한다”책을 보게 되었는데 책에서 라는 기술이 있다는것을 알게 되었습니다. 이후 기술에 대해 관심을 가지게 되었고, 를 활용한다면 서버간의 유연함을 유지하면서 이벤트 기반 아키텍쳐를 구현 할 수 있을것 같았습니다. 이번 글에서는 Kafka와 CDC 를 위한 분산 플랫폼 Debezium 의 세팅하고 기본 사용하는 부분에 대해서 알아보겠습니다. 카프카란? Kafka는 실시간 이벤트 기반 애플리케이션 개발을 가능하게하는 오픈 소스 분산 스트리밍 플랫폼이다. debezium 이란? Debezium 이란 CDC 를 위한 오픈 소스 분산 플랫폼입니다. 데이터베이스 커밋으로 발생하는 삽입,업데이트,삭제를 감지하고 인벤트를 발생 시킵니다. Apache Kafka 를 기반으로 구축 되었습니다. CDC 란? CDC 는 Change Data Capture 의 약자입니…

“AWS 망분리” 인프라 담당이 아니라면 깊이 있게 알기 힘들겠지만, 기본적으로 알아야 하는 부분이 있다고 생각합니다. “망분리”에 대해 알아 보겠습니다. 망분리?? 망분리란 내부망과 외부망 등을 분리하여 외부의 침입을 막는거나 보안 이슈를 관리하기 위함입니다. 예를 들면, 중요한 DB 혹은 사내전용 서버 등을 내부망(사내망)으로 분리하여 외부 노출을 분리합니다. 일반 고객이 접속해야하는 웹서비스 같은 경우 외부망을 오픈하여 외부 인터넷과 접속 할 수 있게 합니다. 개인적인 실무 경험상(일반적인 웹개발자) 심리적으로 굉장히 안정이 됩니다. 인프라 혹은 보안 담당자 없이 AWS 구축하다 보면 무분별하게 생성되는 , 그리고 설정 등 시간이 지날 수록 서버 관리 영역이 관리가 힘들 정도로 난잡해 집니다. 그때 과 을 분리해 보았는데 관리적인 측면에서 굉장한 이득을 볼 수 있었고, 작은 팀에서 AWS 로 서비스를 운용할때 보안의 불안함이 있는데 이부분에 대해 어느정도 주는 경험했었습니…

TDD 란? TDD 란 Test Driven Development 의 약자로 “테스트 주도 개발”이라고 합니다. TDD 의 장점 출처 코드 품질 TDD 는 개발자가 단순한 설계를 할 수 있도록 도와줍니다. 일반적으로 OOP 구조를 유지할 수 있습니다. 애플리케이션 품질 TDD 는 프로덕션 코드를 구현하기 전에 먼저 테스트를 해보고 프로덕션 코드를 구현 할 수 있습니다. TDD 를 통해 프로덕션 코드를 점진적으로 개발해 나가므로써, 철저한 테스트와 적은 버그를 발생 시킬 수 있습니다. 생산성 향상 디버깅 시간을 줄일 수 있습니다. TDD 로 개발을 시작하면 초기에는 시간이 많이 소요 될 수 있습니다. 하지만, 새로운 기능 추가 및 테스트 시간이 더 빨라지고 든든한 테스트가 있기때문에 리팩토링에 부담을 줄일 수 있습니다. 문서 테스트 코드는 문서 역할을 할 수 있습니다. 잘 정리된 테스트코드 가 있다면, 테스트 코드로 프로젝트를 이해 할 수 있습니다. 뿐만 아니라 모든 코드를 이해 하…

학습목적으로 작성되어 생략된 내용과 다소 부적확한 내용이 있을 수 있습니다. 다루는 내용 @Entity, Jpa 연관관계, 편의메소드, @Embedded , @Embeddable 예제로 사용해볼 관계도 테이블 과 테이블이 있습니다. 이때 는 여러개 의 을 작성 할 수 있습니다. 위의 테이블 구조로는 가 작성한 이 어떤것 인지 알수 없습니다. 그래서 이때 relation id 를 둘중 하나의 테이블에 저장 해두어야 합니다. 한명의 가 여러개의 를 가질 수 있으므로, 테이블에 관계 ID를 저장하도록 변경합니다. 테이블에 컬럼은 테이블의 고유 입니다. 데이터 User 테이블 id name password 1 name1 pass1 2 name2 pass2 3 name3 pass3 Post 테이블 |id|user_id|title|contents| |------|---|---| |1|3|제목 123|내용| |1|3|제목 748|내용| |2|1|제목 189|내용| |3|2|제목…

참조블로그 : https://asfirstalways.tistory.com/350 빌더 패턴 한번에 인스턴스를 생성하고 싶은데 생성자 인자가 너무 많을때 혹은 기본 생성자로 인스턴스를 만들고 setter 로 점진적으로 값을 주입시킬때 이럴때 빌더 패턴을 사용하면 장점이 있습니다. 빌더 패턴을 사용하지 않은 예 생성자 생성 인자가 너무 많다보니, 순차적으로 뭐가 들어가는지도 헷갈리기 시작합니다. 혹여나 실수로 위치를 다르게 넣을 수 도 있을것 같습니다. 빌더 패턴 적용 예 빌더 패턴을 사용하면 많은 생성자 인자를 명시적으로 맵핑 할 수 있는 장점이 있고, 기본 생성자를 만들고 로 순차적으로 맵핑하는 것보다 한번에 인스턴스를 생성 할 수있습니다. 한번에 그리고 명시적으로 파라미터를 맵핑 할 수 있는 장점이 있는 빌더 패턴을 알아보았습니다.

정적 메소드 팩토리 정적 메소드 팩토리를 사용하면, 의미있는 이름의 생성자를 제공 할 수 있는 장점이 있습니다. 참조 글 baeldung.com/java-constructors-vs-static-factory-methods 1.생성자에는 의미 있는 이름 이 없으므로 항상 언어에서 부과하는 표준 명명 규칙으로 제한됩니다. 정적 팩토리 메소드는 의미 있는 이름을 가질 수 있으므로 그들이 하는 일을 명시적으로 전달합니다. 2.정적 팩토리 메서드는 메서드, 하위 유형 및 기본 형식을 구현하는 동일한 유형을 반환할 수 있으므로 보다 유연한 반환 유형 범위를 제공합니다. 3.정적 팩토리 메서드는 완전히 초기화된 인스턴스를 미리 구성하는 데 필요한 모든 논리를 캡슐화 할 수 있으므로 생성자에서 이 추가 논리를 이동하는 데 사용할 수 있습니다. 이것은 생성자가 필드를 초기화하는 것 이외의 추가 작업 을 수행하는 것을 방지 합니다. 4.정적 팩토리 메소드는 제어된 인스턴스 메소드 일 수 있으며 싱…

of 와 from 의미가 뭘까? 문득 코딩을 하다 궁금해졌습니다. 메소드의 이름으로 사용되는 of 와 from 의 의미에 대해서 알고 싶어졌습니다. 구글 검색결과 oracle - java documentation stackoverflow 등등 에서 정보를 찾을 수 있었습니다. 오라글 문서에서 정의하는 메소드 네이밍 컨벤션은 아래와 같습니다. Prefix Method Type Use of static factory 팩토리가 주로 입력 매개변수의 유효성을 검사하고 변환하지 않는 인스턴스를 만듭니다. from static factory 입력 매개변수를 대상 클래스의 인스턴스로 변환합니다. 이 경우 입력에서 정보가 손실될 수 있습니다. parse static factory 입력 문자열을 구문 분석하여 대상 클래스의 인스턴스를 생성합니다. format instance 지정된 포맷터를 사용하여 임시 개체의 값을 형식화하여 문자열을 생성합니다. get instance 대상 객체 상태의 일부를 …

위 코드 출력 결과 는 입니다. Collections.unmodifiableList 으로 반환된 객체는 결국 원본객체의 참조입니다. 그러므로 원본 객체가 수정되면 으로 반횐된 도 동일한 값을 가집니다. 그러나, 는 불변객체 이므로 수정 삭제가 불가능합니다.

Java Enum 활용기 참고하여 작성되었습니다. 자바 이넘 자비 enum 을 활용하면 상태와 행위를 한곳에서 관리할 수 있는 장점에 대해서 알아 보겠습니다. 예시로 로또 상금 로직 구현해보면서 파악해보겠습니다. 우선 Enum 미적용된 코드부터 살펴 보겠습니다. Enum 으로 적용안되었을 경우 클래스는 맞춘 로또 숫자에 따라 상금을 반환해주는 메소드를 가지고 있습니다. 우선 위 코드는 확장성에 취약한 상태입니다. 만약에 4등의 상금이 줘야하는 추가 요구상황이 주어졌다면 어떻게 될까요? 이처럼 상태와 로직을 각각 수정해주어야 합니다. 클래스의 인스턴스 변수와 메소드가 같이 있어서 그나마 나아보일 수도 있지만, 위 예제는 단순한 예제이고 복잡해질 경우 유지보수와 확장성에서 어려움을 격을 수 있습니다. Enum 을 활용한다면 어떻게 될까요? 테스트 코드 위 Enum 에도 4등이 빠져 있습니다. 4등을 추가 해주고 싶다면 위 코드만 추가해주면 확장 할 수 있습니다. 이는 상태와 로직…

로 다양하게 테스트 해보기 다양한 파라미터로 테스트 할때 유용하게 사용됩니다. 5보다 작은 숫자 테스트 위 코드 처럼 6이하의 케이스를 테스트 하고싶다고 할때, 중복된 코드가 많이 발생하게 됩니다. 이러한 부분을 을 사용해서 리팩토링 해보겠습니다. 를 활용해서 테스트가 진행될때 숫차적으로 인자로 부여되면서 진행됩니다. 이 외에도 등 다른타입도 적용가능합니다. 한개 이상의 인자를 사용하고 싶을때? 위 예제는 5보다 작은 숫자 테스트 였습니다. 그런데 {숫자}보다 작은 숫자 테스트 하고싶을때는 아래와 같은 방법을 사용 할 수 있습니다. 의 기본 구분자는 입니다. 만약 다른 구분자를 사용하고 싶을때는 를 통해 다른 구분자를 사용해서 분리 시킬수 있습니다. Primitive type 타입 외 객체 부여하기 을 사용하면 다양하게 인자를 사용할 수 있습니다. 메소드처럼 인자를 정의하고 를 통해 메소드 이름을 정의하면, Primitive type 말고도 다양하게 테스트 할 …

#이터레이터(Iterator) 란? 반복자(iterator)는 객체 지향적 프로그래밍에서 배열이나 그와 유사한 자료 구조의 내부의 요소를 순회(traversing)하는 객체이다. (위키백과) Iterator 는 컬렉션 프레임워크에 속하는 인터페이스입니다. 컬렉션을 탐색하고 데이터 요소에 액세스하며 컬렉션의 데이터 요소를 제거할 수 있습니다. Iterator 메소드 Iterator.hasNext() : 다음 요소가 있으면 true 를 반환 Iterator.next() : 다음 요소를 반환 Iterator.remove() : 현재 요소를 제거 example code Iterator 를 잘 활용하면 코드를 단순화하고 일반화 할 수 있을 것 같다.

객체지향 생활 체조 총정리 규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다. 규칙 2: else 예약어를 쓰지 않는다. 규칙 3: 모든 원시값과 문자열을 포장한다. 규칙 4: 한 줄에 점을 하나만 찍는다. 규칙 5: 줄여쓰지 않는다(축약 금지). 규칙 6: 모든 엔티티를 작게 유지한다. 규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 규칙 8: 일급 콜렉션을 쓴다. 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다. (developerFarm 개발자 농장 포스팅 내용) 객체지향 생활 체조 9가지의 원칙은 어떻게 보면 당연하거나, 까다롭게 느껴질 수 있다. 모든 경우에 적용 할 수는 없겠지만 9가지 규칙이 몸에 베인다면 깔끔하고 일관된 코드를 작성 할 수 있을 것 같다. 규칙을 지키며 작은 프로젝트를 진행 해보았는데. 프로젝트 전반적으로 객체지향,클린코드,리팩토링 측면에서 많은 도움이 되었다. 만 지키더라도 코드의 가독성이 많이 향상 된다는 것을 느꼈다.

Balls 는 ball 리스트를 가집니다. ball 은 최소(MIN), 최대(MAX) 조건이 있는 타입입니다. balls 는 특정한 조건을 가지기 때문에 위 코드 처럼 별도의 검증처리를 해줍니다. 단순히 변수의 이름 “balls” 로 정의 된것이 아닌 좀더 객체지향의 관점에서 본다면 어떨까요? 이렇게 말입니다. 에서 정의 했을 뿐인데, 편안함이 느껴지지 않나요? ^^?;;;;; 는 단순히 Integer 를 가진 변수일까? 어떤 조건이 있는 것 일까? 코드를 처음 보는 사람은 고민을 하게 됩니다. 만약에 객체가 1000줄 짜리 코드이고 거기에 인스턴스 변수였다면, 수정하거나 값을 추가하기 부담스러울 것입니다. validation 하는 부분을 찾기 힘들거나 찾았다 하더라도 정말 그것만으로 다 인가? 하는 의구심이 들기 때문입니다. 어떠한 객체가 있는데 그 객체가 최소(MIN), 최대(MAX) 조건이 있는 타입의 객체라면 어떨까요? Ball.class 로 원시 값 포장을 해보았…

캡슐화 객체의 속성(data fields)와 행위(메서드)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉한다. (위키피디아) 디미터 법칙(Law of Demeter) 각 유닛은 다른 유닛에 대한 제한된 지식만 가지고 있어야 합니다. 현재 유닛과 “밀접하게” 관련된 유닛만 있어야 합니다. 각 유닛은 친구들과만 대화해야 합니다. 낯선 사람과 이야기하지 마십시오. 가까운 친구에게만 이야기하십시오. (위키피디아) 캡슐화는 외부로부터 내부 로직을 감춤으로써(은닉), 객체의 내부 데이터와 메소드의 응집도가 생깁니다. 이러한 부분은 스스로 자율적인 객체가 되는 이점이있습니다. 프로젝트가 커지거나 유지보수를 해야할때 추가 또는 수정되는 코드의 비용을 줄일 수 있습니다. 또한, 데이터와 메소드의 응집도가 생기므로 팀단위 개발 또는 규모가 커질때 파편화된 코드를 줄일 수 있고 중복된 코드를 방지 할 수있습니다. 캡슐화를 적용하지 않은 코드 예시 MemberTest 에서 으로 Role 에…

“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.” 소프트웨어 개발 작업에 이용된 많은 모듈 중에 하나에 수정을 가할 때 그 모듈을 이용하는 다른 모듈을 줄줄이 고쳐야 한다면, 이와 같은 프로그램은 수정하기가 어렵다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 재조직(리팩토링)하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다. 1. 확장에 대해 열려 있다. 이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 즉, 모듈이 하는 일을 변경할 수 있다. 2. 수정에 대해 닫혀 있다 이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. …

SOLID 원칙 - SRP (단일 책임 원칙) 한 클래스는 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다. 로버트 마틴은 책임을 변경하려는 이유로 정의하고, 어떤 클래스나 모듈은 변경하려는 단 하나 이유만을 가져야 한다고 결론 짓는다. 예를 들어서 보고서를 편집하고 출력하는 모듈을 생각해 보자. 이 모듈은 두 가지 이유로 변경될 수 있다. 첫 번째로 보고서의 내용 때문에 변경될 수 있다. 두 번째로 보고서의 형식 때문에 변경될 수 있다. 이 두 가지 변경은 하나는 실질적이고 다른 하나는 꾸미기 위한 매우 다른 원인에 기인한다. 단일 책임 원칙에 의하면 이 문제의 두 측면이 실제로 분리된 두 책임 때문이며, 따라서 분리된 클래스나 모듈로 나누어야 한다. 다른 시기에 다른 이유로 변경되어야 하는 두 가지를 묶는 것은 나쁜 설계일 수 있다. 알아보기 회원정보가 있다. 회원 정보에…

Kafka Connect를 활용하여 File Source 해보기 kafka, zookeeper가 실행되어있어야 합니다.(카프가가 없으시다면 공식 홈페이지에서 다운로드) (처음 이시라면 참고) kafka/config 폴더를 열어보면 아래의 파일들이 존재합니다. connect-file-sink.properties connect-standalone.properties 위 파일들을 확용하여 File을 감시해보겠습니다. config/connect-file-source.properties 위 설정 파일은, connect 이름 / connect 라이브러리(connect class) / Source Topic 이름 등등을 설정 할수 있습니다. config/connect-standalone.properties 카프카 서버 주소 설정 / Source key, value 타입 지정 / 감시할 파일 이름 등등을 설정 할 수 있습니다. 실행 해보기 기본 설정 파일에 대해 알아보았고 실행 예제를 알아보겠…

컨슈머 그룹? 지난번 카프카 파티션(링크) 에 대해서 알아 보았습니다. 파티션을 만듬으로인해 Producer가 대량으로 토픽을 전송 하였을때, 토픽을 저장 할 때 병목현상을 해결 할 수 있는 이점을 알 수있었습니다. 그렇다면, 받는입장(Consumer)에서는 어떨까요? 시나리오 이벤트 발생(Producer)이 10대의 서버에서 발생 Consumer 1대 위 와 같은 상황이라면, 이벤트를 처리하는(consumer) 속도보다 이벤트를 쌓는(producer)가 더 많을 것으로 예상됩니다. 그렇다면, 컨슈머 또한 늘려서 해소해야 될것같습니다. consumer group을 활용하여 이벤트를 분산 수행 하는것에 대해알아 보겠습니다. 의문, 컨슈머를 여러대 만들면 되는거 아닌가? 네, 만약 컨슈머 그룹이 아닌 컨슈머를 여러대 만든다면 여려대의 컨슈머가 모두 같은 메세지를 받습니다. 3개의 작업이 대기중일때 3대의 컨슈머가 있다면 3대 모두 3개의 작업을 진행 할 것입니다.(중복 작업) 컨슈머 …

카프카 파티션? 카프카는 초당 수백만개의 메시지를 전송하고 처리를 제공하는 분산 스트리밍 플랫폼입니다. 처리성능을 높이기 위해 토픽 저장을 병렬화 할 수 있습니다. 그러한 방법은 브로커에 파티션을 나누는 것입니다. 하지만, 파티션은 늘리는것은 가능하지만 줄이는 것은 안되기 때문에 주의 해야합니다. 파티션 줄이고 싶다면 토픽을 삭제밖에 방법이 없습니다. ex) 1개의 파티션이 1분에 10개의 메시지를 받을 수 경우를 가정해보겠습니다. 프로듀서에서 1분에 50개의 메세지를 보낸다면, 토픽의 파티션을 5개로 늘려 처리 성능을 높여서 병목현상을 막을수 있을것입니다. 커맨드로 따라 해보기 마무리 토픽에 파티션을 추가하여 토픽을 생성해보았습니다. 토픽 전송 후 파티션을 확인하였을때 분산되어 저장되는것을 확인 할 수 있었습니다. 토픽을 가져올때는 순서대로 가져오지 않는다는걸 확인 하였습니다.

1. 카프로 빠르게 시작해보기 카프카 다운로드 압축해제 $ tar -xzf kafka_2.13-2.7.0.tgz 주키퍼 실행 $ bin/zookeeper-server-start.sh config/zookeeper.properties 카프카 실행 $ bin/kafka-server-start.sh config/server.properties 여기까지 하시면 기본적인 카프카 프로세스는 준비가 되었습니다. 토픽 생성하기 $ bin/kafka-topics.sh —create —topic quickstart-events —bootstrap-server localhost:9092 생성된 토픽 확인하기 $ bin/kafka-topics.sh —describe —topic quickstart-events —bootstrap-server localhost:9092 Producer 실행하고, 토픽내용 전송하기 Consumer로 토픽 읽기 예제 구성도 여기까지 가장 기본적인 카프카로 토픽 생성하여 …

카프카를 알게 된 계기 서비스를 분산화 하고, 여러 도메인 서비스에서 발생하는 이벤트를 받아 분산처리를 할 수 있는 아키텍처를 찾고 있었습니다. 그럴러면, 마이크로 서비스들이 서로 서로 이벤트를 받아야 하는데, 이러한 아키텍처를 구현 할 수 있는 쉽고 강력한 도구가 없을까? 라는 생각을 하게 되었습니다. 그러던중, 카프카라는 강력한 플랫폼을 알게 되었고 알면알수록 매력적으로 다가왔습니다. 위키백과가 말해주는 카프카란? 아파치 카프카는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다. 개발된곳은 링크드인이고, 2011년초 최종적으로 오픈소스화 되었다. 카프카를 사용하는 기업 애플,카카오 (기업),이베이,넷플릭스,페이팔,Uber,월마트 (알만한 기업들은 모두 사용!) Confluent가 말하는 카프카란? (Confluent는 링…