Go Gradually - Repository

1. RESTful API의 개념 및 설계 원칙RESTful API는 클라이언트와 서버 간의 역할을 명확히 분리하여 각 구성 요소가 독립적으로 발전할 수 있도록 설계된 아키텍처이다. 다음의 원칙들이 핵심이다.클라이언트-서버 구조클라이언트와 서버가 서로의 구현에 영향을 받지 않고 독립적으로 변경될 수 있도록 역할을 분리한다.무상태성(Stateless)서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리된다. 실제 개발 환경에서는 세션 등을 사용해 상태를 관리하기도 하지만, REST의 기본 원칙은 무상태를 유지하는 것이다.캐시 처리 가능(Cacheable)응답 데이터는 캐시될 수 있어, 네트워크 부하를 줄이고 성능을 개선할 수 있다.일관된 인터페이스(Uniform Interface)클라이언..

1. 관계형 데이터베이스의 정규화정규화는 데이터베이스 설계 시 데이터 중복을 최소화하고 삽입, 수정, 삭제 이상 현상을 제거하며 데이터 무결성을 유지하기 위한 일련의 과정이다. 정규화 과정을 통해 저장 공간을 효율적으로 사용하고, 일관된 데이터 관리를 보장할 수 있다.정규화의 장점데이터 중복 최소화: 동일 데이터의 반복 저장을 피하여 저장 공간을 절약한다.이상 현상 제거:삽입 이상, 수정 이상, 삭제 이상을 방지한다.데이터 무결성 유지: 데이터의 정확성과 일관성을 보장한다.저장 공간 효율적 사용: 불필요한 중복 저장을 제거하여 공간을 절약한다.정규화의 단점JOIN 연산 필요: 여러 테이블로 분리된 데이터를 조회할 때 복잡한 JOIN 연산이 필요해 성능 저하의 원인이 될 수 있다.2. 비정규화비정규화는 정..

개인적으로 SOLID 는 객체지향의 "기초" 라고 하기엔 너무 어렵다고 생각하지만, SOLID를 통해 객체지향 학습을 시작하는 사례가 많으니, SOLID를 이해하기 위한 흐름을 잡아 설명하도록 하겠다.1. 객체지향 프로그래밍의 기본 특성객체지향 프로그래밍은 소프트웨어 설계와 구현에 있어 효율성과 유지보수성을 높이기 위한 패러다임이다. 대표적인 네 가지 특성은 캡슐화, 상속, 다형성, 추상화이며, 각각 다음과 같이 설명할 수 있다.1.1 캡슐화캡슐화는 데이터(필드)와 그 데이터를 처리하는 메서드를 하나의 객체로 묶어, 외부에서 불필요하거나 민감한 정보에 직접 접근하지 못하도록 제한하는 개념이다. 이를 통해 객체 내부의 상태를 보호하고, 변경의 영향을 최소화할 수 있다. 1.2 상속상속은 기존의 클래스를 기..

자바의 기본 특징자바는 객체지향 프로그래밍(OOP)에 기반하여 설계되었으며, "Write Once, Run Anywhere"라는 플랫폼 독립성을 갖는다. 이는 한 번 작성된 코드가 어떠한 운영체제에서도 동일하게 실행될 수 있음을 의미한다.JDK 구조자바 개발 환경은 JDK(Java Development Kit), JRE(Java Runtime Environment), 그리고 JVM(Java Virtual Machine)으로 구성되며, 각 계층은 다음과 같이 역할을 분담한다.1. JDKJDK는 자바 개발에 필요한 모든 도구를 포함하는 패키지이다.JDK의 주요 구성 요소는 다음과 같다.JRE: 자바 애플리케이션을 실행하기 위한 환경을 제공한다.개발 도구: 자바 컴파일러(javac), 패키징 도구(jar), ..

1. AMI (Amazon Machine Image)1) AMI의 정의AMI는 EC2 인스턴스를 실행하기 위한 템플릿이다. 운영체제, 애플리케이션, 구성 정보가 포함되어 있어, 이를 바탕으로 동일한 환경을 필요로 하는 여러 인스턴스를 쉽게 생성할 수 있다.2) 유연성과 확장성 확보AMI를 활용하면 여러 인스턴스에 동일한 이미지를 적용하여 일관된 환경을 빠르게 구성할 수 있다. 예를 들어, 사용자가 직접 만든 AMI를 Auto Scaling에 적용하면 트래픽 증가 시점을 감지해 자동으로 동일 환경의 인스턴스를 스케일 아웃할 수 있다.3) AMI 선택 시 고려 요소운영체제: Linux, Windows 등 사용하려는 운영체제가 무엇인지 확인해야 한다.리전: AMI는 리전에 따라 사용 가능한 이미지가 다를 수 ..

1. IAM을 배워야 하는 이유AWS 리소스 간 ‘관계’를 정의하는 방식IAM(Identity and Access Management)은 단순히 사용자 권한만을 제어하는 것이 아니라, AWS의 각종 리소스(EC2, S3 등) 간 권한 관계를 표현하고 제어한다. 이를 통해 서비스 간 안전하고 유연한 연동이 가능해진다.보안 및 권한 관리의 핵심AWS 인프라를 운영할 때, 자격 증명과 권한 설정이 명확해야 한다. 잘못된 권한 설정은 치명적인 보안 사고로 이어질 수 있으므로 IAM을 깊이 이해하고 적절히 활용해야 한다.2. Admin UserRoot 대신 Admin 계정 사용Root 계정은 결제 정보 수정이나 계정 전반의 보안 설정 같은 위험도가 높은 작업을 수행할 수 있다. 이로 인해 보안 사고가 발생할 가능..

1. 데이터베이스 보안 설정DB 포트 개방 주의데이터베이스 포트를 불필요하게 열어두면 외부 공격에 노출되어 치명적인 보안 사고로 이어질 수 있다. 무분별하게 포트를 개방하지 말고, 반드시 보안 그룹을 활용해 접근을 엄격히 제한해야 한다.보안 그룹을 통한 포트 제어데이터베이스에 접근할 때는 특정 IP나 서브넷에 한정해 포트를 열도록 설정한다. 이를 통해 같은 VPC 내의 모든 인스턴스가 아니라, 신뢰할 수 있는 범위의 트래픽만이 데이터베이스에 접근할 수 있다.2. VPC 내부 통신과 보안 그룹VPC 내 통신같은 VPC에 있는 인스턴스는 기본적으로 네트워크 계층에서 통신이 가능하다. 그러나 “같은 VPC”와 “같은 보안 그룹”은 다른 의미를 가진다. 단순히 보안 그룹이 동일하다고 해서 자동으로 통신이 허용되..

1. AWS VPC 란?AWS VPC (Amazon Virtual Private Cloud)는 사용자가 AWS 클라우드 내에서 전용 가상 네트워크를 구성할 수 있게 하는 서비스이다. 이 네트워크는 타 사용자와 완전히 논리적으로 분리되며, EC2 인스턴스와 같은 여러 AWS 리소스를 안전하게 실행할 수 있는 환경을 제공한다. VPC 내에서는 네트워크를 보다 작은 범위의 서브넷으로 분할해 세밀하게 리소스와 트래픽을 관리할 수 있다.2. EC2 Classic과 Default VPCEC2 ClassicEC2 Classic은 VPC 도입 이전에 사용하던 단일 네트워크 환경이다. 2013년 12월 4일 이후 생성된 계정에서는 지원되지 않으며, 성능과 보안 측면에서 VPC에 비해 열위에 있다. 따라서 기존 EC2 C..

1. 기본 개념 및 용어라우팅 테이블라우팅 테이블은 패킷이 목적지로 전달되기 위해 거쳐야 할 경로 정보를 저장한 테이블이다. 이 테이블을 통해 네트워크 장비는 다음에 어떤 경로로 데이터를 전송할지 결정한다.서브넷 (Subnet)전통적인 네트워크에서 서브넷은 동일한 네트워크 상의 장비들이 라우터와 같은 중개 장치를 거치지 않고 직접 통신할 수 있도록 분리한 소규모 네트워크이다. 서브넷은 서브넷 마스크를 사용해 네트워크 범위를 구분하며, 이를 통해 내부와 외부 네트워크를 논리적으로 분리할 수 있다.CIDR (Classless Inter-Domain Routing)CIDR 표기법은 IP 주소와 서브넷 마스크를 결합해 네트워크 범위를 지정하는 방식이다. 이를 통해 private 또는 public IP 대역을 유..

1. 빅뱅 방식빅뱅 방식은 전체 시스템을 한 번에 전면적으로 변경하는 접근 방법이다. 초기 계획에서는 단기간 내에 모든 구성요소를 개편함으로써 빠른 변화를 기대하지만, 실제 적용 단계에서는 여러 가지 문제가 동시에 발생할 가능성이 높다.예시한 팀이 1년간 전면 개편을 목표로 개발에 착수하였다. 초기에는 “1년 동안 열심히 개발하면 모든 것을 한 번에 바꿀 수 있다”는 기대감이 팽배하였다.그러나 실제 적용 단계에 들어서자 “이 방식으로 진행하면 시스템 안정성이 우려된다”는 불안감이 확산되었고, 검증 과정에서 추가 6개월이 소요되었다.배포 단계에서는 마이그레이션 문제로 다시 6개월이 추가되었으며, 최종적으로는 롤백 절차에 1년이 더 소요되는 상황에 이르렀다.결과적으로 원래 계획된 1년이 3년으로 늘어났으나,..

팀 프로젝트 일정 관리에서의 데이터 일관성 유지 회고프로젝트를 진행하면서 겪은 가장 큰 도전 중 하나는 팀 프로젝트 기간과 개별 일정 간의 일관성 문제였습니다. 우리 서비스는 단순 피드백을 넘어서 대학생들이 팀 내에서 자유롭게 일정과 할 일을 관리하며 능동적으로 소통할 수 있도록 설계되었는데요, 그만큼 비즈니스 로직에 따른 세밀한 제약 조건을 고려해야 했습니다. 비즈니스 로직의 핵심 요구사항팀 프로젝트 기간 수정: 오직 팀장만 프로젝트 기간을 수정할 수 있습니다.일정 추가: 팀원 누구나 일정을 추가할 수 있습니다.팀-일정 관계: 팀 프로젝트 기간은 반드시 모든 일정을 포함해야 합니다.이러한 제약은 우리 서비스가 팀장에게서 탑-다운으로 내려오는 단순한 피드백 시스템이 아니라, 팀원들이 스스로 일정 관리 및..

그라파나소개대시보드 확인 툴메트릭 DB를 한눈에 보게 해주기 위한 대시보드프로메테우스의 데이터를 조회해서 그래프로 표시초기 id, 비밀번호: admin그라파나 - 프로메테우스 연동connections -> data sources 찾기데이터 소스에 prometheus 추가그라파나 구조대시보드큰 틀패널대시보드 안에 모듈처럼 들어가는 컴포넌트visualization 정보를 보여준다.우측에 있는 설정으로 패널 정보 수정 가능standard options보여지는 정보의 타입 지정 가능보여지는 정보의 형식 지정 가능쿼리해당 패널에 띄울 데이터를 정하는 곳Builder클릭으로 사용가능한 쿼리 생성기code쿼리를 직접 입력해서 사용하는 방식하단의 add query로 여러 쿼리 추가 가능options해당 쿼리의 패널 내..

소개메트릭을 보관할 DB꾸준히 마이크로미터에서 메트릭을 받아와 저장함프로메테우스 아키텍처 pull metrics데이터를 당겨옴Prometheus server프로메테우스의 서버, 두뇌Node당겨온 데이터를 저장하는 저장소PromQL프로메테우스(DB)에 저장된 데이터를 조회하기 위한 쿼리그라파나와 같은 툴이 사용함Alertmanager프로메테우스가 제공하는 알림 툴프로메테우스는 그 자체로도 DB만큼 방대하다책으로 공부해야 할만큼 방대함추가적인 학습이 필요함따로 알아보면서 공부할 것보안 및 개인정보 보호에서 차단 해제해줘야 함기본 포트는 9090프로메테우스 설정 방법2가지 설정이 필요함애플리케이션 설정프로메테우스가 애플리케이션의 메트릭을 가져갈 수 있도록애플리케이션에서 프로메테우스 포멧에 맞추어 매트릭 만들기..

전투에 실패한 지휘관은 용서할 수 있지만, 경계에서 실패하는 지휘관은 용서할 수 없다개발 하고 끝내버리면, DevOps 경험, 좋은 품질, 유지보수가 사라진다.경계는 확실하게 해라개발도 하고, 모니터링도 구축해보고, 해야 한다.메트릭을 보는 이유정확한 값을 확인하기 위해?X값의 추세를 보기 위해?O큰 그림에서, 흐름이 어떻게 흘러가고 있는지 파악마이크로미터란?표준 측정 방식을 정한 인터페이스"애플리케이션 매트릭 파사드"애플리케이션의 매트릭(측정 지표)을 마이크로미터가 정한 표준 방법으로 모아서 제공스프링부트 액츄에이터는 마이크로미터를 기본으로 내장해서 사용개발자는 마이크로미터가 정한 표준 방법으로 매트릭을 전달하면 된다마이크로미터는 이미 지표 수집 기능을 이미 만들어서 제공오토컨픽으로 자동으로 등록마이크..

불안기새로운 지식을 접하는 단계자신의 부족함에 자존감이 깎이는 시기실제로 이 감정을 피하기 위해 행동으로 옮기면, 성장기로 진입하게 된다.성장기새로운 지식을 습득하는 단계가장 많이 능력적으로 성장하게 된다.하지만, 지적 허영심에 빠질 수 있음에 주의해야 한다.지적 허영심에서 빠져나오고, 실제로 활용하게 될 때, 안정기로 진입하게 된다.안정기내 자신의 실력을 실제로 활용하는 기간세상에 자신이 배운 이치를 실제로 자신감을 갖고 활용하는 상황일반적으로 처음 진입할 때 우매함의 봉우리를 겪게 된다.알지 못하는 새로운 지식을 접했을 때, 불안기로 진입하게 된다. 논리적 사고 방법장단점 분석장점좀 더 많은 경우의 수 고려 가능단점현재의 분석이 완벽하다는 가정이 들어감분석 마비 가능성이해득실 분석장점지금 견해가 확실..

DDD바운디드 컨텍스트 vs 연관관계바운디드 컨텍스트도메인 별 개념의 집합Depth로 표현소유권 개념Aggregate Root 가 최상위 개념하위 모든 리소스를 관리함이대로 RESTful 하게 API 설계 가능연관관계1:1, 1:n, n:1, n:m관계로 표현소유권 개념이 있지만, 바운디드 컨텍스트랑은 별계임도메인 객체 탐색 vs 직접 Repository 조회도메인 객체 탐색도메인 로직 내에서 객체를 자연스럽게 탐색할 때 사용검증, 쓰기 작업 시 사용검증 로직 별로 필요한 애그리거트 루트의 하위 애그리거트 fetch join도메인 로직이 객체지향적으로 상태를 관리할 수 있도록이때만 양방향 연관관계 사용직접 Repository 조회애그리거트 루트에서 객체를 조회할 때 사용단순 읽기 작업 시 사용도메인 객체..