2025년 2월 1주차 공부 내용 정리

DDD

바운디드 컨텍스트 vs 연관관계

• 바운디드 컨텍스트
  • 도메인 별 개념의 집합
    • Depth로 표현
    • 소유권 개념
  • Aggregate Root 가 최상위 개념
    • 하위 모든 리소스를 관리함
  • 이대로 RESTful 하게 API 설계 가능
• 연관관계
  • 1:1, 1:n, n:1, n:m
    • 관계로 표현
    • 소유권 개념이 있지만, 바운디드 컨텍스트랑은 별계임

도메인 객체 탐색 vs 직접 Repository 조회

• 도메인 객체 탐색
  • 도메인 로직 내에서 객체를 자연스럽게 탐색할 때 사용
  • 검증, 쓰기 작업 시 사용
    • 검증 로직 별로 필요한 애그리거트 루트의 하위 애그리거트 fetch join
    • 도메인 로직이 객체지향적으로 상태를 관리할 수 있도록
  • 이때만 양방향 연관관계 사용
• 직접 Repository 조회
  • 애그리거트 루트에서 객체를 조회할 때 사용
  • 단순 읽기 작업 시 사용

도메인 객체 로직 vs 서비스 레이어 로직

• 도메인 객체 로직
  • 도메인이 직접 관리하는 상태의 전이
  • 도메인 자체의 규칙 or 현재 내부 상태에 따라 상태의 변화를 “제어”해야 하는 로직
• 서비스 레이어 로직
  • 외부 입력값에 대한 변화 주도
  • 다른 바운디드 컨텍스트와의 협력 주도
  • 이벤트, 안티커럽션 레이어, 공유 커널 등과 협력

DDD로 얻는 이점

• 협업을 강화한다.
  • 책임 분리 및 역할 분담
• 트랜잭션이 애그리거트 루트를 통해서만 흐르게 한다
  • 리포지토리에서 발생하는 조인 흐름 결정
  • 정합성 문제 완화
  • 데드락 문제 완화
  • 트랜잭션이 만나는 부분만으로 정합성 문제의 범위를 제한한다.

애그리거트, 바운디드 컨텍스트 관리 방법

• 애그리거트 크기는 클수록 사용하기 쉬워지지만, 관리하기 어려워진다.
  • 그 안에서 전역적으로 사용할 수 있는 범위가 넓어지니 사용하기는 쉬워지지만
  • 트랜잭션의 흐름에 따른 정합성 문제도 발생하기 쉬워진다
  • 가능한 최소 범위를 잡아라.
  • 책임 분리가 명확하도록, 쓸데없는 정합성 문제가 발생하지 않도록
• 애그리거트 루트 간의 최종 일관성만 보장하면 되는 단위로 가져가라.
• 트랜잭션이 만나는 부분에 대한 해결책
  • 공유 커널
    • 둘이 같이 사용하는 도메인 정의
    • 3자간 id값 정도만 참조하는 최소 정보를 가져야 한다.
  • 안티커럽션 레이어
    • 서로 다른 도메인 간 상호작용하기 위한 레이어 정의
  • 퍼블리시드 랭귀지
    • 서로 다른 도메인 간 상호작용하기 위한 인터페이스(메시지 형식) 정의

검증 로직의 작성 방법

• 검증 시 그냥 조회, FOR UPDATE, UNIQUE 제약조건의 차이
  • 중복 제약조건 위반 예외
  • for update - 검증용 조회로직
  • 유니크 제약조건의 필요 이유 → 유일성 보장 검사
    • 그럼 다대다 관계를 풀어내는 조인 테이블의 유일성 보장은 어떻게 하지?
    • 존재의 유일성 보장 - 역시나 유니크 제약조건
• Redis는 트랜잭션 롤백이 안된다.
  • 언제 캐시에 넣을 것인가
• 조인 순서가 반대면, 데드락 발생 가능성이 존재한다.
  • 애그리거트 루트에서, 트랜잭션이 흐르도록

IAM

어드민 유저

• 루트 유저에서 어카운트 단위로 해야 하는 일을 제거한 것
  • 결제
• 보안 이슈를 해결하기 위해서
  • Root 대신 Admin 써라!

정책(Policy)

• 권한의 집합
  • 권한을 정의한 문서
• JSON 형태로 저장됨
• 작동방식
  • action이 들어오기 전까진 모른다.
  • action이 들어온다.
  • 자신이 가진 모든 정책 내 권한들을 나열한다.
  • Deny 되어있는가?
    • YES -> 거절
  • Allow 되어있는가?
    • YES -> 허용
  • 언급이 안되어있는가?
    • 거절
      • 최대한 보수적으로 작동한다.

Group

• 정책을 상속할 수 있음
  • User에게 정책을 상속함
  • 주의: 원래 본인이 가지고 있던 자격증명도 사용 가능
    • A+x
    • B+x
    • x
  • 그럼 개인 정책과 그룹 정책이 겹치면서, 그룹 정책 내 권한이 더 넓은 범위를 갖는다면?
    • 항상 보수적인 정책이 우선권을 갖는다
    • 딱히 본인 정책이 우선순위를 갖는건 아니다.
• 그룹 밑에 그룹을 넣을 수는 없음
  • 지나친 권한 상속을 막기 위해

User

• Account + id + password
• Access Key + Secret Access Key
  • programatic 한 aws 접근 시 사용
  • EC2 aws cli에 박아놓고 사용
    • ~/.aws
      • config
      • credentials
  • 되도록이면 사용 X

Role

• 모자와 같은 느낌!
  • 와 조교다!
  • 사람(User)에게 씌워줘야 한다.
    • 기존 정책을 다 없앤다.
    • 그룹과 User의 권한을 다 덮어씌운다!
• 정책을 덮어씌운다!
• User, AWS 서비스에 할당 가능하다.
  • EC2, Lambda, RDS에 Role 할당
    • 타 서비스에 접근해서 시스템을 사용할 때
    • ex: S3 접근
      • S3 에 이거 올려줘
      • S3는 AWS가 완전히 관리하는 서비스
        • 개인 서버로 통신하는게 아님
        • 보안 그룹이 아니라, Role이 필요함

AWS

• 아마존 웹 서비스
• 모든 Amazon Services를 API 호출 형태로 사용!
  • 어차피 API 호출이다
  • 다른 인스턴스에서, AWS API를 호출할 수 있다
    • 해당 호출을 할 권한을 인스턴스에게 주는 것!
• 방법
  • 1. 웹 콘솔 사용
    2. AWS CLI 도구
       • aws help
         • aws ec2 launch-instance help
    3. AWS SDK
       • HTTP 주소로 API 호출
       • SDK 를 이용해서 코드 차원에서 AWS 사용
  • 얘네들도 결국 IAM에게 권한 검사를 받는다.
    • 자격 증명 인증
    • 권한 부여

권한을 주는 방법

• 1. 역할 부여
  2. 정책 부여
• 뭔가 분명 정책을 부여했는데 동작하지 않는다면, Role이 씌워져있진 않은지 확인
• ec2에 권한을 주는 방법
  • 1. Access Key + Secret Access Key 직접 입력해서 생성 시도하기
       • CLI
       • SDK
    2. role 을 만들어서, aws ec2 인스턴스 레벨에 role 부여햐기
       • 방법
       • 장점
         • 키체인을 인스턴스 레벨에 밝히지 않아도 된다.

 

EC2, AMI

• AMI란?
  • 인스턴스를 띄울 때 사용하기 위한 이미지.
  • 사용자가 인스턴스를 생성할 때 선택 가능
  • 서로 다른 인스턴스에 동일한 이미지를 적용함으로써 유연성과 확장성 확보 가능
    • 직접 AMI를 생성하여, AutoScaling 시 사용 가능
  • AMI를 선택하는 기준
    • 운영체제
    • 리전
    • 프로세스 아키텍처
    • 시작 권한
    • 루트 디바이스 유형
    • 가상화 유형

EC2의 생명주기

EC2의 생명주기

• pending
  • 어떤 컴퓨터 쓸 지 aws에서 빈 서버 탐색
  • 서버가 켜질 때 매번 여기로 옴
• running
  • 컴퓨터 켜짐
  • 돈 나옴
• stop
  • 멈춤
  • EC2에 대해서는 돈 안나옴
  • EBS를 사용하는 것에 대해선 돈이 나옴

• 인스턴스 중지와 인스턴스 종료는 다름
  • 인스턴스 중지
    • EBS(Block Storage)가 붙어있는 경우에는 STOP이 가능
      • 가상화해놓은 임의의 디스크
  • 인스턴스 종료
    • 인스턴스 정보 삭제