예상 질의 응답 목록

• 다른 Java 프레임 워크도 있는데 Spring을 사용한 이유는 뭔가요? Spring vs Jakarta

  • Spring은 의존성 주입과 AOP와 같은 기능을 통해 더 많은 의존성을 제공하고 설정과 구성이 상대적으로 간단하기에 사용했습니다.

    Spring vs Micronaut

  • Micronaut는 클라우드 네이티브 애플리케이션 개발에 특화되어 있으며 Spring보다 빠르게 시작되고 더 낮은 메모리 사용을 제공하나, spring은 더 많은 기능과 확장성을 제공하며 더 큰 커뮤니티를 갖고 있습니다.

    Spring 프레임워크는 다양한 기능, 강력한 의존성 관리, AOP, 풍부한 데이터 액세스 지원, 활발한 커뮤니티와 같은 장점을 가지고 있습니다.
    다른 프레임워크들은 특정 분야에서 뛰어날 수 있지만, Spring은 전체적으로 균형 잡힌 기능과 유연성을 제공하는 것이 특징입니다

    무엇보다 팀원 모두가 Spring Boot에 경험이 있고 이를 선호하기에 사용했습니다.

• 스타터 종속성을 통해 어떻게 자바 기반의 웹 애플리케이션을 빠르게 구축할 수 있나요? 스타터 종속성은 프로젝트에 필요한 라이브러리들을 미리 정의된 그룹으로 제공하여, 개발자가 웹 서버, 데이터베이스 연결, 보안 등 필요한 기능을 간단하게 추가할 수 있게 해줍니다.
  예를 들어, spring-boot-starter-web을 사용하면 Spring MVC와 Tomcat을 포함한 웹 개발에 필요한 모든 종속성을 한 번에 추가할 수 있습니다.
  이렇게 함으로써, 개발자는 복잡한 설정 과정 없이 기본적인 웹 애플리케이션 구조를 신속하게 구축하고, 즉시 애플리케이션 개발에 집중할 수 있습니다.
  

• Spring Security는 어떻게 동작하나요? 사용자가 HTTP 요청을 보내면 Servlet 필터를 사용해 HTTP 요청을 가로채고, 사용자의 인증 정보를 확인합니다.
  여기서 사용자가 제공한 로그인 정보(자격증명)와 저장된 데이터(DB)와 비교하고 인증합니다.
  인증이 완료되면 사용자가 인증되면 그들에게 권한을 부여(인가)하고 부여한 권한에 따라 사용자가 요청한 리소스에 접근할 수 있는 지 권한을 검사합니다. 만약 권한이 정당하다면 리소스에 접근할 수 있도록 허용해줍니다.
  
• 사용자 정의 로직이 무엇인가요? Spring Security에서 사용자 정의 로직은 개발자가 특정 보안 욫구 사항에 맞게 기본 보안 메커니즘을 변경하거나 확장하는 방법입니다. 예를 들면 필터 체인에 사용자 정의 필터를 추가하고나, 로그인 및 에러 페이지를 직접 만들어서 적용 시키는 것이 포함될 수 있습니다.
  

• JWT의 동작 원리는 어떻게 되나요? Spring에서 JWT의 동작 원리는 사용자가 로그인 시 사용자 정보를 기반으로 JWT를 생성하고 이 토큰을 사용자에게 전송합니다.
  사용자는 JWT를 저장하고, 서버에 요청을 할 때마다 토큰을 HTTP 헤더에 포함시켜서 전송합니다.
  서버는 각 요청 시 헤더에서 JWT를 추출해 유효성을 검증하고 유효한 토큰일 경우에만 요청을 처리합니다. JWT내부에 포함된 권한 정보를 통해 사용자의 요청에 대한 권한 부여 여부도 결정합니다.
  JWT를 이용한 방식은 상태를 유지하지 않는 인증 방식으로 분산 시스템이나 마이크로서비스 아키텍처에서 유용합니다.
  • 상태를 유지하지 않는 인증 방식에 대해 설명해주세요 상태를 유지하지 않는 인증 방식은 서버가 사용자의 인증 상태를 별도로 저장하지 않는 인증 방식을 의미합니다. 서버는 세션을 유지 할 필요 없이 각 요청에 포함된 토큰을 검증 함으로써 인증을 처리합니다.
    
  • JWT 방식을 사용하는 이유는 뭔가요? 가장 핵심 이유는 상태를 유지하지 않는 인증을 가능하게 해서 서버의 부하를 줄이고 확장성을 높여주기 때문입니다. 추가로 JWT는 서명된 토큰 형태로 데이터의 무결성과 안전성을 보장하고 이는 보안성을 향상시킵니다. 마지막으로 JWT는 토큰 자체가 사용자의 인증 및 권한에 관한 모든 필요한 정보를 포함하고 있어서 최초의 인증에서 토큰을 제공 받은 이후 별도의 DB조회 없이 사용자의 인증 및 권한을 검증할 수 있습니다.
    
  • 분산 시스템이나 마이크로서비스 아키텍처에서 JWT가 유용한 이유가 뭔가요? 각 서비스가 독립적으로 토큰을 검증하여 인증을 처리할 수 있게 하여, 중앙 집중식 인증 시스템에 대한 의존성을 줄이고 서비스의 자율성을 증가 시킵니다. 또한 상태를 유지하지 않는 인증은 서버 측에서 세션을 관리할 필요가 없어, 시스템의 수평적 확장이 용이하고 네트워크 트래픽을 줄일 수 있습니다.
    
• JWT를 사용하는 이유 상태를 유지하지 않는 인증으로 서버 부하를 줄이고 확장성을 높일 수 있습니다. 보안성이 뛰어나고 토큰이 자체적으로 사용자 인증 정보를 포함하고 있기에 별도 DB 조회 없이 인증과 권한 부여가 가능합니다. 그에 비해 세션 방식은 사용자 세션 정보를 서버에 저장하므로 서버의 메모리 부하가 증가하고 확장성에 제한이 있을 수 있습니다.
  • 왜 세션이 확장성에 제한이 있을 수 있나요? 서버에서 사용자 세션의 상태를 유지 관리해야 하기 때문입니다. 사용자가 많아지면 서버의 메모리 부담이 증가하고, 이는 서버의 처리 능력에 한계를 가져옵니다.
    또한, 분산 서버 환경에서 세션 일관성을 유지하는 것은 복잡해지고 이는 확장성에 제한을 줍니다

• 다른 도구가 아닌 Swagger를 사용한 이유는 뭔가요? Swagger의 API 문서를 자동화해주는 점이 매력적으로 느껴졌고 팀원 모두가 Swagger를 한번 이상 접해본 경험이 있었습니다.
  API를 자동으로 생성해주는 다른 도구는 접해본 적이 없어서 저희와는 적합하지 않다고 느꼈습니다.

• JPA가 뭔가요? JPA는 자바 애플리케이션에서 관계형 DB의 데이터를 관리하기 위한 표준 ORM 기술입니다. JPA는 개발자가 객체 지향적인 방식으로 DB 작업을 할 수 있도록 도와주며, SQL을 직접 작성하는 대신 객체와 데이터베이스 테이블 간의 매핑을 정의합니다. 이를 통해 데이터 베이스의 작업을 간단하게 할 수 있고 애플리케이션의 이식성과 유지보수성을 향상시킬 수 있습니다.
  • ORM은 뭔가요? ORM이란 객체 지향 프로그래밍 언어를 사용하여 호환 되지 않는 유형의 시스템 간에 데이터를 변환한는 프로그래밍 기법입니다. ORM은 객체와 관계형 DB의 데이터를 매핑합니다. 이를 통해 개발자는 DB의 데이터를 객체로 다룰 수 있습니다. 즉 ORM을 사용할 시 SQL 쿼리 없이 DB 테이블을 객체로서 다루는 것이 가능하기에 개발 속도를 높이고 코드의 가독성을 높여준다.
    
• Spring Data JPA를 사용한 이유는 뭔가요? Spring Data JPA는 Spring 프레임워크와의 원활한 통합을 제공하고 손쉽게 데이터베이스 작업이 가능합니다. 또한 팀원 모두가 유사한 기능을 하는 다른 도구 Hibernate 등 보다 선호도 및 숙련도가 높았습니다. 페이징 및 정렬을 지원한다는 점도 매력적으로 느껴졌습니다.

• QueryDSL은 안전한 쿼리를 작성이 가능한 이유가 뭔가요? QueryDSL의 안전성은 타입 안전성에 기반합니다. QueryDSL은 자바 코드로 작성하니 컴파일 시점에 쿼리의 오류와 타입 불일치를 검출 가능합니다. 또한 객체 지향적인 쿼리 작성이 가능하고 DB 스키마를 바탕의 자동적인 메타모델을 생성합니다. 이 메타모델을 사용해 쿼리를 작성하면 DB의 실제 구조와 다른 쿼리를 작성하는 위험을 줄여줍니다.
  • QueryDSL의 자동 생성된 메타모델에 대해 설명해주세요 QueryDSL의 자동 생성된 메타모델은 데이터베이스 테이블을 대응하는 자바 엔티티 클래스로부터 자동으로 생성되는 클래스입니다.
    이 클래스는 각 엔티티 필드에 대응하는 타입 안전한 속성을 제공하여, QueryDSL을 사용한 쿼리 작성 시 컴파일 시점에 오류를 잡아내고 코드의 정확성을 향상시킵니다.
    

GitHub Actions

GitHub 리포지토리와 밀접하게 통합되어 이벤트 기반 워크플로우를 쉽게 설정할 수 있고, 코드와 CI/CD를 한 곳에서 관리할 수 있어 별도의 도구로 전환할 필요가 없기에 선택하였습니다.

• GitHub Actions을 사용하여 CI/CD를 구현한 이유가 있나요? 프로젝트 코드를 저장하는 GitHub와 GitHub Action은 깊이 통합되어있습니다.
  이를 통해 저희 팀은 프로젝트 소스 코드와 CI/CD 파이프 라인을 동일한 플랫폼에서 관리 할 수 있었습니다. Jenkins와 같은 다른 CI/CD 도구는 통합을 위해서 추가로 플러그인이나 설정이 필요합니다. 또한 GitHub Action은 별도 서버 설치나 관리가 필요하지 않습니다. 추가로 YAML을 통해 간단하게 파이프 라인을 구성합니다. 하지만 Jenkins의 경우에는 서버 설치 및 유지 관리가 필요하고 설정이 GitHub Action에 비해 복잡합니다.
  
• CI/CD ( GitHub Action + S3 + CodeDeploy + EC2 ) 는 어떻게 동작하나요? 개발자가 GitHub에 코드를 Push하면, GitHub Action이 활성화 되며 코드를 자동으로 빌드하고 테스트 합니다.
  성공적으로 빌드 진행되면 생성된 아티팩트는 AWS S3에 업로드된다. 그 이후 CodeDeploy가 아티팩트를 사용해서 EC2 인스턴스에 애플리케이션을 배포한다.
  

Elasticsearch

Elasticsearch의 정의/도입이유는?

• Elasticsearch는 실시간 검색 및 분석을 위한 오픈 소스 분산 검색 엔진입니다.
  기존 검색 개선을 위해서 코드의 복잡도가 증가하는 문제를 Elasticsearch 기술 도입으로 높은 성능과 인덱싱 자동화 구축이 가능했습니다.

  MySQL의 fulltext index가 아닌 Elasticsearch를 사용한 이유는?

• Elasticsearch의 응답속도가 MySQL full-text index에 비해 안정적으로 측정되었으며, Elasticsearch는 튜닝을 통한 성능 개선 고점도 높아 선택하였습니다. 또한 Logstash, Kibana 를 통해 파이프라인을 구축하여 데이터 동기화, 데이터 분석 등 부가 기능들을 쉽게 활용 할 수 있습니다.

  logstash를 통해 MySQL에서 Elasticsearch로 데이터를 가져오는 것으로 보이는데, 변경된 데이터를 실시간으로 가져올 수 있는가?

• 현재 logstash가 1초에 한번 MySql의 DB변경사항을 업데이트하도록 설정되어 있으나, 성능상 문제로 약 7초에 한번 업데이트되고 있습니다. 추후 다른 개선안으로 Kafka를 통한 실시간 연동을 찾아볼 예정입니다.

MySQL

대량 데이터 처리와 유연성이 높아 데이터 조작과 검색이 용이합니다. 높은 안정성 때문에 다른 데이터베이스 옵션 대신 선택했습니다.

• MySQL을 사용한 이유는? MySQL은 사용하기 쉽고 직관적인 인터페이스를 제공하고 팀원들이 많이 사용해보았기에 선호도가 높았습니다.
  

Kafka

Kafka의 정의는?

• Kafka는 분산형 스트리밍 플랫폼으로, 대규모 데이터를 안정적으로 처리하는데 사용됩니다. 카프카는 서버와 서버 사이를 중개하는 메시지 큐 역할을 합니다.

  Kafka와 같이 실행되는 zookeeper에 대해 알고 있는가?

• Zookeeper은 Kafka 브로커들의 상태 관리, 클러스터 메타데이터 저장, 클러스터 내 노드 간 동기화 유지, 파티션의 리더 선출 및 재선출, 시스템의 고가용성 보장, 그리고 트랜잭션 상태 관리 등의 역활을 합니다.
  이를 통해 Kafka 클러스터는 안정적이고 효율적으로 운영됩니다

  Kafka를 통해 Producer로 응답을 다시 받는 구조는 일반적이지 않아(비효율적으로?) 보이는데 그렇게 한 이유는?

• 서버 부하를 줄이려는 관점에서 Kafka를 도입하여 책나눔 기능을 다른 서버로 분리하였으나, 성공여부를 응답으로 받아야 하는 책나눔 서비스에는 Kafka를 사용하는 것이 적합하지 않음을 프로젝트 후반부에 알게 되었습니다. 문제를 인지하고 있으나 수정은 하지 못한 상태입니다.(??)

  Kafka 말고 다른 메시징 시스템은 고려해보았는가?

• RabbitMQ, ActiveMQ등 다른 메시지 시스템도 있으나, 대규모 데이터 처리에 있어 가장 유리한 Kafka를 선택하였습니다.

Redis

DB락을 써도 동시성이 해결될 것으로 보이는데 굳이 Redis 분산락을 사용한 이유는?

• 저희 프로젝트에서는 DB락을 사용해도 문제가 없으나, 추후 분산 DB로의 확장까지 고려하여 Redis분산락을 사용하기로 결정하였습니다.

  Redis 말고 다른 분산락 방법들도 있는데 고려해보았나?

• zookeeper로도 분산락을 걸 수 있는데 in-memory 방식인 Redis가 속도가 더 빨라 적합하다 생각하였습니다.

AWS 인프라

• AWS RDS AWS를 사용한 이유는 현재 저희 프로젝트가 이미 AWS를 사용하고 있는 환경이기 때문입니다.
  AWS를 사용하고 있는 환경에서 RDS를 도입하면 인프라 관리의 복잡성을 줄이고 개발에 더 많은 자원을 할당할 수 있기에 선택했습니다.
  • RDS를 도입하면 인프라 관리의 복잡성이 왜 줄어드는지 RDS는 데이터베이스 업그레이드, 백업, 모니터링 같은 관리 작업을 AWS가 자동으로 처리해주며, DB의 수평, 수직적 확장도 용이하다는 장점이 있습니다. 이러한 이유로 개발자는 DB를 쉽게 관리하고 안정성이 높은 환경에서 사용할 수 있습니다.
    
• AWS Loadbalancer AWS ACM의 인증서를 통한 SSL/TLS 암호화를 통해 보안이 강화된 Https 통신이 가능합니다. 또한 웹서비스로 들어오는 트래픽을 여러 서버에 분산시켜 단일 서버에 과부하 걸리는 것을 방지하기에 선택하였습니다.
  • ACM의 인증서를 왜 사용했는지 ACM 인증서 AWS 생태계 내에서 진행 되기에 다른 AWS 서비스와의 통합이 쉽습니다. 이는 AWS 생태계를 사용할 때 ACM을 사용하는 것은 충분한 메리트가 있다고 생각합니다.
    
  • HTTPS 통신이 어떻게 동작하나요? 사용자가 특정 도메인에 요청을 보내면 DNS서버 혹은 ISP에서 해당 도메인에 대한 IP 주소(Route 53)로 전달하고, Route53은 이 요청을 AWS Load Balancer의 IP주소로 보냅니다. 이 때 사용자의 요청이 HTTP이면 HTTP요청을 HTTPS로 리디렉션합니다. 만약 HTTPS 요청으로 리디렉션하거나 원래의 요청이 HTTPS였다면 이 후 통신은 ACM에서 제공하는 SSL/TLS 인증서를 이용해서 암호화 합니다. 이를 통해 데이터의 기밀성과 무결성을 보장합니다. 그 후 LoadBalanser에서 요청을 연결된 백엔드 서버중 하나로 분산 시킵니다. 서버 요청 처리한 이후 응답은 Loadbalancer을 통해 암호화 되어 사용자에게 전달됩니다.
    
  • Loadbalancer가 어떻게 동작하는지? 만약 LoadBalancer가 HTTPS 통신을 설정해 놓았다면 사용자의 요청을 받았을때 요청이 HTTP이면 HTTP요청을 HTTPS로 리디렉션합니다. 만약 HTTPS 요청으로 리디렉션하거나 원래의 요청이 HTTPS였다면 이 후 통신은 ACM에서 제공하는 SSL/TLS 인증서를 이용해서 암호화 합니다. 이를 통해 데이터의 기밀성과 무결성을 보장합니다. 그 후 LoadBalanser에서 요청을 연결된 백엔드 서버중 하나로 분산 시킵니다. 서버 요청 처리한 이후 응답은 Loadbalancer을 통해 암호화 되어 사용자에게 전달됩니다.
    
• AWS S3 AWS S3를 선택하면 데이터 저장소로서의 안정성과 뛰어난 호환성을 확보할 수 있습니다.
  AWS의 다른 서비스들과의 높은 통합성은 데이터 관리 및 전송을 간소화해줍니다.
  
• AWS CodeDeploy AWS CodeDeploy를 사용하면 기존 AWS 인프라와의 원활한 통합을 통해 지속적인 배포와 자동화된 배포 프로세스를 실현할 수 있습니다.
  이는 배포 작업의 신뢰성을 향상시키고 운영 효율을 증대시킵니다.
• AWS EC2 AWS EC2는 확장성, 유연성, 높은 통합성, 엄격한 보안 기준, 안정성, 그리고 다양한 비용 절감 옵션을 제공함으로써 AWS 생태계 내 시스템 구축에 있어 핵심적인 컴퓨팅 리소스를 제공합니다.