1. 마이크로서비스 기본 구조
마이크로서비스는 작고 독립적인 서비스들로 구성됩니다. 각 서비스는 특정 비즈니스 기능을 담당합니다.
@SpringBootApplication
@RestController
public class UserService {
@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
// 사용자 정보 조회 로직
return new User(id, "John Doe", "john@example.com");
}
public static void main(String[] args) {
SpringApplication.run(UserService.class, args);
}
}
팁: 서비스 경계를 명확히 정의하세요. 각 서비스는 단일 책임 원칙을 따라야 합니다. 너무 작게 나누면 복잡성이 증가하고, 너무 크면 모놀리식 구조의 단점이 나타날 수 있습니다.
2. 서비스 디스커버리 구현
마이크로서비스 환경에서는 서비스 인스턴스의 위치가 동적으로 변할 수 있습니다. 서비스 디스커버리를 통해 이를 관리합니다.
@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServerApplication {
public static void main(String[] args) {
SpringApplication.run(DiscoveryServerApplication.class, args);
}
}
// 클라이언트 서비스
@SpringBootApplication
@EnableDiscoveryClient
public class ClientServiceApplication {
public static void main(String[] args) {
SpringApplication.run(ClientServiceApplication.class, args);
}
}
팁: Netflix Eureka나 Consul과 같은 서비스 디스커버리 도구를 사용하세요. 이들은 동적 환경에서 서비스 등록과 발견을 자동화합니다. 또한, 서비스 헬스 체크 기능을 활용하여 장애 대응 능력을 향상시키세요.
3. API 게이트웨이 구현
API 게이트웨이는 클라이언트 요청을 적절한 마이크로서비스로 라우팅하고, 공통 기능을 처리합니다.
@SpringBootApplication
@EnableZuulProxy
public class ApiGatewayApplication {
public static void main(String[] args) {
SpringApplication.run(ApiGatewayApplication.class, args);
}
@Bean
public SimpleFilter simpleFilter() {
return new SimpleFilter();
}
}
public class SimpleFilter extends ZuulFilter {
@Override
public String filterType() {
return "pre";
}
@Override
public int filterOrder() {
return 1;
}
@Override
public boolean shouldFilter() {
return true;
}
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
log.info(String.format("%s request to %s", request.getMethod(), request.getRequestURL().toString()));
return null;
}
}
팁: API 게이트웨이에서 인증, 로깅, 요청/응답 변환 등의 크로스 커팅 관심사를 처리하세요. 이를 통해 각 마이크로서비스의 복잡성을 줄일 수 있습니다. 또한, 게이트웨이 레벨에서 속도 제한(rate limiting)을 구현하여 DDoS 공격에 대비하세요.
4. 서비스별 데이터베이스
각 마이크로서비스가 자체 데이터베이스를 가지도록 설계하면 서비스 간 결합도를 낮출 수 있습니다.
@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String name;
private String email;
// 생성자, getter, setter
}
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}
@Service
public class UserService {
@Autowired
private UserRepository userRepository;
public User createUser(User user) {
return userRepository.save(user);
}
public User getUserById(Long id) {
return userRepository.findById(id).orElseThrow(() -> new UserNotFoundException(id));
}
}
팁: 데이터베이스 선택 시 각 서비스의 특성을 고려하세요. 예를 들어, 트랜잭션이 중요한 서비스는 관계형 데이터베이스를, 대량의 읽기 작업이 필요한 서비스는 NoSQL을 사용할 수 있습니다. 또한, 데이터 일관성을 위해 이벤트 소싱 패턴을 고려해보세요.
5. 회복성 패턴 구현
마이크로서비스 환경에서는 네트워크 지연, 서비스 장애 등 다양한 문제가 발생할 수 있습니다. 회복성 패턴을 통해 이러한 문제에 대응합니다.
@Service
public class ResilientService {
@HystrixCommand(fallbackMethod = "getFallbackUser")
public User getUser(Long id) {
// 외부 서비스 호출
return userClient.getUser(id);
}
public User getFallbackUser(Long id) {
return new User(id, "Fallback User", "fallback@example.com");
}
}
팁: Netflix Hystrix나 Resilience4j와 같은 라이브러리를 사용하여 서킷 브레이커, 벌크헤드, 재시도 등의 패턴을 구현하세요. 또한, 비동기 통신을 활용하여 서비스 간 결합도를 낮추고 성능을 향상시키세요.
6. 모니터링 및 로깅
분산 시스템에서는 효과적인 모니터링과 로깅이 필수적입니다.
@SpringBootApplication
@EnableZipkinServer
public class ZipkinServerApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinServerApplication.class, args);
}
}
// 클라이언트 서비스
@SpringBootApplication
@EnableZipkinStreamServer
public class MicroserviceApplication {
@Bean
public AlwaysSampler defaultSampler() {
return new AlwaysSampler();
}
public static void main(String[] args) {
SpringApplication.run(MicroserviceApplication.class, args);
}
}
팁: 분산 추적 시스템(예: Zipkin, Jaeger)을 사용하여 서비스 간 요청 흐름을 추적하세요. ELK 스택(Elasticsearch, Logstash, Kibana)을 활용하여 중앙 집중식 로깅 시스템을 구축하세요. 또한, Prometheus와 Grafana를 사용하여 실시간 메트릭 모니터링 대시보드를 만드세요.
결론
Java 기반의 마이크로서비스 아키텍처는 대규모 트래픽 처리에 효과적인 솔루션을 제공합니다. 서비스 분리, 효과적인 통신 방식, 데이터 관리, 회복성 패턴, 그리고 종합적인 모니터링 전략을 통해 확장 가능하고 유지보수가 용이한 시스템을 구축할 수 있습니다. 이러한 접근 방식을 채택할 때는 팀의 기술적 성숙도와 비즈니스 요구사항을 고려해야 합니다.