[当日発表資料]AWS_Summit_CYBIRD_fix.key

(1)

ゲーム事業本部恋愛ゲームチーム藤原涼!

ゲームインフラチーム本田恭!

AutoScale ×

ゲーム

(2)

運用効率化に向けたAWS導入背景から運用のお話

AWSをさらに活用するための技術的なお話

∼後半∼

∼前半∼

Agenda

(3)

１：サービスの特徴とシステム

２：AWSの導入に向けて

３：AWSを利用して発生した問題

Agenda

(4)

自己紹介

藤原涼 (ふじわらりょう)

-

2012年新卒入社 (3年目)

-

Twitter @megadreams14

AWSを使い始めた日

-

２０１３年６月１７日（月）

(5)

女性向け

「恋愛ソーシャルゲーム」

における導入事例

(6)

(7)

恋愛ソーシャルゲームとは

華やかで

甘いストーリー

が楽しめる

(8)

アバターなどを

着せ替えて可愛く

コーディネイトできる

恋愛ソーシャルゲームとは

http://ikemen.cybird.ne.jp/of/play.html

(9)

恋愛ソーシャルゲームとは

(10)

(11)

現在提供している恋愛ソーシャルゲーム

イケメン大奥

恋の園

イケメン恋戦

平清盛

100 日間のプリンセス

もうひとつのイケメン王宮

イケメン王宮

真夜中のシンデレラ

新章イケメン大奥

禁じられた恋

イケメン幕末

運命の恋

ラブセン

∼Ｖ６とヒミツの恋∼

美男宮殿

月下灰姑娘

美男大奧

江戶奇緣

イケメン夜曲

ロミオと秘密のジュリエット

한밤중의 신데렐라

(12)

現在提供している恋愛ソーシャルゲーム

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

d

ゲーム

(13)

現在提供している恋愛ソーシャルゲーム

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

d

ゲーム

(14)

(15)

朝と夜にアクセス上昇

月１回の大きなイベント

(16)

朝と夜にアクセス上昇

弊社恋愛ソーシャルゲームの特徴

通勤通学時間帯・日付変更時に集中

http://gamebiz.jp/?p=127080

1 日のアクセス数の変化

朝

夜

(17)

月１回の大きなイベント

弊社恋愛ソーシャルゲームの特徴

通常の約５倍のアクセス

(18)

月１回の大きなイベント

弊社恋愛ソーシャルゲームの特徴

アバターの付与

華やかにドレスアップ♪

「100日間のプリンセス◆もうひとつのイケメン王宮」より

(19)

月１回の大きなイベント

弊社恋愛ソーシャルゲームの特徴

アバターの付与

華やかにドレスアップ♪

(20)

(21)

弊社恋愛ソーシャルゲームのシステム要件

Web LoadBarancer

Web

サーバ

アバター合成サーバ

Server Server Server

Image LoadBarancer

(22)

１：サービスの特徴とシステム

∼前半∼

２：AWSの導入に向けて

３：AWSを利用して発生した問題

Agenda

(23)

(24)

イベント前のサーバ追加

手動でサーバ追加

サーバの追加に時間がかかる

(25)

コンテンツ数が多い

イベント前のサーバ追加

LB

AWS

を使うまでの苦労

(26)

事前追加や障害対応

アラートメール

状況確認

サーバ追加

手動でサーバ追加

AWS

を使うまでの苦労

(27)

３０分∼２時間程度

サーバの追加に時間がかかる

サーバ追加

ステータスが変わらない

(28)

機会損失

運用コスト

運用上の課題

(29)

AutoScale

(30)

AutoScale

とは

サーバの負荷に合わせて

自動でサーバを追加/削除する機能

(31)

(32)

サーバ構築の自動化

スケールイン時のデータの扱い

(33)

増えるだけでなく減ること

も考慮

ログファイル

セッションデータ

画像ファイル

(34)

サーバ構築の自動化

スケールイン時のデータの扱い

(35)

AMI

画像ファイル

Apacheの設定

ミドルウェアのインストール

AMI

で実現可能・・・だが

(36)

現在提供している恋愛ソーシャルゲーム

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

Ameba

AppStore

GooglePlay

AppStore

GooglePlay

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

d

ゲーム

(37)

(38)

サーバ構築の自動化を目指して

手動によるミスを無くすことが出来る

サーバごとに設定値を変更出来る

繰り返し作業を自動化出来る

Chef

導入理由

(39)

NTP

のインストール

ユーザディレクトリの設定

yum: epel

レポジトリ追加

yum: remi

レポジトリ追加

yum: td

レポジトリ追加

yum

のキャッシュをクリア

swap

領域の設定

SELinux

の設定

ユーザの作成

sudo

権限の設定

ファイアウォールの設定

【AWS】CLIのインストール

【AWS】S3コマンドのインストール

コンパイル系パッケージインストール

mail,sar

コマンドなどのインストール

git

のインストール

社内gitレポジトリへのアクセス設定

SWFEditor

のインストール

Imagick

のインストール

PHP

のインストール

PHP

パッケージのインストール

MySQL

クライアントのインストール

Fluentd

クライアントインストール

Apache:

インストール

ZABBIX: agent

インストール

Chef:knife

コマンドの設定

起動スクリプトの配置

起動スクリプトのデーモン化

ホストの設定

【AWS】ディスクパーティションの設定

Apache : virtualhosts

の設定

Apache :

起動

ZABBIX: agent

起動

Fluentd : td-agent:

起動

全３４項目

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

(40)

NTP

のインストール

ユーザディレクトリの設定

yum: epel

レポジトリ追加

yum: remi

レポジトリ追加

yum: td

レポジトリ追加

yum

のキャッシュをクリア

swap

領域の設定

SELinux

の設定

ユーザの作成

sudo

権限の設定

ファイアウォールの設定

【AWS】CLIのインストール

【AWS】S3コマンドのインストール

コンパイル系パッケージインストール

mail,sar

コマンドなどのインストール

git

のインストール

社内gitレポジトリへのアクセス設定

SWFEditor

のインストール

Imagick

のインストール

全３４項目

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

PHP

のインストール

PHP

パッケージのインストール

MySQL

クライアントのインストール

Fluentd

クライアントインストール

Apache:

インストール

ZABBIX: agent

インストール

Chef:knife

コマンドの設定

起動スクリプトの配置

起動スクリプトのデーモン化

ホストの設定

【AWS】ディスクパーティションの設定

Apache : virtualhosts

の設定

Apache :

起動

ZABBIX: agent

起動

Fluentd : td-agent:

起動

約２０分

(41)

NTP

ユーザディレクトリの設定

yum:

yum: remi

yum: td

yum

swap

SELinux

ユーザの作成

sudo

ファイアウォールの設定

【

コンパイル系パッケージインストール

mail,sar

git

社内

SWFEditor

Imagick

全３４項目

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

PHP

MySQL

Fluentd

Apache:

ZABBIX: agent

Chef:knife

起動スクリプトの配置

起動スクリプトのデーモン化

ホストの設定

【

Apache :

Apache

ZABBIX: agent

Fluentd : td-agent

サーバ構築をスピードよく

約２０分

(42)

イケメン幕末

運命の恋

イケメン夜曲

ロミオと秘密のジュリエット

共通の部分はAMIの中で定義

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

イケメン夜曲用AMI

イケメン幕末用AMI

(43)

設定の違いのみをChefで実行

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

イケメン幕末

運命の恋

イケメン夜曲

ロミオと秘密のジュリエット

GREE

イケメン夜曲用AMI

GooglePlay

イケメン幕末用AMI

AppStore

(44)

NTP

のインストール

ユーザディレクトリの設定

yum: epel

レポジトリ追加

yum: remi

レポジトリ追加

yum: td

レポジトリ追加

yum

のキャッシュをクリア

swap

領域の設定

SELinux

の設定

ユーザの作成

sudo

権限の設定

ファイアウォールの設定

【AWS】CLIのインストール

【AWS】S3コマンドのインストール

コンパイル系パッケージインストール

mail,sar

コマンドなどのインストール

git

のインストール

社内gitレポジトリへのアクセス設定

SWFEditor

のインストール

Imagick

のインストール

PHP

のインストール

PHP

パッケージのインストール

MySQL

クライアントのインストール

Fluentd

クライアントインストール

Apache:

インストール

ZABBIX: agent

インストール

Chef:knife

コマンドの設定

起動スクリプトの配置

起動スクリプトのデーモン化

ホストの設定

【AWS】ディスクパーティションの設定

Apache : virtualhosts

の設定

Apache :

起動

ZABBIX: agent

起動

Fluentd : td-agent:

起動

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

共通２８項目

全３４項目

(45)

NTP

のインストール

ユーザディレクトリの設定

yum: epel

レポジトリ追加

yum: remi

レポジトリ追加

yum: td

レポジトリ追加

yum

のキャッシュをクリア

swap

領域の設定

SELinux

の設定

ユーザの作成

sudo

権限の設定

ファイアウォールの設定

【AWS】CLIのインストール

【AWS】S3コマンドのインストール

コンパイル系パッケージインストール

mail,sar

コマンドなどのインストール

git

のインストール

社内gitレポジトリへのアクセス設定

SWFEditor

のインストール

Imagick

のインストール

PHP

のインストール

PHP

パッケージのインストール

MySQL

クライアントのインストール

Fluentd

クライアントインストール

Apache:

インストール

ZABBIX: agent

インストール

Chef:knife

コマンドの設定

起動スクリプトの配置

起動スクリプトのデーモン化

ホストの設定

【AWS】ディスクパーティションの設定

Apache : virtualhosts

の設定

Apache :

起動

ZABBIX: agent

起動

Fluentd : td-agent:

起動

全３４

項目

サーバ構築の自動化を目指して ∼Chefで設定したこと∼

設定６項目

約５分

+ デプロイ

(46)

Chef

× AWS

(47)

(48)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

各ゾーンに均等にインスタンスを配置

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

(49)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンドインスタンス

Auto Scaling Group

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

(50)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

CloudWatchでサーバ監視

CloudWatch

(51)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

CloudWatchでサーバ監視

CloudWatch

アラートを検知

Alarm

(52)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

CloudWatchでサーバ監視

CloudWatch

Alarm

AMIから起動

AMI

(53)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

CloudWatchでサーバ監視

CloudWatch

Alarm

Chefの実行

AMI

(54)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

CloudWatchでサーバ監視

CloudWatch

Alarm

2台ずつ追加

AMI

EC2

Instance

EC2

Instance

(55)

AutoScale

による運用が順調にスタート

AutoScale

を利用した構成図

(56)

１：サービスの特徴とシステム

∼前半∼

２：AWSを導入に向けて

３：AWSを利用して発生した問題

Agenda

(57)

AWS

を使ってみて

利便性

オンデマンドの価格

機能とサポート

(58)

価格・・・高い問題

(59)

価格・・・やはり高い問題

(60)

リザーブドインスタンスとは

予約金を一括で支払うことで、

期間内の時間あたりの料金が安くなる

インスタンス性能の変更に制約がある

年単位での支払い

∼特徴∼

(61)

リザーブドインスタンスとは

予約金を一括で支払うことで、

期間内の時間あたりの料金が安くなる

インスタンス性能の変更に制約がある

年単位での支払い

∼特徴∼

性能決めつけはリスク

(62)

価格・・・やはり高い問題

(63)

スポットインスタンスとは

需要と共有のバランス

によって

サーバの価格が決まる入札制度

必要なときに短時間だけ利用

約５分の１の価格

∼特徴∼

(64)

Instance Type

Availability zone

それぞれ価格が違う

(65)

スポットインスタンスの特徴

２：サーバ価格より入札額が低いと

１：価格が変動

・サーバが落ちる

(66)

１：価格が変動

(67)

２：サーバ価格より入札額が低いと落ちる

入札額

＜＝

現在のサーバ価格

サーバが落ちる

※自動でサーバが落ちた場合、1時間未満の使用料については課金されない

(68)

２：サーバ価格より入札額が低いと起動しない

入札額

＜＝

現在のサーバ価格

これからサーバを利用する場合

(69)

スポットインスタンスの特徴

２：サーバ価格より入札額が低いと

１：価格が変動

・サーバが落ちる

・

本番での運用はリスク

(70)

スポットインスタンスの問題点

価格高くなる

サーバ落ちる

サーバ起動しない

(71)

価格情報を監視

CYBIRD

が考えたスポットの解決策１

(72)

解決策１：価格情報を監視

価格変動の状況を把握する

(73)

解決策１：価格情報を監視

(74)

価格情報を監視・記録

(75)

スポットとAutoScale

CYBIRD

が考えたスポットの解決策２

(76)

入札価格の変更はConfigの変更だけで可能

解決策２：AutoScaleの利用

AutoScale

の利点

(77)

解決策２：AutoScaleの利用

AutoScalingGroup

・インスタンス起動数

・LaunchConfigの指定

LaunchConfig

・インスタンスタイプ

・スポットインスタンス入札額

(78)

入札価格の変更はConfigの変更だけで可能

解決策２：インスタンス起動数を担保する仕組み

AutoScale

の利点

(79)

AutoScalingGroup

・インスタンス起動数

・LaunchConfigの指定

LaunchConfig

・インスタンスタイプ

・スポットインスタンス入札額

解決策２：インスタンス起動数を担保する仕組み

(80)

解決策２：インスタンス起動数を担保する仕組み

オンデマンド

インスタンス

すぐにサーバ起動

スポットインスタンス

入札価格足りている

入札後サーバ起動

スポットインスタンス

入札価格足りていない

入札待ちが続く

設定したサーバの起動数に足りていない時

(81)

解決策２：インスタンス起動数を担保する仕組み

オンデマンド

インスタンス

すぐにサーバ起動

スポットインスタンス

入札価格足りている

入札後サーバ起動

スポットインスタンス

入札価格足りていない

入札待ちが続く

設定したサーバの起動数に足りていない時

(82)

入札価格の変更はConfigの変更だけで可能

AutoScale

の利点

設定されたインスタンス起動数を担保する仕組み

(83)

解決策２：AutoScaleの利用

AutoScalingGroup

・インスタンス起動数

・LaunchConfigの指定

LaunchConfig

・インスタンスタイプ

・スポットインスタンス入札額

(84)

AutoScalingGroup

の設定

解決策２：AutoScaleの利用

LaunchConfigA

$2.0

入札

m3.2xlarge

AutoScalingGroup

2台起動

LaunchConfigA

(85)

AutoScalingGroup

の設定

解決策２：AutoScaleの利用

LaunchConfigA

の入札額では入札価格が足りない

ずっと入札を待ち続ける

AutoScalingGroup

2台起動

LaunchConfigA

入札待ち

ConfigA

LaunchConfigA

$2.0

入札

m3.2xlarge

の価格 = $3.0

(86)

AutoScalingGroup

の設定

解決策２：AutoScaleの利用

LaunchConfigA

$2.0

入札

m3.2xlarge

LaunchConfigB

$3.0

入札

c3.2xlarge

AutoScalingGroup

2台起動

LaunchConfigB

サーバが起動できるLaunchConfigBに切り替える

新規で入札が入る

入札中止

ConfigA

新規入札

ConfigB

c3.2xlarge

の価格 = $0.8

(87)

AutoScalingGroup

の設定

解決策２：AutoScaleの利用

LaunchConfigA

$2.0

入札

m3.2xlarge

LaunchConfigB

$3.0

入札

c3.2xlarge

AutoScalingGroup

2台起動

LaunchConfigB

サーバが起動できるLaunchConfigBに切り替える

新規で入札が入る

入札中止

ConfigA

新規入札

ConfigB

c3.2xlarge

の価格 = $0.8

無事にサーバ起動

(88)

構成図

CYBIRD

が考えたスポットインスタンス運用

(89)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

(90)

AutoScale

を利用した構成図

ゾーンA

ゾーンB

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

オンデマンド

EC2

Elastic Load

Balancing

スポットインスタンス

AutoScalingGroup

スポット

EC2

スポット

EC2

(91)

オンデマンドインスタンス

スポットインスタンス

価格・・・高い問題

オンデマンドとスポットの利用比率

(92)

オンデマンドインスタンス

スポットインスタンス

オンデマンドとスポットの利用比率

1 ヶ月の使用時間の比率

３∼４割のコスト削減

価格・・・高い問題

(93)

オンデマンドインスタンス

スポットインスタンス

オンデマンドとスポットの利用比率

1 ヶ月の使用時間の比率

３∼４割のコスト削減

価格・・・高い問題

(94)

スポットの利用者が増えた

(95)

2013

年8月からスポットを利用

(96)

価格変動はほとんど無かった

(97)

価格変動が激しい

(98)

利用者が増えたことで起きた問題

(99)

朝と夜にアクセス上昇

月１回の大きなイベント

再掲

(100)

通常時のサーバの例

オンデマンド

WebServer

スポットの利用者が増えた問題

スポット

(101)

イベントに備えサーバ追加

オンデマンドオンデマンド

WebServer

スポット

オンデマンドオンデマンド

スポット

スポットの利用者が増えた問題

(102)

スポットインスタンスの価格上昇

(103)

スポットの利用者が増えた問題

スポットインスタンスの価格上昇

(104)

(105)

現在取り組んでいること

(106)

今出来ていること

現在取り組んでいること

スポットの!

価格状況が把握

AutoScale

の!

容易な設定変更

(107)

やりたいこと

AutoScale

の!

容易な設定変更

現在取り組んでいること

スポットの!

価格状況が把握

自動化

(108)

現在取り組んでいること

１：価格変動のアラートの閾値を設定

２：最適なインスタンス・入札額の選定

(109)

現在取り組んでいること

１：価格変動のアラートの閾値を設定

安定稼働とコスト最適化を目指す

(110)

AWS

のAutoScale

運用コスト削減

様々なツールと組み合わせることで!

ニーズに合ったソリューションを構築

AutoScale

_{スポットインスタンス}

(111)

ここからは!

(112)

運用効率化に向けたAWS導入背景から運用のお話

AWSをさらに活用するための技術的なお話

∼後半∼

∼前半∼

Agenda

(113)

１：アバター合成サーバの負荷対策

２：ログ収集の効率化

３：まとめ

Agenda

(114)

自己紹介

本田恭 (ほんだたかし)

-

2012年新卒入社 (3年目)

-

Twitter @Altsencturely

好きなAWSのサービス

-

S3

(115)

１：アバター合成サーバの負荷対策

２：ログ収集の効率化

３：まとめ

Agenda

(116)

アバター合成サーバの

負荷対策

(117)

恋愛ソーシャルゲームとは

アバターなどを

着せ替えて可愛く

(118)

(119)

ある

画像のレスポンス

ない

画像のレスポンス

画像の存在確認

画像の生成

(ImageMagick)

(120)

(121)

これまでの環境

Image Image Image

NAS

(122)

サーバ間で同じ画像は作成されない

(123)

(124)

Image Image Image

S3

(125)

AWS

の場合1

・S3のマウント先への書き込みに時間がかかる

(126)

AWS

の場合1

・

・サーバ高負荷時にマウントが外れる

(127)

画像A

画像Aリクエスト

画像Aが

ないので作成

AWS

の場合2

Image

Image LoadBarancer

1

2

(128)

画像を余分に作成することの問題点

CPU

ロードアベレージ

サーバを増やしても負荷が減らない

(129)

画像を余分に作成することの問題点

(130)

アバター合成サーバの安定運用

¦¦

合成の回数を減らす

安定運用のために

(131)

サーバ間で画像ファイルを共有

アバター合成サーバの安定運用

¦¦

合成の回数を減らす

安定運用のために

(132)

(133)

マスターレスな分散ファイルシステム

(134)

マスターレスとは

(135)

nodeA

nodeB

nodeC

GlusterFS-Cluster

マスターレスとは

(136)

nodeA

nodeB

nodeC

GlusterFS-Cluster

ノード間で同期

マスターレスとは

単一障害点が存在しない

(137)

1. ルート以外のパーティションでEBSをマウント

2. GlusterFS

のクラスタ構築 (peer probe)

3. ファイルシステムを構築

4. 作成したファイルシステムをマウント

AWS

上でGlusterFSの構築手順

(138)

1. ルート以外のパーティションでEBSをマウント

2. GlusterFS

のクラスタ構築 (peer probe)

3. ファイルシステムを構築

4. 作成したファイルシステムをマウント

(139)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

クラスタ構築

GlusterFS-Cluster

(140)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

追加

peer probe

クラスタ構築

GlusterFS-Cluster

(141)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

追加

peer probe

クラスタのメンバが追加する

クラスタ構築

GlusterFS-Cluster

(142)

GlusterFS

のクラスタのメンバ(nodeAまたはnodeB)が

メンバ追加コマンドを実行

# gluster peer probe nodeC

または

# gluster peer probe 172.31.0.3

(143)

Number of Peers: 2

!

Hostname

:

nodeB

Uuid: xxxxxxxx-xxxx-xxxx

State: Peer in Cluster (Connected)

!

Hostname

:

nodeC

Uuid: xxxxxxxx-xxxx-xxxx

State: Peer in Cluster (Connected)

# gluster peer status

peer probe

の違い

Number of Peers: 2

!

Hostname

:

172.31.0.2 Uuid: xxxxxxxx-xxxx-xxxx

State: Peer in Cluster (Connected)

!

Hostname

:

172.31.0.3 Uuid: xxxxxxxx-xxxx-xxxx

(144)

AWS

だとIPが自動で割り当てられる

AutoScale

時のpeer probe

(145)

サーバを一意に特定できるホスト名の方が管理しやすい

AutoScale

時のpeer probe

(146)

# gluster peer probe

HOSTNAME

サーバを一意に特定できるホスト名の方が管理しやすい

AutoScale

時のpeer probe

(147)

1. GlusterFS

のクラスタの生きているノードが

クラスタに追加

2. IP

アドレスではなくホスト名を使用

GlusterFS

構築の注意点

(148)

(149)

1. GlusterFS

のクラスタの生きているノードの自動判別

2. クラスタ内での自動名前解決

(150)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

追加

peer probe

クラスタの自動構築

GlusterFS-Cluster

(151)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

1. SSH

クラスタの自動構築

GlusterFS-Cluster

(152)

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

1. SSH

2. peer probe

クラスタの自動構築

GlusterFS-Cluster

(153)

GlusterFS

のAutoScale対応

1. GlusterFS

のクラスタの生きているノードの自動判別

2. クラスタ内での自動名前解決

(154)

(155)

Number of Peers: 2

!

Hostname:

nodeB

Uuid: xxxxxxxx-xxxx-xxxx

State: Peer in Cluster

(Connected)

!

Hostname:

nodeC

Uuid: xxxxxxxx-xxxx-xxxx

State: Peer in Cluster

(Connected)

# gluster peer status

(156)

・・・

GlusterFS

のステータスを使う

gluster-peer-status

nod

eB?

nodeC?

ホスト名がわからない

(157)

案1 GlusterFSのステータスを使う

(158)

(159)

・・・

1. 情報取得

(160)

・・・

2. SSH

(161)

・・・

3. 情報取得

(162)

peer probe

・・・

(163)

・・・

AWS API

(164)

不完全なクラスタが構築される

案2 AWS APIを使う

(165)

• Chef Server API

!

• Zabbix API

!

• 内部DNS

その他の案

(166)

(167)

1. GlusterFS

のクラスタの生きているノードの自動判別

2. クラスタ内での自動名前解決

(168)

1. GlusterFS

自動判別

2. クラスタ内での自動名前解決

GlusterFS

のクラスタ内で完結

(169)

(170)

マスターレスなクラスタ構成

ゴシッププロトコル

(171)

$ serf join nodeA

Serf

のクラスタ

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

Serf-Cluster

(172)

Serf

のクラスタ

nodeA

172.31.0.1 nodeB

172.31.0.2 _172.31.0.3

nodeC

自分からクラスタに参加できる

Serf-Cluster

(173)

Serf-Cluster

member-join

nodeA

nodeB

nodeC

ゴシッププロトコルとは

(174)

Serf-Cluster

nodeA

nodeB

nodeC

ゴシッププロトコルとは

(175)

Serf-Cluster

nodeA

nodeB

nodeC

ゴシッププロトコルとは

(176)

Serf-Cluster

nodeA

nodeB

nodeC

ゴシッププロトコルとは

(177)

(178)

クラスタメンバ情報で生存確認

$ serf members

nodeA 172.31.0.1:7946 alive

nodeB 172.31.0.2:7946 alive

nodeC 172.31.0.3:7946 alive

Serfで自動名前解決

(179)

Serfで自動名前解決

member-join

$ serf members

nodeA 172.31.0.1:7946 alive

nodeB 172.31.0.2:7946 alive

nodeC 172.31.0.3:7946 alive

/etc/hosts

(180)

/etc/hosts

member-join

$ serf members

nodeA 172.31.0.1:7946 alive

nodeB 172.31.0.2:7946 alive

nodeC 172.31.0.3:7946 alive

クラスタ内の名前解決の自動化

Serfの便利な点

(181)

(182)

serf-members

172.31.0.1

172.31.0.2

172.31.0.3

172.31.0.4 http://s3-blog.the-new-it.com.s3.amazonaws.com/wp-content/uploads/2014/01/WPandS3Logos.png

Serf

のクラスタをマスターレス

(183)

172.31.0.1

172.31.0.2

172.31.0.3

172.31.0.4 serf-members

serf-members

nodeA 172.31.0.1:7946 alive

nodeB 172.31.0.2:7946 alive

nodeC 172.31.0.3:7946 alive

nodeD 172.31.0.4:7946 failed

Serf

のクラスタをマスターレス

(184)

172.31.0.1

172.31.0.2

172.31.0.3

172.31.0.4 $ serf join nodeA

(185)

172.31.0.1

172.31.0.2

172.31.0.3

172.31.0.4 $ serf join nodeA

Serf

のクラスタをマスターレス

(186)

S3

の耐障害性

!

最大 99.999999999% の耐久性と 99.99% の可用性

安定してどこからでも使える

S3

を使う理由

(187)

(188)

クラスタの名前解決

クラスタの追加/削除時に/etc/hostsが

修正されメンバ間は名前解決可能

(189)

1. GlusterFS

のクラスタの生きているノードの自動判別

2. クラスタ内での自動名前解決

(190)

(191)

Serf-Cluster

nodeA

nodeB

nodeC

GlusterFS-Cluster

(192)

nodeA

nodeB

nodeC

serf-members

(193)

Serf-Cluster

serf-members

nodeA 172.31.0.1:7946 alive

nodeB 172.31.0.2:7946 alive

nodeA

nodeB

nodeC

(194)

Serf-Cluster

member-join

(195)

nodeA

nodeB

nodeC

GlusterFS-Cluster

(196)

nodeA

nodeB

nodeC

1. SSH

2. peer probe

GlusterFS-Cluster

(197)

nodeA

nodeB

nodeC

serf-members

(198)

(199)

(200)

AutoScale

に対応

GlusterFS

の導入

Web

サーバと同じ様にスケールアウト

ファイル共有により無駄なアバター合成

削減し負荷の軽減

[当日発表資料]AWS_Summit_CYBIRD_fix.key

ゲーム事業本部 恋愛ゲームチーム 藤原 涼!

ゲームインフラチーム 本田 恭!

AutoScale ×

ゲーム

運用効率化に向けたAWS導入背景から運用のお話

AWSをさらに活用するための技術的なお話

∼後半∼

∼前半∼

Agenda

１：サービスの特徴とシステム

２：AWSの導入に向けて

３：AWSを利用して発生した問題

Agenda

自己紹介

藤原 涼 (ふじわらりょう)

-

2012年新卒入社 (3年目)

-

Twitter @megadreams14

AWSを使い始めた日

-

２０１３年６月１７日（月）

女性向け

「恋愛ソーシャルゲーム」

における導入事例

恋愛ソーシャルゲームとは

華やかで

甘いストーリー

が楽しめる

アバターなどを

着せ替えて可愛く

コーディネイトできる

恋愛ソーシャルゲームとは

http://ikemen.cybird.ne.jp/of/play.html

恋愛ソーシャルゲームとは

現在提供している恋愛ソーシャルゲーム

イケメン大奥

恋の園

イケメン恋戦

平清盛

100

日間のプリンセス

もうひとつのイケメン王宮

イケメン王宮

真夜中のシンデレラ

新章イケメン大奥

禁じられた恋

イケメン幕末

運命の恋

ラブセン

∼Ｖ６とヒミツの恋∼

美男宮殿

月下灰姑娘

美男大奧

江戶奇緣

イケメン夜曲

ロミオと秘密のジュリエット

한밤중의 신데렐라

現在提供している恋愛ソーシャルゲーム

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Mobage

Ameba

AppStore

GooglePlay

GREE

Ameba

AppStore

GooglePlay

Ameba

ゲーム事業本部恋愛ゲームチーム藤原涼!

ゲームインフラチーム本田恭!

藤原涼 (ふじわらりょう)