MySQL Cluster/MySQL Enterpriseを活用したフルマ …...フルマネージドホスティングサービス—ULTiDC 移行事例パターン OS Windows UNIX(Solaris, AIX, HP-UX)

MySQL Cluster/MySQL Enterpriseを

活用したフルマネージドホスティングサービス事例紹介

株式会社アルティネット櫻田剛史

[email protected]

Apr. 3 2012

OTN MySQL User Forum Tokyo

弊社紹介

株式会社アルティネット

http://www.ultinet.co.jp/

1999年、埼玉・大宮市にて創業、現在は東京・湯島にございます

SIerです！インフラ構築

アプリケーション開発

システム運用

LAMP環境を利用した、フルマネージドホスティングサービスを得意としています。

地図データ©2012 Google,ZENRIN

2

UltinetとMySQL（の歴史？）

MySQLVersion 3.22(1999年)からのお付き合いです。

その後～MySQL AB⇒Sun⇒Oracleといろいろ変遷ありましたが、一貫して使い続けています。

実は、前回のMySQLユーザーコンファレンス（2008年10

月31日）でも事例紹介をさせて頂きまして、本日はそれの続編です。

3

フルマネージドホスティングサービス—ULTiDC

全く新規のシステムを構築する案件だけではなく、既存のシステム（他のDCにあったり、オンプレミスであったり

する）を丸ごと移設（引っ越し）、システムのリニューアル（リプレース）開発、インフラからアプリ部分まで全部の面倒を見るのが得意。

老朽化したシステムをアプリケーション部分も含めて全部リニューアルする提案をしています。

移行後環境をLAMPで統一することによって、コストを抑え、高い品質のプロダクト・サービスとして提供。

MySQL DBはこのビジネスモデルの核となる重要な組込みソフトウェアコンポーネントです。

4


① まず、既存システムを丸ごと引っ越します

アプリケーション

ASP.NET

(C#)

IIS SQL-Server

Windows Server

既存システム※他iDCもしくはオンプレミスで存在 ULTiDC（弊社のデータセンター）

丸ごと引っ越し

5

ULTiDC（弊社のデータセンター）


② LAMP環境上でリニューアルします

既存システム（例：Windowsで構築されたシステム）新システム

6

アプリケーション

ASP.NET

(C#)

IIS SQL-Server

Windows Server

アプリケーション（リニューアル版）

PHP

Apache MySQL

RedHat Enterprise

Linux(RHEL)

リニューアル

ULTiDC（弊社のデータセンター）


顧客側メリット

長年の増築開発でつぎはぎだらけになって保守、運用コストが増大したシステムを最適化できる。

自社でシステム運用担当を抱えなくて済むことによるコスト削減。

オンプレミスの場合、災害対策(DR, BCP)対応のDCで安定運用できる。

新システム

7


PHP

Apache MySQL

RedHat Enterprise

Linux(RHEL)


移行事例パターン OS Windows

UNIX(Solaris, AIX, HP-UX)

Linux

DB SQL Server

Oracle DB

PostgreSQL

MW Java(Weblogic)

ASP.NET(C#, VB)

Perl

PHP

リニューアル

LAMPで統合※MySQL DBはこのビジネスモデルの核となる重要な組込みソフトウェアコンポーネント

8


PHP

Apache MySQL

RedHat Enterprise

Linux(RHEL)

アジャイルソフトウェア開発

スクラム（SCRUM）開発手法認定スクラムマスターが在籍

価値のあるソフトウェアを短いサイクル（スプリント）で、顧客に届ける仕組みを実践。

公開勉強会も開催してますアジャイルサムライ湯島道場

一緒に開発できる仲間を募集中です！

9

（ここから本題）本日ご紹介したい事

MySQL Clsuterに興味を持っている人向け MySQL Clusterの具体的な活用事例についてはあまりオープンになっていないので、できるだけ具体的な話（当初の期待、実際の導入時の検討、実運用での苦労、思ったように行かなかった点、今にして思えば考慮すべき点、最新のv7.2検証結果、今後への期待）をしたい。

商用版のMySQLってどういう意味があるの？って疑問に感じている人向け一般のユーザ、エンジニアのレベルでは、既にGPLでフリーに公開されているMySQLに対してお金を払うことに疑問を感じている人も多い（僕自身がそうだった）。その中でユーザ視点での率直なメリット、デメリットを例示して、今まさにモヤモヤ感を抱いている皆様の判断の一助になれば幸い。

10

UltinetでのMySQL Cluster導入事例

V7.0.xで２年超の運用継続中

データベースシステムとしての信頼性は非常に高いものと考えています。

データの喪失のような重大事象は発生なし

個別の事象を解説するのはいろいろと問題があるので、そこから判明した隠れた仕様、限界と、教訓にフォーカスしてご紹介致します。

11

MySQL Cluster導入のための検討ポイント

12

MySQL Cluster導入検討のポイント（結論）

（NDBが適したアプリケーション）

NDBを高性能かつ、高可用性(HA)を実現する部品として組み込むための、設計、作りこみを前提とする業務システム。 MySQL Enterprise（普通のMySQL）ほど、入れたらぱっと使えるという種類のものではないです（後述します）。

インメモリDBでかつ、トランザクションを使えるというメリットを生かした、オンライン処理(OLTP)が主体となるシステム大量のデータをまとめて処理するバッチ処理は苦手（V7.2の

AQLで改善が見られたようではあります）

インメモリDBとしてのメリットは、現在は、SSDをベースとしたものとのコストベネフィット評価をする必要があると思います。

13

普通のMySQLとの違い普通のMySQLであれば1個DBを置けばOK

冗長構成のためにはMaster/Salveの構成が一般的

マスタで障害が発生した場合にはSlaveをMasterに昇格させるなどの処置が必要（もしくは、Heartbeat/DRBDなどでActive/Standby構成を作っておくなどの方法も一般的）

規模が大きくなれば更新系だけであればSlaveをたくさん設置してスケールアウトできるが、更新系はボトルネックとして残る

MySQL DB

(Master)

冗長構成

MySQL DBMySQL DB

(Slave)

最小構成

【よくあるActive/Standby構成】・READインテンシブなアプリであればSlaveをいっぱいつなげてスケールアウト・Masterに障害が発生した場合には、自動引き継ぎの仕組みが必要(MHAとか、ディスクレベルの冗長化(DRBD)とか）MySQL DB

(Master)

アクセス多

MySQL DB

(Slave2)

MySQL DB

(Slave3)

MySQL DB

(Slave1)

MySQL DB

(Slave5)

MySQL DB

(Slave4)

14

MySQL Cluster導入のメリット

高可用性 HA機能が、もともとシステム自体に備わっている（Slave⇒Master昇格操作などを作りこむ必要が無い）

切替が高速（障害検知～収束のための時間を含めても10秒程度）

高性能インメモリデータベースであるため、ディスクI/Oによる、

READ/WRITEボトルネックが原則発生しない（例外もあり、後述します）

SQLノードを追加することによって、比較的リニアな性能向上が期待できる

各SQLノードはActive/Active構成のため、更新系も分散させることができる（考慮ポイントを後述します）

15

MySQL Clusterを構成するコンポーネント

３種類あります

MGMノード DATAノード SQLノード

・NDBの管理をするマネジメントノード・HA構成のF/Oを制御している・負荷は小さいデーモンなので、SQL

ノードなどに同居させることが多い

・オンラインバックアップなど作業を行うためのコマンドが提供されている

・NDBのデータベース本体・インメモリDB、トランザクション有効（分離レベルはREAD COMMITED）・SQLは直接は解釈できない、専用のNDBAPIを使う

・MySQLのインターフェースを提供し、SQLを解釈してNDBAPIを介してNDB

とやり取りする・要はストレージエンジンとしてNDBを使えるMySQLと理解できる・特性上、複数のSQLノードを起動しても更新できる(Active/Active構成、マルチマスタ)

MGM DATA SQL

16

MySQL Cluster構成検討

基本的な構成

SQL MGM

SQL/MGM 1号機

SQL MGM

SQL/MGM 2号機

データー 1号機

DATA

L2 SW

L2 SW

Web server Web server Web server Web server Web server Web server Web server

アプリケーションレイヤー

データベースレイヤー


DATA


DATA


DATA

17

ノード構成のパターン検討

DATA

SQL MGM MGM

DATA

SQL MGMSQL

DATA

冗長構成最小構成

データ量大

DATA DATA

DATA DATA

アクセス多

DATA DATA

MGMSQL MGMSQL MGM

SQL

MGM

SQL SQL SQL

ミニマム構成だが、冗長性も無いので商用環境には向かない。

単一障害点（SPOF）を排除した冗長構成の基本形（NW部分の検討は必要）

保存するデータ量（件数）が大きくなった場合にはデータノードを増やして対応できる。ただし、Secondary Index使用時の制約あり（後述します）

アクセスピークに応じて性能を向上（スケールアウト）させるためには、SQLノードを増やして対応する。今となっては、この構成が最適なケースが多いかもしれない。

18

ノード構成のパターン検討

構成タイプ

MGM

ノードSQL

ノードDATA

ノード合計ノード数

説明弊社実績

I 1 1 1 3最小構成（冗長化無し）

試験・開発環境ならば使えるがそれ以上の意味が無い

○

II 2 2 2 6単一障害点(SPOF)無しの冗長構成（基本形） ○

III 2 2 4 8保存するデータ量（件数）が大きくなった場合 ○

IV 2 4 2 8 アクセスピークに応じて処理性能を向上させたい場合

○

V 2 8 4 14 データ量と処理性能の両方に要求レベルが高い大規模システム

-

VI 2 2 3 7データノードの冗長化を2重ではなく、3重にした場合（レプリカ数3）

-

VII 2 2 6 10データ量が多く、データノードを増やして対応した場合（レプリカ数2）

-

※完全にPK（主キー）に帰着できるアプリにできないのであれば、データノードの数は最大でも4程度に止めた方が良い。

19

メリット１：高可用性(HA) データノードの障害を検知後、自動的にF/O

所要時間は最短で約2.0秒（以下実験のログ参照）

2012-03-23 16:25:37 [MgmtSrvr] ALERT -- Node 3: Node 2 Disconnected2012-03-23 16:25:37 [MgmtSrvr] ALERT -- Node 5: Node 2 Disconnected2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: Communication to Node 2 closed2012-03-23 16:25:37 [MgmtSrvr] ALERT -- Node 101: Node 2 Disconnected2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: Communication to Node 2 closed2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 3: Communication to Node 2 closed2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 4: Communication to Node 2 closed2012-03-23 16:25:37 [MgmtSrvr] ALERT -- Node 4: Node 2 Disconnected2012-03-23 16:25:37 [MgmtSrvr] ALERT -- Node 5: Arbitration check won - node group majority2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: President restarts arbitration thread [state=6]2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 4: Communication to Node 2 closed2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: GCP Take over started2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: Node 5 taking over as DICT master2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: LCP Take over started2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: ParticipatingDIH = 00000000000000002012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: ParticipatingLQH = 00000000000000002012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_Counter_DIH = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_Counter_LQH = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: m_LAST_LCP_FRAG_ORD = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:37 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_From_Master_Received = 12012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: LCP Take over completed (state = 4)2012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: ParticipatingDIH = 00000000000000002012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: ParticipatingLQH = 00000000000000002012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_Counter_DIH = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_Counter_LQH = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: m_LAST_LCP_FRAG_ORD = [SignalCounter: m_count=0 0000000000000000]2012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: m_LCP_COMPLETE_REP_From_Master_Received = 12012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: GCP Take over completed2012-03-23 16:25:38 [MgmtSrvr] INFO -- Node 5: kk: 31025252/3 0 02012-03-23 16:25:41 [MgmtSrvr] INFO -- Node 5: Communication to Node 2 opened2012-03-23 16:25:41 [MgmtSrvr] INFO -- Node 4: Communication to Node 2 opened2012-03-23 16:25:41 [MgmtSrvr] INFO -- Node 3: Communication to Node 2 opened2012-03-23 16:26:23 [MgmtSrvr] INFO -- Mgmt server state: nodeid 2 reserved for ip 172.16.11.151, m_reserved_nodes 2, 21, 22, 23, 24, 25 and 101.2012-03-23 16:26:44 [MgmtSrvr] WARNING -- Node 5: Releasing node id allocation for node 2

16時25分37秒Node2のNDB

デーモンをkill

16時25分38秒F/O完了

20

HA構築時の考慮事項 MGMノード障害

MGMデーモンを複数台起動して、DATAノード側から両方参照(connect-stringsで2個設定)しておけば、自動的にF/Oされます（但し、configファイルの自動同期はうまく動かないです）。

MGMノードはNDBのメンテナンス、DATAノード、SQLノード障害発生時の自動F/Oを行うために必要なものなので、Active/Standby構成も有りです（他のノードで障害が発生した時に存在していれば問題がないため）が、多重障害が発生すれば当然システムが全断します。

SQLノード障害切り離しはNDB側で制御されますが、アプリケーション側でF/Oの切り替えを作り込んでおく必要があります。

高負荷対策としてautoincremt-prefechを有効にしている場合、一時的にばらつきが発生するので、その場合でも問題が出ないようにアプリを作っておく必要があります。

DATAノード障害自動的にNDBのF/O機能が動きます。障害発生時のクエリ・トランザクションはSQLノードより、エラーとして返却されますので、適切なエラーハンドリング、リトライ（リカバリ）処理はアプリ側で作り込みましょう

21

メリット２：高性能インメモリDB

主キー(PK)でのランダムREAD(SELECT)性能試験を実施

該当のテーブルには数千万件のデータが存在する状態

0

10000

20000

30000

40000

50000

60000

0 50 100 150 200 250 300

並列数

1 InstanceThroughput(TPS)

3 InstancesThroughput(TPS)

22

高性能DBとして扱うためのポイント

スキーマの全面的な見直しは必須

InnoDBの時と同じスキーマのままMySQL Clusterにマイグレーションしても高い性能は享受できません。

（スキーマ・アプリ側のポイント）

可能な限り主キー(PK)に帰着させること

主キー(PK)に帰着が難しい場合も、ユニークインデックスを使

える場合はある程度性能が出るが、並列限界値、長時間ロック多発の原因になるので注意が必要。

セカンダリインデックスはできるだけ使わないようにすること。（並列処理は限界値が非常に低い、V7.2で改善あり）

23

その他、利用上の要考慮ポイント

GCP Stopを回避 GCP Stopが発生すると、データノードがダウン（再起動にデータ件数・インデックス個数が多いと長時間（１時間～２時間）かかる）してしまうので、なるべく発生しないようにアプリ側での作り込みが必要。

GCP Stopが発生する原因の一つとして、一度に大量のデータ行数をCOMMITする際に設定閾値を超過すると発生してしまう。更新系(UPDATE/DELETE)クエリにおいてWHERE節での指定には注意が必要（あらかじめ、最大に対象となる行数が決まることが必須）。

JOINをなるべく避ける JOINが苦手なので、バッチ処理等で大量の行を結合することは避けるべき（V7.2 新機能AQLで改善あり）。

24

Version 7.2性能検証

25

ちょっとだけ

AQLによるJOIN性能の改善

26

MySQL Cluster(NDB)では、これまでJOINで性能が全然出ませんでした…

V7.2のAQLによる性能改善を検証してみました。

検証条件

結合テーブル数：２

結果セット想定： 36,000件

結果

V7.0.x 12秒

V7.5.2 0.14秒

約85倍高速に!!※社内のテストラボで試した結果です。条件によっては速くならないこともあります。

SQLノード単体の性能向上

27

これまでは、同時並列的に大量のアクセスをかけると比較的すぐに性能が劣化していました。

MySQL ClusterではSQLノードを増やすことで比較的リニアにスケールアウトできていましたが、V7.2のSQLノードが最新のMySQL 5.5ベースになったことにより、SQLノード単体の同時並列処理数の限界値が伸びています。

※社内のテストラボで試した結果です。条件によっては速くならないこともあります。

SQLノード単体の性能向上（結果）

28

0

10000

20000

30000

40000

50000

60000

0 50 100 150 200 250

スループット

(TP

S)

並列数

V7.2.5

V7.0.x

並列数を上げても性能が劣化しない(V7.2)

MySQL Cluster導入検討のポイント（まとめ）

（NDBが適したアプリケーション）

NDBを高性能かつ、高可用性(HA)を実現する部品とし

て組み込むための、設計、作りこみを前提とする業務システム。

インメモリDBでかつ、トランザクションを使えるというメリットを生かした、オンライン処理(OLTP)が主体となるシステム

大量のデータをまとめて処理するバッチ処理は苦手なので、InnoDBエンジンと併用するなどの考慮が必要。

29

ユーザ視点から見た商用版MySQL

ライセンスの優位性

30

ユーザ視点から見たMySQL商用版へのギモン

（疑問１）Community(GPL)版がMySQL公式サイトからバ

イナリを無料で入手できるのに、商用版を購入する必要があるのか？

（疑問２）RedHat Enterprise Linuxの公式パッケージにもMySQLがあるけれどもどちらを使う方が良い？

（疑問３）MySQL Enterprise(InnoDB)は、もう相当枯れて

いるんじゃないの？商用サポートが必要なケースってそそうそう無いんじゃない？

31

※本疑問と回答は、Ultinetが非公式に調査し

た結果であり、各メーカーの公式見解ではありません。

（回答１）商用版バイナリ利用の意義

GPLの適用を避けたい（組込み系のプロダクトなどで多いニーズ）ということであれば、商用ライセンスは必須です。

組込み目的であれば、年間サブスクリプション契約とは別メニューであるOEMライセンス(ESL)契約が割安です。

Community版には一部、Enterprise版から落とされている機能(Thread pooling等）がありますので、それを使用したい場合にはEnterprise版を使用しましょう。

（商用版のアドバンテージ） 24h7daysのテクニカルサポートが使えます（無制限、日本語は

weekday daytimeのみ、それ以外の時間帯は英語）。

MySQL Enterprise Monitor（とQuery Analyzer）やEnterprise Backupなどの便利なツール群が提供されます。

32

（回答２）RHEL環境でのバイナリ選択検討

Oracle RedHat（標準提供されるバイナリ）Community(GPL)版商用(Enterprise)版最新版(5.5 GA)が提供中

※RHEL6向けのバイナリパッケージは現在提供されていない（Generic Linux版を使用することは可能）。

（標準提供されるバイナリ）RHEL5 MySQLV5.0.x（22～95)

RHEL6 MySQLV5.1.x（47～61）いずれも(Community)GPL版がベース

※V5.0.xはOracle側では2011/11でEOL

※現在V5.5のパッケージは提供なし

（サポート体制）

商用ライセンス（サブスクリプションなど）を購入していれば、独自ビルドであってもサポートはしてくれます（但し、Oracle側で再現性が取れない場合は限界あり）。

RedHatの標準パッケージもユーザの独自ビルドとしての扱いでサポートしてくれます。

（サポート体制）標準パッケージ群にはRedHatのメンテナーチームがRHEL OSのEOLまで確保される。

※Oracle提供のパッケージ(Community/Enterprise版問わず)を使った場合のサポート体制は無い。

33

3/21リリース!

Ver. 5.5.22

（回答３）商用テクニカルサポートの意義重大度（１～４）に応じた、サービスレベルが提供されます。その場ですぐの解決が保障されるわけではないのですが、暫定回避策(Workaround)の提示など、サポートの動きをしてくれます。

問題事象の原因究明と、再発防止策をサポートしてくれます弊社の実績では、２年超で１０数件くらいの問題事象が発生しています。

納得・解決するまで、とことん対応してくれるのもありがたい（やり取りが100往復を超えているものあります。

InnoDBがらみの障害事象は尐ないですが、ゼロではないので、やはりサポートがあるのは心強いです。

MySQL Clusterの方は、テクニカルサポート無しで運用をするのは不可能だったと思います。

34

MySQL商用サポートへの今後の期待（１）

安心・安全なバージョンアップへ

商用環境でのDBのバージョンアップは現状、マイナーバー

ジョンであってもうっかり上げられないです（それが故の問題を絶対に発生させたくないので）。

できれば、新、旧システムで全く同じ処理を実行させ、でしばらく並行稼働させて検証できるような仕組みがあるとありがたいです（レプリケーション（RBR)だと必ずしも検証にならないので）。

35

MySQL商用サポートへの今後の期待（２）

36

EOLをもっと長期に

業務システムでは、ソフトウェアのライフサイクルがどんどん長くなっていますが、商用サポートの期限(EOL)が短いことがネックになりそうです。

SIerとしてはEOLを迎える前にリプレース、マイグレーションの

提案を進めていますが、お客様によっては費用対効果により提案しても受け入れられない事例もあります。

特に、組込みシステムでは一旦、完成して納入すると極力手を触れない傾向もあるため、たとえばOSと同程度の期間メンテナンス、サポートを継続してもらえるとありがたいです。

UltinetによるMySQL Cluster導入支援サービス

MySQL コンサルティング

MySQLデータベース設計・開発・導入支援

MySQLデータベースチューニング

URL http://www.ultinet.co.jp/mysql/

お問い合わせ・ご相談はこちらまで[email protected]

37

Documents

MySQL Cluster/MySQL Enterpriseを活用したフルマ …...フルマネージドホスティングサービス—ULTiDC 移行事例パターン OS Windows UNIX(Solaris, AIX, HP-UX)