Amazon Web Services 한국 블로그

AWS Step Functions를 통해 서비스 플로우 개선 – 코카콜라 지불 서비스 사례

Amazon의 혁신 문화에 대한 프레젠테이션을 할 때가 많은데 이때마다 Amazon 창업자인 Jeff Bezos의 말을 인용한 슬라이드로 시작합니다.

고객과 함께 머리를 맞대고 앉아 우리가 어떻게 그들의 창의성을 강화시켰는지 알아보고, 함께 새로운 꿈을 추구하는 것을 좋아합니다. 올해 초에 AWS Step Functions 및 기타 AWS 서비스를 사용하여 Coke.com Vending Pass 프로그램을 지원한 방법을 알아보기 위해 Coca-Cola Company의 Patrick과 대화를 나눈 적이 있습니다.

이 프로그램에는 Coca-Cola Vending Pass를 사용하여 모바일 결제를 지원할 수 있는 기능을 갖춘 자동 판매기에서 제품을 구매하여 얻은 음료 보상이 포함됩니다. 참가자는 자신의 NFC 지원 휴대폰을 갖다 대서 Apple Pay 또는 Android Pay 구매를 완료함으로써 자동 판매기에서 자신을 식별하고 향후 무료 자동 판매기 구매를 위한 크레딧을 획득할 수 있습니다.

AWS SNS 토픽과 AWS Lambda 기능의 조합을 통해 기존 백엔드 코드 중 일부에 대한 한 쌍의 호출을 시작하여 자동 판매기 포인트를 계산하고 참가자의 레코드를 업데이트했습니다. 그러나 백엔드 코드는 반응이 느리고 시간 종속성이 있어 Vending Pass 참가자에게 혼동을 줄 가능성이 있는 업데이트 누락이 발생할 수 있었습니다. 이 문제에 대한 초기 해결책은 매우 간단했습니다. 즉, 두 호출 사이에 90초 지연을 포함하도록 Lambda 코드를 수정하는 것이었습니다. 이것으로 문제는 해결되었지만 아무 이유도 없이 프로세스 시간을 소비했습니다(Lambda 함수 사용에 대한 요금 청구는 100ms 간격으로 요청 기간을 기반으로 함).

솔루션을 보다 비용 효율적으로 만들기 위해 팀은 AWS Step Functions를 사용하여 매우 간단한 상태 시스템을 구축했습니다. 이전 블로그 게시물에 썼듯이 Step Functions는 구축하기 쉬운 시각적 워크플로를 사용하여 분산 애플리케이션 및 마이크로서비스의 구성 요소를 규모에 따라 조정합니다.

Coke는 매우 간단한 상태 시스템을 구축하여 비즈니스 로직을 간소화하고 비용을 절감했습니다. 사용자는 동등하게 간단하거나 순차 및 병렬 실행 등의 기타 Step Function 기능과 의사를 결정하고 대체 상태를 선택할 수 있는 기능을 사용할 수 있습니다. Coke 상태 시스템은 다음과 같습니다.

FirstStateSecondState 상태(작업 상태)는 Step Functions가 90초 지연(대기 상태)을 구현하는 동안 적절한 Lambda 함수를 호출합니다. 이 수정 사항을 통해 로직을 간소화하고 비용을 절감했습니다. 함께 정상적으로 작동되는 방식은 다음과 같습니다.

다음 단계
이 초기 성공으로 인해 서버리스 컴퓨팅에 대해 자세히 알아보고 다른 프로젝트에 이 서버리스 컴퓨팅의 사용을 고려하게 되었습니다. Patrick은 생산성의 향상과 개발자의 행복을 이미 실현했다고 말했습니다. 개발자는 더 이상 서버를 프로비저닝할 때까지 기다릴 필요가 없으며 이제 (Jeff의 말처럼) 자신의 창의성을 발휘하고 자신의 꿈을 추구할 수 있습니다. 그들은 Step Functions를 사용하여 애플리케이션의 확장성, 기능성 및 안정성을 향상시킴으로써 Coca-Cola Vending Pass의 초기 사용을 훨씬 능가할 것으로 예상합니다. 예를 들어 Coke는 Lambda, Step Functions, API Gateway를 사용하여 영양 정보를 식품 서비스 파트너에게 게시할 수 있는 서버리스 솔루션을 구축했습니다.

Patrick과 그의 팀은 이제 기계 학습 및 인공 지능을 실험하고 있습니다. 그들은 프로토타입 애플리케이션을 구축하여 Instagram의 사진 스트림을 분석하고 맛과 향미의 추세를 추출했습니다. 애플리케이션(빠른 1일 프로토타입으로 구축)은 Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon Rekognition을 사용했으며 Patrick의 말에 따르면 “큰 승리이자 조력자”였습니다.

서버리스 애플리케이션을 보다 신속하게 구축하기 위해 개발 팀은 서버리스 애플리케이션 프레임워크를 기반으로 하는 내부 CI/CD 참조 아키텍처를 생성했습니다. 이 아키텍처에는 내부 서비스 및 자산에 액세스할 수 있는 몇 가지 보일러플레이트 코드와 서버리스의 가이드 투어가 포함되어 있습니다. Patrick은 이 모델을 통해 유망한 프로젝트를 “컴퓨터를 가진 사람”에서 전체 개발 팀으로 쉽게 확장할 수 있다고 말했습니다.

AWS re:Invent에서 제 동료인 Tim Bray 다음으로 Patrick이 무대에 오를 예정입니다. 직접 만나기 위해서는 SRV306 – 현장에서의 상태 시스템! 고객이 AWS Step Functions를 사용하는 방법에 참석하시기 바랍니다.

참고) 2016년 AWS re:Invent에서 Cocacola가 직접 발표한 세션 동영상도 참고하시기 바랍니다.

Jeff

이 글은 Things Go Better With Step Functions의 한국어 번역입니다.

ASP.NET Core를 위한 AWS CodeStar 사용 방법

AWS CodeStar 팀이 최근 ASP.NET Core 프로젝트 템플릿 2개를 추가로 발표했습니다.  AWS CodeStar는 개발자를 대신해 CI/CD(코드 통합 및 코드 배포) 파이프라인을 생성하므로 개발자는 인프라를 구축하는 대신 애플리케이션 빌드에 집중할 수 있습니다. 새로운 ASP.NET Core 프로젝트 템플릿을 사용하여 .NET 개발자는 처음부터 AWS 애플리케이션을 빌드하고 배포할 수 있습니다. AWS CodeStar에서 ASP.NET Core 애플리케이션을 생성하는 방법이 Tara Walker의 우수 블로그 게시물에 나와 있습니다. 이 블로그 게시물에서는 AWS CodeStar용 ASP.NET Core 프로젝트에 테스트를 추가하는 방법을 배우고 그 이면에서 이루어지는 일을 자세히 살펴볼 수 있습니다.

단위 테스트 프로젝트 추가

HelloController 기능을 연습하는 간단한 테스트 사례를 추가하는 것이 목적입니다. 새로운 ASP.Net Core 웹 서비스 프로젝트가 있다고 가정해 보겠습니다. 이 프로젝트가 없으면 Tara 블로그 게시물(위 내용 참조)에 따라 만드십시오. ASP.NET Core 웹 서비스 템플릿을 선택해야 합니다. AWS CodeStar용 ASP.NET Core를 만들고 Team Explorer를 통해 프로젝트 리포지토리를 복제한 후 AspNetCoreWebService 솔루션을 로드한 다음 블로그 게시물의 나머지 부분에 따르면 됩니다. Team Explorer를 통해 repo를 설정하기 위한 지침이 필요하면 Steve Robert의 Visual Studio 및 AWS CodeCommit 통합 5월자 발표를 참조하십시오.

먼저 AspNetCoreWebServiceTest라는 새 xUnit 프로젝트를 AspNetCoreWebService 솔루션에 추가하십시오. 새로운 테스트 프로젝트는 HelloController 클래스와 JsonResult를 참조하므로 AspNetCoreWebService를 프로젝트 참조로 추가하고 Microsoft.AspNetCore.Mvc를 NuGet 참조로 추가해야 합니다. 이 참조를 테스트 프로젝트에 추가한 후에  AspNetCoreWebServiceTest.csproj에 다음 내용이 추가되어야 합니다.

Xml
<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
    ...
</ItemGroup>
...
<ItemGroup>
    <ProjectReference Include="..\AspNetCoreWebService\AspNetCoreWebService.csproj" />
</ItemGroup>

그러면 HelloController 클래스의 직접 참조를 만들고 JsonResult의 압축을 풀 수 있습니다. 다음과 같이 간단한 테스트 사례를 추가해 보겠습니다.

C#
using System;
using Xunit;
using Microsoft.AspNetCore.Mvc;
using AspNetCoreWebService.Controllers;

namespace AspNetCoreWebServiceTest
{
    public class HelloControllerTest
    {
        [Fact]
        public void SimpleTest()
        {
            HelloController controller = new HelloController();
            var response = controller.Get("AWS").Value as Response;
            Assert.Equal(response.output, "Hello AWS!");
        }
    }
}

파일 이름, 네임스페이스, 클래스 이름 및 메서드 이름이 바뀌었습니다. 테스트를 실행하고 통과하는지 확인하십시오. [Solution Explorer]에 다음과 같이 표시되어야 합니다.

이제 테스트 프로젝트가 작동하므로 애플리케이션을 배포하기 전에 파이프라인을 업데이트하여 테스트를 빌드하고 실행해야 합니다.

AWS CodeBuild 작업 업데이트

먼저 프로젝트가 어떻게 빌드되는지 살펴보겠습니다. 개발자나 팀 구성원이 repo에 변경 사항을 푸시하면 파이프라인이 최신 변경 사항에 따라 자동으로 빌드 프로세스를 시작합니다. 이 단계에서 AWS CodeBuild가 리포지토리 루트에 있는 buildspec.yml 파일을 사용하여 빌드 프로세스를 진행합니다.

YAML
version: 0.2
phases:
  pre_build:
    commands:
      - echo Restore started on `date`
      - dotnet restore AspNetCoreWebService/AspNetCoreWebService.csproj
  build:
    commands:
      - echo Build started on `date`
      - dotnet publish -c release -o ./build_output AspNetCoreWebService/AspNetCoreWebService.csproj
artifacts:
  files:
    - AspNetCoreWebService/build_output/**/*
    - scripts/**/*
    - appspec.yml

AWS CodeBuild용 .NET Core 이미지가 AWS CodeBuild 작업에 사용됩니다. buildspec.yml에서 호출할 .NET Core SDK 및 CLI가 이 이미지에 포함되어 있습니다.  이 프로젝트는 웹 서비스 1개로 구성되므로 buildspec.yml 파일 하나면 충분합니다. 프로젝트가 커지고 빌드 프로세스가 복잡해지면 셸 스크립트나 MSBuild .proj 파일을 통해 외부적으로 빌드 프로세스를 진행하고 buildspec.yml에서 간단하게 스크립트/빌드 파일을 호출할 수 있습니다.

dotnet publish 명령에 주목해 주십시오. 이 게시 단계에서는 호스트 머신에서 즉시 사용할 수 있도록 모든 종속성을 함께 패키지하므로 매우 중요합니다. 위에 나온 buildspec.yml 파일의 artifacts 섹션에서 정의한 대로 파일 목록이 Amazon S3 버킷에 저장되어 AWS CodeDeploy가 호스트에 애플리케이션을 배포하는 데 사용할 수 있습니다.  scripts/**/*에는 appsec.yml이 종속된 모든 스크립트가 포함됩니다. appsec.yml에 익숙하지 않거나 이 파일에 대해 자세히 알아보려면 다음 단원에서 다시 다루겠습니다.

이전 단원에서는 AWS CodeCommit 리포지토리에 테스트 프로젝트를 추가했습니다. 이제 buildspec.yml을 업데이트하여 새 테스트 프로젝트를 빌드하겠습니다. 빌드 단계의 일부로 dotnet vstest를 실행할 수 있습니다. 하지만 이 연습에서는 별도의 빌드 및 테스트 단계를 만들어 모범 사례를 따르겠습니다. buildspec.yml을 수정하여 테스트 바이너리를 빌드하고 비트를 AspNetCoreWebServiceTest/test_output 디렉터리에 게시합니다.

YAML
pre_build:
    commands:
        ...
        - dotnet restore AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj
post_build:
    commands:
        ...
        - dotnet publish -c release -o ./test_output AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj  
artifacts:
    files:
        ...
        - AspNetCoreWebServiceTest/test_output/**/*

AspNetCoreWebServiceTest/test_output/**/*을 아티팩트로 추가했습니다. 그래서 실제로 AWS CodeBuild 서비스가 게시된 테스트 바이너리를 Amazon S3에 업로드하므로 다음에 만들 테스트에서 이 테스트 바이너리를 참조할 수 있습니다.

AWS CodePipeline 업데이트

이전 단원에서는 새로운 테스트 프로젝트를 추가하고 buildspec.yml을 수정하여 테스트 실행에 필요한 바이너리를 빌드하고 저장했습니다. 이제 파이프라인에 테스트 단계를 추가하는 방법을 계속 설명하겠습니다. 먼저 콘솔에서 Test 단계와 UnitTest 작업을 파이프라인에 추가합니다.

나머지 UI를 따르고 다음 파라미터를 입력하십시오.

  • [Action category]: Test
  • [Action name]: UnitTest
  • [Test provider]: AWS CodeBuild
  • [Create a new build project] 선택
  • [Project name]: <your project name>-test
  • [Operating system]: Ubuntu
  • [Runtime]: .NET Core
  • [Version]: aws/codebuild/dot-net:core-1
  • [Build specification]에 대해nbsp;[Insert build Commands] 선택
  • [Build command]: dotnet vstest AspNetCoreWebServiceTest/test_output/AspNetCoreWebServiceTest.dll
  • [Role name]에 대해 목록에서 [CodeStarWorker-<your project name>-CodeBuild] 선택
  • [Input artifacts #1]에 대해 목록에서 [<your project name>-BuildArtifact] 선택

여기서 중요한 정보는 제공된 빌드 명령입니다. 이전 단계에서 빌드한 test .dll에 따라 테스트 작업이 dotnet vstest를 실행합니다. 이제 파이프라인이 다음과 같아야 합니다.

거의 끝났습니다. [Release change]를 눌러 이 파이프라인을 실행하면 [Error Code: AccessDeniedException] 메시지와 함께 Test 단계에서 파이프라인이 실패합니다. AWS CodeStar 서비스에는 새 Test 단계를 실행할 권한이 없기 때문입니다. AWS CodeStar 프로젝트에 적절한 액세스 권한을 부여하는 방법을 알아보겠습니다.

IAM 역할 및 정책 업데이트

AWS CodeStar 프로젝트는 여러 서비스와 작업자가 애플리케이션을 동기화, 빌드 및 배포할 수 있는 최소한의 권한에 대한 정책을 만들었습니다. 새로운 AWS CodeBuild 작업을 추가했기 때문에 [CodeStarWorkerCodePipelinePolicy]에서 새 리소스에 대한 액세스 권한을 부여해야 합니다. IAM 콘솔로 이동하여 변경해 보겠습니다. [Roles] 탭에서 “codebuild” 키워드를 사용하여 검색하십시오 역할은 CodeStarWorker-<project name>-CodePipeline 형식이어야 합니다. 그런 다음 역할에 연결된 정책을 편집하십시오. 편집 과정은 아래와 같습니다.

변경할 내용은 정책에서 AWS CodeBuild 작업과 연결된 새 codebuild 리소스 arn:aws:codebuild:us-east-1:532345249509:project/<your project name>-test를 추가하는 것입니다.

Js
{
    "Action": [
        "codebuild:StartBuild",
        "codebuild:BatchGetBuilds",
        "codebuild:StopBuild"
    ],
    "Resource": [
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>"
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>-test"
    ],
    "Effect": "Allow"
}

완료되었습니다. 이제 AWS CodeStar 프로젝트에 새 작업을 빌드하는 데 적절한 권한이 생겼습니다. [Release change]를 눌러 시도해 보십시오.

ASP.NET Core 애플리케이션 배포

이제까지 AWS CodeStar를 사용하여 프로젝트를 빌드하고 테스트하는 방법을 알아보았습니다. 이 단원에서는 배포 프로세스를 자세히 살펴보겠습니다. AWS CodeStar 프로젝트를 생성하는 동안 AWS CodeStar 서비스가 애플리케이션을 호스팅하기 위해 Amazon EC2 인스턴스를 만듭니다. appspec.yml의 지침에 따라 해당 인스턴스에서 배포 프로세스를 실행하는 code-deploy-agent도 설치합니다. appspec.yml을 살펴보겠습니다.

YAML
version: 0.0
os: linux
files:
  - source: AspNetCoreWebService/build_output
    destination: /home/ubuntu/aspnetcoreservice
  - source: scripts/virtualhost.conf
    destination: /home/ubuntu/aspnetcoreservice 
hooks:
  ApplicationStop:
    - location: scripts/stop_service
      timeout: 300
      runas: root

  BeforeInstall:
    - location: scripts/remove_application
      timeout: 300
      runas: root

  AfterInstall:
    - location: scripts/install_dotnetcore
      timeout: 500
      runas: root

    - location: scripts/install_httpd
      timeout: 300
      runas: root

  ApplicationStart:
    - location: scripts/start_service
      timeout: 300
      runas: root

배포 프로세스의 여러 단계에서 각 스트립트가 실행됩니다.

  • install_dotnetcore – 아직 설치되지 않은 경우 dotnet core를 설치하고 처음 실행할 때 패키지 캐시를 업데이트합니다. Microsoft에서는 이 방식으로 Ubuntu에서 .NET Core를 설치하도록 권장합니다.
  • install_httpd – HTTPD 대몬과 mod를 설치하고 HTTPD 구성 파일을 덮어써 reverse-proxy를 활성화합니다.
  • start_service – HTTPD 서비스를 다시 시작하고 기존의 ASP.NET 애플리케이션/서비스 프로세스를 다시 시작합니다.
  • scripts/stop_service – HTTPD 서비스를 중지하고, 아직 실행 중인 경우 ASP.NET 애플리케이션/서비스를 중지합니다.
  • remove_application – 배포된 애플리케이션을 인스턴스에서 제거합니다.

애플리케이션 배포 중에 인스턴스의 code-deploy-agent가 이 후크를 실행하여 서비스를 설치하고 시작합니다. AWS CodeDeploy 콘솔에서 이벤트 활동을 모니터링할 수 있으며 EC2 인스턴스에서 자세한 로그를 볼 수 있습니다. 인스턴스와의 SSH 연결을 열고 /var/log/aws/codedeploy-agent로 이동하여 배포 로그를 찾으십시오.

결론

이 블로그 게시물에서는 애플리케이션 파이프라인에 테스트 단계를 추가하는 예제를 통해 AWS CodeStar용 ASP.NET Core 프로젝트가 빌드 및 배포되는 방법을 알아보았습니다. 다양한 구성 요소와 AWS 서비스가 상호 작용하여 AWS CodeStar의 전체 CI/CD 시스템을 제공하는 방법을 이해하는 데 이 게시물이 도움이 되었기를 바랍니다.

이 글은 AWS 개발자 블로그의 Steven Kang이 작성한 ASP.NET Core and AWS CodeStar Deep Dive의 한국어 번역입니다.

Microsoft Visual Studio Team Services용 AWS 개발 도구 출시

오늘 Amazon Web Services는 Microsoft Visual Studio Team Services(VSTS)용 AWS 도구를 발표했습니다. Visual Studio 마켓플레이스에서 도구를 자유롭게 사용하고 배포할 수 있습니다. 빌드에서 이 작업을 사용하고 VSTS 및 Team Foundation Server에서 호스팅되는 파이프라인을 릴리스하여 AWS 제품과 상호 작용할 수 있습니다. 예를 들어, 작업을 사용하여 Amazon S3 버킷으로/버킷에서 콘텐츠를 복사하거나 파이프라인에 작업을 추가하여 빌드 출력을 AWS Elastic Beanstalk, AWS CodeDeployAWS Lambda에 배포할 수 있습니다. 또한 도구는 오픈 소스이며 GitHub에서 찾을 수 있습니다.

이 게시물에서는 도구를 설치하는 방법을 살펴보고 도구에 포함된 작업의 개요를 제공한 후 간단한 시나리오를 안내하여 설정을 확인하고 도구의 간편한 사용 방법을 보여줍니다. 이후의 게시물에서는 작업을 면밀하게 살펴보고 VSTS 파이프라인에서 작업을 사용하는 방법을 알아보겠습니다.

설치하기
쉽고 빠르게 Microsoft Visual Studio Team Services용 AWS 도구를 설치할 수 있습니다. 먼저 Visual Studio 마켓플레이스를 방문하십시오. 아래와 같이 도구 설치를 위한 두 가지 옵션이 있습니다. 온라인 VSTS 계정에 도구를 설치하거나 도구를 다운로드하여 온프레미스 Team Foundation Server 인스턴스에 설치할 수 있습니다.

그러면 끝입니다. 이제 계정이나 온프레미스 인스턴스에서 확장의 작업을 사용할 수 있으므로 이 초기 릴리스에 제공된 작업을 빠르게 검토해 보겠습니다. 앞에서 말했듯이 후속 게시물에서는 이 작업 중 몇 가지에 대해 자세히 살펴보겠습니다.

  • AWS CloudFormation Create/Update Stack. 이 작업을 통해 템플릿 파일과 선택적 파라미터 파일을 사용하여 AWS CloudFormation에서 스택을 생성하거나 업데이트할 수 있습니다. 스택이 이미 있는지 여부에 따라 기존 스택 업데이트와 새 스택 생성 간에 자동으로 작업이 전환됩니다. “모드”를 선택할 필요가 없어 파이프라인에서 이 작업을 편리하게 사용할 수 있습니다. 템플릿과 파라미터 파일을 선택할 뿐 아니라 변경 세트를 자동으로 실행하기 위해 추가한 옵션과 함께(변경 세트 확인에 성공할 경우) 변경 세트를 사용하여 스택을 만들거나 업데이트하도록 선택할 수 있습니다. 또는 Execute Change Set 작업을 사용하여 확인된 변경 세트를 나중에 실행할 수 있습니다.
  • AWS CloudFormation Delete Stack. 이 작업은 이름이나 ID로 식별된 스택을 삭제합니다. 이 작업을 사용하여 제거 및 다시 빌드 시나리오에서 새로운 배포 후에 개발 또는 테스트 환경 스택을 정리할 수 있습니다.
  • AWS CloudFormation Execute Change Set. 앞에서 말했듯이 Create/Update Stack 작업에서는 변경 세트를 사용하여 변경하는 옵션과 세트가 확인될 경우 즉시 또는 나중에 이 스택을 사용하여 변경을 실행하는 옵션이 제공됩니다. 변경 세트 이름과 연결된 스택을 제공하면 스택이 생성 또는 업데이트 완료 상태에 도달할 때까지 대기했다가 작업이 나머지 과정을 진행합니다.
  • AWS Elastic Beanstalk Deployment. 이 작업을 통해 WebDeploy 아카이브를 사용하여 기존의 ASP.NET 애플리케이션을 배포하거나 ASP.NET Core 애플리케이션을 배포할 수 있습니다.
  • AWS Lambda .NET Core Deployment. 이 작업을 통해 독립 실행형 함수 또는 서버리스 애플리케이션을 AWS Lambda에 배포할 수 있습니다. AWS Visual Studio Toolkit과 동일한 dotnet CLI 확장이 작업에 사용되므로 명령둘 도구 스위치의 전체 사용자 정의 기능을 작업에 사용할 수 있습니다.
  • AWS Lambda Invoke Function. AWS Lambda에 배포하는 것 외에도 이 작업을 사용하여 파이프라인에서 실행되도록 Lambda 함수를 트리거합니다 파이프라인의 후속 작업이 소비할 변수로 함수 결과를 내보낼 수 있습니다.
  • AWS S3 Download. 버킷 이름과 선택적 키 접두사를 함께 사용하면 하나 이상의 globbing 패턴 세트가 이 작업에 사용되어 Amazon S3 버킷에서 파이프라인의 작업 폴더로 콘텐츠를 다운로드할 수 있습니다. 예를 들어, 이 작업을 사용하여 사용자 정의 정적 콘텐츠를 빌드에 주입할 수 있습니다.
  • AWS S3 Upload. S3 다운로드 작업과 유사하게 이 작업도 버킷 이름과 globbing 패턴 세트를 소스 폴더에서 실행하여 파이프라인 작업 폴더에서 버킷으로 콘텐츠를 업로드합니다.
  • AWS Tools for Windows PowerShell Script. 이 작업을 통해 Windows PowerShell용 AWS 도구(AWSPowerShell) 모듈의 cmdlets를 사용하는 스크립트를 실행할 수 있습니다. 스크립트가 실행되기 전에 선택적으로 모듈을 설치할 수 있습니다.
  • AWS CLI. 이 작업을 통해 개별 AWS CLI 명령을 실행할 수 있습니다. 하지만 AWS CLI가 빌드 호스트에 이미 설치되어 있어야 합니다.

작업 구성 및 사용
릴리스에 포함된 작업에 대해 약간 알아보았으니 이제 파이프라인에서 AWS S3 Upload 작업을 사용하는 방법을 살펴보겠습니다. 여기서 도구의 설정을 확인하고 작업에 맞게 자격 증명이 처리되는 방식을 알아볼 수도 있습니다.

이 연습에서는 빌드 및/또는 배포할 아티팩트를 가져오는 기존의 빌드 또는 릴리스 정의가 있다고 가정합니다. 파이프라인 끝에 새 작업을 추가하고 빌드되거나 배포 가능한 아티팩트를 S3 버킷에 업로드하도록 구성하는 간단한 과정이 진행됩니다. 이제 사용할 빌드 정의를 선택하거나 새로 만드십시오. 정의를 선택하거나 만들었으면 옵션을 선택하여 정의를 편집합니다.

다음 스크린샷 예에서는 ASP.NET Core 프로젝트의 빌드 정의를 새로 만들기로 선택했습니다. 나열된 작업이 기본적으로 할당됩니다.

1. 파이프라인에 S3 업로드 작업 추가

이 연습에서는 Publish 작업에서 생성된 빌드 출력을 캡처하고 Amazon S3에 추가합니다. 따라서 기존 Publish 작업과 Publish Artifacts 작업 사이에 새 작업을 삽입합니다. 그러려면 [Add Task]를 선택하십시오. 오른쪽 패널에서 AWS 작업, 특히 [AWS S3 Upload]가 보일 때까지 사용 가능한 작업을 스크롤합니다. [Add]를 선택하여 빌드 정의에 추가하십시오.

[Publish] 작업 바로 뒤에 새 작업이 추가되지 않으면 새 작업을 제 자리로 끌어다 놓습니다. 그러면 새 작업 구성을 시작할 수 있습니다.

2. 작업 자격 증명 구성

Amazon S3와 같은 AWS 제품의 요청을 만드는 작업에는 자격 증명을 구성해야 합니다. Team Systems 용어로 서비스 엔드포인트라고 합니다. AWS 작업은 AWS라는 서비스 엔드포인트를 제공하여 자격 증명을 제공할 수 있도록 합니다. 이 작업의 자격 증명을 신속하게 추가하려면 [AWS Credentials] 상자 오른쪽에 있는 “+” 아이콘을 클릭하십시오.

기어 아이콘을 클릭하면 새 브라우저 페이지가 탭에 열리고 여기서 새 AWS 유형을 비롯하여 모든 서비스 엔드포인트를 관리할 수 있습니다. 작업에 사용할 여러 AWS 자격 증명 세트를 설정하려는 경우 이 과정을 수행합니다.

+” 아이콘을 클릭하면 AWS 키를 입력할 수 있는 팝업 창이 나타납니다.

AWS SDK 또는 AWS CLI나 PowerShell용 AWS 모듈과 같은 도구를 자주 사용한 경우 이 옵션이 익숙하게 보일 것입니다. 이 SDK 및 도구에서와 같이 AWS 자격 증명 프로파일을 기본적으로 생성합니다. 프로파일에는 이름이 있으며 여기서는 [Connection name]에 입력한 값이 작업 구성에서 이 자격 증명 세트를 나타내는 이름이 됩니다. 이제 사용할 자격 증명의 액세스 키와 보안 키를 입력하고 기억할 이름을 할당한 후 [OK]를 클릭하여 저장하십시오. 팝업이 닫히고 새 자격 증명이 미리 선택된 [S3 Upload] 작업 구성으로 돌아갑니다.

입력한 자격 증명을 다른 작업에서 다시 사용할 수 있습니다. 구성 중인 작업의 [AWS Credentials] 목록에서 자격 증명을 식별하는 데 사용한 이름을 선택하면 됩니다.

참고
계정의 루트 자격 증명은 사용하지 않는 것이 좋습니다. 대신 하나 이상의 IAM 사용자를 생성한 후 해당 자격 증명을 사용하십시오. 자세한 내용은 AWS 액세스 키 관리를 위한 모범 사례를 참조하십시오.

3. 작업 옵션 구성

자격 증명이 구성 및 선택되어 있으면 작업 구성을 완료할 수 있습니다.

  • 버킷이 있거나 생성될 리전을 설정합니다(예: us-east-1, us-west-2 등).
  • 버킷 이름을 입력합니다. 버킷 이름은 전역적으로 고유해야 합니다.
  • [Source Folder]는 업로드할 콘텐츠가 있는 빌드 영역의 폴더를 가리킵니다. Team Services에서는 하드 코딩 경로를 방지하는 데 사용할 수 있는 여러 가지 변수를 제공합니다. 자세한 내용은 여기를 참조하십시오. 이 연습에서는 Build.ArtifactStagingDirectory 변수를 사용하기로 선택합니다. 이 변수는 …아티팩트가 대상에 게시되기 전에 복사되는 에이전트의 로컬 경로로 정의됩니다. 완벽합니다.
  • [Filename Patterns]에는 업로드용 [Source Folder] 아래에서 파일을 선택하는 데 사용되는 globbing 패턴이 하나 이상 포함됩니다. 여기에 표시된 기본값은 모든 파일을 재귀적으로 선택합니다. 한 줄에 하나씩 여러 패턴을 지정할 수 있습니다. 이 연습의 경우 이전 작업(Publish)에서 빌드가 포함된 zip 파일을 내보냅니다. 이 zip이 업로드할 파일입니다.
  • [Target Folder]는 업로드한 모든 파일에 적용할 버킷의 키 접두사입니다. 폴더 경로와 비슷하게 생각할 수 있습니다. 값을 지정하지 않으면 파일이 버킷의 루트로 업로드됩니다. 기본적으로 상대적 폴더 계층 구조가 유지됩니다.
  • 마지막으로 추가 옵션을 설정할 수 있습니다.
    • Create S3 bucket if it does not exist. 버킷을 생성할 수 없으면 작업이 실패합니다.
    • Overwrite([Advanced] 섹션). 기본적으로 선택됩니다.
    • Flatten folders([Advanced] 섹션). [Source Folder]에 상대적인 각 파일의 경로를 제거하고 모든 파일을 [Target Folder]에 직접 배치합니다.

4. 빌드 실행

새 작업이 구성되었으므로 빌드를 실행할 수 있습니다. [Save & queue]를 선택하십시오.

빌드 도중에 작업이 로그에 메시지를 출력합니다.


맺는말
살펴본 바와 같이 새 작업을 사용하는 일은 단순합니다. 향후 게시물에서는 몇 가지 배포 작업과 그 사용 방법을 자세히 설명하겠습니다. 새로운 도구의 등장이 여러분에게 기쁨이 되고 VSTS 환경에서 유익하게 사용되기 바랍니다. GitHub repo에서 피드백을 주시면 이후의 개발 활동에 참고하겠습니다.

감사의 말씀
이 새로운 도구를 Visual Studio 마켓플레이스에 소개하도록 도움과 지원을 아끼지 않은 Visual Studio ALM Rangers에 감사드립니다.

이 글은 Announcing the AWS Tools for Microsoft Visual Studio Team Services의 한국어 번역입니다.

AWS 10월 온라인 세미나 – re:Invent 가이드, Amazon ECS/ECR 기반 마이크로서비스, AWS X-Ray 성능 추적 및 Apache MXNet 기반 딥러닝 등

AWS 클라우드를 아껴주시는 한국 고객 분들을 위해 지속적으로 AWS 월간 온라인 세미나 시리즈를 진행하고 있습니다. 이번 10월 온라인 세미나 에서는  AWS re:Invnet 참여 가이드, Amazon ECS/ECR 기반 마이크로 서비스, AWS X-Ray 성능 추적 및 Apache MXNet 기반 딥러닝  등 다양한  온라인 세미나를 준비하였습니다.

온라인 세미나 일정

비지니스 일반 | AWS re:Invent 참가자를 위한 참여 가이드
연사:  윤석찬 AWS 테크니컬 에반젤리스트
일시: 2017년 10월 17일 (화) 오전 10:00 – 11:00

강연 요약: AWS re:Invent는 4만여명이 참여하는 세계 최대 클라우드 기술 콘퍼런스로 1천여개의 세션과 500개 이상의 부스가 참여하는 행사가 될 예정입니다. 이에 따라 한국에서 참여하는 고객 및 파트너사를 위해 참고하실 부분을 알려드리는 온라인 세미나를 개최합니다. 본 세션에서는 행사 장소, 프로그램, 기술 세션 선 좌석 예약 방법, 한국 참가자를 위한 별도 프로그램, 투어 지원 등을 소개해 드리고, 궁금한 점에 대한 질문과 답변으로 이루어집니다.

발표 자료 및 영상 보기

기술 기초 | Amazon ECS/ECR 활용하여 도커 컨테이너 기반 마이크로서비스 구성하기
연사: 김기완 AWS 솔루션즈 아키텍트
일시: 2017년 11월 1일 (수) 오전 10:00 – 11:30

강연 요약: 컨테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 컨테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 컨테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.

발표 자료 및 영상 보기

기술 기초 | AWS X-Ray를 통한 서버리스 분산 애플리케이션 추적하기
연사:  윤석찬 AWS 테크니컬 에반젤리스트
일시: 2017년 11월 1일 (수) 오후 01:00 – 02:30

강연 요약: AWS Lambda를 통해 서버리스 애플리케이션을 실행하는 경우, 애플리케이션 성능 문제를 효과적으로 진단하는 방법이 필요합니다. 본 세션에서는 분산 애플리케이션 성능 문제 발생 위치를 파악하고 디버깅 할 수 있는 추적 서비스인 AWS X-Ray를 소개합니다. X-Ray를 사용한 동적 스택 추적 및 디버깅, 호출에 대한 시각적 그래프를 사용하여 서버리스 애플리케이션을진단하는 방법을 설명합니다.

발표 자료 및 영상 보기

기술 심화 | Apache MXNet으로 배워보는 딥러닝(Deep Learning)
연사: 김무현 AWS  솔루션즈 아키텍트
일시: 2017년11월 1일(수) 오후 3:00 – 4:30
강연 요약: 다양한 분야에서 좋은 성능을 보여주는 머신러닝의 한 종류인 딥 러닝에 대한 기본적인 개념과 이미지 분석에 많이 적용되는 Convolutional Neural Network 을 배워봅니다. 이를 구현하기 위한 딥러닝 프레임워크인 Apache MXNet에 대한 소개와 기본 사용법을 익혀보고, Fashion MNIST 데이터를 분류하는 CNN 모델을 구현하는 방법을 설명합니다.
발표 자료 및 영상 보기

10월 AWS 온라인 세미나를 통해 AWS 클라우드 기반 다양한 IT 워크로드를 구축하는 방법에 대해 알아보시기 바랍니다. 또한 AWS Online Tech Talk 역시 매월 진행하고 있습니다. 영어로 진행되지만 많은 도움 받으시기 바랍니다.

– AWS 코리아 마케팅팀;

Amazon EC2 Container Registry(ECR), 서울 리전 출시

지난 주 Amazon ECS 서비스 서울 리전 출시 이후, 오늘 Amazon EC2 Container Registry(ECR) 서비스도 서울 리전에 출시 합니다.

Amazon ECR 서비스는 콘테이너 기반 서비스 개발자가 Docker 콘테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있게 해주는 완전관리형 Docker 콘테이너 레지스트리입니다. Amazon ECR은 Amazon EC2 Container Service(ECS)와 통합되어 개발에서 프로덕션까지의 워크플로를 간소화할 수 있을 뿐 아니라 자체 컨테이너 레지스트리를 운영하거나 기본 인프라 확장에 대해 걱정할 필요가 없습니다.

또한, 콘테이너 이미지를 가용성과 확장성이 뛰어난 인프라에 호스팅하여 애플리케이션을 위해 콘테이너를 안정적으로 배포할 수 있습니다. 또한, AWS Identity and Access Management(IAM)와 통합되어 각 리포지토리에 대한 리소스 수준의 제어를 제공합니다.

Amazon ECS/ECR  출시에 맞추어 아래와 같이 온라인 세미나를 준비하였습니다. 관심 있는 분들의 많은 참여를 바랍니다.

기술 기초 | Amazon ECS/ECR 활용하여 마이크로서비스 구성하기
연사: 김기완 AWS 솔루션즈 아키텍트
일시: 2017년 11월 1일 (수) 오전 10:00 – 오전 11:30

콘테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 콘테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 콘테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.

지금 등록하기

Amazon ECR에는 리포지토리에 저장한 콘테이너 이미지 데이터와 인터넷으로 전송한 데이터 양에 대한 요금만 지불합니다. 프리티어 고객은 1년간 500MB 데이터 저장 용량에 대해서 무료입니다. 더 상세한 것은 서울 리전에 대한 ECR 요금표를 참고하시기 바랍니다.

더 자세한 사항은 Amazon ECR 서비스 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);

Amazon EC2 기반 Microsoft SQL Server 2017 구동하기

며칠 전 출시한 Microsoft SQL Server 2017 에는 그래프 데이터베이스 지원, 데이터베이스 자동 튜닝 및 클러스터되지 않은 가용성 그룹 (Always On Availability Groups)을 만드는 기능을 포함한 강력한 신규 기능이 많이 포함되어 있습니다. Linux 및 Docker 컨테이너에서도 실행할 수 있습니다.

EC2 실행 가능
SQL Server 2017의 Windows Server 2016 및 네 가지 에디션 (웹, 익스프레스, 표준 및 엔터프라이즈)을 EC2 인스턴스에서 지금 시작할 수 있습니다. AMI (Amazon Machine Images)는 현재 모든 AWS 리전에서 사용할 수 있습니다 128 vCPU 및 거의 4 TB의 메모리가있는 새로운 x1e.32xlarge를 비롯하여 다양한 EC2 인스턴스 유형에서 실행됩니다.

이제 AWS 관리 콘솔 또는 AWS Marketplace에서 시작할 수 있습니다. 콘솔에서 검색 방법은 다음과 같습니다.

AWS Marketplace에서도 찾을 수 있습니다.

라이선스 옵션
SQL Server에 대한 많은 라이선스 옵션이 있습니다.

  • 종량 지불 (Pay As You Go) – 이 옵션은 라이선스 구매를 피하고 이미 SQL Server의 이전 버전을 실행하고 업그레이드하려는 경우에 적합합니다. 진실한 업, 소프트웨어 준수 감사 또는 Software Assurance를 처리 할 필요가 없으며 장기간 구매할 필요가 없습니다. SQL Server Standard Edition을 사용하고 있다면 52 %의 비용을 절감하면서 최근의 가격 인하 혜택을 누릴 수 있습니다.
  • 라이선스 이동(License Mobility) – 이 옵션을 사용하면 활성 Software Assurance 계약을 통해 기존 라이선스를 EC2로 가져올 수 있으며 Windows 또는 Linux 인스턴스에서 SQL Server를 실행할 수 있습니다.
  • 기존 라이선스 활용(Bring Your Own Licenses) – 이 옵션을 사용하면 기존에 구매한 라이선스를 활용하면서 업그레이드 비용을 최소화 할 수 있습니다. EC2 전용 인스턴스 또는 EC2 전용 호스트에서 SQL Server를 실행할 수 있으므로 코어 단위로 SQL Server를 라이선스함으로써 운영 비용을 절감 할 수 있습니다. 이 옵션을 사용하면 EC2 Linux 인스턴스 (SUSE, RHEL 및 Ubuntu 지원)에서 SQL Server 2017을 실행할 수 있으며 EC2 Windows 및 Linux 인스턴스에서 실행되는 Docker 기반 환경도 지원합니다. 이러한 옵션에 대한 자세한 내용은 Linux에서 SQL Server 설치 지침Docker로 SQL Server 2017 컨테이너 이미지 실행을 참조하십시오.

더 자세히 보기
SQL Server 2017에 대한 자세한 내용과 라이선스 옵션에 대한 자세한 내용은 SQL Server on AWS 페이지를 참조하십시오.

마이그레이션 작업을 계획 할 때 조언 및 지침이 필요하면 Microsoft Workload Competency를 가진 데이터베이스 솔루션에 중점을 둔 AWS 파트너의 도움을 받으실 수 있습니다.

Jeff;

이 글은 Now Available – Microsoft SQL Server 2017 for Amazon EC2 의 한국어 번역입니다.

Amazon Linux 2017-09 버전 업데이트 출시

https://media.amazonwebservices.com/blog/2017/announcing_amazon_linux_2017_09_400x218_1.gif최신 Amazon Linux 버전 AMI (2017.09) 업데이트를 발표합니다. 최신 AMI에는 EC2에서 실행되는 응용 프로그램에 안정적이고 안전한 고성능 환경을 제공하도록 설계된 지원 및 유지 관리되는 Linux 이미지가 포함되어 있습니다.

간편한 업그레이드
두 개의 명령을 실행하고 리부팅하여, 기존 인스턴스를 업그레이드 할 수 있습니다.

$ sudo yum clean all
$ sudo yum update

다양한 기능
AMI에는 많은 새로운 기능이 포함되어 있으며이 중 많은 기능이 고객의 요청에 따라 추가되었습니다

  • Kernel 4.9.51 – 4.9 안정 커널 시리즈를 기반으로하는이 커널에는 ENA 1.3.0 드라이버와 함께 TCP Bottleneck Bandwidth 및 RTT (BBR)가 지원됩니다. ENA에 대해 자세히 알아 보려면 블로그를 참고하세요.   BBR을 사용 가능하게 설정하는 방법은 출시 정보를 살펴보세요.
  • Amazon SSM Agent – Amazon SSM Agent가 기본적으로 설치됩니다. 즉, 이제 EC2 실행 명령을 사용하여 추가 설정없이 인스턴스에서 스크립트를 구성하고 실행할 수 있습니다. 자세한 내용은 Systems Manager를 사용한 명령 실행블로그 글을 살펴 보세요.
  • Python 3.6 – Python의 최신 버전이 포함되어 있으며 virtualenvalternatives을 통해 관리 할 수 있습니다. 다음과 같이 Python 3.6을 설치할 수 있습니다.
    $ sudo yum install python36 python36-virtualenv python36-pip
  • Ruby 2.4 – 2.4 버전의 Ruby 최신 버전을 사용할 수 있습니다. 다음과 같이 설치하십시오.
    $ sudo yum install ruby24
  • OpenSSL – AMI는 OpenSSL 1.0.2k로 업데이트되었습니다.
  • HTTP/2 – HTTP/2 프로토콜은 AMI의 httpd24, nginx 및 curl 패키지에서 지원됩니다.
  • 관계형 데이터베이스Postgres 9.6 및  MySQL 5.7 를 사용할 수 있으며 다음과 같이 설치할 수 있습니다.
    $ sudo yum install postgresql96
    $ sudo yum install mysql57
    
  • OpenMPIOpenMPI 패키지가 1.6.4에서 2.1.1로 업그레이드되었습니다. OpenMPI 호환 패키지를 사용할 수 있으며 이전 OpenMPI 응용 프로그램을 빌드하고 실행할 수 있습니다.
  • 추가 사항 –  Squid 3.5, Nginx 1.12, Tomcat 8.5GCC 6.4 패키지 등이 업데이트 되었습니다.

정식 출시
본 AMI를 사용하여 모든 AWS 리전에서 EC2 인스턴스를 시작할 수 있습니다. EBS 및 Instance Store 기반 인스턴스에서 사용할 수 있으며 HVM 및 PV 모드를 지원합니다.

Jeff;

이 글은 Now Available – Amazon Linux AMI 2017.09 의 한국어 번역입니다.

AWS 주간 소식 모음 – 2017년 10월 9일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

aws-korea-weekly

AWS코리아 블로그

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

Amazon EC2 Container Service(ECS) 서울 리전 출시!

드디어 오늘 Amazon EC2 Container Service (Amazon ECS)를 아시아-태평양(서울) 리전에 출시합니다.

Amazon ECS는 Docker 콘테이너를 프로덕션 환경에 배포 및 확장하기위한 관리 서비스로서, Amazon ECS를 사용하면 클러스터 구성에 필요한 서버 용량을 추가하고, 콘테이너 이미지를 업로드 할 수 있습니다. Amazon ECS는  서버 클러스터 전체에 콘테이너를 배포하고 상태를 모니터링하며, 콘테이너 부하 분산 및 크기 조정을 처리하는 동시에 데이터베이스 및 기타 리소스에 대한 각 콘테이너 접근 제어를 안전하게 할 수 있도록합니다.

Amazon ECS는 이미 다양한 한국 고객들이 콘테이너 기반 애플리케이션에서 사용하고 있습니다. 삼성SDS  신우용 상무는 “AWS 클라우드를 선택한 이유는 Amazon EC2 컨테이너 서비스(Container Service)를 이용한 첼로 구축 POC를 진행하여 2시간 이내로 아주 빠르게 첼로를 구축할 수 있었고, 네트워크 응답 속도도 빠르고 안정적이었다. AWS 클라우드 서비스를 이용하여 고객에게 첼로를 빠르고, 안정적으로 서비스 할 수 있게 됐다”라고 설명하였습니다.

또한, 삼성전자 장수백 상무는 삼성 IoT 서비스인 Samsung Connect 구축을 위해 “오토 스케일링(Auto scaling) 적용, 아키텍처 재정비, 지역적이고 분산된 개발, 자동화 되고 독립적인 배포 및, 다양한 서비스에 최적화될 수 있는 인스턴스 타입이 적용돼야 한다. 이에 대한 적절한 해법이 AWS 클라우드를 사용한 마이크로 서비스 아키텍처(Micro services architecture) “라고 소개했습니다. 특히, 삼성전자 송주영 선임은 Samsung Connect를 위한 Amazon ECS 활용 사례를 들어 “Amazon ECS는 AWS 상의 멀티 계정을 지원하여, 다양한 보안 및 접근 제어, 그리고 확장성 및 비용 절감과 기술 지원을 받을 수 있다”라고 밝혔습니다.

좀 더 자세한 정보는 아래에서 주요 기업들의 사례를 보실 수 있습니다.

다양한 동영상을 통해 Amazon ECS에 대한 내용을 살펴 보실 수 있습니다.

지난 AWS DevDay에서 있었던 콘테이너 트랙의 최선 정보도 참고하시기 바랍니다.

Amazon ECS 서울 리전 출시와 함께, 앞으로 콘테이너 기반 서비스를 하는 많은 한국 고객들의 활용 방법도 안내해 드리도록 하겠습니다. 자세한 내용은 Amazon ECS 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);

AWS 주간 소식 모음 – 2017년 10월 2일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. 추석 연휴에도 어김없이 찾아 왔습니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

즐거운 연휴되세요~

AWS코리아 블로그

AWS코리아 발표 자료

AWS코리아 동영상

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;