[면접] 기술 면접(프로젝트)

1. 데이터베이스 락에서 비관적 락과 낙관적 락에 대해 설명해주세요.

1. 비관적 락 (Pessimistic Lock)

• 개념: 트랜잭션에 의해 데이터 충돌이 발생할 가능성이 높다고 가정하고, 트랜잭션이 데이터를 수정하는 동안 다른 트랜잭션이 해당 데이터에 접근하지 못하게 하는 방식입니다.
• 동작 원리: 트랜잭션이 데이터를 읽거나 수정하려 할 때, 미리 락을 걸어서 다른 트랜잭션이 그 데이터를 수정하지 못하게 합니다. 락이 해제될 때까지 해당 데이터에 대한 접근이 제한됩니다.
• 장점: 충돌을 미리 방지하므로 데이터 무결성이 보장됩니다.
• 단점: 락을 오래 유지하게 되면 성능 저하가 발생하고, 자원 경쟁이 심한 경우 데드락(교착 상태)이 발생할 수 있습니다.
• 사용 예시: 은행 시스템처럼 여러 사용자가 동시에 동일한 데이터를 수정할 가능성이 높고 데이터 무결성이 매우 중요한 환경에서 자주 사용됩니다.

2. 낙관적 락 (Optimistic Lock)

• 개념: 트랜잭션에 의해 데이터 충돌이 발생할 가능성이 낮다고 가정하고, 트랜잭션이 완료될 때 충돌이 있는지 검증하는 방식입니다. 충돌이 발견되면 트랜잭션을 다시 실행하는 전략을 사용합니다.
• 동작 원리: 데이터를 수정할 때 락을 걸지 않고, 데이터를 수정한 후에 충돌 여부를 확인합니다. 일반적으로 버전 번호나 타임스탬프를 사용하여 충돌이 발생했는지 검사합니다. 충돌이 발견되면 트랜잭션을 롤백하고 다시 시도합니다.
• 장점: 락을 사용하지 않아 성능이 더 좋고 자원 경쟁이 적습니다.
• 단점: 충돌이 발생하면 트랜잭션을 재시도해야 하므로, 충돌 빈도가 높은 경우 성능이 떨어질 수 있습니다.
• 사용 예시: 충돌 가능성이 낮은 웹 애플리케이션에서 자주 사용되며, 데이터 충돌이 드물게 발생하는 환경에 적합합니다.

2. 마이크로서비스아키텍쳐와 모놀리틱 아키텍쳐에 대해 설명해주세요.

1. 모놀리틱 아키텍처 (Monolithic Architecture)

모놀리틱 아키텍처는 애플리케이션의 모든 기능이 하나의 큰 코드베이스에 포함된 아키텍처입니다. 즉, 모든 모듈(프론트엔드, 백엔드, 데이터베이스 등)이 하나의 애플리케이션 내에서 긴밀하게 연결되어 함께 배포되고 관리됩니다.

장점

• 단순성: 모든 기능이 하나의 코드베이스에 있기 때문에 개발, 테스트, 배포가 비교적 간단합니다. 코드가 하나로 통합되어 있기 때문에 전체 시스템을 이해하기 쉽습니다.
• 성능: 모든 모듈이 한 애플리케이션 내에서 실행되므로 서비스 간 통신 비용이 없습니다. 시스템 간의 네트워크 오버헤드가 발생하지 않아 빠르게 동작할 수 있습니다.
• 배포 용이성: 애플리케이션 전체를 하나의 배포 단위로 다루기 때문에 배포 프로세스가 단순하며, 배포 관리가 수월합니다.

단점

• 유지보수 어려움: 애플리케이션이 커질수록 코드베이스가 복잡해지며, 수정이 어려워집니다. 작은 변경이라도 전체 시스템을 다시 빌드하고 배포해야 합니다.
• 확장성 제한: 특정 기능만 확장하고 싶더라도 애플리케이션 전체를 확장해야 하므로 리소스 낭비가 발생할 수 있습니다.
• 배포 리스크: 하나의 작은 기능 변경이 애플리케이션 전체에 영향을 줄 수 있어, 오류 발생 시 전체 시스템이 중단될 수 있습니다.

---

2. 마이크로서비스 아키텍처 (Microservices Architecture)

마이크로서비스 아키텍처는 애플리케이션을 독립적으로 배포되고 관리될 수 있는 작은 서비스들의 집합으로 분리한 구조입니다. 각 서비스는 독립적인 기능을 담당하고, 독립적으로 배포 및 확장할 수 있습니다.

장점

• 독립적 배포: 각 서비스는 독립적으로 배포가 가능하므로, 한 서비스의 업데이트나 수정이 다른 서비스에 영향을 주지 않습니다. 특정 서비스만을 빠르게 업데이트할 수 있습니다.
• 확장성: 필요한 서비스만 독립적으로 확장할 수 있습니다. 트래픽이 많은 서비스는 별도로 스케일 아웃(수평 확장)할 수 있기 때문에 자원을 효율적으로 사용할 수 있습니다.
• 기술 선택의 유연성: 각 마이크로서비스는 서로 다른 기술 스택(언어, 데이터베이스, 프레임워크)을 사용할 수 있습니다. 팀이 각 서비스에 적합한 기술을 선택하여 개발할 수 있습니다.
• 고가용성: 한 서비스에 문제가 생겨도 다른 서비스가 영향을 받지 않아 시스템 전체의 가용성을 높일 수 있습니다.

→ 대규모 서비스나 확장성, 고가용성 서비스를 개발해야 할 때 

단점

• 복잡성 증가: 서비스가 여러 개로 나뉘어져 있기 때문에 각 서비스 간 통신, 데이터 일관성, 트랜잭션 관리 등의 문제가 발생할 수 있습니다. 이를 해결하기 위해 메시징 시스템, API 게이트웨이 등 추가적인 인프라가 필요합니다.
• 배포 복잡성: 각 서비스가 독립적으로 배포되기 때문에 배포 관리가 복잡해질 수 있으며, 자동화된 배포 파이프라인이 필요합니다.
• 데이터 관리 어려움: 각 서비스가 독립적인 데이터베이스를 사용할 수 있기 때문에 서비스 간 데이터 일관성을 유지하는 것이 어려울 수 있습니다.

---

3. 차이점

특징	모놀리틱 아키텍쳐	마이크로서비스 아키텍쳐
구조	하나의 코드베이스, 하나의 배포 단위	여러 개의 독립된 작은 서비스로 구성
배포	모든 기능을 한 번에 배포	각 서비스별로 독립적으로 배포 가능
확장성	전체 시스템을 확장해야 함	필요한 서비스만 선택적으로 확장 가능
유지보수	애플리케이션이 커질수록 복잡해지고 유지보수가 어려워짐	개별 서비스만 유지보수 가능
성능	서비스 간 네트워크 비용이 없으므로 빠름	서비스 간 통신 오버헤드 존재
기술 선택	통일된 기술 스택 사용	각 서비스마다 다른 기술 스택 선택 가능
개발 팀 구조	한 팀이 전체 시스템을 관리	서비스별로 작은 팀이 독립적으로 개발 가능
데이터 관리	단일 데이터베이스 사용	각 서비스가 독립적인 데이터 저장소를 가질 수 있음

4. 어떤 경우에 각각을 선택할까?

• 모놀리틱 아키텍처: 초기 개발 단계이거나 작은 애플리케이션일 때, 배포와 유지보수가 간단한 환경에서는 모놀리틱 구조가 더 적합할 수 있습니다.
• 마이크로서비스 아키텍처: 시스템이 점점 커지며, 여러 팀이 동시에 여러 기능을 개발하거나, 확장성 및 유지보수가 중요한 대규모 시스템에서는 마이크로서비스가 더 유리합니다.

3. Docker를 사용하는 이유에 대해서 설명해주세요

도커를 사용하면 소프트웨어의 개발과 배포를 도와주는 컨테이너를 통해 애플리케이션을 빌드, 배포, 실행하는 과정을 쉽게 할 수 있게 한다.

• 어떤 OS에서도 일관된 실행 환경을 제공하여 "개발 환경에서 잘 되는데 운영 환경에서는 안 된다"는 문제를 방지합니다.
• 애플리케이션을 격리하여 종속성 충돌을 피하고, 효율적인 자원 사용을 통해 가상 머신보다 가볍고 빠릅니다.
• 빠른 배포와 확장이 가능하고, 이식성이 뛰어나 다양한 환경에서 쉽게 배포할 수 있습니다.
• DevOps 및 CI/CD 파이프라인과 잘 통합되며, 버전 관리 및 롤백을 지원하여 안정성을 보장합니다.
• 멀티 클라우드 및 하이브리드 클라우드 환경에서도 사용하기 용이합니다.

도커를 사용하는 이유

• 일관성
• 이식성
• 확장성
• 효율성

4. Spring MVC 에 대해 설명해줘

Spring MVC는 Spring Framework에서 제공하는 웹 애플리케이션 아키텍처 패턴으로, Model-View-Controller (MVC) 디자인 패턴을 기반으로 합니다. 이 패턴은 애플리케이션의 각 기능을 모델(Model), 뷰(View), 컨트롤러(Controller)로 분리하여, 애플리케이션의 유지보수성과 확장성을 높이는 구조입니다.

1. Spring MVC 아키텍처의 구성 요소

Spring MVC는 다음과 같은 주요 구성 요소로 이루어져 있습니다.

1) Model (모델)

• 역할: 애플리케이션의 핵심 데이터와 비즈니스 로직을 처리합니다. 모델은 데이터베이스와의 상호작용을 통해 데이터를 가져오고, 비즈니스 규칙을 적용하여 데이터를 처리하거나 변환하는 역할을 합니다.
• 구현: 일반적으로 데이터 객체(엔티티 클래스)나 서비스 클래스 등이 모델에 해당합니다.

2) View (뷰)

• 역할: 사용자에게 보여줄 UI(화면)를 담당합니다. 사용자가 볼 수 있는 데이터나 결과물을 렌더링하여, HTML, JSP, Thymeleaf 같은 템플릿을 사용해 화면을 구성합니다.
• 구현: JSP, Thymeleaf, HTML 등이 뷰로 사용되며, 모델에서 처리된 데이터를 사용해 웹 페이지를 생성합니다.

3) Controller (컨트롤러)

• 역할: 사용자의 요청을 처리하고, 모델과 뷰 사이에서 중개자 역할을 합니다. 클라이언트로부터 HTTP 요청을 받아 적절한 서비스를 호출하고, 데이터를 모델로 처리한 후 그 결과를 뷰에 전달합니다.
• 구현: Spring MVC에서는 주로 @Controller나 @RestController 어노테이션을 사용하여 컨트롤러를 정의합니다.

2. Spring MVC의 장점

• 관심사의 분리: 모델, 뷰, 컨트롤러를 분리하여 각각의 역할을 명확하게 나누므로 코드의 유지보수성과 재사용성을 높일 수 있습니다.
• 유연한 뷰 선택: 다양한 뷰 기술(JSP, Thymeleaf, FreeMarker 등)을 선택하여 사용 가능합니다.
• Spring 의존성 주입(DI)과 결합: Spring MVC는 스프링의 강력한 의존성 주입과 결합되어 애플리케이션을 유연하고 모듈화된 구조로 개발할 수 있습니다.
• 커스터마이징 가능: 인터셉터, 필터, ExceptionResolver 등 다양한 확장 기능을 통해 애플리케이션을 커스터마이징할 수 있습니다.

3. Spring MVC 패턴 요약

구성 요소	역할
Model	데이터 및 비즈니스 로직 처리
View	사용자에게 표시할 UI 렌더링
Controller	사용자의 요청을 처리하고 모델과 뷰를 연결하는 중개자
DispatcherServlet	모든 요청을 처리하는 프론트 컨트롤러 역할
Handler Mapping	요청 URL과 컨트롤러 메서드를 매핑
ViewResolver	어떤 뷰를 사용할지 결정하고 렌더링을 수행

5. Redis와 Mem-cached의 차이

Redis와 Memcached는 둘 다 메모리 기반의 캐시 스토리지로, 빠른 데이터 액세스를 위해 자주 사용됩니다. 하지만 기능과 사용 사례에서 차이가 있습니다. 각각의 특성과 차이점을 아래에서 설명합니다.

1. 데이터 구조 지원

• Redis: Redis는 다양한 데이터 구조를 지원합니다. 단순한 키-값 쌍뿐만 아니라, 문자열(String), 리스트(List), 해시(Hash), 셋(Set), 정렬된 셋(Sorted Set), 비트맵, 하이퍼로그로그(HyperLogLog)와 같은 복잡한 데이터 구조를 지원합니다. 이를 통해 보다 다양한 용도로 Redis를 활용할 수 있습니다.
• Memcached: Memcached는 단순한 키-값 쌍만을 지원합니다. 값으로는 문자열이나 이진 데이터를 저장할 수 있으며, 복잡한 데이터 구조는 지원하지 않습니다. 이는 캐시 시스템으로써 매우 단순하게 설계되었기 때문입니다.

2. 영속성(Persistence)

• Redis: Redis는 데이터 영속성을 지원합니다. 즉, 메모리에 저장된 데이터를 디스크에 저장하여 서버가 재시작되더라도 데이터를 복구할 수 있습니다. Redis는 RDB(Snapshot) 방식과 AOF(Append-Only File) 방식을 통해 데이터를 디스크에 저장합니다. 이를 통해 Redis는 단순한 캐시 시스템뿐만 아니라 데이터베이스로도 사용될 수 있습니다.
• Memcached: Memcached는 영속성 기능을 제공하지 않으며, 메모리 기반의 캐시로만 동작합니다. 서버가 재시작되거나 메모리가 손실되면 데이터는 복구되지 않습니다. 즉, 데이터는 휘발성입니다.

3. 데이터 복제 및 클러스터링

• Redis: Redis는 데이터 복제와 클러스터링을 지원합니다. Redis의 Sentinel 기능을 통해 고가용성(HA)을 구현할 수 있고, Redis Cluster를 통해 데이터의 분산 저장과 자동화된 파티셔닝, 고가용성을 지원합니다. 이로 인해 Redis는 대규모 분산 시스템에서도 안정적으로 사용할 수 있습니다.
• Memcached: Memcached 자체는 복제나 클러스터링 기능을 기본적으로 지원하지 않습니다. 다만, 애플리케이션 측에서 샤딩(데이터 분할)을 구현하여 여러 Memcached 서버를 사용하는 방식으로 확장이 가능합니다. 이 방식은 클라이언트 측에서 데이터를 분산 처리해야 하므로 Redis에 비해 구현이 다소 복잡할 수 있습니다.

4. 메모리 관리

• Redis: Redis는 데이터를 저장할 때 LRU(Least Recently Used) 알고리즘을 사용하여 필요시 오래된 데이터를 삭제할 수 있습니다. 또한, Redis는 데이터를 압축해 메모리 효율성을 높이는 다양한 설정을 제공하며, 필요한 경우 특정 키만 만료 시간(Expire Time)을 설정할 수 있습니다.
• Memcached: Memcached도 LRU를 사용하여 캐시된 데이터가 가득 차면 오래된 데이터를 자동으로 삭제합니다. 하지만 Memcached는 모든 데이터를 메모리에 저장하며, 세분화된 만료 시간 설정 및 메모리 관리 옵션이 상대적으로 단순합니다.

5. 사용 사례

• Redis: Redis는 다양한 데이터 구조를 지원하고, 영속성 및 클러스터링 기능을 갖추고 있기 때문에 캐시뿐만 아니라 메시지 큐, 세션 관리, 실시간 분석, 채팅 시스템, 카운터 관리 등 여러 용도로 활용됩니다. 또한, Pub/Sub 기능을 통해 실시간 메시징 시스템으로도 사용할 수 있습니다.
• Memcached: Memcached는 주로 웹 페이지 캐싱, 데이터베이스 조회 결과 캐싱 등에서 단순한 캐시로 사용됩니다. 데이터 구조가 단순하고 설정이 가벼워, 복잡한 처리가 필요 없는 빠른 데이터 액세스를 요구하는 상황에 적합합니다.

6. 성능

• Redis: Redis는 다양한 기능을 제공하면서도 성능이 뛰어납니다. 하지만 다양한 데이터 구조나 영속성 기능을 사용하는 경우 성능이 다소 저하될 수 있습니다. Redis는 단일 스레드 기반이지만 내부 최적화로 인해 대부분의 경우 매우 높은 성능을 제공합니다.
• Memcached: Memcached는 매우 간단하고 가벼운 설계 덕분에 성능이 뛰어납니다. 멀티 스레드를 지원하여 여러 요청을 동시에 처리할 수 있으며, 캐싱에 특화된 상황에서 성능이 매우 우수합니다. 하지만 복잡한 기능이 없고 단순한 키-값 저장에 초점을 맞추고 있습니다.

7. 개발 편의성

• Redis: Redis는 다양한 클라이언트 라이브러리와 풍부한 커맨드를 지원하며, 복잡한 데이터 구조 및 기능을 활용할 수 있습니다. 이를 통해 개발자에게 강력한 도구를 제공합니다.
• Memcached: Memcached는 상대적으로 간단한 API를 제공하며, 사용법이 매우 직관적입니다. 데이터 구조가 단순하기 때문에 캐시 시스템을 단순히 구현하려는 경우 편리하게 사용할 수 있습니다.

---

Redis와 Memcached의 비교 요약

특징RedisMemcached

데이터 구조 지원	다양한 데이터 구조 (String, List, Set, Hash 등)	단순한 키-값 쌍만 지원
영속성	데이터 영속성 지원 (RDB, AOF)	영속성 없음 (휘발성)
복제 및 클러스터링	복제, 클러스터링 지원 (Redis Sentinel, Redis Cluster)	복제 및 클러스터링 미지원 (클라이언트 샤딩 가능)
메모리 관리	세밀한 메모리 관리 및 만료 시간 설정 가능	단순한 LRU 기반 캐싱
사용 사례	캐싱, 세션 관리, 실시간 분석, 메시지 큐 등	웹 페이지 캐싱, DB 조회 결과 캐싱 등
성능	높은 성능, 다기능	매우 높은 성능, 단순 기능
개발 편의성	다양한 커맨드 및 클라이언트 라이브러리 지원	간단한 API, 직관적인 사용법

결론

• Redis는 더 다양한 기능을 제공하며, 캐시 이외의 다양한 용도로 사용할 수 있는 범용성 있는 도구입니다. 복잡한 데이터 구조와 영속성, 클러스터링이 필요할 때 적합합니다.
• Memcached는 단순한 캐시 시스템을 원할 때 적합하며, 메모리 내에서 단순히 키-값 쌍을 저장하고 빠른 성능이 필요한 경우에 사용됩니다.

6. 정형 , 반정형, 비정형 데이터에대해 설명해주세요.

정형데이터 : 데이터베이스의 정해진 규칙에 맞게 데이터가 들어가 연산이 가능한 데이터

비정형데이터 : 음성데이터, 영상데이터 같이 정해진 규칙이 없는 데이터

반정형데이터 : HTML,XML,JSON 같이 정형, 비정형이 혼합되었고 규칙은 있지만 연산이 불가능

7. 객체지향의 특성에 대해 설명해주세요.

객체지향 프로그래밍(Object-Oriented Programming, OOP)의 특성은 소프트웨어 개발을 구조적으로 조직화하고 유지보수성을 높이기 위한 중요한 개념입니다. 객체지향의 핵심 특성으로는 추상화, 캡슐화, 상속, 다형성이 있습니다.

1. 추상화(Abstraction)

• 추상화는 객체의 복잡성을 숨기고, 중요한 속성이나 기능만을 외부에 제공하는 것을 의미합니다. 즉, 세부 구현은 감추고 필요한 기능만 노출함으로써 프로그래머가 복잡한 시스템을 단순하게 사용할 수 있도록 합니다.
• 예를 들어, 자동차 객체에서 우리는 '운전'이나 '멈추기' 같은 동작만 필요로 하지, 엔진의 작동 원리를 일일이 알 필요는 없습니다.

2. 캡슐화(Encapsulation)

• 캡슐화는 객체의 상태(데이터)와 행동(메서드)을 하나로 묶고, 외부에서 직접 접근하지 못하도록 보호하는 것입니다(은닉성). 이를 통해 데이터의 무결성을 유지하고, 객체가 관리하는 데이터를 잘못된 방식으로 사용하지 않게 합니다.
• 캡슐화는 일반적으로 접근 제어자(public, private, protected)를 통해 구현됩니다. 외부에서는 허용된 메서드를 통해서만 객체의 데이터를 변경하거나 접근할 수 있습니다.

3. 상속(Inheritance)

• 상속은 기존 클래스의 속성과 메서드를 새 클래스가 물려받아 재사용하는 개념입니다. 상속을 통해 중복 코드를 줄이고, 부모 클래스의 기능을 확장하거나 재정의하여 새로운 기능을 추가할 수 있습니다.
• 상속은 코드의 재사용성을 높이고, 계층적인 구조를 통해 객체들을 체계적으로 관리할 수 있게 합니다.
• 예를 들어, 동물이라는 부모 클래스가 있고, 이를 상속받은 개, 고양이 등의 자식 클래스가 있을 수 있습니다.

4. 다형성(Polymorphism)

• 다형성은 같은 메서드 이름이지만 다른 기능을 하도록 하는 것을 말합니다. 즉, 같은 이름의 메서드나 연산자가 여러 형태로 동작할 수 있게 만드는 개념입니다. 다형성은 주로 오버로딩(Overloading)과 오버라이딩(Overriding)을 통해 구현됩니다.
  • 오버로딩(Overloading): 같은 이름의 메서드가 다른 매개변수(파라미터)를 가질 때 발생하는 다형성입니다.
  • 오버라이딩(Overriding): 자식 클래스가 부모 클래스의 메서드를 재정의하여 다른 방식으로 동작하게 하는 것입니다.

8. MSA와 K8S에 대한 기본적인 이해도를 설명해주세요.

1. MSA (Microservices Architecture)

마이크로서비스 아키텍처(MSA)는 애플리케이션을 작은 단위의 독립적인 서비스들로 나누어 개발하고 운영하는 아키텍처입니다. 각각의 서비스는 특정 비즈니스 기능을 담당하며, 서로 독립적으로 배포, 확장, 유지보수가 가능합니다.

주요 특징:

• 독립적인 배포 및 개발: 각 서비스는 독립적으로 개발, 테스트, 배포될 수 있습니다. 한 서비스의 문제가 다른 서비스에 영향을 주지 않게 됩니다.
• 자율적인 기술 스택: 각 마이크로서비스는 서로 다른 언어나 프레임워크, 데이터베이스를 사용할 수 있습니다. 개발팀은 필요한 기술을 자유롭게 선택할 수 있습니다.
• 확장성: 트래픽이 많이 발생하는 특정 서비스만 별도로 확장할 수 있기 때문에 전체 시스템의 자원 효율성이 높아집니다.
• 유지보수 용이성: 서비스가 작고 단순하기 때문에, 변경이 필요한 경우 전체 애플리케이션이 아닌 해당 서비스만 수정하면 됩니다.

2. K8S (Kubernetes)

Kubernetes(K8S)는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 자동화하는 오픈 소스 플랫폼입니다. Docker와 같은 컨테이너 기술을 이용해 애플리케이션을 실행하는 데 초점을 맞추고 있으며, 특히 마이크로서비스 아키텍처와 잘 어울립니다.

주요 특징:

• 자동화된 배포와 확장: Kubernetes는 클러스터 환경에서 컨테이너의 배포와 관리를 자동화합니다. 서비스가 늘어날 때 필요한 컨테이너의 수를 자동으로 조정하거나, 실패한 컨테이너를 자동으로 재시작할 수 있습니다.
• 컨테이너 오케스트레이션: 여러 개의 컨테이너가 서로 협력하여 하나의 서비스를 제공할 때, 이를 자동으로 배치하고 연결하는 역할을 합니다.
• 무중단 롤링 업데이트: 애플리케이션을 배포할 때 Kubernetes는 무중단으로 업데이트를 적용할 수 있습니다.
• 자체 복구(Self-healing): 장애가 발생한 컨테이너를 자동으로 감지하고 재시작하거나, 필요 없는 컨테이너는 자동으로 제거합니다.
• 서비스 디스커버리와 로드 밸런싱: Kubernetes는 각 서비스의 엔드포인트를 자동으로 탐지하고, 트래픽을 분산시키는 로드 밸런서를 제공합니다.

Kubernetes의 구조:

• Pod: 가장 작은 배포 단위로, 하나 이상의 컨테이너를 담고 있습니다.
• Node: Kubernetes 클러스터 내에서 Pod가 실행되는 실제 혹은 가상의 서버입니다.
• Cluster: 여러 노드가 모여 Kubernetes 클러스터를 구성하며, 모든 애플리케이션이 이 환경에서 실행됩니다.
• Master: 클러스터의 상태를 관리하고, 배포를 계획하는 중앙 관리 역할을 합니다.

MSA와 K8S의 상호작용:

• MSA의 서비스들이 각각 독립적인 컨테이너로 실행되고, K8S는 이 컨테이너들을 오케스트레이션하여 안정적으로 운영합니다.
• MSA의 서비스가 증가하면, K8S는 해당 컨테이너들을 자동으로 관리하고 확장하며, 장애 상황에서도 복구를 도와줍니다.

9. Spring Cloud를 사용할 때 개발자들이 Netflix Eureka를 선호하는 이유에 대해서 설명해주세요.

MSA 환경에서 여러 개의 독립적인 서비스가 서로 통신하는데, 이 과정에서 Eureka를 사용하면 Server에서 IP를 관리하고 Client에서 서비스 name만 사용하는 방식으로 동적으로 서비스들을 등록하고 발견할 수 있습니다.

 

1. 서비스 디스커버리

마이크로서비스 환경에서는 수많은 서비스가 배포되며, 각 서비스의 IP 주소와 포트가 동적으로 변경될 수 있습니다. 특히 컨테이너화된 환경(Kubernetes, Docker)에서는 서비스가 수시로 시작되고 중단되기 때문에 고정된 IP 주소를 사용하는 것이 어렵습니다.

Eureka는 각 서비스가 스스로를 Eureka 서버에 등록하고, 다른 서비스는 해당 서버를 통해 동적으로 필요한 서비스를 찾을 수 있습니다. 이렇게 하면 하드코딩된 IP 주소나 고정 포트에 의존할 필요가 없어집니다.

2. 로드 밸런싱

Eureka와 함께 사용되는 Netflix의 Ribbon과 같은 클라이언트 측 로드 밸런싱 라이브러리를 통해, Eureka에 등록된 여러 인스턴스 간에 부하를 분산할 수 있습니다. 이를 통해 트래픽을 분산시켜 서비스의 성능과 안정성을 높일 수 있습니다.

3. Failover 및 Fault Tolerance

서비스 인스턴스가 중단되거나 문제가 생긴 경우, Eureka는 해당 인스턴스를 자동으로 제거하고, 사용 가능한 다른 인스턴스만을 클라이언트에게 제공합니다. 이를 통해 서비스의 고가용성(HA)을 보장하고, 장애가 발생하더라도 클라이언트는 정상적인 인스턴스와 계속 통신할 수 있습니다.

4. 확장성

Eureka는 마이크로서비스 환경에서 동적으로 인스턴스를 추가하거나 제거할 수 있는 기능을 지원합니다. 서비스가 자동으로 Eureka 서버에 등록되기 때문에 수동으로 설정 파일을 변경하거나, 수작업으로 새로운 인스턴스를 관리할 필요가 없습니다. 이렇게 동적인 확장과 축소가 가능하여, 서비스의 확장성(scalability)을 높여줍니다.

5. 헬스 체크 및 자가 등록(Self-registration)

Eureka는 각 서비스가 주기적으로 헬스 체크를 통해 자신의 상태를 보고하도록 합니다. 이를 통해 문제가 있는 서비스는 자동으로 Eureka에서 제거되어, 클라이언트가 비정상적인 서비스와 통신하지 않도록 할 수 있습니다. 또한, Eureka는 각 서비스가 스스로 등록(self-registration)하고 자신의 상태를 보고하므로, 중앙 집중형 설정이나 관리가 필요 없습니다.

6. 클라우드 네이티브 및 마이크로서비스에 적합

Netflix Eureka는 Netflix OSS(Open Source Software) 생태계의 일부로서, 클라우드 환경과 마이크로서비스 아키텍처에서 사용하기 적합하도록 설계되었습니다. 특히 동적으로 변경되는 클라우드 인프라 환경에서 서비스 간 통신을 효율적으로 관리하고 자동화하는 데 유용합니다.

사용 예시

만약 사용자가 Order-Service를 호출하려고 할 때, 이 서비스가 여러 인스턴스로 배포되어 있더라도 Eureka는 사용 가능한 인스턴스 목록을 제공해 최적의 인스턴스에 요청을 전달합니다. 이로 인해 서비스가 확장되거나 축소되더라도 동적으로 인스턴스를 관리할 수 있게 됩니다.

결론

Netflix Eureka는 MSA에서 여러 개의 서비스들이 동적으로 서로를 발견하고, 관리할 수 있도록 하여 마이크로서비스 환경에서 확장성, 유연성, 고가용성을 보장하는 핵심 도구입니다.

 

 

10. REST API에 대해 설명해주세요.

REST API(Representational State Transfer Application Programming Interface)는 웹에서 상호작용하는 시스템 간에 데이터를 교환하기 위한 아키텍처 스타일입니다. REST는 웹의 HTTP 프로토콜을 기반으로 설계되어 있으며, RESTful API는 간단하고 확장성이 뛰어난 방식으로 클라이언트와 서버 간에 데이터를 주고받을 수 있도록 합니다.

REST API의 주요 특징

1. 무상태(Stateless)
   • REST API는 Stateless한 특성을 가지고 있습니다. 즉, 서버는 각 요청을 독립적으로 처리하며, 이전 요청의 상태나 데이터를 저장하지 않습니다. 모든 요청은 필요한 모든 정보를 포함해야 하며, 서버는 클라이언트의 상태를 기억하지 않습니다. 이를 통해 확장성(Scalability)이 높아집니다.
2. 클라이언트-서버 구조
   • REST는 클라이언트와 서버의 역할을 명확히 분리합니다. 클라이언트는 서버에 요청을 보내고, 서버는 클라이언트의 요청을 처리하여 데이터를 응답합니다. 클라이언트는 서버의 내부 동작을 몰라도 되며, 서버는 클라이언트의 상태를 유지하지 않으므로 양쪽의 독립성을 유지할 수 있습니다.
3. 리소스(Resource) 기반
   • REST API에서는 데이터를 리소스(resource)로 취급합니다. 리소스는 URI(Uniform Resource Identifier)로 식별되며, 클라이언트는 HTTP 메서드를 사용해 이 리소스와 상호작용합니다.
4. 표현(Representation)
   • 클라이언트가 리소스를 요청하면, 서버는 해당 리소스의 표현을 응답합니다. 이 표현은 일반적으로 JSON 또는 XML 형식으로 제공됩니다. 예를 들어, 서버가 데이터베이스에 있는 사용자 정보를 리소스로 정의하고, 클라이언트가 이를 요청하면 서버는 사용자 정보를 JSON 형식으로 응답할 수 있습니다.
5. HTTP 메서드 사용
   • REST API는 **HTTP 메서드(Methods)**를 이용하여 리소스에 대한 작업을 정의합니다. 주로 사용되는 메서드는 다음과 같습니다:
     • GET: 리소스를 조회할 때 사용합니다. 서버에서 데이터를 읽기 위한 요청입니다.
     • POST: 새로운 리소스를 생성할 때 사용됩니다.
     • PUT: 기존 리소스를 업데이트할 때 사용됩니다. 전체 리소스를 업데이트할 때 주로 사용합니다.
     • PATCH: 리소스의 일부만 수정할 때 사용됩니다.
     • DELETE: 리소스를 삭제할 때 사용됩니다.
6. 캐싱(Cacheable)
   • REST API는 응답이 캐싱 가능해야 합니다. HTTP 프로토콜의 캐싱 기능을 활용하여 클라이언트가 동일한 요청을 반복할 경우, 서버에 불필요한 요청을 보내지 않고 캐시된 데이터를 사용할 수 있습니다.

11. Docker와 Docker-Compose에 대해 설명해줘

Docker

Docker는 개별 컨테이너를 통해 애플리케이션을 배포하고 관리하는 도구입니다.

• 설명: Docker는 애플리케이션을 독립적인 컨테이너 환경에서 실행할 수 있게 해주는 오픈소스 플랫폼입니다. 컨테이너는 애플리케이션과 해당 애플리케이션이 동작하는 데 필요한 라이브러리, 종속성 등을 하나로 묶어 다른 환경에서도 동일하게 작동하도록 만듭니다. 이를 통해 개발 환경과 운영 환경의 일관성을 유지할 수 있으며, VM보다 가볍고 빠릅니다.
• 주요 기능:
  • 이미지: 컨테이너를 실행하는 데 필요한 설정과 파일들을 묶어놓은 패키지입니다. 이미지는 레이어 구조로 되어 있어, 변경된 부분만 업데이트됩니다.
  • 컨테이너: 이미지를 기반으로 실행되는 인스턴스입니다. 독립된 프로세스로 애플리케이션을 실행하며, 필요한 파일 시스템과 네트워크, 환경 설정을 포함합니다.
• 사용 예시: 특정 언어의 런타임이 필요한 애플리케이션 실행, 개발 환경과 운영 환경의 일관성 유지, 다중 서비스 애플리케이션 배포.

Docker Compose

docker compose는 여러 개의 Docker 컨테이너를 정의하고 , 이들을 하나의 애플리케이션으로 관리 할 수 있게 해준다.

• 설명: Docker Compose는 여러 개의 Docker 컨테이너를 정의하고 동시에 관리할 수 있는 도구입니다. docker-compose.yml 파일을 통해 서비스, 네트워크, 볼륨 등 애플리케이션의 여러 컨테이너 설정을 코드로 관리할 수 있어, 복잡한 멀티 컨테이너 애플리케이션을 쉽게 구성하고 배포할 수 있습니다.
• 주요 기능:
  • 서비스 정의: 여러 컨테이너를 구성하고 연결하여 서비스를 정의합니다. 예를 들어, 웹 애플리케이션, 데이터베이스, 캐싱 서버 등을 하나의 파일로 정의할 수 있습니다.
  • 멀티 컨테이너 실행: docker-compose up 명령으로 정의된 모든 서비스가 실행되며, 종속성과 네트워크 설정에 따라 자동으로 연결됩니다.
• 사용 예시: 웹 서버와 데이터베이스 서버를 포함하는 애플리케이션 실행, 로컬에서 동일한 환경을 손쉽게 재현, CI/CD 파이프라인에서 여러 서비스 간 통합 테스트 수행.

12. on-premise 서비스에 대해 알고있는 만큼 설명해주세요

On-Premise 기반 서비스는 조직이나 기업이 자체 데이터센터나 서버에 IT 인프라와 소프트웨어를 직접 설치하고 운영하는 방식입니다. 클라우드 기반 서비스와는 달리, 모든 하드웨어와 소프트웨어가 기업의 물리적 위치에 있으며, 이로 인해 데이터와 시스템이 완전히 내부 통제 하에 있습니다.

On-Premise 서비스의 주요 특징

1. 데이터 보안 및 통제: 모든 데이터와 애플리케이션이 조직 내부에 위치해 있어 데이터 접근, 보관, 관리에 대한 완전한 통제권을 유지할 수 있습니다. 특히 보안이 중요한 금융, 의료, 정부 기관 등이 많이 사용합니다.
2. 커스터마이징 가능성: 조직의 필요에 따라 시스템을 자유롭게 변경하고 최적화할 수 있어 맞춤형 환경 구축이 용이합니다. 내부 개발자나 IT 팀이 시스템을 조정하고 유지 관리할 수 있습니다.
3. 고정 비용 구조: 초기 하드웨어와 소프트웨어 구축에 대한 고정 비용이 많이 들어갑니다. 이후 유지보수나 업그레이드에도 추가 비용이 발생할 수 있으며, 필요한 경우 서버 확장을 위해 추가 구매도 요구됩니다.
4. 독립성: 클라우드 서비스처럼 인터넷 연결이나 외부 공급자의 상태에 의존하지 않으며, 데이터 전송 지연 없이 고속으로 운영 가능합니다.

On-Premise의 장점

• 보안성: 외부 인터넷 연결이 필수적이지 않아 데이터 유출 위험이 적습니다.
• 맞춤형 설계: 특정 애플리케이션 요구사항에 맞게 설계 및 최적화 가능.
• 규제 준수: 데이터 규제나 법적 요구사항을 충족하기 쉬워, 민감한 데이터를 다루는 산업에서 선호.

On-Premise의 단점

• 높은 초기 비용: 하드웨어, 소프트웨어, 설치 및 유지보수에 대한 비용이 클라우드에 비해 높습니다.
• 유지보수 부담: 전담 IT 인력이 필요한 경우가 많고, 인프라를 직접 관리해야 하므로 인력과 시간 소모가 큽니다.
• 확장성 제한: 트래픽 증가에 대응하기 위해 서버 확장이 필요할 때, 물리적인 인프라 확장이 제한될 수 있습니다.

On-Premise와 클라우드 비교

• On-Premise는 보안, 커스터마이징, 고정 비용이 장점인 반면, 클라우드는 확장성, 유연성, 비용 효율성이 뛰어나며 필요 시 확장과 축소가 용이합니다.

On-Premise는 보안이나 특정 규제 준수가 중요한 기업에게 유리하지만, 유연성과 비용 효율성을 중요시하는 경우 클라우드 솔루션이 적합할 수 있습니다.

13. NAT 에 대해 설명해주세요.

NAT는 Network Address Translation의 줄임말 입니다. NAT는 사설 네트워크에 속한 여러 개의 호스트가하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위해 사용합니다. 쉽게말해서 외부망과 내부망을 나눠주는 기능을 하게 되는 것입니다. 

NAT 특징

- 내부에서 외부로 통신 가능

- 외부에서 내부로 통신 불가

NAT 장점

- 여러 사설 네트워크를 사용함으로서 인터넷 공인 IP 주소를 절약 가능.

- 사내망 IP주소를 외부로 알리지 않음으로서 외부로 부터의 침입/공격 차단

NAT 단점

- 네트워크 복잡성 증가

- 네트워크 지연 영향

NAT 종류

- Static NAT : 사설IP와 공인 IP를 1:1 매핑

- Dynamic NAT : 다수 공인 IP와 다수 사설 IP 매핑

- PAT : 1개의 공인 IP와 다수 사설 IP 매핑 -> 1개 공인 IP에 port를 구분하여 사설 PC를 구분

14. NAS , SAN에 대해 설명해주세요

NAS(Network Attached Storage)와 SAN(Storage Area Network)는 모두 데이터 저장 솔루션을 제공하는 기술이지만, 각기 다른 방식으로 데이터 스토리지를 네트워크에 연결합니다.

NAS (Network Attached Storage)

• 개념: NAS는 네트워크에 연결된 파일 수준의 스토리지로, 여러 사용자와 장치가 네트워크를 통해 파일을 공유하고 접근할 수 있도록 해줍니다. NAS는 파일 서버처럼 작동하며, 파일을 저장, 관리, 공유하기 위한 전용 기기로 구축됩니다.
• 구성: NAS는 독립적인 장치로서 운영 체제와 파일 시스템을 갖추고 있으며, 주로 Ethernet 네트워크를 통해 연결됩니다. NAS 장치는 각 사용자가 네트워크에 접근해 파일을 저장하거나 읽을 수 있도록 파일 공유 프로토콜(NFS, SMB/CIFS 등)을 사용합니다.
• 주요 특징:
  • 파일 수준 스토리지: 사용자가 파일 단위로 데이터를 다룹니다.
  • 용이한 설정: 별도의 하드웨어나 복잡한 설정 없이 NAS 장치만 네트워크에 연결하면 바로 사용할 수 있습니다.
  • 주요 용도: 소규모에서 중규모 네트워크, 가정용, 중소기업의 데이터 저장 및 공유를 목적으로 주로 사용됩니다.
• 장점:
  • 비용 효율성: 초기 비용이 비교적 낮고 설치가 간편합니다.
  • 간단한 관리: 전용 하드웨어나 복잡한 네트워크 설정 없이 쉽게 관리할 수 있습니다.
• 단점:
  • 확장성 제한: 고성능이나 대규모의 확장성 면에서는 SAN보다 제한적입니다.
  • 네트워크 부하: Ethernet을 통해 데이터를 주고받기 때문에 네트워크 트래픽이 많아질 경우 성능에 영향을 줄 수 있습니다.

SAN (Storage Area Network)

• 개념: SAN은 서버와 스토리지 디바이스 간의 네트워크를 별도로 구성한 블록 수준 스토리지입니다. SAN은 주로 고성능, 고용량 데이터 저장이 필요한 엔터프라이즈 환경에서 사용되며, 서버와 디스크 스토리지를 직접 연결하여 빠르고 안정적인 데이터 접근을 제공합니다.
• 구성: SAN은 전용 스토리지 네트워크를 통해 서버와 디스크 스토리지 장치를 연결합니다. 주로 Fibre Channel 프로토콜을 사용해 고속 전송을 지원하며, 최근에는 iSCSI를 통한 SAN 구축도 증가하고 있습니다.
• 주요 특징:
  • 블록 수준 스토리지: 서버가 블록 단위로 데이터를 읽고 쓰며, 로컬 디스크처럼 작동합니다.
  • 고성능 및 대규모 확장성: 고속 네트워크를 통해 다수의 스토리지를 연결하고 고성능의 데이터 접근이 가능합니다.
  • 주요 용도: 대기업, 데이터 센터, 클라우드 환경에서 방대한 양의 데이터 저장 및 고성능 요구에 대응.
• 장점:
  • 고성능: Fibre Channel 네트워크를 통한 빠른 데이터 전송과 안정성.
  • 확장성: 다수의 스토리지 장치를 연결할 수 있어 확장이 용이합니다.
  • 유연성: 서버 간 데이터를 쉽게 공유하고 재구성할 수 있습니다.
• 단점:
  • 복잡한 설치 및 높은 비용: 별도의 고가 하드웨어와 네트워크 구성이 필요하여 초기 비용이 높습니다.
  • 전문 인력 필요: 복잡한 구성을 관리하기 위해 전문적인 지식이 필요합니다.

NAS와 SAN 비교 요약

구분NAS (Network Attached Storage)SAN (Storage Area Network)

스토리지 유형	파일 수준 스토리지	블록 수준 스토리지
구성 방식	Ethernet 네트워크를 통한 파일 서버 방식	전용 네트워크 (Fibre Channel, iSCSI 등)
주요 프로토콜	SMB/CIFS, NFS 등	Fibre Channel, iSCSI
확장성	소규모에서 중규모로 확장 가능	대규모 확장 및 고성능 지원
사용 환경	가정용, 소규모 기업의 파일 저장 및 공유	대기업, 데이터 센터, 고성능 스토리지 요구 환경
장점	비용 효율적, 관리 용이	고성능, 확장성, 유연성
단점	성능 및 확장성의 한계, 네트워크 부하 가능	높은 비용과 복잡한 관리