はじめに
こんにちは、イノベーションセンターの鈴ヶ嶺です。 普段はクラウドサービスをオンプレミス環境でも同様のUI/UXで使用を可能とするハイブリッドクラウド製品の技術検証をしています。
過去に我々はAWS Outposts ラックの検証内容を公開しました。
今回本記事では、新たに導入したAWS Outposts サーバーの仕様、導入方法、利用方法について徹底解説します。
AWS Outposts とは
AWS Outpostsは、AWSのハイブリッドクラウド製品です。オンプレミス上に製品を設置してPublic AWSと同じような操作性でインフラストラクチャとサービスを作成できます。 主なユースケースは次の4つのケースが想定されます。
- 低レイテンシーコンピューティング
- 最寄りのパブリッククラウドサーバーでは通信遅延要件を満たさない場合、近距離地点にAWS Outpostsを設置することで低遅延な高速処理を実現できます。
- データレジデンシー
- 規制や情報セキュリティ上の理由から特定の所在地に保存する必要があるデータ(例えば金融・ヘルスケア情報など)について、AWS Outpostsを利用することでデータの常駐場所の制御を可能とします。
- 移行とモダナイゼーション
- 移行が難しいオンプレミスのレガシーシステムについて、クラウドへの移行準備ができるまでのホスティング先として利用できます。AWSへの接続性を活用して、クラウド移行を計画し、完了できます。
- ローカルデータ処理
- ローカルでプライベート処理することでセキュリティ上のリスクを低減します。コストやネットワーク帯域幅の問題により従来では処理不可能なデータセットを処理可能です。
Public AWSとAWS Outpostsの関係を示した図が次のようになります。物理的には独立していますが、論理的にはVPCを共有しAWS Outposts上にSubnetが作成されるような形式となります。また、コントロールプレーンは既存のPublic AWSのコンソールやAPIから利用します。つまり各拠点にAWS環境が延伸されるようなものとして考えるとわかりやすいかと思います。
2023年3月時点ではAWS Outposts ファミリーには以前紹介したAWS Outposts ラックと今回新たに紹介するAWS Outposts サーバーの2つがメンバーとして存在しています。
AWS Outposts サーバーとは
引用(OGP): https://aws.amazon.com/jp/blogs/news/new-aws-outposts-servers-in-two-form-factors/
AWS Outposts サーバーはAWS Outposts ラックとは異なり、1Uもしくは2Uの専用サーバーをデータセンターなどのオンプレミス環境に設置して使用します。 今までの「ラック」は、データセンターなどへの持ち込みラックの設置準備やサーバーに比べると高い使用料金が課題でしたが、サーバ型はそれらの課題を解消したモデルになっていると思われます。
ラックとサーバの価格設定の詳細については以下の詳細を参照してください。
以下がAWS Outposts サーバーでサポートされるサービス一覧です。
- AWS Outposts サーバーでサポートされるサービス一覧
- Amazon EC2
- Amazon ECS
- AWS IoT Greengrass
- Amazon Sagemaker Edge Manager
- Amazon Virtual Private Cloud
また、次のようにAWS Outposts ラックではサポートされていた機能が一部サーバーではサポートされていないためそれぞれの違いに注意が必要です。
- AWS Outposts サーバーではサポートされていないサービス一覧
- Amazon Elastic Kubernetes Service (EKS)
- Amazon Simple Storage Service (S3)
- Amazon Relational Database Service (RDS)
- Amazon Elasticache
- Amazon EMR
フォームファクタ
次の表が、2023年3月時点で利用可能なサイズ一覧です。 プロセッサにはx86やArm/Graviton2などのアーキテクチャが選択可能です。特にArm/Graviton2については低消費電力が大きな特徴のため、電力制約の規制が厳しいエッジ環境への設置やカーボンニュートラルへの取り組みにおける活用が期待されます。
Outpost リソース ID | ラックユニットの高さ | EC2 容量 | プロセッサ/アーキテクチャ | vCPU | メモリ | ローカル NVMe SSD ストレージ | ネットワークアップリンク | 消費電力 | 重量 | 電源タイプ |
---|---|---|---|---|---|---|---|---|---|---|
OR-STBKRBE | 1U | c6gd.16xlarge | Graviton2 / Arm | 64 | 128 GiB | 3.8 TB | 10 Gbps | 0.8 kVA | 13 kg | AC |
OR-LMXAD41 | 2U | c6id.16xlarge | インテル Ice Lake/x86 | 64 | 128 GiB | 3.8 TB | 10 Gbps | 1.5 kVA | 16 kg | AC |
OR-KOSKFSF | 2U | c6id.32xlarge | インテル Ice Lake/x86 | 128 | 256 GiB | 7.6 TB | 10 Gbps | 1.5 kVA | 16 kg | AC |
ネットワーク設計
AWS Outposts サーバーはPublic AWSと接続する管理系のリンクであるservice linkとローカル環境と接続するためのlocal network interface (LNI) linkがあります。次の図のように付属のQSFPブレイクアウトケーブルを利用しラベル1をLNI linkとして使用し、ラベル2をservice linkとして使用します。ラベル3-4のケーブルについては現時点では未使用となります。
引用: https://docs.aws.amazon.com/outposts/latest/server-userguide/install-server.html#install-network
次の図がネットワークの概要図です。
まずservice linkを用いてサーバーをアクティベートする必要があります。AWS Outposts サーバーには固定IPアドレスを設定する方法がないため、service linkにDHCPを用いてIPアドレスを設定します。その後、シリアル接続したコンソールから outposts.[設置region].amazonaws.com
エンドポイントへの疎通確認やIAM認証情報を用いてAWSと接続することでアクティベートが完了します。1
ローカル環境と接続されるLNI LinkはNetwork Interfaceに紐づく形で利用されます。利用するためには、まずAWS Outposts サーバー上のSubnetでLNIとして利用するNetwork Interface Indexを設定します。その後新たにNetwork Interfaceを作成し、該当のIndexとしてアタッチしてIPアドレスを設定することでローカル環境と接続できるようになります。実際の利用方法は後述するEC2の起動検証でも詳しく説明します。
引用: https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html
EC2の起動検証
AWS CLIベースで次の一連の処理を行いEC2の起動を検証します。
- VPCの作成
- AWS Outposts Subnetの作成
- SubnetのLNI有効化
- EC2 Instanceの起動
- user-dataによるLNI NetworkのIPアドレスとデフォルトルートの設定
- ローカル環境との疎通確認
# 事前設定 ## AWS Outposts サーバーARN OUTPOST_ARN='arn:aws:outposts:ap-northeast-1:XXXXXXXXXXXX:outpost/op-XXXXXXXXXXXXXXXX' ## sshのためのkeypair KEYPAIR='XXXXX' ## AWS Outposts サーバーのLNI Network(ローカル環境のNetwork)を192.168.10.0/24と想定 OUTPOST_LNI_EC2_IP='192.168.10.2' OUTPOST_LNI_SUBNET='24' OUTPOST_LNI_GATEWAY_IP='192.168.10.1' # 1. VPCの作成 VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \ --tag-specifications "ResourceType=vpc, Tags=[{Key=Name,Value=Outposts-Server-VPC}]" \ --query Vpc.VpcId --output text) # 2. AWS Outposts Subnetの作成 SUBNET_ID=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.1.0/24 \ --availability-zone ap-northeast-1a --outpost-arn $OUTPOST_ARN \ --tag-specifications "ResourceType=subnet, Tags=[{Key=Name,Value=Outposts-Server-Subnet01}]" \ --query Subnet.SubnetId --output text) # 3. SubnetのLNI有効化 aws ec2 modify-subnet-attribute --subnet-id $SUBNET_ID --enable-lni-at-device-index 1 # 4. EC2 Instanceの起動 ## Security Group作成 SG_ID=$(aws ec2 create-security-group --group-name Outposts-Server-SG \ --description "Default Security group" --vpc-id $VPC_ID \ --tag-specifications "ResourceType=security-group, Tags=[{Key=Name,Value=Outposts-Server-SG}]" \ --query GroupId --output text) ## Ubuntu22.04の最新AMIを取得 UBUNTU_AMI=$(aws ec2 describe-images --owners 099720109477 \ --filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64*" \ --query "reverse(sort_by(Images, &CreationDate))[0].ImageId" --output text) ## 4.1 user-dataによるLNI NetworkのIPアドレスとデフォルトルートの設定 cat << EOF > user-data.txt #!/bin/bash set -xe # 固定IPの設定 ip addr add $OUTPOST_LNI_EC2_IP/$OUTPOST_LNI_SUBNET dev ens6 # デフォルトゲートウェイの設定 ip route add default via $OUTPOST_LNI_GATEWAY_IP EOF ## ENI作成 ENI_ID0=$(aws ec2 create-network-interface --subnet-id $SUBNET_ID --groups $SG_ID \ --tag-specifications "ResourceType=network-interface, Tags=[{Key=Name,Value=Outposts-Server-ENI0}]" \ --query NetworkInterface.NetworkInterfaceId --output text) ENI_ID1=$(aws ec2 create-network-interface --subnet-id $SUBNET_ID --groups $SG_ID \ --tag-specifications "ResourceType=network-interface, Tags=[{Key=Name,Value=Outposts-Server-ENI1}]" \ --query NetworkInterface.NetworkInterfaceId --output text) ## EC2 Instance作成 INSTANCE_ID=$(aws ec2 run-instances --image-id $UBUNTU_AMI --instance-type c6id.8xlarge \ --key-name $KEYPAIR --user-data file://user-data.txt \ --network-interfaces "[{\"DeviceIndex\":0,\"NetworkInterfaceId\":\"$ENI_ID0\"},{\"DeviceIndex\":1,\"NetworkInterfaceId\":\"$ENI_ID1\"}]" \ --tag-specifications "ResourceType=instance, Tags=[{Key=Name,Value=Outposts-Server-Instance}]" \ --query 'Instances[0].InstanceId' --output text) # 5. ローカル環境との疎通確認 ssh ubuntu@$OUTPOST_LNI_EC2_IP
作成したEC2は次のスクリーンショットのようにAWS Management Consoleから確認できます。 EC2の画面からはPublic AWSかAWS Outposts サーバーのインスタンスかを判断できないためSubnetを確認します。
次のようにSubnetの詳細画面を見るとOutpost IDが紐づいていることが分かるため、AWS Outposts サーバーのインスタンスが正常に起動していることを確認しました。
また、LNIを有効化したネットワークインターフェイスはインターフェイスのタイプが「ローカルネットワークインターフェイス」と記述されていることが分かります。
ちなみに 5. ローカル環境との疎通確認 でSecurity Groupのインバウンド設定をしていないのになぜsshでEC2と疎通できるのか気になった方もいると思います。 これは以下のようにLNIはSecurity Groupを利用しない仕様のためです。
セキュリティグループとローカルネットワークインターフェイス
設計上、ローカルネットワークインターフェイスは VPC 内のセキュリティグループを使用しません。セキュリティグループは、インバウンドとアウトバウンドを制御します。VPC トラフィック。ローカルネットワークインターフェイスは、VPC にアタッチされていません。ローカルネットワークインターフェイスは、ローカルネットワークにアタッチされています。ローカルネットワークインターフェイスでインバウンドおよびアウトバウンドトラフィックを制御するには、他のオンプレミス機器でファイアウォールまたは同様の戦略を使用します。
引用: https://docs.aws.amazon.com/ja_jp/outposts/latest/userguide/how-servers-work.html
まとめ
本記事では
- AWS Outpostsについて
- AWS Outposts サーバーについて
- EC2の起動検証
について記載しました。
AWS Outposts サーバーは省スペースや電力規制が厳しい状況においても設置可能な新たなAWSのハイブリッドクラウド製品です。AWS環境をエッジに延伸しクラウドと同様の開発体験で低遅延処理やセキュリティ課題を解決する場合にはこれを機に AWS Outposts サーバーの利用を検討してみてはいかかでしょうか?