공부하는 개발자

1부. 더 큰 그림 1. 단위 테스트의 목표 단위 테스트에 시간을 투자할 때는 항상 최대한 이득을 얻도록 노력해야 하며, 테스트에 드는 노력을 가능한 줄이고 그에 따르는 이득을 최대화 해야 한다. 단위 테스트의 목표 : SW 프로젝트의 지속 가능한 성장을 가능하게 하는 것 지속 가능한 프로젝트 성장을 위해서는 '고품질' 테스트에만 집중해야 한다. 코드 커버리지 코드 커버리지가 너무 적을 때는 테스트가 충분하지 않다는 좋은 증거이다. 그러나 반대의 경우는 그렇지 못하다. 100% 커버리지라고 해서 반드시 양질의 테스트 스위트라고 보장하지는 않는다. 높은 커버리지의 테스트 스위트도 품질이 떨어질 수 있다. 테스트 스위트의 품질을 결정하는 데 어떤 커버리지 지표도 의존할 수 없는 이유는 다음과 같다. 테스트 ..

웹 크롤러는 몇 개 웹 페이지에서 시작하여 그 링크를 따라 나가면서 새로운 컨텐츠를 수집한다. 크롤러는 다양하게 이용된다. 검색 엔진 인덱싱 웹 페이지를 모아 검색 엔진을 위한 로컬 인덱스 생성 웹 아카이빙 나중에 사용할 목적으로 장기보관하기 위해 웹에서 정보를 모으는 절차 웹 마이닝 인터넷에서 유용한 자료를 도출 (주주 총회 자료 or 연차 보고서 저장 등) 웹 모니터링 인터넷에서 저작권이나 상표권이 침해되는 사례를 모니터링 웹 크롤러의 기본 알고리즘은 간단하다. URL 집합이 입력으로 주어지면, 해당 URL 들이 가리키는 모든 웹 페이지를 다운로드 한다 다운받은 웹 페이지에서 URL들을 추출한다. 추출된 URL들을 다운로드할 URL 목록에 추가하고 위의 과정을 처음부터 반복한다. 요구사항 정성적 측면..

bit.ly 를 생각하면 된다. 크게 2가지 기능이 존재함 긴 URL을 넣으면 짧은 URL을 알려준다 (POST) 단축된 URL을 넣으면 원래 URL을 알려준다 (GET) - redirect 기본적인 요구사항 기본 : 높은 가용성, 규모 확장성, 장애 감내 쓰기 연산 트래픽 : 매일 1억건 서비스 유지 기간 : 10년 정도 이를 통해 다음과 같은 조건을 추가로 유추할 수 있다. 초당 쓰기 연산 횟수 : 1160회 (매일 1억건이므로 86400초로 나눔) 읽기 연산을 쓰기 연산의 10배로 가정시 읽기 연산 초당 11600회 TPS 13,000 ~ 14,000 하루 1억건씩 10년이면 총 3650건의 레코드 보관 1레코드 당 100byte 가정시 36.5TB 필요 비즈니스 조건 URL의 길이는 가능한 짧으면..

좋은 단위 테스트에는 다음 4가지 특성이 있다. 회귀 방지 리팩토링 내성 빠른 피드백 유지 보수성 하나씩 살펴보자 회귀 방지 회귀방지란 SW 버그를 방지할 수 있어야 한다는 의미이다. 코드 수정 후 버그가 있었는데 테스트가 통과하면 안된다. 회귀방지를 평가하려면 다음 사항을 고려해야 한다. 테스트 중에 실행되는 코드의 양 코드 복잡도 코드의 도메인 유의성 회귀방지를 극대화하려면 테스트가 가능한 많은 코드를 실행하는 것을 목표로 해야 한다. 리팩토링 내성 리팩토링 내성은 테스트를 실패로 바꾸지 않고 기본 애플리케이션 코드를 리팩토링 할 수 있는지에 대한 척도이다. 여기서 말하는 리팩토링이란 코드의 비기능적 특징을 개선하는 것으로 가독성을 높이고 복잡도를 낮추는 것이다. 예를 들어 메소드 이름을 바꾸거나 코..

분산 시스템에서 사용될 유일 ID 생성기 요구사항 ID는 유일해야 한다 ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이어야 한다. ID는 발급 날짜에 따라 정렬 가능해야 한다. 초당 10,000 개의 ID를 만들 수 있어야 한다. 선택지 다중 마스터 복제 특징 DB의 auto increment 기능을 활용하는 것이다. 다만 다음 ID를 구할 때 1만큼 증가시키지 않고 k 만큼 증가시킨다. 간단하게 적용할 수 있는 방식이고, 한 데이터 센터에서 어느정도 확장도 가능하다 단점 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다. ID의 유일성은 보장되겠지만, 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다. k가 고정되고 ..

키-값 저장소는 키-값 DB라고도 불리는 비 관계형 DB이다. 키는 유일해야 하며, 키에 매달린 값은 키를 통해서만 접근할 수 있다. 키-값 저장소로 널리 알려진 것으로는 아마존 다이나모, memcached, Redis 같은 것들이 있다. 분산 키-값 저장소 분산 키-값 저장소를 설계하기 전에, 단일 키-값 저장소를 생각해보자. 단일 키-값 저장소는 간단하다. 키-값 쌍 전부를 메모리에 hash table로 저장하면 된다. 또한 2가지 개선책 1) 데이터 압축 2) 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장 을 이용하면 조금 더 나은 단일 키-값 저장소를 만들 수 있다. 하지만 한 대 서버로는 부족한 때가 찾아오며 결국은 분산 키-값 저장소를 활용할 수 밖에 없다. 먼저 분산 시스템을 설..

수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 안정 해시 설계는 이 목표를 달성하기 위해 보편적으로 사용하는 기술이다. 해시 키 rehash 문제 자 여러분~ 한 번 생각해봅시다! cache 서버에 이런 저런 key-value를 넣어두려고 하는데 cache서버가 1, 2, 3, 4 총 4대 있어요! 방금 들어온 Apple 값은 어디 서버에 넣어야 할까요?!!! 우리의 목표 들어오는 req를 N개의 서버에 나눌 것인데, 1) 가능한 균일하게 2) N의 값에 변경이 있더라도 문제 없이 배분하고 싶다. 가능하면 modular 보다 좋은 방법으로...! 해시 : 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 mapping 하는 것 안정해시 : 해시 ..

처리율 제한 장치(rate limiter) : 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치 API 요청 횟수가 제한 장치에 정의된 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 중단된다. 몇 가지 예시 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다. 예시 요구사항 설정된 처리율을 초과하는 요청은 정확하게 제한한다. 낮은 응답시간 : 이 처리율 제한 장치는 HTTP 응답시간에 나쁜 영향을 주어서는 곤란하다. 가능한 한 적은 메모리를 사용해야 한다. 분산형 처리율 제한 - 하나의 처리율 제한 장치를 여러 서버나 프로세스에서 공유할 수 있어야..

https://meetup.toast.com/posts/246 유용한 테스트 케이스를 위한 개발자의 자세 : TOAST Meetup 각종 커뮤니티에 주기적으로 등장하는 "private 메서드를 테스트하려면 어떻게 하나요?" 혹은 "private 메서드를 테스트해야 하나요?"와 같은 질문을 보면서 언젠가는 관련해서 정리해봐야겠다고 생 meetup.toast.com 위 글을 읽으며, 다시 한 번 생각해볼만한 문구를 나름대로 정리! 좋은 글 감사합니다 🙇 무조건 TC를 작성한다고 도움이 되는 것이 아니다. TC는 적을 수록 좋다. 최소의 TC로 최대의 효과를 낼수록, 즉 효율이 높을수록 테스트의 가치는 더 뚜렷해진다. 반대의 경우라면 수많은 TC가 프로젝트의 민첩성을 떨어트리고 사사건건 발목을 잡을 것이다. ..

DSL : domain specific language DSL이란, 특정 영역을 타겟하고 있는 언어를 말한다 예를 들어 SQL! DB의 데이터를 참조하기 위해 날리는 query는 말 그대로 "DB에 데이터를 참조하기 위한 목적"으로만 사용되며 SQL로 웹 애플리케이션 서버를 만드는 것은 절대 불가능 하다. 반면 JAVA는 SQL을 만들어 낼 수도 있고 (사실상 SQL은 특정한 문법을 가진 문자열이기 때문이다) 웹 애플리케이션 서버를 만들 수도 있고, 그 외 원하는 모든 것을 만들어 낼 수 있다. 단지 다른 분야에선 다른 언어가 더 좋을 뿐이지 가능은 할 것이다. 이렇게 SQL처럼 어떤 목적이 있고 그 목적만 달성할 수 있는 언어를 DSL이라고 한다.