I/O bound 애플리케이션 서버를 늘리면 성능이 향상될까?

LJH·2021년 7월 15일
0

DevOps 강의 (feat. Foo)

목록 보기
12/16

해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

1. 목표

  • CPU bound 애플리케이션과 I/O bound 애플리케이션의 차이에 대해 이해하기

  • I/O의 종류별로 서버를 늘려 애플리케이션의 성능을 올릴 수 있는가? 에 대한 답 얻기


2. 복습(CPU bound , I/O bound)

2-1. CPU bound 애플리케이션

  • 하드디스크에 저장되어 있던 프로그램이 메모리에 올라가게 되면 프로세스가 되고,
    스케줄러에 의해 실행될 프로세스가 cpu에 올라가 실행된다. 이 때 cpu가 프로세스를 실행시키는 시간을 cpu 버스트 라고 한다.

  • cpu 버스트가 많은 애플리케이션을 cpu bound 애플리케이션 이라고 한다.

2-2. I/O bound 애플리케이션

  • 파일 읽기, 쓰기 등을 하고자 하드디스크에 접근하기 위해 대기하는 시간을 I/O 버스트 라고한다.

  • I/O 버스트가 많은 애플리케이션을 I/O bound 애플리케이션 이라고 한다.


3. I/O bound 애플리케이션 스케일 아웃

  • 하드디스크도 결국 서버와 늘어나기 때문에 성능이 향상 될 수 있다. 하지만 데이터들을 각 서버가 실시간으로 공유할 수 없다. 즉 데이터의 정합성이 보장되지 않는다. 이를 위해 우리는 보통 데이터 베이스를 이용한다.

  • 결국 위와 같은 형태가 된다. 서버가 아무리 많아봤자 DB의 성능이 낮다면 결국 전체 서비스의 성능은 DB와 동일해 질 것이다. 수행속도가 매우 빠른 CPU가 수행속도가 상대적으로 느린 하드디스크와 같이 일을하는 경우 CPU가 대기하면서 속도가 느려지는 것처럼 말이다.
    이를 병목 현상이라고 한다.

  • 따라서 우리는 DB의 성능에 의존적인 부분을 줄여 전체 서비스의 성능을 올려 더 많은 트래픽을 처리할 수 있도록 한다.


4. 앞으로 만들 애플리케이션 - 한 줄 게시판h1

  • 글 번호를 의미하는 id와, 글 내용을 의미하는 content로 이루어진 간단한 구조이다.

  • 만들 기능들은 다음과 같다.

    1. 글 작성

    2. 글 목록(페이징)

    3. 글 번호로 조회

    4. 글 내용으로 조회

위 기능들을 구현한 애플리케이션을 만들고 글을 생성하거나 조회할 때 발생하는 쿼리들을
바로 DB에 날리지 않고 모아서 처리하도록 하여 DB에서 발생하는 병목현상을 줄여보는
과정을 수행할 예정이다.


5. 결론

  • I/O bound 애플리케이션도 서버를 늘리면 성능을 올릴 수 있는가?에 대한 답은
    파일 I/O bound 애플리케이션이라면 가능하다.
    DB I/O bound 애플리케이션은 불가능하다.

  • 물론 DB I/O bound 애플리케이션도 CPU 버스트가 존재하기 때문에 서버가 늘어난다면
    어느정도 성능이 향상될 수 있다. 하지만 주요 병목은 DB에서 일어나기 때문에 서버를 늘리는게
    해결책이 아니다.

0개의 댓글