컨테이너 vs. 서버리스

컨테이너 vs. 서버리스 : 어떤 제품을 언제 사용해야합니까?

 

서버리스 및 컨테이너는 종종 경쟁 개발 기술서버리스

 

 

서버리스가 무엇인지, 장단점을 간단히 살펴 보겠습니다.

 

서버리스란?

 

서버리스는 장기 실행 가상 머신을 필요에 따라 존재하고 사용 직후 사라지는 컴퓨팅 성능으로 대체하는 개발 접근 방식입니다.

이름에도 불구하고 애플리케이션 실행과 관련된 서버가 확실히 있습니다. AWS, Azure 또는 Google Cloud Platform에 관계없이 클라우드 서비스 공급자가 이러한 서버를 관리하고 항상 실행되는 것은 아닙니다.

대신 서버리스 함수를 실행하도록 트리거하는 API 요청 또는 파일 업로드와 같은 이벤트를 구성합니다. 해당 작업이 완료되면 다른 작업이 요청 될 때까지 서버가 유휴 상태가되며 유휴 시간에 대한 요금이 청구되지 않습니다.

서버리스의 장점

 

서버리스의 장점 

 

1. 서버가 작업을 실행할 때만 시간을 지불

 

2. 이벤트가 트리거 할 때만 실행

 

3.짧은 시간에 대해서만 비용을 지불합니다. 약

 

4. 서버리스를 사용하면 앱을 탄력적으로 사용

 

5.  동시 사용자를 수용 할 수 있도록 자동으로 확장되고 트래픽이 감소하면 축소

 

6. 비용을 절약하면서 앱의 성능을 향상

 

7. 서버 관리에 훨씬 적은 시간을 할애

 

8. 인프라 프로비저닝, 용량 관리 또는 다운 타임 방지

 

9. 클라우드 서비스 공급자가 모든 작업을 수행합니다.

 

10. 서버리스 아키텍처는 개발 시간을 줄이고 제품을 더 빨리 출시 할 수 있도록 도와줍니다

 

11. . 인프라에 집중할 필요가없는 경우 가능한 최고의 제품을 구축하는 데 시간을 할애

 

12. 서버리스는 또한 개발자가 소프트웨어 전체에서 더 작고 느슨하게 결합 된 부분을 구축 

 

13. 마이크로 서비스 와도 매우 잘 맞습니다 . 

 

14. 개발자가 자체 서버 인스턴스를 가동해야하는 필요성을 완화

 

15. 마이크로 서비스를 훨씬 더 빠르게 구축

 

16. 서버리스 기능은 장기 호스팅 위치가 필요하지 않기 때문에 특정 클라우드 서버에 할당 할 필요가 없으며 특정 가용성 영역으로 제한되지 않습니다. 이것은 본질적으로 가용성을 높입니다.

 

서버리스의 단점

 

1. 서버는 애플리케이션에서 핑할 때까지 차갑게 유지되기 때문에 작업 실행과 관련된 약간의 지연시간

 

2. 전자 상거래 및 검색 사이트와 같이 속도가 가장 중요한 애플리케이션에 이상적인 솔루션이 아님

 

3. 공급 업체 종속도 문제입니다. 클라우드 서비스 공급자 (예 : AWS Lambda, Azure Functions 또는 Google Cloud Functions)의 서버리스 제품을 사용하고 다른 CSP로 마이그레이션하기로 결정한 경우 코드베이스를 크게 변경해야 할 수 있습니다. 그리고 이것은 많은 시간과 돈이 필요할 수 있습니다.

 

4. 서버리스를 추상화하고 한 공급자에서 다른 공급자로보다 쉽게 ​​이동

 

5. Serverless Framework 또는 Spring Cloud Function 과 같은 프레임 워크를 사용

 

6. 서버리스의 이벤트 기반 특성으로 인해 장기 실행 앱에는 최선의 선택

 

7. 큰 데이터 세트를 분석하는 온라인 게임 및 앱은 서버리스 기능이 종료되기 전에 시간 제한 (일반적으로 5 분)이 있기 때문에 서버리스 아키텍처에 적합하지 않습니다.

 

8. 서버리스의 또 다른 단점은 서버를 많이 제어 할 수 없다

 

9. 함수가 얻는 메모리 양을 선택할 수 있지만 CSP는 소량의 디스크 스토리지를 할당하고 나머지 사양을 결정합니다. 

 

10. 큰 이미지 또는 비디오 파일을 처리하기 위해 GPU와 같은 것이 필요한 경우 이는 방해가 될 수 있다.

 

11. 마지막으로 복잡한 앱은 서버리스 아키텍처를 사용하여 구축하기 어려울 수 있습니다. 많은 조정을 수행하고 모든 서버리스 기능 간의 종속성을 관리해야하므로 크고 복잡한 응용 프로그램에서는 어려운 작업이 될 수 있습니다.

보시다시피 서버리스에는 장점과 단점이 있습니다. 이제 컨테이너가 어떻게 쌓이는 지 살펴 보겠습니다.

 

컨테이너

컨테이너 란?

Docker에 따르면 컨테이너는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정과 같이 컨테이너를 실행하는 데 필요한 모든 것을 포함하는 소프트웨어의 경량 독립 실행 형 패키지입니다.

컨테이너는 기본적으로 해당 환경에서 격리하여 하나의 컴퓨팅 환경에서 이동 한 소프트웨어 실행 문제를 해결합니다. 예를 들어 컨테이너를 사용하면 소프트웨어를 개발에서 스테이징으로, 스테이징에서 프로덕션으로 이동할 수 있으며 모든 환경의 차이에 관계없이 안정적으로 실행할 수 있습니다.

 

컨테이너 아키텍처 – 이미지 제공 : Google Cloud

 

컨테이너의 장점

 

1. 컨테이너의 첫 번째 이점은 이식성

 

2. 응용 프로그램과 모든 종속성을 깔끔한 작은 패키지로 결합하여 어디서나 실행

 

3. 유연성과 이동성을 제공하고 클라우드 공급 업체에 구애받지 않는 상태를 유지

 

4. 서버리스 아키텍처와 비교할 때 다음 장점은 애플리케이션을 완전히 제어

 

5. 귀하는 도메인의 마스터입니다. 개별 컨테이너, 전체 컨테이너 생태계 및 실행되는 서버를 지배

 

6. 모든 리소스를 관리하고, 모든 정책을 설정하고, 보안을 감독하고, 애플리케이션이 배포되고 작동하는 방식을 결정

 

7. 원하는대로 디버그 및 모니터링 할 수 있습니다. 이것은 서버리스의 경우가 아닙니다. 오히려 모든 것이 CSP에서 관리됩니다.

8. 컨테이너 기반 애플리케이션은 서버리스처럼 메모리 나 시간 제한이 없기 때문에 필요한만큼 크고 복잡 할 수도 있습니다.

 

컨테이너의 단점

1. 컨테이너를 설정하고 관리하는 데 훨씬 더 많은 작업이 필요

 

2. 코드베이스를 변경할 때마다 컨테이너를 패키징하고 프로덕션에 배포하기 전에 모든 컨테이너가 서로 제대로 통신하는지 확인

 

3. 빈번한 보안 수정 및 기타 패치를 사용하여 컨테이너의 운영 체제를 최신 상태로 유지

 

4. 컨테이너가 어떤 서버로 이동하는지 파악해야합니다. 이 모든 것이 개발 프로세스를 늦출 수 있습니다.

 

5. 컨테이너에는 장기 실행 호스팅 위치가 필요하기 때문에 서버리스 기능보다 실행 비용이 더 많이 듬

 

6. 서버리스를 사용하면 서버가 기능을 실행할 때만 비용을 지불

 

7. 컨테이너를 사용하면 유휴 상태 인 경우에도 서버 사용량에 대해 비용을 지불

 

8. 첫 번째 문제는 모니터링 입니다. 

 

9. 애플리케이션이 성장함에 따라 점점 더 많은 컨테이너가 추가

 

10. 컨테이너는 고도로 분산되고 흩어져 있으며 지속적으로 변경되므로 모니터링을 악몽

 

11. 또한 컨테이너 수가 증가함에 따라 데이터 및 스토리지를 확장하는 것도 어렵습니다.

 

12.  컨테이너의 일정이 변경되거나 폐기 될 때 데이터 지속성이 없기 때문에 변경시 데이터가 손실되는 경우가 많습니다. 

 

13. 서로 다른 위치 또는 클라우드 서비스 제공 업체간에 데이터를 이동하기가 어렵습니다. 

 

14. 스토리지는 앱과 함께 확장되지 않아 예측할 수없는 성능 문제가 발생합니다.

 

 

언제 각각을 사용해야합니까?

1. 컨테이너는 환경에 대한 높은 수준의 제어가 필요하고 애플리케이션을 설정 및 유지 관리 할 리소스가있는 복잡하고 장기 실행 애플리케이션에 가장 적합합니다.

 

2. 컨테이너는 모 놀리식 레거시 애플리케이션을 클라우드로 마이그레이션하는 데에도 매우 유용

 

3. 컨테이너화 된 마이크로 서비스로 분할하고 Kubernetes 또는 Docker Swarm 과 같은 도구를 사용하여 오케스트레이션 할 수 있습니다 .

 

4. 컨테이너는 대형 전자 상거래 웹 사이트와 같은 앱에 이상적입니다. 

 

5. 제품 목록, 지불 처리, 재고 관리 등과 같은 많은 부분이 포함되어 있습니다. 시간 제한이나 메모리 문제에 대해 걱정할 필요없이 컨테이너를 사용하여 이러한 각 서비스를 패키징 할 수 있습니다.

 

6. 서버리스는 작업을 수행 할 준비가되어 있어야하지만 항상 실행될 필요는없는 앱에 가장 적합합니다. 

 

7. 예를 들어 서버리스는 물 저장 시설의 누수를 식별하기 위해 물의 존재를 감지하는 사물 인터넷 (IoT) 애플리케이션에 적합한 선택입니다. 앱이 항상 실행될 필요는 없지만 누출시 조치를 취할 준비가되어 있어야합니다.

 

8. 서버리스는 개발 속도와 비용 최소화가 가장 중요하고 확장 문제를 관리하지 않으려는 경우에 이상적입니다.

 

 

 

서버리스와 컨테이너가 함께 작동 할 수 있습니까?

의심 할 여지가 없습니다!

서버리스와 컨테이너는 다른 사람의 약점을 보완 할 수있는 강점을 가지고 있으며이 두 기술을 함께 통합하면 매우 유익 할 수 있습니다.

컨

 

1. 컨테이너 기반 마이크로 서비스 아키텍처를 사용하여 크고 복잡한 애플리케이션을 빌드 할 수 있습니다. 그러나 애플리케이션은 데이터 전송, 파일 백업 및 경고 트리거와 같은 일부 백엔드 작업을 서버리스 기능에 전달할 수 있습니다. 이것은 비용을 절약하고 응용 프로그램의 성능을 향상시킬 수 있습니다.

 

2. AWS Fargate 는 컨테이너와 서버리스 간의 일종의 하이브리드 도구로 이러한 각 기술이 제공하는 일부 문제를 완화하는 데 도움이 될 수 있습니다.

 

3. Fargate는 Amazon Elastic Container Service (ECS) 및 Elastic Container Service for Kubernetes (EKS)를위한 컴퓨팅 엔진으로, 서버 또는 클러스터를 관리하지 않고도 컨테이너를 실행할 수 있습니다. 컨테이너를 실행하기 위해 가상 서버를 프로비저닝, 구성 또는 확장 할 필요가 없습니다. 따라서 Fargate는 컨테이너의 이동성과 서버리스의 탄력성 및 사용 용이성을 결합합니다.

 

Fargate의 작동 방식 – 이미지 제공 : AWS

 

서버리스에 관심사 중 하나는 이식성이 부족하다는 것입니다. 

 

1. 기본적으로 Fargate는 컨테이너 서비스 (서버리스 속성 포함)이므로 이식성은 문제가되지 않습니다. 

 

2. Fargate는 EKS를 통해 Kubernetes 와도 작동하므로 Azure (Azure Kubernetes Service) 또는 Google Cloud Platform (Google Kubernetes Engine)과 같은 다른 클라우드 플랫폼으로 매우 이식 가능합니다.

 

3. 서버리스의 추가 문제로는 최대 5 분의 런타임 및 메모리 제한이 있습니다. 

 

4. 이 문제를 해결하기 위해 Fargate를 사용하여 소프트웨어 개발 부사장 인 Dan Rusk가 "Fat Lambda"라고 부르는 것을 만들 수 있습니다.

 

5. Fat Lambda를 생성하려면 다음을 수행하십시오.

• 컨테이너에 코드 래핑
• 해당 컨테이너를 Elastic Container Repository (ECR)에 배포
• Fargate의 작업에서 해당 컨테이너를 실행합니다 (CloudWatch로 예약하거나 Lambda에서 트리거 할 수 있음).
• 필요한 경우 결국이를 ECS EC2 클러스터에서 실행되도록 변환합니다.

6. 작업이 Lambda에 비해 너무 커지면 Fat Lambda가 실행되도록 트리거 할 수 있습니다. 

 

7. 매우 멋진 해결 방법입니다. Columbia AWS Meetup 에서 Dan의 Fat Lambda 프레젠테이션에 대한 아래 비디오를 확인하십시오 .

 

 

 

결론

서버리스와 컨테이너가 서로 경쟁하지 않고 서로를 보완하는 방식으로 사용될 수 있다는 결론

 

1. Docker Swarm을 오케스트레이션 엔진으로 사용하여 Docker를 구현하기 시작했으며 가까운 장래에 Kubernetes로 이동할 계획입니다.

 

2. 애플리케이션에 서버리스를 통합하는 방법을 계속 연구하고 있습니다.

 

3. 컨테이너와 서버리스는 지속적으로 비교되고 경쟁하는 것으로 보이는 점점 더 인기있는 두 가지 개발 기술