SQL Server 2014 実践シリーズ （HTML 版）
「No.1 インメモリ OLTP 機能の実践的な利用方法」

1.8　bwin 社における利用例

ここからは、早期導入／検証を行った企業では、どのようにインメモリ OLTP を利用したのか、具体的に見ていきます。

bwin 社（オンライン ゲームなどを提供する会社）では、従来 1秒あたり 1万5千件の Batch Request（SQL Server に対するバッチ要求）を処理していたところを、インメモリ OLTP 機能を採用／移行することで、1秒あたり 25万件もの Batch Requestを処理をできるようになりました（16.7倍もの性能向上）。

bwin 社での早期導入の詳細については、以下の米マイクロソフトの事例（Case Studies）サイトに記載されています。
http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2014/bwin.party/Gaming-Site-Can-Scale-to-250-000-Requests-Per-Second-and-Improve-Player-Experience/710000003117

また、2014年 5月に米ヒューストンで開催された Microsoft TechEd North America 2014 での以下のセッションでも詳細が説明されていたので、ここではその内容を要約します。

Microsoft SQL Server 2014: In-Memory OLTP Customer Deployments and Lessons Learned
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DBI-B313#fbid=

◆ Web サイトの利用状況 ～15万/日、100万新規ユーザー/年～

bwin 社が運営する Web サイト（オンライン エンターテイメントを提供している Web サイト）では、1日あたり 15万人以上のアクティブ ユーザーがアクセスし、毎年 100万人以上の新規ユーザーが登録されています。年間収益は 6.5億ユーロにもなります。

◆ ASP.NET のセッション状態データベースで負荷集中 ～ラッチ待ちの多発～

Web サイトの構成は、次のとおりです。

Web サーバー ファーム（多数の Web サーバーによるフロントエンド）に、ASP.NET のセッション状態（セッション変数）を格納するためのデータベースとして、SQL Server が利用されています。Web サーバー上のそれぞれの Web ページからは、SQL Server に対して「2」個のバッチ要求が発生していて、ピーク時には SQL Server への負荷が集中していました（これは、同時に 1万ページ分のアクセスがある場合に、2万ものバッチ要求が発生する状況です）。

インメモリ OLTP を導入する前のシステムでは、ラッチ待ちが多発することによって、最大スループットが「15,000 バッチ要求／秒」で頭打ちになっていました。これは、RamDrive を利用（メモリをストレージとして利用）している場合にも同様でした。また、Latency（遅延、クライアントへの応答時間）も加速度的に増えていっており、これを解決する必要がありました。

◆ ラッチ フリー、SCHEMA_ONLY の利用

この問題を解決するために、同社では SQL Server 2014 のインメモリ OLTP を採用することで、1秒あたり 25万件ものバッチ要求を処理をできるようになりました（16.7倍もの性能向上）。

このような性能向上が実現できた理由の 1つは、インメモリ OLTP がラッチ フリー（ラッチを利用しない同時実行制御）のアーキテクチャであるためです。これまでのシステムでは、多数の同時アクセスが行われた場合に、ラッチ待ちが多発して、スループットに限界がありましたが、インメモリ OLTP では同時アクセス数が増えてもラッチ待ちが発生しないからです。

性能向上の理由には、ASP.NET のセッション状態に関するテーブルに、「SCHEMA_ONLY」オプションを採用したことも大きく関係しています。このオプションでは、データを永続化することなく、メモリ内にのみデータを配置します。これにより、トランザクション ログへの書き込みが必要なくなるので、インメモリ OLTP 機能の性能を最大限に引き出すことができます。

◆ クライアント コードは未修正、互換性を保つ ～BLOB への対応～

今回、インメモリ OLTP の採用を決定したチーム（インフラ チーム）には、クライアント コードをコントロールすることができなかったので、インメモリ OLTP 化にあたっては、クライアント コードへの 100%の互換性を保つことも要求されていました。

クライアント コードへの互換性を保つためには、セッション状態を格納するための列が BLOB（image／varbinary(max) データ型）であることが課題でしたが（∵インメモリ OLTP 機能では BLOB へネイティブに対応していないため）、これに対しては、データを分割することで対応しています。この BLOB データの分割については、オンライン ブックの以下のトピックに実装例が記載されているので、参考になると思います。

メモリ最適化テーブルへの LOB 列の実装
http://msdn.microsoft.com/ja-jp/library/dn296676.aspx

なお、後述の「Microsoft ASP.NET Session State provider for SQL Sever In-Memory 1.0.1」を利用した場合には、自動で BLOB への対応が行われたセッション状態データベースを作成することもできます。

◆ Write-Write 競合への対応 ～エラー 41302～

インメモリ OLTP 機能は、ロック フリー（ロックを利用しない同時実行制御）のアーキテクチャなので、同じデータへの同時更新が発生した場合には、Write-Write 競合（更新競合）が発生します。この場合は、先に更新した方が勝つ方式（First Writer Win）をとり、負けた方（後から更新した側）には、エラー 41302 が通達されます。bwin 社では、エラー 41302 が発生した場合には、次のように再試行を行うロジックを利用することで、Write-Write 競合への対応を行っています（Write-Write 競合については、第2章と第4章でも説明しています）。

◆ 1秒あたり 450,000 バッチ要求も達成 ～約30倍の性能向上～

bwin 社では、Lab 環境での最新の検証では、450,000 バッチ要求/sec を処理できることも確認しています（元々は 15,000 バッチ要求/sec だったので、約30倍の性能向上）。

◆ ASP.NET Session State provider for SQL Sever In-Memory

ASP.NET のセッション状態データベースのインメモリ化は、NuGet（.NET 用のパッケージ マネージャー）から取得できる「Microsoft ASP.NET Session State provider for SQL Sever In-Memory 1.0.1」を利用すると、簡単に実装することができます。

http://www.nuget.org/packages/Microsoft.Web.SessionState.SqlInMemory/

このプロバイダーをインストールすると、次のようにインメモリ化するためのスクリプトが提供されているので、簡単にインメモリ化することができます（詳しくは、第4章で説明します）。