AWS에서 NextJS SSR 응용 프로그램 실행

14062 단어 nextjsapprunneramplify
이 문서를 작성할 때 AWS는 NextJS SSR 응용 프로그램을 실행하는 다양한 옵션을 제공합니다.AWS 관리에 대한 자체 관리 규모에서는 다음 옵션이 제공됩니다.

이들 옵션 중 AWS 관리 제품과 관련된 최고의 개발자 경험은Amplify HostingApp Runner이다.그것들은 AWS 처리의 모든 하부 세부 사항을 제공합니다. CI/CD 파이프를 통해 배치하기만 하면 됩니다. 나머지는 모두 보증됩니다. (신축성, 로그, 사용자 정의 영역, 인증서 자동 갱신 등)
저는 Amplify Hosting과 App Runner 두 가지 응용 프로그램을 시도하여NextJS SSR 응용 프로그램을 개발했습니다. 결국 저는 Applify Runner를 사용하고 더 좋아합니다.나는 본문이 제공한 내용도 다른 사람에게 유용할 수 있기를 바란다.

Amplify 호스팅의 제약 조건 및 사전 요구 사항


Amplify Hosting은 서버측 렌더링이 필요 없는 SPA를 실행하는 데는 잘 하고 있지만, SSR 하면 강조해야 할 구속과 선결 조건이 중요하다.
우선, 이 문서를 작성할 때, Amplify Hosting에서 SSR 프로그램을 실행하기 위해서는 Next.js apps can only be deployed with Continuous deployment. AWS currently do not support manual deployments of Next.js apps. 원본 코드를 연결해야 합니다. 만약 코드가 하나의 주 지점에서 여러 환경으로 배치된다면, 이것은 큰 도전이 될 것입니다.Amplify Hosting의 모든 환경은 같은 주 지점을 감청해야 하며, 어떠한 승인이나 테스트를 진행하기 전에 코드는 Sandbox나 dev 환경에 들어가는 동시에 생산 환경에 들어갈 수 있기 때문입니다.이 문제를 해결하는 방법의 하나는 모든 환경에서 하나의 지점을 사용하는 것이지만 이것은 Continuous Delivery의 개념과 상충된다.
그 다음으로yaml 파일에서 구축 정의를 설정해야 합니다. 이 파일은NextJS SSR을 내보내는 방식을 변경해야 합니다.나는 이것이 매우 곤혹스럽다고 생각한다.
구축 단계에서 다음 변경 사항을 따르면 일부 NextJS 기능을 사용할 수 없는 등의 문제가 발생합니다.Currently, Amplify doesn’t fully support Image Component and Automatic Image Optimization available in Next.js 10. To manually deploy the next-app example, you must edit the index.js file to remove this feature.

"scripts": {
  "dev": "next dev",
  "build": "next build && next export",
  "start": "next start"
},

셋째as documented in AWS Docs, Amplify Hosting은 S3 bucket, 클라우드 Front 발행판과 하나를 구축했다.Lambda@EdgeSSR 어플리케이션을 호스팅하기 위한 스태킹단일 프런트엔드 애플리케이션의 경우 모바일 부품이 너무 많이 들릴 수 있고, 프런트엔드 애플리케이션은 CDN을 통해 전 세계적으로 가용성을 실현할 가능성이 있다.이 단계에서 가장 재미있는 발견은Lambda@Edge이다.제가 알기로는 Amplify Hosting이Lambda@Edge매우 제한된 시간 초과가 있다.Github에 관한 몇 가지 문제에서 나는 이 점을 보았다Lambda@Edge빠른 시간 초과에 있어서 일부 작업 부하를 제한합니다.또한 due to how Lambda@Edge works CloudFront와Lambda@Edge중앙에서 관리하다.

마지막으로, Amplify 위탁 관리를 선택할 때, 당신은 일반적인 업무 절차에 들어간다.기존 CI/CD 파이프 위에서 코드를 Amplify CD 파이프로 밀어 넣고 있습니다. 이 파이프는 AWS 콘솔에서만 볼 수 있습니다.이는 기존 CI/CD 파이프라인에서 실시간 가시성이 없고 AWS Amplify Console에서 배치 진행률을 점검한다는 의미입니다.나는 어떤 해결 방법이 있는지 확실하지 않지만, CD 파이프의 연결을 끊는 여러 개의 도구가 있는 것은 좋은 개발자의 체험이 아니다.또한 NextJS SSR 애플리케이션을 터치하는 모든 프런트엔드 개발자가 AWS 콘솔에 액세스할 수 있도록 하는 보안 측면도 까다롭다.이들 프런트엔드 개발자도 전체 AWS 콘솔 체험에 익숙하지 않을 수 있기 때문에 이것은 안전 문제이자 학습 곡선 문제이기도 하다.

AWS 어플리케이션 실행이 적합합니다!


AWS App Runner는 완전히 관리된 서비스로 개발자가 용기화된 웹 응용 프로그램과 API를 쉽게 배치할 수 있고 이전의 인프라 경험이 필요하지 않게 한다.
이는 기존 도구를 사용하여 NextJS SSR 응용 프로그램에 CI/CD 파이프를 구축하는 데 큰 장점을 제공하고 이를 어떻게 실현하는지에 큰 유연성을 제공한다.이를 위해서는 몇 줄의 CDK 코드와 docker 파일만 필요합니다.
App Runner 애플리케이션은 25개의 인스턴스로 자동으로 확장되며 HTTP 요청이 없을 때 하나의 인스턴스로 확장됩니다.이것은 로트 53, ALB, VPC, 보안 그룹 등을 처리하지 않고 Fargate에 용기를 배치하는 방법에 가깝다. 모든 낮은 수준의 구조는 AWS에서 관리한다.

import * as cdk from "@aws-cdk/core";
import { Duration, NestedStack, NestedStackProps } from "@aws-cdk/core";
import * as apprunner from "@aws-cdk/aws-apprunner";
import * as ecrAssets from "@aws-cdk/aws-ecr-assets";

export class WebStack extends NestedStack {
    constructor(scope: cdk.Construct, id: string, props: NestedStackProps) {
        super(scope, id, props);

        /**
         * Create a docker image and push to ECR
         */
        const imageAsset = new ecrAssets.DockerImageAsset(this, "WebAppImage", {
            directory: "../src",
        });

        /**
         * Deploy to App Runner from the docker image pushed to ECR
         */
        const service = new apprunner.Service(this, "WebApp", {
            source: apprunner.Source.fromAsset({
                asset: imageAsset,
            }),
            cpu: apprunner.Cpu.TWO_VCPU,
            memory: apprunner.Memory.FOUR_GB,
        });
    }
}

이 설정에서 몇 가지 주의해야 할 점이 있습니다.
  • 응답성과 성능이 좋은 NextJS SSR 어플리케이션이 필요한 최소 CPU는 apprunner.Cpu.TWO_VCPU입니다.그렇지 않으면 API가 다운스트림 서비스에 연결되어 데이터를 수신하면 시간이 빨리 초과되어 500 Server Error
  • 불행하게도 최소 메모리는 App Runner가 지원하는 최대 메모리apprunner.Memory.FOUR_GB가 되어야 한다.이것 또한 node 서버에 충분한 호스트 공간을 확보하여 처리하기 위해서이다.
  • 다음 단계는 기본적으로 너를 맞이하는 NextJS SSR이다.이를 위해 NextJS는 간단한 Docker 파일을 제공합니다.너는 이것을 네 src 폴더에 넣기만 하면 된다.나머지 부분은 CDK auto가 신기하게 처리했다.
    
    # Install dependencies only when needed
    FROM node:14-alpine AS deps
    # Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
    RUN apk add --no-cache libc6-compat
    WORKDIR /app
    COPY package.json ./
    RUN npm install
    
    # Rebuild the source code only when needed
    FROM node:14-alpine AS builder
    WORKDIR /app
    COPY . .
    COPY --from=deps /app/node_modules ./node_modules
    RUN npm run build
    
    # Production image, copy all the files and run next
    FROM node:14-alpine AS runner
    WORKDIR /app
    
    ENV NODE_ENV production
    
    RUN addgroup -g 1001 -S nodejs
    RUN adduser -S nextjs -u 1001
    
    # You only need to copy next.config.js if you are NOT using the default configuration
    COPY --from=builder /app/next.config.js ./
    COPY --from=builder /app/public ./public
    COPY --from=builder --chown=nextjs:nodejs /app/.next ./.next
    COPY --from=builder /app/node_modules ./node_modules
    COPY --from=builder /app/package.json ./package.json
    COPY --from=builder /app/.env ./
    
    USER nextjs
    
    EXPOSE 3000
    
    ENV PORT 3000
    
    # Next.js collects completely anonymous telemetry data about general usage.
    # Learn more here: https://nextjs.org/telemetry
    # Uncomment the following line in case you want to disable telemetry.
    ENV NEXT_TELEMETRY_DISABLED 1
    
    CMD ["node_modules/.bin/next", "start"]
    
    
    이것은 정말 타협하지 않는 구축 과정으로 당신의NextJS 구축을 최상의 효과를 얻을 수 있습니다.
    이 스택을 배치해야 할 경우 CI/CD 파이프에서 다음 작업을 수행하기만 하면 됩니다.
    cdk bootstrap
    cdk deploy
    

    App Runner의 기타 이점


    다음은 언급할 만한 앱 런너의 다른 우수한 부분이다.

    사용자 정의 도메인 및 자동 갱신된 HTTPS 인증서


    사용자 정의 영역을 연결할 수 있습니다. 몇 분 동안 NextJS SSR 프로그램은 HTTPS를 통해서만 접근할 수 있습니다.이 문서가 실제로 작동하도록 하기 위해서, 이 문서를 작성할 때, Route53 기록을 업데이트하고 몇 개의 CNAME 항목을 추가해야 합니다
    너도 여러 필드를 같은 응용 프로그램에 연결할 수 있다.

    로그 사용을 환영합니다!


    당신console.log은 App Runner 콘솔을 통해 신기하게도 자동으로 볼 수 있습니다.CloudWatch는 일반적으로 더 좋은 선택이지만 간단한 작업 부하에 문제가 발생하고 로그가 필요할 때 많은 시간을 절약할 수 있다.

    물론, 지표!


    일부 기본 지표들은 어떠한 노력도 필요 없이 이미 쓸 수 있다.

    결론


    만약 프런트엔드 응용 프로그램이 서버 측의 렌더링을 필요로 하지 않는다면, Amplify가 제공하는 S3와 CDN을 이용하여 위탁 관리를 확대함으로써 뛰어난 사용자 체험을 얻을 수 있다.이것은 정말 시장에서 가장 좋은 전단 개발자 체험 중의 하나이다.
    그러나 사이트의 SEO 순위, 1바이트 시간(TTFB)과 첫 번째 콘텐츠 그리기(FCP)를 높이기 위해 가장 중요한 것은 API층에서 하류/백엔드 서비스에 연결하고 브라우저와 클라이언트에게 어떠한 정보도 누설하지 않고 더욱 좋은 안전성을 얻기 위해 앱 런너를 사용하는 것이 더욱 유연한 선택이다.넥스트JS SSR뿐만 아니라 SSR이 필요한 NodeJS 응용 프로그램(익스프레스, Gatsby, React SSR(실험성) 등)에도 앱 런너는 설치하기 쉬울 것 같고 아주 낮은 CI/CD 파이프만 있으면 된다.
    App Runner를 사용하는 장기적인 장점 중 하나는 부두에 SSR 웹 응용 프로그램을 정박하는 것이다.이것은 웹 응용 프로그램을 더 복잡한 설정으로 옮길 수 있는 기회를 준다. 예를 들어Fargate, 심지어 EKS (네, 저는 자신의 k8s 집단에서 SSR 서비스를 대규모로 제공하는 수욕 센터를 본 적이 있습니다)🤓).

    좋은 웹페이지 즐겨찾기