5 분 소요


교착 상태(Dead Lock)

두 개 이상의 스레드나 프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태
시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생.

발생 조건

  • 상호 배제 : 자원은 한 번에 한 프로세스만 사용 가능
  • 점유 대기 : 최소 하나의 자원을 점유하고 있으면서, 다른 프로세스에 할당되어 있는 자원을 점유하기 위해 대기
  • 비선점 : 할당된 자원은 사용이 끝날 때 까지 뺏을 수 없음
  • 순환 대기 : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 갖고 있음

해결 방법

  • 예방 : 교착 상태 조건 중 하나씩 제거하며 해결 (메모리 낭비가 심함)
    • 상호 배제 부정 : 여러 프로세스가 공유 자원을 사용
    • 점유 대기 부정 : 프로세스 실행 전 모든 자원 할당
    • 비전섬 부정 : 자원 점유중인 프로세스가 다른 자원을 요구할 때 가진 자원 반납
    • 순환 대기 부정 : 자원에 고유 번호 할당 후 순서대로 자원 요구
  • 회피 : 교착 상태 발생 시 피해가는 방법
    • 프로세스가 자원을 요구할 때, 시스템은 자원을 할당한 후에도 안정 상태로 남아있는지 사전에 검사.
  • 탐지
    • 자원 요청 시, 탐지 알고리즘을 실행시켜 교착 상태 탐지
  • 회복
    • 교착 상태를 일으킨 프로세스를 종료 시키거나, 할당된 자원을 해제시켜 회복


DI

DI(Dependency Injection) 의존관계 주입이라고 하며, 애플리케이션 실행 시점에 외부에서 구현 객체를 생성하고, 이를 클라이언트에 전달하여 클라이언트와 서버의 실제 의존관계가 연결 되는 것.


IoC

IoC(Inversion of Control) 제어의 역전이라고 하며, 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 의미.


DL

DL(Dependency Look-up)은 한 객체에서 필요로 하는 다른 객체를 찾아서 사용하는 기술이다.


AOP

AOP(Aspect Oriented Programming)는 공통의 관심 사항을 추출하여 원하는 곳에 적용하는 기술이다.


프레임워크 / 라이브러리

프레임워크

SW 개발에서 프레임워크는 미리 만들어진 구조나 도구의 집합으로, 애플리케이션을 빠르고 효율적으로 개발할 수 있도록 지원.
완성된 애플리케이션이 아닌 프로그래머가 완성시키는 작업을 해야한다.

라이브러리

라이브러리는 단순 활용 가능한 도구들의 집합을 말한다.
즉, 개발자가 만든 클래스에서 호출하여 사용.

차이점

둘의 차이는 ‘제어 흐름에 대한 주도성이 누구에게 있는가’이다.
프레임워크는 내가 작성한 코드를 제어하고 대신 실행해 전체적인 흐름을 스스로가 쥐고 있으며, 라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것이라고 할 수 있다.


JPA

JPA(Java Persistence API)는 Java 진영의 ORM 기술 표준으로, JPA는 인터페이스의 모음이다.

ORM(Object Relational Mapping) 객체 관계 매핑으로 객체는 객체대로, 관계형 DB는 DB대로 설계하면 ORM 프레임워크가 중간에서 매핑해준다.
대중적인 언어에는 대부분 ORM 기술이 존재한다.

사용하면 좋은점

ORM은 객체를 관계형 DB 테이블과 매핑해주는 기술인데, 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신 SQL을 동적으로 만들어 실행해 주기도 한다.

사용 이유

  • SQL 중심적인 개발에서 객체 중심으로 개발
  • 생산성
    • 간단한 CRUD(persist, find, dirty-checking, remove)
  • 유지 보수
    • 기존 : 필드 변경시 모든 SQL 수정
    • JPA : 필드만 추가하면 SQL은 JPA가 자동으로 처리
  • 성능
    • 1차 캐시와 동일성 보장
      • 같은 트랜잭션 안에서는 같은 엔티티를 반환
    • 트랜잭션을 지원하는 쓰기 지연
      • 트랜잭션을 커밋할 때 까지 INSERT SQL을 모음
    • 지연 로딩
      • 지연 로딩 : 객체가 실제 사용될 때 로딩
      • 즉시 로딩 : JOIN SQL로 한 번에 연관된 객체까지 미리 조회


JWT(Json Web Token)

JWT란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미.
JWT는 JSON 데이터를 인코딩하여 직렬화 한 것이며, 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있다.
따라서, 사용자가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며, 검증이 완료되면 요청한 응답을 돌려준다.

구조

JWT는 .을 구분자로 나누어지는 세 가지 문자열의 조합.(Header, Payload, Signature)
Header에는 Token의 타입과 hash 알고리즘의 종류가 담겨있으며, Payload에는 서버와 클라이언트가 주고 받는 시스템에서 실제로 사용될 정보에 대한 내용이 담겨있다.
Signature에는 Header와 Payload를 인코딩 한 후에 서버가 갖고 있는 유일한 key값을 합친 것을 Header에 정의한 알고리즘으로 암호화한 전자서명이 담겨있다.

인증 과정

  1. 사용자가 서버에 로그인 인증을 요청
  2. 서버에서 인증 요청을 받으면, Header, Payload, Signature를 정의.
  3. 각각 암호화하여 JWT를 생성하고, 쿠키에 담아 발급
  4. 사용자는 서버로부터 받은 JWT를 로컬 저장소에 저장
    API를 요청할 때, Authorization Header에 Access Token을 담아서 보낸다.
  5. 사용자가 Header에 담아서 보낸 JWT가 내 서버에서 발생한 토큰인지 일치 여부 확인.
  6. 인증에 성공하면 Payload에 들어있는 유저의 정보들을 select해서 사용자에게 돌려준다.
  7. 만일 Access Token의 기간이 만료되면, 클라이언트는 Refresh Token을 이용해 새로운 Access Token을 발급.

신뢰성을 가지는 이유

다른 유저가 임의로 값을 수정해서, 수정한 토큰을 서버에 요청을 보내도 클라이언트로 부터 받은 JWT의 Header, Payload를 서버의 Key값을 이용해 Signature를 다시 만들고, 이를 비교하여 일치할 경우 인증 통과.
따라서, 값을 수정해도 Signature값이 일치하지 않기 때문에 위조 방지를 할 수 있다.

장점

  • 데이터 위조 방지
  • 인증 정보에 대한 별도의 저장소가 필요 없다.
  • 클라이언트 인증 정보를 저장하는 세션과는 다르게, 서버는 무상태(Stateless)가 되어 서버 확장성이 우수.
  • 토큰 기반으로 다른 로그인 시스템에 접근 및 공유가 가능.(쿠키와 차이)

단점

  • 토큰 자체에 정보를 담고 있는 것.
  • 토큰 길이
    • Payload에 3종류의 Claim을 저장하기 때문에 정보가 많아지면 그만큼 길이가 길어지고, 그만큼 네트워크에는 부하가 걸린다.
  • Payload에는 중요한 데이터를 넣을 수 없다.(쉽게 복호화 된다.)
  • Stateless 특징을 가지기 때문에 토큰은 클라이언트 측에서 관리하게 되는데, 토큰 자체를 탈취 당하면 대처가 힘들다.


MSA

MSA 도입 전

기존에 사용하던 방식은 모노리틱(Monolithic) 아키텍처 스타일로, 한 덩어리의 구조로 볼 수 있다.
전체 애플리케이션이 하나로 되어있어서, 보통 동일한 개발 툴을 사용해 개발하며, 빌드 및 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 개발 및 환경설정이 간단하다.
또한, 각 컴포넌트들이 함수로 호출되기 때문에 성능에 제약이 덜하고, 운영 관리가 용이하다.
이런 장점 덕분에 작은 볼륨의 시스템을 개발할 때는 매우 유용하지만, 시스템이 커지기 시작하면 문제가 발생

  • 빌드/테스트 시간이 길어진다.
    • 작은 수정에도 시스템 전체를 빌드/테스트해야 하기 때문.
  • 선택적 확장이 불가능
    • 이벤트로 인해 서비스 접속량이 폭증할 경우 프로젝트 전체를 확장해야 한다.
  • 하나의 서비스가 모든 서비스에 영향을 준다.
    • 이벤트 서비스에 트래픽이 몰려 해당 서버가 죽게 되면, 다른 모든 서비스 역시 마비.

MSA란?

MSA는 Micro Service Architecture의 약자로, 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법.

각 컴포넌트는 서비스 형태로 구현되고, API를 이용해 타 서비스와 통신하게 된다.
각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 되고, 부분적인 확장이 가능.

단점

  • 모노리틱 아키텍처가 서비스간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만, MSA의 경우 서비스간 호출을 API 통신을 이용하기 때문에 속도가 느리다.
  • 또한, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생.

특징

  • 데이터 분리
    • 데이터 저장 시 하나의 DB에 집중하지 않고, 서비스마다 별도의 DB를 사용.
    • 따라서, DB의 종류를 다양하게 가져갈 수 있다.
    • 데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있다.
    • 다른 컴포넌트 데이터를 API 통신을 통해 가져와야 하기 때문에 성능상 문제가 발생할 수 있다.
    • 트랜잭션으로 묶을 수 없는 문제가 발생
  • API Gateway
    • MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 때문에 서버 URL이 각기 다를 수 밖에 없다.
    • 이때, API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다.

댓글남기기

참고