https://www.acmicpc.net/problem/17298

크기가 N인 수열 A = A1, A2, ..., AN이 있다. 수열의 각 원소 Ai에 대해서 오큰수 NGE(i)를 구하려고 한다. Ai의 오큰수는 오른쪽에 있으면서 Ai보다 큰 수 중에서 가장 왼쪽에 있는 수를 의미한다. 그러한 수가 없는 경우에 오큰수는 -1이다. 예를 들어, A = [3, 5, 2, 7]인 경우 NGE(1) = 5, NGE(2) = 7, NGE(3) = 7, NGE(4) = -1이다. A = [9, 5, 4, 8]인 경우에는 NGE(1) = -1, NGE(2) = 8, NGE(3) = 8, NGE(4) = -1이다.

풀이과정

N의 최대 크기가 1,000,000이므로, 단순히 이중 for문으로 오른쪽 값을 확인하면 시간 초과가 발생한다. 따라서 한 번의 순회로 오큰수를 찾기 위해 스택을 활용한다.

핵심 아이디어는 다음과 같다.

1. 스택에는 아직 오큰수를 찾지 못한 인덱스를 저장한다.
2. i번째 원소 lst[i]를 보면서, 스택 top에 있는 인덱스들의 값이 lst[i]보다 작다면 해당 값들의 오큰수는 lst[i]이므로 answer에 기록하고 스택에서 제거한다.
3. i는 아직 오큰수를 찾지 못한 상태이므로 스택에 push한다.

이 과정을 전체 배열에 대해 수행하면 각 원소의 오큰수를 O(N)에 구할 수 있다.

풀이

n = int(input())
lst = list(map(int, input().split()))
answer = [-1] * n

stack = [0] # 스택에는 아직 오큰수를 찾지 못한 수의 인덱스가 들어있다!
for i in range(1, n):
    while stack and lst[stack[-1]] < lst[i]:
        idx = stack.pop()
        answer[idx] = lst[i]
    stack.append(i)

print(*answer)

https://www.acmicpc.net/problem/1377

(요약) 아래 소스코드를 실행했을 때, 어떤 값이 출력되는지 맞추는 문제

bool changed = false;
for (int i=1; i<=N+1; i++) {
    changed = false;
    for (int j=1; j<=N-i; j++) {
        if (A[j] > A[j+1]) {
            changed = true;
            swap(A[j], A[j+1]);
        }
    }
    if (changed == false) {
        cout << i << '\n';
        break;
    }
}

풀이과정

"N은 500,000보다 작거나 같은 자연수이다." 라는 조건이 있으므로, 시간제한이 1초인 해당 문제를 버블 정렬(최악의 경우, 시간복잡도 O(N^2))으로는 풀 수 없다.

따라서 처음에는 O(N log N)의 시간복잡도를 갖는 머지 소트를 구현해서 정렬 후의 idx가 정렬 전의 idx와 일치하는 경우를 찾아 출력하는 방식을 고려하였다. 하지만 직접 시뮬레이션 하는 것보다 더 좋은 방법이 있음을 알게 되어 해당 아이디어를 공유한다.

bool changed = false;
for (int i=1; i<=N+1; i++) {
    changed = false;
    for (int j=1; j<=N-i; j++) {
        if (A[j] > A[j+1]) {
            changed = true;
            swap(A[j], A[j+1]);
        }
    }
    if (changed == false) {
        cout << i << '\n';
        break;
    }
}

출력해야 하는 수 i 가 의미하는 것은 뭘까? 더 이상 changed가 일어나지 않는, 즉 이미 정렬된 상태에 이르렀음을 의미한다. 따라서 몇번째 패스(i) 직전에 이미 정렬이 완료되었는지를 구하면 되는 문제라고 이해할 수 있다.

이때 버블 정렬의 경우, 각 원소는 한 번에 한 칸씩만 이동(swap)할 수 있다. 이 특성을 활용하면 정렬 전 원소의 위치와 정렬 후 원소의 위치를 비교해서 가장 많은 칸을 이동한 원소의 칸 수를 통해, 몇 번의 패스동안 유의미한 정렬이 이루어졌는지를 파악할 수 있게 된다.

풀이

n = int(input())
lst = []

for i in range(n):
    num = int(input())
    lst.append((num, i))
sorted_lst = sorted(lst)

answer = 0
for i in range(n):
    answer = max(answer, sorted_lst[i][1] - i)

print(answer+1)

정렬 전 lst를 (num, 정렬 전 idx) 형태의 튜플로 저장한다. 이후 정렬된 sorted_lst의 idx와 정렬 전 idx의 차이의 최대값을 구한다. 이 값이 곧, 최대 몇 번의 Pass동안 유의미한 정렬이 이루어졌는지를 의미한다.

4.1.2 예외의 종류와 특징

자바에서 throw를 통해 발생시킬 수 있는 예외

1. Error
   1. 자바 VM에서 발생시키며, 애플리케이션 레벨에서 잡을 수 있는 예외가 아니다.
   2. ex) OutOfMemory, ThreadDeath
2. Exception과 체크 예외
   1. 애플리케이션 코드 상에 예외사항이 발생했을 때 java.lang.Exception 클래스가 사용된다.
   2. Exception 클래스는 체크 예외와 언체크 예외로 구분된다.

3. 일반적으로 예외는 체크 예외라고 생각하면 된다. 

    → ex) IOException, SQLException

4. 체크 예외가 발생할 수 있는 메서드를 사용할 때는 반드시 예외 처리 코드를 함께 작성해야 한다. 

    → 체크 예외는 복구할 가능성이 조금이라도 있는, 예외사항을 다루기 때문.

3. RuntimeException과 언체크/런타임 예외

   1. 명시적인 예외 처리를 강제하지 않으며, 프로그램 오류가 있을 때 발생되도록 의도된 것들이다.

      → ex) NULLPointerException, IllegalArgumentException

   2. 런타임 예외는 예상치 못했던 상황에서 발생하는 것이 아니고, 피할 수 있지만 개발자의 부주의에 의해 발생할 수 있는 예외를 다룬다.

→ 체크 예외는 예외 처리를 강제하는 것 때문에 예외 블랙홀이나 무책임한 throws 코드가 남발되어 비난의 대상이 되기도 했다.

4.1.3 예외처리 방법

예외를 처리하는 일반적인 방법

1. 예외 복구

   • 예외상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓는 것
   • 기본 작업 흐름이 불가능할 때 다른 작업 흐름으로 자연스럽게 유도해주는 경우 예외를 복구했다고 볼 수 있다.

2. 예외처리 회피

   • 자신을 호출한 쪽으로 예외처리를 던져버린다.

     → thorws 문으로 선언 or catch 문으로 예외를 잡고 rethrow

     public void add() throws SQLException {
       try {
           //
       } catch(SQLException e) {
           // pring log
           throw e;
       }
     }

   • 예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.

   • 콜백/탬플릿처럼 긴밀한 관계에 있는 다른 오브젝트에게 책임을 분명히 지게 하거나,

   • 자신을 사용하는 쪽에서 예외를 다루는 게 최선의 방법이라는 분명한 확신이 있어야 한다.

3. 예외 전환

   • 예외 회피와 달리, 발생한 예외를 그대로 넘기는 것이 아니라 적절한 예외로 전환해서 던진다.

   • 의미를 분명하게 해줄 수 있는 예외로 바꿔줄 수 있다.

     • 중복 아이디 사용자를 등록하려고 할 때 SQLException → DuplicationUserIdException

       public void add(User user) thorws DuplicateUserIdException, SQLException {
         try {
             // DB에 User 추가
         } catch(SQLException e) {
             if (e.getErrorCode() == MysqlErrorNubmers.ER_DUP_ENTRY)
                 throw DuplicateUserIdException();
             else
                 throw e;
             }
         }

   • 전환하는 예외에 원래 발생한 예외를 담아서 중첩예외로 만드는 것이 좋다.

       catch(SQLException e) {
           throw DuplicateUserIdException(e);
       }
     
       catch(SQLException e) {
           throw DuplicateUserIdException().initCause(e);
       }

     • 의미를 명확하게 하려고 예외 전환하는 것이 아니고, 예외처리를 강제하는 체크 예외를 언체크 예외인 런타임 예외로 바꾸는 경우에 사용한다.
     • 복구 불가능한 예외라면 가능한 한 빨리 런타임 예외로 포장해 던지게 해서 다른 계층의 메소드를 작성할 때 불필요한 thorws 선언이 들어가지 않도록 해줘야 한다.

4.1.4 예외처리 전략

런타임 예외의 보편화

• 최근 등장하는 표준 스펙 또는 오픈소스 프레임워크에서는 API가 발생시키는 예외를 언체크 에외로 정의하는 것이 일반화되고 있다.
• 대개 복구 불가능한 상황이고 RuntimeException 등으로 포장해서 던져야 할 테니 아예 API 차원에서 런타임 예외를 던지도록 만들어서 그 밖의 메소드들이 신경 쓰지 않게 해주는 편이 낫다는 것이다.

public class DuplicateUserIdException extends RuntimeException {
    public DuplicateUserIdException(Throwable cause) {
        super(cause);
    }
}

public void add() thorws DuplicateUserIdException {
    try {
        //
    } catch (SQLException e) {
        if (e.getErrorCode() == MysqlErrorNubmers.ER_DUP_ENTRY)
            throw new DuplicateUserIdException(e); //예외 전환
        else
            throw new RuntimeException(e); //예외 포장
    }
}

→ 낙관적인 예외처리 기법. 복구할 수 있는 예외는 없다고 가정하고 예외가 생겨도 런타임 예외이므로 시스템 레벨에서 처리하거나 꼭 필요한 경우는 런타임 예외를 잡아 복구하거나 대응해줄 수 있다는 태도를 기반으로 함.

애플리케이션 예외

• 외부의 예외상황이 원인이 아니라 애플리케이션 자체의 로직에 의해 의도적으로 예외를 발생시키고, 반드시 catch해서 조치를 취하도록 요구하는 예외

• ex) 잔고 부족 상황에서 출금처리를 하려고 할 때 → 비즈니스적인 의미를 띤 예외를 던지도록 하고, 체크 예외로 만들어 에외상황에 대한 로직을 구현하도록 강제한다.

    try {
        BigDecimal balance = account.withdraw(amount);
    } catch(InsufficientBalanceException e) {
        BigDecimal availFunds = e.getAvailFunds();
        //잔고 부족 메시지를 준비하고 이를 출력하도록 진행
    }

4.2.2 DB 에러 코드 매핑을 통한 전환

DB 종류가 바뀌더라도 DAO를 수정하지 않으려면

아래의 두 가지 문제를 해결해야 한다.

1. SQLException의 비표준 에러 코드

    if (e.getErrorCode() == MysqlErrorNumbers.ER_DUP_ENTRY) { ... 

   → DB별로 DB에러 코드가 다르기 때문에 DB 독립적인 코드가 될 수 없다.

2. SQLException이 제공하는 SQL 상태 정보

   • Open Group의 XOPEN SQL 스펙에 정의된 상태코드

     • 통신장애로 DB연결에 실패한 경우 08S01
     • 테이블이 존재하지 않는 경우 42S02

     → DB의 JDBC드라이버에서 SQLException을 담을 상태 코드를 정확하게 만들어주지 않는 문제가 있다.

해결책은,

• DB 업체별로 만들어 유지하고 있는 DB 전용 에러 코드를 사용해 예외의 원인이 무엇인지 해석해주는 기능을 만든다.
  • ex) 중복 오류가 발생하는 경우 MySQL-1062, Oracle-1 등의 에러 코드를 받게 되는데, 이 코드를 DuplicateKeyException이라는 의미가 분명히 드러나는 예외로 전환해준다.

3.2.2

탬플릿 메서드 패턴

• 상속을 통해 기능을 확장한다. → 상위 클래스에 불필요한 변화가 생기지 않도록 할 수 있으니 객체지향 설계의 핵심 원리인 OCP를 그럭저럭 지킬 수 있다.

• 매번 상속을 통해 서브클래스를 만들어야 한다.

• 확장구조가 클래스 설계 시점에서 고정되어 버린다. → 관계에 대한 유연성이 떨어진다.

전략 패턴

• 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 패턴이다.

• Context에서 일정한 구조를 가지고 동작하고, 특정 확장 기능은 Strategy 인터페이스를 통해 외부의 독립된 전략 클래스에 위임한다. → 복잡한 알고리즘을 바꿔가면서 사용할 수 있다는 것이 핵심

• Context가 구체적인 전략 클래스를 직접 알고 있다면 OCP에 잘 들어맞는다고 볼 수 없다. → Context를 사용하는 앞단의 Client가 어떤 전략을 사용할지 직접 정해서 Context에 전달하는 방식으로 해결할 수 있다.

→ 전략 오브젝트 생성과 컨텍스트로의 전달을 담당하는 책임을 분리하는 과정을 일반화시킨 것이 DI. 즉, DI란 전략패턴의 장점을 일반적으로 활용할 수 있도록 만든 구조인 것.

3.3.2

로컬 클래스

• 클래스 파일이 많아지는 문제를 해결할 수 있다.

💡 중첩 클래스의 종류

• Static Class: 독립적으로 오브젝트로 만들어 질 수 있음

• Inner Class: 자신이 정의된 클래스의 오브젝트 안에서만 만들어질 수 있음

  • 멤버 내부 클래스: 멤버 필드처럼 오브젝트 레벨에 정의됨
  • 로컬 클래스: 메서드 레벨에 정의됨. 로컬 변수를 선언하듯이 선언하면 됨
  • 익명 내부 클래스: 이름을 갖지 않으며 선언된 위치에 따라서 scope를 다르게 가짐

• 특정 메서드에서만 사용되는 클래스라면 로컬 클래스를 바로 정의해서 쓰는 것도 나쁘지 않음

• 내부 메서드는 자신이 정의된 메서드의 로컬 변수에 직접 접근할 수 있다는 장점도 있음. 다만, 외부 변수를 사용할 때는 외부 변수를 반드시 final로 선언할 것!

익명 내부 클래스

• 클래스 선언과 오브젝트 생성이 결합된 형태

• 클래스를 재사용할 필요가 없고, 구현한 인터페이스 타입으로만 사용할 때 유용함

  • 구현한 인터페이스를 생성자처럼 이용해서 오브젝트로 만든다.

      //StatementStrategy -> 인터페이스
      StatementStrategy st = new StatementStrategy() {
    
          ...
    
      };

3.4.2

인터페이스를 사용하지 않고 DI를 적용하는 것은 문제가 있지 않을까?

• 스프링의 DI는 객체의 생성과 관계 설정에 대한 제어권한을 오브젝트에서 제거하고 외부로 위임했다는 IoC라는 개념을 포괄한다.
• 그런 의미에서 인터페이스가 아닌 클래스를 주입했더라도 DI의 기본을 따르고 있다고 이야기할 수 있다.

어떤 경우에 인터페이스가 아닌 클래스를 DI 구조로 괜찮은걸까?

1. 싱글톤으로 등록되어 여러 오브젝트에서 공유해 사용되는 것이 이상적일 때
2. 클래스가 DI를 통해 다른 빈에 의존하고 있는 경우, 오브젝트를 주입받기 위해서라도 마찬가지로 빈으로 등록되어야 한다.

→ 다만, 클래스를 바로 사용하는 코드 구성은 가장 마지막 단계에서 고려해야 한다..

3.5 템플릿/콜백 패턴

• 템플릿: 전략 패턴의 컨텍스트를 의미한다. → 고정되는 틀의 로직
• 콜백: 익명 내부 클래스로 만들어지는 오브젝트를 의미한다. → 템플릿 안에서 호출되는 것을 목적으로 한다.

3.5. 1 탬플릿/콜백의 동작원리

탬플릿/콜백의 특징

• 탬플릿/콜백 패턴의 콜백은 보통 단일 메소드 인터페이스를 사용한다.
  • 탬플릿의 작업 흐름 중 특정 기능을 위해 한 번 호출되는 경우가 일반적이기 때문
  • ex) DB connection
  • 즉, 콜백은 일반적으로 하나의 메서드를 가진 인터페이스를 구현한 익명 내부 클래스로 만들어진다고 보면 된다.

탬블릭/콜백의 작업 흐름

• 클라이언트의 역할은 탬플릿 안에서 실행될 로직을 담은 콜백 오브젝트를 만들고, 콜백이 참조할 정보를 제공하는 것이다. 만들어진 콜백은 클라이언트가 탬플릿의 메소드를 호출할 때 파라미터로 전달된다.
• 탬플릿은 정해진 작업 흐름대로 작업을 진행하다가 내부에서 생성한 참조정보를 가지고 콜백 오브젝트의 메소드를 호출한다.
• 콜백은 클라이언트 메소드에 있는 정보 + 탬플릿이 제공한 참조정보를 이용해서 작업을 수행하고, 그 결과를 다시 탬플릿에 돌려준다.
• 탬플릿은 콜백이 돌려준 정보를 사용해 작업을 마저 진행한다. 경우에 따라서는 최종 결과를 다시 클라이언트에 돌려주기도 한다.
• 이러한 작업 흐름의 특징
  • 매번 메서드 단위로 사용할 오브젝트를 새롭게 전달받는다.
  • 콜백 오브젝트가 내부 클래스로서 자신을 생성한 클라이언트 메서드 내의 정보를 직접 참조한다.
  • 클라이언트와 콜백이 강하게 결합된다.

-> 탬플릿/콜백은 전략패턴 + DI의 장점을 익명 내부 클래스 사용 전략과 결합한 독특한 활용법이다. 이를 하나의 고유한 디자인 패턴으로 기억해두면 편리하다.

2장 테스트

💬 스프링이 개발자에게 제공하는 가장 중요한 가치가 무엇이냐고 질문한다면 나는 주저하지 않고 객체지향과 테스트라고 대답할 것이다.

2.1 UserDaoTest 다시 보기

작은 단위의 테스트 (Unit Test)

• 테스트는 가능하면 작은 단위로 쪼개서 집중해서 할 수 있어야 한다. 관심사의 분리가 여기에도 적용된다.

  • 사용할 DB의 상태를 테스트가 관장하고 있다면 → 단위 테스트 O
  • DB의 상태가 매번 달라지고, 테스트를 위해 DB를 특정 상태로 만들어줄 수 없다면 → 단위 테스트 X

• 단위 테스트가 필요한 이유

  • 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위함

2.2 UserDaoTest 개선

💬 켄트 벡, “테스트란 개발자가 마음 편하게 잠자리에 들 수 있게 해주는 것”

테스트 메소드 전환

• 테스트 메소드는 JUnit 프레임워크가 요구하는 조건 두 가지를 따라야 한다.

  1. 메소드가 public으로 선언되어야 한다.

  2. 메소드에 @Test라는 어노테이션을 붙인다.

     (+리턴값이 void형이고 파라미터가 없어야 한다.)

검증 코드 전환

• 기존의 테스트 코드

    if (!user.getName().equals(user2.getName())) { ... }

• JUnit의 스태틱 메소드 assertThat을 이용한 테스트 코드

    assertThat(user2.getName(), is(user.getName()));

  • is()는 matcher의 일종으로, equals()로 비교해주는 기능을 가진다. 첫 번째 파라미터를 매처와 비교해서 일치하면 다음으로 넘어가고, 아니면 테스트가 실패한다.

2.3 개발자를 위한 테스팅 프레임워크 JUnit

JUnit은 특정한 테스트 메소드의 실행 순서를 보장해주지 않는다.

모든 테스트는 실행 순서에 상관없이 독립적으로 항상 동일한 결과를 낼 수 있도록 해야 한다.

예외조건에 대한 테스트

• 예외 던지기

  • 테스트 중에 예외가 던져지면 테스트 메소드의 실행은 중단되고 테스트는 실패한다.
  • 예외 발생 여부는 메소드를 실행해서 리턴 값을 비교하는 방법으로 확인할 수 없다. 즉, assertThat()메소드로는 검증이 불가능하다.

• JUnit의 예외 테스트 기능을 이용하면 예외조건을 보다 쉽게 검증할 수 있다.

    // 테스트 중에 발생할 것으로 기대하는 예외 클래스를 지정해준다. 
    @Test(expected=EmptyResultDataAccessException.class)

포괄적인 테스트

💬 로드 존슨, “항상 네거티브 테스트를 먼저 만들라”

• 테스트를 작성할 때 부정적인 케이스를 먼저 만드는 습관을 들이는 게 좋다.
• 예외 케이스를 확인할 수 있는 테스트를 먼저 만들려고 한다면 이 예외적인 상황을 빠뜨리지 않는 꼼꼼한 개발을 할 수 있게 된다.

기능설계를 위한 테스트

• 테스트 코드는 마치 잘 작성된 하나의 기능정의서처럼 보인다.
  • 조건: 어떤 조건을 가지고
  • 행위: 무엇을 할 때
  • 결과: 어떤 결과가 나온다

테스트 주도 개발, Test Driven Development

💬 만들고자 하는 기능의 내용을 담고 있으면서 만들어진 코드를 검증도 해줄 수 있도록 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발

• “실패한 테스트를 성공시키기 위한 목적이 아닌 코드를 만들지 않는 것”이 기본원칙
• 머릿속에서 진행되는 테스트는 제약이 심하고, 오류가 많고, 나중에 다시 반복하기가 힘들다. 차라리 머릿속에서 복잡하게 진행하던 작업을 실제 코드로 끄집어 놓으면 그게 바로 TDD가 된다.

→ (정원용 멘토님) 개발 초반에 TDD를 하게 되면 코드를 변경하거나 리팩터링 해야할때 테스트코드가 망가진다는 생각에 코드 수정을 망설이게 될 수 있다…

JUnit이 테스트를 수행하는 방식

1. 테스트 클래스에서 @Test가 붙은 public이고 void형이며 파라미터가 없는 테스트 메소드를 모두 찾는다.

2. 테스트 클래스의 오브젝트를 하나 만든다.

   • 왜 매번 새로운 오브젝트를 만들까?

     💁 각 테스트가 서로 영향을 주지 않고 독립적으로 실행됨을 확실히 보장해주기 위해서 매번 새로운 오브젝트를 만든다.

3. @Before가 붙은 메소드가 있으면 실행한다.

4. @Test가 붙은 메소드를 하나 호출하고 테스트 결과를 저장해둔다.

5. @After가 붙은 메소드가 있으면 실행한다.

6. 나머지 테스트 메소드에 대해 2~5번을 반복한다.

7. 모든 테스트의 결과를 종합해서 돌려준다.

픽스처

💬 테스트를 수행하는 데 필요한 정보나 오브젝트를 말한다. 일반적으로 픽스처는 여러 테스트에서 반복적으로 사용되므로 @Before 메소드를 이용해 생성해두면 편리하다.

2.4 스프링 테스트 적용

@BeforeClass 스태틱 메소드

테스트 클래스 전체에 걸쳐 딱 한번만 실행된다.

여러 테스트가 함께 참조할 애플리케이션 컨텍스트를 오브젝트 레벨에 저장해두면 곤란하므로, 스태틱 필드에 애플리케이션 컨텍스트를 저장해두는 방식을 고민해볼 수 있다.

• 애플리케이션 컨텍스트를 오브젝트 레벨이 저장하게 되면 생기는 문제들
  • 빈이 많아지면 애플리케이션 컨텍스트 생성에 적지 않은 시간이 소요된다.
  • 애플리케이션 컨텍스트가 만들어질 때 모든 싱글톤 빈 오브젝트를 초기화하는데 이때도 상당한 시간을 필요로 한다.
  • 어떤 빈은 많은 리소스를 필요로하거나 독립적인 스레드를 띄우기도 하는데, 테스트를 마칠 때 애플리케이션 컨텍스트 내의 빈이 할당한 리소스를 release해주지 않으면 다음 테스트에 문제가 생길 수도 있다.

하지만 스프링이 직접 제공하는 애플리케이션 컨텍스트 테스트 지원 기능을 사용하는게 더 편리하다!

스프링 테스트 컨텍스트 프레임워크 적용

• ApplicationContext 타입의 인스턴스 변수를 선언하고 @AutoWired 어노테이션을 붙인다.

• 클래스 레벨에 @RunWith 어노테이션을 붙여 JUnit 확장기능을 지정한다.

• 클래스 레벨에 @ContextConfiguration 어노테이션을 붙여 테스트 컨텍스트가 자동으로 만들어줄 애플리케이션 컨텍스트의 위치를 지정한다.

  → 같은 설정파일을 가진 애플리케이션 컨텍스트를 사용하면, 테스트 클래스 사이에서도 애플리케이션 컨텍스트를 공유할 수 있다. (성능 대폭 향상)

@AutoWired

• 타입에 의한 자동 와이어링
  • AutoWired가 붙은 변수 타입과 일치하는 컨텍스트 내의 빈을 찾고, 타입이 일치하는 빈이 있으면 인스턴스 변수에 주입해준다. 이때 생성자나 수정자 메소드가 없어도 주입이 가능하다.
  • 단, 같은 타입의 빈이 두 개 이상 있는 경우에는 타입만으로 어떤 빈을 가져올지 결정할 수 없기 때문에 변수 이름과 같은 이름의 빈이 주입된다.
  • 변수 이름으로도 빈을 찾을 수 없다면 예외가 발생한다.

DI와 테스트

❓ 구현 클래스를 절대 바꾸지 않을 경우에도 굳이 인터페이스를 사용하고 DI를 통해 주입해주는 방식을 이용해야 하는가? → 🙆‍♀️

1. 소프트웨어 개발에서 절대로 바뀌지 않는 것은 없다.
2. 인터페이스를 두고 DI를 적용하게 해두면 다른 차원의 서비스 기능을 도입할 수 있다.
3. DI는 테스트가 작은 단위의 대상에 대해 독립적으로 만들어지고 실행되게 하는 데 중요한 역할을 한다.

테스트 코드에 의한 DI

• 테스트에서 운영용 DB를 사용하는 것은 위험할 수 있다.

• 테스트 코드에 의한 DI를 이용해서 테스트 중에 DAO가 사용할 DataSource 오브젝트를 바꿔주면 된다.

    @DirtiesContext  -> 테스트 메소드에서 애플리케이션 컨텍스트의 구성이나 상태를 변경
    public class UserDatTest {
        @Autowired
        UserDao dao;
  
        @Before
        public void setUp() {
            DataSource dataSource = new SingleConnectionDataSource(
                "jdbc:mysql://localhost/testdb", "spring", "book", true);
                dao.setDataSource(dataSource); // -> 코드에 의한 수동 DI
        }

  • 장점

    • 설정파일을 수정하지 않고도 테스트 코드를 통해 오브젝트 관계를 재구성할 수 있음
    • 예외상황을 만들고자 일부러 엉뚱한 오브젝트를 넣거나, 테스트용오르 준비된 오브젝트를 사용하게끔 할 수 있음

  • @DirtiesContext

    • 이 어노테이션이 붙은 클래스에는 애플리케이션 컨텍스트 공유를 허용하지 않으므로, 테스트 중에 변경한 컨텍스트가 뒤의 테스트에 영향을 주지 않는다.

    • 이 어노테이션이 붙어있는 클래스나 메서드에서 애플리케이션 컨텍스트를 새로 만들고, 실행이 끝나고 나면 해당 컨텍스트는 폐기하고 다시 새로운 애플리케이션 컨텍스트가 만들어진다.

      → 아무래도 찜찜하므로, 그냥 테스트용 설정 파일을 따로 만드는게 낫다! 번거롭게 수동 DI 하거나 위의 어노테이션을 달아줄 필요가 없어짐 👍

컨테이너 없는 DI 테스트

• 애플리케이션 컨텍스트를 사용하지 않고 직접 오브젝트를 만들고 수동 DI 해준다.
• 이 방법은 테스트 수행 속도가 가장 빠르고, 테스트가 간결해지므로 테스트 방법을 선택할 때 컨테이너 없이 테스트할 수 있는 방법을 최우선적으로 고려한다.

2.5 학습 테스트로 배우는 스프링

💬 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리에 대해 작성하는 테스트를 학습테스트라고 한다. 테스트이지만 기능 검증이 목적이 아니며, 기술이나 기능을 자신이 얼마나 제대로 이해하고 있는지를 검증하는 것이 목적이다.

학습 테스트의 장점

• 다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있다.
• 학습 테스트 코드를 개발 중에 참고할 수 있다.
• 프레임워크나 제품을 업그레이드할 때 호환성 검증을 도와준다.

스프링 배포판의 압축을 풀어보면 프레임워크 소스코드와 함께 테스트 코드를 살펴볼 수 있다 → 좋은 공부자료

테스트 검증 방법

1. assertThat(param, matcher)
2. assertTrue(param)
3. assertThat(param, either(is(nullValue())).or(is(this.context))));

버그 테스트

💬 버그 테스트란 코드에 오류가 있을 때 그 오류를 가장 잘 드러내줄 수 있는 테스트를 말한다. 버그 테스트는 일단 실패하도록 만들고, 이후에 버그 테스트가 성공할 수 있도록 애플리케이션 코드를 수정한다.

• 테스트의 완성도를 높여준다.
• 버그의 내용을 명확하게 분석하게 해준다.
• 기술적인 문제를 해결하는 데 도움이 된다.

스프링이 가장 관심을 많이 두는 대상은 오브젝트다. 스프링을 이해하려면 먼저 오브젝트에 깊은 관심을 가져야 한다. 애플리케이션에서 오브젝트가 생성되고 다른 오브젝트와 관계를 맺고, 사용되고, 소멸하기까지의 전 과정을 진지하게 생각해볼 필요가 있다.

POJO 프로그래밍

💬 스프링은 자바의 기술이 복잡해지면서 잃어버린 객체지향 언어의 본질과 장점을 되살릴 수 있도록 도와주는 도구이다. 스프링은 가장 단순한 객체지향적인 개발 모델, POJO 프로그래밍을 주장한다.

진정한 POJO란,

• 객체지향적인 원리에 충실하면서
• 특정 환경과 기술에 종속되지 않고
• 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

공통 프로그래밍 모델

1. IoC/DI 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델이다. 유연하고 확장성이 뛰어난 코드를 만들 수 있게 도와주는 객체지향 설계 원칙과 디자인 패턴의 핵심 원리를 담고 있으며 스프링 프레임워크의 근간이 된다.

2. PSA (서비스 추상화)

   구체적인 기술과 환경에 종속되지 않도록 유연한 추상 계층을 두어 이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있게 된다.

3. AOP

   애플리케이션 코드에서 부가적인 기능을 독립적으로 모듈화하는 프로그래밍 모델이다.

1.1 초난감 DAO

💁 DAO(Data Access Object)는 DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.

💬 사용자 정보를 저장할 때는 자바빈 규약을 따르는 오브젝트를 이용하면 편리하다.

✅ 자바빈 규약의 규칙

1. 자바빈은 기본 패키지 이외의 특정 패키지에 속해 있어야 한다.

2. 기본 생성자가 존재해야 한다.

3. 멤버변수의 접근제어자는 private로 선언되어야 한다.

4. 멤버변수에 접근 가능한 getter와 setter 메서드가 존재해야 한다. (3번의 규칙을 지키기 위함)

5. getter와 setter는 접근제한자가 public으로 선언되어야 한다.

6. 직렬화 되어 있어야 한다. (선택사항)

   • 직렬화란? 참고 링크

     • Serialize, 직렬화를 위한 인터페이스로 객체를 파일에 저장하거나, 다른 서버로 보내거나 받거나 등의 일을 하기 위해 구현한다.

     • 자바 객체를 serialize하기 위해서는, java.io.Serializable 인터페이스를 구현하도록 한다. 해당 인터페이스는 멤버변수나 메서드가 존재하지 않는 maker interface이다.

     • Serialization 특징

     1. 부모 클래스가 Serializable 인터페이스를 구현하면 자식 클래스는 자동으로 Serializable하다.

     2. non-static 변수만 Serialization으로 저장될 수 있다.

     3. 보안 등의 이유로 어떤 멤버 변수가 Serialization되지 않기를 원한다면 해당 데이터를 transient 데이터로 지정하도록 한다.

        class Member implements Serializable {
           transient String password;
           String name;
           ...
        }

     4. 해당 객체가 deserialized 될 때 해당 객체의 생성자는 호출되지 않는다.

     5. Serializable한 객체와 연관되어 있는 객체 또한 Serializable 인터페이스를 반드시 구현해야 한다.

        class ObjectA implements Serializable {  
           //ObjectB는 반드시 Serializable을 구현해야 함  
           ObjectB oj = new ObjectB();
        }

        Serializable을 implement하여 직렬화가 가능하다. 해당 객체에 영속성을 부여하기 위해서 사용되는 매커니즘이다.

   • marker interface란? 참고 링크

     💁 인터페이스 내부에 아무 것도 없는 인터페이스로, 객체의 타입과 관련된 정보를 제공해 준다. 컴파일러와 JVM은 이 마커 인터페이스를 통해 객체에 대한 추가적인 정보를 얻을 수 있다.

     • ❓객체의 타입과 관련된 정보를 제공해준다 NotSerializableException

       import java.io.*;
       
       public class MarkerInterfaceTest {
          public void serializableTest() throws IOException {
              File f = new File("test.txt");
              ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream(f));
       
              // 이 부분이 객체를 파일로 저장하는 부분
              objectOutputStream.writeObject(new SomeObject("kjhoon", "kjhoon0330@snu.ac.kr"));
          }
       
          public static void main(String[] args) {
              MarkerInterfaceTest t = new MarkerInterfaceTest();
              try {
                  t.serializableTest();
              } catch (Exception e) {
                  e.printStackTrace();
              }
          }
       }
       
       // 인터페이스를 구현하지 않은 임의의 오브젝트
       class SomeObject {
          private String name;
          private String email;
       
          public SomeObject(String name, String email) {
              this.name = name;
              this.email = email;
          }
       }

       • 해결 방법

         class SomeObject implements Serializable {
         // Serializlble 인터페이스 구현
         // 내부 생략
         }

       • 해결된 이유 아래 사진은 ObjectOutputStream의 writeObject 함수 내부를 보여준다. obj가 Serializable의 인스턴스인 경우 NotSerializableException이 발생되지 않도록 처리하고 있다. 이는 Serializable이라는 마커 인터페이스가 객체에 추가적인 정보를 주입시키고 있음을 이야기한다.
       

1.2 DAO의 분리

개발자가 객체를 설계할 때 가장 염두에 둬야 할 사항은 바로 미래의 변화를 어떻게 대비할 것인가이다. 객체지향 설계와 프로그래밍이 이전의 절차적 프로그래밍 패러다임에 비해 초기에 좀 더 많은, 번거로운 작업을 요구하는 이유는 객체지향 기술 자체가 지니는, 변화에 효과적으로 대처할 수 있다는 기술적인 특징 때문이다.

💁 템플릿 메소드 패턴

• 슈퍼클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 protected 메소드 등으로 만든다.
• 서브클래스에서는 추상 메소드를 구현하거나, 훅 메소드를 오버라이드하는 방법을 이용해 기능의 일부를 확장한다.
  • 슈퍼클래스에서 디폴트 기능을 정의해두거나 비워뒀다가 서브클래스에서 선택적으로 오버라이드할 수 있도록 만들어둔 메소드를 말한다.

💁 팩토리 메소드 패턴

• 서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 방법
• 주로 인터페이스 타입으로 오브젝트를 리턴하므로 서브클래스에서 정확히 어떤 클래스의 오브젝트를 만들어 리턴할지는 슈퍼클래스에서는 알지 못하며 관심도 없다.

💆‍ 관심사의 분리가 가능해졌지만, 상속을 사용하는 단점이 존재한다.

• 상속을 통한 상하위 클래스의 관계는 생각보다 밀접하다.
• 서브클래스는 슈퍼클래스의 기능을 직접 사용할 수 있다. 즉, 슈퍼클래스 내부의 변경이 있을 때 모든 서브클래스를 함께 수정하거나 다시 개발해야 할 수도 있다.

*디자인 패턴을 공부할 땐, 패턴을 적용할 상황, 해결해야 할 문제, 솔루션의 구조와 각 요소의 역할과 함께 핵심 의도가 무엇인지를 기억해둬야 한다.

1.3 DAO의 확장

1.3.1 클래스의 분리

상속을 사용하는 방식 대신, 관심사가 다른 두 부분을 클래스로 분리한다. 다만 이 경우 아래의 문제가 재차 발생한다.

-> 하나의 클래스가 다른 클래스와 그 코드에 종속적이면 자유로운 확장이 힘들다. 어떤 클래스에서 어떤 메서드를 가져와야하는지 일일이 지정하지 않아도 괜찮을 순 없을까?

1.3.3 관계설정 책임의 분리

• 클래스 사이에 존재하는 불필요한 의존관계를 끊어내자.
• 어떤 클래스를 사용할 것인지는 클라이언트의 책임으로 전가해서 런타임 시점에 다이내믹한 오브젝트 관계를 가지게끔 하는 것이다.

1.3.4 원칙과 패턴

개방 폐쇄 원칙

• 클래스나 모듈은 얼마든지 기능을 확장할 수 있다. (확장에는 열려있고,)
• 동시에 자신의 핵심 기능을 구현한 코드는 그런 변화에 영향을 받지 않고 유지할 수 있다. (변경에는 닫혀있음을 의미)

높은 응집도와 낮은 결합도

• 응집도가 높다는 건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻이다.
• 책임과 관심사가 다른 오브젝트 또는 모듈과는 낮은 결합도, 즉 느슨하게 연결된 형태를 유지하는 것이 바람직하다.

1.4 제어의 역전(IoC, Inversion Of Control)

팩토리

• 객체의 생성 방법을 결정하고 생성한 오브젝트를 돌려주는 일을 하는 오브젝트
• 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 깔끔하게 분리하려는 목적으로 사용한다

제어권의 이전을 통한 제어관계 역전

• 제어의 역전에서는 프레임워크 또는 컨테이너와 같이 애플리케이션 컴포넌트의 생성과 관계설정, 사용, 생명주기 관리 등을 관장하는 존재가 필요하다.

  → 교재에서의 예시: DaoFactory

1.5 스프링의 IoC

💬 스프링의 핵심을 담당하는 건, 바로 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것이다. 이 두가지는 우리가 만든 DaoFactory가 하는 일을 좀 더 일반화한 것이라고 설명할 수 있다.

애플리케이션 컨텍스트와 설정정보

빈, Bean

• 오브젝트 단위의 애플리케이션 컴포넌트
• 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트
• 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트

빈 팩토리, Bean Factory

• 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트
• IoC의 기본 기능에 초점을 맞췄을 때 주로 빈 팩토리라는 용어를 사용한다.

애플리케이션 컨텍스트

• IoC 방식을 따라 만들어진 일종의 빈 팩토리
• 애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC엔진이라는 의미가 좀 더 부각된다.

애플리케이션 컨텍스트가 IoC 방식의 기능을 제공할 때 사용할 설정정보

@Configuration
public class DaoFactory {
    @Bean
    public UserDao userDao() {
        return new UserDao(connectionMaker());
    }

    @Bean
    public ConnectionMaker connectionMaker(){
        return new DConnectionMaker();
    }
}

• @Configuration 어노테이션
  • 스프링이 빈 팩토리를 위한 오브젝트 설정을 담당하는 클래스라고 인식한다.
  • 애플리케이션 컨택스트가 활용하는 IoC 설정정보이다.
• @Bean 어노테이션
  • 오브젝트를 만들어주는 메소드에 해당 어노테이션을 붙인다.

public class UserDaoTest {
    public static void main(String[] args) throws ClassNotFoundException, 
                 SQLException {
            ApplicationContext context = 
                new AnnotationConfigApplicationContext(DaoFactory.class);
            UserDao dao = context.getBean("userDao", UserDao.class);
            ...
}

• getBean()의 첫 번째 파라미터, “userDao”
  • DaoFactory에서 @Bean 어노테이션을 userDao 이름의 메소드에 붙였기 때문에, 이 메소드 이름이 바로 빈의 이름이 된다.
  • userDao라는 이름의 빈을 가져온다는 것은 DaoFactory의 userDao() 메소드를 호출해서 그 결과를 가져온다고 생각하면 된다.
• getBean()의 두 번째 파라미터
  • getBean()은 기본적으로 Object 타입을 리턴하기 때문에 매번 오브젝트를 다시 캐스팅해줘야 하는 부담이 있다.
  • 자바 5 이상의 제네릭 메소드 방식을 사용해 getBean()의 두 번째 파라미터에 리턴 타입을 주면 캐스팅 코드를 추가로 작성하지 않아도 된다.

1.6 싱글톤 레지스트리와 오브젝트 스코프

오브젝트의 동일성과 동등성

• 동일성 == 연산자
• 동등성 equals() 메서드
  • 두 개의 각기 다른 오브젝트의 정보가 동등한 경우를 말한다.
    • 동일한 오브젝트는 동등하지만, 그 반대는 항상 참은 아니다.
  • 단, Object의 equals() 메서드는 두 오브젝트이 동일성을 비교한다.

스프링 컨텍스트로부터 가져온 오브젝트는 매번 동일한 값을 돌려준다.

1.6.1 싱글톤 레지스트리로서의 애플리케이션 컨텍스트

애플리케이션 컨텍스는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이다.

왜 스프링은 싱글톤으로 빈을 만들까?

• 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문이다.
• 매번 클라이언트에서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다고 하면 부하가 매우 클 것이고, 서버가 감당하기는 힘들어진다.
• 이런 이유로 서블릿은 서비스 오브젝트로, 대부분 멀티스레드 환경에서 싱글톤으로 동작한다. 서블릿 클래스당 하나의 오브젝트만 만들어두고, 사용자의 요청을 담당하는 여러 스레드에서 하나의 오브젝트를 공유해 동시에 사용한다.

싱글톤 패턴의 한계

• 생성자는 private으로 제한되기 때문에 다른 생성자가 없다면 상속이 불가하다.
  • 객체지향의 장점인 상속과 이를 이용한 다형성을 적용할 수 없고, 객체지향적인 설계의 장점을 적용하기 어렵게 만든다.
• 싱글톤은 테스트하기 어렵다.
  • 싱글톤은 만들어지는 방식이 제한적이므로 테스트에서 목 오브젝트로 대체하기 힘들다.
  • 생성자를 통해 사용할 오브젝트를 다이내믹하게 주입하기도 어렵다.
• 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.
  • 서버에서 클래스 로더를 어떻게 구성하냐에 따라 하나 이상의 오브젝트가 만들어질 수 있다.
    • 여러 개의 JVM에 분산돼서 설치되는 경우에도 각각 독립적으로 오브젝트가 생기므로 싱글톤으로서의 가치가 떨어진다.
• 싱글톤의 사용은 전역 상태를 만들 수 있다.

대신 스프링은 싱글톤 레지스트리를 제공한다

• 자바의 기본적인 싱글톤 구현 패턴 방식의 단점을 극복하기 위해, 스프링이 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.
• 스태틱 메서드와 private 생성자를 사용하지 않아도 평범한 자바 클래스를 싱글톤으로 활용할 수 있게 된다.

1.6.2 싱글톤과 오브젝트의 상태

싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않은 무상태 방식으로 만들어져야 한다.

• 상태가 없는 방식으로 클래스를 만들면서 각 요청에 대한 정보를 다루기 위해서는 파라미터와 로컬 변수, 리턴 값 등을 이용하면 된다.
• 메소드 파라미터나, 메소드 안에서 생성되는 로컬 변수는 매번 새로운 값을 저장할 독립적인 공간이 만들어지기 때문에 싱글톤이라고 해도 여러 스레드가 변수의 값을 덮어쓸 일이 없다.

읽기 전용 속성의 정보라면 싱글톤에서 인스턴스 변수로 사용해도 좋다. 물론 단순한 읽기전용 값이라면 static final 이나 final로 선언하는 편이 낫다.

• static final
  • 클래스의 모든 인스턴스에 대해 동일한 값을 갖는다.
• final
  • 개별 인스턴스마다 고유의 값을 갖는다.
  • 인스턴스는 new로 힙에 새로 생성될 때 각 인스턴스에서 설정한 값으로 초기화되기 떄문이다.

https://www.acmicpc.net/problem/2800

아래 예제와 같이 올바른 괄호 쌍을 제거해서 나올 수 있는 서로 다른 식을 사전순으로 출력하는 문제이다.

풀이 과정

올바른 괄호쌍을 제거하는건 Stack 자료구조를 사용하면 간단히 해결할 수 있다. 문제는 괄호 쌍을 제거해서 나올 수 있는 서로 다른 식을 어떻게 구하느냐였다.

예제 출력 3을 보면 규칙을 파악할 수 있는데, 괄호가 하나 제거된 경우 -> 두 개 제거된 경우 -> 세 개 제거된 경우 순으로 출력된다.

이때 조합을 사용하면 괄호쌍을 제거해서 나올 수 있는 서로 다른 식을 하나도 빠짐없이 구할 수 있다는 것을 알 수 있다.

풀이

조만간 Ruby로 라이브 코딩테스트가 예정되어 있는 관계로 이번 풀이는 루비로 진행해보았다.

• count

  • 입력받은 수식에 존재하는 괄호쌍의 개수를 의미한다.

• findPair()

  • 입력받은 수식에서 알맞은 괄호쌍들을 찾아낸다.
  • Stack 자료구조의 특성을 활용했다.

• combination 활용부

  • findPair()에서 찾아낸 괄호쌍들에 대해, 1부터 count 까지의 개수만큼 조합을 구한다.
  • 아래처럼 알맞은 괄호쌍들의 인덱스가 조합으로 구성되어 있는 것을 확인할 수 있다.

    [[[6, 10]], 
    [[3, 11]], 
    [[0, 12]], 
    [[6, 10], [3, 11]], 
    [[6, 10], [0, 12]], 
    [[3, 11], [0, 12]], 
    [[6, 10], [3, 11], [0, 12]]]

• output()

  • 입력받은 수식에 대해서, 위 조합을 한줄씩 순회하며 괄호쌍과 일치하는 인덱스이면 pass하고, 일치하지 않으면 수식으로 출력하기 위해 result 배열에 저장한다.

• 사전순 정렬

  • 조합으로 구한 모든 수식은 result 배열에 담겨 있다.
  • 문제 출력 조건을 만족하기 위해, 이 배열을 정렬하는 과정이 필요하다.

def findPair(input)
  tmp = []
  stack = []

  for i in 0...input.length do
    if input[i] == "("
      tmp.push(i)
    elsif input[i] == ")"
      open = tmp.pop()
      close = i
      stack.push([open, close])
    end
  end
  return stack
end

def output(input, arr)
  result = []

  arr.each do |pair|
    idx = Array.new(input.length, 0)

    pair.each do |a, b|
      idx[a] = 1
      idx[b] = 1
    end

    ans = ""
    for i in 0...input.length do
      if idx[i] == 1
        next
      end
      ans += input[i]
    end
    result << ans
  end

  return result
end

input = gets.chomp
count = input.count("(")
stack = findPair(input)

comb = []
for i in 1..count do
  comb.concat(stack.combination(i).to_a)
end

result = output(input, comb)
result.uniq.sort.each {|result| puts result}

사담

조건문, 반복문 끝날 때마다 end 붙여줘야 되는거 진짜 열받는다..

문제

https://www.acmicpc.net/problem/7662

(요약)

• 삽입 명령 시, 우선순위 큐에 데이터를 삽입한다.
• 삭제 명령 시, 우선순위 큐에서 최소값 혹은 최대값 데이터를 삭제한다.
• 이때 Q에 적용할 연산의 개수를 나타내는 정수 k (k ≤ 1,000,000)

풀이 과정

처음엔 우선순위 큐를 하나만 가지고 운영하면서 최대값/최소값 명령에 따라 그때그때 최소힙/최대힙으로 변환하는 작업을 고려했다. 하지만 이 경우 최소힙/최대힙으로 재정렬하는 작업이 반복되어 비효율적이고, 시간제한도 지키기 힘들다.

따라서 힙 자체를 최소힙, 최대힙 두개로 운영하여 최소값 삭제 명령시 최소힙에서 heappop()을 호출, 최대값 삭제 명령시 최대힙에서 heappop()을 호출하는 방향으로 구현하고자 했다.

이때 최소힙과 최대힙의 동기화를 고려해야 한다. (최소힙에서 이미 삭제한 데이터를 최대힙에서 최대값으로 찾는 오류 방지 차원.. 그 반대도 마찬가지)

나는 deleted 리스트를 사용해 이미 삭제된 데이터인지 표시해두고, 힙에서 이미 삭제된 데이터는 제외하고 최대값/최소값을 판별할 수 있도록 아래와 같이 코드를 구성했다.

풀이

import sys
input = lambda: sys.stdin.readline().rstrip()
import heapq

t = int(input())
for _ in range(t):
    k = int(input())
    maxH = []
    minH = []
    deleted = [False] * k

    for i in range(k):
        comm = list(map(str, input().split()))
        c = comm[0]
        n = int(comm[1])

        if c == "I":
            heapq.heappush(maxH, (-n, i))
            heapq.heappush(minH, (n, i))

        else:
            if n == 1: #최대값 삭제
                while maxH and deleted[maxH[0][1]]:
                    heapq.heappop(maxH)
                if maxH:
                    deleted[maxH[0][1]] = True
                    heapq.heappop(maxH)
            else: #최소값 삭제
                while minH and deleted[minH[0][1]]:
                    heapq.heappop(minH)
                if minH:
                    deleted[minH[0][1]] = True
                    heapq.heappop(minH)

    while maxH and deleted[maxH[0][1]]:
        heapq.heappop(maxH)
    while minH and deleted[minH[0][1]]:
        heapq.heappop(minH)

    if maxH and minH:
        print(-maxH[0][0], minH[0][0])
    else:
        print("EMPTY")

번외

내장함수 min max를 사용하면 안될까?

(1) 의사코드

k = int(input())
h = []

for i in range(k):
    comm, n = input().split()

    if comm == "I": # (1) 데이터 삽입 
        h.append(n)

    else:
        if n == 1: 
            # (2) 최대값 삭제
            maxN = max(h)
            h.remove(maxN)
        else:
            # (3) 최소값 삭제
            minN = min(h)
            h.remove(minN)

• max(), min() 연산은 리스트를 순차 탐색하면서 최대값/최소값을 찾으므로 O(n)의 시간복잡도를 갖는다.
• remove() 연산은 리스트를 순차 탐색하면서 특정값을 삭제하므로 O(n)의 시간복잡도를 갖는다.

(2) 시간 복잡도 분석

• 삽입 명령: O(1)
• 삭제 명령: O(k*k)
  • 최대/최대값 탐색에 O(k)
  • 삭제 작업에 O(k) 소요
• 최악의 경우(k=1,000,000), O(1,000,000^2) = O(10^12) 연산이 필요
• 1초에 1억회 연산이라고 어림잡을 때 10,000초가 소요되어 시간초과

(3) 결론 당연히 안된다. (^^;)

https://www.acmicpc.net/problem/22859

풀이 과정

• 정규표현식으로 풀었다.
• 정규표현식에 익숙치 않아서 아래 링크들을 많이 참고하면서 공부하듯 품
  • 풀이 참고
  • 개념 참고

새로 배운 개념

.*? 사용법

• . : 모든 문자
• * : 0번 이상 반복
• ? : 비탐욕적 매칭 (가장 짧은 범위를 매칭)
  

.*와 .*?의 차이는 뭘까

<p>Text1</p><p>Text2</p>

• <p>.*</p> : (탐욕적 매칭) 최대 범위를 매칭한다.
  • <p>Text1</p><p>Text2</p> 가 전부 매칭된다.
• <p>.*?</p> : (비탐욕적 매칭) 최소 범위를 매칭한다.
  • <p>Text1</p&gt 까지만 매칭된다.

풀이

파이썬 풀이

import sys
import re
input = lambda: sys.stdin.readline().rstrip()

html = input()

# 1. main parsing
s = len('<main>')
e = len('</main>')
html = html[s : -e]

# 2. div parsing
html = re.sub(r'<div +title="([\w ]*)">', r'title : \1\n', html)
html = re.sub(r'</div>', '', html)

# 3. p parsing
html = re.sub(r'<p>(.*?)</p>', r'\1\n', html)

# 4. p parsing - 모든 태그 지우기
html = re.sub(r'<([\w /]*)>', '', html)

# 5. p parsing - 맨 앞, 맨 뒤 공백 제거
html = re.sub(r' ?\n ?', r'\n', html)

# 6. p parsing - 공백이 2번 이상 나타나면 하나로 대체
html = re.sub(r' {2,}', ' ', html)

print(html)

자바 풀이

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String html = br.readLine();

        // 1. main parser
        int s = "<main>".length();
        int e = "</main>".length();
        html = html.substring(s, html.length() - e);

        // 2. div parser
        html = html.replaceAll("<div +title=\"([\\w ]*)\">", "title : $1\n");
        html = html.replaceAll("</div>", "");

        // 3. p parser
        html = html.replaceAll("<p>(.*?)</p>", "$1\n");

        // 4. p parser - remove all tag
        html = html.replaceAll("<([\\w /]*)>", "");

        // 5. p parser - trim
        html = html.replaceAll(" ?\n ?", "\n");

        // 6. p parser - two space -> one space
        html = html.replaceAll(" {2,}", " ");

        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        bw.write(html);
        bw.flush();
        bw.close();
    }
}

도입기

우리에게 필요한 건 자동화된 모니터링 도구였다. 더 이상 배포가 잘 되었는지, 서버가 잘 돌아가고 있는지, 장애가 난 포인트는 없는지 등을 직접 확인하지 않아도 되게끔 만드는 것이 제일 중요했다. '무소식이 희소식이겠거니 ~' 하면서 있다가 모니터링 도구가 실시간으로 문제를 알려주면 우리는 빠르게 문제를 해결해서 사용자들이 안정적으로 서비스를 이용할 수 있도록 환경을 마련해야 했다! 이를 도와주는 자동화된 모니터링 도구로는 sentry, data dog, prometheus, cloud watch 등으로 매우 다양한데, 우린 그 중에서도 new relic을 사용하기로 했다. 사실 뉴렐릭은 sentry, cloud watch, prometheus 등에 비해서 레퍼런스가 굉장히 적기도 했고 올해 5월인가에는 뉴렐릭 한국 지사가 철수하기도 하는 등 '도입하지 않을' 이유가 더욱 많아보였다. 그럼에도 소수의 레퍼런스 자료에서(여기어때 기술블로그) 뉴렐릭의 만족도가 커 보여 한번쯤은 경험해보고 싶다는 생각이 들었고, 또 무엇보다 현재 활동 중인 소프트웨어 마에스트로의 담당 멘토님께서 뉴렐릭을 써볼 것을 강추❗️하셨기 때문에 그냥 믿고 써봐야겠다 싶었다.

✋ 들어가기 전에

모니터링에는 pull과 push 방식이 있다

뉴렐릭 연동 과정에 대한 마땅한 참고자료가 없었고 공식문서도 개인적으로는 이해하기에 부족한 점이 있었기 때문에 의존성만 설치하면 끝나는건지, 아님 배포 서버에서 뭔가를 더 설정해줘야 하는건지 기본적인 설정법조차 와닿지 않았다. 이제와서 돌아보니 이 '모니터링 방식'에 대한 개념이 부족해서 이리저리 헤맨 것 같다. 간단하게 설명하면 pull 방식의 경우 모니터링 도구가 메트릭을 자동으로 수집(pull)해서 에러 상황을 분석해주고, push 방식의 경우 코드 상에서 직접 특정 포인트에서 데이터가 수집되도록 설정해 보내야(push)한다. sentry가 대표적인 push 방식으로 동작하며 new relic의 경우 pull 방식으로 동작한다.

new relic이 pull 방식으로 동작하기 위해서는 애플리케이션을 실행할 때 new relic agent가 애플리케이션에 통합하도록 설정해주는 과정이 필요하다. 또한 애플리케이션이 실행 중일 때 뉴렐릭 에이전트도 같이 돌아가는 것이기 때문에, 새 버전을 배포하는 과정에서 기존에 돌아가던 애플리케이션을 kill 해버리면 뉴렐릭 에이전트도 더 이상 모니터링을 하지 못하게 된다. 따라서 새 버전을 배포할 때마다 new relic agent를 애플리케이션에 통합되도록 해줘야 한다.

뉴렐릭이 제공하는 기능

• 뉴렐릭은 APM 모니터링 기능에 매우 특화되어 있다. ~

학생용 뉴렐릭 사용하기

뉴렐릭은 상용 서비스로 돈을 내고 사용하게 되는데 사용량에 따라 가격이 매겨지고 이게 상당히 비싼 것으로 알려져있다. 공식 사이트에서는 사용한 만큼 비용을 지불하는 걸 큰 장점처럼 어필하고 있긴 한데, 사용자 입장에선 이게 더 폭력적으로(😅) 다가오긴 한다.

프라이싱 모델은 아래와 같이 구성되어있다. 무료버전으로 사용해도 괜찮을 것 같다는 생각이 들었는데, 럭키🍀하게도 학생의 경우 무료로 더 많은 혜택을 받을 수 있게끔 되어있었다. 애플리케이션 모니터링 + 인프라 모니터링 등 30개 기능을 이용할 수 있고, 매월 500GB의 데이터를 사용할 수 있고, 플랫폼 사용자도 3명까지 등록할 수 있다!! 다행히(?) 아직 대학생 신분이라 학생용 뉴렐릭 계정을 만들었다.

프로젝트에 통합하기

1. APM(Application Monitoring) - 언어 선택 자바로 개발중이라 모니터링 대상 언어는 자바로 선택했다.
2. 설치 방식 의존성을 추가할건지(gradle, maven), 아니면 운영중인 서버에 직접 설치할 건지(On a host) 선택하면 된다. 나의 경우에는 프로젝트에 의존성을 추가하는게 이후에 설정하거나 커스텀하기에 더 편할 것 같아 gradle을 선택했다.
3. 개발 환경 선택하기 linux, window 중에 선택하고 사용하고 있는 프레임워크를 선택하면 된다. 다음 단계에서 설정파일을 제공해주는데 거기에 사용되는 것 같다.
4. buil.gradle에 의존성 추가 아래 예시로 보여준 build.gradle을 복사해서 프로젝트 build.gradle에 추가한다. 내가 사용하는 버전에서는 조금 문법이 달라져 추가 수정이 필요했다.

   tasks.register('downloadNewrelic', Download) {
    mkdir 'newrelic'
    src 'https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic-java.zip'
    dest file('newrelic')
   }
   

tasks.register('unzipNewrelic', Copy) { from zipTree(file('newrelic/newrelic-java.zip')) into rootDir }

5. 설정파일(newrelic.yml) 세팅
4 단계를 거치고 나면 프로젝트의 루트 디렉터리에 newrelic 폴더가 생긴다. newrelic 폴더 안에 newrelic.yml 파일이 있는데 여기에 4의 화면에 보이는 newrelic.yml 코드를 그대로 복사해서 붙여넣으면 된다. 주의할 건 newrelic.yml에 `lisence_key`가 그대로 노출되어 있다는 건데, 이걸 환경변수로 등록해주는게 좋다.
![](https://velog.velcdn.com/images/yul_ee/post/12ffb03a-990b-4b61-9ea7-b0b7ed3a4a62/image.png)
6. 애플리케이션 실행 시 new relic agent를 통합
여기가 조금 헷갈렸는데, 처음에는 code deploy의 라이프 사이클 중 Application Start단계에서 new relic agent를 실행시키기 위한 스크립트를 하나 새로 생성해야 하는건가 싶었다. 결론적으로 그건 아니었고 배포 자동화가 이뤄지고 있는 경우에는 새 애플리케이션을 실행하는 스크립트를 아래 명령어로 보완만 해주면 됐다. (뉴렐릭이 어떻게 동작하는건지 이해가 부족했음)
![](https://velog.velcdn.com/images/yul_ee/post/a12a140f-e20e-4460-98f8-07268944ef17/image.png)
우리 서비스는 start.sh에 새 애플리케이션을 실행하는 스크립트를 짜뒀기 때문에 아래와 같이 start.sh을 보완했다. 
(기존)

nohup java -jar $JAR

  (보완)

nohup java -javaagent:$NEW_RELIC_JAR_FILE -jar $JAR

7. (optional) 인프라와 연동 
그 다음 과정부터는 선택적으로 진행하면 되는데 왜인지 모르게 계속 실패가 떠서 일단은 APM 모니터링 연동까지만 진행했다. 

</br>

## 짜잔
여기까지 진행하면 이제 아래와 같이 모니터링 내용을 확인할 수 있다. 사실 좋은 도구가 있어도 해석하는 능력이 없으면 무용지물인데 지금 좀 그런 기분이 든다.. 😓 이제는 어떻게 데이터를 해석할건지에 대한 공부를 해보고, 어떤 경우에 알림을 받을건지 정책을 정하기 위해서 또 이리저리 알아봐야 할 것 같다 ~! 
![](https://velog.velcdn.com/images/yul_ee/post/dec6e6af-626a-4c20-b5e6-955e9da022b0/image.png)

CodeDeploy 라이프 사이클

이번 배포가 실패한 로그를 분석하기 전에 CodeDeploy의 라이프 사이클을 이해하는 시간이 필요했다. CodeDeploy는 아래와 같은 순서로 이벤트 훅을 동작시켜 배포를 자동화해주고 있다. 이때 연하늘색으로 표시된 이벤트의 경우에는 해당 이벤트가 발생했을 때 어떤 훅을 동작시킬 것인지 appspec.yml에 유저가 커스텀하게 정의할 수 있도록 지원한다. 이 중 설명이 필요한 몇 가지에 이벤트에 대해서만 간단하게 언급하고자 한다.

• install 배포하려는 애플리케이션 파일 및 의존성을 EC2 인스턴스에 설치한다.
• AfterInstall 설치가 완료된 애플리케이션 파일을 실행시키기 전에 해야 하는 작업이 있다면 해당 단계에서 수행한다.
• ApplicationStart 애플리케이션을 실행하는 작업을 수행한다.

우리 서비스의 경우에는 아래와 같이 appspec.yml이 작성되어 있다.

hooks:
  AfterInstall:
    - location: scripts/stop.sh
      timeout: 60
      runas : root
  ApplicationStart:
    - location: scripts/start.sh
      timeout: 60
      runas : root

이때 AfterInstall 단계에서는 아래와 같이 작성한 stop.sh을 실행시켜 새 애플리케이션을 실행하기 전에 기존에 배포되어있는 애플리케이션의 프로세스를 kill하는 작업을 한다.

#!/bin/bash

ROOT_PATH="/home/ubuntu/freebe-backend"
JAR="$ROOT_PATH/application.jar"
STOP_LOG="$ROOT_PATH/stop.log"
SERVICE_PID=$(pgrep -f $JAR)

if [ -z "$SERVICE_PID" ]; then
  echo "서비스 NouFound" >> $STOP_LOG
else
  echo "서비스 종료 " >> $STOP_LOG
  kill "$SERVICE_PID"
fi

배포 실패 로그 분석하기

이번 배포실패 로그를 살펴보면 EC2 인스턴스에 애플리케이션 설치까지는 성공적으로 수행되었지만, AfterInstall 훅에서 stop.sh 스크립트를 실행하던 중 오류가 난 것을 확인할 수 있다.

stop.sh 스크립트 중에서 기존에 실행중이던 프로세스를 kill하는 과정에서 arguments must not be process or job IDs 로그가 찍힌 것을 보면 아마 kill 명령어와 관련해 문제가 발생하고 있는 것 같다.

실패 원인 가정하기

그렇다면 kill 명령어를 수행하는데 있어 발생할 수 있는 문제는 무엇이 있을까? 가장 먼저 떠올린 것은 권한 문제였다. 터미널에서 직접 kill 명령어를 수행하려고 하면 Operation not permitted가 출력되는 것을 확인할 수 있다.

왜냐하면 현재 내가 접속한 일반 사용자 계정으로는 root 권한으로 실행되는 application.jar 프로세스를 kill할 권한이 없기 때문이다. 이와 유사하게 CodeDeploy 에이전트에게도 root 권한이 없어서 kill 명령이 제한되고 있는 건 아닐까라는 생각을 하게 되었다. 하지만 확인해본 결과 CodeDeploy agent도 root 권한으로 실행되고 있었기 때문에 권한 문제는 아니었다.

그렇다면 kill 명령이 제대로 입력되지 않고 있는건 아닐까? 아래 stop.sh 스크립트를 다시 살펴보면 pgrep -f application.jar로 실행중인 프로세스를 SERVICE_PID 변수에 저장하고 kill $SERVICE_PID를 수행하게 되는데 SERVICE_PID에 pid가 제대로 저장되지 않고 있을 수 있다는 생각이 들었다.

#!/bin/bash

ROOT_PATH="/home/ubuntu/freebe-backend"
JAR="$ROOT_PATH/application.jar"
STOP_LOG="$ROOT_PATH/stop.log"
SERVICE_PID=$(pgrep -f $JAR)

if [ -z "$SERVICE_PID" ]; then
  echo "서비스 NouFound" >> $STOP_LOG
else
  echo "서비스 종료 " >> $STOP_LOG
  kill "$SERVICE_PID"
fi

그런데 터미널에서 직접 실행중인 프로세스를 찾아보니, 왜인지는 모르겠지만 application.jar 프로세스가 두 개가 돌아가고 있는 것을 발견할 수 있었다.

186470, 186551 두 프로세스가 시작된 시간을 확인해보니 9월 12일에 20분 간격을 두고 실행된 것을 확인할 수 있었는데, 두번째 프로그램이 배포된 이후부터 실행중인 프로세스가 두 개가 되면서 그 다음 배포 시도부터는 stop.sh이 여러 개의 프로세스를 kill하지 못하게 되어 배포에 실패한게 아닌가 라는 추측을 해보았다. 왜냐하면 기존 stop.sh 스크립트는 실행중인 프로세스가 하나인 경우를 가정하고 이미 존재하는 하나의 프로세스를 종료시키도록 작성되어 있기 때문이다.

그렇지만 스크립트 실행 자체가 실패하는 것은 이해가 가지 않았던 것이, 실행중인 프로세스가 여러개일 때 SERVICE_PID 변수에 기존에 실행중인 여러개의 프로세스 아이디가 공백으로 구분되어 저장되므로(ex: kill 186470 192838) kill 명령을 실행했을 때 가장 맨 앞에있는 프로세스(186470) 한개는 kill 되게끔 동작할 것이기 때문이다.

조치하기

이때까지는 정확한 실패 원인을 파악하지는 못했지만, 예상치 못하게 실행중인 프로세스가 두 개였기 때문에 이를 적절하게 처리하지 못해서 배포에 실패했을거라는 합리적 의심을 하게 되었다. 그래서 실행중인 프로세스가 여러개일 예외상황까지 고려해서 stop.sh에서 실행중인 모든 프로세스를 죽일 수 있도록 스크립트를 수정했다. 또 로그를 구체화 해서 앞으로는 어디서 오류가 났는지 쉽게 파악할 수 있도록 했다.

#!/bin/bash

ROOT_PATH="/home/ubuntu/freebe-backend"
JAR="$ROOT_PATH/application.jar"
STOP_LOG="$ROOT_PATH/stop.log"
NOW=$(date "+%Y %b %d %a %H:%M:%S")

echo "--------------------------------------------------" >> $STOP_LOG

# 실행 중인 모든 프로세스의 PID를 가져옴
SERVICE_PIDS=$(pgrep -f $JAR)

if [ -z "$SERVICE_PIDS" ]; then
  echo "[$NOW] 실행 중인 기존 프로세스 없음" >> $STOP_LOG
else
  echo "[$NOW] 기존 프로세스 종료 시도: PID $SERVICE_PIDS" >> $STOP_LOG

  for PID in $SERVICE_PIDS; do
    echo "[$NOW] kill $PID 실행 중" >> $STOP_LOG
    kill "$PID"
    sleep 1

    if kill -0 "$PID" 2>/dev/null; then
      echo "[$NOW] 프로세스 강제 종료 시도: PID $PID" >> $STOP_LOG
      kill -9 "$PID"
      echo "[$NOW] 프로세스 강제 종료됨: PID $PID" >> $STOP_LOG
    else
      echo "[$NOW] 프로세스가 성공적으로 종료됨: PID $PID" >> $STOP_LOG
    fi
  done
fi

이렇게 스크립트를 수정한 뒤에 다시 배포를 시도했더니 stop.log 파일에서 아래와 같이 스크립트 실행 과정을 트래킹할 수 있게 되었다. 여기서 주목해야 했던 것은 SERVICE_PID 변수에 pid 두개가 공백으로 구분되는 것이 아니라 개행으로 구분되고 있다는 점이었다.

[Sun Sep 22 16:39:48 2024] 기존 프로세스 종료 시도: PID 186470
260650
[Sun Sep 22 16:39:48 2024] kill 186470 실행 중
[Sun Sep 22 16:39:48 2024] 프로세스 강제 종료 시도: PID 186470
[Sun Sep 22 16:39:48 2024] kill 260650 실행 중
[Sun Sep 22 16:39:48 2024] 프로세스가 성공적으로 종료됨: PID 260650

즉, 기존의 stop.sh스크립트로는 kill 186470/n 26065 으로 실행되었기 때문에 명령 자체가 잘못 입력되어 arguments must be process or job IDs 오류가 나면서 그동안 배포에 실패하지 않았을까 싶다. 하지만 이번에 수정한 스크립트에서는 kill 명령을 수행할 때 for문을 돌면서 pid를 꺼내와 하나의 프로세스만 죽이게끔 동작하기 때문에 kill 명령어를 수행할 때 유사한 이슈가 발생하지 않을 것이다.

또한 이번처럼 두 개 이상의 프로세스가 동시에 실행되고 있는 예외 상황을 아예 만들지 않기 위해서 애플리케이션 실행을 담당하는 start.sh 스크립트도 아래와 같이 보완해보았다. stop.sh 스크립트가 예상대로 실행되지 않아서 새 애플리케이션을 실행하기 전에 기존에 존재하는 프로세스를 종료시키지 못했다면, 새 애플리케이션을 실행하지 않고 배포가 실패하게끔 유도하고 관련 로그를 start.log에 남기도록 해두었다.

#!/bin/bash

# 환경 변수 로드
set -o allexport
source /home/ubuntu/freebe-backend/.env
set +o allexport

# 경로 및 파일 설정
ROOT_PATH="/home/ubuntu/freebe-backend"
JAR="$ROOT_PATH/application.jar"

APP_LOG="$ROOT_PATH/application.log"
ERROR_LOG="$ROOT_PATH/error.log"
START_LOG="$ROOT_PATH/start.log"
NOW=$(date "+%Y %b %d %a %H:%M:%S")

echo "--------------------------------------------------" >> $START_LOG
SERVICE_PIDS=$(pgrep -f $JAR)

# 실행 중인 프로세스가 있는지 확인
if [ ! -z "$SERVICE_PIDS" ]; then
  echo "[$NOW] 이미 실행 중인 프로세스가 있습니다: PID $SERVICE_PIDS" >> $START_LOG
  exit 1 
fi

# JAR 파일 복사
echo "[$NOW] $JAR 복사 중..." >> $START_LOG
if cp $ROOT_PATH/build/libs/freebe-0.0.1-SNAPSHOT.jar $JAR; then
  echo "[$NOW] JAR 파일 복사 완료" >> $START_LOG
else
  echo "[$NOW] JAR 파일 복사 실패" >> $START_LOG
  exit 1
fi

# 애플리케이션 실행
echo "[$NOW] > $JAR 실행" >> $START_LOG
nohup java -jar $JAR > $APP_LOG 2> $ERROR_LOG &

# 실행된 프로세스의 PID 확인
NEW_SERVICE_PID=$(pgrep -f $JAR)
if [ ! -z "$NEW_SERVICE_PID" ]; then
  echo "[$NOW] > 새로운 서비스 PID: $NEW_SERVICE_PID" >> $START_LOG
else
  echo "[$NOW] > 서비스 시작 실패" >> $START_LOG
  exit 1
fi

이번엔 진짜 배포 성공

스크립트 수정이 이뤄진 다음부터는 계속해서 배포에 성공한 것을 확인할 수 있었다.🥹 문제를 해결하게 되어 기쁘지만, 한편으로는 앞으로 프로덕션 환경에서 유사한 상황이 발생할때는 어떻게 대처하는게 현명한 방법일지 고민이 된다. 또 앞으로는 배포가 실패할 때 이에 대한 알림을 빠르게 받아볼 수 있게끔 환경을 구축해야겠다는 생각도 든다 💭

'프리비' 서비스를 개발하는 과정에서 얼마전부터 계속 CodeDeploy를 이용한 배포가 실패하는 문제가 발생했다. 꽤 오래전부터 배포 실패가 계속되고 있었는데, 프론트엔드와 백엔드의 개발 속도가 다르다보니 로컬 테스트 위주로만 진행하고 배포환경에서 테스트를 소홀히해 문제 상황을 뒤늦게 인식하게 되었다. 😓

문제 분석

AWS CodeDeploy에 접속해 분석을 원하는 배포 ID를 클릭하면 해당 배포시도에 대한 세부 정보를 확인할 수 있고, 하단의 view events 버튼을 누르면 배포실패 원인에 대한 로그를 확인할 수 있다.

확인 결과 우리 서비스의 실패로그는 아래와 같았다. 배포를 시도했지만 ubuntu 서버 용량이 부족해 배포가 불가능했던 것이다.

No space left on device @ fptr_finalize_flush - /opt/codedeploy-agent/deployment-root/ongoing-deployment/d-YH9263EJ7

서버 용량 확인

실패 로그에서 서버 용량 부족이 문제임을 알려주고 있으므로, 이를 실제로 확인해 볼 필요가 있었다. /dev/root 파일을 보면 할당된 7.6GB의 서버 용량을 전부 사용해 Use 100%인 것을 확인할 수 있었는데, 실제로 용량 부족이 원인이 되어 배포에 실패했음을 추측할 수 있다🫠

문제가 되고 있는 /dev/root는 기본적으로 시스템 핵심 파일과 디렉토리들이 저장되는 공간으로, 실제 디렉토리는 아니고 루트 파티션을 참조하는 파일이다. 이 파일 시스템에는 다음과 같은 디렉토리들이 포함된다.

• /home: 사용자 데이터, 홈 디렉토리
• /var: 로그 파일, 캐시 파일 등
• /tmp: 임시 파일
• /opt: 추가 애플리케이션
• /usr: 시스템 프로그램, 라이브러리
• /etc: 시스템 설정 파일

즉, ubuntu 운영체제와 더불어 배포를 시도할때 설치되는 패키지, 로그, 배포파일 등 거의 모든 것이 저장되는 공간이다. 이 루트 파티션 전체의 용량이 부족한 것이기 때문에 용량 확보를 위해 불필요한 파일/디렉토리를 정리해주거나 아니면 서버 용량 자체를 늘려주는 방법을 생각할 수 있다.

서버 용량 확보

우선 불필요한 디렉토리나 파일을 삭제해 서버 용량을 확보하고자 했다. 용량이 큰 디렉토리 순서로 정렬해보았다.

용량이 큰 디렉토리 순서로 탐색하면서 불필요한 파일을 삭제하고자 했지만, 지우면 안될 파일과 지워도 되는 파일을 구분하기가 힘들었고 무엇보다 많은 파일을 삭제했음에도 확보한 용량이 0.1GB에 불과했다 🤣

sudo apt-get autoremove 명령어를 통해 불필요한 의존성 패키지를 제거해보기도 했지만 여전히 용량에 변동은 없었다..!

이렇게 하다가는 용량 확보하기가 너무 힘들 것 같아 아예 ec2 서버 용량을 늘리기로 했다. 현재는 기본 8GB 용량으로 설정되어 있는데, 우선 10GB로 조금만 늘려보기로 했다. 30GB까지가 프리티어로 지원되는데 현재 백엔드 서버 1개, 프론트엔드 서버 2개 각각에 8기가짜리 볼륨 3개가 이미 돌아가고 있기때문에 백엔드 서버 스토리지만 30으로 늘려버릴 수는 없었다.

1. AWS EC2 -> 좌측 탭의 볼륨 -> 늘리려는 볼륨 선택 -> 볼륨수정

2. 볼륨 크기 수정

3. (2)단계에서 볼륨 크기를 수정하고 확인버튼을 누르면 아래와 같은 알림창이 뜬다. 여기서 볼륨 크기를 늘리는 경우 파일 시스템을 볼륨의 새 크기로 확장해야 합니다 이 문장이 중요하다! 단순히 볼륨 크기를 늘리면 물리적인 디스크 공간은 늘어나지만, 아직 파일시스템은 이 늘어난 공간을 인식하지 못하기 때문에 이를 인식할 수 있도록 별도로 설정해주는 작업이 필요하다.

4. 파티션 확인 lsblk 명령어를 사용해 확장된 디바이스를 확인한다. 내 경우에는 nvme0n1 디스크의 nvme0n1p1 용량을 증가시켜야 한다.

5. 파티션 크기 조정 & 파일시스템 확장 파일시스템 확장 전에 /dev/root 파일시스템은 7.6GB 사이즈를 갖고있음을 확인할 수 있다.

   
   sudo growpart /dev/nvme0n1 1
   sudo resize2fs /dev/root
   
   

   위 명령어를 연속으로 입력해 파티션 크기를 조정하고 파일시스템 확장을 수행할 수 있다.

6. 확장된 파일시스템 확인 10GB로 디스크 용량이 증가되었고 사용 가능한 공간 2.1GB가 확보되었다!

예방책

이 외에도 예방책으로 서버에 과거 배포본을 저장해두는 최대 개수를 조정해두었다. Code deploy 에이전트는 디폴트로 최대 다섯 개의 배포본을 저장해두는데 프로젝트가 커질수록 이 배포본 하나 하나의 크기가 커지면서 서버 용량 부족 문제로 이어지는 경우가 많은 것 같았다. 이 설정을 수정하려면 /etc/codedeploy-agent/conf 경로의 codedeployagent.yml 파일의 max_revisions를 조정하면 되는데, 나는 5 -> 2로 수정해 최대 두 개의 배포본만 저장되게끔 했다.

설정을 변경할때 단순히 vi codedeployagent.yml로 편집기를 열어서 저장하려고 하면 쓰기 권한이 없어서 반영이 안되므로 sudo 키워드를 붙여야 한다! 그리고 이 설정을 반영하기 위해서는 아래 명령을 통해 codedeploy agent를 재실행해줘야 한다.

sudo service codedeploy-agent restart

배포 성공!

은 아직 못했다 ㅜㅜ .. 용량을 늘리고 재배포를 시도했지만 또 새로운 오류가 발생했다🥲 다음 문제도 손보고 나면 진짜 배포 되겠지..

문제 해결에 참고한 글

• https://prohannah.tistory.com/201
• https://coldpresso.tistory.com/5

6.6.1 트랜잭션 정의

• 트랜잭션이라고 모두 같은 방식으로 동작하는 것은 아님
• commit, rollback 외에도 트랜잭션의 동작 방식을 제어할 수 있는 몇 가지 조건이 있음

트랜잭션 전파

트랜잭션의 경계에서 이미 진행 중인 트랜잭션이 있을 때 또는 없을 때 어떻게 동작할 것인가를 결정

A의 트랜잭션이 시작되고 아직 끝나지 않은 시점에서 B를 호출했다면, B의 코드는 어떤 트랜잭션 안에서 동작해야 할까?

1. B의 코드는 A에서 이미 시작한 트랜잭션에 참여한다.

   → (2)의 코드를 진행하는 중에 예외가 발생하면 A, B코드에서 진행됐던 DB작업이 모두 취소됨

2. A와 무관하게 B를 독립적인 트랜잭션으로 만든다.

   → (2)의 코드를 진행하는 중에 예외가 발생하더라도 B의 코드는 영향을 받지 않음

• PROPAGATION_REQUIRED

  • 가장 많이 사용되는 트랜잭션 전파 속성

  • 진행중인 트랜잭션이 없으면 새로 시작하고, 이미 시작된 트랜잭션이 있다면 이에 참여한다.

  • 해당 속성을 갖는 코드는 다양하게 결합해서 하나의 트랜잭션으로 구성하기 쉽다.

    ex) A, B, A→B, B→A

• PROPAGATION_REQUIRES_NEW

  • 항상 새로운 트랜잭션을 시작

• PROPAGATION_NOT_SUPORTED

  • 트랜잭션 없이 동작하도록 만들고, 진행중인 트랜잭션이 있어도 무시
  • 이럴거면 트랜잭션 경계설정을 아예 안하면 되는거 아닌가?
    • 트랜잭션 경계설정은 보통 AOP를 이용해 한 번에 많은 메소드에 동시에 적용하는 방법을 사용하기 때문에 이런 경우에 특별한 메소드만 트랜잭션에서 제외하기 위해 설정
    • 물론 포인트컷을 잘 만들어서 사용하면 되지만 상당히 복잡해질 수 있기 때문에 차라리 모든 메소드에 트랜잭션 AOP를 설정하고 특정 메소드에만 해당 속성을 사용하는게 낫다고 함

격리수준

• 모든 DB 트랜잭션은 격리수준을 갖고 있어야 함
• 서버환경에서는 여러 개의 트랜잭션이 동시에 진행될 수 있음
  • 모든 트랜잭션이 순차적으로 진행되면 성능이 크게 떨어지므로, 격리수준을 조정해 가능한 많은 트랜잭션을 동시에 진행시키면서도 문제가 발생하지 않게끔 제어한다.
• 기본적으로는 DB, DataSource에 설정된 디폴트 격리수준을 따르지만 필요에 따라 메소드별로 독자적인 격리수준을 지정하기도 한다.

제한시간

• 트랜잭션을 수행하는 제한시간을 설정할 수 있음
• 트랜잭션을 직접 시작할 수 있는 PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW 속성과 같이 사용해야 의미가 있음

읽기전용

• 트랜잭션 내에서 데이터를 조작하는 시도를 막아줌

6.6.2 트랜잭션 인터셉터와 트랜잭션 속성

💡 원하는 메소드만 선택해서 독자적인 트랜잭션 정의를 적용할 수 있는 방법이 없을까?

• TransactionDefinition 네 가지 속성을 이용해 트랜잭션의 동작방식을 제어

• TransactionAdvice TransactionDefinition 오브젝트를 생성하고 사용, 트랜잭션 경계설정 기능을 가짐

TransactionInterceptor

• 트랜잭션 경계설정 어드바이스로 사용 가능

• 트랜잭션 정의를 메소드 이름 패턴을 사용해 지정할 수 있는 방법을 제공해줌

• TransactionInterceptor의 두 가지 프로퍼티

  1. PlatformTransactionManager
  2. Properties - transactionAttributes
     • TransactionDefinition의 네 가지 기본 트랜잭션 속성 + rollbackOn() 메소드를 갖는 TransactionAttribute 인터페이스
     • 트랜잭션 부가기능의 동작방식을 모두 제어할 수 있음

• TransactionInterceptor의 예외 처리 방식

  1. 런타임 예외가 발생하면 트랜잭션을 롤백시킨다.

  2. 타깃 메소드가 런타임 예외가 아닌 체크 예외를 던지는 경우에는 트랜잭션을 커밋한다.

     → 체크 예외를 일종의 비즈니스 로직에 따른 의미 있는 리턴 방식의 한 가지로 인식

• TransactionAttribute는 rollbackOn() 속성을 둬 이런 기본적인 예외 처리 방식을 따르지 않아도 되게끔 해준다.

트랜잭션 속성 정의 방식

1. TransactionInterceptor 타입의 빈 정의
2. tx 스키마의 전용 태그를 이용해 정의

6.6.3 포인트컷과 트랜잭션 속성의 적용 전략

트랜잭션 포인트컷 표현식은 타입 패턴이나 빈 이름을 이용한다

• 일반적으로 트랜잭션을 적용할 타깃 클래스의 메소드는 모두 트랜잭션 적용 후보가 되는 것이 바람직하다.
  • 비즈니스 로직을 담고 있는 클래스라면 메소드 단위까지 세밀하게 포인트컷을 정의해줄 필요는 없음
• 쓰기 작업이 없는 단순한 조회 작업 메소드에도 모두 트랜잭션을 적용하는게 좋다.
• 트랜잭션 경계로 삼을 클래스들이 모여 있는 패키지 혹은 비즈니스 로직 서비스를 담당하는 클래스명의 패턴을 찾아서 표현식으로 만든다.
  • 메소드 시그니처를 이용한 execution() 방식의 포인트컷 표현식
    • Service, ServiceImpl로 끝나는 경우 execution(..ServiceImpl.(..))
  • 스프링의 빈 이름을 이용하는 bean() 표현식
    • bean(*Service)

공통된 메소드 이름 규칙을 통해 최소한의 트랜잭션 어드바이스와 속성을 정의한다

• 기준이 되는 몇 가지 트랜잭션 속성을 정의하고, 그에 따라 적절한 메소드 명명 규칙을 만들어두면 하나의 어드바이스만으로 애플리케이션 모든 서비스 빈에 트랜잭션 속성을 지정할 수 있다.

  • get으로 시작하는 메소드에 대해서는 읽기 전용 속성을 부여할 수 있음

      <tx:advice id="transactionAdvice">
          <tx:attributes>
              <tx:method name="get*" read-only="true" />
              <tx:method name="*" />
          </tx:attributes>
      </tx:attributes>

프록시 방식 AOP는 같은 타킷 오브젝트 내의 메소드를 호출할 때는 적용되지 않는다

• 프록시 방식의 AOP에서는 프록시를 통한 부가기능의 적용은 클라이언트로부터 호출이 일어날 때만 가능하다. __

  • (2)를 통해 update() 메소드가 호출될 때, 전파속성이 REQUIRES_NEW로 설정되어 있더라도 프록시의 delete()메소드에서 시작된 트랜잭션에 참여하게 된다.

    • 즉 타깃 오브젝트 안에서 메소드 호출이 일어나는 경우에는 부가기능 적용이 되지 않음

  • 타깃 안에서의 호출에 프록시가 적용되지 않는 문제를 해결할 수 있는 방법

    • AspectJ와 같은 타깃의 바이트코드를 직접 조작하는 방식의 AOP 기술 적용

트랜잭션 속성 테스트

→ TransientDataAccessResourceException 예외가 발생한다. 스프링의 DataAccessException의 한 종류로 일시적인 예외상황을 만났을 때 발생하는 예외다.

6.7 애노테이션 트랜잭션 속성과 포인트컷

트랜잭션 속성을 비즈니스 로직을 담당하는 패키지, 클래스 등에 일괄적으로 적용하는 방식은 대부분의 상황에 잘 들어맞는다. 하지만 세밀한 제어가 필요한 경우도 종종 있는데, 이때는 직접 타깃에 트랜잭션 속성정보를 가진 애노테이션을 지정한다.

6.7.1 트랜잭션 애노테이션

@Transactional

//Transactional.class

@Inherited
@InterceptorBinding
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Transactional {
    TxType value() default Transactional.TxType.REQUIRED;

    @Nonbinding
    Class[] rollbackOn() default {};

    @Nonbinding
    Class[] dontRollbackOn() default {};

    public static enum TxType {
        REQUIRED,
        REQUIRES_NEW,
        MANDATORY,
        SUPPORTS,
        NOT_SUPPORTED,
        NEVER;

        private TxType() {
        }
    }
}

• @Target
  • 메소드와 타입이 타깃이므로 메소드, 클래스, 인터페이스에 @Transactional 애노테이션을 사용할 수 있음
• 스프링은 @Transactional이 부여된 모든 오브젝트를 자동으로 타깃 오브젝트로 인식한다.
  • 이때 TransactionAttributeSorcePointcut 포인트컷을 사용하는데 표현식과 같은 선정기준을 갖는 것이 아니라, 해당 애노테이션이 붙은 빈 오브젝트를 모두 찾아서 포인트컷의 선정 결과로 돌려준다.

트랜잭션 속성을 이용하는 포인트컷

@Transactional 애노테이션을 사용했을 때 어드바이저의 동작방식

• 포인트컷과 트랜잭션 속성을 애노테이션 하나로 지정 가능
• 메소드 단위로 지정할 수 있으므로 세밀한 제어가 가능
• 애노테이션이 메소드마다 반복적으로 부여되어 코드가 지저분해질 수 있음

대체 정책

스프링은 @Transactional을 적용할 때 4단계의 대체정책을 이용한다.

• 메소드의 속성을 확인할 때 다음의 순서로 트랜잭션이 적용됐는지 차례로 확인하고, 가장 먼저 발견되는 속성을 사용하게 하는 방법

  • 타깃 메소드 → 타깃 클래스 → 선언 메소드 → 선언 타입

• 예시) @Transactional을 부여할 수 있는 위치는 총 6개

• 스프링은 5 → 6 → 4 → 2 → 3 → 1의 순서로 애노테이션을 찾는다.

• 대체정책을 잘 활용하면 애노테이션을 최소한으로 사용하면서 세밀하게 제어할 수 있음
  1. 타입 레벨에 정의할 수 있는지 본다.
  2. 공통 속성을 따르지 않는 메소드에 대해서만 메소드 레벨에 애노테이션을 부여한다.

6.7.2 트랜잭션 애노테이션 적용

애노테이션을 이용할 때는 단순하게 트랜잭션이 필요한 타입 또는 메소드에 직접 애노테이션을 부여한다.

6.8 트랜잭션 지원 테스트

6.8.1 선언적 트랜잭션과 트랜잭션 전파 속성

• 사용자 등록 로직을 담당하는 add() 메소드가 트랜잭션 전파 방식을 사용할 수 없어서 매번 새로운 트랜잭션을 시작하도록 만들어졌다면, 다른 메소드에서 호출하기가 꺼려질 것이다.

  • 결국 add() 메소드를 복사해서 하나의 메소드 안에 넣게 되는 중복코드가 계속 발생할 것이다.

• 스프링의 선언적 트랜잭션을 사용하면 AOP를 이용해 코드 외부에서 트랜잭션의 기능을 부여해주고 속성을 지정할 수 있다

• 또한 스프링은 개별 데이터 기술의 트랜잭션 API를 사용해 직접 코드 안에서 사용하는 프로그램에 의한 트랜잭션도 지원한다.

6.8.2 트랜잭션 동기화와 테스트

트랜잭션 매니저와 트랜잭션 동기화

• 트랜잭션 추상화 기술의 핵심은 트랜잭션 매니저와 트랜잭션 동기화
  • 트랜잭션 매니저 구체적인 트랜잭션 기술의 종류에 상관없이 일관적인 제어 가능
  • 트랜잭션 동기화 시작된 트랜잭션 정보를 저장소에 보관해뒀다가 DAO에서 공유
    • 이 기술 덕분에 트랜잭션 전파 속성에 따라 진행 중인 트랜잭션이 있는지 확인하고 이에 참여할 수 있는 것

트랜잭션 매니저를 이용한 테스트용 트랜잭션 제어

• 메소드를 추가하지 않고도, UserService의 메소드를 호출하기 전에 트랜잭션을 미리 시작시켜서 UserService의 세 개의 메소드가 동일한 트랜잭션 내에 참여하게끔 유도할 수 있음

트랜잭션 동기화 검증

• 테스트에서 미리 트랜잭션을 시작함으로써 테스트코드를 하나의 트랜잭션 단위로 묶는 것이 가능 (@Transactional 애노테이션 적용과 같은 용도로..)
  • DB 작업이 포함되는 테스트를 원하는 대로 제어하는 것이 가능해졌다.
  • 하이버네이트 등 ORM에서 세션에서 분리된 엔티티 동작을 확인할 때도 유용하다.

롤백 테스트

• DB에 엑세스하는 테스트를 할 때마다 테스트 데이터를 초기화하는 작업이 반복되는데, 이럴 때 롤백 테스트가 유용하다.
• 테스트에서 트랜잭션을 제어할 수 있기 때문에 얻을 수 있는 가장 큰 유익이 있다면 롤백 테스트다.
  • MySQL에서는 동일한 작업을 수행한 뒤에 롤백하는게 커밋보다 더 빠르기 때문에 성능이 향상되기도 함

6.8.3 테스트를 위한 트랜잭션 애노테이션

@Transactional

• 테스트에서 사용하는 이 애노테이션은 AOP를 위한 것은 아님

@Rollback

• 테스트용 @Transactional 애노테이션은 테스트가 끝나면 자동으로 롤백된다.
• 강제 롤백을 원하지 않는 경우에는 @Rollback(false) 애노테이션을 사용하자

@TransactionConfiguration

• @Transactional은 테스트 클래스에 적용가능하지만, @Rollback은 메소드 레벨에만 적용 가능하다.

• 테스트 클래스의 모든 메소드에 트랜잭션을 적용하되 모든 트랜잭션을 롤백시키지 않고 커밋하려면 이 애노테이션을 사용해보자.

    @TransactionConfiguration(defaultRollback=false)

NotTransactional과 Propagation.NEVER

• 필요하지도 않은 트랜잭션이 만들어지는 것이 싫은 경우에 적용한다.

    @Transactional(propagation=Propagation.NEVER)

효과적인 DB 테스트

• 일반적으로 의존, 협력 오브젝트를 사용하지 않는 단위 테스트와, DB 같은 외부의 리소스나 여러 계층 클래스가 참여하는 통합 테스트는 아예 구분해서 만드는 게 좋다.
• 테스트는 어떤 경우에도 서로 의존하면 안 된다.

6.9 정리

• 목 오브젝트를 활용하면 의존관계에 있는 오브젝트로 쉽게 고립된 테스트로 만들 수 있다.
• DI를 이용한 트랜잭션의 분리는 데코레이터 패턴과 프록시 패턴으로 이해될 수 있다.
• AOP는 OOP만으로 모듈화하기 힘든 부가기능을 효과적으로 모듈화하도록 도와주는 기술이다.
• AOP를 이용해 트랜잭션 속성을 지정할 때, 포인트컷 표현식과 메소드 이름 패턴을 이용하는 방법과 타깃에 직접 부여하는 @Transactioanl 애노테이션을 사용하는 방법이 있다.

6장 AOP

• 6.3 다이내믹 프록시와 팩토리 빈
• 6.4 스프링의 프록시 팩토리 빈
• 6.5 스프링 AOP

6.3 다이내믹 프록시와 팩토리 빈

6.3.1 프록시와 프록시 패턴, 데코레이터 패턴

• 부가기능 외의 나머지 모든 기능은 원래 핵심기능을 가진 클래스로 위임해줘야 한다. 핵심기능은 부가기능 클래스의 존재를 모르며, 부가기능이 핵심기능을 사용하는 구조가 된다.
• 클라이언트가 핵심기능을 가진 클래스를 직접 사용해버리면 부가기능이 적용될 기회가 없다는 문제가 존재한다.

• 부가기능은 자신이 핵심기능을 가진 클래스처럼 꾸며서, 클라이언트가 자신을 거쳐 핵심기능을 사용하도록 만든다.
• 클라이언트는 인터페이스를 통해서만 핵심기능을 사용하게 하고, 부가기능도 같은 인터페이스를 구현한 뒤에 자신이 그 사이에 끼어들어야 한다.

프록시

자신이 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서 클라이언트의 요청을 받아주는 것을 대리자, 대리인과 같은 역할을 한다고 해서 프록시라고 부른다. 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃 또는 실체라고 부른다.

• 프록시의 특징
  • 타깃과 같은 인터페이스를 구현한다.

• 프록시의 사용 목적

  1. 클라이언트가 타깃에 접근하는 방법을 제어하기 위함

  2. 타깃에 부가적인 기능을 제공해주기 위함

     → 이 사용 목적에 따라 두 개는 다른 디자인패턴으로 구분된다.

데코레이터 패턴

타깃에 부가적인 기능을 런타임 시 다이내믹하게 부여해주기 위해 프록시를 사용하는 패턴 (2에 해당)

• 부가적인 기능을 다이내믹하게 부여

  = 컴파일 시점에 (즉, 코드 상에서) 어떤 방법과 순서로 프록시-타깃이 연결되어 사용되는지 정해져있지 않다.

• 데코레이터 = 제품이나 케이크를 여러 겹으로 포장하고 그 위에 장식을 붙이는 것처럼 실제 내용물은 동일하지만 부가적인 효과를 부여해줄 수 있다는 의미
  • 프록시는 한 개로 제한되지 않으며, 프록시가 직접 타깃을 사용하도록 고정시킬 필요도 없다.

• 데코레이터 패턴 적용 예

  • 프록시가 여러 개인 만큼 순서를 정해서 단계적으로 위임하는 구조를 만든다.
  • 부가적인 기능을 프록시로 만들어두고 런타임 시에 이를 적절한 순서로 조합해서 사용한다.

• 프록시로 동작하는 각 데코레이터는 위임하는 대상에도 인터페이스로 접근하기 때문에 자신이 최종 타깃으로 위임하는지, 아니면 다음 단계의 데코레이터 프록시로 위임하는지 알지 못한다.

  → 데코레이터의 다음 위임 대상은 인터페이스로 선언하고 생성자나 수정자 메소드를 통해 위임 대상을 외부에서 런타임 시에 주입받을 수 있도록 만들어야 한다.

• 데코레이터 패턴이 적용된 대표적인 예시

    InputStream is = new BufferdInputStream(new FileInputStream("a.txt"));

  • Component 인터페이스: InputStream이 공통 인터페이스 역할을 한다.
  • Concrete Component & 타깃: FileInputStream은 기본 기능을 제공하는 구체적인 구현이다.
  • Decorator: BufferedInputStream은 FileInputStream을 감싸서 버퍼링 기능을 추가해 read() 메서드가 효율적으로 동작할 수 있도록 돕는다.

• UserService 인터페이스를 구현한 타깃인 UserServiceImpl에 트랜잭션 부가기능을 제공해주는 UserServiceTx를 추가한 것도 데코레이터 패턴의 적용이라고 볼 수 있다.

    <bean id="userService" class="springbook.user.service.UserServiceTx">  
            <property name="transactionManager" ref="transactionManager" />
            **<property name="userService" ref="userServiceImpl" />**  
        </bean>
  
    <bean id="**userServiceImpl**" class="springbook.user.service.UserServiceImpl">

  → UserServiceImpl로 선언된 타깃 빈이 DI를 통해 데코레이터인 UserService빈에 주입되도록 설정

• 언제 유용할까?

프록시 패턴

클라이언트가 타깃에 접근하는 방법을 제어하려는 목적을 가진다. (1에 해당)

• 타깃의 기능을 확장/추가해주진 않지만 클라이언트가 타깃에 접근하는 방식을 변경해준다.
  • 타깃 오브젝트가 필요해지는 시점까지 오브젝트를 생성하지 않는 편이 좋지만 타깃 오브젝트에 대한 레퍼런스가 미리 필요할 수 있는데, 이때 프록시 패턴을 적용하면 좋다.
  • 클라이언트에게 타깃에 대한 레퍼런스를 넘겨야 할 때 실제 오브젝트 대신 프록시를 넘겨준다. 그리고 프록시의 메소드를 사용해 타깃을 사용하려고 시도하면 그때 프록시가 타깃 오브젝트를 생성하고 요청을 위임해준다. → 프록시를 통해 타깃의 생성을 최대한 늦춤

• 특별한 상황에서 타깃에 대한 접근권한을 제어

  • 수정 가능한 오브젝트가 특정 레이어에서는 읽기 전용으로 사용되어야 할 때, 오브젝트의 프록시를 만들 수 있다. 프록시의 특정 메소드를 사용하려고 하면 접근이 불가능하다고 예외를 발생시킨다.

    • Collections의 unmodifiableCollection()을 통해 만들어지는 오브젝트가 전형적인 접근권한 제어용 프록시

    • 파라미터로 전달된 Collection의 프록시를 만들어서 add(), remove() 등 수정 메소드를 호출하면 예외를 발생하게 해준다.

• 프록시 패턴의 경우 자신이 만들거나 접근할 타깃 클래스의 정보를 알고 있는 경우가 많다.

• 프록시 패턴 + 데코레이터 패턴

6.3.2 다이내믹 프록시

프록시를 일일이 모든 인터페이스를 구현해서 클래스를 새로 정의하지 않고도 편리하게 만들어 사용할 방법이 있다. 몇 가지 API를 이용해 프록시처럼 동작하는 오브젝트를 다이내믹하게 생성하는 것이다.

프록시의 구성과 프록시 작성의 문제점

public class UserServiceTx implements UserService {
    UserService userService;

    // 프록시의 기능(1). 메소드 구현과 위임
    public void add(User user) {
        this.userService.add(user);
    }

    public void upgradeLevels() {
        // 프록시의 기능(2). 부가기능 수행
        TransactionStatus status = this.transactionManager
                .getTransaction(new DefaultTransactionDefinition());
        try {

            userService.upgradeLevels(); // (1). 메소드 구현과 위임

            this.transactionManager.commit(status);
        } catch (RuntimeException e) {
            this.transactionManager.rollback(status);
            throw e;
        }
    }
}

프록시를 만들기 번거로운 이유

1. 부가기능 코드가 중복될 가능성이 많다.

   → 중복되는 코드를 분리해서 어떻게든 해결할 수 있다.

2. 인터페이스를 구현하고 위임하는 코드를 작성하기 번거롭다. 부가기능이 필요없는 메소드도 구현해서 타깃으로 위임하는 코드를 일일이 만들어줘야 한다.

   → JDK의 다이내믹 프록시를 이용해 해결할 수 있다.

리플렉션

다이내믹 프록시는 리플렉션 기능을 이용해서 프록시를 만들어준다. 리플렉션은 자바의 코드 자체를 추상화해서 접근하도록 만든 것을 말한다.

• 자바의 모든 클래스는 그 클래스 자체의 구성정보를 담은 Class 타입의 오브젝트를 하나 갖는다.

  • 클래스 코드에 대한 메타정보를 가져오거나 오브젝트를 조작할 수 있다.
    • 클래스 이름, 어떤 클래스를 상속하는지, 어떤 인터페이스를 구현했는지, 어떤 필드를 갖고 있고, 각각의 타입은 무엇인지, 메소드는 어떤 것을 정의했고, 메소드의 파라미터와 리턴 값은 무엇인지 등

• 리플렉션 API 중, 메소드에 대한 정의를 담은 Method 인터페이스를 이용해 메소드 호출하는 방법

    //Method를 이용해 리플렉션 방식으로 호출
    Method lengthMethod = String.class.getMethod("length");

    // 특정 오브젝트의 메소드를 실행시킬 수도 있다.
    public Object invoke(Obeject obj, Object ...args)
  
    int length = lengthMethod.invoke(name); // int length = name.length();

프록시 클래스

1. Hello 인터페이스

    interface Hello { 
        String sayHello(String name);
        String sayHi(String name);
        String sayThankYou(String name);
    }

2. 타깃 클래스

    public class HelloTarget implements Hello { 
        public String sayHello(String name) { return "Hello " + name;}
        public String sayHi(String name) { return "Hi " + name;}
        public String sayThankYou(String name) { return "Thank You " + name;
        } 
    }

3. 프록시 클래스

   • 데코레이터 패턴을 적용해 부가기능을 추가한다.

     public class HelloUppercase implements Hello { 
       Hello hello;
     
       public HelloUppercase(Hello hello) { 
           this.hello = hello;
       }
     
       public String sayHello(String name) { 
           return hello.sayHello(name).toUpperCase(); // 위임과 부가기능 적용
       }
     
       public String sayHi(String name) { 
           return hello.sayHi(name).toUpperCase();
       }
     
       public String sayThankYou(String name) { 
           return hello.sayThankYou(name).toUpperCase();
       }
     
     }

     → 인터페이스의 모든 메소드를 구현해 위임하도록 만들어야 하고, 부가기능인 리턴값을 대문자로 바꿔주는 기능이 모든 메소드에 중복된다는 프록시 적용의 일반적인 문제점 두가지를 모두 갖는다.

다이내믹 프록시 적용

• 다이내믹 프록시 오브젝트는 타깃의 인터페이스와 같은 타입으로 만들어진다. 클라이언트는 다이내믹 프록시 오브젝트를 타깃 인터페이스를 통해 사용할 수 있다.

  • 인터페이스를 구현하고 위임하는 코드를 작성하기 번거롭다는 문제 해결
  • 프록시 팩토리에게 인터페이스 정보만 제공해주면 해당 인터페이스를 구현한 클래스의 오브젝트를 자동으로 만들어주기 때문

• 다이내믹 프록시가 인터페이스 구현 클래스의 오브젝트를 만들어주지만, 부가기능 제공 코드는 직접 작성해야 한다.

  • 부가기능은 프록시 오브젝트와 독립적으로 InvocationHandler를 구현한 오브젝트에 담는다.

• InvocationHandler 인터페이스는 다음의 메소드 하나만을 갖는다.

    public Object invoke(Object proxy, Method method, Object[] args) 

  → 다이내믹 프록시 오브젝트는 클라이언트의 모든 요청을 리플렉션 정보로 변환해서 InvocationHandler 구현 오브젝트의 invoke() 메소드로 넘기는 것.

• 각 메소드 요청은 어떻게 처리할까?

    public class UppercaseHandler implements InvocationHandler {
        Hello target; // 타깃의 정보를 갖고 있다.

        public UppercaseHandler(Hello target) {
            this.target = target;
        }

        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            String ret = (String)method.invoke(target, args); //타깃으로 위임
            return ret.toUpperCase(); // 부가기능 제공
        }
    }

    // 프록시 생성
    Hello proxiedHello = (Hello)Proxy.newProxyInstance(
            getClass().getClassLoader(),
            new Class[] { Hello.class }, //구현할 인터페이스
            new UpperCaseHandler(new HelloTarget())); // 부가기능과 위임코드를 담은 InvocationHandler

다이내믹 프록시의 확장

다이내믹 프록시를 사용하면 직접 정의해서 만든 프록시보다 훨씬 유연하고 많은 장점이 있다.

1. Hello 인터페이스의 메소드가 늘어나도 일일이 메소드를 구현할 필요가 없다.

   → 다이내믹 프록시가 생겨날때 추가된 메소드가 자동으로 포함되기 때문

2. InvocationHandler는 리플렉션의 Method 인터페이스를 이용해 타깃의 메소드를 호출하므로, 타깃의 종류에 상관없이 적용이 가능하다.

6.3.4 다이내믹 프록시를 위한 팩토리 빈

• 스프링은 지정된 클래스 이름을 가지고 리플렉션을 이용해 해당 클래스의 오브젝트를 만든다.

    Date now = (Date) Class.forName("java.util.Date").newInstance();

• 다이내믹 프록시 오브젝트는 클래스가 어떤 것인지 알 수 없다. 클래스 자체도 내부적으로 다이내믹하게 정의해서 사용하기 때문에 사전에 클래스 정보를 알아내서 스프링 빈에 정의할 방법이 없다.

팩토리 빈

스프링을 대신해 오브젝트의 생성로직을 담당하도록 만들어진 특별한 빈을 말한다.

• FactoryBean 인터페이스를 구현해 팩토리 빈을 생성할 수 있다.
• 스프링은 FactoryBean 인터페이스를 구현한 클래스가 빈의 클래스로 지정되면, 팩토리 빈 클래스의 오브젝트의 getObject() 메소드를 이용해 오브젝트를 가져오고, 이를 빈 오브젝트로 사용한다.

    public class MessageFactoryBean implements FactoryBean {
        String text;

        public void setText(Strint text) {
            this.text = text);
        }

        public Message getObject() throws Exception {
            return Message.newMessage(this.text);
        }
    }

다이내믹 프록시를 만들어주는 팩토리 빈

• 팩토리 빈을 사용하면 다이내믹 프록시 오브젝트를 스프링의 빈으로 만들어줄 수 있다.

  • getObject() 메소드에 다이내믹 프록시 오브젝트를 만들어주는 코드를 넣으면 된다.

    public class MessageFactoryBean implements FactoryBean {
      public Object getObject() throws Exception { 
          TransactionHandler txHandler = new TransactionHandler();
          txHandler.setTarget(target);
          txHandler.setTransactionManager(transactionManager);
          txHandler.setPattern(pattern);
          return Proxy.newProxyInstance( getClass().getClassLoader(),new Class[] { serviceInterface }, txHandler);
      }
    }

• 팩토리 빈은 타깃 오브젝트인 UserServiceImpl에 대한 레퍼런스를 프로퍼티를 통해 DI 받아야 한다.

  → TransactionHandler에게 타깃 오브젝트를 전달해주기 위함

6.3.5 프록시 팩토리 빈 방식의 장점과 한계

프록시 팩토리 빈의 한계

1. 프록시를 통해 타깃에 부가기능을 제공하는 것은 메소드 단위로 일어나는 일이다.

   1. 하나의 클래스 안에 존재하는 여러 개의 메소드에 부가기능을 한 번에 제공하는 것은 가능하지만, 여러 클래스에 공통적인 부가기능을 제공하는 것은 불가능하다.

      → 프록시 팩토리 빈의 중복설정으로 이어질 수 있다.

2. 같은 타깃 오브젝트에 트랜잭션 프록시 뿐만 아니라, 다른 프록시도 추가하고 싶다면 프록시 팩토리 빈 설정이 부가기능의 개수만큼 늘어나게 된다.

3. Handler 오브젝트가 팩토리 빈 개수만큼 늘어난다.

   1. 타깃 오브젝트를 프로퍼티로 갖고 있으므로, 타깃 오브젝트가 달라질 때마다 새로운 Handler 오브젝트를 만들어야 한다.

6.4 스프링의 프록시 팩토리 빈

스프링은 이런 문제에 어떤 해결책을 제시할까?

6.4.1 ProxyFactoryBean

스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공한다.

• 스프링의 ProxyFactoryBean은 프록시 생성 작업만 담당하고, 부가기능은 별도의 빈에 둘 수 있다.

  • 부가기능은 MethodInterceptor 인터페이스를 구현해 만든다.

• MethodInterceptor와 InvocationHandler의 차이

  • InvocationHandler의 invoke() 메소드가 타깃 오브젝트에 대한 정보를 제공하지 않기 때문에 InvocationHandler를 구현한 클래스는 타깃을 알고 있어야 한다.

  • MethodInterceptor의 invoke() 메소드는 ProxyFactoryBean으로부터 타깃 오브젝트에 대한 정보까지도 함께 제공받는다.

      static class UppercaseAdvice implements MethodInterceptor { 
              public Object invoke(MethodInvocation invocation) throws Throwable { 
                      String ret = (String)invocation.proceed();
                      return ret.toUpperCase();
              } 
      }

어드바이스: 타깃이 필요 없는 순수한 부가기능

• MothodInvocation은 일종의 콜백 오브젝트로, proceed() 메소드를 실행하면 타깃 오브젝트의 메소드를 내부적으로 실행해주는 기능이 있다.

  • 일종의 공유가능한 템플릿처럼 동작한다.
  • ProxyFactoryBean은 템플릿 역할을 하는 MethodInvocation을 싱글톤으로 두고 공유할 수 있다.

• ProxyFactoryBean에는 여러 개의 MethodInvocation을 추가할 수 있다.

  → ProxyFactoryBean 하나만으로 여러 개의 부가기능을 제공하는 프록시를 만들 수 있다.

• 어드바이스 타깃 오브젝트에 적용하는 부가기능을 담은 오브젝트

포인트컷: 부가기능 적용 대상 메소드 선정 방법

• MethodInterceptor는 InvocationHandler와 달리 클라이언트로 받는 요청을 일일이 전달받을 필요가 없다.

• MethodInterceptor에는 순수한 부가기능 제공 코드만 남겨두고 프록시에 부가기능을 적용할 메소드를 선택하는 기능을 넣자.

  • 프록시의 핵심 가치는 타깃을 대신해 클라이언트의 요청을 받는데 있으므로, 메소드 선별기능은 다시 프록시에서 분리하는게 낫다.

• 스프링의 ProxyFactoryBean 방식은 두 가지 확장기능인 부가기능과 메소드 선정 알고리즘을 활용하는 유연한 구조를 제공한다.

• 어드바이스와 포인트컷은 모두 프록시에 DI로 주입돼서 사용된다.

    → 여러 프록시에서 공유가능하도록 만들어지기 때문에 스프링 빈으로 등록 가능하다.

  1. 프록시는 클라이언트로 요청을 받으면 먼저 포인트컷에게 부가기능을 부여할 메소드인지 확인해달라는 요청을 보낸다.
  2. 확인받으면 프록시는 MethodInterceptor타입의 어드바이스를 호출한다.
     1. 어드바이스는 타깃에 의존하지 않도록 일종의 템플릿 구조로 설계되어 있다.
  3. 어드바이스가 부가기능을 부여하는 중에 타깃 메소드 호출이 필요하면 프록시로부터 전달받은 MethodInvocation 타입 콜백 오브젝트의 proceed() 메소드를 호출한다.
  4. 위임대상인 타깃 오브젝트의 레퍼런스를 갖고 있고 이를 이용해 타깃 메소드를 직접 호출하는건 Invocation 콜백이 수행한다.

• 어드바이저 = 포인트컷(메소드 선정 알고리즘) + 어드바이스(부가기능)

    ProxyFactoryBean pfBean = new ProxyFactoryBean();
  
    pfBean.addAdvisor(new DefaultPointCutAdvisor(pointcut, new UpperCaseAdvice());

  → 포인트컷과 어드바이스를 따로 등록하게 되면 포인트컷을 어떤 어드바이스에 적용할지 애매하기 때문

6.5 스프링 AOP

6.5.1 자동 프록시 생성

프록시 팩토리 빈 방식의 접근 방법의 한계를 되짚어보자.

1. 부가기능이 타깃 오브젝트마다 새로 만들어지는 문제

   → 스프링 ProxyFactoryBean의 어드바이스를 통해 해결

2. 부가기능 적용이 필요한 타깃 오브젝트마다 비슷한 내용의 ProxyFactoryBean 설정 정보를 추가해야함

   → ?

중복문제의 접근 방법

한 번에 여러 개의 빈에 프록시를 적용하기 위해 ProxyFactoryBean 설정 문제는 어떻게 해결해야 할까?

빈 후처리기를 이용한 자동 프록시 생성기

스프링은 OCP의 가장 중요한 요소인 유연한 확장 개념을 스프링 컨테이너 자신에게도 적용하고 있다.

나를 포함한 소마 15기 연수생 4명과 함께 6월부터 토비의 스프링 스터디를 진행하고 있다. 스프링 스터디이다보니 책 내용 이외에도 스프링과 관련한 이런 저런 이야기를 많이 나누게 된다. 얼마 전에는 스프링 시큐리티의 SecurityContextHolder의 동작 원리와 관련해 이야기를 나눌 기회가 있었는데, 관련 코드를 작성해본 경험이 있음에도 내부의 동작 방식에 무지했던 것이 부끄러워 뒤늦게라도 공부한 내용을 기록해보고자 한다.

기존에 가지고 있던 의문: SecurityContext의 전역적 사용

이전에 인증 로직을 구현하면서 SecurityContextHolder의 동작에 대해 가지고 있던 궁금증이 있다. jwt 토큰을 이용해 인증객체를 생성한 뒤 이 인증객체를 전역적으로 사용하기 위해 SecurityContextHolder의 컨텍스트에 인증객체를 저장하는데, 이때 전역적으로 사용한다는게 어떤 의미인지 잘 와닿지가 않았던 것이다.

아래 코드는 현재 진행중인 프로젝트의 코드로, jwt 토큰을 이용해 API 요청을 보낼 때마다 SecurityContextHolder에 인증객체를 저장하게끔 구현되어 있다. 이렇게 매 요청마다 인증객체를 저장할거라면, SecurityContextHolder가 왜 필요한걸까?

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {
    private final JwtVerifier jwtVerifier;
    private final JwtService jwtService;

    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
        List<RequestMatcher> matchers = new ArrayList<>();
        matchers.add(new AntPathRequestMatcher("/customer/product/**"));
        matchers.add(new AntPathRequestMatcher("/login/**"));
        matchers.add(new AntPathRequestMatcher("/reissue"));

        return matchers.stream()
            .anyMatch((matcher -> matcher.matches(request)));
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
        FilterChain filterChain) throws ServletException, IOException {

        try {
            String accessToken = request.getHeader("Authorization");

            if (accessToken == null || !accessToken.startsWith("Bearer ")) {
                throw new JwtTokenException(JwtErrorCode.INVALID_TOKEN);
            }

            accessToken = accessToken.substring(7);
            if (jwtVerifier.isAccessTokenValid(accessToken)) {
                Authentication auth = jwtService.getAuthentication(accessToken);
                SecurityContextHolder.getContext().setAuthentication(auth);
            }
        } catch (ExpiredJwtException e) {
            throw new JwtTokenException(JwtErrorCode.EXPIRED_TOKEN);
        } catch (JwtException e) {
            throw new JwtException(e.getMessage(), e);
        }
        filterChain.doFilter(request, response);
    }
}

전역적으로 사용한다는 의미

SecurityContextHolder를 전역적으로 사용가능하다는 것은 하나의 API 요청에서 그렇다는 의미이다. 한 요청에서 여러 보안 체크를 하면서 시큐리티 필터 체인이 동작하게 되는데, 이때 SecurityContextHolder에 저장된 인증 정보를 전역적으로 참조한다는 의미인 것이다. 그리고 stateless한 jwt 인증 방식에서는 매 요청마다 토큰을 검증하고 인증객체를 생성하는 코드가 반복되는 것이 자연스럽다.

또 다른 의문: Spring Security는 사용자를 어떻게 구분할까?

SecurityContextHolder는 인증이 완료된 유저의 정보를 저장하는 저장소의 역할을 한다. 스프링 시큐리티는 이 저장소에 인증객체가 어떻게 저장되는지에는 관심이 없으며, 인증객체가 담겨져 있다면 인증된 사용자로 간주하고 사용한다.

사용자가 인증되었음을 나타내기 위해서 우리는 SecurityContextHolder를 직접 설정하게 된다. 이때 SecurityContextHolder는 new를 통해 매번 새로운 인스턴스가 생성되는 것이 아님을 확인할 수 있다. 그런데 그렇다면, 매번 다른 유저가 API 요청을 동시다발적으로 보내게 될 텐데 SecurityContextHolder에 저장된 인증객체도 매번 새로운 값으로 덮어씌워지는 건 아닐까? 하나의 유저 당 하나의 SecurityContextHolder를 가진다는 건 어떻게 보장할 수 있는걸까?

public class JwtAuthenticationFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
        FilterChain filterChain) throws ServletException, IOException {

            accessToken = accessToken.substring(7);
            if (jwtVerifier.isAccessTokenValid(accessToken)) {
                Authentication auth = jwtService.getAuthentication(accessToken);
                SecurityContextHolder.getContext().setAuthentication(auth);
            }
     }
}  

public class JwtService {
   public Authentication getAuthentication(String token) {
          String memberId = String.valueOf(jwtProvider.getMemberIdFromToken(token));
          CustomUserDetails userDetails = customUserDetailsService.loadUserByUsername(memberId);

          return new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
      }
}      

ThreadLocal을 통한 동시성 보장

SecurityContextHolder의 내부 구현 코드를 확인해보자. initializeStrategy() 메소드를 보면 개발자가 특별하게 전략을 설정하지 않는 경우에는 기본적으로 MODE_THREADLOCAL이 설정됨을 알 수 있다. 즉, SecurityContextHolder가 내부적으로 사용하는 SecurityContext는 ThreadLocal에 저장된다. 따라서 여러 사용자가 동시다발적으로 API 요청을 보내더라도 각 요청마다 서로 다른 스레드가 할당되고 스레드마다 독립적인 SecurityContext를 갖게 되기 때문에 유저간 인증객체는 서로 간섭받지 않는다는 걸 보장할 수 있게 되는 것이다.

public class SecurityContextHolder {
    public static final String MODE_THREADLOCAL = "MODE_THREADLOCAL";
    public static final String MODE_INHERITABLETHREADLOCAL = "MODE_INHERITABLETHREADLOCAL";
    public static final String MODE_GLOBAL = "MODE_GLOBAL";
    private static final String MODE_PRE_INITIALIZED = "MODE_PRE_INITIALIZED";
    public static final String SYSTEM_PROPERTY = "spring.security.strategy";
    private static String strategyName = System.getProperty("spring.security.strategy");
    private static SecurityContextHolderStrategy strategy;
    private static int initializeCount = 0;

    public SecurityContextHolder() {
    }

    private static void initialize() {
        initializeStrategy();
        ++initializeCount;
    }

    private static void initializeStrategy() {
        if ("MODE_PRE_INITIALIZED".equals(strategyName)) {
            Assert.state(strategy != null, "When using MODE_PRE_INITIALIZED, setContextHolderStrategy must be called with the fully constructed strategy");
        } else {
            if (!StringUtils.hasText(strategyName)) {
                strategyName = "MODE_THREADLOCAL";
            }

            if (strategyName.equals("MODE_THREADLOCAL")) {
                strategy = new ThreadLocalSecurityContextHolderStrategy();
            } else if (strategyName.equals("MODE_INHERITABLETHREADLOCAL")) {
                strategy = new InheritableThreadLocalSecurityContextHolderStrategy();
            } else if (strategyName.equals("MODE_GLOBAL")) {
                strategy = new GlobalSecurityContextHolderStrategy();
            } else {
                try {
                    Class<?> clazz = Class.forName(strategyName);
                    Constructor<?> customStrategy = clazz.getConstructor();
                    strategy = (SecurityContextHolderStrategy)customStrategy.newInstance();
                } catch (Exception var2) {
                    Exception ex = var2;
                    ReflectionUtils.handleReflectionException(ex);
                }

            }
        }
    }

final class ThreadLocalSecurityContextHolderStrategy implements SecurityContextHolderStrategy {
  private static final ThreadLocal<Supplier<SecurityContext>> contextHolder = new ThreadLocal();
}

ThreadLocal이 아닌 다른 전략을 사용하는 경우는 언제일까?

기본적으로 ThreadLocal 전략이 설정되었기 때문에 사용자마다 독립적인 SecurityContext를 가지며, 실제로 그렇게 동작하는 것이 합리적이라는 생각이 든다. 그런데 위 코드를 살펴보다 보면 MODE_INHERITABLETHREADLOCAL, MODE_GLOBAL과 같은 다른 전략을 선택할 수도 있음을 확인할 수 있는데 이것들은 무엇이고 언제, 왜 사용하게 되는건지 궁금해졌다.

1. MODE_INHERITABLETHREADLOCAL

• 부모-자식 스레드 간의 SecurityContext를 상속할 필요가 있을 때 사용한다.
• 기본적으로 ThreadLocal 전략에서는 부모-자식 스레드 간에 SecurityContext를 공유하지 않는다. 하지만 해당 전략을 사용하게 되면 자식 스레드가 부모 스레드의 SecurityContext를 상속받기 때문에 자식 스레드에서도 인증이 유지된다.
• 구체적으로 어떤 경우에 이런 필요성이 대두되는지는 아직 파악하지 못했다.
  

2. MODE_GLOBAL

• 내가 처음 이해했던 것처럼 하나의 SecurityContext를 모든 스레드가 공유하게끔 설정할 때 해당 전략을 사용한다.
• ThreadLocal 전략에서는 각 스레드마다 독립적인 SecurityContext를 관리하지만, 이 전략에서는 모든 스레드가 동일한 SecurityContext를 공유하도록 보장하므로 이름 그대로 전역적인 모드를 지원하는 것이다.
• 실제 배포 환경에서 해당 전략을 사용할 가능성은 0에 수렴할 것 같지만 아마 특수한 테스트 환경 등에서 전역적인 사용이 필요한 경우도 있지 않을까 생각해본다.

ThreadLocal 사용 시 주의사항

*김영한님의 스프링 핵심 원리 - 고급편 참고

ThreadLocal을 스레드 풀과 함께 사용할 때 스레드 재사용과 관련해 주의해야 할 점이 있다고 한다. 이를 그림으로 이해해보자.

1. 사용자 A의 요청

2. 사용자 A의 요청 종료 WAS는 사용이 끝난 ThreadA를 스레드 풀에 반환한다. 이는 스레드 생성 비용이 비싸기 때문에, 스레드를 나중에 재사용하기 위함이다. 따라서 ThreadA는 스레드 풀에 계속해서 살아있게 되고, ThreadA 전용 보관소에 userA에 대한 정보도 함꼐 살아있게 된다.

3. 사용자 B의 요청 만약 ThreadA가 재할당되면, ThreadA가 스레드 로컬 조회 시 사용자 A에 대한 저장소에서 사용자 A에 대한 정보가 반환되는 심각한 문제가 발생할 수 있다.

내 코드에도 적용해야 할까?

내가 작성한 JwtAuthenticationFilter 클래스는 OncePerRequestFilter를 상속받고 있다. 매 요청마다 해당 필터가 동작하면서 인증객체를 생성하고, ThreadLocal 매커니즘으로 동작하는 SecurityContext에 이 인증객체를 저장하고 있다. 그럼 위에서 살펴본 ThreadLocal 사용 시 발생할 수 있는 문제점을 예방하기 위해 OncePerRequest 필터에서 스레드 로컬을 비워주는 코드를 작성해야 하는 건 아닐까?

하지만 스프링 시큐리티는 기본적으로 요청이 끝난 뒤에 SecurityContext를 자동으로 정리해준다고 한다. 따라서 명시적으로 코드를 작성할 필요는 없어보인다.

마무리

평소에 코드를 작성하면서 조금이라도 의문이 들거나 궁금한 점이 생기면 그걸 이해하고 넘어가려고 습관을 들여야겠다는 생각이 든다. 이번에 글을 작성하며 작은 의문 하나 하나를 해소하는 과정에서 생각지도 못했던 단어, 개념이 등장하고 그걸 공부하다보니 조금씩 지식이 확장되는 즐거운 경험을 했던 것 같다 ✨

(1)에서는 OAuth2.0 Client에 대한 개념적 이해 (2)에서는 OAuth2.0 Client를 사용했을 때 필터체인의 동작 흐름 및 각 필터의 역할 (3)에서는 OAuth2.0 Client를 사용해서 카카오 로그인을 연동한 실제 코드 (4)에서는 라이브러리를 사용하지 않고 직접 카카오 로그인을 연동한 코드

총 네번에 나눠 기록하고자 하고, (1)에서는 간단히 라이브러리를 이해한 내용을 작성해보았다.

Spring Security + OAuth 2.0 Client

Spring Security는 HTTP 요청을 처리하는 여러 필터의 체인으로 구성된다. 각 필터는 특정한 보안 작업을 수행하게 되는데, OAuth 2.0 Client 라이브러리는 이 체인에 OAuth2와 관련된 필터들을 추가하여 클라이언트의 인증 과정을 처리하는데 도움을 준다.

OAuth2와 관련된 대표적인 필터로는 OAuth2LoginAuthenticationFilter가 있는데, 여기서는 간단히 언급만 하고 필터에서 처리하는 동작이나 전체적인 흐름에 대해서는 (2)편에서 자세히 녹여보고자 한다.

OAuth2.0 Client의 역할은?

The OAuth 2.0 Client features provide support for the Client role as defined in the OAuth 2.0 Authorization Framework.

공식문서에서 OAuth2.0 Client는 OAuth2.0 인증 프레임워크에 정의된 클라이언트의 역할을 지원한다고 소개되고 있다. OAuth에서 정의하고 있는 역할을 이해하고자 개략적으로 그렸던 그림이 있어 함께 첨부한다.

• Resource Owner: 자원(여기서는 사용자 정보)에 대한 접근권한을 가지고 있는 소유자를 말한다. 카카오 사용자인 홍길동이 여기 해당한다.
• Resource Server: 카카오 계정 정보와 같은 보호된 자원를 가지고 있는 주체로 access token이 유효한 경우에 이 자원을 제공한다. 카카오 API 서버가 여기 해당한다.
• Client: Resource Owner의 승인을 받아 카카오 계정 정보에 접근하고자 하는 외부 어플리케이션을 말한다. 우리는 여기 해당한다.
• Authorization Server: Resource Owner가 카카오 계정에 로그인 했는지 여부를 확인하고, Resource Owner의 승인을 받아 access token을 Client에 제공하는 역할을 한다. 카카오 인증 서버가 여기 해당한다.
  

OAuth 2.0 Client 라이브러리는 Client의 역할을 지원한다고 했는데, Client가 해야 할 역할은 아래와 같이 크게 세가지로 구분된다.

1. 인가 코드 요청 및 받기
2. 인가 코드와 함께 엑세스토큰 요청 및 받기
3. 엑세스토큰과 함께 사용자 정보 요청 및 받기

즉, Spring Security의 OAuth2 Client 라이브러리를 사용하면 Spring Security 필터 체인에서 동작하는 여러 필터를 통해 위와 같은 OAuth 2.0 인증 프로세스를 전부 도맡아 처리해준다고 이해하면 된다.

OAuth2.0 Client의 장단점

라이브러리를 사용해보고 느낀 장단점은 다음과 같다.

장점

• 인가 코드 받기, 엑세스 토큰 받기, 사용자 정보 조회 등 일련의 과정을 수행하기 위해 Kakao API Server, Kakao Authorization Server로 API 요청을 직접 보낼 필요가 없다. 따라서 HTTP 요청을 보내기 위한 별도의 라이브러리(ex: WebFlux)를 추가할 필요도 없다.
• application.yml 등의 파일에 provider 정보만 추가하는 등 간단한 설정만 하면 된다.

단점

• 일련의 인증 과정이 Spring Security와 밀접하게 엮여서 필터 단위로 동작하는데, Spring Security를 사용해본 적이 없다면 초반엔 이 개념과 흐름을 이해하기 어렵고 디버깅이 쉽지 않다.
• 인증 과정에서 제어권을 라이브러리가 가지며, 인증 흐름을 커스터마이징 할 수 없다.

예를 들면, 인가 코드 요청/받기는 클라이언트에서 직접 수행한 뒤에 서버에 인가코드와 함께 로그인 요청을 보내서 서버는 토큰 요청하기/받기 부터 수행하겠다와 같이 흐름을 직접 제어하는 것이 불가능해진다.

(2)편에서는 실제로 OAuth2.0 Client를 사용했을 때 필터체인이 어떻게 동작하는지 그 흐름을 이해해보고자 한다!

올해 4월부터 소프트웨어 마에스트로 15기 과정에 참여하게 되었는데, 4월부터 6월까지 약 3개월이라는 긴 시간동안 프로젝트 기획 및 기획 검증의 시간을 가졌다.

기획에 꽤 많은 시간을 쏟다보니 (기획에 이렇게 공을 들여본 프로젝트는 처음이다 .. !) 개발에 투자할 시간이 줄어들어 일정이 살짝 빠듯해졌다. 프로토타입 출시까지 남은 약 2주의 시간 동안 빠르게 개발이 이루어져야 하는 상황이다.

나는 현재 카카오 로그인 및 회원가입 개발을 맡고 있는데, 스프링 시큐리티와 함께 OAuth2 Client 라이브러리를 사용하는 과정에서 (많은) 시행착오를 겪어 생각보다 개발이 지연되었다. 그래도 다행히 프론트엔드와 연동 테스트를 거쳐 무사히 사용자 정보 가져오기를 마쳤다!

Cognito 도입기

카카오 로그인 과정에서 엑세스 토큰과 리프레시 토큰을 발급받기는 하지만, 보안상의 이유로 서비스 API를 호출할 때 카카오 토큰을 계속해서 사용하는 것은 권장되지 않는다고 한다. 따라서 카카오 로그인이 끝나는 시점에 서비스 내에서 자체적으로 엑세스 토큰과 리프레시 토큰을 생성해주고자 한다.

처음에는 토큰 관련한 로직을 전부 직접 개발하려고 했지만, 앞서 사담에서 언급했듯이 개발 일정이 빠듯한 와중에 이건 좋은 선택이 아닌 것 같았다. 그리고 무엇보다 실사용자를 유치하고자 하는 서비스에서 보안 상 구멍이라도 생긴다면 ..? 🫨

이때 AWS Cognito를 사용하게 되면 Cognito에서 제공해주는 API를 사용해 보다 간편하고 안전하게 인가 처리를 할 수 있다고 해 고민끝에 도입해보기로 결정하게 되었다. (그리고 무엇보다 멘토님의 추천이 있었다!🤩)

또 사용자 50,000명이 넘어가기 전까지는 과금 없이 Cognito에서 제공하는 서비스를 계속해서 무료로 사용할 수 있다는 점도 큰 메리트로 다가왔다.

그래서, Cognito란?

Cognito는 인증/인가, 로그인, 회원가입, 자격증명 등 회원관리에 필요한 모든 기능들을 총망라하여 지원해주는 AWS 서비스 중 하나이다. AWS Cognito에서 제공하는 기능은 크게 두 가지로, 사용자 풀(User Pool)과 자격 증명 풀(Identity Pool)이 있다.

사용자 풀은 말 그대로 사용자 정보를 저장하고 있는 저장소의 역할을 한다. 다양한 방식의 회원가입과 로그인을 지원하고, 로그인 한 사용자에게는 토큰을 발급해 자격 증명을 수행할 수 있게 도와준다.

자격 증명 풀은 사용자 풀에 등록되어 있는 사용자의 AWS 인프라 접근 권한을 관리할 수 있도록 도와준다. 사용자 풀을 생성하는 과정이 선행시 되어야 한다는 특징이 있다.

도입 환경

• Spring Boot 3.3.1
• Spring Security + OAuth2 Client 라이브러리를 사용하여 카카오 인증/인가 구현
• 자체 DB를 구축하여 사용자 정보 저장 → 회원가입 시 필요한 정보들을 모두 사용자 풀에 저장하진 않는다. 사용자 풀은 오로지 토큰을 발급하는 목적으로만 사용한다.

AWS Cognito 연동 과정

Cognito를 도입하게 된 주요 목적이 토큰 발행 및 관리인 만큼, 이번에는 사용자 풀을 생성하고 프로젝트와 연동하는 방법에 대해서만 다루고자 한다.

AWS Cognito 사용자 풀 생성

1. AWS Cognito 사용자 풀에 접속한다.
2. 사용자 풀 생성
3. 로그인 환경 구성

• 공급자 유형은 기본 옵션으로 지정되어 있는 Cognito 사용자 풀을 선택한다. 만약 자격 증명 풀도 함께 사용하고자 한다면 연동 자격 증명 공급자를 함께 선택하면 된다.
• 사용자 풀 로그인 옵션은 사용자 풀에서 개별 사용자를 구별하기 위해 사용할 고유값이라고 생각하면 된다. 여기서 선택한 옵션이 사용자 풀에 중복되게 존재하면 사용자를 등록할 수 없기 때문에 나는 사용자 이름 대신 이메일을 선택했다.

4. 보안 요구 사항 구성 (1) 암호 정책 Cognito를 이용해 회원가입까지 구현할 계획이 아니라면 암호 정책을 사용할 일이 없으니 신경쓰지 않아도 된다. 기본값으로 선택해줬다. (2) 멀티 팩터 인증 Cognito를 이용해 로그인 프로세스를 처리할 때, 비밀번호 입력 외에도 SMS 인증 등을 추가로 사용하고자 할 때 멀티 팩터 인증을 적용하면 된다. 마찬가지로 사용하지 않으므로 MFA 없음을 선택한다. (3) 사용자 계정 복구
5. 가입 환경 구성 (1) 셀프 서비스 가입 활성화 하게 되면 인터넷 상의 모든 사용자가 사용자 풀에 자신을 직접 등록할 수 있게 된다. 필요하지 않은 기능이므로 선택하지 않는다. (2) 속성 확인 및 사용자 계정 확인 Cognito에서 사용자에게 이메일이나 SMS를 보내 사용자 계정을 확인 및 검증할 수 있다. 다만 이 옵션을 허용할 경우 메시지 전송에 별도의 요금이 추가될 수 있음에 주의한다. (3) 필수 속성 및 사용자 지정 속성 필수 속성은 사용자를 유저 풀에 등록할 때 반드시 포함해야 할 정보를 말한다. 앞서 로그인 옵션으로 이메일을 선택했기 때문에 이메일은 자동으로 포함되었다. 유저 풀을 DB처럼 사용할 생각이 아니기 때문에 필수 속성을 추가로 등록하지 않았다. 사용자 지정 속성도 마찬가지의 이유로 추가로 등록하지 않고 넘어간다.
6. 메시지 전송 구성 유저 풀에 등록된 사용자에게 메시지를 전송할 방식을 선택한다. Amazon SES를 사용할 경우 별도의 요금이 부과된다. Cognito를 사용하는 방식을 선택하고 From, Reply-to는 기본값 그대로 둔다.
7. 앱 통합 (1) 사용자 풀 이름 AWS Cognito에서 유저 풀을 구분하기 위한 용도이다. 어떤 프로젝트/서비스에 사용하는 것인지 잘 구분되도록 지으면 된다. (2) 호스팅 인증 페이지 Cognito에서 제공하는 호스팅 UI를 사용해 회원가입 및 로그인을 구현한다면 해당 옵션을 선택한다. 이번 프로젝트에서는 카카오 로그인을 연동하고, 로그인 이후에 백엔드 로직에서만 Cognito를 활용할 계획이므로 선택하지 않았다. (3) 초기 앱 클라이언트 Cognito 인증을 어디에 어떻게 붙일 것인지를 선택하는 항목이다. → 퍼블릭 클라이언트: SPA나 모바일 앱에서 직접 인증을 처리하는 경우 → 기밀 클라이언트: 백엔드 서버에서 인증을 처리하는 경우 앱 유형을 구분할 때의 핵심은 `클라이언트 보안키`(Secret Key)를 노출하지 않고 안전하게 관리할 수 있느냐인데, 브라우저 환경에서는 보안키를 안전하게 관리할 수 없으므로 퍼블릭 클라이언트는 보안키를 생성하지 않도록 주의한다. 우리 프로젝트에서는 백엔드 서버에서 인증을 처리하고 있으므로 `기밀 클라이언트`를 선택해 주고, 클라이언트 보안키를 생성해 환경변수로 안전하게 처리하고자 한다.  (4) 고급 앱 클라이언트 설정 엑세스 토큰, 리프레시 토큰의 만료 시간을 설정할 수 있다. 서비스를 운영해보면서 적절히 조절해주는게 좋을 것 같아 아직 별도로 커스텀하지는 않았다.  (5) 속성 읽기 및 쓰기 권한 유저 풀에 등록된 사용자의 속성에 대해 읽기/쓰기 권한을 할당할 수 있는데 별도로 커스텀 할 필요성을 느끼지 못해 마찬가지로 기본값으로 설정하고 넘어간다.
8. 사용자 풀 생성 사용자 풀 생성이 끝났다! 이제 프로젝트와 연동해 Cognito에서 제공해주는 API를 활용해서 카카오에서 가져온 유저 정보를 사용자 풀에 등록해주고, 토큰을 발급해주는 작업을 하면 된다 🥳

[보안/인증] Amazon Cognito를 이용한 백엔드 API 권한 관리 | 배진수, 당근마켓을 참고했습니다.

https://school.programmers.co.kr/learn/courses/30/lessons/59408

동물 보호소에 들어온 동물의 이름이 몇 개인지 조회하는 쿼리를 작성하는 문제이다. 만약 동물들의 이름이 중복되는 경우에는 하나로 합치고, 이름이 NULL인 경우에는 집계하지 않아야 한다.

코드 및 풀이

SELECT COUNT(DISTINCT NAME) 
FROM ANIMAL_INS
WHERE NAME IS NOT NULL;

DISTINCT 키워드를 사용하여 NAME의 중복을 제거하고, WHERE 절을 사용하여 NAME이 NULL인 경우를 제외한다.

https://www.acmicpc.net/problem/16236

알고리즘 분류

• 구현
• 시뮬레이션
• 그래프 이론
• 그래프 탐색
• 너비 우선 탐색

풀이

아기 상어가 물고기를 먹기 위해서는 고려해야 할 우선순위들이 있다. 1. 최단 거리의 물고기를 먹는다. 2. 최단 거리의 물고기가 여러 마리라면, 가장 위쪽에 있는 물고기를 먹는다. 3. 이러한 물고기도 여러 마리라면, 가장 왼쪽에 있는 물고기를 먹는다.

입력받은 이차원 리스트 하나만 사용해서는 이걸 모두 고려한 코드를 작성하기 어려웠다. 따라서 거리를 계산하기 위한 이차원 리스트가 추가로 하나 더 필요했다.

무엇보다 이 풀이의 핵심은 우선순위 기준에 따라 정렬을 해주는 것이라고 생각한다. bfs 탐색 시, 물고기를 먹을 수 있다고 판단되면 [거리, x좌표, y좌표] 정보를 리스트에 저장한다. 그리고 우선순위가 높은 순서대로 정렬하여 가장 우선순위가 높은 물고기를 선별한 후, 최종적으로 '먹었다' 라고 처리해주면 되는 것이다.

이 과정을 먹을 수 있는 물고기가 더 이상 없을 때 까지 반복한다.

코드

import sys
from collections import deque
input = lambda: sys.stdin.readline().rstrip()

N = int(input())
board = [list(map(int, input().split())) for _ in range(N)]
direct = [(-1, 0), (0, -1), (1, 0), (0, 1)]
queue = deque([])

def bfs(start_x, start_y, size):
    distance = [[0]*N for _ in range(N)]
    visited = [[0]*N for _ in range(N)]
    priority = []

    queue.append([start_x, start_y])
    while queue:
        i, j = queue.popleft()
        visited[i][j] = 1

        for x, y in direct:
            nx = i + x
            ny = j + y

            if N > nx >= 0 and N > ny >= 0 and visited[nx][ny] == 0:
                if size >= board[nx][ny]:
                    queue.append([nx, ny])
                    visited[nx][ny] = 1
                    distance[nx][ny] = distance[i][j] + 1
                if size > board[nx][ny] > 0:
                    priority.append([distance[nx][ny], nx, ny])
    return sorted(priority, key=lambda x:(-x[0], -x[1], -x[2]))

ans = cnt = 0
size = 2
for i in range(N):
    for j in range(N):
        if board[i][j] == 9:
            board[i][j] = 2
            x = i
            y = j

while True:
    shark = bfs(x, y, size)
    board[x][y] = 0
    if len(shark) == 0:
        break

    time, x, y = shark.pop()
    ans += time
    board[x][y] = 0
    cnt += 1

    #아기 상어는 자신의 크기와 같은 수의 물고기를 먹을 때 마다 크기가 1 증가한다
    if cnt == size:
        size += 1
        cnt = 0

print(ans)

https://resilient-923.tistory.com/357 를 참고하였습니다.

• ORDER BY 절은 SELECT 문의 맨 끝에 위치한다.
• ASC/DESC 키워드를 이용해 오름차순/내림차순 정렬을 할 수 있다.

COLUMN NAME 사용하기

SELECT * FROM TABLE_NAME
ORDER BY COLUMN_NAME;

열의 인덱스 사용하기

SELECT * FROM TABLE_NAME
ORDER BY 3;

여러 기준으로 정렬하기

-- 첫 번째 열을 기준으로 오름차순 정렬한 뒤,
-- 세 번째 열을 기준으로 내림차순 정렬하는 쿼리

SELECT * FROM TABLE_NAME
ORDER BY 1, 3 DESC;