#cross2012 クラウドCROSS ニフティの中の人によるニフティクラウド活用

Copyright © NIFTY Corporation All Rights Reserved.Copyright © NIFTY Corporation All Rights Reserved.

ニフティの中の人によるニフティクラウド活用

2012年1月27日ニフティ株式会社

安部潤一郎

Copyright © NIFTY Corporation All Rights Reserved. - 1 -Copyright © NIFTY Corporation All Rights Reserved.

自己紹介

• 安部潤一郎 Twitter @abej

• 所属ニフティ株式会社

サービスプラットフォーム統括部

サービス基盤開発部

• インフラエンジニア

ウェブオペレーター / オペレーションエンジニア

• ニフティクラウドの中の人

ニフティクラウドを使って、サービスを構築/運用してい

ます。


ニフティクラウドとは

• IaaS型パブリッククラウドコンピューティングサービス

• 2010年1月より、お客様へも提供開始

• 1,000社以上の導入実績


クラウドをどう使っているか（Webサービス関係）

コンテンツ管理システム

ニフティクラウドIaaS

SaaS 個別構築

IaaS（ニフティクラウド）をベースに、大きく２通りの使い方

– SaaSまで構築したシステムを使う

– 個別に構築して使う


SaaSを使うケース



SaaS個別構築

@niftyのポータルサービス向けコンテンツ管理システム

– 最小限の開発で、大量生産大量運用可能

– 100以上のサービスが稼働

– なるべくこちらを使いたいが、制約がある

– いわゆる、NoOps の世界


IaaSベースに個別に構築するケース



SaaS個別構築

SaaSのシステムで対応できない場合、個別構築

– 協業案件など、社外で開発・運用するケース

– 特殊な要件

– いわゆる、DevOps の世界

こちらのケースのインフラを担当しています。


例えば

• コンテンツ制作・運用，開発は他の会社。インフラはニフティで。

当然、サービスは落とさないように。セキュリティ対策もヨロシク。

• 社外のシステムを使っていたけど、利用者が増えてシステムの限界に。ニフティクラウドに移行して運用して。

• 200MBのファイルを何十万件もダウンロードさせたい。

「CDNですね」「ニフティクラウドで安くできない！？」

• 事業部長「サービスごと買って来たよ。システム移行してね。」


規模感的には

• ビジネス化するかまだ分からない、スモールスタートなサービス

から

• 月間 PV 3億以上, ユーザ100万人以上のサービス

• １週間で10万ユーザ登録してくる、ソーシャルゲームの

サービス

まで様々


お話しする内容

様々な体制，様々な要件の案件に対して、

① 最低限の品質を守る

② なるべく効率的に、構築/運用する

③ 各種要件に対応する

過去：クラウドが無かったとき、どうだったか。現在：クラウドがある今、どうしているか。

考え方がどう変わったか。

特にクラウドに関係する部分について



・サーバの冗長化

・ミドルウェアの適切な設定, 監視

・ステージング, デプロイの整備

・ネットワーク, フィルタの適切な設定

② なるべく効率的に構築/運用する



サーバの冗長化

• SPOF（単一障害点）を無くす。

• ハード故障に備えて、同一機能のサーバを複数用意。

• 管理ツール, 非オンラインのバッチサーバなども2台ず

つ用意。

• 確かに冗長・・・

クラウドクラウドクラウドクラウド以前以前以前以前


サーバの冗長化

• （ニフティクラウドでは）サーバのホストで物理的な障

害が発生しても、別のホストで自動的に再起動。

• 管理ツール, 非オンラインのバッチサーバなど

数分程度停止しても問題ない機能であれば、

その機能を１台でも運用。

（念のため安定稼働時のサーバのコピーをとっておく）

クラウドクラウドクラウドクラウド以後以後以後以後


ミドルウェアの適切な設定, 監視

• Apache, MySQL, ... 適切に設定

• リソース監視, 死活監視

• サービス/システム個別に担当者が設定。

• ノウハウを共有していても限界が・・・

– 不適切な設定で、問題発生。火消しに。

– 問題が発生しても、必要なメトリクスが無い。



ミドルウェアの適切な設定, 監視

• あらかじめ、ソフト・検証済みの設定・監視をセットアップしたサーバイメージを用意。コピーして使う。

バリエーションを増やすのは難しい。融通が効かない。

• 自動セットアップスクリプトでセットアップ

（クラウドなら起動スクリプト）

はじめはいいけど、運用してると変わってくる。

• Puppet / Chef の使用（クラウドAPI使用）



ステージング, デプロイの整備

• 本番になるべく近い環境のステージング環境整備

• 安全で簡単なデプロイの仕組み

• サービス/システムによって、整備が不十分だったり。

• ハードが違って、本番とステージングに差異があったり。



ステージング, デプロイの整備

• 基本的に、ステージング環境をまずセットアップ。

• ステージング環境のサーバをコピーして本番環境作成。

• デプロイツールもあらかじめ入れておく。

（クラウドAPIでデプロイ用定義生成）


ステージング環境

本番環境


ネットワーク, フィルタの適切な設定

• ファイアウォール, ロードバランサーを適切に設定

• ネットワーク専門の担当者が設定・確認。



ネットワーク, フィルタの適切な設定

• コントロールパネルで

ポチポチ設定できる。

• まずい設定を回避するために– API で、基本的なルールを一括設定

– ルールに従っていない設定を自動検知

– 特別な要件による設定は、確認/承認の上設定





・システム設定の自動化, 一括構築



システム設定の自動化, 一括構築

• OSの/etc以下の設定やソフトの設定

• Web,Apl,DB 3層のサーバ/ネットワークを構築

• ネットワークブート, 各種ツールで対応



システム設定の自動化, 一括構築

• クラウドのAPIを使って、よりカンタンに、統合的に設定

構築できる。


本番環境

クラウドサーバ群管理サーバAPI

API利用管理サーバ



自動設定シンプルな例

• 簡単な例 hosts 設定


本番環境

ENDPOINT = クラウドサーバ群管理サーバdesc "各サーバの /etc/hosts を更新する"task :hosts, :roles => [:web, :apl, :dbm, :chk, :bat, :kvs] do

run "cp /etc/hosts /etc/hosts.`date +%Y%m%d`"

url = ENDPOINT + "api/instances.txt?for=hosts"

put open(url).read, "/etc/hosts"

end

クラウドサーバ群管理サーバ

（整形）

API



一括構築

• ネットワーク, ロール（web,db...）, サーバを yamlで定義すると、一括でネットワーク設定/サーバ構築

instance_groups:

- production:

- web

- apl

- db

default_ip_list:

- basic_monitoring_ping:

- 202.248.175.141

- 111.171.220.13

default_fw_list:

- desc: MySQL

from: fw:apl

to : fw:db

type: tcp

port: 3306

:






・急激な負荷増

・高いスペックのサーバが欲しい

・ IO性能が必要な高トラフィックサービス


急激な負荷増

• ソーシャルゲームで、プロモーションかける

• 季節物/イベント WBC とか

• 机上で試算したら、平常時の5倍リクエスト来るかも・・・

• 物理サーバ追加/増設大変…

• イベントが終わったら、機材どうする？



急激な負荷増

• 簡単にサーバ増やせる減らせる

– イベント前に、フロントサーバを 30台盛る。

– 何日か経過して 20台でさばける → 減らす。

• 本当に突発的な負荷増には、オートスケールで対応。



高いスペックのサーバが欲しい

• データ分析したい

• 一通りテストしているが、まだ非効率な処理が残っているかも。リリース後のリスクを減らしたい。

• 物理サーバやパーツ追加/増設大変…

• 必要無くなったけど、この 16コアCPUどうする・・・？

• もっとテストを徹底して、リスクを減らしましょう。



高いスペックのサーバが欲しい

• 必要に応じてスペックアップ– CPU 8コア追加しておこうとか。

– 使い終わったら削除。

• リスクを減らすために、新機能リリース時だけ、

スペックアップして、問題無ければ戻すのも簡単。




IO性能が必要な高トラフィックなサービス

• ソーシャルゲームのデータベースなど

• 高性能な物理サーバを使う– SSD使ったり

物理物理物理物理サーバサーバサーバサーバ



データストアの使い分け。

(a) 課金/基本情報/アイテム所持→ RDBに保存。スレーブで参照分散

(b) ゲームのセーブ情報/セッション情報更新多い。→ 永続化できるKVSに保存（KyotoTycoon, kumofs など）

(c) 特によく参照する情報→ RDBからmemcachedにキャッシュ

(d) アクションログデータの記録→ ファイルやmongodb 非同期書き込み。

よく使うデータをメモリに。




・・・と、工夫しながら対応していましたが、2011年9月 Disk 200 リリース（ニフティクラウド）

http://ncloud.cocolog-nifty.com/blog/2011/09/disk200-4776.html

高負荷なデータベースサーバも結構いける


スループット300 MB/sec

以上



さらに、追加ディスクは、LVMをかましてマウント

• ディスク追加で、要求が分散して性能がアップするかも。

• 容量をカンタンに追加できる。

• スナップショットをとれる。

（スナップ取得中、性能低下するため、取得タイミングや取得場所は要注意）



まとめ


② 効率的に、運用構築


クラウドが無かったときどうだったか、

クラウドがある今、どうしているか。

今後は、さらに、プログラマブルなインフラに。

クラウドと一緒に進化していきたい。続きは後半で


ニフティクラウドちょっとPR

2012年1月17日から、

個人事業主の方にもニフティクラウドを、

ご利用いただけるようになりました。

今なら、ニフティクラウド体感キャンペーンで、

30,000円分無料でお試しいただけます。

→ http://cloud.nifty.com/


Technology

#cross2012 クラウドCROSS ニフティの中の人によるニフティクラウド活用