How to implement DB Schema[5]

  형이 내게 준 피드백 내용들을 계속 검토하는 시간들을 가졌다. 기본적인 개념을 담은 ppt를 다운 받아서 보고, 실무에서 적용되는 사례들을 검색해보고 공부하며 보충해야할 점들을 적어서 제출하였고 피드백을 받았다.

 

 

Marking scheme: Poor/Fair/Good

 

추가적인 방안 : CDC조사해볼 것 

 

CDN을 기준별로 설정하기

1. 팔로우 관계가 이루어져있거나 함께 아는 친구들의 정보를 담고 있는 user table을 물리적으로 가까운 proxy server 위에 두기.

→ fair. proxy server는 유저의 접속 지역과 밀접한 곳에 위치해야 적은 레이턴시를 보장할 수 있는데, 이를 만족시키기 위한 세부적인 알고리즘이 어떤 것이 있을지 고려할 것

 

solution)

 

대역폭 - 처리할 수 있는 통신 경로의 최대 데이터 양 

 

총4가지 지연을 합친 것이 latency

전파지연 - 총 이동거리 대비 신호가 이동하는 속도 

전송지연 - 패킷의 모든 비트를 내보내는데 필요한 시간 

프로세싱지연 - 패킷헤더 처리 시간 

큐잉지연 - 패킷이 처리될 때 버퍼 안에서 대기하는 시간 

 

question : 이때 사용할 패킷은 무엇일까? 궁금한 이유는 패킷별 패킷헤더 구조가 다르기 때문에 그 구조를 활용해서 무언가를 해볼 수도 있지 않을까라는 생각이 들었기 때문. 

 

-> 패킷은 데이터 전송을 위해 데이터를 쪼개놓는 추상적 개념일 뿐 이를 구현하는건 전적으로 프로그래머의 마음. 프로토콜(e.g., TCP, UDP 등)을 정하는건 목적에 따라 부합하는 것을 택하면 됨.

 

방안 

1.왕복시간 줄이기 

RTT(Round Trip TIme>왕복시간) > CDN을 통해 가능 

 

-> Fair

 

2. 가중 라운드 로빈 방식 (with L7 로드밸런서 사용)

-접속 지역별로 프록시 서버를 둔다고 하였음. 인구 대비 각 서버별 이용 회원 수들을 고려하여 가중 라운드 로빈 방식을 통해 서버에 처리 용량을 설정. 이용회원 수가 많다는 것은 IT 인프라가 발전한 곳이며 주 고객들이기 때문에 더욱 속도에 예민할 수 밖에 없기에 가중 라운드 로빈 방식을 사용하는 것이 좋을 것 같다는 생각을 하였음 

 

-> Good

 

L7 로드밸런서 사용

-sns특성 상 사용자의 요청이 매우 다양함. 이를 기준으로 특정 서버에 트래픽 분산을 하기 위해 L7 로드밸런서를 사용해야한다고 생각함. 또한, 네트워크 보호를 위해서도 필요함.

 

-> Poor, 비용이 저렴한 L3/L4로드밸런서가 아닌 비싼 L7로드밸런서를 이용해야 한다면 그에대한 justification이 필요. 어플리케이션 레벨 로드밸런서는 세션 단위 로드 밸런싱을 지원하는 것일 뿐 방화벽 혹은 IDS/IPS급의 security appliance가 아닌데 왜 네트워크 보호를 위해 이것이 필요한 것인지 더 알아볼 것. 

 

 

2. 인플루언서를 포함한 셀럽들을 국적별로 카테고라이징 시켜서 그들의 user table을 해당 국가에 두기 

→ good.

 

Caching

캐싱은 영구적으로 데이터를 보관할 수 없다는 점을 이용하여 story table을 캐싱시키는 게 좋을 거 같다는 생각이 들었음. 특별한 삭제처리를 유저가 하지 않더라도 24hours가 경과하면 알아서 사라지기 때문. 

→ fair. 다만 인스타그램 구동 시 포스트를 불러오는 동작이 스토리를 불러오는 동작보다 훨씬 빈번하게 일어나는데 스토리만 캐싱시켰을 때 얻는 이점이 무엇일지 생각해 볼 필요가 있음.

 

오히려 cdn과 연계하여 이미지를 in-memory storage에 업로드 한 뒤, 아시아/유럽 지역으로 region을 나누어 분산배치 하는 것이 효율적이지 않을지

 

https://www.samsungsds.com/kr/insights/in-memory-data-grid.html

 

solution)

 

In-Memory Data Grid

-기존 의견에 스토리만 불러왔던 이유는 용량의 제한 때문이었음. 하지만 In-memory Data Grid를 이용하면 Son feedback 내용처럼 포스트를 불러오는 동작을 캐싱시킬 수 있음. 

가장 주목할 점은 

1.글로벌 원격지의 IMDG(In-Memory Data Grid) 클러스터 간 데이터 동기화(Federation) 지원. 

2.요청된 쿼리를 다중 서버에서 병렬 처리(혹시라도 원하는 정보가 user와 가장 인접한 proxy server에 있지 않을 때 )

-> Good

LFS&BLOB

이미지, 동영상 등 상대적으로 용량이 큰 파일들을 BLOB형식으로 저장 처리를 한 뒤, FEED를 보여 줄 때 POST의 미디어 파일을 끌어 올 때 LFS를 적용하는 것이 좋은 방안이 될 거 같다.

→ good. 세부적인 LFS 구현 방식 (in-memory storage 활용 및 backbone network attach 등)을 추가적으로 생각해보면 좋을 것. 

버퍼 캐시 히트율

디스크를 읽는 물리적 과정을 최대한 줄이고, 평소 user가 좋아하는 유형의 post들이나, 함께 아는 user_id들을 버퍼 캐시에 올려둔다면 곧 바로 메모리 블록에서 찾을 수 있는 비율이 올라가 효율적으로 데이터를 읽을 수 있을 것 같다. 

→ good.

 

데이터를 읽는 과정은 index Full scan이 효율적일 것 같다는 생각이 들었음. SNS 특성 상, 우리가 데이터를 조회할 때 000이상, 000미만 등의 조건을 붙여서 데이터를 추출할 작업이 많이 있지 않을 것 같음. 보통 특정 id를 검색하거나, 특정 post를 검색하는 등의 작업이 주를 이루기 때문. 테이블 전체를 스캔하기 보다 PK, Candidate Key를 이용하여 레코드의 대부분을 필터링 한다면 I/O 측면에서 큰 효율성을 얻을 수 있을 것 같음 .

→ good. 다만 cache organization scheduler를 어느시점에 구동할 지 생각해보면 좋을 것

 

solution)

filtering 후 조건에 해당되는 메모리들의 data를 새로운 index값을 통해 Cache(block단위 )에 매칭시키는 과정에서 cache organization scheduler가 구동되어야 할 것 같다.

하지만 주의해야할 점은 Mapping의 과정에서 high order bits에 관한 정보들의 손실이 일어날 수도 있다는 점. 이를 Tag를 통해 방지해야 할 것 같다(SNS에서 정보의 유실은 큰 손실이므로. 물론 다른 앱들도 마찬가지이지만 ).  Mapping은 세트 연관 매핑으로 진행 

 

-> Good

인메모리 데이터베이스 

 

DB전원 종료 시 휘발되어버린다는 점을 고려하였을 때, low risk를 지고 싶다면 로그인 세션 관련 정보를 올려두면 좋을 것 같다는 생각이 들었음. 하지만 수정된 정보들을 디스크 로그에 기록한다는 점과  Active - Active Clustering을 사용한다는 가정 하(전원이 종료되도 다른 서버가 작동하기 때문에)에는 로그인세션 뿐만 아니라 빠른 속도로 접근해야하는 post table(미디어 파일들에 빠른 access를 allow하기 위해 또한 post들을 수정할 때 빠르게 정보가 최신화 되어야하기 때문에), comment table에 적용시켜도 좋을 거 같음  

→ poor. active clustering(high availability) 설정 시 네트워크 상단에 load balancer가 위치하는 것이 통상적인 실무 관례이므로 네트워크 세션은 서버 단이 아닌 load balancer단에서 관리됨.

또한 단순 로그인 정보를 cache로 구동하는 것은 비용대비 효과가 적으며, 분산 배치 시 db 최신화는 in-memory caching과 무관함 (db mirroring과 관련있음)

 

solution)

Mirroring은 DB 가용성을 높이는 이중화(보조서버에서 백업이 이루어짐)

Active - Active Clustering

돈이 많은 다국적 기업의 특성 상, 약간의 비용 risk를 감수하더라도 서비스 중단이 되지 않도록 초점을 맞출 것이라는 판단 하에 Active - Active Clustering을 사용하는 것이 좋을 것 같다는 생각이 들었음. 

→ fair. active clustering의 목적성에 부합함

 

테이블의 수평 분할

파티션 방법을 통해 수천만 건의 데이터가 들어있는 post table을 수평분할하면 I/O가 효율 것이라 생각함. 그 중에서도 Range 파티션을 통해 post가 작성된  날짜를 기준으로 분할함으로써 성능 개선을 보장시킬 수 있음.  

→ good.

 

슈퍼타입/서브타입 적용 

  이전에 구성한 DB Schema에는 슈퍼타입/서브타입을 적용시킬만한 attribute들의 중복이 없었으나, 향후 youtube DB schema 같은 복잡도가 높은 과제에서는 적용시키면 좋을 것 같음. 

→ poor. 스토리와 일반 포스트의 관계가 밀접하고, 이를 구현하는 방식이 유사함에 따라 포스트/스토리 관계를 슈퍼/서브타입으로 구분할 수 있을 것. OOP적 접근을 더 생각해 볼 것.

객체지향이라… 흐음 

 

캡슐화를 사용해야하나 ?

->Correct

like this  ?

-> Good

 

Overall score: 90

 

Do

1. Use english terms
2. Put references if the idea is not coming from your head
3. Use diagrams wisely
4. Justify your choice with your purpose, advantages, drawbacks and cost-effectiveness

Don’t

1. 무지성 - 될 것 같다 - 식 설명
2. Explain everything in one line

*구글 doc(private)에서 edit된 문서를 paste한 내용임*

*적용된 기술들에 관해서는 나중에 따로 공부 기록글을 작성하고 remind할 예정*

 

 

하루에 최대로 시간을 할애해도 4,5시간 뿐이라는 점을 고려해줘서 그런지 나를 미소 짓게 만드는 칭찬들을 해주었다. 몇가지 criticize들까지. 이렇게 내가 성장할 수 있도록 이끌어주고, 도와주는 사람이 있다는 이 상황이 너무 감사할 따름이다.

 

 

 

그 뒤 workflow를 확인하기 위해 질문하였다. 

Then.. could you tell me what is my next step?
1.renovate existing one?
2. UML?
3. move to Youtube?
4. Study Network?

돌아온 답변이다 

move on to 2.3.4.

 

 

이제는 설계한 DB를 UML로 작성하는 작업을 해볼 예정이다. 매일 매일을 목표의식을 가지고 살게 된 이 상황에 감사하며,