Amazon EFS 東京リージョンの限界を試す

最近激変のAmazon EFS

みんなが首を長くして待っていたAmazon Elastic File System (Amazon EFS)。
2018年7月末のJAWS-UG愛媛支部で Amazon EFS東京 Deep Dive という話をしたところスライド公開を求められるも、
あれから１ヶ月経たぬ間に大きく変わってしまったため代わりに本記事を。
この記事は濃い目で基本的なサービスの説明等はしていないのでそういうのは公式へ。

EFSはNFSに似ているけどEFS

• 広義にはマネージドNFSサーバサービスだけど、NFSサーバだと思って使うと問題に直面するので注意
• 非対応な機能が多数ある（以下は主な例）
  • ルートスカッシュ
  • ロック
  • pNFS
  • Setuid, Setgid
  • Kerberosによるセキュリティ

EFSを利用する上の注意点

• アクセス制御はセキュリティグループで守るしか方法が無い（重要）
• EFSはアクセスされたUIDを信頼し無認証で動作する
  • ネットワーク的に接続可能であれば全てのアクセスが許可される。
  • 前述の通りルートスカッシュが無いので uid 0 はrootとして動作する。
  • これは野良端末が接続可能だと全ファイルを削除も可能であるということを意味する。
  • セキュリティグループの設定は厳格に（再掲）
• 使用するAZに必ずマウントターゲットを設定すること
  • VPCのルーティングに基づき通信可能であれば他のサブネットや他のAZからでもアクセス可能なため、他のAZへ通信が発生するとAZ間通信として課金される。
• 高くはないが安くもないEFSの料金
  • 月額$0.36/GiB。10TiBでは月額$3600に。
  • 実際には1時間毎に(?)使用容量が計測され時間課金の累計。（10TiBで毎時$5）
  • Amazon EBS 汎用SSD(gp2) ボリュームの３倍の料金なので高くはないが容量が増えるとそれなりの料金になる。

容量表示は不定期更新

df コマンドなどで表示される容量表示は不定期に更新される。

# du -s /efs/
1536000004      /efs/
# df /efs/
ファイルシス        1K-ブロック     使用           使用可 使用% マウント位置
172.31.30.23:/ 9007199254739968        0 9007199254739968    0% /efs
#

ファイルが存在しduコマンドで使用容量が表示されているにもかかわらず、dfコマンドでは使用容量 0 と表示される。
ファイルシステム作成後２時間近く経過してもこの状況なので必ずしも１時間毎に更新されるわけではないようだ。
料金請求に用いられる容量計算の値が用いられていると思われるがその計算周期は不明。

２つのパフォーマンスモード

• 「汎用パフォーマンスモード」は標準

• 「最大I/Oパフォーマンスモード」は同時アクセス数が多い場合の性能が向上するがファイル操作が体感ではわからない程度だが遅くなる。

• 殆どの場合「汎用パフォーマンスモード」で良い。

  • PercentIOLimit Amazon CloudWatchメトリクスが100%近くなった場合のみ「最大I/Oパフォーマンスモード」を検討。
  • 「最大I/O」にしても接続毎の転送速度が高速になるわけではなく、逆にファイル操作が若干遅くなるため上記メトリクスで問題になった場合以外は「汎用パフォーマンスモード」の方が高速。

• 注意：これはファイルシステム作成時に選択し作成後は変更不可。よって必ず最初に汎用で検証すべし。

通信経路の暗号化 (新しい)

• 通信経路上のTLS1.2による暗号化に対応した。
• stunnelによる実装。NFS自体が通信経路の暗号化に対応したわけではない。
• 主要なLinuxでは amazon-efs-utils パッケージを導入すると -o tls 指定のみで通信経路可能。
• amazon-efs-utilsはGitHubで公開されておりオンプレミス等からの利用も可能 https://github.com/aws/efs-utils

(参考) EFSに保存されるデータはサービス開始当初から暗号化が可能。(AWSによる自動鍵管理またはKMSユーザ鍵管理)

EFSの性能について

• ファイルシステム全体の総容量で決定される。
• 総容量1TiBから本来の性能となる。1TiB未満は制限あり。
• 総容量は１時間毎に再計算される。
• 総容量1TiBに達するまでは性能に制限があるが、ファイルシステム作成時に2.1TiBのクレジットバランス（後述）が付与されるため、これによりバースト（後述）可能な間にファイルを増やすと良い。
• ベースラインとバースト
  • ベースラインは基本性能。総容量1TiBあたり50MiB/sの速度。
  • バーストは毎日12時間基本性能の２倍の速度が提供される。ただし総容量1TiB未満の場合は速度100MiB/s固定で提供時間が容量比例で減る。
  • バースト可能時間はクレジットバランスで管理される。(t系EC2インスタンスのCPU時間に同じ）
  • クレジットバランスは毎日総容量1TiBあたり2.1TiBのクレジットバランスが付与される。（つまり毎日50%の時間バースト可能）

旧プロビジョンドスループット (既に廃止）

• 2018年7月、クレジットバランスが無くなっても追加費用を支払うことで常時バーストする機能が登場した。(T2 unlimitedのような)
• バースト可能時間には制限があり、この制限を超えたい場合に使用する。
• 小容量（総容量1TiB未満）でも常に100MiB/sの速度を得られる。
• 名前がまぎらわしいが、任意のスループットを設定できるわけではない。
• 設定してもただちに課金されるわけではない。クレジットバランスを超えた場合にのみ課金される。

プロビジョンドスループット (新しい）

• 2018年8月、わずか３週間ほどで先月発表のプロビジョンドスループットが廃止され、1～1024MiB/sの範囲で任意のスループットが指定可能なサービスが登場した。

しかし 2018/8/20 東京リージョンでは何故か動かなかった

早速ファイルシステムの作成を試みるも…

作成時から指定可能なはずだけど何故かだめ。
仕方なく指示通り一旦Burstingスループットモードで作成した後に変更を試みるも…

やっぱりだめ。
オレゴンリージョンでは問題無く設定できたので東京はまだなのかも。発表だけ先走りはアマゾンのカルチャーなのでそんなもんだといえばそうだ。
AWSサポートからは有償サポートの契約が無いと回答できないと拒否されたので（怒）お蔵入り。
これはiPhoneを買って電話を掛けようとしたらできず故障なのではという問い合わせのようなもので、回答を拒否するAWSJは問題あり。

2018/8/25 東京リージョンでも動作を確認

なしのつぶてなAWSサポートが何かしたのかしらないが、いつの間にか使えるようになっていた。
ファイルシステム作成時、既設変更共に可能。（仕様通りの動作）

プロビジョンドスループットの制限事項

• 増速は何度でも随時可能
• しかし減速は24時間に一度しかできない
• スループットの設定上限は1024MiB/sまで
• 合計スループットを1GiB/s以上に上限緩和申請で引き上げても変わらない。別途上限緩和申請が必要。

上限緩和申請

• できること（括弧内は標準値）
  • 合計スループット(1GiB/s)
  • プロビジョンドスループット(1GiB/s)
    • 海外の合計スループットが標準3GiB/sのリージョンもプロビジョンドスループットは標準1GiB/sなので必要な場合は別途申請を。
• できないこと（括弧内は標準値）
  • アベイラビリティーゾーンごとのファイルシステムあたりのマウントターゲットの数 (1)
  • マウントターゲットあたりのセキュリティグループ (5)
  • リージョン毎のファイルシステムの数 (125)
  • ファイルシステムあたりの VPC の数 (1)

EC2インスタンスで実際の性能を試す

• では実際にどのぐらいの性能が出るのか？
• 検証環境
  • 10GiBのファイルを読み書きする速度を計測する。８回試行し大きな変動が無い事を確認する。
  • EFS プロビジョンドスループット 1024MiB/s
  • EC2インスタンス i3.16xlarge Amazon Linux 2 (25GbE, NVMe-SSD, ami-08847abae18baa040)
  • NFSマウント方法はAWS推奨の記述 mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 172.31.1.1:/ /efs/
  • 東京リージョン AZ-A,C,D で同時に使用する
  • インスタンス毎に250MiB/sの速度上限がある事を念頭に検証結果へ…

読み込み速度はほぼ仕様通り

• １インスタンスから読み出すと当然に240MiB/s程度とほぼ仕様通りの速度であった
• ４インスタンスから同時に読み出してもそれぞれ240MiB/s程度とほぼ仕様通り
• ８インスタンスから同時に読み出すと合計スループット(1024MiB/s)上限に達するためそれぞれ100～150MiB/sと全インスタンスで合計値を満たす結果となった
• １インスタンスで２ファイル同時に読み出すとそれぞれ120MiB/s程度とインスタンス毎の上限速度(250MiB/s)が按分された結果となった
• いずれもほぼ仕様通りの性能を得ることができた

書き込み速度には限界がある

• １ファイルの書き込みは 190MiB/s 程度が限界のようだ。
• しかしインスタンス毎の速度上限(250MiB/s)に抵触しているわけではなく、１インスタンスで２ファイル同時に書き込むと120MiB/s程度ずつ出た。
• 当然に４インスタンスから同時に書き込んでもそれぞれ190MiB/s程度という結果が得られた。
• ８インスタンスの場合は読み込み同様、合計スループットが按分された。

EC2インスタンスタイプよる速度変動

• NFS I/Oにはネットワーク性能はもちろん、CPU性能も求められる
• t2.microには荷が重い。EFSへアクセスするとCPUクレジットをどんどん消費する。CPUクレジットが有る間は100MiB/s近い速度だが、無くなると8～18MiB/s程度と悲惨な結果に。
• 10GbE以上のネットワークを持つインスタンスでないと十分な性能を発揮できない。
• i3.16xlarge, i3.8xlarge, c5.18xlarge, c5.9xlarge で大差が無く、25GbEと10GbEによる転送速度の差は皆無であった。

使用するAZの数による性能の変化

• ない
• 2AZのみ設定したEFSと3AZ設定したEFSで性能比較するも、読み書き共に差は無かった。
• VPCのサブネットが無いAZにはマウントターゲットが設定されないが、内部的には全AZにデータが置かれていると思われる。

ウィンドウズでの利用

• 公式にはサポート外。
• これはウィンドウズサーバがNFSv3までしか対応しないため。（EFSはNFSv4, v4.1のみのサポート）
• 社外品のドライバでアクセスした記事を書きました。 https://qiita.com/zakky/items/b0c4df1ee7cb75830186
• ただし読み込みと削除のみ可能。これはドライバの仕様。長いことメンテナンスされていないため今後の対応は期待できない。

VPC外からの利用

• AWS Direct Connectで接続されたネットワークから利用可能。
• AWS Direct Connect Gateway経由は理論上動く（中の人談。要確認）。
• VPC Peering経由はc5,m5系EC2インスタンスのみ利用可能。
• VPN経由は利用不可能。
• 公式資料にも記載の通りその性能はNFSの構造上、回線に大きく依存する（伝送速度ではなくRTT）

他のVPCへの移動

• 全てのマウントターゲットを削除すると他のVPCへ移動出来る。
• 上限緩和申請できないので移動したい場合はこうするしかない。

まとめ

• セキュリティグループは厳格に設定すること
• 総容量10TiBを超えたら合計スループットの上限緩和申請を
  • 東京リージョンの合計スループットは標準で1GiB/sなのでしないともったいない…