このブログは「mobage developers blog」2016.7.21の記事を転載させていただきました。

みなさま初めまして、IT基盤部の原田と申します。

大学時代は農学部に在籍しており、コンピュータと会話している情報系の人たちを揶揄するような人間だったのですが、何の因果か、2012年にDeNAに入社して以来一貫してIT猛者の集うインフラ部隊に所属し、インフラ業務に従事してきました。相変わらずコンピュータとは仲良くなれません。

さて、そんな私が僭越ながらDeNAのインフラの紹介をしようと思います。昨今のIaaSの普及やプライベートクラウド技術の発展により、DeNAインフラも日々変化をしていますが、今回は今現在の状況にフォーカスして、DeNAが実施しているインフラ運用の概要と、少し踏み込んだ安定化や効率化周りの工夫をメインに話していきます。

以下の構成でお伝えしていきます。

• 第一回: DeNAインフラ概況 / サーバ構築・キャパシティ管理
• 第二回: 性能劣化、障害発生時のプロファイリングツールの紹介
• 第三回: オンプレミスとクラウド

DeNAインフラ概況

DeNAインフラ体制

まず最初にDeNAのインフラ体制について触れていきます。

DeNAはMobage、Yahoo! Mobage、Mobageオープンプラットフォームはじめ大規模トラフィックを扱うサービスから、社内新規事業等の数多くの小規模サービスまで、多岐にわたるサービスを提供していますが、DeNAのインフラを担当する部署はIT基盤部１箇所に集中しており、全事業部横断で担当しています。

また、運用ツールもIT基盤全体で共通のものを多く利用しています。その事によって知見が溜まりやすく、かつメンバー一人一人が複数部署をオーバラップして担当しやすい体制になっています。

DeNAサーバ概況

次に規模感をお伝えするため、サーバ概況を紹介します。 (2016年1月時点)

• サーバ数: 約4,000台

  • DRしているので実際の必要台数は半分の約2,000台

  • AWSも一部サービスで利用

• コモディティサーバを利用

• ネットワークトラフィック

  • 13Gbps

DeNAではコスト意識を非常に強くもっているため、1台あたりの性能を使い切るような運用をしており、サーバ台数を可能な限り抑えています。

サーバ構築

さて、ここから実際に普段の作業内容の紹介にうつっていきます。管理する対象のサーバが無ければ始まりませんので、まずはDeNAでのサーバ構築の話から。

OS install - mbgaclone

DeNAではOS install + 全サーバ共通な構築をした種サーバからサーバごとコピーし、各種用途ごとの構築を行っていくという方法が主ですが、サーバコピーにはDeNA独自のmbgacloneというオンプレミスサーバコピーツールを利用しています。イメージとしてはAWSでのAMIからinstanceを作るものに近いものになります。

実装は各vendor用Management Interface + PXE + anaconda + データコピー + 補助スクリプトとなっており、P2V, P2P, V2V, V2P いずれにも対応して実機、仮想問わずコピー可能で、(Hardware) RAID構成も自動で実施できるものになっています。

つまり、vendor, 物理/仮想を気にせずコピーが出来、面倒なRAID構成もoption指定だけで自動的に構築できるようになっています。

利用イメージ

Server Setup - chef

OSinstallされたサーバが準備出来たら、次にmiddleware等の構築です。

DeNAではかつてプロビジョニングツールはDeNA独自のものを主に利用していましたが、現在はDeNAインフラ全体でChefに統一しています。Chefを利用する事自体はもはや特に目新しい事ではないですが、数多くのサービスに、かつ既存の運用ルール・体制を踏襲しつつ利用するための工夫をしています。

Chefの構成としては、

Base Cookbook + Application Cookbook + Environment Cookbook

となっています。

それぞれについて簡単に説明しますと、

• Base Cookbook

  • 全サーバで共通で必要な構成を記述した基底的なCookbook

• Application Cookbook

  • software/middlewareを構成 (install, 設定)するCookbook

  • 1softwareで1Cookbook (例: apacheで1Cookbook, mysqlで1Cookbook)

  • attributeを外部から指定することで処理を変更することができる

• Environment Cookbook

  • 実際に直接的に実行されるCookbook

  • 1サービスに1Cookbook

  • 用途ごとに必要なセットアップ処理を実行する

つまり、共通部分(Base Cookbook / Application Cookbook)はDeNAインフラ全体で共有し、各サービスの細かな差分はそれぞれのEnvironment Cookbookで吸収できるようになっています。

またその他の工夫としては、jenkinsと連携させて、Cookbookのgit reposにpull requestされたブランチに対して自動的にテストを行ったり、chef why-runを利用したサーバ構成のテストを行ったりしています。

キャパシティ管理

用途ごとのサーバを構築したら、それを日々のトラフィックに合わせた適正な台数に調整していきます。リアルタイムに、かつグラフィカルに傾向をつかむため、DeNAでは fluentd + Elasticseach + kibana を利用しています。それぞれの役割は下記のとおりです。

• fluentd : ログ収集ミドルウェア

• Elasticsearch : 全文検索システム

• Kibana: Elasticsearchにクエリを発行し、グラフで可視化する

fluentdで各サーバのメトリクス(CPU, Memory, Disk… etc)、リクエスト数、レスポンスサイズ等をElasticseachに突っ込んで、そのデータをkibanaで見るといった構成になります。

(左: APIごとのリクエスト数推移  右:APIごとの利用ゲーム内訳)

各APIへのアクセスが時間帯に寄ってどう変化しているか、また各APIにおいてどのゲームが支配的であるかなどがひと目で分かるようになっています。

例えば特定ゲームがイベントを開く場合、グラフを見るだけである程度の予測が付けられるので、そのゲームが多く利用する部分だけ事前にキャパシティ強化しておく、といったことでき、素早い対応の手助けになります。

まとめ

- DeNAのインフラ体制は全事業部横断で担当することで知見をためやすい体制にしている

- OSinstall部分は、vendor, 物理/仮想問わずコマンド一つでオンプレミスにおけるサーバコピー(RAID構成も)ができるツールを独自開発して利用している

- サーバ構築にはchefを利用しているが、数多くのサービス、多種多様な用途のサーバ構築を知見が分散しないような構成で管理している

- fluentd / Elasticsearch / kibana を用いてサーバのメトリクス情報を取得閲覧できるようにしており、格納されたデータはキャパシティ管理の他にもトラブルシューティングなどの用途に利用している

次回は性能劣化、障害発生時に利用しているプロファイリングツールの紹介をしようと思います。