Now Loading ...
-
(CI/CD) Github Actions Secret의 JSON 파일 저장 오류
구글 인앱결제 서비스 로직을 구현할 때 겪은 오류이다.
1. 오류 발생 상황
전체 코드
// InAppPurchaseService.java
@Service
public class InAppPurchaseService {
@Value("${google-account.file-path}")
private String googleAccountFilePath;
@Value("${google-application.package-name}")
private String googleApplicationPackageName;
@Transactional
public Boolean validateReceipt(Long userId, PurchaseRequest purchaseRequest) {
HttpTransport httpTransport;
GoogleCredentials credentials;
try {
httpTransport = GoogleNetHttpTransport.newTrustedTransport();
InputStream inputStream = new ClassPathResource(googleAccountFilePath).getInputStream();
credentials = GoogleCredentials
.fromStream(inputStream)
.createScoped(AndroidPublisherScopes.ANDROIDPUBLISHER);
} catch (IOException | GeneralSecurityException e) {
throw ExpectedException.withLogging(ResponseCode.GoogleCredentialException, e);
}
AndroidPublisher.Builder builder = new AndroidPublisher.Builder(httpTransport,
GsonFactory.getDefaultInstance(),
new HttpCredentialsAdapter(credentials));
AndroidPublisher publisher = builder.setApplicationName(googleApplicationPackageName).build();
//...(중략)
}
}
# ci-cd.yml
jobs:
CI-CD:
runs-on: ubuntu-22.04
steps:
# ...(중략)
- name: Create Google key.json file
if: contains(github.ref, 'main') || contains(github.ref, 'staging')
run: |
cd ./genti-api/src/main/resources
mkdir -p ./jsonkey
echo "${secrets.GOOGLE_ACCOUNT_KEY }" > ./jsonkey/key.json
shell: bash
# ...(중략)
오류 메세지
com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 2 column 4 path $.
2. 오류 분석
코드 오류 부분
// InAppPurchaseService.java
public Boolean validateReceipt(Long userId, PurchaseRequest purchaseRequest) {
//...
try {
//...
credentials = GoogleCredentials
.fromStream(inputStream) // 오류 발생 부분
.createScoped(AndroidPublisherScopes.ANDROIDPUBLISHER);
}
//...
}
오류 분석
오류 메시지를 보면, JSON 파싱 중 문제가 있다고 한다. 로컬에서는 발생하지 않던 오류라서, 서버 측에 저장되는 JSON 파일에 문제가 있을 것으로 추측했다.
따라서, 서버 측에 저장되는 JSON 파일을 확인하기 위해 해당 JSON 파일을 S3에 저장하는 부분을 ci-cd.yml에 임시로 추가했다.
- name: Upload key.json to S3
if: contains(github.ref, 'staging')
run: |
aws s3 cp ./genti-api/src/main/resources/jsonkey/key.json s3://$S3_BUCKET_NAME/jsonkey/key.json
S3에서 key.json 파일을 다운받아 확인해보았더니, 아래처럼 큰따옴표가 다 사라져 있었다.
{
type: service_account,
project_id: example,
(...)
}
결론 - 오류의 원인
Github Actions Secret에 JSON 파일 내용을 넣으면 JSON 파일 내용의 큰따옴표가 다 사라지게 된다.
3. 오류 해결
create-json 라이브러리 사용
# ci-cd.yml
- name: Create jsonkey directory
if: contains(github.ref, 'main') || contains(github.ref, 'staging')
run: mkdir -p ./genti-api/src/main/resources/jsonkey
- name: Create Google key.json file
if: contains(github.ref, 'main') || contains(github.ref, 'staging')
id: create-json
uses: jsdaniell/create-json@1.1.2
with:
name: "./genti-api/src/main/resources/jsonkey/key.json"
json: ${ secrets.GOOGLE_ACCOUNT_KEY }
참조 자료
https://stackoverflow.com/questions/11484353/gson-throws-malformedjsonexception
https://choo.oopy.io/fd2d4fc6-21ac-45b6-bd0c-05768920bb00
https://roel-yomojomo.tistory.com/38
https://velog.io/@godkimchichi/Github-Actions-secret%EC%97%90-json-%EB%84%A3%EA%B3%A0-%EC%8B%B6%EC%9D%84-%EB%95%8C
-
(JPA) 삭제 상태 Entity(객체)를 merge()할 때 발생하는 ObjectDeletedException
Spring Data JPA를 쓰고 있는 Repository 계층의 단위 테스트를 작성할 때 겪은 오류이다.
1. 오류 발생 상황
전체 코드
@DataJpaTest
public class ResponseExampleRepositoryTest {
@Autowired
ResponseExampleRepository responseExampleRepository;
private List<ResponseExample> mockResponseExamples;
@BeforeEach
void setUp() {
mockResponseExamples = List.of(
createExample("피드뷰 - 예시 프롬프트1", PictureRatio.RATIO_SERO, null, FALSE),
createExample("피드뷰 - 예시 프롬프트2", PictureRatio.RATIO_SERO, null, FALSE),
createExample("피드뷰 - 예시 프롬프트3", PictureRatio.RATIO_SERO, null, FALSE),
// ..(중략)
);
responseExampleRepository.saveAll(mockResponseExamples);
}
@Test
@DisplayName("피드뷰 - 조건에 맞는 예시가 없을 때 빈 리스트가 반환되는지 검증")
void findAllFeedViewWhenNoMatchingData_Then_Return_emptyList() {
//given
responseExampleRepository.deleteAll();
responseExampleRepository.saveAll(mockResponseExamples.subList(10, mockResponseExamples.size()));
//when
List<ResponseExample> result = responseExampleRepository.findAllByPromptOnlyIsFalse();
//then
assertThat(result).isEmpty();
}
}
오류 메세지
org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.ObjectDeletedException: deleted instance passed to merge
2. 오류 분석
코드 오류 부분
@Test
@DisplayName("피드뷰 - 조건에 맞는 예시가 없을 때 빈 리스트가 반환되는지 검증")
void findAllFeedViewWhenNoMatchingData_Then_Return_emptyList() {
responseExampleRepository.deleteAll();
responseExampleRepository.saveAll(mockResponseExamples.subList(10, mockResponseExamples.size()));
// ..(중략)
}
오류 분석 요약
Hibernate의 merge()는 삭제 상태 객체를 처리할 수 없다.
merge()하려고 할 때 삭제된 객체가 포함되어 있다면 오류(ObjectDeletedException)를 던진다.
deleteAll()을 호출한 이후에 삭제된 객체를 saveAll()로 다시 저장하려고 해서 오류가 발생한 것이다.
테스트 메서드의 saveAll()에서 인자로 넣어준 객체들이 setUp 메서드의 saveAll()에서 인자로 넣어준 객체들과 같은 객체이기 때문이다.
saveAll()은 내부적으로 merge()를 사용한다.
오류 분석 상세
@DataJpaTest 어노테이션이 테스트 클래스에 붙어 있기 때문에, 각 테스트 메서드는 트랜잭션 내에서 실행된다. 또한, 각 테스트 메서드는 테스트 클래스가 실행되는 동안 하나의 트랜잭션 범위 내에서 진행된다.
@Transactional 어노테이션이 기본적으로 사용하는 전파 방식은 Propagation.REQUIRED이다. REQUEST 옵션은 현재 트랜잭션이 없으면 새로 시작하고, 이미 트랜잭션이 있으면 해당 트랜잭션에 참여하는 동작을 한다.
테스트 메서드는 @Transcational을 사용하고 있으며, deleteAll()과 saveAll()를 호출하고 있다. 이때, deleteAll()과 saveAll()은 모두 내부적으로 @Transactional 어노테이션을 사용하고 있는데, 이 메서드들을 호출하는 테스트 메서드에서 트랜잭션이 존재하기 때문에 두 메서드 모두 새로운 트랜잭션을 시작하지 않고 이미 존재하는 트랜잭션(테스트 메서드 것)에 참여한다.
스프링은 기본으로 트랜잭션 범위의 영속성 컨텍스트 전략을 사용한다. 이는 트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료한다는 의미이다. 또한, 트랜잭션이 같으면 같은 영속성 컨텍스트를 사용한다.
테스트 메서드 내의 deleteAll()과 saveAll()은 같은 트랜잭션(테스트 메서드 것)에 참여하고 있으므로 같은 영속성 컨텍스트를 사용한다.
결론 - 오류의 원인
deleteAll()과 saveAll()이 같은 영속성 컨텍스트를 사용하고 있다.
1번의 이유만으로는 오류가 발생하진 않는다. 그러나 나는 1번의 상황 속에서 deleteAll()에서 삭제된 객체를 saveAll()에서 사용하기 때문에 오류가 발생한 것이다.
3. 오류 해결
방법 1 : 삭제된 객체를 다시 저장하지 않고, 새로운 객체를 생성하여 저장
void findAllFeedViewWhenNoMatchingData_Then_Return_emptyList() {
// given
responseExampleRepository.deleteAll();
List<ResponseExample> newObjects = mockResponseExamples.subList(10, mockResponseExamples.size())
.stream()
.map(example ->
createExample(example.getExamplePrompt(),
example.getPictureRatio(),
example.getType(),
example.getPromptOnly())) // 새 객체 생성
.collect(Collectors.toList());
responseExampleRepository.saveAll(newObjects);
// ...(동일)
}
방법 2 : 영속성 컨텍스트 초기화
@PersistenceContext
private EntityManager entityManager;
void findAllFeedViewWhenNoMatchingData_Then_Return_emptyList() {
// given
responseExampleRepository.deleteAll();
entityManager.flush(); // DB와 동기화
// flush()로 데이터베이스에 반영된 변경 사항도 테스트가 끝난 후 롤백되므로
// 최종적으로 데이터는 삭제되지 않은 상태로 유지된다!
entityManager.clear(); // 영속성 컨텍스트 초기화
responseExampleRepository.saveAll(mockResponseExamples.subList(10, mockResponseExamples.size()));
// ...(동일)
}
참고 자료
https://stackoverflow.com/questions/18358407/org-hibernate-objectdeletedexception-deleted-object-would-be-re-saved-by-cascad
https://stackoverflow.com/questions/31335211/autowired-vs-persistencecontext-for-entitymanager-bean
https://www.inflearn.com/community/questions/527211/%EC%98%81%EC%86%8D%EC%84%B1-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8%EC%99%80-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-propagation?srsltid=AfmBOordQwcCFu6HJkovFm-_NBBIR6DOSjiUAWJYAvy0H_xmAGEZMWnG
https://milenote.tistory.com/107
https://insanelysimple.tistory.com/314
ChatGPT
-
데이터베이스 서버 해킹 사건
개발의 테스트 용도로, EC2 인스턴스에서 MySQL 컨테이너를 실행하여 사용하고 있었다. (로컬에서는 데이터베이스 관리 도구로 DBeaver를 사용 중이다.)
그런데.. 어제까지만 해도 잘 사용하고 있었는데 오늘 DBeaver를 켜보니..?
연결이 거부되었다고 한다. 컨테이너에 문제가 생긴 것 같아 EC2 인스턴스에서 컨테이너가 실행 중인지 확인해봤더니 컨테이너가 중지되어 있었다. 컨테이너가 중지된 이유를 확인하기 위해 컨테이너의 로그를 확인해보았다.
어제와 오늘 사이에 발생한 로그가 있었고, 위의 세부 설명처럼 MySQL 서버가 root 사용자로부터 종료 명령을 받았다고 한다. (MySQL 컨테이너는 그 안에서 실행되는 프로세스가 종료되면 종료된다.)
-> 나는 종료한 적이 없다. 따라서 다른 누군가가 MySQL 서버에 root 사용자로 로그인하여 종료했다는 것이므로, 해킹이 의심되었다.
컨테이너를 재시작하고 접속한 후, MySQL 서버에 root 사용자로 로그인하여 데이터베이스를 확인해보았다.
아니나 다를까, 내가 사용 중이던 “test” 데이터베이스가 없었다. 대신에 “RECOVER_YOUR_DATA”라는 데이터베이스가 있었고, 이 데이터베이스 안에 같은 이름의 테이블이 있었다. 이 테이블에 저장된 데이터는 위의 내용과 같은데, 요약하자면 “데이터를 살리고 싶으면 0.0123BTC를 달라”는 것이었다. (찾아보니 랜섬웨어라고 한다.)
-> 그러나, 테스트용 데이터 밖에 없어서 전혀 살릴 필요가 없었다.
컨테이너에 접속해서 MySQL 로그(/var/log/mysqld.log)도 확인해보려고 했지만, 아쉽게도 mysqld.log 파일은 비어있었다.
MySQL은 기본적으로 로그 기록하는 부분이 OFF 처리되어 있기 때문이다.
내 데이터베이스 서버를 해킹한 이유는 모르겠지만, 해킹 당한 이유를 추측해보면 다음과 같다.
EC2 인바운드 규칙에서 누구나 3306 포트로 접근 가능하도록 설정한 것 + root 사용자의 비밀번호를 1234로 설정한 것
앞으로 이런 상황을 염두해서 다음 사항들을 고려하여 개발해나가려고 한다.
백업 설정 + root 사용자의 비밀번호 설정 + 포트 번호 설정
-
API
API는 “소프트웨어 간의 인터페이스 또는 소프트웨어와 하드웨어 간의 인터페이스”라고 말할 수 있다.
“소프트웨어 간의 인터페이스” 의미에 초점을 두고 API를 좀 더 구체적으로 얘기해보자면 다음과 같다.
A 소프트웨어가 B 소프트웨어의 다양한 기능 중 하나를 이용하려고 할 때, A 소프트웨어가 B 소프트웨어에 어떻게 접근하는 지, 어떤 정보를 전달하고 어떤 정보를 받는 지 등의 통신 방법 집합을 API라고 하는 것이다. 그리고 API에 대해 기술하는 문서나 표준, 즉 설명서를 “API 문서(사양, 규격)“라고 한다.
API란?
API(Application Programming Interface) : 어떤 소프트웨어의 기능을 사용할 수 있도록 해주는 인터페이스
클라이언트는 API를 통해 다른 소프트웨어(라이브러리, 외부 서비스, 운영체제 등)에서 제공하는 기능을 사용할 수 있다.
API 제공 예시 1 : 라이브러리 API
-> 라이브러리는 기능을 호출하고 사용할 수 있도록 해주는 API를 제공한다.
-> 클라이언트에서 라이브러리에 실질적으로 접근하는 방법은 함수 호출을 통한 접근이다.
ex) Mongoose, Numpy, Pandas 등
API 제공 예시 2 : 외부 서비스 API
-> 외부 서비스는 기능을 호출하고 사용할 수 있도록 해주는 API를 제공한다.
-> 클라이언트에서 외부 서비스에 실질적으로 접근하는 방법은 대부분 URL(엔드포인트)과 HTTP 요청을 통한 접근이다.
ex) Google Maps API, Twitter API 등
API 제공 예시 3 : 애플리케이션 서버 API
-> 애플리케이션 서버는 기능을 호출하고 사용할 수 있도록 해주는 API를 제공한다.
-> 클라이언트에서 애플리케이션 서버에 실질적으로 접근하는 방법은 대부분 URL(엔드포인트)과 HTTP 요청을 통한 접근이다.
ex) 데이터 저장, 검색 등의 비즈니스 로직 => 애플리케이션(모바일, 웹)에서 사용할 백엔드 기능
Web API : 웹 기술을 기반으로 한 API
ex) HTTP API, WebSocket API 등
HTTP API : HTTP 프로토콜을 사용하여 통신하는 API
다양한 클라이언트에서 HTTP API를 호출하여 데이터(주로 JSON 형식)만 주고 받는다. UI 화면이 필요하면 클라이언트가 별도로 처리한다.
앱 클라이언트(모바일 앱, PC 앱)
웹 클라이언트(React, Vue.js 등)
웹 브라우저에서 자바스크립트를 통한 HTTP API 호출
서버에서 HTTP API 호출
외부 서비스에서 제공하는 API, 애플리케이션 서버에서 제공하는 API 등 우리가 사용하는 API는 대부분 HTTP API이다.
참고 자료
https://ko.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/API
https://aws.amazon.com/ko/what-is/restful-api/
https://www.ibm.com/kr-ko/topics/api
https://ko.wikipedia.org/wiki/%EC%9B%B9_API
https://www.guru99.com/ko/what-is-api.html
https://www.quora.com/What-is-a-Web-API
https://www.quora.com/Is-an-API-just-a-library
https://www.inforad.co.kr/single-post/api-library
chatgpt
bard
-
Web Server, Application Server
웹 서버란?
웹 서버 : 일반적으로, 클라이언트(웹 브라우저)로부터 HTTP 요청을 받아들이고 정적 리소스를 반환하는 서버
웹 서버는 정적 리소스 제공은 물론, 기타 부가기능도 제공한다.
웹 서버는 동적 리소스를 요청 받으면 애플리케이션 서버에게 해당 요청을 넘겨주고, 애플리케이션 서버에서 처리한 결과를 받아 클라이언트에게 전달해주는 역할을 한다.
웹 서버도 애플리케이션 서버와 같이 프로그램을 실행하는 기능을 포함할 수도 있다.
정적 리소스 : HTML 문서, CSS, JavaScript, 이미지, 파일 등
정적 리소스는 일반적으로 웹 서버의 저장 장치에 저장되어 있고, 항상 동일한 내용을 반환한다.
-> 정적 웹 페이지는 이러한 정적 리소스를 기반으로 구성된다.
동적 리소스 : 검색 결과, 실시간 데이터 등
동적 리소스는 주로 데이터베이스와 상호 작용하여 동적으로 생성되고, 항상 동일한 내용을 반환하지 않는다.
-> 동적 웹 페이지는 이러한 동적 리소스를 기반으로 구성된다.
웹 서버 작동 방식 - 정적 웹 페이지 요청
브라우저는 URL을 사용하여 웹 서버의 IP 주소를 찾는다.
브라우저는 정보에 대한 HTTP 요청을 보낸다.
웹 서버는 저장 장치에서 관련 데이터를 찾는다.
웹 서버는 HTTP 응답으로 HTML, 이미지, 파일과 같은 정적 리소스를 브라우저에 반환한다.
브라우저가 정보를 표시한다.
이미지 파일 등의 정적인 리소스들은 HTML 문서가 클라이언트로 보내질 때 함께 가는 것이 아니다.
클라이언트는 HTML 문서를 먼저 받고, HTML 문서 안에 포함된 이미지 파일이나 기타 정적인 리소스들에 대한 URL을 통해 서버로 추가 요청을 보내서 받아온다.
애플리케이션 서버란?
애플리케이션 서버 : 일반적으로, 클라이언트의 요청에 따라 비즈니스 로직(사용자의 요구사항을 해결하기 위한 실질적인 코드)을 실행하여 데이터 처리 등 다양한 서비스를 제공하는 서버
애플리케이션 서버는 주로 데이터 처리와 같은 작업을 담당하는데, 이를 위해 데이터베이스 서버(대부분), 외부 서비스 API 등과 상호 작용한다.
즉, 애플리케이션 서버는 데이터베이스 등의 소프트웨어 구성 요소와 상호 작용하고 비즈니스 로직을 실행할 수 있는 런타임 환경을 제공한다.
애플리케이션 서버에서 제공하는 API
애플리케이션 서버는 클라이언트에게 API, 웹 페이지 등 다양한 서비스를 제공한다.
-> 애플리케이션 서버는 데이터 처리 등의 비즈니스 로직의 실행을 담당하는데, API는 이러한 애플리케이션 서버의 기능을 외부에 노출하여 클라이언트가 사용할 수 있도록 하는 인터페이스이다.
-> 즉, 애플리케이션 서버는 API를 통해 클라이언트(모바일 앱 등)에게 데이터와 기능을 제공한다.
일반적으로, 애플리케이션 서버와 웹 애플리케이션 서버는 같은 용어이다. 웹 애플리케이션 서버의 의미는 주로 웹 애플리케이션에서의 애플리케이션 서버의 의미로 사용되며, HTTP 프로토콜을 사용하는 모든 종류의 애플리케이션 서버(API를 제공하는 애플리케이션 서버 등)의 의미도 포함한다.
애플리케이션 서버는 웹 서버가 할 수 있는 대부분의 작업(HTTP 요청 처리, 정적 리소스 제공 등) 또한 수행할 수 있다.
그러나, 이상적인 웹 서비스 아키텍처는 웹 서버와 함께 사용하는 것이다. 이러한 아키텍처에서 애플리케이션 서버는 주로 웹 서버로부터 요청을 받아들이고, 해당 요청에 따라 비즈니스 로직을 실행한다. 그 후에 처리된 결과를 웹 서버로 전달하고, 웹 서버가 이를 사용자에게 전송한다.
API만 제공하는 애플리케이션 서버는 굳이 웹 서버를 함께 사용하지 않아도 된다.
애플리케이션 서버 작동 방식(웹 서버 x) - 동적 웹 페이지 요청
브라우저는 URL을 사용하여 애플리케이션 서버의 IP 주소를 찾는다.
브라우저는 정보에 대한 HTTP 요청을 보낸다.
애플리케이션 서버는 데이터베이스 서버 등의 외부 시스템과 상호 작용하며 비즈니스 로직을 수행한다.
애플리케이션 서버는 주로 HTML 문서를 동적으로 생성(서버 측 렌더링)하고 브라우저에 반환한다.
브라우저가 정보를 표시한다.
서버 측 렌더링(Server-Side Rendering, SSR)
-> 서버에서 HTML 최종 결과를 생성해서 클라이언트(웹 브라우저)에 전달하고, 이후 클라이언트에서는 간단한 렌더링 작업을 처리하는 방식
-> 주로 화면이 정적이고, 복잡하지 않을 때 사용
-> 관련 기술: JSP, 타임리프 등
클라이언트 측 렌더링(Client-Side Rendering, CSR)
-> 서버에서 초기 렌더링을 수행하지 않고, 브라우저에서 모든 렌더링 작업을 처리하는 방식
-> 주로 화면이 동적이고, 복잡할 때 사용 (ex) 구글 지도)
-> 관련 기술: React, Vue.js 등
웹 서비스 아키텍처
웹 서비스는 다양한 아키텍처를 가질 수 있다.
클라이언트 - 웹 서버 - 데이터베이스 서버
클라이언트 - 애플리케이션 서버 - 데이터베이스 서버
클라이언트 - 웹 서버 - 애플리케이션 서버 - 데이터베이스 서버 : 이상적인 웹 서비스 아키텍처
애플리케이션 서버만 사용하지 않고, 웹 서버와 함께 사용하는 이유
기능을 분리하여 서버 부하 방지
애플리케이션 서버는 데이터베이스 조회 등의 다양한 비즈니스 로직을 처리하고, 웹 서버는 정적 리소스를 클라이언트에게 제공한다.
효율적인 리소스 관리
정적 리소스가 많이 사용되면 웹 서버를 증설하고, 동적 리소스가 많이 사용되면 애플리케이션 서버를 증설한다.
오류 화면 제공 가능
정적 리소스만 제공하는 웹 서버는 잘 죽지 않고, 비즈니스 로직을 처리하는 애플리케이션 서버는 잘 죽는다. 애플리케이션 서버나 데이터베이스 서버 장애 시 웹 서버가 오류 화면을 제공할 수 있다.
여러 대의 애플리케이션 서버를 연결 가능
앞 단의 웹 서버에서, 오류가 발생한 애플리케이션 서버를 이용하지 못하도록 한 후 애플리케이션 서버를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.
여러 웹 애플리케이션 서비스 가능
ex) 하나의 서버에서 PHP Application과 Java Application을 함께 사용할 수 있다.
참고 자료
https://en.wikipedia.org/wiki/Application_server
https://ko.wikipedia.org/wiki/웹_서버
https://ko.wikipedia.org/wiki/웹_애플리케이션_서버
https://aws.amazon.com/ko/compare/the-difference-between-web-server-and-application-server/
https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html
https://gmlwjd9405.github.io/2018/10/29/web-application-structure.html
https://yozm.wishket.com/magazine/detail/1780/
https://youwjune.tistory.com/41
https://www.quora.com/What-is-the-difference-between-a-web-API-and-an-application-server
https://www.quora.com/Web-Applications-What-is-a-web-server
https://www.quora.com/Can-you-explain-server-side-rendering-in-the-simplest-possible-way
chatgpt
bard
-
Domain Name, DNS
도메인 네임, DNS란?
도메인 네임(Domain Name) : IP 주소에 매핑되는 문자열 주소 체계
컴퓨터는 IP 주소로 통신하는데, 도메인 네임은 서버(대부분 웹 서버)를 쉽게 찾을 수 있도록 해주는 주소라고 할 수 있다.
도메인 네임은 DNS를 통해 해당하는 IP 주소로 변환되어 웹 브라우저나 다른 응용 프로그램에서 서버를 찾을 수 있게 해준다.
도메인은 영구적으로 소유하는 개념이 아니라, 일정기간 임대하는 개념이다.
도메인 네임의 계층적 구조 : Subdomain.Domain.TLD
Subdomain(= Hostname)
Domain의 앞에 오는 추가적인 식별 요소로, 선택적으로 사용된다.
-> “www”가 대표적인 Subdomain이며, “blog”, “mail”, “shop” 등도 사용된다.
Domain(= Second-Level Domain)
TLD 앞에 위치하며, 일반적으로 특정 기업, 조직, 서비스를 식별하는데 사용된다.
-> “google”이나 “naver”가 Domain이다.
TLD(Top-Level Domain)
도메인 이름의 가장 오른쪽에 위치하며, 인터넷에서 특정 종류의 기관, 지역 또는 용도를 나타낸다.
-> “com”, “org”, “net” 등이 대표적인 TLD이며, “kr”(한국), “jp”(일본)과 같은 국가 코드도 TLD에 해당한다.
일반적으로 도메인 네임이라 하면 “Domain.TLD”를 의미한다.
Domain Name : naver.com
FQDN(Fully Qualified Domain Name) : 도메인 네임의 전체 이름을 표기하는 방식
FQDN : www.naver.com
DNS(Domain Name System) : 인터넷에서 도메인 네임을 IP 주소로 변환하는 전세계적인 거대한 분산 데이터베이스 시스템
DNS는 여러 DNS Server들이 서로 상호 작용하며 동작한다.
Domain Name Space : DNS가 저장 및 관리하는 계층적 구조
각 레벨은 그 하위 도메인에 관한 정보를 관리하는 구조를 가진다.
DNS 구성 요소
Stub Resolver ( = DNS Client)
Stub Resolver : 클라이언트 기기에 내장된 작은 DNS 클라이언트 소프트웨어
Stub Resolver는 사용자가 웹 브라우저나 다른 응용 프로그램을 통해 도메인 네임을 입력할 때 동작한다.
Stub Resolver는 수많은 Name Server(Root DNS Server, TLD DNS Server, SLD DNS Server)의 구조를 파악할 필요가 없다.
Stub Resolver 동작 과정 - 캐시 x
사용자가 웹 브라우저에 도메인 네임을 입력하면, 웹 브라우저는 사용자의 운영체제에서 설정된 Stub Resolver를 사용한다.
-> 운영체제에서 설정된 Stub Resolver는 현재 연결된 ISP의 Local DNS Server(= Resolver)와 통신한다.
Stub Resolver는 Resolver로 DNS Query를 전송한다.
Stub Resolver는 Resolver로부터 도메인 네임에 대한 IP 주소를 받아 웹 브라우저에 전달한다.
Resolver ( = Local DNS Server ) => ISP가 관리
Resolver : DNS Client로부터 받은 DNS Query를 처리하여 DNS Client에게 IP 주소를 반환하는 서버
Resolver는 도메인 네임에 대한 IP 주소를 찾기 위해 계층적으로 Name Server들에게 DNS Query를 전송한다.
Resolver는 이전에 처리된 DNS Query의 결과를 캐시에 저장하여, 동일한 DNS Query에 대한 응답 속도를 향상시킬 수 있다.
Resolver 동작 과정 - 캐시 x
DNS Client에서 Resolver에게 DNS Query를 전송한다.
Resolver는 먼저 Root DNS Server에게 DNS Query를 보낸다.
Root DNS Server는 TLD DNS Server의 IP 주소를 반환한다.
Resolver는 Root DNS Server로부터 받은 응답을 기반으로, TLD DNS Server에게 DNS Query를 보낸다.
TLD DNS Server는 SLD DNS Server의 IP 주소를 반환한다.
Resolver는 TLD DNS Server로부터 받은 응답을 기반으로, SLD DNS Server에게 DNS Query를 보낸다.
SLD DNS Server는 도메인 네임에 대한 IP 주소를 반환한다.
Resolver는 최종적으로 SLD DNS Server로부터 받은 도메인 네임에 대한 IP 주소를 DNS Client에게 전달한다.
Name Server
Name Server : Domain Name Space에 대한 정보를 가지고 있는 서버
Name Server는 계층적 구조로 조직되어 있는데, 이것은 Name Server 간의 상호 작용이 계층적이라는 의미이다.
Name Server는 데이터 저장 및 관리, 요청 처리 및 응답 구현 등의 역할을 수행한다.
Name Server는 Root DNS Server, TLD DNS Server, SLD DNS Server로 분류할 수 있다.
Root DNS Server
DNS의 최상위 계층에 위치하는 서버로, DNS Query 프로세스의 시작점이다.
TLD DNS Server의 IP 주소를 제공한다.
ICANN이 직접 관리하는 서버이며, 전세계에 13개의 Root DNS Server가 존재한다.
TLD(Top-Level Domain) DNS Server
TLD를 관리하는 서버이다.
ex) “com”, “net”
SLD DNS Server의 IP 주소를 제공한다.
일반적으로 특정 조직이나 단체에 의해 관리된다.
SLD(Second-Level Domain) DNS Server(= Authoritative DNS Server)
SLD를 관리하는 서버이다.
ex) “google(.com)”
도메인 네임에 대한 IP 주소를 제공한다.
일반적으로 도메인/호스팅 업체에 의해 관리된다.
일부 조직이나 기업, 또는 개인이 자체적으로 SLD DNS Server를 운영하거나 관리할 수도 있다.
DNS 동작 과정 예시
사용자가 웹 브라우저에 “www.google.com”을 입력한다.
먼저, 웹 브라우저와 운영체제는 캐시를 확인한다.
a. 이전의 결과가 이미 캐시에 저장되어 있는 경우 바로 해당 정보를 반환하고, 아래 과정을 생략한다.
b. 웹 브라우저 및 운영체제 캐시에 해당 정보가 없거나 만료된 경우, 웹 브라우저는 DNS Client를 사용하여 Resolver에게 “www.google.com”의 IP 주소를 요청한다.
Resolver는 캐시를 확인한다.
a. 이전의 결과가 이미 캐시에 저장되어 있는 경우 바로 해당 정보를 DNS Client에게 해당 정보를 반환하고, 아래 과정을 생략한다.
b. Resolver 캐시에 해당 정보가 없거나 만료된 경우, 아래 과정을 진행한다.
Resolver는 Root DNS Server에게 “com” 도메인에 대한 정보를 요청한다.
Root DNS Server는 “com” 도메인을 관리하는 TLD DNS Server의 IP 주소를 응답한다.
Resolver는 “com” 도메인을 관리하는 TLD DNS Server에게 “google” 도메인에 대한 정보를 요청한다.
TLD DNS Server는 “google” 도메인을 관리하는 SLD DNS Server의 IP 주소를 응답한다.
Resolver는 “google” 도메인을 관리하는 SLD DNS Server에게 “www” 도메인에 대한 정보를 요청한다.
SLD DNS Server는 “www.google.com”의 IP 주소인 “209.85.227.104”를 응답한다.
Resolver는 DNS Client에게 “209.85.227.104”를 전달하고, 최종적으로 DNS Client는 웹 브라우저에게 “209.85.227.104”를 전달한다.
참고 자료
https://ko.wikipedia.org/wiki/도메인_네임
https://ko.wikipedia.org/wiki/도메인_네임_시스템
https://www.cloudflare.com/ko-kr/learning/dns/glossary/what-is-a-domain-name/
https://aws.amazon.com/ko/route53/what-is-dns/
https://www.ibm.com/kr-ko/topics/dns
https://hanamon.kr/dns란-도메인-네임-시스템-개념부터-작동-방식까지/
https://velog.io/@qltkd5959/DNSDomain-Name-System란
https://velog.io/@dnwlsrla40/DNS-Domain-Name-System-zrombqvk
https://copycode.tistory.com/124
https://www.quora.com/What-are-domain-names
chatgpt
bard
-
-
웹
웹(World Wide Web, WWW, W3) : 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간
웹은 여러 인터넷 서비스 중 하나라고 볼 수 있다.
인터넷에서 제공하는 서비스는 웹(HTTP) 등 여러 서비스들이 있다.
웹 페이지(Web Page) : 웹 상에 있는 단일 문서
아래의 내용들은 일반적인 웹 서비스 구조인 <클라이언트 - 웹 서버 - 애플리케이션 서버> 아키텍처를 바탕으로 정리하였다.
웹 페이지는 HTML, CSS, JavaScript 등으로 구성되어 있다.
웹 페이지들은 서로 하이퍼링크로 연결시킬 수 있으며, 하이퍼링크를 통해 다른 웹 페이지로 이동할 수 있다.
정적 웹 페이지 : 변경되지 않는 구조의 웹 페이지
정적 웹 페이지는 일반적으로 웹 서버에 저장되어 있고, 클라이언트가 요청할 때마다 동일한 내용을 제공한다.
ex) 회사 소개 웹 페이지(하이퍼링크 포함 or 포함하지 않음)
동적 웹 페이지 : 클라이언트의 요청에 따라 변경되는 구조의 웹 페이지
클라이언트 사이드 동적 웹 페이지 : 웹 브라우저에서 실행되는 스크립트에 의해 동적으로 생성되는 구조의 웹 페이지
웹 브라우저는 서버로부터 받은 초기 HTML 및 정적 리소스를 기반으로, 사용자와의 상호작용에 따라 동적으로 리소스를 업데이트하고 변경한다.
클라이언트 사이드 스크립트 언어 : 웹 브라우저에서 실행되는 스크립트 언어
JavaScript, TypeScript 등
ex) 구글 지도, 사용자가 입력한 텍스트를 모두 소문자로 변환해주는 웹 페이지
서버 사이드 동적 웹 페이지 : 애플리케이션 서버에서 실행되는 스크립트에 의해 동적으로 생성되는 구조의 웹 페이지
애플리케이션 서버는 클라이언트의 요청에 따라 동적으로 웹 페이지를 생성한 후 클라이언트로 전달한다.
서버 사이드 스크립트 언어 : 애플리케이션 서버에서 실행되는 스크립트 언어
PHP, JavaScript(Node.js), Java(Servlets, JSP) 등
ex) 데이터베이스를 조회하는 웹 페이지
웹사이트(Website) : 웹 페이지들의 의미 있는 묶음
웹사이트는 기업, 기관 등의 정보를 담고 있거나 서비스를 제공하는 데 사용된다.
공식적으로 접속할 수 있는 모든 웹사이트는 총체적으로 웹을 이루고 있다.
웹 브라우저(Web Browser) : 웹 서버와 통신하여 웹 페이지를 출력하는 GUI 기반의 응용 소프트웨어
웹 브라우저는 HTML, CSS, JavaScript를 해석하고 렌더링하는 역할을 한다.
웹 브라우저는 웹 서버와 대부분 URL과 HTTP(HTTPS)를 통해 웹 페이지를 가져올 뿐 아니라 웹 서버에 정보를 송신하기도 한다.
웹 애플리케이션, 웹 앱(Web Application) : 웹 브라우저를 통해 실행되는 응용 프로그램
참고 자료
https://ko.wikipedia.org/wiki/월드_와이드_웹
https://ko.wikipedia.org/wiki/웹_페이지
https://ko.wikipedia.org/wiki/동적_웹페이지
https://ko.wikipedia.org/wiki/웹사이트
https://ko.wikipedia.org/wiki/웹_브라우저
https://ko.wikipedia.org/wiki/웹_애플리케이션
chatgpt
-
서버리스
서버리스란?
서버리스 : 개발자가 서버 또는 백엔드 인프라를 프로비저닝하거나 관리하지 않고도 애플리케이션을 설계하고 실행할 수 있는 클라우드 컴퓨팅 애플리케이션 개발 모델
서버리스는 보통 “서버리스 컴퓨팅” 또는 “서버리스 아키텍처”로 불린다.
서버리스 컴퓨팅에서는 CSP가 서버를 관리 및 실행한다.
CSP는 운영 체제 관리, 보안 패치, 파일 시스템 및 용량 관리, 로드 밸런싱, 모니터링, 로깅과 같은 여러 작업을 처리한다.
개발자는 서버 관리에서 자유로워지며 실제 구현해야 할 기능에 더 집중할 수 있다.
즉, “서버리스”는 서버가 없는 것이 아니라, 개발자가 서버를 직접 관리할 필요가 없다는 의미이다.
서버리스 아키텍처 유형 - FaaS, BaaS
FaaS(Function as a Service) : 특정 이벤트가 발생할 때 코드를 실행하고 관리해주는 클라우드 컴퓨팅 서비스
개발자는 이벤트에 따라 실행되는 함수(코드)를 작성하고 클라우드 인프라에 배포(업로드)만 하면 된다.
함수(코드)는 이벤트(HTTP 요청, 파일 업로드 등)가 발생할 때만 실행되며, 실행 후에는 리소스가 자동으로 해제된다.
개발자는 코드를 실행하는 데 필요한 인프라를 구축하고 관리하지 않아도 된다.
ex) AWS Lambda, Amazon API Gateway, Google Cloud Functions
BaaS(Backend as a Service) : 백엔드 인프라(데이터베이스, 스토리지, 인증, 푸시 알림 등)를 제공하는 클라우드 컴퓨팅 서비스
개발자는 API를 사용하여 백엔드 기능에 액세스한다.
개발자는 백엔드 인프라를 구축하고 관리하지 않아도 된다.
ex) Amazon DynamoDB, AWS RDS, AWS S3, AWS Amplify, AWS SQS
서버리스 아키텍처 유형에는 FaaS와 BaaS가 있지만, 일반적으로 서버리스는 FaaS를 의미한다.
API 서버를 예시로 들어보면, (AWS EC2 - Amazon DynamoDB(BaaS)) 아키텍처와 (AWS Lambda(FaaS) - Amazon DynamoDB(BaaS)) 아키텍처가 있을 때, 후자를 서버리스 아키텍처라고 말한다.
참고 자료
https://aws.amazon.com/ko/serverless/
https://aws.amazon.com/ko/what-is/serverless-computing/
https://www.samsungsds.com/kr/insights/1232763_4627.html
https://www.ibm.com/kr-ko/topics/serverless
https://www.oracle.com/kr/cloud/cloud-native/functions/what-is-serverless/
https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless
https://ko.wikipedia.org/wiki/서버리스_컴퓨팅
https://yozm.wishket.com/magazine/detail/2168/
chatgpt
-
데이터베이스 시스템
데이터베이스 시스템
데이터베이스 시스템 : 데이터를 저장하고 관리하는 모든 시스템
데이터베이스 시스템 구성 요소
데이터베이스 : 구조화된 데이터 집합
DBMS : 데이터베이스를 관리하는 소프트웨어 도구 집합
하드웨어 : 데이터베이스 시스템에서의 물리적 장치(CPU, 네트워크, 저장 장치 등)
클라이언트 : 데이터베이스에 접근하는 개인 또는 소프트웨어
데이터베이스(DB, Database)
데이터베이스 : 데이터의 효율적인 검색 및 갱신 등을 위해 구조화된 데이터의 집합
데이터베이스는 서로 관련 있는 데이터의 집합이다.
데이터베이스의 사전적인 의미는 구조화된 데이터의 집합이지만, 데이터베이스는 아래와 같이 여러가지 의미로 쓰인다.
구조화된 데이터 집합
DBMS
구조화된 데이터가 저장되는 저장 장치(스토리지)
-> 일반적으로, “DBMS” 의미로 자주 쓰인다. 해당 게시글에서는 1의 의미로 정리하였다.
데이터베이스 관리 시스템(DBMS, Database Management System)
DBMS : 데이터베이스 시스템의 핵심 부분으로, 사용자가 데이터베이스 내의 데이터를 접근할 수 있도록 해주는 소프트웨어 도구의 집합
DBMS는 데이터 관리(CRUD 등), 성능 최적화, 보안 및 권한 관리, 백업 및 복구 등의 작업을 수행한다.
DBMS마다 다양한 쿼리 언어(SQL 등)를 지원한다.
DBMS 구성 요소
데이터베이스 엔진(= 스토리지 엔진) : 데이터의 실제 저장 및 관리하는 역할
쿼리 언어 인터페이스, 쿼리 옵티마이저 등
DBMS 종류
RDBMS(Relational DBMS) : 스키마 필요
Table 형태로 데이터 저장
SQL 지원
ex) MySQL, PostgreSQL, SQLite, SQLServer, Oracle 등
NoSQL : 스키마가 없거나 유연한 스키마
Document 형태
파일(문서) 안에 JSON 형태로 데이터 저장
ex) MongoDB, Cloud Firestore
Key-Value 형태
Key-Value 형태로 데이터 저장
ex) Redis, DynamoDB
Column Family 형태
Table 등의 형태이지만, 유연하게 데이터 저장
ex) Cassandra, Hbase
Graph 형태
Node 안에 데이터와 Node 간의 관계 저장
ex) Neo4j
DBMS는 데이터베이스 서버 소프트웨어라고 할 수 있다. 즉, 데이터베이스 서버는 DBMS가 실행되는 컴퓨터 시스템(물리적 또는 가상적 환경)을 말한다.
-> 데이터베이스 서버는 DBMS 설치, 초기 설정, 외부 연결 허용 등의 단계를 거쳐 구축된다.
-> 데이터베이스 서버는 클라이언트로부터 데이터베이스 요청을 수신하고, 해당 요청을 처리하여 결과를 반환한다.
데이터베이스 시스템에서의 스토리지
일반적으로, 스토리지는 데이터를 저장하고 있는 저장 장치를 의미한다.
데이터베이스 시스템에서 스토리지란, 구조화된 데이터(데이터베이스)를 저장하고 있는 저장 장치를 의미한다.
데이터베이스 서버에서는 데이터베이스를 서버의 저장 장치에 직접 저장하거나 Cloud Storage에 저장한다.
-> 일반적으로, 개인 PC에서 데이터베이스 서버를 가동하면, 데이터베이스는 개인 PC의 저장 장치(HDD나 SSD)에 저장된다.
-> 일반적으로, AWS EC2 인스턴스에서 데이터베이스 서버를 가동하면, 데이터베이스는 Cloud Storage(ex) AWS EBS)에 저장된다.
데이터베이스 시스템에서 이미지와 같은 파일을 저장하는 방법
파일 자체를 데이터베이스 시스템의 스토리지에 저장
-> 파일을 데이터베이스 필드에 이진 데이터 형태로 저장한다.
파일 자체를 다른 스토리지에 저장
-> 파일을 다른 스토리지(ex) AWS S3)에 저장한 후, 저장된 파일의 위치(URI)를 데이터베이스 필드에 저장한다.
-> 일반적으로, 2의 방법이 효율적이다.
참고 자료
https://ko.wikipedia.org/wiki/데이터베이스_시스템
https://ko.wikipedia.org/wiki/데이터베이스_관리_시스템
https://survey.stackoverflow.co/2022
https://terms.tta.or.kr/dictionary/dictionaryView.do?subject=데이터베이스
https://jaemunbro.medium.com/nosql-데이터베이스-특성-비교-c9abe1b2838c
chatgpt
-
클라우드 스토리지(Block, File, Object)
Cloud Storage 유형
Cloud Storage Service에서 말하는 “블록 스토리지, 파일 스토리지, 객체 스토리지”라는 용어들은, Cloud Storage가 데이터를 저장하고 관리하는 기술을 의미한다.
블록 스토리지(ex) AWS EBS)는 데이터를 고정된 크기의 블록 단위로 나누어 저장하고 관리한다.
파일 스토리지(ex) AWS EFS)는 데이터를 파일 단위로 나누어 저장하고 관리한다.
객체 스토리지(ex) AWS S3)는 데이터를 객체 단위로 나누어 저장하고 관리한다.
각각의 스토리지 유형은 특정한 용도와 특성을 가지고 있으며, 어떤 스토리지 유형을 선택할지는 데이터의 특성과 요구 사항에 따라 다르다.
Cloud Storage Service에서 제공하는 데이터 처리 방식의 감춤, 추상화된 인터페이스 등은 사용자가 스토리지 유형 간의 차이를 잘 느끼지 못하게 한다.
일반적인 사용자 입장에서 각 스토리지 유형의 기술적인 측면에 집중할 필요가 없다. 사용자는 각 스토리지의 기술적인 측면보다는 데이터를 다루는 방식과 필요한 기능에 집중한다.
AWS Cloud Storage 예시
-> AWS EC2를 사용하여 가상 서버(인스턴스)를 생성할 때 기본 저장 장치로 AWS EBS(블록 스토리지)를 사용하는데, 이는 일반적인 컴퓨터에서의 하드 디스크와 비슷한 역할을 한다.
-> 대용량의 정적 파일이나 이미지 등을 저장하기 위해서 AWS S3(객체 스토리지)를 사용한다.
기술적 측면
일반적인 사용자 입장에서 각 스토리지 유형의 기술적인 측면에 집중할 필요는 없지만, 그래도 간단하게 살펴보자.
스토리지 유형
데이터 저장 및 관리 단위(논리적)
실제 데이터의 저장 공간(물리적)
블록 스토리지
블록
HDD, SSD 등의 저장 장치
파일 스토리지
파일
HDD, SSD 등의 저장 장치
객체 스토리지
객체
HDD, SSD 등의 저장 장치
일반적으로, “블록 스토리지, 파일 스토리지, 객체 스토리지”는 데이터를 저장하고 관리하는 기술을 설명하는 개념이다.
HDD와 SSD 등의 저장 장치는 블록 스토리지를 구현한 하드웨어라고 할 수 있으며, 파일 스토리지와 객체 스토리지는 블록 스토리지를 기반으로 한다.
파일 스토리지 ≒ 블록 스토리지 + 파일 시스템
객체 스토리지 ≒ 블록 스토리지 + 객체 스토리지 시스템
사용자가 PC에서 블록 스토리지가 아니라 파일 스토리지처럼 사용할 수 있는 이유
-> 기본적으로 운영 체제는 자체적인 파일 시스템을 가지고 있기 때문이다. 파일 시스템은 블록 단위로 저장되는 데이터를 파일 단위로 조직화하고 관리하여 사용자가 편리하게 파일을 다룰 수 있도록 해준다.
참고 자료
https://www.redhat.com/ko/topics/data-storage/file-block-object-storage
https://www.alibabacloud.com/ko/knowledge/difference-between-object-storage-file-storage-block-storage
https://www.alibabacloud.com/ko/knowledge/what-is-object-storage?spm=a2c64.255190.1234557720.5.3ef51326H49VXc
https://www.youtube.com/watch?v=YBc8Mx89Af0
https://www.iwinv.kr/storage/block.html
chatgpt
-
스토리지
스토리지란?
데이터 : 우리가 인식할 수 있는 어떤 것 (ex) 이미지, 텍스트, DB 테이블 등)
기억 장치 : 컴퓨터에서 데이터를 일시적 또는 영구적으로 보존하는 장치
주기억 장치
ex) RAM, ROM 등
주기억 장치는 휘발성(RAM) 또는 비휘발성(ROM)이다.
일반적으로, 주기억 장치를 메모리 또는 RAM이라고도 부른다.
보조기억 장치(= 저장 장치)
ex) HDD, SSD 등
보조기억 장치는 모두 비휘발성이다.
일반적으로, 스토리지는 (대용량) 저장 장치를 지칭한다.
스토리지 연결 방식
서버(또는 PC)와 스토리지 간의 연결 방식
직접 연결하거나 스토리지와 연결된 네트워크에 연결 (→ DAS, NAS, SAN)
인터넷을 통한 Cloud Service 이용 (→ Cloud Storage)
직접 연결 스토리지(DAS, Direct Attached Storage) 방식
DAS 방식은 스토리지를 서버의 HBA(Host Bus Adapter, 컴퓨터와 스토리지 또는 컴퓨터와 네트워크 장치 사이의 연결을 담당하는 하드웨어)에 전용 케이블로 직접 연결하는 방식이다.
일반적으로, 데이터를 블록 단위로 읽고 쓴다.(블록 레벨 엑세스)
서버에서 파일 시스템을 사용하면 파일 레벨 엑세스를 한다. 즉, 서버에서 파일 시스템을 직접 관리한다.
특징
일반적으로 서버와 직접적으로 연결되어 있어 다른 서버에서는 직접 액세스할 수 없다.
서버에 직접 외장 저장장치를 추가하므로 속도가 빠르고 확장이 쉽지만, 연결 수에 한계가 있다.
일반적으로 개인용 데스크탑, 작은 기업 또는 부서 수준에서 사용된다.
네트워크 결합 스토리지(NAS, Network Attached Storage) 방식
NAS 방식은 서버와 스토리지를 일반적인 네트워크(LAN, 인터넷)를 통해 연결하는 방식이다.
일반적으로, 파일이나 디렉토리 단위로 데이터를 읽고 쓴다.(파일 레벨 엑세스)
NAS 장치가 파일 시스템을 설정하고 관리한다. 즉, NAS 장치는 파일 서버라고 볼 수 있다.
특징
네트워크를 통해 데이터를 외부로 공유할 수도 있으며, 여러 장치들과 연결이 가능하다.
네트워크를 사용하기 때문에 대역폭으로 인한 전송 속도에 제한과 병목 현상이 일어날 수 있다.
RAID 기술을 사용하므로 저장된 데이터를 여러 하드 디스크에 분산하고 복제할 수 있다.
일반적으로 개인 사용자나 작은 비즈니스 등 작은 규모의 환경에서 사용되고, 파일 공유, 중앙 파일 관리, 백업, 멀티미디어 스트리밍 등에 주로 사용된다.
스토리지 영역 네트워크(SAN, Storage Area Network) 방식
SAN 방식은 서버와 스토리지를 전용 네트워크(SAN)를 통해 연결하는 방식이다.
일반적으로, 데이터를 블록 단위로 읽고 쓴다.(블록 레벨 엑세스)
특징
광케이블을 사용하기 때문에 데이터 접근이 빠르며, LAN을 사용하지 않아 네트워크 부하를 최소화할 수 있다.
관리가 어렵고, 네트워크 구성에 따라 전문 인력이 필요하다.
일반적으로 대규모 기업이나 데이터 센터에서 사용되고, 가상화, 데이터베이스 등 높은 성능과 가용성이 필요한 시스템에서 사용된다.
Cloud Storage
Cloud Storage : 일반적으로, 물리적인 스토리지가 CSP에 의해 관리되는 여러 개의 서버들에 걸쳐 있는 스토리지 모델
-> Cloud Storage는 가상화에 기반을 두고 있다.
-> 보통 파일은 한 개의 스토리지에 저장이 되는데, Cloud Storage에서는 한 개의 파일을 여러 대의 가상화된 물리 서버에 공통적으로 저장한다.
Cloud Storage 유형
사용자(서버 또는 PC)는 인터넷을 통해 Cloud Storage를 사용한다.
일반적으로, 데이터를 객체 단위로 읽고 쓴다.
Cloud Storage Service : Google Drive, Microsoft OneDrive, AWS S3 등
특징
사용자는 필요에 따라 저장 공간을 쉽게 확장할 수 있다.
데이터를 안전하게 백업하고 복구할 수 있는 기능을 제공한다.
사용자는 Public 또는 Private 네트워크 연결을 통해 액세스할 수 있다.
Cloud Computing을 통해서 작동하기 때문에 외부에서 쉽게 접속할 수 있고, 웹 서비스를 통해서 접속할 수도 있으며, API를 이용하여 애플리케이션으로 접속할 수도 있다.
참고 자료
http://wiki.hash.kr/index.php/스토리지
https://ko.wikipedia.org/wiki/기억_장치
https://ko.wikipedia.org/wiki/주기억장치
https://ko.wikipedia.org/wiki/고정_기억_장치
https://ko.wikipedia.org/wiki/직접_연결_저장장치
https://ko.wikipedia.org/wiki/네트워크_결합_스토리지
https://ko.wikipedia.org/wiki/스토리지_에어리어_네트워크
https://ko.wikipedia.org/wiki/호스트_어댑터
https://ko.wikipedia.org/wiki/클라우드_스토리지
https://aws.amazon.com/ko/what-is/nas/
https://aws.amazon.com/ko/what-is/cloud-storage/
https://www.ibm.com/kr-ko/topics/network-attached-storage
https://www.vmware.com/kr/topics/glossary/content/storage-area-network-san.html
https://server-talk.tistory.com/366
https://mindstation.tistory.com/152
https://www.youtube.com/watch?v=QVG-MK014ck
chatgpt
-
클라우드 컴퓨팅
Cloud Computing
클라우드 컴퓨팅 : 인터넷을 통해 가상의 컴퓨팅 리소스를 사용하는 기술
여기서 말하는 컴퓨팅 리소스 개념은 CPU, RAM, 스토리지 등의 하드웨어 리소스는 물론, 데이터베이스 서버, 프로그램 실행 환경, 각종 응용 프로그램 등도 포함한다.
클라우드 컴퓨팅의 주요 특징
사용자는 인프라 관리에 신경 쓸 필요가 없다.
사용자는 컴퓨팅 리소스에 언제 어디서든 접근이 가능하며, 다양한 장치에서도 접근할 수 있다.
사용자는 필요에 따라(On-demand) 컴퓨팅 리소스를 즉시 이용할 수 있고, 필요에 맞게 확장하거나 축소할 수 있어 비용 효율적이다.
Cloud Computing - 가상화
클라우드 컴퓨팅을 실현하기 위한 핵심 기술 중 하나가 가상화이다.
가상화 없이도 클라우드 컴퓨팅은 가능하지만, 클라우드 컴퓨팅을 더 효율적으로 구현하고 관리하기 위해 가상화 등 여러 기술들을 사용한다.
CSP는 가상화를 통해 하드웨어 리소스를 더욱 효율적으로 활용하고, 사용자는 필요에 따라 빠르게 확장할 수 있는 장점을 얻는다.
CSP는 물리적 서버의 하드웨어 리소스를 가상화하여 가상 서버로 분할하고, 이를 클라우드 환경에서 관리한다.
CSP는 데이터 센터를 관리하고, 가상 환경을 생성, 관리, 제공하는 역할을 한다.
가상화는 기술, 클라우드는 그 기술을 이용하여 제공되는 환경이라고 볼 수 있다.
Cloud Service
클라우드 컴퓨팅 모델(서비스 제공 형태) : 클라우드에서 무엇을 제공하는지
IaaS(Infrastructure as a Service)
인프라(Network, Storage, Computing 등) 제공
사용자는 OS 등을 직접 설치하고 애플리케이션을 개발
ex) AWS EC2, AWS S3 등
PaaS(Platform as a Service)
애플리케이션 개발 구성 요소(인프라, OS, 개발 환경 등) 제공
사용자는 애플리케이션 개발에 집중
ex) Google App Engine, Microsoft Azure App Service, Heroku 등
SaaS(Software as a Service)
완전한 서비스(인프라, OS, 사용할 애플리케이션) 제공
사용자는 소프트웨어 사용에 집중
ex) Gmail, Google Docs, DropBox, Slack 등
클라우드 컴퓨팅 배포 모델(서비스 유형) : 클라우드 컴퓨팅을 어떻게 제공하는지
Public Cloud
인터넷에 접속 가능한 모든 사용자를 대상으로 하는 클라우드 서비스 모델
공개형(클라우드)
낮은 비용과 높은 확장성
ex) AWS, Microsoft Azure, Google Cloud 등
Private Cloud
제한된 네트워크 상에서 특정 기업이나 특정 사용자만을 대상으로 하는 클라우드 서비스 모델
폐쇄형(온프레미스)
높은 초기 비용 및 유지 보수 비용
높은 수준의 커스터마이징 가능하며, 보안이 중요한 기업에서 선호
ex) 기업이 자체적으로 구축한 클라우드 환경
Hybrid Cloud
Public Cloud와 Private Cloud를 함께 사용하는 환경
ex) 기업에서 주요 데이터는 온프레미스에서 유지하고, 예측하기 어려운 트래픽(이벤트 또는 신규 서비스 등의 특정한 상황)에서는 Public Cloud를 활용
참고 자료
https://aws.amazon.com/ko/what-is-cloud-computing/
https://ko.wikipedia.org/wiki/클라우드_컴퓨팅
https://ko.wikipedia.org/wiki/컴퓨터_성능
https://www.samsungsds.com/kr/cloud-glossary/cloud-computing.html
https://times.postech.ac.kr/news/articleView.html?idxno=5086
https://velog.io/@noyohanx/0.-클라우드란-무엇일까
https://glossary.cncf.io/ko/cloud-computing/
https://selog.tistory.com/entry/가상화-Virtualization가상화-개념-쉽게-이해하기
https://www.youtube.com/watch?v=JjiYqBl2328&list=PLfth0bK2MgIan-SzGpHIbfnCnjj583K2m&index=1
https://www.youtube.com/watch?v=s75iONF6XFw&list=PLfth0bK2MgIan-SzGpHIbfnCnjj583K2m&index=3
chatgpt
-
Touch background to close
개발is:e
