밤낮개발

Kafka 메시지 브로커 활용기 - 1

Nickolodeon — Tue, 3 Dec 2024 09:04:39 +0900

개요

A 사에서 진행하는 x 프로젝트에서는 기존에 A 사에 구축된 시스템과 연동을 통해 데이터를 받아오는 로직이 존재했었다. 새롭게 A 사에서 수주한 y 프로젝트는 x 프로젝트가 받아오는 데이터가 필요했으나, x 프로젝트와 같이 A 사 시스템과의 연동은 보안 문제로 허용되지 않는 상황이었다. 결국 x 프로젝트에서 A 사와 연동해 가져온 데이터를 y 프로젝트 쪽 DB로 넘겨주는 방안이 필요했고, 이를 위해 메시지 브로커인 Kafka를 사용하게 되었다.

내용

앞에서 설명했듯이, 나는 데이터를 주고받는 중계자의 역할로서 Kafka를 활용하게 되었다. API 가 아닌 외부 브로커인 Kafka를 사용했던 이유는 데이터 송수신 간 아래와 같은 장점이 있기 때문이었다:

Kafka를 사용하는 애플리케이션 인스턴스가 오류로 인해 중지되어도, 인덱스를 이용해 마지막까지 읽어 들인 데이터부터 다시 수신할 수 있다.
Polling 방식으로 데이터를 읽어 들이므로, 실시간으로 데이터의 변동 사항을 반영할 수 있다.

위와 같은 이유로, DB 쿼리에의 의존성 및 서버에의 부하를 감소시키는 방향으로 진행이 가능했다.

구축 방식을 살펴보기 이전에, 먼저 Kafka의 기본 개념들을 살펴보도록 하자.

특징

비동기 메시지 처리
Topic에 대해 Sub / Pub으로 메시지 주고받음

구성

Zookeeper
- Kafka 내의 메시지 큐 메타데이터 관리용
- KRaft를 지원하는 버전 (KIP-500, 2019.08.01부터) 은 자체 클러스터 내에서 메타데이터를 관리하므로 Zookeeper 를 사용하지 않음
Kafka Cluster

Kafka Server (Broker)
- 여러 개 구동 가능

Partition
- Log (각 Partition 도 여러 Log로 나누어진다)
  - Key
  - Value
  - Timestamp

Facts

Producer는 순차적으로 Topic에 맞게 (Queue) 메시지를 Partition에 쌓는다. 이때, Partition 이 여러 개인 경우 Round-Robin 방식으로 쌓는다.
Comsumer Group과 Topic 은 1 : 1 관계이다. (단방향)
Topic과 Consumer Group 은 1 : N 관계이다. (단방향)
Consumer 인스턴스 : offset을 Partition과 공유한다.
즉 Consumer Group 내에서 Consumer 인스턴스는 한 번에 하나의 Partition 만 접근할 수 있다. (Partition : Consumer Instance = 1 : 1 (단방향))
Partition의 개수가 많을수록 병렬 처리의 이점이 있으나 단점도 존재한다. 바로 Partition 은 한 번 개수를 늘리면 줄이는 것이 불가능하다는 점이다.
Partition 중 Leader와 Follower를 설정할 수 있으며, Follower는 Leader를 복제하며 Leader와 다른 브로커에 존재한다. Leader 가 다운되었을 때를 대비해서 In-Sync Replica를 만드는 것이다.

정해야 할 것들

Topic
Partition 개수
Consumer 개수
보존 기간
메시지 보존 기간은 log.retention.hours의 값에 따라 정할 수 있다. (기본값 = 7일)

장점

여러 개의 Consumer를 고려한 설계 덕분에 소비가 효율적으로 이뤄진다.
매번 찾아서 메시지 pull 하는 게 아니라 offset을 활용, 이전에 consumer 가 공유해 준 정보를 통해 움직인다. (캐싱 같이?)

단점

데이터 유무에 관련 없이 정기적으로 polling 한다.
그러나 데이터가 도착할 때까지 대기하는 long poll 방식을 쓸 수 있게 하는 parameter 가 있다.

지금까지 카프카에 대해서 간략하게 알아보았다.

이제 2부에서는 카프카를 실제로 어떻게 스프링에서 적용할 수 있는지 알아보겠다.

FCM (Firebase Cloud Messaging) 사용기 - 1

Nickolodeon — Tue, 1 Oct 2024 00:52:22 +0900

FCM 이란?

Firebase Cloud Messaging 의 줄임말로, 메시징 기능을 클라우드 서버에서 제공해주는 구글의 서비스이다.

개요

프로젝트를 하는 도중에 FCM 을 사용해 볼 수 있는 기회가 생겼다. 용도는 특정 알림 기능을 모바일 단말에 푸시로 전달하는 것이었다. 기존에 구현되어 있는 기능이었으나, 최근에 FCM Legacy API 가 만료됨에 따라 V1 으로 마이그레이션하는 작업을 하게 되었다.

FCM 동작 플로우

프로젝트 생성

먼저 FCM 은 위에서 언급한대로 클라우드 서버에서 기능을 제공하기 때문에, 어떤 프로젝트 하위에서 푸시를 주고받을 건지 정해야 한다. 그래서 프로젝트를 생성하면 아래와 같은 페이지로 관리가 가능하다:

이름들은 가렸지만, 클라우드 메시징을 관리하는 페이지임을 확인할 수 있다.

관리자 페이지는 프로젝트별로 생성이 되고, 프로젝트 정보는 아래 항목들을 포함한다:

프로젝트 이름
프로젝트 ID
프로젝트 번호
Web API 키

private key 생성

이후 좌측 네비게이션 바에 있는 Project Overview 항목 오른쪽의 톱니바퀴를 누르면, Project settings 메뉴를 확인할 수 있다. Service accounts 탭에 Generate new private key 버튼을 누르면 FCM 을 사용하기 위한 인증에 필요한 key 를 생성할 수 있다.

단말 토큰 생성

private key 가 푸시 자체를 보내기 위한 인증에 필요하다면, 각 단말이 FCM 을 사용하는지 여부는 단말 토큰을 통해 인증하게 된다. 이 토큰은 각 단말을 분별하는 데에 사용된다. 최초에 앱을 설치할 때 생성되며, 나의 경우 RDB 에 저장해두고 관리하고 있었다.

Spring 에서 FCM 활용하기

의존성 라이브러리 추가

다른 모든 기능과 마찬가지로, 빌드 시에 관련 라이브러리에 대한 의존성을 갖고 있어야 Spring 어플리케이션 내에서 FCM 을 사용할 수 있다. 아래는 Maven 으로 빌드된 프로젝트에서 의존성을 추가하는 방법이다:

<dependency>
    <groupId>com.google.firebase</groupId>
    <artifactId>firebase-admin</artifactId>
    <version>9.3.0</version>
</dependency>

firebase-admin 은 SDK 형태로 만들어져서 코드로 구현 시 FCM 의 기능들을 편리하게 사용할 수 있게 도와준다.

아래는 firebase-admin 라이브러리를 활용한 코드의 예시이다:

package framework.config;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;

import javax.annotation.PostConstruct;
import java.io.FileInputStream;
import java.io.IOException;

/**
 * @deprecated Firebase Admin SDK 방식은 아직 적용되지 않았으므로
 * 우선은 {@link api.presence.bo.service.PushNotificationServiceImpl} 활욯.
 */
@Deprecated
@Configuration
public class FirebaseConfig {

    @Value("#{config['firebase.admin.sdk.key.name']}")
    private String FIREBASE_KEY_NAME;

    @PostConstruct
    public void initFirebase() throws IOException {
        Resource resource = new ClassPathResource("/" + FIREBASE_KEY_NAME);
        FileInputStream stream = new FileInputStream(resource.getFile());;
        try {
            GoogleCredentials googleCredentials = GoogleCredentials.fromStream(stream);
            FirebaseOptions options = new FirebaseOptions.Builder()
                    .setCredentials(googleCredentials)
                    .build();
            FirebaseApp.initializeApp(options);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            stream.close();
        }
    }
}

위와 같이, 단순히 클래스들을 import 하여 연관된 메서드들을 호출하는 것만으로도 FCM 사용이 가능하다.

다음 글에서는 이렇게 세팅된 FCM 을 통해 구체적으로 어떻게 푸시 메시지를 주고 받을 수 있는지 알아보겠다.

레디스 활용기 - 2

Nickolodeon — Mon, 8 Jul 2024 22:50:14 +0900

새로운 프로세스 구현하기

앞서 레디스 활용기 - 1 는 어떻게 레디스를 활용하기로 결정하게 되었는지에 대한 내용이었다면, 이번에는 그 구체적인 구현 방식을 소개해 보고자 한다.

레디스의 특징

구현을 하기 위해 학습해야 했던 레디스 (Redis) 의 몇몇 특징은 다음과 같다:

레디스는 key-value 형태로 데이터를 저장한다.
value 는 hkey-value 형태 또는 그냥 문자열이다.
key 가 문자열인 데에 반해, hkey 는 해시 값으로 인식된다.
여러 명령어를 통해 key / hkey / value 를 다룰 수 있다. 몇 가지 자주 사용되는 명령어들은 아래와 같다:
- get {key 이름} : key-value(문자열) 인 경우에 {key 이름} 에 해당하는 value 를 반환한다.
- hget {key 이름} {field(hkey) 이름} : key-value(해시) 인 경우에 {key 이름} 과 {field(hkey) 이름} 에 해당하는 value 를 반환한다.
- keys {key 이름} : 이름에 {key 이름} 을 포함하는 key 들을 모두 반환한다. {key 이름} 이 asterisk (*) 인 경우에는 모든 key 들을 반환한다.
- hgetall {key 이름} : {key 이름} key 에 row 로 등록된 field(hkey) 들과 valule 들을 모두 반환한다.
- set {key 이름} {value 이름} : {key 이름} key 에 {value 이름} value 를 저장한다.

레디스가 적합했던 이유

레디스 활용기 - 1 에서도 확인했던 것처럼, 현재 방문자 출입기록 테이블에 들어가야 할 데이터는 로그 테이블에서 재조합이 필요했다. 이는 소스 상에서 로그 테이블 엔티티의 도메인 클래스 객체 A를 우선 조회한 후, A가 갖고 있는 데이터로 방문자 출입기록 테이블 엔티티의 도메인 클래스 객체 B를 생성하여 테이블에 추가함으로써 가능했다.

이러한 방식은 불필요하게 많고 복잡한 RDB 조회가 발생하고, 주기적으로 도는 스케줄러에 대한 의존성이 크다는 점에서 프로그램 성능을 떨어트린다. 레디스 (Redis) 를 사용하면 빠른 읽기/쓰기가 가능하므로,

IoT 기기에서 수신된 데이터로 위 설명에서의 B 객체를 생성한 후,
실시간으로 레디스에 쓸 수 있게 된다.

변경된 방식

스프링에서는 RedisTemplate 를 사용하면 쉽게 레디스를 다룰 수 있다.

구현 동안에는 Redis Desktop Manager 를 사용하여 로컬 레디스의 상태를 확인하며 진행할 수 있었다.

Redis Desktop Manager 설치 방법

레디스가 활용될 프로세스는 아래와 같다:

IoT 기기에서 데이터가 수신될 때마다, 아래 중 한 가지를 수행한다:
1. 하루를 기준으로 방문자 출입기록 관련 데이터 수신이 최초인 경우, 레디스에 새로운 key 를 생성한다.
2. 이미 하루 중에 방문자 출입기록 관련 데이터 수신을 했던 경우, 생성되어 있을 key 의 value 를 수정한다.
  - 이 때 이미 하루 중에 데이터 수신이 되었는지의 여부는 TTL 이 당일이 끝나는 시간까지로 설정되어 있는 다른 key 를 조회하여 확인한다.
하루가 끝나는 자정에 방문자 출입기록 관련 데이터 value 를 추출하여 RDB 에 저장한다.
- 스케줄러로 구현한다.

방문자 출입기록 관련 key - value 쌍에서 value 에 해당하는 데이터는 다음과 같다:

각 방문자 타입 별 방문 횟수
- 방문자 타입은 소스 상 로직에서 판단한 후 프로세스 1-2 에서 타입에 맞는 데이터 값 + 1 을 해주었다.
전체 방문자 방문 횟수 총계
- 프로세스 1-2 에서 value 수정 시 총계에 해당하는 데이터는 단순 + 1 을 해주었다.

배운 점

레디스에서 hkey 로 등록된 데이터는 key-hkey-value 형태로 이뤄져 있으며, hkey-value 가 비어 있을 시 TTL 설정이 불가능하다. 그래서 구현 당시에 hkey-value 를 임의로 설정해준 뒤에, TTL 을 설정하고, 이후 다른 hkey-value 쌍이 추가로 저장된 이후에 임의 hkey-value 쌍을 삭제하는 방식으로 진행해야 했다.
짧은 시간 안에 많은 데이터를 다루어야 하는 상황에선, 레디스가 매우 유용하다. 그러나 소스 상 로직에서도 분명 데이터 누락을 잘 확인해주어야 한다. 구현 당시에는 방문자 10명 정도가 약 1~2초 이내에 방문하는 상황에서는 1명이나 2명에 대한 카운트가 누락되는 경우가 있었다. 그래서 for 문 내에서 방문자 데이터를 레디스에 쓰는 로직이 정상적으로 수행되기 전까지 다른 로직이 수행되지 못하게 반복하도록 구현하여 해결해야 했다.

결론

RDB 만 쓰다가 처음으로 NoSQL 기반의 데이터베이스를 사용했는데, 확실히 단순한 질의 방식이나 빠른 읽기/쓰기가 쉬운 사용성을 보장한다는 점에서 큰 강점을 가졌다는 것을 느낄 수 있는 경험이었다.

레디스 활용기 - 1

Nickolodeon — Tue, 28 May 2024 22:30:20 +0900

개요

현재 사물 또는 사람에게 부착된 IoT 기기로부터 BLE 신호 형태로 수신되어 정제된 데이터를 RDB 에 쓰고, 다시 읽어서 상태 (위치 등) 를 모니터링 할 수 있는 소프트웨어 개발 및 운영에 참여하고 있는 중이다.

사업은 병원들을 위주로 전개하고 있으며, 각 클라이언트마다 서로 다른 요구사항들을 갖고 있다.

약 3년 전 이 모니터링 소프트웨어를 설치하여 지금까지 개발 및 유지보수를 해주고 있는 Y 병원에서 한 달 전쯤 이슈제기를 해왔다:

방문자 출입기록과 로그 데이터가 일치하지가 않습니다!

방문자 출입기록은 말 그대로 병원에 각기 다른 목적으로 방문하는 다양한 사람들의 현황을 IoT 기기 (Y 병원에서는 스마트폰 앱) 를 이용하여 파악하고 정리한 기록이다. 회사에서 개발 중인 모니터링 소프트웨어에는 IoT 기기로부터 신호를 받을 때 이미 이 IoT 기기를 사용하는 사람의 프로필을 알 수 있다. 그리고 수신된 정보를 잘 정리해서 기록해놓는다. 모든 사람에 대해 출입 유형을 분석하고 내용을 재구성해서 DB 에 써넣는다.

그런데, 프로세스에 무엇인가 문제가 있었다는 이야기였다.

기존 프로세스의 문제점

기존 프로세스는 아래와 같았다:

먼저 로그 테이블에 넣고, 하루에 두 번씩 방문자 출입기록 테이블로 옮긴다.

위 그림에서 하루 두 번씩 스케줄러가 돌면서 로그 테이블에 있는 데이터를 재조합해 방문자 출입기록 테이블에 넣는 형태였다. 데이터를 재조합하는 쿼리는 꽤 복잡했는데, 테이블들의 구조가 아래와 같은 차이와 공통점이 있었기 때문이었다:

	PK	각 컬럼이 나타내는 것	유니크 키	특징
로그 테이블	로그 번호	로그의 다양한 정보	로그 등록 날짜 / 시간	각 row 가 단일 정보를 담음
방문자 출입기록 테이블	로그 번호	방문자 종류 별 카운트	통계, 로그 등록 날짜 / 시간	각 row 가 여러 정보의 통계임

즉, 로그 테이블에서는 데이터의 통계를 내서 방문자 출입기록 테이블로 insert 해야 하는 상황이었고, 이슈가 발생한 시점에는 1억 6천만 건의 데이터가 저장되어 있었다. 통계 쿼리 수행에는 383.437 초 = 약 6분이 걸리고 있었는데, 이는 다른 스케줄러가 돌기 시작할 때까지의 간격 이상의 시간이 쿼리에 소요되고 있었다는 의미였다.

변경된 프로세스

처음에는 쿼리를 튜닝하고자 했는데, 이미 인덱스도 걸려 있었고 통계를 내기 위해 반드시 수행되어야 하는 로직으로만 구성되어 있는 것을 확인하고서 다른 방법을 고민해보게 되었다. 먼저 떠오른 방법은 간단했다. 바로 IoT 기기에서 신호가 들어오면 로그 테이블에 쌓은 뒤 방문자 출입기록 테이블에 넣지 않고, 바로 방문자 출입기록 테이블에 기록하도록 하는 것이었다. 이 때 몇 가지 걸리는 것이 있었다:

첫째, 신호 수신 시 곧바로 어떤 종류의 방문자인지 알 수 있는가?
둘째, 몇 초 단위로 신호를 받는데, 다른 로직에 영향 없이 수신된 데이터를 RDB 에 쓰는 로직을 추가할 수 있는가?

회사 동료 분들과 이 두가지 문제에 대해 상의했고, 내린 결론은 아래와 같았다:

첫째, 신호 수신에는 대상의 카테고리 정보 등 신호에 대한 정보들이 포함된다. 여기서 대상의 카테고리 정보가 방문자 종류와 같은 데이터이다.
둘째, 수초 단위로 RDB 에 쓰는 로직은 부하가 심할 수 있으므로, 쓰기/읽기가 빠른 NoSQL 기반 데이터 저장소인 레디스를 활용하면 된다.

다음 포스팅에서는 결론으로 도출된 해결 방법들을 구체적으로 어떻게 구현했는지 소개하도록 하겠다.

@@sql_mode 변경 방법

Nickolodeon — Thu, 23 May 2024 18:41:22 +0900

...which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

위 에러가 발생해서, 확인해보니 full_group_by 옵션이 켜져 있어 group by 절에 없는 컬럼은 어느 부분에 표시해야 할 지 정하지 못해서 발생하는 문제라고 한다.

full_group_by 옵션을 끄기 위해, 구글링을 해봤다.

먼저 아래 쿼리로 full_group_by 옵션이 설정되어 있는지 확인했다:

쿼리: select @@sql_mode;
결과 (@@sql_mode 컬럼의 값):
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

이후, 이를 끄기 위해 windows 내의 mysql 관련 config 설정 파일인 my.ini 를 찾아봤는데, 도저히 찾을 수가 없었다.

다음 위치에 있다고 하는데...

C:\Program Files\MySQL\MySQL Server 8.0

아무리 봐도 없었다.

다른 방법을 찾아보려고 같은 팀 동료분께 문의드렸는데, chatGPT 로 금방 찾아주셨다. 아래 쿼리로 가능하다고 한다.

SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

기존의 @@sql_mode 를 ONLY_FULL_GROUP_BY 를 제외한 나머지로 재설정하는 방식이다.

결과는 실패...

알고보니 잘못된 위치에서 my.ini 파일을 찾고 있었다.

Program Files 가 아니라 ProgramData 였다

아래 위치에서 my.ini 을 발견하였다.

C:\ProgramData\MySQL\MySQL Server 8.0

my.ini 내에 다음 한 줄을 추가해주었다.

sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

이후 windows > 시스템 > 서비스에서 MySQL 서비스를 찾아 다시 시작 해주었다.

오류 해결 완료.

[Spring] Controller 메서드 파라미터에 어노테이션이 안 붙어있을 때

Nickolodeon — Fri, 10 Nov 2023 11:17:41 +0900

기본적으로 String, Long 타입은 @RequestParam 을 붙였을 때와 같이,
이외의 클래스 객체는 @ModelAttribute 를 붙였을 때와 같이 동작합니다.

[기술면접] General Interview Questions

Nickolodeon — Wed, 11 Oct 2023 23:38:09 +0900

1. 컴포넌트와 모듈의 차이

① 컴포넌트: 런타임 개체 단위
② 모듈: 실질적으로 구현이 된 단위

※ 서버 / 클라이언트 구조에서 서버 1개 · 클라이언트 100개라면?
→ 모듈: 서버 1 + 클라이언트 1 = 2개 → 컴포넌트: 서버 1 + 클라이언트 100 = 101개

2. 자바란?

"Write once, Run anywhere" 라는 특성의 객체지향 언어

3. 자바의 구동원리

① 컴파일러가 코드를 검증하고 JVM이 읽는 바이트 코드 (.class) 로 변환한다.
② JVM 으로 바이트 코드를 가져온다.
③ 바이트 코드가 올바른지 검증한다.
④ 인터프리트한다.
⑤ 바이트 코드를 바이너리 코드로 변경하고 JVM 의 클래스 영역에 저장한다.
⑥ 런타임 과정에서 클래스들의 static 변수를 자동으로 초기화한다.
⑦ static 블록을 수행한다.
⑧ 인스턴스 블록을 수행한다.
⑨ 생성자를 호출한다.
⑩ main 함수를 호출한다.

4. JVM 의 특징

▷ 스택 기반의 가상 머신이다.
▷ GC (Garbage Collector) 가 동작한다.
▷ 플랫폼에 독립적으로 작동한다.

5. 객체 지향과 절차 지향의 차이점

◎ 절차 지향 프로그래밍 ▶ 루틴, 서브루틴, 함수 (프로시저) 등을 이용해 프로그래밍하는 것
◎ 객체 지향 프로그래밍 ▶ 프로그램을 데이터 \ 처리방법 으로 나누지 않고 객체 내에 데이터와 처리방법 (동작) 을 모두 담아 객체 간의 상호작용으로 서술하는 것 ▶캡슐화, 상속, 다형성, 추상화와 같은 특징을 가짐

6. 객체 지향 언어의 특징

◈ 캡슐화:객체의 속성과 행위를 하나로 묶고 실제 구현 내용의 일부는 외부에 감추는 것
◈ 상속: 새 클래스가 기존 클래스의 자료 및 연산을 사용할 수 있는게 하는 것
◈ 다형성: 하나의 요소에 여러 개념을 넣은 것 (오버라이딩, 오버로딩)
◈ 추상화: 공통되는 속성이나 기능을 묶어서 이름을 붙이는 것

7. 상속과 구현의 차이점과 특징 및 장단점

상속은 is-a, 구현은 can-do
장점 ☞ 코드의 중복을 줄일 수 있다; 확장성이 증가한다; 하나의 인터페이스와 여러 구현체로 다형성을 구현 가능하다.
단점 ☞ 다중상속 시 복잡도가 증가한다.

8. 오버라이딩과 오버로딩

오버라이딩? 상속하는 부모 클래스의 함수를 재정의하는 것, 함수 이름 / 매개변수 / 반환형이 동일하다.
오버로딩? 함수 이름 외의 다른 요소들을 재정의한다.

9. 기본형 변수와 참조형 변수

기본형 ≫ Stack 영역에 값이 저장되는 변수
e.g. byte, short, int, long, float, double, boolean, char
참조형 ≫ Heap 영역에 저장되고, Stack 에 저장되는 주소값에 의해 참조되는 변수
e.g. Integer, Long, Double, Character, String

10. 스택 오버플로우의 원인

스택 포인터가 스택의 경계를 넘는 것이 원인
왜? 상당히 깊은 / 무한 루프 (예) 탈출 조건이 없는 재귀 함수)

11. 메모리 누수란?

프로세스가 메모리 할당을 한 후 해제하지 않으면 발생한다.
프로세스를 장기간 동작시키는 경우에 메모리 누수의 위험이 있다.
막기 위해서는 프로세스가 끝날 때 메모리가 할당된 변수를 제거하면 된다.

12. static 이란?

절차 지향과 객체 지향으로 나누어 생각할 수 있다.
㉮ 절차 지향: 지역변수 · 전역변수; 함수 내에서만 사용가능 (지역 변수) 함수 종료 시까지 메모리에서 해제되지 않음 (전역 변수)
㉯ 객체 지향: 클래스 멤버; 클래스 내에 선언이 되면 클래스 관련 모든 인스턴스가 사용 가능한 객체이다.

13. 싱글턴 패턴이란?

인스턴스를 한 번만 생성하고 계속 재사용하는 패턴

14. 전략 패턴?

스트래티지 패턴(Strategy pattern)이라고도 하며, 교환 가능한 행동을 캡슐화하고 위임을 해 행동을 다르게 하는 패턴
e.g. '운송 전략' 이라는 인터페이스를 생성하고 서로 다른 전략을 클래스로 구현한 후, 버스나 기차와 같은 운송 수단이 전략을 매개 변수로 변경할 수 있도록 한다. 버스나 기차의 내부 구현 방식은 한 메서드의 매개 변수로 주어지는 전략에 따라 행동을 변경하는 방식으로 되어 있다.

15. 익명 클래스와 익명 객체

익명 클래스 → 인스턴스를 생성함과 동시에 클래스를 선언한다; 일회성, 유일의 객체

16. 스레드란? 스레드가 사용되는 때

프로세스 내에서 실제로 작업을 수행하는 주체
하나 이상의 프로세스가 있을 때 멀티 스레드

17. 여러 번 Join 하기 vs 역정규화

데이터가 500만개만 되도 join 을 여러 번 하는 것은 시간이 많이 걸린다. 정규화되지 않은 DB 라도 foreign key 를 이용해 데이터를 바로 참조할 수 있도록 설계하는 것을 선호하기도 한다.

18. 쿼리 실행 계획

explain 키워드를 사용한다.
id, type, key 등의 컬럼의 값을 확인하여 쿼리가 어떻게 실행될지 판단할 수 있다.

19. 서브 쿼리 순서

서브 쿼리 → 메인 쿼리
장점: 쿼리의 각 부분을 명확히 구분할 수 있다; 복잡한 JOIN 을 대체할 수 있다; 복잡한 JOIN에 비해 가독성이 뛰어나다.

20. lazy loading

당장에 필요하지 않은 리소스를 추후에 로딩하는 것

21. Spring을 사용함에 있어서 가장 핵심적인 이유는?

Spring 의 IOC, 즉 제어의 역전은, 개발자가 관리하던 객체의 생성부터 소멸까지의 생명주기를 스프링 빈을 통해 프레임워크가 관리한다는 의미이다. Spring 은 개발 외의 구성을 신경 쓰지 않고 오롯이 코드 작성에 집중할 수 있게 해준다.
▷ 스프링은 POJO 기반의 프레임워크이므로, 객체 지향적 설계를 하는 데에 용이하며, 개발자의 생산성을 높여준다.

22. Java 컴파일 과정을 설명하시요

Java 는 컴파일러에 의해 바이트 코드 (.class) 로 변환된다. 바이트 코드를 JVM 이 읽고 바이너리 코드로 변환한 후 클래스 영역에 저장한다. execution engine 이 바이너리 코드를 읽고 실행시킨다.
▷ 1. 컴파일러가 코드를 검증한 후 바이트 코드 (.class) 로 변환한다.
▷ 2. 컴파일러가 바이트 코드를 검증한다.
▷ 3. 인터프리트
▷ 4. 바이트 코드를 바이너리 코드로 변환하고 JVM 의 클래스 영역에 저장한다.
▷ 5. 런타임 과정에서 static 변수들을 초기화한다.

23. Array와 Linked List의 차이점을 설명하시고 시간복잡도 순으로 설명하시요

Array는 값을 단순히 나열한 자료 구조로 삽입, 조회, 삭제 모두 O(n) 의 시간 복잡도를 가진다.
LinkedList는 노드로 구성되어 각 노드가 앞뒤 노드의 정보를 알고 있는 노드끼리 연결된 형태의 자료구조이다. 그래서 단순히 삽입과 삭제에 앞뒤 노드가 참조하는 모양을 바꾸면 되기 때문에 O(1)이 걸리고 최악의 경우 O(n)이 걸린다. 조회도 O(1) 이 걸리지만 최악의 경우 O(n) 이 걸린다.

24. TCP/UDP의 통신 방식 차이점

TCP 는 연결 지향적인 프로토콜로, 서버와 클라이언트 간 통신을 위한 연결을 맺을 때 3-way handshake, 끊을 때 4-way handshake 를 사용해 안전하게 연결한다. 보안성이 높지만 속도가 느리다는 단점이 있다.
UDP 는 서버의 상태에 상관 없이 계속해서 연결 요청을 보낸다. 그래서 연결이 보장되지는 않지만 통신의 속도는 빠르다는 장점이 있다.

25. HTTP/HTTPS의 정의와 차이점

HTTP 는 서버 클라이언트 간 네트워크 통신 프로토콜이다. 80 포트를 사용한다.
HTTPS 는 HTTP 에 데이터 암호화를 추가한 프로토콜이다. 443 포트를 사용한다.

26. DB의 ACID 요소 설명

A: Atomicity, 원자성으로 트랜잭션은 오직 완전히 성공하거나 완전히 실패하기만 한다는 특성이다.
C: Consistency, 일관성으로 트랜잭션 전후로 데이터의 모순이 존재하지 않는다는 특성이다.
I: Isolation, 독립성으로 트랜잭션은 한번에 하나만 존재할 수 있다는 특성이다.
D: Durability, 지속성으로 모든 트랜잭션은 (rollback 포함) 영원히 남는다는 특성이다.

27. DB의 Transaction이란?

트랜잭션은 DB 에 수행하는 작업의 단위이다.

28. 조인이란?

2 개 이상의 테이블 레코드들을 하나로 엮어서 하나의 열로 보고 싶을 때 사용하는 쿼리문이다.

29. SQL vs NoSQL

SQL은 정형화된, 스키마가 있는 중복이 없고 관계가 있는 데이터베이스 → 수직적 확장만 가능
NoSQL은 비정형화된, 스키마가 없고 중복이 있으며 관계도 없는 데이터베이스 → 수평적, 수직적 확장 모두 가능

30. 이상 (Anomaly) 의 종류

1. 삽입 이상
2. 갱신 이상
3. 삭제 이상

31. 쿠키와 세션

Http 의 Stateless, Connectionless 한 특징을 보완할 수 있다.
쿠키는 클라이언트에 저장된다. 쿠키 만료 시간을 설정하면 브라우저가 종료되어도 상태를 유지할 수 있다. 서버에 저장되지 않기 때문에 보안에 취약하지만 속도가 빠르다.
세션은 서버에 저장된다. 브라우저가 종료되면 세션은 만료된다. 서버에 저장되어 보안성이 높지만 서버의 자원을 활용하기 때문에 서버에 부하를 줄 수 있다.

[Spring] Interview Questions for Beginner

Nickolodeon — Fri, 22 Sep 2023 07:34:03 +0900

스프링 프레임워크

핵심은 IOC (제어의 역전), DI (의존성 주입) 이다.

스프링 빈

스프링 빈의 특징

스프링 빈은 Singleton 으로 생성해 메모리나 성능 최적화에 유리하다.

IOC (제어의 역전)

객체의 제어권을 다른 대상에게 위임한 것으로, 개발자 (또는 애플리케이션 코드) 가 아닌 프레임워크가 객체의 생성부터 소멸까지 관리하게 되는 것을 말한다.

DI (의존성 주입)

한 클래스와 다른 클래스 사이의 의존 관계를 컨테이너가 빈을 가지고 자동으로 연결해주는 것을 말한다.

AOP (관점 지향 프로그래밍)

프록시 패턴 기반의 구현체를 사용한다. 중복 제거, 객체 간 복잡도 증가에 대한 해결책이 될 수 있다.

POJO

마틴 파울러는 EJB 에서 돌아서서 POJO 로 돌아와야 한다고 이야기했다. 비즈니스 로직과 특정환경을 분리시켜 객체지향적이고 단순한 코드를 짤 수 있게 해준다.

DAO 와 DTO

DAO 는 Data Access Object 로, DB 에 접근할 목적으로 사용되는 객체이다.

DTO 는 Data Transfer Object 로, 계층 간 데이터 교환을 위해 사용되는 객체이다.

Filter, Interceptor

Filter 는 WAS 단에서 Spring 과 무관한 자원을 처리하고, Interceptor 는 Spring 내에서 controller 실행 전 후에 자원을 가로채서 조작한다.

[OOP & Java & etc.] Interview Question for Beginner

Nickolodeon — Thu, 21 Sep 2023 19:26:41 +0900

객체 지향 프로그래밍

캡슐화

항상 요구 사항은 추가되거나 변경될 수 있다

1. 객체의 의인화

현실 세계와는 다르게 가상 세계에서의 객체는 능동적이다.

2. 클래스 설계

- 객체가 형태를 갖추면 비슷한 객체들끼리 타입으로 묶어 클래스를 추상화한다.

- 외부와 내부를 구분 지어야 한다. 외부와의 협력은 public 인터페이스를 통해서만 한다.

- 객체가 능동적이기 위해서는 외부로부터의 간섭을 최소화해야 한다.

3. 객체의 특징

1. 캡슐화 - 객체의 세부적인 상태는 감추고 메시지는 오직 public 인터페이스로만 주고받는다.

2. 단일 책임 - 모든 객체는 맡은 일을 외부의 도움 없이 할 수 있어야 한다.

3. 응집도 - 밀접하게 연관되어 있는 일만 수행하고 관련이 없는 일은 다른 객체에게 위임해야 한다.

훌륭한 객체는 외부와 내부의 구분이 잘 이루어져있다. 외부에서 알지 못하는 내부의 상태를 구현이라고 하고
외부에서 접근 가능한 부분을 public 인터페이스라고 한다.

함수형 프로그래밍

함수를 일급 객체로 간주한다.

MVC 아키텍처

- 모델 (Model) : 컨트롤러가 호출할 때 요청에 맞는 역할을 수행하는 영역이다. 비즈니스 로직을 수행하는 부분이다.

- 뷰 (View) : 사용자에게 보여지는 화면을 만드는 역할을 한다. 사용자와의 상호작용을 위한 인터페이스가 있는 영역이다.

- 컨트롤러 (Controller) : 일종의 조정자 또는 중재자로서, 클라이언트로부터 온 요청을 수행하는 모델 컴포넌트 (서비스 레이어) 를 호춣한다. 수행이 완료된 이후에는 뷰 (View) 로 결과를 반환한다.

Git flow vs GitHub flow vs GitLab flow

GitLab flow 의 장점: 단순하고 릴리즈와 머지 등에 발생할 수 있는 오버헤드를 줄여준다.

Integer 과 int

Wrapper Class 와 Primitive 타입

차이점

제너릭이나 Collection 에서는 Wrapper class 만 사용할 수 있다. null 이 필요하거나 비교가 필요할 때 Wrapper class 를 사용하면 유용하다.

== 와 equals() 의 차이

== 는 메모리 주소를 비교하는 것이고, equals() 는 내용을 비교하는 것이다.

Call by Value, Call by Reference

Stack 영역에 있는 변수가 수정되지 않는 것은 값만 가져오는 것이기 때문이다.

그러나 객체를 참조하고 있는 변수를 가져온 경우에는 같은 객체를 참조하기 때문에 객체도 변한다.

둘 다 Call by Reference 이다.

Garbage Collection

Garbage Collector 의 구조

Reachability 와 Unreachability

stop the world 가 있다.

young generation 과 old generation 이 있다.

eden 과 survivor 영역이 있다.

minor GC 와 full (major) GC 가 있다.

mark and sweep 으로 이루어진다.

reachable 과 unreachable 을 분리한다.

JVM

Interpreter vs JIT compiler

한 줄씩 명령어 단위로 해석해서 실행하는 인터프리터와, 모두 native code 로 변환해 캐시에 저장하여 한 번에 실행하는 컴파일러가 있다.

Stack / Heap / Method Area / PC Register

Stack: 스레드 하나당 가지고 있고, 변수들을 저장하는 스택과 Native 코드를 저장하는 스택이 있다.
Heap: 동적으로 할당되는 객체들을 저장하며, GC 가 활동하는 영역이다.
Method Area: 상수를 가지고 있는 Runtime constant pool 을 가지고 있으며, 모든 스레드가 공유하는 메모리 영역이다.
PC Register: 실행되고 있는 명령어의 주소값을 가지고 있다. 스레드마다 하나씩 부여된다.

String

string constant pool 이 존재하여 equals 메서드가 가능하게 만든다. intern() 이 실행되어서 String 을 리터럴로 생성할 때 constant pool 에 있으면 주소값을 반환하기 때문에 리터럴로 선언되면 == 가 true 를 반환하는 것이다.

인터페이스 vs 추상 클래스

인터페이스: 상수와 추상 메서드 외에는 가질 수 없다.
추상 클래스: 추상 메서드 하나만 가지고 있어도 추상 클래스이다.

[자료 구조] Interview Question for Beginner

Nickolodeon — Thu, 21 Sep 2023 19:24:06 +0900

Array

- 조회: 논리적 저장 순서 = 물리적 저장 순서 (random access O(1) 가능)

- 삭제, 삽입: 접근 O(1) + shift O(n) = O(n)

Linked List

- 조회: 논리적 저장 순서 != 물리적 저장 순서 O(n)

- 삭제, 삽입: O(n)

Stack

- LIFO or FILO

Queue

- Heap 구현하기

Stack 2개로 Queue 구현하기
하나는 입력만 받고, 다른 하나는 pop 만 하게 한 후, pop 하는 쪽이 비면 입력 받는 stack 에 원소가 있다면 pop 시켜서 가져오게끔 구현하면 된다.

Tree

- 포화 이진 트리: 모든 노드가 2개의 자식 노드를 갖는 트리

- 완전 이진 트리: 위에서 아래로, 왼쪽에서 오른쪽으로 차곡차곡 채워져 있는 트리

- 정 이진 트리: full binary tree, 모든 노드가 0개 또는 2개의 자식 노드를 갖는 트리

이진탐색트리

- 구현 시 고려할 점이 많고 까다롭다.

Heap

시간복잡도

종류	ArrayList	LinkedList	HashSet	TreeSet	HashMap	TreeMap	PriorityQueue	ConcurrentHashMap
add	O(1)	O(1)	O(1)	O(logn)	-	-	O(logn)	-
remove	O(n)	O(1)	-	-	-	-	O(logn)	-
get	O(1)	O(n)	-	-	O(1)	O(logn)	O(1)	O(1)
contains	O(n)	O(n)	O(1)	O(logn)	-	-	-	-
containsKey	-	-	-	-	O(1)	O(logn)	-	O(1)
iterator.remove	O(n)	O(1)	-	-	-	-	-	-
next	-	-	O(h/n)	O(logn)	O(h/n)	O(logn)	-	O(h/n)
size	-	-	-	-	-	-	O(1)	-

HashSet 과 HashMap

HashSet: 중복을 허용하지 않는다. 순서가 없다. equals() 와 hashcode() 메서드를 사용해 중복 여부를 체크한다.
HashMap: key 는 중복이 없지만, value 는 중복이 허용된다.