본문 바로가기

Programming

(72)

🔵 네트워크 레이어, IP 프로토콜 🔵 IP 주소 IP 주소는 네트워크 상에서 장치를 식별하기 위한 논리적 주소입니다.인터넷에 연결된 모든 장치는 IP 주소를 통해 서로를 구분하고 통신합니다. IP 주소의 핵심 역할은 두 가지입니다.첫째는 식별로, 이 패킷이 어떤 장치에서 왔는지를 나타내고,둘째는 위치로, 이 패킷을 어느 네트워크로 전달해야 하는지를 판단하는 기준이 됩니다. MAC 주소가 하드웨어에 고정된 물리 주소라면IP 주소는 네트워크 환경에 따라 변경될 수 있는 논리 주소입니다.이 특성 덕분에 네트워크 간 이동이나 주소 재할당이 가능하고라우터를 통한 인터넷 규모의 라우팅이 가능합니다. IP 주소는 일반적으로 네트워크 부분과 호스트 부분으로 구성됩니다.네트워크 부분은 장치가 어느 네트워크에 속해 있는지를 나타내고,호스트 부분은 ..

🔵 UDP & TCP 🔵 UDP UDP는 비연결형·비신뢰성 전송 방식을 제공하는 전송 계층 프로토콜로,연결 설정 없이 데이터그램을 바로 전송하기 때문에 초기 지연이 낮고 구조가 단순한 것이 특징입니다하지만 신뢰성을 보장하는 기능이 없어 패킷 손실이나 순서 뒤바뀜이 발생할 수 있습니다.이런 특성 때문에 UDP는 지연에 민감한 실시간 서비스에서 주로 사용됩니다. 🔵 UDP의 장단점 UDP의 가장 큰 장점은 지연(latency)이 낮고 오버헤드가 적다는 점입니다. 연결을 설정하지 않고 헤더도 단순하기 때문에 패킷을 즉시 전송할 수 있고,실시간성이 중요한 서비스에서 유리합니다. 멀티캐스트·브로드캐스트를 지원한다는 점도 특징입니다.반면 단점으로는 신뢰성을 보장하지 않는다는 점이 있습니다. 재전송, 패킷 순서 보장, 흐름 제어·..

🔵 애플리케이션 레이어 🔵 쿠키와 세션 HTTP는 기본적으로 무상태성(stateless) 이기 때문에서버는 사용자가 누구인지, 이전에 어떤 요청을 보냈는지 기억하지 못합니다.이 한계를 해결하기 위해 등장한 기술이 바로 쿠키와 세션입니다. 쿠키는 웹 브라우저에 저장되는 작은 데이터로,서버가 클라이언트를 식별하거나 설정값을 유지하기 위해 사용합니다.주요 특징- 서버가 생성 → 클라이언트(브라우저)에 저장- 요청마다 자동으로 서버에 전송됨- 로그인 유지·사용자 설정·광고 트래킹 등에 많이 사용- 만료 시간/도메인/경로 설정 가능장점- 구현이 단순하고 빠름- 별도 서버 자원 사용 X- 상태 유지 기능을 최소 비용으로 제공한계- 클라이언트 저장 방식이라 보안 취약 (탈취·변조 가능 → Secure, HttpOnly, SameSi..

🔵 HTTP/1.1 vs HTTP/2 vs HTTP3 차이 🔵 HTTP HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위해 사용하는요청-응답 기반의 애플리케이션 계층 프로토콜입니다.무상태성(stateless)을 가지므로각 요청이 서로 완전히 독립적으로 처리되고서버가 클라이언트의 이전 상태를 유지하지 않습니다.상태를 저장하지 않기 때문에 확장성이 뛰어나고 서버 부담이 적어지는 장점이 있습니다.GET·POST·PUT·DELETE 같은 메서드를 통해 리소스를 표현하고 조작하며헤더와 바디 구조로 다양한 형태의 데이터를 교환합니다.기본적으로 TCP 위에서 동작하며HTTP/2와 HTTP/3에서는 멀티플렉싱·헤더 압축·QUIC 같은 기술이 적용되어더 빠르고 효율적인 통신을 제공합니다. 🔵 1. HTTP/1.11_ 기본 개념HTTP/1.1은 1997년에 ..

🔵 HTTP 🟢 HTTPS 🔴 DNS 🔵 HTTP 프로토콜 HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위해 사용하는요청-응답 기반 프로토콜입니다.무상태성(stateless)을 가지므로 서버는 이전 요청의 상태를 기억하지 않고각 요청은 독립적으로 처리됩니다.GET·POST·PUT·DELETE 같은 메서드를 통해 리소스를 표현하고 조작하며헤더와 바디 구조로 다양한 형태의 데이터를 교환합니다. HTTP/1.1과 HTTP/2는 신뢰성 있는 전송을 위해 TCP를 기반으로 동작하는 애플리케이션 계층 프로토콜입니다.HTTP/2는 기존 TCP 구조를 유지하면서 멀티플렉싱과 헤더 압축을 도입해 성능을 개선했습니다. HTTP/3는 TCP 대신 QUIC 프로토콜을 기반으로 동작하여 핸드셰이크 지연을 줄이고 연결 설정의 안정성을 높였습니다. ..

🔵 TCP/IP & OSI 7 Layer 🔵 인터넷 프로토콜 인터넷은 전 세계의 컴퓨터가 데이터를 주고받는 네트워크로공통된 규칙이 없으면 통신이 불가능합니다.이런 규칙들을 모아 놓은 것이 인터넷 프로토콜 스위트이고,TCP/IP는 그중에서도 가장 널리 사용되는 표준 프로토콜 집합입니다. 🔵 TCP와 IP TCP/IP는 패킷 통신 방식의 인터넷 프토토콜인 IP (인터넷 프로토콜)와 전송 조절 프로토콜인 TCP로 이루어져 있습니다. TCP는 IP 통신을 기반으로 작동하기 때문에 따로 생각하기 보단 하나의 흐름으로 보는 것이 좋습니다. 🔵 IP IP는 데이터를 패킷(데이터그램) 단위로 나누어 전송하는데이 과정에서 데이터가 제대로 전달되었는지나 순서가 올바른지는 보장하지 않는다는 특징이 있습니다.- 비신뢰성(unreliability) / 비연..

Apache Kafka 톺아보기 🔵 Apache Kafka란?오픈소스 분산 데이터 스트리밍 플랫폼링크드인에서 개발, 현재는 Apache 재단에서 관리실시간 데이터 스트림의 게시(Publish), 구독(Subscribe), 저장(Storage), 처리(Process) 기능 제공대규모 데이터 이동에 적합 (A → B뿐 아니라 A → 여러 지점(Z) 동시에 가능)전통적 메시징 시스템의 대안높은 처리량(Throughput) 과 내결함성(Fault Tolerance)지속성(Persistence) 기반 저장 구조 (디스크에 로그 형태로 저장)소비자가 개별 오프셋을 관리하며, 재처리나 리플레이가 용이 🔵 Apache Kafka 구성 요소 요약Kafka는 메시지를 효율적으로 전달하고 저장하기 위한 분산형 스트리밍 플랫폼입니다. 아래는 Kafka의..

[ 보고서 ] Kafka 도입을 통한 선착순 쿠폰 발급 기능 개선 🟡 보고서 목적 이 보고서는 기존 Redis 단독 구조의 선착순 쿠폰 발급 시스템이 지닌 한계를 분석하고, Kafka 도입을 통한 아키텍처 개선 방안을 제시하는 데 목적이 있습니다. 선착순 쿠폰 이벤트는 대용량 트래픽 대응, 발급 정합성(중복/재고 초과 방지), 안정적인 장애 대응 및 복구 능력을 요구합니다. 기존 Redis 중심 구조는 빠른 응답성과 강력한 동시성 제어가 강점이었습니다.하지만 스케줄러 기반 비동기 처리로 인해 발급 시점이 불확실하고결과 누락 시 보상이나 추적이 어려운 구조적 한계를 가지고 있습니다. 이를 해결하기 위해 Kafka 기반의 비동기 처리 구조를 도입하여 분산성, 확장성, 메시지 기반의 안정적인 발급 플로우를 확보하는 방안을 제안합니다. 🧾 시나리오1. 이벤트 목적특정 시..

[ 보고서 ] Redis 도입을 통한 선착순 쿠폰 발급 시스템 개선 ✅ 1. Redis 기반으로 개선한 이유 진행하고 있는 "e-커머스" 프로젝트에서선착순 쿠폰 발급 기능은 비관적 락과 분산 락 등으로 동시성 이슈를 처리했습니다.하지만 락 기반 제어 방식은락 충돌과 대기 시간 증가로 인해 응답 지연과 성능 저하를 초래할 수 있다는 단점이 있습니다. 반면 Redis는 메모리 기반으로 빠른 속도를 제공합니다.ZSet, Set 같은 자료구조로 중복 체크나 순서 정렬 같은 작업을 빠르게 처리하는 장점이 있습니다. 특히 선착순 쿠폰처럼 짧은 시간에 요청이 몰리고, 순서가 중요한 상황에서는락보다 Redis의 원자적 연산과 정렬 구조가 더 효율적이라고 판단하였습니다. ✅ 2. 결론 Redis의 빠른 처리 속도와 원자적 연산을 활용해전반적인 성능이 향상됨을 확인할 수 있었습니다..

[ 보고서 ] 동시성 이슈 - 비관적 락 vs 낙관적 락 🔍 이 문서를 작성한 목적이 문서는 e-커머스 시스템에서 발생할 수 있는 대표적인 동시성 문제를시나리오를 기반으로 문제 정의, 원인 분석, 해결 방안을 중심으로 정리했습니다. 특히 아래 세 가지 주요 기능에서의 동시성 이슈를 중점적으로 다룹니다. 📦 상품 재고 차감 및 복원💰 사용자의 잔액 차감🎟️ 선착순 쿠폰 발급 처리 * 주로 RDBMS의 DB Lock 방법을 적용한 내용입니다. 🔬 문제 식별 로직문제 정의📦 상품 재고 차감 ✔ 사용자 A와 B가 동시에 동일 상품의 재고를 차감하려 할 때 재고 중복 차감, 초과 차감 등의 문제가 발생할 수 있습니다.💰잔액 충전 / 차감 ✔ 동일 사용자가 여러 기기에서 동시 결제나 더블 클릭을 통해 여러 요청을 보낼 경우, 중복 충..

[ 보고서 ] 정렬 인덱스, 필터 인덱스, 그 조합이 만드는 쿼리의 운명 🔍 이 문서를 작성한 목적조회 성능 저하가 우려되는 API를 분석하여 원인을 파악하고개선 방안을 도출하기 위해 작성하였습니다. 🧭 성능 저하 가능성이 있는 API`/api/v1/products`는 상품 목록을 조회하는 API로,다음과 같은 조건을 기반으로 필터링합니다. 조건 항목설명가격 정렬가격 오름차순 / 내림차순 정렬최신순 정렬최신순으로 상품을 정렬category문자열 필드, 정규화되지 않음내부 조인: product_inventory재고 정보와의 조인페이징 + COUNT(*)페이지네이션과 총 개수 동시 조회 정렬 및 필터 조건이 인덱스를 활용하지 못하는 경우옵티마이저가 전체 테이블을 스캔하거나 대량의 정렬 연산을 수행하게 되어데이터량이 증가할수록 쿼리 조회 비용이 증가할 수 있습니다. ..

대규모 트래픽 티켓팅 시스템 설계를 해보다. 이번 글에서는 대규모 트래픽이 발생할 수 있는티켓팅 시스템을 어떻게 설계할지 고민해보고최종적으로 정리한 아키텍처 구성을 단계적으로 살펴보려고 한다. 📐 전체 아키텍처 아래는 설계해 본 티켓팅 시스템 전체 아키텍처를 그려본 것이다. 📋 요구사항 정의 1️⃣ 계정당 구매할 수 있는 티켓 수량 제한R석과 S석을 포함하여 총 5장까지만 구매 가능해야 한다.2️⃣ 보유하고 있는 티켓 수량 초과 판매 방지실제 보유하고 있는 티켓보다 더 많은 티켓이 판매되지 않도록 관리해야 한다.3️⃣ 초당 최소 5,000장의 티켓 구매 요청 처리사용자가 몰리는 상황에서도 초당 최소 5,000장의 티켓 구매 요청을 처리할 수 있어야 한다. 🎯 설계 방향 티켓팅 시스템은 짧은 시간에 대규모 요청이 폭주하는 상황에서 안정..

AWS Lightsail로 HTTPS 서버를 구축해보다. GitHub - olive-side-project/payment-project: 📌[ 결제 시스템 프로젝트 ] 👉 확장성을 고려한 멀티모📌[ 결제 시스템 프로젝트 ] 👉 확장성을 고려한 멀티모듈 구조와 결제 API 설계 👉 Redis 기반 동시성 처리 👉 멀티프로파일 환경에서의 로그백 설정 및 MDC를 활용한 쓰레드별 로그 관리 - olive-sgithub.com [ AWS Lightsail을 선택한 이유 ] 최근 사이드 프로젝트를 진행하면서HTTPS로 서버를 구축하기로 했다. 이때 AWS Lightsail을 사용했다.Lightsail은 AWS에서 제공하는 가상 프라이빗 서버로,간편하고 직관적인 서버 설정을 제공해 준다. AWS EC2는 다양한 용도에 맞춰 수백 가지 인스턴스 옵션과 네트워크..

Push 서버 재구성: 유연한 이벤트성 푸시 발송 시스템 구현 얼마 전 회사에서이벤트성 및 서비스성 푸시 메세지를 발송하기 위한 별도의 Push Server를 만들었다. 기존에 Push Server가 있는 상태이긴 했는데,기존 Push Server는 사용자가 인증한 정보를 기반으로타겟팅하여 푸시를 발송하는 포맷으로 정해져 있었다. 그런데 이벤트성, 서비스성 푸시를 보낼 때는기존 Push Server를 이용하면 비효율적인 부분이 있었다. 예를들면, 보내려는 서비스성 푸시메세지가 기존 시스템의 포맷과 맞지 않아 새로운 DB 테이블을 생성하거나새로운 객체에 맞게 발송 프로그램을 따로 구현하고 테스트 해야 했다. 이를 해결하기 위해다양한 서비스 유형 푸시 메세지를 발송할 수 있도록새로운 Push Server를 만들었다. 기존 Push Server를 이용할 때는새로운 유형..

MDC를 활용해 쓰레드 전환을 이해해보다. 멀티쓰레드 환경에서는 항시적으로 로그가 뒤섞이곤 한다. 여러 요청이 동시에 처리될 때동일한 요청에 대한 로그가 연속적으로 쌓이는것이 아니기 때문이다. 이 문제를 해결하는 한 가지 방법으로, MDC(Mapped Diagnostic Context)를 활용할 수 있다. 각 HTTP 요청에 대한 UUID를 MDC에 저장하고, 이 UUID를 모든 로그 메시지에 자동으로 포함시키는 방식이다.이를 통해 로그를 분석할 때 각 요청을 명확하게 구분할 수 있다. 이처럼 MDC는 주로 로그에 추가적인 컨텍스트 정보를 자동으로 포함시키는 기능을 제공한다.덕분에 멀티스레드 환경에서도 요청별 또는 사용자별로 로그를 일관되게 관리할 수 있어로그 추적이 훨씬 간편해진다. MDC를 이용해 특정 로그를 제외시키는 것은 일반적인 ..

JPA에서 @BatchSize 를 쓸 것인가 vs Fetch Join을 쓸 것인가 [ JPA에서 @BatchSize 사용 시 장점 ] @BatchSize 어노테이션은 Hibernate에서 성능을 개선하는 데 유용하다.특히 대량의 데이터를 처리할 때 이 어노테이션의 효과를 직접 느낄 수 있다. 상황cust_info (사용자 정보) 테이블을 조회할 때,대부분의 상황에서 cust_agree_info (사용자 동의 정보)도 함께 조회해야 해야 하는 상황.예를들어 1,000명의 회원 정보를 한꺼번에 조회 할 때는 어떨까? JPA 기본 쿼리 방식기본적으로 Hibernate는 1000명의 cust_info를 조회한 후,각 회원의 cust_agree_info를 조회하기 위해 별도의 쿼리를 실행함.결과적으로 1000개의 쿼리가 데이터베이스로 나가게 되며,이로 인해 성능 저하를 초래하는 N+1 문제가..

[k8s] 모니터링 시스템을 구축했다. (Fluentd, Elasticsearch, Kibana) [ 프롤로그 ] 회사에서 쿠버네티스를 도입한 지 얼마 되지 않았다. 쿠버네티스 모니터링 시스템을 구축하라는 명을 받고- Fluentd(로그 수집 도구)- ElasticSearch (로그 저장 및 검색)- Kibana (수집된 로그를 시각화)이 3가지를 연결한 내용을 정리하였다. [ 상황 ] (1) 모니터링 시스템을 구축하기 위해ElasticSearch와 Kibana를 만들었다. 참고로 ElasticSearch는 VM 환경에 배포하였다.이유는 안정화를 높이기 위해모니터링 시스템은 쿠버네티스 노드와 격리된 환경에서 구축하는 것이 좋다고 생각했기 때문이다. (2) 로그 수집을 담당하는 Fluentd는 Kubernetes DaemonSet을 이용하여각 노드에 설치하였다. (3) Fluentd를 선택한 이..

[쿠버네티스] cronjob.yaml - error converting YAML to JSON 에러 해결하기 회사 개발 프로젝트에서 쿠버네티스 크론잡을 이용해 포인트를 만료시키는 스프링 배치 코드를 실행시키고 있었다. [ 개발 환경 ] - JAVA : 17 - Spring framework : 3.1.5 - Cloud : Azure 나는 매일 오전 12시 01분에 도는 배치였고, value.yaml 파일은 대략 다음과 같았다. 그리고 이렇게 내가 만든 포인트 만료 배치만 돌릴 때는 문제가 발생하지 않았다. service: "batch" image: repository: 생략 pullPolicy: IfNotPresent tag: "" jobs: - name: expire-point (1번 배치) envFrom: - configMapRef: name: 생략 - secretRef: name: 생략 - secretRe..

[Java] 인터페이스를 통해 if문의 향연을 고쳐보았다. 상황 물건의 최소 시세값이 '5억', 최대 시세값이 '10억' 이라고 세팅 되었다고 할 때, - 사용자의 물건이 7억이면? 필터링을 통과한다. 👉 5억과 10억 사이기 때문이다. - 사용자의 물건이 3억이면? 필터링을 통과하지 못한다. 👉5억과 10억 사이가 아니기 때문이다. 이에 대한 필터링 코드를 작성했고, 이를 리팩토링 하는 과정을 정리해보고자 한다. 결론 비교 화면 리팩토링 전 코드 딱 봐도 if 문의 향연 그 잡채다. 최소값과 최대값이 항상 둘 다 세팅된다는 보장이 없기에 (1) 최소값 / 최대값이 둘 다 세팅되었을 때 (2) 최대값만 세팅되었을 때 (3) 최소값만 세팅되었을 때 를 나누어 조건을 분리하는 그런 코드이다. 필터링을 수행하는데 크게 이상은 없지만, if 문이 너무 많아 보기 좋아보..

[Java] 역직렬화로 JSON 포맷을 바꿔보았다. 백오피스 프로젝트를 개발하던 중에 Jackson 라이브러리를 통해 '역직렬화'를 사용해 보았다. 먼저 상황은 다음과 같았다. 프로모션 관련 백오피스 기능이었는데, 프로모션을 등록할 때 섹션 종류가 총 3가지가 있었다. (buttion, image, detail) 이 때 프론트에서 세팅해야하는 JSON 데이터 포맷을 맨 처음에는 아래 이미지에서 A와 같이 되도록 코드를 작성했었다. sectionType이 달라짐에 따라 "imageSection" , "buttonSection", "detailSection" 과 같은 필드가 따로 따로 생기는 방식이었다. 프론트 입장을 고려했을 때는 A 보다는 B 방식이 데이터를 다루는 데 있어서 더 편하다고 판단하였고 B 와 같이 JSON 포맷이 되도록 하기 위해 Jacks..

[Java] 인터페이스 사용하여 필터링 기능을 구현해 보았다. 최근에 했던 개발 중, 특정 상품에 대해 필터링을 해야 하는 내용이 있었다. 내용을 간단히 말하면,현재 이 상품을 사용하려는 사용자가 가진 조건이이 상품이 요구하는 조건과 일치하지 않는다면 필터링 아웃 시켜야하는 것이었다. 제일 처음 작성했던 코드 스타일은 다음과 같다. @Slf4j@Service@Transactional@RequiredArgsConstructorpublic class CalculatorService {private boolean filterConditions(CalculatorContext context, long productSeq) { return Stream.of( isPurposeValid(putData.getPurposeCd(), p..

[Linux] top과 jstat -gc 명령어로 서버와 GC 살펴보기(with 챗지피티) 📌 크롬은 용량을 너무 많이 차지해....😢 최근에 크롬창을 띄워 스크래핑을 진행하는 서버를 개발하면서 만난 이슈가 하나 있었다. 테스트를 위한 스테이지 서버는 t3.small 인스턴스 유형으로 세팅이 되어 있었는데, 하나의 스크래핑 요청만 진행할 때는 이상없이 진행됐지만 2개의 스크래핑을 동시에 진행하니 서버가 뻗어버렸다. (겨우 2개에 뻗다니 ㄷㄷㄷ) 가장 큰 원인은 스크래핑이 실패하는 경우 무조건 크롬창을 닫아야 하는데, 부분부분 특정 단계에서 크롬창이 닫히지 않고 그대로 떠있어서 크롬이 많은 용량을 차지하고 있었기 때문이었다. (크롬의 용량은 상당히 크다..........!) 그래서 어떤 단계에서든 스크래핑이 실패하면 무조건 크롬창을 닫도록 코드를 수정하니 동시의 2개의 스크래핑 요청이 온다고 해..

[Spring] 멀티 쓰레드 환경에서 자원이 공유돼 버렸다. 이번에는 어떤 상황이 발생했을까?! 최근에 특정 데이터를 스크래핑하는 개발을 했다. Java + Selenium 을 통해 서버에서 크롬창을 연 뒤 클릭이벤트를 발생시켜 데이터를 스크래핑 한 후,그 데이터를 Redis에 저장하는 방식이었다. AWS SQS (Simple Queue Service) 기술도 사용했다."C"라는 서버에서는 SQS 메세지를 Publishing 하는 역할을 하고=> "D"라는 스크래핑 서버에서는 AWS SQS를 구독하고 있다가 메세지가 생기면 수신하여 처리하는 방식이다. 이때 "D"라는 스크래핑 서버에는 아래와 같은 서비스가 존재한다. (1) SqsService (큐 서비스)(2) ScraperService (스크래퍼 서비스) (1) SqsService(큐 서비스)는 SQS..

[Spring] @Async는 왜 제대로 동작하지 못했는가악! 일단, @Async가 뭘까? @Async는 Spring에서 제공하며, Thread Pool을 활용하여비동기를 지원하는 어노테이션이다. @Async가 제대로 동작하지 않는 상황이 발생했다! 이번에도 어김없이 등장하신 개발실 실장님 🙌 최근 누군가가 개발한 코드 중에서@Async 어노테이션을 붙인 코드가 제대로 동작하지 않아서비동기 처리가 되고 있지 않은데원인이 무엇인지 확인해 보라고 하셨다. 회사코드라 그대로 옮길 수 없지만,대략 큰 뼈대 내용은 다음과 같다. public class BenzService extends CarService{ public void init(CarDto carDto) { // 생략 .. callExternalApi(carDto, api..

[Spring] Thread-safe 에 대해서 고찰해 보다. 부제 : 스프링 빈은 멀티쓰레드 환경에서 Thread-safe 할까? 개발 실장님께서아래 코드에 버그가 있는데, 무엇이 버그인지 알겠냐고 물어보셨다. ( 회사코드를 그대로 가져다 쓸 수 없어 예시를 들기 위해 클래스명, 변수명 등을 조금 변경했다. ) 아래 코드를 보면,for문을 돌면서 getBean() 메소드를 통해 생성되어 있는 스프링 빈(bean)을 찾아와 characterService에 할당하고 있다. - (1)번 파트 그다음 할당된 스프링 빈(bean)의 init() 메소드를 실행한다. - (2)번 파트 public class Service { // .... 생략 private CharacterServi..

[코드리뷰 받은 내용 정리] 코드를 작성할 때 '이것'을 생각해보자! 🎨 참조타입 vs 원시타입 @Schema(description = "정기알림 신청여부", example = "false") private Boolean monthlyRequestYn; [ 위 코드에 대한 코드리뷰 내용 ] " 개인적으론 Boolean type은 boolean을 쓰는 걸 추천합니다. Reference type과 성능 차이도 있을 수 있지만 null point exception 과 같은 것도 고민안해도 되니깐요. 특히 boolean type은 만약 입력을 하지 않으면 false나 true 둘 중에 하나의 default 값이 존재하는 경우가 많아서 reference type을 쓸일이 더 없었던거 같아요. 물론 100%라고 말씀드릴 순 없어요. 그러나 여기는 false가 default 일거 같긴..

[AWS] VPC / 서브넷 / 인터넷 게이트웨이 / 라우팅 테이블 / 로드밸런싱 스케줄러는 원래 A 웹 서버와 함께 사용하던 탓에 WAS와는 다른 서브넷 설정이 되어 있었습니다. 그러나 설계 목적과 역할을 고려해보면, 스케줄러가 WAS 쪽 보안 그룹 및 네트워크 설정을 공유하고 WAS 서브넷에서 실행되는 것이 더 적절해 보입니다. 이에 따라 스케줄러 EC2 인스턴스를 새로 생성할 계획이며, 동시에 CRM 서버 사양도 조정할 예정입니다. 먼저, 위에서 'subnet(서브넷)' 이라는 단어가 등장하는데서브넷을 이해하기 위해서는 앞서 VPC라는 것을 알아야 한다.그래서 VPC부터 시작하여 연관된 내용을 하나씩 알아보았다. 또한, 어떻게 AWS에서 직접 생성하는지 정리해야 각각의 내용이 더 기억될 것 같아서 화면을 캡처하여 정리했다. 🎯 VPC (Virtual Private Clou..

[리팩토링 기술-7] 기본형을 객체로 바꾸기 / 타입 코드를 서브클래스로 바꾸기 / 조건부 로직을 다형성으로 바꾸기 👀 기본형 집착 ? - 어플리케이션이 다루고 있는 도메인에 필요한 기본 타입을 만들지 않고 프로그래밍 언어가 제공하는 기본 타입을 사용하는 경우가 많다. - 기본형으로는 단위 또는 표기법을 표현하기 어렵다. 🙌 기본형을 객체로 바꾸기 (Replace Primitive with Object) - 개발 초기에 기본형 (숫자 또는 문자열)으로 표현한 데이터가 나중에는 해당 데이터와 관련있는 다양한 기능을 필요로 하는 경우가 많다. (예) 문자열로 표현하던 전화번호의 지역코드가 필요한 경우 (예) 숫자로 표현하던 온도의 단위(화씨, 섭씨)를 변환하는 경우 기본형을 사용한 데이터를 감싸 줄 클래스를 만들면, 필요한 기능을 추가할 수 있다. [ Berfore ] Order 클래스에서 우선순위를 의미하는 prioir..

[리팩토링 기술-6] 단계 쪼개기 / 클래스 추출하기 🙌 단계 쪼개기 (Split Phase) - 서로 다른 일을 하는 코드를 각기 다른 모듈로 분리한다. : 그래야 어떤 것을 변경해야 할 때, 그것과 관련있는 것만 신경쓸 수 있다. - 여러 일을 하는 함수의 처리과정을 각기 다른 단계로 구분할 수 있다. (예) 전처리 -> 주요작업 -> 후처리 (예) 컴파일러 : 텍스트 읽어오기 -> 실행 가능한 형태로 변경 - 서로 다른 데이터를 사용한다면, 단계를 나누는데 있어 중요한 단서가 될 수 있다. - 중간 데이터를 만들어 단계를 구분하고, 매개변수를 줄이는데 활용할 수 있다. [ Berfore ] priceOrder() 함수는 주문에 값을 매기는 일을 하지만 내부에서 할인가격과 할인된 가격을 구하는 두가지 일을 같이한다. [ After ] - basePric..

[리팩토링 기술-5] 반복문을 처리하는 리팩토링 👀 반복문 (Loops) - 프로그래밍 언어 초기부터 있었던 반복문은 처음에는 별다른 대안이 없어서 간과했지만 최근 자바와 같은 언어에서 함수형 프로그래밍을 지원하면서 반복문에 비해 더 나은 대안책이 생겼다. - "반복문을 파이프라인으로 바꾸는 (Replace Loop with Pipeline)" 리팩토링을 적용하면 필터나 맵핑같은 파이프라인 기능을 사용해 보다 빠르게 어떤 작업을 하는지 파악할 수 있다. 🙌 반복문을 파이프라인으로 바꾸기 (Replace Loop with Pipeline) - 고전적인 반복문을 파이프라인 오퍼레이션을 사용해 표현하면 코드를 더 명확하게 만들 수 있다. (1) filter : 전달받은 조건의 true에 해당하는 데이터만 다음 오퍼레이션으로 전달 (2) map : 전달받은 ..

이전 1 2 3 다음

티스토리툴바