グリーがOpenStackで目指す“適材適所”なクラウド環境：特集：これからのIaaSニーズと失敗しない選択基準（3）（1/2 ページ）

　Amazon Web Services（以下、AWS）が世界のクラウド市場で独走を続ける一方で、ここ1年ほどの間に急激にその存在感を増しているクラウドソリューションがOpenStackだ。AWSやプロプライエタリの仮想化環境と比べれば未成熟な部分もあることは否めないものの、IBMやRed Hat、HP、Dellといった大手ITベンダーがプロジェクトに積極的に関わっている信頼感も手伝って、OpenStackを使ったプライベートクラウド導入に踏み切る企業が国内でも増えつつある。

　ソーシャルゲーム市場でトップの座を争うグリーもまた、OpenStackの導入に踏み切った企業の一つだ。本稿では2月13〜14日の2日間にわたって東京で開催された「OpenStack Days Tokyo 2014」のセッションから、14日に行われた基調講演「GREEにおけるOpenStackの導入事例」の概要を紹介。大規模環境におけるOpenStack導入および運用のメリットと課題を検証してみたい。

欲しいのはスケールアウト自在のインフラ

　現在、国内ソーシャルゲーム事業者の多くは、サービスの提供においてもプロダクトの開発においても、プラットフォームとしてAWSを選択している。だが今年で創業10年目を迎えるグリーは、AWSがクラウド市場を開拓する前から事業を展開しており、物理サーバーによるサービス提供を中心としてきた。「内製を含めて1000を超えるプロダクトを、1万台以上の物理サーバーに載せてオンプレミスで運用してきた」と、グリー 開発統括本部 インフラストラクチャ本部 渡辺光一氏は説明する。

グリー 開発統括本部 インフラストラクチャ本部 渡辺光一氏

　人気のあるサービスやゲームの場合、1つのサービスに100台以上のサーバーが割り当てられることも少なくないという。事業が拡大すれば、当然ながらユーザーもプロダクトの数も増え、サーバーへのアクセスも増えていく。厄介なのは1日に数回訪れるピーク時のトラフィックだ。

　そこで急激なトラフィック増によるサービスの遅延や停止を防ぐため、独自ポータルの「サーバーダッシュボード」を使ってハードウェアの管理を自動で行ってきた。サーバーの構築は、「セットアップツールを使って自動で終わらせるようにしている」（渡辺氏）とのこと。ダッシュボードとツール、物理サーバーの連携は全てRESTful APIを通して行われている。

図1　独自ポータルの「サーバーダッシュボード」を使って物理環境を効率的に管理してきた（講演資料より）

　「重要なのはサーバーのスケールアウトが自在にできるインフラであること。必要に応じてサーバーを足せるように、ベアメタル（物理サーバー）を共通のプールに配置している。ハードウェアが故障したりサービスから外れたりした状態になった場合は、サーバーダッシュボードから代替のリソースをデプロイするオペレーションサイクルになっている」(渡辺氏)

オンプレミスの課題と仮想化に対する不安

　では、このように物理サーバーで回せる運用を基本としながら、なぜOpenStackの導入に踏み切ったのか。渡辺氏はオンプレミスにおける3つの課題を挙げている。

　1つ目はサービスの内容に適したサーバーリソースの割り当てが難しいこと。グリーでは膨大な数のサービスやロールが運用されているが、ときにはバッチサーバーやゲートウェイにオーバースペックな物理サーバーが割り当てられていることもある。そうした無駄を減らし、リソースの最適化を図ることで運用の負荷を減らすのは、インフラ管理の重要なポイントとなる。

　2つ目はテストの自動化に時間がかかること。テスト環境を迅速に用意できればコードデプロイまでの期間をより短縮できる。テスト環境を用意することも終了後に破棄することも、仮想環境の方がずっと速く楽にできるのは明白だった。

　3つ目のポイントは運用コストの問題だ。障害復旧機能（High Availability／Fault Tolerance）やライブマイグレーション、フローティングIPなど、仮想化ならではの機能を使えば、大規模環境ほど大きなコスト削減効果が見込まれるはずと考えた。

　しかし一方で「仮想化に対する懸念点もあった」と渡辺氏は話す。パフォーマンスの劣化、信頼性の低下、無駄な導入パッケージによるコストの増加、などだ。「パフォーマンスに関しては、場合によっては5〜50％も劣化するという報告もあり、慎重に精査した。また、仮想化を進めることで、物理サーバーそのものが見えにくくなり、かえってインフラが複雑になるのではという不安もあった」（渡辺氏）