Build

• 소스 코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 일련의 과정이나 결과물이다.
  • 컴파일, 링크, Resource 등 실행에 필요한 파일을 지정된 위치로 옮기는 행위, 테스팅, JAR 혹은 WAR로의 패키징 등
  • 컴파일과 링크 등은 빌드의 여러 단계 중 한 가지에 속하는 부분 집합이다.

    Build Tool

• 상기한 빌드 프로세스를 자동으로 수행함으로써 소스 코드를 실행 가능한 어플리케이션으로 생성해주는 도구이다.
• 프로젝트 규모가 확대될수록 사용하는 라이브러리가 많아진다.
• 라이브러리를 직접 다운받아서 추가하는 등 수동 작업이 매우 번거롭고 실수가 발생하기 쉽다.
• 빌드 툴은 라이브러리를 자동으로 추가 및 관리해준다.
• 라이브러리의 버전을 자동으로 동기화하는 기능도 제공한다.
• ex) Gradle, Maven

무중단 배포

새로운 빌드 결과물을 서버의 다운타임 없이 배포하는 '무중단 배포' 전략에 대해서 살펴보겠다!

롤링 (Rolling)

• 원리
  • 서버 1을 로드 밸런서에서 뺀다.
  • 서버 1을 배포한다.
  • 서버 1을 다시 로드 밸런서에 넣는다.
  • 서버 2를 로드 밸런서에서 뺀다.
  • 서버 2에 배포한다.
  • 서버 2를 다시 로드 밸런서에 넣는다.
  • (모든 서버가 배포 완료 될 때 까지 계속 진행)
• 단점
  • 배포할 서버가 너무 많다면 n대 단위로 배포하는데, 배포가 모두 끝나기 전까지는 누구는 이전 서비스를 받고 누구는 신규 서비스를 받는 문제가 존재한다.
  • 1대에 배포하는 것 보다 최소 2배 이상 느리다.

카나리(Canary)

소수의 유저만 사용하는 환경에 신규 버전을 배포하고, 문제가 없다고 판단됐을 때 다른 모든 서버에 배포하는 방식이다. 트래픽을 분산시킬 때에는 라우팅을 랜덤하게 할 수도 있고, 사용자를 분류할 수도 있다.

• 장점
  • 위험을 빠르게 감지할 수 있다.
  • A/B 테스트가 가능하고, 성능 모니터링에 유용하다.

블루 그린 (blue green)

실제로 서비스 중인 환경(Blue)과 새롭게 배포할 환경(Green)을 세트로 준비해서 배포하는 방식이다.

• 장점
  • 새롭게 배포할 환경에만 (동시에) 배포하면 되기 때문에 배포 속도가 매우 빠르다.
  • 언제나 Green 환경이 떠있기 떄문에, 만약 잘못된 버전으로 배포한 경우 신속하게 롤백할 수 있다.
• 단점
  • Green 환경이 항상 떠있어야 하기 때문에 비용이 2배로 든다.

reference

• https://xlffm3.github.io/devops/build-deploy-ci-cd/
• https://reference-m1.tistory.com/211

Heap 영역

• 인스턴스, 배열 등을 저장
• JDK 8 부터는 Perm 영역이 사라졌다.

  Young 영역 - 마이너 GC

• 처음 객체가 생성되면, Eden 영역에 객체가 지정된다. Eden 영역이 꽉차면, GC 를 통해서 삭제되거나 살아남은 경우에는 Survivor 영역으로 옮겨진다. Survivor 영역은 2개로 나뉘어 있는데, 둘 중 하나는 반드시 비어 있어야 한다. 이런 작업을 반복하다가 Old 영역으로 이동하게 된다. (단, Young 영역에서 바로 Old 영역으로 이동하는 경우도 있는데, 객체의 크기가 아주 커서 Survivor 영역 보다 큰 경우다.) 이렇게 Young 영역에서 발생하는 GC를 마이너 GC 라고 한다.

  Old 영역 - 메이저 GC

• Old 영역이나 Perm 영역에서 발생하는 GC 를 메이저 GC 라고 한다.

GC

• 하나의 객체는 메모리(힙)를 점유하는데, 필요하지 않을 때 메모리(힙)에서 객체를 해제한다.
• GC 는 메모리를 할당하고, 사용 중이거나 사용 중이지 않은 메모리를 인식하는 역할을 한다.

  OutOfMemoryError

  더 이상 사용 가능한 메모리 영역이 없는데, 계속 메모리를 할당하려고 할 때 OutOfMemoryError 이 발생하여 JVM 이 다운될 수 있다.

방식

• Serial Collector
  • Young 영역과 Old 영역을 연속적으로 처리하며, 하나의 CPU 를 사용한다.
  • 대기 시간이 많아도 크게 문제가 되지 않는 클라이언트 장비에서 주로 사용한다.
  • stop-the world
  • mark-sweep-compact : Old 영역으로 이동된 객체들 중 살아 있는 객체와 쓰레기 객체를 식별한다. 쓰레기 객체를 삭제하고, 살아 있는 객체를 한 곳으로 모은다.

    Mark-Sweep-Compact
• Parallel Collector (= Throughput Collector)
  • 다른 CPU 가 대기 상태로 남아있는 것을 최소화한다.
  • Young 영역에서는 (Serial Collector 와 달리) 병렬적으로 처리한다.
  • 많은 CPU 를 사용하기 때문에, CG 의 부하를 줄이고, 애플리케이션 처리량을 늘릴 수 있다.
  • Old 영역에서는 mark-sweep-compact 를 사용한다.
• Parallel Compacting Collector
  • 여러 CPU 를 사용하는 서버에 적합하다.
• G1 Collector
  • 바둑판 모양의 구역으로 메모리를 나누고, 각각 Eden, Survivor, Old 역할을 지정한다.

    성능

• full GC 가 실행 중일 때에는 JVM 에서 처리되지 않는다. 따라서, GC 를 많이 할수록 응답 시간에 영향을 끼치게 된다.
• 자바는 메모리를 GC 를 통해서 관리하기 때문에, 메모리 처리 로직을 굳이 만들 필요가 없다.
  • 사실, 절대로 GC 를 쓰지 않는 것을 권장한다. System.gc() 등의 메소드로

@EnableCaching
@Configuration
public class RedisCacheConfig {

    @Value("${spring.redis.cache.host}")
    private String host;

    @Value("${spring.redis.cache.port}")
    private int port;

    @Value("${spring.redis.cache.password}")
    private String password;

    @Bean
    public RedisConnectionFactory redisCacheConnectionFactory() {
        RedisStandaloneConfiguration config = new RedisStandaloneConfiguration();
        config.setHostName(host);
        config.setPort(port);
        config.setPassword(password);
        return new LettuceConnectionFactory(config);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        redisTemplate.setConnectionFactory(redisCacheConnectionFactory());
        return redisTemplate;
    }

    @Bean
    public RedisCacheConfiguration defaultRedisCacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .disableCachingNullValues()
                .entryTtl(Duration.ofHours(1L))
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));
    }

    @Bean
    public RedisCacheManagerBuilderCustomizer redisCacheManagerBuilderCustomizer() {
        return (builder) -> builder
                .withCacheConfiguration("products", defaultRedisCacheConfiguration().entryTtl(Duration.ofMinutes(30)));
    }
}

@EnableCaching

• 스프링에 AOP로 구현되어있는 캐시 로직을 사용한다.
• 스프링이 CacheManager 인터페이스를 추상화하였기 때문에 RedisCacheManager, EhCacheManager 등 필요한 CacheManage 로 갈아끼워 사용할 수 있다.

캐시 설정

• CacheManager 를 이용해서 Serializer, TTL(Time to Live), key 의 prefix 등을 디테일하게 설정할 수 있다.
• RedisCacheManagerBuilderCustomizer 를 사용하여 캐시마다 TTL 등 캐시 정책을 다르게 적용할 수 있도록 하였다.

ProductController.java

@RequestMapping("/products")
@RequiredArgsConstructor
@RestController
public class ProductController {

    private final ProductService productService;

    @Cacheable(key="#dto.start", value="products")
    @GetMapping
    public SuccessResponse getProducts(@Valid @ModelAttribute GetProductsRequest dto) {
        List<SimpleProduct> products = productService.getProducts(dto);
        return SuccessResponse.builder()
                .status(StatusEnum.OK)
                .message("상품 목록 가져오기 성공")
                .data(products)
                .build();
    }
 }

캐시 저장/삭제

• 캐시 저장
  • @Cacheable : 캐시가 있으면 캐시의 정보를 가져오고, 없으면 등록한다.
    • SpEL(Spring Expression Language) 을 지원한다.
    • @Cacheable(key="#dto.start", value="products")
      • (필자는 사용하지 않았으나) unless 라는 옵션으로 조건을 걸어줄 수 있으니 참고하기 바란다!
  • @CachePut : 무조건 캐시에 저장한다.
• 캐시 삭제
  • @CacheEvict : 캐시 데이터와 DB의 불일치성이 발생할 수 있기 때문에 캐시 데이터의 update, delete가 발생할 경우 해당 어노테이션을 적용하여 캐싱 데이터를 제거해야 한다.

@Component
@RequiredArgsConstructor
public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws UnauthorizedException {
        try {
            if (isNeedToAuth((HandlerMethod)handler)) {
                String userIdBySession = getUserIdBySession(request);
                String userIdByPath = getUserIdByPathVariable(request);
                if (!userIdBySession.equals(userIdByPath)) {
                    throw new UnauthorizedException();
                };
            }
            return true;
        } catch (Exception e) {
            throw new UnauthorizedException(e);
        }
    }
    // 기타 메소드 생략
}

@Configuration
@RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {

    @Autowired
    private AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry){
        registry.addInterceptor(authInterceptor);
    }
}

대략 @AuthRequired 어노테이션이 붙은 MethodHandler 에 로그인 세션 검증을 추가하는 인터셉터를 만들었다! 그런데 문제는 일반적으로 404 에러가 발생해야 하는 "서비스하지 않는 URL"을 요청했을 때, ResourceHttpRequestHandler 를 HandlerMethod 로 타입변환 할 수 없다는 에러가 발생한다. 별다른 설정이 없는 한, 서버 에러를 띄우게 된다!

java.lang.ClassCastException: class org.springframework.web.servlet.resource.ResourceHttpRequestHandler cannot be cast to class org.springframework.web.method.HandlerMethod (org.springframework.web.servlet.resource.ResourceHttpRequestHandler and org.springframework.web.method.HandlerMethod are in unnamed module of loader 'app')

정적 리소스 요청

스프링 2.X 프레임워크에서 정적 리소스를 요청할 때에도 인터셉터가 호출되기 때문에, 인터셉터에 전달되는 핸들러가 모두 HandlerMethod가 아닐 수 있다는 것이다!

API 로 등록되지 않은 모든 URL을 정적 리소스를 요청하는 URL 로 바꾸는 것은 성능 향상을 위해 2.X 부터 바꾼 것으로 추측해본다.

정적 리소스

• 클라이언트로부터 요청이 들어왔을 때, 요청에 대한 리소스가 이미 만들어져 있어 그대로 응답하는 경우
• html, css, js, image 등

ResourceHttpRequestHandler

• 아까 우리가 HandlerMethod 로 들어올 것이라고 예상했으나, 실제로 받았던 이 핸들러가 바로 '정적 리소스를 처리하는 핸들러' 이다!
• 브라우저가 최초로 정적리소스를 요청하는 경우에는 응답으로, 200 응답 코드에, Last-modified 헤더를 함께 보낸다.
• 브라우저는 이 정보를 기억하고 있다가, 다음 요청에서는 If-Modified-Since 헤더를 포함해서 보낸다.
  • 서버는If-Modified-Since 헤더값과 리소스의 변경 시점이 같다면
    • 304 상태코드를 응답하면서 다시 리소스를 응답하지 않는다.
  • 서버는 If-Modified-Since 헤더값과 리소스의 변경 시점이 다르다면
    • 변경된 리소스와 200 상태코드를 응답하게 되면서 브라우저는 다시 응답의 Last-Modified 헤더값을 다음 요청의 If-Modified-Since 헤더값에 포함하여 전송한다.

해결

@Configuration
@RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {

    @Autowired
    private AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry){
        registry.addInterceptor(authInterceptor)
            .addPathPatterns("/rest-api-root/**");;
    }
}

이렇게 addPathPatterns 를 이용해서, REST API 의 루트 URL 을 명시해주면, 정적 요청없이 잘 동작한다!

Reference

• https://cheolhojung.github.io/posts/java/web-mvc-static-resources.html

우리 서비스는 언젠가 전세계에서 이용 가능한 글로벌 이커머스 서비스가 될 수 있다는 가정 하에, 어떻게 설계할지 고민했다 🧐 여러 국가에서 이 서비스를 사용할 때, 발생할 수 있는 문제는 어떤 것들이 있을까?

한번, 데이터베이스에 한국시간 기준 2021-01-02 00:00:00 으로 새해 할인 이벤트 만료 시간이 저장되어있다고 생각해보자! 한국 시간 2021-01-02 00:00:01 에 한국에 있는 사용자는 이벤트를 이용할 수 없지만, 한국보다 약 13시간 느린 미국에 있는 사용자는 이미 13시간 전부터 이벤트가 만료되었을 것이다! 우리는 모든 나라의 1월 2일에 이벤트가 만료되길 바랐지만, 의도대로 동작하지 않았다...!

그렇다면, 한국시간을 기준으로 미국에서는 +13시간, 독일에서는 +7시간 등 나라마다 한국을 기준으로 계산해주어야 하는걸까..? 한국과 다른 나라의 시차를 일일이 계산해서 적용한다면, 실수하기 너무 쉬울 것 같다. 어떤 시간을 기준으로 해야 유연하고, 안전하게 시간 데이터를 관리할 수 있을까?

데이터베이스 기준 : UTC

• "국제적인 표준 시간" 이다.
• 대부분의 시간 라이브러리는 UTC를 기준으로 만들어져있다! 따라서, 여러 다른 시간대로 변환하기 매우 편리하다.
• 우리는 UTC를 기준으로 데이터를 저장하기로 결정했다!

저장 형태

• UCT 기준 yyyy-MM-dd hh:mm:ss 문자열 형태로 저장하고자 한다!
• 사람이 읽기 쉽고, 필요한 정보를 적절히 담았다.

서버 기준 : Local

• 서버에서는 JVM timezone 을 로컬 타임존으로 설정한다.
• 데이터베이스에 있는 데이터를 가져와서 사용자에게 보여줄 때에는 로컬 타임을 적용하여 변환해서 보여준다.

표현 형태

• ISO 8601 포맷 문자열을 사용하고자 한다.
• ISO 는 데이터 교환을 다루는 국제 표준 방식이다.
• 2021-08-10T17:40:00+09:00 처럼 시간 뒤에 timezone offset 이 표시되어 있기 때문에 커뮤니케이션 미스 등으로 인한 실수의 염려가 적다!
• 사람이 읽기 쉽다는 점은 당연하다!

시간 타입

Timestamp VS ZonedDateTime

• 결론 : ZonedDateTime 을 쓰는 것이 더 좋다.
• Timestamp 는 기존 java.util.Date 를 상속받았기 때문에 그것의 문제점을 그대로 안고 있다!

java.util.Date 의 문제점

• 불변 객체가 아니다.
• 상수 필드 남용
  • calendar.add(Calendar.SECOND, 2);
• 헷갈리는 월 지정
  • 1월을 0으로 표현하는 문제
• 일관성 없는 요일 상수
• Date와 Calendar 객체의 역할 분담
  • 필요한 기능을 사용하기 위해서 Calendar 객체를 생성하고 Date 객체를 생성하는 프로세스를 거치기 때문에 번거롭고 생성 비용이 비싸다.
• 기타 java.util.Date 하위 클래스의 문제

Reference

• https://d2.naver.com/helloworld/645609
• https://velog.io/@lsb156/Instant-vs-LocalDateTime
• https://jojoldu.tistory.com/361

쿠팡에는 키워드로 상품을 검색하는 기능이 있다 이 기능을 더 효율적인 쿼리로 구현하기 위해서는 어떻게 할 수 있을지 고민해보았다!

1. LIKE

쿼리

SELECT * 
FROM coupang.PRODUCT
WHERE name LIKE '%키워드%';

성능 테스트

• Execution Time
  • 2.862 sec
• Explain
  • type : ALL
    • 인덱스를 타지 못하고, full scan 하는 것을 확인할 수 있다.
  • rows : 49488572
    • 전체 로우를 검사한다.

문제점

• LIKE 에서 물티슈%와 같이, 와일드카드를 뒤쪽에 붙였을 때에는 인덱스를 잘 활용한다.
• 하지만, %물티슈, %물티슈% 와 같이% 와일드카드를 앞에 붙이면 인덱스를 활용하지 못하고, full scan 하여 성능이 매우 떨어지는 것이다.
  • mysql 버전에 따라 %물티슈 처럼 앞에만 와일드카드를 붙이는 경우에는 인덱스를 탈 수 있다고 한다.

2. fulltext

쿼리

1. FULLTEXT 인덱스 추가

   ALTER TABLE `coupang`.`PRODUCT` 
   ADD FULLTEXT INDEX `name` (`name`) 
   WITH PARSER NGRAM VISIBLE;

2. 검색 쿼리 작성 ```

-- QUERY 1 SELECT * FROM coupang.PRODUCT WHERE MATCH (name) AGAINST ('2312341' IN NATURAL LANGUAGE MODE);

- 이 쿼리는 NGRAM 파서로 나누어진 단어들도 찾기 때문에 잘못된 결과가 나오기 쉽다.
- 위의 쿼리를 실행했을 때, 일치하지 않는 칼럼도 나오게 된다.
  ![](https://images.velog.io/images/now_iz/post/6a021756-cef4-48b7-a9af-474b1b71fadb/image.png)

-- QUERY 2 SELECT * FROM coupang.PRODUCT WHERE MATCH (name) AGAINST ('2312341' IN BOOLEAN MODE);

```

• 첫번째 쿼리에서 모드를 BOOLEAN 으로 바꾸었다.
• 그러나 아래와 같은 캐시 제한에 걸렸고, 최대한으로 늘려보아도 부족하여 해결할 수 없었다.

  [ERROR] FTS query exceeds result cache limit mysql

  • 캐시 한도를 두 배로 올렸지만, 계속 같은 오류가 발생하였음 SET GLOBAL innodb_ft_result_cache_limit = 4000000000;

성능 테스트

• Explain

3. 검색 엔진

• 추후에 검색 엔진을 사용해서 검색 성능을 높여보겠다.

reference

• https://stackoverflow.com/questions/10354248/optimizing-mysql-like-string-queries-in-innodb
• https://gongzza.github.io/database/mysql-fulltext-search/

우리가 따라하고 있는 쿠팡에서는 페이징 기능이 있다! 그래서 상품 목록을 조회하는 API 에서 페이지 번호와 상품 개수를 함께 돌려줘야 하기 때문에 페이징 기능을 구현해보기로 했다 😀 어떻게 하면, 대용량 데이터에서도 빠르게 페이지 정보와 상품 정보를 가져올 수 있을까?

1. Offset 기반 페이징

• 가장 일반적인 페이징 방식으로서, OFFSET 과 LIMIT 을 이용한다.
• 그러나, 이 방법에는 큰 문제점이 있다. 앞에서 읽었던 행을 다시 읽어야 하기 때문에 페이징 쿼리가 뒤로갈수록 느려진다. 뒤로 갈수록 버리지만 읽어야 할 행의 개수가 많아 점점 뒤로 갈수록 느려지는 것이다! ### 쿼리 ``` SELECT * FROM coupang.PRODUCT WHERE is_rocket = 1 LIMIT 120 OFFSET 30000000; ``` ### 성능 테스트
• 전체 데이터
  • 약 5천만개
• execution time
  • 29 sec
• 실행 계획

2. JOIN 을 활용한 페이징

• 기본적으로 mysql 은 인덱스가 가르키는 row 에 접근하여 가져오는 Row lookup 를 사용한다.
• 그런데, Inner Select 문에서 최대한 인덱스로 검색해서 id 를 가져온 다음에 JOIN 하여 Row lookup 을 최대한 늦추는 Late row lookup 을 활용하면, 성능을 향상 시킬 수 있다.

쿼리

SELECT *
FROM coupang.PRODUCT as p
JOIN (
    SELECT id
    FROM coupang.PRODUCT
    LIMIT 120
    OFFSET 30000000
) AS t
ON p.id = t.id;

성능 테스트

• 전체 데이터
  • 약 5천만개
• execution time
  • 9.408 sec
  • offest 방식보다 약 70% 정도 성능이 향상되었다.
  • 그러나, 아직 너무 느리다!
• 실행 계획

3. Cursor 기반 페이징

• Cursor 기반 페이징 방식은 조회 시작 부분을 인덱스로 빠르게 찾아 매번 첫 페이지만 읽도록 하는 방식이다.
• 아무리 페이지가 뒤로 가더라도 처음 페이지를 읽은 것과 동일한 성능을 가지게 되므로, Offset 방식보다 훨씬 성능이 개선된다.
• 그러나, 이 방식은 원래 페이지 번호가 없고, 다음 페이지를 호출할 수 있는 키워드 등을 제공하는 페이징 기능이다. 아래와 같은 시스템 (흔히 SNS 게시물 조회 API에서 많이 볼 수 있다) 에서 사용한다.
• 즉, 직전 조회 결과의 마지막 ID 를 넘겨서 다음 페이지를 조회하는 방식인 것이다.

  SELECT *
  FROM coupang.PRODUCT
  WHERE id < 직전_조회_결과의_마지막_id
  LIMIT 페이지 사이즈

• 쿠팡에서는 아래처럼 페이지 네비게이터를 사용하기 때문에, 반드시 바로 다음 페이지를 요청할 것이라는 보장이 없다. 1번 페이지를 조회했다가도, 5번 페이지를 조회할 수 있어야 했다!
• cursor 방식은 성능 면에서 압도적이기 때문에 최대한 활용해보려고 노력했고, 이전 페이지 목록 마지막 커서, 현재 페이지 목록의 조회 커서 목록, 다음 페이지 목록 시작 커서 를 가져오는 방법 등을 생각했다. 하지만, 결국 모두 한계가 있어서 사용하기는 힘들었다.

쿼리

SELECT *
FROM coupang.PRODUCT
WHERE id >= 조회_시작점_id AND is_rocket = 1
LIMIT 120;

성능 테스트

• 전체 데이터
  • 약 5천만개
• execution time
  • 0.035 sec
  • offest 방식보다 약 80배 이상 성능이 향상되었다.
  • 커서 목록을 가져오는 쿼리의 오버헤드가 있겠지만, 그것을 감안해도 압도적인 성능이다!
• 실행 계획

4. 테이블의 분리

처음으로 돌아와서, "쿠팡에서는 어떻게 하고 있을까?" 추측해보기로 했다. 쿠팡 사이트를 탐색한 결과, 어떤 필터링 조건을 걸어도 항상 최대 17 페이지까지만 있는 것을 확인했다! 아마도 "모든 필터링 조건에 따라서 테이블을 분리해서 관리하는 대신, offset 방식으로 가져오는 게 아닐까?" 추측했다. 나중에 우리도 해당 방법으로 리팩토링을 시도해볼 생각이다!

기타

대용량 더미 데이터를 생성하는 방법

1. 더미 데이터를 만들 때 이용한 사이트
2. mysql 프로시저 이용하기

• 프로시저 : 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합 - 참고

reference

• https://jojoldu.tistory.com/528?category=637935
• https://explainextended.com/2009/10/23/mysql-order-by-limit-performance-late-row-lookups/
• https://mariadb.com/kb/en/pagination-optimization/

mac은 brew를 이용하여 쉽게 설치할 수 있다.

• 설치

  $ brew install redis

• 시작/종료

  $ brew services start redis
  $ brew services stop redis

• redis-cli 사용하기

  $ redis-cli

응집도를 높이고, 결합도를 낮춰라 (High Cohesion, Loose Coupling)

SRP (단일 책임 원칙)

어떤 클래스를 변경해야 하는 이유는 하나 뿐이다.

• 클래스/속성/메서드/패키지/모듈/프레임워크 등에도 적용된다
• 장점 : 재사용성이 좋아진다
  • A 기능과 B 기능으로 나누어져있으면, 다른 클래스에서 A 기능만 필요한 경우에는 A 만 가져다 쓸 수 있는 모듈이 된다.

OCP

확장은 열려있고, 변경은 닫혀있다.

• 장점 : 유지보수성이 좋아진다
  • JDBC에서 DB를 mysql 에서 oracle 로 바꾸어도 Connection 설정 부분만 바꾸면 된다.
    • 자바 애플리케이션은 JDBC 인터페이스로 인해 변화에 영향을 받지 않는다.
• 변하는 것과 변하지 않는 것을 구분해야 한다!

LSP (리스코프 치환 원칙)

서브 타입은 기반 타입으로 변경할 수 있어야 한다. (상속)

• 고래 -> 포유류

ISP (인터페이스 분리 원칙)

자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.

• 인터페이스는 최소한의 메서드만 제공해야 한다

DIP (의존 역전 원칙)

자신보다 변경되기 쉬운 것들에 의존하지 않는다.

• 변하기 어려운 상위 클래스/ 인터페이스/ 추상 클래스에 의존하라.
  • 자신보다 변하기 쉬운 것에 의존하던 관계 -> 인터페이스를 추가하여 의존성을 역전

Q. 객체 지향 프로그래밍 왜 해야할까?

A. 유지보수성 + 재사용성 👍

✨ 객체 지향 4대 원칙

1. 캡슐화(Encapsulation)

정보 은닉

• public : 모두가 접근 가능
• protected : 상속 / 같은 패키지 내 클래스에서 접근 가능
• default : 같은 패키지 내 클래스에서 접근 가능
• private : 본인만 접근 가능

2. 상속(Inheritance)

재사용 => extends

• 하위 클래스 - 상위 클래스
  • 하위클래스 is a kind of 상위클래스
  • 하위 클래스는 상위클래스 특성을 재사용하고, 확장한다.
  • 상위 클래스의 물려줄 특성이 많을수록 좋다 (LSP)
    • 상위 클래스가 너무 빈약하면, 불필요한 형변환이 자주 일어난다.
• 인터페이스
  • 다중 상속 대신 도입
  • 어떤 객체가 해야할 일을 정의하는 추상 자료형
  • 구현 클래스 is able to 인터페이스 (ex. Runnable)
  • 인터 페이스는 구현을 강제할 메서드가 적을수록 좋다 (ISP)

3. 추상화(Abstraction)

모델링 => class

• 클래스 VS 객체
  • 클래스 : 분류에 대한 개념 -> 같은 특성을 지닌 여러 객체를 총칭하는 집합의 개념 (ex.사람)
  • 객체 : 실체 -> 유일무이한 사물 (ex. 김연아)
• 추상화 : 구체적인 것을 분해해서 관심 영역 (애플리케이션 경계) 에 있는 특성만 가지고 재조합하는 것 (= 모델링)

4. 다형성 Polymorphism

사용 편의 => 오버라이딩, 오버로딩

• 오버라이딩
  • 같은 메서드 이름 / 같은 인자 목록 / 상위 클래스의 메서드 재정의
  • 상위 클래스 타입의 객체 참조 변수에서 자동으로 하위 클래스가 오버라이딩한 메소드를 호출해 줌
• 오버로딩
  • 같은 메서드 이름 / 다른 인자 목록 / 다수의 메서드 중복 정의

번외

Q. 실무에서는 클래스와 인터페이스 중에 어떤 걸 사용하는 게 좋을까? ✏️ 인터페이스 ✏️ 클래스의 상속은 하위클래스가 100개라면, 상위클래스를 바꾸기 쉽지 않기 때문이다.

변수는 메모리에 저장된다

1) 지역 변수

• 스택 프레임에 스택 프레임이 삭제될 때까지 존재
• 서로 다른 스택 프레임이면 지역 변수를 참조할 수 없다.

  메서드는 고유 공간이며, 다른 메서드의 지역 변수에 접근하려면 지역 변수의 메모리 주소 값인 포인터를 알아야 하는데 자바에서는 포인터를 사용할 수 없으므로 값만 전달해야 한다. (Call by value)

2) 클래스 멤버 변수

• 메소드 영역에 JVM 종료될 때까지 존재
• 정적 메소드는 객체 존재 여부와 상관없이 사용할 수 있음
  • 유틸리티성 메서드 (ex. Math 클래스 내 메서드)
• 전역 변수는 조심해서 써야 한다.
  • 가급적 '읽기 전용'으로 쓰자.
  • 모든 객체가 동일한 값은 가지는 것을 전역 변수로 쓰면 좋다. (ex. 고양이 클래스의 다리 개수)

3) 객체 멤버 변수

• 힙 영역에 GC가 삭제할 때까지 존재

번외

초기화 없이 선언만 했을 때, 지역 변수에는 쓰레기값이 할당되고, 클래스 및 객체 멤버 변수는 0, 0.0, false 등으로 초기화되는 이유는 무엇일까? ✏️ 클래스, 객체 멤버 변수는 공유 변수의 성격의 띄기 때문이다.

멀티 스레드 vs 멀티 프로세스

• 메모리 안전성 : 멀티 스레드 < 멀티 프로세스
  • 다른 프로세스의 메모리 영역을 절대 침범할 수 없다.
• 메모리 사용량 : 멀티 스레드 < 멀티 프로세스
  • 멀티 스레드는 메소드 영역(스태틱 영역), 힙 영역은 공유하므로 메모리를 적게 사용한다.
• 요청 당 스레드 (Servlet), 요청 당 프로세스 (CGI)