gihyo.jpサイトのロゴ

AWS+Windows環境における大規模ソーシャルゲーム開発／運用の実際

最終回　Windows on AWS EC2でImmutable Infrastructure

2014-09-18

今回は、弊社がどのようにしてAWS EC2でWindowsサーバを運用しているのかをImmutable InfrastructureとDisposableに焦点を当ててお話しします。Immutable Infrastructureの概念については多くの資料があるので、サーバに焦点を絞って簡単に概要を振り返ります。

Immutable Infrastructureは、「⁠サーバの初期セットアップを行ったあとは変更しない＝サーバの状態を不変に保つ」ことを原則としています。つまり、アプリケーションのデプロイやミドルウェアの設定変更など、軽微な修正も含めてサーバのあらゆる状態の変更を許可せず、変更のたびにサーバを再セットアップするということです。

いつでも再セットアップするということは、「⁠サーバを廃棄可能（Disposable）な状態に維持する」ことと言い換えることもできます。弊社が目指しているのも、WindowsでのImmutable/Disposableな構成と運用です。まだまだWindowsでの事例は少ないため、今回の記事が少しでも参考になればさいわいです。

ゴールデンイメージによる運用

弊社では、アプリケーションを厳密に同一な環境で動作させるため、Amazonの提供するまっさらなAMIイメージのWindows Server 2012 R2ではなく、そこに最低限必要な設定を施したイメージをベースにサーバを展開しています。これをゴールデンイメージと呼んでいます。

ゴールデンイメージを使う理由は2つあります。

起動タイミングによるバージョン差異の発生を防ぐため

負荷の増大時にスケールする際、現在起動しているインスタンスも含めた全台数を作りなおすのではなく、足りない台数だけをゴールデンイメージから構成して追加しています。

Amazonが提供する最新のAMIを常に利用していると、もともと動いているインスタンスとスケールして追加したインスタンスでバージョンが異なってしまう可能性がありますが、全インスタンスを同じゴールデンイメージから構成することでインスタンス間の環境の差異を最小にできます。

必要な初期構成に15分程度かかるため

Windowsは、IISなどの機能を容易に追加できますが、IISの全機能を入れる場合は十数分かかります。そのため、必要な機能を事前にインストールしたイメージを用いることで素早くインスタンスを展開できます。

ゴールデンイメージ作成時の構成例を次に紹介します。

  • Windowsの機能の追加
  • Webサイトの追加
  • レジストリの最適化
  • ソフトウェアのインストール
  • 監視用エージェントのインストール
  • Configuration Management（以降CM）への参加

このゴールデンイメージは、ちょっとした構成変更があった際に自動生成できるようにしています。そこで次は、Windowsでどのようにゴールデンイメージを作成し、スポットインスタンスの起動を自動化しているのか、中心となるツールを紹介します。

自動化と使用しているツール

Linuxがそうであるように、Windowsサーバにおいても自動化の対象をいくつかのレイヤに分けることができます。コードによる運用自動化には、C#とPowerShellを利用しており、ここではとくにPowerShellによる自動化について紹介します。

AWS Tools for Windows PowerShell：AWS APIの操作

AWS CLIと同様に、ほぼすべての操作をPowerShellから実行できます。Amazon AMIからのゴールデンイメージ作成用インスタンスの起動、Custom AMIの作成、Custom AMIからのスポットリクエストによるインスタンスの展開など、AWSコンソールの操作のすべてをAPI経由で行っています。

UserData：ゴールデンイメージから起動したサーバのブートストラップ処理

UserDataは、AWS EC2をAMIから起動した初回だけ自動実行するという機能です。Linuxでシェルスクリプトを実行できるように、WindowsではバッチファイルやPowerShellスクリプトを実行できます。

UserDataを使うことで、インスタンスの起動直後のCMツールへの追加、S3やGitHubからの必要なファイルの取得、認証情報の設定など、CMツールで状態を維持したくないが、実施しておきたい前処理を自動化できます。

PowerShell DSC：CM

CMツールは、サービスの提供に必要な「Windowsの機能」「⁠ソフトウェア」「⁠ユーザ」など、「⁠OS構成があるべき状態で維持されている」ことを保証するために必須となります。

Windows Server 2012 R2にはPowerShell DSCと呼ばれるCMのための機能があり、Chefと同等のことがOS標準で可能になっています。このDSCによってWindowsもCMが可能になったことは、WindowsをStatelessに近づけ、Disposableな環境を作るのに大きな役割を果たしています。

サンプルコード

次に、Linuxで使われるAWS CLIやRubyと比べたコードの違いをサンプルと一緒にご紹介します。

AWS APIを操作してインスタンスを作成する

AWS Tools for Windows PowerShellは、AWS CLIと同様にAmazonの各リソース操作をIDや型で指定します。弊社ではAPI周りを薄くラップして「TagからIDを拾う」ようにしています。このようにすると、すべてのリソースをTagのNameキーや型で安全に利用できます。

リスト1は、Amazon AMIからWindowsインスタンスを起動する例です。パラメータは違いますが、弊社ではこういった書式でゴールデンイメージの作成に始まり、ゴールデンイメージからスポットインスタンスへの展開／破棄まで行っています。

  • EC2-VPCで起動
  • General Purpose 50GB
  • Private IPが10.0.0.10
リスト1　Amazon AMIからWindowsインスタンスを起動する例（PowerShell）
# Create EC2 Instance
$ec2Param = @{
    EC2AMIImageName         = 'Windows_Server-2012-R2_RTM-Japanese-64Bit-Base-*'
    EC2InstanceType         = 'c3.2xlarge'
    KeyName                 = 'MyKeyPair'
    AvailabilityZone        = 'ap-northeast-1c'
    VpcName                 = 'Dev'
    VpcSecurityGroupTagName = 'Web-Dev'
    InstanceProfileName     = 'Web'
    SubNetState             = 'Available'
    IpAddress               = "10.0.0.10"
    VolumeSize              = 50
    VolumeType              = 'gp2'
    Userdata                = Get-AWSModuleUserData -userdataServerType web ｭ
-userdataUsageType bootstrap}
New-AWSModuleEC2InstanceFromAMI @ec2Param

「Amazon Document - Using Amazon EC2 Instances」と比較すると、PowerShellもAWS CLIと同じ感覚で利用できるのがわかるかと思います。リスト1は宣言的に書いたため、AWS CLIのサンプルに比べてコードが長く見えますが、IDを使わず名前を使って、意図をよりわかりやすくするほうがメリットが高いと判断しています。

同様に、インスタンスの破棄も書けるので、WindowsであってもLinuxと同様にAWS上の操作は完全に自動化できます。

UserDataでインスタンス起動時にコードを自動実行する

Linuxとほぼ同様に、WindowsインスタンスのUserDataも活用できます。もちろん、インスタンスで実行するコードを直接入力してもよいですが、処理が長い場合やバージョン管理システムで管理したい場合は、コードをダウンロードさせての実行が推奨されます。

リスト2は、GitHub上のPowerShellスクリプトをダウンロードしてインスタンスで実行させるコードです。PowerShellを使って、cURLと同じように簡単にWebリクエストができます。

リスト2　GitHubからPowerShellスクリプトをダウンロードしてインスタンスで実行させるコード（PowerShell）
<powershell>
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String((irm "https://api.github.com/repos/ACCOUNT/REPOGITORY/contents/
PATH/TO/SCRIPT.ps1").Content)))
</powershell>

PowerShell DSCでWindowsをCM

最後に、Windows Server 2012 R2においてWindowsをCMするサンプルを紹介します。リスト3では、IISとASP.NETのインストールをPowerShell DSCで実行しています。

リスト3　Windows Server 2012 R2でWindowsをCMするサンプル（PowerShell）
Configuration IISSetup
{
    WindowsFeature IIS
    {
        Ensure = "Present"
        Name   = "Web-Server"
    }
  
    WindowsFeature ASP
    {
        Ensure = "Present"
        Name   = "Web-Asp-Net45"
    }
}

これまでもChefでWindows用のレシピを書けましたが、現在はさらにDSCを呼び出してレシピを書くこともできます。dsc Cookbookがスーパーマーケットで公開されていますので、ぜひ試してみてください。これを使えば、DSCのサンプルコードをレシピで呼び出したり、同様の処理をChefの記法で書けます。たとえば、リスト3と同じ操作をChefで書くとリスト4のようになります。

リスト4　DSCを利用してIISとASP.NETをインストールするコード（Ruby）
dsc_resource 'IIS' do 
  resource_name :WindowsFeature
  property :ensure, 'Present'
  property :Name, "Web-Server"
end

dsc_resource 'ASP' do 
  resource_name :WindowsFeature
  property :ensure, 'Present'
  property :Name, "Web-Asp-Net45"
end

ChefとDSCはコード以外にも構文や機能がよく似ています。また、ChefからDSCを呼び出せるので、Linux環境にWindowsを組み込むこともこれまで以上に簡単になっています。

WindowsでImmutable Infrastructureするにあたって足りないこと

現実にはLinuxのほうがまだまだ発展しています。一例としては、決定版と言えるようなCMのテスト基盤が整っていないことが挙げられます。CMで新しい構成を組んでそれを正しく動作させるには、serverspecやPesterを使ってのテスト基盤が必要ですが、決定版と言える手法がまだ広まっていないのが実情です。よりGitHubと連携したインフラのソーシャルコーディングが求められています。

まとめ

いかがでしたでしょうか。みなさんにとって意外だったことや、参考にしていただけることはあったでしょうか。私たちは、AWS＋Windows＋PowerShell DSCという珍しい環境でどうやってDisposableを維持できるか、日々LinuxやWindowsでのやり方を考えています。WindowsでもLinuxと近いことができますが、まだまだ改善しなければならない点が数多く存在します。それでも、Windowsだからという理由だけで選択肢から外れないように、これからも事例を紹介し、足りない技術やノウハウを積極的に公開していきたいと思います。

提供／株式会社グラニ

http://grani.jp/

おすすめ記事

記事・ニュース一覧