본문 바로가기

Architecture

 (16)
Spring Security 없이 OAuth2 클라이언트 직접 구현 OAuth2 인증 절차OAuth2 클라이언트를 Spring Boot 만 사용하여 구현해보겠습니다.Spring Security 없이, 순수 HTTP 통신과 세션 기반으로 인증 흐름을 직접 설계함으로써OAuth2의 내부 동작을 보다 깊이 있게 이해해보는 것이 목적입니다. 매우 간단합니다. 깃허브에서 전체 코드 확인하기:https://github.com/youseonghyeon/oauth2-client GitHub - youseonghyeon/oauth2-client: oauth2-client 구현을 위한 리포지토리oauth2-client 구현을 위한 리포지토리. Contribute to youseonghyeon/oauth2-client development by creating an account on Gi..
OAuth2 인증 Flow OAuth2는 서버에서는 사용자의 ID/PW 없이, 인증 서버를 통해 인증을 수행하는 프로토콜입니다.즉, 사용자가 직접 로그인 정보를 입력하지 않고도 Google, GitHub 등 외부 인증 서비스를 통해 로그인할 수 있게 해줍니다. 사용자와 클라이언트 모두 보안에 대한 부담을 낮춰줄 수 있습니다. 용어 정리OAuth2 에서는 의미가 비슷한 용어가 있어서 글에서 아래 용어는 다음과 같은 의미로 사용하겠습니다.사용자 : 사용자 + 프론트엔드(브라우저) 를 통합한 개념클라이언트 : OAuth2 인증을 연동하는 애플리케이션 서버 (예: my-service)인증 서버 : OAuth2 인증을 제공하는 서버 (예: Google, GitHub)여기서는 흔히 사용되는 구조인 (사용자 - 웹서버 - API서버) 구조로써..
소프트웨어 복잡성 소프트웨어 복잡성개발을 시작한 지 2년이 넘어가고 개발 팀장이 되면서 소프트웨어 복잡성이라는 벽을 실감하기 시작했습니다. 작은 애플리케이션을 만들 때는 모든 게 단순해 보였지만, 시스템이 커져갈수록 보이지 않던 복잡성이 곳곳에서 드러났습니다.재미있게도 이 복잡성은 단순히 코드 구조나 아키텍처 문제만이 아니였습니다. 조직 구조, 커뮤니케이션, 일정 압박, 우선순위 결정 등 비기술적인 요소들과 복잡하게 얽혀 있다는 것입니다. 한가지 예를 들어보겠습니다. 어떤 서비스가 Web 서비스와 API 서비스를 모두 제공한다고 가정할 때, 사용자의 요청으로 ‘A’라는 기능을 개발하게 되었습니다. 처음엔 Web 서비스에만 우선적으로 기능을 추가하고, API 서비스는 나중에 개발하기로 계획했습니다. 그러나 시간이 흐르면서 ..
코어 수에 따른 프로세스와 쓰레드 개수의 관계와 성능 영향 코어 수와 쓰레드 수의 관계는 멀티스레드 프로그래밍에서 성능 최적화의 핵심 요소입니다. 쓰레드 수가 특정 코어 개수와 맞지 않을 때 성능이 저하되는 이유는 여러 가지가 있으며, 이는 CPU가 수행하는 컨텍스트 스위칭, 메모리 대역폭 문제, 그리고 CPU 코어의 오버헤드와 관련이 있습니다. 이를 구체적인 예시로 살펴보겠습니다. 1. 코어 개수와 쓰레드 개수의 관계CPU는 보유한 코어 수만큼 작업을 동시에(병렬성) 수행할 수 있습니다. 예를 들어, 4개의 코어가 있는 CPU는 이론적으로 최대 4개의 쓰레드를 동시에 실행할 수 있습니다. 이보다 많은 쓰레드가 실행될 경우, 운영 체제는 TCB(Thread Control Block)을 사용해 각 쓰레드의 상태를 저장하고 복구하면서 컨텍스트 스위칭을 수행하게 됩니..
대규모 트래픽에 대비한 아키텍처 확장 전략 이 글에서는 기본적인 Application 서비스 환경에서 대규모 서비스로의 전환을 시간 순으로 나열해보겠습니다. 현재  시스템 구성현재 서비스는 1개의 Nginx 웹 서버와 2개의 Tomcat 애플리케이션 서버로 구성되어 있습니다.기존요청의 흐름사용자는 로컬 또는 DNS 서버를 통해 IP를 받아와 HTTPS(443 포트)로 요청을 보냅니다.요청은 웹 서버를 거쳐 애플리케이션 서버로 전달되고, 필요한 경우 데이터베이스(DB)에서 데이터를 가져와 사용자에게 응답을 전송합니다.HTTP 요청과 응답 구조를 따릅니다.대규모 서비스 전환 단계이제 각 컴포넌트의 성능을 높이고 트래픽을 효과적으로 분산하기 위해 시스템을 확장하는 단계를 살펴보겠습니다. 1. Database 의 Scale Up현재 DB 성능이 충분하지..
CachedThreadPool의 한계와 ThreadPoolExecutor 커스터마이징 CachedThreadPool의 동작 방식과 한계Java의 CachedThreadPool은 다음과 같은 특성을 지니며 높은 처리량을 지원하지만, 동시 작업 수가 많을 때 주의가 필요합니다.  /** * 필요한 경우 새 스레드를 생성하지만, 기존에 생성된 스레드가 있으면 * 이를 재사용하는 스레드 풀을 생성합니다. 이 풀은 많은 짧은 비동기 작업을 * 수행하는 프로그램의 성능을 일반적으로 향상시킵니다. * {@code execute} 호출 시 기존에 생성된 스레드가 사용 가능하다면 이를 재사용합니다. * 사용 가능한 기존 스레드가 없으면 새 스레드를 생성하여 풀에 추가합니다. * 60초 동안 사용되지 않은 스레드는 종료되고 캐시에서 제거됩니다. * ..
의존성 역전 원칙(DIP): 유연하고 확장 가능한 코드 설계의 핵심 의존성 역전의 원칙(Dependency Inversion Principle, DIP)은 객체지향 설계의 5대 원칙 중 하나로, 상위 수준 모듈이 하위 수준 모듈에 의존하지 않도록 하여 시스템의 결합도를 줄이고 유연성을 높이는 데 중점을 둡니다. 이 원칙은 애플리케이션이 변화에 쉽게 대응할 수 있도록 구조적으로 설계하는 데 중요한 역할을 합니다. 의존성 역전의 원칙(DIP)의 핵심 개념 DIP는 두 가지 주요 원칙으로 설명됩니다. 1. 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 된다.상위 수준 모듈은 애플리케이션의 비즈니스 로직을 담당하고, 하위 수준 모듈은 데이터베이스나 네트워크와 같은 구체적인 기능을 처리합니다. 상위 모듈이 하위 모듈에 직접 의존하면, 하위 모듈이 변경될 때 상위 모듈도 영향을..
좋은 코드를 위한 5가지 핵심 원칙: SOLID부터 리팩토링까지 좋은 코드를 작성하는 방법에 대해 많은 이론과 원칙이 있지만, 저는 특히 다음 5가지가 중요하다고 생각합니다. 1. SOLIDSOLID 원칙은 효과적인 소프트웨어 설계의 핵심입니다. 이 중에서도 '단일 책임 원칙(Single Responsibility Principle, SRP)'은 특히 중요합니다. SRP는 하나의 클래스가 단 하나의 책임을 가져야 한다고 말합니다.  이 원칙을 지키면 클래스 간의 복잡도가 줄어들고, 코드의 가독성과 유지보수성이 향상됩니다. 단일 책임 원칙을 통해 각 클래스의 목적이 명확해지며, 이는 전체 시스템의 이해와 확장성에 긍정적인 영향을 미칩니다. 2. 읽기 쉬운 코드좋은 코드인지 확인하는 방법은 아주 간단합니다.좋은 코드의 핵심 요소 중 하나는 바로 '읽기 쉬움'입니다. 다른..

티스토리툴바