해당 컨텐츠는 주간동안 읽은 아티클 중 일부를 정리한 내용입니다.
Article
메모리 배리어
스터디 진행 중 애기가 나와서 찾아보았다. 우리가 작성한 코드들은 CPU 또는 컴파일러에 의해 순서가 보장되지 않을 수 있는데 이 순서를 강제하는 것을 메모리 배리어라 한다. 여기서 CPU가 연산의 순서를 바꿀 수 있다라는 문장이 나에게 시사하는 점이 있다.
컴퓨터 구조 시간에 배운 내용을 복기해보면 명령어 파이프라인은 효율적인 사용성을 위해 branch prediction 등의 다양한 최적화 기법을 사용하는데 이로 인해 명령어 사이클 실행 순서가 달라질 수 있다. 때로는 이러한 최적화 때문에 스펙터나 멜트다운 같은 보안적 이슈가 발생하기도 한다. 보안 이슈 뿐만 아니라 멀티 스레드 환경에서 값이 잘 못 동작할 위험도 있다.
이 말은 곧 CPU 최적화조차도 성능과 안전성 사이에 트레이드 오프가 있었다는 애기가 된다. 개발 세계에서 트레이드 오프는 언제나 존재한다. 결국 트레이드 오프를 잘하는 엔지니어가 잘하는 엔지니어다.
멀티 스레드 환경에서의 CPU 최적화로 인한 이슈가 잘 정리된 글을 발견했는데, 요건 차주 중으로 천천히 읽어볼 예정이다.
parallelStream 남용으로인한 장애경험기
위 아티클을 한줄로 요약하면 하나의 스레드 풀을 모든 parallelStream이 공유하게된다.이다. parallelStream의 스레드 풀의 스레드들이 Network I/O로 블락킹 되면서, parallelStream 사용하는 다른 곳에서도 영향을 받아 발생한 장애와 이를 찾아가는 과정을 짧게 정리가 잘되어 있다.
Book
데이터 중심 애플리케이션 설계 - 9장 일관성과 합의
선형성과 분산 트랜잭션, 합의 알고리즘 등 분산 시스템에서의 일관성에 대해 다루고 있다. 이 장에서 인상적이었던 부분에 대해 하나씩 살펴보자
선형성
선형성이란 최신성 보장으로 연산의 전체 순서를 보장할 수 있어야 한다. 가장 강한 일관성 보장이나 네트워크 결함등으로 인해 성능 저하가 발생할 수 있다. 대표적인 예시로 AWS S3의 PUT 연산이 있다. 이 연산은 모든 az에 데이터 삽입/갱신이 발생하기 전까지는 노출되지 않는다.
S3의 PUT은
read after writer보장한다고 애기하기도 한다.
선형성이 연산의 전체 순서를 보장하는 것에 반에 인과성은 부분 연산의 순서만 보장하는데 대표적인 예시가 트랜잭션 스냅숏이다. 선형성에서 민감한 부분은 연산의 전체 순서가 언제 결정되냐인데, 이러한 개념을 확장해서 전체 순서 브로드 캐스트라는 개념이 등장한다.
합의
전체 순서 브로드 캐스트는 결국 합의를 몇 회 하는것과 동일하다. 합의 알고리즘은 어떤 값을 결정하기 위해서는 최소한 노드의 과반수가 올바르게 동작해야한다. 또한 리더가 죽었을 때 새로운 리더 선출을 위한 투표와 리더 제안을 수용하기 위한 투표가 존재한다. 투표에서는 에포크 번호(세대 번호)가 더 높은 리더를 모르는 노드만이 제안에 찬성해야 한다.
합의 부분을 보면서 졸업과제 때 진행했던 하이퍼레저 페브릭이라는 블록체인 기술이 떠올라 당시에 이해가 되지 않던 부분들이 이해가 되었다.
CAP
CAP 이론을 처음 접했을 때 P(네트워크 분단 용인)이 잘 이해가 가지 않았는데, 이 책을 보면서 명확해졌다. 책에서는 결국 모든 분산 시스템은 P를 강제하고 일관성과 가용성 중 하나를 선택하라는 의미로 보는게 좋다고 설명한다.
2PC
이 책을 읽기 전까지는 2PC(2 phase commit)의 최종 커밋/어보트의 일관성이 어떻게 보장되는지에 대한 의문이 있었다. 책에서는 커밋/어보트가 결정되면 코디네이터가 죽더라도 성공할 때까지 무한히 재시도한다고 설명하고 있다. 필자 생각에는 2PC에서는 아래와 같은 민감한 부분들에 주의가 필요해 보인다.
1. 코디네이터가 상태를 가지게 된다. -> 스케일 아웃이 쉽지 않다.
2. 코디네티터가 트랜잭션을 끝내기 전까지 잠금을 계속해서 잡고 있어야한다.
3. 참여자들은 코디네이터의 중복 커밋 요청에 대해 멱등성을 보장해야한다.도메인 주도 설계 - 16장 대규모 구조
시스템이 거대해짐에 따라 복잡도가 함께 증가한다. 이에 따라 시스템의 여러 모듈들이 어떻게 상호작용하는지 파악이 어려워지고 개발자들은 숲을 보지 못하게 된다. 16장에서는 이러한 문제에 대한 대안들을 서술하고 있다.
그 중 Evolving order이라는 개념이 인상 깊었다. 이는 개념적 대규모 구조가 애플리케이션과 발전하는 동시에, 세부적인 설계 및 모델과 관련된 의사결정을 과도하게 제약해서는 안된다는 의미를 내포하고 있다.
또한 Knowlegde level 개념 역시 기억에 남는다. 이는 관심사를 두가지 수준으로 분리해 하나는 매우 구체적으로 만들어 예외를 제어하는 반면 다른 하나는 유연하게 만들어 사용자나 관리자의 경험을 시스템이 반영할 수 있게 만들어주는 것을 의미한다. 필자는 Knowlegde level이 시스템적 도메인이 안정적이지 않고 실무자(관리자)의 경험과 지식에 기반한 백오피스 툴을 만들 때 적용하기 좋은 개념이라는 생각이 들었다. 그러나 과도한 유연함은 시스템을 복잡하게 만들고 예상치 못한 동작을 유발 할 수 있음으로 주의해야하며 점진적으로 실무자의 지식을 시스템으로 흡수해 발전시켜야 하는 것이 바람직해 보인다.
