그리디 알고리즘은 현재 상태에서 보는 선택지 중 최선의 선택지가 전체 선택지 중 최선의 선택지라고 가정하는 알고리즘이다.

쉽게 말해 매 선택에서 지금 이 순간 당장 최적인 답을 선택하여 적합한 결과를 도출하자 하여 전체적인 최적 해를 찾는 알고리즘이다.

그리디 알고리즘 단점

그리디 알고리즘은 지금 당장 좋은 것만 고르는 방법으로, 현재의 선택이 나중에 미칠 영향은 고려하지 않는다.

💡 [문제] 노드에서 가장 합이 높은 방법을 선택하는 방법을 생각해 봅니다.

최적의 선택: 3+100=103 그리디한 선택: 10+8=18

첫번 째 단계에서 최적이지만 미래 선택까지 포함한다면 최적의 알고리즘이 아닐 수 있다.

그리디 알고리즘을 통해 문제를 해결하는 방법

👉 탐욕 알고리즘 문제를 해결하는 방법

1. 선택 절차(Selection Procedure): 현재 상태에서의 최적의 해답을 선택한다.
2. 적절성 검사(Feasibility Check): 선택된 해가 문제의 조건을 만족하는지 검사한다.
3. 해답 검사(Solution Check): 원래의 문제가 해결되었는지 검사하고, 해결되지 않았다면 선택 절차로 돌아가 위의 과정을 반복한다.

탐욕 알고리즘 예시

❗️탐욕 알고리즘을 일상 예시 1 – 매트로이드

하나몬은 오늘도 편의점에서 열심히 아르바이트하고 있다. 손님으로 온 박해커는 과자와 음료를 하나씩 집어 들었고, 물건 가격은 총 4,040원이 나왔다. 박해커는 계산을 하기 위해 5,000원을 내밀며, 거스름돈은 동전의 개수를 최소한으로 하여 거슬러 달라고 하였다.

👉 이때 하나몬은 어떻게 거슬러 주어야 할까?

• 탐욕 알고리즘으로 동전의 개수를 헤아리는 일은 일반적으로 거스름돈으로 동전을 선택하는 방법과 동일하다.

• 거스름돈 960원을 채우기 위해서 먼저 500원짜리 동전을 한 개를 선택한다.

• 그다음은 100원짜리 동전을 네 개 선택하고, 그다음엔 50원짜리 동전과 10원짜리 동전을 각각 하나씩 선택할 것이다.

  👉 탐욕 알고리즘의 문제 해결 과정을 적용

1. 선택 절차

• 거스름돈의 동전 개수를 줄이기 위해 현재 가장 가치가 높은 동전을 우선 선택한다.

2. 적절성 검사

• 1번 과정을 통해 선택된 동전들의 합이 거슬러 줄 금액을 초과하는지 검사한다.
• 초과하면 가장 마지막에 선택한 동전을 삭제하고, 1번으로 돌아가 한 단계 작은 동전을 선택한다.

3. 해답 검사

• 선택된 동전들의 합이 거슬러 줄 금액과 일치하는지 검사한다.
• 액수가 부족하면 1번 과정부터 다시 반복한다.

👉 이 과정을 통해 얻은 문제에 대한 해답

가장 가치가 높은 동전인 500원 1개를 먼저 거슬러 주고 잔액을 확인한 뒤, 이후 100원 4개, 50원 1개, 10원 1개의 순서대로 거슬러 준다.

참고 자료

https://velog.io/@falling_star3/%EA%B7%B8%EB%A6%AC%EB%94%94-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98Greedy-Algorithm

https://hanamon.kr/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%ED%83%90%EC%9A%95%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-greedy-algorithm/

https://www.youtube.com/watch?v=_IZuE7NIeW4&t=373s

https://hanamon.kr/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%ED%83%90%EC%9A%95%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-greedy-algorithm/

Spring에서 코드를 작성할 때 @Transaction을 자주 사용하곤했는데 DB에 무결성, 안전성을 보장해준다기에 사용하곤 했다. 하지만 어떤식으로 보장해주는지 잘 알지 못하는 것은 재대로 Spring을 사용하는 것이 아니기에 이번 기회에 정리해보려고한다.

선언적 트랜잭션 VS 프로그래밍적 트랜잭션

Spring에서는 Transaction 처리를 지원하는데 프로그래밍적 트랜잭션 처리와 선언적 트랜잭션을 지원해준다.

1. 프로그래밍적 트랜잭션

• Spring에서 제공하는 프로그래밍적 트랜잭션은 두 가지가 있다.
• TransactionTemplate(프로그래밍적 트랜잭션 사용 시 Spring에서 권장 함)
• PlatformTransactionManager

2. 선언적 트랜잭션

• 클래스, 메서드 위에 @Transactional을 추가해서 관리한다.

프로그래밍적 트랜잭션 =/= @Transactional

public class PointTransaction {

    private PointDao pointDao;
    private TransactionTemplate transactionTemplate;

    public void setPointDao(PointDao pointDao) {
        this.pointDao = pointDao;
    }

    public void setTransactionManager(PlatformTransactionManager transactionManager) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
        this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
    }

    public void invoke() {
        dolnternalTransaction();
    }

    public void dolnternalTransaction() throws Exception {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() { 
            protected void doInTransactionWithoutResult(TransactionStatus status) { 
                try { 
                    pointDao.plusPoint() //<--------------------주목
                } catch (Exeption ex) { 
                    status.setRollbackOnly(); 
                } 
            } 
        });
    }
}

TransactionTemplate은 개발자가 Transaction을 시작, 종료 시점을 명시적으로 결정할 수 있도록 Spring에서 제공하는 하나의 방법이다.

위 코드에서는 pointPlus()메소드를 사용하기위해 Try-Catch과 transactionManager를 주입받고 Transaction 속성을 설정해주고 execute 메서드 내에서 로직을 실행한다.트랜잭션 설정으 하기위해 상당히 많은 코드를 볼 수 있다.

선언적 트랜잭션 = @Transactional

@Transactional
public void plusPoint() { //<--------------------주목
    pointRepository.updatePoint(10);
}

@Transactional 포함된 메서드가 호출될 경우 Spring은 해당 메서드에 대한 프록시(프록시패턴 디자인 패턴 중 하나)를 만드는데, PlatformTransactionManager를 사용해 트랜잭션을 시작하고, 정상 여부에 따라 커밋 또는 롤백을 알아서 해준다.

@Transactional 어노테이션을 plusPoint 메서드에 선언했다. Spring이 plusPoint에 대한 프록시를 만들고 해당 로직이 잘 끝났으면 커밋 오류 나면 롤백을 시켜준다.

즉 프로그래밍적 트랜잭션에서는 번거롭게 Try-Catch문을 통해 Commit, RollBack을 해주어야했지만 Spring에서는 @Transactional 하나로 DB에 무결성, 안정성을 보장할 수 있다.

@Transactional annotation 지원 설정

1. 트랜잭션의 전파 유형

2. 트랜잭션의 격리 수준

3. 트랜잭션에 의해 래핑 된 연산에 대한 시간제한

트랜잭션의 전파 유형

트랜잭션 전파(Transaction propagation) 어떤 트랜잭션이 동작중인 과정에서 다른 트랜잭션을 실행할 경우 어떻게 처리하는 가에 대한 개념이다.

1. Required

기본 전파 유형. 트랜잭션이 이미 있는 경우 현재 메서드가 해당 트랜잭션에 참여합니다. 트랜잭션이 존재하지 않으면 메서드에 대한 새 트랜잭션이 생성합니다.

REQUIRED @Transactional(propagation = Propagation.REQUIRED) public void requiredExample(String user) { // ... }

REQUIRED는 Default 이므로 생략이 가능합니다.

@Transactional public void requiredExample(String user) { // ... }

2. Requires New

이 전파 유형은 항상 새 트랜잭션을 만듭니다 트랜잭션이 이미 존재하는 경우 새 트랜잭션이 완료될 때까지 일시 중단합니다.

Requires New

@Transactional(propagation = Propagation.REQUIRES_NEW) public void requiresNewExample(String user) { // ... }

3. Nested

이 전파 유형은 중첩된 트랜잭션을 생성함. 트랜잭션이 이미 존재하는 경우 새 트랜잭션이 생성되어 기존 트랜잭션 내에 중첩됨. 트랜잭션이 존재하지 않으면 새 트랜잭션이 생성됨.

nested @Transactional(propagation = Propagation.NESTED) public void nestedExample(String user) { // ... }

4. Supports

이 전파 유형은 트랜잭션이 이미 존재하는 경우 트랜잭션을 지원. 트랜잭션이 존재하면 해당 트랜잭션 내에서 현재 메서드가 실행. 트랜잭션이 존재하지 않으면 트랜잭션 없이 메서드가 실행.

Supports @Transactional(propagation = Propagation.SUPPORTS) public void supportsExample(String user) { // ... }

5. Mandatory

이 전파 유형은 트랜잭션이 이미 존재해야 합니다. 트랜잭션이 존재하지 않으면 예외가 발생합니다.

Mandatory @Transactional(propagation = Propagation.MANDATORY) public void mandatoryExample(String user) { // ... }

6. Not Supported

이 전파 유형은 트랜잭션을 지원하지 않음. 트랜잭션이 존재하면 현재 메서드가 실행되는 동안 트랜잭션이 일시 중단됨.

@Transactional(propagation = Propagation.NOT_SUPPORTED) public void notSupportedExample(String user) { // ... }

7. Never

이 전파 유형은 현재 메서드가 실행될 때 트랜잭션이 존재하지 않는지 확인한다. 트랜잭션이 존재하면 예외가 발생한다.

never @Transactional(propagation = Propagation.NEVER) public void neverExample(String user) { // ... }

트랜잭션의 격리 수준

1. Read Uncommitted

2. Read committed

3. Repeatable Read

4. Serializable

Spring Boot JPA 프로젝트에서 기본 격리 수준은 일반적으로 READ_COMMITTED임

Read Uncommitted

@Service
@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public class UserService {

    @Autowired  
    private UserRepository userRepository;  

    public void updateUser(User user) {  
        userRepository.save(user);  
    }  
}

이 격리 수준을 가진 트랜잭션은 다른 concurrent 트랜잭션의 커밋되지 않은 데이터를 읽습니다.

또한 Nonrepeatable read와 Phantom read가 모두 발생할 수 있음 즉 행을 다시 읽거나 범위 쿼리를 다시 실행할 때 다른 결과를 얻을 수 있음

Read Committed

@Service
@Transactional(isolation = Isolation.READ_COMMITTED)
public class UserService {

    @Autowired  
    private UserRepository userRepository;  

    public User getUserById(Long id) {  
        return userRepository.findById(id)  
            .orElseThrow(() -> new EntityNotFoundException("User not found"));  
    }  
}

concurrent 트랜잭션에서 커밋되지 않은 변경 사항은 영향을 미치지 않지만, 트랜잭션이 변경 사항을 커밋하면 다시 쿼리 하여 결과가 변경될 수 있음

Repeatable Read

@Service
@Transactional(isolation = Isolation.REPEATABLE_READ)
public class UserService {

    @Autowired  
    private UserRepository userRepository;  

    public User getUserById(Long id) {  
        return userRepository.findById(id)  
            .orElseThrow(() -> new EntityNotFoundException("User not found"));  
    }  
}

concurrent 트랜잭션에서 커밋되지 않은 변경 사항의 영향을 받지 않음 단)한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타남

트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 나타나는 현상임

Serializable

@Service
@Transactional(isolation = Isolation.SERIALIZABLE)
public class UserService {

    @Autowired  
    private UserRepository userRepository;  

    public User getUserById(Long id) {  
        return userRepository.findById(id)  
            .orElseThrow(() -> new EntityNotFoundException("User not found"));  
    }  
}

앞서 언급한 모든 동시성 부작용을 방지하지만, concurrent 호출을 순차적으로 실행함 즉 트랜잭션 그룹을 정말로 serial 하게 실행하는 것과 동일한 결과를 가져옴

참고자료

https://itjava.tistory.com/33 https://colevelup.tistory.com/34 https://www.youtube.com/watch?v=taAp_u83MwA&t=219s

Blocking: 자신의 작업을 진행하다가 다른 주체에 어떠한 요청을 했을 때 다른 주체에 작업이 끝날 때까지 기다렸다가 자신의 작업을 시작하는 것

Non-Blocking: 다른 주체의 작업 완료와 관련없이 자신의 작업을 하는 것

위 둘의 가장 큰 차이점은 다른 주체가 작업을 할 때 자신의 제어권 유무임

• Blocking은 제어권이 없음
• Non-Blocking은 제어권 있음

동기(Sync)와 비동기(Async)

동기(Sync): 요청한 작업이 끝나는 동시에 해당 작업의 결과 값을 바로 처리함

비동기(Async):요청한 작업이 끝나도 해당 작업의 결과를 처리할 수도 안 할 수도있음

위 둘의 가장 큰 차이점은 요청 결과를 돌려 받았을 때 결과 완료 여부에 대한 관심도

• 동기는 요청 작업 완료 결과에 관심이 많아 결과를 받고 바로 처리함
• 비동기는 요청 작업 완료 결과 값에 관심이 적어 결과를 받고 처리할 수 도 있고 안 할 수도 있음

비동기의 성능 이점

보통 비동기 특징을 이용하여 성능과 연관지어 말한다. 왜냐하면 요청한 작업에 대하여 완료 여부를 신경쓰지 않고 자신의 그다음 작업을 수행한다는 것은, I/O 작업과 같은 느린 작업이 발생할 때, 기다리지 않고 다른 작업을 처리하면서 동시에 처리하여 멀티 작업을 진행할수 있기 때문이다. 이는 전반적인 시스템 성능 향상에 도움을 줄 수 있다.

4가지 조합

1. Sync Blocking (동기 + 블로킹) 2. Async Blocking (비동기 + 블로킹) 3. Sync Non-Blocking (동기 + 논블로킹) 4. Async Non-Blocking (비동기 + 논블로킹)

Sync Blocking 조합

Sync Blocking 조합은 다른 작업이 진행되는 동안 자신의 작업을 처리하지 않고 (Blocking), 다른 작업의 완료 여부를 바로 받아 순차적으로 처리하는 (Sync) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 주는 경우에 활용할 수 있다.

적용 프로그램 예시

대표적으로 C나 JAVA의 코드 실행 후 커맨드에서 입력을 받는 경우가 이에 해당된다. 사용자로부터 입력을 받아야 그 입력값을 가지고 내부 처리를 하여 결과값을 콘솔에 출력해주기 때문에 순차적인 작업이 요구된다. 내부적으로 본다면 실행 코드가 콘솔창을 띄우고 Please enter your name 텍스트를 치고 난 다음 사용자의 리턴값이 필요하기 때문에 제어권을 시스템에서 사용자로 넘겨 사용자가 값을 입력할때까지 기다리는 것이다.

Async Non-Blocking 조합

Async Non Blocking 조합은 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고 (Non Blocking), 다른 작업의 결과를 바로 처리하지 않아 작업 순서가 지켜지지 않는 (Async) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 주지 않은 경우에 활용할 수 있다.

적용 프로그램 예시

웹 브라우저의 파일 다운로드가 비동기 논블로킹을 활용하는 예시 라고 할 수 있다. 웹 브라우저는 웹 사이트에서 파일을 다운로드할 때, 파일의 전송이 완료될 때까지 다른 작업을 하지 않고 기다리는 것이 아니라, 다른 탭이나 창을 열거나 웹 서핑을 할 수 있다. 이는 웹 브라우저가 파일 다운로드를 비동기적으로 처리하고, 콜백 함수를 통해 다운로드가 완료되면 알려주는 방식으로 구현되어 있기 때문이다.

Sync Non-Blocking 조합

Sync Non-Blocking 조합은 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고 (Non Blocking), 다른 작업의 결과를 바로 처리하여 작업을 순차대로 수행 하는 (Sync) 방식이다.

해당 케이스는 흔히 사용되지 않는다.

Async Blocking 조합

Async Blocking 조합은 다른 작업이 진행되는 동안 자신의 작업을 멈추고 기다리는 (Blocking), 다른 작업의 결과를 바로 처리하지 않아 순서대로 작업을 수행하지 않는 (Async) 방식이다. Async-blocking 의 경우는 실무에서 잘 마주하기 쉽지 않아 다룰일이 거의 없다. 그래서 그냥 넘어가도 크게 문제는 없다.

안티 패턴인 Async Blocking

Sync-blocking 수행과 큰 차이가 없다. 보통 Async-blocking은 개발자가 비동기 논블록킹으로 처리 하려다가 실수하는 경우에 발생하거나, 자기도 모르게 블로킹 작업을 실행하는 의도치 않은 경우에 사용된다. 그래서 이 방식을 안티 패턴(anti-pattern)이라고 치부하기도 한다.

자료 출처

https://www.youtube.com/watch?v=oEIoqGd-Sns&t=516s

https://inpa.tistory.com/entry/%F0%9F%91%A9%E2%80%8D%F0%9F%92%BB-%EB%8F%99%EA%B8%B0%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%B8%94%EB%A1%9C%ED%82%B9%EB%85%BC%EB%B8%94%EB%A1%9C%ED%82%B9-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC

https://sujinhope.github.io/2021/06/13/Network-%EB%8F%99%EA%B8%B0vs%EB%B9%84%EB%8F%99%EA%B8%B0,-%EB%B8%94%EB%A1%9C%ED%82%B9vs%EB%85%BC%EB%B8%94%EB%A1%9C%ED%82%B9%EC%9D%98-%EC%B0%A8%EC%9D%B4.html

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 통신 규칙 세트 또는 프로토콜이다.

Ex) 사용자가 웹 사이트에 방문해서 웹 브라우저를 통해 웹서버에 HTTP 요청을 전송하면 웹서버에서는 HTTP 응답을 한다.

HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동하며 80포트에서 사용한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Start Line(Status Line), Headers, Body 등으로 구성된다.

HTTP Request Message

HTTP Response Message

HTTP는 무상태성이라는 장점으로 서버확장성이 높다는 장점이 있지만 치명적인 보안 단점이 있다. 데이터를 주고 받을 때 평문 데이터를 전송하는 프로토콜이기 때문에 비밀번호나 주민등록번호를 주고 받으면 제 3자가 정보를 조회할 수 있다는 점이다. 이러한 문제를 해결하기 위해 등장한 것이 HTTPS다.

HTPPS란?

HTTPS는 HTTP에 SSL을 사용하여 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

HTTP 자체를 암호화 하는 것이 아닌 HTTP 메세지 BODY를 암호화 한는 것이다.

SSL

Secure Sokects Layer의 약자이며 웹 서버와 웹 브라우저간 보안을 위해 만든 프로토콜이다. 대칭키/ 비대칭 기반을 사용한다.

대칭키 암호화와 비대칭키 암호화

앞서 언급하였듯이 SLL을 사용하는 HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하고 있다. 각각의 암호화 방식은 다음과 같다.

대칭키 암호화

• 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
• 키가 노출되면 매우 위험하지만 연산 속도가 빠름

비대칭키 암호화

• 1개의 쌍으로 구성된 각각의 공개키와 개인키를 암호화/복호화 하는데 사용함
• 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

비대칭키 암호화

암호화를 공개키로 하느냐 개인키로 하느냐에 따라 얻는 효과가 다른데, 공개키와 개인키로 암호화하면 각각 다음과 같은 효과를 얻을 수 있다.

공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. *-> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다. *

개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS 동작과정

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있다.

처음 연결을 성립하여 안전하게 세션키를 공유하는 과정(HTTPS 연결 과정 Hand-Shaking)에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다

그렇다면 가장 중요한 내용인 HTTPS의 동작 방식에 대해서 알아보자.

HTTPS의 경우 웹 브라우저와 웹 서버말고 추가적으로 CA(Certificate Authority)라는 인증 기관이 추가되어 웹 브라우저, 웹 서버, CA 세개의 주체가 키를 주고 받으며 하나의 대칭키를 생성한다고 생각할 수 있다.

1. 웹 서버(사이트)에서 인증기관(CA)에게 사이트 정보와 사이트 공개키를 전송한다.

2. 인증기관에서는 전달받은 데이터를 검증 후 인증기관의 개인키로 암호화(서명)한다.

3. 사이트 인증서가 생성되어 이 인증서를 웹 서버(사이트)에게 인증서를 전달한다.

4. 그후, 인증기관(CA)은 웹 브라우저(사용자)에게 인증기관의 공개키를 제공하고 사용자 브라우저에 자동으로 내장된다.

5. 모든 준비가 끝나고 웹 브라우저(사용자)는 웹 서버(사이트)에게 접속을 요청한다.

6. 웹 서버(사이트)는 웹 브라우저(사용자)에게 인증기관(CA)에서 받은 사이트 인증서를 준다.

7. 웹 브라우저(사용자)는 인증기관 공개키를 사용하여 사이트 인증서를 복호화하여 사이트 정보와 사이트 공개키를 얻을 수 있다.

8. 사이트 공개키를 활용하여 사용자는 통신에 사용할 대칭키(세션키)를 암호화하여 웹 서버(사이트)에게 전달한다.

9. 웹 서버(사이트)는 자신이 가지고 있는 개인키를 활용하여 대칭키(세션키)를 복호화하여 대칭키를 얻는다.

10. 이후 대칭키를 활용하여 암호화하여 통신을 진행한다.

참고자료

99CORN- HTTP Request/Response 구조

https://velog.io/@hyoribogo/what-is-the-defference-between-http-and-https https://mangkyu.tistory.com/98

https://rnclf1005.tistory.com/11 https://www.youtube.com/watch?v=wPdH7lJ8jf0&t=339s

행위 패턴은 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴으로 총 11개의 패턴이 있다.

행위 패턴은 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다.

결론적으로 행위 패턴은 코드의 유지보수성과 가독성을 향상시키며 재사용성을 증가시킨다.

이터레이터 패턴

11가지의 행위 패턴 중 오늘은 이터레이터 패턴에 대해서 정리해보려고한다.

이터레이터 패턴이란?

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

쉽게 말해 이터레이터를 하나 만들어 두면 어떤 구조의 컬렉션이든 순회할 수 있다.

• 컬렉션: 객체들을 묶어 자료의 구조를 취하는 데이터 집합(ex 리스트, 트리 , 그래프)

for문을 통해 단순 순회하면 되지 않는가?

리스트나 보통배열의 경우 연속적인 데이터 집합이기 때문에 간단한 for문으로 순회할 수 있다. 하지만 해시, 트리와 같은 컬렉션은 데이터 저장순서가 정해지지 않고 적재되기 때문에, 각 요소들을 어떤 기준으로 접근해야할지 애매해진다.

이처럼 복잡하게 얽혀있는 자료 컬렉션들을 순회하는 알고리즘 전략을 정의하는 것을 이터레이터 패턴이라고 한다.

컬렉션 객체 안에 들어있는 모든 원소들에 대한 접근 방식이 공통화 되어 있다면 어떤 종류의 컬렉션에서도 이터레이터만 뽑아내면 여러 전략으로 순회가 가능해 보다 다형(多形) 적인 코드를 설계할 수 있게 된다

이밖에도 이터레이터 패턴은 별도의 이터레이터 객체를 반환 받아 이를 이용해 순회하기 때문에, 집합체의 내부 구조를 노출하지 않고 순회 할 수 있다는 장점도 있다.

이터레이터 패턴 구조

이터레이터 패턴의 4가지 구성요소는 아래와 같다.

Aggregate (인터페이스) : ConcreateIterator 객체를 반환하는 인터페이스를 제공한다.

• iterator() : ConcreateIterator 객체를 만드는 팩토리 메서드

• 쉽게 컬렉션이라고 볼 수 있음

ConcreateAggregate (클래스) : 여러 요소들이 이루어져 있는 데이터 집합체 Iterator (인터페이스) : 집합체 내의 요소들을 순서대로 검색하기 위한 인터페이스를 제공한다.

• hasNext() : 순회할 다음 요소가 있는지 확인 (true / false)
• next() : 요소를 반환하고 다음 요소를 반환할 준비를 하기 위해 커서를 이동시킴

ConcreateIterator (클래스) : 반복자 객체

• ConcreateAggregate가 구현한 메서드로부터 생성되며, ConcreateAggregate 의 컬렉션을 참조하여 순회한다.
• 어떤 전략으로 순회할지에 대한 로직을 구체화 한다.

코드구현

// 집합체 객체 (컬렉션)
interface Aggregate {
    Iterator iterator();
}

class ConcreteAggregate implements Aggregate {
    Object[] arr; // 데이터 집합 (컬렉션)
    int index = 0;

    public ConcreteAggregate(int size) {
        this.arr = new Object[size];
    }

    public void add(Object o) {
        if(index < arr.length) {
            arr[index] = o;
            index++;
        }
    }

    // 내부 컬렉션을 인자로 넣어 이터레이터 구현체를 클라이언트에 반환
    @Override
    public Iterator iterator() {
        return new ConcreteIterator(arr);
    }
}

// 반복체 객체
interface Iterator {
    boolean hasNext();
    Object next();
}

class ConcreteIterator implements Iterator {
    Object[] arr;
    private int nextIndex = 0; // 커서 (for문의 i 변수 역할)

    // 생성자로 순회할 컬렉션을 받아 필드에 참조 시킴
    public ConcreteIterator(Object[] arr) {
        this.arr = arr;
    }

    // 순회할 다음 요소가 있는지 true / false
    @Override
    public boolean hasNext() {
        return nextIndex < arr.length;
    }

    // 다음 요소를 반환하고 커서를 증가시켜 다음 요소를 바라보도록 한다.
    @Override
    public Object next() {
        return arr[nextIndex++];
    }
}

사용 흐름

public static void main(String[] args) {
    // 1. 집합체 생성
    ConcreteAggregate aggregate = new ConcreteAggregate(5);
    aggregate.add(1);
    aggregate.add(2);
    aggregate.add(3);
    aggregate.add(4);
    aggregate.add(5);

    // 2. 집합체에서 이터레이터 객체 반환
    Iterator iter = aggregate.iterator();

    // 3. 이터레이터 내부 커서를 통해 순회
    while(iter.hasNext()) {
        System.out.printf("%s → ", iter.next());
    }
}

이터레이터 패턴 특징

패턴 사용 시기

• 컬렉션에 상관없이 객체 접근 순회 방식을 통일하고자 할 때
• 컬렉션을 순회하는 다양한 방법을 지원하고 싶을 때
• 컬렉션의 복잡한 내부 구조를 클라이언트로 부터 숨기고 싶은 경우 (편의 + 보안)
• 데이터 저장 컬렉션 종류가 변경 가능성이 있을 때
• 클라이언트가 집합 객체 내부 표현 방식을 알고 있다면, 표현 방식이 달라지면 클라이언트 코드도 변경되어야 하는 문제가 생긴다.

패턴 장점

• 일관된 이터레이터 인터페이스를 사용해 여러 형태의 컬렉션에 대해 동일한 순회 방법을 제공한다.
• 컬렉션의 내부 구조 및 순회 방식을 알지 않아도 된다.
• 집합체의 구현과 접근하는 처리 부분을 반복자 객체로 분리해 결합도Visit Website를 줄 일 수 있다.
• Client에서 iterator로 접근하기 때문에 ConcreteAggregate 내에 수정 사항이 생겨도 iterator에 문제가 없다면 문제가 발생하지 않는다.
• 순회 알고리즘을 별도의 반복자 객체에 추출하여 각 클래스의 책임을 분리하여 단일 - 책임 원칙(SRP)Visit Website를 준수한다.
• 데이터 저장 컬렉션 종류가 변경되어도 클라이언트 구현 코드는 손상되지 않아 수정에는 닫혀 있어 개방 폐쇄 원칙(OCP)Visit Website를 준수한다.

패턴 단점

• 클래스가 늘어나고 복잡도가 증가한다.
• 만일 앱이 간단한 컬렉션에서만 작동하는 경우 패턴을 적용하는 것은 복잡도만 증가할 수 있다.
• 이터레이터 객체를 만드는 것이 유용한 상황인지 판단할 필요가 있다.
• 구현 방법에 따라 캡슐화를 위배할 수 있다.

참고자료

InpaDev-반복자Iterator-패턴-완벽-마스터하기

GIS DEVELOPER-GoF의 Design Pattern - 2. Iterator(유튜브)

호락호락한순무-[Dev] 디자인 패턴 중 행위 패턴이란 무엇이지 알아보자

공통적으로 발생하는 문제에 대해서 재사용 가능한 해결책을 의미한다. 다른 상황에 맞게 사용될 수 있는 문제를 해결하는데 사용되는 템플릿임

디자인 패턴을 학습하면 확장성이 높고 유연한 개발이 가능해진다.

GOF의 디자인 패턴은 3가지로 나뉜다 생성 패턴, 행위 패턴, 구조 패턴 오늘은 구조 패턴과 그 중 데코레이터 패턴을 알아보려고한다.

구조 패턴이란?

클래스와 객체를 더 큰 구조로 만들 수 있게 구성을 사용하는 패턴을 의미한다. 보통 규모가 있는 객체지향 프로그램을 구현할 경우 사용된다.

• 독립적으로 개발한 클래스 라이브러리를 마치 하나인 것처럼 사용
• 여러 인터페이스를 합성하여 서로 다른 인터페이스들의 통일된 추상을 제공
• 인터페이스나 구현을 복합하는 것이 아니라 객체를 합성하는 방법을 제공

데코레이터 패턴

데코페이터 패턴은 뜻 그대로 기능을 마치 장식처럼 계속 추가할 수 있는 패턴이다. 심지어 실행 중에 동적으로 기능을 변경 또는 확장을 할 수 있는 패턴이다.

데코레이터 패턴의 핵심은 Composition과 다형성이다.

Composition(구성)은 상속과 다르다. 상속은 고정된 특성을 물려받는 것이고, 구성은 필요한 기능을 포함하여 유연하게 조합할 수 있는 방식 상속: 부모 클래스를 오버라이딩해서 메소드를 재정의 구성: 부모 클래스를 Private 변수로 가져와서 해당 기능을 사용

상속과 구성에 자세한 내용은 이곳을 참고

클래스 다이어그램 예시

Strings는 문자열을 여러개 가지고 있는 클래스이며 장식 당하는 대상 Decorator는 String을 장식할 클래스임 Item 클래스를 통해서 Strings와 Decorator를 사용할 수 있게된다.

실제 사용 사례

Item을 인터페이스를 통해 클래스를 구현한다면 기본적인 문자열로 이루어진 String 클래스에 Decorator 클래스 기능을 유연하게 확장할 수 있다.

SideDecorator 클래스는 문자열에 쌍따옴표 BoxDecorator 클래스는 문자열에 박스 LineNumberDecorator 클래스는 번호를 각각 추가할 수 있다

기능을 추가하고 싶으면 위와 같이 각 데코레이터 클래스를 추가해주면 된다.

참고 코드

** Item 클래스 **

** String 클래스 **

** Decorator 클래스 **

** LineNumberDecorator 클래스 **

** 사용 코드 **

참고 자료

GIS DEVELOPER- GoF의 Design Pattern - 15. Decorator <-- 다른 디자인 패턴에 대한 내용도 동영상으로 잘 정리해둠 Design Pattern : 구조 패턴(Structural Patterns) SCB 개발자 이야기- 디자인패턴이란?

• DB 종류 선택
  • 데이터베이스 생성 방식 선택: 표준 생성
  • Mysql
• DB 설정 입력
  • 템플릿: 프리 티어
  • DB 인스턴스 식별자에 원하는 데이터베이스 이름을 입력하고 마스터 사용자 이름과 마스터 암호 입력
  • 데이터베이스 이름, 마스터 이름, 비밀번호는 실제로 DB에 접근할 때 사용할 정보이므로 신중하게 입력하고 반드시 기억해두어야 한다

• 스토리지 자동 조정 활성화 해제

  

- 체크했을 경우 : 개발 진행 중 임계값이 초과되는 경우 자동으로 스토리지가 늘어나 추가 금액이 붙을 수 있음!

• 보안그룹 설정(연결)

  • 퍼블릭 엑세스: 예
  • VPC 보안 그룹(방화벽): 새로 생성 클릭 → 새 VPC 보안 그룹 이름 입력

• 추가 구성

  • 백업: '자동 백업을 활성화합니다' 체크 해제
  • 유지 관리: '마이너 버전 자동 업그레이드 사용' 체크 해제

  ---

2. 현재 보안 그룹 확인

1. RDS 인바운드 규칙에 EC2 보안 그룹 ID 입력
   • '인바운드 규칙 편집' 클릭 → 규칙 추가 클릭하여 새 인바운드 규칙 작성 후 저장
   • 새 인바운드 규칙 내용
     • 유형: MYSQL/Aurora
     • 프로토콜: TCP
     • 포트 범위: 3306
     • 소스: 사용자...

3. 파라미터 그룹 설정

• 파리미터 그룹 생성

• Time Zone, Character set, Collation, Max Connection 설정

파라미터 그룹 클릭 후 편집 눌러서 값 변경하기 아래처럼 변경하기

• timezome→ Asia/Seoul
• max_connections → 150
• 파라미터 char_ -> 값 utf8로 변경
• collaction_ -> 값 utf8mb4_general_ci

• RDS 파라미터 그룹 변경
  • RDS 인스턴스 이동 → 수정 클릭
  • DB 파라미터 그룹을 새로 생성한 파라미터 그룹으로 변경 (ex. my-rds-parameter-group)
  • DB 인스턴스 수정 사항 확인
  • 수정 예약은 '즉시 적용' 선택하고 'DB 인스턴스 수정' 클릭

4. RDS 접속 테스트

1. 로컬 PC 접속

MySQL Workbench에 New Connection 생성

• Hostname: RDS 엔드포인트

• Username: RDS 생성 시 입력했던 정보 (마스터 사용자 이름)

• Password: RDS 생성 시 입력했던 정보 (마스터 암호)

2. EC2에서 접속

# ubuntu에서 MySQL 설치
sudo apt-get update
sudo apt-get install mysql-server

# MySQL 명령어로 접속 시도
mysql -u {마스터 사용자 이름} -p --host {엔드포인트}

참고자료

https://rovemin.tistory.com/27 ← main 자료

https://debut12.tistory.com/34 ← 보조 자료

• AMI: Ubuntu 선택
• 키페어
  • 키페어명은 내가원하는 이름
  • 키페어 유형은 RSA
  • 프라이빗 키파일 형식은 .pem

다운 받은 후 다시 다운 불가하기 때문에 잘 저장해두기

• 네트워크 설정
  • 보안 그룹 선택 후 내 IP에서 SSH 트래픽 허용 (NACL단에서 설정하는 것임)
• 스토리지 구성
  • 1X 30 gib gp2 루트 볼륨

인스턴스 시작하기

2. 탄력적 IP 추가

AWS EC2 인스턴스는 서버를 중지하고 다시 실행시키면 퍼블릭 IP 가 변경되기 때문에 클라이언트가 사용할 수 있는 변하지 않는 IP 가 필요하다.

탄력적 IP (Elastic IP) 란 외부에서 인스턴스에 접근 가능한 고정 IP 입니다.

탄력적 IP 는 만들어놓고 사용하지 않더라도 과금이 되기 때문에 필요한 만큼만 생성하는 것이 중요하다.

• 위 사진처럼 탄력적 ip에서 탄력적 ip 주소 할당 클릭 후 탄력적 IP 생성

• 생성한 탄력적 ip에 인스탄스 연결하기

  • 퍼블릭 IPv4 주소

  • 프라이빗 IPv4 주소

    위 주소 연결해주고 인스턴스에서 탄력적 ip로 변경되었는지 확인

3. 보안 그룹 설정

인스턴스 정보 요약 화면에서 하단에 ‘보안’ 클릭

즉 내가 선택하고 싶은 인스탄스 보안 그룹에서 인바운드 규칙을 추가해준다.

[SG 규직 설정]

4. Ec2 접속 해보기

참고 블로그 :https://velog.io/@spamdong/PuTTy-설치-및-사용법

PuTTy란?

• 암호화 기능을 비롯 수 많은 기능을 포함하고 있어 윈도우에서 리눅스 환경으로 접속하는데 가장 좋은 프로그램

왜 사용해야하는가?

• 아래 사진은 AWS Doc이다. PuTTy를 사용하는 방법이 있는 것을 확인할 수 있을정도로 자주 사용됨
• 이전 작업 내용을 확인이 가능함(Log)
• PuTTY는 한번 설정한 사용자 환경은 저장이 되어있어 있기 때문에 재 실행시 이전 환경을 그대로 유지가 가능(글자 크기, 글자 색깔)

Putty로 EC2 접근 과정

• HostName에 아까 받은 인스탄스의 퍼블릭 IPv4 주소 입력

• Auth-SSH-Credantial에서 privatekey 넣어주기

참고로 puttygen을 통해pem키를 ppk로 변경한 상태다. 이 내용이 궁금하면 참고한 블로그를 확인하길 바란다.

• login as: ubuntu 입력해주고 접속하기

5. EC2에 자바 설정

1. JDK 설치 (Java 17 설치)

sudo apt-get update
sudo apt-get install openjdk-17-jdk

참고자료

https://rovemin.tistory.com/27 ← main 자료

https://bcp0109.tistory.com/356 ← Ec2 설정 추가 자료

https://velog.io/@spamdong/PuTTy-설치-및-사용법 ← putty 사용법

키워드 throw를 사용해서 프로그래머가 고의로 예외를 발생시킬 수 있다.

방법 1 . 연산자 new를 이용해서 발생시키려는 예외 클래스의 객체를 만든다.

 Exception e= new Exception("고의로 발생시킴");

2 . 키워드 throw를 이용해서 예외를 발생시킨다.

 throw e

• 객체를 만드는 것으로 예외가 발생하는 것이 아니라 throw로 던져야지 발생하게 됨
• "고의로 발생시킴" 이라는 매개변수로 넘긴 문자열은 printStackTrave()나 getmessage()로 확인할 수 있다.

예시 코드

아래 예시처럼 throw new Exception("고의로 발생시켰음.") 처럼 한줄로 예외 발생시키고 던지는 것을 더 많이 사용한다.

class Tes {
    public static void main(String[] args) {
        try {
            Exception e = new Exception("고의로 발생시켰음.");
            throw e; // 예외를 발생시킴
//            throw new Exception("고의로 발생시켰음."); // 위  두 줄을 한 줄로 작성
        } catch(Exception e) {
            System.out.println("에러 메시지 : " + e.getMessage());
            e.printStackTrace();
        }
        System.out.println("프로그램이 정상 종료되었음.");
    }
}

📌 Throws: 메서드 예외 선언하기

throw는 예외를 생성하는 키워드라는 것을 알았다. 하지만 비슷하게 생긴 throws는 완전 다른 역할인 예외를 처리하는 방법 중 하나다.

예외를 처리하는 방법은 다음 2가지 방법이 있다.

• try-catch: 예외가 발생한 곳에서 바로 처리
• throws: 메소드 내에서 발생할 수 있는 예외를 선언하고 호출한 곳으로 던져서 처리 단 호출한 곳에서 try-catch로 예외를 처리해줘야함

방법 예외가 여러 개인 경우 쉼표(,)로 구분한다.

  void method() throws Exception1, Exception2, ... ExceptionN {
         // 메서드의 내용
    }

만약 아래와 같이 모든 예외의 최고 조상인 Exception 클래스를 메서드에 선언하면, 이 메서드는 모든 종류의 예외가 발생할 가능성이 있다는 뜻

void method() throws Exception {
         // 메서드의 내용
    }

예시 코드

class ExceptionEx14 {
    public static void main(String[] args) {
        try  {
                method1();        
        } catch (Exception e)    {
                System.out.println("main메서드에서 예외가 처리되었습니다.");
                e.printStackTrace();
        }
    }    // main메서드의 끝

    static void method1() throws Exception {
        throw new Exception();
    }    // method1()의 끝
} // class의 끝

1. method1 () 메소드에서 발생할 수 있는 예외를 throws 옆에 정의해줌
2. main메소드에서 method1() 메소드 호출
3. method1 () 메소드에서 예외발생
4. method1 () 메소드 호출하며 발생된 예외가 main메소드로 넘어옴
5. main메소드의 catch문에서 예외처리

📌 참고 자료

송병훈-Java의 정석 정리 (예외처리)

두 날짜 사이의 차이를 계산을 도와주는 Period.between() 을 사용하여 알 수 있다.

LocalDateTime

LocalDateTime은 날짜 데이터와 시간 데이터를 가지는 클래스다. (LocalDate는 날짜만 저장)

두 LocalDateTime 인스턴스의 차이를 구하는 메서드는 존재하지 않아 위에서 언급한 Period.between()를 사용한다.

Period 와 Duration

Period.between()

사용 예제

LocalDate startDate = LocalDate.of(1939, 9, 1);
LocalDate endDate = LocalDate.of(1945, 9, 2);

Period period = Period.between(startDate, endDate);

System.out.println("Years: " + period.getYears());
System.out.println("Months: " + period.getMonths());
System.out.println("Days: " + period.getDays());

결과

Years: 6
Months: 0
Days: 1

두 LocalDateTime 인스턴스 사이의 년, 월, 일 차이를 구하기 위해서는 Period 클래스의 between() 메서드를 사용   Period.between() 메서드 특징

• 두 날짜 사이의 간격을 년/월/일 단위로 반환한다.
• "x년 y개월 z일" 형식의 데이터가 반환된다. 따라서, getDays() 메서드를 호출하면 두 날짜 사이의 일수가 아닌 "z일" 부분만 반환된다.
  • getYears()
  • getMonths()
  • getDays()

Duration.between()

사용 예제

LocalTime start = LocalTime.of(10, 35, 40);
//10시 35분 40초
LocalTime end = LocalTime.of(10, 36, 50, 800);
//10시 36분 50초 800나노초
Duration duration = Duration.between(start, end);

System.out.println("Seconds: " + duration.getSeconds());
System.out.println("Nano Seconds: " + duration.getNano());

결과

Seconds: 70
Nano Seconds: 800

• 두 시간 사이의 간격을 초나 나노 초 단위단위로 반환한다.
• getSeconds() 사용시 초, getNano() 나노초 반환

Period로 사이 기간 구하기

1.  LocalDateTime을 LocalDate로 변환

만약 날짜를 LocalDateTime형식으로 받는다면 시간 데이터는 분리한다.

xxxx년x월 ~xxxx년x월 사이에 기간을 구분해야 하기 때문에 시간 데이터는 필요 없다. 따라서 toLocalDate() 사용

사용 예시

LocalDateTime localDateTime = LocalDateTime.now();
System.out.println(localDateTime);
System.out.println(localDateTime.toLocalDate());

결과

2021-11-08T12:42:11.769062
2021-11-08

2. Period.between() 사용 하기

사용 예시

LocalDateTime registerAt = user.getRegisterAt();
 LocalDateTime nowRegisterAt = LocalDateTime.now();

 Period diff = Period.between(registerAt.toLocalDate(), nowRegisterAt.toLocalDate());


  System.out.printf("두 날짜 사이 기간: %d년 %d월 %d일",
          diff.getYears(), diff.getMonths(), diff.getDays());

diff.getYears(), diff.getMonths(), diff.getDays())메소드는 int형으로 반환 됨

결과

두 날짜 사이 기간: 1년 8월 22일

결과

System.out.println(diff);
P1Y8M22D

참고 자료

https://covenant.tistory.com/255

https://www.daleseo.com/java8-duration-period/

남궁성-자바의정석 P528~541

프로그램의 흐름을 직접 제어하는 것이 아니라 외부에 제어권을 넘겨 관리하게 하는 것을 제어의 역전이라고한다.

상세히 말하면 객체의 생성과 관리를 외부에서 한다면 제어권을 넘기게 되어 제어의 역전이 발생한 것이다.

프레임워크와 라이브러리

프레임워크는 제어의 역전 개념이 적용된 대표적인 기술이다. 프레임워크와 라이브러리를 구분할 때 IOC 개념이 중요하다.

Library

개발자는 필요한 Library 들을 선택하고, 연결하고, 설정하는 모든걸 다 직접 해야함

세부적으로 보면 라이브러리를 통해 객체를 생성하고 메소드를 호출하는 것을 개발자가 직접하기에 제어권이 코드 자체(개발자)에게 있는 것이다.

Framework

개발자가 직접 구현한것 혹은 Library 들을 연결하고, 설정하는 것들을 제공함

개발자가 기능 구현에 필요한 특정 코드를 프레임워크에 작성하면 프레임워크가 알아서 객체를 생성하고 메소드를 호출해준다. 즉 제어권이 프레임워크에 있는 것이다.

Spring 프레임워크에서의 IoC

스프링에서는 사용할 객체를 직접 생성하지 않고 객체의 생성과 생명주기 관련해서는 Spring 컨테이너에 위임을 하여 제어권을 넘기게 된다. 이것이 Spring에서의 제어의 역전 IoC다.

IoC를 통해 ID(의존성 주입), 관점 지향 프로그래밍(AOP)등이 가능해지는 것이다. 이번 포스팅 글에서는 Spring에서의 DI를 집중적으로 다루어 보려고 한다.

빈 등록

• 스프링 빈 자동 등록 방법: @Repository, @Service, @Contorller, @Component <-@ComponentScan

• 스프링 빈 수동 등록 방법: @Bean + Method

  참고 블로그 : 2가지 빈 등록 방식

빈 사용

• @Autowired

의존성 주입(DI)

의존성 주입은 제어 역전의 방법 중 하나로, 사용할 객체를 직접 생성하지 않고 외부 컨테이너가 생성한 객체를 주입받아 사용하는 방식이다.

@Autowired

스프링 컨테이너에서 객체를 찾아 의존 객체 타입에 맞게 넣어준다.

의존관계 주입의 4가지 방법

• 생성자 주입
• 수정자 주입
• 필드 주입
• 일반 메서드 주입

생성자 주입

쉬운 이해를 위한 코드

@Component
public class OrderServiceImpl implements OrderService {

     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;

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

• 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법
• Final 적용 가능하여 생성자 호출시점에 의존 객체가 딱 1번만 주입되는 것이 보장된다. 의존 객체를 변경하지 않을 경우에 사용함

실제 현업에서 사용하는 코드(@RequiredArgConstructor + private final)

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;


    /*  
      public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicydiscountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
 }
     */

}

• @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어줌
• 주석 처리된 생성자가 RequiredArgsConstructor로 인해 생성되었지만 안 보이는 것임

수정자 주입

@Component
public class OrderServiceImpl implements OrderService {

     private MemberRepository memberRepository;
     private DiscountPolicy discountPolicy;

     @Autowired
     public void setMemberRepository(MemberRepository memberRepository) {
             this.memberRepository = memberRepository;}

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

• setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용

필드 주입

@Component
public class OrderServiceImpl implements OrderService {

     @Autowired
     private MemberRepository memberRepository;

     @Autowired
     private DiscountPolicy discountPolicy;
}

• 이름 그대로 필드에 바로 주입하는 방법
• 코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있음

Test 코드를 짤 때 순수 자바로 단위 Test Code를 만든다고 한다.
스프링을 띄우고 하나 하나 테스트를 돌리면 굉장히 시간이 오래 걸리기 때문이다.

일반 메서드 주입

@Component
public class OrderServiceImpl implements OrderService {

     private MemberRepository memberRepository;
     private DiscountPolicy discountPolicy;

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

• 일반 메서드를 통해서 주입 받는 방법
• 한번에 여러 필드를 주입 받을 수 있다.
• 생성자 주입과 다를게 많이 없어서 많이 사용하지 않는다고 한다.

결론

항상 생성자 주입을 선택하고 그리고 가끔 의존 객체를 변경할 상황이 생긴다면 수정자 주입을 선택하면 된다. 일반 메서드 주입, 필드 주입은 사용하지 않는게 좋다.

참고자료

• Arron(ASAC_04)- Spring Boot 의 등장 및 특장점, 기본 Annotations
• 김영한- 스프링 기본편(DI편)
• 장정우- 스프링 부트 핵심가이드(P2~P11)
• bitkunst- DI, IOC...

프로그램이 예기치 못하게 종료될 수 있는 오류는 에러와 예외로 나뉘고 예외는 프로그래머가 미리 처리할 수 있다고 앞 포스팅 글에서 정리했었다. 이 개념을 바탕으로 예외처리에 대한 정의는 다음과 같다.

예외처리 : 프로그램 실행 시 발생할 수 있는 예기치 못한 예외의 발생에 대비한 코드를 작성하는 것

• 예외처리의 목적은 예외의 발생으로 인한 실행 중인 프로그램의 비정상적인 종료를 막고 정상적인 실행 상태를 유지하게 하는 것임

발생한 예외를 처리하지 못하면 비정상적으로 프로그램이 종료되며 화면에 에러 종류가 출력되는데 Uncaught exception(처리 되지 않은 예외)를 JVM의 Uncaught exception handler(예외처리기)가 받아서 예외의 원인을 화면에 출력해주는 것이다.

📌 Try-Catch로 처리하기

예외는 Try-Catch를 통해 처리할 수있다. Try 블록에는 예외가 발생할 수 있는 코드를 넣는다. Catch에는 예외가 발생할 경우, 이를 처리하는 문장을 넣는다.

작성 예시

try {
    // 예외가 발생할 가능성이 있는 문장들을 넣는다.

} catch (Exception1 e1) {
    // Exception1 이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
} catch (Exception2 e2) {
    // Exception2 이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
}  catch (Exception3 e3) {
    // Exception3 이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
}

코드 예시: try catch 특징

다음 코드에서 주목할 점은 에러가 발생하면 그 아래 코드는 실행되지 않는다는 것이다. System.out.println(0 / 0); 부분에서 ArithmeticException 에러가 발생했을 시 아래 System.out.println(4)코드는 실행되지 않는 것을 볼 수 있다.

따라서 예외가 발생한 위치 이후에 있는 try블럭의 문장들은 수행되지 않기 때문에 try 블럭에 포함시킬 코드의 범위를 잘 선택해야한다.

class aaaa {
    public static void main(String args[]) {
        System.out.println(1);
        System.out.println(2);
        try {
            System.out.println(3);
            System.out.println(0 / 0); // 0으로 나눠서 고의로 ArithmeticException 에러 발생.
            System.out.println(4); // 실행되지 않는다.

        } catch (ArithmeticException ae) {
            System.out.println(5);

        } // try-catch의 끝
        System.out.println(6);
    } 
}

출력값
1
2
3
5
6

Excecption 클래스 타입으로는 마지막에 처리하기

다음 예시에서 첫번째 catch문에서 ArithmeticException 예외를 잡아주어 두번째 catch블럭은 검사하지 않게 된다.

만약 try 블럭 내에서 ArithmeticException 이 아닌 다른 종류의 예외가 발생한 경우에는 두번째 catch블럭인 Exception 클래스 타입의 참조변수를 선언한 곳에서 처리되었을 것이다.

이렇게 마지막에 Exception 타입으로 catch 해주면 어떤 종류의 예외가 발생하더라도 이 catch블록 의해 처리하게할 수 있다.

주의할 점은 맨 앞 catch 블록에 Exception클래스 타입으로 예외를 잡으면 세부 예외를 파악하기 어렵기 때문에 맨 앞 catch에 Exception클래스 사용은 자제하는 것이 좋다.

class aaaa {
    public static void main(String args[]) {
        System.out.println(1);
        System.out.println(2);
        try {
            System.out.println(3);
            System.out.println(0 / 0); // 0으로 나눠서 에러 발생.
            System.out.println(4); // 실행되지 않는다.

        } catch (ArithmeticException ae) {
            if (ae instanceof ArithmeticException) {
                System.out.println("true");
      }
            System.out.println("ArithmeticException");

        } catch (Exception e) {
            System.out.println("Exception");
        } // try-catch의 끝
        System.out.println(6);
    } // main메서드의 끝
}

출력값.
1
2
3
true
ArithmeticException
6

📌 printStackTrace()와 getMessage()

예외가 발생하면 예외 객체가 생성된다. 예외객체 타입과 catch 블록에 참조변수 타입이 일치하면 예외 객체가 참조 변수에 할당된다.

예외 객체 내에는 예외에 관련된 정보가 들어있고, 객체의 예외 정보를 볼 수 있는 메소드는 여러개 있는데 그 중에서 대표적엔 메소드는 2개다.

• printStackTarce(): 예외발생 당시의 호출스택에 있었던 메서드의 정보와 예외 메시지를 화면에 츨력한다. Exception 이 발생한 이유와 위치는 어디에서 발생했는지 전체적인 단계를 다 출력

• getMessage(): 발생한 예외 클래스의 인스턴스에 저장된 메시지를 String으로 반환해준다. Exception의 유형도 없이 정말 간단하게 왜 에러가 발생하였는지 보여주기만함

사용 예시

아래 예시에서는 throw를 통해 예외를 발생시켰는데 다음 포스팅글에서 자세히 다루려고한다.

class Tes {
    public static void main(String[] args) {
        try {
            Exception e = new Exception("고의로 발생시켰음.");
            throw e; // 예외를 발생시킴
//            throw new Exception("고의로 발생시켰음."); // 위  두 줄을 한 줄로 작성
        } catch(Exception e) {
            System.out.println("에러 메시지 : " + e.getMessage());
            e.printStackTrace();
        }
        System.out.println("프로그램이 정상 종료되었음.");
    }
}

참고 log4에서는 e.printStackTrace()를 log 안에 담을수 없기 떄문에 log.error("error : ", e); 로 사용하면 된다.

📌 참고자료

주니어녕- e.toString(), e.getMessage(), e.printStackTrace() 예외처리

mingseok-예외처리하기 - try-catch문, 코드참고

남궁성- 자바의 정석 P414~P430

프로그램이 실행 중 오작동 하거나 비정상적으로 종료하게 하는 원인을 프로그램 에러, 오류 라고한다.

에러는 발생 시점에 따라 컴파일 에러, 런타임 에러로 나눌 수 있다. 이외에도 논리적 에러가 있는데 컴파일도 잘되고 실행도 잘되는데 의도와 다르게 동작하는 것을 의미한다.

에러 종류

컴파일 에러: 컴파일 시에 발생하는 에러

런타임 에러: 실행 시에 발행하는 에러

논리적 에러: 실행은 되지만, 의도와 다르게 동작하는 것

컴파일 에러 ex) 보통 문법에러로 int i="this is error",int형에 String타입 넣는 경우

런타임 에러 ex) 특정 객체가 매개변수로 값을 받아왔는데 값이 Null 인경우

논리적 에러 ex) 창고의 재고가 음수가 되는 경우, 게임 프로그램에서 비행기가 총알을 맞아도 죽지 않은 경우

📌 런타임 에러

런타임 에러 발생 시점

.java 파일을 -> .class 파일로 변환하는 과정을 컴파일이라는 것을 앞 포스팅글에서 정리했었다. 이 과정에서 컴파일러가 소스 코드의 오타, 잘못된 구문, 자료형 체크등을 다 해준 후 컴파일 오류 여부를 알려준다.

주목할 점은 컴파일 에러 없이 .class파일이 만들어 졌어도 프로그램 실행 시에 에러가 발생하지 않는 것은 아니다. 컴파일러가 실행도중에 발생할 수 있는 잠재적인 에러까지 검사할 수 없기 때문이다.

따라서 자바 프로그램 실행 중 많은 에러가 발생할 수 있고 런타임 에러가 발생할 수 있는 모든 경우의 수를 고려하여 대비하는 것이 좋다.

런타임 에러(오류) 종류

자바 프로그램 실행 시 발생할 수 있는 오류를 두가지로 구분할 수 있다.

에러 : 프로그램 코드에 의해서 수습될 수 없는 심각한 오류

예외 : 프로그램 코드에 의해서 수습될 수 있는 다소 미약한 오류

Error가 발생하면 프로그램의 비정상적인 종료는 막을 수 없지만, Exception은 발생하더라도 프로그래머가 이에 대한 적절한 코드를 미리 작성해 놓으면 프로그램의 비정상적인 종료를 막을 수 있다.

Error ex) 메모리 부족(OutOfMemoryError)이나 스택오버플로우(StackOverFlow) 같이 복구할 수 없는 오류

Exception ex) 특정 객체가 매개변수로 값을 받아왔는데 값이 Null 인경우

📌 예외 클래스 계층 구조

자바에서는 런타임 및 컴파일시 발생할 수 있는 Error,Exception를 클래스로 정의 했다.

모든 클래스의 조상은 Object 이고 Error,Exception역시 Object의 자손 클래스다.

Error,Exception 클래스

Exception 클래스 (세부)

Exception 클래스는 아래 두가지로 세분화 된다. Exception 자손 클래스(Checked), RuntimeException 클래스(Unchecked)

이 둘은 프로그램에 실수에 의한 것인가 아니면 외부에 외부에 영향 영항으로 발생한 것이냐에 따라 구분한다. 또한 Checked / Unchecked  Exception의 가장 핵심적인 차이는 '반드시 예외 처리를 해야 하는가이다.

RuntimeException (Unchecked Exception)

프로그래머 실수에 의해 프로그램 내부에서 발생할 수있는 예외, 런타임시 발생한다.

특징

• 어떤 상황에서 발생되는지 예측할 수 없기에, 어떻게 복구해야할지 전혀 알 수 없다.
• 그래서 로그를 되게 잘 남겨야한다. 그게 Unchecked Exception 처리의 가장 근본, 원칙
• 명시적으로 에러 처리하지 않아도 됨
• 따라서 에러를 일부러 일으키는 코드가 있더라도 try - catch 처리하지 않더라도 컴파일도 되고 실행까지 가능함

예시)

• Arrayindexoutofboundsexception: 배열의 범위를 벗어남
• Nullpointerexception: 실제 값이 아닌 null을 가지고 있는 객체/변수를 호출할 때 발생
• Arithmeticexception: 정수를 0으로 나눌 때

Exception 자손 클래스(Checked Exception)

사용자 실수와 같은 주로 외부 영향으로 발생할 수 있는 예외들 , 컴파일시 발생한다.

특징

• 충분히 예상가능한 에러이기에, 콕 집어 복구가 꼭 필요한 예외
• Checked Exception예외는 처리 안 하면 IDE에서 빨간색 라인이 생기면서 컴파일 자체가 안됨
• 따라서 Checked Exception는 반드시 예외 처리를 해줘야함

예시)

• IOException : 휴먼은 충분히 이상한걸 입력할 수 있다.
• FileNotFoundException: 존재하지 않는 파일의 이름을 입력
• SQLException : 데이터베이스 접속은 충분히 갑자기 끊길 수 있다.

📌 헷갈렸던 개념

글 초입에 에러 종류를 컴파일 에러, 런타임에러, 논리적 에러가 있다고 설명했었다. 이후 예외 종류를 Checked Exception과 Unchecked Exception로 나누었을 때 에러,예외를 너무 쪼개서 머리가 혼잡했었다. 그래서 총 정리하면 다음과 같다.

Checked Exception은 컴파일 예외클래스들을 가리키는 것이고, Unchecked Exception은 런타임 예외클래스들을 가리키는 것으로 보면 된다

그냥 컴파일 / 런타임 예외로 분류하면 되지, 또다시 Checked / Unchecked Exception으로 재분류 한 이유는 코드적 관점에서 예외 처리 동작을 필수 지정 유무에 따라 나뉘기 때문이다.

즉 Checked Exception는 반드시 예외처리를 해야하고, Unchecked Exception는 명시적으로 처리를 안해도 되었기 때문이다.

참고자료

인파- 자바 에러(Error) 와 예외 클래스(Exception) 💯 이해하기

✨New Wisdom✨·- [Java] Exception에 대하여

남궁성-자바의 정석 P414~P435

Java는 JVM이라는 가상 머신을 통해 OS 종류와는 관계 없이 구동 환경만 적합하면 코드를 실행할 수 있다. 따라서 Java의 특징적인 컴파일 환경, JVM의 구조 등을 정리하려 한다.

📌 JVM을 사용하지 않는다면?

C언어를 예시로 한번 살펴 보려고한다. C는 컴파일 시 바로 Binary code인 기계어로 변환이된다. 이때 특정 OS, CPU 구조를 사용하는 컴파일러에 의해서 컴파일 됐으며, 다른 OS, CPU 구조를 사용하는 환경에서는 이 기계어를 읽을 수 없게 된다.

📌 자바의 컴파일

자바 컴파일 과정은 소스 파일을 JVM이 읽을 수 있는 바이트 코드로 변경하는 과정이다.

1. 개발자가 소스코드 .java 파일을 작성한다.
2. Java compiler인 javac이 .java 파일(소스 코드) -> .class 파일(바이트 코드)로 변환해준다.

📌 자바의 런타임

자바 런타임 과정은 JVM에서 컴파일된 바이트 코드가 실제로 실행되는 단계이다. 아래는 JVM의 구조다.

3. 런타임시, 컴파일된 바이트 코드를 JVM의 클래스로더(Class Loader)에게 전달한다.

4. 클래스 로더는 동적 로딩(Dynamic Loading)을 통해 필요한 클래스들을 로딩 및 링크하여 런타임 데이터 영역(Runtime Data Area), 즉 JVM의 메모리에 올린다.

클래스 로더 세부 동작

로드: 클래스 파일을 가져와서 JVM의 메모리에 로드한다. Linking을 통해 로드된 .class 파일들을 검증, 준비, 해석과정을 거친다.

• 검증: 자바 언어 명세(Java Language Specification) 및 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.
• 준비: 클래스가 필요로 하는 메모리를 할당한다. (필드, 메서드, 인터페이스 등)
• 분석: 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.
  • 초기화: 클래스 변수들을 적절한 값으로 초기화한다. (static 필드)

5. 실행엔진(Execution Engine)은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다.

이 때 실행 엔진은 두 가지 방식을 함께 사용해 실행한다. 인터프리터 컴파일 방식은 코드를 한줄씩 읽어 해석하기 때문에 속도가 느리다. JIT는 느린 인터프리터 방식을 보완해준다.

인터프리트: 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행한다. JIT 컴파일러: 프로그램 실행 중 자주 사용되는 바이트코드 부분을 실시간으로 기계어로 컴파일하여 실행 속도를 향상시킴

Byte code: "가상 머신이 읽을 수 있는 이진 코드" Binary code: "기계가 읽을 수 있는 이진 코드"

📌 JVM 내 RUNTIME DATA AREA

JVM이 운영체제로부터 할당받은 메모리영역이다.

Method Area : 클래스에 대한 정보가 올라오는 영역. 모든 쓰레드가 공유 Heap : new 키워드를 통해 생성된 인스턴스가 생성되는 영역. 모든 쓰레드가 공유 Stack : 지역변수, 매개변수, 리턴값 등 임시적으로 사용되는 값들이 저장되는 영역 PC Register : 현재 쓰레드가 실행되는 부분의 주소와 명령을 저장하는 영역 Native Method Stack : Native 언어로 작성된 코드를 실행하기 위한 영역

참고자료

당근케잌- 왜 JVM이 필요한가?

조민서-자바 컴파일 과정 & JVM 내부 구조

doozi- JVM이란? 개념 및 구조

impala- Runtime Data Area

데이터 정합성(데이터의 정확성과 일관성을 유지하고 보장)과 이상현상 해결을 위해 엔티티를 작은 단위로 분리하는 과정

• 정규화를 하는 경우 조회성능은 처리조건에 따라 향상될 수도 있고, 저하될 수도 있음
• 단 입력, 수정, 삭제 성능은 향상됨

📌Anomaly 문제 상황 (이상현상)

삭제 이상

튜플 삭제 시 같이 저장된 다른 정보까지 연쇄적으로 삭제되는 현상

삽입 이상

튜플 삽입 시 특정 속성에 해당하는 값이 없어 NULL을 입력해야 하는 현상

수정 이상

튜플 수정 시 중복된 데이터의 일부만 수정되어 일어나는 데이터 불일치 현상

📌 제 1 정규화

데이터 베이스의 Table내 하나의 컬럼에 여러 값이 들어가 있는 상황에서 데이터베이스의 각 컬럼이 하나의 데이터만 가지도록 하는 과정이다.

즉, 각 컬럼이 하나의 데이터만 저장하고, 여러 값을 가지지 않게 Table을 분리한다.

제 1 정규화 적용 전

DBMS에 대한 내용을 담은 topic table이 아래와 같이 있다.

• 하나의 tag 컬럼안에 여러 데이터들이 들어가 있다.

발생할 수 있는 단점

단점 1. DBMS에서 가지고 있는 tag값을 조회하기 어렵다.

• where 프로그램='rdb'가아닌 where 프로그램 LIKE '%rdb%'으로 찾아야함

단점 2. tag 값 수정시 두개의 값을 수정해줘야하는 번거로움이 있음

단점 3. Order By할 때 정렬에 어려움이 있음

제 1 정규화 적용 후

위 사진에서 볼 수 있듯이 tag 컬럼에 여러 data가 들어가 있는 것을 확인했다. 이에 따라 Topic table과 Tag table로 분리하려한다.

✔️ Table 분리할 때 체크해야하는 부분

1. 증복된 컬럼이 어느 컬럼에서 발생하는지 확인 후 table을 분리한다.

• 예시에서는 tag table을 topic으로 부터 분리했다.

2. Cardinarity 확인

• 테이블을 분리했을 때 각 table이 어떤 관계를 맺고있는지 확인해야한다.

3. Cardinarity가 N:M이면 두 Table간 맵핑 Table을 만들어주고, 아니면 table만 분리한다.

• 예시에서 하나의 topic은 여러개의 tag를 가질 수 있다. title은 rdb, free등 2개 이상의 tag를 가짐
• 하나의 tag는 여러개 topic을 가질 수있다. rdb는 MYSQL에도, ORACLE에서 사용된다.

Topic Table

Mapping Table

Tag Table

장점

• 데이터의 수정, 삭제, 삽입 연산에 이상 문제 방지
• 데이터 구조가 단순해지고 명확해진다

📌 제 2 정규화

제 1 정규화에서 참고했던 자료들이 제2, 제3 정규화에서 다소 오해를 불러일으킬 수 있어 제 2 정규화부터는 다른 자료를 참고하여 글을 썼다.

하나의 테이블에 복합키 결정자가 있을 때, 복합키의 부분집합이 결정자가 되면 안된다. 따라서 복합키의 부분집합 결정자 부분과 종속되는 일반 속성을 다른 하나의 테이블로 분리해주는 과정이다.

쉽게 설명하면, 현재 테이블의 주제와 관련없는 컬럼을 다른 테이블로 빼는 작업이다.

제 2 정규화 적용 전

해당 예시에서 기본키는 (학생번호, 강좌이름)으로 복합키라는 것을 알아두자.

• 성적은 (학생번호, 강좌이름) 복합키에 종속된다. (학생번호, 강좌이름) --> (성적)

• 강의실은 복합키의 부분집합인 (강좌 이름)에 종속된다. (강좌이름) --> (강의실)

즉, 기본키(학생번호, 강좌이름)의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 다음과 같이 기존의 테이블에서 강의실을 분해하여 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.

발생하는 단점

단점 1. 하나의 테이블에 강좌이름, 강의실 데이터가 중복으로 들어가고 있다.

제 2 정규화 적용 후

제2 정규형을 적용 대상인 수강강좌 Table에 제2 정규화를 적용하여 수강, 강의실 2개의 table로 나누었다. 이제 수강 Table 내 복합키 부분집합에 종속되는 일반 속성은 존재하지 않는다.

장점

• 더 이상 강좌이름과, 강의실 데이터가 중복으로 들어가지 않게 된 것을 확인할 수 있다.

📌 제 3 정규화

제2 정규화를 완료한 테이블에서, 이행적 함수 종속성을 제거하는 과정이다. 이행적 종속이라는 것은 A -> B, B -> C가 성립할 때 A -> C가 성립되는 것을 의미한다.

쉽게 말하면 주식별자가 아닌 모든 속성 간에는 서로 종속될 수 없는 것이다.

제 3 정규화 적용 전

테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정하고 있다. 그렇기 때문에 이를 (학생 번호, 강좌 이름) 테이블과 (강좌 이름, 수강료) 테이블로 분해해야 한다.

강좌이름은 학생번호에 종속된다. (학생번호) --> (강좌 이름)

수강료는 강좌이름에 종속된다. (강좌이름) --> (수강료)

발생하는 단점

단점 1. 501번 학생이 강좌를 자료구조로 변경하고 싶을 때 수강료를 따로 20000원으로 수정해야하는 번거로움이 있음

제 3 정규화 적용 후

제 3 정규형 적용 대상인 계절학기 Table에 제3 정규화를 적용하여 계절수강, 수강료 2개의 Table로 나누었다. 이제 계절수강 Table 내 주식별자가 아닌 다른 일반 속성에 종속되는 값은 없다.

참고자료

애플코딩: 정규화

hyun: 단계별 정규화 정의

망나니 개발자: 정규화 정의

ASAC 04 애런: 정규화 정의

** !! 글을 읽기 전 필독 !!** DBMS 마다 격리 수준에 대한 내용이 다를 수 있으니 보다 정확하게 알기 위해서는 공식 문서를 확인해야 한다. 필자는 MySQL 에서 제공하는 격리수준을 기준으로 하였다. 참고로 MySQL의 기본 격리수준은 Repeatable Read이다.

📌 ISOLATION LEVEL: 트랜잭션 격리 수준

여러 트랜잭션이 동시에 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다.

• 표준적으로 0~3 Level 총 4개가 존재한다.
• Level이 올라갈수록 격리 수준이 높아지지만 성능이 떨어진다.
• 데이터 정확성과 성능이 반비례하기 때문에 상황에 맞게 잘 선택해야함

📌 왜 트랜잭션 격리 수준이 필요할까?

Isolation Level에 대한 조정은, 동시성과 데이터 무결성에 연관되어 있음

• Level 낮을 수록 동시성은 증가 데이터 무결성에 문제가 발생확률 증가
• Level 높을 수록 동시성은 감소 데이터 무결성에 문제가 발생확률 감소

즉 상황에 따라 처리해야하는 데이터 특성이 다를 것이다. 따라서 트랜잭션 격리 수준을 각 Level로 나누어 상황에 따라 동시성이 높은 Level, 데이터 무결성이 높은 Level을 선택할 수 있게 하기위해 존재한다.

📌 Read Uncommitted (레벨 0)

• SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리지 않는 계층
• 트랜잭션에서 처리중이거나, 아직 Commit되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용하는 계층
• 데이터 베이스의 일관성을 유지하는 것이 불가능함

발생할 수 있는 문제: DIRTY-READ

커밋되지 않은 수정중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상

어떤 트랜잭션에서 아직 실행이 끝나지 않은 상황에서 다른 트랜잭션에 의한 변경사항을 보게되는 경우

상황 예시

1. DB에는 10만원을 가지고 있는 계좌가 있다.
2. Transaction A는 DB에 Read 요청을한다. ->계좌의 10만원 확인
3. Transaction A는 DB에 5만원 입금 Write 요청을한다. -> DB의 계좌는 15만원이 됨
4. Transaction A의 Commit은 완료되지 않았는데 Transaction B가 DB에 Read가 가능하다.
5. Transaction B는 15만원의 계좌금액을 확인한다.
6. 이 때 Commit이 완료되지 않은 Transaction A에 Rollback이 생겨 DB의 계좌는 10만원이 된다.
7. 즉 DB에는 10만원이 있는데 Transaction B는 15만원이 조회되는 DIRTY-READ 상황이 발생함

하지만 데이터가 잘 처리되어서 RollBack이 안 되었다면 동시에 데이터를 처리했기 때문에 빠른 성능을 보이게 되었을 것임, 즉 DB의 일관성, 고 신뢰성을 낮지만 성능은 높을 것을 확인할 수 있다.

📌 Read Committed (레벨 1)

• SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리는 계층
• 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 하는 계층
• Commit 이루어진 트랜잭션만 조회가능
• Commit 완료된 데이터만 읽을 수 있기 때문에 DIRTY-READ문제를 해결할 수 있다.

발생할 수 있는 문제: NON-REAPEATABLE READ

트랜잭션 내에서 같은 데이터를 여러 번 조회할 때 읽은 데이터가 서로 다른 값으로 나오는 문제

상황 예시

1, DB에는 10만원을 가지고 있는 계좌가 있다. 2. Transaction A는 DB에 Read 요청을한다. ->계좌의 10만원 확인 3. Transaction A는 DB에 5만원 입금 Write 요청을한다. -> DB의 계좌는 15만원이 됨 4. Transaction A의 Commit은 완료되지 않아서 Transaction B는 Transaction A 실행 전 데이터인 10만원을 읽어 옴 5. Transaction A 가 Commit을 완료하고, Transaction B가 다시 Read하면 15만원을 읽어온다. 6. 즉 Transaction B는 같은 DATA를 읽기 요청을 헀는데 서로 다른 DATA가 나오며 문제 발생 여기서 헷갈렸는데 이해한 부분은 Transaction B내에서 Read 요청을 2번 이상 했을 때 다른 Data가 Read된다는 것이었다.

📌 Repeatable Read (레벨 2)

• 트랜잭션이 완료될 때까지 SELECT 문장이 사용되는 모든 데이터에 Shared Lock이 걸리는 계층
• 트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장하는 계층
• 앞선 NON-REAPEATABLE READ의 상황 예시 5번에서 Transaction A가 Commit을 완료해도 10만원을 읽어오게 함
• 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능

발생할 수 있는 문제: Phantom Read

한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상

트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 나타나는 현상임

상황 예시

1. DB에는 10만원을 가지고 있는 계좌가 있다.
2. Trasaction B가 은행계좌 수 조회를 하는 Read 쿼리를 날림 -> 계좌 갯수 1반환
3. Transaction A가 새로운 계좌를 5만원이 들어있는 계좌를 생성
4. 이후 Trasaction B가 은행계좌 수 조회하는 Read 쿼리 날림 -> 계좌 갯수 2반환
5. 한 트랜잭션 에서 다른 값을 반환하게 됨

레코드가 추가된 상황에는 Repeatable Read가 적용되지 않아 동일한 값이 보장되지 않은 것임

📌 Serializable (레벨 3)

• 트랜잭션이 완료될 때까지 SELECT 문장이 사용되는 모든 데이터에 Shared Lock이 걸리는 계층
• 모든 Transaction들은 모두 순차적으로 실행하게 되는 계층임
• 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능

1. Transaction A Commit이 완료된다.
2. Transaction B가 실행된다.

📌 정리

Read Committed : 아직 커밋되지 않은 데이터를 읽을 수 있다. Read Committed: 커밋된 데이터만 읽을 수 있다. Repeatable Read: 특정 데이터를 반복조회시 같은 값을 반환한다. Serializable: 트랜잭션이 순차적으로 실행된다.

참고자료

낮은 단계 Isolation Level을 활용할 때 발생하는 현상들

[10분 테코톡] 로건의 Transaction

정리의 표 참고

TRANSACTION이란?

DB에 요청시 한 스텝에서 모두 처리되어야 하는 SQL 요청을 하나로 묶은 단위다.

• TrancSaction의 연산은 RollBack, Commit 두가지다.
  • 하나의 SQL 이라도 처리되지 않으면 요청 전 상태로 RollBack되는 것이 특징.
  • 트랜잭션 내 SQL문들이 모두 성공하는 경우 Commit되어 DB에 반영되는 것이 특징.
• 위 사진을 보면 읽기, 쓰기, 지우기, 읽기가 한 스텝에 처리 되어야하는 TRANSACTION임

TRANSACTION이 필요한 경우

상황 가정

• A는 계좌에 10만원 , B는 계좌에 0원이 있는 상태이다.
• A가 B에게 돈을 송금하는 경우를 가정해본다.

DB내에 작업은 두가지로 나뉨

1. A에 계좌에 10만원을 출금 작업 (잔고:10만원-> 0원)

2. B계 계좌에 10만원을 입금 작업(잔고: 0원 -> 10만원)

하지만 1번 작업을 진행 후 에러가 발생하면 A의 계좌는 0원, B의 계좌도 0원인 상태이다.

해결 방법으로는 두 작업에 Transaction을 적용하여 묶는다. 1번, 2번 작업을 논리적으로 한가지 작업으로 묶으면 성공시 Commit을 통해 DB에 반영 실패시 RollBack을 통해 원 상태 복귀로 A와 B 두 계좌가 0원인 상황이 발생하지 않게 된다.

📌 ACID

ACID란?

DB에 있는 데이터의 고신뢰성을 보장하기 위해서 TRANSACTION이 필요하다는 것을 확인했다. 그렇다면 ACID는 무엇일까?

ACID는 DB에서 TRANSACTION이 안전하게 수행되기 위해서 보장되어야 하는 성질 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability) 를 의미하는 ACID 로 알려져 있다.

원자성(Atomicity)

트랜잭션은 DB에 모두 반영되거나, 전혀 반영되지 않아야 한다는 것을 의미한다. (즉 완료되지 않은 트랜잭션의 중간 상태를 DB에 반영하면 안 된다) TrancSaction의 두가지 연산 Commit, RollBack을 통해 보장해줄 수 있다.

원자성이 보장되면 A의 계좌에서 10만원이 출금되었는데 B의 계좌에서 10만원이 입금되지 않는 경우는 없을 것이다.

일관성(Consistency)

일관성은 데이터베이스의 상태가 일관되어야 한다는 성질이다. 하나의 트랜잭션 전후에 데이터베이스의 상태는 이전과 같이 유효해야 한다. (즉, 트랜잭션이 일어난 이후 DB에 여러제약 조건에 맞는 상태를 보장해준다는 의미.)

마이너스 통장을 허락하지 않는다는 DB에 제약조건이 있다면 이 조건을 만족하지 못 한다면 Transaction은 바로 RollBack하게 될 것임

격리성(Isolation)

둘 이상의 트랜잭션이 동시에 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.

A 통장에서 10만원이 출금되고 B 통장에 10만원이 입금되지 않은 중간 상황에, 다른 Transaction이 조회하면 안 되는 것임

Isolation Level (격리 수준) : Transaction 독립(고립)의 정도에 대한 정의

• Isolation Level은 Transaction 간 격리를 시키지 않은것(L0)에서부터 완벽한 격리(L3, 직렬화)까지 총 4단계가 존재한다.
  • 단계가 낮을 수록 단일 시간내에 많은 Transacton을 처리할 수 있지만 데이터 정확도가 낮아질 수 있다.
  • DBMS는 여러 종류의 isolation level을 제공하고, 개발자는 이중에서 어떤 레벨로 트랜잭션을 동작시킬지 설정할 수 있다.

Isolation Level과 단계별 에러는 다음 포스팅 글을 참고!

지속성(Durability)

트랜잭션이 성공적으로 완료되었으면 결과는 영구히 DB에 반영되어야한다.

트랜젝션 조작을 하드 디스크에 로그로 기록하고 시스템에 이상이 발생하면 그 로그를 사용해 이상 발생 전까지 복원하는 것으로 지속성을 실현하고 있다.

A가 B에 10만원 송금을 성공했다면 은행 시스템에 에러가 발생했더라도 10만원 송금 성공된 상태로 복구할 수 있어야한다.

참고자료

[10분 테코톡]예지니어스의 트랜잭션

[10분 테코톡] 로건의 Transaction

[10분 테코톡] 🐤 샐리의 트랜잭션

[DB] 트랜잭션 ACID란? (Atomicity, Consistency, Durability, Isolation)

DB

데이터 저장소

• CSV 혹은 EXCEL 같은 다양한 데이터 형태로 저장되어있는 저장소

  DBMS

  DB(데이터 저장소)기능 + 엔진(데이터를 정의 및 조작하는 기능)을 가진 응용 프로그램
• DB Management System 으로써 위 DB 에 대한 CRUD 엔진, 관리 등 제공
• DBMS마다 엔진이 다르므로 사용하는 쿼리문이 다름 ex) Mysql Select 명령어, PostGres Select 쿼리 명령어가 다름

📌 관계형/비관계형 DBMS

데이터 베이스는 관계형 데이터베이스, 비관계형 데이터 베이스 두가지로 구분된다. 관계형 데이터 베이스는 데이터를 관리할 때 SQL을 사용하고 데이터마다 연결할 수있어 RDBMS라고도 불린다. 비관계형 데이터 베이스는 SQL을 사용하지 않기 때문에 NO SQL 데이터 베이스라고 불리기도 한다.

관계형 데이터베이스(RDBMS)

RDBMS는 데이터를 행과 열의 형태인 테이블로 데이터를 저장하며, 테이블 간의 관계를 정의할 수 있다. ex) 쇼핑물 서비스에서 상품정보 테이블과 판매사 테이블을 연결하여 두 데이터를 함께 사용할 수 있다.

특징

• 테이블간 데이터를 연결할 수 있기 때문에 복잡한 데이터를 표현할 수 있다.
• SQL을 사용하려면 고정된 형식의 스키마가 필요하다. 처리하려는 데이터 속성별로 열(column)에 대한 정보를 미리 정해야 한다
• Transaction으로 데이터 처리가 가능해 ACID를 준수할 수있음(고신뢰성, 무결성 준수 가능)

비관계형 데이터베이스(NO SQL)

NoSQL은 키-값(key-value) 저장, 문서(document) 저장, 그래프(graph) 데이터 저장 등 다양한 형태의 데이터 저장 방식을 사용한다.

특징

• NoSQL의 경우, 다른 구조의 데이터를 같은 컬렉션(=테이블)에 추가할 수 있다. SQL이 정해진 스키마를 따르지 않는다면 데이터를 추가할 수 없는 것과는 다름.
• 미리 정해둔 스키마가 없기 때문에 훨씬 더 유연하다. 언제든지 저장한 데이터를 조정할 수있음.
• 수평적 확장이 가능함 (데이터 베이스를 분산되어 늘릴 수 있음)

용어 구분

SQL에서의 테이블(table) -> NoSQL에서는 컬렉션(Collection) SQL에서의 레코드(record) -> NoSQL에서는 문서(document)

📌 관계형 vs 비관계형, 언제 사용하면 좋을까?

둘은 데이터 저장 방식이 다르고 DB 확장 방식도 다른 것을 확인했다. 그렇기에 각 DB를 사용하기 적절한 상황도 다르다. 다음은 어는 상황에 관계형, 비관계형 DB를 사용하면 좋은지 정리했다.

📖 SQL 기반의 관계형 데이터베이스를 사용하는 케이스

데이터베이스의 ACID 성질을 준수해야 하는 경우

ACID는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)을 의미한다. 데이터베이스에서 트랜잭션이 실행되는 과정에서 안정성을 보장하기 위해 필요한 성질이다.   SQL을 사용하면 데이터베이스와 상호 작용하는 방식을 정확하게 규정할 수 있기 때문에, 데이터베이스에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 줄이고, 데이터베이스의 무결성을 보호할 수 있다.   전자 상거래, 금융 서비스 등의 소프트웨어 개발에서는 반드시 데이터베이스의 ACID 성질을 준수해야 한다. 이러한 경우 일반적으로 SQL을 이용한 관계형 데이터베이스를 사용한다.  

소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우

소프트웨어(프로젝트)의 규모가 많은 서버를 필요로 하지 않고, 일관된 데이터를 사용하는 경우 관계형 데이터베이스를 사용하는 사례가 많다. 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없기 때문이다.

📖 NoSQL 기반의 비관계형 데이터베이스를 사용하는 케이스

데이터의 구조가 거의 없거나 전혀 없는 대용량의 데이터를 저장하는 경우

대부분의 NoSQL 데이터베이스는 저장할 수 있는 데이터의 유형에 제한이 없다. 필요에 따라 언제든지 데이터의 새 유형을 추가할 수 있으며 소프트웨어 개발에 정형화되지 않은 많은 양의 데이터가 필요할 경우 NoSQL을 적용하는 것이 효율적일 수 있다.  

클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우

클라우드 기반으로 데이터베이스를 구축하면 저렴한 비용으로 솔루션을 제공받을 수 있다. 소프트웨어에 데이터베이스의 확장성이 중요하다면 NoSQL 데이터베이스를 사용하는 것이 좋다.  

빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 수정하는 경우

NoSQL 데이터베이스의 경우 스키마를 미리 준비할 필요가 없기 때문에 빠르게 개발하는 과정에 매우 유리하다. 따라서 시장에 프로토타입을 빨리 출시해야 하는 경우에 NoSQL이 적합하다. 또한, 소프트웨어 버전 별로 많은 다운타임 없이 데이터 구조를 자주 업데이트해야 하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스보다 NoSQL 기반의 비관계형 데이터베이스를 사용하는 게 적합하다. 다운타임(Downtime) : 은행 점검 시간과 같이 데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간

참고자료

- 관계형 vs 비관계형 적절한 사용 상황 참고 - 사진 참고 - DB 및 DBMS 참고

AMI

AMI는 AMI 커뮤니티에서 **amazon/amzn-ami-vpc-nat-2018.03.0.20230807.0-x86_64-ebs 을 검색해서 넣어준다.**

AWS 공식 NAT 인스턴스 AMI (Pre-configured Amazon Linux AMI) 는 이제 미지원하기 때문이다.

키페어

키는 이전에 Bastion과 Private_Instance를 연결할 때 사용했던 Public key를 넣어준다.

SUBNET 및 SG 설정

subnet은 Bastion에 할당되어있는 Public Subnet을 할당해준다.

보안 그룹 같은 경우nat-instance-sg 라는 이름으로 구분하기 쉽게 만들고 아래와같이 설정했다.

• SSH, Source Type : Anywhere, Source : 0.0.0.0/0 (모든 트래픽)
• HTTP, Source Type : Custom, Source : 172.16.0.0/16 (로컬)
• HTTPS, Source Type : Custom, Source : 172.16.0.0/16 (로컬)
• 참고로 Private Instance는 172.16.3.25의 Private Ip를 갖고 있다.

위와 같이 설정한 이유는 Private instance로부터 SSH, HTTP, HTTPS요청을 받을 것이기 때문이다.

Network 설정에서 Source/Destination Check 옵션에서 STOP 체크 필요 필요

NAT INSTANCE를 만들어줬다면 Source/Destination Check 옵션에서 STOP 체크 필요 필요하다.

이유는 NAT (Network Address Translation) 의 정의에 따라 Src/Dst 는 수행하면 안되기 때문이다.

📌 Private 서브넷의 Route Table 에 0.0.0.0/0 트래픽에 대해 NAT Instance 로 가게 설정

Private 서브넷의 Route Table 생성 및 설정

Private Instance에서 외부로 요청하는 모든0.0.0.0/0 트래픽은 Nat Instance로 보내려고한다.

Private Instance가 있는 private Subnet에 다음과 같이 Route Table을 설정해준다.

• Route Table 설정 시 NAT Instance EC2 인스턴스 명을 넣으면 자동으로 ENI 설정으로 변경

이제 Private Subnet에 설정해주면 Private Instance에서 발생하는 모든 트래픽은 다 Nat Instance로 가게된다.

주의) 만든 Route Table을 Private Instance가 있는 Private Subnet에 적용하는 것을 잊지 말자

Bastion (혹은 AWS Console 의 Session Manager) 을 통해 Private EC2 에 접속한 뒤 외부요청해보기

• ping goole.com 명령어를 치면 외부로 요청이 정상적으로 이뤄지는지 확인할 것 → 실패
• 실패 : 왜 그럴까? 아래 에서 NAT Instance 의 SG 의 인바운드에 ICMP 오픈 필요

📌 NAT Instance EC2 의 SG 의 인바운드 규칙에 모든 ICMP 요청에 대해 풀어주기

NAT Instance EC2 의 SG 내 다음 인바운드 규칙을 추가해줘야한다.

• All ICMP - IPv4, Source Type : Custom, Source : 172.16.0.0/16 (로컬)
• 참고로 Private Instance는 172.16.3.25의 Private Ip를 갖고 있다.

추가해주는 이유는 NAT에 INBOUND는 Private_Instance에서 오는 요청이기 때문이다.

**Local-to-bastion.pem**이라는 Private key를 생성해준다.

Local에 다운로드 되어있는 것을 확인했다.

📌 Bastion 호스트 역할을 할 EC2 (Public Subnet) 인스턴스 만들기

Public Subnet에 Bastion이라는 인스탄스를 만들어준다.

주의할 점은 INBOUND 규칙에 SSH 프로토콜과 22Port를 열어줘야한다.

이후 내 Local 컴퓨터에서 SSH로 Bation에 접근해야 하기 때문이다.

이후 Local과의 SSH 통신을 위해 아까 만들어둔 Private Key에 대한 Public Key를 주입해준다.

Bastion 생성 확인 후 연결해보기

Pulbic Instance인 Bastion이 만들어진 것을 확인할 수 있다. (ROUTING TABLE과 IGW는 앞서 쓴 블로그에서 만든 것을 참고함)

📌 추후 Bastion 에서 EC2 (Private Subnet) 에 접근하기 위한 Key Pair (.pem 키) 생성

bastion-to-private.pem 이라는 Private key를 생성해준다.

내 Local에 Private키가 잘 다운 받아져있는 것을 확인했다.

📌 EC2 (Private Subnet) 과제용 테스트 인스턴스 만들기

Private Subnet에 Private Instance라는 인스탄스를 만들어준다.

주의할 점은 INBOUND 규칙에 SSH 프로토콜과 22Port를 열어줘야한다.

이후 내 Bation에서 SSH로 Private Instance에 접근해야 하기 때문이다.

이후 Bastion과의 SSH 통신을 위해 아까 만들어둔 Private Key에 대한 Public Key를 주입해준다.

Private-Instance 생성 후 Bastion에서 Private-Instance에 연결해보기

Private-Instance 생성 확인했다.

Bastion에서 Private_Instance로 SSH 접근할 수 있는지 아래와 같이 Test해본다. ssh ec2-user@{target-private-ip} 명령어를 통해 Private_Instance에 요청해본다.

에러 발생

Private EC2 에 SSH 접근을 위해서는 Key Pair (.pem 키)를 넣어서 함께 요청해야한다.

📌 Bastion EC2 인스턴스 내 Private EC2 에 SSH 접속을 위한 .pem 키 설정 후 접속 성공 확인

Bastion EC2 의 터미널에서 나가지말고 .pem 키를 vi편집기를 통해 만들어 준다.

1. 아까 다운 받은 아래 키 내용을 전체 복붙한다.

2. vi bastion-to-private.pem 로 파일을 만들어 복사한 키 값을 넣어준다.

3. chmod 400 bastion-to-private.pem 읽기 권한 부여하여 SSH 접속시 해당 키 읽을 수 있게한다.

4. **ssh ec2-user@{target-private-ip} -i bastion-to-private.pem 만든 Private key와 함께 다시 요청해본다.**

Private_Instance 접속 성공한 것을 볼 수 있다.

📌 SSH Tunneling 으로 지금 내 컴퓨터 로컬에서 Bastion 을 통해 Private EC2 에 SSH 접속해보기

위에서 만든 .pem 키를 사용하여 접속 ssh -i {local-to-bastion-pem-location} ec2-user@{bastion-host-public-ip}

접속 성공을 확인했다.

Bastion EC2 에 SSH Tunneling 열기 = SSH 통로를 위한 터널 열어두기

SSH 통로를 위한 터널을 열어두는 작업이기에 새 터미널에 아래 명령어를 실행한채 계속 냅둬야함

ssh -i **"local-to-bastion.pem"** -N -L 33322:{target-private-ip}:22 ec2-user@{bastion-host-public-ip}

새 터미널을 하나 더 열어서 통로로 명령어 수행하기

• 위에서 열어놓았던 터널을 통해 Private EC2 에 직접 SSH 명령어를 수행할 수 있다.

ssh -i **"bastion-to-private.pem"** -p 33322 ec2-user@**localhost**

• 주의 1 : .pem 키는 2개가 있다. 1번 작업과 2번 작업 시 혼용하지 않도록 주의하라
• 주의 2 : 터널이 열리는 순간 Private EC2 는 내 로컬에서 접근 가능한 포트가 되기에
  • 33322 포트의 localhost 로 접속해야한다는 점 꼭 유념하기 바란다

주의할 점은 PEM키는 읽기 모드로 변경해야 한다는 것이다.