インフラ屋のAWSはじめた日記─GUIを捨てよ

第5回 そろそろサーバを弄りたい

この記事を読むのに必要な時間:およそ 7 分

踏み台

RDSを起動したのは良いけれど,接続できないのは困ったものだ。

外から接続できないようにしたのはいいのだけれど,一時的にでも接続できないのは辛い。接続するためには,外からアクセスできるようにするのか,踏み台を介してつなぐようにするのかの二択だろう。今回は踏み台のEC2を起動してDBにアクセスするようにする。

踏み台起動

EC2の起動はpublic側のサブネットにして,まずそこにSSHで接続できることを確認する。

画像

ここまでできたら,EC2からRDSに対して接続できるのかを確認してみる。

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|
$ sudo yum install mysql 
$ mysql -h test-db.xxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -u root -p

つながらない。パスワードが間違っているとかそういった感じではなく,なんかネットワーク的につながっていないような気がする。

また出てきたよSecurity Group

この何故か接続できないというのは,ここでもハマった。たぶんSecurity Groupだろう。そういえば,さっきRDSを起動するときに--vpc-security-group-idsというのを見かけていた。どのVPCに起動するかっていうときに--vpcでタブを連打したら出てきていた。わかってしまえば簡単で,Security Groupを作って設定すればよい。

と思った所で,ひとつ疑問が湧いた。Security Groupってアクセス元に自Security Groupを指定できる。こんな時に,どうするべきなのか悩む。こんな事で悩んでも仕方の無いことなのかもしれないけど,自分のポリシーは決めておきたい。Security Groupはタグのようにインスタンスに付けられる。そこで,Security Groupはどのようにつけるべきなのかを考えてみる。

画像

1つめは上の図のような感じで,データベースにはデータベースのSecurity Group,WebサーバにはWebサーバのSecurity Groupをつけ,DBにはDBのSecurity Groupをつける。その上で,DBのSecurity GroupにはWebサーバからのアクセスをつけるという方法。

画像

もう1つは通信の内容でSecurity Groupを作る方法。MySQLの通信をしたいのであれば,同一Security GroupからのみTCPの3306を通すようにして,EC2とRDSの両方につけるという方法。

どちらの考えかたでも,やりたいことは実現できるかもしれないけれど,それぞれメリット・デメリットがありそうで,どちらが良いとは言いがたい。

前者では,同じ機能を持つインスタンスには同じSecurity Groupが付き,Security Groupを見ればどんなインスタンスなのかがわかるという利点がある。

しかし,新たな通信を許可したい場合は既存のSecurity Groupを編集することになる。いろいろな所で使いまわしていたりしたら,余計な通信を許可することにもなりかねない。

逆に後者では,新たな通信を許可したい場合にはその通信専用にSecurity Groupを作り,インスタンスに設定すればよい。通信の種類が増える毎にSecurity Groupを作るため,インスタンスに設定できるSecurity Groupの上限に達しやすいという問題も存在する。

こちらのURLで上限数を確認してみると,インターフェースあたりのSecurity Groupの数,Security Groupあたりのルール数をかけたものが,250を超えないように上限緩和を行えるみたいだから,どちらの使い方でも可能なんだろう。

“セキュリティグループの設定方法に応じて,ネットワークパフォーマンスが影響を受ける場合があります。” との記述もある。どちらの方法が良いパフォーマンスなのか,管理しやすいのかというのは正直まだわからない。この日記を読んでくれた人がはてブのコメントとかTwitterで考え方を教えてくれたらいいなとか図々しいことも思っていたりもする。

RDSのSnapshotを作る

MySQLに無事に接続できるようになったら,次にはデータを入れるなどをしてみたい。

とはいえ踏み台となるEC2から接続できる事が確認できたら,あとはAWSとは関係の無い,今まで慣れ親しんだ方法で操作が可能になる。

SSHのport forwardingを使って手元からつないでも良いし,EC2上で作業してもよい。特に目新しさは無いけれど,俺は.ssh/configに書くのが好きで,

Host vpc-test-db
   HostName     ec2-****-conpute.amazonaws.com
   User          ec2-user
   Identityfile  ~/.ssh/id_rsa
   GatewayPorts  yes
   LocalForward  13306 test-db.*************.rds.amazonaws.com:3306

と書いておいて,

$ ssh vpc-test-db

とすればCtrl+Cで終わらせるまで,forwardingさせ続けるというやり方を良くする。こうしておけば,

$ mysql -P 13306 -u hoge -p

で接続できるから楽だ。

こんな感じでデータベースの操作をしたら,今度は運用面でRDSを触ってみたい。

Snapshotを作る

RDSの機能の1つに,バックアップがすごく楽になるというのがある。バックアップがすごく楽になるというのがどんなものなのか試してみたい。

$ aws rds create-db-snapshot --db-instance-identifier test-db  \
--db-snapshot-identifier test-db-snapshot-001
{
    "DBSnapshot": {
        "Engine": "mysql",
        "Status": "creating",
        "AvailabilityZone": "ap-northeast-1a",
        "PercentProgress": 0,
        "MasterUsername": "root",
        "Encrypted": false,
        "LicenseModel": "general-public-license",
        "StorageType": "standard",
        "VpcId": "vpc-6ac1020f",
        "DBSnapshotIdentifier": "test-db-snapshot-001",
        "InstanceCreateTime": "2015-02-03T23:03:14.906Z",
        "OptionGroupName": "default:mysql-5-6",
        "AllocatedStorage": 5,
        "EngineVersion": "5.6.19a",
        "SnapshotType": "manual",
        "Port": 3306,
        "DBInstanceIdentifier": "test-db"
    }
}

恐ろしく簡単にsnapshotができたような気がする。

Snapshotが作れたら,次はこのSnapshotからrestoreするということをやってみる。

aws rds restore-db-instance-from-db-snapshot --db-snapshot-identifier test-db-snapshot-001-略-

snapshotからrestoreするのもものすごく簡単だった。

ただひとつ問題なのが,また新たに--db-instance-identifierを指定するって事。それはすなわちrdsのエンドポイントが別で,全く新しくDBサーバが立ち上がったということだ。ここが実は俺の中では面白いところで,クラウドってこういう考え方をするんだなって実感した。

もしたとえばこれが実運用の際にはデータベースが破損しているなどの理由でサービスは停止してしまっているような状況が想像できる。言い換えれば,無停止でデータベースの切り替えを行う必要はない状況だ。であれば,なんとかして新しい方のデータベースに接続できるようにすれば,問題は解決する。壊れたサーバは捨ててしまえというなんとも漢らしい考え方だ。

実際にどうやるかというと

$ aws rds modify-db-instance --db-instance-identifier test-db \
--new-db-instance-identifier test-db-broken --apply-immediately

このコマンドで実行してみる。ただちに変更したい場合は--apply-immediately というオプションを付けないといけないことに気づくまでに少しかかってしまった。

このコマンドを実行すると,

             "PendingModifiedValues": {
                 "DBInstanceIdentifier": "test-db-broken"
             },

こんな感じでPendingModifiedValuesという項目で表示される。

しばらく経つと(Statusがrebootingとなっていたので,たぶん再起動??)⁠db-identifierが変更されている。

こうなれば,新しくSnapshotから作った方も同様に,DBInstanceIdentifierを変更し,もともと動いていたDBInstanceIdentifierにしてあげる事でエンドポイントが新しい方のデータベースを指すことになり,アプリケーションをいじることなく故障したDBサーバから新しいDBサーバに切り替える事ができる。

あれ,でもこれMultiAZ使えば,自動的にやってくれるんじゃないか?と一瞬思ったけど,MultiAZはハードウェア障害では良いかもしれないけれど,データの破損に関してはカバーできなそうだ。そういった時にはこの方法が役に立ちそうだ。

結局今日もRDSの使い方の辺りははわかってきたけど,まだミドルウェアをインストールして,設定してという作業を行っていない。この辺りはやはりなんとかやってみたい。

まあでも最初に比べて,俺はもうAWSを使いこなせばインフラの設計に全力を注げるのではないんじゃないかとも,なんとなく思い始めてきている。だからこそ,ここからの楽しみ度も高い気がする,なんというか,期待大だ。


ついに,GUIなしでサーバ構築まで辿り着いた,とあるインフラエンジニア。これはいよいよ本格的にクラウドエンジニアへの道をつかみ始めている…かも。次回,最終回です,ご期待ください。

AWSの仕事ができるようになる,トレーニングプログラム
http://tr.pasonatech.co.jp/wpaws01

著者プロフィール

あけり

学生時代からマウスが机の上で無くなってしまうので,マウスに頼らないインフラエンジニアになると決意。そして,インフラエンジニアになって10年目の今年,ついにクラウドを触りだす。