기술면접 준비 + 예상질문 10가지

1. 데이터베이스 주 서버와 부 서버의 역할은 어떻게 다른가요?

데이터베이스 시스템에서 주 서버는 일반적으로 모든 쓰기 작업을 처리하며, 부 서버는 읽기 작업을 처리합니다. 주 서버는 데이터 변경 사항을 부 서버에 전파하여 데이터 일관성을 유지하는 역할을 합니다. 이러한 구조는 부하를 분산하는 데 도움이 되며, 또한 데이터 복제를 통해 시스템의 안정성과 가용성을 높이는 역할을 합니다. 즉, 주 서버가 실패하는 경우에는 부 서버 중 하나가 역할을 대체하여 다운타임을 최소화하게 됩니다.

1.1. 주 서버가 실패했을 때 부 서버가 주 서버의 역할을 어떻게 인수하는지 설명해 주실 수 있나요? 또한, 이렇게 되면 부 서버가 어떤 부하를 감당하게 되는지, 그리고 이러한 상황을 어떻게 관리하고 최적화할 수 있는지에 대한 전략은 무엇인지 설명해 주실 수 있나요?

주 서버가 실패하면, 먼저 시스템은 실패를 감지해야 합니다. 이것은 종종 헬스 체크 또는 'keep-alive' 메시지를 통해 수행됩니다. 실패가 감지되면, 다른 부 서버 중 하나가 주 서버의 역할을 인수합니다.
이 인수 과정은 주로 미리 설정된 규칙에 따라 수행되며,
'리더 선출' 의 과정을 수행됩니다.
인수가 발생하면, 해당 부 서버는 주 서버의 모든 쓰기 작업을 처리하게 됩니다. 이는 증가된 부하를 초래할 수 있으며, 이에 대응하기 위해서는 추가적인 리소스 할당, 더 나은 부하 분산, 또는 스케일링 전략이 필요할 수 있습니다.

리더선출 ? (Leader Election)

분산 시스템에서 중요한 개념입니다. 이는 한 시스템 내 여러 노드 중 하나가 장애가 발생하였을 때, 다른 노드 중 하나를 새로운 "리더"로 선출하여 원래의 리더가 수행하던 작업을 계속 수행할 수 있게 하는 과정을 말합니다.

리더선출 알고리즘?

1. Raft
   Raft라는 것은 분산 시스템에서 사용되는 알고리즘 중 하나로, 전체 시스템이 일관된 상태를 유지할 수 있게 도와줍니다. 그러니까 이 Raft를 통해서 우리는 리더를 선정하고, 이 리더가 모든 데이터 변경 사항을 다른 노드들에게 알려주게 됩니다. 이런 식으로 모든 노드가 동일한 상태를 유지하게 되는 거죠.
2. ZooKeeper의 ZAB 프로토콜
   ZooKeeper의 ZAB 프로토콜도 있는데요, 이 프로토콜은 모든 서버가 동일한 순서로 상태 변경을 볼 수 있도록 보장해줍니다. 서버가 문제가 생기거나 네트워크에 문제가 생겨도, 여전히 리더를 선출할 수 있도록 도와줍니다.
3. Bully Algorithm
   Bully Algorithm이라는 것도 있습니다. 이 알고리즘은 각 노드가 자기 자신의 고유 번호를 기준으로 더 높은 번호를 가진 노드에게 '나 리더 될게'라는 메시지를 보내는 건데, 만약 답이 오지 않으면 그 노드가 리더가 됩니다. 이 방법은 빠르게 리더를 결정할 수 있다는 장점이 있지만, 너무 많은 메시지를 주고받아야 한다는 단점도 있습니다.

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

먼저, 1. 읽기 및 쓰기 작업의 빈도를 최소화하는 것이 중요합니다. 가능한 경우 배치 작업을 사용하여 한 번의 요청으로 여러 개의 데이터 항목을 처리하는 것이 효율적입니다.
또한 2. 데이터를 효율적으로 구조화하는 것이 중요합니다. 적절한 데이터 타입을 사용하고, 항목의 크기를 최적화하며, 필요하지 않은 속성을 제거하여 데이터 전송량을 줄일 수 있습니다.
마지막으로, 3. 테스트 단계에서 DynamoDB Local을 사용하면 읽기/쓰기 작업과 데이터 전송에 대한 불필요한 비용을 피할 수 있습니다.

2.1. 언급하신 방법 외에도 다른 방법이 있을까요? 또한, DynamoDB Local을 사용하여 테스트를 할 때의 한계점은 무엇인가요?

데이터 전송 비용을 더욱 줄이기 위해 쿼리 최적화도 중요합니다. 쿼리를 효율적으로 작성하면 불필요한 데이터 전송을 줄일 수 있습니다. 예를 들어, 필요한 항목만을 가져오는 Projection Expressions를 사용하거나, 불필요한 데이터 전송을 방지하기 위해 쿼리의 조건을 최적화할 수 있습니다.
DynamoDB Local의 한계점 중 하나는 실제 DynamoDB 서비스의 모든 기능을 지원하지 않는다는 것입니다. 예를 들어, DynamoDB Streams는 지원되지 않습니다. 또한, 실제 환경의 성능과 조건을 완벽하게 모방할 수 없으므로, 테스트 결과는 실제 운영 환경에서의 결과와 다를 수 있습니다.

쿼리 최적화 ?

쿼리 최적화는 어떤 쿼리가 주어졌을 때, 이 쿼리를 가능한 한 효과적이고 효율적으로 처리하기 위한 프로세스를 말합니다.

• 선택적 데이터 요청: 데이터베이스에서 모든 필드를 가져오는 대신, 필요한 필드만 선택하여 가져오는 것입니다. 이렇게 하면 네트워크를 통해 전송되는 데이터의 양이 줄어들고, 결과적으로 데이터 전송 비용이 줄어듭니다.

• 인덱싱: 데이터베이스 테이블의 특정 열에 인덱스를 생성하여, 데이터의 검색 속도를 향상시킵니다. 인덱스가 있으면, 데이터베이스는 테이블의 모든 행을 스캔하지 않고도 원하는 데이터를 찾을 수 있습니다. 따라서, 더 적은 데이터를 읽어들이고, 더 적은 데이터를 전송하게 됩니다.

• 조인 최적화: 다중 테이블에서 데이터를 가져올 때, 어떤 테이블을 먼저 검색하고 어떻게 조인할 것인지에 따라 성능이 크게 달라집니다. 이런 결정들을 최적화하면, 쿼리 실행 시간을 단축시키고 데이터 전송 비용을 줄일 수 있습니다.

• 파티셔닝: 대용량 데이터베이스에서는 테이블을 여러 파티션으로 나누는 것이 유용할 수 있습니다. 이렇게 하면 쿼리는 필요한 파티션만 검색하게 되므로, 불필요한 데이터 전송을 줄일 수 있습니다.

위와 같은 방법들은 데이터 전송 비용을 줄이는 데 도움이 될 수 있습니다. 그러나, 이들 방법들은 쿼리의 성능을 개선하고, 응답 시간을 줄이는 데도 중요한 역할을 합니다. 따라서, 쿼리 최적화는 전체적인 시스템 성능 향상에도 기여합니다.

다만, DynamoDB에서는 몇 가지 추가적인 고려사항이 있습니다.

예를 들어, DynamoDB에서는 '프로비저닝된 처리량'이라는 개념이 중요합니다. 이는 읽기 및 쓰기 작업을 위해 할당된 리소스를 의미하며, 초과 사용에 따라 추가 비용이 발생합니다. 따라서, 쿼리를 최적화하여 필요한 처리량을 정확히 예측하고 할당하는 것이 비용 효율성을 높이는 데 중요합니다.

또한, DynamoDB에서는 테이블 디자인과 항목의 키 구조를 잘 선택하는 것이 중요합니다. 이를 통해 효율적인 읽기/쓰기 작업을 수행하고, 데이터 전송 비용을 최소화할 수 있습니다.

마지막으로, DynamoDB에서는 '스캔' 작업 대신 '쿼리' 작업을 가능한 한 사용하는 것이 좋습니다. 스캔 작업은 테이블의 모든 항목을 검색하므로 비용이 높으며, 반면에 쿼리 작업은 특정 키 값을 가진 항목만 검색하기 때문에 비용이 낮습니다.

결국, DynamoDB에서의 쿼리 최적화도 다른 데이터베이스에서의 쿼리 최적화와 같이, 필요한 데이터만 효율적으로 가져오는 것을 목표로 합니다. 하지만 DynamoDB의 특성과 구조를 이해하고 이에 따라 최적화 전략을 조정하는 것이 중요합니다.

3. 캐시 데이터의 만료시간이 너무 길거나, 너무 짧을 경우에 발생하는 문제를 알고 있나요?

캐시 데이터의 만료 시간 설정은 적절한 균형이 필요합니다.
만료 시간이 너무 길면, 최신 데이터를 반영하지 못하고 오래된 데이터를 제공하게 될 수 있습니다. 이는 고객에게 오래된 정보를 제공하거나, 최신의 비즈니스 결정을 반영하지 못하게 만드는 문제를 야기할 수 있습니다.
반면, 만료 시간이 너무 짧으면 캐시 미스 <- 컴공 용어라서 면접관이 좋아할 수 있음
가 더 자주 발생하여, 원본 데이터베이스나 서비스에 대한 쿼리가 늘어나게 됩니다. 이는 캐싱의 성능 향상 효과를 줄일 수 있습니다.
따라서 적절한 캐시 만료 시간을 설정하여 데이터의 신선도와 성능 간의 균형을 유지하는 것이 중요합니다.

어떻게 ?

로그인 상황에서 캐시를 사용하면 유용한 경우가 많지만, 몇 가지 주의해야 할 문제점이 있습니다.

• 데이터 일관성(Data Consistency): 만약 사용자 정보가 변경되었는데, 이 변경사항이 캐시에 반영되지 않으면, 이전 데이터를 기반으로 한 로그인 정보가 제공될 수 있습니다. 이는 사용자가 최신 정보를 확인하지 못하게 하는 문제를 일으킵니다. 따라서, 사용자의 로그인 상태나 정보가 변경될 때마다 캐시를 업데이트하거나 무효화하는 것이 중요합니다.

• 보안(Security): 캐시는 일반적으로 빠른 접근을 위해 메모리에 저장되므로, 보안에 취약할 수 있습니다. 로그인 정보나 인증 토큰 같은 민감한 데이터가 캐시에 저장될 경우, 이를 악용할 수 있는 공격 벡터가 될 수 있습니다. 따라서, 캐시에 저장되는 데이터의 보안성을 보장하거나, 민감한 정보는 캐시에서 배제하는 것이 중요합니다.

• 세션 관리(Session Management): 로그인 상태는 일반적으로 세션을 통해 관리되며, 세션 정보 역시 캐시에 저장될 수 있습니다. 하지만, 만약 세션 정보가 캐시에서 소멸될 경우, 사용자는 로그아웃 상태로 전환될 수 있습니다. 이는 사용자 경험을 해칠 수 있으므로, 세션 정보의 만료 시간 관리가 중요합니다.

이런 문제들에 주의하며 캐시를 사용하면, 로그인 정보의 빠른 접근성을 향상시키고, 서버의 부하를 줄일 수 있습니다. 하지만, 캐시는 절대적인 데이터 소스가 아니라 임시적인 데이터 저장소이므로, 캐시의 데이터가 손실될 경우를 대비해 항상 원본 데이터 소스에서 필요한 정보를 복구할 수 있어야 합니다.

3.1. 캐시 데이터의 만료 시간을 결정할 때 고려해야 할 기타 요인들은 무엇이 있나요? 또한, 특정 비즈니스 요구사항이나 트래픽 패턴에 따라 캐시 전략을 어떻게 조정하시나요?

캐시 만료 시간을 결정할 때, 주로 데이터의 변동성을 고려합니다. 자주 변경되는 데이터는 만료 시간을 짧게 설정하며, 그렇지 않은 데이터는 길게 설정할 수 있습니다. 또한, 비즈니스 요구사항에 따라 일부 항목은 실시간으로 반영되어야 할 수 있으므로, 이러한 항목은 캐시하지 않거나, 아주 짧은 만료 시간을 설정할 수 있습니다. 트래픽 패턴에 따라 캐시 전략을 조정하는 것은 더 복잡할 수 있습니다. 예를 들어, 피크 시간에는 부하를 줄이기 위해 캐시 만료 시간을 늘릴 수 있습니다. 반면, 트래픽이 낮은 시간에는 데이터를 최신 상태로 유지하기 위해 캐시를 더 자주 업데이트할 수 있습니다. 이러한 결정은 항상 비즈니스 요구사항, 시스템 성능, 그리고 데이터의 신선도와 관련된 트레이드오프를 고려해야 합니다.

4. 데이터베이스 수평 확장에 등장하는 샤딩의 개념을 알고 있나요?

샤딩은 단일 논리적 데이터 세트를 분할하여 여러 데이터베이스에 저장하는 방법입니다. 기본적으로 큰 데이터베이스를 샤드라고 하는 더 작고 관리하기 쉬운 부분으로 나눕니다. 각 샤드는 별도의 데이터베이스 서버 인스턴스에 보관되어 로드를 분산하고 단일 실패 지점의 위험을 줄입니다. 이는 데이터베이스의 수평 확장을 달성하기 위한 일반적인 접근 방식입니다.

5. 프로세스와 쓰레드의 차이는 무엇인가요?

프로세스와 스레드는 모두 독립적인 실행 시퀀스이지만 범위가 다릅니다. 프로세스는 자체 메모리 공간과 시스템 리소스가 있는 실행 중인 프로그램의 인스턴스입니다. 반면 스레드는 프로세스의 하위 집합입니다. 프로세스 내의 여러 스레드는 동일한 메모리 공간을 공유하므로 스레드 간의 효율적인 통신이 가능하지만 동기화 및 데이터 경합과 관련된 복잡성이 발생할 수도 있습니다.

6. 프로세스 간 통신에서 동기와 비동기의 차이점은 무엇인가요?

동기식 통신에서는 수신 프로세스가 메시지를 수신할 때까지 송신 프로세스가 차단됩니다. 비동기식 통신에서 보내는 프로세스는 메시지를 보낸 후 수신자의 승인을 기다리지 않고 실행을 계속합니다.

7. DNS란 무엇이며, 어떤 방식으로 호스트를 찾아가는지 설명해주세요.

DNS(도메인 이름 시스템)는 인터넷의 전화번호부와 같습니다. 사람에게 친숙한 도메인 이름(예: www.google.com)을 컴퓨터가 네트워크에서 서로를 식별하는 데 사용하는 IP 주소로 변환합니다. 호스트를 찾기 위해 DNS 쿼리가 수행됩니다. 쿼리는 요청된 도메인과 일치하는 IP를 가진 서버에 도달할 때까지 클라이언트에서 일련의 DNS 서버로 이동한 다음 클라이언트로 반환됩니다.

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

L4와 L7 로드 밸런서의 주요 차이점은 작동하는 OSI 계층과 네트워크 트래픽을 전달하는 데 사용하는 정보에 있습니다. L4 로드 밸런서는 IP 주소 및 포트 번호와 같은 전송 계층 데이터(TCP, UDP, FTP)를 기반으로 라우팅 결정을 내립니다. L7 로드 밸런서는 애플리케이션 레이어 데이터(HTTP, HTTPS)를 기반으로 트래픽을 라우팅하므로 HTTP 헤더, 쿠키 또는 콘텐츠 유형을 기반으로 트래픽을 전달하는 것과 같이 보다 복잡한 콘텐츠 기반 라우팅 결정을 내릴 수 있습니다.

9. 가상화와 컨테이너화의 차이점은 무엇인가요?

가상화와 컨테이너화는 둘 다 단일 호스트에서 여러 운영 체제 또는 애플리케이션을 실행하는 방법이지만 서로 다른 수준에서 작동합니다. 가상화는 기본 하드웨어를 추상화하는 하이퍼바이저 <- 오
에서 전체 운영 체제를 실행하는 전체 호스트를 에뮬레이트합니다. 각 가상 시스템에는 고유한 OS와 리소스가 있으므로 격리되지만 리소스도 많이 사용됩니다. 반면 컨테이너화는 OS 수준에서 작동합니다. 여러 컨테이너가 호스트 OS와 라이브러리를 공유하고 각 컨테이너는 애플리케이션과 해당 종속성을 캡슐화합니다. 이로 인해 컨테이너는 가상 머신보다 더 가볍고 빠르게 시작할 수 있지만 잠재적으로 둘 사이의 격리는 덜합니다.

하이퍼바이저 : 가상 머신 모니터라고도 하는 하이퍼바이저는 가상 머신(VM)을 생성하고 실행하는 프로세스입니다. 하이퍼바이저는 메모리 및 처리와 같은 단일 호스트 컴퓨터의 리소스를 가상으로 공유하여 호스트 컴퓨터가 여러 게스트 가상 머신을 지원할 수 있도록 합니다.

10. 람다의 콜드 스타트와 웜 스타트의 차이는 무엇인가요?

AWS Lambda 함수가 한동안 유휴 상태였다가 실행되면 "콜드 스타트"가 발생합니다. 이것은 함수를 로드하고 초기화 코드를 실행하는 데 걸리는 시간입니다. 다음에 함수가 호출되면 AWS는 사용 가능한 경우 "웜 스타트"라고 하는 기존 실행 컨텍스트를 재사용합니다. 이는 초기화 코드를 다시 실행할 필요가 없기 때문에 훨씬 더 빠릅니다.