1월 9일 ~ 1월 15일

유수민·2023년 1월 15일
0

인사이트

목록 보기
11/15
post-thumbnail
post-custom-banner

일주일간 나의 흥미를 끈 인사이트는??

📌목록

📌감상

1. 2023년 소프트웨어 엔지니어를 위한 필수 도서 추천

https://news.hada.io/topic?id=8208&utm_source=slack&utm_medium=bot&utm_campaign=T03DN2VDVFG

  • 컴퓨터 프로그램의 구조와 해석

글에서 도서 추천한 것들 중 내가 읽어 봐야할 책이라고 판단 책은 위의 책이다. 실용주의프로그래머도 추천되어 있긴한데 읽어본 책이라 넣지는 않았다(근데 더 한번 읽어볼 계획)
추천된 책들을 다 찾아보면서, 자연스럽게 목록뿐만 아니라 다른 사람들은 이 책을 읽고 어땠는지 서평을 찾게되는 나를 발견하였다. 나도 책을 주기적으로 읽고 있는데 내가 읽은 책들이라도 짧게 나마 서평을 남겨두면, 혹시 책을 읽는 사람들에게 도움이 되지 않을까? 란 생각이 들었다.

2. Sharded MySQL Cluster 도입 배경과 개발기 (부제: 우당탕탕 좌충우돌 개발기)- 지마켓 기술블로그

https://dev.gmarket.com/61
위의 글을 일단 박수부터 치고 읽어야 했었다.엄청 많은 노력끝에 완성되었다는 것을 느낄 수 있다. 정말 도움이 많이 된 글이다
1) CQRS
처음의 흥미는 CQRS(Command Query Responsibility Segregation) Pattern이였다. 현재 내 프로젝트에서 CQRS 패턴을 적용했고, 같은 db를 이용한 것이기 때문에, 나중에 역량이 된다면 다른 DB 이용해서 적용해봐야지라고 큐에 저장해놨는데, 이 글을 통해 약간이나마 간접체험을 할 수 있었다.

(시도 1) CDC
지마켓에서는 주 DB는 Microsoft SQL Server이고, 타겟 서버는 MySQL이라 이기종 간 데이터 복제는 CDC(Change Data Capture)를 활용한다고 한다.
-> 주 DB의 가용 리소스가 많지 않아 활용 안됨
| CDC(Change Data Capture)
데이터베이스 내 데이터 변경을 식별하여 외부 저장소에 전달하는 기술을 의미하는데, 데이터 실시간 동기화나 데이터 변경 이벤트를 외부 시스템에 보내는 등 폭넓게 활용

(시도 2) 소스 커넥터와 싱크 커넥터를 Application으로 구현하여 이를 활용
일단 얕은 지식으로 파악한것은 카프카를 이용하는 것이 주요 특징인것같다. 변경데이터를 주기적으로 읽어와서 카프카에게 전송하고, 카프카를 통해 mysql에 반영한다고 한다.

2) 샤딩
옛날에 한번 샤딩에 대해 정리한 적이 있었는데 샤딩에 대해 다시 알아보는 시간이 되었다. 샤딩은 한마디로 데이터를 효율적으로 분산시키는 것을 의미한다. 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리하는데 이 샤드키 방식 중 지마켓은 modular 샤딩 을 이용했다고 하니 아마 내가 아는 hash sharding 방법을 쓴 것이 아닐까싶다. DB를 추가 증설하면 새롭게 데이터를 재정렬해야한다는 단점만 기억하고 있어서 안좋은 인식이 있는데 알아보니 지마켓뿐만아니라 우아한형제들 쪽에서도 이 방법을 사용한다는 것을 확인할 수 있었다. 여기서 언급한 데이터 균일 분산의 중요도를 더 높게 판단한것 같다. 즉, 한 쪽에 데이터가 몰리거나 혹은 너무 트래픽이 없는 경우 자원낭비가 발생하는 점이 더 손해라고 생각한 것 같다.
우아한 형제들 : https://techblog.woowahan.com/2687/

3) ShardingSphere & Data Migration
ShardingSphere은 이번에 처음 알았다. RDBMS의 샤딩 처리를 지원하는 아파치 오픈소스 프로젝트라고 한다. 해당 기술들을 적용하면서 겪었던 해결 흐름을 보니, 아는 모든 방식에도 해결되지 않으면 공식문서 정독 -> github repository의 issue 탭과 Release history를 확인 한다는 것을 알게 되었다. 공식문서 정독은 알고 있었는데 github repository의 issue 탭과 Release history를 확인함으로써 해결방법을 찾는 것을 이번에서야 알게되었다.

3. 분산 락에 대해서

https://charsyam.wordpress.com/2022/12/31/%EC%9E%85-%EA%B0%9C%EB%B0%9C-%EB%B6%84%EC%82%B0-%EB%9D%BD%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C/
처음의 흥미는 락 이라는 글자였다. 내가 아는 락은 만약 공유 자원인 DB에 동시에 여러 프로세스, 쓰레드가 접근하지 못하도록하는 것인데, 테이블 전체가 아닌 필요한 row에 lock를 거는 것도 분산락의 일종이라한다.
해당 글은 redis의 분산락에 대해 설명하였다.
1) redis가 싱글쓰레드인 점을 이용해서 setnx 명령을 통해 딱하나만 해당 key를 얻을 수 있고 이미 생성되어있으면 해당 명령이 실패하도록 한다.
2) 해당 키는 일정 시간이 지나면 자동으로 삭제하도록 되어있다.
3) spinlock을 통해 키를 계속 얻을때까지 시도하여 자원 사용량이 높기 때문에, 짧은 시간안에 lock을 획득할 수 있는 케이스에만 사용한다고 한다.

4. 안전한 웹을 위해 HTTPS 이해하기: ①HTTPS의 작동 원리

https://yozm.wishket.com/magazine/detail/1852/
이전에 정리했던 내용이나 3wayhandshake와 ssl-3wayhandshake에 대한 내용을 한번 더 상기하고자 한다.
1) Client hello
브라우저가 사용하는 SSL/TLS 버전 정보
cipher suite( 브라우저가 지원하는 암호화 정보 )
브라우저가 생성한 임의의 난수

2) Sever hello
cipher suite 선택(암호화방식 선택)
서버의 공개키가 담긴 ssl 인증서 전달
서버가 생성한 임의의 난수

3) 서버 인증서 확인(클라이언트)
-> 서버의 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지 확인한다.

4) Premaster Secret(클라이언트)

  • f(브라우저에 내장된 CA리스트, CA 공개키, 서버인증서)
    -> 서버가 보낸 SSL 인증서를 CA 공개키로 복호화한다. 인증서에 들어있는 서버 공개키를 획득한다.
  • Premaster Secret 생성
    주고받은 난수를 조합해 Premaster Secret이라는 키를 생성
    서버 공개키로 Premaster Secret키 암호화

5) Premaster Secret 복호화 (서버)

  • Premaster Secret 복호화
    자신의 비공개키로 pre master secret키를 복호화
  • Master Secret 생성
    서버와 클라이언트 모두 pre master secret을 일련의 과정을 거쳐서 master secret으로 만든다.
  • Seession Key 생성
    master secret으로 session key를 생성
profile
배우는 것이 즐겁다!
post-custom-banner

0개의 댓글