From 4befbaba4286edbe04827d1e434b8ca302324a7f Mon Sep 17 00:00:00 2001 From: haruyosh <47203398+haruyosh-amazon@users.noreply.github.com> Date: Sun, 19 Apr 2020 18:48:46 +0900 Subject: [PATCH] Add our Japanese translation (#50) * Adding _index.ja.md * Adding some Japanese translations on running-ec2-workloads-at-scale * Adding some Japanese translations on running-ec2-workloads-at-scale * working * updating * updating * first completion on at-scale workshop * update spot_resilience * update with remaining * update the top page * Modifieng all other feedbacks from the dry-run session * Adding _index.ja.md * Adding some Japanese translations on running-ec2-workloads-at-scale * Adding some Japanese translations on running-ec2-workloads-at-scale * working * updating * updating * first completion on at-scale workshop * update spot_resilience * update with remaining * update the top page * Modifieng all other feedbacks from the dry-run session * updates on .gitignore * Updating to enable the language toggle button and adjusting the content of the top page in Japanese Co-authored-by: Haru T --- .gitignore | 1 + config.toml | 11 +- content/_index.ja.md | 60 ++++++++ .../_index.ja.md | 15 ++ .../architecture.ja.md | 27 ++++ .../before/_index.ja.md | 12 ++ .../before/aws_event/_index.ja.md | 27 ++++ .../before/self_paced/_index.ja.md | 13 ++ .../cleanup.ja.md | 41 ++++++ .../clone_github.ja.md | 33 +++++ .../create_asg.ja.md | 59 ++++++++ .../create_lt.ja.md | 63 +++++++++ .../create_rds.ja.md | 18 +++ .../deploy_app_codedeploy.ja.md | 128 ++++++++++++++++++ .../deploy_lb.ja.md | 75 ++++++++++ .../finished.ja.md | 6 + .../launch_cloudformation.ja.md | 53 ++++++++ .../learn_more.ja.md | 16 +++ .../requirements_notes.ja.md | 19 +++ .../scale_dynamic.ja.md | 16 +++ .../seed_db.ja.md | 20 +++ .../setup_cli.ja.md | 16 +++ .../spot_resilience.ja.md | 91 +++++++++++++ .../stress_ssm.ja.md | 26 ++++ .../using_cloud9.ja.md | 22 +++ 25 files changed, 867 insertions(+), 1 deletion(-) create mode 100644 content/_index.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/_index.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/architecture.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/before/_index.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/before/aws_event/_index.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/before/self_paced/_index.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/cleanup.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/clone_github.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/create_asg.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/create_lt.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/create_rds.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/deploy_app_codedeploy.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/deploy_lb.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/finished.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/launch_cloudformation.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/learn_more.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/requirements_notes.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/scale_dynamic.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/seed_db.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/setup_cli.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/spot_resilience.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/stress_ssm.ja.md create mode 100644 content/running-amazon-ec2-workloads-at-scale/using_cloud9.ja.md diff --git a/.gitignore b/.gitignore index df4f35c2..f5e6a958 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ resources/ node_modules/ **/cdk.out/* +*~ diff --git a/config.toml b/config.toml index 83475035..e984bb82 100644 --- a/config.toml +++ b/config.toml @@ -17,7 +17,7 @@ showVisitedLinks = true description = "EC2 Spot Workshops" disableSearch = false disableAssetsBusting = false -disableLanguageSwitchingButton = true +disableLanguageSwitchingButton = false disableShortcutsTitle = false disableInlineCopyToClipBoard = true @@ -63,3 +63,12 @@ weight = 20 name = " Feedback / Questions?" url = "mailto:ec2-spot-workshops@amazon.com" weight = 30 + + +[languages] + [languages.en] + languageName = "English" + weight = 1 + [languages.ja] + languageName = "Japanese" + weight = 2 diff --git a/content/_index.ja.md b/content/_index.ja.md new file mode 100644 index 00000000..af50d79f --- /dev/null +++ b/content/_index.ja.md @@ -0,0 +1,60 @@ +--- +title: "Amazon EC2 Spot Workshops" +date: 2019-01-06T12:22:13Z +draft: false +--- +# EC2スポットインスタンスワークショップへようこそ！ + +![spot_logo](/images/spotlogo.png ) + +### Overview + +[Amazon EC2 スポットインスタンス](https://aws.amazon.com/ec2/spot/)はAWSの空きキャパシティを活用した、オンデマンドインスタンスに比べて大幅な割引でお使いいただけるEC2インスタンスの購入オプションのひとつです。スポットインスタンスを活用することでAWSの使用コストを最適化し、アプリケーションの対費用スループットを10倍にも高めることができます。 + +EC2サービスがキャパシティを必要とし、戻してもらう必要がある場合、スポットインスタンスは2分前の中断通知とともに中断されることがあります。アプリケーションが耐障害性を持ち、また柔軟であるほど、中断の可能性と大幅な割引という特徴を持つスポットインスタンスを大いに活用することができます。このようなワークロードの例には、ビッグデータ分析、コンテナ化されたアプリケーション、大規模計算(High Performance Computing, HPC), ステートレスなウェブサーバー、CG等のグラフィックレンダリング処理、CI/CDを含むテスト・ビルド処理などが挙げられます。 + +このワークショップサイトでは、EC2スポットインスタンスを活用することのできる様々なシナリオを、ハンズオン形式で自習することができます。ワークショップ内ではそれぞれのワークロードに応じたベストプラクティスを実践形式で紹介しています。 + +左メニューから興味のあるワークショップを選択し、スポットインスタンスの様々な活用シーンに触れてみてください。左メニューには、現時点で日本語化されたワークショップコンテンツのみが表示されています。オリジナルの英語版のコンテンツ一覧はグローバルの[EC2 Spot Instances Workshop](https://ec2spotworkshops.com/)ウェブサイトからアクセス可能です。また以下に示した概要からも、主要なワークショップに進むことができます。 + +{{< card important_workshop + "ja/running-amazon-ec2-workloads-at-scale" + "EC2 Auto Scalingによる自動スケール (日本語版)" + "Amazon-EC2_Auto-Scaling_light-bg.png" +>}} +このワークショップでは、スケールするワークロードに対してコストを最適化しながらAmazon EC2を活用する方法を学びます。 +{{< /card >}} + +{{< card important_workshop + "running_spark_apps_with_emr_on_spot_instances" + "Running Spark apps with EMR on Spot instances (in English, 英語版のみ提供)" + "Amazon-EC2_Instances_light-bg.png" +>}} +In this workshop you will assume the role of a data engineer, tasked with cost optimizing the organization’s +costs for running Spark applications, using Amazon EMR and EC2 Spot Instances. +{{< /card >}} + +{{< card important_workshop + "using_ec2_spot_instances_with_eks" + "Using Spot Instances with EKS (in English, 英語版のみ提供)" + "Amazon-Elastic-Container-Service-for-Kubernetes.svg" +>}} +In this workshop, you learn how to provision, manage, and maintain your Amazon Kubernetes clusters with Amazon EKS at any scale on Spot Instances to architect for optimizations on cost and scale. +{{< /card >}} + +{{< card workshop + "launching_ec2_spot_instances" + "Launching EC2 Spot Instances (in English, 英語版のみ提供)" + "Amazon-EC2_Spot-Instance_light-bg.png" +>}} +In this workshop you will explore different ways of requesting Amazon EC2 Spot requests +and understand how to qualify workloads for EC2 Spot. +{{< /card >}} + + + + + + + + diff --git a/content/running-amazon-ec2-workloads-at-scale/_index.ja.md b/content/running-amazon-ec2-workloads-at-scale/_index.ja.md new file mode 100644 index 00000000..01f5cdab --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/_index.ja.md @@ -0,0 +1,15 @@ +--- +title: "EC2 Auto Scalingによる自動スケール" +date: 2019-01-24T09:05:54Z +weight: 10 +pre: "⁃ " +--- +## はじめに +このワークショップでは、スケールするワークロードに対してコストを最適化しながらAmazon EC2を活用する方法を学びます。具体的には、Amazon EC2スポットインスタンスとEC2 Auto Scalingでの複数インスタンスタイプ・複数購入オプションの構成方法を取り上げます。 + +## シナリオ +あなたは新時代の音楽配信ストリーミングサービスを開発することになりました。これまでに調査した結果、[Koel](https://koel.phanan.net/)を採用するのがベストであることが分かっています。 + +要件には自動デプロイ、それから需要予測と実トラフィックのそれぞれに応じたスケールが含まれ、また費用上限を越えないようにコントロールすることが求められます。 + +性能と費用を最適化するため、[EC2 Auto Scalingの提供する複数インスタンスタイプ・複数購入オプションサポート機能](https://aws.amazon.com/jp/blogs/news/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)を活用します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/architecture.ja.md b/content/running-amazon-ec2-workloads-at-scale/architecture.ja.md new file mode 100644 index 00000000..e4bf765f --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/architecture.ja.md @@ -0,0 +1,27 @@ ++++ +title = "アーキテクチャ" +weight = 20 ++++ + +このワークショップでは次のような項目を取り扱います。 + +* 以下の構成要素を含むAWS Cloud Formationスタック + * ワークショップ用のAmazon Virtual Private Cloud (Amazon VPC) + * 2つのアベイラビリティゾーンに対応する2つのサブネット + * AWS Cloud9開発環境 + * 動作に必要なIAMポリシーおよびIAMロール + * 動作に必要なセキュリティグループ + * EFSファイルシステム + * AWS CodeDeploy用のS3バケット +* Amazon EC2起動テンプレート +* Amazon RDS DBインスタンス +* アプリケーションロードバランサー(ALB), および関連するリスナーとターゲットグループ定義 +* Amazon EC2 Auto Scalingグループ + * スケジュールスケーリング定義 + * 動的スケジューリング定義 +* AWS CodeDeployアプリケーション開発環境 +* AWS System Managerによるrun command(システム負荷生成用) + +今回構築するシステムのアーキテクチャ図を以下に示します。 + +![Architecture Description](/images/running-amazon-ec2-workloads-at-scale/architecture.jpg) diff --git a/content/running-amazon-ec2-workloads-at-scale/before/_index.ja.md b/content/running-amazon-ec2-workloads-at-scale/before/_index.ja.md new file mode 100644 index 00000000..52748708 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/before/_index.ja.md @@ -0,0 +1,12 @@ ++++ +title = "ワークショップの開始" +chapter = true +weight = 25 ++++ + +ではワークショップを始めましょう。参加するワークショップの形式に応じて次のいずれかを参照してください。 + +{{% children %}} + +セットアップが終わったらば[**CloudFormationによるセットアップ**](/ja/running-amazon-ec2-workloads-at-scale/launch_cloudformation.html)に進んでください。 + diff --git a/content/running-amazon-ec2-workloads-at-scale/before/aws_event/_index.ja.md b/content/running-amazon-ec2-workloads-at-scale/before/aws_event/_index.ja.md new file mode 100644 index 00000000..02fbd623 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/before/aws_event/_index.ja.md @@ -0,0 +1,27 @@ ++++ +title = "AWSイベントでの参加" +chapter = true +weight = 5 ++++ + +### AWSイベントに参加している場合 +Running the workshop at an AWS Event + +{{% notice warning %}} +このセクションは、AWS re:InventやAWS SummitなどのAWSイベントでこのワークショップに参加する場合のみ適用されます。AWS社員から特別な指示がある場合のみこちらのセクションに従ってください。そうでない場合は[自習形式、および小規模セミナー形式での参加](/ja/running-amazon-ec2-workloads-at-scale/before/self_paced)に沿って進めてください。 +{{% /notice %}} + +### Login to the AWS Workshop Portal + +If you are at an AWS event, an AWS acccount was created for you to use throughout the workshop. You will need the **Participant Hash** provided to you by the event's organizers. + +1. Connect to the portal by browsing to [https://dashboard.eventengine.run/](https://dashboard.eventengine.run/). +2. Enter the Hash in the text box, and click **Proceed** +3. In the User Dashboard screen, click **AWS Console** +4. In the popup page, click **Open Console** + +You are now logged in to the AWS console in an account that was created for you, and will be available only throughout the workshop run time. +You can now start the workshop by heading to [**CloudFormationによるセットアップ**](/ja/running-amazon-ec2-workloads-at-scale/launch_cloudformation.html) + + +{{% children %}} diff --git a/content/running-amazon-ec2-workloads-at-scale/before/self_paced/_index.ja.md b/content/running-amazon-ec2-workloads-at-scale/before/self_paced/_index.ja.md new file mode 100644 index 00000000..808860e3 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/before/self_paced/_index.ja.md @@ -0,0 +1,13 @@ ++++ +title = "自習形式、および小規模セミナー形式での参加" +chapter = true +weight = 5 ++++ + +### ご自身のアカウントでワークショップを進めるには + +ワークショップを進める前に、お使いのアカウントの管理者権限にアクセスできることを確認してください。例えば、**arn:aws:iam::aws:policy/AdministratorAccess**をアタッチしたIAMユーザーを準備します。 + +続いて[**CloudFormationによるセットアップ**](/ja/running-amazon-ec2-workloads-at-scale/launch_cloudformation.html)に進んでください。 + +予期せぬ費用増加を防ぐため、ワークショップを終える場合にはこのワークショップ末尾に付記する[**クリーンアップ**](/ja/running-amazon-ec2-workloads-at-scale/cleanup.html)の確認と実施を強く推奨します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/cleanup.ja.md b/content/running-amazon-ec2-workloads-at-scale/cleanup.ja.md new file mode 100644 index 00000000..c8517bb3 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/cleanup.ja.md @@ -0,0 +1,41 @@ ++++ +title = "クリーンアップ" +weight = 170 ++++ + +{{% notice note %}} +AWSイベントでAWSから提供されたアカウントを用いている場合、このステップは省略できます。ご自身のアカウントをお使いの場合、予期せぬ請求が発生しないよう、作成したリソースを確実に消去してください。 +{{% /notice %}} + +1. もしまだであれば、Auto Scalingグループからデタッチしたインスタンスを削除(Terminate)します。 + +1. 手動で作成した全てのリソースを、次のコマンドで削除します。 + + ``` + aws autoscaling delete-auto-scaling-group --auto-scaling-group-name runningAmazonEC2WorkloadsAtScale --force-delete + + aws deploy delete-deployment-group --application-name koelApp --deployment-group-name koelDepGroup + + aws deploy delete-application --application-name koelApp + + aws s3 rm s3://$codeDeployBucket --recursive + + aws elbv2 delete-load-balancer --load-balancer-arn $alb_arn + + sleep 5 + + aws elbv2 delete-target-group --target-group-arn $tg_arn + + aws rds delete-db-instance --db-instance-identifier runningAmazonEC2WorkloadsAtScale --skip-final-snapshot + + aws ec2 delete-launch-template --launch-template-name runningAmazonEC2WorkloadsAtScale + + aws cloudformation delete-stack --stack-name spotinterruptionhandler + + ``` + +1. 最後にCloudFormationスタックを削除します。 + + ``` + aws cloudformation delete-stack --stack-name runningAmazonEC2WorkloadsAtScale + ``` diff --git a/content/running-amazon-ec2-workloads-at-scale/clone_github.ja.md b/content/running-amazon-ec2-workloads-at-scale/clone_github.ja.md new file mode 100644 index 00000000..bf7a2a25 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/clone_github.ja.md @@ -0,0 +1,33 @@ ++++ +title = "GitHubリポジトリのクローニング" +weight = 60 ++++ + +ワークショップ用に準備したファイル群をCloud9環境に取得するため、GitHubリポジトリをクローンします。 + +1. Cloud9ターミナルから次のコマンドを発行します。 + + ``` + git clone https://github.com/awslabs/ec2-spot-workshops.git + ``` + +1. カレントディレクトリを移動します。 + + ``` + cd ec2-spot-workshops/workshops/running-amazon-ec2-workloads-at-scale + ``` + +1. 内容を確認します。ディレクトリ構造の確認にはターミナルからだけでなく、**Environment** タブのファイルツリーを活用できます。ファイルをダブルクリックすることで編集も可能です。 + +1. このワークショップのアプリケーションをお使いのアカウントで稼働させるため、設定ファイル群を編集し、先ほどCloudFormationで作成した具体的なAWSリソース名を指定する必要があります。個別にファイルを編集しても良いのですが、今回は *[sed](https://linux.die.net/man/1/sed)* を使って作業を省力化してみましょう。このために、ここでは事前にCloudFormationの **Outputs** の出力をbashの環境変数に格納します。以下のコマンドを発行し、それぞれの意味も考えてみてください。 + ```bash + export AWS_REGION=$(curl --silent http://169.254.169.254/latest/dynamic/instance-identity/document | jq -r .region) + export stack_name=runningAmazonEC2WorkloadsAtScale + + # load outputs to env vars + for output in $(aws cloudformation describe-stacks --stack-name $stack_name --query 'Stacks[].Outputs[].OutputKey' --output text) + do + export $output=$(aws cloudformation describe-stacks --stack-name $stack_name --query 'Stacks[].Outputs[?OutputKey==`'$output'`].OutputValue' --output text) + eval "echo $output : \"\$$output\"" + done + ``` diff --git a/content/running-amazon-ec2-workloads-at-scale/create_asg.ja.md b/content/running-amazon-ec2-workloads-at-scale/create_asg.ja.md new file mode 100644 index 00000000..c16e670e --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/create_asg.ja.md @@ -0,0 +1,59 @@ ++++ +title = "EC2 Auto Scalingグループの作成" +weight = 100 ++++ + +Amazon EC2 Auto Scaling は、Amazon EC2 のインスタンスを自動的に作成または終了してアプリケーションの負荷を処理する Amazon EC2 インスタンスの数を調整できる、完全マネージド型サービスです。Amazon EC2 Auto Scaling では、異常なインスタンスを検出して置き換えることにより、EC2 インスタンスのフリートを管理できます。また、お客様が定義する条件に応じて Amazon EC2 のキャパシティーのスケールアップ/スケールダウンを自動的に行って、アプリケーションの可用性を維持できます。Amazon EC2 Auto Scaling を使用することで、需要が急激に上昇したときには Amazon EC2 インスタンスの数を自動的に増やしてパフォーマンスを維持し、需要が落ち着いた状態にあるときにはインスタンスの数を減らしてコストを削減できます。 + +1\. **asg.json**を編集し、先ほどCloudFormationから作成したTarget Groupのとサブネットの値を書き換えます。 + +``` +sed -i.bak -e "s#%TargetGroupARN%#$tg_arn#g" -e "s#%publicSubnet1%#$publicSubnet1#g" -e "s#%publicSubnet2%#$publicSubnet2#g" asg.json +``` + +#### チャレンジしてみましょう +これからデプロイするEC2 Auto Scalingグループは、[ミックスインスタンスグループ機能](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)(オンデマンドインスタンスとスポットインスタンス、および複数インスタンスタイプの混在環境)をサポートするものです。**asg.json**ファイルを確認し、次の質問に答えてみましょう。\ + +- Q. それぞれ何台のオンデマンドインスタンス、スポットインスタンスが起動されるでしょうか。\ +- Q. Overridesのセクションに列挙されたインスタンスタイプ一覧から、実際にオンデマンドインスタンスとして起動されるのはどのインスタンスタイプでしょうか。またスポットインスタンスはどうでしょうか。 + +ヒント: EC2 Auto Scalingのユーザーガイドの[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-purchase-options.html)のセクション、また合わせて +APIドキュメントの[InstancesDistribution] (https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html)のセクションを読んでみてください。 + +{{%expand "考え方の一例(クリックで展開)" %}} + +まず`OnDemandBaseCapacity`(ベースのオンデマンド部分)に2が指定され、`OnDemandPercentageAboveBaseCapacity`(オンデマンドの割合)に0, `DesiredCapacity`(希望する容量)に4が指定されています。このとき、EC2 Auto ScalingがこのAuto Scalingグループを作成するタイミングで、2台のオンデマンドインスタンスと2台のスポットインスタンスを起動します。 + +`SpotAllocationStrategy`に`lowest-price`が指定されているため、スポットインスタンスとしては、アベイラビリティゾーンごとに最も価格の安いインスタンスタイプが選択されます。また`SpotInstancePools`に4が指定されているため、今後このAuto Scalingグループがスケールアウトし、追加のスポットインスタンスが起動されるとき、アベイラビリティゾーンごとに上から4番目までに安いインスタンスタイプが選択されます。 + +{{% /expand %}} + + +2\. 次のコマンドを発行し、Auto Scalingグループを作成します。 + + ``` + aws autoscaling create-auto-scaling-group --cli-input-json file://asg.json + ``` + +{{% notice note %}} +コマンドが成功したとき、特別な出力がないのが正常動作です。 +{{% /notice %}} + + +3\. [Auto Scaling コンソール](https://console.aws.amazon.com/ec2/autoscaling/home#AutoScalingGroups:view=details)を開き、新たに作成されたAuto Scalingグループの詳細情報を確認します。次にEC2インスタンスコンソールに移り、起動されたインスタンスがオンデマンドかスポットかを確認します。この属性を表示するには、右上の歯車ボタンから表示属性ダイアログボックスを開き、「ライフサイクル」列を表示させるようにしてください。Normalがオンデマンドおよびリザーブドインスタンス、Spotがスポットインスタンスを示します。 + +#### チャレンジしてみましょう +Q. 各アベイラビリティゾーンに1台ずつスポットインスタンスを起動しました。このとき選択されたインスタンスタイプは、実際にそのアベイラビリティゾーンで最安値のものになっているでしょうか。\ +ヒント: [スポットインスタンスの価格履歴] (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html)を参照してみましょう。 + +{{%expand "考え方の一例(クリックで展開)" %}} + +1. [EC2インスタンスコンソール] (https://console.aws.amazon.com/ec2/v2/home?#Instances)からスポットインスタンスを選択します。追加表示させたライフサイクル属性を確認し、値がSpotであるものを選択します。 +2. それぞれのスポットインスタンスがどのアベイラビリティゾーンに起動されたかを確認します。 +3. [EC2スポットインスタンスコンソール Spot Instances console] (https://console.aws.amazon.com/ec2sp/v1/spot/home)を開き、「価格設定履歴」ボタンを押して起動されたスポットインスタンスのインスタンスタイプに設定された現在の価格を確認します。そして**asg.json**に定義した他のインスタンスタイプと価格を比較します。 + +次の図はeu-west-1リージョンにおける、ある日のm5.largeのスポットインスタンス価格です。アベイラビリティゾーンごとの価格推移が表示され、この図では直近3時間の推移が選択されています。 + +![spotpricehistory](/images/running-amazon-ec2-workloads-at-scale/spotpricehistory.png) + +{{% /expand %}} diff --git a/content/running-amazon-ec2-workloads-at-scale/create_lt.ja.md b/content/running-amazon-ec2-workloads-at-scale/create_lt.ja.md new file mode 100644 index 00000000..b1bfe1f8 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/create_lt.ja.md @@ -0,0 +1,63 @@ ++++ +title = "EC2起動テンプレートの作成" +weight = 70 ++++ + +EC2起動テンプレートを活用することにより、EC2インスタンス起動時に指定する様々なパラメータを事前に定義し、再利用可能な形で保管できます。 + +起動テンプレートを使えば、EC2インスタンスの起動時に毎回同じ値を入力する必要がなくなります。AMI ID, インスタンスタイプやネットワーク設定といった項目のセットを事前定義でき、EC2マネジメントコンソールやAWS CLI, SDKのいずれからも、EC2インスタンスを起動するときにこの起動テンプレートを指定することができます。 + +{{% notice note %}} +[起動テンプレート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)と[起動設定](https://docs.aws.amazon.com/autoscaling/ec2/userguide/LaunchConfiguration.html)の違いについて補足します。いずれもEC2の起動に必要なパラメータを定義する機能ですが、起動テンプレートはAmazon EC2とEC2 Auto Scalingを活用する上で、バージョン管理機能を含むより強力な機能を提供します。特にこのワークショップで取り扱う、複数インスタンスタイプ・複数購入オプションを指定したEC2 Auto Scalingグループは起動テンプレートからの作成のみがサポートされています。起動テンプレートについてさらに深く知るには[こちら](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)のドキュメントを参照してください。 +{{% /notice %}} + +このワークショップに必要な起動テンプレートを定義していきます。 + +1. 作成されたリソース名で**user-data.txt**を更新するため、次のコマンドを実行します。この内容には、EC2インスタンス起動時に自動実行される[cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html)命令を含んだ[ユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)が含まれます。 + ```bash + sed -i.bak -e "s/%awsRegionId%/$AWS_REGION/g" -e "s/%fileSystem%/$fileSystem/g" user-data.txt + ``` +1. インスタンス起動時に実行される処理がどのようなものか、ユーザーデータスクリプトの内容を確認します。 + +1. 起動テンプレートに定義するデータを格納する **launch-template-data.json** を更新します。ここでは、その時点の最新のAmazon Linux 2 AMIを指定し、CloudFormationで作成したリソースIDを指定し、また上のステップで作成したユーザーデータスクリプトをbase64エンコーディングした値を指定します。次のコマンドを発行します。 + ``` + # 事前に最新のAmazon Linux 2 AMIのAMI IDを取得する + export ami_id=$(aws ec2 describe-images --owners amazon --filters 'Name=name,Values=amzn2-ami-hvm-2.0.????????-x86_64-gp2' 'Name=state,Values=available' --output json | jq -r '.Images | sort_by(.CreationDate) | last(.[]).ImageId') + + sed -i.bak -e "s#%instanceProfile%#$instanceProfile#g" -e "s/%instanceSecurityGroup%/$instanceSecurityGroup/g" -e "s#%ami-id%#$ami_id#g" -e "s#%UserData%#$(cat user-data.txt | base64 --wrap=0)#g" launch-template-data.json + ``` + +1. 起動テンプレートに定義する項目がどのようなものか、launch-template-data.jsonの内容を確認します。問題がなければ次のコマンドを発行し、起動テンプレートのリソースを作成します。 + ``` + aws ec2 create-launch-template --launch-template-name runningAmazonEC2WorkloadsAtScale --version-description dev --launch-template-data file://launch-template-data.json + ``` + + 次のような出力を確認します。 + + ``` + { + "LaunchTemplate": { + "LatestVersionNumber": 1, + "LaunchTemplateId": "lt-04c1ee7ef0e1e6b3b", + "LaunchTemplateName": "runningAmazonEC2WorkloadsAtScale", + "DefaultVersionNumber": 1, + "CreatedBy": "arn:aws:sts::012345678912:assumed-role/runningEC2WorkloadsAtScale-instanceRole-E5CPATQAY4O0/i-xxxxxxx", + "CreateTime": "2019-11-05T13:27:58.000Z" + } + } + ``` + +作成された起動テンプレートを[EC2起動テンプレートマネジメントコンソール](https://console.aws.amazon.com/ec2/v2/home?#LaunchTemplates:sort=launchTemplateId)もしくはCLIから確認します。CLIから確認する場合、正常に作成されたことを次のコマンドで確かめてください。 + + +* 起動テンプレートの定義が正しいことを確認します。 + + ``` + aws ec2 describe-launch-template-versions --launch-template-name runningAmazonEC2WorkloadsAtScale + ``` + +* 起動テンプレートに指定したユーザーデータが正しいことを確認します。 + + ``` + aws ec2 describe-launch-template-versions --launch-template-name runningAmazonEC2WorkloadsAtScale --output json | jq -r '.LaunchTemplateVersions[].LaunchTemplateData.UserData' | base64 --decode + ``` \ No newline at end of file diff --git a/content/running-amazon-ec2-workloads-at-scale/create_rds.ja.md b/content/running-amazon-ec2-workloads-at-scale/create_rds.ja.md new file mode 100644 index 00000000..edad80ee --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/create_rds.ja.md @@ -0,0 +1,18 @@ ++++ +title = "Amazon RDSによるデータベースの導入" +weight = 80 ++++ + +Amazon Relational Database Service (Amazon RDS)はリレーショナルデータベースを簡単に作成・操作・運用できるマネージド型のデータベースサービスです。サイズ変更可能なデータベースをコスト効率よく提供し、またこれまでデータベース運用につきものだった、ハードウェアの増強、データベースエンジンの導入、パッチ当てやバックアップ運用といった時間のかかる作業を自動化します。さらにデータベースの性能チューニングのヒント、高可用性オプションの提供、セキュリティや互換性の維持などを提供することで、ユーザーは本質的なアプリケーションの開発と運用に集中することができます。 + +1. 次のコマンドを実施し、CloudFormationから作成したリソースIDで **rds.json** を更新します。 + ``` + sed -i.bak -e "s#%dbSecurityGroup%#$dbSecurityGroup#g" -e "s#%dbSubnetGroup%#$dbSubnetGroup#g" rds.json + ``` + +1. 更新されたjsonファイルの内容を確認します。問題がなければ次のコマンドでRDS DBインスタンスを作成します。 + ``` + aws rds create-db-instance --cli-input-json file://rds.json + ``` + +1. [Amazon RDSマネジメントコンソール](https://console.aws.amazon.com/rds/home?#dbinstances:)を開き、作成したRDS DBインスタンスが起動する様子を確認します。データベースの作成には数分かかります。これを待つ間に次のステップに進むこともできます。また後ほどデータベースが作成されたことを確認してください。 diff --git a/content/running-amazon-ec2-workloads-at-scale/deploy_app_codedeploy.ja.md b/content/running-amazon-ec2-workloads-at-scale/deploy_app_codedeploy.ja.md new file mode 100644 index 00000000..cc847efb --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/deploy_app_codedeploy.ja.md @@ -0,0 +1,128 @@ ++++ +title = "CodeDeployからAuto Scalingグループにデプロイする" +weight = 120 ++++ + +AWS CodeDeployで用いるアプリケーション仕様ファイル(AppSpecファイル)はYAMLもしくはJSON形式のファイルです。 +AppSpecファイルは、ファイルで定義されている一連のライフサイクルイベントフックとして、各デプロイを管理するために使用されます。 + +正しい形式の AppSpec file を作成する方法については、[CodeDeploy AppSpec Fileリファレンス](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure.html)を参照してください。 + +ここまでのステップが完了すると、Auto Scalingグループ内のEC2インスタンスにアプリケーションをデプロイできるようになっています。 + +1. **codedeploy**ディレクトリの内容を参照し、これからデプロイするアプリケーションの構造を確認します。 + +1. CodeDeployデプロイスクリプトを編集し、RDS DBインスタンス名を更新します。 +次のコマンドを発行して**codedeploy/scripts/configure_db.sh**を更新し、**%endpoint%**をRDS DBインスタンスのエンドポイントの値で置き換えます。 + + ``` + # RDS DBインスタンスエンドポイント名を取得 + rds_endpoint=$(aws rds describe-db-instances --db-instance-identifier runningamazonec2workloadsatscale --query DBInstances[].Endpoint.Address --output text) + + sed -i.bak -e "s#%endpoint%#$rds_endpoint#g" codedeploy/scripts/configure_db.sh + ``` + +1. 続いてKoelのGitHubレポジトリを手元にクローンします。 + + ``` + cd ~/environment/ec2-spot-workshops/workshops/running-amazon-ec2-workloads-at-scale/ + + git clone https://github.com/phanan/koel.git + + cd koel && git checkout v3.7.2 + ``` +{{% notice note %}} +Gitから'detached HEAD'の通知が来ることを確認してください。 +{{% /notice %}} + +1. KoelアプリケーションディレクトリにCodeDeployの構成情報をコピーします。 + + ``` + cp -avr ../codedeploy/* . + ``` + +1. コピーされたCodeDeploy構成情報を確認し、次のコマンドでCodeDeployアプリケーションを作成します。 + + ``` + aws deploy create-application --application-name koelApp + ``` + +1. [AWS CodeDeployコンソール](https://console.aws.amazon.com/codesuite/codedeploy/applications)を開き、右上のリージョン情報が正しいことを確認した上で、作成されたアプリケーションを確認します。 + +{{% notice note %}} +CodeDeployコンソールに遷移したタイミングで、リージョンが変更されている可能性があります。右上のリージョン情報が異なっている場合、正しいリージョンを改めて選択してください。 +{{% /notice %}} + + +1. アプリケーションをCodeDeploy用S3バケットに配置します。 + + ``` + aws deploy push --application-name koelApp --s3-location s3://$codeDeployBucket/koelApp.zip --no-ignore-hidden-files + ``` +{{% notice note %}} +次のような出力が表示されることを確認してください。 + +*To deploy with this revision, run: aws deploy create-deployment --application-name koelApp --s3-location bucket=runningamazonec2workloadsatscale-codedeploybucket-11wv3ggxcni40,key=koelApp.zip,bundleType=zip,eTag=870b90e201bdca3a06d1b2c6cfcaab11-2 --deployment-group-name --deployment-config-name --description * +{{% /notice %}} + +1. アプリケーションが正しくS3バケットに配置されたことを確認します。CloudFormationスタックの出力からS3バケット名を確認し(もしくは`$ echo $codeDeployBucket`を発行し), [S3コンソール](https://s3.console.aws.amazon.com/s3/home)から対象バケットを選択します。 + +1. 次のコマンドを発行して**deployment-group.json**の**%codeDeployServiceRole%**を作成した値で更新します。続いてデプロイグループを作成します。 + + ``` + cd .. + + sed -i.bak -e "s#%codeDeployServiceRole%#$codeDeployServiceRole#g" deployment-group.json + + aws deploy create-deployment-group --cli-input-json file://deployment-group.json + ``` + +1. [AWS CodeDeployコンソール](https://console.aws.amazon.com/codesuite/codedeploy/applications)を開き、再度リージョンが正しいことを確認してから、アプリケーションを選択して「デプロイグループ」タブをクリックし、作成されたデプロイグループを確認します。 + +{{% notice note %}} +CodeDeployコンソールに遷移したタイミングで、リージョンが変更されている可能性があります。右上のリージョン情報が異なっている場合、正しいリージョンを改めて選択してください。 +{{% /notice %}} + +1. 次のコマンドを発行して**deployment.json**の**%codeDeployBucket%**を作成した値で更新します。 + + ``` + sed -i.bak -e "s#%codeDeployBucket%#$codeDeployBucket#g" deployment.json + ``` + +1. **deployment.json**の内容を確認し、デプロイを作成します。 + + ``` + aws deploy create-deployment --cli-input-json file://deployment.json + ``` +{{% notice note %}} +**deploymentId** をメモしてください。 +{{% /notice %}} + +1. [AWS CodeDeployコンソール](https://console.aws.amazon.com/codesuite/codedeploy/deployments)を開き、再度リージョンが正しいことを確認してから対象のデプロイIDをクリックし、デプロイ状況を確認します。下部のデプロイイベントに対象となるEC2インスタンスが表示されていることを確認します。個々のインスタンスへのデプロイ状況は「イベントの表示」から確認できます。 + +{{% notice note %}} +CodeDeployコンソールに遷移したタイミングで、リージョンが変更されている可能性があります。右上のリージョン情報が異なっている場合、正しいリージョンを改めて選択してください。 +{{% /notice %}} + +1. アプリケーションが正しくインスタンスにデプロイされると、ターゲットグループのヘルスチェックが正常としてマークされます。[ターゲットグループコンソール](https://console.aws.amazon.com/ec2/v2/home#TargetGroups:sort=targetGroupName)からTargetsタブを選択し、ヘルスチェック結果を確認します。 + +1. 最低1つのインスタンスが正常とマークされたら、[ロードバランサコンソール](https://console.aws.amazon.com/ec2/v2/home#LoadBalancers:sort=loadBalancerName)から作成したロードバランサを選択します。 + +1. **DNS名**をコピーし、URLとしてブラウザからアクセスします。ログインページが表示されたらば、ユーザー名に'**admin@example.com**', パスワードに'**admin-pass**'を指定してログインします。 + +1. 各インスタンスにはマウントポイント**/var/www/media**があり、ここにEFSファイルシステムがマウントされており、オーディオファイルが格納される想定となっています。mp3ファイルをいくつかコピーするため、Cloud9環境からEFSファイルシステムをマウントします。CloudFormationスタックの出力から控えた **$fileSystem** の値に置き換えた上で、次のコマンドを実行します。 + + ``` + mkdir -p ~/environment/media + + sudo mount -t efs $fileSystem:/ ~/environment/media + + sudo chown ec2-user. ~/environment/media + + sudo cp -av *.mp3 ~/environment/media + ``` + +1. ブラウザのKoel画面に戻り、**MANAGE**から**Settings**, **Scan**と進みます。構築できた音楽サービスにしばらく触れてみてください。 + +1. [オプション] 任意のmp3ファイルを同様の手順で追加することもできます。追加した後にはメディアディレクトリの再スキャンを忘れずに実施してください。 + diff --git a/content/running-amazon-ec2-workloads-at-scale/deploy_lb.ja.md b/content/running-amazon-ec2-workloads-at-scale/deploy_lb.ja.md new file mode 100644 index 00000000..6535f70d --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/deploy_lb.ja.md @@ -0,0 +1,75 @@ ++++ +title = "AWS Elastic Load Balancerのデプロイ" +weight = 90 ++++ + +ロードバランサは、不特定多数のクライアントに対するアプリケーションのアクセスポイントです。ロードバランサは受け付けたトラフィックを複数アベイラビリティゾーンに配置されたEC2インスタンスなどの複数のターゲットに分散します。この構成はアプリケーションの可用性向上に寄与します。ロードバランサには複数のリスナーを関連づけることができます。 + +リスナーはクライアントからのリクエストに応じてプロトコルおよびポートベースでリクエストを検査し、ルールごとに登録されたターゲットグループにリクエストを振り分けます。それぞれのルールにはターゲットグループ、条件、優先順位を指定します。これらの条件に合致したリクエストは適切なターゲットグループにルーティングされます。それぞれのリスナーにはデフォルトルールを定義する必要があります。またそれ以外に、リクエスト内容に応じて特定のターゲットグループを指定するルールを定義することもでき、これはコンテントベースルーティングとも呼ばれます。 + +ターゲットグループにルーティングされたリクエストは、プロトコルとポート番号に応じてEC2インスタンスのようなグループ内のターゲットにさらにルーティングされます。1つのターゲットを複数のターゲットグループに登録することもできます。ターゲットグループにはヘルスチェックを設定できます。ヘルスチェックはターゲットグループ内のすべてのターゲットに対して実行されます。 + +1. 次のコマンドを実施し、CloudFormationから作成したリソースIDで **application-load-balancer.json** を更新します。 + + ``` + sed -i.bak -e "s#%publicSubnet1%#$publicSubnet1#g" -e "s#%publicSubnet2%#$publicSubnet2#g" -e "s#%loadBalancerSecurityGroup%#$loadBalancerSecurityGroup#g" application-load-balancer.json + ``` + +1. 更新されたjsonファイルの内容を確認し、次のコマンドでロードバランサを作成します。 + + ``` + aws elbv2 create-load-balancer --cli-input-json file://application-load-balancer.json + ``` +1. 環境変数にロードバランサのARNを格納します。 + + ``` + export alb_arn=$(aws elbv2 describe-load-balancers --names runningAmazonEC2WorkloadsAtScale --query LoadBalancers[].LoadBalancerArn --output text) + ``` +1. [ロードバランサマネジメントコンソール](https://console.aws.amazon.com/ec2/v2/home#LoadBalancers:sort=loadBalancerName)から作成されたロードバランサを確認します。 + +1. 次のコマンドを実施し、CloudFormationから作成したリソースIDで **target-group.json** を更新します。 + + ``` + sed -i.bak -e "s#%vpc%#$vpc#g" target-group.json + ``` + +1. 次のコマンドでターゲットグループを作成します。 + + ``` + aws elbv2 create-target-group --cli-input-json file://target-group.json + ``` + +1. 環境変数にターゲットグループのARNを格納します。 + + ``` + export tg_arn=$(aws elbv2 describe-target-groups --names runningAmazonEC2WorkloadsAtScale --query TargetGroups[].TargetGroupArn --output text) + ``` + +1. 次のコマンドを実施し、作成したターゲットグループのARNで **modify-target-group.json** を更新します。 + + ``` + sed -i.bak -e "s#%TargetGroupArn%#$tg_arn#g" modify-target-group.json + ``` + +1. デフォルトで5分となっているターゲットグループのderegistration_delay_timeout値を2分に更新し、スポットインスタンスの中断通知の猶予時間に合わせます。この設定項目の理解を深めるには、Elastic Load BalancingのApplication Load Balancerユーザーガイドの[登録解除の遅延](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay)の記述を参照してください。 + + ``` + aws elbv2 modify-target-group-attributes --cli-input-json file://modify-target-group.json + ``` + +1. [ターゲットグループマネジメントコンソール](https://console.aws.amazon.com/ec2/v2/home#TargetGroups:sort=targetGroupName)から作成されたターゲットグループを確認します。 + +1. 次のコマンドを実施し、先ほどのステップで作成した**%LoadBalancerArn%** と **%TargetGroupArn%** で + **listener.json** を更新します。 + + ``` + sed -i.bak -e "s#%LoadBalancerArn%#$alb_arn#g" -e "s#%TargetGroupArn%#$tg_arn#g" listener.json + ``` + +1. 次のコマンドでリスナーを作成します。 + + ``` + aws elbv2 create-listener --cli-input-json file://listener.json + ``` + +1. [ロードバランサマネジメントコンソール](https://console.aws.amazon.com/ec2/v2/home#LoadBalancers:sort=loadBalancerName)からロードバランサを選択し、**リスナー** タブを開きます。作成されたリスナーが関連づけられていることを確認します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/finished.ja.md b/content/running-amazon-ec2-workloads-at-scale/finished.ja.md new file mode 100644 index 00000000..3cd6da22 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/finished.ja.md @@ -0,0 +1,6 @@ ++++ +title = "終わりに" +weight = 160 ++++ + +おめでとうございます！　ワークショップを完了することができたでしょうか。概念の理解を復習したいとき、いつでもこのワークショップに戻り、確認してみてください。また、フィードバックを歓迎しています。左ペインのメニューの最下部のFeedbackボタンから、ぜひ忌憚のないご意見を頂戴できればと思います。そして最後に、予期せぬ請求を防ぐため、必ず今回作成したリソースを削除することをお忘れなく。次のステップに進んでください。 diff --git a/content/running-amazon-ec2-workloads-at-scale/launch_cloudformation.ja.md b/content/running-amazon-ec2-workloads-at-scale/launch_cloudformation.ja.md new file mode 100644 index 00000000..363dc321 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/launch_cloudformation.ja.md @@ -0,0 +1,53 @@ ++++ +title = "CloudFormationによるセットアップ" +weight = 30 ++++ + +### CloudFormationスタックの起動 + +事前準備を省力化するため、このワークショップの環境を準備するCloudFormationテンプレートを用意しました。このCloudFormtionスタックには、VPCおよび2つのアベイラビリティゾーンに対応するそれぞれのサブネット、IAMポリシーとロール、セキュリティグループ、S3バケット、EFSファイルシステム、そしてワークショップ環境自体を操作していくためのCloud9 IDE環境が含まれます。 + +#### CloudFormationスタックの作成 + +1. [こちら](https://raw.githubusercontent.com/awslabs/ec2-spot-workshops/master/workshops/running-amazon-ec2-workloads-at-scale/running-amazon-ec2-workloads-at-scale.yaml)に準備したCloudFormationテンプレートをダウンロードします。 + +1. 作成されるリソースにどのようなものがあるか、テンプレートの内容を確認します。 + +1. [AWS CloudFormationマネジメントコンソール](https://console.aws.amazon.com/cloudformation)を開きます。 +{{% notice note %}} +ファシリテーターがいる場合、ファシリテーターの指示したリージョンを選択していることを確認してください。 +{{% /notice %}} + +1. 「**スタックの作成 (Create stack)**」をクリックします。 + +1. 「**テンプレートの指定 (Specify template)**」で「**テンプレートファイルのアップロード (Upload a template file)**」をクリックし、「**ファイルの選択 (Choose file)**」に先ほどダウンロードしたテンプレートファイルを指定します。 + +1. 「**次へ (Next)**」をクリックします。 + +1. 「**スタックの詳細指定 (Specify stack details)**」で、「**スタック名 (Stack name)**」に *runningAmazonEC2WorkloadsAtScale* を指定します。 + +1. (オプション) **パラメータ (Parameters)**で **sourceCidr** を変更することで、EC2インスタンスへのSSHおよびHTTPアクセス、またロードバランサへのHTTPアクセスの接続元を限定することができます。 + +1. 「**次へ (Next)**」をクリックします。 + +1. 「**スタックオプションの指定 (Configure stack options)**」は変更不要です。 + +1. 「**次へ (Next)**」をクリックします。 + +1. スタックの構成内容を確認します。画面最下部の「**機能**」では、**「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」(I acknowledge that AWS CloudFormation might create IAM resources)** にチェックを入れます。設定内容に問題がなければ「**スタックの作成 (Create stack)**」をクリックします。 + +#### スタックの進捗確認 + +スタックの作成完了の目安は、おおむね5分ほどです。 + +1. [AWS CloudFormationマネジメントコンソール](https://console.aws.amazon.com/cloudformation) から、作成したスタックを選択します。 + +1. スタックの詳細を表示するペインで「**イベント (Events)**」タブをクリックします。更新ボタンで最新情報を表示することができます。 + + +「**イベント (Events)**」タブでは最新のイベントが先頭に表示され、スタックの主要なステップがどこまで進んだかを確認できます。 + + +AWS CloudFormationがそれぞれのリソースの作成を開始すると、「**CREATE\_IN\_PROGRESS**」イベントが記録されます。そのリソースが正常に作成完了すると、「**CREATE_COMPLETE**」イベントが記録されます。 + +スタック全体の作成が完了すると、「**イベント (Events)**」タブの最上部に「**CREATE_COMPLETE**」イベントが記録されます。 diff --git a/content/running-amazon-ec2-workloads-at-scale/learn_more.ja.md b/content/running-amazon-ec2-workloads-at-scale/learn_more.ja.md new file mode 100644 index 00000000..0196f6f1 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/learn_more.ja.md @@ -0,0 +1,16 @@ ++++ +title = "参考情報" +weight = 180 ++++ + +より深く学ぶために、次の情報源を参照してみてください。 + +### 参考情報 + +* [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) +* [Amazon EC2 Spot Instances](https://aws.amazon.com/ec2/spot/) +* [Amazon EC2 Spot Workshops GitHubリポジトリ](https://github.com/awslabs/ec2-spot-workshops/) + +### 参考記事 +* [Amazon EC2 Auto Scaling Groups With Multiple Instance Types & Purchase Options](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/) +* [Taking Advantage of Amazon EC2 Spot Instance Interruption Notices](https://aws.amazon.com/blogs/compute/taking-advantage-of-amazon-ec2-spot-instance-interruption-notices/) \ No newline at end of file diff --git a/content/running-amazon-ec2-workloads-at-scale/requirements_notes.ja.md b/content/running-amazon-ec2-workloads-at-scale/requirements_notes.ja.md new file mode 100644 index 00000000..e251f330 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/requirements_notes.ja.md @@ -0,0 +1,19 @@ ++++ +title = "ワークショップを始める前に" +weight = 10 ++++ +1\. __このワークショップは自習形式です__。ワークショップ内のコマンドは[AWS Command Line Interface (CLI)](https://aws.amazon.com/cli)で記述されていますが、マネジメントコンソールでの操作を指示する場合もあります。AWSに慣れている方はCLI, マネジメントコンソールのどちらを用いても構いません。 + +2\. ワークショップをステップバイステップで進められるよう、それぞれの節で具体的なコマンドを提示しています。このため、単にコマンドを追いかけるだけでも進めることができますが、それぞれのコマンドが何をしているのか、実際に何が起こったのかを時間を取って確認することを推奨します。このワークショップはスポットインスタンスとEC2 Auto Scalingを活用するはじめの一歩という位置付けですが、一つ一つのコマンドの意味を咀嚼し、読者自身の環境に適用するとしたらどうかと考え、さらにコマンドを変化させるといったチャレンジをしてみることがとても重要です。 + +3\. ワークショップを実施するリージョンは、AWS Cloud9の使えるところを選択してください。最新の詳細は[リージョン表](https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/)を参照してください。 + +{{% notice note %}} +AWSの主催するイベントに参加している場合、ファシリテーターの指示するリージョンを選択して実施してください。 +現時点でCloud9が動作し、このワークショップで例示するインスタンスタイプが提供されているリージョンは、us-east-1 (北バージニア), us-east-2 (オハイオ), us-west-2 (オレゴン), eu-west-1 (アイルランド), eu-central-1 (フランクフルト), ap-southeast-1 (シンガポール), ap-northeast-1 (東京)です。 +{{% /notice %}} + +4\. ワークショップ内では、お使いのアカウントに起動するEC2インスタンスに、いくつかのソフトウェアとそれに依存する前提ソフトウェアをインストールします。[Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/)をはじめとするソフトウェアパッケージ、またサードパーティのものについて、使用許諾条件を確認してください。 + +## 謝辞 +[Koel](https://koel.phanan.net/)という素晴らしいソフトウェアを開発し、このワークショップでの使用を快諾してくださった[Phan An](https://www.phanan.net/)に深く感謝します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/scale_dynamic.ja.md b/content/running-amazon-ec2-workloads-at-scale/scale_dynamic.ja.md new file mode 100644 index 00000000..5c8375a1 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/scale_dynamic.ja.md @@ -0,0 +1,16 @@ ++++ +title = "Auto Scalingグループの動的スケーリング" +weight = 140 ++++ + +動的スケーリングを設定する場合は、需要の増減に応じてスケールする方法を定義する必要があります。たとえば、現在 2 つのインスタンスで実行されているウェブアプリケーションがあり、アプリケーションの負荷が変化しても Auto Scaling グループの CPU 使用率を約 50% に維持する必要があるとします。これにより、過剰な量のアイドルリソースを維持することなくトラフィックの急上昇を処理するための追加の容量が得られます。このニーズを満たすため、自動的にスケーリングするように Auto Scaling グループを設定できます。ポリシータイプによって、スケーリングアクションがどのように実行されるかが決まります。 + +ターゲット追跡スケーリングポリシーでは、スケーリングメトリクスを選択してターゲット値を設定します。Amazon EC2 Auto Scaling はスケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するために、必要に応じて容量を追加または削除します。ターゲット追跡スケーリングポリシーは、メトリクスをターゲット値に近い値に維持することに加えて、変化するロードパターンによるメトリクスの変化に適応します。 + +1. **asg-automatic-scaling.json**ファイルを開き、スケーリングポリシーとして設定される内容を確認します。ファイルの内容変更は不要です。次のコマンドでスケーリングポリシーを設定します。 + + ``` + aws autoscaling put-scaling-policy --cli-input-json file://asg-automatic-scaling.json + ``` + +1. [Auto Scalingコンソール](https://console.aws.amazon.com/ec2/autoscaling/home#AutoScalingGroups:view=details)を開き、「スケーリングポリシー」タブから設定を確認します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/seed_db.ja.md b/content/running-amazon-ec2-workloads-at-scale/seed_db.ja.md new file mode 100644 index 00000000..eaa6b41b --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/seed_db.ja.md @@ -0,0 +1,20 @@ ++++ +title = "データベースへのデータの投入" +weight = 110 ++++ + +1. [Amazon RDS コンソール](https://console.aws.amazon.com/rds/home?#dbinstances:)を開き、データベースの作成状況を確認します。データベース名を選択し、「概要」セクションに表示される「情報」ステータスが利用可能になっていることを確認します。もしまだ「作成中」であれば、数分おきにリロードして利用可能になるまで待機してください。おそらく初期バックアップの作成に時間を要していることが考えられます。 + +1. 次に「接続とセキュリティ」セクションから「エンドポイント」をメモします。例えば **runningamazonec2workloadsatscale.ckhifpaueqm7.us-east-1.rds.amazonaws.com** というような文字列です。 + +1. このデータベースに実データを投入します。次のコマンドの**%endpoint%**を先ほどメモした文字列に置き換え、実行します。 + + ``` + mysql -h %endpoint% -u dbadmin --password=db-pass-2020 -f koel < koel.sql + ``` + +{{% notice note %}} + +コマンドが成功したとき、特別な出力がないのが正常動作です。 + +{{% /notice %}} \ No newline at end of file diff --git a/content/running-amazon-ec2-workloads-at-scale/setup_cli.ja.md b/content/running-amazon-ec2-workloads-at-scale/setup_cli.ja.md new file mode 100644 index 00000000..cff54ff4 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/setup_cli.ja.md @@ -0,0 +1,16 @@ ++++ +title = "AWS CLIおよび関連ツールの導入" +weight = 50 ++++ + +1. Cloud9環境から以下のコマンドを発行し、最新のAWS CLIがインストールされていることを確認します。必要に応じて最新版がインストールされるようにします。 + + ``` + sudo pip install -U awscli + ``` + +1. このワークショップで用いるツール群を次のコマンドで導入します。 + + ``` + sudo yum -y install jq amazon-efs-utils + ``` \ No newline at end of file diff --git a/content/running-amazon-ec2-workloads-at-scale/spot_resilience.ja.md b/content/running-amazon-ec2-workloads-at-scale/spot_resilience.ja.md new file mode 100644 index 00000000..49f7eb17 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/spot_resilience.ja.md @@ -0,0 +1,91 @@ ++++ +title = "スポットインスタンスを利用するシステムの堅牢化" +weight = 155 ++++ + +### スポットインスタンス中断への対処 +あるアベイラビリティゾーンのあるインスタンスタイプにおいてキャパシティが不足するとき、EC2サービスはキャパシティを回復させる必要があります。このとき、対象のアベイラビリティゾーンにおけるインスタンスタイプにスポットインスタンスが起動していれば、EC2サービスは該当するスポットインスタンスに2分前の中断通知を送付し、スポットインスタンスを中断することでEC2キャパシティの回復に充てます。2分前の中断通知はインスタンスメタデータサービス、およびCloudWatch Eventsから受け取ることができます。中断通知の詳細は[こちら](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#spot-instance-termination-notices)のドキュメントを参照してください。 +ここでは、中断通知イベントをCloudWatch Events経由で受信し、それをトリガーにLambda関数を実行する仕組みを構築します。中断通知イベントは`EC2 Spot Instance Interruption Warning`という名称です。Lambda関数には、中断対象とマークされたスポットインスタンスをAuto Scalingグループからデタッチ([DetachInstances](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DetachInstances.html))する動作を記述します。デタッチの詳細はEC2 Auto Scalingユーザーガイドの[Auto Scaling グループからの EC2 インスタンスのデタッチ](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/detach-instance-asg.html)を参照してください。 + + 1. まず検討すべきポイントは、スポットインスタンスをデタッチするタイミングでAuto Scalingグループの希望容量を1台減らすのか、それとも台数変更なしにするのか、という点です。もし希望容量を変更しない場合、デタッチの直後にAuto Scalingサービスが新しいインスタンスを自動的に起動します。 + + 1. 次に、今回のワークショップのようにAuto Scalingグループがロードバランサー配下に登録される場合、インスタンスがAuto Scalingグループからデタッチされるとき、ロードバランサーからも登録解除(deregister)されます。このとき、ロードバランサー(あるいはターゲットグループ)にConnection Draining(あるいは登録解除の遅延とも呼ばれます)が設定されていれば、Auto Scalingは処理中のコネクションが終了するまでデタッチを待ちます。今回、このタイムアウト値は中断通知の長さに合わせて120秒を設定しています。 + +EC2 Auto Scalingのデタッチ動作については[こちらのドキュメント](https://docs.aws.amazon.com/autoscaling/ec2/userguide/detach-instance-asg.html)を参照してください。 + +ここでは、Lambda関数とClowdWatch Eventsを作成し、それぞれを関連付けるCloudFormationテンプレートを用いてこの仕組みを構築します。 + + 1. CloudFormationテンプレートの内容を確認し、次のコマンドでスタックを作成します。 + + ``` + aws cloudformation deploy --template-file spot-interruption-handler.yaml --stack-name spotinterruptionhandler --capabilities CAPABILITY_IAM + ``` + + 1. スタックの作成が完了したらば[Lambdaコンソール](https://console.aws.amazon.com/lambda/home)を開き、新規作成された関数名をクリックします。作成完了の目安は2分以内を想定しています。 + + + 1. 作成されたLambda関数の内容を確認します。Cloud9のインラインコードエディタを活用してください。 + +これでスポットインスタンスの中断通知を受け取り、そのインスタンスを自動的にAuto Scalingグループからデタッチさせることができるようになりました。中断そのものをシミュレーションすることはできませんが、ここではLambda関数のテスト機能を使い、処理が正しく実行されるかを確認します。 + + 1. Labmdaコンソール右上にあるドロップダウンメニューから「テストイベントの選択」をクリックしてドロップダウンメニューを表示させ、「テストイベントの設定」を選択します。グレーアウトされている場合にもそのままクリックし、ドロップダウンメニューを表示できます。 + 1. 「テストイベントの設定」ダイアログボックスではイベント名に任意の名前を設定し(TestSpotInterruptionなど), 次のjsonを入力します。 + + ```json + { + "version": "0", + "id": "92453ca5-5b23-219e-8003-ab7283ca016b", + "detail-type": "EC2 Spot Instance Interruption Warning", + "source": "aws.ec2", + "account": "123456789012", + "time": "2019-11-05T11:03:11Z", + "region": "eu-west-1", + "resources": [ + "arn:aws:ec2:eu-west-1b:instance/" + ], + "detail": { + "instance-id": "", + "instance-action": "terminate" + } + } + ``` + + 1. このjsonに2箇所存在する**"\"**を、作成したAuto Scalingグループ内の任意の1台のインスタンスIDで置き換えます。インスタンスIDは[EC2 Auto Scalingコンソール](https://console.aws.amazon.com/ec2/autoscaling/home#AutoScalingGroups:view=details)のインスタンスタブから確認できます。 + + 1. 作成を押します。 + 1. 「テストイベントの選択」で先ほど選択したテストイベントを選択し、「テスト」ボタンをクリックします。 + 1. 画面上部に実行結果の成功が表示されます。「詳細」をクリックして内容を確認します。 + 1. [EC2 Auto Scalingコンソール](https://console.aws.amazon.com/ec2/autoscaling/home#AutoScalingGroups:view=details)から対象Auto Scalingグループの「アクティビティ履歴」タブを開き、成功ログとして"Instance i-01234567890123456 belongs to AutoScaling Group runningAmazonEC2WorkloadsAtScale. Detaching instance..."のようなメッセージが出ていることを確認します。またその直後のログに新しいインスタンスの起動が記録されているのを確認します。 + 1. [EC2 ELBターゲットグループコンソール](https://console.aws.amazon.com/ec2/v2/home?1#TargetGroups:sort=targetGroupName)から今回のターゲットグループを選択し、ターゲットタブを開きます。該当インスタンスがdrainingのステータスになっていることを確認します。 + +ここまでの手順で、スポットインスタンスの中断通知を受けたタイミングでシームレスに新しいスポットインスタンスを起動し、スポットインスタンスが終了する前に安全に入れ替える仕組みを構築することができました。 + +{{% notice warning %}} +実際に中断が発生する場合、Auto ScalingグループからデタッチしたインスタンスはEC2スポットサービスにより自動的に終了(Terminate)されます。今回は単に中断イベントをシミュレーションしただけであったためインスタンスは終了されません。デタッチしたインスタンスを忘れずに終了させてください。 +{{% /notice %}} + + +### スポットインスタンスを利用するシステムの堅牢化 + +これまでスポットインスタンスの起動に際して、アベイラビリティゾーンごとに最も安い順に4種類のインスタンスタイプを9種類のインスタンスタイプから選択できるように構成してきました。ここからさらに、使用するインスタンスタイプとアベイラビリティゾーンの組み合わせを増やすことで、特定のスポットキャパシティプール(アベイラビリティゾーンとインスタンスタイプの組み合わせ)での中断の影響を緩和していくことができます。 + +#### チャレンジしてみましょう + +今回作成したスポットインスタンスによる音楽ストリーミングアプリケーションをより堅牢にするために、どのような構成の改善を検討したらよいでしょうか。 + +{{%expand "考え方の一例" %}} + +1. アベイラビリティゾーンを追加します。今の設定では2つのアベイラビリティゾーンを定義しています。ここにもうひとつアベイラビリティゾーンを追加することで、ある1箇所のスポットキャパシティプールでキャパシティが不足し、スポットインスタンスの中断が発生するとき、引き続きワークロードを受けることのできる可能性を高めることができます。 + +2. インスタンスタイプを追加します。さらに増やせば増やすほど中断発生する確率を下げることができます。今回は9種類のインスタンスタイプを定義していますが、さらに追加できるものがあるでしょうか。 + +3. スポットインスタンスを起動する対象となるスポットキャパシティプールを増やします。今回は9種類のインスタンスタイプのうち、4種類を上限に指定しました。これを増やすことで使用できるインスタンスタイプの多様性を高めることができ、中断発生確率の低下につながります。 +{{% /expand %}} + +#### チャレンジしてみましょう +スポットインスタンスの配分戦略には、今回選択したlowest-priceの他にどのようなものがあるでしょうか。今回のワークロードに最も適した配分戦略はどれになるでしょうか。 +ヒント：新しい配分戦略についての[記事] (https://aws.amazon.com/blogs/compute/introducing-the-capacity-optimized-allocation-strategy-for-amazon-ec2-spot-instances/)を参照してください。 + +{{%expand "Click here for the answer" %}} +今回はいわゆるステートレスなアプリケーションを構築しました。これよりも中断を許容しにくい、ステートがインスタンス内に残るようなアプリケーションなどを検討する場面では、capacity-optimizedと呼ばれる配分戦略を選択することを検討してください。AWSがその時点で最も中断の発生しにくいスポットキャパシティプールを自動的に選択し、そこからスポットインスタンスを立ち上げる配分戦略です。 +{{% /expand %}} diff --git a/content/running-amazon-ec2-workloads-at-scale/stress_ssm.ja.md b/content/running-amazon-ec2-workloads-at-scale/stress_ssm.ja.md new file mode 100644 index 00000000..9bc05bad --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/stress_ssm.ja.md @@ -0,0 +1,26 @@ ++++ +title = "AWS Systems Managerで負荷をかける" +weight = 150 ++++ + +AWS Systems Manager は、AWS でご利用のインフラストラクチャを可視化し、制御するためのサービスです。Systems Manager を使用すると、統合ユーザーインターフェイスで AWS のさまざまなサービスの運用データを確認でき、AWS リソース全体に関わる運用タスクを自動化できます。AWS Systems Manager を使うと、AWS で実行されるサーバーと、オンプレミスのデータセンターで実行されるサーバーを、1 つのインターフェイスで管理できます。また、サーバーにインストールされた軽量なエージェントとセキュアな通信を確立し、管理タスクを実行できます。これは Amazon EC2 やオンプレミスで実行されている Windows および Linux オペレーティングシステムのリソース管理に役立ちます。 + +ここではSSMのリモートコマンド機能を使って、各インスタンスに負荷をかけ、自動スケールされることを確認します。 + +1. **ssm-stress.json**の内容を確認します。内容の変更は不要です。各インスタンスに負荷をかけるため、次のコマンドを実行します。 + + ``` + aws ssm send-command --cli-input-json file://ssm-stress.json + ``` + +1. [AWS Systems Manager コンソール](https://console.aws.amazon.com/systems-manager/run-command/executing-commands)を開き、実行したコマンドの実行状況を確認します。 + +1. [CloudWatchコンソール](https://console.aws.amazon.com/cloudwatch/home?#alarm:alarmFilter=ANY)を開き、ターゲット追跡ポリシーに設定したアラームが発火するのを待ちます。 + +1. [Auto Scalingコンソール](https://console.aws.amazon.com/ec2/autoscaling/home#AutoScalingGroups:view=details)を開き、対象Auto Scalingグループの「アクティビティ履歴」および「インスタンス」タブを確認します。コマンド投入から数分でターゲット追跡ポリシーに設定したCPU使用率アラームが閾値に達し、スケールアウトが実行されます。 + +{{% notice info %}} +AWSアカウントを作って間もない場合、もしくはスポットインスタンスをこれまでに起動したことがない場合、作成したAuto Scalingグループが希望容量までスケールアウトできないことがあります。このステップはインスタンス台数が少なかったとしてもワークショップの進行に影響しないため、「アクティビティ履歴」にスケールアウト失敗のメッセージがあった場合には無視して構いません。 +{{% /notice %}} + +1. [AWS CodeDeployコンソール](https://console.aws.amazon.com/codesuite/codedeploy/deployments)を開き、画面右上のリージョン設定を確認した上で、新規起動されたインスタンスに正しくアプリケーションがデプロイされることを確認します。 diff --git a/content/running-amazon-ec2-workloads-at-scale/using_cloud9.ja.md b/content/running-amazon-ec2-workloads-at-scale/using_cloud9.ja.md new file mode 100644 index 00000000..eb966951 --- /dev/null +++ b/content/running-amazon-ec2-workloads-at-scale/using_cloud9.ja.md @@ -0,0 +1,22 @@ ++++ +title = "Cloud9環境の使用" +weight = 40 ++++ +AWS Cloud9はsudo権限のあるターミナルとセットアップ済みのAWS CLI環境を提供する、統合開発環境です。AWS Cloud9はお使いのアカウントにEC2インスタンスを起動し、その上にこれらの環境を自動的にセットアップします。AWS Cloud9を用いることで、Linuxコマンドの発行とCLIからのAWSサービスへのアクセスが非常に容易になります。 + +このワークショップでは、AWS Cloud9環境はCloudFormationスタック経由で起動されます。ワークショップ本体のCloudFormationスタックと別に、もう一つのCloud9用のCloudFormationスタックが作られています。 + +{{% notice note %}} +このワークショップでは、以後の操作をこのCloud9環境から実施するものとします。お手元のローカルのコンピューターからの操作ではないことに注意してください。 +{{% /notice %}} + +1. CloudFormationスタック出力に含まれる **cloud9Environment** を確認し、お使いのアカウントに起動されたAWS Cloud9環境名を確認します。 + +1. [AWS Cloud9 マネジメントコンソール](https://console.aws.amazon.com/cloud9/)を開きます。 + +1. **Your environments**から**Open IDE**を開きます。 +{{% notice note %}} +特に複数Cloud9環境がある場合、今回このワークショップで作成したCloud9環境にアクセスしていることを確認してください。"Description"に"Running Amazon EC2 Workloads at Scale - Cloud9 environment"と記載されているのが今回のワークショップ用環境です。 +{{% /notice %}} + +1. 今回がCloud9に触れる初めての機会である場合、すこし時間を取ってCloud9環境に慣れ親しんでください。Cloud9の[クイックツアー](https://docs.aws.amazon.com/ja_jp/cloud9/latest/user-guide/tutorial.html#tutorial-tour-ide)を通読しても良いでしょう。 \ No newline at end of file