잠깐만...
우리 모두는 프로덕션을 진행하느라 바쁜 상황에 직면했지만 배포 플랫폼을 선택하는 데에는 많은 요인이 고려됩니다. 음 네, 우리는 AWS를 선택하겠습니다. 일반적으로 플랫폼을 고수한 후에는 아키텍처, 비용, 안정성, 확장성, 가용성 및 타당성과 같은 몇 가지 요소에 의존할 수 있습니다. 맞춰보세요 !!! 이는 신뢰성, 확장성, 가용성 및 타당성에 관한 것이 아닙니다. AWS는 이 모든 면에서 신뢰할 수 있기 때문입니다. 이 튜토리얼에서는 Django 앱의 일부 아키텍처의 장점과 단점을 식별합니다.
진행하기 전에 무슨 일이 일어나고 있는지 완벽하게 이해하기 위한 몇 가지 전제 조건을 알아보겠습니다.
:) 이 튜토리얼에 포함된 모든 코드는 오픈소스로 제공됩니다. 마음껏 발자국을 남겨보세요.
계속 진행하기 전에 다음을 수행해야 합니다.
캐싱은 자주 액세스하는 데이터를 빠른 액세스 위치에 임시로 저장하여 이 데이터를 검색하는 데 걸리는 시간을 줄이는 데 사용되는 기술입니다. AWS에서 캐싱은 기본 데이터베이스 및 API의 로드를 최소화하여 최종 사용자의 응답 시간을 단축함으로써 애플리케이션 성능과 확장성을 향상시킵니다.
효율성을 향상하고 대기 시간을 줄이며 비용을 절감하기 위해 캐시를 사용합니다. 캐싱은 데이터를 애플리케이션에 더 가깝게 저장함으로써 데이터베이스 쿼리, 네트워크 트래픽 및 계산 부하의 빈도를 줄입니다. 이를 통해 더 빠른 데이터 검색, 향상된 사용자 경험, 최적화된 리소스 사용이 가능하며 이는 트래픽이 많은 애플리케이션에 매우 중요합니다.
EC2:
Elastic Compute Engine의 완전한 의미에서 EC2는 AWS 데이터 센터에 있는 웹 서버입니다. 즉, EC2는 AWS에서 얻을 수 있는 가상입니다. 모든 기능을 사용할 수 있는 "종량제 플랜"에 따라 매우 저렴한 월별 요금으로 구입할 수 있습니다.
AWS App Runner:
이는 웹 애플리케이션과 API의 실행과 확장을 단순화하는 완전 관리형 서비스로, 개발자가 인프라 관리 없이 코드 저장소나 컨테이너 이미지에서 빠르게 배포할 수 있도록 해줍니다.
셀러리와 장고 셀러리:
Celery는 Python의 실시간 처리를 위한 오픈 소스 분산 작업 대기열입니다. Django Celery는 Celery를 Django 프레임워크와 통합하여 Django 애플리케이션 내에서 비동기 작업 실행, 주기적 작업 및 백그라운드 작업 관리를 지원합니다. 이 기술의 사용 사례는 다양합니다. 통신 서비스(SMS, 이메일), 예약된 작업(Crons) 및 백그라운드 데이터 처리 작업(예: 데이터 집계, 기계 학습 모델 교육, 파일 처리)이 될 수 있습니다.
Amazon RDS(관계형 데이터베이스 서비스):
클라우드에서 관계형 데이터베이스의 설정, 운영 및 확장을 단순화하는 관리형 데이터베이스 서비스입니다. MySQL, PostgreSQL, Oracle 및 SQL Server와 같은 다양한 데이터베이스 엔진을 지원하여 자동화된 백업, 패치 및 고가용성을 제공하여 사용자가 데이터베이스 관리 작업에서 해방되도록 합니다.
앱이 어떻게 구성되어 있고 배포 설정이 어떻게 작동하는지 살펴보겠습니다.
AWS App Runner(ECR)를 사용한 배포 설정
코드를 GitHub에 푸시하여 CodePipeline 워크플로를 트리거합니다. CodePipeline은 CodeBuild를 사용하여 릴리스 버전 관리를 위해 ECR(Elastic Container Registry)에 저장된 Docker 이미지를 생성합니다. 이 튜토리얼에서는 Virtual Private Cloud(VPC) 구성을 건너뜁니다. CloudWatch를 사용하여 로그를 지속적으로 모니터링하여 애플리케이션 상태를 보장합니다. 그리고 보너스는 정적 파일에 대해 AWS RDS 및 S3에서 제공하는 Postgres를 사용하도록 프로젝트를 빠르게 구성하는 것입니다.
AWS EC2 인스턴스로 배포
버전 관리 및 ECR을 생략하고 유사한 프로세스를 사용하여 코드를 GitHub에 푸시하고 CodeBuild를 사용하여 버전 관리를 위해 ECR에 저장된 Docker 이미지를 생성하는 CodePipeline을 트리거합니다. EC2 인스턴스는 이러한 이미지를 가져와 VPC 내에 애플리케이션을 배포하므로 최종 사용자가 애플리케이션에 액세스할 수 있습니다. 애플리케이션은 CloudWatch에서 모니터링하는 데이터 스토리지용 RDS 및 정적 파일용 S3와 상호 작용합니다. 선택적으로 certbot과 같은 옵션을 사용하여 이 인스턴스에 SSL 구성을 추가할 수 있습니다.
다음은 일반적인 사용 시나리오를 기반으로 EC2와 App Runner 간의 가상 가격 비교입니다.
Service | Component | Cost Breakdown | Example Monthly Cost (Estimate) |
---|---|---|---|
EC2 | Instance Usage | t2.micro (1 vCPU, 1 GB RAM) | .50 |
Storage | 30 GB General Purpose SSD | .00 | |
Data Transfer | 100 GB Data Transfer | .00 | |
Total | .50 | ||
App Runner | Requests | 1 million requests | .00 |
Compute | 1 vCPU, 2 GB RAM, 30 hours/month | .00 | |
Data Transfer | 100 GB Data Transfer | .00 | |
Total | .00 |
이 두 리소스를 어떻게 관리하는지 간략하게 요약해 보겠습니다.
Factor | EC2 | App Runner |
---|---|---|
Setup | Manual setup required | Fully managed service |
Management Overhead | High - requires OS updates, security patches, etc. | Low - abstracts infrastructure management |
Configuration | Extensive control over instance configuration | Limited control, focuses on simplicity |
Factor | EC2 | App Runner |
---|---|---|
Scaling Setup | Manual setup of Auto Scaling groups | Automatic scaling based on traffic |
Scaling Management | Requires configuration and monitoring | Managed by AWS, seamless scaling |
Flexibility | High - granular control over scaling policies | Simplified, less flexible |
Factor | EC2 | App Runner |
---|---|---|
Deployment Time | Slower - instance provisioning and configuration | Faster - managed deployment |
Update Process | May require downtime or rolling updates | Seamless updates |
Automation | Requires setup of deployment pipelines | Simplified, integrated deployment |
Factor | EC2 | App Runner |
---|---|---|
Customization | Extensive - full control over environment | Limited - managed environment |
Control | High - choose specific instance types, storage, etc. | Lower - focus on ease of use |
Flexibility | High - suitable for specialized configurations | Simplified for standard web applications |
Factor | EC2 | App Runner |
---|---|---|
Security Control | High - detailed control over security configurations | Simplified security management |
Management | Requires manual configuration of security groups, IAM | Managed by AWS, less granular control |
Compliance | Extensive options for compliance configurations | Simplified compliance management |
우리 프로젝트의 비교가 프로젝트 설정 자체에 의존하지 않는다는 점을 감안할 때. AWS의 셀러리 구성을 갖춘 기본 Django 애플리케이션을 갖게 됩니다.
Django를 활용한 기본 프로젝트를 진행하겠습니다.
명령어는 아래 순서대로 실행해야 합니다.
# Project directory creation mkdir MySchedular && cd MySchedular # Creating an isolated space for the project dependencies python -m venv venv && source venv/bin/activate # Dependencies installation pip install django celery redis python_dotenv # Creating project and app django-admin startproject my_schedular . && python manage.py startapp crons # Let's add a few files to the project skeleton touch my_schedular/celery.py crons/urls.py crons/tasks.py
이 시점에서 다음을 통해 프로젝트 뼈대를 확인할 수 있습니다.
tree -I "venv|__pycache__" .
그리고 지금 이 순간엔 이게 있어야 해
. ├── crons │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ └── __init__.py │ ├── models.py + │ ├── tasks.py │ ├── tests.py + │ ├── urls.py │ └── views.py ├── manage.py └── my_schedular ├── __init__.py ├── asgi.py + ├── celery.py ├── settings.py ├── urls.py └── wsgi.py 3 directories, 16 files
이제 앱의 로직에 몇 줄을 추가하고 이 프로젝트의 또 다른 마일스톤을 다루는 것으로 진행할 수 있습니다.
1- 셀러리 설정
# my_schedular/celery.py from __future__ import absolute_import, unicode_literals import os from celery import Celery os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings') app = Celery('myproject') app.config_from_object('django.conf:settings', namespace='CELERY') app.autodiscover_tasks() @app.task(bind=True) def debug_task(self): print(f'Request: {self.request!r}')
2- 브로커를 설정하기 위해 셀러리 변수를 덮어씁니다
# my_schedular/settings.py CELERY_BROKER_URL = os.getenv('CELERY_BROKER_URL ') CELERY_RESULT_BACKEND = os.getenv('CELERY_RESULT_BACKEND')
3- Django가 시작될 때 앱이 로드되도록 init.py를 업데이트하세요.
# my_schedular/__init__.py from __future__ import absolute_import, unicode_literals from .celery import app as celery_app __all__ = ('celery_app',)
4- 작업을 만듭니다
# crons/tasks.py from celery import shared_task import time @shared_task def add(x, y): time.sleep(10) return x + y
5- 이제 간단한 Json 응답이 포함된 간단한 뷰를 추가해 보겠습니다.
# crons/views.py from django.http import JsonResponse from crons.tasks import add def index(request): return JsonResponse({"message": "Hello world, your Django App is Running"}) def add_view(request): result = add.delay(4, 6) return JsonResponse({'task_id': result.id})
6- 액세스를 가능하게 하는 엔드포인트가 없으면 뷰를 가질 수 없습니다
# crons/urls.py from django.urls import path from crons.views import add_view, index urlpatterns = [ path('', index, name='index'), path('add/', add_view, name='add'), ]
7- 전체 프로젝트의 일반 urls.py에 앱 URL을 추가합니다.
# my_schedular/urls.py from django.contrib import admin from django.urls import include, path urlpatterns = [ path('admin/', admin.site.urls), path('/', include('crons.urls')), ]
환경 변수 추가:
# .env SECRET_KEY= DEBUG= CELERY_BROKER_URL= CELERY_RESULT_BACKEND=
이러한 모든 단계를 적절하게 수행한 후에는 다음과 같은 결과가 나옵니다.
AWS로 배송 중이므로 몇 가지 리소스를 구성해야 합니다.
우리는 리소스 간의 안전한 액세스와 통신을 위해 격리된 환경과 네트워크를 만듭니다.
이전에 만든 VPC 아래에 보안 그룹을 생성하고 TCP 포트 6379(Redis 포트)에 인바운드 및 아웃바운드 규칙을 함께 추가합니다.
기본적으로 AWS Elastic Cache는 캐싱과 관련하여 RedisOSS와 memCache라는 두 가지 종류를 제공합니다. RedisOSS는 고급 데이터 구조와 지속성 기능을 제공하는 반면 Memcached는 더 간단하며 키-값 쌍의 고속 캐싱에 중점을 둡니다. Redis는 Memcached와 달리 복제 및 클러스터링도 지원합니다. 다시 비즈니스로 돌아가서 Redis로 돌아가세요.
ECR 이미지 생성은 매우 간단하고 간단합니다.
아래 단계에 따라 앱 실행기를 실행하세요.
여기서 우리는 매우 기술적이어야 합니다. VPC는 대부분의 리소스가 있는 보안 네트워크입니다. App Runner가 VPC에서 발견되지 않으므로 해당 리소스 간의 통신을 위한 보안 수단을 제공해야 합니다.
이 튜토리얼에서는 워크플로를 ECR에 연결하기 위한 승인이 필요합니다. 그런 다음 이미지를 AWS ECR에 푸시할 수 있도록 AmazonEC2ContainerRegistryFullAccess 권한 정책을 추가합니다.
모든 작업이 완료되면 다음과 같은 트리 구조가 됩니다.
My GitHub에서 이 튜토리얼의 전체 코드 베이스를 볼 수 있습니다.
We will go with one the easiest EC2 to setup and the one having a free tier, an ubuntu EC2 instance. And The same code base that was used above is the same we are using here.
![EC2 1]https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rk8waijxkthu1ule91fn.png)
Alternatively, we can setup the security group separately.
Run this script to install necessary dependencies
#!/bin/bash # Update the package list and upgrade existing packages sudo apt-get update sudo apt-get upgrade -y # Install Python3, pip, and other essentials sudo apt-get install -y python3-pip python3-dev libpq-dev nginx curl # Install Redis sudo apt-get install -y redis-server # Start and enable Redis sudo systemctl start redis.service sudo systemctl enable redis.service # Install Supervisor sudo apt-get install -y supervisor # Install virtualenv sudo pip3 install virtualenv # Setup your Django project directory (adjust the path as needed) cd ~/aws-django-redis # Create a virtual environment virtualenv venv # Activate the virtual environment source venv/bin/activate # Install Gunicorn and other requirements pip install gunicorn pip install -r requirements.txt # Create directories for logs if they don't already exist sudo mkdir -p /var/log/aws-django-redis sudo chown -R ubuntu:ubuntu /var/log/aws-django-redis # Supervisor Configuration for Gunicorn echo "[program:aws-django-redis] command=$(pwd)/venv/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 my_schedular.wsgi:application directory=$(pwd) autostart=true autorestart=true stderr_logfile=/var/log/aws-django-redis/gunicorn.err.log stdout_logfile=/var/log/aws-django-redis/gunicorn.out.log user=ubuntu " | sudo tee /etc/supervisor/conf.d/aws-django-redis.conf # Supervisor Configuration for Celery echo "[program:celery] command=$(pwd)/venv/bin/celery -A my_schedular worker --loglevel=info directory=$(pwd) autostart=true autorestart=true stderr_logfile=/var/log/aws-django-redis/celery.err.log stdout_logfile=/var/log/aws-django-redis/celery.out.log user=ubuntu " | sudo tee /etc/supervisor/conf.d/celery.conf # Reread and update Supervisor sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl restart all # Set up Nginx to proxy to Gunicorn echo "server { listen 80; server_name <your_vm_ip>; location / { proxy_pass http://127.0.01:8000; proxy_set_header Host \$host; proxy_set_header X-Real-IP \$remote_addr; proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto \$scheme; } error_log /var/log/nginx/aws-django-redis_error.log; access_log /var/log/nginx/aws-django-redis_access.log; }" | sudo tee /etc/nginx/sites-available/aws-django-redis # Enable the Nginx site configuration sudo ln -s /etc/nginx/sites-available/aws-django-redis /etc/nginx/sites-enabled/ sudo rm /etc/nginx/sites-enabled/default # Test Nginx configuration and restart Nginx sudo nginx -t sudo systemctl restart nginx
This setup is available on GitHub on the dev branch, have a look and open a PR.
Feature / Service | Self-Managed on EC2 (Free Tier) | Fully Managed AWS Services |
---|---|---|
EC2 Instance | t2.micro - Free for 750 hrs/mo | Not applicable |
Application Hosting | Self-managed Django & Gunicorn | AWS App Runner (automatic scaling) |
Database | Self-managed PostgreSQL | Amazon RDS (managed relational DB) |
In-Memory Cache | Redis on the same EC2 | Amazon ElastiCache (Redis) |
Task Queue | Celery with Redis | AWS managed queues (e.g., SQS) |
Load Balancer | Nginx (self-setup) | AWS Load Balancer (integrated) |
Static Files Storage | Serve via Nginx | Amazon S3 (highly scalable storage) |
Log Management | Manual setup (Supervisor, Nginx, Redis) | AWS CloudWatch (logs and monitoring) |
Security | Manual configurations | AWS Security Groups, IAM roles |
Scaling | Manual scaling | Automatic scaling |
Maintenance | Manual updates and patches | Managed by AWS |
Pricing | Minimal (mostly within free tier) | Higher due to managed services |
참고: 가격은 대략적인 것이며 지역 및 특정 AWS 가격 변동에 따라 달라질 수 있습니다. 특정 요구 사항에 대한 가장 정확한 비용 견적을 얻으려면 항상 현재 AWS 가격 페이지를 확인하세요.
아아아아아아아!!! 아쉽게도 이에 대한 요약은 없습니다. 예, 더 나은 이해를 위해 다시 돌아가세요.
배움의 길은 길고 어려워 보일 수 있지만, 한 번에 하나의 리소스씩 지속적으로 지식을 추가하면 목표와 목표를 달성할 수 있습니다.
위 내용은 Django 앱 배포: 외부 Celery가 포함된 EC 앱 실행기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!