AutoScale ゲーム～運用効率化への取り組み～ - …Title [当日発表資料]AWS_Summit_CYBIRD_fix.key Created Date 7/22/2014 7:07:32 AM

Copyright 2014 CYBIRD Co., Ltd. All Rights Reserved.

ゲーム事業本部恋愛ゲームチーム　藤原涼!ゲームインフラチーム　本田恭!

2014年07月18日

AutoScale × ゲーム

～運用効率化への取り組み～


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

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

～後半～

～前半～

Agenda


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

２：AWSの導入に向けて

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

Agenda

～前半～


自己紹介

藤原涼 (ふじわらりょう)- 2012年新卒入社 (3年目)- Twitter @megadreams14

AWSを使い始めた日- ２０１３年６月１７日（月）


女性向け

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

における導入事例


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



華やかで

甘いストーリー

が楽しめる

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



アバターなどを

着せ替えて可愛く

コーディネイトできる






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

私達が皆様にお約束すること

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


リリース一覧


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

イケメン大奥恋の園

イケメン恋戦平清盛

100日間のプリンセスもうひとつのイケメン王宮

イケメン王宮真夜中のシンデレラ

新章イケメン大奥禁じられた恋

イケメン幕末運命の恋

ラブセン～Ｖ６とヒミツの恋～

美男宮殿月下灰姑娘

美男大奧江戶奇緣

イケメン夜曲ロミオと秘密のジュリエット

한밤중의 신데렐라



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 GooglePlayAmeba

AppStore GooglePlayAppStore GooglePlay AppStore GooglePlay

GREE Mobage Ameba

AppStore GooglePlay

dゲーム



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



GREE Mobage Ameba

AppStore GooglePlay

dゲーム

全４０サイト


特徴


朝と夜にアクセス上昇

月１回の大きなイベント

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




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

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

1日のアクセス数の変化

朝夜

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




通常の約５倍のアクセスイベント開始時のアクセス数の変化




アバターの付与

華やかにドレスアップ♪

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




アバターの付与

華やかにドレスアップ♪

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

アバター合成でサーバ負荷


システム要件


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

Web LoadBarancer

Webサーバアバター合成サーバ

Server Server Server

Image LoadBarancer




～前半～

２：AWSの導入に向けて


Agenda


AWSを使うまでの苦労


イベント前のサーバ追加

手動でサーバ追加

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



コンテンツ数が多い

イベント前のサーバ追加LB LBLB LBLB LBLB LBLB LBLB LBLB LB



事前追加や障害対応

アラートメール

状況確認

サーバ追加

手動でサーバ追加



３０分～２時間程度サーバの追加に時間がかかる

サーバ追加ステータスが変わらない



機会損失運用コスト

運用上の課題



AutoScale

URL


AutoScaleとは

サーバの負荷に合わせて

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

サーバ負荷スケジュール


AutoScaleを利用するには


サーバ構築の自動化

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



増えるだけでなく減ることも考慮

ログファイル

セッションデータ

画像ファイル



サーバ構築の自動化

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



AMI

画像ファイル Apacheの設定

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

AMIで実現可能・・・だがサーバ構築の自動化



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



GREE Mobage Ameba

AppStore GooglePlay

dゲーム

設定が異なる複数のAMIが必要


http://www.techtonet.com/jenkins-continuous-integration/


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

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

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

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

Chef導入理由


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で設定したこと～



全３４項目

サーバ構築の自動化を目指して　～Chefで設定したこと～PHPのインストール PHPパッケージのインストール MySQLクライアントのインストール Fluentdクライアントインストール Apache:インストール ZABBIX: agentインストール Chef:knifeコマンドの設定起動スクリプトの配置起動スクリプトのデーモン化ホストの設定【AWS】ディスクパーティションの設定 Apache : virtualhostsの設定 Apache : 起動 ZABBIX: agent起動 Fluentd : td-agent: 起動

約２０分


NTPユーザディレクトリの設定yum: yum: remiyum: tdyumswapSELinuxユーザの作成sudoファイアウォールの設定【【コンパイル系パッケージインストールmail,sargit社内SWFEditorImagick

全３４項目

サーバ構築の自動化を目指して　～Chefで設定したこと～PHPPHPMySQLFluentdApache:ZABBIX: agentChef:knife起動スクリプトの配置起動スクリプトのデーモン化ホストの設定【Apache : Apache ZABBIX: agentFluentd : td-agent

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

約２０分


イケメン幕末運命の恋


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


イケメン夜曲用AMI イケメン幕末用AMI


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

サーバ構築の自動化を目指して　～Chefで設定したこと～イケメン幕末運命の恋


GREE

イケメン夜曲用AMI

GooglePlay

イケメン幕末用AMI

AppStoreMobage GooglePlayAppStoreAmeba





共通２８項目

全３４項目




全３４項目


設定６項目

約５分

+　デプロイ


Chef　×　AWS

サーバ構築の自動化を目指して　～Chefの実行～


AutoScale構成図


AutoScaleを利用した構成図

ゾーンA ゾーンB

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

オンデマンド EC2


Elastic Load Balancing




オンデマンドインスタンス Auto Scaling Groupオンデマンド

EC2













CloudWatchでサーバ監視CloudWatch










アラートを検知Alarm










Alarm

AMIから起動

AMI










Alarm

Chefの実行

AMI










Alarm

2台ずつ追加

AMI

EC2 Instance

EC2 Instance


AutoScaleによる運用が順調にスタートAutoScaleを利用した構成図

CPUロードアベレージ



～前半～

２：AWSを導入に向けて


Agenda


AWSを使ってみて

利便性

オンデマンドの価格

機能とサポート


価格・・・高い問題≈ç


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

リザーブドインスタンス検討


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

予約金を一括で支払うことで、期間内の時間あたりの料金が安くなる

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

年単位での支払い

～特徴～


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

予約金を一括で支払うことで、期間内の時間あたりの料金が安くなる

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

年単位での支払い

～特徴～性能決めつけはリスク


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

スポットインスタンス検討


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

需要と共有のバランスによって

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

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

約５分の１の価格～特徴～


Instance Type

Availability zone

それぞれ価格が違う

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


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

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

１：価格が変動

・サーバが落ちる

・サーバが起動しない



需要と供給のバランスで価格が変動


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

入札額現在のサーバ価格＜＝

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

既にサーバを利用中の場合


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

入札額現在のサーバ価格＜＝

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

サーバが起動しない


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

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


・サーバが落ちる

・

本番での運用はリスク


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

価格高くなる

サーバ落ちるサーバ起動しない

本番運用での課題


価格情報を監視

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

≈ç


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

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

入札価格の決定



http://www.zabbix.com/jp/img/logo/zabbix_logo_500x131.png

http://www.zabbix.com/jp/img/logo/zabbix_logo_500x131.png


価格情報を監視・記録



スポットとAutoScale

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

≈ç


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

解決策２：AutoScaleの利用

AutoScaleの利点

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



AutoScalingGroup・インスタンス起動数・LaunchConfigの指定

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



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

AutoScaleの利点








オンデマンドインスタンスすぐにサーバ起動

スポットインスタンス入札価格足りている入札後サーバ起動

スポットインスタンス入札価格足りていない入札待ちが続く

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



オンデマンドインスタンスすぐにサーバ起動

スポットインスタンス入札価格足りている入札後サーバ起動

スポットインスタンス入札価格足りていない入札待ちが続く

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



AutoScaleの利点








AutoScalingGroupの設定解決策２：AutoScaleの利用

LaunchConfigA

$2.0入札m3.2xlarge

AutoScalingGroup

2台起動LaunchConfigA



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

ずっと入札を待ち続ける

AutoScalingGroup

2台起動LaunchConfigA

入札待ちConfigA

LaunchConfigA

$2.0入札m3.2xlarge

m3.2xlargeの価格 = $3.0



LaunchConfigA

$2.0入札m3.2xlargeLaunchConfigB

$3.0入札c3.2xlarge

AutoScalingGroup

2台起動LaunchConfigB

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

新規で入札が入る入札中止ConfigA

新規入札ConfigB

c3.2xlargeの価格 = $0.8



LaunchConfigA

$2.0入札m3.2xlargeLaunchConfigB

$3.0入札c3.2xlarge

AutoScalingGroup

2台起動LaunchConfigB

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

新規で入札が入る入札中止ConfigA

新規入札ConfigB

c3.2xlargeの価格 = $0.8無事にサーバ起動


構成図

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

≈ç

















スポットインスタンス AutoScalingGroup

スポット EC2

スポット EC2


オンデマンドインスタンススポットインスタンス

価格・・・高い問題

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

1ヶ月の使用時間の比率





３～４割のコスト削減






３～４割のコスト削減



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


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

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


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



価格変動が激しいスポットの利用者が増えた問題


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





再掲



通常時のサーバの例

オンデマンド

WebServer


スポット


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

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

WebServer

スポットスポット

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

スポットスポット



スポットインスタンスの価格上昇スポットの利用者が増えた問題



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

自分たちで価格吊り上げる


現在取り組んでいること



スポットインスタンスConfig切り替え自動化


今出来ていること


スポットの!価格状況が把握

AutoScaleの!容易な設定変更


やりたいこと

AutoScaleの!容易な設定変更


スポットの!価格状況が把握

自動化



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

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

３：AutoScalingGroupに適用



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

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

３：


AWSのAutoScale

運用コスト削減

様々なツールと組み合わせることで!ニーズに合ったソリューションを構築

AutoScale スポットインスタンス


ここからは!より技術的なお話


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

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

～後半～

～前半～

Agenda


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

２：ログ収集の効率化

３：まとめ

Agenda

～後半～


自己紹介

本田恭 (ほんだたかし)- 2012年新卒入社 (3年目)- Twitter @Altsencturely

好きなAWSのサービス- S3




３：まとめ

Agenda

～後半～


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



アバターなどを着せ替えて可愛くコーディネイトできる


アバター画像の基本的な仕組み


ある

画像のレスポンス

ない

画像のレスポンス

画像の存在確認画像の存在確認

画像の生成 (ImageMagick)


これまでの環境



Image Image Image

NAS


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



AWSのAutoScale運用を行う場合


Image Image Image

S3

AWSの場合1


AWSの場合1

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

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


AWSの場合1

・

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

S3のマウントはNASの様にいかない


画像A

画像Aリクエスト

画像Aがないので作成

AWSの場合2

Image Image

Image LoadBarancer

1 2


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

CPUロードアベレージ

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


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

安定運用できない


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

合成の回数を減らす

安定運用のために


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

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

合成の回数を減らす

安定運用のために


http://shoreditchworks.com/sw/wp-content/uploads/2013/10/orange-ant-glusterfs.png

http://shoreditchworks.com/sw/wp-content/uploads/2013/10/orange-ant-glusterfs.png


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

GlusterFSとは


マスターレスとは

特定のサーバに依存しないクラスタ構成


nodeA

nodeB nodeCGlusterFS-Cluster


ノード間で同期


nodeA

nodeB nodeCGlusterFS-Cluster

ノード間で同期


単一障害点が存在しない


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

2. GlusterFSのクラスタ構築 (peer probe)

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

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

AWS上でGlusterFSの構築手順


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

2. GlusterFSのクラスタ構築 (peer probe)

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

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

AWS上でGlusterFSの構築手順


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

クラスタ構築

GlusterFS-Cluster


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

追加 peer probe

クラスタ構築

GlusterFS-Cluster


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

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

クラスタ構築

GlusterFS-Cluster


GlusterFSのクラスタのメンバ(nodeAまたはnodeB)がメンバ追加コマンドを実行

# gluster peer probe nodeCまたは

# gluster peer probe 172.31.0.3

peer probeの違い


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の違い


Hostname: 172.31.0.2 Uuid: xxxxxxxx-xxxx-xxxx State: Peer in Cluster (Connected) !

Hostname: 172.31.0.3 Uuid: xxxxxxxx-xxxx-xxxx State: Peer in Cluster (Connected)


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

AutoScale時のpeer probe


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




# gluster peer probe HOSTNAME

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




1. GlusterFSのクラスタの生きているノードが　　　クラスタに追加

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

GlusterFS構築の注意点


AutoScaleに対応させるためには


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

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

GlusterFSのAutoScale対応


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

追加 peer probe

クラスタの自動構築

GlusterFS-Cluster


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

1. SSH


GlusterFS-Cluster


nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

1. SSH

2. peer probe


GlusterFS-Cluster






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



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

GlusterFSのステータスを使う


・・・

GlusterFSのステータスを使う

gluster-peer-status

nodeB?

nodeC?

ホスト名がわからない


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

名前解決されていないため構築できない


案2 AWS APIを使う


・・・

1. 情報取得

AWS API

http://cdn.blog.celingest.com/wp-content/uploads/2013/09/aws-s3-512x215.png

http://cdn.blog.celingest.com/wp-content/uploads/2013/09/aws-s3-512x215.png


・・・

2. SSH

AWS API


・・・

3. 情報取得

AWS API


peer probe

・・・

AWS API


・・・

AWS API

名前解決出来ていない


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

案2 AWS APIを使う


• Chef Server API

!

• Zabbix API

!

• 内部DNS

その他の案

http://recipe.kc-cloud.jp/wp-content/uploads/2013/04/20130405_02_01.gif

http://recipe.kc-cloud.jp/wp-content/uploads/2013/04/20130405_02_01.gif


単一障害点を作ってしまう






1. GlusterFS自動判別


GlusterFS

GlusterFSのクラスタ内で完結


S E R Fhttp://pocketstudio.jp.s3.amazonaws.com/log3/wp-content/uploads/2013/11/serf-logo.png

http://pocketstudio.jp.s3.amazonaws.com/log3/wp-content/uploads/2013/11/serf-logo.png


マスターレスなクラスタ構成ゴシッププロトコル

Serfとは


$ serf join nodeA

Serfのクラスタ

nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

Serf-Cluster


Serfのクラスタ

nodeA 172.31.0.1

nodeB 172.31.0.2

nodeC 172.31.0.3

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

Serf-Cluster

$ serf join nodeA


Serf-Cluster

member-join

nodeA nodeB nodeC

ゴシッププロトコルとは


Serf-Cluster

nodeA nodeB nodeC


member-join


Serf-Cluster

nodeA nodeB nodeC



Serf-Cluster

nodeA nodeB nodeC


伝播して同じ状態に


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


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

$ serf members nodeA 172.31.0.1:7946 alive nodeB 172.31.0.2:7946 alive nodeC 172.31.0.3:7946 alive

Serfで自動名前解決


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


/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の便利な点


Serfのクラスタをマスターレスに構築


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のクラスタをマスターレス

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


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



172.31.0.1 172.31.0.2

172.31.0.3 172.31.0.4

$ serf join nodeA



172.31.0.1 172.31.0.2

172.31.0.3 172.31.0.4

$ serf join nodeA


マスターレスにクラスタ構築


S3の耐障害性 !

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

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

S3を使う理由


Serf　×　S3


クラスタの名前解決クラスタの追加/削除時に/etc/hostsが修正されメンバ間は名前解決可能






GlusterFSのAutoScale対応の仕組み


Serf-Cluster

nodeA nodeB nodeC

GlusterFS-Cluster


nodeA nodeB nodeC

serf-members

Serf-Cluster


Serf-Cluster

serf-members nodeA 172.31.0.1:7946 alive nodeB 172.31.0.2:7946 alive

nodeA nodeB nodeC$ serf join nodeB


Serf-Cluster

member-joinmember-joinmember-join

nodeA nodeB nodeC


nodeA nodeB nodeC

GlusterFS-Cluster

Serf-Cluster


nodeA nodeB nodeC

1. SSH

2. peer probe

GlusterFS-Cluster

Serf-Cluster


nodeA nodeB nodeC

serf-members

GlusterFS-Cluster


GlusterFSのマスターレスな構築


GlusterFS × Serf × S3

http://www.gluster.org/images/antmascot.png

http://www.gluster.org/images/antmascot.png


AutoScaleに対応

GlusterFSの導入

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

ファイル共有により無駄なアバター合成削減し負荷の軽減




３：まとめ

Agenda

～後半～


ログ収集の効率化


http://excalemedia.s3.amazonaws.com/wp-content/uploads/2014/02/fluentd2.png



なぜFluentdを使うの?

AutoScaleだとサーバが削除された時ログも消える


Fluentdの運用を出来るだけ楽に !

中継サーバのリソースを十分に使う

Fluentdの要件


分析用VPCタイトル毎のVPC

Server

Redshift

Elasticsearch

Fluentd Fluentd Fluentd Fluentd



Redshift

Elasticsearch



Fluentd 中継

Fluentd 中継

Server Server Server Server


Redshift

Elasticsearch

分析用VPCタイトル毎の

Fluentd 中継



Fluentd 中継


https://blog.linode.com/wp-content/uploads/2014/01/docker.png



Redshift

Elasticsearch

Fluentd 中継


Fluentd 中継




分析用VPCタイトル毎の

Fluentd 中継

Fluentd 中継

Fluentd 中継



Fluentd 中継


Redshift

Elasticsearch

Fluentd 中継


Fluentd 中継

Fluentd 中継

Fluentd 中継




Fluentd × Docker × Jenkins


運用効率化

リソースの活用

JenkinsでFluentdの増減を管理

中継サーバのリソースを無駄なく利用

One more thing…


http://tctechcrunch2011.files.wordpress.com/2010/07/github-logo.png

Chef Serverspec

Docker

JMeter

JMeter負荷

Vagrant

JMeter

http://tctechcrunch2011.files.wordpress.com/2010/07/github-logo.png


まとめ


AWSの価値とは


AWSの機能を使えばやりたいことが簡単にすぐに導入できる

試験的・部分的な利用から本番運用まで

幅広い利用をサポート


APIを使って自分たちの体制に合わせて最適化可能

海外等の普段手が回らない部分までカバー

運用コスト削減


すべての開発者が、するキモチのような心やすまる運用を。

AWSが私達にくれたもの


Documents

AutoScale ゲーム ～運用効率化への取り組み～ - …Title [当日発表資料]AWS_Summit_CYBIRD_fix.key Created Date 7/22/2014 7:07:32 AM

AutoScale ゲーム～運用効率化への取り組み～ - …Title [当日発表資料]AWS_Summit_CYBIRD_fix.key Created Date 7/22/2014 7:07:32 AM