이번 목표는 "메시지브로커에 메시지가 발행이 될 때마다 가격을 업데이트해서 보여주는 것"이다.

여기서 중간에 서버를 또 거치면 지연시간이 발생할텐데, 메시지브로커에 발행된 메시지를 그냥 클라이언트에 직접 꽂으면 빠르지 않을까? 라는 생각이 들었다.

Redis 보안 관리 공식문서 https://redis.io/docs/latest/operate/oss_and_stack/management/security/

For instance, in the common context of a web application implemented using Redis as a database, cache, or messaging system, the clients inside the front-end (web side) of the application will query Redis to generate pages or to perform operations requested or triggered by the web application user. In this case, the web application mediates access between Redis and untrusted clients (the user browsers accessing the web application).

신뢰할 수 없는 클라이언트로부터 Redis에 직접 쿼리를 보낼 수 있는 정보가 노출이 되고 (Redis 서버 정보), 이로 인해 보안, 안정성 문제가 발생한다. 라는 내용이다.

그래서 백엔드를 통해 접근하는 방식으로 구현한다. 이렇게 정리하고보니 Database를 프론트에 직접 연결해본적이 없다는 게 생각났다.

필요한 건 무엇일까?

우선 클라이언트에 실시간 시세정보가 보여지기까지 과정을 생각해보자.

과정

1. 메시지브로커로 활용하는 Redis로부터 price 채널 내에 발행된 메시지를 가져와야한다.
2. 가져온 메시지를 비트코인, 이더리움 시세로 분리해야한다.
3. 각각 웹소켓을 연결을 통해 클라이언트로 데이터를 전달한다.

이러한 과정에서 구현에 있어 필요한 것은 무엇일까?

구현

1. Redis 서버와 연결
2. Websocket 설정 및 메시지 발행
3. React로 Websocket 연결 구독

1. Redis 서버와 연결

RedisConfig.java

package com.crpyto_trading.demo.config;

import com.crpyto_trading.demo.infra.redis.RedisPriceSubscriber;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.listener.PatternTopic;
import org.springframework.data.redis.listener.RedisMessageListenerContainer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, String> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        return template;
    }

    @Bean
    public RedisMessageListenerContainer redisMessageListenerContainer(
            RedisConnectionFactory connectionFactory,
            RedisPriceSubscriber subscriber
    ) {
        RedisMessageListenerContainer container =
                new RedisMessageListenerContainer();

        container.setConnectionFactory(connectionFactory);
        container.addMessageListener(
                subscriber,
                new PatternTopic("price:*") // 티커별 구독
        );

        return container;
    }
}

Redis Pub/Sub은 메시지가 발행되면 구독자에게 즉시 전달되는 구조로 메시지를 수신하기 위해 Listener를 등록한다. Spring에서는 RedisMessageListenerContainer를 통해 Redis 서버와 연결하고, 특정 채널 패턴에 대해 MessageListener를 구현한 객체를 등록한다. 여기서 구현 객체는 subscriber이다. 이후 메시지가 발행되면 컨테이너가 해당 Listener의 onMessage() 메서드를 호출하여 메시지를 처리한다.

RedisPriceSubscriber.java

package com.crpyto_trading.demo.infra.redis;

import com.crpyto_trading.demo.service.PriceStreamService;
import org.springframework.data.redis.connection.Message;
import org.springframework.data.redis.connection.MessageListener;
import org.springframework.stereotype.Component;

import java.nio.charset.StandardCharsets;

@Component
public class RedisPriceSubscriber implements MessageListener {

    private final PriceStreamService priceStreamService;

    public RedisPriceSubscriber(PriceStreamService priceStreamService) {
        this.priceStreamService = priceStreamService;
    }

    @Override
    public void onMessage(Message message, byte[] pattern) {
        String payload = new String(message.getBody(), StandardCharsets.UTF_8);
        String channel = new String(message.getChannel(), StandardCharsets.UTF_8);

        // 받아온 메시지를 처리 (Service에 처리 로직 구현)
        priceStreamService.onPriceMessage(channel, payload);
    }
}

Redis PUB/SUB으로부터 받은 메시지를 처리하는 onMessage를 구현하는데, Redis로부터 온 데이터를 RedisTemplate를 활용해서 다뤄야하는게 아닌가? 싶지만 Redis에 접근해서 저장, 조회를 하는 것이 아니니깐 필요없다. priceStreamService를 통해 받아온 메시지를 처리한다.

PriceStreamService.java

package com.crpyto_trading.demo.service;

import com.crpyto_trading.demo.infra.websocket.outbound.PriceWebSocketPublisher;
import org.springframework.stereotype.Service;

@Service
public class PriceStreamService {

    private final PriceWebSocketPublisher publisher;

    public PriceStreamService(PriceWebSocketPublisher publisher) {
        this.publisher = publisher;
    }

    public void onPriceMessage(String channel, String payloadJson) {
        // channel: price:BTCUSDT
        String symbol = extractSymbol(channel);
        publisher.publish(symbol, payloadJson);
    }

    private String extractSymbol(String channel) {
        // "price:BTCUSDT" → "BTCUSDT"
        int idx = channel.indexOf(':');
        return (idx > -1) ? channel.substring(idx + 1) : channel;
    }
}

종목별 시세 구독을 처리하기 위해 extractSymbol로 종목 정보를 추출한다. 클라이언트에게 실시간 시세 정보를 전달하기 위해, onPriceMessage 메서드에서 PriceWebSocketPublisher를 통해 메시지를 발행한다. 메시지를 어떻게 발행하는지는 아래...

2. Websocket 설정 및 메시지 발행

WebSocketConfig.java

package com.crpyto_trading.demo.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.messaging.simp.config.MessageBrokerRegistry;
import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
import org.springframework.web.socket.config.annotation.StompEndpointRegistry;
import org.springframework.web.socket.config.annotation.WebSocketMessageBrokerConfigurer;

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("*")
                .withSockJS();
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        registry.enableSimpleBroker("/topic");
        registry.setApplicationDestinationPrefixes("/app");
    }
}

registerStompEndpoints 메서드를 통해 클라이언트와의 실시간 통신을 위한 WebSocket 엔드포인트를 설정하고, configureMessageBroker 메서드를 통해 Spring의 STOMP 프로토콜을 기반으로 메시지 브로커를 활성화한다.

withSockJS()는 WebSocket 연결이 불가능한 환경에서도 통신을 유지하기 위해 HTTP 기반 대체 전송 방식을 제공한다. enableSimpleBroker는 서버 -> 클라이언트, setApplicationDestinationPrefixes 클라이언트 -> 서버 방향으로 라우팅할때 필요한 prefix(접두사)를 세팅한다.

PriceWebSocketPublisher.java

package com.crpyto_trading.demo.infra.websocket.outbound;

import org.springframework.messaging.simp.SimpMessagingTemplate;
import org.springframework.stereotype.Component;

@Component
public class PriceWebSocketPublisher {

    private final SimpMessagingTemplate messagingTemplate;

    public PriceWebSocketPublisher(SimpMessagingTemplate messagingTemplate) {
        this.messagingTemplate = messagingTemplate;
    }

    public void publish(String symbol, String payloadJson) {
        // 예: /topic/price/BTCUSDT
        messagingTemplate.convertAndSend("/topic/price/" + symbol, payloadJson);
    }
}

STOMP 프로토콜 위에 메시지를 발행하기위해 SimpMessagingTemplate을 활용한다. publish 메서드에서 enableSimpleBroker에서 설정한 접두사가 포함된 목적지로 데이터를 전송하고, 이를 통해 STOMP 프로토콜을 활용하는 메시지 브로커가 해당 주소를 구독 중인 클라이언트들에게 실시간으로 메시지를 발행한다.

public void onPriceMessage(String channel, String payloadJson) {
    // channel: price:BTCUSDT
    String symbol = extractSymbol(channel);
    publisher.publish(symbol, payloadJson);
}

목적지 구분을 통해 종목별 실시간 시세를 구분하려고 symbol, payloadJson 데이터를 publish에 넘겨준 것이다.

클라이언트(브라우저)에서 이걸 어떻게 구독할까? 개념 설명 이후에 있다.

간단한 개념만...

STOMP (Simple/Stream Text Oriented Message Protocol)

1. websocket 위에서 동작하는 문자 기반 메세징 프로토콜
2. 클라이언트와 서버가 전송할 메세지의 유형, 형식, 내용들을 정의
3. pub/sub 구조

역할은 Redis Pub/Sub과 비슷한데, 차이는 다음과 같다.

여기서 TCP라는 용어가 있는데, OSI 7계층의 전송계층에서 양방향 통신을 가능하게 해주는 프로토콜이다. 서로 연결하기 위해 3 Way Handshake, 전송 데이터 순서 보장... 등등 뭐 많은데

[HTTP] 1. HTTP 이해를 위한 사전 지식 이전에 강의들으면서 정리해놓은 것 참고하면 된다.

전송 계층 부분에 Websocket → TCP 표시가 되어 있는데, Websocket 프로토콜을 사용하여 클라이언트와 서버 간의 지속적인 TCP 연결을 수립, 이를 통해 실시간 양방향 데이터 전송을 가능하게 하는 것으로 이해하면 된다.

Websocket이 뭐길래? HTTP 통신을 위해 생성된 TCP 연결을 WebSocket으로 업그레이드한 뒤, 해당 TCP 연결 위에서 지속적인 양방향 통신을 수행한다. 자세한 개념은 다음 게시글에 정리하겠다.

3. React로 Websocket 서버 구독

App.js

import { useEffect, useState } from "react";
import { Client } from "@stomp/stompjs";
import SockJS from "sockjs-client";
import "./App.css";

function App() {
  const [btcPrice, setBtcPrice] = useState("-");
  const [ethPrice, setEthPrice] = useState("-");

  useEffect(() => {
    const client = new Client({
      webSocketFactory: () => new SockJS("http://localhost:8080/ws"),
      reconnectDelay: 5000,

      onConnect: () => {
        // BTC 구독
        client.subscribe("/topic/price/BTCUSDT", (message) => {
          const data = JSON.parse(message.body);
          setBtcPrice(data.price);
        });

        // ETH 구독
        client.subscribe("/topic/price/ETHUSDT", (message) => {
          const data = JSON.parse(message.body);
          setEthPrice(data.price);
        });
      },
    });

    client.activate();

    return () => {
      client.deactivate();
    };
  }, []);

  return (
    <div className="App">
      <div className="content">
        <div className="box">
          <h3>비트코인 시세</h3>
          <p>{btcPrice} USDT</p>
        </div>

        <div className="box">
          <h3>이더리움 시세</h3>
          <p>{ethPrice} USDT</p>
        </div>

        <div className="box asset-box">나의 자산정보</div>
        <div className="box large">수익률 랭킹</div>
      </div>
    </div>
  );
}

export default App;

STOMP 프로토콜 기반의 Websocket 연결을 통해 시세 정보를 구독하고, 메시지를 수신할 때마다 화면에 표시되는 시세 값을 업데이트한다.

그리고 React에서 소켓통신 그리고 STOMP 프로토콜을 활용하려면 패키지를 받아야한다.

npm install sockjs-client @stomp/stompjs

4. 결과

이러한 구조가 완성이 되었다.

그리고 구현 결과는 단순하긴한데, 이렇다.

5. 잡담

구현과정에서 Websocket 개념, STOMP가 뭔지 찾고 STOMP가 Redis PUB/SUB이랑 어떻게 다른지 이해하는 것이 어려웠다. CS 지식이 여기서 활용되네...

Websocket 구현은 이후 개념들 정리한번해보면서 마무리할 것이다. 다음은 매수/매도를 구현하면서 트랜잭션, 동시성에 대한 고민을 해보겠다.

이번 구현 목표는 "외부 시스템으로부터 시세 정보를 웹소켓을 구독해서 메시지 브로커에 전달"하는 것이다.

웹소켓 서버 언어, 프레임워크 선택

스프링을 백엔드로 하는 플랫폼 웹서버와 분리가 되었기 때문에 다른 언어와 프레임워크로 시세 수신 서버를 구현을 해도 된다는 선택지가 생겼다. 그래서 직접 벤치마크 테스트를 해서 언어와 프레임워크를 선택할까? 했지만, 너무 산으로 가는 것 같았다. 보통 어느 언어와 프레임워크를 사용하는 지 자료를 찾다가 웹소켓 벤치마크 관련 논문자료를 찾았다.

https://www.researchgate.net/publication/348993267_An_Analysis_of_the_Performance_of_Websockets_in_Various_Programming_Languages_and_Libraries

여러 조건하에서 벤치마크 테스트를 한 내용이다. Python은 커넥션이 많아질수록 높은 지연시간, C는 특정구간에서 안정적이지 못한 결과를 가져왔다. 결론으로 Python은 소켓통신으로 비추천이라고 한다.

서비스 환경에 맞게 조건들 조정하고, 자체적으로 테스트해보는 게 확실한데... 참고만하고 그냥 Java, Spring로 가자.

메세지 브로커 프레임워크 선택

눈에 보이는 것들은 Redis, Kafka가 있는데, 토스 세미나 영상에서 메세지 브로커 처리 속도를 비교한 것이 있다. 출처: https://www.youtube.com/watch?v=SF7eqlL0mjw

Redis가 Kafka에 비해 낮은 지연시간, Queue가 없는 PUB/SUB구조라는 장점이 있는데, 대신 Redis로부터 데이터를 수신받는 서버가 처리를 제때 못한다면 메시지가 유실된다는 단점이 있다. 토스는 이걸 Spring의 Redis 라이브러리 구조를 분석하고 이벤트 루프를 구현해서 해결한 것 같은데... Redis로 가자

뭐 구현할꺼임?

필요한 것은 무언인지 생각을 해보자.

구현 요소

1. 서버 내에서 외부 시스템으로부터 데이터를 불러오기
2. 불러온 데이터에서 필요한 데이터만 가공
3. 가공된 데이터를 메시지 브로커로 Publish

이 3가지 기능만 제대로 작동하면 시세수신 서버 구현은 완료다.

1. Spring Project 생성

Websocket 의존성만 추가해서 생성했다. Redis 의존성도 추가해야하는데, 서버 내에서 외부 시스템으로부터 데이터를 불러오는 과정을 먼저 구현해보고 눈으로 보고 싶어서 Webscoket만 추가했다. Redis 의존성은 있다가 추가한다.

2. Bybit Websocket 명세

https://bybit-exchange.github.io/docs/v5/websocket/public/ticker

실시간 시세정보를 받고 싶은 코인 티커를 토픽으로 서버에 전달하면 관련 정보를 웹소켓을 통해 수신할 수 있다. 모의투자플랫폼에서 지원하는 거래는 현물거래가 아닌 선물거래로 진행할 예정이라 "Linear/Inverse" 기준으로 ts, symbol, lastPrice 이 3가지를 가져올 것이다.

설명

1. ts: 시점 (timestamp)
2. symbol: 코인 이름 + 거래 코인단위
3. lastPrice: 마지막 가격

실제로 받아오는 데이터 로그를 찍어보면 시세변동정보뿐만이 아니라 실제 주문이 등록되는 정보들도 수신된다. 시세 정보가 수신되었을때만 Publish 하는 것이 필요하다.

3. Websocket Publish 구현

BybitWebSocketClient.java : 외부 Websocket 구독

package com.example.receivePrice.infra.websocket.bybit;

import jakarta.annotation.PostConstruct;
import org.springframework.stereotype.Component;
import org.springframework.web.socket.client.WebSocketClient;
import org.springframework.web.socket.client.standard.StandardWebSocketClient;

@Component
public class BybitWebSocketClient {
    private static final String BYBIT_WS_URL = "wss://stream.bybit.com/v5/public/linear";
    private final WebSocketClient webSocketClient = new StandardWebSocketClient();
    private final BybitWebSocketHandler handler;

    public BybitWebSocketClient(BybitWebSocketHandler handler) {
        this.handler = handler;
    }

    @PostConstruct
    public void connect() {
        webSocketClient.execute(handler, BYBIT_WS_URL);
        System.out.println("Connecting to Bybit WebSocket...");
    }
}

외부 웹소켓을 연결하는 부분이다. BybitWebSocketClient 클래스는 스프링에서 @Component로 선언되어 서버가 올라갈때, 스프링 컨테이너 내에 Bean으로 등록이 된다. Bean 생성과 의존성 주입이 완료된 직후 @PostConstruct가 붙은 메서드가 실행되고, 이 시점에 외부 Bybit WebSocket 서버로의 연결이 자동으로 이루어진다.

생성자에서 BybitWebSocketHandler를 주입받는데, 이는 BybitWebSocketHandler가 Spring 컨테이너에 Bean으로 등록되어 있어 Spring이 미리 생성해 둔 Bean 인스턴스를 자동으로 주입해준다.

BybitWebSocketHandler.java : 외부 Websocket 구독 이후 처리부

package com.example.receivePrice.infra.websocket.bybit;

import com.example.receivePrice.infra.redis.RedisPricePublisher;
import org.springframework.stereotype.Component;
import org.springframework.web.socket.TextMessage;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;
import tools.jackson.databind.JsonNode;
import tools.jackson.databind.ObjectMapper;

import java.util.List;
import java.util.Map;

@Component
public class BybitWebSocketHandler extends TextWebSocketHandler {
    private final ObjectMapper objectMapper = new ObjectMapper();
    private final RedisPricePublisher publisher;

    public BybitWebSocketHandler(RedisPricePublisher publisher) {
        this.publisher = publisher;
    }

    // 소켓 연결 이후 서버에 보낼 메세지
    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        // subscribe 메세지 (소켓 구독 방법: 문서 참조)
        Map<String, Object> subscribeMsg = Map.of(
                "op", "subscribe",
                "args", List.of("tickers.BTCUSDT", "tickers.ETHUSDT")
        );
        // 연결된 소켓에 메세지 보내기
        session.sendMessage(
                new TextMessage(objectMapper.writeValueAsString(subscribeMsg))
        );
        System.out.println("Subscribed to BTCUSDT, ETHUSDT ticker");
    }

    // 수신 받은 메세지 가공
    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) {
        try {
            JsonNode root = objectMapper.readTree(message.getPayload());

            // 0. ts 노드 확인
            JsonNode timeNode = root.get("ts");
            if (timeNode == null) return;
            String receiveTime = timeNode.asString();

            // 1. data 노드 없으면 무시
            JsonNode dataNode = root.get("data");
            if (dataNode == null) return;

            // 2. symbol
            JsonNode symbolNode = dataNode.get("symbol");
            if (symbolNode == null) return;
            String symbol = symbolNode.asString();

            // 3. lastPrice
            JsonNode lastPriceNode = dataNode.get("lastPrice");
            if (lastPriceNode == null) return;
            String lastPrice = lastPriceNode.asString();

            System.out.println("symbol=" + symbol + ", price=" + lastPrice + ", time=" + receiveTime);

            // Redis publish
            publisher.publish(symbol, lastPrice, receiveTime);


        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void handleTransportError(WebSocketSession session, Throwable exception) {
        System.err.println("WebSocket error: " + exception.getMessage());
    }
}

TextWebSocketHandler를 상속받아와서 구현하였다.

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/socket/handler/TextWebSocketHandler.html TextWebSocketHandler에서 상속받는 메서드들은 여기서 확인할 수 있다.

상속받는 메서드들 중 3가지 메서드를 재정의했다.

재정의 메서드 3가지

• afterConnectionEstablished WebSocket 연결이 성공적으로 완료된 직후 구독 요청 메세지를 보낸다. 연결 session을 저장한다.
• handleTextMessage WebSocket으로 텍스트 메시지를 수신할 때마다 실시간으로 반복 호출되는 부분으로 수신 데이터를 처리한다.
• handleTransportError WebSocket 통신 중 에러 발생 시 처리하는 부분으로 session을 닫거나 연결을 재호출한다.

afterConnectionEstablished

@Override
public void afterConnectionEstablished(WebSocketSession session) throws Exception {
    // subscribe 메세지 (소켓 구독 방법: 문서 참조)
    Map<String, Object> subscribeMsg = Map.of(
            "op", "subscribe",
            "args", List.of("tickers.BTCUSDT", "tickers.ETHUSDT")
    );
    // 연결된 소켓에 메세지 보내기
    session.sendMessage(
            new TextMessage(objectMapper.writeValueAsString(subscribeMsg))
    );
    System.out.println("Subscribed to BTCUSDT, ETHUSDT ticker");
}

웹소켓 연결이후 구독 정보를 외부 서버로 보내고, 그 연결 세션을 저장하는 부분이다. Json 형태로 구독 정보를 보내야되는데, Map을 활용해 Bybit에서 요구하는 형태를 맞추었다.

handleTextMessage

// 수신 받은 메세지 가공
@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) {
    try {
        JsonNode root = objectMapper.readTree(message.getPayload());

        // 0. ts 노드 확인
        JsonNode timeNode = root.get("ts");
        if (timeNode == null) return;
        String receiveTime = timeNode.asString();

        // 1. data 노드 없으면 무시
        JsonNode dataNode = root.get("data");
        if (dataNode == null) return;

        // 2. symbol
        JsonNode symbolNode = dataNode.get("symbol");
        if (symbolNode == null) return;
        String symbol = symbolNode.asString();

        // 3. lastPrice
        JsonNode lastPriceNode = dataNode.get("lastPrice");
        if (lastPriceNode == null) return;
        String lastPrice = lastPriceNode.asString();

       System.out.println("symbol=" + symbol + ", price=" + lastPrice + ", time=" + receiveTime);

        // Redis publish
        publisher.publish(symbol, lastPrice, receiveTime);


    } catch (Exception e) {
        e.printStackTrace();
    }
}

수신받은 데이터를 처리하는 부분이다. Json형태의 데이터를 받아오기 때문에 JsonNode 객체형태로 전처리를 했고, 전처리된 데이터를 Redis로 Publish 했다. publisher는 어디서 구현되었냐고? Redis 연동파트에서 다시 언급하겠다.

트러블슈팅 String symbol = symbolNode.toString(); -> String symbol = symbolNode.asString(); toString()으로 하니깐 값에 "" 큰따옴표가 붙어 Redis-cli 창에서 채널을 구독이 정상적으로 되지않았다. JsonNode 객체의 값만 그대로 사용하고 싶으면 asText()로 변환한다고 한다. API 정리를 위해 asString() 같은 새로운 이름이 도입되었고, asText()와 같은 역할을 하기때문에, asString()으로 변환해주었다.

handleTransportError

@Override
public void handleTransportError(WebSocketSession session, Throwable exception) {
   System.err.println("WebSocket error: " + exception.getMessage());
}

일단 시세수신서버를 분리해놓기도 했고, 데이터가 메세지브로커까지 가는 과정을 확인해보는 것이 1순위라 연결 오류 정보만 띄울 수 있게 해놓았다. 재연결로직은 나중에...

4. Redis 연동

Redis 의존성 추가, properties 정보 추가

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

프로젝트에 Redis 의존성을 추가해준다.

# Setting Redis Connection
spring.data.redis.host=${REDIS_HOST}
spring.data.redis.port=${REDIS_PORT}
spring.data.redis.password=${REDIS_PASSWORD}

Redis 서버 정보를 properties에 추가해준다.

Spring Boot의 Redis Auto Configuration이 해당 설정을 기반으로 RedisConnectionFactory를 생성한다. 이후 RedisConfig에서는 이 RedisConnectionFactory를 주입받아 Redis와의 연결을 수행하는 RedisTemplate를 구성한다.

properties → Auto Configuration → RedisConnectionFactory → RedisTemplate

RedisConfig가 뭔데? 아래있다.

RedisConfig.java

package com.example.receivePrice.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.StringRedisSerializer;

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, String> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        return template;
    }
}

Redis 서버와 통신할때 필요한 정보를 사전에 정의한 부분이다. 서버 정보, 데이터 저장, 전송 형태가 정의되어있다.

RedisPricePublisher.java

package com.example.receivePrice.infra.redis;

import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
import tools.jackson.databind.ObjectMapper;

import java.util.Map;

@Component
public class RedisPricePublisher {
    private final RedisTemplate<String, String> redisTemplate;
    private final ObjectMapper objectMapper = new ObjectMapper();

    public RedisPricePublisher(RedisTemplate<String, String> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void publish(String symbol, String price, String ts) throws Exception {
        String channel = "price:" + symbol;

        Map<String, String> payload = Map.of(
                "symbol", symbol,
                "price", price,
                "ts", ts
        );

        redisTemplate.convertAndSend(
                channel,
                objectMapper.writeValueAsString(payload)
        );
    }

}

Redis Pub/Sub을 통해 시세 데이터를 발행하는 Publisher 부분이다. 코인별로 채널을 분리하고, JSON 형태의 메시지를 Map으로 구성한 후 RedisTemplate를 사용해 Redis로 전송한다.

5. 결과

비트코인, 이더리움 실시간 시세정보가 Redis PUB/SUB으로 올라가는 걸 확인할 수 있다.

6. 잡담

Redis-cli에서 원하는 데이터가 올라올때 신기했다. 이게되네... 코드 작성은 GPT, 구글의 힘으로 어렵진 않았는데, 왜 이런것들을 쓰는지, 다른 방법은 없는지 납득을 하는 과정이 오래 걸렸다.

그리고 코드 내에 의존성 분리를 해야하는 부분들이 보인다. 일단 다 만들어놓고 이후 수정하는 방향으로 기술 부채를 쌓아두자. 지금부터 건들이면 완주가 안된다.

번외: 정리 금방 끝날 줄 알았는데...시간... 토익 언제함

프론트는 React로 구성을 마쳤다. (GPT 없었으면 불가능) 유튜브로 공개된 강의듣고, 코드를 읽고 원하는 대로 바꿀 수 있을 정도로만 익혔다. React의 특징으로 서버에서 렌더링을 하는 것이 아닌 클라이언트단에서 렌더링이 진행이되면서 이걸로 얻을 수 있는 장점들이 여럿 있는 것 같은데, 페이지 넘어갈 때 깜빡이지 않는다 정도로만 이해하고 넘어갔다. 가상돔, 컴포넌트 뭐 이래저래 많은데, 프로젝트 완성하고 깊게 다뤄보는 방향으로 가자. 여기서부터 파보면 한도 끝도 없다...

1. Websocket 구상

단순한 생각

먼저, 프론트에 웹소켓을 구현해서 실시간 시세를 받아오는 경우를 생각해보았다.

사용자가 늘어날 때마다 실시간 시세를 받아오는 Websocket 연결이 늘어날텐데

1. 시세제공 서버로부터 API key 밴부터 먹고 시작하지않을까?
2. 그리고 외부 웹소켓 구독에 필요한 API key가 다 노출될텐데?

그럼 백엔드 서버 1대에서 실시간 시세 Websocket 연결을 관리하고, 클라이언트와 연결하는 Websocket를 각각 생성해서 실시간 시세를 뿌려주자

조금 깊은 생각

그래서 그냥 스프링으로 외부 Websocket 구독하고 스프링에서 웹소켓 열어서 클라이언트에 뿌려주면 되겠다. 라고 쉽게 생각했다. 여기서 이유는 모르겠는데 이질감이 들었다.

1. 클라이언트가 많아지면 서버 한대가 그 많은 웹소켓 연결을 관리할 수 있을까?

-> Scale-out으로 백엔드 서버 갯수를 늘리면 감당이 된다. 2. 그러면 시세제공 서버와 Websocket 연결도 늘어나겠네? 3. 그런데 각 서버가 받는 데이터가 모두 일치할까? 4. 비즈니스로직을 처리하는 백엔드서버에서 실시간 시세도 받는다?

이제서야 이렇게 4가지로 고민의 흔적을 정리하는데, 이질감이 들었을땐 그냥 막막해서 바로 구현에 들어가기보다 웹소켓을 활용해 실시간 서비스를 구현한 자료를 많이 찾아보았다. 많은 블로그 자료를 통해 메시지 브로커라는 존재를 알았다. 근데 왜 쓰는 거냐에 대해 확실하게 와닿는 글들은 없었다. 공식문서가 아니니깐...

[ 토스ㅣSLASH 23 - 실시간 시세 데이터 안전하고 빠르게 처리하기 ] https://www.youtube.com/watch?v=SF7eqlL0mjw 토스증권에서 실시간 시세 데이터를 다룬 방법에 대해 고민한 영상이 가장 도움되었다. 메시지 브로커를 도입하는 이유에 대해 Scale-out, MSA 구조들을 예시로 들어가며 설명해주는데, 메시지 브로커를 사용하는 이유에 대한 고민이 해결되었다.

도움이 된 부분 수신부가 늘어난 처리부에 일일 모두 데이터를 보내주어야하는데 이 때 수신부의 성능이 떨어진다. 해결: 메시지 브로커 도입을 통해 수신부와 처리부의 결합도를 낮추고, 수신부는 데이터를 한번만 보내면된다.

결론

메시지 브로커 도입으로 해결

1. 외부 시세 수신 로직과 비즈니스 로직의 결합도를 낮춘다.
2. Scale-out으로 늘어나는 백엔드 서버로 넘어가는 데이터 일관성도 확보할 수 있다.
3. 그리고 외부 시세제공 서버와 WebSocket 연결을 1개만 유지할 수 있다.
4. 시세를 수신하는 서버에서 데이터를 메시지 브로커에 한번만 보낼 수 있다.

2. 잡담

꿀벌집인줄 알고 건들였더니 말벌집이다. "실시간 정보를 처리할 때는 웹소켓이란 기술을 활용한다."만 알고 덤볐는데 존재만 알고 있던 Redis Pub/Sub, Kafka와 같은 메시지 브로커 역할을 하는 기술들에 대해 접할 수 있는 기회였다. 구현 언제함.

하반기 IT 신입 공고가 시들해지고, 날도 추워져서 1주일간 동면에 들어가면서 부족했던 부분에 대해 생각을 해보았다.

스타트업을 나오고 부트캠프를 시작으로 이력서 부분을 채울 수 있는 활동을 해왔다. 그리고 원하는 기업으로 취업까지 이어졌으면 정말 좋았겠지만, 그렇게 쉽게 될리가 없었다. 연속된 실패에도 억지로 루틴지켜가며 취업준비를 이어가려고 했으나 한계다. 그렇게 1주일간 동면에 들어갔다.

그동안의 성과들을 돌이켜보면 AI 기술을 써서 완성한 성과들이 많은데, Web, DB에서 다루게되는 트랜잭션, 동시성, 웹소켓통신, 인증/인가에 대해 고민해본적이 없다. 그래서 그걸 채워보고자 이 모의투자 플랫폼 프로젝트를 진행하려고 한다.

1. 모의투자를 종목을 코인으로

미국주식, 국내주식도 많은데 왜 굳이 코인으로 하냐면, 실시간으로 가격과 오더북을 제공하는 웹소켓 API가 의외로 코인쪽이 누구나 쓸 수 있게 오픈되어있다. 그리고 24시간 오픈되어있어 무언가 테스트를 할 때, 시간에 제약을 받지않을 것이라 생각하여 코인으로 설정하였다. 한국투자증권에서도 제공하는 웹소켓 API가 잘되어 있긴하지만, 시간 제약 조건을 뛰어넘기에는 그렇게 와닿진 않았다.

2. 요구사항 명세서

부트캠프 교육에서 배웠던 문서화 방법을 통해 어느정도 정리하면서 프로젝트를 진행하려고 한다. 그냥 머릿속에 있는 내용을 그대로 구현으로 옮기기에는 날마다 보는 관점이 달라지니깐 프로젝트가 산으로 가는 것을 방지하려고 명세서부터 작성해본다.

3. 와이어프레임

메인페이지	로그인페이지

회원가입페이지	이체페이지

마이페이지	기록페이지

종목페이지	주문페이지

화면은 단순하다. React를 써볼지는 좀만 더 고민해보자.

4. E-R 다이어그램

ERD까지해서 테이블 정의까지 할까? 개발하면서 추가되고 제거될 것들이 많아질 것 같아 일단 다이어그램으로만 정리했다.

5. 잡담

이 프로젝트를 통해 확실하게 건져갈 것은 트랜잭션, 동시성, 웹소켓통신, 인증/인가이다. 이게 취업에 도움이 되는가? 그건 모르겠다. 그냥 하자. 뭐라도 도움되겠지.

1. DFS - 백트래킹

코딩테스트에서 백트래킹을 활용하여 풀어야하는 문제는 종종 나온다. 개인적으로 BFS, DFS는 개념적인 어려움보단 구현에 있어 신경써야하는 것들이 좀 있고, 풀기위해서 세팅해야하는 것들이 많아 구현만 어느정도 익숙해지면 놓치기 아까운 문제라고 생각한다. DFS를 활용한 백트래킹을 어떻게 구현하는 지 단계별로 정리해보자.

import java.io.*;
import java.util.StringTokenizer;

// 각 종류 색종이 5개씩

public class Main {
    private static int[][] adj = new int[10][10];
    private static int[] paper = {0, 5, 5, 5, 5, 5};
    private static int answer = Integer.MAX_VALUE;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringTokenizer st;

        for (int i = 0; i < 10; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < 10; j++) {
                adj[i][j] = Integer.parseInt(st.nextToken());
            }
        }

        dfs(0, 0);
        if (answer == Integer.MAX_VALUE) {
            bw.write("-1");
        } else {
            bw.write(Integer.toString(answer));
        }

        bw.flush();
        br.close();
        bw.close();
    }

    private static void dfs(int yx, int count) {
        if (count >= answer) return;
        if (yx == 100) {
            if (answer > count) {
                answer = count;
            }
            return;
        }
        int y = yx / 10;
        int x = yx % 10;

        if (adj[y][x] == 1) {
            for (int i = 1; i <= 5; i++) {
                if (paper[i] > 0 && check(y, x, i)) {
                    fill(y, x, i, 0);
                    paper[i]--;
                    dfs(yx + 1, count + 1);
                    fill(y, x, i, 1);
                    paper[i]++;
                }
            }
        } else {
            dfs(yx + 1, count);
        }
    }

    private static boolean check(int y, int x, int size) {
        if ((y + size) > 10 || (x + size) > 10) return false;
        for (int i = y; i < y + size; i++) {
            for (int j = x; j < x + size; j++) {
                if (adj[i][j] == 0) return false;
            }
        }
        return true;
    }

    private static void fill(int y, int x, int size, int flag) {
        for (int i = y; i < y + size; i++) {
            for (int j = x; j < x + size; j++) {
                adj[i][j] = flag;
            }
        }
    }
}

그래프 및 공유할 변수들

private static int[][] adj = new int[10][10];
private static int[] paper = {0, 5, 5, 5, 5, 5};
private static int answer = Integer.MAX_VALUE;

전역으로 설정하자. 정신건강을 위해서. 메서드 파라미터로 넘길 수 있는데, 머리아프다. 문제 푸는데 의의를 두고 전역으로 두자. 파이썬은 global 변수로 관리해야하는데, 자바는 클래스 내에서 전역으로 설정하면 클래스 내에서 공유가 되니 이건 파이썬보다 훨씬 편하다.

탐색 위치 체크 및 방문 여부 체크 그리고 액션

private static boolean check(int y, int x, int size) {
    if ((y + size) > 10 || (x + size) > 10) return false;
    for (int i = y; i < y + size; i++) {
        for (int j = x; j < x + size; j++) {
            if (adj[i][j] == 0) return false;
        }
    }
    return true;
}

그래프를 인접행렬로 구현했다면 필수적으로 해야하는 부분이다. 만약, 그래프를 인접리스트로 구현했다면 방문여부만 체크해주면 된다.

if (adj[i][j] == 0) return false;

이 문제에서는 방문여부를 색종이로 채웠냐 안채웠냐로 체크를 한다. 다른 문제에서는 방문여부를 별도의 boolean 배열을 전역으로 설정해서 체크해주는 경우가 많다.

private static void fill(int y, int x, int size, int flag) {
    for (int i = y; i < y + size; i++) {
        for (int j = x; j < x + size; j++) {
            adj[i][j] = flag;
        }
    }
}

방문을 했을 경우 취할 액션이다. 색종이 붙이기 문제에서는 그래프에 종이를 덮는다 가 액션이다. 해당 문제에서는 방문여부를 true로 변환해주는 액션을 이렇게 변형을 한 것이다.

백트래킹 구현

private static void dfs(int yx, int count) {
    if (count >= answer) return;
    if (yx == 100) {
        if (answer > count) {
            answer = count;
        }
        return;
    }
    int y = yx / 10;
    int x = yx % 10;

    if (adj[y][x] == 1) {
        for (int i = 1; i <= 5; i++) {
            if (paper[i] > 0 && check(y, x, i)) {
                fill(y, x, i, 0);
                paper[i]--;
                dfs(yx + 1, count + 1);
                fill(y, x, i, 1);
                paper[i]++;
            }
        }
    } else {
        dfs(yx + 1, count);
    }
}

단순히 짧은 경로를 탐색할 때는 재귀에서 빠져나오는 경우, 복원해주야하는 요소가 없다. 목표지점까지 경로를 카운팅해주고, 최소값을 답으로 던져주면 되니깐. 그런데 백트래킹은 다르다. 재귀에서 빠져나올때 방문여부나 변화된 변수들 상태들을 복원해주어야한다. 다른 방법으로 같은 경로를 접근할 때, 이전에 했던 방법이 영향을 주면 안되니깐.

fill(y, x, i, 0);
paper[i]--;
dfs(yx + 1, count + 1);
fill(y, x, i, 1);
paper[i]++;

색종이 붙이기 문제애서는 방문시 액션이 종이를 채우는 것이다. 그리고 가지고 있는 종이 갯수를 소모하는 것. 재귀에서 빠져나올 때 이 액션을 복원해주는 것이다. 다른 액션을 취할 때 영향을 주면 안되니깐.

if (count >= answer) return;
if (yx == 100) {
    if (answer > count) {
        answer = count;
    }
    return;
}

조건을 만족하는 경우 재귀를 마무리하는 것을 상단에 구현한다. 재귀에 들어왔을 때, 현재 위치가 최종 종착지인지 여부를 체크해준다. 그리고 최소값을 구하는 건데, 이미 현재 카운팅하고 있는 값이 최소값보다 크다면 그 경로는 더이상 탐색을 하지 않아도 되니, 가지치기를 해준다! (최적화)

DFS - 백트래킹 구조

1. 그래프 및 공유할 변수들 설정
2. 탐색 위치 체크 및 방문 여부 체크 그리고 액션
3. 백트래킹 구현: 복원과 가지치기

2. 정리하며...

DFS, BFS 기본 문제를 많이 풀어서 자신있다고 생각했는데, 색종이 붙이기 문제는 신경써야할 것들이 많이 변형되어서 많이 당황스러웠다. 방문시 취해야할 액션들을 하나하나 정리해서 그대로 구현에만 옮긴다면 큰 문제는 없을 것으로 생각된다. 계속 나아가자, 될 때까지.

1. 분할정복 - 병합정렬

병합정렬은 분할정복 방식을 사용해서 데이터를 분할하고 분할한 집합을 정렬해가며 합치는 알고리즘이다. 병합 정렬의 시간 복잡도 평균값은 O(nlogn)이다. 잘게 분할하고 합쳐가면서 정렬, 개념은 이해된다. 이걸 어떻게 구현하는 것인지 아래 코드를 보면서 이해해보자.

import java.io.*;
import java.util.StringTokenizer;

public class Main {
    public static int[] arr;
    public static long answer = 0;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        int n = Integer.parseInt(br.readLine());
        arr = new int[n];
        StringTokenizer st = new StringTokenizer(br.readLine());
        for (int i = 0; i < n; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }

        sort(arr, 0, n - 1);

        bw.write(Long.toString(answer));
        bw.flush();
        br.close();
        bw.close();
    }

    // 분할 정복 : 재귀로 구현
    private static void sort(int[] arr, int left, int right) {
        // 길이가 1이면 빠져나오기
        if (left == right) {
            return;
        }

        int mid = (left + right) / 2;

        // 왼쪽 분할
        sort(arr, left, mid);
        // 오른쪽 분할
        sort(arr, mid + 1, right);
        // 정렬
        merge(arr, left, mid, right);
    }

    private static void merge(int[] arr, int left, int mid, int right) {
        int leftLength = mid - left + 1;
        int rightLength = right - mid;

        int[] leftTmp = new int[leftLength];
        int[] rightTmp = new int[rightLength];

        for (int i = 0; i < leftLength; i++) {
            leftTmp[i] = arr[left + i];
        }
        for (int i = 0; i < rightLength; i++) {
            rightTmp[i] = arr[mid + 1 + i];
        }

        int leftIdx = 0;
        int rightIdx = 0;
        int oriIdx = left;

        // 분할 이후 합병 정렬
        while (leftIdx < leftLength && rightIdx < rightLength) {
            if (leftTmp[leftIdx] <= rightTmp[rightIdx]) {
                arr[oriIdx] = leftTmp[leftIdx];
                if ((left + leftIdx) > oriIdx) {
                    answer += (left + leftIdx) - oriIdx;
                }
                leftIdx++;
            } else {
                arr[oriIdx] = rightTmp[rightIdx];
                if ((rightIdx + mid + 1) > oriIdx) {
                    answer += (rightIdx + mid + 1) - oriIdx;
                }
                rightIdx++;
            }
            oriIdx++;
        }

        // 왼쪽 배열 나머지 채우기
        while (leftIdx < leftLength) {
            arr[oriIdx] = leftTmp[leftIdx];
            leftIdx++;
            oriIdx++;
        }

        // 오른쪽 배열 나머지 채우기
        while (rightIdx < rightLength) {
            arr[oriIdx] = rightTmp[rightIdx];
            rightIdx++;
            oriIdx++;
        }
    }
}

분할

전체코드는 이렇다. 재귀호출로 분할을 하고, 재귀에서 빠져나오면서 정렬이 되는 방식으로 구현하였다. 재귀호출로 분할하고 빠져나오는 부분은 다음과 같다.

    private static void sort(int[] arr, int left, int right) {
        // 길이가 1이면 빠져나오기
        if (left == right) {
            return;
        }

        int mid = (left + right) / 2;

        // 왼쪽 분할
        sort(arr, left, mid);
        // 오른쪽 분할
        sort(arr, mid + 1, right);
        // 정렬
        merge(arr, left, mid, right);
    }

이해해보기

1st

sort라는 메서드를 재귀호출하는 과정을 생각해보면

1. 배열의 중간값을 계산
2. 왼쪽, 오른쪽으로 분할
3. 분할할 배열 길이가 1이 될때까지 왼쪽 분할 로 이어진다.

2nd

길이가 1이되고 나서 재귀에서 빠져나오면 오른쪽 분할 재귀로 넘어가는데, 이때 전달된 왼쪽, 오른쪽 인덱스 파라미터를 생각해보면 길이가 1짜리인 오른쪽 배열이 새롭게 정렬 대상이 된다. 그렇게 merge라는 메소드를 만나게 되면서 분할된 왼쪽과 오른쪽이 만나면서 병합 정렬이 일어난다.

병합 및 정렬

private static void merge(int[] arr, int left, int mid, int right) {
        int leftLength = mid - left + 1;
        int rightLength = right - mid;

        int[] leftTmp = new int[leftLength];
        int[] rightTmp = new int[rightLength];

        for (int i = 0; i < leftLength; i++) {
            leftTmp[i] = arr[left + i];
        }
        for (int i = 0; i < rightLength; i++) {
            rightTmp[i] = arr[mid + 1 + i];
        }

        int leftIdx = 0;
        int rightIdx = 0;
        int oriIdx = left;

        // 분할 이후 합병 정렬
        while (leftIdx < leftLength && rightIdx < rightLength) {
            if (leftTmp[leftIdx] <= rightTmp[rightIdx]) {
                arr[oriIdx] = leftTmp[leftIdx];
                if ((left + leftIdx) > oriIdx) {
                    answer += (left + leftIdx) - oriIdx;
                }
                leftIdx++;
            } else {
                arr[oriIdx] = rightTmp[rightIdx];
                if ((rightIdx + mid + 1) > oriIdx) {
                    answer += (rightIdx + mid + 1) - oriIdx;
                }
                rightIdx++;
            }
            oriIdx++;
        }

        // 왼쪽 배열 나머지 채우기
        while (leftIdx < leftLength) {
            arr[oriIdx] = leftTmp[leftIdx];
            leftIdx++;
            oriIdx++;
        }

        // 오른쪽 배열 나머지 채우기
        while (rightIdx < rightLength) {
            arr[oriIdx] = rightTmp[rightIdx];
            rightIdx++;
            oriIdx++;
        }
    }

1. 원본 배열에서 인덱스를 파라미터로 받아 왼쪽 배열과 오른쪽 배열을 임시적으로 만들고
2. 왼쪽, 오른쪽 배열 투포인터 방식으로 인덱스를 옮겨가며 원본배열에 값을 다시 채운다.
3. 한쪽이 배열의 끝까지 탐색이 끝났으면, 나머지 한쪽 배열을 그대로 이어붙인다. 이 때, 양쪽 배열 모두 각각 정렬이 끝난 상태이니 나머지 요소를 그대로 이어붙여도 정렬 상태가 깨지지 않는다.

2. etc...

    private static boolean isPrime(int num) {
        if (num < 2) {
            return false;
        }
        for (int i = 2; i <= (int) Math.sqrt(num); i++) {
            if (num % i == 0) {
                return false;
            }
        }
        return true;
    }

시간 복잡도를 생각한 소수 판별 메서드인데 for (int i = 2; i <= (int) Math.sqrt(num); i++) 이부분 암기해놓자. 종종 쓰인다.

3. 정리하며...

분할정복에 관한 아이디어는 코테 문제를 풀면서 떠오르긴하지만, 어떻게 구현을 했더라에서 막힌 경험이 여러번 있었다. O(nlogn)이라는 시간복잡도로 최적화에 많은 도움을 줄 듯하다.

1. 선언형-함수형 프로그래밍

1. 무엇을 풀어내는가에 집중하는 패러다임
2. 프로그램은 함수로 이루어진 것이다 라는 명제가 담겨 있는 패러다임
3. 순수 함수를 블록처럼 쌓아 로직을 구현, 고차 함수를 통해 재사용성을 높인 패러다임

• 순수 함수: 출력이 입력에만 의존하는 것
• 고차 함수: 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것

고차 함수를 쓰기위해서는 해당 언어가 일급 객체라는 특징을 가져야한다. 일급객체 변수나 메서드에 함수를 할당할 수 있다. 함수 안에 함수를 매개변수로 담을 수 있다. 함수가 함수를 반환할 수 있다.

2. 객체지향 프로그래밍

OOP, Object-Oriented Programming으로

1. 객체들의 집합으로 프로그램의 상호 작용을 표현
2. 데이터를 객체로 취급
3. 객체 내부에 선언된 메서드를 활용 하는 방식을 말한다.

특징

1. 추상화: 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려 내는 것
2. 캡슐화: 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉
3. 상속성: 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장
4. 다형성: 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것을 말함 (대표적으로 오버로딩, 오버라이딩)

• 오버로딩: 같은 이름을 가진 메서드를 여러 개 두는 것 (메서드의 타입, 매개변수 유형, 개수 등으로 여러개 둘 수 있다.), 컴파일 중에 발생하는 정적 다형성
• 오버라이딩: 주로 메서드 오버라이딩을 말하고, 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것 의미, 이는 런타임 중에 발생하는 동적 다형성!

설계 원칙

객체지향 프로그래밍을 설계할 때 SOLID 원칙을 지켜야한다.

1. SRP (Single Responsibility Principle): 단일 책임의 원칙 모든 클래스는 각각 하나의 책임만 가져야하는 원칙

2. OCP (Open Closed Principle): 개방-폐쇄의 원칙 유지 보수 사항이 있으면 코드를 쉽게 확장하고 수정할 때는 닫혀 있어야 하는 원칙

3. LSP (Liskov Substitution Principle): 리스코프 치환 원칙 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야하는 것 ex) 부모, 자식 계층 관계에서 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가게 만드는 것

4. ISP (Interface Segregation Principle): 인터페이스 분리 원칙 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙

5. DIP (Dependency Inversion Principle): 의존 역전 원칙 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스에 두어 변하기 쉬운 것의 변화에 영향을 받지 않게 하는 원칙 ex) 타이어를 갈아끼울 수 있는 틀 만들고, 다양한 타이어를 교체 가능해야함

    -> 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립

3. 절차형 프로그래밍

로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있다. 일이 진행되는 방식으로 그저 코드를 구현

• 코드의 가독성이 좋고 실행속도가 빠르다.
• 계산이 많은 작업에 쓰인다.

단점으로 모듈화가 어렵고 유지 보수성이 떨어진다.

1. 싱글톤 패턴

싱글톤 패턴 개념

하나의 클래스에서 오직 하나의 인스턴스만 가지는 패턴이다. 하나의 클래스에서 여러개의 개별적인 인스턴스를 만들어낼 수 있지만, 하나만 생성해서 관리하는 것이다. ex) 데이터베이스 연결

클래스, 객체, 인스턴스

1. 클래스: 변수와 메서드를 가지는 명세서, 설계도
2. 객체: 클래스로 구현할 어떤 것
3. 인스턴스: 객체를 실체화 시킨 것

인스턴스를 하나만 생성해서 관리하니깐, 구현과 유지보수가 쉬워보이지만 아니다. 단점은 다음과 같다.

1. TDD에서 걸림돌이 된다. 단위 테스트 위주로 하는 테스트 주도 개발에서 테스트가 서로 독립적이고, 테스트를 어떤 순서로도 실행할 수 있어야되는데, 미리 생성된 인스턴스를 기반으로 구현하는 패턴이라 독립적인 인스턴스를 만들기가 어렵다.
2. 결합도 문제 모듈간의 결합도를 강하게 만든다. 이 때, DI (Dependency Injection)을 활용하여 결합도를 느슨하게 만들 수 있다.
3. Java의 멀티쓰레드 환경 싱글톤 패턴으로 인스턴스를 생성할 때, 생성된 인스턴스가 있는지 먼저 검사를 하는 방식으로 구현이 되어있는 경우, 여러개의 쓰레드가 해당 인스턴스를 여러개 생성할 수 있다. (Thread Safe 문제 발생)

DI (Dependency Injection) 메인 모듈이 직접 하위 모듈에 의존성을 주기보단, 별도의 의존성 주입자 (Dependency Injecter)가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식

• A가 B에 의존성이 있다는 것은 B의 변경 사항에 A도 변해야 된다는 것을 의미

의존성 주입의 장점

1. 상위 모듈이 하위 모듈에 대한 의존성이 감소된다.
2. 모듈을 쉽게 교체할 수 있는 구조가 된다. (테스팅, 마이그레이션 수월)
3. 추상화 레이어를 기반으로 구현체를 넣기 때문에 애플리케이션의 의존성 방향이 일관적 (쉬운 기능 추론, 모듈 간의 관계 명확)

의존성 주입의 단점

1. 모듈들이 분리되어 클래스 수가 늘어나 복잡성이 증가 (약간의 런타임 패널티 발생!)

참고 SOLID에서 DIP (의존성 주입 원칙) 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다. 둘 다 추상화에 의존! 추상화는 세부 사항에 의존하지 말아야 한다.

Thread Safe 문제해결방법

1. 싱글톤 패턴으로 인스턴스를 생성하는 메서드에 synchronized 접근제어자를 추가하여 쓰레드 하나가 접근 중일 때, 다른 쓰레드는 접근을 하지 못하게 락을 걸 수 있다. 대신, 인스턴스를 가져올 때마다 락이 걸리기 때문에 불필요한 오버헤드가 발생한다는 단점이 있다.
2. 정적멤버방식으로 JVM이 클래스를 로드할 때 미리 싱글톤 객체를 생성할 수도 있다. 다만, 이는 자원낭비로 이어질 수 있다.

다른 여러가지 방법도 많지만, 여기까지 정리하겠다.

2. 팩토리 패턴

객체를 생성하는 부분을 따로 분리하여 구현하는 패턴이다. 상속관계에 있는 두 클래스에서 상위 클래스는 객체 생성에 필요한 중요한 뼈대, 하위 클래스에서는 객체 생성에 관한 구체적인 내용을 결정한다.

팩토리 패턴 종류

1. 단순 팩토리 패턴
2. 팩토리 메서드 패턴
3. 추상 팩토리 패턴

Java 단순 팩토리 패턴

enum CoffeeType {
    LATTE,
    ESPRESSO
}

abstract class Coffee {
    protected String name;

    public String getName() {
        return name
    }
}

class Latte extends Coffee {
    public Latte() {
        name = "latte";
    }
}

class Espresso extends Coffee {
    public Espresso() {
        name = "Espresso"
    }
}

class CoffeeFactory {
    public static Coffee createCoffee(CoffeeType type) {
        switch (type) {
            case LATTE:
                return new Latte();
            case ESPRESSO:
                return new Espresso();
            default:
                throw new IllegalArgumentException("Invalid coffee type: " + type);
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Coffee coffee = CoffeeFactory.createCoffee(CoffeeType.LATTE);
        System.out.println(coffee.getName()); // latte
    }
}

팩토리 밑에 객체 뼈대를 담당하는 상위 클래스를 두고, 해당 클래스를 상속하여 객체 생성을 담당하는 하위 클래스를 두어 구현한다. 팩토리에서는 생성할 객체의 타입을 받아 분기처리해서 객체를 반환한다.

단순 팩토리 패턴 장점

1. 상위 클래스와 하위 클래스가 분리되기 때문에 느슨합 결합을 가짐
2. 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없어 더 많은 유연성을 가지게 됨
3. 객체 생성 로직이 분리되어 있어서 유지 보수성이 증가

단순 팩토리 패턴 단점

1. 새로운 클래스를 추가하거나 제거할 때마다 조건문을 수정해야 한다.

SOLID의 OCP 위반 (확장에는 열려있으나, 수정에는 닫혀있어야한다.)

그래서 팩토리 메서드 패턴과 추상 팩토리 패턴이 나왔다.

3. 전략 패턴

정책 패턴이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고, 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴

ex) 결제 시스템 (카카오페이? 토스페이?), 로그인 방식 (서비스 내? OAuth?)

4. 옵저버 패턴

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴

주체: 객체의 상태 변화를 보고 있는 관찰자 옵저버: 객체 상태 변화에 따라 추가 변화가 생기는 객체들 ex) 유튜브 알림, 트위터 알림, MVC

• MVC: 모델에서 변경 사항이 생겨, update로 뷰에 알려주고 컨트롤러가 작동한다.
• 주체와 객체를 분리하는 경우와 한번에 두는 경우가 있다.

import java.util.ArrayList;
import java.util.List;

interface Subject {
    public void register(Observer obj);
    public void unregister(Observer obj);
    public void notifyObservers();
    public Object getUpdate(Observer obj);
}

interface Observer {
    public void update();
}

class Topic implements Subject {
    private List<Observer> observers;
    private String massage;

    public Topic() {
        this.observers = new ArrayList<>();
        this.message = "";
    }

    @Override
    public void register(Observer obj) {
        if (!observers.contains(obj)) observers.add(obj);
    }

    @Override
    public void unregister(Observer obj) {
        observers.remove(obj);
    }

    @Override
    public void notifyObservers() {
        this.observers.forEach(Observer::update);
    }

    @Override
    public Object getUpdate(Observer obj) {
        return this.message;
    }

    public void postMessage(String msg) {
        System.out.println("Message sended to Topic: " + msg);
        this.message = msg;
        notifyObservers(); // 옵저버에게 상태변화 알림
    }
}

class TopicSubscriber implements Observer {
    private String name;
    private Subject topic;

    public TopicSubscriber(String name, Subject topic) {
        this.name = name;
        this.topic = topic;
    }

    // 구독중인 옵저버들에게 상태 변화에 대한 알림이 감
    @Override
    public void update() {
        String msg = (String) topic.getUpdate(this);
        System.out.println(name + ":: got message >> " + msg);
    }
}

public class HelloWorld {
    public static void main(String[] args) {
        Topic topic = new Topic();
        Observer a = new TopicSubscriber("a", topic);
        Observer b = new TopicSubscriber("b", topic);
        Observer c = new TopicSubscriber("c", topic);
        topic.register(a);
        topic.register(b);
        topic.register(c);

        topic.postMessage("hello everyone!");
    }
}

/*
Message sended to Topic: hello everyone!
a:: got message >> hello everyone!
b:: got message >> hello everyone!
c:: got message >> hello everyone!
*/

자바 상속과 구현

1. 상속(extends): 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용하며 자식 클래스에서 추가 및 확장을 할 수 있는 것을 말한다. 이를 통해 재사용성, 중복성의 최소화가 이루어 짐
2. 구현(implements): 부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것, 상속과는 달리 반드시 부모클래스의 메서드를 재정의하여 구현해야한다.

• 상속은 일반 클래스, abstract 클래스 기반으로 구현, 구현은 인터페이스 기반으로 구현

5. 프록시 패턴

대상 객체에 접근하기 전에 그 접근에 대한 흐름을 가로채 해당 접근을 필터링하거나 수정하는 역할을 하는 계층이 있는 패턴

1. 객체의 속성, 변환 등을 보완
2. 보안, 데이터 검증, 캐싱, 로깅에 사용

프록시 서버

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램

예시

1. nginx: 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버

-> 서버 앞단의 프록시 서버로 활용 -> 실제 포트를 숨기고, 정적 자원 gzip으로 압축, 메인 서버 앞단에서 로깅 가능 2. CloudFlare: 웹 서버 앞단에 프록시 서버로 두어 DDOS 공격 방어나 HTTPS 구축에 쓰인다. -> 의심스러운 트래픽은 CAPTCHA를 기반으로 일정부분 막아줌 3. CDN :각 사용자가 인터넷에 접속하는 곳과 가까운 곳에서 콘텐츠를 캐싱 또는 배포하는 서버 네트워크 -> 이를 통해 웹 서버로 부터 콘텐츠를 다운로드하는 시간을 줄일 수 있음

CORS와 프론트엔드의 프록시 서버

CORS(Cross-Origin Resource Sharing): 서버가 웹 브라우저에서 리소스를 로드할 때, 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘

• 오리진: 프로토콜과 호스트 이름, 포트의 조합을 말한다.

프론트엔드 포트와 백엔드 포트가 다르면 테스팅 중 CORS 에러가 난다. 프록시 서버를 통해 프론트엔드에서 요청되는 오리진을 동일하게 수정해주면 테스팅이 진행이 된다.

6. 이터레이터 패턴

이터레이터를 사용하여 컬렉션의 요소들에 접근하는 패턴이다. 순회할 수 있는 여러 가지 자료형의 구조와 상관없이 이터레이터라는 하나의 인터페이스로 순회가 가능

• 이터레이터 프로토콜: 이터러블한 객채들을 순회할 때 쓰이는 규칙
• 이터러블한 객체: 반복 가능한 객체로 배열을 일반화한 객체

7. 노출모듈 패턴

즉시 실행 함수를 통해 private, public 같은 접근제어자를 만드는 패턴 ex) 자바스크립트는 접근 제어자가 없어, 전역 범위에서 스크립트가 실행된다. -> 해당 패턴으로 접근 제어자를 구현하기도 한다.

접근 제어자 정리

1. public: 클래스에 정의된 함수에서 접근 가능, 자식 클래스와 외부 클래스에서 접근 가능
2. protected: 클래스에 정의된 함수에서 접근 가능, 자식 클래스는 접근 가능, 외부 클래스는 접근 불가
3. private: 클래스에 정의된 함수에서 접근 가능, 자식 클래스와 외부 클래스에서 접근 불가
4. 즉시 실행 함수: 함수를 정의하자마자 바로 호출하는 함수, 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용한다.

8. MVC 패턴

Model, View, Controller로 이루어진 패턴 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다.

• 장점: 재사용성과 확장성이 용이
• 단점: 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡

Model

1. 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 의미
2. 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신

View

1. 사용자 인터페이스 요소 -> 모델을 기반으로 사용자가 볼 수 있는 화면
2. 모델이 가지고 있는 정보를 따로 저장X, 단순히 화면에 표시하는 정보만 가지고 있어야 한다.
3. 변경이 일어나면 컨트롤러에 이를 전달

Controller

1. 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할 -> 이벤트 등 메인 로직을 담당
2. 모델과 뷰의 생명주기 관리, 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에 해당 내용을 알려준다.

Spring: 디스패처 서블릿의 요청 처리 과정을 이해해보자...

MVC로부터 파생된 패턴

• MVP 패턴

1. MVC의 Controller가 Presenter로 교체된 패턴
2. 뷰와 프레젠터는 일대일 관계여서 MVC 패턴보다 더 강한 결합을 지닌 패턴

• MVVM 패턴

1. MVC의 Controller가 뷰모델(view model)로 바뀐 패턴
2. 뷰모델은 뷰를 더 추상화한 계층, MVC패턴과 다르게 커맨드와 데이터 바인딩을 가짐
3. 뷰와 뷰모델 사이의 양방향 데이터 바인딩 지원, UI를 별도의 코드 수정 없이 재사용가능, 단위 테스팅하기 쉽다는 장점
4. 값 대입만으로 변수가 변경, 양방향 바인딩, html을 토대로 컴포넌트를 구축, 재사용 가능한 컴포넌트를 기반으로 UI를 구축가능 (Vue.js)

• 커맨드: 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법
• 데이터 바인딩: 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치, 뷰모델을 변경하면 뷰가 변경된다.

1. 자소설닷컴 vs 인디스워크 응답속도

자소설닷컴 응답속도	인디스워크 응답속도

자소설닷컴 응답대기 시간은 95.22ms, 인디스워크 응답대기 시간은 2.18s 이다. 채용사이트이고 다루는 데이터가 비슷한데, 응답대기 시간은 20배가 넘게 차이가 난다. 캐시를 하는 데이터가 없어서 그런지 응답들을 확인해보았으나, 이미지 같은 것들은 캐시 데이터에서 활용해서 페이지를 로드하는 것을 알 수 있었다.

인디스워크는 ETag 전략으로 캐시 데이터를 관리한다는 것도 추가적으로 알 수 있었다. 그럼 똑같이 한국에서 서비스를 하는데, 왜 서버 응답대기 시간이 20배 넘게 차이가 날까?

프록시 캐시에 대한 개념을 배우면서, 서버와 클라이언트간에 물리적인 거리로 인해 응답지연이 발생하고 그것을 해결하기 위해 프록시 서버를 둔다는 사실을 알게 되었다. 이 덕분에 서버의 물리적인 거리 차이에서 응답대기 시간의 차이를 만든다는 생각으로 이어질 수 있었다. 그래서 서버의 위치를 찾아봤다.

2. 서버 위치 찾기

물리적인 서버 위치를 찾기에는 정보가 없으니깐... 서버의 대략적인 위치를 추측해보기 위해 도메인으로 서버 위치를 찾아봤다.

http://www.ipipipip.net/

이 링크에서 두 사이트를 찍어보았다.

자소설닷컴 서버위치	인디스워크 서버위치

자소설닷컴은 도메인을 국내 호스팅 업체의 네임서버, 인디스워크는 해외 호스팅 업체의 네임서버를 활용한다는 것을 알 수 있었다. 서버의 물리적인 거리 차이로 인해 응답대기시간이 길어지고, 같은 국내 사이트더라도 네임서버 위치에 따라 응답속도 차이가 발생할 수 있다는 것을 확인했다.

3. 결론

자소설닷컴은 국내, 인디스워크는 해외 호스팅 업체를 통해 도메인을 할당받았고, 호스팅 업체의 네임서버의 물리적인 위치차이로 인해 20배가 넘는 응답속도 차이가 발생한다고 추측해본다. 그리고 인디스워크가 이용하는 해외 호스팅 업체는 국내에 프록시 서버가 없는 듯하다.

응답속도를 개선하기 위해서는 호스팅 업체를 국내로 바꾸는 방법이 제일 쉬운 방법으로 보인다...

캐시가 없을 때는 같은 요청을 반복하더라도 같은 용량의 데이터를 전송한다.

캐시가 없을 경우

1. 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
2. 인터넷 네트워크는 매우 느리고 비싸다.
3. 브라우저 로딩 속도가 느리다.
4. 느린 사용자 경험 느리고, 그만큼 네트워크에 불필요한 부하가 걸린다

캐시

cache-control 헤더를 통해 캐시 유효시간을 설정하여 첫 번째 요청을 처리하면, 시간 내에 같은 요청이 들어오면 캐시 데이터를 활용한다. 단. 캐시 시간이 초과되었을 경우, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이 때, 다시 네트워크 다운로드가 발생한다.

캐시가 있을 경우

1. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
2. 비싼 네트워크 사용량을 줄일 수 있다.
3. 브라우저 로딩 속도가 매우 빠르다.
4. 빠른 사용자 경험 빠르고, 그만큼 네트워크에 불필요한 부하를 줄일 수 있다

캐시 시간 초과

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음

서버에서 데이터를 변경하지 않았을 경우

1. 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
2. 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요 -> 검증 헤더

검증 헤더를 통해 캐시 시간 초과되었을 경우에도, 캐시를 재활용할 수 있게 한다. 예시는 다음과 같다.

Last-Modified 헤더 추가를 통해 데이터의 최종 수정일 정보도 기록한다.

If-Modified-Since (조건부 요청) 요청 헤더를 붙여서 서버로 넘기고, 데이터 최종 수정일이 변경된 사항이 없으면 만료된 캐시를 재활용할 수 있다. 304 Not Modified 응답, 캐시 유효시간 재설정, HTTP 바디 없이 헤더 정보만 전송한다.

조건에 부합하는 데 왜 304? modified: 수정된, since: ~이후에 if-modified-since: 이 날짜 이후에 수정되었니? 서버에서 기존 데이터 변경사항이 없으면 수정이 안된거다. 이 날짜 이후에 수정되었니?에 대한 답변은 아니오. 이므로 304 응답이 오고, 캐시를 재활용한다.

캐시 시간 초과일 경우 정리를 하면 다음과 같다. 1. 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 -> 304 Not Modified + 헤더 메타 정보만 응답 (바디X) 2. 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신 3. 클라이언트는 캐시에 저장되어 있는 데이터 재활용 4. 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

2. 검증 헤더와 조건부 요청 헤더

예시 If-Modified-Since: 이후에 데이터가 수정되었으면?

• 데이터 미변경 예시
  • 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
  • 304 Not Modified, 헤더 데이터만 전송(Body 미포함)
  • 전송 용량 0.1M (헤더 0.1M, 바디 1.0M)
• 데이터 변경 예시
  • 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
  • 200 OK, 모든 데이터 전송 (Body 포함)
  • 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

Last-Modified, If-Modified-Since 단점

1. 1초 미만 (0.x초) 단위로 캐시 조정이 불가능
2. 날짜 기반의 로직 사용
3. 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
4. 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag, If-None-Match

1. 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 예) ETag: "v1.0", ETag: "studyhttp"
2. 데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash를 다시 생성) 예) ETag: "aaaaa" -> ETag: "bbbbb"
3. 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!

ETag 헤더 추가를 통해 데이터의 고유버전을 저장

If-None-Match (조건부 요청) 요청 헤더를 붙여서 서버로 넘기고, 데이터 고유버전 변경된 사항이 없으면 만료된 캐시를 재활용할 수 있다.

ETag 활용시

1. 캐시 제어 로직을 서버에서 완전히 관리
2. 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름) 예시 1) 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지 예시 2) 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

3. 캐시 제어 헤더

4. 프록시 캐시

원 서버에 접근하기에는 거리에 비례히여 응답속도가 느려진다 -> 프록시 캐시 도입

Cache-Control 캐시 지시어 (directives) - 기타

1. Cache-Control: public 응답이 public 캐시에 저장되어도 됨
2. Cache-Control: private 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
3. Cache-Control: s-maxage 프록시 캐시에만 적용되는 max-age
4. Age: 60 (HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

5. 캐시 무효화

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

이걸 다 넣어주어야 확실한 캐시 무효화 응답이 된다.

1. Cache-Control: no-cache 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
2. Cache-Control: no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
3. Cache-Control: must-revalidate 캐시 만료후 최초 조회시 원 서버에 검증해야함 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout) must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
4. Pragma: no-cache HTTP 1.0 하위 호환

must-revalidate가 필요한 이유

no-cache는 프록시 캐시 서버가 원 서버와 순간 네트워크가 단절되면, 오류 보다는 오래된 데이터라도 보여주는 경우가 많다. must-revalidate는 504 Gateway Timeout을 띄운다.

6. 마무리하며...

HTTP 강의를 완강하면서, 데이터가 네트워크를 통해 전달되는 과정, 그리고 그 상태에 따라 서비스를 설계 하는 전략, 개발자의 시선으로 통신을 최적화하는 개발 방법에 대해 알게 되었다... API 서버를 띄우고 Postman으로 API 기능을 검사할 때, 뜨는 응답 값들이 이러한 깊은 의미들을 가지고 있다는 것을 배울 수 있었다.

하반기 취업준비전략 변경과 동시에 시작한 웹 관련 강의듣고 포스팅하기... 이런저런 이유로 중간중간 포기를 하고 싶을 때가 많았다. 그리고 최근 최악의 1주일을 보내게 되면서 그동안 노력했던 것들에 대한 허무함이 다가왔다. 그래도 버틸 수 있는 건 여러가지 이유가 있지만, 강의 듣고 포스팅이라는 루틴이 그 중 하나다. 이러한 루틴이 있기 때문에 실패를 하더라도 변경한 전략에 대해 흔들리지 않을 수 있다는 생각이 든다.

근데, 지금은 진짜 큰일남. 다음 포스팅부터 웹 강의듣고 내용 정리방식은 잠시 멈출 것이다. 면접을 위한 CS 준비, 그리고 자바 코딩테스트 준비 위주로 정리를 할 예정이다.

일단, 취업을 위한 공부에 집중하자... 그래야 Next가 있다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/YZxop

강의 자료 중 일부를 포스팅에 활용해서 출처용으로 겸사겸사 링크를 달아두었다.

1. HTTP 전송에 필요한 모든 부가정보
2. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등
3. 표준 헤더가 너무 많음
4. 필요시 임의의 헤더 추가 가능

과거 표준 (RFC 2616)

HTTP 헤더 General 헤더: 메시지 전체에 적용되는 정보, ex) Connection: close Request 헤더: 요청 정보, ex) User-Agent: Mozilla/5.0 Response 헤더: 응답 정보, ex) Server: Apache Entity 헤더: 엔티티 바디 정보, ex) Content-Type: text/html, Content-Length: 3423
HTTP 바디 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공

1999년 RFC2616 (폐기) 2014년 RFC7230~7235 (등장)

현재 표준 (RFC 7230)

HTTP 헤더 엔티티(Entity) -> 표현(Representation)으로 개념이 바뀌었다. Representation = representation Metadata + Representation Data
HTTP 바디 메시지 본문(message body)을 통해 표현 데이터 전달 메시지 본문 = 페이로드(payload) - 보내고자하는 데이터 그 자체 표현은 요청이나 응답에서 전달할 실제 데이터 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공 참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야하지만, 여기서 생략

페이로드(payload)는 택배를 예시로 들자면, 택배를 보낼 물건 - payload임 택배와 관련된 송장 정보들 - payload가 아님

2. 표현 (representation)

3. 협상 (content negotiation)

클라이언트가 선호하는 표현 요청

1. Accept: 클라이언트가 선호하는 미디어 타입 전달
2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩
3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
4. Accept-Language: 클라이언트가 선호하는 자연 언어 협상 헤더는 요청시에만 사용

협상의 우선 순위를 정하기 위해서 Quality Values(q) 값 사용한다.

협상과 우선순위1

0~1 사이의 값을 가지고, 클수록 높은 우선순위를 가진다. 생략하면 1이다.

예시 Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

1. ko-KR;q=1 (생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en;q=0.7

협상과 우선순위2

구체적인 것이 우선한다.

예시 Accept: text/*, text/plain, text/plain;format=flowed, */*

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

협상과 우선순위3

구체적인 것을 기준으로 미디어 타입을 맞춘다.

예시 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

4. 전송방식

5. 일반 정보

6. 특별한 정보

TCP/IP는 IP로만 통신을 하기 때문에, 도메인 정보가 담긴 Host가 필수적으로 있어야한다.

7. 쿠키

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답) Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

쿠키가 필요한 이유 (로그인 예시) Stateless한 HTTP 특성상 로그인한 상태 서버는 모른다. 대안: 모든 요청에 사용자 정보 포함 -> 모든 요청에 사용자 정보가 포함되도록 개발 해야함 -> 브라우저를 완전히 종료하고 다시 열면? 문제가 많다...

쿠키 흐름

1. 서버에서 Set-Cookie를 통해 로그인 정보를 쿠키로 말고, 클라이언트에서 쿠키 저장소에 저장한다.

2. 클라이언트는 이후 쿠키 저장소에서 조회해서 Cookie 정보에 로그인 정보를 넣어서 요청을 보낸다.

사용처

1. 사용자 로그인 세션 관리
2. 광고 정보 트래킹
   

쿠키 정보는 항상 서버에 전송됨

1. 네트워크 트래픽 추가 유발
2. 최소한의 정보만 사용(세션 id, 인증 토큰)
3. 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage)
   

주의! 보안에 민감한 데이터는 저장하면 안됨 (주민번호, 신용카드 번호 등등)

쿠키 - 생명주기

1. Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT 만료일이 되면 쿠키 삭제
2. Set-Cookie: max-age=3600 (3600초) 0이나 음수를 지정하면 쿠키 삭제
3. 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지
4. 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

1. 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함 domain=example.org를 지정해서 쿠키 생성

    example.org는 물론이고
    dev.example.org도 쿠키 접근

2. 생략: 현재 문서 기준 도메인만 적용 example.org에서 쿠키를 생성하고 domain 지정을 생략

    example.org에서만 쿠키 접근
    dev.example.org는 쿠키 미접근

도메인을 명시하는 것과 안하는 것으로 쿠키 활용 범위가 달라진다.

쿠키 - 경로

Path 이 경로를 포함한 하위 경로 페이지만 쿠키 접근 일반적으로 path=/루트 로 지정

쿠키 - 보안

1. Secure 쿠키는 http, https를 구분하지 않고 전송 Secure를 적용하면 https인 경우에만 전송
2. HttpOnly XSS 공격 방지 자바스크립트에서 접근 불가 (document.cookie) HTTP 전송에만 사용
3. SameSite XSRF 공격 방지 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

8. 정리하며...

현재 기억에 남는 것은 쿠키의 흐름과 활용방식에 대해서만 기억이 난다. 용어가 많아 한눈에 안 들어오는데, 중요해보이는 쿠키는 확실하게 남기고 가자...

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗 https://inf.run/YZxop

HTTP 상태코드란? 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 이를 통해 처리 상태에 대한 응답에 따라 다음 작업을 설계하거나, 서버의 응답이 성공인지 실패인지, 실패라면 그 원인이 클라이언트의 문제인지 서버의 문제인지 파악할 수 있다.

상위 상태코드와 그 의미 1xx (Informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

만약 모르는 상태 코드가 나타나면? 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? 클라이언트는 상위 상태코드로 해석해서 처리한다. 그래서 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

1xx (Informational)

요청이 수신되어 처리중

• 거의 사용하지 않으므로 생략

2xx (Successful)

200 OK

• 요청 성공

  201 Created

• 요청 성공해서 새로운 리소스가 생성됨
• 생성된 리소스는 응답의 Location 헤더 필드로 식별

  202 Accepted

• 요청이 접수되었으나 처리가 완료되지 않았음
• 배치 처리 같은 곳에서 사용 ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

  204 No Content

• 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 ex) 웹 문서 편집기에서 save 버튼 save 버튼의 결과로 아무 내용이 없어도 된다. save 버튼을 눌러도 같은 화면을 유지해야 한다. 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

다양한 상태코드가 많지만, 개발 시작전 사용할 코드를 협의를 한다. 200만 사용하는 경우가 많고, 201까지 사용하는 경우도 있다.

3xx (Redirection)

리다이렉션 이해

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

자동 리다이렉트 흐름

여기서 301은 요청 메서드가 GET으로 바뀐다.

종류 1. 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동 ex) /members -> /users ex) /event -> /new-event 2. 일시 리다이렉션: 일시적인 변경 주문 완료 후 주문 내역 화면으로 이동 PRG: Post/Redirect/Get 3. 특수 리다이렉션 결과 대신 캐시를 사용

영구 리다이렉션

301, 308

• 리소스의 URI가 영구적으로 이동
• 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
• 301 Moved Permanently 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
• 308 Permanent Redirect 301과 기능은 같음 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

308을 왜 쓰냐? 301은 등록을 위해 데이터를 POST를 보냈으나, 리다이렉트 후 보내는 요청은 메시지 바디가 빈 GET 요청 처음부터 등록하려던 것을 처음부터 입력해야한다. 이걸 308로 해결할 수 있다. 그런데 다른 페이지로 돌릴 때, 대부분 받는 정보가 다 달라 301로 하는 경우가 많다.

일시적인 리다이렉션

302, 307, 303

• 리소스의 URI가 일시적으로 변경
• 따라서 검색 엔진 등에서 URL을 변경하면 안됨
• 302 Found 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
• 307 Temporary Redirect 302와 기능은 같음 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
• 303 See Other 302와 기능은 같음 리다이렉트시 요청 메서드가 GET으로 변경

PRG: Post/Redirect/Get

일시적인 리다이렉션 - 예시

• POST로 주문 후에 웹 브라우저를 새로고침하면?
• 새로고침은 다시 요청
• 중복 주문이 될 수 있다.

PRG 패턴으로 해결!

• POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
• POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청 Location 태그가 포함된 302로 리다이렉션이 키포인트.

PRG 이후 리다이렉트 URL이 이미 POST -> GET으로 리다이렉트 됨 새로 고침 해도 GET으로 결과 화면만 조회

기타 리다이렉션

• 300 Multiple Choices: 안쓴다.
• 304 Not Modified 캐시를 목적으로 사용 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.) 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로) 조건부 GET, HEAD 요청시 사용

4xx (Client Error)

클라이언트 오류 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음 오류의 원인이 클라이언트에 있음 중요! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음

• 요청 구문, 메시지 등등 오류
• 클라이언트는 요청 내용을 다시 검토하고, 보내야함
• ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요함

• 인증(Authentucation) 되지 않음
• 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
• 참고 인증(Authentucation): 본인이 누구인지 확인, (로그인) 인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음) 오류 메시지가 Unauthorized 이지만 인증 되지 않음 (이름이 아쉬움)

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

• 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• ex) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

404 Not Found

요청 리소스를 찾을 수 없음

• 요청 리소스가 서버에 없음
• 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

5xx (Server Error)

서버 오류 서버 문제로 오류 발생 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음 (복구가 되거나 등등)

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 500 오류

• 서버 내부 문제로 오류 발생
• 애매하면 500 오류

503 Service Unavailable

서비스 이용 불가

• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
• Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

서버에 비즈니스 로직에서 예외 케이스가 발생했을 때, 5xx으로 내면 안된다! ex) 고객의 잔고가 부족할 경우 진짜 서버에 문제가 있을 때, 5xx를 사용한다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/YZxop

1. 클라이언트 > 서버 데이터 전송

전송하는 방식

1. 쿼리 파라미터를 통한 데이터 전송
   • GET
   • 정렬 필터 (검색어)
2. 메시지 바디를 통한 데이터 전송
   • POST, PUT, PATCH
   • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

전송하는 상황

1. 정적 데이터 조회

   • 이미지, 정적 텍스트 문서
   • 조회는 GET 사용
   • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

2. 동적 데이터 조회

   • 주로 검색, 게시판 목록에서 정렬 필터 (검색어)
   • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
   • 조회는 GET 사용
   • GET은 쿼리 파라미터 사용해서 데이터를 전달

3. HTML Form을 통한 데이터 전송

   • 회원 가입, 상품 주문, 데이터 변경

     1. HTML Form submit시 POST 전송 Content-Type: application/x-www-form-urlencoded 사용 form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식) 전송 데이터를 url encoding 처리
     2. HTML Form은 조회 목적일 경우 GET 전송도 가능
     3. HTML Form은 여러 형태의 데이터를 한꺼번에 전송 가능 (POST) Content-Type: multipart/form-data 파일 업로드와 같은 바이너리 데이터 전송시 사용 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)
     4. 참고 HTML Form 전송은 GET, POST만 지원

4. HTTP API를 통한 데이터 전송

   • 회원 가입, 상품 주문, 데이터 변경
   • 서버 to 서버 (백엔드 시스템 통신)
   • 앱 클라이언트 (아이폰, 안드로이드)
   • 웹 클라이언트 HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX) React, Vue.js 같은 웹 클라이언트와 API 통신
   • Content-Type: application/json

2. HTTP API 설계 예시

API 설계를 할 때, 단순 조회도 중요하지만, 데이터를 변경하는 상황인 데이터 등록, 그리고 HTML Form을 활용하여 데이터를 다루는 상황을 중점으로 정리해보자. 회원 관리 시스템을 예시로 정리해보겠다.

API 설계 - POST 기반 등록

POST - 신규 자원 등록 특징 1. 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /members -> POST POST /members 2. 서버가 새로 등록된 리소스 URI를 생성해준다. HTTP/1.1 201 Created Location: /members/100 3. 컬렉션(Collection) 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리 여기서 컬렉션은 /members

API 설계 - PUT 기반 등록

PUT - 신규 자원 등록 특징 1. 클라이언트가 리소스 URI를 알고 있어야 한다. 파일 등록 /files/{filename} -> PUT PUT /files/star.jpg 2. 클라이언트가 직접 리소스의 URI를 지정한다. 3. 스토어(Store) 클라이언트가 관리하는 리소스 저장소 클라이언트가 리소스의 URI를 알고 관리 여기서 스토어는 /files

API 설계 - HTML Form 사용

HTML Form은 GET, POST만 지원 AJAX 같은 기술을 사용해서 해결 가능 -> 회원 API 참고 여기서는 순수 HTML, HTML Form 이야기 GET, POST만 지원하므로 제약이 있음

HTML Form - 신규 자원 등록 특징 1. HTML Form은 GET, POST만 지원 2. 컨트롤 URI GET, POST만 지원하므로 제약이 있음 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용 POST의 /new, /edit, /delete가 컨트롤 URI HTTP 메서드로 해결하기 애매한 경우 사용 (HTTP API 포함)

3. URI 설계 개념

1. 문서(document) 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row) ex) /members/100, /files/star.jpg

2. 컬렉션(collection) 서버가 관리하는 리소스 디렉터리 서버가 리소스의 URI를 생성하고 관리 ex) /members

3. 스토어(store) 클라이언트가 관리하는 자원 저장소 클라이언트가 리소스의 URI를 알고 관리 ex) /files

4. 컨트롤러(controller), 컨트롤 URI 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행 동사를 직접 사용 ex) /members/{id}/delete

4. 정리하며...

POST와 PUT의 차이, 그리고 순수 HTML Form과 ajax를 활용했을 때 차이를 중점으로 가져가보자. PUT은 실무에서 많이 쓰이지는 않지만, 게시판 수정과 같은 기능에서 어울리는 방법이다. HTML Form은 HTML코드에서 GET과 POST요청을 생성하여 전송하지만, GET과 POST만 지원한다는 한계가 있다. 이 한계를 해결하기위해 동사로 명명한 컨트롤러 URI를 통해 추가 프로세스를 실행하는 방법과 자바스크립트에서 실행되는 ajax를 활용하여 한계를 해결할 수 있다.

이정도 남기고, 다음으로 넘어가자...

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗 https://inf.run/YZxop

HTTP API를 만들 때, 요구사항을 식별하고 그에 맞는 URI를 설계하는 것이 필요하다. 다음 예시로 그 과정을 들어보겠다.

요구사항 - API URI 설계 (1)

이게 정말 좋은 URI일까? URI 설계에서 가장 중요한 것은 리소스 식별이다.

API URI 고민사항

• 리소스의 의미 회원을 등록하고 수정하고 조회하는게 리소스가 아니다! ex) 미네랄을 캐라! -> 미네랄이 리소스
• 회원*이라는 개념 자체가 바로 리소스다.
• 리소스 식별 방법 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하면 된다 -> 회원 리소스를 URI에 매핑

요구사항 - API URI 설계 (2)

리소스 식별 중심으로 URI 설계를 했다. 그런데, 회원 조회, 회원 등록, 회원 수정, 회원 삭제는 어떻게 구분하지???

리소스와 행위 분리

• 리소스와 해당 리소스를 대상으로 하는 행위를 분리 리소스: 회원 행위: 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사 행위는 어떻게 구분함? -> GET, POST 같은 HTTP 메서드

요구사항 - API URI 설계 (최종)

최종 모습은 이렇게 될 것이다...

2. HTTP 메서드 - GET, POST, PUT, PATCH, DELETE

메서드 종류

GET

리소스 조회

1. 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
2. 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

POST

요청 데이터 처리

1. 메시지 바디를 통해 서버로 요청 데이터 전달
2. 서버는 요청 데이터를 처리 - 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
3. 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

   참고 응답 코드로 200 ok 대신에 201 Created 쓰기도 한다. 단, 이 때는 리소스가 위치하는 정보인 Location: /members/100 정보도 함께 보내준다.

요청 데이터 처리한다는 것의 의미 공식 스펙: POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다.

예시

• HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공 HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시 게시판 글쓰기, 댓글 달기
• 서버가 아직 식별하지 않은 새 리소스 생성 신규 주문 생성
• 기존 자원에 데이터 추가 한 문서 끝에 내용 추가하기

POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 즉, 정해진 것이 없다

POST 정리

1. 새 리소스 생성(등록)

• 서버가 아직 식별하지 않은 새 리소스 생성

2. 요청 데이터 처리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우 ex) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음 ex) POST /oreders/{orderId}/start-delivery (컨트롤 URI) <- 행위의 URI가 나올 수도 있다!

3. 다른 메서드로 처리하기 애매한 경우 ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

애매하면 조회라도 POST로 가능하다. 메시지를 내부에 담아서 할 수 있는 것들, POST는 모든 것을 할 수 있다. 단, 조회는 캐싱 때문에 GET이 유리, POST는 캐싱을 하기 어렵다.

PUT

리소스를 대체

1. 리소스가 있으면 대체
2. 리소스가 없으면 생성

쉽게 이야기해서 덮어버림

POST와 차이점으로 클라이언트가 리소스를 식별한다. 클라이언트가 리소스 위치를 알고, URI 지정하여 요청을 보낸다.

주의 리소스를 완전히 대체한다. 여러 필드 중에 하나만 수정하고 싶다고 하나만 넣으면, 나머지 기존 필드 데이터는 날아간다.

PATCH

리소스 부분 변경 PATCH가 지원이 안되는 서버가 있다. 그런 경우는 POST를 쓰면 된다!

DELETE

리소스 제거

3. HTTP 메서드의 속성

Safe(안전)

호출해도 리소스를 변경하지 않는다. Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면? A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다 안전을 판단할 땐, 리소스만!

Idempotent(멱등)

f(f(x)) = f(x) 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

멱등 메서드 GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다. PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

멱등이 아닌 메서드 POST: 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

멱등 개념 활용 분야 자동 복구 메커니즘 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거가 된다.

Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리면? 사용자1: GET -> username: A, age: 20 사용자2: PUT -> username: A, age: 30 사용자3: GET -> username: A, age: 30 A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지는 않는다.

Cacheable(캐시가능)

응답 결과 리소스를 캐시 GET, HEAD, POST, PATCH 캐시가능 실제로 는 GET, HEAD 정도만 캐시로 사용 POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗 https://inf.run/YZxop

HyperText란? 문서 간에 링크를 통해서 연결할 수 있는 것!

HTTP 메시지에 모든 것을 전송할 수 있다.

1. HTML, TEXT
2. IMAGE, 음성, 영상, 파일
3. JSON, XML (API)

거의 모든 형태의 데이터 전송 가능하다. 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용한다.

참고 HTTP/1.1: 가장 많이 사용 HTTP/2, HTTP/3 (진행중) - 성능 개선 초첨 HTTP/3는 TCP 대신 UDP 사용

기반 프로토콜

HTTP가 패킷을 전달할 때, 기반으로하는 프로토콜은 버전별로 다음과 같다.

1. TCP: HTTP/1.1, HTTP/2 2. UDP: HTTP/3

HTTP 특징

1. 클라이언트 서버 구조
2. 무상태 프로토콜(Stateless), 비연결성
3. HTTP 메시지
4. 단순함, 확장성

아래 내용부터 이 특징들을 하나씩 정리해보겠다.

2. 클라이언트 서버 구조

1. Request Response 구조
2. 클라이언트는 서버에 요청을 보내고, 응답을 대기
3. 서버가 요청에 대한 결과를 만들어서 응답

클라이언트와 서버가 개념이 분리되고, 비즈니즈 로직은 서버, UI/UX는 클라이언트에 집중(독립)할 수 있다는 것이 중요!

3. 무상태 프로토콜 (Stateless)

1. 서버가 클라이언트의 상태를 보존X
2. 장점: 서버 확장성 높음 (스케일 아웃)
3. 단점: 클라이언트가 추가 데이터 전송

Stateful - 예시

Stateful - 점원이 일정한 경우

Stateful - 점원이 중간에 바뀌는 경우

Stateful 항상 같은 서버가 유지가 되어야 한다. 응답해주던 서버가 맛이 가면 클라이언트는 처음부터 다시 해야한다.

Stateless - 예시

이 경우에는 중간에 점원이 바뀌더라도, 요청마다 필요한 정보를 모두 전달하므로 응답에 문제가 없다. 즉, 고객이 무엇을 요청해왔는 지, 서버에서 그 상태를 저장할 필요없이 설계하는 것이 Stateless이다.

Stateless 상태를 보관하지 않으니깐, 아무 서버나 호출해도 된다. 그래서 스케일 아웃(수평 확장)에 유리하다.

Stateful, Stateless 차이

Stateful: 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다.)

Stateless: 중간에 다른 점원으로 바뀌어도 된다.

• 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
• 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

Stateless 실무 한계

모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

• Stateless로 가능한 것 -> 로그인이 필요 없는 단순한 서비스 소개 화면
• Stateful이 필요한 것 -> 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지한다. 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지한다.

따라서, Stateful은 최소한만 사용하는 방향으로 설계하는 것이 중요하다. 그리고 Stateless의 단점으로 보내야하는 데이터가 너무 많다는 단점이 있다.

Stateless를 구현하기 정말 어려운 상황 정말 같은 시간에 딱! 맞추어서 발생하는 대용량 트래픽 ex) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록 ex) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청 항상 Stateless하게 설계하는 것이 중요하다! 머리를 갈아넣더라도...

4. 비연결성 (connectionless)

연결을 유지하는 모델 특징

• TCP 연결이후 작업이 끝나고 연결 유지한다.
• 서버자원 소모한다.

연결을 유지하지 않는 모델 특징

• TCP 연결이후 작업이 끝나면 연결 해제한다.
• 최소한의 자원 사용한다.

HTTP는 기본이 연결을 유지하지 않는 모델이다.

• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음 ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버 자원을 매우 효율적으로 사용할 수 있다.

그런데, 연결을 유지하지 않는 모델이 최소한의 자원만 사용하는 것 같아 장점만 있는 것 같지만 아니다.

• HTTP 요청을 보낼 때마다 TCP/IP 연결을 새로 맺어야한다.
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지등 수많은 자원들이 함께 다 다운로드된다.

이러한 문제들은 응답시간을 늦추는 한계가 된다. 이를 해결하기 위해 HTTP 지속 연결 (Persistent Connections)로 문제를 해결하고 있고, HTTP/2, HTTP/3에서 더 많은 최적화가 이루어지고 있다.

HTTP 초기	HTTP 지속 연결 적용

5. HTTP 메시지

empty line(CRLF) 무조건 있어야한다. 공식 스펙에 명시되어 있다.

start-line

header

Content-Type: text/html;charset=UTF-8
Content-Length: 3423

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) field-name은 대소문자 구분 없음

용도

• HTTP 전송에 필요한 모든 부가정보가 다 있다. (body를 제외한 필요한 모든 메타데이터가 여기 있다.)
• 표준 헤더가 많다
• 필요시 임의의 헤더도 추가가 가능하다.

message body

용도

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능

정리하며...

오늘 정리한 게 난잡해보여서 맘에 들지가 않는다... 일단 가져갈 것은 1. Stateless의 구조로 수평적인 확장이 자유로운 것 2. 비연결성의 구조지만 지속 연결이라는 최적화를 통해 한계를 해결 3. HTTP 구조가 단순해서 여기저기 확장이 가능하다 정도 확실하게 가져가자.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/YZxop

1. URI (Uniform Resource Identifier)

URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류 될 수 있다.

Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것 (제한 없음) Identifier: 다른 항목과 구분하는 데 필요한 정보

큰 개념으로 URI(리소스를 식별), 그안에 작은 개념으로 URL(리소스 위치), URN(리소스 이름)이 있다.

URL - Uniform Resource Locator foo://example.com:8042/over/there?name=ferret#nose
URN - Uniform Resource Name urn:example:animal:ferret:nose !! 이름만 부여한 것, 실제 리소스의 위치를 잡아주려면 별도의 맵핑 과정이 필요함.

URN 특징

1. 위치는 변할 수 있지만, 이름은 변하지 않는다.
2. urn:isbn:8960777331 (어떤 책의 isbn URN)
3. URN 이름만으로 실제 리소스를 찾을 수 있는 방법은 보편화 되지 않음
4. URI 와 URL을 같은 의미로 보고 서술

전체문법

https://www.google.com/search?q=hello&hl=ko

• 프로토콜: https
• 호스트명: www.google.com
• 포트번호: 443
• 패스: /search
• 쿼리 파라미터(q=hello&hl=ko)

scheme://[userinfo@]host[:port][/path][?query][#fragment]

scheme

1. 주로 프로토콜 사용
2. 어떤 방식으로 자원에 접근 할 것인가 하는 약속 규칙
3. http, https, ftp 등
4. http - 80, https - 443 포트를 주로 사용, 포트는 생략 가능
5. https는 http에 보안 추가 (HTTP Secure)

userinfo@

1. URL에 사용자정보를 포함해서 인증
2. 거의 사용하지 않음

host

1. 호스트명
2. 도메인명 또는 IP 주소를 직접 입력

PORT

1. 접속 포트
2. 일반적으로 생략, 생략시 http는 80, https는 443

/path

1. 리소스 경로(path), 계층적 구조

   /home/file1.jpg /members /members/100, /items/iphone12

?query

1. key=value 형태
2. ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB
3. query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태

#fragment

1. 잘 사용하진 않음
2. html 내부 북마크 등에 사용 <- 써본 기억이 있다....
3. 서버에 전송되는 정보는 아님

2. 웹 브라우저 요청 흐름

1. 데이터 생성 (클라이언트)

• DNS 서버 조회, PORT 정보 조회 -> HTTP 요청 메시지 생성
• SOCKET 라이브러리를 통해 전달
• TCP/IP 패킷 생성, HTTP 메시지 포함

2. 서버에 전송

3. HTTP 응답 메시지 생성 (서버)

• 1번 데이터 생성 과정과 동일
• HTTP 메시지가 응답 메시지로 바뀐 것일 뿐....

4. 클라이언에 전송

5. 웹 브라우저 HTML 렌더링 (우리가 보는 화면)

위에 그림처럼 클라이언트에서 HTTP 메시지를 생성해서 패킷을 서버로 전송하고, 위의 단계와 같이 HTML 정보를 수신하여 렌더링을 하면, 우리가 보는 화면이 나오게 된다.

HTTP 메시지에는 어떤 것들이 포함되어 있는 지, 어떻게 다뤄야하는 지 다음 글부터 정리하겠다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/YZxop

많은 웹 서비스는 HTTP 프로토콜 위에서 데이터를 주고 받는다. 웹 개발 공부를 하다보면 HTTP 용어가 많이 등장하는 데, 이 때 깊이있는 이해를 위해서는 HTTP에 대한 이해가 필요하다. 그리고 웹 개발을 하다보면 API URL, PUT, POST, HTTP 상태코드와 관련된 고민을 하게 되는 데, 이때 HTTP에 대한 지식이 활용된다. 그래서 웹 개발만 한다고 해서 HTTP와 같은 CS 공부를 무시할 수 없다. 이론적인 공부라 정말 하기 힘들지만 해야되는 이유를 되새기며 정리를 시작해본다.

애플리케이션 계층에 있는 HTTP를 이해하기 위해서는 그 아래 계층에 있는 인터넷 네트워크에 대한 이해가 필요하다. 따라서, 먼저 인터넷 네트워크와 관련된 내용을 정리하고자 한다.

1. 인터넷 통신

클라이언트와 서버가 직접적으로 연결이 되어 있다면, 중간과정 없이 클라이언트에서 요청을 보내면 서버에서 보낸 응답을 직접 받게 된다. 하지만, 다수의 클라이언트와 서버, 멀리 떨어진 클라이언트와 서버들과 통신을 하기 위해 중간에 인터넷이라는 것을 거치면서 요청과 응답을 처리할 수 있게 되었다. 여기서 인터넷망은 여러개의 노드들로 되게 복잡하게 이루어져 있는데, 통신을 어떻게 하는 것인가? 그렇게 등장한 것이 IP 이다.

2. IP (Internet Protocol)

클라이언트와 서버가 인터넷 망을 거쳐서 통신을 하기위해서 각각 IP 주소를 부여받아야한다.

IP의 역할 지정한 IP 주소(IP Address)에 데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달

이 때, IP 패킷에는 출발지 IP, 목적지 IP 정보가 포함되어 있으며 다음과 같은 과정에서 활용된다. 노드끼리 목적지를 위한 경로를 찾아주며 목적지 IP에 전송 데이터가 도달된다. 도착 이후 목적지에서는 성공적으로 받았다는 응답을 역으로 출발지 IP로 던져준다.

데이터를 주고받는 데 문제가 없어보이지만, IP로만 통신하기에는 다음과 같은 한계점이 존재한다.

IP 프로토콜의 한계점

• 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송된다. ex) 클라이언트는 서버의 상태를 모르는 상태에서 패킷을 보낸다.
• 비신뢰성 중간에 패킷이 사라질 경우 패킷이 순서대로 안오는 경우 ex) 인터넷 망 중간 노드가 문제가 생길 경우 패킷이 그대로 소실된다.
• 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 ex) 1500byte가 넘어가게 되면 패킷을 쪼개서 보내는 데, 이 때 각각의 패킷이 다른 노드를 거치게 되면서 순서가 바뀔 수도 있다.

그래서 등장한 것이 TCP 이다.

3. TCP (Transmission Contril Protocol)

TCP는 IP 프로토콜이 가진 문제점들을 해결해준다.

TCP를 이해를 위해 인터넷 프로토콜 스택의 4계층은 다음과 같다.

1. 애플리케이션 계층 - HTTP, FTP
2. 전송 계층 - TCP, UDP
3. 인터넷 계층 - IP
4. 네트워크 인터페이스 계층 - LAN 장비, LAN 드라이버

프로토콜 계층

한눈에 들어어는 것은 애플리케이션, OS, 네트워크 인터페이스가 끝이다. 채팅 프로그램을 예시로 들면 다음과 같다.

참고: 이더넷 프레임은 MAC 주소와 같이 물리적인 주소를 포함하고 있다.

TCP/IP 패킷 정보

출발지 IP, 목적지 IP 정보가 있는 IP 패킷 안에 TCP 세그먼트 정보가 들어가는데, 여기에 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등이 있다. 이렇게 IP 프로토콜을 보완해주는 TCP 특징은 다음과 같다.

TCP 특징 연결지향 - TCP 3 way handshake (가상 연결) 데이터 전달 보증 순서 보장

연결지향 - TCP 3 way handshake

connect, 연결과정은 다음과 같다.

3번째 과정에서 ACK와 함께 데이터 전송이 가능하다. SYN: 접속 요청 ACK: 요청 수락

데이터 전달 보증

다음과 같은 순서로 보증이 된다.

1. 클라이언트 - 데이터 전송
2. 서버 - 데이터 잘 받았음

순서 보장

다음과 같은 순서로 보장이 된다.

1. 클라이언트 - 패킷1, 패킷2, 패킷3 순서로 전송
2. 서버 - 패킷1, 패킷3, 패킷2 순서로 도착
3. 서버 - 패킷2부터 다시 보내

4. UDP (User Datagram Protocl)

UDP는 TCP와는 달리 거의 기능이 없어 특징이 다음과 같다.

UDP 특징 연결 지향 X 데이터 전달 보증 X 순서 보장 X 단순하고 빠르다.

IP와 비교하면 기능이 거의 같지만, PORT, Checksum 정도만 추가된다. PORT는 하나의 IP에서 여러 애플리케이션이 동작하고 있을 때, 패킷이 도달할 애플리케이션을 구분할 때 활용된다. Checksum은 전송된 데이터가 제대로 된 데이터인지 확인할 때 활용된다.

TCP는 이미 많은 것이 구축되어 있어 연결 지향 과정에서 오래걸리고, 패킷이 크다해서 무언가 건드리기 힘들다. UDP는 아무것도 안되어 있기 때문에, 애플리케이션 단에서 UDP를 처리할 무언가를 만들면 된다.

5. PORT

한번에 둘 이상 연결해야하는 경우, 여러 애플리케이션을 활용하고 있는 경우, IP만 활용하면 패킷을 구분하기 힘들다. 그래서 TCP/IP 패킷정보는 출발지 IP, PORT와 도착지 IP, PORT 정보를 담고 있다. 같은 IP 내에서 프로세스를 구분하는 역할을 수행한다. 즉, IP가 아파트이면 PORT는 동, 호수 이다.

PORT 잡지식 0 ~ 65535 할당 가능 0 ~ 1023: 많이 쓰는 포트, 임의로 사용하지 않는 것이 좋음 FTP - 20, 21 TELNET - 23 HTTP - 80 HTTPS - 443

6. DNS (Domain Name System)

IP 주소는 기억하기 힘들고, 변경이 될 수 있다. 그래서 도메인 네임시스템이 등장하였고, 이는 전화번호부처럼 IP 주소에 대한 도메인 명을 등록해서 해당하는 IP 주소를 찾아준다. IP 주소 변경이 될 경우 DNS 서버에 등록된 정보만 수정해주면 된다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗 https://inf.run/YZxop

1. 배포 방식의 변화

위 그림은 쿠버네티스 공식자료에 게시된 그림이다. 전통적인 방식의 배포방식부터 컨테이너 기반의 배포방식까지 시스템 구조를 나타낸 그림이다.

1-1. 전통적인 배포

기존 전통적인 방식으로 베어메탈 위에 OS를 올리고, 바로 App를 배포하는 방식은 단점이 있었다.

서로 다른 App들이 OS와 자원을 공유하면서 발생하는 단점들이다.

1. OS를 공유하고 있어 패키지 버전 문제로 App 호환성 문제가 발생하기 쉽다.
2. 자원을 공유하고 있어 App 사용하는 자원에 따라 다른 App 성능에 영향을 줄 수 있다.

1-2. 가상화 기반 배포

그렇게 나온 것이 가상화 기반 배포 방식이다.

<참고> 위에 그림에는 가상화 Type2로 베어메탈-OS-Hypervisor 순으로 올라가 있는데, 베어메탈 위에 Hypervisor를 직접 올리는 Type1도 있다.

이는 하나의 큰 서버를 작은 단위의 VM으로 나누어 사용하여 서버를 좀 더 효율적으로 사용할 수 있게 도와주고, VM에 떠 있는 App이 다른 VM 위에 떠 있는 App에 영향을 주지 않는다는 장점이 있다.

하지만 이것도 단점이 있다.

1. VM마다 OS를 설치를 하기 때문에, 오버헤드가 발생한다.
2. VM이 할당받은 자원을 모두 활용하는 것이 아니기 때문에, 의미 없이 남는 자원이 발생한다.
3. 무겁다.

1-3. 컨테이너 기반 배포

그렇게 나온 것이 컨테이너 기반 배포방식이다.

VM은 OS부터 격리하였지만, 컨테이너는 OS를 공유한다. 다만, VM과 마찬가지로 컨테이너는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스는 격리가 되어있어 클라우드나 OS 배포본에 모두 이식할 수 있다. 그리고 가볍다.

하지만, 단점은 다음과 같다.

1. OS를 공유하고 있어 컨테이너 하나라고 보안에 취약점이 발생하면 전체가 위험해진다.
2. 컨테이너는 프로세스이므로 데이터 영구 저장을 위해 별도의 스토리지 솔루션이 필요하다
3. 컨테이너 간의 네트워크 설정이 복잡하다.
4. 이식은 용이한데, 다른 OS와 호환성 문제가 발생할 수 있다.

배포할 서비스의 규모, 형태, 지불할 수 있는 비용과 같이 여러 조건을 따져보고 배포방식을 선정하면 된다. 그래도 최근 클라우드 환경이 떠오르면서 가장 마지막에 나온 컨테이너 기반 배포방식을 많이 활용하고 있다.

여기서 컨테이너가 많아지고, 여러 서버에 띄워진 컨테이너들이 서로 상호작용을 하며 하나의 서비스를 이룰 때, 이걸 어떻게 관리를 할까?

서버 하나하나 들어가서 컨테이너에 접근해 이슈를 파악하고, 컨테이너 간의 통신을 위한 네트워크 설정도 모두 일일이 다 하고 있으면 부서진 모니터와 키보드만 늘어날 것이다.

그래서 나온 것이 바로 Kubernetes (K8s) 이다.

2. Kubernetes

바로 쿠버네티스의 구성요소로 들어가기 전에 전체적인 그림을 보겠다. 위에 그림에서 컨테이너 배포환경을 가져와 쿠버네티스의 구조를 그린 것이다. 여러 대의 서버가 쿠버네티스를 통해 한 클러스터로 묶여 각각의 서버는 노드의 역할을 하고 있다. 가상화 기반의 배포환경보다 가볍고 효율적으로 보인다.

그런데 큰 서버에 쿠버네티스 환경을 구성할 때 전체적인 그림은 다음과 같다. 이러한 방식 때문에 쿠버네티스를 사용하는 이유를 납득하는 데 오래 걸렸다.

가볍고 효율적인 컨테이너 배포방식을 채택하고, 그 컨테이너를 잘 관리하려고 쿠버네티스를 사용하는 것이 아니였나? 하나의 베어메탈 위에 하이퍼바이저를 올리고, 여러대의 VM을 각각 노드로 취급해서 쿠버네티스로 묶으면 성능 저하가 있지 않나? ← 여기서 막혔다.

단점은 다음과 같다.

1. 이중 오버헤드: VM 오버헤드, 컨테이너 런타임 오버 헤드
2. 자원 낭비: VM이 자체 커널과 OS를 가져야되서 기본 메모리/디스크 소비가 증가
3. 복잡성 증가: VM관리, Kubernetes 관리

성능 저하가 있음에도 VM 위에 쿠버네티스를 띄울 때, 장점은 다음과 같다.

1. 보안: 하이퍼바이저를 통해 커널까지 분리되어 컨테이너 간 취약점 전파 위험이 어느정도 해소
2. 클러스터 관리: 노드를 VM으로 쉽게 생성, 삭제, 스냅샷 복원을 할 수 있어 운영이 간편
3. 노드 자원 관리: VM 자체에서 자원을 명확하게 제한 가능

보안, 클러스터 및 노드 관리에 이점이 있기 때문에 어느정도 성능 감소를 부담하고, VM 위에 쿠버네티스를 띄워 활용한다.

가상화 기반 배포환경의 단점이였던 낭비되는 자원의 문제는 클러스터 내의 노드의 자원 상황에 맞추어 Pod가 뜨기 때문에, 남는 자원 문제는 해결된다. (VM에 남는 자원이 영영 안쓰이는 것이 아니다)

오히려 큰 서버를 하나의 노드로 사용하는 것이 성능에서 이점이 있을 수 있지만, 운영상의 장점이 있어서 VM 위에 쿠버네티스를 띄워 활용한다.

그리고 서버를 여러대 사서 하나로 묶는 것보다 큰 서버 하나를 사서 나누어 구성하는 게 유지보수, 비용적 측면에서 유리하다.

３. Kubernetes 장단점

VM 위에 쿠버네티스 납득완료. 그러면 쿠버네티스를 왜 쓸까?

컨테이너 배포환경에서 여러 개의 컨테이너를 관리하려고 쓰는 것이다. 그에 따른 장단점은 다음과 같다.

장점

1. 고가용성: Pod, 노드, 컨트롤 플레인 장애 시 자동 복구
2. 자동화: 배포, 스케일링, 업데이트 등을 자동으로 관리
3. 서비스 디스커버리 및 로드밸런싱: ClusterIP, Ingress 등으로 트래픽 자동 분산
4. 자원 최적화: 노드에 적절히 Pod를 배치하고 자원 낭비 줄임
5. 이식성/플랫폼 독립성: 어떤 클라우드/OS에서도 동일한 방식으로 실행
6. 멀티테넌시 및 격리: 네임스페이스, RBAC 등으로 논리적 격리

단점

1. 러닝커브: 러닝커브 각도가 가파르다 못해 수직이다. 어렵다.
2. 운영 복잡성: 설치, 보안, 업데이트 등 손이 많이 감
3. 자원 오버헤드: kubelet, kube-proxy, controller-manager 등 기본 데몬들이 자원 소모
4. 어려운 디버깅: 컨테이너 하나가 죽었을 때, 원인 파악을 위해 kubectl logs, kubectl describe, events, metrics 등 여러 단계를 거쳐야 함

결국, 단점들은 고수가 등장하면 해결되는 일들이라 어느정도 규모가 있는 프로젝트라면 쿠버네티스를 활용하지 않을 이유가 없다. 쿠버네티스를 활용하는 이유는 이해가 되었었지만, VM위에 쿠버네티스를 세팅하는 이유가 이해가 안되서 초입에서 길을 잃었다.

다음은 쿠버네티스의 구성요소에 대해 다뤄보겠다.

1. Spring Bean 출력

public class ApplicationContextInfoTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + "object = " + bean );
        }
    }

    @Test
    @DisplayName("애플리케이션 빈 출력하기")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);


            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName + "object = " + bean );
            }
        }
    }
}

별 다른 조건없이 출력을 하게 될 경우, 스프링 내부에서 사용하는 빈이 모두 함께 출력이 된다. BeanDefinition 조건을 걸어 직접 등록한 애플리케이션 빈, 스프링이 내부에서 사용하는 빈을 구분하여 출력할 수 있다.

참고 ROLE_APPLICATION: 직접 등록한 애플리케이션 빈 ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈

그런데, 이렇게 실제로 다 출력해서 확인할 일은 별로 없다.

2. Spring Bean 조회

한번에 다 출력하고, 일일이 눈으로 확인해보는 것은 비효율적이다. 원하는 빈을 선택하여 조회하는 방법이 있다.

.getBean(빈이름, 타입) .getBean(타입)

해당 메서드로 스프링 컨테이너에 등록된 빈을 꺼내올 수 있다. 조회 대상 빈이 없으면 예외 발생한다.

NoSuchBeanDefinitionException: No bean named 'xxxxx' available

오류명을 알아야 테스트 코드를 작성할 때, 실패 케이스에 대한 테스트가 가능하다.

1. 일반적인 조회

public class ApplicationContextBasicFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2() {
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회X")
    void findBeanByNameX() {
        // ac.getBean("xxxxx", MemberService.class);
        assertThrows(NoSuchBeanDefinitionException.class,
                () -> ac.getBean("xxxxx", MemberService.class));
    }
}

빈 이름으로 조회해서 원하는 구현 객체로 빈이 생성되었는 지 확인할 수 있다. 즉, 인터페이스를 조회를 하면 검증의 대상으로 인터페이스의 구현체가 대상이 된다.

직접 구현체를 조회해도 된다. 다만, 구현체를 직접 등록하면 역할과 구현을 구분하고 역할에 의존하지 않기 때문에 유연성이 떨어진다. 가끔 필요할 때가 있으니 가능하다는 정도로만 알고 있자.

실패 케이스는 junit Assertions의 assertThrow를 활용, 람다를 활용하여 예외가 터지는 케이스를 정의한다.

2. 동일한 타입 둘 이상일 경우 조회

타입으로 조회시 같은 타입의 빈이 둘이상이면 오류가 발생한다. 이 때는 빈 이름을 지정한다. .getBeanOfType()을 사용하면 해당 타입의 모든 빈을 조회할 수 있다. 만약 타입으로만 빈을 조회했으나, 같은 타입의 빈이 둘 이상이면 NoUniqueBeanDefinitionException 에러가 발생한다.

public class ApplicationContextSameBeanFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class);

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByTypeDuplicate() {
        assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(MemberRepository.class));
    }

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByType() {
        MemberRepository memberRepository = ac.getBean("memberRepository1", MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemoryMemberRepository.class);
    }

    @Test
    @DisplayName("특정 타입을 모두 조회하기")
    void findAllBeanByType() {
        Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
        System.out.println("beansOfType = " + beansOfType);
        assertThat(beansOfType).hasSize(2);
    }


    @Configuration
    static class SameBeanConfig {

        @Bean
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }

        @Bean
        public MemberRepository memberRepository2() {
            return new MemoryMemberRepository();
        }
    }
}

특정 타입의 빈을 모두 조회하는 경우가 있는데, 이는 @Autowired에서 자동으로 의존관계 주입과 관련이 있다.

1. @Configuration, @Bean

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(
                memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

스프링 컨테이너에 등록할 때, 구성파일로 활용될 AppConfig를 스프링 컨테이너가 등록할 객체들을 인식할 수 있게 @Configuration 어노테이션을 달아준다.

스프링 컨테이너는 @Configuration이 붙어있는 클래스를 자동으로 빈으로 등록, 해당 클래스에서 @Bean이 있는 메소드를 찾아서 빈 생성

public class MemberApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new Member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
    }
}

스프링 컨테이너를 활용하기 전에는 기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI를 진행했다.

여기서 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용하고, @Bean이라고 붙은 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 등록된 객체를 스프링 빈이라고 한다. 즉, DI가 된 객체들이다.

정리하면, AppConfig에서 직접 호출해서 조회하는 방식에서 스프링 컨테이너에서 applicationContext.getBean() 메서드를 사용하여 찾는 방식으로 바뀌었다.

2. 스프링 컨테이너 생성 과정

메인에서 이렇게 등록된 객체를 불러올 때, ApplicationContext를 호출해서 Bean을 가져오는데, ApplicationContext를 스프링 컨테이너라고 한다.

더 정확히는 스프링 컨테이너를 부를 때 BeanFactory, ApplicationContext 로 구분한다. 하지만, BeanFactory를 직접 사용하는 경우는 거의 없어 ApplicationContext를 스프링 컨테이너라고 한다.

1. 스프링 컨테이너 생성

new AnnotationConfigApplicationContext(AppConfig.class)

이를 통해 스프링 컨테이너가 생성된다. 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야하는 데, AppConfig.class가 구성 정보이다.

2. 스프링 빈 등록

스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다.

참고 빈 이름은 메서드 이름을 사용한다. @Bean(name="이름") 방식으로 직접 부여도 가능하다. %% 주의: 빈 이름은 항상 다른 이름은 부여! 같은 이름을 부여하게 될 경우 충돌난다.

3. 스프링 빈 의존관계 설정 - 준비

스프링 컨테이너에는 빈 들이 등록이 되어있다.

4. 스프링 빈 의존관계 설정 - 완료

스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다. 단순 자바 코드 호출처럼 보이지만, 싱글톤 컨테이너와 관련있다.

참고 정리된 글에서는 스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져 있다. 그런데 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다. 이후 의존관계 자동 주입에서 자세히 다룰 예정이다...