일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- JPA
- 프로그래밍문제
- 스프링부트
- Apache Kafka
- springboot
- 스프링
- Spring Boot
- 머신러닝
- DFS
- Kafka
- 알고리즘
- Docker
- 백준
- 스프링 부트
- Spring
- 백트래킹
- aws
- 로드밸런서
- 카프카
- 오일러프로젝트
- 쿠버네티스
- 월미도
- Spring Data JPA
- 자료구조
- 코드업
- 클라우드 컴퓨팅
- 클라우드
- Elasticsearch
- VPC
- gcp
- Today
- Total
GW LABS

Single Thread로 처리하기에는 너무 많은 양의 데이터를 처리해야 할 경우가 있다. 특히 마이그레이션 작업 시에 이런 일이 자주 발생한다. 신속하게 대용량 데이터를 DB에 저장 및 업데이트하기 위해서 Spring Boot와 Spring Boot JDBC를 Multi-Thread와 함께 사용해보았다. DB 작업에 Multithread를 적용하기 위해서 어떤 부분을 주의해야 하는지 함께 살펴보자. DB 배치작업 소요시간을 줄이기 위해 선택한 Multithread DB 배치작업 소요시간을 줄이기 위해서 멀티쓰레드 방식으로 구현을 진행하기로 결정했다면 아래와 같은 사항들을 고려해야 할 것이다. Thread 단위로 데이터를 나눌 수 있는가? 데이터를 Key 기준으로만 제어하는 작업이라면 Multithrea..

이번 포스팅에서는 스프링 부트에서 여러 DataSource를 구성하는 방법을 소개한다. 보통의 경우 스프링 부트에서 DataSource는 하나로 유지해도 충분할 것이다. MSA 아키텍처가 유행하고 있고, 이에 따라 각각의 작은 API 프로젝트들이 하나의 DB만 바라보면 충분하기 때문이다. 그러나 특별한 상황에서 한 프로젝트에서 여러 DataSource가 필요한 경우가 있다. 이러한 Multi Datasource 같은 경우에도 구성방법은 어렵지 않다. 실수하기 쉬운 부분을 여기에 정리하려고 한다. 여러 개의 DataSource가 필요한 상황 마이그레이션 마이그레이션 작업을 스프링 부트를 이용해서 진행해야 할 때 여러 DataSource를 설정하여 작업이 필요하다. API없이 하나 이상의 DB처리 별도 AP..
14720번 우유 축제 문제는 그리디 문제로 배열을 조건대로 순회하면서 개수를 세는 문제였다. 오랜만에 그리디 문제를 풀면서 느낀 점은 문제를 파악하는 속도와 센스가 많이 줄었다는 것이었다. 주기적으로 그리디 관련 문제를 풀면서 감각을 살려야한다. 아래는 소스코드다. #include using namespace std; int stores[1000]; int getNextStore(const int& currentStore) { switch (currentStore) { case 0: return 1; case 1: return 2; case 2: return 0; default: return 0; } } int main() { int storeNum; cin >> storeNum; for (int i ..
오랜만에 백준 구현문제를 풀어보았다. 단순한 구현문제로 반복문을 활용하는 문제이다. 코드를 줄이는 연습을 계속해서 진행해야겠다. 반복문 안에 들어가는 변수들은 미리 선언해서 반복문의 중복을 피하도록 해야한다. #include #include using namespace std; char phase[100][100]; int main() { int size; cin >> size; for (int i = 0; i > phase[i][k]; } } int cmd; cin >> cmd; switch (cmd) { case 2: for (int i = 0; i < size; ++i) { for (int k = 0; k..

이번 포스팅에서는 Private Subnet에 위치한 서비스들을 외부에 오픈하는 방법에 대해 알아본다. 기본적인 구조는 Private Subnet에는 외부에 노출되지 않는 서비스들을 생성하고, Public Subnet에서는 로드밸런서를 두어서 로드밸런서로 들어온 트래픽을 Private Subnet으로 연결시키는 구조이다. 이번 포스팅에서는 EKS를 사용하여 진행했지만 EC2와 로드밸런서를 직접 생성해서 트래픽을 연결시키는 방법도 공부가 필요하다. 전체 아키텍처 이번 실습의 전체 아키텍처는 다음과 같다. 이전 포스팅에서 Private, Public 서브넷을 나눴다면, Public에 위치해야 할 자원들은 NAT와 로드밸런서이다. EKS와 같은 쿠버네티스를 사용한다면 로드밸런서를 쿠버네티스 서비스를 이용해 자..

이번 포스팅에서는 VPC의 엔드포인트와 배치 그룹에 대해 알아본다. 실습을 진행할 만한 큰 내용은 없는 것 같아 이론을 정리한 내용들을 포스팅하기로 결정했다. 이전 포스팅과 함께 알아두면 좋은 내용이고, VPC에 대한 사항은 대부분 파악한 것 같다. 앞으로는 외부로 서비스를 하기 위한 내용들을 집중적으로 공부해야겠다. VPC 엔드포인트 사용자가 생성한 VPC에서 프라이빗 서브넷에서도 AWS 퍼블릭 서비스와 프라이빗 네트워크 통신을 제공하는 프라이빗 엑세스 기능이다. VPC 엔드포인트는 두 종류가 있는데 엔드포인트와 엔드포인트 서비스로 나뉜다. 엔드포인트: AWS 퍼블릭 서비스에 대상으로 프라이빗 연결 게이트웨이 엔드포인트: AWS 퍼블릭 서비스 중 S3, DynamoDB 등에 대한 연결 인터페이스 엔드포..

개발자가 클라우드 컴퓨팅을 처음 배울 때 가장 어려운 점이 무엇일까? 내 경우에는 네트워크를 구성하는 부분이었다. 그 이유를 생각해보면 통상적인 업무에서는 개발 업무에 집중하고 인프라에 작업이 필요한 경우에는 인프라 담당자에게 요청하면서 개발을 진행했기 때문이다. 클라우드 컴퓨팅에서는 모든 컴퓨팅 리소스를 개발자가 다룰 수 있도록 구성되어 있기 때문에 네트워크부터 설계해야하는 상황이라면 공부가 꼭 필요하다. 이번 시리즈에서는 AWS를 통해 클라우드 컴퓨팅을 네트워크 관점으로 공부해보려고 한다. 그 중 가장 기본인 VPC부터 살펴보자. VPC(Virtual Private Cloud) 독립된 가상의 클라우드 네트워크 사용자가 직접 네트워크 오브젝트들을 생성하고 제어할 수 있음 VPC 특징 확장성: 클라우드 ..

프로젝트 운영을 하면서 자주 발생하는 변경사항에 따라 빌드, 테스트, 배포 하는 과정은 매우 지루하고 반복적인 업무이다. 운영업무에서 마주하게 되는 이런 불편한 점들을 해소시켜주기 위해 CI/CD 프로세스가 대두되었고, 지금에는 다양한 CI/CD 툴들이 필요에 따라 선택되고 있다. 이번 포스팅에서는 대표적인 CI 툴인 Jenkins를 알아보고 CI/CD 개념에 대해서도 정리해보자. CI/CD 지속적인 통합(Continuous Integration): 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 레포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식이다. 지속적인 전달(Continuous Delivery): 프로덕션에 릴리즈하기 위한 코드 변경이 자동으로 준비되는 소프트웨..