騒音の出ないサーバがあれば便利だと思っていましたが、最近はAWS でサーバを立ち上げるというオプションもあります。サービスとしてサーバがクラウド上にあれば、熱や音で悩まされることはないはずだと思い、AWS で 社内用にWindowsサーバを立ち上げてみました。
なにしたいかというと、社内 LAN 上に AWSの Windowsサーバがあるかのような環境を整えることができるかどうか、そして、そのよう環境を実運用できるかどうかを確かめることです。
1. 社内 LAN と VPC間をVPN接続
AWS の VPN はIPsecなので IPsec対応の VPN装置が必要です。簡単に試せるような装置をさがしていたところ、https://ultradairen.wordpress.com/2013/12/22/buffalo-vr-s1000-vpn-to-aws/
Buffalo VR-S1000 VPN to AWS
を見つけました。バッファロー VR-S1000 は実売価格 20,000円で、インターネットルーター機能、10接続VPN, 簡易NAS（ USBポートに接続した USBメモリ/ハードディスクを共有できる ) といった機能を兼ね備えています。これを使って試してみました。
2. AWS で Windows 2012 Server R2 （無料枠対象）インスタンスを作成
最初は何も考えずに Windows 2012 Server R2 のEC2 インスタンスを 作成してみました。物理的な作業はまったく不要で、身体を動かす必要がありません。OSインストールも不要です。
このインスタンスは VPC （ 10.0.0.0/16 ）の サブネット 10.0.0.0/24 に配置したものとします。
3. VPC へのVPN 接続
この VPC に VR-S1000を使って接続してみます。
3-1 AWS側設定
a. カスタマーゲートウェイ作成
社内インターネット接続の WAN IP アドレスを指定するのみで作成できます。
b. VPNゲートウェイ作成/アタッチ。
任意の識別名を指定するだけで作成できます。作成したら、VPC ( 10.0.0.0/16 ) にアタッチします。
c. VPN接続作成
カスタマーゲートウェイとVPNゲートウェイを指定して VPN 接続を作成します。ルーティングは”静的”を選択して、 VR-S1000 の LAN側アドレス ( 例えば 192.168.10.0/24 ) を指定します。
d. セキュリティ設定の追加
インバウンドルールで 送信元 192.168.10.0/24からのトラフィック、プロトコール, ポートを許可します。
3-2 VR-S1000 の設定
a. AWSコンソール - VPC - VPN接続で、作成済みの VPN接続を選択して "設定のダウンロード”で Microsoft - Windows Server の設定を取得します。
b. VPN ウィザードで ”事前共有キー”に Preshared keyの値、”リモートWAN IPアドレス”に
Remote Tunnel Endpointの値、リモート LANネットワークに 10.0.0.0, リモート LANサブネットマスクに 255.255.0.0 を設定して、[追加]します。次の画面で暗号化方式を AES-128 に変更します（２箇所）
3-3 設定確認
インスタンスのプライベート IP ( ここでは10.0.0.100 ) に対して PING して応答が返ってきました。次にリモートデスクトップでこのインスタンスに接続していました。AWSコンソールの EC2から Windows 2012R2のインスタンスを選択して、[接続]ボタンで
a. リモートデスクトップファイルのダウンロード
b. Administrator ユーザのパスワード取得
をします。ダウンロードしたリモートデスクトップファイルをダブルクリックして RDP 接続を開始。ユーザ名(Administrator)とパスワードを設定して Windows にログインできました。
4 問題点
この Windowsサーバはデフォルトの VPCのサブネットで動いています。デフォルト VPCは、特に何もしなくてもインターネットゲートウェイが付いていため、インターネット接続ができるようになってます。インスタンスに Elastic IP が割り当てられていれば、そのパブリック IPでインターネットアクセスができますし、外部からこのインスタンスにアクセスできます。これは、社内 LANのサーバに外部からそのサーバの パブリック IP でアクセスできてしまうことを意味します。
これでは困ります。社内 LAN 上のサーバのように、プライベート IP だけを持っていて、外部には自由に NAT 経由で出ていくことができる一方、外部からはアクセスできないようにしなければなりません。
5. NATインスタンス
そのようは方法を探すと、AWS サイトにNATインスタンスというものが紹介されていました。
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#NATSG"
NATインスタンス
a. デフォルト VPC とは別途 VPC を作成して、そこに２つのサブネットを作成。
b. インターネットゲートウェイを この新規 VPC にアタッチ
c. １つのサブネットのルートテーブルでデフォルトゲートウェイにインターネットゲートウェイを指定
してパブリックサブネットとする
d. このパブリックサブネットに NATインスタンスを立ち上げる
e. もう１つのサブネットのデフォルトゲートウェイに NATインスタンスを指定。外部へは直接アクセスするルートはないため、プライベートサブネットになる
f. Windowsサーバをこのプライベートサブネットに配置する
g. この VPC に VPNゲートウェイをアタッチして Windows サーバに RDP 接続を行う
思っていたより簡単に Windows サーバをプライベートサブネットに配置できました。NATインスタンス専用の AMI があります。NATインスタンスは本当に起動するだけで、ログインする必要すらありません。ローカル LAN にブロードバンドルータを取り付けるといった感覚で設置できました。もちろん、LANケーブル、電源コードをいじる必要はなく、ブローバンドルータの既定 IP アドレスが分からないといったこともなく、AWSコンソールからすべて設定できました。
サブネットを複数作成してもルータを設置する必要がありません。ルータは”組み込まれている”
そうです。インターネット回線を用意する必要もありません。机に座ったままキーボードとマウス操作だけでインターネット接続できる複数のサブネットをもったネットワークにサーバを立てて、VPN接続できる環境を整えることができてしまいました。Windowsサーバに言語パックをインターネットから導入したときにインターネット接続が非常に速かったことに気づきました。
6. Windowsサーバ使用
Windowsサーバは北米リージョンで立ち上げました。既定では言語は英語になっていましたので、日本に変更しようとしてみると、ディスク容量不足でインストールできませんでした。無料枠は 30GBの容量でインスタンスが作成されていましたが、インスタンス作成直後、1GB程しか空き容量が残っていませんでした。これでは何もできないため、現在のボリュームのスナップショットを作成してから、ボリュームを削除、新規に 50GB の EBS ボリュームをスナップショットをもとに作成しました。
この新規ボリュームをインスタンスにアタッチして、インスタンスを起動しても C ドライブのサイズは以前のままです。 管理ツールの「コンピュータ管理」ー「ディスク管理」を使って Cドライブを拡張しました。
Cドライブの容量が 50GB になったところで、Windowsの言語を日本に変更してみたところ問題なく変更できました。
次に AWS の Windows サーバから社内 LAN 側のリソースを参照できるかどうか確認してみました。エクスプローラで \\（社内PCのIP） を指定すると、アクセスのためのユーザ情報が求められたあと、共有フォルダにアクセスできました。社内 LAN上のプリンタも問題なくセットアップでき、Windows サーバから直接印刷ができました。ほとんど遅延なく、北米のWindowsサーバから社内プリンタに印刷がされました。
おそらく社内 LAN に置いた物理サーバを置き換えることができるような気がします。
7 物理サーバ利用との比較
AWS の Windowsサーバは短期間の一時的な利用であればメリットは十分あると思われます。短期間の利用のために、わざわざ PC購入、設置、 OS インストールする必要はなく、使った分の費用しかからないため、費用的なメリットも十分にあるはずです。しかし、長期間にわたって使うことは零細企業にとってはコストメリットを十分に検討する必要があるような気がします。
AWS 費用は非常に細かく設定されていて、トータルのコストは１つ１つ積み上げてみないと分かりません。
a. EC2
b. EBS
c. Elastic IP
d. VPN接続
EC2 は停止可能、Elastic IP はデタッチ可能ですが、EBS は一度使い始めたら削除できません。VPN接続も、削除/作成を繰り返すわけにいきません。 EBS / VPN 接続は２４時間/365日課金されるはずです（ VPN接続を作成した時点から課金されると理解しています）
多くても数台のサーバが必要なだけの零細企業が業務に使うことことを考えると、すぐに飛びついて利用できるものではないのかもしれません。
AWS は、大手企業がオンプレミスのサーバ群を AWS に移すことができる環境を構築できるようなので、中途半端な部分はないはずです。すべてが”本格的” といった印象があります。クラウドサービスでもっとも気になるのがセキュリティだと思いますが、こちらも”本格的”のようです。
http://yoshidashingo.hatenablog.com/entry/2014/08/24/211825
このような本格的なインフラのコストだと考えると納得できる価格だとは思いますが、従来そこまで本格的なインフラを構築してきていない零細企業にとってはコスト負担増加は避けられないのではないでしょうか。
業務ではなく、提供する製品やサービスに利用する目的で AWSを活用する機会は零細企業にもあるはずですので、ハード/OS一切自前で用意することなくテスト、評価、試用目的で一時的に活用するメリットは十分にあるのではないかと思われます。
AWS ですぐに利用開始できたのは Route 53 DNSサービスでした。他のサービスとの違いは、ヘルスチェック機能が付加されている点で、この機能をつかうだけでもメリットはあるのではないかと思っています。
AWS ですぐに利用開始できたのは Route 53 DNSサービスでした。他のサービスとの違いは、ヘルスチェック機能が付加されている点で、この機能をつかうだけでもメリットはあるのではないかと思っています。
8 レンタルサーバとの比較
AWS でレンタル専用サーバと同じことをすることを考えると、コスト増は避けられません。インスタンスをハード占有にすると、1時間2ドルの追加料金（年 $2 x 24 x 365 = $17,520? ) が発生するようです。ハード占有にしない、リザーブドインスタンスにする、といったことで同等コストで Webサーバを構築できるかもしれません。同等コストで可用性、信頼性、保守性が高まるのであればメリットがでてきます。
可用性を求められる場合、本サーバ、バックアップサーバの２つのインスタンスを起動しておき、Route 53 DNSサービスでフェイルオーバを利用する、本サーバとバックアップサーバ間でデータの同期の問題がなければバックアップサーバは普段は止めておき本サーバに異常が発生したら通知を受け取り起動するなど、柔軟に考えた通りの構成を実現できそうです。
9 サービス提供のインフラとしての利用
AWS を使うことで零細企業でも大手と同じインフラを使ってサービスが提供できるようになります。サービスの可用性、安定性、信頼性について、AWSを使うことで”大手を同じインフラをつかっています、同等の可用性、安定性、信頼性です”といった形で提示できるメリットは大きいと思います。
0 件のコメント:
コメントを投稿