Azure 스토리지 계정

스토리지 계정은 HTTP 또는 HTTPS를 통해 전 세계 어디에서나 액세스할 수 있는 Azure Storage 데이터에 고유한 네임스페이스를 제공합니다. 이 계정의 데이터는 안전하고 가용성과 내구성이 높으며 대규모 확장이 가능합니다.

스토리지 계정을 만들 때 먼저 스토리지 계정 유형을 선택합니다. 계정 유형은 스토리지 서비스 및 중복 옵션을 결정하고 사용 사례에 영향을 줍니다. 다음은 이 모듈의 뒷부분에서 다룰 중복 옵션 목록입니다.

• LRS(로컬 중복 스토리지)
• GRS(지역 중복 스토리지)
• RA-GRS(읽기 액세스 지역 중복 스토리지)
• ZRS(영역 중복 스토리지)
• GZRS(지역 영역 중복 스토리지)
• RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)

HTTP 또는 HTTPS

HTTP와 HTTPS의 차이점

HTTP와 HTTPS는 모두 웹 브라우저와 웹 서버 간 데이터를 전송하기 위한 프로토콜이지만, 보안성과 데이터 처리 방식에서 큰 차이가 있습니다. 아래는 두 프로토콜의 주요 차이점과 작동 방식을 설명합니다.

1. HTTP (Hypertext Transfer Protocol)

특징

• 데이터 전송 방식: HTTP는 데이터를 암호화하지 않고 **평문(plaintext)**으로 전송합니다.
• 보안성: 암호화가 없기 때문에 도청(eavesdropping), 중간자 공격(Man-in-the-Middle, MITM) 등에 취약합니다.
• 포트 번호: 기본적으로 포트 80을 사용합니다.
• 사용 사례: 과거의 간단한 텍스트 기반 웹사이트에서 주로 사용되었습니다.

작동 방식

1. 사용자가 브라우저에 URL을 입력하면 HTTP 요청이 생성됩니다.
2. 요청은 인터넷을 통해 여러 네트워크를 거쳐 서버에 도달합니다.
3. 서버는 요청을 처리하고 HTML, 이미지, 텍스트 등의 응답 데이터를 클라이언트에 반환합니다.
4. 클라이언트는 받은 데이터를 평문으로 표시합니다.

취약점

• 데이터가 암호화되지 않으므로 네트워크 상에서 쉽게 가로채거나 수정할 수 있습니다.
• 공용 Wi-Fi와 같은 비보안 네트워크에서는 특히 위험합니다.

2. HTTPS (Hypertext Transfer Protocol Secure)

특징

• 데이터 전송 방식: HTTPS는 HTTP에 보안 계층인 SSL/TLS를 추가하여 데이터를 암호화합니다.
• 보안성: 데이터를 암호화하여 도청 및 중간자 공격을 방지하며, 데이터 무결성을 보장합니다.
• 포트 번호: 기본적으로 포트 443을 사용합니다.
• 사용 사례: 현대의 모든 웹사이트, 특히 로그인 페이지, 결제 시스템 등 민감한 데이터를 처리하는 사이트에서 필수적입니다.

작동 방식

1. 사용자가 HTTPS URL을 입력하면 브라우저가 서버에 SSL/TLS 인증서를 요청합니다.
2. 서버는 인증서를 제공하며, 브라우저는 이를 검증하여 신뢰성을 확인합니다.
3. 브라우저와 서버 간에 암호화 키를 교환하여 안전한 연결(SSL/TLS 핸드셰이크)을 설정합니다.
4. 이후 모든 데이터는 암호화된 상태로 전송됩니다.

보안 메커니즘

• 암호화(Encryption): 데이터를 암호화하여 제3자가 내용을 읽지 못하도록 보호합니다.
• 인증(Authentication): SSL/TLS 인증서를 통해 서버의 신원을 확인합니다.
• 데이터 무결성(Data Integrity): 데이터가 전송 중 변경되지 않았음을 보장합니다.

HTTP와 HTTPS 비교

항목HTTPHTTPS

풀네임	Hypertext Transfer Protocol	Hypertext Transfer Protocol Secure
보안성	없음 (평문 데이터 전송)	SSL/TLS를 통한 암호화 및 인증 제공
포트 번호	80	443
데이터 암호화	지원하지 않음	지원 (TLS/SSL로 암호화)
사용 사례	간단한 정보 제공 웹사이트	로그인, 결제 등 민감 정보 처리 웹사이트
신뢰성 표시	브라우저에서 "Not Secure"로 표시 가능	브라우저 주소창에 자물쇠 아이콘 표시

 

HTTPS 사용의 이점

1. 보안 강화
   • 데이터가 암호화되어 도청과 공격으로부터 보호됩니다.
   • 민감한 정보를 다루는 사이트(예: 은행, 전자상거래)에 필수적입니다.
2. SEO 향상
   • Google과 같은 검색 엔진은 HTTPS를 사용하는 웹사이트를 더 높은 순위로 표시합니다.
3. 사용자 신뢰도 증가
   • 브라우저 주소창에 자물쇠 아이콘이 표시되어 사용자가 사이트를 신뢰할 수 있습니다.
4. 데이터 무결성 보장
   • 중간 경로에서 데이터가 변경되지 않도록 보호합니다.

결론

HTTPS는 HTTP의 확장판으로, 현대 인터넷 환경에서 보안을 강화하기 위해 필수적인 프로토콜입니다. 특히 민감한 정보를 처리하는 모든 웹사이트는 HTTPS를 사용해야 하며, 이를 통해 사용자 신뢰도와 검색 엔진 최적화를 동시에 달성할 수 있습니다.

 

Azure 스토리지 : 형식지원되는 서비스중복 옵션사용 현황

표준 범용 v2	Blob Storage(Data Lake Storage 포함), Queue Storage, Table Storage, Azure Files	LRS, GRS, RA-GRS, ZRS, GZRS, RA-GZRS	Blob, 파일 공유, 큐 및 테이블에 대한 Standard Storage 계정 유형 대부분의 시나리오에 대해 Azure Storage를 사용하는 것이 좋습니다. Azure Files에서 NFS(네트워크 파일 시스템)를 지원하려면 프리미엄 파일 공유 계정 형식을 사용하세요.
Premium 블록 Blob	Blob Storage(Data Lake Storage 포함)	LRS, ZRS	블록 Blob 및 추가 Blob에 대한 프리미엄 스토리지 계정 유형입니다. 트랜잭션 속도가 높은 시나리오나, 더 작은 개체를 사용하거나 일관되게 짧은 스토리지 대기 시간이 필요한 시나리오에 권장됩니다.
프리미엄 파일 공유	Azure 파일	LRS, ZRS	파일 공유 전용 프리미엄 스토리지 계정 유형입니다. 엔터프라이즈 또는 고성능 규모의 애플리케이션에 추천됩니다. SMB(서버 메시지 블록) 및 NFS 파일 공유를 모두 지원하는 스토리지 계정을 원하는 경우 이 계정 형식을 사용합니다.
프리미엄 페이지 Blob	페이지 Blob만 해당	LRS	페이지 Blob에 대한 프리미엄 스토리지 계정 유형입니다.

Storage 계정 엔드포인트

Azure Storage 계정을 사용할 경우의 이점 중 하나는 데이터에 대해 Azure에 고유한 네임스페이스를 갖는 것입니다. 이렇게 하려면 Azure의 모든 스토리지 계정에 고유한 Azure 계정 이름이 있어야 합니다. 계정 이름과 Azure Storage 서비스 엔드포인트의 조합이 스토리지 계정의 엔드포인트가 됩니다.

스토리지 계정의 이름을 지정할 때는 다음 규칙에 유의하세요.

• Storage 계정 이름은 3자에서 24자 사이여야 하고 숫자 및 소문자만 포함할 수 있습니다.
• 스토리지 계정 이름은 Azure 내에서 고유해야 합니다. 두 개의 스토리지 계정이 같은 이름을 사용할 수 없습니다. Azure에서 액세스 가능한 고유한 네임스페이스를 사용할 수 있는 기능을 지원합니다.

다음 표에는 Azure Storage 서비스의 엔드포인트 형식이 나와 있습니다.

테이블 확장

스토리지 서비스엔드포인트

Blob Storage	https://<storage-account-name>.blob.core.windows.net
Data Lake Storage Gen2	https://<storage-account-name>.dfs.core.windows.net
Azure 파일	https://<storage-account-name>.file.core.windows.net
Queue storage	https://<storage-account-name>.queue.core.windows.net
Table Storage	https://<storage-account-name>.table.core.windows.net

 

Blob Storage

 

 

 

Blob Storage 개요

Blob Storage는 **"Binary Large Object"**의 약자로, 대규모 비정형 데이터를 저장하기 위한 클라우드 기반 객체 스토리지입니다. Microsoft Azure Blob Storage는 이러한 데이터를 효율적으로 관리하고 저장할 수 있는 확장성 있고 비용 효율적인 솔루션을 제공합니다. 비정형 데이터란 특정 데이터 모델이나 스키마에 맞지 않는 데이터를 의미하며, 텍스트, 이미지, 비디오, 로그 파일 등이 포함됩니다.

주요 특징

1. 확장성
   • Blob Storage는 데이터가 증가함에 따라 자동으로 확장되며, 최대 수 페타바이트(PB)까지 저장 가능합니다.
2. 비용 효율성
   • 데이터 액세스 빈도에 따라 핫(Hot), 쿨(Cool), 아카이브(Archive) 계층으로 나뉘어 비용을 최적화합니다.
   • Azure Storage는 Blob Storage에 대해 서로 다른 액세스 계층을 제공하기 때문에 비용 효율적인 방식으로 개체 데이터를 저장할 수 있습니다. 사용 가능한 액세스 계층은 다음과 같습니다.
     • 핫 액세스 계층: 자주 액세스하는 데이터(예: 웹 사이트의 이미지)를 저장하는 데 최적화되어 있습니다.
     • 쿨 액세스 계층: 자주 액세스하지 않고 30일 이상 저장하는 데이터(예: 고객에 대한 송장)에 최적화되어 있습니다.
     • 콜드 액세스 계층: 자주 액세스하지 않으며 최소 90일 동안 저장되는 데이터 저장용으로 최적화된 계층입니다.
     • 보관 액세스 계층: 거의 액세스하지 않고 180일 이상 보관하며 유연한 대기 시간 요구 사항(예: 장기 백업)이 있는 데이터에 적합합니다.
3. 보안
   • 데이터 암호화 및 Azure Active Directory와 통합된 인증 기능을 통해 안전하게 데이터를 보호합니다.
4. 유연한 접근성
   • HTTP/HTTPS를 통해 어디서든 데이터에 접근 가능하며, 다양한 프로그래밍 언어(.NET, Python, Java 등)를 지원합니다.
5. 내구성과 가용성
   • 99.99999999999999%의 설계 내구성과 지역 복제를 통한 높은 가용성을 제공합니다.

Blob Storage의 구성 요소

1. Storage Account (저장소 계정)
   • 모든 Blob 데이터를 저장하는 기본 단위로, 여러 컨테이너를 포함할 수 있습니다.
2. Container (컨테이너)
   • Blob을 조직화하는 논리적 그룹으로 디렉토리처럼 작동합니다.
   • 하나의 컨테이너에는 무제한의 Blob을 저장할 수 있습니다.
3. Blob (블롭)
   • 실제로 저장되는 데이터 단위입니다. Blob에는 세 가지 유형이 있습니다:
     • Block Blob: 대규모 텍스트 및 바이너리 파일(예: 문서, 이미지) 저장에 적합.
     • Append Blob: 로그 파일과 같이 추가 작업이 많은 데이터에 사용.
     • Page Blob: 임의 읽기/쓰기 작업이 필요한 VHD(가상 하드 디스크) 파일에 최적화.

주요 사용 사례

1. 미디어 스트리밍
   • 오디오 및 비디오 파일을 저장하고 스트리밍 서비스 제공.
2. 백업 및 복구
   • 장기 보관 및 재해 복구를 위한 데이터 백업.
3. 데이터 분석
   • 빅데이터 분석을 위한 원시 데이터를 저장하고 처리하기 위한 데이터 레이크로 활용.
4. IoT 데이터 저장소
   • IoT 기기로부터 생성된 대량의 데이터를 수집하고 관리.
5. 웹 애플리케이션 콘텐츠 제공
   • 이미지, CSS 파일 등 정적 콘텐츠를 웹 브라우저로 빠르게 제공.

Azure Blob Storage의 장점

특징설명

확장성	데이터 증가에 따라 자동으로 확장 가능
비용 효율성	데이터 액세스 빈도에 따른 계층화를 통해 비용 절감
보안성	Azure Active Directory와 통합된 인증 및 암호화 지원
다양한 통합 옵션	Azure Functions, Data Factory 등과 통합하여 다양한 워크로드 지원
글로벌 접근성	HTTP/HTTPS를 통해 전 세계 어디서든 데이터 접근 가능

 

Azure Blob Storage와 다른 스토리지 비교

스토리지 유형특징

Blob Storage	비정형 데이터를 위한 객체 스토리지로 대규모 데이터 처리에 적합
File Storage	공유 네트워크 드라이브처럼 작동하며 구조화된 데이터를 관리
Block Storage	고성능 읽기/쓰기 작업이 필요한 데이터베이스 또는 애플리케이션에 적합

 

Azure Blob Storage는 대규모 비정형 데이터를 효율적으로 관리하고 다양한 클라우드 애플리케이션과 통합할 수 있는 강력한 솔루션입니다. 이를 통해 기업은 빅데이터 분석, 미디어 스트리밍, 백업 및 복구 등 다양한 요구 사항을 충족할 수 있습니다.

 

 

REST  API  개요 

REST API(Representational State Transfer API)는 **웹 기반 애플리케이션**과 **서비스 간의 데이터 교환**을 위한 설계 원칙과 규칙을 따르는 **애플리케이션 프로그래밍 인터페이스(API)**입니다. REST는 2000년 Roy Fielding 박사가 제안한 아키텍처 스타일로, 간단하고 확장 가능하며 유연한 통신 방식을 제공합니다[1][3][7].

---

## REST API의 주요 특징

1. **리소스 기반 설계**  
   - 모든 데이터와 기능은 **리소스**로 표현되며, 각 리소스는 고유한 URI(Uniform Resource Identifier)로 식별됩니다.  
   - 예: `https://api.example.com/users/123` → ID가 123인 사용자 리소스.

2. **HTTP 메서드 사용**  
   - REST API는 HTTP 메서드를 사용하여 리소스를 처리합니다:
     - `GET`: 리소스 조회.
     - `POST`: 새로운 리소스 생성.
     - `PUT`: 기존 리소스 업데이트.
     - `DELETE`: 리소스 삭제[3][5].

3. **상태 비저장성 (Statelessness)**  
   - 클라이언트와 서버 간의 요청은 독립적이며, 서버는 이전 요청의 상태를 저장하지 않습니다.  
   - 요청에 필요한 모든 정보는 자체적으로 포함되어야 합니다[2][4].

4. **데이터 표현 형식**  
   - JSON(JavaScript Object Notation) 또는 XML 형식으로 데이터를 주고받습니다. JSON이 더 가볍고 읽기 쉬워 일반적으로 선호됩니다[3][5].

5. **캐싱 지원**  
   - HTTP 캐싱 헤더를 사용하여 클라이언트 또는 서버 측에서 자주 요청되는 리소스를 캐싱해 성능을 최적화합니다[4][8].

6. **자체 설명 메시지(Self-Descriptive Messages)**  
   - 각 요청과 응답은 메시지 자체에 처리 방법과 관련된 충분한 정보를 포함합니다.

7. **HATEOAS (Hypermedia as the Engine of Application State)**  
   - 클라이언트는 초기 URI만 알고, 이후에는 서버가 제공하는 하이퍼링크를 통해 다른 리소스에 접근합니다[8].

---

## REST API 작동 방식

1. **클라이언트 요청**  
   클라이언트는 특정 URI로 HTTP 요청(예: GET, POST)을 보냅니다.

2. **서버 처리**  
   서버는 요청을 처리하고, 필요한 데이터를 JSON 또는 XML 형식으로 응답합니다.

3. **응답 코드**  
   서버는 HTTP 상태 코드를 통해 요청 결과를 전달합니다:
   - `200 OK`: 성공.
   - `201 Created`: 리소스 생성 성공.
   - `404 Not Found`: 리소스 없음.
   - `500 Internal Server Error`: 서버 오류.

---

## REST API의 장점

1. **확장성**: 상태 비저장성과 표준화된 HTTP 메서드를 통해 대규모 시스템에서도 효율적으로 작동합니다[2][6].  
2. **유연성**: 다양한 프로그래밍 언어와 데이터 형식을 지원하며, 클라이언트와 서버가 독립적으로 개발될 수 있습니다[1][4].  
3. **표준화된 인터페이스**: HTTP 기반의 표준화된 설계를 통해 이해하기 쉽고 구현이 간단합니다[6].  
4. **캐싱 활용**: 캐싱을 통해 성능을 최적화하고 네트워크 부하를 줄일 수 있습니다[8].  

---

## REST API와 다른 API 비교

프로토콜	HTTP	HTTP, SMTP 등 다양한 프로토콜 사용	HTTP
데이터 형식	JSON, XML	XML	JSON
상태 관리	Stateless	Stateful	Stateless
유연성 및 확장성	높음	낮음	매우 높음
사용 사례	웹 및 모바일 애플리케이션	금융 및 엔터프라이즈 시스템	동적 쿼리가 필요한 애플리케이션

---

REST API는 현대 웹 및 모바일 애플리케이션에서 가장 널리 사용되는 통신 방식으로, 간단하고 효율적인 데이터 교환을 제공합니다. 이를 통해 개발자는 확장 가능하고 유지보수가 용이한 시스템을 구축할 수 있습니다.

 

GET, POST 명령어

GET과 POST 명령어 개요

GET과 POST는 HTTP 프로토콜에서 가장 널리 사용되는 HTTP 메서드입니다. 클라이언트(예: 웹 브라우저 또는 애플리케이션)가 서버와 통신할 때, 특정 작업을 요청하기 위해 사용됩니다. 두 메서드는 주로 REST API와 같은 웹 기반 애플리케이션에서 데이터를 요청하거나 전송하는 데 사용됩니다.

1. GET 명령어

특징

• 목적: 서버에서 데이터를 조회(read)하기 위한 요청입니다.
• 데이터 전송 방식: 요청 데이터는 URL의 쿼리 문자열에 포함됩니다.
  • 예: https://api.example.com/users?id=123
• 안전성: 서버의 상태를 변경하지 않으므로 "안전한" 메서드로 간주됩니다.
• 캐싱 가능성: GET 요청은 캐싱이 가능하며, 브라우저나 프록시 서버가 요청 결과를 저장할 수 있습니다.
• 길이 제한: URL에 데이터를 포함하므로 브라우저 또는 서버에 따라 길이 제한이 있을 수 있습니다.

사용 사례

1. 특정 리소스 조회:
   • 예: 사용자 정보 가져오기 → GET /users/123
2. 검색 기능:
   • 예: 검색어를 전달하여 결과 반환 → GET /search?q=example

2. POST 명령어

특징

• 목적: 서버에 데이터를 전송하거나 리소스를 생성(create)하기 위한 요청입니다.
• 데이터 전송 방식: 요청 본문(body)에 데이터를 포함하여 전송합니다.
  • 예: JSON, XML, 또는 HTML 폼 데이터.
• 안전성: POST는 서버의 상태를 변경할 수 있으므로 "안전하지 않은" 메서드로 간주됩니다.
• 캐싱 불가능: POST 요청은 기본적으로 캐싱되지 않습니다.

사용 사례

1. 새로운 리소스 생성:
   • 예: 새로운 사용자 등록 → POST /users
   • 요청 본문(body):
   •  

     json

     { "name": "John Doe", "email": "john@example.com" }
2. 데이터 처리:
   • 예: 로그인 정보 제출 → POST /login
   • 요청 본문(body):
   •  

     json

     { "username": "user123", "password": "securepassword" }

GET과 POST의 차이점

특징GETPOST

목적	데이터 조회 (read)	데이터 전송 및 리소스 생성 (create)
데이터 위치	URL 쿼리 문자열에 포함	HTTP 본문(body)에 포함
보안성	민감한 데이터 노출 가능 (URL에 표시됨)	더 안전 (데이터가 본문에 숨겨짐)
캐싱 가능 여부	캐싱 가능	기본적으로 캐싱 불가능
URL 길이 제한	있음	없음
서버 상태 변경 여부	변경하지 않음	변경 가능

 

사용 예시

GET 요청

 

text

GET /users/123 HTTP/1.1 Host: api.example.com

• 서버는 ID가 123인 사용자 정보를 반환합니다.

POST 요청

 

text

POST /users HTTP/1.1 Host: api.example.com Content-Type: application/json { "name": "Jane Doe", "email": "jane@example.com" }

• 서버는 새로운 사용자 정보를 받아 저장하고, 생성된 리소스의 정보를 반환합니다.

결론

• GET은 데이터를 조회할 때 사용되며, 서버의 상태를 변경하지 않습니다.
• POST는 데이터를 전송하거나 새로운 리소스를 생성하는 데 사용되며, 서버의 상태를 변경할 수 있습니다.

두 메서드는 RESTful API 설계에서 핵심적인 역할을 하며, 목적에 맞게 적절히 선택하여 사용하는 것이 중요합니다.