新CDP候補「Shared Serverパターン(仮)」

#Amazon VPC

#AWS

望月政夫

2014.03.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。望月です。
昨日、VPC Peeringという特大アップデートがありました！今までは行えなかった、VPC間のローカル接続を実現するVPC Peering機能です！詳細はこちらのブログを参照して下さい。

Amazon VPC Peeringの技術的考察と留意点 - Developers.IO クラスメソッド開発ブログ

さて、このアップデートで今まで出来なかった色々な問題が解決されると思います。で、私がこの機能追加を聞いた時に「これだ！」と思ったものをCDP候補"Shared Server"として提案したいと思います！CDP(Cloud Design Pattern)については、公式サイトを御覧ください。

AWS-CloudDesignPattern : メインページ

解決したい課題

AWSの設計の基本として、「システムごとにVPCを作成して独立したネットワーク環境を作成する」というのが定石になっています。しかし一方で、この方針を採用することによる不都合な点も出てきます。例えば

一般的なVPCに必要なNATや踏み台といった要素をそれぞれのVPCに作成する必要がある。(一般的なVPC構成については過去ブログを参考にして下さい。
監視サーバなどの複数システムから利用されることがあるシステムも、VPC毎に作成する必要がある。

そのためEC2インスタンス数が増え、メンテナンス負荷と利用料金が増大するというのが今までの欠点でした。しかし、今回のアップデートにより、複数のシステムから共通で利用するVPCを作成することができるようになりました。

構造

Untitled (4)

構成図はかなりシンプルです。構築する上でのポイントは３つです。

VPC Peeringを設定するVPCは、異なるCIDRアドレスブロックで作成する
それぞれのVPCのRoute Tableで、VPC間の通信を許可する
Security Groupで、必要なポートの通信を許可する

いくつかこのCDPを利用した実例を紹介します。VPC Peeringの設定や仕組みに関しては、前述のブログを参考にしてみてください。

実例その１：踏み台サーバ

VPC毎に踏み台を作成せずに、単一の踏み台からSSH接続を行うケースです。従来ですと、VPC毎に踏み台サーバを作成する必要がありました。それはそれで、役割と権限の分割、という意味で非常に意味のある構成です。一方で、一人の管理者が複数システムを管理するような場合ですと、踏み台サーバが複数存在することが煩雑に感じられるケースもあると思います。
そこで、上図でいう10.0.0.0/16のVPCにBastionインスタンスを作成し、そこから10.1.0.0/16のインスタンスにSSHでアクセスしてみます。

VPC Peeringの設定方法に関しては、前述のブログを参照して下さい。

$ ssh 54.199.247.157 # 10.0.0.0/16に作成した踏み台にアクセス
Last login: Tue Mar 25 10:25:51 2014 from : 

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
[ec2-user@ip-10-0-0-181 ~]$ ssh -i <鍵ファイル> 10.1.0.143 # 10.1.0.0/16のホストにSSHアクセスする
The authenticity of host '10.1.0.143 (10.1.0.143)' can't be established.
RSA key fingerprint is aa:cf:a9:8d:06:ca:58:21:9a:94:74:c4:ac:9e:09:1b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.0.143' (RSA) to the list of known hosts.
Last login: Tue Mar 25 10:25:47 2014 from :

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
17 package(s) needed for security, out of 39 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-1-0-143 ~]$

別のVPCにSSH接続することが確認できました。

実例その２：Zabbixサーバ

今度は、10.0.0.0/16のVPCにZabbix Serverをインストールしてみます。その上で、10.1.0.0/16のVPCにZabbix Agentをインストールしたインスタンスを用意し、Zabbix Serverに対して情報を送信します。Zabbix Serverのインストールについては、過去のブログで紹介していますので、そちらをお使い下さい。

監視対象側(10.1.0.0/16側)にZabbix Agentをインストールしたら、/etc/zabbix/zabbix_agentd.confを編集しましょう。Serverの設定項目をZabbix ServerのプライベートIPアドレスに設定します。

$ sudo vim /etc/zabbix/zabbix_agentd.conf
# 86行目を変更
Server=<Zabbix ServerのプライベートIPアドレス>

$ sudo service zabbix_agent start

Agentが起動したら、ZabbixのWeb画面からホストの追加を行います。

Configuration_of_hosts

登録をしてしばらくすると、監視が実際に実行されているのが確認できます。

Latest_data__refreshed_every_30_sec_

異なるVPCのインスタンスをZabbixで監視することができるようになりました。

注意点

公式ページや前述のブログでも言及されていますが、同じCIDR同士のアクセスやIGW,VGWを共有した通信などは現在のVPC Peeringではサポートされていません。

制限事項はあるものの、しっかりと理解した上でこの機能を利用すればかなりVPC活用の幅が広がるのではないでしょうか。
また、「構造」の部分でも述べましたが、接続予定のそれぞれのVPCのCIDRは、別のレンジを設定しておくことを意識して下さい。「既存のVPCを全て同じCIDRで作ってしまっているよ！」という方は多いと思いますが、その救済はあるのでしょうか...