1.
기술을 습득하는 방식은 사람마다 상이하다. bottom-up 방식이 편한 사람도 있으며, top-down 방식이 편한 사람도 있다.
나 같은 경우에는 top-down 방식이 친숙하다. 기술 자체에 학습 목적을 두지않고, 특정 기술이 프로젝트에 필요할 때, 학습하는 편이다.
기술을 습득하는 방식은 사람마다 상이하다. bottom-up 방식이 편한 사람도 있으며, top-down 방식이 편한 사람도 있다.
나 같은 경우에는 top-down 방식이 친숙하다. 기술 자체에 학습 목적을 두지않고, 특정 기술이 프로젝트에 필요할 때, 학습하는 편이다.
2.
involved된 프로젝트의 규모가 크면 크다는 이유(be specialist)로, 작으면 작다는 이유(low traffic)로 분명 많은 팀에서 사용하고 있지만 필요성을 느끼지 못한 기술스택들이 즐비하다. (주로 infra 계열)
involved된 프로젝트의 규모가 크면 크다는 이유(be specialist)로, 작으면 작다는 이유(low traffic)로 분명 많은 팀에서 사용하고 있지만 필요성을 느끼지 못한 기술스택들이 즐비하다. (주로 infra 계열)
3.
특히 container orchestration은 왜 사용해야하는지에 의문이 항상 있었고, 주변의 인프라 개발자들에게 매번 k8s 사용 이유에 대해서 묻곤 했다.
여러 답변들을 들었지만, 그럼에도 container orchestration이 없으면 불편한 이유에 대해 명확하게 와닿진 않았다.
특히 container orchestration은 왜 사용해야하는지에 의문이 항상 있었고, 주변의 인프라 개발자들에게 매번 k8s 사용 이유에 대해서 묻곤 했다.
여러 답변들을 들었지만, 그럼에도 container orchestration이 없으면 불편한 이유에 대해 명확하게 와닿진 않았다.
4.
물음표를 가지고 있던 때마침, 개발 중인 현 프로젝트에서 golang으로 서버를 작성했고, 해당 서버를 배포해야할 니즈가 생겨 이 참에 정리하고자 마음을 먹었다.
나처럼 server보단 client 위주의 개발을 주로했던 분들은, 본 스레드가 인프라의 전반적 이해 증진에 도움이 될라 생각한다.
물음표를 가지고 있던 때마침, 개발 중인 현 프로젝트에서 golang으로 서버를 작성했고, 해당 서버를 배포해야할 니즈가 생겨 이 참에 정리하고자 마음을 먹었다.
나처럼 server보단 client 위주의 개발을 주로했던 분들은, 본 스레드가 인프라의 전반적 이해 증진에 도움이 될라 생각한다.
5. 컨테이너
보통 컨테이너라고 하면, docker를 떠올린다.
얘가 필요한 이유는 명확하다.
"내 로컬에선 잘되는데?"의 이슈를 해소시켜준다.
이를 resource virtualization이라고 하는데, 다른 시스템 환경(os 등)에서도 이를 사용하면 동일 코드, 동일 동작을 보장한다.
보통 컨테이너라고 하면, docker를 떠올린다.
얘가 필요한 이유는 명확하다.
"내 로컬에선 잘되는데?"의 이슈를 해소시켜준다.
이를 resource virtualization이라고 하는데, 다른 시스템 환경(os 등)에서도 이를 사용하면 동일 코드, 동일 동작을 보장한다.
6.
"그럼 vm이랑 같은거 아닌가"라는 생각이 들 수 있는데, 맞다.
vm과 container는 기술적으로 유사하며, 둘의 차이는 layer에 있다.
vm - 하드웨어 레이어까지 가상화
container - 소프트웨어 레이어까지 가상화
"그럼 vm이랑 같은거 아닌가"라는 생각이 들 수 있는데, 맞다.
vm과 container는 기술적으로 유사하며, 둘의 차이는 layer에 있다.
vm - 하드웨어 레이어까지 가상화
container - 소프트웨어 레이어까지 가상화
7. 컨테이너 오케스트레이션
"내 로컬에선 되는데요?"를 줄이기 위해서 소프트웨어의 배포 환경을 컨테이너에 말아 작업하는 것까진 이해했다.
그럼 컨테이너 오케스트레이션은 왜 필요한가?
이를 이해하기 위해 우리가 운영하는 컨테이너의 갯수가 100개 이상이라고 가정해보자
"내 로컬에선 되는데요?"를 줄이기 위해서 소프트웨어의 배포 환경을 컨테이너에 말아 작업하는 것까진 이해했다.
그럼 컨테이너 오케스트레이션은 왜 필요한가?
이를 이해하기 위해 우리가 운영하는 컨테이너의 갯수가 100개 이상이라고 가정해보자
8.
이 때, 갑자기 서비스에 장애가 발생하여, 100개의 컨테이너에서 돌아가는 application이 종료됐다.
우리는 모든 컨테이너에 직접 접근해서, 어플리케이션을 재실행시켜야한다.
반복과 중복을 싫어하는 우리는 이를 해결할 방법이 필요하다.
그걸 해주는 것이 컨테이너 오케이트레이션이다.
이 때, 갑자기 서비스에 장애가 발생하여, 100개의 컨테이너에서 돌아가는 application이 종료됐다.
우리는 모든 컨테이너에 직접 접근해서, 어플리케이션을 재실행시켜야한다.
반복과 중복을 싫어하는 우리는 이를 해결할 방법이 필요하다.
그걸 해주는 것이 컨테이너 오케이트레이션이다.
9.
컨테이너 오케스트레이션은 컨테이너를 관리하는데 드는 리소스를 줄여준다. 그것만으로 우리는 충분히 컨테이너 오케스트레이션을 사용할 이유가 있다.
컨테이너 오케스트레이션이 제공하는 기능은 많겠지만, 아직 나도 많이 사용해보진 않아서 기회가 되면 따로 정리하겠다.
컨테이너 오케스트레이션은 컨테이너를 관리하는데 드는 리소스를 줄여준다. 그것만으로 우리는 충분히 컨테이너 오케스트레이션을 사용할 이유가 있다.
컨테이너 오케스트레이션이 제공하는 기능은 많겠지만, 아직 나도 많이 사용해보진 않아서 기회가 되면 따로 정리하겠다.
10.
이제 우리는 컨테이너 오케스트레이션을 사용이점을 깨달았다. 그러나 어떤 서비스를 사용할 지는 아직 정하지않았다.
정말 많은 서비스들이 존재하지만 전부 나열할 필요도, 전부 알 필요도 없다 생각한다.
이제 우리는 컨테이너 오케스트레이션을 사용이점을 깨달았다. 그러나 어떤 서비스를 사용할 지는 아직 정하지않았다.
정말 많은 서비스들이 존재하지만 전부 나열할 필요도, 전부 알 필요도 없다 생각한다.
11.
유명한 컨테이너 오케스트레이션 서비스를 나열해보면 다음 정도로 추릴 수 있겠다.
- Docker Swarm
- Kubernetes
- AWS ECS
- AWS EKS
우리는 각자의 프로젝트에 맞도록, 다음 중 하나를 선택해서 사용하면된다.
중점적으로 볼 것은 1) Sustainable 2) Customize다.
유명한 컨테이너 오케스트레이션 서비스를 나열해보면 다음 정도로 추릴 수 있겠다.
- Docker Swarm
- Kubernetes
- AWS ECS
- AWS EKS
우리는 각자의 프로젝트에 맞도록, 다음 중 하나를 선택해서 사용하면된다.
중점적으로 볼 것은 1) Sustainable 2) Customize다.
12.
지속가능성(Sustainable)은 이미 크게 입지를 굳힌 서비스로, 많은 개발자들이 사용해서 유지보수가 쉽고, 사장되지않을 기술을 의미한다.
커스터마이즈(Customize)는 얼마나 설정에 대한 자유도가 높은지를 의미한다. 딥하게 커스텀을 해야하면 Saas보다는 직접 운영하는게 옳을 수 있다.
지속가능성(Sustainable)은 이미 크게 입지를 굳힌 서비스로, 많은 개발자들이 사용해서 유지보수가 쉽고, 사장되지않을 기술을 의미한다.
커스터마이즈(Customize)는 얼마나 설정에 대한 자유도가 높은지를 의미한다. 딥하게 커스텀을 해야하면 Saas보다는 직접 운영하는게 옳을 수 있다.
13.
이에 근거하여 운용할 서비스 관점에서 평가해보자면
1) Docker Swarm
- Sustainable 🔴
- 중소규모 프로젝트에 적합하지만, 사용유저 풀이 적다.
2) Kubernetes
- Learning Curve 🔴
- Sustainable 🟢
- Customize 🟢
- 좋은 선택지이지만, 러닝커브가 심하고, 운용 리소스가 많이든다.
이에 근거하여 운용할 서비스 관점에서 평가해보자면
1) Docker Swarm
- Sustainable 🔴
- 중소규모 프로젝트에 적합하지만, 사용유저 풀이 적다.
2) Kubernetes
- Learning Curve 🔴
- Sustainable 🟢
- Customize 🟢
- 좋은 선택지이지만, 러닝커브가 심하고, 운용 리소스가 많이든다.
14.
3) AWS ECS (✅)
- Learning Curve 🟢
- Sustainable 🟢
- AWS의 서비스로 운용 리소스 부담을 줄이고, 다른 AWS 서비스와의 확장성이 좋다.
4) AWS EKS
- Project fit🟡
- Sustainable 🟢
- Customize 🟢
- AWS에서 k8s를 운용하도록 도와주는 서비스로 ECS보다는 자율성이 높다.
3) AWS ECS (✅)
- Learning Curve 🟢
- Sustainable 🟢
- AWS의 서비스로 운용 리소스 부담을 줄이고, 다른 AWS 서비스와의 확장성이 좋다.
4) AWS EKS
- Project fit🟡
- Sustainable 🟢
- Customize 🟢
- AWS에서 k8s를 운용하도록 도와주는 서비스로 ECS보다는 자율성이 높다.
15.
이러한 관점에서 이번 프로젝트에서 운용해볼 컨테이너 오케스트레이션 서비스는 AWS ECS로 정했다.
운용 후, 장단점은 어떤게 있는지 서술해보겠다.
추가적으로 AWS에서 사용할 수 있는 컨테이너 서비스에 대한 글이 있으니, 참고하면 좋다.
aws.amazon.com/ko/blogs/korea…
이러한 관점에서 이번 프로젝트에서 운용해볼 컨테이너 오케스트레이션 서비스는 AWS ECS로 정했다.
운용 후, 장단점은 어떤게 있는지 서술해보겠다.
추가적으로 AWS에서 사용할 수 있는 컨테이너 서비스에 대한 글이 있으니, 참고하면 좋다.
aws.amazon.com/ko/blogs/korea…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
