クラスタープレイスメントグループのパフォーマンスを検証する構成
クラスタープレイスメントグループのパフォーマンスを検証する構成をご紹介します。
プレイスメントグループとは、EC2インスタンスが起動するハードウェアを指定することができるオプションです。
新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。
プレイスメントグループ
プレイスメントグループは3種類ありますが、中でもクラスタープレイスメントグループは、EC2インスタンス間のネットワークパフォーマンスの向上が期待できます。クラスタープレイスメントグループ内に配置されたEC2インスタンスは、同一のAZ内に配置させることになるため、ネットワークパフォーマンスの向上に繋がります。
クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。(中略) 同じクラスタープレイスメントグループ内のインスタンスは、TCP/IP トラフィックのフローあたりのスループット上限が高くなり、ネットワークの二分帯域幅の広い同じセグメントに配置されます。(中略) 低いネットワークレイテンシー、高いネットワークスループット、またはその両方からメリットを受けるアプリケーションの場合は、クラスタープレイスメントグループの使用をお勧めします。
クラスタープレイスメントグループ
構築する環境
サブネット内に、クラスタープレイスメントグループを設置します。そして同グループ内に、2台のEC2インスタンスを配置します。
クラスタープレイスメントグループの性能の確認ですが、pingコマンドを使って、以下の手順で実施します。
- クラスタープレイスメントグループ内に設置したEC2インスタンス間でpingを実施し、RTT値を測定する。
- 両EC2インスタンスのクラスタープレイスメントグループ設定を削除する。
- 再度、EC2インスタンス間でpingを実施し、RTT値を測定する。
ハンズオン用のCloudFormationテンプレートファイル
上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置します。
テンプレートファイルのポイント解説
今回の環境を構成するための、各テンプレートファイルのポイントを取り上げます。
クラスタープレイスメントグループ作成
saa-02-001-ec2.yamlでクラスタープレイスメントグループやEC2インスタンスを定義します。
まずEC2インスタンスを配置するクラスタープレイスメントグループを作成します。
Resources:
PlacementGroup:
Type: AWS::EC2::PlacementGroup
Properties:
Strategy: cluster
Code language: YAML (yaml)Strategyプロパティで作成するプレイスメントグループのタイプを指定します。今回はクラスタータイプを作成するため、「cluster」を指定します。
EC2インスタンスをクラスタープレイスメントグループ内に配置
EC2インスタンス作成時に、先ほど作成したクラスタープレイスメントグループに配置するように設定します。
Parameters:
InstanceType:
Type: String
Resources:
Instance1:
Type: AWS::EC2::Instance
Properties:
IamInstanceProfile: !Ref InstanceProfile
ImageId: !Ref ImageId
InstanceType: !Ref InstanceType
PlacementGroupName: !Ref PlacementGroup
NetworkInterfaces:
- DeviceIndex: 0
SubnetId: !Ref PrivateSubnet
GroupSet:
- !Ref InstanceSecurityGroup
Code language: YAML (yaml)PlacementGroupNameプロパティで配置するプレイスメントグループを指定します。今回は先ほど定義したクラスタープレイスメントグループに配置しますので、組み込み関数Fn::Refを使用して参照します。
クラスタープレイスメントグループにインスタンスを配置する上で、インスタンスタイプは要注意です。クラスタープレイスメントグループに配置可能なインスタンスタイプには制限があります。
クラスタープレイスメントグループには、以下のルールが適用されます。クラスタープレイスメントグループのインスタンスでは、サポートされている以下のインスタンスタイプを使用する必要があります。バーストパフォーマンスインスタンス (T2 など) と Mac1 インスタンスを除く現世代のインスタンス。
プレイスメントグループのルールと制限
上記に従い、今回はParametersセクションのパラメータ(InstanceType)に「m6g.medium」と指定し、これをInstanceTypeプロパティで参照することによって、クラスタープレイスメントグループに配置可能なインスタンスタイプとします。
上記(Instance1)と同様の設定がなされたEC2インスタンス(Instance2)を定義し、クラスタープレイスメントグループに2台を配置します。
環境構築
CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。
CloudFormationスタックを作成し、スタック内のリソースを確認する
CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください。
各スタックのリソースを確認した結果、今回作成された主要リソースの情報は以下の通りです。
- Instance1のID：i-025541ac55e8e6513
- Instance2のID：i-0909f7ff1d7e79819
- Instance1のプライベートDNS名：ip-10-0-1-19.ap-northeast-1.compute.internal
- Instance2のプライベートDNS名：ip-10-0-1-98.ap-northeast-1.compute.internal
- プレイスメントグループ名：saa-02-001-EC2Stack-VOI60JJZO8JG-PlacementGroup-1HJXNFRRDPDTY
続いてAWS Management Consoleからプレイスメントグループの状況を確認します。
Strategryの値がプレイスメントグループのタイプになります。「cluster」となっておりますので、正常にクラスタープレイスメントグループが作成できたことが確認できます。
EC2インスタンス側のプレイスメントグループ設定も確認します。
こちらも正常にインスタンスが作成されています。
確かに両インスタンスがプレイスメントグループに配置されていることが確認できます。
Session ManagerからEC2インスタンスにアクセス
SSM Session Managerを使用して、EC2インスタンスにアクセスします。
Instance1の方にアクセスします。
$ aws ssm start-session \
--target i-025541ac55e8e6513
...
sh-4.2$
Code language: Bash (bash)正常にアクセスすることができました。
ネットワークパフォーマンス計測：クラスタープレイスメントグループあり
Pingでクラスタープレイスメントグループの性能を評価します。
現在Session Managerでアクセスしているインスタンス(Instance1)から、もう一方のインスタンス(Instance2)に向かってPingを100発実行した際の値を測定します。
sh-4.2$ sudo ping -f -c 100 ip-10-0-1-98.ap-northeast-1.compute.internal
PING ip-10-0-1-98.ap-northeast-1.compute.internal (10.0.1.98) 56(84) bytes of data.
--- ip-10-0-1-98.ap-northeast-1.compute.internal ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 0.030/0.035/0.070/0.005 ms, ipg/ewma 0.059/0.035 ms
Code language: Bash (bash)意図通りに測定することができました。
RTTのavg(平均)が0.035msということで、応答速度がかなり早いことがわかります。
プレイスメントグループ設定の削除
クラスタープレイスメントグループ設定の有効性を確認するために、既存のプレイスメントループ設定を削除します。
配置済みのプレイスメントグループに関する設定の削除は、以下の手順で実施します。
- インスタンスを停止させる。
- インスタンスを配置するプレイスメントグループを空白に指定する。
- インスタンスを起動させる。
上記の手順をAWS CLIから実施します。
まずインスタンスを停止します。
$ aws ec2 stop-instances \
--instance-ids i-025541ac55e8e6513 i-0909f7ff1d7e79819
{
"StoppingInstances": [
{
"InstanceId": "i-025541ac55e8e6513",
"CurrentState": {
"Name": "stopping",
...
},
...
},
{
"InstanceId": "i-0909f7ff1d7e79819",
"CurrentState": {
"Name": "stopping",
...
},
...
}
]
}
Code language: Bash (bash)次にプレイスメントグループのグループ名を空白に修正し、既存のプレイスメントグループに関する設定を削除します。
$ aws ec2 modify-instance-placement \
--instance-id i-025541ac55e8e6513 \
--group-name ""
{
"Return": true
}
$ aws ec2 modify-instance-placement \
--instance-id i-0909f7ff1d7e79819 \
--group-name ""
{
"Return": true
}
Code language: Bash (bash)プレイスメントグループ設定が削除できましたので、再度インスタンスを起動します。
$ aws ec2 start-instances \
--instance-ids i-025541ac55e8e6513 i-0909f7ff1d7e79819
{
"StartingInstances": [
{
"InstanceId": "i-025541ac55e8e6513",
"CurrentState": {
"Name": "pending"
},
"PreviousState": {
"Name": "stopped"
}
},
{
"InstanceId": "i-0909f7ff1d7e79819",
"CurrentState": {
"Name": "pending"
},
"PreviousState": {
"Name": "stopped"
}
}
]
}
Code language: Bash (bash)インスタンスの起動後、改めてインスタンスの詳細を確認します。
両インスタンスのPlacement.GroupNameの値が「-」に変化しました。これでプレイスメントグループに関する設定が削除されたと判断できます。
ネットワークパフォーマンス計測：クラスタープレイスメントグループなし
改めてEC2インスタンスにアクセスし、パフォーマンスを測定します。
sh-4.2$ sudo ping -f -c 100 ip-10-0-1-98.ap-northeast-1.compute.internal
PING ip-10-0-1-98.ap-northeast-1.compute.internal (10.0.1.98) 56(84) bytes of data.
--- ip-10-0-1-98.ap-northeast-1.compute.internal ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 15ms
rtt min/avg/max/mdev = 0.036/0.138/0.388/0.117 ms, ipg/ewma 0.159/0.119 ms
Code language: Bash (bash)RTTのavg(平均)が0.138msということで、プレイスメントグループありと比べると、約4倍ほど時間がかかっていることがわかります。
Summary
今回はEC2インスタンスをクラスタープレイスメントグループ内に配置しました。
Pingによってネットワークパフォーマンスを評価し、速度が4倍程度向上することを確認しました。