Even though I work and work...

AWSメインのメモ。基本的に22:00に予約投稿

AWS Wavelengthの検証

はじめに

まず、AWS Wavelengthとは

AWS Wavelength は、AWS コンピューティングおよびストレージサービスを 5G ネットワーク内に組み込んで、超低レイテンシーアプリケーションの開発、デプロイおよびスケーリングのためのモバイルエッジコンピューティングインフラストラクチャを提供します。

とのこと。日本ではKDDIのネットワークエッジにて提供されています。

biz.kddi.com

主にネットワークの通信可否と監視周りで少し気になったため検証してみます。

検証のために構築した環境

検証環境構成図

構築の手順は下記を参照してください。
ドキュメント：Get started Wavelength
Qiita：AWS Wavelength を構築してみた

確認事項はこちら

  1. インスタンス間の通信可否
  2. Wavelength上のリソース情報をAPIで取得できるか
  3. System Managerが利用できるか
  4. New Relicを利用してEC2のメトリクスを収集できるか
  5. バックアップ（AMI、EBSスナップショット）

インスタンス間の通信可否

基本的な通信可否の把握、Carrier IPへの通信がどうなるのかの確認です。

結果

No. source dest TCP(http) ICMP(ping)
① ローカル wl-tokyo-1(Carrier IP) × ◯
② public-instance(Private IP) wl-tokyo-1(Private IP) ◯ ◯
③ public-instance(Public IP) wl-tokyo-1(Carrier IP) × ◯
④ wl-tokyo-1(Private IP) public-instance(Private IP) ◯ ◯
⑤ wl-tokyo-1(Carrier IP) public-instance(Public IP) ◯ ◯
⑥ wl-tokyo-2(Private IP) wl-tokyo-1(Private IP) ◯ ◯
⑦ wl-tokyo-2(Carrier IP) wl-tokyo-1(Carrier IP) ◯ ◯
⑧ wl-osaka-1(Private IP) wl-tokyo-1(Private IP) × ×
⑨ wl-osaka-1(Carrier IP) wl-tokyo-1(Carrier IP) × ◯

通信確認

詳細

各インスタンスにElastic IP、Carrier IPを割りあて、セキュリティグループは各IPに対してすべてのトラフィックを許可しました。
ICMPはpingで確認しています。
TCPはwl-publicとwl-tokyo-wにはningxをインストールし、wgetでデフォルトページが取得できるかを確認しました。

基本的に公開されている資料通りの結果でした。

Networking considerations AWS Wavelength最新情報(2020/12) p.9

想定外だったのは⑧のWZ間ではprivate IPでの通信ができないこと。 WZ間で通信したいとなるとCarrier IPを利用することになり、結果⑨を見るとInternetを経由しているようなのでTCPが利用できません。 上記のNetworking considerationsにも記載あり。

Multiple Wavelength Zone considerations
EC2 instances that are in two different Wavelength Zones in the same VPC are not allowed to communicate with each other. If you need communication from one Wavelength Zone to another Wavelength Zone, we recommends that you use multiple VPCs, one for each Wavelength Zone. You can use a transit gateway to connect the VPCs. This configuration enables communication between instances in the Wavelength Zones. For information about how to configure multiple Wavelength Zones, see Extend your VPC resources to Local Zones in theAmazon VPC User Guide.

別VPCにしてtransit gatewayでつないで〜とのこと。
複数の Wavelength Zone に関する考慮事項

おなじWZ内であればCarrier IP間の通信でもKDDI網を出ることはなく、HTTP通信が可能のようです。

Wavelength上のリソース情報をAPIで取得できるか

ネットワーク的に到達できないインスタンスの情報もAPIで取得できるのかの確認です。

結果

取得できました。 api、aws cli、boto3のドキュメントにもWavelengthのリソースに対する操作について記載があります。

例：CarrierGatewayの一覧取得
API Reference
aws cli
boto3

詳細

aws cliによるWavelength Zone（WZ）上のリソース操作は問題なく行えました。 リソース自体はWZに作成されるけれどもEC2などのコントロールプレーンはAWS側にあると理解しています。 スライド p.25にも「コントロールプレーンはリージョン側」と記載あり。（なんのコントロールプレーンかはわからないので当てにならないかもしれないけど）

例：WZに作成したinstanceをdiscribe

[cloudshell-user@ip-10-0-101-101 ~]$ aws ec2 describe-instances --instance-ids i-0123456789abcdef0
{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    "AmiLaunchIndex": 0,
                    "ImageId": "ami-0de5311b2a443fb89",
                    "InstanceId": "i-0123456789abcdef0",
                    "InstanceType": "t3.medium",
                    "KeyName": "wl-test-key",
                    "LaunchTime": "2022-11-17T01:52:04+00:00",
                    "Monitoring": {
                        "State": "disabled"
                    },
                    "Placement": {
                        "AvailabilityZone": "ap-northeast-1-wl1-nrt-wlz-1",
                        "GroupName": "",
                        "Tenancy": "default"
                    },
                    "PrivateDnsName": "ip-10-0-1-101.ap-northeast-1.compute.internal",
                    "PrivateIpAddress": "10.0.1.101",
                    "ProductCodes": [],
                    "State": {
                        "Code": 16,
                        "Name": "running"
                    },
    ... 以下略

System Managerが利用できるか

EC2を利用するなら必須なので！

結果

利用できました。

ドキュメントの対応サービスにも記載があります。

AWS resources on Wavelength

You can create Amazon EC2 instances, Amazon EBS volumes, and Amazon VPC subnets and carrier gateways in Wavelength Zones. You can also use the following:

The services in Wavelength are part of a VPC that is connected over a reliable connection to an AWS Region for easy access to services running in Regional subnets.

詳細

WZに作成したインスタンスにSSM Agentをインストールし、

  • フリートマネージャーに表示されるか
  • SessionManagerによる接続ができるか
  • Run Commandを実行してagent updateを実行できるか

を確認しました。いずれも問題なく実行完了。
Private subnetの場合はVPCエンドポインを設定できますが、WZに作成したサブネットはエンドポイントの対象に出てきません。 なのでCarrier IPを割り当てる必要があります。

フリートマネージャーでの表示

バックアップ（AMI、EBSスナップショット）

これは以前にどこかでエラーが出ると聞いたことがあったので...

結果

WZに作成したインスタンスのAMIとEBSスナップショットを手動で作成したところ、 AMI、EBSスナップショットのいずれも問題なく実行でき、ステータスも利用可能でした！

New Relicを利用してEC2のメトリクスを収集できるか

問題なく収集できるはずですが、念の為。

結果

インフラストラクチャモニタリングにおいて、AWSインテグレーションによるメトリクスの取得やAgentからのメトリクス送信は可能でした。 外形監視はネットワーク構成上不可能であるため検証していません。

詳細

WZ上に作成したインスタンスにNew Relic Agentをインストールし、 インフラストラクチャモニタリングのHostに出力されるか、各種メトリクスが取得されているかを確認しました。 ログも問題なく収集できています。

NewRelic Logs

外形監視について

New Relicの外形監視は基本的にHTTPなので、ネットワークの制約上利用不可です。 DataDogはICMPを利用する設定があるので、それならば利用できる可能性があります。
また、New Relic、DataDogともにプライベートロケーションからの監視機能があるので、動作確認はしていませんが、WZに接続可能なAWS側のsubnetでこれらを利用すればPrivate IP経由での外形監視はできそうです。

New Relic プライベートロケーションの概要
DataDog Synthetic テストをプライベートロケーションから実行する

おわりに

簡単ではありますが動作検証でした。
なかなか情報をえられないサービスであるため良い勉強になりました。

参考

サービスページ：AWS Wavelength
ドキュメント：AWS Wavelength ドキュメント
Youtube：IoT@Loft#18 大阪リージョンとAWS Wavelengthの紹介
スライド：IoT@Loft#18 大阪リージョンとAWS Wavelengthの紹介
スライド：AWS Wavelength最新情報(2020/12)

【X-ray】概要と本番環境への段階的な導入案

まず、X-Rayとは

AWS X-Ray は、リクエストがアプリケ ーションを通過する際の完全なビューを提供し、ペイロード、関数、トレース、サービス、API などのビジュアルデータをノーコードおよびローコードモーションでフィルタリングします。

https://aws.amazon.com/jp/xray/

とのこと。
Lambda や API Gatewayなどの場合は設定を有効化するだけでも利用できるため、Lambdaを主体としたサーバーレス構成であれば比較的容易に導入できます。

アプリケーションコードへの埋め込みはX-Ray SDK、AWS SDK、AWSDistro for openTelemetryの３つの方法がありますが、

  • 基本的には手軽に X-Ray SDK
  • よりフレームワークやアプリケーションに即したトレーシングの実装が必要な場合はAWS SDK
  • 複数のモニタリング先に対してトレースを送信する必要がある場合にはAWSDistro for OpenTelemetry

といったような使い分けができます。
X-Rayの主な用途としては

などで、もう少し具体的なユースケースをあげてみると、

  • 負荷試験時のみ集中的に利用し、パフォーマンスチューニングを行う。
  • 本番環境において、クリティカルなパスについてはすべてトレースするようにし、問題発生時の調査を可能にする。それ以外のパスについてはサンプリングレートを調整し、統計的なモニタリングを行う。
  • ステージング環境や開発環境ではすべてをトレースするように設定し、ボトルネックやパフォーマンス劣化を早期発見できるようにする。

などなど。

いくらか注意事項もあります。

たとえばサンプリングレートの都合でエラー監視には向いていません。
サンプリングレートが1より小さいとエラーを取り逃がすことがあり、すべてをサンプリングしようとレートを1にするとコストが増加する可能性が高く、また同時に負荷も増加する可能性があります。
そのため、エラー監視については別途行う必要があります。

また、多少パフォーマンスへの影響があります。
これについてはサンプリングレートの調整、アノテーションを活用したフィルタリング、対象リソースの制限などによりサンプリングルールや取得期間を設定し、サンプリングをコントロールすることで対応可能です。

つまり、コストやアプリケーションへの負荷を考慮する必要があるため、導入の範囲やトレースのサンプリングは適切にコントロールする必要があるのです。

既存の本番環境へX-Rayを導入する場合にはやはりこのあたりの負荷や本番環境へのコードの追加がネックになりがちなイメージです。
その対策案として適用範囲を限定的に、段階的に拡大して導入していくのがよいのではないかと考えます。

例えば、API Gateway、Lambda、DynamoDB、S3というよくあるサーバーレス構成でパフォーマンス劣化が生じてきており、その原因と特定し、以降は継続的なモニタリングを行いたいとします。そのときに

  1. 詳細な調査の対象となるLambdaを絞り込む（コード追加不要）
    API Gateway、Lambdaにおいてアクティブトレースを有効化し、十分な期間データを蓄積する。
    コンソールにて詳細な調査の対象となるパスや処理とそれに関連するLambdaを絞り込む。
  2. 詳細なトレースを取得し、原因となる処理を特定する（特定のLambdaのみコード追加、サンプリングの調整）
    対象のLambdaにAWS X-Ray SDKを導入し、サブセグメント等を設定する。
    サンプリングルールにて対象となるリソースARNやURLを指定する。
    コンソールにて分析を行い、パフォーマンス劣化の原因となる処理を特定する。
  3. 全体にSDKを導入し継続的にモニタリングを行う
    2の対応が完了した後に、他のLambdaへX-Ray SDKを導入し、サンプリングレートの調整やクリティカルな処理へのサブセグメント設定などを行ったうえで常時有効化する。

というようなイメージです。 もちろん上記は全てが上手くいったパターンではありますが、段階的な導入を行うことでX-Rayの知見やアプリケーションへの適用方法などを蓄積していく期間を設けることができるため全体に適用する際にもスムーズに移行でき、影響範囲を限定的にする以外にもメリットが得られるのではないでしょうか。

AWSでDevOpsを実践するための資料整理

AWSでDevOpsを実践するためのステップと関連資料の整理です。 DevOps自体がなかなかに掴みづらいところもあり、実際に問題に取り組んでいくことで理解が深まることも多いので、
その準備としてDevOpsの知識や関連するAWSサービスの理解など、引き出しを増やすために取り組むと良いことをAWSのリソースにフォーカスしてまとめました。

DevOpsの概要を理解する

DevOpsとは？
https://aws.amazon.com/jp/devops/what-is-devops/

AWSのDevOpsについてのページ。
DevOpsやプラクティスの概要、関連するサービスの紹介など。

ハンズオン

ハンズオンはやはりAWSで用意されているものが簡潔でサービスの理解に非常に役立ちます。

ラーニングパス：DevOps エンジニア

https://aws.amazon.com/jp/getting-started/learning-path-devops-engineer/

AWS Hands-on for Beginners

AWS認定資格取得

DevOpsとは何かを理解し、実際に手を動かしてイメージを掴めたら、知識の補強と確認のために資格取得を目指しましよう。 それぞれの資格の学習リソースは各資格のページより参照してください。

AWS Certified SysOps Administrator - Associate（SOA）

AWS 上でのデプロイ、管理、オペレーションのワークロードの経験を証明します。

https://aws.amazon.com/jp/certification/certified-sysops-admin-associate/?ch=sec&sec=rmg&d=1&refid=ba_card

AWS Certified Developer - Associate（DVA）

クラウドベースのアプリケーションで書き込みおよびデプロイを行う能力を認定します。

https://aws.amazon.com/jp/certification/certified-developer-associate/?ch=sec&sec=rmg&d=1&refid=ba_card

AWS Certified DevOps Engineer - Professional（DOP）

AWS インフラストラクチャとアプリケーションのテストとデプロイを自動化する能力が認定されます。

https://aws.amazon.com/jp/certification/certified-devops-engineer-professional/?ch=sec&sec=rmg&d=1

その他関連資料

その他、DevOpsの理解に役立つ資料など。

The Amazon Builders' Library