From 83cac44d7b81b70d9fca9737eb81b38e79fb2a35 Mon Sep 17 00:00:00 2001 From: Kohseoyoung Date: Thu, 18 Jun 2026 22:45:59 +0900 Subject: [PATCH] =?UTF-8?q?10=EC=A3=BC=EC=B0=A8=20=ED=82=A4=EC=9B=8C?= =?UTF-8?q?=EB=93=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- keyword/chapter10/keyword.md | 211 +++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 keyword/chapter10/keyword.md diff --git a/keyword/chapter10/keyword.md b/keyword/chapter10/keyword.md new file mode 100644 index 0000000..17da2f0 --- /dev/null +++ b/keyword/chapter10/keyword.md @@ -0,0 +1,211 @@ +- 클라우드 컴퓨팅이란? + + ### 클라우드 컴퓨팅 + + - 인터넷을 통해 온디맨드로 IT 리소스를 제공하고 종량제 요금을 지불하는것. 물리 서버를 직접 사고 관리하는 대신, AWS 같은 공급자한테서 필요에 따라 컴퓨팅 파워, 스토리지, 데이터베이스 같은 기술 서비스에 액세스 하는 방식. + - ⇒ 남의 서버를 인터넷으로 빌려 쓰고, 쓴 만큼만 냄. + + ### 이점 4가지 + + 1. **민첩성:** 컴퓨팅, 스토리지, DB로부터 ML분석까지 단 몇 분 만에 기술 서비스를 배포가능 + 2. **탄력성:** 미리 오버 프로비저닝할 필요 없이, 수요에 따라 즉시 확장/축소 + - ⇒ **오버 프로비저닝(over-provisioning)** = 필요한 것보다 자원을 미리 너무 많이 마련해두는 것. + 3. **비용 절감:** 고정 비용을 가변 비용으로 전환하고 사용량만큼만 지불 + 4. **글로벌 배포:** 클릭 몇 번으로 여러 물리적 위치에 애플리케이션을 배포, 사용자와 가까워 지연 시간 단축 + + ### 서비스 유형 (IaaS / PaaS / SaaS) + + - 클라우드는 제어 범위에 따라 세 유형으로 나뉨. 위로 갈수록 직접 관리할 게 많고, 아래로 갈수록 다 맡김. + + | 유형 | 제공 범위 | 신경 써야되는 부분 | 비유 | + | --- | --- | --- | --- | + | IaaS | 네트워킹, 컴퓨터(가상/전용 하드웨어), 데이터 스토리지 | OS, 런타임, 앱 전부 | 빈 땅 빌리기 | + | PaaS | 인프라+하드웨어와 운영체제까지 관리해줌 | 앱 배포, 관리에만 집중 | 골조 올린 집 | + | SaaS | 서비스 공급자가 실행, 관리하는 완전한 제품 | 사용법만 | 입주만하면 됨 | + - **IaaS**는 IT 리소스에 대한 최고 수준의 유연성과 관리 제어 기능을 줘서, 기존 IT 환경과 가장 비슷 + - **PaaS**는 리소스 구매, 용량 계획, 소프트웨어 유지 관리, 패치 작업 같은 잡일에서 해방 + - **SaaS**는 기본 인프라를 관리하는 방법에 대해 생각할 필요 없이 그냥 쓰면 되고, 웹 이메일이 대표 예시 +- AWS? GCP? + + ### AWS + + - 아마존이 만든 클라우드 서비스. 2006년에 시작한 가장 오래된 퍼블릭 클라우드로, 서버·저장소·DB 등을 빌려주는 종합 플랫폼 + - **장점** + - 서비스가 제일 많음 (200개 이상) + - 가장 오래되고 커뮤니티가 가장 큼 - 자료, 강의가 압도적으로 많음 + - 파트너 생태계가 넓고 안정적 + - **단점** + - 과금 구조가 복잡 - 특히 데이터 전송 비용이 헷갈림 + - 콘솔(화면) UX가 GCP보다 복잡 - 처음엔 어려움 + + ### GCP + + - 구글이 만든 클라우드 서비스. 후발주자지만 빅쿼리 등 빅데이터, ML 영역에 특화 + - **장점** + - 데이터 분석·AI/ML에 특 (BigQuery, Vertex AI) + - 쿠버네티스(GKE)가 가장 성숙 + - 콘솔이 깔끔하고 문서가 좋음 + - **단점** + - 서비스 범위가 AWS보다 좁음 + - 서비스 폐기(없애는) 이력이 많아 신뢰도 우려 + + ### 언제 어떤 걸 사용? + + - **데이터 분석·AI가 핵심** → GCP (BigQuery + Vertex AI 조합이 압도적) + - **쿠버네티스 중심** → GCP (GKE Autopilot이 최고의 K8s 경험 제공) + - **서비스 다양성·안정성·생태계 중요** → AWS + - **비용 최우선** → GCP(지속 사용 할인) 또는 AWS(Graviton + Spot) +- 환경변수 처리 방법과 왜 환경변수로 민감 정보를 가려야 하는가? + + ### 왜 민감 정보를 환경 변수로 가려야 하는가? + + 1. **깃허브 유출 위험 (제일 중요)** + - 코드에 DB 비밀번호나 JWT 시크릿을 직접 적어두면, 그 코드를 GitHub에 올리는 순간 **전 세계에 공개** + 2. **환경마다 값이 다름** + - 개발할 때 쓰는 DB와 실제 서비스 DB는 주소·비밀번호가 다름 + - 드에 박아두면 환경이 바뀔 때마다 코드를 고쳐야 하는데, 환경 변수로 빼두면 코드는 그대로 두고 값만 바꾸면 됨 + 3. **협업 시 안전** + - 팀원끼리 코드는 공유하되, 민감한 값은 각자 따로 관리 + + ### 환경 변수 처리 방법 (Spring Boot) + + 1. 1단계: application.yml에서 `${}`로 참조 + - `${환경변수이름}`을 적어주면, 그 application 파일로 기동되는 Spring Boot 앱이 속한 OS의 환경 변수 값을 사용할 수 있음 + + ```jsx + jwt: + secret-key: ${JWT_SECRET_KEY} + + spring: + datasource: + password: ${DB_PASSWORD} + ``` + + 2. 2단계: 실제 값은 환경 변수로 설정 + - `.env`파일: 파일을 별도로 정의해서 사용하는 흔한 방법 + - `export` 명령: 리눅스 계열이면 매번 export로 설정하거나 쉘 설정 파일에 추가 + - 컨테이너 파라미터: 도커 같은 컨테이너에서 파라미터로 넘겨주기 + - IDE 설정: IntelliJ에서 실행 구성에 환경 변수 직접 입력 + 3. 3단계: `.gitignore`에 `.env` 추가 (필수) + - `.env` 파일 자체는 실제 비밀값이 들어있으니 절대 깃허브에 올라가면 안 된다. 그래서 `.gitignore`에 꼭 넣어야 함 +- yml 환경 분리 방법 + + ### 환경 분리(Profile)란? + + - 환경 분리란 개발 단계(local/dev/prod)마다 설정을 따로 나눠두고, 실행할 때 골라 쓰는 것 + - 같은 프로젝트라도 내 컴퓨터(local), 개발 서버(dev), 실제 운영 서버(prod)는 사용하는 DB가 모두 다르고, DB가 다르면 접속 정보(주소·비밀번호)도 전부 다름 + - 설정을 하나로만 두면 환경이 바뀔 때마다 코드를 고쳐야 하므로, 환경별로 설정을 분리하여 관리 + - **대표적인 환경 구분** + 1. local: 내 컴퓨터에서 개발하는 환경 + 2. dev: 팀이 함께 테스트하는 개발 서버 환경 + 3. prod: 실제 사용자가 쓰는 운영 서버 환경 + + ### 환경 분리 방법 + + 1. **파일을 나눠서 관리** + - resources 폴더에 환경별 설정 파일을 따로 둠 + - application.yml은 공통 설정 + - application-local.yml은 로컬 전용 + - application-dev.yml은 개발 서버 전용 + - application-prod.yml은 운영 서버 전용 + - 환경별로 분리된 파일들은 application.yml을 오버라이딩(덮어쓰기)해서 사용 + - 따라서 공통 설정은 application.yml에 작성하고, 필요한 부분만 환경별 파일에서 오버라이드 + + ```jsx + // 공통 파일(application.yml)에서는 어떤 환경을 켤지 지정 + spring: + profiles: + active: local # 기본으로 local 환경 사용 + ``` + + ```jsx + // 환경별 파일(application-prod.yml)에서는 그 환경에서만 적용할 설정을 작성 + spring: + config: + activate: + on-profile: prod + datasource: + url: jdbc:mysql://운영DB주소:3306/proddb + username: ${DB_USERNAME} + password: ${DB_PASSWORD} + ``` + + 2. 한 파일 안에서 `---`로 나누기 + - application.yml 파일 하나로 여러 프로파일을 관리할 수도 있으며, 환경별로 나눌 때는 `---` 구분자를 사용 + + ```jsx + # 기본(공통) 설정 + spring: + profiles: + default: local + --- + # dev 환경 + spring: + config: + activate: + on-profile: dev + datasource: + url: jdbc:mysql://dev주소:3306/devdb + --- + # prod 환경 + spring: + config: + activate: + on-profile: prod + datasource: + url: jdbc:mysql://prod주소:3306/proddb + ``` + + - **실행할 환경을 정하는 법** + - IntelliJ에서는 Edit Configurations로 들어가 Active profiles 부분에 원하는 profile명을 입력하면 그 설정으로 실행 + - 아무 설정 없이 실행하면 default로 지정해둔 환경으로 실행 + - 빌드 후 명령줄에서는 실행 시점에 프로파일을 지정할 수 있음 + + ```jsx + java -jar myapp.jar --spring.profiles.active=prod + ``` + + - 주의사항 + 1. 민감 정보는 profile로 나눠도 여전히 환경 변수로 처리 + 2. properties와 yml을 동시에 사용하지 않음 + - application.properties와 application.yml이 같이 있으면 properties가 나중에 로드되어 yml에 정의한 설정을 덮어쓸 수 있기 때문 +- Docker와 .jar vs Docker 이미지 + + ### .jar 배포란? + + - .jar는 Spring Boot 프로젝트를 하나로 묶은 실행 파일 + - Spring Boot에서의 배포는 보통 Maven이나 Gradle로 빌드한 application.jar를 Java 실행 환경(Java Runtime)이 구성된 서버에 복사해서 실행하기만 하면 됨 + - 즉 `.\gradlew.bat bootJar`로 jar를 만들고, 서버에서 `java -jar app.jar`로 실행하는 방식 + - **단점** + - 서버에 **Java가 미리 깔려 있어야** 함 + - Java 버전이 다르거나 환경이 다르면 문제가 생길 수 있음 + + ### Docker 이미지란? + + - Docker 이미지는 앱 + 실행 환경(Java 등)을 통째로 묶은 "박제된 상자” + - 도커 이미지는 읽기 전용 파일이라 처음 빌드한 이후로 상태값이 변하지 않으며, 에러가 발생하지 않을 때의 환경이 그대로 이미지로 박제 + - **장점** + - 서버 환경에 구애받지 않고 실행이 가능함 + - 즉, jar만 옮기는 게 아니라 Java 환경까지 같이 싸들고 가는 셈이라, 어느 서버에서든 똑같이 돌아감 + + ### **이미지 vs 컨테이너** + + - 이미지와 컨테이너는 다른 개념 + - 도커 컨테이너는 실행 중인 이미지를 의미함 + - 실행 후 변경 사항(DB 변경, 서비스 추가 등)은 이미지와 별도로 컨테이너 안에 저장되며, 컨테이너를 삭제하면 함께 삭제됨 + - 비유: 이미지는 붕어빵 틀, 컨테이너는 그 틀로 찍어낸 붕어빵 (틀 하나로 붕어빵 여러 개를 똑같이 찍어낼 수 있음) + + ### **.jar vs Docker 이미지** + + | 구분 | .jar 배포 | Docker 이미지 배포 | + | --- | --- | --- | + | 묶는 범위 | 앱 코드만 | 앱 + 실행 환경 전부 | + | 서버 준비 | Java 미리 설치 필요 | Java 설치 불필요 | + | 환경 일관성 | 서버마다 다를 수 있음 | 어디서든 동일하게 작동 | + | 실행 방법 | `java -jar app.jar` | `docker run 이미지명` | + + ### **.jar와 Docker 이미지의 관계** + + - 둘은 같은 게 아니라 jar가 Docker 이미지 안에 들어가는 포함 관계 + - jar = 실행할 내용물, Docker = 그 내용물을 어디서든 똑같이 돌게 포장한 것 + - 배포 흐름도 보통 jar를 먼저 만들고 → 그걸 Docker 이미지로 감싸는 순서 \ No newline at end of file