시작하기 전

원래 딴거 하다가 정리하려고 했는데 학교 선배가 취업한 라이너의 특강을 듣고 마음을 다잡고 정리한다 내용 정리라기 보다는 중요한 내용을 더 상세히 설명하면서 이해하는 느낌으로 작성할 것이다

유지보수하기 쉬운 애플리케이션

• 계산 중심 -> 데이터 중심
• 애플리캐이션의 구성 요소
  • 데이터베이스 : 나중에 다시 데이터를 사용 할 수 있게 저장
  • 캐시 : 읽기 속도 향상을 위해 값비싼 수행 결과를 기억
  • 검색 색인 : 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링
  • 스트림 처리 : 비동기 처리를 위해 다른 프로세스로 메세지 보내기
  • 일괄 처리 : 주기적으로 대량의 누적된 데이터를 분석
• 엔지니어는 완전히 새로운 데이터 시스템을 설계하지 않는다
• 그럼에도 현실에서는 다양한 구조의 데이터 시스템을 원하므로 다양한 규칙의 데이터 구조가 필요하다

데이터 시스템에 대한 생각

• 데이터 저장 / 처리를 위한 도구는 최근에 만들어 지고, 그것들은 다양한 사례에 특화되어 있기 때문에 전통적인 분류와 맞지 않는다
• 최근 데이터 시스템은 처리와 저장 모두 가능한 요구사항을 가지고 있다
• 즉, 단일 도구가 아닌 태스크로 여러 가지 일을 할 수 있도록 한다
• 이와 같은 예시로 엘라스틱서치가 있다

신뢰성

• 애플리케이션은 사용자가 기대한 기능을 수행한다
• 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있다
• 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다
• 시스템은 허가되지 않은 접근과 오남용을 방지한다
• 결함 : 잘못될 수 있는 일, 결함성 : 결함에 대응 할 수 있는 능력
• 장애 : 전체 시스템의 붕괴
• 겐지가 3단 점프를 한다 : 결함, 겐지를 픽하면 게임이 멈춘다 : 장에

하드웨어 결함

• 10000개의 디스크로 구성된 저장 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다
• 이러한 에러를 대처하는 방식이 복제이다
• 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 옮겨가고 있다.
• 게다가 이런 시스템에는 운영상 장점이 있다.
• 부팅해야하는 경우 단일 서버 시스템은 계획된 중단시간이 필요하지만 장비 장애를 견딜 수 있는 시스템은 전체 시스템의 중단시간 없이 한 번에 한 노드씩 패치할 수 있다

소프트웨어 오류

• 하드웨어 결함은 서로 상관관계를 가진다
• 또 다른 부류의 결함으로 시스템 내 체계적 오류가 있다. 이러한 결함은 하드웨어 결함과 달리 예상하기 어렵고, 자주 발생한다
• 시스템 오류의 종류
  • CPU, 메모리, 디스크 공간, 네트워크 대역폭처럼 공유 자원을 과도하게 사용하는 일부 프로세스
  • 시스템의 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
  • 한 구성 요소의 작은 결함이 다른 구성 요소의 겨람을 야기하고 차례차례 더 많은 결함이 발생하는 연쇄 장애
• 소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다.
• 상호작용과 가정에 대해 주의깊게 생각하기
• 빈틈없는 테스트, 프로세스 격리
• 죽은 프로세스의 재시작 허용
• 모니터링 등을 수행할 수 있다.

인적 오류

• 하드웨어 오류보다 인적 오류가 9배 더 많이 일어난다
• 최고의 시스템은 다양한 접근 방식을 결합한다
• 인적 오류를 줄이기 위해서
  • 오류의 가능성을 최소화하는 방향으로 시스템을 설계하자
  • 사람의 실수로 장애가 발생할 수 있는 곳과 그렇지 않는 곳을 분리하자
  • 단위 테스트부터 전체 테스트까지 철저하게 테스트하자
  • 장애 영향을 최소화할 수 있게 하자 (ex 롤백)
  • 성능 지표와 오류율같은 상세하고 명확한 모니타링 대책을 마련하자
  • 조작 교육과 실습을 실행하자

신뢰성은 얼마나 중요할까

• 신뢰성은 웹에서도 매우 중요한 요소이다
• 중요하지 않은 애플리케이션에서도 책임이 있다
• 비용을 위해 신뢰성을 낮춰야 할 상황이 생길 수 있다

확장성

부학 기술하기

• 시스템의 부하를 간결하게 기술해야 한다.
• 부하는 부하 매개변수(초당 요청 수, 데이터베이스 읽기 쓰기 비율, 동시 활성 사용자) 등으로 알 수 있다
• 트위터를 예시로 들어보자
  • 트위터에서는 2가지 주요 기능이 있다
    • 트윗 작성
      • 시용자는 팔로워에게 새로운 메세지를 게시 할 수 있다(평균 초당 4.6k 요청)
    • 홈 타임라인
      • 사용자는 팔로우한 사람이 작성한 트윗을 볼 수 있다
• 여기서 초당 12000건의 쓰기 처리는 매우 쉽지만, 이에 관한 *팬아웃이 발목을 잡는다
• *팬아웃 : 팬아웃(Fan-out)은 한 모듈이 직접 호출하는 다른 모듈의 개수 (팬아웃이 높으면 결합도가 증가해서 유지보수가 어려워진다)
• 개별 사용자는 많은 사람을 팔로우하고 많은 사람이 개별 사용자를 팔로우한다. 이에 대한 처리 방법은 2가지가 있다
• 트윗 작성은 간단히 새로운 트윗을 전역 컬랙션에 삽압한다. 사용자가 자신의 홈 타임라인을 요청하면 팔로우하는 모든 사람을 찾고 이 사람들의 모든 트윗을 찾아 시간순으로 정렬해서 합친다.

SELECT tweets.*, users.* FROM tweets
JOIN users ON tweets.sender_id = users.id
JOIN follows ON follows.followee_id = users.id
WHERE follows.follower_id = current_user

(즉 트윗 시 그냥 DB에 추가하고, 조회할 때는 팔로워의 모든 트윗을 정렬해서 보여준다)

• 각 수신 사용자용 트윗 우편함처럼 개별 사용자의 홈 타임라인 캐시를 유지한다. 사용자가 트윗을 작성하면 해당 사용자를 팔로우하는 사람을 모두 찾고 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다. 그러면 홈 타임라인의 읽기 요청 결과를 미리 계산했기 때문에 비용이 저렴하다

(즉 트윗 시 팔로워에게 올린 트윗 캐시를 추가해, 조회할 때 정렬없이 캐시만으로 바로 트윗을 볼 수 있다.)

• 트위터는 방식 1번에 한계를 느끼고 방식 2번으로 바꿨다

성능 기술하기

• 하둡 : 대규모 데이터를 분산처리하기 위한 오픈소스 프레임워크
• 온라인 시스템에는 응답 시간, 처리량이 중요하다
• 소요 시간들은 가끔 꽤 오래걸리는 특이 값이 있다
• 켄텍스트 스위치, 네트워크 패킷 손실과 TCP 재전송, 가비지 컬렉션 퍼즈, 디스크에서 일기를 강제하는 페이지 폴트
• 평균 응답 시간은 산술 평균(모든 값을 더하고 n으로 나눔)보다는 중앙값(모든 값의 정렬중 중앙에 있는 수)이 좋다
• 아마존은 응답 시간을 99.9분위의 값으로 기술한다. 웹사이트 지연이 1초 늘어날 때 마다 구매율이 현저히 낮아지기 때문이다

부하 대응 접근 방식

• 확장성의 종류로 수직 확장(더 강려한 장비로 이동), 수평 확장(다수의 낮은 사양 장비에 부하를 분산)
• 대게 대규모로 동작하는 애플리케이션은 그 상황에 특화되어 설계되어있다

유지보수성

운용성 : 운영의 편리함 만들기

단순성 : 복잡도 관리

• 프로젝트는 커질 수록 그에 따른 복잡도를 제어하기 어려워진다
• 복잡도는 모듈 간 강한 커플링, 복잡한 의존성, 일관성 없는 명명과 용어, 임시 방편으로 문제를 해결한 특수 사례
• 우발적 복잡도를 해결하기 위한 최상의 도구는 추상화이다

발전성 : 변화를 쉽게 만들기

마무리

이 속도면 다하는데 한달 걸릴 거 같다