GW LABS

이번 포스팅에서는 서버리스 아키텍처에 대해 알아본다. 지금까지 클라우드 서비스를 이용하면 네트워크와 하드웨어, 운영체제 등을 IT 팀이 직접 구축하지 않아도 되고 pay-as-you-go 형태로 인프라를 사용할 수 있다는 점을 배웠다. 그런데 서비스가 커지면 클라우드 상에서 관리해야할 자원들이 많아지고, 이로 인한 이슈도 점점 늘어날 것이다. 특히 설계했던 아키텍처에 문제가 있어서 설계를 변경해야 한다면 서비스 중단시간이 발생할 수도 있고, IT 팀이 대용량 트래픽 경험이 부족하다면 어플리케이션 자체에 문제가 있을 수도 있다. 이를 해결하고자 나온 개념이 서버리스 아키텍처이다. 서버리스 서버리스 아키텍처는 인프라를 관리할 필요없이 애플리케이션과 서비스를 구축하고 실행하는 방식이다. 서버, 미들웨어 등을 ..

이번 포스팅에서는 GCP 내에서 kubernetes를 다루는 방법에 대해 알아본다. kubernetes는 컨테이너 오케스트레이션의 표준으로 자리잡고 있다. 대부분의 클라우드 제공자들은 kubernetes 엔진 및 서비스들을 제공하고 있고 GCP에서는 아주 손쉽게 kubernetes를 사용할 수 있다. 이는 GCP에서 kubernetes를 쉽게 이용할 수 있도록 Google Kubernetes Engine(GKE)을 제공하기 때문이다. 이 포스팅에서는 GCP 내에서의 kubernetes를 다루는 기본적인 사항에 대해 다루기 때문에 kubernetes에 대한 개념과 로컬 개발환경에 대한 포스팅은 아래 링크를 참조하자. kubernetes 시작하기 Docker와 같은 컨테이너 기술은 개발팀의 개발환경 구성문제..

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 정책으로 접근권한이 없다는 메세..