Amazon Timestream for InfluxDBをMulti-AZ構成にする時のサブネット指定について

しばたです。

前回の記事でAmazon Timestream for InfluxDBついて「どちらかというとRDSやDocumentDBの仲間と考えたほうが良さそう」と評しました。

https://dev.classmethod.jp/articles/personal-opinion-on-amazon-timestream-for-influxdb-202403/

ただ、Multi-AZ構成のアーキテクチャに関してはAmazon FSxシリーズの様に「優先サブネット」「スタンバイサブネット」に分かれ異常時のみスタンバイ側にフェイルオーバーする仕組みとなっています。
(Amazon Timestream for InfluxDBの用語としては「Availability zone」「Secondary availability zone」となります)

• 参考 : Failover process for Amazon Timestream

Multi-AZ構成にする時のサブネット指定

ここから本記事の主題となるのですが、マネジメントコンソールからサブネットを指定する場合、下図の様なシンプルなチェックボックスとなっており優先順位を明示できない様に見えます。

インスタンスを作成するCreateDbInstance APIにおいてもサブネット指定は単純なリスト形式となっており優先度を明示する形にはなっていませんでした。

"vpcSubnetIds": [ "string" ]

A list of VPC subnet IDs to associate with the DB instance. Provide at least two VPC subnet IDs in different availability zones when deploying with a Multi-AZ standby.

恐らくは「リストの要素順に優先度がきまるのかな？」と思い指定順序を変えてみたものの、実際の結果は異なりました。

(マネジメントコンソール上は左から要素が指定される。上図だと ap-northeast-1d, ap-northeast-1a の順になる)

(実際に作られた構成は指定順とは異なる結果に)

念のためCloudTrailログを見ても指定順に狂いはありませんでした。

    "requestParameters": {
        // ・・・省略・・・
        "vpcSubnetIds": [
            "subnet-<ap-northeast-1d>", // ap-northeast-1d (apne1-az2)
            "subnet-<ap-northeast-1a>"  // ap-northeast-1a (apne1-az4)
        ]
    }

2つのAZ指定順をそれぞれ変えて試した結果は以下の通りとなり、あたかも採用されるAZに優先度が付いてる様な結果になりました。

今回試した限りでは

• ap-northeast-1a (apne1-az4) → ap-northeast-1d (apne1-az2) → ap-northeast-1c (apne1-az1)

の順に優先度が高い結果になりました。

この結果が私のアカウントだけの挙動なのか？それとも全アカウントで共通した挙動なのかは何とも言えません。

ドキュメント上は「ランダムに決まる」とされている

改めてAWSのドキュメントを調べてみると、AZ構成に関して

When you create a DB instance, Amazon Timestream for InfluxDB choose one for you randomly based on your subnet configuration.

および

You can't choose the Availability Zones for the primary and secondary DB instances in a Multi-AZ DB deployment. Amazon Timesteram for InfluxDB chooses them for you randomly.

• What is Timestream for InfluxDB?

と記載されており、AWSの仕様としては「Multi-AZ構成におけるAZ指定はランダムに決まる」とのことです。

とはいえ私の環境で実際に試した限りでは完全ランダムではありませんでした。
まったく根拠は無いですが「アカウント毎で優先度が違うのかな？」「AZの利用状況に応じた重みづけが存在しているのかな？」という予想をしています。

余談1 : 指定できるサブネットは3つまで

CreateDbInstance APIの仕様を確認するとvpcSubnetIdsパラメーターは

Array Members: Minimum number of 1 item. Maximum number of 3 items.

とあり最大3サブネット(3AZ)指定可能となっています。

この場合も前述の優先度に従って優先AZとセカンダリAZが設定され、本日時点では特に3AZである意味をなさない感じでした。
(常に ap-northeast-1a (apne1-az4) → ap-northeast-1d (apne1-az2) の順で選ばれてしまったので...)

なお、4AZ以上指定した場合はこんなエラーになります。

サブネット must have 1 to 3 options selected.

(4AZ以上ある北米リージョンで試した例)

余談2 : サブネット指定時のキャプション

本記事にある画像を注意深く見ると、サブネット指定欄のキャプションが

対応する DB サブネットグループを持つ VPC のみが一覧表示されます。

であることに気が付きます。(というか記事を書いてるいま気が付きました...)
Amazon Timestream for InfluxDBに「DBサブネット」は存在しないので、RDSの仕組みを流用し誤った翻訳が付いている可能性が疑われます。

ちなみに、英語環境だと

Choose one or more subnets for your selected VPC.

と特に違和感のないキャプションとなっていました。

こういった細かい点からもRDSとの親和性が見て取れます。

補足 : AWS CLIでインスタンスを作成する方法

最後に今回の検証に使ったAWS CLIコマンドを共有しておきます。

インスタンスの作成はaws timestream-influxdb create-db-instanceコマンドで行い、PowerShell環境であれば最低限以下の様な形で実行できます。

• 参考 : ヒアドキュメントを使ってAWS CLIの –cli-input パラメーターを便利に使う

# PowerShell 7.4環境で実施
$params = @"
{
    "name": "my-multi-az-db",
    "username": "test-user",
    "password": "********",
    "organization": "test-org",
    "bucket": "bucket1",
    "dbInstanceType": "db.influx.medium",
    "dbStorageType": "InfluxIOIncludedT1",
    "allocatedStorage": 20,
    "deploymentType": "WITH_MULTIAZ_STANDBY",
    "vpcSubnetIds": [
        "subnet-<ap-northeast-1c>",
        "subnet-<ap-northeast-1a>",
        "subnet-<ap-northeast-1d>"
    ],
    "vpcSecurityGroupIds": [
        "sg-xxxxxxxxxxxxxxxx"
    ],
    "publiclyAccessible": false
}
"@
aws timestream-influxdb create-db-instance --cli-input-json $params

実行結果はこんな感じになります。

# コマンドを実行すると作成したインスタンス情報を返す
PS C:\> aws timestream-influxdb create-db-instance --cli-input-json $params
{
    "id": "xxxxxxxxxx",
    "name": "my-multi-az-db",
    "arn": "arn:aws:timestream-influxdb:ap-northeast-1:xxxxxxxxxxxx:db-instance/xxxxxxxxxx",
    "status": "CREATING",
    "dbInstanceType": "db.influx.medium",
    "dbStorageType": "InfluxIOIncludedT1",
    "allocatedStorage": 20,
    "deploymentType": "WITH_MULTIAZ_STANDBY",
    "vpcSubnetIds": [
        "subnet-<ap-northeast-1c>",
        "subnet-<ap-northeast-1a>",
        "subnet-<ap-northeast-1d>"
    ],
    "publiclyAccessible": false,
    "vpcSecurityGroupIds": [
        "sg-xxxxxxxxxxxxxxxx"
    ],
    "availabilityZone": "ap-northeast-1a"
}

REST APIおよびAWS CLIの仕様ではsecondaryAvailabilityZoneも作成と同時に取得できるとあるのですが、実際の結果には含まれていませんでした。

なお、aws timestream-influxdb get-db-instanceコマンドからならsecondaryAvailabilityZoneを取得できました。

おわりに

以上となります。

かなり予想と異なる挙動をしたので驚いています。
AWSの仕様としては「AZはランダムに決まる」ため、環境や時期によって本記事の内容と異なる結果になる可能性が非常に高いのでご注意ください。