Official-Dev. blog

REST API 성숙도 모델 Rechardoson의 REST API 성숙도 모델이라는 것을 정리한다. 성숙도 모델은 총 4단계로 나누어져서 각 단계의 조건에 만족할 수록 REST API에 가까워진다고 한다. Level 0 Level 0은 웹 매커니즘을 사용하지 않고 HTTP를 원격 호출을 위한 전송 시스템으로 사용하는 경우이다. RPC(Remote Procedure Call)처럼 리소스 구분 없이 설계된 HTTP API이다. 하나의 End-point를 사용해서 HTTP Method도 반드시 POST가 된다. 그래서 서로 다른 매개변수를 통해서만 여러 동작을 하게 된다. Request POST /api/user { "function": "getUser", "arguments" [ "1" ] } Respon..

SOP (Same-Origin Policy) SOP는 같은 출처에서만 리소스를 공유할 수 있다는 정책이다. 개발을 하다가 HTTP HTTPS 간 통신에만 CORS 에러가 나는 경험이 많이 있었는데 그 이유가 SOP 정책 때문이다. 출처를 비교할 때는 URL의 구성요소 중 Protocol, Host, Port 3가지가 모두 동일해야 한다. https://www.honey.com/로 요청을 보낸다고 가정하자. https://www.honey.com/resources -> 가능 https://www.honey.com/resources?query=상품 -> 가능 http://www.honey.com/ -> 불가능 (프로토콜이 다르다) https://www.bee.com/ -> 불가능 (호스트가 다르다) 그렇다면..

다중 서버 Session 관리 요즘은 서버의 성능을 업그레이드 하는 방법으로 스케일 아웃을 많이 사용한다. 그리고, 쿠버네티스의 여러 개의 POD에 각각 올려서 관리하기도 한다. 일반적인 멀티 서버의 환경은 아래와 같다. 가령, 스프링 부트 프로젝트를 분산 서버로 배포하고있다고 가정하자. 일반적으로 Tomcat이 JSESSIONID라는 세션을 만들어서 관리한다. 세션 저장소는 Tomcat 내부에 있으므로 여러개의 톰캣이 뜨게되면 각각이 가지는 세션 저장소는 다르다. 그러면 WAS1에서 세션을 생성한 사용자가 WAS2로 접속했을 때 세션을 찾을 수 없는 현상이 발생한다. Sticky Session Sticky Session 방식을 사용하면 WAS1에서 세션을 생성한 사용자는 다시 접속할 떄도 WAS1로 접..

DNS Load Balancing DNS 로드밸런싱은 별도의 하드웨어 장비나, 소프트웨어 없이 사용자가 DNS를 이용하여 도메인 정보를 조회하는 시점에서 트래픽을 분산하는 기법이다. DNS Load Balancing 기법 중에 Round robin 방식은 부하 분산의 대표적인 알고리즘인데, 순서대로 돌아가면서 (보통 시간 단위) 각각의 서버로 트래픽을 분산시켜서 처리하는 알고리즘이다. 즉, 사용자가 도메인 주소를 브라우저에 입력하게되면 DNS가 여러개의 IP 리스트 중에서 랜덤으로 IP를 하나 알려준다. 장단점 장점 중간 장비(로드밸런서 등) 없이도 서비스가 가능하다. 간편하다. 단점 서버의 수 만큼 공인 IP 주소가 필요하다. 서버에 장애가 발생해도 감지하지 않고 부하를 분산시킨다. 일반적인 로드밸런싱..

교착상태(Deadlock) 교착상태는 다중 프로그래밍 환경에서 나타날 수 있는 문제점으로, 2개 이상의 프로세스들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 무한정 기다리는 현상이다. 교착상태는 위와 같이 그림으로 표현할 수 있다. 프로세스1은 자원 A가 필요하다. 자원 A는 프로세스2에 의해 잠겨져있다. 프로세스2는 자원 B가 필요하다. 자원 B는 프로세스1에 의해 잠겨져있다. 즉, 어느 한 프로세스를 강제적으로 종료하지 않으면 컴퓨터가 정지된 것 처럼 어떤 작업도 수행할 수 없다. 발생 조건 교착상태의 발생 조건은 아래 4가지를 모두 만족하는 것이다. 하나라도 만족하지 않으면 절대로 데드락이 발생하지 않는다. 상호 배제(Mutual exclusion) 한 리소스는 한..

MSA 요즘 MSA가 대두되면서 Kafka, RabbitMQ, ActiveMQ 등 메시징 시스템도 함께 떠오른다. MSA에서는 시스템 간 호출이 많기 때문에 서비스간 결합도를 낮추기 위해서 + 비동기 요청, 성능, 안정성 등 여러가지 이점이 있어서 메시징 시스템을 많이 사용하게 된다. 이 글에서는 MSA에서의 전반적인 메시징 시스템에 대해 다룬다. 용어 MOM (Message Oriented Middleware, 메시지 지향 미들웨어) 독립된 애플리케이션 간 데이터를 주고받을 수 있는 설계 함수 호출, 메모리 공유가 아닌 메시지 교환을 이용하는 중간 계층 Infra Architecture 분산 컴퓨팅이 가능해지며, 서비스간의 결합도가 낮아진다. 비동기로 메시지를 전달한다. Queue, Broadcast,..

Export CSV 지난 주 회사에서 CSV 형태로 친구목록을 내보내는 API를 추가하는 작업이 있었습니다. 작업 내용은 아래와 같습니다. Response Header를 명시한다. -> (Content-type: application/csv) List를 하나 생성한다. List에 CSV의 헤더(첫 행)을 삽입한다. 친구 목록 테이블이 5개의 다른 테이블과 LEFT JOIN해서 결과를 받는다. 조회 결과를 record 단위로 순회하면서 CSV에 맞는 스펙으로 변환하고 List에 삽입한다. 결과를 반환한다. 중요한 점은 개발해야 하는 CSV 구조 Tables 구조가 많이 달라서 데이터 가공 작업을 했어야 했습니다. 예를 들면, 아래와 같은 CSV 스펙이 필요하다고 가정합시다. 집 주소 회사 주소 배송 주소 ..

Bulk delete REST API에서 리소스의 id array를 사용해서 Bulk delete를 해야할 때 어떻게 하면 좋을까요? 저의 경우 DELETE /resources 로 요청을 보내고, Body에 { ids: [] } 형식의 데이터를 넣어주면 안되는지 생각했었습니다. Data의 위치 그런데, DELETE에서 Body에 데이터를 담는 것이 바람직한 방법이 아니라고 합니다. 왜냐하면, 일반적으로 HTTP 메소드를 사용할 때 데이터 위치는 아래와 같습니다. GET, DELETE => header에 데이터 포함 POST, PUT => body에 데이터 포함 그래서, 클라이언트나 라이브러리, 미들웨어 등에서 이를 지원하지 않는 경우도 있기 때문에 나중에 문제를 일으키기 쉽습니다. 방법 1 첫 번째 방법..

Transfer-encoding: chunked Chunked 인코딩 전송방식은 HTTP 1.1에서 사용가능한 스트리밍 데이터 전송 방식입니다. 청크 전송 방식의 특징은 아래와 같습니다. 데이터를 여러 개의 청크 단위로 쪼개서 순차적으로 전송 각 청크는 독립적으로 송수신 됨 각 청크의 앞에는 해당 청크의 Size(16진수)를 설정해서 보냄 길이가 0인 청크가 수신되면 전송이 종료됨 청크 전송 방식의 장점 큰 데이터 전송에도 HTTP 연결이 중간에 끊어지지 않게 유지할 수 있음. Content-Length가 필요 없음 -> 크기가 가변적인 데이터 전송에 유리 전체 컨텐츠를 생성할 때까지 대기하지 않음 HTTP 1.1부터는 기본적으로 연결 유지(Connection: keep-alive)가 활성화되어있습니다...

메일 작동 원리메일을 전송하고 전송 받을 때 사용하는 프로토콜은 크게 3가지로 나눌 수 있습니다.SMTP: 메일을 송신할 때 사용하는 프로토콜TCP/IP 호스트 사이의 메일을 전달할 때 사용됨POP3: 메일을 전송받을 때 사용하는 프로토콜POP3는 로컬에서 수정, 삭제를 해도 메일 서버에는 변화가 없음.메일을 수신할 때는 주로 POP3, IMAP을 사용.IMAP: 메일을 전송받을 때 사용되는 또 하나의 프로토콜IMAP은 POP3의 단점의 비동기성을 보완하기 위한 방식각 로컬마다 데이터가 다르지 않고 어떤 디바이스에서 메일을 열든 동일하게 동기화하는 방식복잡하다는 단점이 있음.기본 메일 서버의 동작 구조는 아래와 같습니다. abc@abc.com 사용자가 메일서버에게 MUA(Mail user agent ex..