workflow-project, cs공부

최수민·2023년 8월 18일

CS UseGuards(AuthGuard) 사용 오류 기술면접 top30

TIL

목록 보기

20/41

어제 1차적으로 board crud, column crud, member, message를 작성을 했고, 오늘은 테스트를 하면서 확인을 하려고 합니다.

확인하려는데 workspace가 있어야 board도 작성이 되서 workspace를 새로 생성하려고 하니 아래 오류가 나왔습니다.

위 문제는 UseGuards(AuthGuard)를 사용해서 나왔다는것은 알겠으나 뭐가 부족한지 몰라 회원정보 확인할때도 사용을 하니 user와 workspace를 비교를 해봤습니다.

그러자 user module에서는 아래와 같이 redisCache가 있는 반면, workspace의 module에서는 없는 것을 확인했습니다.

imports: [RedisCacheModule,...]

추가를 해주니 잘 작동되었고, board에 관련된 module들에도 추가해주었습니다.

그리고나서 board를 작성하려는데도 오류가 떠서 뭐가 문제인지 찾아보다가
workspace와 user에는 있고 board에는 없어서 아래와 같이 module에 추가해주었습니다.

imports: [RedisCacheModule, TypeOrmModule.forFeature([..., User])],
  ...
  providers: [..., JwtService, UsersService, MailService],

다행히 잘 작동되었습니다.

cs 공부를 하던 중 예찬님이 리포지토리 문제가 있어 화면 공유로 보던 중 상훈님이 한 서비스에서 다른 리포지토리를 건드는건 따로 나눈게 소용이 없는거라 해당 서비스를 가져다가 사용하라고 하셔서 수정했습니다.

변경 전 BoardMembersService

export class BoardMembersService {
  constructor(
    @InjectRepository(Board_Member)
    private boardMemberRepository: Repository<Board_Member>,
    @InjectRepository(Board)
    private boardMemberRepository: Repository<Board>,
    @InjectRepository(User)
    private boardMemberRepository: Repository<User>,
  ) {}
  ...
}

변경 후

export class BoardMembersService {
  constructor(
    @InjectRepository(Board_Member)
    private boardMemberRepository: Repository<Board_Member>,
    private usersService: UsersService,
    private boardsService: BoardsService,
  ) {}
  ...
}

사용중 해당 서비스에서 필요한게 있으면 작업한 분한테 먼저 얘기를 나눠보고 추가허용이 떨어지면 추가했습니다.

기술면접 top30
3. RDBMS의 정규화에 대해 설명해주세요.

-> 먼저 정규화가 필요한 이유는 이상현상이 나타나기 때문입니다.
이상현상은 세가지가 있는데 테이블에 데이터를 넣을때 필요하지 않은 데이터도 넣어야하는 경우의 삽입이상과, 데이터를 삭제하는데 원하지 않은 데이터도 같이 삭제되는 삭제이상, 중복된 데이터 중 특정 부분만 수정되서 값이 이상해지는 갱신 이상이 있습니다.

이 이상현상을 가지지 않기 위해 정규화를 하는데 총 6단계로 이뤄져있습니다.
먼저 1차 정규화(1NF)는 원자값으로 구성되어야한다는 것입니다. 즉 하나의 컬럼엔 하나의 값만 들어있어야한다는 것입니다.

2차 정규화(2NF)는 부분함수 종속 제거입니다. 두개의 키(a,b)가 같이 하나의 테이블을 가리키고, 두개의 키중 하나(b)가 다른 하나의 테이블을 가리킨다면 해당 b키는 따로 해당 테이블에 또 생성을 해서 분리를 시켜놔야한다는 것입니다.

3차 정규화(3NF)는 이행함수 종속 제거입니다. 즉 a -> b, b -> c, a -> c가 되는 관계를 이행함수 관계라고 합니다. 즉 a의 b가 바뀐다면 c도 바꿔 줘야하는 갱신 이상이 발생할 수 있어 쪼개줘야합니다.

보이스-코드 정규화(BCNF:Boyce-Codd NF)는 결정자 함수이면서 후보키가 아닌 것을 제거하는 겁니다.
해당 정규화는 3차와 매우 비슷해서 3.5차 정규화라고도 합니다.
하나의 테이블(A)안에서 학생(a)과 교실(b)이 묶여있고 선생님(c)이 따로 있는데 A -> c, b -> c 인 경우 c를 하나 더 만들어서 c와 연결을 해주는 것입니다.

4차 정규화(4NF)는 다치(다중값) 종속 제거입니다.
하나의 테이블에 a,b,c 컬럼이 있으면 a->b, a->c인 경우 하나만 수정하거나 삭제를 하는경우 이상현상이 발생할 수 있습니다.
그래서 하나의 테이블을 두개로 나누어 다중값 종속을 제거하는것입니다.

5차 정규화(5NF)는 조인 종속성 제거입니다.
4차 정규화가 된 테이블들을 join 연산을 시켰을 때, 정규화 이전의 테이블과 값이 달라지는 경우를 조인 종속성을 가졌다고 합니다.
이부분은 잘 이해가 되지 않습니다.

자주 질문에 나오는 거라고 하셔서 정리를 했습니다.

CS - 스케줄링

공통 배정조건 : 오버헤드 ↓ / 사용률 ↑ / 기아 현상 ↓
- 오버헤드 : 프로세스가 필요한 자원보다 더 많이 사치부리며 사용하지 않도록(=투머치🤑)
- 사용률 : 프로세스가 최대한 자원을 많이받고 빨리 처리하도록 (=알잘딱깔쎈🤓)
- 기아 현상 : 프로세스가 자원할당을 못받아서 배고픈상태로 대기하지 않도록(=지못미🤕)

스케쥴링 알고리즘 평가 기준
1. CPU이용률 : 전체 시스템 시간 중, CPU가 작업을 처리하는 시간의 비율

2. 처리량 : CPU가 단위 시간당 처리하는 프로세스의 개수

3. 총 처리 시간 : 프로세스가 시작해서 끝날때 까지 걸린 시간

4. 대기시간 : 프로세스가 준비완료 큐에서 대기하는 시간의 총 합

5. 응답시간 : 대화식 시스템에서 요청 후 첫 응답이 오기까지 걸린 시간

선점 스케쥴링

OS가 나서서 CPU사용권을 '선점'하고, 특정 요건에 따라 각 프로세스의 요청이 있을 때 프로세스에게 분배하는 방식

1. Priority Scheduling(우선순위 스케쥴링)

정적/동적으로 우선순위를 부여하여 우선순위가 높은 순서대로 처리
우선 순위가 낮은 프로세스가 무한정 기다리는 기아 현상 발생 가능
Aging 방법으로 기아현상 문제 해결 가능
- 노화(Aging)이 있는데 기다리는 시간에 따라 우선순위를 증가시켜주는 방식입니다. 마찬가지로 우선순위가 같으면 FCFS를 적용

2. Round Robin(라운드로빈)

FCFS에 의해 프로세스들이 보내지면 각 프로세스는 동일한 시간의 Time Quantum 만큼 CPU 할당

- 시간 할당량이 중요한데, 너무 작으면 빈번한 문맥 전환(Context Switching)이 발생하고, 너무 길면 FCFS와 다를 바 없어진다.

3. Multilevel-Queue(다단계 큐)

준비완료 큐를 여러개의 큐로 분류하여 각 큐가 각각 다른 스케쥴링 알고리즘을 가지는 방식
메모리 크기, 우선순위, 유형 등 프로세스의 특성에 따라 하나의 큐에 영구적으로 할당
큐와 큐 사이에도 스케쥴링이 필요하다. 우선순위 방식 혹은 시분할 방식으로 한다.

고정 우선순위의 선점형 방식으로 구현되며, 따라서 우선순위에 따른 큐의 스케쥴링은 절대적이다. 예를 들어,

우선순위가 높은 Forground Queue

- 대화형 프로세스를 위한 큐
- Round Robin

우선순위가 낮은 Background Queue

- 연산작업을 처리하는 프로세스 큐
- FCFS

여기서 Forground큐가 비어있지 않는 한 Background큐는 먼저 실행될 수 없으며, Background큐가 먼저 실행중이더라도 Forground큐에 프로세스가 들어오면 선점된다.

비선점 스케쥴링

프로세스 종료 or I/O 등 이벤트가 있을 때까지 실행 보장 (처리시간 예측 용이)
어떤 프로세스가 CPU를 할당받으면 그 프로세스가 종료되거나, 입출력 요구가 발생하여 자발적으로 중지될 때 까지 계속 실행되도록 보장하는 방법
특징
- 순서대로 처리되는 공정성 / 응답시간을 예상
- 선점방식보다 스케쥴러 호출 빈도 ↓ / 문맥교환에 의한 오버헤드 ↓
- 일괄처리 시스템에 적합
- 자칫 CPU사용시간이 긴 프로세스가 다른 프로세스들을 대기시킬 수 있으므로 처리율이 떨어질 수 있다는 단점

1. FCFS (First Come , First Serve)

큐에 도착한 순서대로 CPU 할당
실행 시간이 짧은 게 뒤로 가면 평균 대기 시간이 길어짐

FIFO큐(먼저 입력된것 먼저 출력)를 이용하여 간단하게 구현

Convoy Effect(호위효과)가 발생하는데, 긴 처리시간의 프로세스가 선점되어버리면 나머지 프로세스들은 끝날때 까지 대기

2. SJF(Shorted Job First)

수행시간이 가장 짧다고 판단되는 작업 먼저 수행
FCFS 보다 평균 대기 시간 감소, 짧은 작업에 유리

가장 적은 평균 대기 시간을 달성할 수 있다.

만약 CPU버스트 시간이 동일하다면 FCFS방식을 따름.

다만 선점형인 경우에는 위와같이 진행이 되지만 비 선점형일 경우엔 최소잔여시간우선 법칙을 따릅니다.

현재 CPU에 할당된 프로세스의 남은 잔여시간과, 새로 들어온 프로세스의 CPU버스트 타임을 비교하여 더 적은 프로세스에게 할당하게끔 한다.

최적이긴 하지만 다음 프로세스의 버스트시간을 계산하기 어렵다는 단점이 있어서 '비슷할것이다'라고 추측을 통해 진행하기도 한다.

3. HRN (Highest Response-ratio Next)

우선순위를 계산하여 점유 불평등 보완(SJF 단점 보완)
우선순위 = (대기시간 + 실행시간) / (실행시간)

스케쥴링 동작 시점 스케쥴링 알고리즘에 따라 프로세스들은 상태변화가 일어나며 준비/수행 상태일때 CPU를 사용하게 됩니다.

아래 그림에서

🟠은 프로세스들의 상태를 의미하고
🔜 은 스케쥴링에 따라 상태가 변화되는 동작을 의미합니다.

수행 -> 대기 (Running->Waiting) : I/O요청이 발생하거나, 자식 프로세스가 종료 대기를 할 때
수행 -> 종료 (Running -> Terminate) : 프로세스를 종료시켯을때
수행 -> 준비 (Running-> Ready) : 인터럽트가 발생했을때
대기 -> 준비 (Waiting -> Ready) : I/O가 완료되었을때

여기서 1,2은 프로세스가 스스로 CPU를 반환하기에 비선점 스케쥴링이 발생되고

3,4은 프로세스에서 CPU를 강제로 할당(회수)해야 하므로 선점 스케쥴링 이 발생됩니다.

📌 예를들어 이해해봅시다.

카카오톡 메세지를 보내기 위해 메세지 창을 켜면 카카오톡 프로세스는 신규 > 준비 상태가 됩니다.

준비 (Ready) 상태:
1. 카카오톡을 띄워서 메시지를 입력하고 있을 때, 해당 프로세스는 준비 상태가 됩니다.
2. CPU 스케줄링 알고리즘은 준비 상태의 프로세스 중에서 CPU를 할당할 프로세스를 선택합니다.
3. 이때, 선택하는 선점 알고리즘에 따라 우선순위, 라운드 로빈 등 다양한 방식이 있을 수 있습니다.
대기 (Waiting) 상태:
1. 카카오톡이 비활성화 되어있거나, 가만히 상대방의 답장을 기다릴때 대기 상태가 됩니다.
2. 해당 프로세스는 대기 상태로 변경되면서 수행중 이었다면 CPU를 반납합니다.
3. CPU 스케줄링 알고리즘은 다른 준비 상태의 프로그램(프로세스)를 선택하여 CPU를 할당할 수 있습니다.
수행 (Running) 상태
1. 사용자가 메시지를 발송하거나 상대방의 메시지를 수신할때 수행 상태가 됩니다.
2. CPU 가 준비 상태의 프로세스에 명령을 보내면, 해당 프로세스는 수행 상태로 변경됩니다.
3. CPU 스케줄링 알고리즘은 실행 시간을 제어하며, 일정 시간이 지나면 해당 프로세스를 중단하고 실행 대기 상태의 다른 프로세스를 선택할 수 있습니다.
종료 (Terminated) 상태:
1. 카카오톡 프로그램을 종료하면 해당 프로세스는 중지 상태로 변경됩니다.
1. 이때, CPU 스케줄링 알고리즘은 다른 실행 대기 상태의 프로세스를 선택하여 CPU를 할당할 수 있습니다.