지난 포스트에서는 GraphQL에 대해서 간단하게 테스트를 해보았다.
이번 포스트에서는 GraphQL의 Learn에 나오는 내용을 따라 설명을 덧붙이려고 한다.
설명과 더불어 GraphiQL을 붙여 즉각 실행해볼 수 있게 구성하였다.
테스트는 Heroku를 사용하고 있다.
Heroku를 무료로 사용할 시 유휴시간이 30분이 넘는 경우, 애플리케이션이 sleep 상태로 바뀐다.
그렇기 때문에 아래의 테스트 로딩이 느릴 수 있으나, 1분 이내에 로딩될 것이다.
Github에서 제공하는 V3 API들을 보면서, 이거야말로 RESTful이구나 했었는데, V4로 넘어오면서 GraphQL을 사용하게 되었다.
Github은 자신들이 V4 API를 RESTful이 아닌 GraphQL로 작성한 이유를 다음과 같이 2가지로 이야기했다.
웹 개발자로서 웹 애플리케이션을 만들 때 신경써야할 것은 서비스 로직 뿐만이 아니다. 웹 애플리케이션의 사용자는 누구인지(일반인? 외부시스템?), 어떤 경로로 애플리케이션에 요청을 할 지(Load Balancing, Fire Wall), 요청 수나 TPS 등 많은 것들을 고려해야한다. 이번에 소개할 spring-boot-actuator라는 모듈은 애플리케이션의 상태를 종합적으로 정리하여 우리에게 제공해준다. 본문에서는 Spring Boot Samples에 있는 프로젝트 중에서 spring-boot-sample-actuator-ui를 가져와 살짝 소스를 수정하여 actuator가 무엇이고 어떤 일 해주는지 알아보려한다.
Spring Boot를 사용해서 Database Sharding을 처리할 수 있을까?
요즘 NoSQL에서는 Sharding과 관련해서 많은 편의를 제공한다. 알아서 Sharding을 제공해주고, 클러스터에 노드가 추가되면 Shard key를 기반으로 자동으로 새로운 노드로 값들을 분배해주거나, 노드를 제거하면 대상 노드에 있던 값들을 Shard Key에 맞추어 남은 노드로 분배해준다. 자세히 알아보지는 않았지만 RDBMS 측의 각종 벤더들도 이러한 아키텍처를 구현기위한 방법을 제공할 것이라 생각된다.(예를 들어 MySQL의 Fabric - 현재 MySQL Utilities에 통합)
이번 포스트에서는 RDBMS Sharding을 각 벤더에 의존해서 구현하지 않고, Spring Boot로 편리하게 설정을 추상화하여 사용할 방법에 대해 공유하려 한다. 앞서 Sharding에 대해서 거창하게 이야기를 했지만, 본문에서 다루고자 하는 영역은 아래의 두 가지 기능이다.
Spring은 캐시 추상화를 통해서 쉽게 캐시를 사용할 수 있게 해준다. CacheManager를 잘 구현한다면 @Cacheable, @CachePut, @CacheEvict 등을 통해서 얼마든지 커스터마이징된 캐시를 사용할 수 있다. 하지만 의외로 장애에 대응하는 방안에 대해서는 Reference 상에서도 구체적인 설명을 해주지 않고 있다. 덕분에 다시 글 쓸 거리가 생긴 것 같다.
사용하는 캐시 시스템에 문제가 생겼을 때 어떻게 대처해야하는지는 어떤 정보를 캐시하느냐에 따라 다르다. 경우의 수 자체가 너무 많다. 또한 캐시 자체가 여러 용도로 쓰일 수 있다. HTTP 응답을 캐시하든지, Repository의 결과를 캐시하든지 혹은 Service의 결과를 캐시할 수도 있다. 본문에서는 아래 두 경우로 간단하게 나누고 이에 대한 해결법을 궁리해보고자 한다.
spring-boot에서는 Logback을 확장해서 편리한 logging 설정을 할 수 있다. application.yml의 설정을 읽어 오거나 특정 profile의 동작을 수행할 수 있다. 이 글에서는 Spring Boot에서 어떻게 logging 설정을 하는지를 알아볼 것이다. 그리고 그것을 기반으로 spring-boot를 사용할 때 profile을 활용할 수 있는 방법을 공유하려고 한다.
본문에서는 logback의 기초적인 정보를 가이드하지 않는다.
spring-boot는 logback 외에도 log4j 등을 지원하지만 logback만을 고려하고 작성한다.
Spring을 익힌지 얼마 되지 않았을 때, 회원 인증 로직을 구현할 일이 생겼었다. 그 인증을 구현하기 위해 Filter와 Interceptor를 조사했었다. 하지만 Filter와 Interceptor를 어떤 경우에 써야 좋은지 명확하게 알지는 못했다. 이제 와서 옛 기억들이 떠올라 다시 spring filter interceptor 차이로 검색을 해보고 올라온 글들을 읽어봤는데, 아무래도 몇 가지 아쉬운 부분들이 있었다. 이번 글에서는 Spring Web Application에서 사용하는 Filter와 Interceptor에 대해, 많은 글에서 공통적으로 이야기하는 부분과 의외로 언급하지 않는 부분 두가지를 쓰려고 한다.
Web Browser에서 Request를 보내면 Server는 Response를 준다. HTTP 통신의 기본적인 동작 방식이다. 하지만 Server에서 Client로 특정 동작을 알려야 하는 상황도 있다. 예를 들어 Browser로 Facebook에 접속해 있다가 누군가 친구가 글을 등록하는 경우, 혹은 Web Browser로 메신저를 구현하는 경우다. WebSocket이 있기 전에는 이를 Polling이나 Long polling 등의 방식으로 해결했었다. 하지만 WebSocket의 등장으로 Server-Client 간의 실시간 통신이 가능하게 되면서, 앞으로 Long polling은 역사의 뒤안길로 사라질 것 같다.
원래 글을 쓰기 위해 준비하던 내용은 Event를 강조하는 것이었는데, 준비를 하다 보니 Async와 AOP를 다 쓰게 되어버렸다.
이번 글에서는 하나의 transaction 안에서 많은 일을 처리하는 소스 코드를 두고, 아래와 같이 점진적으로 리팩토링해나가는 과정에 대해 이야기하려고 한다.