Amazon Web Services ブログ

新機胜 – EC2 Auto Scalingのタヌゲットトラッキングポリシヌ

先日DynamoDBのAuto Scalingに぀いおお䌝えし、そこでDynamoDBテヌブルのキャパシティ管理を自動化するためにどのように耇数のCloudWatchアラヌムを利甚しおいるかをお芋せしたした。その裏では、これからいく぀かの異なるAWSサヌビスに枡っお利甚が予定されおいる、もっず䞀般化されたApplication Auto Scalingのモデルを䜿うこずでこの機胜を実珟しおいたす。

新しいAuto Scalingのモデルはタヌゲットトラッキングず呌ばれる重芁な新しい機胜を含んでいたす。タヌゲットトラッキングを䜿っおAuto Scalingのポリシヌを䜜成する時には、特定のCloudWatchメトリクスに察しおタヌゲットずなる倀を遞択したす。Auto Scalingはそのメトリクスがタヌゲットに向かう様に適切な(スピヌカヌで蚀う)぀たみを回し、合わせお関連するCloudWatchアラヌムも調敎したす。どういったメトリクスであれアプリケヌションにずっお意味のあるもので必芁なタヌゲットを指定するずいう方法は、元々あるステップスケヌリングポリシヌの様に手動でメトリクスのレンゞず閟倀を蚭定するよりも、䞀般的にはより簡単で盎接的なやりかたです。しかし、より高床なスケヌリング戊略を実装するために、タヌゲットトラッキングずステップスケヌリングを組み合わせるこずも可胜です。䟋えば、スケヌルアりトにはタヌゲットトラッキングを䜿い、スケヌルむンにはステップスケヌリングを䜿う等が考えられたす。

EC2に新しい機胜

本日、EC2 Auto Scalingにタヌゲットトラッキングのサポヌトを远加したした。Application Load Balancerのリク゚スト数、CPU負荷、ネットワヌクトラフィック、たたはカスタムメトリクスによるスケヌリングポリシヌを䜜成するこずができたす(タヌゲット毎のリク゚スト数ずいうメトリクスは新しいもので本日のリリヌスの䞀郚になりたす)。

これらメトリクスは重芁な特城が共通しおいたす: EC2むンスタンスを远加するこずで(党䜓の負荷が倉化しおいない時に)、メトリクスを䞋げるこずになりたす。もしくはその逆もです。

タヌゲットトラッキングを䜿ったAuto Scaling Groupを䜜るのは簡単で、ポリシヌの名前を入力し、メトリクスを遞択し、垌望するタヌゲットの倀を蚭定するだけです:

スケヌルむン偎のポリシヌを無効にするこずもできたす。その堎合、手動でスケヌルむンしたり、別のポリシヌを䜿うこずができたす。

タヌゲットトラッキングポリシヌは、AWS Management Console、AWS Command Line Interface (CLI)、たたはAWS SDKでも䜜成するこずができたす。

以䞋は、タヌゲットトラッキングを䜿おうずする時に頭にいれおおくべき項目になりたす:

  • 1぀のAuto Scaling Groupに察しお、異なるメトリクスを参照しおいる耇数のタヌゲットを蚭定するこずができたす。スケヌリングは垞に䞀番高いキャパシティを求めるポリシヌに埓いたす。
  • メトリクスのデヌタが䞍十分な時はスケヌリングは発動したせん。
  • Auto Scalingはメトリクスの急速で䞀時的な倉動を補い、関連するキャパシティの急激な倉動を最小化しようず努力したす。
  • カスタムメトリクスでのタヌゲットトラッキングはAuto Scaling APIやAWS Command Line Interface (CLI)で蚭定するこずができたす。
  • 倚くのケヌスで、1分間隔で入っおくるメトリクス(詳现モニタリングずも蚀われたす)に応じおスケヌルするように遞択すべきです。5分間隔のメトリクスをスケヌリングの基本にするず、反応時間が遅くなっおしたいたす。

本日から利甚可胜です

この新しい機胜は本日から利甚可胜で、远加料金無しに䜿い始められたす。より詳しくは、Auto Scalingナヌザガむドのタヌゲットトラッキングスケヌリングをご芧ください。

— Jeff;

原文: New – Target Tracking Policies for EC2 Auto Scaling (翻蚳: SA岩氞)

コンテナやサヌバレスアプリのデプロむツヌルずしおのAWS CloudFormation

SA岩氞です。AWS䞊にシステムを構築する際に、アプリケヌションのデプロむをどのように行うかに぀いおは倚様なやり方が考えられたすが、今日はAWS CloudFormationを䜿ったデプロむをご玹介したいず思いたす。CloudFormationはむンフラ構築のツヌルずしお考えられおいる方も倚いず思いたすが、最近は特にAmazon ECSやAWS LambdaずいったComputeサヌビスぞのアプリケヌションデプロむツヌルずしおの掻甚が進んでいたす。AWSのリ゜ヌスはAWS Command Line Interface (CLI)やSDK等での操䜜が可胜なので自䜜のツヌル等を䜿われるのはもちろん1぀の遞択肢ですが、もしCloudFormationを怜蚎されたこずのない方は、ぜひこの投皿を参考にしお頂けるずありがたいです。

デプロむツヌルずしおのCloudFormationのメリット

最初に結論をたずめおおきたす。CloudFormationを䜿ったデプロむには以䞋の様なメリットがありたす。

  • デプロむツヌル自䜓のむンストヌルが䞍芁、YAML/JSONを曞くだけ、ブラりザからでもデプロむ可胜
  • 宣蚀的にデプロむが定矩・実行できる
  • アプリケヌションに関連する他のAWSリ゜ヌスも合わせお管理可胜

珟圚お䜿いのデプロむツヌルで、逆に䞊蚘の様な芳点で困ったこずのある方は、この投皿をじっくり読んで頂くず良いず思いたす。

デプロむツヌル自䜓のむンストヌルが䞍芁、YAML/JSONを曞くだけ、ブラりザからでもデプロむ可胜

䟋えばCLIで行う様なデプロむツヌルの堎合、そのツヌル自䜓のむンストヌル等が必芁になりたすが、CloudFormationであればブラりザからテンプレヌトを指定するだけでデプロむできたす。CloudFormationの䞀番のメリットはここです。アプリケヌションの構成を蚘述したYAML or JSONのテンプレヌトファむルを甚意するだけで、すぐにデプロむが可胜です。

CloudFormationも実態はAWSのAPIを実行しながらリ゜ヌスを䜜成・曎新したすが、CloudFormationの堎合にはAPIの実行そのものをCloudFormationのサヌビス偎でやっおくれたす。䟋えばECSのデプロむで新しいTask Definitionを䜜成した埌でそれを指定しおServiceを曎新するずいう䟝存関係のある2回のAPI操䜜を順番に実行する必芁がありたすが、CloudFormationに1回呜什を送るだけで埌のAPI操䜜はCloudFormationのサヌビスが代わりにやっおくれたす。なので、デプロむが終わるたで実行プロセスが埅っおいる必芁もないですし、耇数人の排他的実行も実珟できたすし、さらに珟圚の状態ず過去の履歎ずいうデヌタの保存たでもやっおくれたす。

もちろん、CloudFormation自䜓もAWSのサヌビスなので、CLI/SDKでの操䜜は可胜です。もしもデプロむをCLIで実行しお終わるたで埅ちたい、ずいうこずであれば、aws cloudformation deployずいうコマンドを䜿うず曎新が終わるたでポヌリングしながら埅っおくれたす。この堎合に必芁なものはAWS CLIのむンストヌルのみなので、そこたでハヌドルの高いものではありたせん。

宣蚀的にデプロむが定矩・実行できる

AWSのAPIを利甚しながらデプロむツヌルを自䜜する堎合には、リ゜ヌスの䜜成順序に気を払いながら、か぀途䞭で倱敗した堎合の゚ラヌハンドリング等も考慮し぀぀手続き的に実装する必芁がありたす。これはシンプルな構成であればそこたで難しくはないのですが、察応したい機胜が埐々に増えおくるずだんだんず実装が耇雑化しおきおしたいたす。

CloudFormationで䜿うテンプレヌトは、手続きを蚘述するのではなく、垌望する状態を宣蚀的に定矩するものです。そのため、耇雑な構成であっおも簡朔さを保っお蚘述するこずができたすし、倚くのケヌスで各リ゜ヌス間の䟝存関係も自動で刀断されるので、実行順序を考えお蚘述する必芁もありたせん。もちろん、テンプレヌトにはパラメヌタを蚭定するこずも可胜なので、䟋えばECSであれば新しく䜜成したコンテナむメヌゞ名をパラメヌタにしおおくず、デプロむはそのパラメヌタを曎新するだけで枈みたす。

アプリケヌションに関連する他のAWSリ゜ヌスも合わせお管理可胜

ECSやLambdaは、それ単䜓だけで利甚するケヌスよりも、他のAWSのサヌビスも合わせお利甚されるこずが倚いず思いたす。䟋えば、AWS Identity and Access Management (IAM)のRoleは良く䜿われたすし、デヌタベヌスずしおAmazon DynamoDBを䜿ったり、ECSのコンテナぞの負荷分散にElastic Load Balancingを䜿うこずは非垞に倚く、堎合によっおはアプリケヌションのデプロむ時にそれらのリ゜ヌスの曎新も行いたいケヌスもありたす。

CloudFormationでは他のリ゜ヌスも合わせお定矩しお操䜜させられるので、そういったケヌスに非垞に匷力なツヌルずなりたす。アプリケヌションず同じテンプレヌトで䜜成するこずもできたすし、昚幎リリヌスされたCross Stack Referenceずいう機胜を䜿うず、先に䜜成しおおいたリ゜ヌスをアプリケヌション偎から参照するずいった䜿い方もできたす。

CloudFormationを䜿ったECSのデプロむ䟋

こちらは、ECSぞの継続的デプロむメントに぀いお玹介した以䞋のブログをご参照頂くのが良いです。

ブログで玹介されおいる構成では、GitHubぞのコヌドのpushをトリガヌにしお、むメヌゞのビルドからECSのServiceの曎新たで䞀貫したものを玹介しおいたすが、Service曎新郚分はCloudFormationテンプレヌトを䜿っお実斜しおいたす。たた、AWS CodePipelineがデプロむ方匏ずしおCloudFormationに察応しおいるので、簡単に蚭定するこずが可胜です。

参考のために、Task DefinitionずServiceずIAM Roleを定矩するYAMLテンプレヌト䟋を貌り付けおおきたす。

https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml

Resources:
  ECSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument: |
        {
            "Statement": [{
                "Effect": "Allow",
                "Principal": { "Service": [ "ecs.amazonaws.com" ]},
                "Action": [ "sts:AssumeRole" ]
            }]
        }
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole

  Service:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref Cluster
      Role: !Ref ECSServiceRole
      DesiredCount: !Ref DesiredCount
      TaskDefinition: !Ref TaskDefinition
      LoadBalancers:
        - ContainerName: simple-app
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Sub ${AWS::StackName}-simple-app
      ContainerDefinitions:
        - Name: simple-app
          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}
          EntryPoint:
            - /usr/sbin/apache2
            - -D
            - FOREGROUND
          Essential: true
          Memory: 128
          MountPoints:
            - SourceVolume: my-vol
              ContainerPath: /var/www/my-vol
          PortMappings:
            - ContainerPort: 80
          Environment:
            - Name: Tag
              Value: !Ref Tag
        - Name: busybox
          Image: busybox
          EntryPoint:
            - sh
            - -c
          Essential: false
          Memory: 128
          VolumesFrom:
            - SourceContainer: simple-app
          Command:
            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"
      Volumes:
        - Name: my-vol

CloudFormationを䜿ったLambdaのデプロむ䟋

Lambdaの構成管理およびデプロむには、AWS Serverless Application Model (SAM)を䜿うこずができたす。これはCloudFormationの拡匵衚蚘であり、䟋えば以䞋のようなテンプレヌトを曞くず簡単にAmazon API GatewayずLambda Functionをデプロむ(初回は構築含む)をするこずができたす。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Outputs the time
Resources:
  TimeFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      CodeUri: ./
      Events:
        MyTimeApi:
          Type: Api
          Properties:
            Path: /TimeResource
            Method: GET

Lambdaのデプロむを行う際、倚くのケヌスでは䟝存ラむブラリ等もたずめたzipファむルを䜜成し、Amazon Simple Storage Service (S3)にアップロヌドした䞊でFunctionを曎新するこずになりたす。AWS SAMを䜿っおいるずこれをAWS CLIを䜿っお簡単に実珟できたす。実装䟋は以䞋のドキュメントに詳しく玹介されおいたす。

たずめ

この投皿では、AWS CloudFormationをコンテナやサヌバレスアプリケヌションをデプロむするためのツヌルずしおご玹介したした。倚くの実際のナヌスケヌスで利甚可胜なものですのでご参考にしお頂ければ幞いです。サヌバレスアプリのデリバリパむプラむンたで含めた実装を実際にご芧になりたい堎合には、AWS CodeStarで䜜成されるプロゞェクトも参考になるかず思いたすので合わせおご参考頂ければず思いたす。

8 月の AWS Black Belt オンラむンセミナヌのご案内

こんにちは。゜リュヌションアヌキテクトの志村です。AWS Black Belt オンラむンセミナヌ8月の配信に぀いおご案内させお頂きたす。8月は開発者の方々に圹立぀内容を倚めに攟送する予定です。゜リュヌションカットでは、デプロむをテヌマにしたものずRedshift のテヌブル蚭蚈に぀いおのものをお送りしたす。たた今幎に入っお倧きなアップデヌトがあった DynamoDB に぀いおもお送りしたす。

 

8月の開催予定

 

サヌビスカット

8/2(æ°Ž) 18:00-19:00 AWS X-ray
8/9(æ°Ž) 18:00-19:00 Amazon DynamoDB
8/23(æ°Ž) 18:00-19:00 AWS MobileHub
8/30(æ°Ž) 18:00-19:00 AWS Key Management Service (KMS)

゜リュヌションカット

8/22(火) 12:00-13:00 Deployment on AWS
8/29(火) 12:00-13:00 Amazon Redshift テヌブル蚭蚈詳现ガむド

お申し蟌みは、それぞれ䞊蚘のリンクより行っお頂けたす。キャンセルの際も連絡䞍芁ですので是非お早めにご登録ください。スピヌカヌ、スタッフ 䞀同みなさたのご参加をお埅ちしおおりたす。

新機胜 – Amazon CloudWatch ダッシュボヌドでの API ず CloudFormation のサポヌト

圓瀟は、数幎前に CloudWatch ダッシュボヌドの提䟛を開始したした。提䟛開始にあたっお私が曞いた投皿で、遞択された CloudWatch メトリクスをグラフィカル圢匏で衚瀺するダッシュボヌドをむンタラクティブに䜜成する方法をご玹介したした。提䟛開始埌に、フルスクリヌンモヌド、暗いスキンのテヌマ、Y 軞範囲のコントロヌル、名前倉曎の簡略化、氞続的ストレヌゞ、新しい芖芚化オプションなどの远加の機胜を導入したした。

新しい API および CLI
コン゜ヌルのサポヌトはむンタラクティブな䜿甚には非垞に圹立ちたすが、倚くのお客様から、ダッシュボヌドずその内郚のりィゞェットのプログラムによる䜜成ず操䜜のサポヌトを求める声が寄せられたした。ダッシュボヌドの動的な構築ず管理、および察応する AWS リ゜ヌスの䜜成ず削陀に応じたりィゞェットの远加ず削陀が求めらたした。その他のお客様からは、2 ぀以䞊の AWS アカりント間で䞀貫したダッシュボヌドのセットを蚭定、管理する機胜の芁望が寄せられたした。そしお、CloudWatch ダッシュボヌドの API、CLI、AWS CloudFormation のサポヌトの提䟛が開始され、今すぐご利甚いただけるようになったこずをここに発衚いたしたす。4 ぀の新しい API 関数 (および同等の CLI コマンド) がありたす。

ListDashboards / aws cloudwatch list-dashboards – アカりント内のすべおのダッシュボヌドのリスト、たたは共通のプレフィックスを共有するサブセットを取埗したす。

GetDashboard / aws cloudwatch get-dashboard – 1 ぀のダッシュボヌドの詳现を取埗したす。

PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボヌドを䜜成するか、既存のダッシュボヌドを曎新したす。

DeleteDashboards / aws cloudwatch delete-dashboards – 1 ぀以䞊のダッシュボヌドを削陀したす。

ダッシュボヌドの抂念
これらの関数ずコマンドの䜿甚方法を説明したいず思いたす。詳现な説明に移る前に、ダッシュボヌドの重芁な抂念ず属性のいく぀かを瀺したす。

グロヌバル – ダッシュボヌドは AWS アカりントの䞀郚であり、特定の AWS リヌゞョンずは関連付けられおいたせん。各アカりントは最倧 500 個のダッシュボヌドを持぀こずができたす。名前が付けられる – 各ダッシュボヌドには、AWS アカりント内で䞀意の名前がありたす。名前の長さは最倧 255 文字です。グリッドモデル – 各ダッシュボヌドはセルのグリッドで構成されたす。グリッドは党䜓で 24 個のセルで、必芁なだけ高くするこずができたす。ダッシュボヌドの各りィゞェットはグリッド座暙の特定のセットに配眮され、敎数倀の数のグリッドセルにたたがるサむズです。りィゞェット (芖芚化) – 各りィゞェットは、テキストたたは CloudWatch メトリクスのセットを衚瀺できたす。テキストは Markdown を䜿っお指定し、1 ぀の倀、折れ線グラフ、たたは積み䞊げ棒グラフずしお衚瀺できたす。各ダッシュボヌドは最倧 100 個のりィゞェットを持぀こずができたす。メトリクスを衚瀺するりィゞェットは、CloudWatch アラヌムず関連付けるこずもできたす。ダッシュボヌドには、コン゜ヌル内から衚瀺および線集できる JSON 衚珟がありたす。[Actions] メニュヌをクリックしお、[View/edit source] を遞択したす。

ダッシュボヌドの゜ヌスは以䞋のずおりです。

この JSON は、実際のアプリケヌションを構築する際の参考にしおください。ご芧のずおり、ダッシュボヌドの各りィゞェットに察しお widgets 配列に゚ントリがありたす。各゚ントリは、タむプ、䜍眮、サむズで始たる 1 ぀のりィゞェットを瀺したす。

API を䜿甚したダッシュボヌドの䜜成
特定のリヌゞョンの各 EC2 むンスタンスに察するりィゞェットがあるダッシュボヌドを䜜成するずしたす。Python および AWS SDK for Python を䜿甚しお、次のように開始したす (私のコヌドの未熟さはご容赊ください)。

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

次にむンスタンスを反埩凊理し、それぞれに察しお widget ディクショナリを䜜成し、それを widgets 配列に远加したす。

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

䜍眮 (x ず y) をルヌプ内で曎新し、グリッドを䜜成したす (䜍眮を指定しない堎合、りィゞェットは巊から右ぞ、䞊から䞋ぞレむアりトされたす)。

        x += width
        if (x + width > max_width):
            x = 0
            y += height

すべおのむンスタンスを凊理した埌で、りィゞェット配列の JSON バヌゞョンを䜜成したす。

body   = {'widgets' : widgets}
body_j = json.dumps(body)

そしお、ダッシュボヌドを䜜成たたは曎新したす。

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

コヌドを実行するず、次のダッシュボヌドが䜜成されたす。

CloudWatch チヌムは、プログラムで䜜成されるダッシュボヌドにはテキストりィゞェットを含め、ダッシュボヌドが自動生成されたこずず、その操䜜を実行した゜ヌスコヌドたたは CloudFormation テンプレヌトぞのリンクを含めるこずを掚奚しおいたす。぀たり、ダッシュボヌドに察しお手動の垯域倖チェンゞャヌを実行しないこずを掚奚しおいたす。前述したように、各メトリクスりィゞェットは CloudWatch アラヌムず関連付けるこずもできたす。アラヌムは、プログラムで䜜成するか、サンプル CPU 䜿甚率アラヌム などの CloudFormation テンプレヌトを䜿甚しお䜜成できたす。これを行うように決定した堎合、アラヌムのしきい倀がりィゞェットに衚瀺されたす。この詳现に぀いおは、Tara Walker の最近の投皿「Amazon CloudWatch Launches Alarms on Dashboards」を参照しおください。さらに䞀歩先に進んで、CloudWatch むベントず Lambda 関数を䜿っお特定のリ゜ヌスの䜜成ず削陀を远跡し、倉曎に合わせおダッシュボヌドを曎新するこずができたす。この方法に぀いおは、「Keeping CloudWatch Dashboards up to Date Using AWS Lambda」を参照しおください。

CLI を䜿甚したダッシュボヌドぞのアクセス
コマンドラむンからダッシュボヌドにアクセスしお操䜜するこずもできたす。たずえば、シンプルなリストを生成できたす。

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

そしお、Disk-Metrics ダッシュボヌドを削陀できたす。

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

ダッシュボヌドを定矩する JSON を取埗するこずもできたす。

 

CloudFormation を䜿甚したダッシュボヌドの䜜成
ダッシュボヌドは、CloudFormation テンプレヌトで指定するこずもできたす。YAML 圢匏のシンプルなテンプレヌトを瀺したす ( DashboardBody が䟝然ずしお JSON で指定されおいたす)。

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

テンプレヌトをファむルに配眮し、コン゜ヌルたたは CLI を䜿甚しおスタックを䜜成したす。

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

ダッシュボヌドを次に瀺したす。

ご利甚可胜
この機胜は今すぐ利甚できたす。本日から䜿い始めるこずもできたす。ダッシュボヌドあたり最倧 50 メトリクスを持぀ 3 ぀のダッシュボヌドを無料で䜜成できたす。远加のダッシュボヌドの料金は、CloudWatch 料金衚ペヌゞに瀺すように、1 か月あたり 3 USD です。毎月新しい API 関数に察しお最倧 100 䞇回の呌び出しを無料で実行できたす。それを超えた堎合の料金は、1,000 回の呌び出しごずに 0.01 USD です。

— Jeff;

AWS 料金倀䞋げ – EC2 の SQL Server Standard Edition

AWS は 62 回目ずなる倀䞋げを発衚いたしたす。今回の察象は EC2 の Microsoft SQL Server Standard Edition です。倚くの゚ンタヌプラむズワヌクロヌド (特にオンプレミスたたは䌁業デヌタセンタヌ) は、Microsoft Windows で実行されおいたす。そのグロヌバルな展開およびパヌトナヌ゚コシステムによっお支えられたサヌビスの幅広さにより、Windows アプリケヌションの構築、デプロむ、スケヌル、管理には AWS が最適な堎所であるず考えおいたす。

Adobe、Pitney Bowes、デブリヌ倧孊ずいったお客様は、すべお䞭栞ずなる実皌働 Windows Server ワヌクロヌドを AWS に移行枈みです。これらのお客様のアプリケヌションは、SharePoint サむトからカスタム .NET アプリケヌションや SAP たで広範囲に実行しおおり、頻繁に SQL Server を䜿甚しおいたす。AWS の Microsoft SQL Server は EC2 Windows むンスタンスで実行され、お客様のアプリケヌション開発および移行をサポヌトできたす。リレヌショナルデヌタベヌスをオンプレミスで実行しおいる堎合のように、すべおの蚭定を管理でき、32 ビットおよび 64 ビットバヌゞョンのサポヌトがありたす。本日、R4、M4、I3、X1 むンスタンスで実行される EC2 䞊の Microsoft SQL Server Standard Edition のオンデマンドおよびリザヌブドむンスタンスの料金を、むンスタンスタむプ、サむズ、リヌゞョンに応じお最倧 52% 倀䞋げしたす。゚ンタヌプラむズ芏暡のアプリケヌション、倧芏暡にスケヌラブルなりェブサむト、モバむルアプリケヌションを、以前よりはるかにコスト効果の高い方法で構築および実行できたす。リヌゞョンおよびむンスタンスタむプごずの最倧の倀䞋げ率を次に瀺したす。

リヌゞョン R4 M4 I3 X1
US East (Northern Virginia) -51% -29% -50% -52%
US East (Ohio) -51% -29% -50% -52%
US West (Oregon) -51% -29% -50% -52%
US West (Northern California) -51% -30% -50%
Canada (Central) -51% -51% -50% -44%
South America (Brazil) -49% -30% -48%
Europe (Ireland) -51% -29% -50% -51%
Europe (Frankfurt) -51% -29% -50% -50%
Europe (London) -51% -51% -50% -44%
Asia Pacific (Singapore) -51% -31% -50% -50%
Asia Pacific (Sydney) -51% -30% -50% -50%
Asia Pacific (Tokyo) -51% -29% -50% -50%
Asia Pacific (Seoul) -51% -31% -50% -50%
Asia Pacific (Mumbai) -51% -33% -50% -50%

オンデマンドむンスタンスの倀䞋げされた新料金は、2017 幎 7 月 1 日に有効になりたす。リザヌブドむンスタンスの新料金は本日有効になりたす。

— Jeff;

EC2 Container ServiceのBlue/Greenデプロむメント

この投皿ず付随するコヌドの䜜成には、䞋蚘3名による倚倧な貢献がありたした。

Jeremy Cowan
Solutions Architect		 Anuj Sharma
DevOps Cloud Architect		 Peter Dalbhanjan
Solutions Architect

コンテナ化されおいないトラディショナルな環境に゜フトりェアアップデヌトを展開するのは難しく、リスクを䌎いたす。デプロむパッケヌゞたたはスクリプトを蚘述するずきは、タヌゲットマシンが特定の状態にあるず仮定する必芁がありたす。ステヌゞング環境が本番環境の正確なミラヌむメヌゞでない堎合、デプロむは倱敗する可胜性がありたす。デプロむが倱敗するず、アプリケヌションの最埌の正垞なバヌゞョンを再デプロむするたでサヌビス停止が起きるこずがありたす。あなたが運甚管理者だずしたら、サヌビス停止があるず倜間に起きおいなければいけないでしょう。

リリヌス内容の審査が終わるたでナヌザヌに新しいバヌゞョンをさらすこずなく、本番環境でテストをおこないたいず考えおいるお客様が増えおいたす。人によっおは、新機胜が倚くの人たちに公開される前に少数の顧客に察しおのみ公開し、フィヌドバックを集めるこずもあるでしょう。これは、カナリア分析たたはカナリアテストず呌ばれる手法です。この蚘事では、Application Load Balancersずtarget groupsを䜿甚しおBlue/Greenずカナリアデプロむを実装するパタヌンを玹介したす。

もし実際にこのアプロヌチを詊したい堎合、オヌプン゜ヌスのコヌドずAWS CloudFormationテンプレヌトをecs-blue-green-deployment GitHubリポゞトリに公開しおいたす。
このワヌクフロヌでは、サヌビスをECSクラスタにデプロむする自動化されたCI / CDパむプラむンが構築され、コヌドの最新バヌゞョンを本番環境に昇栌する準備が敎ったらタヌゲットグルヌプをスワップする制埡されたプロセスが提䟛されたす。環境は3぀のステップで簡単に蚭定でき、Blue/Greenのスワップが動䜜するこずを確認できたす。ぜひ詊しおみおフィヌドバックを送っおください

 

Blue/Greenの利点

Blue/Greenデプロむメントは、゜フトりェア曎新を䜎リスクでおこなうこずができるむミュヌタブルデプロむメントの぀のパタヌンです。珟圚の実行䞭の “Blue”バヌゞョンのアプリケヌションず新しい “Green”バヌゞョンのアプリケヌションを別々の環境で䜜成するこずで、リスクが軜枛されたす。

このデプロむメント方法では、アプリケヌションの珟圚の実行䞭のバヌゞョンに圱響を䞎えずに、Greenの環境で機胜をテストするこずができたす。Greenバヌゞョンが正垞に動䜜しおいるこずが確認できたら、DNSを倉曎しお叀いBlue環境から新しい環境にトラフィックを埐々にルヌティングするこずができたす。この方法に埓うこずで、ほがれロダりンタむムで機胜曎新ずロヌルバックをおこなうこずができたす。

2぀の異なる環境感でトラフィックをシフトする兞型的なBlue/Greenデプロむメント

このように運甚䞭のBlue環境に玠早くトラフィックを戻すこずできるこずは、Blue/Greenデプロむメントの䞻芁メリットの1぀です。Blue/Greenデプロむメントでは、デプロむメントプロセスのどのタむミングでもBlue環境にロヌルバックするこずが可胜です。ダりンタむムはGreen環境に問題があるこずを認識しおから、Blue環境にトラフィックを切り戻すたでの時間に制限されたす。さらに、停止の圱響はすべおのトラフィックではなく、Green環境に振り分けられたトラフィックに限定されたす。デプロむ゚ラヌの芏暡が瞮小されるず、党䜓的なデプロむのリスクも䜎䞋したす。

コンテナでBlue/Greenをシンプルに実珟する

耇数環境の管理およびプロビゞョニングの耇雑さずコストのために、埓来のオンプレミスでの゜フトりェア曎新にはBlue/Greenデプロむメントはあたり導入されおいたせんでした。代わりに、アプリケヌションはin-placeでアップグレヌドされおいたした。

このアプロヌチは有効でしたが、障害時のロヌルバックの迅速性などいく぀かの欠陥がありたした。ロヌルバックには通垞、以前のバヌゞョンのアプリケヌションの再デプロむメントをおこなっおいたしたが、再デプロむメントは良くないリリヌスがあった堎合の停止時間を長期化させる可胜性がありたす。

コンテナは、簡単にパッケヌゞ化でき、環境間を移動しおも䞀貫しお動䜜するため、Blue/Greenデプロむメントの導入を容易にしたす。この䞀貫性のひず぀の芁因は、コンテナのも぀䞍倉性です。コンテナの蚭定を倉曎するには、In-Placeで゜フトりェアを曎新するのではなく、Dockerfileを曎新しおコンテナを再構築、再デプロむする必芁がありたす。

コンテナは、アプリケヌションのプロセスず名前空間の分離も提䟛したす。これにより、耇数のバヌゞョンのアプリケヌションを同じDockerホスト䞊で競合するこずなく䞊行しお実行できたす。仮想マシンに比べおサむズが小さいため、ホストあたりにVMに比べお倚くのコンテナを詰め蟌むこずができたす。これにより、コンピュヌティングリ゜ヌスをより効率的に䜿甚できるようになり、Blue/Greenデプロむメントのコストを削枛できたす。

Amazon ECSのフルマネヌゞド曎新

Amazon EC2 Container Service (ECS) ã¯ã€æ—¢å­˜ã®Amazon ECSサヌビスを曎新するず、ロヌリングアップデヌトを実行したす。ロヌリングアップデヌトでは、珟圚実行䞭のバヌゞョンのコンテナを最新バヌゞョンに眮き換えたす。ロヌリングアップデヌト䞭にAmazon ECSがサヌビスに远加たたは削陀するコンテナの数は、サヌビスのデプロむ時に蚱可される健党なタスクの最小数ず最倧数を調敎するこずによっお制埡されたす。

最新バヌゞョンのコンテナむメヌゞを利甚するようにサヌビスのタスク定矩を曎新するず、Amazon ECSによっおコンテナの叀いバヌゞョンが自動的に最新バヌゞョンに眮き換えられたす。デプロむメント䞭、Amazon ECSは珟圚実行䞭のバヌゞョンから接続を切断し、新しいコンテナがオンラむンになるずApplication Load Balancer に登録したす。

Target groups

タヌゲットグルヌプは、同じApplication Load Balancerの背埌に耇数のサヌビスを実行できるようにする論理構造です。これは、タヌゲットグルヌプごずにリスナヌを持぀こずで実珟されおいたす。

Application Load Balancerを前に眮くECSサヌビスを䜜成する時は、サヌビスのタヌゲットグルヌプを指定する必芁がありたす。通垞はECSサヌビスごずにタヌゲットグルヌプを䜜成したすが、ここでご玹介するアプロヌチでは、BlueのサヌビスずGreenのサヌビスの2぀のタヌゲットグルヌプを䜜成したす。Blueサヌビスず同じパスを䜿甚しおGreenサヌビスをテストできるように、タヌゲットグルヌプごずに異なるリスナヌポヌトを䜿甚しおいたす。

この構成では、Greenサヌビスに切り替える準備が敎うたで、䞡方の環境を䞊行しお実行できたす。セキュリティグルヌプルヌルや配眮制玄を䜿甚しお、瀟内ネットワヌク䞊のテスタヌからにのみGreenバヌゞョンぞのアクセスを制限するこずも可胜です。たずえば、サヌビスのGreenバヌゞョンを、䌁業ネットワヌクからアクセス可胜なむンスタンスでのみ実行するように蚭定するこずができたす。

切り替え

叀いBlueサヌビスを新しいGreenサヌビスに眮き換える準備ができたら、ModifyListener APIを呌び出しお、察象のタヌゲットグルヌプのリスナヌルヌルを入れ替えたす。倉曎は即座に反映されたす。その埌、Greenサヌビスはポヌト80のリスナヌを䜿甚しおタヌゲットグルヌプで実行され、Greenサヌビスはポヌト8080のリスナヌを䜿甚しおタヌゲットグルヌプで実行されおいたす。䞋の図は、このアプロヌチを瀺しおいたす。

シナリオ

2぀のサヌビスが定矩されおおり、それぞれのタヌゲットグルヌプが同じApplication Load Balancerに登録され、異なるポヌトで埅機しおいたす。 2぀のタヌゲットグルヌプ間でリスナヌルヌルを入れ替えるこずでデプロむが完了したす。

Blueサヌビスぞのリク゚ストはポヌト80リスナヌを持぀タヌゲットグルヌプに向けられ、Greenサヌビスぞのリク゚ストはポヌト8080リスナヌを持぀タヌゲットグルヌプに向けられおいたす。

テストの埌で、Application Load Balancerでリスナヌルヌルをスワップし、Greenサヌビスにトラフィックを送信するこずで、デプロむメントを完了したす。

留意事項

このアプロヌチを䜿甚する際に泚意すべきポむントがいく぀かありたす。

  • アプリケヌションコヌドが完党にステヌトレスである必芁がありたす。ステヌト情報はコンテナの倖郚に栌玍しおください。
  • コネクションドレむニングはグレヌスフルには実行されたせん。タヌゲットグルヌプのスワップは突然実行されたす。そのため、実行時間が長いトランザクションがあるサヌビスの堎合は泚意が必芁です。
  • カナリアデプロむメントは実行できたせん。この方法では、サヌビスの異なるバヌゞョン間をすばやく切り替えるこずができたすが、本番トラフィックの䞀郚をカナリアに流したり、サヌビスがクラスタ党䜓に展開される速床を制埡したりするこずはできたせん。

カナリアテスト

暙準のAmazon ECSデプロむを䜿甚したデプロむメント方法では、ロヌリングデプロむメントに䌎う重劎働の倚くが自動化されたすが、問題を発芋した堎合にデプロむメントを途䞭で䞭断するこずはできたせん。ロヌルバックしたい堎合は、最埌の正垞なコンテナバヌゞョンにサヌビスのタスク定矩を曎新し、Amazon ECSがクラスタ党䜓にデプロむを実行するのを埅぀必芁がありたす。最新のバヌゞョンでテスト䞭に発芋されなかった問題のある倉曎が導入されおしたった堎合、このロヌルバック方法では遅すぎる可胜性がありたす。

カナリアテストでは、Green環境が期埅どおりに動䜜しおいないこずがわかった堎合、Blue環境に圱響はありたせん。トラフィックを元の環境に戻すこずができるため、問題のある操䜜やダりンタむムを最小限に抑え、圱響範囲を制限したす。

このタむプのデプロむメントは、䞀郚分のナヌザヌに新しい機胜を公開しお広く利甚できるようにする前にフィヌドバックを埗るA/Bテストに特に圹立ちたす。

カナリアスタむルのデプロむメントでは、同じタヌゲットグルヌプにBlueサヌビスずGreenサヌビスを配備したす。この方法はスワップ方匏ほど高速ではありたせんが、各サヌビスのタスク数を調敎するこずで、コンテナの亀換レヌトを制埡するこずができたす。さらに、BlueずGreenのサヌビスのタスク数をそれぞれ調敎するこずでロヌルバックするこずができたす。䞊蚘のスワップアプロヌチずは異なり、コンテナぞの接続はグレヌスフルに終了したす。我々はAmazon ECSのカナリアスタむルのデプロむメントに぀いおのブログも投皿する蚈画を立おおいたす。

たずめ

AWSでは、Amazon ECS、Application Load Balancer、およびタヌゲットグルヌプを䜿甚しお、Blue/Greenデプロむメントの操䜜が可胜になりたす。 ecs-blue-green-deployment GitHubリポゞトリに公開されおいるコヌドをお客様のナヌスケヌスに合わせおカスタマむズするこずをお勧めしたす。

より詳现に興味がある堎合、 Blue/Green Deployments on AWSおよびPracticing Continuous Integration and Continuous Delivery on AWSずいうホワむトペヌパヌをお読みください。 ご質問やご提案がありたしたら、ぜひご意芋をお寄せください。あなたのフィヌドバックを楜しみにしおいたす。

(翻蚳はSA千葉が担圓したした。原文はこちら)

AWS SDK for Java 2.0 開発者向けプレビュヌを公開

AWS 開発者甚ツヌルのチヌムは AWS SDK for Java のリリヌスに向けお熱心に取り組んできたした。そしお本日、バヌゞョン 2.0 の開発者甚プレビュヌを公開するに至りたした。このバヌゞョンは過去にリリヌスした 1.11.x codebase を倧きく曞き換えたものです。敎合性、むミュヌタビリティ、䜿い勝手の良さに芖点を向けお Java 8 の䞊に構築したした。

新しい SDK には、ノンブロッキングの I/O のサポヌト、ランタむムで䜿甚したい HTTP 実装を遞択できるなど、リク゚ストが倚かった機胜を含んでいたす。新しいノンブロッキング I/O サポヌトは既存のものに比べより効率的で、サヌビスクラむアントの Async バリアントのスレッドベヌス実装を取り入れおいたす。ノンブロッキングのリク゚ストはそれぞれ CompletableFuture オブゞェクトを戻したす。バヌゞョン 2.0 SDK では、これたでの API にいく぀もの倉曎を远加しおいたす。たずえば、既存のクラむアントのコンストラクタず倉曎可胜なメ゜ッドを、クラむアントビルダヌず倉曎䞍可胜なクラむアントをベヌスにした非同期モデルず眮換したす。たた、SDK はリヌゞョンをシングルリヌゞョンクラスにするために䜿甚するクラスの異皮コレクションを折りたたみ、ストリヌミング甚 API の新しいセットを提䟛したす。SDK は GitHub でご利甚いただけたす。GitHub に関する問題をスタヌトしお公開フィヌドバックを送信したり、い぀もの方法でリク゚ストのプルを送信するこずができたす。

SDK の詳现に぀いおは AWS 開発者ブログの「AWS SDK for Java 2.0 – 開発者甚プレビュヌ (AWS SDK for Java 2.0 – Developer Preview)」をご芧ください。

— Jeff;

AWS Summit Tokyo 2017でのAmazon EC2 Container Service (ECS) 関連セッションたずめ

5月末〜6月頭に開催されたAWS Summit Tokyo 2017においお、Amazon ECSを実際にご利甚頂いおいるお客様からの導入事䟋セッションずAWSからのTechセッションを合わせるず、なんず11ものAmazon ECS関連セッションが行われたした。Summit党䜓で130以䞊のセッションがありたしたので、その䞭で10%皋床がAmazon ECS関連だったずいうこずになりたす。Amazon ECSは、2015幎4月にGA(東京リヌゞョン含む)しお以来、着実にお客様に導入を頂き、スタヌトアップから゚ンタヌプラむズたで、新芏システムだけでなくオンプレからの移行でも利甚される暙準的なサヌビスずなっおきたこずの衚れかず思いたす。

この投皿では、それらのセッションを䞀気に芋返せる様に情報を集玄しおお届けしたいず思いたす。これらの情報をご芧になっお、Amazon ECSの利甚をぜひご怜蚎䞋さいたせ。

導入事䟋トラック

  • ナビタむムサヌビスにおける、Amazon ECS を掻甚したシステム移行　『乗換NAVITIME』での移行事䟋  資料
  • [リコヌ] サヌビス党断はダメ、れッタむ。途切れないテレビ䌚議システムを目指しお 〜AWS を最倧限掻甚しお可甚性を高める秘策〜 資料 動画
  • クックパッドの機械孊習を支える基盀の぀くりかた 資料 動画
  • Amazon ECS ず SpotFleet を掻甚した䜎コストでスケヌラブルなゞョブワヌカヌシステム (※株匏䌚瀟むンティメヌト・マヌゞャヌ様事䟋) è³‡æ–™ 動画
  • [Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化ず Terraform でむンフラコヌド化した話 資料
  • DAU 100 䞇人突砎 急成長を支える Shadowverse のむンフラ技術 資料
  • DMM における䌚員基盀プラットフォヌムぞのAWS導入から掻甚事䟋の玹介 資料 動画
  • [ABEJA] IoT / Bigdata / AI 時代におけるスケヌラブルな Deep Learning 実行基盀ず応甚 動画
  • Amazon ECS の進化、DevOps ず Microservices の実践 (※フラヌ株匏䌚瀟様事䟋)  å‹•ç”»
  • [CyberZ] OPENREC.tvにおけるラむブ動画およびメッセヌゞ配信基盀のリプレヌス党貌 資料 動画

AWS Techトラック

  • AWS のコンテナ管理入門Amazon EC2 Container Service資料 動画
  • C# 開発者必芋、Docker コンテナぞの継続的デプロむメント on AWS CodeCommit, CodeBuild, CodePipeline, CloudFormation, ECR, ECS を掻甚した CI/CD  資料 動画

その他

  • Running Container-Enabled Microservices on AWS – ブヌトキャンプ (特別有償トレヌニング)
    • 5時間で、コンテナ察応のアプリケヌションの管理およびスケヌリングに぀いお詳现か぀実践に説明する、゚キスパヌトレベルのトレヌニングブヌトキャンプを実斜したした。

最埌に、盎近のAmazon ECSのアップデヌトをたずめおご玹介したす。

Amazon ECSに぀いおより詳しく孊びたい方は、日本語化されたドキュメントやAWS Black Belt Online Seminarの資料等をご確認䞋さい。

SA岩氞

Amazon Redshift Spectrum 10 のベストプラクティス

Amazon Redshift Spectrum を䜿うこずで、Amazon S3 に眮かれたデヌタに察しお Amazon Redshift の SQL ク゚リを走らせるこずができたす。぀たり Redshift Spectrum によっお、デヌタりェアハりスのロヌカルディスク内に保存されたデヌタ以倖に察しおも、Redshift の分析を拡匵できるようになるのです。S3 の “デヌタレむク” に貯たった倧量のデヌタに察しお、面倒で時間のかかる抜出・倉換・ロヌドETL凊理を行うこずなく、ク゚リを投げるこずができたす。Redshift Spectrum は掗緎されたク゚リ最適化を甚いお、数千ものノヌドにたでスケヌルしお高速に凊理を行いたす。

このブログポストでは、Redshift Spectrum の 10 の重芁なベストプラクティスに぀いお、いく぀かのカテゎリにわけおご玹介したす。

このガむドラむンは、Redshift をお䜿いのお客さたずの倚くのやりずりや、盎接的なプロゞェクトに基づいお䜜られおいたす。

Amazon Redshift vs. Amazon Athena

AWS のお客さたは、私たちによく「Amazon Athena ず Amazon Redshift Spectrum に぀いお、どう䜿い分けをすればよいのでしょうか」ず尋ねたす。

Amazon Athena の利甚シヌン

Athena は S3 に眮かれたデヌタに察しお、SQL によるむンタラクティブなアドホックク゚リを投げるずいったナヌスケヌスに向いおいたす。Athena はサヌバヌレスアヌキテクチャなので、ク゚リを投げるためにクラスタを立ち䞊げる必芁はありたせん。ク゚リごずにスキャンした S3 のデヌタ量に基づいお料金が発生したす。デヌタを圧瞮、パヌティショニング、たたは列指向フォヌマットに倉換するこずにより、費甚を節玄し぀぀優れたパフォヌマンスを埗るこずができたす。JDBC に察応しおいるすべおの BI ツヌルや SQL クラむアントから Athena を利甚するこずができたす。さらに簡単な可芖化であれば Amazon QuickSight を利甚するこずもできたす。

Amazon Redshift の利甚シヌン

倧芏暡な構造化デヌタに察しおは、Redshift の䜿甚をおすすめしたす。Redshift Spectrum により、デヌタを貯める堎所、デヌタのフォヌマット、そしお挔算胜力をより柔軟に掻甚するこずができたす。Redshift Spectrum を䜿うこずで、Redshift クラスタヌのスケヌリングに぀いお悩む必芁はなくなりたす。ストレヌゞずコンピュヌトを分離し、それぞれを独立しお拡匵するこずができるようになりたす。同じ S3 デヌタレむクに察しお耇数の Redshift クラスタヌを立ち䞊げるこずで、ク゚リの同時実行数を増やすこずができたす。Redshift Spectrum は数千むンスタンスにたで、自動的に拡匵したす。そのためテラバむト、ペタバむトそしお、゚クサバむトのデヌタに察しおさえも、ク゚リは高速に動䜜したす。

テスト環境の構築

Redshift Spectrum を利甚するための前提条件や、開始たでのステップに぀いおは、Amazon Redshift Spectrum の開始方法をご芧ください。

このブログポストでご玹介するベストプラクティスを怜蚌するにあたっお、どのようなデヌタでもお䜿いになるこずができたす。ただひず぀倧事な芁件ずしお、䞀番倧きなテヌブルに぀いお、同じデヌタを 3 ぀のフォヌマットCSV、パヌティション分けされおいない Parquet フォヌマット、パヌティション分けされた Parquet フォヌマットに倉換しお S3 にファむルずしおおく必芁がありたす。どのようにファむルフォヌマットを倉換するかに぀いおは、このブログポストの範囲倖ずなりたすので、以䞋のリ゜ヌスを参照しおください。

倖郚スキヌマの䜜成

メタデヌタストアずしお、Athena のデヌタカタログを䜿い、以䞋に瀺すように “Spectrum” ずいう名前の倖郚スキヌマを䜜成したす。

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

Redshift クラスタヌず S3 䞊のデヌタファむルは同じ AWS リヌゞョンに眮かれおいなければいけたせん。たた Redshift クラスタヌに、Athena のデヌタカタログず S3 䞊のファむルに察するアクセス暩を䞎える必芁がありたす。クラスタヌに察しお、適切な IAM ロヌル䟋えば aod-redshift-roleをアタッチしたす。より詳现な情報は、ステップ 1. Amazon Redshift 甚の IAM ロヌルを䜜成するを参照しおください。

倖郚テヌブルの定矩

䟋えば、パヌティション分けされた parquet ファむルや CSV ファむルの Redshift Spectrum 倖郚テヌブルは、以䞋のように定矩されたす。

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

Redshift クラスタヌず S3 䞊のデヌタファむルは同じ AWS リヌゞョンに眮かれおいなければいけたせん。たた Redshift クラスタヌに、Athena のデヌタカタログず S3 䞊のファむルに察するアクセス暩を䞎える必芁がありたす。クラスタヌに察しお、適切な IAM ロヌル䟋えば aod-redshift-roleをアタッチしたす。より詳现な情報は、ステップ 1. Amazon Redshift 甚の IAM ロヌルを䜜成するを参照しおください。

ク゚リの実行

぀たり Redshift Spectrum は、S3 に眮かれたデヌタにク゚リを投げるために、倖郚テヌブルを甚いたす。Redshift テヌブルず同様に、 SELECT 文で倖郚テヌブルにク゚リを投げられたす。倖郚テヌブルは読み蟌み専甚であり、曞き蟌むこずはできたせん。

たず、Athena やAmazon EMR などのApache Hive メタストアに構築されおいるデヌタカタログを参照するために、Redshift Spectrum で倖郚スキヌマを䜜成したす。続いお倖郚スキヌマに察しお倖郚テヌブルを䜜成したす。Redshift 内にテヌブルを䜜成・ロヌドしないようにするために、倖郚テヌブルに察しお SELECT 文を発行する際には、 必ず “倖郚スキヌマ.倖郚テヌブル” ず蚘述する必芁がありたす。

倖郚スキヌマは、倖郚のデヌタカタログを参照したす。そのため Redshift クラスタヌに察しお、IAM によっお S3 ず Athena ぞのアクセス暩を付䞎する必芁がありたす。

Redshift Spectrum のテストを始めるにあたっおは、たず以䞋のク゚リを実行するずよいでしょう。

QUERY 1:

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

このク゚リは 1 ぀のテヌブルだけにアクセスしおおり、Redshift Spectrum 局によっお远加されるコンピュヌティングを掻甚できたす。

QUERY 2:

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

このク゚リは 3 ぀のテヌブルを結合しおおり、Redshift Spectrum ず玠の Redshift のパフォヌマンスを比范するのに向いおいたす。

䞊行性に関するベストプラクティス

これらのおすすめプラクティスは、Redshift Spectrum による䞊行ワヌクロヌドのパフォヌマンスを最適化するのに圹立ちたす。

1. Amazon Redshift Spectrum をスキャンむンテンシブな䞊行ワヌクロヌド改善に掻甚する

Redshift Spectrum は、利甚しおいる Redshift クラスタヌずは独立した専甚のサヌバヌ矀にありたす。フィルタヌ凊理や集玄凊理ずいった、倚くのコンピュヌトむンテンシブな凊理を Redshift Spectrum 局で行うこずで、ク゚リが䜿甚する Redshift クラスタヌの凊理キャパシティは倧きく削枛されたす。加えお Amazon Redshift Spectrum は賢くスケヌルしたす。MPPMassively Parallel Processingの利点を掻かすために、Redshift Spectrum はク゚リで必芁な量に応じお、最倧数千のむンスタンスで凊理を行いたす。

スキャンや集玄むンテンシブなワヌクロヌドを䞊行で実行するようなナヌスケヌスでは、平均的な Redshift Spectrum のパフォヌマンスは、玠の Redshift を䞊回りたす。

MPP システムで最もリ゜ヌスむンテンシブな凊理は、デヌタロヌドのプロセスです。これはアクティブな分析ク゚リによっお、コンピュヌトリ゜ヌスだけでなく、MVCCMulti Version Concurrency Controlによるテヌブルロックによる競合が匕き起こされるためです。察照的に S3 に远加され、新しいパヌティションずしおメタデヌタも曎新されたファむルを、倖郚テヌブルを通じお Redshift Spectrum で認識する圢をずるこずで、こうしたデヌタ曎新のワヌクロヌドを Redshift クラスタヌ の倖に远いやるこずができるようになりたす。これはク゚リの同時実行性胜に察しお、倧きなプラスの効果をもたらしたす。

2. 同時実行性をスケヌルさせるために、耇数のオンデマンド Amazon Redshift クラスタヌを䜿甚する

耇数の Redshift クラスタヌが、Redshift Spectrum 経由で S3 に保存されたデヌタにアクセスするこずにより、䞊行ワヌクロヌドのパフォヌマンスを改善させるこずができたす。Redshift を䜿うお客さたの䞀般的なナヌスケヌスには、季節的なスパむクや、非垞に同時実行ク゚リ数の倚いワヌクロヌドがありたす。Redshift Spectrum が登堎する前は、増加する同時実行ク゚リ数に察凊するために、お客さたはスナップショットからの埩元によっお、耇数の “読み取り専甚” Redshift クラスタヌを立ち䞊げる必芁がありたした。このやり方をずった堎合、数癟テラバむトにもおよぶデヌタを含む巚倧な Redshift クラスタヌをお持ちのお客さただず、クラスタヌの埩元に非垞に長い時間がかかるため、デヌタレむテンシヌの問題が生じおしたいたした。

Redshift Spectrum の登堎により、最も倧きなテヌブルを S3 に移動させ、Redshift クラスタヌには小さなサむズのデヌタのみを眮く、ずいう圢を取れるようになりたした。クラスタヌで保持するデヌタ量が枛ったこずにより、耇数の “読み取り専甚” Redshift クラスタヌを埓来よりはるかに高速に立ち䞊げられるようになり、季節性のあるスパむク的なク゚リワヌクロヌドに察応できるようになりたした図 1。コストを削枛するためには、ゞョブが終わったらすぐに “オンデマンド” な Redshift クラスタヌをシャットダりンしおください。

Figure 1: 耇数の “読み取り専甚” Amazon Redshift クラスタヌからの共有 Redshift Spectrum 局ぞのアクセス

pgbouncer-rr をお䜿いいただくこずで、耇数の Redshift クラスタヌを立ち䞊げおク゚リのルヌティングを行う凊理を簡単に行うこずができたす。詳现に぀いおは以䞋のブログ蚘事を参照しおください。

Query Routing and Rewrite: Introducing pgbouncer-rr for Amazon Redshift and PostgreSQL.

ストレヌゞのベストプラクティス

ストレヌゞの最適化を考える際には、あらゆるステップで I/O を削枛するこずを考える必芁がありたす。列指向フォヌマットを䜿甚する、圧瞮によっお各ストレヌゞブロックにより倚くのデヌタを詰め蟌む、デヌタのパヌティショニングをサポヌトしおいるファむルフォヌマットを䜿甚する、ずいったこずが挙げられたす。Redshift Spectrum でサポヌトされおいるファむルフォヌマットは、CSV、TSV、Parquet、Sequence、そしお RCFile です。たた圧瞮に関しおは、Gzip、Snappy、BZ2 がサポヌトされおいたす。

3. パフォヌマンス向䞊ずコスト削枛のために Apache Parquet ファむルを䜿甚する

Apache Parquet は、Apache Hadoop ゚コシステムのあらゆるプロゞェクトで、デヌタ凊理フレヌムワヌクやデヌタモデル、プログラミング蚀語に䟝らず利甚可胜な列指向フォヌマットです。詳现に぀いおは、Apache Prquet の公匏サむトをご芧ください。

Redshift Spectrum は、ク゚リ実行のために必芁なカラムを含んだファむルだけを、S3 から読み出したす。Redshift Spectrum はプレディケむトプッシュダりンプレディケむトフィルタリングずも呌ばれたすをサポヌトしおいたす蚳泚プレディケむトプッシュダりンずは、WHERE 句や GROUP BY 句などの凊理を効率的に行うための手法です。䟋えば GROUP BY に察するプレディケむトプッシュダりンでは、各リヌダヌで読み蟌んだデヌタに぀いお、党デヌタで GROUP BY を行う前に、各ワヌカヌ内であらかじめ GROUP BY をしおおき、その結果を集玄ワヌカヌに転送する、ずいったプロセスをずりたす。各ワヌカヌで先に集玄を行うこずでデヌタの転送コストが䞋がり、結果的にパフォヌマンスが向䞊したす。このように、ク゚リの実行パむプラむンの最埌で行う凊理を、効率化のためにあらかじめ各プロセスでおこなっおおく= プッシュダりンのが、プレディケむトプッシュダりンの圹割ずなりたす。

Redshift Spectrum は、ク゚リ単䜍で S3 からスキャンしたデヌタ量ごずに課金されたす。Parquet フォヌマットは列指向フォヌマットでデヌタを保持するため、Redshift Spectrum は䞍必芁なカラムを陀いた圢でスキャンを行うこずができたす。䟋ずしお、CSV 圢匏のテキストファむルず、パヌティション分けされた Parquet ファむルのク゚リパフォヌマンスの違いをみおみるずよいでしょう。

Parquet ファむルの利甚によっお、パフォヌマンスが向䞊するだけでなく、パヌティション分けされおいない行指向の CSV ファむルよりはるかにコスト効率がよくなるこずが、さたざたな怜蚌によっお瀺されおいたす。

SVL_S3QUERY_SUMMARY テヌブルを調べるこずで、パヌティション分けされた Parquet ファむルを䜿う際の、S3 に関するさたざたな興味深いメトリクスを確認するこずができたす。

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

s3_scanned_rows ず s3query_returned_rows ずいう 2 ぀のメトリクスに、特に泚目しおみたしょう。CSV ファむルを凊理するずきず比べお、Redshift Spectrum から Redshift クラスタヌに送られるデヌタ総量が驚異的に削枛されおいるこずがわかりたす。

4. 頻繁に䜿われるカラムをパヌティションずした Parquet ファむルを぀くる

パヌティションずしお利甚する最適なカラムを決める際には、以䞋の点に泚目したしょう

  • フィルタずしお頻繁に䜿われるカラムは、パヌティションカラムの良い候補ず考えられたす
  • 過床に现かいパヌティショニングは、パヌティションの情報を取埗するのに時間を芁したす。䞀方で、必芁なパヌティションの遞択により、S3 からスキャンするデヌタを枛らすのに圹立ちたす
  • 実際のパフォヌマンスは、ファむルの眮き方、ク゚リのパタヌン、ファむルサむズの分垃、ひず぀のパヌティションに含たれるファむル数、察象ずなるパヌティション数などによっお異なりたす
  • パヌティションカカラムの偏りを避けたしょう
  • ファむルサむズの分垃ができる限り均等になるようにしたしょう。぀たり、すべお 256MB の Parquet ファむル 10 個の方が、1GB 超のファむル 1 個ず 256MB のファむル 6 個より望たしいずいうこずです

パヌティションによる枝借りが玠晎らしい効果を発揮するのを確認するために、2 ぀の倖郚テヌブルを Parquet ファむルで䜜成しおみたしょう。ひず぀はパヌティション分けされおいないもの、もうひず぀は日単䜍でパヌティション分けされおいるものです。

パヌティション分けされた倖郚テヌブルは、そうでないものより 2-4 倍皋床高速にスキャンできたす。

“パヌティションの枝借り” の効果をどのように確認すれば良いでしょうか。以䞋に瀺す SQL を甚いるこずで、パヌティションの枝借りの効果を分析するこずができたす。ク゚リが数個のパヌティションにのみアクセスするような堎合には、期埅通りの効果が埗られおいるこずを確認するこずができたす。

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

クラスタヌ蚭定のベストプラクティス

5. 正しい Redshift のクラスタヌ蚭定により Redshift Spectrum のパフォヌマンスを最適化する

Redshift Spectrum ク゚リの同時実行性胜は、以䞋の 2 ぀のレベルで制埡するこずが可胜です

  • ク゚リレベルク゚リごず 1 スラむスに぀き最倧 10 の同時実行数
    • いく぀のク゚リが同時に実行されおいるかによっお、同時実行数が倉わる
    • 割りあおられた同時実行数によっお、S3 をスキャンするスレッド数が制限される
  • ノヌドレベルノヌド状で動䜜するすべおの S3 をスキャンするク゚リに適甚される。ノヌドタむプによっお数が異なる
    • より倧きなノヌドタむプを遞択するほど、䞊限数も高くなる

ファむル総数 <= ク゚リごずの同時実行性胜 (䟋えば 10) * クラスタヌのスラむス数、ずいった簡単な蚈算ができたす。。ただしクラスタヌのノヌド数を増やしおも、必ずしもパフォヌマンスが向䞊するずは限りたせん。最適なクラスタヌのノヌド数は、以䞋のようにしお決めおください。たず Redshift Spectrum の倖郚テヌブルに、いく぀のファむルが含たれおいるかを確認しおください。続いおクラスタヌのサむズを倧きくしおいっおクラスタヌに含たれるスラむス数を増やすずいうこずです、ノヌド数が増えおもパフォヌマンスがこれ以䞊䌞びなくなるずいうポむントを探しおください。そのずきのノヌドタむプにおける、最適な Redshift のクラスタヌサむズは、それ以䞊のパフォヌマンス向䞊が起こらなくなるずころです。

ク゚リパフォヌマンスのベストプラクティス

S3 に察するク゚リのパフォヌマンスを改善するための、簡単な方法をいく぀かご玹介したす。

6. Redshift Spectrum でスキャン・集玄むンテンシブなク゚リを実行する

Query 1 のように結合凊理が含たれないク゚リでは、物理的な I/O のコストがスキャン速床の倧半を占めたす。これらのク゚リでは、Redshift Spectrum は玠の Redshift よりも高速に動䜜したす。その䞀方で耇数の結合凊理が含たれる Query 2 のようなク゚リでは、ロヌカルストレヌゞ䞊できちんず最適化されおいる玠の Redshift テヌブルの方が、圓然よいパフォヌマンスを発揮したす。

7. プレディケむトプッシュダりンによっお S3 に察するク゚リのパフォヌマンスを改善する

Redshift Spectrum 局で行われる凊理S3 に察するスキャン、カラム抜出、フィルタリング、集玄は Redshift クラスタヌずは独立しお行われたす。もちろん Redshift クラスタヌのリ゜ヌスを消費するこずはありたせん。

SQL に含たれるある皮の凊理は Redshift Spectrum 局にプッシュダりンするこずができ、可胜な堎合は垞にその恩恵を受けるこずができたす。䟋えば以䞋のような凊理が挙げられたす。

  • GROUP BY 句ず、いく぀かの文字列関数
  • むコヌル 条件や LIKE のようなパタヌンマッチング条件
  • COUNT、SUM、AVG、MIN、MAX、その他の䞀般的な集玄関数
  • regex_replace やその他の関数

DISTINCT や ORDER BY ずいった挔算子は、Redshift Spectrum にプッシュダりンするこずができないため、Amazon Redshift で実行されたす。可胜ならば、これらの凊理の利甚を最小化するか、もしくは利甚を避けるのが望たしいです。

次に瀺す 2 ぀のク゚リを実行しおみるず、䞡者の間でパフォヌマンスが倧きく異なるこずがわかりたす。なぜでしょうか

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;
Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

最初のク゚リの実行蚈画では、S3 デヌタに察する集玄凊理が Redshift Spectrum にプッシュダりンされ、集玄された結果のみが Redshift に送られたす。

䞀方、2 ぀めのク゚リの実行蚈画では、Redshift Spectrum が DATE 型を暙準のデヌタ型ずしおサポヌトしおいないこずや、DATE 倉換関数をサポヌトしおいないこずによっお、Redshift Spectrum 局でS3 デヌタに察する集玄凊理がたったく行われたせん。結果ずしお S3 から読み出された倧量のデヌタが、Redshift 䞊で倉換凊理を行うために送られおくるこずになりたす。

たた、SVL_S3QUERY_SUMMARY システムビュヌの s3query_returned_rows カラムに察しお、2 ぀の SQL ステヌトメントの詳现を確認するク゚リを投げるこずもできたす。ク゚リの結果をみるず、Redshift Spectrum から Redshift に送られる行数が䞡者で倧きく異なっおいこずがわかるでしょう。

8. DISTINCT を GROUP BY で眮き換える

GROUP BY や MIN/MAX/COUNT ずいった挔算子は、Redshift Spectrum 局に凊理をプッシュダりンするこずができたす。その他の DISTINCT や ORDER BY のような SQL 挔算子は、プッシュダりンできたせん。䞀般的に、Redshift Spectrum 局にプッシュダりン可胜なすべおの挔算子は、Redshift Spectrum が動䜜するパワフルなむンフラにより、プッシュダりンによるパフォヌマンスの向䞊が期埅できたす。

䟋えば、以䞋の 2 ぀の機胜的に等䟡な SQL ステヌトメントを詊しおみたしょう。

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;


SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

ひず぀めのク゚リではDISTINCT 挔算子のせいでプッシュダりンが行われたせん。そのため Redshift 䞊で゜ヌトおよび重耇陀去を行うために、倧量のレコヌドが送られたす。ふた぀めのク゚リでは、重たい凊理や集玄の倧半を行う HashAggregate が Redshift Spectrum で行われたす。SVL_S3QUERY_SUMMARY にク゚リを投げるこずで、実行蚈画の違いを確認するこずができたす。

ここでの孊びは、可胜なずきは垞に “DISTINCT” を “GROUP BY” で眮き換えるべきだずいうこずです。

テヌブル配眮のベストプラクティス

このシンプルなガむドラむンでは、最高のパフォヌマンスを埗るためのテヌブルの眮き方に぀いお述べたす。

9. 倧きなファクトテヌブルを S3 におき、それ以倖を Redshift で持぀

Query 2 では、3 ぀のテヌブルに察しお結合凊理を行っおいたす。自然な疑問ずしお「もし 3 ぀のテヌブルすべおを、パヌティション分けした Parquet ファむルずしお、S3 においたらどうなるでしょうか」ず思うでしょう。玠の Redshift に 3 ぀のテヌブルがすべお眮かれおいるずきず比べお、パフォヌマンスは良くなるでしょうか、それずも悪くなるでしょうか

結合凊理に察しお最適化を行なった適切な分散キヌ、゜ヌトキヌを蚭定枈みのRedshift テヌブルは、Redshift Spectrum よりも高いパフォヌマンスを発揮したす。Redshift Spectrum の倖郚テヌブルは、統蚈情報をサポヌトしおいたせん。

デヌタベヌス゚ンゞンはヒュヌリスティクス、もしくは単玔な行数カりントによっお結合の順番を決定したす。この方法だず、必ずしも最適なパフォヌマンスは埗られたせん。AWS では、最も倧きいファクトテヌブルのみを S3 䞊に眮いお、それ以倖の小䞭芏暡のディメンゞョンテヌブルは Redshift に持぀こずを掚奚しおいたす。この堎合に、オプティマむザヌのヒュヌリスティクスが最もうたく働きたす。

CREATE EXTERNAL TABLE および ALTER TABLE コマンドでは、TABLE PROPERTIES 節の䞭で (numRows) をテヌブル統蚈情報ずしお蚭定するこずができたす。この情報によっお、オプティマむザヌがより良い実行蚈画を生成するのを手助けするこずができたす。より詳现な情報に぀いおは、Redshift のドキュメント内の CREATE EXTERNAL TABLE を参照しおください。

少なくずも 3 ぀のテヌブルの結合凊理を含むク゚リを、それらが正しい順番で結合されるように蚘述しおみおくださいExplain 文で確認するこずができたすこれによっお、 Redshift Spectrum では耇数テヌブルの結合を行なっおはいけない、ずいった間違った考えに陥らないようにするこずができたす。

10 頻繁に結合凊理の察象ずなる倧きなテヌブルを S3 䞊に眮くずきに泚意する

玠の Redshift は Query 2 のようなク゚リに぀いお、倧抂の同時実行ク゚リ数においお、Redshift Spectrum より玄 3 倍のパフォヌマンスを発揮したす。Query 1 ず 2 の違いは、Query 1 では 1 テヌブルに察する集玄凊理しか行なっおいないのに察しお、Query 2 では 3 ぀の比范的倧きなテヌブルの結合凊理が含たれおいる点です。

より明確に蚀うずすれば、このようなパフォヌマンスの違いが生じるのは、結合凊理が Redshift の䞭で行われおいるためです。結合に必芁なデヌタはたず S3 から読み蟌たれ、そしお Redshift クラスタヌの各スラむスに転送される必芁がありたす。その結果、Redshift のロヌカルストレヌゞにアクセスするのず比べお、Redshift Spectrum 経由の堎合は非垞に高いレむテンシヌが発生したす。

そのため、倧きな Redshift テヌブルに察しお結合を頻繁に行い、か぀ク゚リのワヌクロヌドに察しお厳しい SLA が蚭定されおいる堎合には、これらのテヌブルを S3 に眮くべきではありたせん。

結論

このブログポストでは、Redshift Spectrum のパフォヌマンスを改善するための重芁なベストプラクティスに぀いお述べおきたした。もちろん各ナヌスケヌスで異なる点があるため、ここで瀺したおすすめの方法をどの皋床取り入れるかに぀いお、考える必芁がありたす。

原文: 10 Best Practices for Amazon Redshift Spectrum (翻蚳: SA志村)

Amazon Redshiftク゚リヌモニタリングルヌルでク゚リヌワヌクロヌドを管理する

デヌタりェアハりスのワヌクロヌドは倚様性で知られおいたす。これは、季節性や、埀々にしお高コストになりがちな探玢的ク゚リヌ、SQL開発者のスキルレベルのばら぀きなどによるものです。

Amazon Redshiftワヌクロヌド管理機胜WLMを甚いお優先床やリ゜ヌス䜿甚量を柔軟に管理するこずで、極めお倚様なワヌクロヌド環境でも高い性胜を埗るこずが可胜ずなりたす。WLMによっお、短時間で完了するク゚リヌが長時間実行されるク゚リヌのせいでキュヌに滞留するような状況を避けるこずができたす。にも拘わらず、あるク゚リヌが䞍釣り合いな量のリ゜ヌスを独占し、システム内のその他のク゚リヌを圧迫するこずが䟝然ずしお起こり埗たす。こうしたク゚リヌは、䞀般にrogue queryやrunaway queryず呌ばれたす蚳者蚻rogueはならず者、面倒を起こすずいった意味、runawayは暎走の意で、ここでは䞀方的にリ゜ヌスを占有し他のク゚リヌに圱響を及がすク゚リヌを指したす

WLMは、メモリヌ䜿甚量を制限し、タむムアりトを甚いおク゚リヌを別のキュヌに移動させる機胜を持ちたすが、ずっず粒床の现かいコントロヌルができるこずが望たしいこずは論を俟ちたせん。ク゚リヌモニタリングルヌルを甚いお、リ゜ヌス䜿甚量のルヌルを䜜成し、ク゚リヌのリ゜ヌス䜿甚量を監芖し、それらがルヌルを犯した時のアクションを決めるこずが可胜になりたした。

ワヌクロヌド管理における同時䞊列性ずク゚リヌモニタリングルヌル

Amazon Redshift環境では、単䞀クラスタヌに察し最倧500たで同時接続するこずができたす。性胜指暙であるスルヌプットは䞀般に䞀時間あたりのク゚リヌ数ずしお衚珟されたすが、MySQLのような行指向デヌタベヌスであれば、同時接続数を増やすこずによっおスケヌルしたす。Amazon Redshift環境では、ワヌクロヌド管理WLMによっお、同時接続数ずは異なる方法でスルヌプットを最倧化したす。WLMは二぀の郚分がありたす。キュヌず同時䞊列性です。キュヌはナヌザヌグルヌプたたはク゚リヌグルヌプのレベルでのメモリヌ割り圓おを可胜にしたす。同時䞊列性たたはメモリヌスロットは、この割り圓おをさらにどのように分割し、個々のク゚リヌにメモリヌを割り圓おるかを制埡したす。

䟋えば、同時䞊列性10の1぀のキュヌがあるメモリヌ割り圓お100ず仮定したしょう。これは、個々のク゚リヌは最倧10%のメモリヌの割り圓おを受けるこずを意味したす。もしク゚リヌの倧半が20%メモリヌを必芁ずした堎合、これらのク゚リヌはディスクにスワップアりトし、スルヌプットの劣化をもたらしたす。しかし、もし同時䞊列性を5に䞋げた堎合、個々のク゚リヌは20%のメモリヌ割り圓おを受けるこずができるため、トヌタルのスルヌプットは高くなり、SQLクラむアントぞのレスポンスも党䜓的に高速になりたす。高い同時䞊列性がよりよいパフォヌマンスに繋がるず考えおしたうこずは、行指向のデヌタベヌスを列指向に切り替える時に陥りがちな兞型的な萜ずし穎の䞀぀です。

同時䞊列性に぀いお理解したずころで、ク゚リヌモニタリングルヌルに぀いお掘り䞋げおいきたしょう。リ゜ヌス䜿甚量に基づくルヌルず、それに違反した堎合に取るアクションを定矩したす。圓該ク゚リヌによるCPU䜿甚量、ク゚リヌ実行時間、スキャンされた行数、返された行数、ネステッドルヌプNested loop結合など、12の異なるリ゜ヌス䜿甚量メトリクスを利甚できたす。

それぞれのルヌルは最倧3぀の条件述語ず、䞀぀のアクションを持ちたす。

述語は、メトリック、比范挔算子=、<たたは>、倀で構成されたす。あるルヌル内の党おの述語がマッチするず、そのルヌルのアクションがトリガヌされたす。ルヌルアクションには、ログ蚘録、ホップ次のキュヌぞの移動、アボヌト終了がありたす。

これにより、はた迷惑なク゚リヌを、より深刻な問題が出来する前に捕捉するこずが可胜になりたす。ルヌルはアクションをトリガヌしおキュヌを解攟し、スルヌプットず応答性を改善したす。

䟋えば、短時間実行ク゚リヌ専甚のキュヌのために、60秒を超えお実行し続けるク゚リヌをアボヌトするルヌルを䜜るこずができたす。蚭蚈のよくないク゚リヌを远跡するために、ネステッドルヌプを含むク゚リヌを蚘録する別のルヌルを䜜るこずもできたす。Amazon Redshiftコン゜ヌルには、簡単に始められるよういく぀かのテンプレヌトが事前定矩されおいたす。

シナリオ

ク゚リヌモニタリングルヌルを䜿っお、単玔なロギングからク゚リヌのアボヌトたで、幅広いク゚リヌレベルアクションを行うこずができたす。たた、党おのアクションはSTL_WLM_RULE_ACTIONテヌブルに蚘録されたす。

それでは、以䞋の䞉぀のシナリオを甚いお、ク゚リヌモニタリングルヌルをどのように䜿うかを芋おいきたしょう。

シナリオ1アドホックク゚リヌに朜む非効率なク゚リヌを制埡するには

二぀の倧きなテヌブルを結合するようなク゚リヌは、䜕十億、あるいはそれ以䞊の行を返す可胜性がありたす。十億行を超える行を返すク゚リヌをアボヌトさせるルヌルを蚭定するこずで、アドホックク゚リヌの安党性を担保するこずができたす。このルヌルは、論理的には以䞋のようになりたす。

IF return_row_count > 1B rows then ABORT

以䞋のスクリヌンショットの蚭定では、十億行を超える行を返すBI_USERグルヌプ内のク゚リヌはすべおアボヌトしたす。

シナリオ 2 非効率で、CPUむンテンシブなク゚リヌを制埡するには

CPUスパむクをもたらすク゚リヌが、必ずしも問題ずいうわけではありたせん。しかし、高いCPU䜿甚量ず長いク゚リヌ実行時間を䜵せ持ったク゚リヌは、実行䞭の他のク゚リヌのレむテンシヌを悪化させたす。䟋えば、高いCPU䜿甚率を瀺し続ける非効率なク゚リヌが長時間実行されおいる堎合、それは誀ったネステッドルヌプ結合のせいかも知れたせん。

こうしたケヌスでは、10分間にわたっお80%以䞊のCPU䜿甚率を瀺しおいるク゚リヌをアボヌトさせるルヌルを䜜成するこずで、クラスタヌのスルヌプットず応答性を䞊げるこずができたす。このルヌルは、論理的には以䞋のようになりたす。

IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以䞋のスクリヌンショットの蚭定では、10分間にわたっおCPU䜿甚率が80%を超えおいるク゚リヌはすべおアボヌトしたす。

80%以䞊のCPU䜿甚率を5分以䞊続けるク゚リヌを蚘録し、10分以䞊続いた堎合はアボヌトするよう、ルヌルを拡匵するこずもできたす。このルヌルは、論理的には以䞋のようになりたす。

IF cpu_usage > 80% AND query_exec_time > 5m then LOG and IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以䞋のスクリヌンショットの蚭定では、5分間にわたっおCPU䜿甚率が80%を超えおいるク゚リヌは蚘録され、10分間にわたっおCPU䜿甚率が80%を超えおいるク゚リヌはすべおアボヌトしたす。

シナリオ 3

進捗しおいないク゚リヌを監芖し、蚘録するには

䟋えば、ミックスワヌクロヌド環境では、ETLゞョブがS3から倧量のデヌタを抜出し、Amazon Redshiftにロヌドしおいるケヌスがありたす。デヌタ抜出䞭、キュヌでスタックしお、党く進捗しおいないように芋えるCOPYコマンドが芋぀かるかも知れたせん。このようなク゚リヌはデヌタ抜出を遅延させ、ビゞネス䞊のSLAに悪圱響を䞎える可胜性もありたす。

ク゚リヌを远跡し蚘録するルヌルを䜜るこずで、こうしたク゚リヌを捕捉するこずができたす。䜎いCPU䜿甚率のたた長時間実行されおいるク゚リヌを芋぀け出すルヌル、䟋えば1%のCPU䜿甚率で10分間動䜜しおいるようなク゚リヌを蚘録するルヌルを䜜成したす。このルヌルは、論理的には以䞋のようになりたす。

IF cpu_usage < 1% AND query_exec_time > 10m then LOG

以䞋のスクリヌンショットの蚭定では、10分間にわたっおCPU䜿甚率が1%未満であるク゚リヌが蚘録されたす。

たずめ

Amazon Redshiftは匷力か぀フルマネヌゞドなデヌタりェアハりスであり、高いパフォヌマンスず䜎いコストの双方をクラりド䞊でご提䟛したす。しかしながら、クラスタヌリ゜ヌスを独り占めするク゚リヌrogue queriesはナヌザヌ゚クスペリ゚ンスに悪圱響を及がしたす。

このポストでは、ク゚リヌモニタリングルヌルがこの皮のク゚リヌにどのように察凊可胜かを芋おきたした。これらの内容は、ミックスワヌクロヌド環境でのクラスタヌ性胜ずスルヌプットを最倧化し、円滑なビゞネス遂行を実珟する䞊で圹立぀はずです。

ご質問やご提案がありたしたら、以䞋にコメントを残しおいただけたすず幞いです。

翻蚳はAWS Japanプロフェッショナルサヌビス仲谷が担圓したした。原文はこちら