• 스케줄링(Scheduling)의 단계
  • 고수준 스케줄링
  • 가게가 장사가 잘된다고 손님을 계속 받는 것이 아닌 것처럼 시스템 내의 전체 작업 수를 조절하는 것을 말함. 여기서 작업이란 운영체제에서 다루는 일의 가장 큰 단위로 1개 또는 여러개의 프로세스로 이뤄짐.
  • 중간 수준 스케줄링⇒ 즉, 고수준 스케줄링은 스케줄링 대상에 참여하는 job을 조절하는 것이라면 중간 수준 스케줄링은 이미 들어온 프로세스들에 대하여 전체적으로 조절하는 것임.
    1. 고수준과 저수준 스케줄링 사이에서 일어나는 일.
    2. suspend와 active 로 전체 시스템의 활성화된 프로세스 수를 조절하여 과부하를 막음.
    3. 이는 프로세스의 상태 중 보류 상태(suspend state)에 해당하며 저수준 스케줄링이 원만하게 이루어지도록 완충하는 역할을 함.
  • 저수준 스케줄링준비 상태인 프로세스를 실행 상태로, 실행 상태를 대기 상태로, 대기 상태를 준비 상태로 보내는 것들이 있음.
  • 어떤 프로세스에 CUP를 할당할지, 어떤 프로세스를 대기 상태로 보낼지 등을 결정하는 일임.

정리

고수준 스케줄링에서 전체 시스템의 부하를 고려하여 작업을 시작할지 말지 결정함. 이 결정에 따라 전체 프로세스의 수가 결정되는 것임.

중간 수준 스케줄링은 시스템이 과부하가 걸려서 전체 프로세스 수를 조절해야할 때, 이미 활성화된 프로세스 중 일부를 보류 상태로 보낸다. 보류 사애가 된 프로세스는 처리 능력에 여유가 생기면 다시 활성화가 됨.

저수준 스케줄링에서 실제로 작업이 이루어집니다. CUP 스케줄러는 필요에 따라 준비 상태에 있는 프로세스를 실행 상태로 옮기고, 대기 상태로 보내기도 하며, 타임 아웃으로 준비 상태로 보내기도 한다. 보통 특별한 명시가 없다면 CPU 스케줄러는 저수준 CPU 스케줄러를 말함.

RestAPI란?

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)

→ 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다. 주로 파일 제어, 창 제어… 등

인터페이스(Interface)는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면임. 즉, 사용자가 기기를 쉽게 동작시키느데 도움을 주는 시스템을 의미합니다.

REST(Representational State Transfer)

→ 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식임.

REST는 HTTP 기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍처라고 합니다.

구성 요소

• 자원(Resource)

  - 자원은 서버에 존재하는 데이터의 총칭이며 모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있습니다.

• 행위(Verb)

   - 행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다.

• 표현(Representation)

   - 클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답(JSON, XML)을 보내는데 그것을 의미합니다.

특징

• 서버-클라이언트 구조(Server-Client Architecture)

  - 서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을  분명하게 구분할 수 있습니다.

• 무상태성(Stateless)

  - HTTP를 이용하는만큼 Stateless의 특성을 가집니다. 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있습니다.

• 캐시 가능(Cacheable)

  - HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있습니다.

• 일관된 인터페이스(Uniform Interface)

  - HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있으며 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리됩니다.

• 자체적인 표현 구조(Self-Descriptiveness)

  - JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 지관적으로 이해할 수 있습니다.

• 계층 구조(Layered System)

  - 클라이언트는 대상 서버와 직접 통신하는지 아니면 중간 서버와 통신하는지 알 수 없습니다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있습니다.

장점

• 별도의 인프라 구축이 필요 없음

  - HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없습니다.

• 클라이언트와 서버의 분리

  - 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리됩니다.

• 플랫폼에 독립적

  - HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능합니다.

• 쉬운 사용

  - 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽습니다.

단점

• 표준이 존재하지 않음

  - 명확한 표준이 존재하지 않습니다. 따라서 REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 탄생할 수 있으며 관리가 어렵습니다.

• HTTP Method의 한계

  - HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원합니다.

• RDBMS와 맞지 않음

  - REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않은 형태입니다. 그래서 NoSQL이 더 선호되는 추세입니다.

Intro.

RDS에서 특정 테이블에서 Trigger를 생성했는데, 완료 버튼을 누름과 동시에 "SQL 오류 (1419): You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable) " 라는 에러를 만났습니다.

... 보안상의 이유로 권장되지 않으나.. 그래도 한번 해보자는 생각으로 진행하였는데
RDS에서는 2번을 설정을 변경을 해줬지만 똑같은 에러가 돌아왔습니다.

Window에서 사용하는 MySQL을 접속하여 사용하였더니, 거짓말처럼 되더군요.
아무래도 RDS는 3번 방안을 사용해서 진행을 해야하는 것이 아닐까..

저는 대체 방안으로 "Trigger" 를 사용하지 않고 코드단에서 스케줄러로 해결하였습니다..

HTTP와 HTTPS의 차이?

HTTPS는 SSL(Secure Socket Layer) 인증서를 사용하는 HTTP입니다.

SSL인증서는 일반 HTTP 요청 및 응답을 암호화합니다.

따라서 HTTPS는 HTTP보다 더 안전한 보안용 프로토콜입니다.

HTTP란?

HTTP(HyperText Transfer Protocol) 로 인터넷을 작동시키는 역할을 하며,

웹서버 및 브라우저 상호 간의 데이터 전송을 위한 응용 계층 프로토콜입니다.

HTTPS란?

HTTPS(HyperText Transfer Protocol Secure)로 표준 HTTP와 동일한 방식으로

작동하나 서버와 주고받는 데이터가 암호화되기 때문에 웹사이트에 추가적인 보호를 제공합니다.

사이드 프로젝트 진행중 ... 안드로이드 개발자(기획)와 백엔드 개발자의 채팅 설계 질문지에 대한 답변 정리입니다.

Q) 1:1 채팅 앱인지, 그룹 채팅 앱인지?

A) 그룹 채팅입니다. 생각했던 스토리는 경기 시작 1시간 전에 채팅방 입장이 가능하고(나중에 푸시와 연동) 경기 종료 1시간 후에 채팅방이 끝나는 느낌이구요, 그 때 해당 경기에 관해 채팅을 할 수 있는 방이 하나만 열리고, 그 방에서 그룹 채팅을 하는 형태입니다.

Q) 일별 능동 사용자 수 (DAU) 기준으로 몇명을 처리할 예정인지?

A) 아직 고려는 하지 않았습니다. 몇 명인지에 따라서 개발 방향이 크게 바뀐다면 한번 다같이 더 찾아보고 의논해보는 게 좋을 것 같습니다.

Q) 그룹 채팅의 경우에 인원 제한이 있는지?

A) 따로 두지는 않았습니다. Socket 통신 시 문제가 생기는 지점이 있는지 파악을 해두는 건 좋을 것 같습니다. 서버단에서 체크를 해보는 것도 좋을 것 같아요. 

Q) 중요 기능으로 어떤 것이 있는지, 첨부파일도 지원할 수 있는지?

A) 저희가 따로 파일을 저장하는 시스템이 현재 없어서 첨부파일은 고려하지 않아도 될 것 같구요. 간단하게 생각해본 건 챗봇 느낌으로 명령어나 특정 메세지를 보내면 그에 맞게 데이터를 보내주고 클라 UI 상에서 일반 메시지와는 다르게 보여준다거나, 경기와 관련된 채팅이기 때문에 득점이나 경기 시작, 종료 등과 같은 상황을 브로드캐스트로 뿌려준다거나 하는 등의 기능을 생각해봤습니다. 우선은 복잡하게 데이터 규격을 정해야 하는 기능보다는 문자열 형태로도 주고받을 수 있는 기능인데, 다른 형태로 구현해 볼만한 기능이 있는지도 고민해보겠습니다.

Q) 메시지 길이에 제한이 있는지?

A) 당장은 변수가 발생할 수도 있는 상황을 배제하고 원활한 처리를 위해 길이를 제한하는 게 좋을 것 같구요, 현재는 메시지 저장을 따로 안 하는데 차후에 더 디벨롭해서 기능을 확장하게 되어 저장을 한다면 테이블 구조와 소켓 통신, 클라에서 처리 가능한 길이 등을 고려해서 제한을 두는 것도 좋을 것 같습니다.

Q) 종단 간 암호화를 할 것 인지?

A) 메시지 저장하기 전까지는 고려하지 않아도 될 것 같습니다.

Q) 채팅 이력은 얼마나 오래 보관해야하는지?

A) 지금 기능 상으론 서버에선 소켓으로 들어온 메세지를 바로바로 다시 내보내는 형태일 걸로 생각되는데 그 때 따로 보관은 하지 않아도 될 것 같구요. 클라에선 채팅방 입장~퇴장 까지 중에서 화면이 활성화되어 있는 상황에서 주고 받은 메세지들은 보여줘야 하기 때문에 메모리상에는 들고 있을 것 같습니다. 서버나 클라나 현재로선 메시지를 DB에 저장하지는 않아서 관련 기능 추가전까지는 고려하지 않아도 될 것 같습니다.

프로젝트 GITHUB : https://github.com/Mirandalaw/gooner

Node.js로 데이터베이스 커넥션 풀을 구현하면서 사용하게 된 라이브러리를 정리하기 위해 작성합니다.

[generic-pool]

- Node.js에서 일반적인 자원 풀링을 구현할 수 있도록 도와주는 라이브러리임.
- 이 라이브러리를 사용하면 자원( DB connection, HTTP 요청 등) 을 관리하고 재사용할 수 있음.
- 특히, 데이터베이스 연결과 같은 생성 비용이 비싼 자원을 사용할 때 효과적임.

사용법
 1. 풀 생성 및 구성 : "generic-pool" 을 사용하여 풀을 생성하고 필요한 옵션을 구성함.
 2. 자원 생성 및 반환 로직 정의 : 풀에서 관리할 자원을 생성하고 반환하는 로직을 정의함. ( 이는 "create" 와 "destroy" 옵션에 해당함)
 3. 자원 획득 및 반환 : "acquire" 함수를 사용하여 자원을 획득하고, 작업이 끝난 후에 "release" 함수를 사용하여 자원을 풀에 반환함.

사용이유
 1. 성능향상 : 자원을 반복적이고 생성하고 소멸하는 것은 비용이 많이 들며 시스템 성능을 저하시킬 수 있음.
대신 자원을 풀에 보관하고 필요할 때 재사용함으로써 성능을 향상시킬 수 있음.
 2. 자원관리 : 풀을 사용하면 동시에 여러 작업에서 자원을 공유하고 관리할 수 있음. 이는 메모리 누수나 자원 고갈과 같은 문제를 방지할 수 있음.
 3. 서버 부하 감소 : 풀을 사용하면 서버에 대한 부하를 분산할 수 있음. 
예를 들어, 데이터베이스 연결 풀을 사용하면 동시에 많은 클라이언트 요청을 처리할 수 있고, 데이터베이스 서버에 대한 과도한 부하를 방지할 수 있음.
 4. 애플리케이션 확장성 : 풀을 사용하면 애플리케이션의 확장성을 향상시킬 수 있음.
풀을 관리하는 컴포넌트를 쉽게 확장하거나 교체하여 시스템의 요구 사항에 맞게 조정할 수 있음.
 5. 안정성 : 풀을 사용하면 시스템이 과부하 상태일 때도 자원을 효율적으로 관리할 수 있음. 이는 시스템의 안정성을 높일 수 있음.

※ 자원 풀링
- 다수의 요청이 동시에 발생하는 경우, 요청마다 자원을 새로 생성하는 것이 아니라 풀에 미리 생선된 자원을 할당하여 사용하고,
작업이 끝나면 자원을 풀에 반환하는 방식으로 동작함. 
=> 이를 통해 성능을 향상시킬 수 있음.