스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.

스프링이 지원하는 스코프

• 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
• 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

  웹 관련 스코프

• reqeust: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프
• session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
• application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스포크
• websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

프로토타입 스코프

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환하다. 반면에 프로토타입 스코프는 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

핵심은 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다는 것이다. 클라이언트에 빈을 반환하고, 이후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않는다. 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있다. 그래서 @PreDestroy같은 종료 메서드가 호출되지 않는다.

Singleton

SingletonBean.init
singletonBean1 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
singletonBean2 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
org.springframework.context.annotation.AnnotationConfigApplicationContext -
Closing SingletonBean.destroy

Prototype

find prototypeBean1
PrototypeBean.init
find prototypeBean2
PrototypeBean.init
prototypeBean1 = hello.core.scope.PrototypeTest$PrototypeBean@13d4992d
prototypeBean2 = hello.core.scope.PrototypeTest$PrototypeBean@302f7971
org.springframework.context.annotation.AnnotationConfigApplicationContext -
Closing 

프로토타입 스코프를 보면 .destroy 종료 문구가 없다. 생성과 의존관계 주입 그리고 초기화까지만 관여한다는 것을 알 수 있다.

프로토타입 스코프와 싱글톤 빈과 함께 사용시 문제점

스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다. 그런데 싱글톤 빈은 생성시점엠나 의존관계 주입을 받기 때문에 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것이 문제다.

매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 그런데 실무에서 웹 애플리케이션을 개발해보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 드물다.

스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다.

객체 생성 -> 의존관계 주입

스프링 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다.

스프링 빈의 이벤트 라이프 사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

• 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
• 소멸전 콜백 : 빈이 소멸되기 직전에 호출

생성자는 필수 정보를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행한다. 따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다 객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다. 물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다.

싱글톤 빈들은 스프링 컨테이너가 종료될 때 싱글톤빈들도 함께 종료되기 때문에 스프링 컨테이너가 종료되기 직전에 소멸전 콜백이 일어난다. 싱글톤 처럼 컨테이너의 시작과 종료까지 생존하는 빈도 있지만, 생명주기가 짧은 빈들도 있는데 이 빈들은 컨테이너와 무관하게 해당 빈이 종료되기 직전에 소멸전 콜백이 일어난다.

간단하게 요약 생성자 → 필수 정보를 받아 객체를 생성하고 기본 상태를 만드는 책임 초기화 콜백 → 객체 생성과 의존관계 주입이 끝난 뒤, 외부 연결 같은 무거운 초기화 작업을 수행 종료 콜백 → 빈이 제거되기 직전, 외부 연결 해제나 자원 정리 작업을 수행

인터페이스 Initializing, DisposableBean

public class NetworkClient implements InitializingBean, DisposableBean {

    @Override
    public void afterPropertiesSet() throws Exception {
        connect();
    }

    @Override 
    public void destroy throws Exception {
        disConnect();
    }
}

• InitializingBEan은 afterPropertiesSet() 메서드로 초기화를 지원한다.
• DisposableBean은 destroy 메서드로 소멸을 지원한다.

  참고 인터페이스를 사용하는 초기화, 종료 방법은 스프링 초창기에 나온 방법들이고, 지금은 더 나은 방법들이 있어서 거의 사용하지 않는다.

설정 정보에 초기화 메서드, 종료 메서드 지정

설정 정보에 @Bean(initMEthod = "init", destroyMethod = "close")처럼 초기화, 소멸 메서드를 지정할 수 있다.

@PostConsturct, @PreDestroy 어노테이션 지원

@PostConstruct, @PreDestroy 어노테이션 특징

• 최신 스프링에서 가장 권장하는 방법이다.
• 어노테이션 하나만 붙이면 되므로 편리하다.
• 패키지를 보면 javax.annotation.PostConstruct이다. 스프링에서 종속적인 기술이 아니라 JSR-250라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.
• 컴포넌트 스캔과 잘 어울린다.
• 유일한 단점은외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 기능을 사용하자.

정리

• @PostConstruct, @PreDestroy 어노테이션을 사용하자
• 코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod, destroyMethod를 사용하자.

• 생성자 호출 시점에 1번만 호출되는 것이 보장된다.
• 불편, 필수 의존관계에 사용

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
           this.memberRepository = memberRepository;
           this.discountPolicy = discountPolicy;
    }   
}

생성자가 1개만 존재하면 @Autowired를 생략해도 자동 주입된다.

수정자 주입

• setter 수정자 메서드를 통해서 의존관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용
• 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법

  @Autowired
  public void setDiscountPolicy(DiscountPolicy discounPolicy) {
    this.discuntPolicy = discountPolicy;
  }

필드 주입

• 이름 그대로 필드에 바로 주입하는 방법

• 코드가 간결해서 많이 사용되지만, 외부에서 변경이 불가능해서 테스트 하기 힘든 치명적인 단점이 있다.

• DI 프레임워크가 없으면 아무것도 할 수 없다.

• 사용하지 않는 것을 추천

  @Component
  public class OrderServiceImpl implements OrderService{
  
    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;
  }

• 순수한 자바 테스트 코드에는 다연히 @Autowired가 동작하지 않는다. @SpringBootTest처럼 스프링 컨테이너를 테스트에 통합한 경우에만 가능하다.

일반 메서드 주입

• 일반 메서드를 통해서 주입 받을 수 있다.

• 한번에 여러 필드를 주입 받을 수 있다.

• 일반적으로 사용하지 않는다.

  @Component
  public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
  
    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
           this.memberRepository = memberRepository;
           this.discountPolicy = discountPolicy;
    }   
  }

옵션처리

• @Autowired(required=false) : 자동 주입할 대상이 수정자 메서드 자체가 호출 안됨
• org.springfreamework.lang.@Nullalbe: 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty가 입력된다.

생성자 주입을 선택해라

• 생성자 주입을 권장한다.

불변

• 생성자 주입은 객체를 생성할 때 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

누락

• @Autowired가 프레임워크 안에서 동작할 때는 의존관계가 없으면 오류가 발생하지만, 지금은 프레임워크 없이 순수한 자바 코드로만 단위 테스트를 수행하고 있다.

final 생성자 주입을 사용하면 필드에 final키워드를 사용할 수 있다. 그래서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아준다.

• 수정자 주입을 포함한 나머지 주입 방싯은 모두 생성자 이후에 호추되므로, 필드에 final 키워드를 사용할 수 없다. 오직 생성자 주입 방식만 final키워드를 사용할 수 있다.

정리

• 생성자 주입 방식을 선택하는 이유는 여러가지 있지만, 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이기도 한다.
• 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.

조회 빈이 2개 이상

• @Autowired는 타입으로 조회한다.
• 타입으로 조회하면 선택된 빈이 2개 이상일 때 문제가 발생한다.
• DiscounPolicy의 하위 타입인 FixDiscountPolicy, RateDiscountPolicy 둘다 스프링 빈으로 선언하게 되면 NoUniqueBeanDefinitionException 오류가 발생한다.

  NoUniqueBeanDefinitionException: No qualifying bean of type
  'hello.core.discount.DiscountPolicy' available: expected single matching bean
  but found 2: fixDiscountPolicy,rateDiscountPolicy

@Autowired 필드명, @Qualifier, @Primary

@Autowired 필드 명 매칭

• @Autowired는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.
• 필드 명 매칭은 먼저 타입 매칭을 시도 하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능이다.
• 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

@Qualifier

• @Qualifier는 추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolict implements DiscountPolicy{}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolict implements DiscountPolicy{}

---
//생성자 자동 주입 예시
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy){
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

//수정자 자동 주입 예시
@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy){
    this.discountPolicy = discountPolicy;
}

• @Qualifier끼리 매칭
• 빈 이름 매칭
• NosuchBeanfinitionException 예외 발생

@Primary

• @Priamry는 우선순위를 정하는 방법이다. @Autowired시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.

  @Component
  @Primary
  public class RateDiscountPolicy implements DiscountPolicy{}
  

@Component public class FixDiscountPolicy implements DiscointPolicy{}

@Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){ this.memberRepository = memberRepository; this.dicountPolicy = discountPolicy; }

## 수동 빈 등록은 언제?
- **업무 로직 빈** -> 웹을 지원하는 컨트롤러, 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 피로지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
- **기술 지원 빈** -> 기술적인 문제나 공통 관심사(AOP)를 처리할 떄 주로 사용된다. 데이터베이스 연결이나, 공통 로그처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술이다.
- 편리한 자동 기능을 기본적으로 사용하자
- 직접 등록하는 기술 지원 객체는 수동으로 등록

1. @ComponentScan

• @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.

• 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.

  2. Autowired

• 생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.

• 생성자에 파라미터가 많아도 다시 찾아서 자동으로 주입한다.

  @Component
  public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
  
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
  }

탐색 위치와 기본 스캔

@ComponentScan(
    basePackage = "hello.core",
)

• basePackages : 탐색할 패키지의 시작 위치를 지정, 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.
• basePackages = {"hello.core", "hello.service"} 여러 시작 위치를 지정할 수도 있다.
• basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
• 지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.

  스프링 부트를 사용하면 스프링 부트의 대표 시작 정보인 @SpringBootApplication을 이 프로젝트 시작 루트 위치에 두는 것이 관례이다.(그리고 이 설정 안에 @ComponentScan이 들어있다.)

컴포넌트 스캔 기본 대상

• @Compnent : 컴포넌트 스캔에 사용
• @Controller : 스프링 MVC 컨트롤러에 사용
• @Service : 스프링 비즈니스 로직에 사용, 특별한 기능은 따로 존재하지 않지만, 개발자들이 핵심 비즈니스 로직이 여기에 존재한다고 인식 가능
• @Repository : 스프링 데이터 접근 계층에 사용, 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
• @Configuration : 스프링 설정 정보에서 사용

  해당 클래스의 소스 코드를 보면 @Component를 포함하고 있다.

Filter

• includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
• excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다.

FilterType

• ANNOTATION : 기본값, 애노테이션을 인식해서 동장 ex) org.example.SomeAnnotation
• ASSIGNABLE_TYPE : 지정한 타입과 자식 타입을 인식해서 동작한다. ex) org.example.SomeClass
• ASPECTJ : AspectJ 패턴 사용 ex) org.example..*Service
• REGEX : 정규표현식 ex) org\.example\.Default.*
• CUSTOM : TypeFilter 이라는 인터페이스를 구현해서 처리 ex) org.example.MyTypeFilter

@ComponentScan(
    includeFilters = {
        @Filter(type = FilterType.ANNOTATION, classes = MyIncludeCompnont.class),
    },
    excludeFilters = {
        @Filter(type = FilterType.ANNOTATION, classes = MyExclueComponent.class),
        @Filter(type = FilterType.ASSIGNABLE_TYPE, classes = BeanA.class
    }
)

@Component 면 충분하기 때문에 거의 사용될 일은 거의 없다. 여러가지 이유로 간혹 사용할 때가 있지만 많지는 않다. 특히 스프링 부트는 컴포넌트 스캔을 기본적으로 제공하는데, 개인적으로 옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장하고, 선호하는 편이다.

중복 등록과 충돌

자동 vs 자동 출동

• 컴포넌트 스캔에 의해 자동으로 빈으로 동록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
• ConflictingBeanDefinitionException 예외 발생

수동 vs 자동 출동

• 수동 빈과 자동 빈이 출동하게되면 수동 빈 등록이 우선권을 가진다.
• 수동 빈이 자동 빈을 오버라이딩 한다.

  Overriding bean definition for bean 'memoryMemberRepository' with a different
  definition: replacing

  의도적으로 했다면 상관없지만, 여러 설정들이 꼬여서 이런 결과가 만들어지는 경우가 대부분이다. 그래서 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다.

Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true

• 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴
• 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다.
• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야한다.

public class SingletonService{

    //1. static 영역에 객체를 1개만 생성
    private static final SingletonService instance = new SingletonService();

    //2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용
    public static SingletonService getInstance(){
        return instance;
    }

    //3. 생성자를 private로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService(){}

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }

}

1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
2. 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
3. 1개의 객체 인스턴스만 존재하므로, 생성자를 private로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

싱글톤 패턴을 적용하면 고객의 요청이 올 때 마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다.

싱글톤패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. -> DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵고, 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다.

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

주의점

• 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
• 무상태(stateless)로 설계해야 한다.
• 의존적인 필드, 값을 변경할 수 있는 필드가 있으면 안된다.

1. 무상태로 만들라는 건 필드를 아예 쓰지 말라는 뜻이 아니라, 요청마다 달라지는 값을 필드에 저장하지 말라는 뜻
2. Repository, Service, Client 같은 의존 객체를 final 필드로 주입받는 것은 괜찮
3. userId, price, currentOrder처럼 사용자별로 달라지는 값은 필드가 아니라 파라미터, 지역 변수, 반환값으로 처리해야 함

@Configuration과 바이트코드 조작

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 자바 코드는 여러번 호출될 수 있다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다. 모든 비밀은 @Configutation을 적용한 AppConfig에 있다.

• AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig도 스프링 빈이 된다.

프록시 적용 대상

• "스프링이 메서드 호출을 가로채야 하는 이유가 있는지"로 정한다.
• 비즈니스 빈 -> 객체 하나 만들고 주입하면 싱글톤 보장 끝, 기본 프록시 불필요
• @Configuration, @Transactional, @Cacheable, @Async <- 프록시 대상

정리

• 비즈니스 빈은 스프링 컨테이너가 객체를 한 번 생성하고, 등록된 빈을 의존성으로 주입하면 되므로 싱글톤 보장을 위한 프록시가 필요없다.
• 반면 @Configuration은 @Bean 메서드가 여러 번 직접 호출될 수 있으므로, 스프링이 프록시로 호출을 가로채 기존 싱글톤 빈을 반환
• @Configuration이 적용된 설정 클래스의 @Bean 메서드라면, 여러 번 생성하는 코드처럼 보여도 프록시가 가로채서 이미 등록된 빈을 반환

• 핵심 : Spring DI 컨테이너, AOP, 이벤트, 기타
• 웹 : Spring MVC, Spring WebFlux
• 데이터 접근 기술 : Transaction, JDBC, ORM, XML
• 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
• 테스트 : 스프링 기반 테스트 지원
• 언어 : Kotlin, Groovy

스프링 핵심

• 스프링은 자바 언어 기반의 프레임워크
• 자바 언어의 가장 큰 특징 - 객체지향
• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
• 좋은 객체 지향 애플리케이션을 개발할 수 있게 도화주는 프레임워크

객체 지향

• 추상화, 캡슐화, 상속, 다형성
• 객체 지향 프로그래밍은 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다.
• 객체는 메시지를 주고 받고, 데이터를 처리할 수 있다.
• 유연하고 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

좋은 객체지향 설계 5가지 원칙(SOLID)

• SRP : 단일 책임 원칙 (Single Responsibility Principle)
• OCP : 개방-폐쇄 원칙 (Open-Close Principle)
• LSP : 리스코프 치환 원칙 (Liskov Substution Principle)
• ISP : 인터페이스 분리 원칙 (Interface Segregation Principle)
• DIP : 의존관계 역전 원칙 (Dependency Inversion Principle)

SRP

• 한 클래스는 하나의 책임만을 가져야 한다.
• 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

OCP

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 즉, 새로운 구현체를 추가하거나 교체할 때 기존 클라이언트 코드는 수정하지 않아야 한다는 뜻입니다.

LSP

• 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다.
• 부모 타입이나 인터페이스 타입으로 사용하던 코드를, 자식 타입이나 구현체로 바꿔도 프로그램이 정상적으로 동작해야 한다.

ISP

• 특정 클라이언트를 위한 여러개의 인터페이스가, 범용 인터페이스 하나보다 좋다.
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.
• 클라이언트가 사용하지 않는 기능에 의존하지 않게 인터페이스를 작게 나누는것
• 하나의 큰 인터페이스에 모든 기능을 몰아넣기보다, 역할별로 인터페이스를 분리하는 것이 좋다.

DIP

• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법중 하나다.
• 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻

정리

스프링 이야기에 왜 객체지향 이야기가 나오나?

• 스프링은 다음 기술 -> 다형성, OCP, DIP를 가능하게 지원
• DI 컨테이너 제공
• 클라이언트 코드의 변경없이 기능 확장
• 쉽게 부품을 교체하듯이 개발
• 모든 설계에 역할과 구현을 분리
• 애플리케이션을 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체지향 설계

Spring Container

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext를 스프링 컨테이너라 하고, 인터페이스다.
• 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 어노테이션 기반의 자바 설정 클래스로 만들 수 있다.
• 더 정확히 Spring Container를 부를 때 BeanFactory, ApplicationContext로 구분해서 이야기 한다.
• BeanFactory를 직접 사용하는 경우는 거의 없으므로 일반적으로 ApplicationContext를 스프링 컨테이너라고 한다.

Spring Container 생성 과정

1. 스프링 컨테이너 생성

• 생성할 때는 구성 정보를 지정해줘야 한다.

2. 스프링 빈 등록

• 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈으로 등록한다.
• 빈 이름은 메서드 이름을 사용하고 직접 부여할 수 도 있다.

  주의 빈 이름은 항상 다른 이름으로 부여해야 한다. 같은 이름을 부여하면서 다른 빈이 무시되거나, 기존 빈을 덮어버리거나 설정에 따라 오류가 발생한다.

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

• 설정 정보를 참고해서 의존관계를 주입(DI)한다.

BeanFactory와 ApplicationContext

BeanFactory :

• 스프링 컨테이너의 최상위 인터페이스
• 스프링 빈을 관리하고 조회하는 역할 담당
• 위의 대부분의 기능은 BeanFactory가 제공하는 기능

ApplicationContext :

• BeanFactory 기능을 모두 상속받아서 제공
• 메시지소스를 활용한 국제화 기능
• 환경변수
• 애플리케이션 이벤트

다양한 설정 지원

1. 애노테이션 기반 자바 코드 설정 AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘긴다.

2. XML 설정 부트로 넘거가면서 XML기반의 설정은 잘 사용하지 않는다. 아직 많은 레거시 프로젝트들이 XML로 되어 있고, 또 XML을 사용하면서 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있다.

3. Xxx 설정

• 기타...

• 분산 이벤트 스트리밍 플랫폼
• 대규모 데이터를 실시간으로 처리하기 위해 사용
• 고성능, 확장성, 내구성 가용성

Producer: 데이터 생산자 Comsumer: 데이터 소비자

통신 방법

API

직접 통신, 단순하고 간단한 방법이다. 하지만 Concumer에 장애가 발생한다면 직접 호출하기 때문에 장애가 전파될 수도 있고, 전달되지 않는다면, 데이터 유실 가능성이 있다. 대규모 데이터를 안전하게, 고성능으로 처리하는데 한계가 있다.

Message Queue

Producer와 Consumer 사이에 Message Queue에 데이터 전송을 위힘해볼 수 있다. 직접적으로 결합되지 않기 때문에 장애 전파될 위험은 감소될 수도 있고, 데이터 유실 위험을 낮출 수도 있고, 데이터에 대한 처리가 비동기로 수행될 수도 있다.

Producer와 Consumer가 많아진다면? 처리해야될 데이터가 늘어난다면? Message Queue 장애가 발생한다면? 데이터에 대해 복잡한 라우팅이 필요하다면? 단일 Message Queue로 대규모 데이터를 처리하기 어려울 수 있다.

여러 Message Queue를 만들고, 이를 처리하는 시스템을 고려할 수 있다. Message Queue(메시지 중개자)가 여러 Message Queue를 관리함으로써 대규모 데이터를 병렬로 처리하며, 복잡한 데이터 요구사항을 처리한다.

만약 Producer가 생산하는 데이터가 Broker나 Consumer의 처리향을 넘어가면, 리소스 부족으로 장애가 전파될 수도 있고, 데이터 유실될 수 있다.

Consumer가 Message Broker에서 데이터를 push받는게 아니라, Consumer가 Message Broker에서 데이터를 pull 해온다. 자신의 처리향에 따라서 조절할 수 있다.

Producer가 데이터 생산(publish), Consumer는 데이터 구독(subscribe) pub/sub 패턴

그렇다면 이러한 시스템을 직접 구축해야되나? 고성능, 안전성, 가용성을 위한 분산 시스템을 구축하는 것은 쉽지 않다.

직접 구축할 필요 없이 Kafka를 사용하면된다.

Kafka

머메이드 문법상 <-- 없으면 방향이 틀어지기 때문에 방향 제거 불가

kafka는 데이터를 구분하기 위해 topic이라는 단위를 사용한다.

• Producer는 topic 단위로 이벤트를 생산 및 전송
• Consumer는 topic 단위로 이벤트를 구독 및 소비한다.
• topic: Kafka에서 생산 및 소비되는 데이터를 논리적으로 구분하는 단위

• Broker: kafka에서 데이터 중개 및 처리해주는 애플리케이션 실행 단위
• Kafka Cluter: 여러개의 Broker가 모여서 하나의 분산형 시스템을 구성한 것
• Partition: Topic이 분산되는 단위, 각 Topic은 여러 개의 Partition으로 분산 저장 및 병렬 처리된다.
• Offset: 각 데이터에 대해 고유한 위치, Consumer Group은 각 그룹이 처리한 Offset을 관리한다.
• Consumer Group: 각 Topic의 Partition 단위로 Offset을 관리한다.

데이터 일관성

• 비교적 덜 중요하다.
• 모든 조회 내역을 보여주진 않는다. 단순히 조회된 횟수만 보여주면 된다.
• 불일치가 발생하더라도 사용자가 인지하기 어렵다.

쓰기 트래픽

• 비교적 많다.
• 단순히 게시글 조회만 해도 쓰기 작업이 필요하다.

데이터 일관성이 덜 중요하고, 다른 데이터에 의해 파생되는 데이터가 아니므로, 트랜잭션이나 안전한 저장소가 반드시 필요하진 않다. 또한 디스크는 접근 비용이 비싸다. 디스크보다 더 빠른 저장소를 고려해 볼 수 있다.

그렇다면 조회수 관리를 위해 In-memory Database를 사용해볼 수 있다. Redis

Redis는 휘발성이다. 종료되면 저장되어 있던 데이터는 사라진다. 그렇다면 Redis에는 백업이 필요하다. 약간의 데이터 유실을 허용했기 때문에 모든 데이터를 백업할 필요는 없다.

• 시간 단위 백업 X
• 개수 단위 백업 O

조회수 어뷰징 방지

게시글을 조회하면 조회수가 올라간다. 어뷰저는 특정 게시글을 여러 번 조회해서 데이터를 조작할 수 있다. 조회수 기반으로 인기글이 산정되는 경우, 올바르지 않는 어뷰징으로 인기글이 선정될 수 있다.

어뷰징을 방지하기 위한 조회 여부는

• 로그인 사용자 사용자 식별
• 비로그인 사용자 IP, User-Agen, 브라우저 쿠키, 토큰 등

로그인 사용자만 고려하고 설계하게 한다.

• 조회수 증가 요청이 오면, Redis에 TTL = 10분으로 데이터를 저장
• key는 ? + userId가 된다.
• 이미 저장된 데이터가 있으면 저장에 실패하는 명령어를 사용
• 데이터 저장 성공 여부에 따라, 증가 및 증가하지 않는다.

code

@Service
@RequiredArgsConstructor
public class ArticleViewService {

    private final ArticleViewCountRepository articleViewCountRepository;
    private final ArticleViewCountBackUpProcessor articleViewCountBackUpProcessor;
    private final ArticleViewDistributedLockRepository articleViewDistributedLockRepository;

    private static final int BACK_UP_BACH_SIZE = 100;
    private static final Duration TTL = Duration.ofMinutes(10);

    public Long increase(Long articleId, Long userId) {
        if (!articleViewDistributedLockRepository.lock(articleId, userId, TTL)) {
            return articleViewCountRepository.read(articleId);
        }

        Long count = articleViewCountRepository.increase(articleId);

        if(count % BACK_UP_BACH_SIZE == 0){
            articleViewCountBackUpProcessor.backUp(articleId, userId);
        }

        return count;
    }

로그인 사용자 기준으로 조회수를 관리하기로 했고, 조회수 증가에서 articleId, userId로 락의 여부를 확인한다.

• .lock(articleId, userId, TTL) 에서 사용자 A가 해당 게시글을 조회한 여부가 있는지 확인한다. 처음 조회한다면 락을 획득하고 아니면 락 획득에 실패해 해당 게시글의 조회수를 반환한다.
• 락 획득에 성공했다면 조회수를 증가한다.
• 개수 단위로 백업을 하기로 했었다. 100단위로 백업 여부를 체크해 조회수를 저장한다.

XXXXX    |  XXXXX  |  XXXXX  | ...........
1depth    2depth    3depth    4depth

depth 별로 5개의 문자열 경로 정보를 갖는다.

• 1depth : 5개의 문자열
• 2depth : 10개의 문자열
• 3depth : 15개의 문자열

  N depth = (N * 5)

5개의 문자열로 나타내므로, 표현 범위가 제한된다. 10개의 숫자로 나타내면 표현 수는 10 ^ 5 = 100,000개로 제한된다. (00000 ~ 99999)

하지만 문자열이기 떄문에 09, AZ, a~z 62개의 문자를 사용할 수 있다. 62 ^ 5 - 916,132,832개로 제한된다. (00000 ~ zzzzz)

데이터베이스 collation

문자열을 정렬하고 비교하는 방법을 정의하는 설정

SELECT table_name, table_colation 
FROM information_schema.TABLES WHERE table_schema = 'comment';

utf8mb4_0900_ai_ci 설정인 것을 확인할 수 있다. _ci는 대소문자의 순서를 비교할 수 없다. 그래서 utf8mb4_bin 을 사용한다.

create table comment(
    path varcher(25) character set utf8md4 collate utf8md4_bin not null
...
);

create unique index inx_article_id_path on comment(article_id asc, path asc);

무한 depth

00a0z  <- parentPath
├── 00a0z 00000
├── 00a0z 00001
├── 00a0z 00002 <- childernTopPath
└── ?          └── 00a0z 00002 00000 <- descendantsTopPath

descendantsTopPath 찾아 신규 댓글의 depth * 5까지만 남기고 잘라내면 된다. ex) 00a0z 00002 00000 에서 (신규 댓글의 depth * 2) * 5 = 10개의 문자만 남기고 잘라내면 00a0z 00002를 찾을 수 있다.

select path from comment
 where article_id = {article_id}
   and path > {parentPath} 
   and path like {parentPath}% 
order by path desc 
 limit 1; 

descendantsTopPath를 구할 수 있다.

code

public class CommentPath {
    private String path;

    private static final String CHARSET = "0123456789ABCDEFGHIJKMNLOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

    private static final int DEPTH_CHUNK_SIZE = 5;
    private static final int MAX_DEPTH = 5;

    // MIN_CHUNK = "00000" MAX_CHUNK = "zzzzz"
    private static final String MIN_CHUNK = String.valueOf(CHARSET.charAt(0)).repeat(DEPTH_CHUNK_SIZE);
    private static final String MAX_CHUNK = String.valueOf(CHARSET.charAt(CHARSET.length() - 1)).repeat(DEPTH_CHUNK_SIZE);

• CHARSET에 62개의 문자열 정의
• 최대 Depth 깊이와 Depth 길이 정의
• 시작과 끝 Depth 정의

    public static CommentPath create(String path) {
        if(isDepthOverflow(path)){
            throw new IllegalStateException("depth overflowed");
        }
        CommentPath commentPath = new CommentPath();
        commentPath.path = path;
        return commentPath;
    }

• 팩토리 메서드

    public CommentPath createChildCommentPath(String descendantsTopPath) {
        if (descendantsTopPath == null) {
            return CommentPath.create(path + MIN_CHUNK);
        }
        String childrenTopPath = findChildrenToPath(descendantsTopPath);
        return CommentPath.create(increase(childrenTopPath));
    }

• 자식 여부를 체크해 자식이 없다면 depth 자식 생성, null아니라면 자식 또는 형제 생성
• path가 빈 값이고 descendantsTopPath이 00000 라면 00001을 형제 생성
• 00000이 자식을 생성하려 할때 00000 00000 자식이 존재한다. descendantsTopPath이 00000 00000에서 형제이고 00000 자식인 00000 00001을 생성 한다.

private String findChildrenToPath(String descendantsTopPath) {
        return descendantsTopPath.substring(0, (getDepth() + 1) * DEPTH_CHUNK_SIZE);
}

• 루트에서 형제를 생성한다면 path = "" 뎁스는 0이고, 00000을 반환
• 자식을 생성한다면 path = 00000뎁스는 1이고 00000 00000을 반환

private String increase(String path) {
        // 00000 00000
        String lastChunk = path.substring(path.length() - DEPTH_CHUNK_SIZE);
        if (isChunkOverflow(lastChunk)) {
            throw new IllegalStateException("chunk overflowed");
        }
        int charsetLength = CHARSET.length();

        int value = 0;
        for(char ch : lastChunk.toCharArray()) {
            value = value * charsetLength + CHARSET.indexOf(ch);
        }

        value = value + 1;

        String result = "";
        for(int i = 0 ; i < DEPTH_CHUNK_SIZE ; i++) {
            result = CHARSET.charAt(value % charsetLength) + result;
            value /= charsetLength;
        }

        return path.substring(0, path.length() - DEPTH_CHUNK_SIZE) + result;
    }

• 루트가 형제를 생성하기 위해00000을 받았다면 00001을 반환하고, 자식을 만들기 위해 00000 00000을 받았다면 00000 00001을 반환하게 된다.
• 문자열 청크를 62진수 숫자로 변환하고 1을 증가시킨다.
• 다시 62진수 숫자를 문자열 청크(길이 5)로 변환

Github 라벨을 하나하나 설정하지 않고 템플릿을 사용해서 적용하는 방법

사전 작업

• Node.js 설치 여부 npx 명령어를 사용하기 위해 설치해야 됨
• Git Access Token 발급 토큰 생성시 repo권한 부여 후 발급
• 라벨 템플릿 준비 (해당 게시글 하단에 템플릿 존재)

적용 명령어

 npx github-label-sync --access-token <Git Access Token> --labels ./labels.json <Git Name>/<Git Repository Name>

• Git Access Token -> 발급 받은 토큰(repo 권한 O)
• Git Name -> 사용하는 깃허브 이름
• Git Repository Name -> 적용할 레포지토리

적용 결과

라벨 템플릿

[
{
    "name": "⚙ Setting",
    "color": "e3dede",
    "description": "개발 환경 세팅"
},
{
    "name": "✨ Feature",
    "color": "a2eeef",
    "description": "기능 개발"
},
{
    "name": "🌏 Deploy",
    "color": "C2E0C6",
    "description": "배포 관련"
},
{
    "name": "🎨 Html&css",
    "color": "FEF2C0",
    "description": "마크업 & 스타일링"
},
{
    "name": "🐞 BugFix",
    "color": "d73a4a",
    "description": "Something isn't working"
},
{
    "name": "💻 CrossBrowsing",
    "color": "C5DEF5",
    "description": "브라우저 호환성"
},
{
    "name": "📃 Docs",
    "color": "1D76DB",
    "description": "문서 작성 및 수정 (README.md 등)"
},
{
    "name": "📬 API",
    "color": "D4C5F9",
    "description": "서버 API 통신"
},
{
    "name": "🔨 Refactor",
    "color": "f29a4e",
    "description": "코드 리팩토링"
},
{
    "name": "🙋‍♂️ Question",
    "color": "9ED447",
    "description": "Further information is requested"
},
{
    "name": "🥰 Accessibility",
    "color": "facfcf",
    "description": "웹접근성 관련"
},
{
    "name": "✅ Test",
    "color": "ccffc4",
    "description": "test 관련(storybook, jest...)"
}
]

git init                     # 현재 디렉토리를 Git 저장소로 초기화
git add .                    # 모든 파일 스테이지에 올리기
git commit -m "init"         # 초기 커밋 생성
git branch -M main           # 브랜치 이름을 main 으로 변경
git remote add origin <URL>  # 원격 저장소(origin) 등록
git push -u origin main      # 원격 저장소에 첫 푸시

#-----------------------------

git clone <URL>              # 원격 저장소를 로컬로 복제

-u 를 붙이는 이유는 로컬의 브랜치와 원격의 브랜치를 연결해주는 옵셥 이후 git pull, git push 를 브랜치명 없이 가능 하지만 git pull main, git push main 을 이름을 명시해준다면 않해도 됨

Git PR

git checkout -b feature/my-task            # 작업용 브랜치 생성 및 이동

# --- 여기서 코드 수정 작업 ---

git add .                                  # 변경 파일 스테이지
git commit -m "작업 내용"                    # 작업 커밋
git push -u origin feature/my-task         # 작업 브랜치를 원격에 업로드

# 이후 GitHub 웹 화면에서 "Compare & pull request" 클릭하여 PR 생성

Git branch

브랜치 목록 확인/생성/삭제

git branch          # 목록
git branch -d feat  # 삭제
git branch -M main  # 이름 변경

Git switch

git switch는 브랜치 이동을 직관적으로 만들기 위해 만들어진 명령어 기존의 git checkout이 너무 많은 기능을 한꺼번에 담당해서 혼란을 줄이기 위해 분리된 명령어

git switch main                 # main 브랜치로 이동
git switch -c feature/my-task   # 브랜치를 만들고 바로 이동

git checkout 을 하게 되면 파일이 변경되어 과거 버전을 보고 개발하게 될 수 있음 하지만 git switch 는 브랜치만 변경되기 때문에 그런일이 줄어듬

Git Checkout

checkout은 “브랜치 이동, 파일 복원”을 한 명령으로 처리하는 바람에 실수 위험이 크다. 작업 중이던 파일이 다른 브랜치 기준으로 덮어쓰여서 변경 중이던 코드가 사라지는 사고가 자주 발생 그래도, 특정 상황에서는 필요함

# --- 브랜치 이동 ---
git checkout main
git checkout feature/login
#대신 추천
git switch main                 # main 브랜치로 이동

# --- 새 브랜치 생성 + 이동 ---
git checkout -b feature/login
#대신 추천
git switch -c feature/login

# --- 파일을 특정 커밋 상태로 되돌리는 기능 ---
git checkout HEAD src/App.java
git checkout -- src/App.java
#대신 추천
git restore src/App.java

Git status

현재 작업 디렉토리에서 어떤 파일이 변경되었는지 확인하고 싶을 때 스테이지(add) 되었는지, 아직 unstaged 인지 확인하고 싶을 때 어떤 파일이 커밋 대산인지 보고싶을 때

git status
git add .
git status
git commit -m "msg"

# --- Untracked files (Git에 없는 파일) ---
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/test/Main.java


# --- Changes not staged for commit (변경됐지만 add 안 됨) ---
Changes not staged for commit:
  modified: src/app/UserService.java


# --- Changes to be committed (커밋될 준비가 된 파일) ---  
Changes to be committed:
  new file: src/app/OrderService.java
  modified: src/app/CartService.java


# --- 현재 브랜치 정보 / 리모트 상태 ---  
On branch feature/login
Your branch is ahead of 'origin/feature/login' by 2 commits.

# --- 충돌(conflict) 상황도 알려줌 ---  
Unmerged paths:
  both modified: src/app/UserService.java

Git merge

두 브랜치의 변경사항을 하나의 브랜치로 합치는 것

예를 들어:

• main branch
• feature/login branch
• feature 브랜치에서 작업을 끝내고 → main에 합칠 때 merger를 사용

git switch main               # 합쳐질(받아들일) 브랜치로 이동
git merge feature/login       # feature의 변경사항을 main에 합치기

main:      A — B — C — F
               \
feature:         D — E

# --- git merge ---

main:      A — B — C — F — M
               \           /
feature:         D — E ——

merge conflict

git merge feature/login
# <<<<<<< HEAD
# =======
# >>>>>>> feature/login

# --- 해당 파일을 직접 수정 후 ---

git add 파일명
git commit

merge는 언제 사용?

PR(풀 리퀘스트) 병합시

GitHub에서 PR을 만들고 → 리뷰 후 → Merge Pull Reqeust (내부적으로 merge를 수행)

main ← feature 작업 완료시

Git rebase

rebase = 내 브랜치 출발점을 (main 최신 지점)으로 옮기는 것

• 커밋을 다시 만들어서 직선을 만듦
• 공유 브랜치에서는 절대 사용하면 안됨(커밋 재작성되니 충돌과 히스토리 꼬임)

git switch feature
git rebase main

# rebase 후 원격 브랜치 업데이트
git push -f 
# or
git push -f <브랜치명>

# 더 안전하게는 
git push --force-with-lease
# or
git push --force-with-lease <브랜치명>

main:      A — B — C — F
               \
feature:         D — E

# --- git merge ---

main:      A — B — C — F
                        \
feature:                 D' — E'

rebase conflict

error: could not apply D
hint: Resolve conflicts and run `git rebase --continue`

#-----------------------------

<<<<<<< HEAD
main 버전의 코드
=======
feature 버전의 코드
>>>>>>> D

#-----------------------------

git add <충돌난파일>
git rebase --continue

rebase는 언제 사용?

1. main 브랜치가 업데이트된 상태에서 feature 브랜치를 최신으로 맞추고 싶을 때
2. feature 브랜치의 커밋을 깔끔하게 정리하고 싶을 때
3. PR 보내직 전에 히스토리를 직선으로 만들고 싶을 때
4. merge coimmit 이 싫을 때

feature 브랜치의 커밋을 깔끔하게 정리하고 싶을 때

D  (작업 커밋)
E  (오타 수정)
F  (테스트 로그 삭제)
G  (실제 기능 추가)

#-----------------------------

$ git log --oneline
g7f3abc G
c9b312f F
a4e129b E
d1f2c9a D

#-----------------------------

git rebase -i HEAD~4

# 아래 명령어 사용 가능:
# pick (그대로)
# squash(commit 합치기)
# reword(메시지 수정)
# drop(커밋 삭제)
#-----------------------------

pick d1f2c9a D
pick a4e129b E
pick c9b312f F
pick g7f3abc G

#-----------------------------

pick d1f2c9a D
squash a4e129b E
squash c9b312f F
pick g7f3abc G

#-----------------------------

D
# E
# F

#-----------------------------

기능 구현 + 오타 수정 + 로그 정리

#-----------------------------

new_hash2 G
new_hash1 기능 구현 + 오타 수정 + 로그 정리

Git restore

수정한 App.java 파일을 마지막 커밋 상태(HEAD)로 되돌림

• 수정했던 내용 → 모두 사라짐
• 파일은 커밋된 기준 버전으로 리셋됨
• add 되지 않은 변경사항(staged 전 변경)만 리셋됨

개발하다가 “이거 그냥 다시 처음부터 하자” 싶을 때 쓰는 명령어

src/App.java  ← 내가 수정함
# 근데 “아… 이거 아니네… 그냥 돌아가자” 하면
git restore src/App.java
# → 마지막 커밋 시점으로 돌아감

한번 더

# --- 파일 수정함 (아직 add 안 함) ---
git status

Changes not staged for commit:
    modified: src/App.java
# --- 복구 ---
git restore src/App.java

# --- 복구 후 상태 ---
git status
# nothing to commit, working tree clean
# 변경 내용 전부 사라짐

🟥 중요한 점!

git add src/App.java
git restore src/App.java  ❌ 안 됨

단일 DB Auto Increment에 의존하지 않고 다중 서버(멀티 노드)에서 동시 생성해도 충돌없는 고유 ID를 만드는 알고리즘

• DB INSERT 전에 ID를 만들어도 됨(DB 부하 감소)
• 분산환경에서도 충돌 없음
• 시간 순서대로 정렬 가능(정렬 성능 ↑)
• 64 비트의 long값 하나로 표현 -> 빠르고 메모리 효율적

1  비트  : UNUSED  
41 비트  : Timestamp (시간)
10 비트  : Node ID (서버 ID)
12 비트  : Sequence (동일 시간 내 증가값)
-----------------------------------------
총 64비트 = long

Code

public class Snowflake {
    private static final int UNUSED_BITS = 1;
    private static final int EPOCH_BITS = 41;
    private static final int NODE_ID_BITS = 10;
    private static final int SEQUENCE_BITS = 12;

    private static final long maxNodeId = (1L << NODE_ID_BITS) - 1;
    private static final long maxSequence = (1L << SEQUENCE_BITS) - 1;

    private final long nodeId = RandomGenerator.getDefault().nextLong(maxNodeId + 1);

    private final long startTimeMillis = 1704067200000L;

    private long lastTimeMillis = startTimeMillis;
    private long sequence = 0L;

    public synchronized long nextId() {
        long currentTimeMillis = System.currentTimeMillis();

        if (currentTimeMillis < lastTimeMillis) {
            throw new IllegalStateException("Invalid Time");
        }

        if (currentTimeMillis == lastTimeMillis) {
            sequence = (sequence + 1) & maxSequence;
            if (sequence == 0) {
                currentTimeMillis = waitNextMillis(currentTimeMillis);
            }
        } else {
            sequence = 0;
        }

        lastTimeMillis = currentTimeMillis;

        return ((currentTimeMillis - startTimeMillis) << (NODE_ID_BITS + SEQUENCE_BITS))
            | (nodeId << SEQUENCE_BITS)
            | sequence;
    }

    private long waitNextMillis(long currentTimestamp) {
        while (currentTimestamp <= lastTimeMillis) {
            currentTimestamp = System.currentTimeMillis();
        }
        return currentTimestamp;
    }
}

Snowflake idGen = new Snowflake();

long id = idGen.nextId();
System.out.println(id); // 전 세계 고유 ID

DB auto_increment

• 분산 데이터베이스 환경에서는 PK가 중복될 수 있기 때문에, 식별자의 유일성이 보장되지 않는다.
• 클라이언트 측에 노출하면 보안 문제 user_id = 1000 라면 1,000명의 사용자가 있다는 사실을 유추
• 간단하기 때문에 다음 상황에서 유리할 수 있다.

1.보안적인 문제를 크게 고려하지 않는 상황 2.단일 DB를 사용하거나 애플리케이션에서 PK의 중복을 직접 구분하는 상황

• 보안 적인 문제가 염려된다면 PK는 데이터베이스 내에서의 식별자로만 사용하고, 애플리케이션에서의 식별자를 위해 별도 유니크 인덱스를 사용할 수도 있다. PK = id(DB auto_increment) unique index = article_id(UUID 등) Client는 article_id만 식별자로서 노출 및 사용

유니크 문자열 또는 숫자

• UUID 또는 난수를 생성하여 PK를 지정할 수 있다.
• 정렬 데이터가 아니라 랜덤 데이터를 삽입하는 것이다.
• 하지만, 랜덤 데이터로 인해 성능 저하가 발생할 수 있다. Clustered Index는 정렬된 상태를 유지한다. 데이터 삽입 필요한 인덱스 페이지가 가득 찼다면, B+tree 재구성 및 페이지 분할로 디스크 I/O증가 PK를 이용한 범위 조회가 필요하다면, 디스크에서 랜덤 I/O가 발생하기 때문에, 순차 I/O보다 성능 저하

유니크 정렬 문자열

• 분산 환경에 대한 PK 중복 문제 해결
• 보안 문제 해결
• 랜덤 데이터에 의한 성능 문제 해결
• UUID v7, ULID 등의 알고리즘 일반적으로 알려진 알고리즘음 128비트를 사용한다.
• 데이터 크기에 따라 공간 및 성능 효율이 달라진다. Clustered Index는 PK를 기준으로 만들어지고, Secondary Index는 데이터에 접근할 수 있는 포인터를 가진다. 즉, PK를 가지고 있다. PK가 크면 클수록, 데이터는 더 많은 공간을 차지, 비교 연산에 의한 정렬/조회에 더 많은 비용 소모

유니크 정렬 숫자

• 분산 환경에 대한 PK 중복 문제 해결
• 보안 문제 해결
• 랜덤 데이터에 의한 성능 문제 해결
• Snowflake, TSID 등의 알고리즘 64비트를 사용한다. (BIGINT) 정렬을 위해 타임스탬프를 나타내는 비트 수의 제한으로, 키 생성을 위한 시간적인 한계가 있을 수있다. 문자열 알고리즘에서도 동일한 문제가 있으나 비트 수가 많을수록 제한이 덜할 수 있다.

분산 데이터베이스를 사용을 고려해 게시글이 N개의 Shard로 분산되는 상황을 고려한다.

Shrad Key = board_id

❓Shard Key는 왜 게시판 ID일까? ❗️게시글 서비스는 게시판 단위로 서비스를 이용한다. 게시판 단위로 게시글 목록이 조회되기 때문

만약 Shard Key가 article_id 일 경우 동일한 게시판에 속한 게시글이 별도의 샤드에 저장될 수 있다. 각 게시판의 게시글 목록을 조회하는 경우 게시글이 속한 모든 샤드에 조회를 요청해야 한다. N개의 샤드라면, 게시글의 N개의 샤드로 분산되어 있으므로 게시글 목록 조회를 위해 N개의 쿼리를 사용해 목록을 조회하는 복잡한 처리가 필요하다.

Primary Key

• 오름차순 유니크 숫자를 애플리케이션에 직접 생성 AUTO_INCREMENT 또는 UUID를 사용하지 않는다.
• 오름차순 유니크 숫자를 만들기 위한 알고리즘
• Snowflake*, TSID 등

게시글 API 및 Test Data

• 1200만 건 데이터 삽입 1번 게시판에 1200만 건 게시글

❓대규모 데이터에서 게시글 목록 조회는 왜 복잡할까? 모든 데이터를 한 번에 보여줄 수 없다. 메모리, 네트워크, 성능 등의 제약...페이징이 필요하다.

서버 애플리케이션 내의 메모리로 디스크에 저장된 모든 데이터를 가져오고, 특정 페이지만 추출하는 것은 비효율적이다. 데이터베이스에서 특정 페이지의 데이터만 바로 추출하는 방법이 페이징 쿼리다.

페이징

• 페이지 번호 이동할 페이지 번호가 명시적으로 지정, 원하는 페이지로 즉시 이동 가능

• 무한 스크롤 스크롤을 내리면 다음 데이터가 조회, 주로 모바일 환경에서 사용

페이지 번호

페이지 번호 방식에는 두 가지 정보가 필요하다. 페이지 당 30개의 게시글을 보여주고, 총 94개의 게시글이 있다면, 사용자는 클라이언트 화면에서 4번 페이지까지 이동할 수 있다. 페이지 번호 활성화에 필요

N번 페이지에서 M개의 게시글을 조회하려면? SQL offset, limit을 활용하여 페이지 쿼리를 할 수 있다. offset지점 부터 limit개의 데이터 조회

select * from article
where board_id = {board_id}
order by create_at desc 
limit 30 offset 90;

그런데 1,200만 건의 데이터를 조회하는데 4초가 소요되었다. 정상적으로 서비스하기 어려운 상황이다. Query Plan으로 확인해보고 인덱스를 사용한다.

create index idx_board_id_article_id on article(board_id asc, article_id);

여기서 created_at 이 아닌 article_id로 사용했나? 현재 게시판은 분산 환경을 가정하여 만들고 있는데 여러 서버에서 동시에 처리될 수 있기 때문이다. 게시글이 동시에 생성될 수 있다. 또한, 테스트 데이터를 멀티스레드에서 동시에 생성했기 때문에 동일 시간을 갖는 데이터가 많다.

article_id는 분산 시스템에서 고유한 오름찬순을 위해 고안된 알고리즘을 사용해 데이터를 저장한다.

select * from article
where board_id = 1
order by aricle_id desc 
limit 30 offset 90;

이전에는 약 4초가 소요되었다면 0초대에 수행되는 것을 확인해 볼 수 있다. 또한, Query Plan를 살펴보면 key = idx_board_id_article_id 를 사용하는 것도 확인해 볼 수 있을 것이다.

그렇다면 모든 문제는 해결되었는가?? 만약 50,000페이지를 조회한다면 다시 4초의 시간이 걸릴 것이다. 인덱스를 생성하고 사용하게 했지만 느려진다.

이런 경우에는 Secondary Index(보조 인덱스 or Non-clustered Index)가 Clustered Index에 접근하게 하여 데이터를 가져오면 된다. Secondary Index에더 데이터에 접근하기 위한 포인터를 찾은 뒤, Clustered Indexd에서 데이터를 찾는 방식이다.

select * from (
    select article_id from article
    where board_id = 1
    order by article_id desc
    limit 30 offset 1499970
) t left join article on t.article_id = article.article_id;

여기서 서브쿼리는 Covering Index로 동작한다. 데이터를 읽지 않고 인덱스에 포함된 정보만으로 쿼리가 가능하기 때문에 1499970 건이 있어도 빠르게 조회할 수 있다.

만약 여기서 더 높은 페이지를 조회할려 한다면??? 여기서 생각해 볼 수 있는건 그 조회가 정상적인 조회인지를 생각해야 한다. 데이터 수집을 목적으로 하는 어뷰저일 수도 있기 때문에 정책으로 풀어내 특정 페이지까지만 제한해야 한다.

Clinet는 초기에 단일 데이터베이스를 사용한다.

❓서비스가 활성화되어 단일 DB로 처리하기엔 큰 부담이 생기게 되었을 때, 저장해야 할 데이터와 트래픽이 많아졌다면???

❗️가장 간단한 방법으로 Scale-Up을 고려해볼 수 있다.

❓얼마 후 서비스가 더욱 활성화되면서 단일 DB로 처리하기엔 큰 부담이 생기게 되었다. 저장해야 할 데이터와 트래픽이 계속 많아 진다면???

❗️이번에도 Scale-Up을 고려해볼 수 있지만, 장비를 무한정 Scale-Up하는 것은 한계가 있다. 한계로 인해 Scale-Out을 고려해볼 수 있다. 장비를 어러 대 사용하여 수평확장하는 것이다.

2대의 DB로 운용되어 Client의 요청은 각 DB로 분살될 수 있고, 데이터베이스에 대한 하나의 분산 시스템이 구성된 것이다.

❓그렇다면 데이터는 각 DB에 어떻게 분산될 수 있을까?

샤딩을 이용하여 데이터를 여러 DB에 분산할 수 있다. 그리고 샤딩된 각각의 데이터 단위를 샤드라고 부른다.

샤딩(Sharding): 데이터를 여러 데이터베이스에 분산하여 저장하는 기술 샤드(Shard): 샤딩된 각각의 데이터 단위

Sharding

Vertical Sharding

수직 샤딩(Vertical Sharding): 데이터를 수직으로 분할하는 방식(컬럼 단위) article_id 식별자를 이용하여 분산 저장

• 상위 샤드 -> board_id, created_at
• 하위 샤드 -> title, content

각 샤드가 적은 수의 컬럼을 저장하므로, 성능 및 공간 이점이 생긴다. 하지만, 데이터의 분리로 인해 조인 또는 트랜잭션 관리가 복잡해질 수 있다. 수직으로 분할되므로 수평적 확장에 제한이 있다.

Horizontal Sharding

수평 샤딩(Horizontal Sharding): 데이터를 수평으로 분할하는 방식(행 단위) 으로 분산 저장

• 하위 샤드 -> article_id 1 ~ 5000
• 상위 샤드 -> article_id 5000 ~ 10000

각 샤드에 데이터가 분산 저장되므로 성능 및 공간 이점이 생긴다. 하지만, 데이터의 분리로 인해 조인 또는 트랜잭션 관리가 복잡해질 수 있다. 수평으로 분할되므로 수평적 확장에 용이하다.

• 시스템의 구조나 설계 방식
• 확장성, 유지보수성, 서능 등 큰 영향

대표적인 아키텍처

• Monolithic Architecture
• Micorservice Architecture

Monolithic Architecture

Monolithic: 단일의, 일체형의, 하나의 큰 덩어리로 된 Monolithic Architecture:애플리케이션의 모든 기능이 하나로 통합된 아키텍처 위 애플리케이션은 게시판 서비스의 모든 기능을 포함하고 있다. 간단한 구조를 가지기 때문에 초기에 쉽고 빠르게 개발할 수 있다.

이러한 애플리케이션을 1대의 서버에 배포하여 서비스하는 상황을 가정

Monolithic Architecture 로 구성된 애플리케이션 서버 한 대에 배포했을 때 단일 코드베이스로 관리하기 때문에, 각 애플리케이션에는 모든 기능이 포함되어 있다. 서비스가 활성화되면, 게시글 조회 수와 작성 트래픽이 급등했다고 가정했을 때, 게시글 기능만 트래픽이 많아 진 것이다.

부하를 감당하기 위해 Scale-Up하여 단일 서버의 성능을 향상시키는 것이다.

그렇다면 트래픽이 서버에서 감당할 수 없을 정도로 많아질 때 마다 Scale-Up을 하면 되는 것일까? 하지만 서버를 무한정 Scale-Up하는 것은 한계가 있고 가격도 점점 비싸진다.

수직으로 확장하는 것은 한계가 있으므로, 수평으로 확장하는 방법을 고려해 볼 수 있다. 서버를 여러대의 부하를 분산하여 성능을 높이는 Scale-Out

서버가 1대에서 3대로 확장되었고, 3개의 서버에서 게시글 트래픽을 처리하므로, 1대에서 처리되는 부하가 3대로 분산되는 것이다.이제 게시글 기능은 문제 없이 처리될 수 있다.

하지만, 위 구성은 리소스 낭비되는 지점이 있다. 분명 게시글 기능에 대한 부담만 대응하면 충분했다. Monolithic Architecture에서 모든 기능이 단일 애플리케이션에서 함께 배보되므로, 게시글과 관련 없는 기능들도 같이 배푀되어서 리소스를 점유하고 있는 것이다.

직접 코드를 개발하는 상황에서의 문제점도 있다. 흔히 개발 편의와 생산성을 위해 중복을 제거하고, 공통 코드를 관리한다. 위 그림에서 인기글 기능에서 공통 코드를 사용한다.

서비스의 활성화를 위해 인기글 선정 정책에 변화가 필요해졌을 때 인기글의 코드 변경이 필요한상황이라고 가정한다. 인기글 코드와 인기글 개발 편의를 위해 사용하던 공통 코드에 변경이 생겼다. 코드에서 인기글과 공통 코드만 변경이 있었고, 인기글 기능에 문제가 없음을 확인했다. 그리고 개발자는 변경 사항을 반영하기 위해 재배포를 진행한다.

그런데 문제가 발생한다. 건드린적 없던 게시글과 댓글 기능이 동작하지 않는 것이다.

공통 코드의 사용처를 살펴보니, 게시글과 댓글 기능에서도 함께 사용되고 있었다. 인기글을 위한 변경 사항이 게시글과 댓글 기능에선 호환되지 않던 것이다.

단일 코드베이스에서 통합 관리하다보면, 공통 코드 관리 등으로 변경 사항이 타 기능에 예기치 않게 전파될 수 있다. 전파되는 범위는 시스템이 커질수록 넓어지고 복잡해진다. 공통 코드가 아니더라도, 연관된 기능에 대해 서로의 코드를 침범하며, 코드 간 결합도가 높아지고, 각 기능의 응딥도가 낮아질 수 있다. 이는 유지보수를 점점 어렵게 만든다.

또한, 인기글 기능만 변경하려고 했음에도 모든 기능이 다시 배포되어야 했다. 모든 기능이 단일 애플리케이션에 함계 관리되기 때문이다. 애플리케이션이 무거워질수록, 빌드 및 배포 시간은 늘어난다.

만약 인기글 기능 변경 사항에 오류가 남아있어서 장애가 발생했다면? 인기글 기능만 사용할 수 없다면 다행이다. 또는, 변경이 전파된 게시글, 댓글까지만 사용할 수 없어도 다행일 것이다. 최악의 경우 모든 기능이 단일 애플리케이션에서 함께 배포 및 관리되므로, 시스템의 모든 기능으로 장애가 전파될 수 있다.

정리

• 모든 기능이 단일 코드베이스로 결합된 아키텍처
• 소규모 시스템에서 개발 및 배포가 간단하기 때문에 많이 선택
• 빠르고 효율적으로 개발할 수 있음

  하지만

• 특정 부분만 확장하기 어려움
• 변경 사항이 시스템 전체에 영향을 미침
• 대규모 시스템에서 복잡도가 커지고 개발의 어려움

Micorservice Architecture

Micorservice Architecture에서는 시스템이 작고 독립적인 서비스(Microservice)로 구성된다. 단일 애플리케이션에 모두 포함 됐던 기능이 각각의 마이크로서비스로 분리되고, 하나의 애플리케이션에 만들어진 기능이 6개의 애플리케이션으로 분리된 것이다.

각각의 마이크로 서비스는 독립적으로 배포될 수 있다. 6개의 마이크로 서비스가 배포되는 상황을 가정

각 서비스가 독립적인 애플리케이션으로 배포되었고, 배포되는 서버도 독립적으로 구성될 수 있다. 각 서비스는 유기적으로 연결되어 통신하며 하나의 시스템을 이룬다.

각 서비스의 코드는 독립적으로 관리 및 배포되므로, 개별 서비스 내에서는 복잡도가 낮고, 빠르게 빌드 및 배포할 수 있다.

게시글에 대한 트래픽에 대응해야 한다면?? 모든 기능이 함께 배포되어야 했던 Monolithic Architecture와 달리 Microservice Archtecture에서는 게시글 서비스의 서버만 증설해볼 수 있다. 다른 서비스들과 독립적으로 배포되기 때문에, 게시글에 대한 리소스만 추가로 점유하게 된다.

인기글에 대한 코드 변경 또는 장애가 발행하더라도 다른 서비스의 코드는 물리적으로 분리되어 있기 때문에 전파 범위가 줄어든다.

얼핏 보면 Monolithic의 문제를 모두 해결하는 만능 아키텍처인 것 같지만, 서비스 간 통신 비용, 트랜잭션 관리, 서비스 분리 기준, 모니터링, 개발 비용, 테스트, 설계 등 고려해야할 부분이 엄청 많다.

정리

• 시스템이 작도 독립전이 서비스(Microservice)로 구성
• 각 서비스는 단일 기능을 담당하며, 독립적 배포가능
• 서비스 단위로 유연한 확장 가능

  하지만

• 서비스 간 복잡한 통신 및 모니터링 필요
• 데이터 일관성 및 트랜잭션 관리의 어려움
• 여러운 개발 난이도

Server -> Spring Boot

Spring Boot는 Client의 요청을 처리하면서 어딘가에 상태를 관리해야 할 수 있다. 데이터는 데이터베이스에 의해 안전하게 괸리 될 수 있다.

서비스가 활성되면서 Client의 요청이 많아졌다고 가정했을 때, 서버의 리소스 부족으로 인해, 단일 서버, 단일 애플리케이션에서 감당할 수 없는 지경이 된다.

단순히 Scale-Up을 고려할 수 있지만 한계는 존재한다. 애플리케이션을 여러 서버에서 동시에 실행하여 처리를 분산할 수 있다. Scale-Out

Scale-Up : 단일 서버의 성능을 향상시키는 것 (수직확장) Scale-Out : 서버를 추가하여 성능을 향상시키는 것(수평 확장)

Client는 애플리케이션으로 요청을 분산하여 처리할 수 있다. 하지만 서버가 증설될 때 마다 Client가 이러한 정보를 모두 알 수 없고, 알아야 할 필요도 없다.

트래픽을 라우팅 및 분산하기 위한 도구로 Load Balancer를 활용할 수 있다. Client는 Load Balancer로 요청을 보내면, Load Balancer는 요청을 적절히 분산하여 서버로 전달한다.

Scale-Out은 Load Balancer, Database에 대해서도 처리될 수 있지만, Client가 요청을 처리하는 과정이 복잡해 질 수록 응답은 느려질 수 있다. 그래서빠른 성능을 위해 캐시(Cache)를 사용한다.

캐시는 각 구간마다 적절히 적용 해 브라우저에서 자제적인 캐시를 활용, DNS 쿼리 결과를 캐시, 데이터베이스보다 빠르게 데이터에 접근, CDN 기술에 활용, 캐시라는 개념을 다양한 구간에 적용될 수 있다. Cache도 필요하면 Scale-Out을 적용하여 단일 서버의 부하를 줄여줄 수 있다.

안전성에 대한 문제도 있다. 네트워크는 안전하지 않기 때문에 언제든 순단 가능성이 있고, 서버와 데이터는 시스템 오류 또는 자연 재해 등으로 언제든 중단 및 유실될 수 있다. 또, 지리적으로 서버와 멀리 떨어져 있다면, 응답 시간에 큰 지연이 생길 수 있다.

문제를 방지하기 위해, 서버를 지리적으로 여러 장소에 구설 할 수도 있다. 서버가 설치된 데이터센터를 다중화하는 것이다. 분산된 각 서버에 대한 Client의 라우팅을 위해 DNS를 활용할 수도 있고, 더욱 정밀하고 복잡한 라우팅이 필요한 경우 GSLB 등 다양한 방법을 활용할 수도 있다.

단일 애플리케이션은 커질수록 관리가 어려워질 수있다. 서버가 처리해야할 트래픽이 너무 많아지면, 리소스가 부족할 수도 있고, 시스템이 커질수록 애플리케이션의 유지보수가 어려워질 수도 있기 때문이다. 단일 애플리케이션을 기능에 맞는 여러 개의 애플리케이션으로 분리하여 관리할 수 있다. 각 애플리케이션은 담당한 기능에 대해 개별 작업만 처리할 수있는 것이다.

예를 들어 A 애플리케이션은 게시글 기능만, B 애플리케이션은 댓글 기능만 처리한다. 필요하면, 데이터베이스도 각 기능 별로 분리하여 구성할 수 있다.

분리된 웹 애플리케이션이 하나의 서비스를 이루려면 서로 네트워크 통신이 필요할 수 있다. API를 통해 직접적으로 통신할 수도 있지만, 메시지(이벤트) 를 통해 간접적으로 통신할 수도 있다.

이처럼 시스템은 성능, 안전성, 확장성이라는 세 가지 축을 균형있게 고려해야 한다. 단순히 서버를 늘리거나 기능을 분리하는 것만으로 충분하지 ㅇ낳다. 서비스의 특성과 트래픽 패턴에 따라 적절한 캐시 전략, 데이터 분산 방식, 통신 구조(API 또는 메시징 기반)를 설계해야 한다. 또한 각 구성 요소 간의 장애 격리와 복구 절자, 모니터링 체계를 갖추는 것이 중요하다.

마지막으로 이러한 요소들이 조화롭게 결합된 시스템 아키텍처를 살펴보면, 서비스가 어떤 원리로 대규모 트래픽을 안정적으로 처리하고 빠르게 확장할 수 있는지 한눈에 이해할 수 있다.

• 여러 개의 Docker 컨테이너들을 하나의 서비스로 정의하고 구성해 하나의 묶음으로 관리할 수 있게 해 준다.
• 여러 개의 컨테이너를 관리하는데 용이
• 복잡한 명령어로 실행시키던걸 간소화시킬 수 있음

Docker Compose 흐름(Nginx)

Docker CLI로 컨테이너 실행

$ docker run --name webserver -d -p 80:80 nginx

Docker Compose로 컨테이너 실행

1. compose.yml 파일 작성

services:
 my-web-server:
  container_name: webserever
  image: nginx
  ports:
   - 80:80

• services: my-web-server -> Docker Compose에서 하나의 컨테이너를 서비스(service)라 부른다. 이 옵션은 서비스에 이름을 붙이는 기능이다.
• container_name: web-server -> 컨테이너를 뛰울 때 붙이는 별칭이다. CLI에서 --name web-server와 동일하다.
• image: nginx -> 컨테이너를 실행시킬 때 어떤 이미지를 사용할지 정의하는 명령어다. docker run [이미지명]과 동일
• ports -> 포트 매핑은 어떻게 할지를 설정하는 옵션이다. CLI -p 80:80과 동일하다.

1. compose 파일 실행시키기

$ docker compose up -d

1. compose 실행 현황 보기

$ docker compose ps
$ docker ps

1. localhost:80 확인
2. compose로 실행된 컨테이너 삭제

$ docker compose down

Docker Compose로 MySQL 실행

Docker CLI 로 컨테이너 실행

$ docker run -e MYSQL_ROOT_PASSWORD=pwd123 -p 3306:3306 -v /User/docker/docker-mysql:/var/lib/mysql -d mysql

Docker Compose로 MySQL 실행

1. compose 파일 작성

service:
 my-db:
  image: mysql
  enviroment:
   MYSQL_ROOT_PASSWORD: pwd123
  volumnes:
   - ./mysql_data:/var/lib/mysql
      ports:
   - 3306:3306

• enviroment: ... -> CLI에서 -e MYSQL_ROOT_PASSWORD=password 역할과 동알하다.
• volumnes: ... -> CLI 에서 -v {호스트 경로}:/var/lib/mysql 역할과 동일하다.

2. compose 파일 실행

$ docker compose up -d

3. compose 실행 현황

$ docker compose ps
$ docker ps

4. 잘 작동하는 지 DBeaver 연결 확인

5. volumne의 경로에 데이터 저장되고 있는지 확인

6. compose로 실행된 컨테이너 삭제

$ docker compose down

Docker Compose로 Spring Boot 실행

1. 프로젝트 셋팅

Java17 버전을 기준으로 진행

2. 간단한 코드 작성

@RestController
public class AppController {
  @GetMapping("/")
  public String home() {
    return "Hello, World!";
  }
}

3. Dockerfile 작성

FROM openjdk:17-jdk

COPY build/lib/*SNAPSHOT.jar /app.jar

ENTRYPOINT ["java","-jar","/app.jar"]
bash

4. Spring Boot 프로젝트 빌드

$ ./gradlew clean build

5. compose 파일 작성

compose.yml

services:
 my-server:
  build: .
  ports:
   - 8080:8080

• build: . -> compose.yml 이 존재하는 디렉토리( . )에 있는 Dockerfile로 이미지를 생성해 컨테이너를 뛰우겠다는 의미

참고) Docker CLI 로 실행

$ docker build -t hello-server .
$ docker run -d -p 8080:8080 hello-server

6. compose 파일 실행시키기

$ docker compose up -d --build

7. compose 실행 현황 보기

$ docker compose ps
$ docker ps

8. localhost :8080으로 들어가보기

9. compose로 실행된 컨테이너 삭제

$ docker compose down

Dockerfile이라는 걸 활용해서 Docker 이미지를 만들 수 있다.

Dockerhub에 올려놓은 Docker 이미지가 아닌 나만의 Docker 이미지를 만들고 싶을 수 있다.

예로 Spring Boot 프로젝트가 있을 때 프로젝트 자체를 Docker 이미지로 만들고 싶다면 이럴때 Dockerfile을 활용하면 나만의 Docker 이미지를 만들고 사용할 수 있다.

FROM

FROM 은 베이스 이미지를 생성하는 역할을 한다. Docker 컨테이너 특정 초기 이미지를 기반으로 추가적인 셋팅을 할 수 있다. 여기서 말한 특정 초기 이미지가 곧 베이스 이미지다.

FROM [이미지명]
FROM [이미지명]:[태그명]

태그명을 적지 않으면 해당 이미지의 최신(latest)버전을 사용한다.

FROM 실습

# Docker file
FROM openjdk:17-jdk

-------------------------------------------------------------------------

# Docker로 이미지 생성하는 문법
$ docker build -t my-jdk17-serever

# 이미지를 기반으로 컨테이너 뛰우기
$ docker run -d my-jdk17-server

COPY

COPY는 호스트 컴퓨터에 있는 파일을 복사해서 컨테이너로 전달한다.

COPY [호스트 컴퓨터에 있는 복사할 파일의 경로] [컨테이너에서 파일이 위치할 경로]

# 예시 (파일)
COPY app.txt /app.txt

# 예시 (폴더)
COPY my-app /my-app/

# 예시 (와일드 카드)
COPY *.txt /text-files/

.dockerignore

특정 파일 또는 폴더만 COPY를 하고 싶지 않을 수 있다. 그럴때 .dockerignore를 활용한다.

.dockeignore

readme.txt

dockerfile을 만들고 이미지 생성 및 컨테이너를 실행하면

readme.txt 을 제외하고 COPY된 결과를 볼 수 있다.

ENTRYPOINT

ENTRYPOINT컨테이너가 생성되고 최초로 실핼할 때 수행되는 명령어를 뜻한다. 쉽게 설명하자면 컴퓨터의 전원을 키고나서 실행시키고 싶은 명령어를 적으면 된다.

ENTRYPOINT [명령문...]
ENTRYPOINT ["/bin/bash","-c","echo hello"]

Spring Boot를 Docker 실행

1. SpringBoot간단한 코드 작성

@RestController
public class AppController {
 @GetMapping("/")
 public String home() {
     return "Hello World";
 }
}

2. Dockerfile

FROM openjdk:17-jdk

COPY build/libs/*SNAPSHOT.jar app.jar

ENTRYPOINT ["java", "-jar", "/app.jar"]

3. Spring Boot Build

$ ./gradlew clean build

4. Dockerfile을 이미지 빌드

$ docker build -t hello-server .

5. 생성 이미지 컨테이너 실행

$ docker run -d -p 8080:8080 hello-server

RUN

RUN 은 이미지를 생성 과정에서 명령어를 실행시켜야 할 때 사용한다.

RUN [명령문]
RUN npm install

RUN VS ENTRYPOINT

RUN, ENTRYPOINT를 사용하다보면 헷갈리는 경우가 있다. 둘 다 같이 명령어를 실행시키기 때문이다.

하지만 둘의 사용 용도는 다르다. RUN은 이미지 생성 과정에서 필요한 명렬어를 실행시킬 때 사용하고 ENTRYPOINT는 생성된 이미지를 기반으로 컨테이너를 생성한 직후에 명령어를 실행시킬 때 사용한다.

FROM ubuntu

RUN apt update && apt install -y git

ENTRYPOINT ["/bin/bash","-c","sleep 500"]

WORKDIR

WORKDIR 으로 작업 디렉터리를 전환하면 그 이후에 등장하는 모든 RUN, CMD, ENTRYPOINT, COPY, ADD 명령문은 해당 디렉터리를 기준으로 실행된다. 작업 디렉터리를 굳이 지정해주는 이유는 컨테이너 내부의 폴더를 깔끔하게 관리하기 위해서이다.

WORKDIR [작업 디렉토리로 사용할 절대 경로]
WORKDIR /usr/src/app

EXPOSE

EXPOSE는 컨테이너 내부에서 어떤포트에 프로그램이 실행되는 지를 문서화하는 역할을 한다.

-p의 옵션과 같은 역할은 아니다. 쉽게 표현하자면 EXPOSE 명령어를 쓰나 안 쓰나 작동하는 방식의 영향을 미치지 않는다.

권장사항 일 뿐 실제 뜨는 포트랑 달라도 전형 상관없다.

EXPOSE [포트 번호]
EXPOSE 8080

Docker를 활용하면 특정 프로그램을 컨테이너로 뛰울 수 있다.

프로그램에 기능이 추가되면 새로운 이미지를 만들어 컨테이너를 실행시켜야 한다.

이때 Docker는 기존 컨테이너에서 변경된 부분을 수정하지 않고 새로운 컨테이너를 만들어서 통째로 갈아 끼우는 방식으로 교체한다.

이런 특징 때문에 기존 컨테이너를 새로운 컨테이너로 교체하면 기존 컨테이너 내부에 있던 데이터도 같이 삭제된다.

만약 이컨테이너가 데이터베이스를 실행시키는 컨테이너였다면 저장된 데이터도 같이 삭제 된다.

따라서 컨테이너 내부에 저장된 데이터가 삭제되면 안되는 경우에는 볼룸(Volume) 이라는 개념을 사용한다.

Docker Volume(도커 볼룸)

도커의 볼룸(Volume)이란 도커 컨테이너에서 데이터를 영속적으로 저장하기 위한 방법이다.

볼룸은 컨테이너 자체의 저장 공간을 사용하지 않고 호스트 자체의 저장 공간을 고유해서 사용하는 형태이다.

볼룸(Volumne)을 사용하는 명령어

$ docker run -v [호스트의 디렉토리 절대경로]:[컨테이너의 디렉톤리 절대경로] [이미지]:[태그명]

• [호스트의 디렉토리 절대경로]에 디렉토리 이미 존재할 경우 호스트의 디렉터리가 컨테이너의 디렉터리를 덮어 쒸운다.
• [호스트의 디렉토리 절대경로]에 디렉토리가 존재하지 않을 경우 호스트의 데렉터리 절대 경로에 디렉터리를 새로 만들고 컨테이너의 디렉터리에 있는 파일들을 호스트의 티렉터리로 복사해온다.

Dokcer로 MySQL 실행시키기

1. MySQL 이미지를 바탕으로 컨테이너 실행시키기

$ docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -d mysql
$ echo $MYSQL_ROOT_PASSWORD
또는
$ exprot

• -e : 해당 옵셩은 컨테이너의 환경 변수를 설정하는 옵션
• Dockerhub의 MySQL 공신 문서를 보면 환경 변수로 MYSQL_ROOT_PASSWORD를 정해야만 정상적으로 컨테이너가 실행된다고 적혀있다.
• 아래의 명령어로 컨테이너로 들어가서 환경 변수를 직접 확인할 수 있다.

$ docker exec -it [MySQL 컨테이너 ID] bash

1. 컨에티너가 잘 실행되고 있는지 체크
2. 컨테이너 실행시킬 때 에러 없이 잘 실행되는지 로그 체크
3. DBeaver에도 연결 시켜 체크

볼룸(Volumne)을 활용해서 MySQL 컨테이너 뛰우기

1. MySQL 컨테이너 뛰우기

$ cd /User/test $ mkdir docekr-mysql
# docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -v {호스트의 절대경로}/mysql-sql:/var/lib/mysql -d mysql
$ docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -v /User/test/docker-mysql:/var/lib/mysql -d mysql`

1. MySQL 컨테이너에 접속해서 데이터베이스 만들기

$ docker exec -it [MySQL 컨테이너 ID] bash
$ mysql -u root -p
mysql> show database;
mysql> create databases mydb;
mysql> show datavbases;

1. 컨테이너 종료 후 다시 생성해보기

# 컨테이너 종료 후 삭제하고 다시 생성

$ docker stop [MySQL 컨테이너 ID]
$ docker rm [MySQL 컨테이너 ID]
$ docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -v /User/test/docker-mysql:/var/lib/mysql -d mysql

$ docker exec -it [MySQL 컨테이너 ID] bash
$ mysql -u root -p

mysql> show database;
mysql> show datavbases;

• 결과를 보면 삭제 전에 만들었던 데이터베이스 mydb의 정보가 남아 있는걸 확인할 수 있다.