Submit Search
Upload
負荷分散勉強会
•
43 likes
•
8,108 views
Yuji Otani
Follow
2012年12月20日に開催した勉強会の資料です。基礎的な内容を中心に負荷対策について紹介しています。
Read less
Read more
Technology
Report
Share
Report
Share
1 of 163
Recommended
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#
Yoshifumi Kawai
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
gRPC入門
gRPC入門
Kenjiro Kubota
PHP AST 徹底解説
PHP AST 徹底解説
do_aki
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
ScrapyとPhantomJSを用いたスクレイピングDSL
ScrapyとPhantomJSを用いたスクレイピングDSL
Masayuki Isobe
Recommended
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#
Yoshifumi Kawai
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
gRPC入門
gRPC入門
Kenjiro Kubota
PHP AST 徹底解説
PHP AST 徹底解説
do_aki
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
ScrapyとPhantomJSを用いたスクレイピングDSL
ScrapyとPhantomJSを用いたスクレイピングDSL
Masayuki Isobe
async/await のしくみ
async/await のしくみ
信之 岩永
【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things
UnityTechnologiesJapan002
クラウド環境下におけるAPIリトライ設計
クラウド環境下におけるAPIリトライ設計
Kouji YAMADA
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
Spring Day 2016 - Web API アクセス制御の最適解
Spring Day 2016 - Web API アクセス制御の最適解
都元ダイスケ Miyamoto
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Takahiko Ito
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
Koichiro Matsuoka
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
例外設計における大罪
例外設計における大罪
Takuto Wada
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
Yasuhiro Mawarimichi
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
php-src の歩き方
php-src の歩き方
do_aki
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Jenkinsとamazon ecsで コンテナCI
Jenkinsとamazon ecsで コンテナCI
shigeyuki azuchi
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
Joni
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
Atsushi KOMIYA
NoSQL勉強会
NoSQL勉強会
Yuji Otani
Fuel php活用事例
Fuel php活用事例
Toshiyuki Maeda
More Related Content
What's hot
async/await のしくみ
async/await のしくみ
信之 岩永
【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things
UnityTechnologiesJapan002
クラウド環境下におけるAPIリトライ設計
クラウド環境下におけるAPIリトライ設計
Kouji YAMADA
徳丸本ができるまで
徳丸本ができるまで
Hiroshi Tokumaru
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
Spring Day 2016 - Web API アクセス制御の最適解
Spring Day 2016 - Web API アクセス制御の最適解
都元ダイスケ Miyamoto
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Takahiko Ito
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
Koichiro Matsuoka
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
例外設計における大罪
例外設計における大罪
Takuto Wada
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
Yasuhiro Mawarimichi
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
php-src の歩き方
php-src の歩き方
do_aki
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Jenkinsとamazon ecsで コンテナCI
Jenkinsとamazon ecsで コンテナCI
shigeyuki azuchi
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
Joni
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
Atsushi KOMIYA
What's hot
(20)
async/await のしくみ
async/await のしくみ
【Unite Tokyo 2019】Understanding C# Struct All Things
【Unite Tokyo 2019】Understanding C# Struct All Things
クラウド環境下におけるAPIリトライ設計
クラウド環境下におけるAPIリトライ設計
徳丸本ができるまで
徳丸本ができるまで
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
Spring Day 2016 - Web API アクセス制御の最適解
Spring Day 2016 - Web API アクセス制御の最適解
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
例外設計における大罪
例外設計における大罪
WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
php-src の歩き方
php-src の歩き方
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Jenkinsとamazon ecsで コンテナCI
Jenkinsとamazon ecsで コンテナCI
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
ASP.NET Core の パフォーマンスを支える I/O Pipeline と Channel
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
Similar to 負荷分散勉強会
NoSQL勉強会
NoSQL勉強会
Yuji Otani
Fuel php活用事例
Fuel php活用事例
Toshiyuki Maeda
アドテク案件入門講座
アドテク案件入門講座
伊藤 孝
CGS_J_20.3.12
CGS_J_20.3.12
Hemant_Kumar_Setya
CGS_J_19.3.12
CGS_J_19.3.12
Hemant_Kumar_Setya
CGS_J_1.4.12
CGS_J_1.4.12
Hemant_Kumar_Setya
CGS_J_7.4.12
CGS_J_7.4.12
Hemant_Kumar_Setya
雲の上の継続的デリバリー
雲の上の継続的デリバリー
Salesforce Developers Japan
Midworks
Midworks
ssuser163445
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
Ryoma Hosokawa
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
Yusuke Suzuki
アド部 アスタリスク資料
アド部 アスタリスク資料
松本 勇
HSM_J_16.3.12
HSM_J_16.3.12
Hemant_Kumar_Setya
【Webinar-Slide】DataBridgeとは
【Webinar-Slide】DataBridgeとは
Talend KK
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
Amazon Web Services Japan
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
Cybozucommunity
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
Amazon Web Services Japan
HSM_J_20.3.12
HSM_J_20.3.12
Hemant_Kumar_Setya
HSM_J_19.3.12
HSM_J_19.3.12
Hemant_Kumar_Setya
AWSでの金融系システム構築・運用勘所
AWSでの金融系システム構築・運用勘所
ナレッジコミュニケーション
Similar to 負荷分散勉強会
(20)
NoSQL勉強会
NoSQL勉強会
Fuel php活用事例
Fuel php活用事例
アドテク案件入門講座
アドテク案件入門講座
CGS_J_20.3.12
CGS_J_20.3.12
CGS_J_19.3.12
CGS_J_19.3.12
CGS_J_1.4.12
CGS_J_1.4.12
CGS_J_7.4.12
CGS_J_7.4.12
雲の上の継続的デリバリー
雲の上の継続的デリバリー
Midworks
Midworks
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
アド部 アスタリスク資料
アド部 アスタリスク資料
HSM_J_16.3.12
HSM_J_16.3.12
【Webinar-Slide】DataBridgeとは
【Webinar-Slide】DataBridgeとは
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
HSM_J_20.3.12
HSM_J_20.3.12
HSM_J_19.3.12
HSM_J_19.3.12
AWSでの金融系システム構築・運用勘所
AWSでの金融系システム構築・運用勘所
More from Yuji Otani
SKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジー
Yuji Otani
Hack/HHVMの最新事情とメイン言語に採用した理由
Hack/HHVMの最新事情とメイン言語に採用した理由
Yuji Otani
「技術のインテリジェンスを創る」をどうやって実現するか
「技術のインテリジェンスを創る」をどうやって実現するか
Yuji Otani
Why choose Hack/HHVM over PHP7
Why choose Hack/HHVM over PHP7
Yuji Otani
PHP7ではなくHack/HHVMを選ぶ理由
PHP7ではなくHack/HHVMを選ぶ理由
Yuji Otani
MariaDB+GaleraClusterの運用事例(MySQL勉強会2016-01-28)
MariaDB+GaleraClusterの運用事例(MySQL勉強会2016-01-28)
Yuji Otani
PHP7がリリースされたいま、 改めてHackについて考える。
PHP7がリリースされたいま、 改めてHackについて考える。
Yuji Otani
FuelPHP × HHVM サービス開発事例
FuelPHP × HHVM サービス開発事例
Yuji Otani
Hack言語に賭けたチームの話
Hack言語に賭けたチームの話
Yuji Otani
スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方
Yuji Otani
Go言語のフレームワークRevelの紹介とサービスにおける活用事例
Go言語のフレームワークRevelの紹介とサービスにおける活用事例
Yuji Otani
Hack+FuelPHPによるWebサービス開発
Hack+FuelPHPによるWebサービス開発
Yuji Otani
【初心者向け】Go言語勉強会資料
【初心者向け】Go言語勉強会資料
Yuji Otani
NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )
Yuji Otani
Phalcon勉強会資料
Phalcon勉強会資料
Yuji Otani
RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)
RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)
Yuji Otani
Redis勉強会資料(2015/06 update)
Redis勉強会資料(2015/06 update)
Yuji Otani
【基礎編】社内向けMySQL勉強会
【基礎編】社内向けMySQL勉強会
Yuji Otani
Nginx勉強会
Nginx勉強会
Yuji Otani
PHP基礎勉強会
PHP基礎勉強会
Yuji Otani
More from Yuji Otani
(20)
SKYDISCのIoTを支えるテクノロジー
SKYDISCのIoTを支えるテクノロジー
Hack/HHVMの最新事情とメイン言語に採用した理由
Hack/HHVMの最新事情とメイン言語に採用した理由
「技術のインテリジェンスを創る」をどうやって実現するか
「技術のインテリジェンスを創る」をどうやって実現するか
Why choose Hack/HHVM over PHP7
Why choose Hack/HHVM over PHP7
PHP7ではなくHack/HHVMを選ぶ理由
PHP7ではなくHack/HHVMを選ぶ理由
MariaDB+GaleraClusterの運用事例(MySQL勉強会2016-01-28)
MariaDB+GaleraClusterの運用事例(MySQL勉強会2016-01-28)
PHP7がリリースされたいま、 改めてHackについて考える。
PHP7がリリースされたいま、 改めてHackについて考える。
FuelPHP × HHVM サービス開発事例
FuelPHP × HHVM サービス開発事例
Hack言語に賭けたチームの話
Hack言語に賭けたチームの話
スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方
Go言語のフレームワークRevelの紹介とサービスにおける活用事例
Go言語のフレームワークRevelの紹介とサービスにおける活用事例
Hack+FuelPHPによるWebサービス開発
Hack+FuelPHPによるWebサービス開発
【初心者向け】Go言語勉強会資料
【初心者向け】Go言語勉強会資料
NoSQL勉強会資料(2015/03/12@ヒカラボ )
NoSQL勉強会資料(2015/03/12@ヒカラボ )
Phalcon勉強会資料
Phalcon勉強会資料
RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)
RDBとNoSQLの上手な付き合い方(勉強会@LIG 2013/11/11)
Redis勉強会資料(2015/06 update)
Redis勉強会資料(2015/06 update)
【基礎編】社内向けMySQL勉強会
【基礎編】社内向けMySQL勉強会
Nginx勉強会
Nginx勉強会
PHP基礎勉強会
PHP基礎勉強会
Recently uploaded
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Recently uploaded
(11)
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
負荷分散勉強会
1.
負荷分散勉強会
〜Webシステムの運用で試行錯誤したこと〜 株式会社シーエー・アドバンス 大谷 祐司 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
2.
自己紹介
大谷 祐司 (株式会社シーエー・アドバンス 技術責任者) 出身:山口県下関市 年齢:32歳 趣味:プログラミング、技術系の勉強、車 はまっているもの:自転車 2009年:サイバーエージェント入社。 2011年:シーエー・アドバンスに出向。 その前:人材会社で仕事の紹介をしていました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
3.
シーエー・アドバンスの紹介 Copyright © 2012
CAADvance, Inc. All Rights Reserved.
4.
シーエー・アドバンスってどんな会社?
2008年に、サイバーエージェントの子会社として設 立。 インターネットメディアや広告の運用に関連する事業 を中心に行っている会社です。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
5.
シーエー・アドバンスってどんな会社?
従業員数は約300人で、東京と沖縄に事業所がありま す。 (東京約50名、沖縄約250名) 私も毎月沖縄出張しています。 (オフィスとホテルの往復ですが・・・) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
6.
勉強会で対象にするシステム Copyright © 2012
CAADvance, Inc. All Rights Reserved.
7.
■ 勉強会で対象にするシステム
リスティング広告運用プラットフォーム Search Suite(サーチスイート) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
8.
■ Search Suiteについて
概要: ・リスティング広告の運用をサポート。 ・いわゆる社内システム。 ・約500名のユーザが存在。 ・30以上のサブシステムが乗っています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
9.
■ Search Suiteについて
特徴: ・扱うデータが大きい。 ・データ集計などで負荷の高い処理が多い。 ・土日、祝日はほとんどアクセスが無い。 私はサイバーエージェントに入社してからずっと、 Search Suiteの開発・運用に関わってきました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
10.
■ リスティング広告とは
・検索エンジンの結果画面に表示される広告。 ・Yahoo!, Googleが大きなシェアを持っています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
11.
■ リスティング広告とは
・キーワード毎に入札を行い、表示順番が決まる。 ・大型のクライアントは数百万キーワードに入札します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
12.
■ リスティング広告とは
赤枠の部分が広告です。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
13.
■ Search Suite
開発の経緯 私が入社当初の2009年、社内ではリスティング広告の運用に とても多くの時間がかかっていました。 Excel上のコピー&ペーストを繰り返したり、Yahoo!やGoogle の用意する管理画面から1つづつレポートデータをダウンロー ドして並び替えたり。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
14.
■ Search Suite
開発の経緯 リスティング広告の運用をシステムで効率化して、オペレー ションのスピードと正確性でサイバーエージェントの競争力 を高めていく。 これを実現すべく開発されたのが「Search Suite」です。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
15.
本日は「レポート機能」で行った
負荷対策をメインでご紹介します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
16.
■ レポート機能の概要
・クライアントに提出するレポートを作成する。 ・システム負荷が高くて運用が大変。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
17.
■ レポート機能の概要
Yahoo!やGoogleからAPIで広告の実績データを取得。 ⬇ Search SuiteのDBに蓄積。 ⬇ 集計してExcelファイルで出力。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
18.
■ レポートデータ取り込み/出力の概要図
Intranet Internet Batch Web DB Copyright © 2012 CAADvance, Inc. All Rights Reserved.
19.
■ リスティング広告のレポートデータ
リスティング広告の階層構造 クライアント 人材会社XXXX 保険代理店XXXX アカウント アルバイト 採用 システム アルバイト 採用 システム 火災保険 生命保険 保険見 火災保険 生命保険 保険見 キーワード エンジニア 転職 採用試験 内定 人材派遣 人材紹介 派 エンジニア 転職 採用試験 内定 人材派遣 人材紹介 派 直し 地震保険 自動車保険 保険見積もり 保険代理店 直し 地震保険 自動車保険 保険見積もり 保険代理店 遣登録 ヘッドハンティン 遣登録 ヘッドハンティン 新築アパート 水害保険 安 新築アパート 水害保険 安 グ 派遣会社 人材紹介会社 グ 派遣会社 人材紹介会社 い保険 保険更新 保険見積 い保険 保険更新 保険見積 年収 退職交渉 内定承諾 採 年収 退職交渉 内定承諾 採 もり 安い自動車保険 もり 安い自動車保険 用試験 etc・・・ 用試験 etc・・・ etc・・・ etc・・・ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
20.
■ レポートデータの量
アカウント単位のレポート 約2,500レコード/日(約100万/年) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
21.
■ レポートデータの量
キーワード単位のレポート 約160万レコード/日(約6億/年) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
22.
どのようにして、ユーザーが見たいレポートを早く
正確に出力できるようにするか。 本日は、これまでに行ってきた処理の効率化や負荷 分散の対策をお話ししたいと思います。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
23.
Search Suite システム構成 Copyright
© 2012 CAADvance, Inc. All Rights Reserved.
24.
■ Search Suite
システム構成 LAMP環境で構築しています。 ○ OS :Linux(CentOS 5) ○ 言語 :PHP5.3 ○ Webサーバ:Apache2.2 ○ DB :MySQL5.5 ○ キャッシュ :Memcached ○ フレームワーク :未使用 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
25.
■ 保持しているデータのサイズ
総レコード数:約63億 増加頻度 :300万レコード/日 容量 :約4.3T ほとんどが、レポートデータです。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
26.
現在の状態にするまでに、たくさんの試行
錯誤がありました。 今日はリリースから現在までの4年間に 行ってきた対策を、凝縮してお伝えしま す。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
27.
ステージ1
とりあえずWebサービスを作る。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
28.
■ システムリリースまで
入社してすぐ、リスティング広告の運用における 問題解決のためにWebサービスを構築することに なりました。 ・社内マスタ管理 ・売り上げ管理 この2つ機能を持ったシステムの開発です。 社内にサーバを置き、イントラネットで公開する ことにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
29.
■ システムリリースまで
この時のレポートは「アカウント単位」のみを持っ ています。 アカウント単位のレポート 約2500レコード/日(約100万/年) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
30.
■ 与えられたサーバー
システム構築用に、終了したWebサービスで使っ ていた中古のサーバが1台割り当てられました。 とりあえずそのサーバでシステム構築を進めるこ とになりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
31.
■ 与えられたサーバー
ハードウェア:Dell Power Edge 650 (2003年製) CPU :Pentium4 3.06GHz メモリ :4G HDD :120G Copyright © 2012 CAADvance, Inc. All Rights Reserved.
32.
■ 与えられたサーバー
・当時でも非常に低いスペックでした。 ・入社したばかりで「サーバ買ってくれ」と主張 できませんでした。 ・ひとまず社内のサーバルームに置くことにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
33.
■ リリース当初のDB
下記のようにDBを構築しました。 ・MySQL5.1 ・my.cnfはデフォルトのまま。 ・ストレージエンジンは全てMyISAM。 ・インデックスは張らない。 ・定期的なバックアップはとらない。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
34.
リリースしましたが、すぐに問題が
発生しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
35.
■ リリース当初に発生した問題
① テーブルのロック待ちが頻発し、画面が固まる。 ② トップページの「売上推移」表示に時間がかかる。 ③ 深夜のレポート取り込みバッチが朝までに終わらない。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
36.
■ リリース当初の問題点 ①
問題点:テーブルのロックにより、画面が固まる。 対策 :テーブルをMyISAMからInnoDBに変更。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
37.
■ リリース当初の問題点 ①
MyISAMはデータ参照時にテーブル単位でロックしま す。 重いクエリでjoinを行うと長時間テーブルがロック されたままになってしまいます。 Select Select MyISAM Select Copyright © 2012 CAADvance, Inc. All Rights Reserved.
38.
■ リリース当初の問題点 ①
InnoDBはレコード単位でロックします。 InnoDBにしたことで、テーブルロックで処理待ちが 発生する事象が解消されました。 Select Select InnoDB Select Copyright © 2012 CAADvance, Inc. All Rights Reserved.
39.
■ リリース当初の問題点 ①
ロック等、DBのクエリ実行状況は、 SQL「show processlist」で確認できます。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
40.
■ リリース当初の問題点 ②
問題点:トップの「売上推移」表示に時間がかかる。 対策 :予めサマリしたデータを別テーブルに保持する。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
41.
■ リリース当初の問題点 ②
対策前: 約20,000レコードを集計してグラフを表示。 対策後: バッチで集計済のデータを予め別のテーブルに保持。 これで、トップ画面の表示が約10秒から1秒以下に短縮 されました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
42.
■ 画面表示用にバッチで予め集計
集計バッチ導入前 そのまま蓄積 集計/サマリ 30,000レコー ド 75,000レコード/日 DB Web Copyright © 2012 CAADvance, Inc. All Rights Reserved.
43.
■ 画面表示用にバッチで予め集計
集計バッチ導入後 そのまま蓄積 集計/サマリ 360レコード 75,000レコード/日 DB Web 集計/サマリ Batch Copyright © 2012 CAADvance, Inc. All Rights Reserved.
44.
■ リリース当初の問題点 ③
問題点:深夜のレポート取り込みバッチが朝までに 終わらない。 対策 :バッチの並列実行と、SQLのbulk-insertへ の切り替え。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
45.
■ リリース当初の問題点 ③
・バッチでAPIから取得したレポートをDBに登録す る。 ・バッチの完了期限⇒9時 ・12時までかかってしまう事もありました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
46.
■ リリース当初の問題点 ③
対策① 処理対象のレコードを分割して、4本のバッチを 並行して起動するようにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
47.
■ リリース当初の問題点 ③
対策② SQLを変更しました。 insert部分を1レコード毎から、1,000件毎の bulk-insertに変更しました。 これでバッチが完了するまでの時間が約20倍ほ ど早くなりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
48.
レポート取り込みSQLの解説 Copyright © 2012
CAADvance, Inc. All Rights Reserved.
49.
■ レポート取り込みSQLの歴史
レポート取り込みバッチのSQLは、何度か変更を 行いました。 対策についてより深く知ってもらうため、レポー ト取り込みがどんなシステムかを説明します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
50.
■ レポート取り込みSQLの歴史
①毎日深夜、Yahoo!, Googleから過去30日分の レポートデータをAPI経由で取得します。 Internet Batch Copyright © 2012 CAADvance, Inc. All Rights Reserved.
51.
■ レポート取り込みSQLの歴史
②直近1日分のレポートは新規で登録します。 新規登録 直近1日分 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
52.
■ レポート取り込みSQLの歴史
③それ以前の29日分のレポートは、既に登録さ れている値を書き換えます。 レコード更新 過去29日分 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
53.
■ レポート取り込みSQLの歴史
30日分を更新している理由は、過去の数値が変動する からです。 ・不正な広告クリック分の調整 ・集計遅延分の反映 このような原因で、過去の数値が変動します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
54.
■ レポート取り込みSQLの歴史
30日分のレポートは、 2,500(アカウント) × 30(日) = 75,000 レコードになります。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
55.
■ レポート取り込みSQLの歴史
初期段階: ・APIから取得したレポートを条件に1件ずつselect。 ・同一レコードがDBに存在するかを確認。 ・insertまたはupdateを実行。 SQL発行回数:150,000回 (75,000回 × 2) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
56.
■ レポート取り込みSQLの歴史
改修後: ・過去データを一括でdelete。 ・レポートを1,000件づつbulk-insert。 SQL発行回数:76回 速度は劇的に早くなったのですが・・・ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
57.
■ レポート取り込みSQLの歴史
改修後の問題点: delete⇒insertを繰り返した結果、InnoDBテーブルの 性能劣化が顕著にみられるようになりました。 DBのデータサイズの増加が激しくなりました。 ※InnoDBのデータサイズは、レコードを削除しても減りませ ん。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
58.
■ レポート取り込みSQLの歴史
再改修後: ・INSERT ... ON DUPLICATE KEY UPDATE 構文に変 更。 ・既存レコードはUPDATE、新規レコードはINSERT。 ・1,000レコードづつ一括で実行。 SQL発行回数:76回 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
59.
■ レポート取り込みSQLの歴史
現在は、 ・1,000レコードに対して一括でクエリを実行できる ・レコードが存在すればUPDATE、存在しなければ INSERT ・削除分の無駄な容量増加がほとんど起こらない ・過去データの著しい劣化が無い という、良い状態での運用を実現できています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
60.
■ リリース当初に発生した問題
以上の対策を行ったことで、システムを何とか運用でき るようになりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
61.
ステージ2
きちんとシステムが動くようにする Copyright © 2012 CAADvance, Inc. All Rights Reserved.
62.
Search Suiteがリリースされて半年。
リスティング広告の売り上げも順調に伸び、シ ステムのユーザも増えてきました。 最初はシステム化されたことに喜んでいたユー ザも、徐々にパフォーマンスを求めるように なってきました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
63.
より大きな業務改善を実現するために、キーワード
単位のレポートを蓄積する必要が出てきました。 キーワード単位のレポート 約160万レコード/日(約6億/年) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
64.
■ 次に行った対策
システムのパフォーマンスアップのため、以下の 対策を行いました。 ① ハードウェア増強 ② DBにインデックスを張る ③ DBのレプリケーション Copyright © 2012 CAADvance, Inc. All Rights Reserved.
65.
■ ハードウェア増強
さすがに今のままのサーバ構成だと限界だと感じ、 サーバを増やす事にしました。 本番サーバと同じものがヤフオクで5,000円で落札 されていたのに軽くショックを受けた頃でした。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
66.
■ ハードウェア増強
増設前: Web/Batch/DBを全て1台のサーバで運用 増設後: サーバを4台構成にして、それぞれに別の役割を 持たせるようにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
67.
■ ハードウェア増強
新しく購入したサーバで、かなりスペックも上 がりました。見た目も強そうです。 ハードウェア:Dell Power Edge CPU :Xeon E5506 メモリ :32G HDD :600G SAS Copyright © 2012 CAADvance, Inc. All Rights Reserved.
68.
■ ハードウェア増強
同じタイミングで社内サーバールームを撤去す ることになったので、インフラをデータセン ターに移設しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
69.
■ その時点のハードウェア構成
Intranet VPN Web Batch Data Center MySQL(MASTER) MySQL(SLAVE) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
70.
■ サーバの役割分担で解消されたこと
・メモリやHDDを目一杯割り当てる事ができる。 ・Web, Batchがの負荷お互いに影響を与えなくなった。 ・サーバ負荷が高いとき、原因の特定がしやすくなった。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
71.
■ DBにインデックスを張りました
対策の方針: ・検索される条件になるカラムにインデックスを張る。 ・設定ファイルのslow-query-logを有効にする。 ・クエリにインデックスが効いているかを調べる(explain 文) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
72.
■ インデックスによる速度の違いを調べました
対象テーブル:アカウント レコード数 :約1万6千 カラム数 :18 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
73.
■ インデックスによる速度の違いを調べました
実行したSQL SELECT SQL_NO_CACHE id, account_name FROM account WHERE client_id=3894 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
74.
■ インデックスによる速度の違いを調べました
インデックスによる実行速度の違い 30倍ほど高速になっています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
75.
■ 300万件以上のレコードで実行してみました。
対象テーブル:アカウント別レポート レコード数 :約340万 カラム数 :16 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
76.
■ 300万件以上のレコードで実行してみました。
実行したSQL SELECT SQL_NO_CACHE account_id, report_date FROM transaction_daily_report WHERE account_id='961-565-4063' AND report_date >= ‘20121101’ AND report_date <= ‘20121130’ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
77.
■ 300万件以上のレコードで実行してみました。
インデックスによる実行速度の違い 6,000倍ほど高速になっています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
78.
■ DBにインデックスを張りました
インデックスを張ることで、特に大容量テーブルの 速度が速くなることが分かりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
79.
■ レプリケーション
MySQLには、親子関係を作って複数台で同じデー タを保持できる「レプリケーション」という機能が あります。 ハードウェアのコストはかかりますが、負荷対策に とても有効です。また、ハードウェア障害の対策に もなります。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
80.
■ レプリケーションの仕組み
①APからマスタDBにクエリ送信 ②マスタDBがバイナリログにクエリを書き込み ③マスタサーバからAPに実行完了を伝達 ④バイナリログに書き込まれたクエリをスレーブに転送 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
81.
■ レプリケーションの仕組み
注意 マスタとスレーブにおけるデータの一意性は保証されて いません。マスタとスレーブで同期の遅延が発生するこ とがあります。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
82.
■ レプリケーションの活用方法
よく使用されるのが、データを更新する時はマスターに、 参照する時はSLAVEにクエリを振り分ける方法です。 サーバの負荷が分散されてパフォーマンスがUpします。 Web 参照 SLAVE 更新 参照 MASTER SLAVE Copyright © 2012 CAADvance, Inc. All Rights Reserved.
83.
■ レプリケーションの活用方法
定期的なバックアップはSLAVEで行うと、マスタの 更新処理に影響を与えることなく実行できます。 SLAVE dump MASTER SLAVE Copyright © 2012 CAADvance, Inc. All Rights Reserved.
84.
■ その他:リソース監視ソフト(Munin)導入
サーバリソースの使用状況を確認できるように しました。 定期的に確認して、システムリソースに問題が 無いかをチェックしています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
85.
■ きちんとシステムが動くようにする
以上の対策を行ったことで、 「とても重くて時間がかかるシステム」 から、 「業務システムとして割と普通に使えるシステム」 になったと思います。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
86.
ステージ3
原因調査からのパフォーマンス対策 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
87.
■ 負荷の原因特定
レポートシステムにはよく、想定していなかった負 荷の高いリクエストを投げてくるユーザがいます。 ・2年分くらいのレポートを一括で出す。 ・100アカウントのレポートを一気に出す。 などなど。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
88.
■ 負荷の原因特定
正直、どのように対応してよいか非常に迷いました。 アプリケーションで制限するのは簡単だけど、業務影 響はどうなんだろうかと。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
89.
■ ログ出力の詳細化(Web/Batch)
アプリケーションの実行のログから、負荷が高いク エリは誰のどういう操作か追えるようにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
90.
■ ログ出力の詳細化(Web/Batch)
アプリケーションの実行ログに、下記を出力しました。 ・リクエスト固有のID ・リクエストURL ・実行ユーザID ・メモリ使用量 ・実行時間 ログを定期的に確認し、システムのどこに負荷がか かっているかを特定しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
91.
■ ログ出力の詳細化(Web/Batch)
[実行ログのサンプル] 2012-11-28 03:42:08 t PID[14754] t UID[CAAM0182] t MEMORY[26,990,224] t TIME[2.391] t URL[/sem/quickview/quickview.php] t info ACTION_END n Copyright © 2012 CAADvance, Inc. All Rights Reserved.
92.
■ ログ出力の詳細化(DB)
Web/Batchと合わせてDBのログから、負荷が高いク エリは誰のどういう操作か追えるようにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
93.
■ ログ出力の詳細化(DB)
全てのSQLに「発行したサーバID」と「リクエスト ID」を付与しました。 DBの「プロセス一覧」「slow-log」とWebの実行ロ グを付け合せ、どのリクエストに負荷がかかってい るか調査できるようになりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
94.
■ ログ出力の詳細化
[SQLの例] /** SID[web01] PID[4083428] */ select account_id from report_batch_history where exe_date = '2012-11-08' and report_type = 'ACCOUNT' and status = 0 ただし、これを行うとクエリキャッシュが効か なくなってしまうのでご注意ください。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
95.
■ そのリクエストは何のために?
想定外の重い処理を行っているユーザを特定し て、時には電話ヒアリング。 システムからレポートを出していると、いきな り電話がかかってくるのです。よくびっくりさ れました(笑) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
96.
■ DBの負荷対策を重点的に行いました
① シャーディング ② 敢えて正規化しない ③ インデックス見直し ④ 設定ファイルのチューニング ⑤ キャッシュサーバ導入 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
97.
■ DBのシャーディング
レコード数が大きなテーブルを、複数に分割しました。 キーワードレポートは「年月」「クライアント」で分割 しています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
98.
■ DBのシャーディング
テーブル数が増えるために「テーブルの構造変更」 「テーブル横断での検索」は行いにくくなりますが、 更新/参照の速度は非常に早くなりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
99.
■ 敢えて正規化しない
レコード数の大きなテーブルでは、あえて正規化を せずにデータを持っています。 Joinや複数回のクエリでレコードを作るよりも、高 速に値の取得ができるからです。 report report account + Copyright © 2012 CAADvance, Inc. All Rights Reserved.
100.
■ 敢えて正規化しない
データ容量は少し大きくなりますが、パフォーマンスは 大きく向上します。 結合先の値が変わらない前提のデータのみに有効です。 report report account + Copyright © 2012 CAADvance, Inc. All Rights Reserved.
101.
■ 敢えて正規化しない
正規化した場合 ・SQLでjoinして取得。 ・別々に取得して、プログラムで紐づける。 report account + Copyright © 2012 CAADvance, Inc. All Rights Reserved.
102.
■ 敢えて正規化しない
正規化しない場合 単一テーブルから完全なデータが取得できます。 これによって、データ生成のコストを抑えることがで きます。 report Copyright © 2012 CAADvance, Inc. All Rights Reserved.
103.
■ パフォーマンスを比較してみました
対象テーブル:キーワード別レポート レコード数 :約3400万 カラム数 :16 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
104.
■ パフォーマンスを比較してみました
「正規化」で実行したSQLはこちらです。 SELECT SQL_NO_CACHE count(*) FROM transaction_daily_report inner join account on account.id=transaction_daily_report.account_id WHERE transaction_daily_report.account_id='961-565-4063' AND report_date >= ‘20121101’ AND report_date <= ‘20121130’ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
105.
■ パフォーマンスを比較してみました
結果はこんな数値になりました Joinすると、約3倍の時間がかかっています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
106.
■ インデックスの見直し
データベースにインデックスを張っていましたが、改 めて見直しを行いました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
107.
■ インデックスの見直し
ポイント ・無駄なインデックスは削除 ・複合インデックスで賄えるものは、そちらに一本化。 ・カーディナリティ(値の分散)が高いものから順に復号 インデックスを張る。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
108.
■ インデックスの見直し
explain文でインデックスが有効かを確認します。 例)EXPLAIN SELECT * FROM media_master WHERE id =1 詳しい説明は割愛しますが、クエリの実行にインデック スがきちんと効いているかを調べる事ができます。 Extraフィールドでクエリの実行計画を確認できます。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
109.
■ MySQL設定ファイルの最適化
MySQL設定ファイルを書き換えて、チューニングを行 いました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
110.
■ MySQL設定ファイルの最適化
・メモリ関連のチューニングを行いました。 (InnoDBに多くのメモリを割り当てています。) ・接続した際に、文字コードをutf8に設定しています。 init-connect=SET NAMES utf8 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
111.
■ MySQL設定ファイルの最適化
・InnoDBのデータファイル「ibdata」をテーブル毎に 作成する。 ⇒Innodb_file_per_table └テーブルを最適化しやすい。 ※デフォルトだと、データベース単位でibdataが作成されます。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
112.
■ MySQL設定ファイルの最適化
ib_logfile(更新用の領域)を最大値の4GBを取り、更新系 クエリの高速化を図っています。 innodb_log_file_size = 1364MB innodb_log_files_in_group = 3 ※MySQL5.6系ではib_logfileを512GBまで拡張可能になるようです。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
113.
■ MySQL設定ファイルの最適化
これらの対策を行った結果、DBの動作が目に見えて高 速になりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
114.
■ キャッシュサーバ導入
キャッシュサーバとしてMemcachedを導入しまし た。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
115.
■ Memcached について
概要: Key-Value型のデータストア。 オンメモリで動作をし、非常に高速なのが特徴です。 データは「キー」と「値」をペアで保持します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
116.
■ Memcached の特徴
特徴 ・1つのキーに対して、値の上限が1M。 ・指定したメモリの上限に達した場合、最近最も 使われなかったものから消されていく。 ・オンメモリのため、サーバが落ちるとデータは消失する。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
117.
■ キャッシュサーバ導入
導入にあたり、検討したポイント ① 値を保持する方法。 ② 検索の仕組み。 ③ DB→Memcachedへデータロードのタイミング。 ④ Memcachedに値が無い場合。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
118.
■ 値を保持する方法
テーブルの内容や検索結果の全レコードをtsvにし、 1つのキーに設定しています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
119.
■ 検索の仕組み
Memcachedから値を取り出す際に、指定条件でフィルタ できるようにアクセス用のクラスを開発しました。 複数の値を、1回のMemcachedアクセスで取得 することができます。 アプリケー フィルタ ション Copyright © 2012 CAADvance, Inc. All Rights Reserved.
120.
■ DB→Memcachedへデータロードのタイミング
・ほぼ更新のないマスタ系のデータ:1日3回 ・頻繁に更新されるデータ:1時間に3回 ・DBの値を更新した際:再ロードを実行 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
121.
■ Memcachedに値が無い場合
キーに対して値が全く存在しない場合には、DBから 値を持ってくるような仕組みを構築しました。 ① アプリケー ション ② Copyright © 2012 CAADvance, Inc. All Rights Reserved.
122.
Memcached導入の具体例 Copyright © 2012
CAADvance, Inc. All Rights Reserved.
123.
■ レポート作成画面への導入事例
クライアントを選択する画面です。 プルダウンのリストをMemcached化しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
124.
■ レポート作成画面への導入事例
Memcached登録用のSQL select company_name, account.client_id, if( LENGTH( client_name ) > 0, concat( company_name, '//', client_name ) , company_name ) AS client_name from account inner join account_info on account.id=account_info.account_id inner join client on client.id=account.client_id inner join company on company.id=client.company_id inner join client_con_user on client.id= client_con_user.client_id where account_info.account_status_id=1 and client.delete_flg = 0 and client_con_user.user_id=‘XXXX’ group by client_id order by company_name, client_name Copyright © 2012 CAADvance, Inc. All Rights Reserved.
125.
■ レポート作成画面への導入事例
「ログインユーザの担当クライアントを選択」 という条件をSQLで実行しています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
126.
■ レポート作成画面への導入事例
DBから取得していた値をMemcachedに載せました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
127.
■ レポート作成画面への導入事例
Mencache導入の結果、画面表示が2倍以上早くなりまし た。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
128.
■ Memcached導入
Memcachedはとても効果の大きい対策になりました。 少し手間はかかりましたが、導入して良かったです。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
129.
ステージ4
更なるパフォーマンスを求めて Copyright © 2012 CAADvance, Inc. All Rights Reserved.
130.
■ 新メンバーのジョイン
新しいエンジニア2名がチームに加わりました。 別グループにいた佐久本、仲里です。 力を合わせて、システムの更なる高速化・安定運用 に向けて取り組みます。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
131.
■ 更なる対策
更なる速度を追求すべく対策を行いました。 ① サーバの増強(また追加しました) ② PHPのアクセラレータ導入 ③ DB-SLAVEへのLB導入 ④ ネットワークの2重化 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
132.
■ サーバの増強
この頃になると、予算もキーワード数も多いク ライアントが多くなってきました。 システム負荷は上がるばかりです。 これに対応すべく、サーバの増強を行うことに しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
133.
■ サーバの増強
サーバを10台ほど購入し、以下の対策を行いました。 ・Webサーバの多重化 ・容量の多いデータベースを別サーバに移動する。 ・DBサーバ(SLAVE)の多重化 サーバ多重化に伴い、ロードバランサを導入しました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
134.
■ ロードバランサ導入
ロードバランサの種類:IPVS(LVS:Linux Virtual Server) 振り分け方法:全てのサーバに均等(ラウンドロビン) サーバ①②③に均等に振り分け Load Balancer る。 Web① Web② Web③ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
135.
■ ロードバランサ導入
KeepalivedのMISC_CHECKと組み合わせて、ダウンし たサーバは自動的に切り離すようにしています。 Load Balancer サーバダウン⇒自動的に切り離 × す。 Web① Web② Web③ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
136.
■ ハードウェア構成
Intranet 監視(nagious) Intranet VPN Load Balancer NFS Data Center Web/ Cache Batch 監視(nagious) Load Balancer MySQL(MASTER) MySQL(SLAVE) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
137.
■ PHPアクセラレータ導入
Webサーバに「eAccelerator」を導入しました。 PHPの実行が驚くほど早くなりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
138.
■ PHPアクセラレータ導入
PHP(スクリプト型言語)の特徴として ・コンパイル無しですぐに実行できる。 ・ソースを入れ替えるだけでリリース可能。 等があります。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
139.
■ PHPアクセラレータ導入
でも、実は裏では、 実行する前にソースがコンパイルされているの です。 プログラムが参照するファイルが多ければ多い ほど、コンパイルに時間がかかってしまいます。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
140.
■ PHPアクセラレータ導入
アクセラレータは初回実行時に、コンパイル済の バイトコードをメモリ上にキャッシュします。 これによって高速な実行を実現しています。 PHP実行イメージ 初回実行時に メモリにキャッシュ コンパイ 解析 ル PHPソースコード バイトコード 実行 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
141.
■ PHPアクセラレータの効果
画面を表示する時間を計測しました。 表示にDBアクセスはせず、キャッシュサーバーから プルダウンのリストを取得して表示しています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
142.
■ PHPアクセラレータの効果
ベンチマークしてみました。 約2倍も高速になっているのが分かります。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
143.
■ PHPアクセラレータの導入
とても手軽で、かつ効果的な対策でした。 コストも0円です。 もっと早く知っていれば・・・。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
144.
■ DB-SLAVEのロードバランサ導入
アプリケーション側で行っていたSLAVEへクエリ発 行する際の接続先制御を、ロードバランサで行うよ うにしました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
145.
■ DB-SLAVEのロードバランサ導入
ロードバランサでのSLAVE接続先制御を行うことで、 ・故障したハードの切り離し ・SLAVEの追加 ・負荷が低いサーバへの接続 これらが簡単にできるようになりました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
146.
■ DB-SLAVEのロードバランサ導入
これまでのDBバランシング ⇒アプリケーション側でSLAVE接続先を選択。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
147.
■ DB-SLAVEのロードバランサ導入
対策後のDBバランシング ⇒ロードバランサーがSLAVE接続先を選択。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
148.
■ DB-SLAVEのロードバランサ導入
ロードバランサを利用したMySQLの運用にあたり ・MySQLのレプリケーションの遅延を監視 ・遅延しているSLAVEにリクエストしない これを実現する仕組みを構築して運用しています。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
149.
■ DB-SLAVEのロードバランサ導入
SLAVEサーバにプログラムを設置し、自身の状態を監視。 MISC_CHECK経由でロードバランサがSLAVEの状態を確 認。 レプリケーション遅延や停止が起こるとSLAVEを切り離 します。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
150.
■ DB-SLAVEのロードバランサ導入
この対策を行った結果、DB負荷の高い処理が1つの SLAVEに集中しなくなりました。 結果として、「レポート出力に時間がかかる」とい う問題発生を減らすことができました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
151.
■ ネットワークの2重化
ネットワークをデータセンターの内部向け/外部 向けで2重化を行い、トラフィックを分散させま した。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
152.
■ 対策前のネットワークのイメージ
外部向け、内部向けのネットワークが全てが同じセグメ ントにあるので、回線にトラフィックが集中しています。 外部API Data Center DB(MASTER Web Batch DB(SLAVE) ) Copyright © 2012 CAADvance, Inc. All Rights Reserved.
153.
■ 対策後のネットワークのイメージ
外部向け、内部向けのネットワークが分かれているので、 トラフィックを分散することができるようになりました。 外部API Data Center 外部向けネット ワーク × × DB(MASTER Web Batch DB(SLAVE) ) 内部向けネット ワーク Copyright © 2012 CAADvance, Inc. All Rights Reserved.
154.
■ ネットワークの2重化
ネットワークの2重化によって ・ 外部APIからのデータ取得の高速化 ・ DBとWeb-Batchサーバ間の通信高速化 ・ レプリケーション遅延の減少 これらを実現することができました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
155.
■ 今はここまで
これらの対策を行った結果、システムの速度や安定 性が格段に上がりました。 これからもメンバーと力を合わせて、更に高いレベ ルを目指していきたいと思います。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
156.
失敗した対策 Copyright © 2012
CAADvance, Inc. All Rights Reserved.
157.
■ DBへのSSD導入
書き込みの回数が多すぎて、1ヶ月でSSD が故障(ミラーリングしていた2台とも・・) 書き込みが回数多いDBへのSSDは導入は難しいのか もしれません。 速度はとても早くなったのですが・・・ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
158.
■ DBへのSSD導入
講演「 GREEを支える大規模インフラテクノロジー」 や書籍「Mobageを支える技術」によると、GREEさ んDeNAさんではSSD導入で成功しているみたいです。 弊社でも機会があれば、また検証したいと思います。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
159.
これから行いたいこと Copyright © 2012
CAADvance, Inc. All Rights Reserved.
160.
■ Fusion-io使ってみたい!
・新しいフラッシュメモリのストレージ。 ・非常に高速で、信頼性が高い。 ・Amebaでは、96台のサーバを8台にした実績あり。 ・百万円以上で、HDDと比べると非常に高価。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
161.
■ MySQL5.6を導入したい!
・現在はRC(リリース候補版)が最新。 ・データベース単位でレプリケーションの並列実行。 ・MemcachedプロトコルでInnoDBに直接アクセス可能。 ・InnoDBがパワーアップして、全文検索に対応。 その他、新機能が盛りだくさん。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.
162.
■ さいごに
いかがでしたでしょうか。本日の内容が、少しでも 皆様のお役に立てば幸いです。 ブログも書いていますので、興味があればぜひご覧 ください。 エグジニアブログ http://ameblo.jp/exgineer/ Copyright © 2012 CAADvance, Inc. All Rights Reserved.
163.
本日の勉強会は以上になります。
ご清聴ありがとうございました。 Copyright © 2012 CAADvance, Inc. All Rights Reserved.