sagecode 님의 블로그

API Gateway란?[ Client (Web/App) ] │ ▼ ┌─────────────────┐ │ API Gateway │ ← 인증/보안, 요청 라우팅, 로깅, 응답 집계 └─────────────────┘ │ │ │ ▼ ▼ ▼ [Auth] [Order] [Chat] ← 마이크로서비스API Gateway는 클라이언트와 여러 백엔드 서비스 사이의 진입 문 역할을 하는 서버입니다. Gateway 에만 요청하면 내부적으로 직접 각 서버의 포트를 몰라도 적절한 서비스로 라우팅이 가능합니다.API Gateway를 거치면 로깅, 인증/인가, 보안 문제 같은 공통적으로 거쳐야되는 문제를 한 번에 해결할 수..

Apache Kafka는 분산 메시징/스트리밍 플랫폼 입니다. Kafka는 초당 수십만 건 이상의 메시지를 처리 가능하고, 여러 Broker를 통해 분산처리가 가능합니다. 또한, 메시지를 디스크에 저장하고 유실된 메시지를 요청을 한번 더 보내는 큐도 존재하면서 장애 발생 시에도 데이터 유실을 방지 할 수 있고, 한 메시지를 여러 Consumer 그룹이 독립적으로 읽을 수 있습니다. Kafka 주요 개념1. Producer메시지를 Kafka에 Publish 즉, 발행을 하는 주체이다.특정 Topic에 메시지를 보낸다.메시지는 JSON 등 여러가지 Payload 형태로 전송이 가능하다.2. Topic메시지가 모이는 구분 단위이다.3. PartitionTopic을 쪼갠 단위이며, topic내에서 여러 Part..

일단 서버 장애가 발생하면 로그를 확인합니다.로그는 애플리케이션 로그, 웹서버 로그, DB 로그, 시스템 로그 순으로 확인하면 됩니다.애플리케이션 로그는 보통 코드로직에서 잘못된 서버에러가 발생합니다.웹서버 로그는 HTTP 요청과 응답에 대한 에러가 발생하는데, 200번대 같은 경우는 정상, 400번대의 경우 인증/인가 or 리소스 없음 오류, 500에러는 서버오류, 게이트웨이, 타임아웃 오류 등을 나타냅니다.DB 로그에서는 보통 쿼리 실행시 slow query오류나 connection 문제가 발생합니다.시스템 로그에서는 CPU 프로세스 과다사용, 네트워크 지연 등 OS 계층에서 발생할 수 있는 문제들이 있습니다. 이렇게 로그를 확인한 뒤 원인들을 찾고 해결한 다음 다시 실행합니다.

캐시는 자주 사용되거나 다시 사용될 가능성이 높은 데이터를 미리 저장해놓는 저장소입니다. 데이터를 디스크에서 직접 I/O 하게 되면 속도가 느리기 때문에 메모리에서 직접 갖고오는 캐시를 이용한다.데이터를 갖고오는 속도를 빠르게 할 뿐만아니라 DB와 서버에 걸리는 부하도 줄일 수 있다.

일단 로드밸런싱을 하게되면 트래픽을 분산할 수 있습니다. 하나의 서버에 갑자기 요청이 몰리게 되면 서버에 부하가 걸리게 되어 다운되거나 병목현상이 발생할 수 있습니다. 그 때, 로드밸런서가 요청을 여러 서버로 분산시켜 부하를 나누어 처리할 수 있습니다. 또한 늘어난 트래픽을 감당하기 위한 서버 수평확장을 하게되면 알아서 로드밸런서가 분산시켜줍니다. 또한, 특정 한 서버가 장애가 생기더라도 자동으로 정상 운영중인 서버로 요청을 보내줍니다. 그러면서 무중단 운영이 가능합니다. 마지막으로 로드밸런서가 외부 요청을 받아 내부 서버로 전달하기 때문에 서버의 직접적인 IP가 노출되지 않으며 SSL 인증서 관리도 로드 밸런서에서 한 번만 하면 되기 때문에 보안 관리도 편리합니다.

CORS 정책은 브라우저에서 다른 origin의 리소스에 접근할 권한을 허용하는 정책입니다. 여기서 origin이란 프로토콜 + 도메인 + 포트를 말합니다. CORS가 발생하는 이유는사용자가 어떤 브라우저에 접속했을 때, 그 사이트의 js코드가 api를 호출해 각종 개인정보 유출이나 악성코드를 실행시킬 수 있기 때문에, 기본적으로는 다른 출처를 허용하지 않습니다. 개발 환경에서 보통 현실적으로 백엔드랑 프론트엔드가 origin이 다르므로 CORS오류가 발생합니다. 브라우저는 요청을 보낼 때, 서버가 응답 헤더에 Access-Control-Allow-Origin 등을 포함해야만 응답을 JS 코드에서 접근할 수 있게 허용합니다.

TCP 연결 같은 경우에는 데이터를 주고받을 때, 서로 준비가 되었는지 확인하는 절차가 필요합니다. 그 방법이 3-way handshake입니다. 처음에 클라이언트가 서버에 syn 패킷을 보내면서버가 클라이언트의 syn 패킷을 수신하고 요청을 수락하며 자신의 isn이 담긴 syn 패킷을 재전송합니다. 또한, 클라이언트의 syn에 대한 응답인 ack도 전송합니다.클라이언트가 서버의 syn패팃을 수신하면 그에 맞는 응답인 ack를 서버에 보냅니다. 이 단계가 끝나면 서로 연결이 완료됩니다. 연결을 종료할 때, 서로 양쪽 모두 통신이 끝났음을 알려야하므로 4-way-handshake를 진행하게 됩니다. 처음에 클라이언트가 서버에게 더이상 보낼 데이터가 없음을 알리고 fin을 전송합니다.서버가 fin을 받았다는..

애플리케이션에서 데이터를 생성한 후 TCP 소켓을 통해 TCP 계층에 데이터를 넘깁니다. 그 후 TCP는 데이터를 세그먼트 단위로 쪼개서 헤더를 붙인 다음 IP계층에 넘깁니다. 또 다른 컴퓨터의 IP 계층이 세그먼트를 받으면 TCP로 넘기고 그 후 순서대로 TCP는 재조립, 손실된 데이터는 재전송 요청, 중복을 제거합니다. 그 후 복구한 데이터를 해당 포트의 애플리케이션에 넘깁니다. UDP의 경우 애플리케이션에서 데이터를 UDP 소켓을 통해 UDP 계층에 전달을 받게되면 UDP는 메시지에 간단한 헤더(길이, 포트)정도만 붙여 데이터그램을 만들어 IP계층으로 넘깁니다. 또 다른 컴퓨터의 IP 계층이 그 데이터그램을 받게되면 UDP로 넘기고 헤더에 써있는 포트로 그대로 애플리케이션으로 전송하게 됩니다. 만약..

N+1 문제는 JPA같은 ORM에서 자주 발생하는 문제입니다. 한 번의 쿼리를 실행해서 엔티티 리스트를 가져온 다음 그 엔티티와 연관된 데이터를 조회하려고 접근할 때 엔티티 개수만큼 추가로 쿼리가 실행되는 문제입니다. 원래는 쿼리 한 번이면 충분한 작업이 N+1번의 쿼리로 나누어 실행되어 불필요한 DB 부하가 발생하는 것이 N+1 문제입니다. ORM은 성능 이슈로 인해 기본원칙이 지연 로딩(lazy loading)입니다. 즉시 연관 엔티티를 가지고 오지 않고, 실제로 접근하는 시점에 쿼리를 날려 데이터를 조회합니다. 데이터 수가 많아질수록 조회 횟수가 늘어나므로 네트워크 왕복 비용, DB 부하, 메모리 사용량 등이 커져서 성능 병목이 발생합니다. N+1 문제 해결방법은JPQL에서 JOIN FETCH를 사..

데이터베이스에서 하나의 논리적 작업 단위를 트랜잭션이라고 합니다.이 트랜잭션이 안전하게 동작하기 위해 보장해야 하는 성질을 ACID라고 합니다. 1. Atomicity(원자성)트랜잭션은 모두 수행되거나 전혀 수행되지 않아야 합니다. 중간단계에서 오류가 발생하면 지금까지 수행된 작업들이 모두 취소(ROLLBACK)되고 이전 상태로 되돌아 가야 합니다. 2. Consistency(일관성)트랜잭션 실행 전과 실행 후에 데이터베이스는 일관된 상태를 유지해야 합니다.제약 조건, 규칙 등 을 항상 만족해야 합니다.(Unique, pk, fk 등) 3. Isolation(격리성)동시에 여러 트랜잭션이 실행되더라도 작업끼리 서로 간섭하지 않아야 합니다. 4. Durability(지속성)트랜잭션이 성공적으로 commit..