Amazon RedshiftとEC2のインスタンスタイプに於ける”MTU”の関係について

RedshiftとEC2に関するちょっとした小ネタです。

Redshiftに対してEC2サーバからのアクセス確認を行っていた所、『インスタンスタイプによってRedshiftにアクセス出来るものと出来ないものがある』という事象に直面しました。分かってみると『なるほど〜』という内容でしたのでここにその経緯と対応をまとめてみたいと思います。

当エントリについて結論から先に申しますと『EC2にはMTU(Maximum Transmission Unit: 最大トランスミッション単位)というものがあり、インスタンスタイプ毎にその値は異なる』『EC2からAmazon Redshiftにアクセスする際、そのMTUの値が影響する(インスタンスタイプによってアクセス出来るものと出来ないものがある)』のです。

当該問題の言及箇所

インスタンスタイプ毎のMTU値に関する言及はこちら。

• インスタンスタイプ - Amazon Elastic Compute Cloud

インスタンスの最大トランスミッション単位（MTU）はインスタンスタイプに依存します。CC2、C3、CG1、CR1、G2、HS1、HI1、I2、M3 の各インスタンスタイプは、9001 MTU（ジャンボフレーム）を提供します。他のインスタンスタイプは、1500 MTU（Ethernet v2 フレーム）を提供します。

MTU自体の詳細については以下サイトなどをご参照下さい。

• Maximum Transmission Unit - Wikipedia
• MTU / MSS / RWINとは
• [Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す ｜ Developers.IO

そして、Redshiftに於けるMTUの制限に関する言及はこちら。

• Amazon Redshift Clusters - Amazon Redshift

we recommend disabling TCP/IP jumbo frames by setting the maximum transmission unit (MTU) to 1500 on the network interface (NIC) in the EC2-VPC instance. (EC2-VPCインスタンスに於いては、ネットワークインタフェース(NIC)のMTUの値を1500にする事でTCP/IP ジャンボフレームを無効にする事を推奨します)

と、仕様的にもMTUの値が1500でないインスタンス(CC2、C3、CG1、CR1、G2、HS1、HI1、I2、M3)からはデフォルト値のままではRedshiftのアクセスが出来ないようです。

実際に試してみる

では、実際に試してみましょう。MTU=9001の値で起動するEC2インスタンスを1つ用意しログイン。確かにMTUの値が9001を示しています。

$ ssh -i xxxxxxxxxxxxxxx.pem ec2-user@xxx.xxx.xxx.xx
$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX:  
          inet addr:10.0.0.0  Bcast:10.0.0.0  Mask:255.255.255.0
          inet6 addr: XXXX::443:XXXX:XXXX:XXXX/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1 【←MTU値＝9001】
          RX packets:1961 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1648 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:710688 (694.0 KiB)  TX bytes:173423 (169.3 KiB)
          Interrupt:26 

Redshiftにログイン、任意のSQLを実行してみます。ログインまでは問題無く進めましたが、クエリを実行した段階で返答がなくなってしまい、固まってしまいました。

$ -h xxxxxxxx.ap-northeast-1.redshift.amazonaws.com -d sampledb -U sampleuser
$ (パスワードを入力)
# SELECT * FROM .....
(ここで固まる...)

解決策としては以下の様にifconfigコマンドを使ってMTUの値を変更する事で対応が可能となります。

$ sudo ifconfig eth0 mtu 1500 【←このコマンドをそのまま実行】
$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX:  
          inet addr:10.0.0.0  Bcast:10.0.0.0  Mask:255.255.255.0
          inet6 addr: XXXX::443:XXXX:XXXX:XXXX/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1【←再度確認。今度はMTU値＝1500となっている】
          RX packets:2128 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1793 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:730489 (713.3 KiB)  TX bytes:198797 (194.1 KiB)
          Interrupt:26 

$

改めて接続確認をしてみます。今度は問題無く繋がるかと思います。

$ -h xxxxxxxx.ap-northeast-1.redshift.amazonaws.com -d sampledb -U sampleuser
$ (パスワードを入力)
# SELECT * FROM .....
(結果表示！)

まとめ

以上、Amazon RedshiftとEC2のちょっとした関係について書いてみました。今回取り上げたようなインスタンスタイプから接続・処理を行うようなケースが発生した場合は『こういう事もあるんだな』と頭の片隅に置いておき、対処に役立てて頂けると幸いです。