다음 글은 Real MySQL 스터디를 진행하면서 정리한 4.1장 내용입니다. 🙌 💡 Intro 프로젝트를 진행해보니 서비스의 대부분의 병목은 데이터베이스에서 발생한다는 것을 알 수 있었다. DBA가 아니더라도 기본적으로 파생된 쿼리가 어느 과정을 거쳐서 처리되는지, 성능을 좌우하는 시스템 변수들은 어떠한 것들이 있는지 아는 것이 매우 중요하다고 생각한다. MySQL 엔진은 데이터베이스의 뇌의 역할을 한다. 기본적은 서버 구조와 MySQL 엔진과 스토리지 엔진의 차이점 및 담당 부분을 이해해보자. 🌩 MySQL 서버의 구조 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진(InnoDB, MyISAM)이 있다. 스토리지 엔진은 핸들러 API를 만족하면 직접 구현하여 추가해서 사용할 수 있다. 🌩 MySQL 엔진 아키텍쳐 MySQL 전체구조 MySQL 엔진 먼저 MySQL 서버는 대부분의 상용 언어에서 지원할 수 있으며 MySQL 서버의 커넥션 핸들러에서 커넥션을 관…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 11] equals를 재정의하려거든 hashCode도 재정의하라 와 함께 도 재정의하지 않으면 이나 의 원소로 사용할 때 일관성이 무너진다. Object 명세에 따르면 다음 규약이 있다. eqauls(Object)가 두 객체를 같다고 판단하면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. 다시 말해서 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다는 것이다. 해시코드가 같지 않으면 다음 코드에서 일관성이 깨진다. 좋은 hashCode를 작성하기 hashCode의 로컬 int 변수 result를 첫번째 핵심 필드의 해시코드로 초기화 한다. (여기서 해시코드는 다음 2.a 단계대로 계산한다.) 다음 핵심 필드 들에 대해서 다음과 같이 해시코드를 계산하고 result 필드를 갱신한다. 기본 타입 필드라면 Type.hashCode(f)를 수행한다. Type은 해당 기본 타입의 박싱 클…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 9] try-finally 보다는 try-with-resources를 사용하라 자바에서 close 메서드를 직접 호출해서 닫아주어야하는 자원들 , , 등등 try-finally 사용시 단점 try-finally를 사용한다면 닫아야 하는 자원이 많아질수록 매우 복잡해진다. try 블록과 finally 블록에서 모두 예외가 발생할 수 있는데, 만일 둘다 예외가 발생했을 경우 이후에 일어난 예외가 첫번째 예외를 삼켜서 디버깅을 어렵게 한다. try-with-resources로 해결 짧고 간결하여 읽기가 수월하다. try 내부와 에서 모두 예외가 발생 하더라도 첫번째 예외만 보여지고 두번째 예외는 되어 출력된다. catch 블록을 함께 사용하여 여러 예외를 처리할 수 있다. 🌩 [아이템 10] equals는 일반 규약을 지켜 재정의하라 대부분은 를 재정의 하지 않는 것이 가장 좋다. 책에서는 특히나…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 7] 다 쓴 객체 참조를 해제하라 JVM 언어를 사용한다면 GC가 알아서 사용되지 않는 객체를 해제할텐데 왜 이런 항목이 있는걸까? 다음과 같은 경우에는 GC가 해당 객체가 다 쓴 객체인지 아닌지 판단할 수가 없다. Stack 자료구조를 구현한 예시이다. 다음과 같은 경우 다시 참조되지 않을 객체에 대한 해제가 이루어지지 않았기 때문에 ‘메모리 누수’가 발생한다. 이 프로그램이 오랜시간 실행이 되다보면 메모리 사용량이 늘어나 성능이 저하되거나 심하면 를 일으킬수도 있다. 위 코드와 같은 경우 배열에 더이상 사용되지 않는 영역의 객체 참조를 배열이 여전히 가지고 있다. 예를 들면 바깥에 존재하는 객체들에 대해서 말이다. 이렇게 GC에게 객체 처리를 맡기는 언어에서 이러한 메모리 누수를 찾기가 매우 어렵다. 또한 쓰이지 않지만 참조되고 있는 객체의 영향이 해당 객체에서 끝이 나는 것이 아니라 해…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 5] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 하나의 클래스에서 다른 자원에 의존하는 경우가 많다. 또한 해당 클래스가 유틸리티 클래스라면 싱글톤이나 정적 클래스로 사용되는 경우가 많다. 정적 클래스로 구현한 경우 싱글톤으로 구현한 경우 그런 경우 여러 단점이 발생한다. 유연하지 않다. 안에 의존하고 있는 객체를 런타임 시점에 바꾸거나 조작하기가 어렵다. 여러 다른 사전들을 이용하고 싶을 때 변경에 자유롭지 못하다. 테스트하기 어렵다. 정적으로 의존 객체를 내부에서 생성하므로 모킹하거나 해당 객체에 대한 조작으로 테스트를 하기 어렵다. 의존성 주입(DI)을 통해 해결하기 위 문제에 대한 가능한 해결방법이 DI 말고 하나가 더 있다. 변경에 대한 유연성을 부여하기 위해 을 제거하고 여러 사전들을 바꿔서 사용할 수 있도록 한다. 이렇게 할 경우 멀티스레드 환경에 취약하고 오류를 내기가 …

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 3] private 생성자나 열거 타입으로 싱글턴임을 보증하라 하나의 인스턴스만 생성할 수 있는 것이 싱글턴(Singleton) 패턴이다. 참고로 싱글턴을 사용할 경우 이것을 사용하는 클라이언트를 테스트하기가 어렵다. 싱글턴 객체의 생성지점을 제어하기 어려우므로 mock으로 대체하기가 어렵기 때문이다. 싱글턴 객체를 구현하기 위해서는 다음 3가지 방법을 사용할 수 있다. 1) private 생성자 & public static final 필드 생성자의 접근제어자가 private이므로 인스턴스는 오직 필드를 초기화할 때 단 한번만 생성된다. 일반적인 경우 클라이언트는 이 부분에 대한 권한이 전혀 없지만 예외적으로 을 사용한다면 private 생성자를 호출할 수 있기는 하다. (방어를 위해서는 두번째 생성자 호출시 예외발생) 장점 필드를 사용할 경우 싱글턴이라는 것이 분명히 드러난다. (이므로 재…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 1] 생성자 대신 정적 팩터리 메서드를 고려하라 정적 팩터리 메서드(static factory method)란? 해당 클래스의 인스턴스를 반환하는 정적 메서드이다. 예를 들어 다음 박싱 클래스를 반환하는 정적 메서드를 보자. 이 챕터에서 추천하는 바는 public 생성자 대신 정적 팩터리 메서드를 고려해보라는 것이다. 정적 팩터리 메서드는 장단점이 있다. 따라서 항상 정적 팩터리 메서드가 더 우수하다는 것은 아니다. 다만 습관적으로 public 생성자를 사용하기 이전에 상황을 살피고 정적 팩터리 메서드가 더 적합하다면 해당 메서드를 사용하도록 추천한다. 장점 이름을 가질 수 있다. 여러 종류의 생성자가 필요로 할 경우 매개변수의 수를 다르게 해서 추가하곤 한다. 하지만 이 매개변수와 생성자 자체로는 반환될 객체의 특성이나 언제 이 생성자가 사용이 되는지 설명할 수 없다. 따라서 이름을 가진 정적…

💡 Intro 애자일의 의도는 불확실성이 큰 소프트웨어 개발 분야에서는 꼼꼼한 초반 계획을 세우고 이행하는 형태는 불가능하다는 것에서 출발한다. 따라서 애자일은 불확실성이 더 큰 프로젝트일수록 적합하다. 하지만 저자는 애자일을 단순한 소프트웨어 개발론으로만 보지 않고 하나의 일하거나 삶을 사는 스타일로 확장해서 해석해본다. 어떻게 우리 삶에서, 일에서 애자일을 적용할 수 있을까? 지금까지 말한 학습과 협력이 애자일의 핵심 전략이 될 수 있다. 불확실성이 높은 프로젝트 일수록 안좋은 일이 생기기 쉽다. 그리고 안좋은 일은 ‘또는’ 조건에서 생기기 마련인데 애자일은 앞서 말한 서로의 업무를 공유하고 상호 검토하는 협력을 통해 ‘또는’ 조건을 ‘그리고’ 조건으로 만들어 확률을 낮춘다. 또한 좋은 일은 확장될 수 있도록 ‘또는’ 조건을 공유를 통한 ‘그리고’ 조건으로 변경한다. 공유를 통해 전체가 개선되도록 하는 것이다. 이 글은 세 번째 파트인 애자일 파트이다. 🌩 애자일의 씨앗 애자일…

💡 Intro 주로 협력이라고 하면 초반에 일을 나누고 선을 그어 따로 진행하는 것처럼 생각한다. 실제로 일을 나누는 것은 초반에 하기 어렵다. 왜냐면 그 일이 무엇인지 잘 모르기 때문이다. 그럼에도 불구하고 사람들은 일을 초반에 나누고 따로 진행하면서 협력이 아닌 협력을 한다. 요즘에 ‘함께’라는 것이 중요 키워드다. 회사와 구성원이 함께, 팀원들이 함께 성장하는 것에 관심이 많다. 이 글은 두 번째 파트인 함께 파트이다. 🌩 소프트웨어 관리자의 우선순위 다음 4가지 영역이 소프트웨어 개발의 관리에 영향을 미치는 요소들이다. 도구: 소프트웨어 개발에 사용하는 도구 사람: 사람의 능력과 경험 시스템: 제품의 복잡도, 요구 신뢰성, DB 크기 등등 관리: 사람을 배정하고 작업을 분배하고 위임. 작업을 모니터링, 동기 고취 환경 개선, 리스트 확인 및 적절한 조치 등등 주로 개발 비용을 개선하려면 도구나 사람을 개선한다. 즉, 더 좋은 도구로 바꾸거나 더 실력있는 사람을 데리고 오는 …

💡 Intro 개발바닥의 김영한님 편을 보다가 꼭 추천하실 책이 김창준님의 함께 자라기라고 하셔서 바로 주문했다. 이 책을 읽으면서 얻고 싶은 것은 3가지였다. 내가 지금 성장하고 있는 방법이 잘 하고 있는 방법인가 요즘 그렇게도 강조하는 ‘함께’라는 것이 개발자에게는 어떤 의미인가 최근 진행한 7명 팀 프로젝트를 더 잘 할 수 있는 부분은 무엇이 있었을까 이 글은 첫번째 파트인 자라기 파트이다. 🌱 자라기 시간에 비례하여 실력이 상승하지 않는다. 중요한 것은 얼마나 오랜 기간 학습했느냐보다 얼마나 많은 의도적 수련을 했는지다. 업무를 하면서 의도적 수련을 할 수 있는 방법은 애자일 철학을 활용하는 것이다. 애자일에서 학습은 소프트웨어 개발에 큰 병목 중 하나이다. 그 이유는 일반 프로젝트에서 피드백의 주기가 느려서 결정을 내리고 학습을 한 후 다시 피드백을 받응ㄹ 시기에 이전에 내린 결정에 대한 이유를 기억하기 어렵다. 하지만 애자일 프로젝트에서는 당장 한 행동에 대한 피드백을 …

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH9. 디스크 관리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 컴퓨터 시스템의 대표적인 2차 저장장치이다. 메모리는 휘발성이지만 디스크는 데이터를 영구저장할 수 있다. 🌩 1. 디스크의 구조 디스크 외부에서 디스크를 일정크기 저장공간들로 이루어진 1차원 배열로 취급한다. 그 저장공간들을 논리 블록 logical block 이라고 한다. 디스크에 데이터가 저장될 때 논리블록 단위로 저장되고, 입출력도 논리블록 단위로 전송된다. 데이터 접근을 위해 배열처럼 블록 인덱스를 디스크에 전달하고 디스크 컨트롤러가 해당 논리블록의 물리적 위치를 찾아 요청 데이터에 대한 입출력 작업을 수행한다. 섹터 sector - 논리 블록이 저장된 물리적 위치 논리블록과 섹터는 1대1 매핑 디스크는 마그네틱 원판들로 구성되며 원판은 트랙, 트랙은 섹터로 나뉜다. 원판의 동일한 위치의 트랙들을 실린더라고 부른다. 디스크의 가장 바깥 실린더의 첫 트랙의 …

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH8. 가상 메모리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 시분할 환경에서는 여러 프로세스가 동시에 메모리에 올라와서 수행되기 때문에 어떤 메모리에 어느 정도의 메모리를 할당해야할지가 문제이다. 운영체제는 몇몀 프로그램에게 집중적으로 메모리를 할당하고 시간이 흐른다음 메모리를 회수하여 다른 프로그램에게 집중적으로 메모리를 할당하는 방식을 택한다. 프로그램마다 프로세스를 빠르게 수행하기 위해서 확보해야하는 최소한의 메모리 크기가 있기 때문이다. 프로세스의 전체가 올라가는 것이 아니라 스왑 영역에 일부분은 내려놓기 때문에 프로세스 입장에서 물리 메모리 크기 제약은 생각하지 않게 된다. 또한 운영체제는 각 프로세스가 자기만 메모리에 올라간 것처럼 여겨질 수 있는 가장 메모리를 지원한다. 각자의 주소 공간을 가정하여 모든 프로세스가 0번지부터 시작한다. 일부는 스왑 영역에 일부는 메모리에 있다. 프로세스의 주소 공간을 메모리로 …

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH7. 메모리 관리를 읽고 정리한 내용입니다 🙌 🌩 들어가기 전 우리가 흔히 사용하는 컴퓨터 주소 체계는 32비트 혹은 64비트로 나뉘어져 있다. 32비트면 32개의 비트로 주소를 표현할 수 있는 것이다. 2^32가지 다른 메모리 위치를 구분할 수 있다. 컴퓨터는 바이트 단위(8비트)로 주소를 부여한다. 따라서 2^32 바이트 만큼의 메모리 공간에 서로 다른 주소를 할당할 수 있다. 32 비트를 계층적으로 묶어서 관리한다. 보통 4KB (2^12 바이트) 단위로 묶어서 페이지(page)를 구성한다. 페이지 내에서 주소를 구분하기 위해서는 12비트가 필요하다. 따라서 32비트 중 하위 12비트는 페이지 내에서 주소를 나타낸다. 🌩 1. 주소 바인딩 프로세스의 주소 공간 (address space)는 프로그램이 실행되기 위해 메모리에 적재되면 프로세스를 위한 독자적인 주소 공간이 생성된다. 논리적 주소 (logical addres…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH6. CPU 스케줄링를 읽고 정리한 내용입니다 🙌 🌩 INTRO CPU는 PC가 가리키는 명령어를 하나씩 수행하기 때문에 효율적으로 관리해야한다. 기계어 명령은 다음 3가지로 나뉜다. CPU 내에서 수행되는 명령 ADD 명령 수행 속도 빠르며 일반명령 CPU 버스트 메모리 접근을 필요로 하는 명령 LOAD 명령 메모리에 있는 데이터를 CPU로 읽는 명령 CPU 명령보다는 오래 걸리지만 비교적 빠르며 일반명령 CPU 버스트 입출력을 동반하는 명령 입출력 작업이필요한 경우이며 오랜 시간이 소요 특권명령으로 운영체제를 통해 서비스를 대행해야한다. I/O 버스트 CPU 수행은 위 명령어의 조합과 반복으로 이루어진다. 각 프로그램마다 위 명령어들의 비율이 다르며 CPU 연산이 많이 이루어지는 것을 CPU 바운드 프로세스, I/O 연산이 많이 일어나는 것을 I/O 바운트 프로세스라고 한다. I/O 바운드 프로세스는 사용자 인터렉션이 많…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH5. 프로세스 관리를 읽고 정리한 내용입니다 🙌 🌩 1. 프로세스의 개념 프로세스란 실행 중인 프로그램이다. 프로세스는 CPU를 획득해서 코드를 수행하고 CPU를 반환하고 입출력 작업을 수행하기도 한다. 프로세스 문맥 (context) - 프로세스가 현재 어떤 상태에서 수행되고 있는 규명하기 위해 필요한 정보 여러 프로세스가 CPU를 사용하면서 중간에 CPU를 다른 프로세스에게 넘겨야 한다. 이때 다시 이어서하기 위한 필요 정보가 있는데 그것을 프로세스 문맥이라고 한다. 프로세스의 주소 공간, 레지스터의 값, 시스템 콜을 통해 커널에서 수행한 일의 상태, 프로세스에 대해 커널이 관리하고 있는 여러 정보들을 포함한다. 프로세스 문맥은 3가지로 나뉜다. 하드웨어 문맥 CPU의 수행 상태를 나타낸다. 프로그램 카운터 값, 각종 레지스터에 저장하고 있는 값들이다. 프로세스의 주소 공간 코드, 데이터, 스택으로 이루어진 프로세스의 독…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH4. 프로그램의 구조와 실행를 읽고 정리한 내용입니다 🙌 🌩 1. 프로그램의 구조와 인터럽트 CPU에서 프로그램 명령을 실행하기 위해서는 프로그램 명령을 담은 주소 영역이 메모리에 올라가야한다. 주소 영역은 code(프로그램 함수들이 기계어로 변환되어 저장), data(전역 변수 등 프로그램이 사용하는 데이터 저장), stack(함수 복귀 주소 및 데이터 임시 저장)으로 구분된다. 함수를 호출하여 새로운 함수 위치로 점프할 때 다시 돌아올 주소를 스택 영역에 저장한다. 인터럽트 동작 원리도 함수의 호출과 비슷하다. 인터럽트 발생시 실행중이던 명령어의 위치를 저장한다. 처리루틴 후 해당 주소로 돌아와서 수행을 이어간다. 이 주소는 운영체제가 관리하는 PCB에 저장된다. 🌩 2. 컴퓨터 시스템의 작동 개요 CPU는 매 시점 특정 주소에 존재하는 명령을 읽어서 그대로 실행한다. CPU가 실행해야할 명령의 메모리 위치는 Progra…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH3. 컴퓨터 시스템의 동작원리를 읽고 정리한 내용입니다 🙌 🌩 1. 컴퓨터 시스템의 구조 내부 장치 - CPU, 메모리 외부 장치 - 디스크, 키보드, 마우스, 모니터, 네트워크 장치 등등 입출력장치라고 한다. 각 하드웨어 장치를 각각의 컨트롤러가 제어한다. 컴퓨터는 외부장치에서 내부장치로 데이터를 읽어 연산한 후 결과를 외부장치로 내보내는 방식으로 동작한다. input - 내부로 들어오는 것 output - 외부로 내보내는 것 여러 프로그램을 동시에 수행할 수 있도록 하는 것이 운영체제이기 때문에 항상 메모리에 상주한다. 전체가 상주하기엔 너무 낭비이기 때문에 꼭 필요한 부분만 항상 메모리에 상주하고 그 부분을 **커널(kernel)**이라고 한다. 🌩 2. CPU 연산과 I/O 연산 I/O 연산들은 입출력 컨트롤러가 담당하고 컴퓨터 내부의 연산은 메인 CPU가 담당한다. 입출력 장치와 메인 CPU는 동시 수행이 가능하다.…

다음은 반효경 교수님의 ‘운영체제와 정보기술의 원리’ CH2. 운영체제 개요를 읽고 정리한 내용입니다 🙌 🌩 1. 운영체제의 정의 운영체제란 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어이다. 사용자가 직접 하드웨어를 다루는 것이 쉽지 않기 때문에 하드웨어를 기본적으로 운용하는 운영체제를 탑재해서 사용하도록 한다. 좁은 의미 운영체제 vs. 넓은 의미 운영체제 운영체제도 소프트웨어이기 때문에 컴퓨터가 켜지면서 메모리에 올라가서 사용이 되어야 한다. 하지만 운영체제 전부를 메모리에 올려서 사용하기에는 리소스 낭비가 심하기 때문에 꼭 필요한 부분만을 전원이 켜짐과 동시에 메모리에 올린다. 메모리에 전원이 켜짐과 동시에 상주하는 부분을 커널이라고 한다 ⇒ 좁은 의미의 운영체제 이후 필요한 부분은 그때그때 사용자 유틸리티로 메모리에 올려서 사용한다 ⇒ 넓은 의미의 운영체제 파일 복사 등등 🌩 2. 운영체제의 기능 1) 하드웨어와 2) 사용자를 위한 역할 두가지를 중간에서 담당한다. 하드…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH6. 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다 입니다 🙌 🛺 [Story3] 웹 서버 소프트웨어가 리퀘스트 메시지의 의미를 해석하여 요구에 응한다. 1. 조회의 URI를 실제 파일명으로 변환한다 http 요청 메세지의 메소드와 URI에 따라서 웹 서버 내부의 동작이 달라진다. URI에 적힌 경로에 따라서 데이터를 얻어 응답하는 것이다. 하지만 이 데이터를 반드시 디스크에서 읽는 것은 아니다. URI에 기록된 경로명의 파일을 읽어오면 디스크의 파일이 전부 노출되기 때문에 무방비해진다. 해결 방법으로 웹 서버에 공개하는 디렉토리를 디스크의 실제 디렉토리가 아니라 가상으로 만든 디렉토리 구조를 사용하도록 한다. 웹 어플리케이션 내부에서 가상으로 설정한 디렉토리와 실제 데이터를 대응하여 해당 데이터를 반송하도록 한다. 만일 브라우저에서 보낸 URI에 마지막 파일명이 생략되면 def…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH6. 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다 입니다 🙌 🛺 [Story1] 서버의 개요 1. 클라이언트와 서버의 차이점 서버도 클라이언트로부터 전송된 패킷을 받기 위해서 준비 단계를 거쳐야한다. 서버와 클라이언트의 차이점 네트워크와 관련된 전체적인 구조는 비슷한 형태를 지니고 있다. 하지만 서버는 소켓을 미리 열고 클라이언트의 연결을 기다린다는 점, 여러 클라이언트와 소통해야 한다는 점에서 클라이언트와 차이점을 가지고 있다. 2. 서버 어플리케이션의 구조 서버 프로그램에서 다수의 클라이언트와 소켓 통신을 하기 위해서 다음과 같은 구조로 진행한다. 서버 프로그램에서 클라이언트의 접속을 기다리는 부분과 클라이언트와 대화를 하는 부분을 나눈다. 클라이언트와 대화를 하는 부분은 각 클라이언트와 1대1로 대화를 한다. 따라서 대화가 섞이지 않는다. 서버 OS의 멀티태스크, 멀티스레…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH5. 서버측의 LAN에는 무엇이 있는가?_방화벽과 캐시 서버의 탐험입니다 🙌 🛺 [Story4] 캐시 서버를 이용한 서버의 부하 분산 1. 캐시 서버의 이용 프록시 구조를 사용하여 데이터를 캐시에 저장한다. 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개한다. 중개하는 과정에서 웹 서버에서 받은 데이터를 저장해두고 가능하면 해당 데이터를 대신하여 응답한다. 웹 서버가 처리해야할 일을 실행하기 위해서 오랜 시간이 걸리는 반면 캐시 서버는 받은 데이터를 곧바로 송신만 하면 되기 때문에 매우 빠르다. 데이터가 자주 바뀌는 부분은 캐시 서버를 활용하기 어렵다. 하지만 캐시 서버에서 처리할 수 있는 얼마를 담당하면 웹 서버에 가는 부하도 줄어들어 처리속도도 향상된다. 2. 캐시 서버는 갱신일로 콘텐츠를 관리한다 캐시 서버가 동작할 때 캐시 서버를 웹 서버 대신 DN…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH5. 서버측의 LAN에는 무엇이 있는가?_방화벽과 캐시 서버의 탐험입니다 🙌 🛺 [Story1] 웹 서버의 설치 장소 1. 사내에 웹 서버를 설치하는 경우 사내 LAN에 서버를 설치하고 인터넷에서 직접 액세스 하는 경우 (a) 이 경우는 현재 주류가 아님 IP 부족 - 이 경우 서버와 클라이언트에도 글로벌 주소를 할당해야하는데 IP 주소가 매우 부족하다. 보안상의 이유 - 인터넷에서 들어오는 패킷이 그대로 중계되는데 어플리케이션에 보안 구멍이 있다면 어플리케이션은 무방비 상태가 된다. 방화벽 보안 문제를 해결하기 위해서 방화벽을 두어 관문의 역할을 하도록 한다. (b) 특정 서버에서 동작하는 특정 어플리케이션에 액세스 하는 패킷만 통과시키고 나머지는 차단하도록 한다. 외부 액세스가 허가되지 않은 어플리케이션에 대한 패킷은 차단이 되므로 도착하지 않는다. 액세스가 허가된 어플리케이션에 보안구…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH3. 케이블의 앞은 LAN 기기였다_허브와 스위치, 라우터의 탐험입니다 🙌 🛺 [Story3] 라우터의 패킷 중계 동작 1. 라우터의 기본 라우터의 동작은 스위치 허브와 비슷하지만 IP와 이더넷의 차이로 인한 세부 동작의 차이점이 있다. 라우터는 크게 1) 중계 부분과 2) 포트 부분으로 나뉘어져 있다. 중계 부분은 다음 중계 대상을 판단하고 포트 부분은 송수신 동작을 담당한다. 라우터의 포트 부분은 이더넷이나 무선 LAN 외에도 ADSL, FTTH 등의 통신 기술을 지원한다. 라우터의 내부 구조 포트 부분에서 패킷을 수신하며 포트 부분의 통신 기술 규칙에 따라서 수신한다. (포트 부분의 하드웨어 부분이 패킷을 수신하는 것) 중계 부분에서 받은 패킷의 수신처 IP주소와 중계 대상을 동록한 표를 대조하여 중계 대상을 판단한다. 해당 포트로 옮기고 포트의 하드웨어에 따라서 패킷 송신 동작을 실…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH3. 케이블의 앞은 LAN 기기였다_허브와 스위치, 라우터의 탐험입니다 🙌 🛺 [Story1] 케이블과 리피터, 허브 속을 신호가 흘러간다 1. 패킷 하나하나가 독립적으로 동작한다 케이블로 흘러간 패킷은 중계 장치를 경유해서 목적지에 도착한다. 중계 장치는 데이터의 내용을 보지 않고 헤더에 적힌 정보만 보고 중계한다. 기본적인 흐름은 LAN 어댑터 → 리피터 허브 → 스위칭 허브 → 라우터를 경유해서 인터넷으로 나가는 것이다. 2. LAN 케이블은 신호를 약화시키지 않는 것이 핵심이다 LAN 어댑터의 PHY(MAU)회로에서 신호가 나가 케이블에 흘러 리피터 허브의 커넥터 부분에 도착한다. 이때 케이블을 이동하고 그 길이가 길어지면서 신호가 약해져서 변형된다. 3. 꼼은 잡음을 방지하기 위한 방법이다. 선을 꼬게 되면서 전자파에 의한 잡음을 상쇄한다. 4. 리피터 허브는 연결되어 있는 전체 …

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH2. TCP/IP의 데이터를 전기 신호로 만들어 보낸다_프로토콜 스택과 LAN 어댑터의 탐험입니다 🙌 🛺 [Story4] 서버에서 연결을 끊어 소켓을 말소한다 1. 데이터 보내기를 완료하고 연결을 끊는다 소켓 연결 말소 시점은 한쪽이 데이터 보내기를 완료했을때다. 어느 측에서든 먼저 연결을 끊을 수 있도록 프로토콜이 설계 되어 있다. 주로 브라우저에서 요청을 보내고 서버에서 응답을 하면 서버 측에서 먼저 연결 끊기 동작을 실행한다. 메소드를 호출해서 연결끊기 동작에 들어간다. 연결끊기 동작 세부 로직 - 끊는 쪽 (예. 서버) 연결을 끊고자 하는 측이 TCP 헤더를 만들어서 FIN 컨트롤 비트를 1로 설정한다. 이 패킷을 IP 담당에게 요청하여 상대에게 송신한다. 자신의 소켓에 연결 끊기 동작에 들어갔다는 사실을 통지한다. 연결끊기 동작 세부 로직 - 상대 쪽 (예. 브라우저) 프로토콜 …

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH2. TCP/IP의 데이터를 전기 신호로 만들어 보낸다_프로토콜 스택과 LAN 어댑터의 탐험입니다 🙌 🛺 [Story1] 소켓을 작성한다. 1. 프로토콜 스택의 내부 구성 네트워크를 제어하는 다음 두 가지가 필요하다. 소프트웨어 - (OS 내장) 프로토콜 스택 하드웨어 - LAN 어댑터 아래가 네트워크 계층 구조이다. 어플리케이션에서 데이터 송신을 시작한다. 이때 소켓 라이브러리를 사용하여 리졸버로 DNS 서버를 조회하는 등의 동작을 실행한다. OS 내부에 있는 프로토콜 스택이 그 다음 작업을 의뢰받는다. TCP 혹은 UDP로 데이터를 송수신한다. IP 프로토콜로 패킷 송수신 동작을 제어한다. ICMP(패킷운반시 오류 통지, 제어용 메세지) 혹은 ARP(IP에 대응하는 MAC주소 조사)로 동작한다. LAN 드라이버는 LAN 어댑터라는 하드웨어를 제어한다. LAN 어댑터라는 하드웨어가 실제 …

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 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에 한정되서 이야기 한다. 엔터프라이즈는 데이터의 정합성이 매우 중요하다. (은행에서 돈 예시) 웹 서비스는 (블로그와 같이) 정합성이 일치하지 않아도 큰 문제가 생기지 않는다. 웹 서비스의 인프…

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH1. 웹 브라우저가 메시지를 만든다 입니다 🙌 🛺 [Story3] 전 세계의 DNS 서버가 연대한다. DNS 서버의 기본 동작 DNS 서버는 조회 메세지를 받고 그것에 대해 응답을 한다. 조회 메세지 내용 이름: 서버나 메일 배송 목적지 (@뒤 호스트) ex. www.example.com 클래스: 이전에 필요했으나 요즘에는 항상 인터넷을 나타내는 클래스 ‘IN’으로 표기됨 타입: 다음마다 응답 형태가 바뀐다. A: 이름에 지원되는 IP 주소 MX: 메일 배송 목적지 DNS 서버에서 위 3가지가 일치하는 응답 정보를 찾아서 등록된 IP 주소 등을 회신한다. MX, 메일 서버에 대한 응답인 경우 메일 서버의 우선순위 + 메일 서버의 이름, 해당 메일 서버의 IP 주소를 함께 회신한다. DNS 서버에서 취급하는 타입은 여러개가 있다. PTR, NS, SOA, CNAME 등등 도메인의 계층 정말 …

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

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

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

다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH1. 웹 브라우저가 메시지를 만든다 입니다 🙌 💡 개요 HTTP 리퀘스트 메세지를 작성한다. URL을 해독하는 곳에서 브라우저의 동작이 시작된다. 이 URL의 의미에 따라서 요청 메세지를 작성하고 요청 내용을 만든다. 이때 HTTP 라는 프로토콜이 사용된다. 웹 서버의 IP 주소를 DNS 서버에 조회 OS에 의뢰해서 요청 메세지를 송신할 때 송신대상의 IP주소를 알아야한다. URL의 웹 도메인명으로 DNS 서버를 조회해서 IP 주소를 조사한다. 전세계 DNS 서버 연대 다수의 DNS 서버가 연대하여 IP 주소를 조사한다. 프로토콜 스택에 메시지 송신을 의뢰 OS에 메세지를 송신하는 동작을 의뢰한다. OS에서 제공하는 규칙에 따라서 의뢰를 해야한다. 해당 프로그램을 직접 구현하는 것이 아니더라도 규칙의 큰 흐름을 알는 것이 중요하다. 🛺 [STORY1] HTTP 리퀘스트 메세지를 작성한다 U…

다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌 [강의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대의 서버로 처리 할 수 없는 부하를 어떻게 처리할 것인가 ? 스케일 아웃 → 서버 대수를 늘림으로 스스템 처리능력을 높임 스케일 업 → 하드웨어 성능을 높여 처리 능력을 끌어올림 여러대의 서버를 사용했을 때 파생되는 문제 데이터 동기화, 네트워크 통신 지연시간, 다중성 확보 특정 서버가 고장이 나도 서비스를 계속 할 수 있어야 함 스케일아웃은 서버의 고장율이 올라가고 하나가 고장났다고 전체가 정지해버릴 순 없다. 시스템이 고장나면 다른 시스템이 자동으로 처리를 인계받는 시스템 설계가 …