본문 바로가기

관심사/도서

<마틴 클러스만> 데이터 중심 애플리케이션 설계 01장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 트위터의 데이터 파이프라인 사례 System design for Twitter The Architecture Twitter Uses To Deal With 150M Active Users, 300K QPS, A 22 MB/S Firehose, And Send Tweets In Under 5 Seconds 꼬리 지연 시간 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요하다. 예를 들어 아마존은 내부 서비스의 응답 시간 요구사항을 99.9분위로 기술한다. 99.9분위는 요청 1000개 중 1개만 영향이 있음에도 말이다. 보통 응답 시간이 가장 느린 요청을 경험한 고객들은 많은 구매를 해서 고객 중에서 계정에 ..
도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문 03. 컨테이너 실전 구축 및 배포 애플리케이션과 시스템 내 단일 컨테이너의 적정 비중 도커는 애플리케이션과 인프라를 도커 컨테이너라는 단위로 분리한 것이라 볼 수 있다. 이런 관점에서 웹 애플리케이션과 워커형 상주 애플리케이션 프로세스 하나를 하나의 컨테이너로 만드는 방식 (컨테이너 1개 = 프로세스 1개)이 괜찮게 생각될 수 있다. 실제로 도커 초기에는 "컨테이너 1개 = 프로세스 1개"를 반드시 지켜야 한다고 생각하는 사용자가 있어 자주 토론거리가 됐다. 그러나 "컨테이너 1개=프로세스 1개" 원칙을 고수하는 것은 무리이다. 예를 들어, 크론 프로세스에서, 다른 job을 실행하는 경우가 있다. 사실 도커 공식문서에는 "컨테이너는 하나의 관심사에만 집중해야 한다"라고 적혀있다. 즉, 컨테이너 하나가 ..
최범균 <DDD START! > 4-5장 요약 4장. 리포지터리와 모델 구현 별도 테이블에 저장하는 밸류 매핑 애그리거트에 속한 객체가 밸류인지 엔티티인지 구분하는 방법은 고유 식별자를 갖는지 여부를 확인하는 것이다. 하지만 식별자를 찾을 때 매핑되는 테이블의 식별자를 애그리거트 구성요소의 식별자와 동일한 것으로 착각하면 안된다. 별도 테이블로 저장되고 테이블에 PK가 있다고 해서 테이블과 매핑되는 애그리거트 구성요소가 고유 식별자를 갖는 것은 아니다. 보통 주문 애그리거트는 실주문을 의미하는 Order 테이블과 주문 품목을 의미하는 Order Lines 테이블로 구성되어 있다. 여기서 주문 품목(Order Lines)은 밸류이다. Order Lines 테이블도 고유 PK를 갖고 있지만, 주문 애그리거트를 식별하는 고유 식별자는 주문번호이다. (위 ..
위르헌 아펄로 -Management 3.0 9. 제약 조건을 정렬하는 방법 여러분의 목표와 팀의 목표를 절충하자 팀과 목표가 부딪히면 그걸 해결해야 할 것이다. 팀의 결정을 무시하면 매우 갚기 어려운 동기 부채가 생길 것이고, 그건 상황을 더욱 어렵게 만들 뿐이다. 권한 경계 목록을 만들자 권한 경계 목록을 만들면 사람들이 전기 철조망에 뛰어들지 않아도 되기 때문에 사람들에게 동기를 부여하고 생산성을 유지할 수 있다. 10. 규칙을 만드는 기술 애자일의 맹점 애자일 선언의 애자일은 팀이 훌륭할 때만 훌륭하다. 애자일 선언이 역량 문제를 해결해주지는 않는다. 프로젝트의 치사율을 낮추고 싶은 애자일 관리자라면 아래의 기본 원칙을 응용할 수 있다. 문화 : 사회 시스템의 역량을 높이기 위해 어떤 방법을 적용하든, 결국 모든 것은 사람이 진심으로 관심이..
<사이트 신뢰성 엔지니어링> - 2부 요약 본문 중에서...Chapter 6. 분산 시스템 모니터링 알럿 호출 방식 철학매번 호출기가 울릴 때마다 긴급한 상황임을 인지하고 그에 대응할 수 있어야 한다. 이러한 긴급 호출은 빈번한 호출로 인한 피로를 느끼지 않도록 하루에 단 몇번 정도만 발생해야 한다.모든 호출은 대응이 가능해야한다.호출은 새로운 문제나 지금까지 보지 못한 사건에 대한 것이어야 한다.호출에 대한 모든 대응은 이성적이어야 한다. 장기적 모니터링 장애 호출에 대해 이미 정해진 규칙에 의해 대응하는 것은 위험 신호다. 팀의 그 누구도 이런 호출에 대해 자동화를 할 의지가 없다는 것은 팀이 스스로 만든 기술 부채를 해소할 자신이 없다는 것을 암시한다. 한 걸음 더 나아가기 순수한 노력의 힘은 너덜너덜한 시스템을 고가용성을 갖춘 시스템으로 ..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 9장 요약 Chapter 9: Why It's Always Hard to Steer9.2.2 The history of software engineeringThe Size/Complexity Dynamic 은 문제의 크기가 커질수록 복잡도가 제곱으로 높아지는 문제 유형을 말한다.소프트웨어 역사를 보면, 성공하는 경험을 할 수록, 조직은 점점 더 어려운 문제를 찾고, 도전해왔다. 그러면서 소프트웨어가 발전해왔다. 위의 그림은 소프트웨어 개발에 대한 effect diagram이다.소프트웨어 조직이 성공을 경험하면 -> 도전적인 과제를 찾아서 -> 문제의 크기가 커져서 -> 솔루션의 복잡도가 높아진다.문제의 난이도가 높아지면, 처음에는 개발자수를 늘리고, 고급인력을 채용하면서 리니어하게 문제를 해결할 수 있다. 그런데 ..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 4장 요약 How Software Is Built 본문 중에서..4.1 Shooting at Moving TargetsWhen teaching someone to shoot at a moving target, you cannot give instructions about which direction to shoot, because the direction is constantly changing. Instead, you must give general instructions about aiming guns, instructions that can then be applied to a wide variety of moving targets. That's why the study of patterns of softwa..
마틴파울러 <NoSQL 빅데이터 세상으로 떠나는 간결한 안내서> - 15장 데이터베이스 선정 본문 중에서... 15장 데이터베이스 선정NoSQL 기술을 사용하는 데는 두가지 주요 이유가 있다.애플리케이션의 필요에 더 잘 부합하는 데이터베이스를 사용해 프로그래머 생산성을 향상시키기 위해.대용량 데이터 처리, 지연 시간 감소, 처리량 증가를 통해 데이터 접근 성능을 향상시키기 위해NoSQL 기술을 사용하기로 결정하기 전에 프로그래머 생산성과 성능에 대한 기대를 테스트로 확인하는 것이 필수다.서비스를 캡슐화하면 필요에 따라 데이터 저장소 기술을 변경할 수 있다. 애플리케이션 일부를 서비스로 분리하면 기존 애플리케이션에서도 NoSQL을 도입할 수 있다.대부분의 애플리케이션에서, 특히 전략적인 것이 아니라면 관계형 기술을 계속 사용해야 한다. 적어도 NoSQL 생태계가 더 성숙해질 때까지는 그렇다. 관계..