CS 스터디 - 본격 CS 스터디 시작! (DI, 트랜잭션, Https, AOP, 로드밸런싱)

스터디에서 그동안은 각자 맡은 코드가 실제로 어떤 원리로 어떻게 실행되는지에 대해 공유하고,
고도화를 진행했었다.

이 과정이 끝나고 (나는 아직 남음) 
본격적으로 면접 대비 및 이해도 향상을 위한 CS 스터디가 시작되었다.

파란색은 새롭게 알게된 부분이다.

---

✅DI

1) DI에 대해 설명하시오

DI는 의존성 주입이라고 하며, 객체가 직접 의존성을 생성하지 않고 외부에서 주입받는 방식을 말합니다.
스프링에서는 Bean을 기반으로 IoC 컨테이너가 의존성을 주입 및 관리하면서 제어의 역전이 적용되어있습니다.

2) DI를 사용하는 이유가 뭔가요?

new를 사용해서 의존성을 직접 생성하면, 결합도가 높아지면서 재사용성이 떨어지게 됩니다.
외부에서 의존성을 주입받는 것을 통해서 결합도를 낮추어 재사용성과 확장성이 높아지고
테스트 시, Mock 객체를 쉽게 주입할 수 있어 테스트가 용이해집니다.

3) DI를 적용하지 않았을 때의 문제점에는 무엇이 있나요?

- 2번 답변의 정반대이므로 생략! - 
(원리 : new를 통해 직접 명시하면서 어떤 객체를 참고하는지에 대한 정보가 은닉되지 않음 -> 그래서 결합도가 높아지는 것
 예를 들어 같은 부모 클래스를 상속받은 다른 자식 객체로 대체될 수 있는데 new로 특정 자식을 의존하세요라고 명시해놓았으니 결합도가 올라감)

 

---

✅트랜잭션

이건 내가 낸 질문인데 가장 최근에 공부한 부분에서 출제해보았다.

1) 트랜잭션과 4가지 특성에 대해 설명하세요

트랜잭션은 데이터베이스의 논리적인 작업 단위를 말합니다.
트랜잭션은 성공하면 모두 커밋되거나, 실패하면 모두 롤백되어야 하고
동시에 실행되는 트랜잭션이 서로에게 간섭할 수 없어야 하며
항상 일관된 형식의 데이터가 DB에 영구적으로 저장되어야 합니다.

2) 트랜잭션의 격리 수준에 따라 발생할 수 있는 문제 3가지에 대해 설명하세요

Read-Uncommited는 다른 트랜잭션에서 수정했지만 아직 커밋되지 않은 상태의 데이터를 읽는 Dirty Read 문제가 발생할 수 있습니다.
Read-commited는 커밋된 데이터만 읽을 수 있지만 락을 걸지는 않기 때문에 동일한 데이터를 두 번 읽을 때, 그 결과가 다른 Non-Repeatable Read 문제가 발생할 수 있습니다.
마지막으로 Reapeatable-Read는 백업 공간에 저장한 데이터를 가져오기 때문에 중간에 데이터가 다른 트랜잭션에 의해 변하더라도 항상 일관된 값을 읽어올 수 있지만, 여러 번 조회했을 때 이전에는 없던 레코드가 나타나는 Phantom Read 문제가 발생할 수 있습니다.

3) 대규모 트래픽 상황에서 트랜잭션 락 경합을 줄이기 위한 방법에는 어떤 것들이 있나요?

락 경합은 ‘같은 키/행에 몰리는 갱신’이 원인이므로 인덱스 핫스폿을 분산하고, 트랜잭션을 짧게 가져가며, 상황에 맞게 낙관/비관 락을 선택하고, 업서트·SKIP LOCKED·큐 직렬화·샤딩 같은 패턴으로 경합 자체를 줄이는 게 핵심입니다. 나머지는 idempotency와 재시도 전략으로 안정성을 담보합니다

 

---

✅HTTP와 HTTPS

1) HTTP와 HTTPS의 차이점이 무엇인가요?

HTTP는 암호화되지 않은 평문 데이터를 전송하지만 HTTP는 TLS 프로토콜에 따라 암호화도니 데이터를 전송하기 때문에
보안이 더 뛰어나다는 차이가 있습니다.

2) HTTP보다 HTTPS가 더 안전한 이유는? 

HTTPS는 암호화 덕분에 탈취에도 비교적 안전하고,
서버 인증서를 통해 신뢰도 있는 서버를 보장 및 데이터 무결성을 보장하기 때문에 더 안전합니다.

3) HTTPS에서 인증서(SSL/TLS 인증서)의 역할은 무엇인가요?

HTTPS에서 인증서는 공개키로써 서버가 이를 넘겨주면 브라우저가 유효성을 검사하고 
공개키로 암호화된 세션키를 발급하여 신원 보증된 서버와 암호화된 데이터를 주고받을 수 있는 역할을 수행합니다.

 

---

✅AOP

1) AOP에 대해 설명해주세요

AOP는 관점 지향 프로그래밍으로 로깅, 트랜잭션 관리, 보안 등의 공통로직을 비즈니스 로직과 같은 핵심로직과 분리해
재사용 가능하도록 모듈화하는 기법입니다.

2) AOP에서 사용하는 Advice의 종류에는 어떤 것들이 있나요?

총 5가지가 있는데, 그 중 AfterReturning이나 AfterThrowing은 거의 안 쓰이고
메서드 실행 전에 수행되는 Before, 메서드 실행 후에 수행되는 After
마지막으로 두 시점에 모두 수행되는 Around가 있습니다.

3) Spring AOP와 AspectJ AOP의 차이점은 무엇인가요?

Spring AOP는 주로 프록시 기반에서 동작하기 때문에 메서드 실행에 대해서만 Advice를 적용할 수 있습니다.
반면 AspectJ AOP는 바이트코드 위빙을 사용하기 때문에 필드 접근이나 객체 생성 등 다양한 곳에 적용할 수 있다는 차이가 있습니다.

4) 그렇다면 AOP를 프로젝트에서 사용한 경험이 있으신가요?

네 있습니다. 메일을 발송할 때 메일 발송이라는 비즈니스 로직과 메일 발송 내역을 저장하는 트랜잭션 관리 로직이 동시에 필요했습니다. 이 때 AOP를 사용하여 로깅 및 트랜잭션 관리 부분을 별도의 모듈로 분리하였습니다.
이를 통해 핵심 로직인 메일 발송 코드는 깔끔하게 유지하면서 유지보수성을 높일 수 있었습니다.

 

 

---

✅로드 밸런싱

1) 스케일 업과 스케일 아웃의 차이점에 대해 설명해주세요.

스케일 업은 수직적 확장으로 단일 서버의 성능을 높이는 것이고
스케일 업은 수평적 확장으로 서버의 수를 확장하는 것을 말합니다.
스케일업은 단일 구조로도 충분히 운영가능하거나 구조변경이 어려운 경우 사용하고,
스케일아웃은 대규모 트래픽에 대응하기 위해 분산할 필요가 있을 때 주로 사용합니다.

2) 스케일 아웃을 서버 부하를 분산할 때 주로 사용한다고 했는데,
    이 때 어떤 기술을 사용할 수 있을까요?

주로 로드 밸런싱 기술을 사용합니다.
로드 밸런서는 들어오는 요청을 여러 서버에 균등 분배하여 특정 서버에 트래픽이 집중되는 것을 막아줍니다.
로드 밸런서에는 대표적으로 L4와 L7이 있습니다. L4는 IP/port 단위의 분산으로 단순하고 빠르며
L7은 URL, Header, Cookie 값으로 세밀한 분산이 가능합니다.

3) 로드 밸런싱을 저희 서버에 적용시키고 싶은데 어떤 기술들이 있을까요?

로드 밸런싱 알고리즘에는 요청을 순차적으로 분배하는 라운드 로빈 알고리즘,
서버 별 가중치에 따라 높은 서버 부터 순차적으로 분배하는 가중치 로빈 알고리즘,
요청이 들어온 시점에 가장 적게 연결되어 있는 서버에 분배하는 최소 연결,
요청이 들어온 시점에 가장 적은 연결 수와 가장 빠른 응답시간을 가지는 서버에 분배하는 최소 응답 등이 있습니다.
이를 기반으로 Nginx나 AWS ELB 같은 기술을 통해 상황에 적합한 로드 밸런싱을 적용해볼 수 있을 것 같습니다.

4) Apache와 Tomcat은 로드 밸런싱 관점에서 어떤 차이점이 있을까요?

Apache는 L7 리버스 프록시이기 때문에 로드 밸런싱 기능을 직접 제공하며 Tomcat 앞단에서 요청을 나눠줍니다.
반면 Tomcat은 자바의 서블렛 컨테이너이기 때문에 자체적인 로드 밸런싱 기능은 없고 외부 로드 밸런서 뒤에 배치되어
분산 처리한다는 차이가 있습니다.

 

첫날부터 알차다 알차