« 2016年11 月 | メイン | 2017年1 月 »
こんにちは。テクニカルトレーナーの鬼形です。AWS Black Belt オンラインセミナー1月の配信についてご案内させて頂きます。2017年もAWS Black Belt Online Seminarをどうぞ宜しくお願い致します！
1月の開催予定
ソリューションカット
1月24日(火) 12:00-13:00 AWS上のJenkins活用方法
1月31日(火) 12:00-13:00 AWSで実現するDisaster Recovery
サービスカット
1月11日(水) 18:00-19:00 AWS Elastic Beanstalk
1月18日(水) 18:00-19:00 Amazon Lightsail
1月25日(水) 18:00-19:00 AWS Storage Gateway
お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。
皆様、こんにちは。セキュリティ ソリューション アーキテクトの桐山です。
2016年も師走に入り、いよいよ一年が終わろうとしているこの時期、該当の方は初めての AWS Certificate Manager (ACM) 証明書の自動更新を迎えることになります！
そこで今回はACM 証明書自動更新時の注意点を以下に投稿いたします。
滅多にない事ですが、悪条件が重なれば最悪の場合、証明書が失効して皆様の Web サイトが突然不通になるかもしれませんので、ACM ご利用の方は是非ご覧ください。
ACM について
ACM とは、CloudFront や Elastic Load Balancing (ELB) などの AWS サービスで使用する SSL/TLS 証明書の管理を行えるマネージドサービスです。
2016/1/21に米国東部 (バージニア北部) リージョンでサービスを開始し、東京リージョンでは2016年5月から提供が始まりました。
証明書を CloudFront で利用する場合は、必ず米国東部 (バージニア北部) リージョンの ACM になっています。
よって、ACM サービス開始当時から CloudFront にてご利用いただいている方は、利用開始からもうすぐ一年が経つことになります。
ACM 証明書更新プロセス
SSL/TLS 証明書は通常有効期限が設定されており、有効期限が切れる前に更新を行う必要があります。
ACM での証明書の有効期限は発行日から13か月後です。そして、有効期限の60日前から更新プロセスが開始されます。
たとえば、ACM サービス開始日 (2016年1月21日) からご利用いただいている方は、有効期限がその13か月後 (2017年2月21日) であり、更新プロセスは有効期限の約60日前 (2016年12月後半) から始まります。
皆様がお使いの ACM 証明書の有効期限がいつから開始されたかは、AWS 管理コンソールから確認できます。
自動更新プロセス適用条件
通常、ACM では自動で証明書更新が完了いたします。ご利用者側で証明書をインストールしたりソフトウェアを更新いただく必要はありません。自動更新による通信の瞬断もありません。証明書の保守管理が理由でWebサイトなどを一時停止する必要無いのは便利ですね。
この自動更新が完了するには以下の条件を全て満たす必要があります。
これらの条件に当てはまらない場合は自動更新が失敗することになります。
もし自動更新が失敗した場合は?
証明書に記載されているドメインのオーナーに対して、証明書更新方法を記載した検証用メールを送付いたします。メール内容を確認し、手動で更新してください。
検証用メールの宛先は、利用者が証明書発行の際に使用したメールアドレスです。具体的には、WHOIS 情報に記載のメールアドレスと、admin@、administrator@、hostmaster@、webmaster@、および postmaster@です。
この検証用メールを受け取れないとなると、手動更新もできずに知らぬ間に証明書の有効期限が切れることになるかもしれません。Web サイトの不通など最悪の事態に陥らないように、ACM 証明書申請時に使用していたメールアドレスや環境がお手元にあることをご確認ください。WHOIS 上のメールアドレスが変更になっていたり、MX レコードが削除されていたりしないか要注意です。
検証用メールによる方法でも更新できなかった場合、その旨を AWS アカウントに登録されているメールアドレス宛てに通知いたします。
ここまで書きましたが、もちろん大前提としてこれらは「現在使用されている証明書」についての話です。どの AWS リソースにも関連づいていない場合は使用中ではないので、証明書の更新プロセスはそもそも行われません。
それでは皆様、これからも快適なACMライフをお楽しみください！
本ブログ執筆にあたり、AWS サポートの山下さん、長谷川(はせじゅん)さんに多大なご協力をいただきました。あらためて感謝申し上げます。
- セキュリティ ソリューション アーキテクト 桐山 隼人(@hkiriyam1)
本日(訳者注:2016年11月29日)、AWS はAWS Organizations の提供を開始しました。組織内の全ての AWS アカウントを一元管理する新しい方法です。AWS アカウントを組織単位(OU)と呼ばれるグループに分け、ポリシーを組織単位やアカウント毎に適用できます。たとえば、アプリケーション、環境、チーム、その他ビジネスにとって意味のあるグループ毎に、AWS アカウントを組織化できるようになります。
Organizations があれば、複数のAWS アカウントのセキュリティポリシーをそれぞれ管理する必要がなくなります。Organizations が提供される前は、もし複数の AWS アカウントがある場合、それら AWS アカウントにおけるユーザーに、各 AWS サービスに対して適切なアクセス権を 付与する必要がありました。それぞれのアカウント上でセキュリティ設定を個別に行うか、各アカウントに繰り返し設定を適用するためのカスタムスクリプトを書かなければなりませんでした。それにも関わらず、それら AWS アカウントにおけるユーザーが管理者権限を持っていれば、定義された権限をバイパスできてしまいました。Organizations では、組織全体、組織単位(OU)ごと、もしくは、個々のアカウントごとにポリシーを構成し適用できるサービスコントロールポリシー (SCP) を提供します。このブログ投稿で Organizations の使い方の例を見ていきましょう。
たとえば、ヘルスケア業界や金融業界の規制に準拠したソフトウェアを AWS 上にデプロイし稼働させたいとしましょう。、ISO や SOC などの規制によると、AWS 上で保護されたヘルスケア情報を処理し、保管し、転送するためには、指定された AWS サービスだけを使用するようにソフトウェアを制限しなければなりません。Organizations があれば、そのような規制が許可する AWS サービスだけにアクセスするようソフトウェアを制限できます。SCP は組織内の全てのアカウントに渡って AWS サービスへのアクセスを制限し、SCP が効いている AWS アカウントにおいてどんなユーザーであってもポリシーの上書きはできません。新しい組織を作る時は、マスターアカウント となるアカウントから開始する必要があります。マスターアカウントとはその組織を所有し、全ての管理者用アクションが適用されます。マスターアカウントは、SCP やアカウントグループの設定から、メンバーアカウントと呼ばれる自分以外の AWS アカウントの支払い方法まで定義できます。一括請求と同様、マスターアカウントは、メンバーアカウントの AWS 請求書を支払うアカウントでもあるので、賢明に選択してください。
この投稿では全ての例において AWS CLI を使用しますが、Organizations では AWS 管理コンソールや AWS SDK も使用可能です。
次の例では、create-organization という API を使って、Full_Control モードで新しい組織を作成します。
server:~$ aws organizations create-organization --mode FULL_CONTROL
結果は以下です。
{
"organization": {
"availablePolicyTypes": [
{
"status": "ENABLED",
"type": "service_control_policy"
}
],
"masterAccountId": "000000000001",
"masterAccountArn": "arn:aws:organizations::000000000001:account/o-1234567890/000000000001",
"mode": "FULL_CONTROL",
"masterAccountEmail": "[email protected]",
"id": "o-1234567890",
"arn": "arn:aws:organizations::000000000001:organization/o-1234567890"
}
}
この例では、この組織にセキュリティポリシーを設定するため、Full_Control モードで作成しました。組織の作成には Full_Control モードか Billing モードという二つの異なるモードがあります。Full_Control モードは Billing モードができる全てのことができる上に、サービスコントロールポリシーを適用する機能があります。
注意： 一括請求を現在ご利用の場合、一括請求ファミリーは AWS Organizations に自動的に Billing モードにて移行されます。一括請求と同様、メンバーアカウントで発生した全ての費用がマスターアカウントに請求されます。
作成された組織にメンバーを追加するには、組織の中に新規 AWS アカウントを作成するか、既存アカウントを招待します。
Organizations は組織内に新しい AWS アカウントをプログラムで作成する API を提供します。email アドレスとアカウント名さえ指定すれば、残りの情報 (住所など) はマスターアカウントから継承します。
AWS CLI を使って新しいアカウントを作成するには、新しいアカウントに割り当てたい email アドレスとアカウント名を引数に create-account を呼びます。
server:~$ aws organizations create-account --account-name DataIngestion --email [email protected]
AWS アカウント作成は非同期処理で、 create-account は createAccountStatus の応答を返します:
{
"createAccountStatus": {
"requestedTimestamp": 1479783743.401,
"state": "IN_PROGRESS",
"id": "car-12345555555555555555555555556789",
"accountName": "DataIngestion"
}
}
createAccountStatus id を引数にして describe-create-account-status を呼べば、その AWS アカウントがいつ使用可能になるか分かります。アカウントは一般的に数分以内で使用可能になります。
組織に既存 AWS アカウントを招待することもできます。組織に AWS アカウントを招待するためには、AWS アカウント ID か email アドレスが必要です。
AWS CLI でのコマンドは invite-account-to-organization です。
server:~$ aws organizations invite-account-to-organization --target [email protected],type=EMAIL
このコマンドは、送られたリクエストに関する全ての情報を含む handshake オブジェクトを返します。この例は、 [email protected] のアカウントに、 id 1234567890 の組織に参加するように送られたリクエストです。
{
"handshake": {
"id": "h-77888888888888888888888888888777",
"state": "OPEN",
"resources": [
{
"type": "ORGANIZATION",
"resources": [
{
"type": "MASTER_EMAIL",
"value": "[email protected]"
},
{
"type": "MASTER_NAME",
"value": "Example Corp"
},
{
"type": "ORGANIZATION_MODE",
"value": "FULL"
}
],
"value": "o-1234567890"
},
{
"type": "EMAIL",
"value": "[email protected]"
}
],
"parties": [
{
"type": "EMAIL",
"id": "[email protected]"
},
{
"type": "ORGANIZATION",
"id": "1234567890"
}
],
"action": "invite",
"requestedTimestamp": 1479784006.008,
"expirationTimestamp": 1481080006.008,
"arn": "arn:aws:organizations::000000000001:handshake/o-1234567890/invite/h-77888888888888888888888888888777"
}
}
上記のコマンドはアカウント所有者に、組織に参加するように招待された旨を通知する email が送られます。招待された AWS アカウントの所有者が、その組織へ参加する条件に同意した場合は、email 中のリンクからリクエストを承諾するか、 accept-handshake-request を呼び出します。
現時点で、この組織には DataIngestion and DataProcessing という二つのメンバーアカウントが追加されています。マスターアカウントは [email protected] です。デフォルトでは、アカウントは組織のルート直下に配置されます。次の図に示されている通り、ルートとは組織構造のベースで、全ての組織単位(OU)やアカウントはそこから分岐します。
list-accounts という CLI コマンドで、組織内の全てのアカウントを参照できます。
server:~$ aws organizations list-accounts
list-accounts コマンドは、アカウント一覧とどのように組織に参加したかの詳細を返します。マスターアカウントはメンバーアカウントと一緒の組織であることに注意してください。
{
"accounts": [
{
"status": "ACTIVE",
"name": "DataIngestion",
"joinedMethod": "CREATED",
"joinedTimestamp": 1479784102.074,
"id": "200000000001",
"arn": "arn:aws:organizations::000000000001:account/o-1234567890/200000000001"
},
{
"status": "ACTIVE",
"name": " DataProcessing ",
"joinedMethod": "INVITED",
"joinedTimestamp": 1479784102.074,
"id": "200000000002",
"arn": "arn:aws:organizations::000000000001:account/o-1234567890/200000000002"
},
{
"status": "ACTIVE",
"name": "Example Corp",
"joinedMethod": "INVITED",
"joinedTimestamp": 1479783034.579,
"id": "000000000001",
"arn": "arn:aws:organizations::000000000001:account/o-1234567890/000000000001"
}
]
}
サービスコントロールポリシー (SCP) によって、AWS アカウントがどの AWS サービスや API にアクセスできるかを統制できます。SCP はアカウント内の全てのエンティティ (ルートユーザー、AWS Identity and Access Management (IAM) ユーザー、IAM ロール) に適用されます。この例では、7つの AWS サービスにのみアクセスを許可する SCP を設定しようとしています。
SCP は IAM ポリシーと連携して動作することに注意してください。この SCP は一連のサービスへのアクセスを許可しますが、ユーザーに対して更に制限された IAM ポリシーを設定することも可能です。AWS は最も制限されたポリシーの組み合わせを実施します。
SCP の適用のされ方は、マスターアカウントとその他のアカウントで異なります。組織から自分自身をロックアウトしないように、組織に適用されるSCP はマスターアカウントには適用されません。
この例では、与えられた一連のサービスだけにアクセスさせたいので、リストされたサービスだけにアクセス権を与える Allow ポリシーを作成します。次のポリシーは、Amazon DynamoDB, Amazon RDS, Amazon EC2, Amazon S3, Amazon EMR, Amazon Glacier, そして Elastic Load Balancing へのアクセスを許可します。
server:~$ aws organizations create-policy --name example-prod-policy --type service_control_policy --description "All services allowed by regulation policy." --content file://./Regulation-Policy.json
Regulation-Policy.json の中身は以下の通りです。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"dynamodb:*","rds:*","ec2:*","s3:*","elasticmapreduce:*",
"glacier:*","elasticloadbalancing:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
SCP は IAM ポリシーと同じ構造に従います。この例は Allow ポリシーですが、SCP は特定のサービスや API へのアクセスを制限する Deny ポリシーも同様に記述できます。
CLI によって組織の SCP を作成するには、以前の SCP を Regulation-Policy.json に保存し、 create-policy を呼びます。
server:~$ aws organizations create-policy --name example-prod-policy --type service_control_policy --description "All services allowed for regulation policy." --content file://./Regulation-Policy.json
The create-policy コマンドは作成されたポリシーを返します。組織の要素に適用する時のために、policy id を保存しておいてください。
{
"policy": {
"content": "{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Action\": [\n \"dynamodb: *\",\"rds: *\",\"ec2: *\",\"s3: *\",\"elasticmapreduce: *\",\"glacier: *\",\"elasticloadbalancing: *\"\n],\n \"Effect\": \"Allow\",\n\"Resource\": \"*\"\n}\n ]\n}\n",
"policySummary": {
"description": "All services allowed for regulation policy.",
"type": "service_control_policy",
"id": "p-yyy12346",
"arn": "arn:aws:organizations:: 000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
"name": "example-prod-policy"
}
}
}
ポリシーを作成した後は、組織のエンティティにそれをアタッチします。ルートアカウントにも、組織単位(OU)にも個々のアカウントにもアタッチできます。アカウントは組織ツリーの上位にある全てのポリシーを継承します。ここでは簡単のため、 example-prod-policy に定義されている Example Corp. Prod SCP を組織全体に適用するためルートにポリシーを適用しましょう。ルートは組織ツリーの最上位要素のため、ツリーに適用されたポリシーは組織の全メンバーに適用されます。
CLI を使う場合、最初に list-roots を呼んで、ルート id を取得する必要があります。ルート id を取得したら、 attach-policy を呼んで、 ( create-policy の応答で得られた) example-prod-policy id とルート id を渡します。
server:~$ aws organizations list-roots
{
"roots": [
{
"policyTypes": [
{
"status": "ENABLED",
"type": "service_control_policy"
}
],
"id": "r-4444",
"arn": "arn:aws:organizations::000000000001:root/o-1234567890/r-4444",
"name": "Root"
}
]
}
server:~$ aws organizations attach-policy --target-id r-4444 --policy-id p-yyy12346
それではルート上のポリシーを確認してみましょう。ルート上で list-policies-for-target を呼び出すと、組織のルートにアタッチされている全てのポリシーが表示されます。
server:~$ aws organizations list-policies-for-target --target-id r-4444 --filter service_control_policy
{
"policies": [
{
"awsManaged": false,
"description": "All services allowed by regulation policy.",
"type": "service_control_policy",
"id": " p-yyy12346",
"arn": "arn:aws:organizations::000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
"name": "example-prod-policy"
},
{
"awsManaged": true,
"description": "Allows access to every operation",
"type": "service_control_policy",
"id": "p-FullAWSAccess",
"arn": "arn:aws:organizations::aws:policy/service_control_policy/p-FullAWSAccess",
"name": "FullAWSAccess"
}
]
}
ルート上での list-policies-for-target から、example-prod-policy と FullAWSAccess という二つのポリシーが返されました。FullAWSAccess は AWS 管理ポリシーで、組織内で全ての要素にデフォルトで適用されています。組織を作ると全てのルート、組織単位(OU)、アカウントは FullAWSAccess を有していて、AWS 内の全てのリソース (*:*) にアクセスできます。
もし Example Corp. Prod SCP の特定のサービスにアクセスを制限したい場合は、 FullAWSAccess を削除しなければなりません。上記の例では、Organizations はルートアカウントに、FullAWSAccess ポリシー かつ Example Corp. Prod SCP で許可されたサービス、つまり 全てのAWS のサービスアクセスへのアクセスを許可しています。Example Corp. Prod SCP で意図した制限をかけたい場合は FullAWSAccess を削除する必要があります。CLI ではこれを以下のように行います。
aws organizations detach-policy --policy-id p-FullAWSAccess --target-id r-4444
ルートにアタッチされているのは example-prod-policy ただ一つになったことが確認できます。
aws organizations list-policies-for-target --target-id r-4444 --filter service_control_policy
{
"policies": [
{
"awsManaged": false,
"description": "All services allowed by regulation policy.",
"type": "service_control_policy",
"id": "p-yyy12346",
"arn": "arn:aws:organizations:: 000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
"name": "example-prod-policy"
}
]
}
これで、 組織内の全てのアカウントからアクセスを Example Corp の規制に準拠したサービスに制限することで、保護を強化することできました。
組織を更に細分化したなら、組織単位とポリシーを追加することもできます。たとえば、いくつかの AWS アカウントはヘルスケア情報を保護するために使用されないかもしれず、その場合、制限された SCP は必要ないことになります。
たとえば、業務上異なる AWS サービスを試す必要がある開発チームがいるとします。この場合、規制された顧客情報にアクセスできるアカウントよりも、これらのアカウントの統制を緩くすることになるでしょう。Organizations があれば、たとえば本番環境で稼働させる医療ソフトウェアを扱う組織単位(OU)を作成する一方、開発者アカウントを有する組織単位(OU)も作成することができます。そうすれば、それぞれの組織単位(OU)に異なるセキュリティの制限を適用できます。
次の図では Developer Research 組織単位(OU)に3つの開発者アカウントが示されています。規制による保護が求められる元々の2つのアカウントは Production 組織単位(OU)にいます。 Example Corp. Prod Policy をルートからデタッチし、代わりにそれをProduction 組織単位(OU)にアタッチしました。最後に、規制と無関係な制限は、新しい Company ポリシーに配置することでルートレベルで引き続き有効となっています。
上の図では、 Developer Research 組織単位(OU)にあるアカウントは依然ルート配下にあるため、Company policy が適用されています。 Production 組織単位(OU)にあるアカウントは、Company policy と Example Corp. Prod Policy の両方の SCP が有効です。IAM ポリシー同様、SCPも2つのポリシーのより限定された共通部分がアカウントに適用されます。もし Company policy SCPが Glacier, EMR, S3, EC2, RDS, Dynamo, Amazon Kinesis, AWS Lambda, そして Amazon Redshift へのアクセスを許可していたら、 Production 組織単位(OU)のアカウントに適用されるポリシーは次の図で示される共通部分になるでしょう。
Production 組織単位(OU)のアカウントは、Company policy SCP と Example Corp. Prod Policy SCP の両方が適用されます。2つのポリシーの共通部分が適用されるので、これらのアカウントは DynamoDB, Glacier, EMR, RDS, EC2, そして S3 へのアクセスできます。Redshift, Lambda, 及び Kinesis は Example Corp. Prod Policy SCP には含まれていないので、Production 組織単位(OU)のアカウントはそれらサービスへのアクセスが許可されません。
ポリシーの適用について要約すると、全ての要素 (ルートアカウント、 組織単位(OU)、 アカウント) はデフォルトで FullAWSAccess (*:*) を持ちます。複数の SCP が同じ要素に適用されていたら、Organizations はそれらを結合します。組織ツリー内の複数の要素に渡ってポリシーが継承されるとき、Organizations はそれら SCP の共通項を取ります。最後に、マスターアカウントは独自の保護機能を有しており、マスターアカウントに直接アタッチされた SCP のみ、そのアクセス権を変更できます。
AWS Organizations では1つのマスターアカウントから複数の AWS アカウントを簡単に管理できます。アカウントを組織単位にグループ化し、アプリケーション、環境、チーム、その他ビジネスにとって意味のあるグループ毎に、アカウントを管理できるようになります。SCP は複数のアカウントに一度にポリシーを適用できる機能を提供します。
詳細については、AWS Organizations のホームページをご覧になり、AWS Organizations のプレビューに今すぐ登録してください。 AWS re：Invent 2016に参加している場合は、11月30日水曜日、午前11時のセッション SAC323 – NEW SERVICE: Centrally Manage Multiple AWS Accounts with AWS Organizations に参加することもできます。
– Caitlyn
AWSソリューションアーキテクトの篠原英治(@shinodogg)です。
2016年12月5日(前夜祭)・6日(Day1)・7日(Day2)に、Infinity Ventures Summit と共催で、約100名のCTOの皆さまにお集まりいただきまして、京都で2日間のカンファレンスを開催しました！
■ Day0
■ Day1
■ Day2
■ #CTONight リンク集
本日私達はBloxという新しいオープンソースプロジェクトをAmazon ECSチームから発表しました。これによって、ECS上にカスタムスケジューラや他のツールを開発することができます。Bloxの目標は、カスタムスケジューラ、ダッシュボード、その他の拡張を作ることをシンプルにするためのツールを提供することで、皆さんの特定のユースケースの要件に合わせることができます。
ECSは先日、イベントストリームが利用可能になったこともアナウンスしており、これによってECSコンテナインスタンスとタスクの状態変化が[cloudwatch_events]に送られます。スケジュールワークフローを開発するお客様はしばしばECSクラスタで生成されたイベントを受け取り、この状態を手元に保存して、ローカルのクラスタの状態を使って操作を行います。Bloxにはこの機能とローカルのクラスタの状態をREST APIで提供するcluster-state-serviceが含まれます。BloxはECSクラスタの現在のリソース状況を必要とするカスタムスケジューラや処理を開発したり、クラスタのイベントに応じてアクションをしたい開発者をターゲットとしています。
Bloxは、ECSクラスタ上のすべてのコンテナインスタンスにおいてそれぞれ1つだけのタスクを起動できるdaemon-schedulerも含まれています。このスケジューラは新しいコンテナインスタンスがクラスタの参加したかを監視していて、そこにタスクを配置します。Bloxのdaemon-schedulerによって、ログエージェントやメトリクス収集エージェントの様なタスクをECSクラスタ上で起動できるようになります。
私達はBloxをオープンソースソフトウェアとしてリリースできて大変うれしく思っており、ECSの周辺ツールのエコシステムを開発していく計画があります。もしBloxを使ったり貢献したりすることに興味があれば、BloxのGitHubレポジトリをご覧ください。機能要望の数を見続けていて、ロードマップのために評価しています。ぜひGitHubのレポジトリに参加して、改善点の発見や優先度づけにご協力下さい。
Bloxをとりあえず初めてみたい方には、ローカルのDocker環境にフレームワークをデプロイすることをお勧めします。Bloxはローカル環境へのデプロイを可能にするDocker Composeファイルを提供しています。これによって、cluster-state-serviceを使ったカスタムスケジューラの開発を始めることができます。
こちらがローカルで実行した時のBloxのアーキテクチャです:
BloxはCloudWatch Eventsで送られるECSイベントストリームに依存しています。Bloxを使うためには、SQSキューを作成し、ECSイベントがこのSQSキューに送られる様にCloudWatchを設定する必要があります。Bloxは既に構成済のAWS CloudFormationテンプレートを提供していて、必要なAWSのコンポーネントをデプロイし設定することができます。BloxのレポジトリからCloudFormationテンプレートを持ってきたら、AWS CLIを使って以下のコマンドを実行します:
$ aws --region cloudformation create-stack --stack-name BloxLocal --template-body file://cloudformation_template.json
数分すると、CloudFormationテンプレートでのCloudWatch EventsとSQSキューの設定が終わり、Bloxをデプロイする準備が整います。
次に、BloxのレポジトリからDocker Composeファイルをダウンロードします。Bloxを起動する前に、先に以下の様にdocker-compose.ymlを更新する必要があります:
docker-compose.ymlを更新したら、以下のコマンドを使ってローカルのDocker環境にBloxのコンテナを起動することができます:
# From the folder where you downloaded docker-compose.yml
$ docker-compose up –d
$ docker-compose ps
出力として、Bloxのcluster-state-service、daemon-scheduler、そしてetcdストレージを確認できます:
Name Command State Ports ----------------------------------------------------------------------------- etcd_1 /usr/local/bin/etcd --data ... Up 2379/tcp, 2380/tcp scheduler_1 --bind 0.0.0.0:2000 --css- ... Up 0.0.0.0:2000->2000/tcp css_1 --bind 0.0.0.0:3000 --etcd ... Up 3000/tcp
これでBloxのローカルインストールは完了です。http://localhost:2000/でScheduler APIを利用開始できます。
daemon-schedulerは以下のコンセプトを持っています:
もしECSクラスタを持っていなければ、Create Clusterのガイドに従って下さい。
ECSクラスタにタスクを起動するためには、ECSにタスク定義を登録する必要があります。もしまだなければ、以下のタスク定義を使うことができます。
$ cat > /tmp/nginx.json << EOF
{
"family": "nginx",
"containerDefinitions": [{
"name": "nginx",
"image": "nginx",
"cpu": 1024,
"memory": 128
} ]
}
EOF
$ aws ecs register-task-definition --cli-input-json file:///tmp/nginx.json
nginxタスク定義のARNを調べておきます。次のステップで必要になります。
$ aws ecs list-task-definitions
{
"taskDefinitionArns": [
"arn:aws:ecs:us-west-2::task-definition/nginx:1"
]
}
daemon-schedulerを使ってデーモンのワークロードを起動
この例では、Bloxが提供するスケジューラとのやりとりのためのdemo-cliを使っています。daemon-schedulerのAPIの説明はBloxのGitHubレポジトリをご覧ください。
以下のコマンドのクラスタ名とタスク定義ARNを置き換えて、environmentを作成します:
./blox-create-environment.py --environment TestEnvironment --cluster --task-definition
サンプル出力はこちら:
{
"items": [
{
"deploymentToken": "17fb6b8b-abf3-4e7b-b9f4-fdb431d53887",
"health": "healthy",
"name": "releaseenvironment",
"instanceGroup": {
"cluster": "arn:aws:ecs:us-west-2:203719379804:cluster/BloxTestCluster-1123-2"
}
}
]
}
environmentの作成に成功すると、daemon-schedulerのレスポンスの中には次のステップで使われるdeploymentTokenが含まれます。
このenvironmentを実際にECSクラスタ上に実現するために、deployment操作をする必要があります:
./blox-create-deployment.py --environment TestEnvironment --deploymentToken
deploymentを作成することで、スケジューラはenvironmentに設定されたタスク定義をクラスタ内のすべてのコンテナインスタンスに起動します。そうしたら、ECSコンソールに行って、コンテナインスタンス上で実行されているタスクを確認することができます。これで、daemon-schedulerを使って無事にECSクラスタにデーモンのワークロードを起動することができました。
BloxはAWS上にもデプロイ可能です。BloxのCloudFormationテンプレートを使って作成します:
このBloxのデプロイをすることで、アカウントに紐付いているECSクラスタの管理に使うことができます。
このオプションでの設定方法については、GitHubレポジトリの説明をご覧ください。
Bloxは本日から利用可能です。詳細は、GitHubレポジトリ内のドキュメントをご覧下さい。
原文: Introducing Blox from Amazon EC2 Container Service (翻訳: SA岩永)
著者 Zach Christopherson は Amazon Redshift チームのシニアデータベースエンジニアです。
Part 1: Preamble, Prerequisites, and Prioritization（序文、事前準備、優先順位付け）
Part 2: Distribution Styles and Distribution Keys（分散スタイルと分散キー）
Part 3: Compound and Interleaved Sort Keys （Compound と Interleaved ソートキー）
Part 4: Compression Encodings（圧縮エンコーディング）
Part 5: Table Data Durability（テーブルデータの永続性）［本稿］
「Amazon Redshift テーブル設計詳細ガイド」の最終回となるPart 5では、Amazon Redshift環境のパフォーマンスを更に引き出すための2つのシンプルなテーブルデータの永続性に関するプロパティの使い方について説明します。
自動バックアップでは、Amazon Redshiftは増分の変更ブロックを高頻度でAmazon S3にプッシュします。これらの自動バックアップは時間の閾値または変更されたブロックによりトリガーされます。このアプローチによりスナップショットやテーブルレベルのリストア操作などのリカバリ機能が可能となっています。
一般的に自動バックアップの実際の処理コストは大きなものではありません。しかし、データブロックをS3に転送するため、継続的に大規模なCOPYやUNLOADを実行するワークロードに関するS3へのスループットに影響を与える可能性があります。このような自動バックアップの処理コストを抑制するために、S3に格納し耐久性を高めたいデータを含まないテーブルに対しては「BACKUP NO」テーブルプロパティを使用することができます。このプロパティを使用できるのは下記のようなテーブルです:
我々は下記の2点を実現するためにこのプロパティを使用します:
注: TEMPORARYとして定義されたテーブル（一時テーブル）は、それらが作成されたセッションの終了時にクリーンアップされるため、デフォルトでこのプロパティを継承しています。
デフォルトでは、マルチノード構成のAmazon Redshiftは自動的にクラスタ内の別ノードが持つテーブルデータの冗長コピーを保持するため、複数のディスクやノードの障害に耐性を持ちます。全ての同期データレプリケーションと同様に、このプロセスにはオーバーヘッドがあります。一時テーブルに関しては、システムがそれらのテーブル内のデータは一時的なものであると見なしているため、レプリケーションは実行されません。更に、一時テーブル内のブロックは自動バックアップをトリガーする閾値にはカウントされません。従って、一時的なデータに対して一時テーブルを使用することで、BACKUP NOオプションを使用した場合と同様に、バックアッププロセスの起動を回避し自動バックアップが完了するまでの速度を向上することができます。
一時テーブルのデータはレプリケートされていないので、一時テーブルデータをコミットするトランザクションは永続テーブルに対して実行するよりも処理コストが低くなります。つまり、適切な場面で一時テーブルを活用することで、クラスタのオーバーヘッドを大幅に抑制することができると言えます。例として、テーブルデータが単一のセッション内でのみアクセス可能であればよい場合や、本質的に一時的なデータである場合が挙げられます。
下記のクエリを使用して、クラスタ内でこれらのテーブルプロパティのいずれかが適用されているテーブルを特定することができます。
SELECT DISTINCT id, name, temp, backup FROM stv_tbl_perm WHERE backup=0 ORDER BY 1;
あなたの環境のデータの永続性や保存の要件次第では、これらのオプションを使用することは適切ではないかもしれませんが、それでも問題ありません。このブログシリーズを通して説明してきた内容の中では、今回のような細部の最適化はクラスタ全体のパフォーマンス向上への貢献度は小さいかもしれません。しかし、上から下まで最適化されている環境においては、これがパフォーマンス向上のために紹介できる最後のテーブルデザインコンセプトとなります。
Part 1: Preamble, Prerequisites, and Prioritization（序文、事前準備、優先順位付け）
Part 2: Distribution Styles and Distribution Keys（分散スタイルと分散キー）
Part 3: Compound and Interleaved Sort Keys （Compound と Interleaved ソートキー）
Part 4: Compression Encodings（圧縮エンコーディング）
Part 5: Table Data Durability（テーブルデータの永続性）［本稿］
Zach Christopherson はパロアルトを拠点とするAWSのシニアデータベースエンジニアです
彼は、全ての業界において、Amazon Redshiftのユーザーが最適なパフォーマンスを得るためのワークロードをチューニングすることを支援しています。 Amazon Redshiftサービスチームの一員として、彼は新しいサービスや既存のサービスの開発にも影響を与えており、貢献しています。休暇の際は妻のメアリーと一緒に新しいレストランにトライし、生まれたばかりの娘ソフィアの世話を楽しんでいます。
※日本語訳はSA岡本が担当しました。原文は Amazon Redshift Engineering’s Advanced Table Design Playbook: Table Data Durability
このブログ内の記事を検索
このブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。 @awscloud_jpをフォロー
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |