1. 데이터베이스 주 서버와 부 서버의 역할은 어떻게 다른가요?
- 주 서버 (Primary Server):
- 주 서버는 데이터베이스의 중앙 관리자 역할을 담당합니다.
- 주 서버는 읽기 및 쓰기 작업을 처리하고, 데이터베이스의 일관성과 무결성을 유지합니다.
- 주 서버는 데이터베이스의 기본 복제본을 가지며, 모든 업데이트 작업은 주 서버에서 수행됩니다.
- 주 서버의 장애 시 부 서버 중 하나가 새로운 주 서버로 승격될 수 있습니다.
- 부 서버 (Secondary Server):
- 부 서버는 주 서버의 복제본으로, 주 서버의 데이터를 복제하여 가지고 있습니다.
- 부 서버는 읽기 작업을 처리하는 데 사용될 수 있습니다. 읽기 작업은 주 서버에 영향을 주지 않고 부 서버에서 수행될 수 있으므로 성능을 향상시킵니다.
- 부 서버는 주 서버의 데이터를 동기화하고 최신 상태로 유지합니다.
- 하지만 주 서버에서 발생한 업데이트가 부 서버에 반영되기까지는 일정한 시간이 소요됩니다. 이 시간을 Replication Lag 또는 데이터 복제 지연이라고 부르며, 네트워크 속도, 부하, 데이터 크기 등에 따라 다를 수 있습니다.
- 주 서버의 장애 시 부 서버 중 하나가 새로운 주 서버로 승격될 수 있습니다.
- 주 서버와 부 서버는 데이터베이스 시스템의 가용성과 성능을 향상시키기 위해 사용됩니다. 주 서버는 데이터의 중앙 관리와 업데이트 작업을 처리하며, 부 서버는 읽기 작업을 분산시켜 성능을 개선하고, 장애 대비 및 데이터 복구를 위해 사용됩니다.
2. 데이터베이스 수평 확장에 등장하는 샤딩의 개념을 알고 있나요?
샤딩은 데이터베이스의 데이터를 수평으로 분할하고, 각 조각(샤드)을 여러 서버에 분산 저장하는 것을 의미합니다. 각 샤드는 독립적인 서버 또는 클러스터에 할당되어 데이터를 저장하고 처리합니다. 이렇게 분산된 데이터는 각 샤드에서 병렬로 처리되므로 전체 시스템의 처리량과 성능이 향상될 수 있습니다.
샤딩의 개념은 대규모 데이터베이스 시스템에서 특히 중요합니다. 대량의 데이터를 단일 서버에서 처리하는 것은 한계가 있으며, 성능 저하와 확장성 문제가 발생할 수 있습니다. 샤딩을 통해 데이터를 분산 저장하면 데이터베이스 시스템은 여러 서버에서 작업을 병렬로 처리할 수 있으므로 성능과 확장성이 개선됩니다.
샤딩은 주로 데이터베이스의 키(Key)나 해시(Hash) 함수를 사용하여 데이터를 분할합니다. 예를 들어, 사용자의 아이디나 지역 정보를 기준으로 데이터를 분할할 수 있습니다. 각 샤드는 일부 데이터의 소유자가 되며, 해당 데이터에 대한 쿼리를 처리합니다. 또한, 샤딩된 데이터를 조회하거나 조인할 때에는 여러 샤드에서 필요한 데이터를 가져와서 처리해야 합니다.
하지만 샤딩은 데이터의 일관성과 관련된 문제를 야기할 수 있습니다. 분산된 데이터 간의 일관성 유지, 트랜잭션 처리, 조인 연산 등의 복잡한 문제를 다루어야 합니다. 따라서 샤딩은 신중하게 설계되고 구현되어야 하며, 데이터베이스의 성격과 요구 사항에 따라 다양한 샤딩 전략을 고려해야 합니다.
3. 캐시 데이터의 만료시간이 너무 길거나, 너무 짧을 경우에 발생하는 문제를 알고 있나요?
- 만료 시간이 너무 긴 경우:
- 데이터가 오래된 상태로 유지되어 최신 정보를 반영하지 못할 수 있습니다.
- 데이터의 변동 사항을 캐시에 반영하지 못하므로 정확성이 떨어질 수 있습니다.
- 서버의 자원을 낭비하게 되며, 캐시 공간이 채워져 새로운 데이터를 저장할 수 없게 될 수도 있습니다.
- 만료 시간이 너무 짧은 경우:
- 캐시 데이터가 자주 갱신되므로 서버에 과도한 요청이 발생할 수 있습니다.
- 캐시 데이터를 가져오기 위한 네트워크 비용이 증가할 수 있습니다.
- 만료 시간 내에 캐시 데이터를 갱신하지 못한 경우, 계속해서 새로운 데이터를 가져와야 하므로 성능 저하가 발생할 수 있습니다.
4. dynamoDB와 통신할 때, 데이터 전송 비용을 효율적으로 사용하기 위해서는 어떻게 해야 하나요?
- 필요한 필드만 조회: DynamoDB는 NoSQL 데이터베이스로서, 필요한 필드만 조회하여 가져오는 것이 중요합니다. 읽기 작업 시 테이블에서 필요한 필드만 선택하면 전체 항목을 가져오는 대신 필요한 데이터만 가져오므로 데이터 전송 비용을 절약할 수 있습니다.
- 적절한 읽기/쓰기 용량 설정: DynamoDB 테이블에 대해 읽기/쓰기 용량을 적절하게 설정해야 합니다. 용량이 과도하게 높으면 비용이 불필요하게 증가할 수 있고, 용량이 부족하면 성능 저하 및 추가 비용이 발생할 수 있습니다. 예상 트래픽과 작업 부하를 고려하여 적절한 용량을 설정하는 것이 중요합니다.
- 배치 작업 사용: 대량의 데이터를 읽거나 쓸 때는 배치 작업을 사용하여 여러 항목을 한 번에 처리할 수 있습니다. 이를 통해 네트워크 오버헤드를 줄이고 데이터 전송 비용을 절약할 수 있습니다. 배치 작업은 BatchWriteItem 또는 BatchGetItem API를 사용하여 수행할 수 있습니다.
- 캐싱 적용: 반복적인 조회 작업이나 계산이 많이 필요한 데이터의 경우, 캐싱 메커니즘을 도입하여 데이터 전송을 효율적으로 관리할 수 있습니다. 캐시를 사용하면 DynamoDB에 대한 요청을 줄이고, 캐시 된 데이터를 사용하여 데이터 전송 비용을 절약할 수 있습니다.
- GSI 및 LSI 최적화: DynamoDB의 Global Secondary Index (GSI) 및 Local Secondary Index (LSI)를 효율적으로 사용하여 쿼리의 효율성을 높일 수 있습니다. 인덱스를 적절하게 설계하고 쿼리 패턴을 고려하여 데이터 전송 비용을 최소화할 수 있습니다.
- 데이터 압축 사용: 데이터를 압축하여 전송 비용을 줄일 수 있습니다. DynamoDB에서는 데이터 압축을 지원하며, 압축 알고리즘을 사용하여 데이터 크기를 줄일 수 있습니다.
5. 프로세스와 쓰레드의 차이는 무엇인가요?
프로세스:
- 프로세스는 운영체제에서 실행 중인 프로그램의 인스턴스입니다.
- 각 프로세스는 독립된 메모리 공간을 할당받고, 실행 중인 프로그램의 코드, 데이터, 스택, 힙 등을 포함합니다.
- 프로세스는 독립된 실행 환경을 가지며, 각 프로세스는 자체적으로 리소스(메모리, 파일 핸들, 디바이스 등)를 할당받습니다.
- 프로세스 간의 통신은 IPC(Inter-Process Communication) 기법을 사용해야 합니다. 이는 프로세스 간 데이터 교환을 위한 명시적인 메커니즘입니다.
- 각 프로세스는 별도의 주소 공간을 가지고 있으므로, 다른 프로세스의 메모리에 직접 접근할 수 없습니다.
- 각 프로세스는 운영체제로부터 독립적인 스케줄링을 받으며, 하나의 프로세스가 충돌하거나 종료되더라도 다른 프로세스에 영향을 주지 않습니다.
쓰레드:
- 쓰레드는 프로세스 내에서 실행되는 경량화된 실행 단위입니다.
- 하나의 프로세스는 여러 개의 쓰레드를 가질 수 있으며, 각 쓰레드는 공유된 메모리 공간(코드, 데이터, 힙)을 사용합니다.
- 쓰레드는 프로세스의 자원을 공유하면서 동시에 실행될 수 있습니다.
- 쓰레드 간의 통신은 공유된 데이터에 직접 접근하여 이루어집니다. 따라서, 쓰레드 간의 데이터 공유 및 동기화에 주의가 필요합니다.
- 하나의 쓰레드가 예외를 발생시키면 해당 프로세스 내의 다른 쓰레드들도 종료될 수 있습니다.
- 각 쓰레드는 자신만의 스택을 가지고 있지만, 쓰레드들은 프로세스 내에서 같은 코드와 데이터를 공유하므로 서로의 스택이 겹칠 수 있습니다.
6. 프로세스 간 통신에서 동기와 비동기의 차이점은 무엇인가요?
- 동기 통신:
- 동기 통신은 호출된 작업이 완료될 때까지 대기하고, 작업의 결과를 반환받은 후에 다음 작업을 수행합니다.
- 호출자는 호출된 작업의 응답을 받을 때까지 블로킹되며, 다른 작업을 수행하지 못합니다.
- 호출된 작업이 완료되기 전까지는 제어권이 호출자에게 유지됩니다.
- 동기 통신은 순차적으로 작업이 처리되며, 작업 간의 순서와 상호 의존성을 유지할 수 있습니다.
- 주로 동기적 통신 방식으로는 RPC(Remote Procedure Call)와 블로킹 I/O(입출력) 등이 있습니다.
비동기 통신:
- 비동기 통신은 호출된 작업이 완료되지 않아도 대기하지 않고, 호출자는 작업이 완료될 때까지 다른 작업을 수행할 수 있습니다.
- 호출자는 비동기 작업을 요청하고 나면 즉시 제어권을 반환받아 다른 작업을 수행할 수 있습니다.
- 호출된 작업은 백그라운드에서 실행되고, 작업 완료 후에 결과를 콜백이나 이벤트 등을 통해 알립니다.
- 비동기 통신은 여러 작업을 동시에 처리하고, 작업 간의 의존성 없이 병렬로 수행될 수 있습니다.
- 비동기 통신은 대기 시간을 최소화하고 시스템 자원을 효율적으로 활용할 수 있으며, 주로 비동기적 통신 방식으로는 메시지 큐, 이벤트 기반 통신, 비동기 I/O 등이 있습니다.
동기 통신은 작업의 순서와 의존성이 중요한 경우에 유용하며, 비동기 통신은 대기 시간을 줄이고 효율적인 병렬 처리가 필요한 경우에 적합합니다.
7. DNS란 무엇이며, 어떤 방식으로 호스트를 찾아가는지 설명해 주세요.
DNS(Domain Name System)은 인터넷에서 도메인 이름을 IP 주소로 변환하고, IP 주소를 도메인 이름으로 변환하는 시스템입니다. DNS는 사용자가 읽기 쉬운 도메인 이름(예: www.example.com)을 컴퓨터가 이해할 수 있는 숫자로 된 IP 주소(예: 192.0.2.1)로 매핑하는 역할을 합니다.
- 사용자가 웹 브라우저에서 도메인 이름을 입력합니다.
- 사용자 컴퓨터는 로컬 DNS 캐시를 확인합니다. 로컬 DNS 캐시에 도메인 이름이 캐싱되어 있다면, 사용자 컴퓨터는 해당 IP 주소를 가져와서 웹 페이지를 로드합니다.
- 만약 로컬 DNS 캐시에 도메인 이름이 없다면, 사용자 컴퓨터는 인터넷에 연결된 ISP(ISP는 인터넷 서비스 제공 업체)의 DNS 서버에 쿼리를 보냅니다.
- ISP의 DNS 서버는 쿼리를 받고, 먼저 자신의 로컬 DNS 캐시를 확인합니다. 캐시에 도메인 이름이 있으면 해당 IP 주소를 가져와서 사용자 컴퓨터에 반환합니다.
- ISP의 DNS 서버도 로컬 DNS 캐시에 해당 도메인 이름이 없으면, DNS 계층 구조에서 루트 DNS 서버를 쿼리 합니다.
- 루트 DNS 서버는 도메인 이름의 최상위 도메인(.com, .net, .org 등)을 포함하는 TLD(Top-Level Domain) DNS 서버의 IP 주소를 반환합니다.
- ISP의 DNS 서버는 TLD DNS 서버를 쿼리하고, 해당 도메인의 네임서버의 IP 주소를 반환합니다.
- ISP의 DNS 서버는 해당 도메인의 네임서버에 쿼리를 보내고, 최종적으로 도메인 이름에 해당하는 IP 주소를 반환합니다.
- 사용자 컴퓨터는 DNS 서버로부터 받은 IP 주소를 사용하여 해당 웹 페이지를 로드합니다.
8. L4 로드밸런서와 L7 로드밸런서의 차이는 무엇인가요?
- L4 로드밸런서:
- L4(Transport Layer) 로드밸런서는 IP 주소와 포트 번호를 기반으로 트래픽을 분산시킵니다.
- 전송 계층(Transport Layer)에서 작동하며, TCP 및 UDP와 같은 전송 계층 프로토콜을 사용합니다.
- L4 로드밸런서는 패킷 수준에서 로드밸런싱을 수행하므로, 트래픽을 서버 그룹 간에 균등하게 분산시킵니다.
- 로드밸런서가 웹 요청의 내용을 이해하거나 조작하지 않기 때문에, 웹 애플리케이션의 라우팅이나 로직에 대한 처리는 수행하지 않습니다.
- L7 로드밸런서:
- L7(Application Layer) 로드밸런서는 애플리케이션 계층에서 작동하며, HTTP, HTTPS, SMTP, FTP 등과 같은 응용 프로토콜을 기반으로 트래픽을 분산시킵니다.
- L7 로드밸런서는 클라이언트의 요청을 분석하여 트래픽을 여러 서버로 라우팅 하고, 요청에 대한 부하 분산, 세션 관리(사용자의 상태를 유지하는 방법), 캐싱, SSL 종료(SSL로 암호화된 데이터 트래픽이 해독(또는 오프로드)되는 프로세스) 등과 같은 고급 기능을 제공할 수 있습니다.
- 웹 애플리케이션의 내용을 이해하고 처리하기 때문에, HTTP 요청의 헤더, 쿠키, URL 등에 기반하여 특정 서버로의 라우팅을 결정할 수 있습니다.
- 요약하면, L4 로드밸런서는 전송 계층에서 IP와 포트 번호를 기반으로 트래픽을 분산시키고, L7 로드밸런서는 응용 계층에서 요청의 내용을 이해하고 처리하여 트래픽을 분산시킵니다.
9. 가상화와 컨테이너화의 차이점은 무엇인가요?
- 격리 수준:
- 가상화: 가상화는 하이퍼바이저(Hypervisor)라는 소프트웨어 계층을 사용하여 각 가상 머신(VM)이 호스트 시스템과 완전히 분리된 환경에서 실행됩니다. 각 VM은 독립된 운영체제(OS)와 필요한 애플리케이션을 가지고 있습니다.
- 컨테이너화: 컨테이너는 호스트 시스템의 운영체제를 공유하며, 각 컨테이너는 격리된 프로세스 및 파일 시스템 공간을 가지고 있습니다. 컨테이너는 가볍고 빠르며, 호스트 운영체제 위에서 실행됩니다.
- 리소스 사용:
- 가상화: 가상화는 각 VM이 독립된 운영체제와 애플리케이션을 가지므로, 각 VM은 일반적으로 더 많은 리소스(메모리, 디스크 공간)를 필요로 합니다. 이는 가상화의 오버헤드가 크다는 것을 의미합니다.
- 컨테이너화: 컨테이너는 호스트 운영체제를 공유하기 때문에 가상화보다 더 경량화되었으며, 빠른 시작 및 종료 시간, 작은 디스크 이미지 크기 등의 이점이 있습니다.
- 배포 및 확장성:
- 가상화: 가상화는 VM 단위로 배포되며, 각 VM은 독립된 운영체제를 가지고 있기 때문에 배포 및 관리에 별도의 작업이 필요합니다. 또한, VM은 일반적으로 수직 확장(가상 머신 자원 증가)이므로 확장성 측면에서 제한이 있을 수 있습니다.
- 컨테이너화: 컨테이너는 이미지 단위로 배포되며, 호스트 운영체제와 호환되는 이미지를 생성하고 공유할 수 있습니다. 컨테이너는 빠른 배포 및 확장이 가능하며, 수평 확장(컨테이너 인스턴스 수 증가)이 쉽습니다.
10. 람다의 콜드 스타트와 웜 스타트의 차이는 무엇인가요?
AWS 람다(Lambda)는 서버리스 컴퓨팅 서비스로, 이벤트에 응답하여 코드를 실행하는 기능을 제공합니다. 람다 함수의 실행 방식에는 "콜드 스타트(Cold Start)"와 "웜 스타트(Warm Start)"라는 두 가지 주요한 차이점이 있습니다.
- 콜드 스타트(Cold Start):
- 콜드 스타트는 람다 함수가 처음 실행되거나, 이전 실행 후 일정 시간 동안 사용되지 않은 상태에서 다시 실행될 때 발생합니다.
- 이 경우, 람다 함수가 처음 실행될 때는 실행 환경을 설정하고 초기화하는 시간이 필요합니다.
- 따라서 처음 실행되거나 일정 시간 동안 사용되지 않은 경우, 콜드 스타트로 인해 함수의 실행이 느려질 수 있습니다.
- 이는 초기 설정 비용과 부하에 의해 영향을 받습니다.
- 웜 스타트(Warm Start):
- 웜 스타트는 이전에 실행된 람다 함수가 일정 시간 동안 활성 상태로 유지되어 다시 실행될 때 발생합니다.
- 이 경우, 람다 함수의 실행 환경이 이미 설정되어 있으며, 초기화 과정이 필요하지 않습니다.
- 따라서 이전에 활성 상태로 유지된 람다 함수는 웜 스타트로 인해 콜드 스타트보다 더 빠르게 실행됩니다.
- 이는 요청에 대한 응답 시간을 단축시킬 수 있습니다.
콜드 스타트를 줄이는 방법
- 람다 함수의 활성 유지: 람다 함수를 정기적으로 실행하여 활성 상태를 유지하는 방법입니다. 예를 들어, AWS CloudWatch 이벤트를 사용하여 람다 함수를 주기적으로 트리거하거나, 외부 스케줄링 메커니즘을 사용하여 주기적으로 호출할 수 있습니다. 이렇게 하면 함수가 항상 활성 상태로 유지되어 콜드 스타트를 피할 수 있습니다.
- 프로비저닝 된 용량 모드 사용: AWS Lambda에서는 프로비저닝된 용량 모드(Provisioned Concurrency)를 사용할 수 있습니다. 이 모드에서는 사전에 지정된 수의 함수 인스턴스를 유지하여 콜드 스타트를 피할 수 있습니다. 예를 들어, 트래픽이 예상대로 변동되는 경우에 유용합니다.
- 트리거 간격 조정: 람다 함수를 트리거하는 이벤트의 간격을 조정하여 콜드 스타트를 최소화할 수 있습니다. 예를 들어, 일정 시간 동안 동일한 이벤트를 반복해서 트리거하는 경우, 트리거 간격을 더 넓게 설정하여 람다 함수가 계속해서 활성 상태로 유지될 수 있도록 할 수 있습니다.
'DevOps BootCamp > CS 면접' 카테고리의 다른 글
| 자주 물어보는 질문 (0) | 2023.07.26 |
|---|---|
| Kubernetes (0) | 2023.07.12 |
| AWS, 애플리케이션 설계 (0) | 2023.07.11 |
| Linux, DevOps (0) | 2023.07.10 |
| Docker, 네트워크 (0) | 2023.07.05 |