はじめに
突然ですが，みなさんはWindowsやWindows Serverに対してどのような印象をお持ちでしょうか？ Linuxと比べて良い点や悪い点はあるのはなんとなくわかるものの，総合的に，Windowsに対してあまり良いイメージを持たれない方も多いのではないでしょうか。
私たちの会社では，GREE向けにリアルタイムギルドバトル（注1）と呼ばれるジャンルのソーシャルゲームをAWS＋Windows環境を使って提供しています。Web 業界全体を通しても珍しい，AWSかつWindowsという組み合わせの大規模Webアプリケーションをどのように提供し，継続的に運用しているのか，実際のところはどうなのか，といった点を今回は紹介したいと思います。
グラニが提供するソーシャルゲームの規模
実際に弊社で提供している「神獄のヴァルハラゲート」の規模感は次のようなものになります。
| PV数 | 100,000,000 PV/日 |
|---|
| 瞬間最大リクエスト数 | 10,000リクエスト/秒 |
|---|
| 瞬間最大クエリ数 | 25,000クエリ/秒 |
|---|
| Redisの瞬間最大コマンド発行回数 | 230,000コマンド/秒 |
|---|
リアルタイムギルドバトルというジャンルの性質上，リクエスト数を描くグラフは極端になりがちで，ピーク時には恐ろしい数のリクエストに襲われます。また，弊社ではRedisを最大限に利用しており，Redisへのリクエスト数がデータベースクエリ数の10倍になることもあります。これくらいの規模になると，数十ミリ秒のスロークエリが1つあるだけ
で致命傷になり，サービスがダウンすることも珍しくありません。
グラニの開発／運用環境
グラニでは次のような技術やツールを使っています。
- OS
- Windows Server 2012
- Amazon Linux（ Redisのみ）
- Web／アプリケーション
- IIS
- ASP.NET MVC 5.0
- C#
- Glimpse
- DB／キャッシュ
- MySQL 5.6（ RDS）
- Redis 2.6
- その他
- New Relic
- Sumo Logic
- GitHub
- Jenkins
- PowerShell
- Tools
- Visual Studio 2013（＋ReSharper）
- SourceTree for Windows
- HeidiSQL
- Remote Desktop Connection Manager
開発環境も本番環境も基本的にWindowsを使っていますが，データベースはSQL ServerではなくMySQLを使っていたり，キャッシュストアとしてもRedisを使っていたりと，Windowsの世界だけで完結しているわけではありません。ほかにもNew Relicでアプリケーションのパフォーマンスを監視していたり，Jenkinsを使ってCIを行っていたりと，みなさんがよく使っているであろうサービスや技術を組み合わせた開発／運用を行っています。
実際の開発フローも，Visual Studioでコーディングし，SourceTreeを使ってGitHubにプッシュ，ときにはプルリクエストを送ってコードレビューをしてもらい，マージされたコードはJenkinsでビルドしてブランチに対応した開発環境へデプロイする，というように，Windowsでも最近よくあるWeb開発と遜色ない開発が可能です。
また，すべてのエンジニアは開発／本番環境のサーバに自由に入ることができ，本番環境へのリリース作業などを行う権限があります。
AWS＋Windowsの実際
グラニではAWS上でWindowsを動かしていますが，やはりWindowsならではの「つらみ」はそれなりにあります。ですが，一般的に思われているよりは間違いなくハードルは高くなく現実的です。次は，AWS＋Windowsという環境が実際にどうなのかを紹介します。
使えるソフトウェア／ミドルウェアの幅はグッと狭まるが戦うことはできる
当たり前ですが，流行りのソリューションのほとんどはLinuxをメインターゲットとしています。Windowsにまで対応しているものはまれですし，「Rubyが動けば動くよ」といったものでも，Windows版のRubyで使おうとするのはほとんどが茨の道だったりします。Microsoftの世界を抜けると途端に選択肢が狭まってしまう──これがWindowsを使ううえでの最大の欠点と言えます。しかし，サービスを開発／運用していくうえで致命的になる，あからさまに不便になる，というほど選択肢がないわけではありません。Redis，memcached，MySQLなどのよく使われるサーバ製品であればLinuxサーバとして独立させることが可能ですし，実用的な.NET用のクライアントもあります。後述しますが，サーバをプロビジョニングするソリューションに関しても，豊富とは言えないものの現実的な手段があります。
選択肢自体は豊富ではないものの，大規模Webアプリケーションを相手にするだけの基盤は整っていると思ってよいでしょう。このあたりは実際のモデルケースとして弊社が示していきたいと思っていますし，実際にいくつかのソリューションをオープンソースとして公開しています。
お金は意外とかからない
ライセンス代やサーバ代がお高いんでしょう？ と思われる方も多いかと思います。確かに単体で見れば，EC2のインスタンスもLinuxと比べて1.5～2倍近い値段になりますが，これについては最も台数が増えやすいであろうWeb／アプリケーションサーバの数をいかに減らせるか，つまりアプリケーション単体でどれだけパフォーマンスを出せるかが勝負になってきます。
実は，弊社も立ち上げ時にはLAMP環境でアプリを提供しており，途中でC#＋Windows環境に完全リプレースしたのですが，アプリ側のロジックはほぼ同じだったにもかかわらず，レスポンスタイムで5～6倍の数値，サーバとしても2～3倍のリクエストをさばけるようになったため，サーバの台数が半分以下になってサーバ代はむしろ安くなった，というエピソードがあります。この話に関しては多少でき過ぎ感はありますが，ある程度パフォーマンスを出せればトータルのコストはそんなに変わらない，という考え方もできるでしょう。
BizSparkを有効活用しよう
ちなみにIT系のスタートアップ企業に限れば，BizSparkというベンチャー向けプログラムの利用を強くオススメします。BizSparkを利用すると，Visual StudioやOffice，Windows Server，SQL Serverなどのライセンスを無料で取得できます。参加条件は厳しくなく，ほとんどのスタートアップが該当するのではないでしょうか。
Windowsでのサーバプロビジョニング
最近のインフラエンジニア界隈では，「Infrastructureas Code」「Immutable Infrastructure」というキーワードがよくテーマになります。Windowsでも，これらのテーマを実現するサーバプロビジョニングのしくみが用意されています。
PowerShell
「そもそもWindowsってGUIしかないんじゃないの？」「あの貧弱そうなコマンドプロンプトを使ってるんでしょ？」「.bat的なアレ。」というイメージを持たれる方も多いですが，WindowsのCUIと言えばPowerShellです。PowerShellについては詳しく触れませんが，特徴の1つとして，コマンドの実行結果がすべてオブジェクトで返ってくることが挙げられます。Linuxではすべてテキストで返ってくるため，grepやawkを組み合わせた文字列操作を行う必要がありますが，PowerShellではオブジェクトが返ってきて，かつメソッドを適用できるため，より直感的かつ保守しやすいスクリプトを書けます（図1）。
図1 PowerShellの例
またPowerShell ISEというIDEを使うと，入力補完がサポートされ，デバッグ実行も容易に行えます。
さらに，PowerShell DSCというしくみもあります。簡単に言うと，LinuxにおけるChefです。サーバ構成があるべき状態をコードとして記述すると，そのとおりにサーバを構成する，というように，サーバプロビジョニングなどの処理結果の冪等性（べきとうせい）を保証してくれます（図2）。
図2 PowerShell DSCでIISの状態をコードとして記述している例
valentia
valentiaは弊社のインフラエンジニア（@guitarrapc_tech）が作成したPowerShellのライブラリで，リモートのコンピュータに対して並列でコマンドを実行できるものです。簡単に言えば，LinuxにおけるCapistranoです。弊社ではこのvalentiaを使い，複数台のサーバへ並列にアプリケーションをデプロイしています。ちなみに，valentiaはOSSとして公開されています。
Windows向けAPI
AWSはWindows向けのAPI操作のツールも提供しています。これによって，C#やPowerShellからでもEC2インスタンスの作成／起動／停止などをプログラマブルに行えます。
このように，けっしてLinux環境ほど充実しているとは言えませんが，Windows環境でもImmutableなインフラを作っていくためのしくみは存在します。
つらみがある中，なぜWindowsなのか
「C#が好きだからです（笑）」というのは半分冗談で半分本気ですが，厳密にはC#という言語自体のパフォーマンスや構文であったり，Visual Studioの使い勝手の良さ，優れた保守性など，エンジニアがアプリケーションを開発する点においてほかの言語や環境と比べて圧倒的に優位であると思っており，C#を軸とした開発基盤で開発を行いたいからです。このあたりのこだわりは，弊社CTOの河合の記事に詳しく書かれています。
また大事なのは，いかに良いサービスをユーザに提供できるか？ だと思いますが，良いサービスを生み出すには，サービスを開発するエンジニアが気持ち良く開発できる環境が
必須だと思っています。C#が気持ちの良い開発を実現してくれると思っていますし，結果的に良いサービスを提供することにつながると信じているので，私たちはそれなりのつらみがあってもWindowsを選択しています。
まとめ
いかがでしたか。みなさんの想像どおりの部分もあったかとは思いますが，意外な事実も多かったのではないでしょうか。AWS＋Windowsというかなり珍しい環境の話でしたが，実はだいたいのことがLinuxと遜色ない形でできますし，現実的に手が届くレベルではあります。しかし，細かいところでまだまだ足りていないものも多く，誰もが気軽に手を出せるかと言うと，そうではありません。サービスを開発するエンジニアがC#を使いたい！ といったときに，インフラエンジニアが安心してWindowsを提供できるように，Windowsだからという理由で選択肢から外れないように，これからも私たちはモデルケースとなり，足りていない技術やノウハウを積極的に公開していきたいと思います。
- 提供／株式会社グラニ
- http://grani.jp/
- グラニでは各種エンジニアを募集しています。
- 詳細はこちら→http://grani.jp/recruit/
