Arthur's Blog

📌 정의 서로 상호작용하는 시스템들간의 의존성. 의존성은 실질적 의존성과 인위적 의존성으로 나뉠 수 있다. 실직적 의존성 한 시스템이 소비하는 다른 시스템이 기능이나 서비스의 집합. 인위적 의존성 한 시스템이 다른 시스템이 제공하는 기능이나 서비스를 소비하기 위해 필요한 여러 요소들의 집합. 언제나 존재하지만 그 비용은 충분히 감소될 수 있으며 Loose Coupling은 인위적 의존성을 최소한으로 줄이는 구조를 의미한다. 언어적 의존성 플랫폼 의존성 API 의존성 🔗 긴밀한 결합(Tight Coupling) 강하게 결합된 객체(Tightly Coupled Object Object)는 다른 오브젝트에 대한 상당히 많은 정보를 필요로 하고, 보통 두 객체간의 인터페이스들에게 서로 높은 의존성을 가지고 있다..

📌 정의 AWS에서 제공하는 CDN서비스이다. 엣지 로케이션을 여러 개 두고, 가장 가까운 엣지 로케이션에 접근해서 지연시간을 최소화 한다. 👍 장점 엣지 로케이션을 활용해서 사용자에게서 가장 가까운 엣지 로케이션에 접근해서 지연시간을 최소화 한다. 캐싱을 활용해서 엣지 로케이션에 있는 정보면 S3에 다시 접근하지 않는다. 따라서 S3의 비용이 줄어든다.

📌 정의 IoC 컨테이너, 어플리케이션 콘텍스트, 스프링 컨테이너, 스프링, DI 컨테이너 등 여러 용어로 불리지만 이 글에서는 “IoC 컨테이너” 라는 용어를 사용하겠다. 또한 해당 글에서는 xml설정이 아닌 java설정 설명만 있음에 주의하자. ❓ IoC 컨테이너가 뭐야? 간단하게 Bean부터 알고 넘어가야한다. Bean은 스프링이 제어권을 가지고, 직접 만들고 관계를 부여하는 오프젝트를 뜻한다. 스프링 빈은 IoC 컨테이너가 생성, 관계설정, 사용 등을 제어해주는 IoC가 적용된 오브젝트를 가리키는 말이다. 바로 위에서 언급했듯이 IoC 컨테이너는 스프링 빈을 생성, 관계설정, 사용 등을 제어한다. ♻ IoC 컨테이너의 동작방식 먼저, @Configuration이 붙은 Class에 @Bean이 붙어..

📌 정의 도커가 공식적으로 만든 오케스트레이션 툴. 도커 컨테이너를 위한 클러스터링, 스케줄링 툴이다. 스웜을 이용해서 여러 개의 서버와 컨테이너 관리를 쉽게 할 수 있다. 또한 매니저 노드와 작업자 노드가 존재한다. 👨‍🎓 매니저 노드 매니저 노드는 아래의 업무를 통해 도커 클러스터를 관리한다. 매니저 노드 역시 작업자에 속하긴 한다. 클러스터의 상태를 유지 : 뗏목 알고리즘 사용한다. 스케줄링 서비스 : 작업자 노드에게 컨테이너를 배포한다. 특정 노드에게만 배포하거나, 모든 노드에 하나씩 배포할 수도 있다. 스웜 모드 제공 👷‍♂️ 작업자 노드 도커에서 일반적으로 컨테이너를 실행하는 노드를 작업자 노드라고 한다. 작업자 노드들의 클러스터는 반드시 하나 이상의 관리자 노드를 가져야 한다.

📌 정의 의존성 주입이라고 말하며, 추상화를 해치지 않고 의존성을 인수로 넘겨주는 것을 말한다. 😎 예시 Spring Boot를 예시로 들자면, Service 구현체에서는 Repository와 같이 의존성을 갖는다. 하지만 해당 Service를 추상화 한 interface는 Repository가 인수로 넘어가는 정보를 전혀 담고있지 않다. interface UserService { void removeUser(Long userId); } @Service @RequiredArgsConstructor class UserServiceImpl implements UserService { private final UserRepository userRepository; } 위 코드는 위의 말에 따라서 UserSer..

🎊 시작하기 전에.. DI, IoC, DIP가 비슷비슷한건줄 알고, 어떤 부분이 다른지 몰랐다면 잘 찾아온것이라고 생각한다. 이 글에서는 각 각의 정의, 내용보다는 차이점을 중점적으로 다룰 것이다. 😵 DI, IoC 스프링을 공부하는 사람이라면 DI과 IoC가 거의 동등한 것이라고 생각할 수도 있다. 왜냐하면 스프링 3대 요소를 이야기할 때 IoC/DI라고 많이 이야기 하기 때문이다. 하지만 DI는 IoC를 구현하는 방법 중 하나이다. 하지만 역으로 IoC 컨테이너를 사용하지 않는 DI또한 가능하다. 이를 Pure DI라고 부른다. 참고 위에서 IoC를 사용하지 않는 DI 라는 표현을 했는데, 이 표현은 무리가 있을 수 있다고 생각된다. 왜냐하면 모든 DI 구현체는 IoC로 간주될 수 있기 때문이다. 자..

📌 정의 애플리케이션에 필요할 수 있는 모든 서비스를 얻는 방법을 알고있는 객체를 갖는 것이다. IoC를 구현하는 DI 외 방법 중 하나. 🔗 종속성 다이어그램 실제 사용방법 class ServiceLocator{ private static ServiceLocator sInstance; public static void load(ServiceLocator arg) { sInstance = arg; } private Map services = new HashMap(); public static Object getService(String key){ return sInstance.services.get(key); } public void loadService (String key, Object service..

배포를 두려워 하는 이유 영향도 콜백 따라서 영향도 최소화 및 쉽고 빠른 롤백을 구축해놓는게 중요하다. 기능 플래그 점진적 전달 기능 플래그 배포와 출시의 분리 데이터 측정 사례 점진적 전달(Progressive Delivery) 기능 출시를 제어 일부 사용자들한테만 먼저 기능을 출시 주요 지표를 측정 지표에 문제가 있으면 롤백 사용자 기준 기능 플래그(Feature Flag) on / off 스위치 Rollout Targeting 배포 전략 블루 그린 배포 v1이 있을 때 v2를 배포하고, 로드밸런서로 v2를 가리키게해서 다운 없이 배포를 할 수 있다. 카나리 배포 하나 혹은 일부 서버에만 v2를 배포하고, 나머지는 기존버전으로 로드밸런싱 해놓고, 점차 늘려가는 방식. 코드배포와 기능출시가 한번에 이루..