MEGAZONE 株式会社 のテック陣「MEGAZONEのゆかいな仲間たち」がおくる、Megazone Japan Advent Calendar 2023 の6日目のエントリーです。
S3へのデータ転送速度が落ちてゆく……
オンプレミスのデータをAWSのDirect ConnectやVPN経由でS3へ保存したい！という場合にはインターフェース型のVPCエンドポイントを利用するのが管理運用面でメリットが大きいです。
しかし、インターフェース型はゲートウェイ型に比べてVPCエンドポイントの維持費用とデータ処理費用がかかり、特にデータ転送量が多い場合は無視できない金額となります。
そのようなわけで昔ながらのProxyサーバを利用した構成で費用を抑えたS3へ転送するケースもあると思います。以下はVPC内にProxyサーバが1台だけあるシンプルな構成です。
Proxyサーバはt3.microのお手頃EC2インスタンス。Proxyサーバ経由でS3へデータ転送する350MB/secほど。2.8Gbpsと考えると悪くない転送速度です。さぁ、このままTB級のデータを大量転送だ！……って、あれ？ 転送速度が激落ちしてほとんど進まないぞ！
妙だな……この動き、まるでバーストクレジットのようだ
一度S3への転送を停止し、しばらくしてから再開すると転送速度が回復している……が、またすぐに同じ状態になってしまう。よく見ると転送自体はされているが、まるでリミットがかかったように8MB/secで固定されている。
Proxyサーバに利用しているTタイプのEC2インスタンスはバースト可能なタイプで、EC2インスタンスが獲得するクレジットを消費してベースラインを超えた性能を発揮することができる。逆にいえば、クレジットの獲得量を超えるクレジットを消費してバーストし続けると、ベースラインの性能まで落ち込んでしまう。
はたしてCPUクレジットが原因だろうか……
CPUクレジットは枯渇していない
CloudWatchでCPUクレジットの使用量や残高を確認すると枯渇しているわけではなさそうだ。しかも、t3タイプはクレジット仕様が標準でunlimitedとなっているため、CPUクレジットが枯渇したとしても追加コストがかかるもののバーストは維持できる。
どうやらCPUクレジットの枯渇による問題ではなさそうだ。
EBSはどうだろう？
そういえばEBSにも同じような仕組みがあったような……
MackerelのDisk I/Oのメトリクスを確認すると、EBSボリュームへの負荷はないようだ。
まだ隠されたバーストの仕組みがあるのだろうか……
"最大"って何だ？
バーストと同じような"EBS最大パフォーマンス"の仕組みがあるEC2インスタンスにはインスタンスタイプのページで、"EBS帯域幅"の項目に"最大〇〇"といった表記がされている。
おやおや？ "ネットワーク帯域幅"にも"最大〇〇"の表記があるぞ？
あるのか……ネットワーク帯域幅にも"バースト"がッ！
やはり存在した"ネットワークI/Oクレジット"メカニズム
細かい仕組みはAWSのドキュメントを確認していただくとして、基本的な仕組みはCPUクレジットと同じです。
ベースラインの帯域幅は以下のAWSドキュメントに記載されています。
今回利用したProxyサーバと同じ"t3.micro"のベースライン帯域幅は"0.064Gbps"。MB換算すると"8MB/sec"となり、これはMackerelのTrafficメトリクスで天井張り付きしていた値と同じ。
ネットワークI/Oクレジット……原因はお前だったのか……
で、どうすればいい？
もっとも簡単な方法はProxyサーバのEC2インスタンスタイプを変更することです。主要なインスタンスタイプだとTタイプ以外の8xlarge以上がバースト無しとなっています。
しかし、8xlargeは比較的高価なインスタンスタイプなので、大量のデータをS3へ転送するためだけに長期間稼働させるのは予算的になかなか難しいかもしれません。バーストタイプでもベースラインのネットワーク帯域幅が実用レベルのインスタンスタイプがあります。たとえばt3.xlargeは1Gbps、t3.2xlargeは2Gbpsなので、転送元の環境によっては十分な帯域幅となります。
あとは予算的に問題がないようであればS3へのアクセスにインターフェース型のVPCエンドポイントを利用するのもよいです。VPCエンドポイントの稼働時間と通過するデータの処理量で決まるため予算を立てやすい上に、Proxyサーバの運用をしなくて済むので運用負荷低減やリスク回避なります。
バーストなしのインスタンスタイプに変更してみた
せっかくなのでProxyサーバをt3.microからm6i.8xlarge(バーストなし)に変更してみたところ、時間が経過してもトラフィックの急激な落ち込みがないことを確認できました。インスタンスを停止してからインスタンスタイプ変更するだけなのでお手軽ですね！
おわりに
ちょっとした検証などではお手頃価格のバースト可能インスタンスを選ぶということもあると思います。CPUクレジットとは異なり、現時点ではネットワークI/Oクレジットをどれくらい持っているか、どれくらいバーストを維持できるかといった具体的な情報を確認することができません。
アクションゲームのスタミナゲージよろしくクレジットの枯渇防止を意識しながらコストを抑えた運用もまた一興……
いや、やはり予算無制限で高性能インスタンスをぶん回したいですね！