Fairy ' s

[Study] 면접 예상 질문 #1 본문

Study/Etc

[Study] 면접 예상 질문 #1

berafairy 2023. 7. 5. 00:46

면접 예상 질문  ㅡ  #1

 


 

DynamoDB와 통신할 때, 데이터 전송 비용을 효율적으로 사용하기 위해서는 어떻게 해야 하는가?


 DynamoDB로 작업할 때는 데이터 전송 비용의 효율적인 관리가 필수적입니다. 데이터 전송 비용을 최적화하기 위한 전략으로는 먼저 전송되는 데이터의 크기와 양은 비용에 직접적인 영향을 미치므로, 불필요한 데이터 전송을 최소화해야 합니다. DynamoDB는 유연한 쿼리 기능을 제공하므로, 원하는 속성과 필터를 지정하여 관련 데이터만 검색할 수 있습니다. 이렇게 필터링하여 필요한 정보만 전송하면 비용을 최소화할 수 있습니다.

 또한, 애플리케이션의 액세스 패턴 및 쿼리 요구 사항을 기반으로 데이터 모델 및 인덱스를 신중하게 설계하고 업데이트하여 효율적인 데이터 검색을 보장하는 것이 중요합니다. 적절한 파티션 키와 정렬 키, 보조 인덱스를 활용해서 필요한 데이터에 직접 액세스하도록 쿼리를 최적화하여 테이블의 많은 부분을 스캔할 필요성을 줄일 수 있습니다. 이것을 통해 성능도 향상시킬 수 있고, 네트워크를 통해 전송되는 데이터의 양을 줄여 비용을 최소화할 수 있습니다.

 마지막으로, DynamoDB는 읽기 쓰기 작업을 모두 포함하여 API 요청에 대해 요금을 부과합니다. BatchItem과 같은 페이지 매김 지원 및 배치 작업을 통해 데이터를 검색하거나 수정하는 데 필요한 API 요청 수를 제한할 수 있기 때문에 총 API 요청 수가 줄어들어 비용이 절감됩니다. 일괄 작업은 여러 항목에 대해 동시에 대량 읽기 또는 쓰기 작업을 수행해야 할 때 유용합니다.

 


L4 로드 밸런서와 L7 로드 밸런서의 차이는 무엇인가 ?


 로드 밸런서는 들어오는 네트워크 트래픽을 여러 서버에 분산하기 위한 클라우드 인프라의 중요한 구성 요소입니다. 로드밸런서 유형 중 L4(레이어 4) 및 L7(레이어 7) 로드 밸런서는 일반적으로 사용되는 두 가지 유형이지만, 차이가 있습니다.

L4 (Network Stack Layer 4) 로드 밸런서

  • 일반적으로 트래픽 분산 및 네트워크 수준 상태 확인에 중점을 둡니다.
  • IP 주소 및 포트 같은 네트워크 수준 정보를 기반으로 트래픽을 분산합니다.
  • TCP, UDP 같은 전송 계층 프로토콜의 정보를 사용해 부하 분산을 수행합니다.
  • L7 로드 밸런서에 비해 대기 시간이 짧으며, 효율적이고 빠른 로드 밸런싱을 제공합니다.

L7 (Network Stack Layer 7) 로드 밸런서

  • HTTP 헤더, 쿠키 및 콘텐츠를 포함한 애플리케이션 수준 정보를 기반으로 라우팅 결정을 내립니다.
  • 복잡한 애플리케이션을 위한 SSL 종료, 콘텐츠 기반 라우팅, 요청/응답 조작과 같은 고급 트래픽 관리 및 로드 밸런싱 기능을 제공합니다.
  • 트래픽 분산을 보다 세밀하게 제어할 수 있으며 애플리케이션 성능을 최적화할 수 있습니다.
  • 애플리케이션 수준의 상태 확인을 제공하고, 애플리케이션 별 메트릭을 기반으로 트래픽을 라우팅할 수 있습니다.

 결론적으로, L4는 네트워크 수준 트래픽 분산에 중점을 두는 반면, L7 로드 밸런서는 고급 애플리케이션 수준의 기능을 제공합니다. 두 가지 로드 밸런싱에 대한 선택은 애플리케이션의 특정 요구 사항, 사용 중인 프로토콜, 트래픽 관리에 필요한 제어 및 가시성 수준에 따라 다를 수 있습니다.

 


데이터베이스 수평 확장에 등장하는 샤딩이란 ?


 먼저, 데이터베이스를 더 작고 관리하기 쉬운 단위로 분할된 데이터 하위 집합이 샤드라는 것인데, 이러한 샤드를 여러 데이터베이스 인스턴스 또는 서버에 분산하는 작업을 일반적으로 샤딩이라고 합니다. 샤딩은 확장 가능하고 내결함성이 있는 고성능 데이터베이스 시스템을 구축할 수 있게 해주는 강력한 기술입니다.

 샤딩의 주요 목표는 데이터와 워크로드를 여러 시스템에 분산하여 성능, 확장성 및 가용성을 개선하는 것입니다. 배포는 일반적으로 샤드 키 또는 특정 분할 전략을 기반으로 하며, 데이터를 분산함으로써 여러 사드에서 쿼리를 병렬로 처리해 시스템이 대량의 데이터와 사용자 요청을 처리하는 능력을 크게 향상시킬 수 있습니다.

단점

  • 샤딩은 샤드 전체에서 데이터 일관성을 유지하는 것이 복잡할 수 있습니다.
     * 솔루션 : 세심하게 설계된 데이터 모델과 애플리케이션 로직을 사용하여 여러 샤드에서 분산 트랜잭션을 처리하여 원자성, 일관성 및 내구성 속성을 보장할 수 있습니다.
  • 여러 샤드의 데이터에 액세스해야 하는 쿼리는 서로 다른 샤드의 결과를 조정하고 잠재적으로 병합해야 하기 때문에 애플리케이션 논리에 복잡성을 추가하고 성능에 영향을 미칠 수 있습니다.
     * 솔루션 : 샤드 전체에서 투명하게 쿼리를 최적화하고 병렬화할 수 있는 분산 쿼리 처리 프레임 워크를 활용할 수 있습니다.
  • 샤딩은 특정 샤드가 다른 것보다 더 많은 트래픽이나 데이터를 수신하는 핫스팟으로 이어질 수 있습니다. 이로 인해 자원 활용도가 고르지 않고 잠재적인 병목 현상이 발생할 수 있습니다. 
     * 솔루션 : 지능적인 샤드 키 선택 전략을 구현하여 샤드 전체에 워크로드를 고르게 분배하여 핫스팟을 방지할 수 있고, 핫스팟이 감지되면 자동으로 데이터 또는 워크로드를 재분배하는 샤드 재조정 메커니즘을 구현하여 리소스 활용도를 보장할 수 있습니다.

 

'Study > Etc' 카테고리의 다른 글

[9. Apr] Github.io 로 블로그 이전? -> 다시 복귀  (0) 2023.04.09
[9. Apr] Github.io 시작 #1  (1) 2023.04.09
[Git] Github  (0) 2023.01.06
Comments