일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 월미도
- Kafka
- Spring Data JPA
- 알고리즘
- aws
- 백준
- gcp
- Spring Boot
- 쿠버네티스
- Docker
- springboot
- DFS
- 백트래킹
- 자료구조
- 클라우드 컴퓨팅
- 오일러프로젝트
- Apache Kafka
- 프로그래밍문제
- 클라우드
- 스프링
- 카프카
- 스프링 부트
- 로드밸런서
- VPC
- Elasticsearch
- Spring
- 스프링부트
- 코드업
- JPA
- 인천여행
- Today
- Total
목록Infrastructure (22)
GW LABS
Docker와 같은 컨테이너 기술은 개발팀의 개발환경 구성문제, 애플리케이션 단위로 격리하여 코드로 서버를 관리하는 등 다양한 운영과 관련된 문제를 해결해줬다(44bits Docker 필요성 포스팅). 그러나 Docker로 서버 및 앱들을 관리하면서 규모가 점점 커지게 되면 컨테이너 운영의 문제가 발생한다. 여러 대의 서버에서 컨테이너들을 관리해야 할 때 네트워크 문제, 배포 문제 등을 해결하기 위해 대두된 기술이 컨테이너 오케스트레이션이다. Docker swarm, AWS ECS 등의 오케스트레이션 서비스들이 있지만 현재 컨테이너 오케스트레이션의 표준으로 자리잡고 있는 Kubernetes에 대해 알아보자. Kubernetes 소개 Kubernetes는 구글의 노하우가 담긴 프로덕션급 컨테이너 오케스트레..
이번 포스팅에서는 GCP의 Auto Scaling 기능에 대해 알아본다. 나는 클라우드의 막강한 기능 중 하나가 오토스케일링이라고 생각한다. 오토스케일링 기능이 없었다면 클라우드의 이점이 많이 상실되었을 것이다. 서버 트래픽의 증가에 따라 서버를 증설해야할 때 개발자가 수동으로 인스턴스를 생성하는 것도 일종의 비용으로 볼 수 있기 때문이다. 다행히 오토스케일링 기능을 이용하면 트래픽에 따라 유연하게 확장할 수 있다. Instance Group을 통한 Auto Scaling 이전 Deployment Manager 포스팅에서 오토스케일링까지 적용했지만 직접적으로 콘솔화면에서 리소스를 생성하는 실습을 진행해보려고 한다. 순서는 다음과 같다. 방화벽 규칙 생성 인스턴스 템플릿 생성 인스턴스 그룹 생성 로드밸런서..
이번 포스팅에서는 클라우드 모니터링 서비스에 대해 알아본다. VM 인스턴스들을 생성하고 웹 서버로 사용하고 있다고 가정하자. 갑자기 서비스가 불안정해질 때 인스턴스들의 상태를 파악해야한다. 그렇다고 직접 인스턴스들에 SSH로 접속해서 top 명령어로 보기에는 아주 번거로울 것이다. GCP의 모니터링 서비스는 이러한 상황에서 아주 편리하게 이용할 수 있다. GCP Monitoring GCP Monitoring 서비스는 GCP 리소스들의 상태를 파악하기 위한 모니터링 서비스이다. 멋진 대시보드를 지원하고 알림서비스 등을 지원하고 있다. 실습을 통해서 빠르게 알아보자. 우선 VM 인스턴스를 생성하고 웹 서버를 설치한 다음, 모니터링 서비스에 필요한 것들을 인스턴스 내에 직접 설치할 것이다. 실제 운영에 사용할..
이번 포스팅에서는 GCP Deployment Manager에 대해 알아본다. GCP를 사용하면서 Cloud Console 화면만을 이용해서 개발을 진행한다고 가정해보자. 매번 VM 인스턴스를 생성할 때마다 네비게이션 메뉴에서 Compute Engine을 찾고, 거기에서 VM instances란을 클릭한다. 그리고 create 버튼을 클릭에서 정보를 입력하고 생성한다. 클라우드에 대한 지식이 없는 상태에서는 이렇게 접근하는 것이 안전해보일 수 있지만, 익숙해진 상태에서는 너무 지루하고 비효율적이다. Cloud Shell을 사용한다면 조금은 편해진다. 인스턴스 생성명령어를 미리 메모장에 작성해두고 설정을 바꿔야한다면 명령어를 수정해서 다시 실행하면 된다. 그러나 매번 변경이 일어날때마다 이런 작업을 해야한다..
이번 포스팅에서는 클라우드 컴퓨팅의 근간이 되는 VPC 네트워크에 대해 알아보자. 네트워크는 클라우드 컴퓨팅의 중요한 요소이므로 꼭 알아두어야 할 개념이다. 대부분의 클라우드 제공자들은 VPC 네트워크를 기본 네트워크 구성으로 제공하고 있으므로, 한번 개념을 잡아두면 대부분의 클라우드 서비스의 네트워크를 이용할 수 있을 것이다. VPC Virtual Private Cloud(VPC)는 GCP 내부 네트워크에서 가상화되어 서비스되는 네트워크이다. 대부분의 클라우드 서비스들은 VPC 형태의 네트워크 서비스를 제공한다. 클라우드 리소스의 대부분이 VPC 네트워크를 통해서 제공된다. 또한 방화벽 규칙, 전달 규칙 등 다양한 네트워크 정책들은 VPC 내에서 구현된다. VPC 네트워크는 위의 그림처럼 구성이 된다...
SElinux를 사용하고 있는 리눅스에서 Docker를 사용할 때에는 SElinux의 보안정책에 주의해야한다. CentOS에서 Docker를 설치하고 사용하고자 하는 컨테이너에 volume을 마운트하면 컨테이너가 마운트한 경로에 접근이 안되는 경우가 발생할 수 있기 때문이다. 왜 그럴까? 이유는 Docker 호스트가 컨테이너에 대한 SElinux의 정책을 알 수 없기 때문이다. # docker run -v /var/db:/data1 some_image_name 따라서 SElinux를 사용하고 있는 리눅스에서는 위의 명령어와 같은 방식으로 Docker 컨테이너를 생성할 때 /var/db 경로는 컨테이너에 쓸 수 없다. 컨테이너 내부에서 접근하려고 해도 호스트의 SElinux 정책으로 접근권한이 없다는 메세..
저번 포스팅에서는 클라우드 구성요소와 GCP의 기본적인 구조와 특징, 대표적인 서비스들이 무엇이 있는지 알아봤다. 이번시간에서는 직접 가상머신을 생성하고, 여러 대의 가상머신에 로드밸런서를 연결하여 트래픽을 분산하는 방법까지 살펴보려고 한다. 예제 서비스 구조 이번 포스팅에서 구현해보려고 하는 서비스의 구조는 위의 그림과 같다. 사용자는 로드밸런서에 할당된 고정 IP(static ip)로 서비스에 접근한다. 그러면 로드밸런서는 트래픽을 분산하여 www1 가상머신이나 www2 가상머신에 요청을 보내게 된다. 각각의 www1, www2는 받은 요청대로 html 응답을 사용자에게 보낸다. 예제에서는 www1, www2로 트래픽 분산이 실제로 일어나는지 확인하기 위해서 가상머신의 이름을 출력하는 html을 보내..
이전 포스팅에서 클라우드의 장단점을 통해서 클라우드를 알아봤다. 이번 포스팅에서는 기본적인 클라우드 컴퓨팅의 구성요소들을 알아보고 Google Cloud Platform의 특징과 서비스들을 알아본다. 먼저 하나의 질문으로 이번 글을 시작해보려고 한다. 만약 우리의 장비가 망가진다면? 철수는 소규모 인터넷 쇼핑몰을 서비스하고 있는 기업에서 웹 개발자겸 시스템 엔지니어로 근무하고 있다. 그런데 이게 웬일인가!? 서버가 먹통이되어 홈페이지로 접속이 안되고 있다! 철수는 침착하게 옆방에 있는 서버 컴퓨터를 재부팅시키고 웹 서버를 다시 실행시켜줬다. 다시 접속이 된다. 휴 다행이다. 다음날 철수 회사 근처에서 엄청난 폭우가 쏟아지고 있다. 갑자기 벼락이 회사 건물에 떨어져 정전이 되버렸다. 철수는 재빨리 옆방을 ..