5주차 학습정리 ‐ 유동근
| 번호 | 시그널 이름 | 설명 |
|---|---|---|
| 2 | SIGINT | 인터럽트 (Ctrl+C) |
| 9 | SIGKILL | 강제 종료 (취소 불가) |
| 11 | SIGSEGV | 메모리 접근 오류 |
| 15 | SIGTERM | 종료 요청 (기본 종료 시그널) |
| 18 | SIGCONT | 정지된 프로세스 계속 |
| 19 | SIGSTOP | 프로세스 정지 (취소 불가) |
| 20 | SIGTSTP | 터미널 정지 (Ctrl+Z) |
event driven architecture를 사용하는 MSA 환경에서 이벤트에 어떤 데이터를 포함할 것인가? 단순히 생각하면 이벤트를 처리하는 소비자의 입장에서 필요한 데이터를 포함하는 것이 좋다는 생각을 했다. 하지만 해당 이벤트를 처리하는 소비자가 여러 서비스가 존재하고 각 서비스마다 요구하는 데이터가 다르다면 이벤트는 어떤 정보를 포함해야할까?
아마 각 서비스가 필요한 데이터를 모두 포함해야할 것이다. 이는 불필요한 데이터를 서빙한다는 단점이 생길 수 있다.
그리고 변경으로 인해서 소비자가 요구하는 데이터가 추가/삭제되는 경우에는 이벤트를 수정해야하는데 어떻게 이벤트를 사용하고 있는지에 따라서 문제가 될 가능성이 있다.
[우아콘2020] 배달의민족 마이크로서비스 여행기에서는 이벤트의 변경을 막기위해서 Zero payload를 사용했다. 각기 다른 서비스에 필요한 데이터를 제공하는 API를 제공하여 필요한 데이터 스키마가 변경을 API 스펙을 변경함으로써 대응하는 방식이다. 이때, 이벤트는 최소한의 정보만을 가지고 있기 때문에 payload가 없는 메타 정보만을 가지고 있어서 변경 사항이 있어도 변경에 대상에 포함되지 않는다.
- event driven architecture의 장점인 느슨한 결합이 훼손될 가능성 vs 유연한 변경 가능성 서비스가 API에 결국 의존하는 형태이기 때문에 서비스간의 강결합이 생긴다. API 서버의 장애가 발생하면 장애가 다른 서비스로 확장이 될 수 있는 구조라고 생각이 들었다. 대신 필요한 데이터를 각 서비스 마다 맞춤형으로 제공할 수 있다는 점은 변경에 더 유리할 수 있다는 생각이 들었다.
각 서비스마다 적합한 데이터를 서빙하는 큐를 생성하는 방식도 있을 것 같다. 큐를 관리하기는 복잡하겠지만 각 서비스마다 필요한 API를 개발하면 결국 관리 대상이 늘어나는 것은 비슷하지 않을까?
https://www.youtube.com/watch?v=BnS6343GTkY&pp=ygUc67Cw66-8IOuniOydtO2BrOuhnOyEnOu5hOyKpA%3D%3D
https://sowhat4.tistory.com/71
https://techblog.woowahan.com/7835/
- 여러 명의 유저가 동시에 사용할 수 있는 시스템 -> 각 사용자의 환경을 격리(보호)해야하는 필요성!!
하드웨어를 관리할 수 있는 유일한 프로세스이다. 유저 프로세스는 하드웨어 리소스가 필요한 경우 커널을 통해서 리소스에 접근할 수 있다.
유저 프로세스가 하드웨어 자원이 필요한 경우 커널에게 자원을 요청하기 위한 함수
https://olc.kr/course/course_online_view.jsp?id=35&s_keyword=kernel+of+linux&x=15&y=12