이 글은 다음 링크를 번역하며 공부한 글입니다 🙌 💡 Intro 성능 테스트에 관련한 공부 및 적용을 하면서 좋은 아티클을 추천 받았다. (Thanks to 제리 👍) 관련 명령어들에 대해서 공부하고 각 칼럼이 의미하는 os 및 네트워크 기초 지식을 메꾸보자. 1. uptime 실행되기를 기다리는 프로세스의 갯수를 출력한다. 리눅스 시스템에서는 CPU를 기다리는 프로세스와 uninterruptible I/O (disk I/O) 에 의해 프로세스가 막혀있을 수 있다. 따라서 이 수치를 통해서 리소스 부하를 간편하게 확인 할 수 있다. 위 세개의 번호는 각각 1분, 5분, 15분 간 실행되지 못하고 대기 중인 프로세스 갯수를 나타낸다. 시간 추이에 따른 부하 상태를 통해 상황을 유추할 수도 있다. 2. dmesg | tail 마지막 10개의 시스템 메세지를 출력한다. 여기서 성능에 이슈를 일으킨 에러 메세지를 확인할 수 있다. oom-killer나 TCP 요청 드랍 같은 경우를 확인할…

💡 Intro 진행 중인 프로젝트에서 구현한 웹 어플리케이션이 어느 정도의 부하를 견딜 수 있는지에 대한 성능테스트를 진행했다. 프로젝트는 개발자를 타켓으로 한 깃헙 레포지토리를 연동한 게시물을 업로드하여 개발자들이 자신의 작업을 공유하고 다른 이들의 프로젝트를 캐줄얼하게 엿볼 수 있는 SNS형 웹 어플리케이션이다. 웹 어플리케이션에 들어가자마자 최신순으로 정렬된 게시물 피드를 볼 수 있다. (비로그인/로그인 모두 가능) 홈피드 게시물 조회 성능테스트를 진행, 병목 지점을 분석하고 개선하는 과정을 따라가보자. 🌩 사전 작업 테스트 더미 데이터 입력 테스트를 진행하기 위해서는 실제 운영환경과 최대한 유사한 환경에서 테스트하는 것이 중요하다. 운영환경과 유사한 환경이라고 하면 크게 1) 인프라 구조 2) 데이터 두 가지가 있다. 먼저 대량의 더미 데이터를 입력하도록 한다. (팀원 케빈이 수고해주었다 !! 👍) MariaDB 쿼리 캐시 끄기 왜 쿼리 캐시를 껐을까? 실제 어플리케이션에서…

💡 Intro 이전 포스트에서 진행한 프로젝트에서 홈피드 게시물 조회 성능 테스트에 대한 결과를 보고 개선대상을 파악하고 개선한다. 개선 후 테스트를 재진행하여 결과를 비교한다. 🌩 쿼리 진단 이전 포스트에서 진행한 성능 테스트를 통해 DB 쿼리 쪽 병목이 있다는 것을 알아냈다. 구체적으로 쿼리를 자세히 살펴보면서 어떤 문제가 있는지 확인해보자. 홈피드 게시물을 반환할 때 발생하는 slow query 현재는 포스트 조회하는 쿼리가 최대값으로는 3.62 초가 소요된다. 쿼리의 실행계획을 확인해서 문제점을 파악해보니 100만건의 데이터를 거의 다 훑으면서 filesort를 하고 있었다. 게시물을 최신순으로 정렬하여 상위 10개를 가지고 오는 Pagination을 적용하고 있기 때문이다. 🌩 개선하기 createt_At 칼럼에 인덱스를 추가하여 데이터가 정렬되도록 한다. 인덱스를 건 후 실행계획을 확인해보니 filesort가 제거되었고 훑는 row 수가 대폭 줄어들었다. 🌩 개선 후 성…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 1. 작업큐(Job-Queue) 시스템 웹 서비스와 요청 본래 웹 서비스의 요청은 동기적으로 실행이 되었는데, 데이터가 축적되어 처리가 무거워지면서 작업큐 시스템을 통해서 나중으로 미뤄도 되는 처리를 비동기로 실행하도록 한다. 예) 특정 url을 북마크 할 때 해당 url의 개요를 얻고 키워드를 추출하고, 카테고리를 판정하는 작업들을 비동기로 처리한다. 그렇지 않으면 북마크를 추가할 때마다 긴 시간이 소요된다. 작업큐 시스템 입문 비동화 하는 방법 → 해당 처리를 독립된 스크립트로 어플리케이션 내부에서 호출한다. 이 방법은 대량의 비동기 처리시 그 수만큼의 프로세스를 실행시키므로 성능상 단점이 될 수 있다. 스크립트 시작과 초기화의 오버헤드가 커서 성능이 좋지 않다. 소규모 어플리케이션에서만 진행하는 것이 좋다. 작업큐와 워커를 세트로 작업큐 시스템을 사용하는 것이 일반적이다. 작업큐에 실행하고자 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 규모가 커지면서 트래픽이 커지면 문제가 발생한다. → 라우터의 성능 관점에서는 bps보다 패킷 단위인 pps가 더 중요하다. 사용하고 있는 라우터에서 감당하는 이상의 패킷이 송수신되면 문제가 발생한다. 또한 호스트 수가 500을 넘어가면서 하나의 서브넷을 구성하면 여러 패킷 손실등이 발생하기도 한다. 글로벌 서비스로 확장하면 데이터 센트럴 한군데 두었을 때 latency도 한계에 다다를 수 있다. [강의38] 네트워크 분기점 1Gbps의 한계 - PC 라우터의 한계 1Gbps 는 30만pps → 한계치이다. 이것을 해결하기 위해서는 PC 라우터를 여러 대 병렬화 하던지, 고가의 라우터를 사용해야 한다. 500호스트의 한계 - 1서브넷 ARP 테이블에서의 한계 스위치의 ARP(Address Resolution Protocol table)에서 한계가 있다. ARP는 IP주소와 MAC 주소간의 관계를 나…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 다중화로 어느정도 문제를 해결할 수 있지만 규모가 작으면 다중화를 했을 경우 전체적인 리소스 사용률이 떨어지면서 효율이 떨어진다. 가상화로 전체적인 리소스 사용률을 높일 수 있다. [강의36] 가상화 기술 가상화 기술의 도입 왜 가상화 기술을 사용하나 확장성 → 오버헤드 최소화 비용대비 성능 → 리소스 사용률 향상, 운용의 유연함 고가용성 → 환경 격리 가상화 기술의 효용 IPMI를 대체하는 하이퍼바이저 호스트 OS : 서버에서 최초에 기동하는 OS 하드웨어 간 차이 흡수 → 환경 추상화 준 가상화 사용 리소스 소비 제어 과부하 경고 부하 조정 가상화 서버 구축정책 하드웨어의 이용효율을 높이기 위해 남아있는 리소스를 사용하는 게스트 OS를 투입하는 것이다. 예를 들어 CPU 리소스가 남이있으면 웹 서버, I/O 리소스가 남아있으면 DB 서버, 메모리 용량이 남아있으면 캐시 서버를 투입한다. 리소스 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 가동률을 100%로 끌어올려 시스템이 멈추지 않도록 하는 것 여기서 중요한 것은 SPOF (Single Point of Failure) 단일장애점을 제거하는 것이다. [강의33] 다중성 확보 다중성 확보 - WAS 서버 중요한 것은 여러대의 서버가 있을 때 몇대의 서버가 정지하더라도 서비스가 정상적으로 처리될 수 있는 상태를 만드는 것이다. 로드밸런서에서 failover를 처리할 수 있다. 고장난 서버를 분리시키고 정상적인 서버로 요청을 보내는 것 연결된 서버들에 대한 주기적인 헬스체크 failback 고장난 서버를 복구하고 다시 복귀시키는 것 다중성 확보 - DB 서버 마찬가지로 여러대의 DB 서버가 있을 때 몇대가 고장나더라도 요청을 정상적으로 처리할 수 있어야 한다. Master도 다중화 하면 좋다 → 하지만 어렵다. 책의 예시에서는 멀티 마스터를 사용하고 있다. 양쪽이 서로 slave 관계이…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의31] 계층과 확장성 확장성에 대한 요구 - 서버 1대에서 처리할 수 있는 트래픽 한계 (업데이트가 필요한 정보이다) 이 때 당시에 서버 한대로 처리할 수 있는 트래픽은 월 100만 PV 정도, 최고사양으로 100만 ~200만 까지도 감당할 수 있었다. 수천 ~1만 건/분 정도의 요청을 처리할 수 있는 정도이다. 더 대규모는 서버1대로 동작할 수 없다. 계층별 확장성 WAS는 상태를 가지고 있지 않으므로 단순히 대수를 늘리는 것으로 요청을 확장할 수 있다. 로드밸런서에 새로운 서버를 추가하면 된다. DB는 다른 방법으로 (쓰기, 읽기가 나뉘어져 있으므로) 더 많은 요소들을 고려하면서 확장해야한다. [강의32]부하 파악, 튜닝 부하 파악 - 관리화면 시각화의 중요성 각각의 서버에 관해서 그래프화 하는 것이 중요하다. 부하 측정을 위한 항목 Load Average, 메모리, CPU Load Ave…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의29] 엔터프라이즈 vs. 웹 서비스 엔터프라이즈 vs. 웹 서비스 - 응용범위로 보는 차이 웹 서비스의 특징 - 엔터프라이즈와 비교 트래픽 - 엔터프라이즈에 대규모 트래픽이 일어날 일은 많이 없지만 웹 서비스에서는 대규모 트래픽이 일어나고는 한다. 성장성 - 비즈니스와 연관된 엔터프라이즈는 급격히 성장하지는 않는다. 웹 서비스와 같은 경우는 폭팔적 성장이 가능하다. 신뢰성 - 사람의 목숨이나 돈에 관련된 일이 많기 때문에 높은 신뢰성이 요구된다. 웹 서비스는 인명이나 돈과 깊게 관련 없는 경우가 더 많기 때문에 그정도의 신뢰성이 중요하지는 않다. 트랜잭션 - 신뢰성과 비슷한 맥락의 이야기지만 더 DB에 한정되서 이야기 한다. 엔터프라이즈는 데이터의 정합성이 매우 중요하다. (은행에서 돈 예시) 웹 서비스는 (블로그와 같이) 정합성이 일치하지 않아도 큰 문제가 생기지 않는다. 웹 서비스의 인프…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의19] 알고리즘과 평가 데이터 규모와 계산량 차이 데이터가 클 수록 알고리즘이나 데이터 구조 선택이 속도에 영향을 미친다. ex. 선형탐색 vs. 이분탐색 알고리즘이란? 알고리즘은 값의 집합을 입력, 다른 값의 집합을 출력으로 하고 명확하게 정의된 계산절차이다. 유한한 자원인 CPU나 메모리를 어떻게 활용하여 문제를 해결해야 할까? 적절한 데이터구조를 사용하여 알고리즘을 구현해야지 효과가 있다. 결국 측정이 중요하다 !! 알고리즘을 활용한 데이터 처리 과도한 알고리즘이 항상 더 효율이 좋은 것은 아니다. 때로는 간단한 알고리즘이 더 시간을 줄여줄 때가 있다. 과도한 알고리즘의 경우 전처리에 많은 시간이 소요되기도 한다. 항상 측정이 중요하다. 단순이 데이터가 ‘적다’, ‘많다’ 라는 것으로 판단하는 것은 좋지 않다. 데이터 압축과 속도 - 전체적인 처리량을 높이기 위한 사고방식 압축이라는 것이…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 이전에는 미들웨어를 살펴보면서 운용에 대한 생각을 했다면 이제는 개발에 대한 생각을 하면서 어플리케이션 개발시 고려해야할 급소들에 대해서 살펴보도록 한다. 대량의 데이터에 액세스 (그리고 이러한 데이터들을 특정 부분을 절단하기 어려운 경우가 대부분이다)를 할 대 RDBMS, MySQL등에서 처리할 수 없는 규모의 데이터를 계산하고자 할 경우를 살펴본다. [강의14] 용도특화형 인덱싱 인덱스와 시스템 구성 - RDBMS가 한계를 보일 때 지나치게 많은 데이터를 다루는 경우 (검색 등) RDBMS로는 한계가 있다. 그렇다면 해결 방법은 ? 배치 처리로 RDBMS에서 대량의 데이터를 추출 별도의 인덱스 서버와 같은 것에 데이터를 보관 웹 어플리케이션에서 RPC(Remote Procedure Call)등으로 액세스 하도록 처리 RPC, 웹 API DB 가 정기적으로 데이터를 추출해서 인덱스 서버로 넘긴다.…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 검색엔진의 노하우를 알아두면 용도특화형 인덱스를 직접 만들어서 대규모 데이터에 대한 문제를 해결할 수 있다. [강의24] 전문 검색기술의 응용범위 키워드 역 인덱스 전문 검색의 종류 grep 형 전부 읽어가면서 검색하는 것 시간이 오래 걸린다. 즉시성이 좋다 → 문서가 갱신되더라도 바로 검색할 수 있으며 검색누락이 없다. 병렬화 하기가 간단하다 → 분할해서 검색하기 편리하다 suffix 형 검색 가능한 형태로 검색 대상 전문을 보유한다. 구현이 어렵다. 역 인덱스형 단어와 문서를 연관짓는 것 문서와 별도로 역 인덱스를 만들어야 한다. → 즉 전처리가 필요하다. 즉시성이 떨어진다. 인덱스를 압축함으로 컴팩트하게 가져갈 수 있다. 대규모화 하기 가 쉽다. [강의26]검색엔진의 내부구조 역 인덱스의 구조 - Dictionary + Postings 어떠한 단어 (dictionary 형태)에서 연결되어 있는…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의8] OS 캐시 구조 OS의 캐시 구조를 알고 애플리케이션 작성하기 - 페이지 캐시 OS는 메모리를 이용해서 캐시 구조를 갖추고 디스크 액세스를 줄인다. Linux(x86) 페이징 구조 OS는 가장 메모리 구조를 가지고 있는데 논리적인 선형 어드레스를 물리적인 어드레스로 변환한다. 가상 메모리 구조 기본적인 OS 구조를 보면 OS에서 관리하고 있는 메모리 구조 있고, OS가 있으며 OS에서 돌아가는 프로세스가 존재한다. 프로세스에서 메모리가 필요한 경우 메모리에 직접 접근해서 주소를 가져오는 것이 아니라, OS를 통해서 비어있는 주소와 다른 주소를 반환한다. 왜 가상 주소를 반환할까? 개별 프로세스가 실제로 메모리의 어느 부분을 사용하는지 스스로 알고 있을 필요가 없고, 특정 번지에서 통일해서 시작하는 것으로 다루면 더 쉽기 때문이다. 예) 유닉스에서 공유 라이브러리는 프로세스 내에서 지정된 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 이번장은 레이어를 DB로 옮겨서 DB의 스케일아웃 전략에 대해서 살펴본다. [강의11] 인덱스 올바르게 운용하기 분산을 고려한 MySQL 운용, 세 가지 포인트 OS 캐시 활용 인덱스를 적절하게 설정 확장을 전제로 한 설계 OS 캐시 활용 전체 데이터 크기가 물리 메모리보다 가능한 적도록 유지한다. 상황: 대규모 서비스일 경우 (3억건의 데이터), 테이블에 칼럼을 한 개 (약 8바이트)를 추가하더라도 3GB 가 추가된다. → 스키마도 신경써서 설계해야한다. 따라서 테이블의 레코드를 컴팩트하게 설계해야한다. (int형 32비트, 문자열 8비트 같은 수치에 대한 감각 필요) DB 테이블의 데이터를 정규화하는 것은 ? 예를 들어서 필수적으로 필요한 데이터만 테이블에 남기고, flag로 사용되는 데이터들을 테이블 분리하여 필요할 때만 사용할 수도 있다. 대규모 데이터인 경우 이것만 분리를 하더라도 엄청난 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의4] 어느정도가 대규모 데이터인가 ? 이때 당시의 수치임을 감안하고 보자 !! 하테나의 경우 레코드 건수 1500만, 5000만 entry 테이블이 3기가, bookmark 데이블이 5.5기가 등등 html 텍스트 데이터 압축 후 200 기가 이정도가 중규모 ~ 대규모 디비 규모가 기가바이트면 굉장히 많은 것이다. 인덱스 사용 안했을 때 1건 검색시 200초 소요 [강의5] 대규모 데이터는 어떤 점이 어려운가 한마디로 말하면 ‘메모리 내에서 계산할 수 없다’ 데이터가 너무 많으면 메모리 내에서 계산할 수 없으므로 디스크를 검색하면 읽어야하는데 디스크를 읽는 것은 계산량도 지나치게 많아지고 시간도 많이 소요된다. (I/O 시간) 메모리와 디스크 속도 차이는 10만 ~ 100만배 정도 디스크는 왜 늦나 디스크의 경우 헤드의 이동과 원반의 회전이라는 두 가지 물리적인 이동이 수반되며 속도가 저하된다…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 어느 정도가 대규모 인가 ? 이것은 이 책이 쓰여졌을 당시의 상황이다. 전혀 감이 없으니 이때 당시의 대규모 정도를 숫자로 파악해보자. 등록 사용자 100만 명 이상, 1500만 UU 서버 500대 이상 피크시 회선 트래픽 430Mbps [강의1] 소규모 서비스와 대규모 서비스의 차이 확장성 확보, 부하분산 필요 1대의 서버로 처리 할 수 없는 부하를 어떻게 처리할 것인가 ? 스케일 아웃 → 서버 대수를 늘림으로 스스템 처리능력을 높임 스케일 업 → 하드웨어 성능을 높여 처리 능력을 끌어올림 여러대의 서버를 사용했을 때 파생되는 문제 데이터 동기화, 네트워크 통신 지연시간, 다중성 확보 특정 서버가 고장이 나도 서비스를 계속 할 수 있어야 함 스케일아웃은 서버의 고장율이 올라가고 하나가 고장났다고 전체가 정지해버릴 순 없다. 시스템이 고장나면 다른 시스템이 자동으로 처리를 인계받는 시스템 설계가 …