さて、手元に大きなSQLの束がある。MySQLのサーバからmysqldumpしたデータで、サイズは何とか少なくしたけれど50GBはあるだろう。このデータをAWSのRDSのインスタンス(もちろん、MySQL)で使えるようにしたいのだが、いかんせん、データのサイズが大きいので、社内のサーバから動かすのも大変。ウチの社内サーバは、フツーのフレッツでしかインターネットに接続されてないので…と。
思いついた選択肢「その1：直接、MySQLクライアント接続」
ま、RDSのエンドポイントにはインターネットからアクセスできるわけだし*1、社内のサーバからインターネット経由でMySQLのクライアント接続をかけて、SQLを実行しちゃえ、というアイデア。
$ mysql -h [RDSのENDPOINT] -u [User] -p [Database] < XXXX.sql
ま、これでRDSにSQLのデータを入れることはできる。だけど、なんせmysqldumpしたデータは巨大な1つのファイルになっているので、SQLを実行している途中でネットが切れたらやり直しになる可能性が高い。うーむ、なんとなく微妙だ。
思いついた選択肢「その2：(AWSに近い)どこかのサーバにアップロードして、そこから実行」
ま、そもそもインターネットとウチの社内の間がフレッツだから、そこがネットワーク的にボトルネックに違いない。AWSとネットワーク的に近いサーバにSQLの束をアップロードして、そこからAWSに対して、選択肢1のようなことをやればすんなり行きそうな気がしないでもない。ただ、そのサーバとAWSの間の帯域はよくわかんない*2し、そもそも、そのサーバまで巨大なSQLをアップロードするのに時間かかる。gzipで圧縮してアップロードしたいような気もするが、その圧縮にすらうんざりするくらい時間かかりそうだ*3
…とはいうものの…。
他にも、MySQLのデータベース単位でmysqldumpせずにテーブル単位でファイルを作っておけば…とか、いろいろと泡沫のアイデアが浮かんでは消えていった。そして、とても大事なことに気がついた。お財布の都合上、できるだけAWSの無料枠内で納めたい、となると、使えるのは「マイクロDBインスタンス」。まぁ、あんまり性能面ではたいしたことないインスタンスだから、何をどう工夫してもRDSのサーバ側でSQLを実行するところがボトルネックになりそうな気がしてきた。
そんなわけで、何にも考えずに選択肢1で始めたものの…RDSのインスタンスをモニターしてる限りでは、CPU使用率もWrite Throughputもなんだかイマイチな結果になっている。マイクロインスタンスでも余裕がありそうだ。それに、社内でmysqlクライアントを実行しているマシンも暇そうにしている。…ということは、AWSとウチの会社の間のネットワークがボトルネックになっているってことだろうか(汗)やっぱり、MySQLクライアントを実行するマシンとMySQLサーバはネットワーク的に近いところにあった方がいいんだろうなぁと思い始めたが、今から止めてやり直すべきだろうか…どっちにしろぐったりする時間がかかりそうなことだけは間違いなさそうだ。
素人らしく、素人っぽいところでつまずいてるなぁ…いやはや。
追記：
ま、普通にEC2にSQLファイルをどーんとアップロードして、EC2からRDSのインスタンスに対してSQLを実行すればいいんだな、きっと。Amazonのネットワークの中はさすがに遅いって事はないだろうし。…とりあえず、EC2に50GB近くのEBSをAttachすると…ってビビっていたけれど、意外と大して高くないことに気がついてorz