【レポート】JAWS-UG Meguro#1に参加してきました #jawsmeguro

Guri / Hajime Oguri

2015.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。先日JAWS-UG Meguro#1に参加してきましたのでレポートしてみます。当日は雨天でにより参加者が少なかったので、内容を詳しく書いてみます。

JAWS-UG Meguro

JAWS-UG Meguroとはアマゾンデータサービスジャパン(所在地が目黒)の方、つまりAWSの中の人を中心とした勉強会です。前回JAWS-UG Meguro #0があったため#1ですが2回目となります。

MySQL on EC2

最初はrockhopper6542 さんによる社内でのMySQL運用についてのお話でした。 * システム構成 * なぜRDSを使わないか * MySQL on EC2 な構築 * MySQL on EC2 な運用

システム構成

社内ではWebSocketサーバとELB＋Appサーバ＋Cacheサーバ＋DBサーバ(Master＋Slave)の構成があります。

なぜRDSを使わないか

基本的にメンテナンス(のための停止を)しない運用ポリシー

停止しなければ作業は楽だが、いつでもゲームを楽しんでもらいたいメンテナンスウィンドウの停止時間が許容できない

ベンダーロックインしたくない

エンジニアのデータベース技術低下

個人的意見だが、マネージドサービスに頼ると技術力が低下するかもしれない。いざという時のノウハウが不足する

MySQL on EC2 な構築

EBS Pre-Warming

EBSへの初回アクセス時に5〜50%低下するので、ddしてPre-Warmingを行う

$ sudo dd if=/dev/zero of=/dev/xvdf bs=1024k

ただし、16TBのPre-Warming時間が34時間掛かる。Pre-WarmingなしのEBSがほしいです！！！

NUMA

8xlargeを使うときは、MySQLのNUMAパッチを適用する。

PPS(Packet Per Second)対策

SR-IOVを使用する。
バケット処理が1コアに集中して、処理できなくなる。 RSS(Receive Side Scale)で複数のキューを使用する。 RPS(Receive Packet Steering)：RSSのソフトウェア実装を使用する。 ※：NUMAとPPSについてはEC2チューニングTipsを参照

MySQL on EC2 な運用

オンラインマスタ切り替え

マニュアルオペレーションで切り替える方法です。

メリット：サービス停止なしで切り替えられる
デメリット：切り替え先として現構成と同じインスタンス台数が必要

切り替えの流れ

新系統 MasterDB ＆ SlaveDB を構築
SlaveDB 切り替え
MasterDB 切り替え

切り替え前は1:N レプリケーションで更新系はMasterDB、参照系はSlaveDBへ分散している。

SlabeDBを基にMasterDBの下にMasterDB(New)を構築する。MasterDB(New)はlog-slave-updatesとする。MasterDB(New)の下にSlaveDB(New)を構築する。新系統はウォームアップしておく。

参照系をSlaveDB(New)に向ける。

MasterDB(New)のauto incrementを少し増やす。auto incrementを増やすことで、MasterDBの切り替え時にキー重複を防ぐ。更新系をMasterDB(New)に向ける。 MasterDBへの更新がなくなったら新旧レプリケーション設定を削除する。

切り替えが完了する。

ウォームアップについて

事前にinnodb buffer poolにデータを読み込ませる
できれば本番DBと同じメモリ状況でサービスインさせたい
全テーブル読み込み BLACKHOLEでテーブルを作成して既存テーブルをINSERT INTO SELECTする
頻度の高いテーブル読み tcpdumpの実行結果をpt-query-digestで集計する
MySQL5.6からは、innodb_buffer_pool_dump/loadを実行する

i2インスタンス

想定外の負荷の場合は、SLaveDBにi2インスタンスを使う * SSDなインスタンスストアをソフトウェアRAIDで使用 * 高速なSSDなので、ウォームアップなしでサービスイン * あくまでも一時しのぎで、MasterDBとしては使っていません。(高価であるため)

まとめ

RDS使わないで、MySQL on EC2しています
EBS Pre-Warmingが大変
カジュアルにオンラインマスタ切り替えしています
i2インスタンスもカジュアルに使っています
でも、RDS、Auroraに興味あります

Q&A

Q:切り替えはサービスダウン無し？ A:auto_incrementで更新が重複しないようにしている。auto_incrementの増える量を確認して、必要な分だけ増やしている。

Q:DBのIPの管理は？ A:泥臭くやっている。開発側への知らせて作業している。

Q:innodbバッファプールのダンプの方法は？ A:普通にSlaveでやっている。すぐ終わって、あまり負荷も大きく無い。

Q:切り替えをどこでやっているか？ A:データセンタではLVSでやっていた。AWSではApp側の設定ファイルをばら撒いている。 Route53だと切り替わら無い時があるので、まだやっていない。

Q:伝送遅延時間がシビアそうだがどうしている？ A:Single-AZで運用している。初期のアプリはMulti-AZ環境では遅延が許容できなかったから。バックアップなどの用途で別AZにおいている。ただし、最近のゲームはローカル処理が増えているため、シビアでなくなっている。そのためMulti-AZを検討したい。

Q:マスタ障害時のフェイルオーバーはどうしている？ A:普通にSlaveを人力で昇格させている。MHAなどを使っていない。あまりマスタが落ちることが無いので、自動化のモチベーションが無い。模索中です。

Q:切り替えのタイミングで、多段Slaveの遅延はどうしている？ A:孫なので遅延はする。夜間のピーク外に作業しているため、影響は起こっていない。

今更だけどAmazon Dynamoの論文解説するお

@imai_factoryさんによるDynao論文の解説です。なお、Amazon Dynamoは、DynamoDBの基となっていますが別のプロダクトです。ご注意ください。

Amazon Dynamo is

Amazonが開発したプロプライエタリな分散型KVS。 Amazonのショッピングカートで使われていた。 100%書き込みに成功することを目標に作られた。 CAP定理でいうとAとPを優先。書き込み時に整合性を取るのではなく、読み出し時にアプリケーション側で整合性を取るモデル。 CassandraやRiakに影響を与えたと言われている。

2.Background

AmazonはもともとRDBを多用していた RDSに可用性の面で満足がいかなくなってきた Amazonで使われるトランザクションの多くはKey Valueで表現できるものだった

2.1 System assumption

Key Valueのモデル
弱い整合性のワークロードがターゲット
効率コモディティハードウェア 99パーセンタイルで300msのレイテンシ → 2007年当時は300msで問題なかった。
その他の前提信頼できるネットワークに配置される。 100ホストのスケータビリティがターゲット

2.2 SLA

99パーセンタイルで300msのレイテンシ。 Amazonの文化として平均や中央値を使わずにパーセンタイルを使う。更に耐久性と一貫性はアプリケーション側で要件に合わせて利用することができることを目指した。

2.3 Design Considerations

楽観的レプリケーション
オプジェクトのバージョンチェック
すべては書き込みを簡素化し、失敗をなくすため！
アプリケーションが読み出し時に整合性チェック？読み込み時のクォーラムを設定できる。アプリに全部データが帰ってきて、アプリが判断する。
Incremental scalability(増分拡張性？) ノードの増加でスケールできる
Symmetry(対称性？) すべてノードは同じ役割を持つ
Decentralization(分散化？) ノード間はフラットなP2Pネットワーク
Heterogeneity(不均一性？) ノードの性能がちがっても問題にならない

3. Related Work

Dynamoは

100%書き込み可能で Key Valueでデータアクセスできればよい

ということで

a zero-hop DHT(Distributed Hash Table) すべてのノードがルーティング情報を持つ

4. Design

Partitioning Consistent Hashing
HA for writes Vector clocks with reconciliation during
Handling temporary failures Sloppy Quorum with hinted had off
Recovering from permanent failures Anti-entropy using Merkle trees
Membership and failure detection Gossip-based membership protocol and failure detection

4.1 System Interface

Interfaceはgetとputの2種類

4.2 Partitioning Algorithm

Virtual Node
すべてのNodeはリング内の1箇所ではなく、複数のポイントにマッピングされる。
Consistent HashingをよりUniformにするための努力

4.3 Replication

レプリケーションファクター「N」、書き込みQuorum「W」、読み出しQuorum「R」
Coordinatorは自分のローカルディスクにデータを書き込み、リングのN-1先のNodeまでデータを転送して、ディスク書き込みを行わせる。
W先のNodeまで書き込みできたらput()は成功を返す
Wの値を大きくするとデータ耐久性は上がるが書き込み成功率が下がる

4.4 Data Versioning

Vector clocks!
Conflictの解消はアプリケーション側で実施。
merge & commit的なことをアプリケーション側でしてやる必要がある。
merge strategyはアプリケーション任せ。

4.6 Handling Failures : Hinted Handoff

リング内のNodeが一時的に書き込み不可の場合、Coordinatorが？別のNodeに書き込み命令を出す。そちらのNodeは本来のテーブル領域とは別のTemporary領域に書いておく。
問題が起きていたNodeが復旧すると、そちらに書き戻す。

4.7 Handling permanent Failures : Replica synchronization

レプリカ間のデータのInconsistencyを極小化し、可能な限りの速度で復旧させるため、Merkle treesを使用している。
各Nodeは自分が担当するキー範囲のtreeを保持する。
同じ範囲を担当するNodeとtreeの比較を行い、Inconsistencyが発見されたら修復を行う。

5. Implementation

ストレージはプラカバルになっており、BDB、MySQL、etcを使用できる。
Frontend/Coordinator event-driven messaging SEDA(Staged Event Driven Application)アーキテクチャ

6. Lessons Learned

今までの内容エッセンスは詰まっているます。 6.1. Balancing Performance and Durability 6.2. Ensuring Uniform Load distribution 6.3. Divergent Versions: When and How Many? 6.4. Client-driven or Server-driven Coordination

Client-driven or Server-driven Coordination

	99.9th percentale read latency (ms)	99.9th percentale write latency (ms)	Average read latency (ms)	Average write latency (ms)
Server-driven	68.9	68.5	3.9	4.02
Client-driven	30.4	30.4	1.55	1.9

とある AWS サービスの運用移管〜データストア編〜

@key_ambさんによるサービスの運用移管についてのお話です。

とある AWS サービスの運用移管〜データストア編〜 #jawsmeguro from YASUTAKE Kiyoshi

iemoについて

iemoは住まいに特化したキュレーションプラットフォーム。スマートフォンからのアクセスが主。 DeNAが2014年10月に買収。

当時のシステム構成

当時の問題点

SPOFが多い
単一AZ構成のコンポーネントが多い
その他 Security Group の設定が甘かったり監視が甘かったり

こんな感じにしました

どう改善したか(まとめ)

SPOFを無くして、かつAZ冗長化した。 Web => Multi-AZ に配置 RDS => Multi-AZ Active-Standby 構成 Redis(ElastiCache) => Multi-AZ Master-Slave 構成 Groonga => 諦めました。ゴメンナサイ Snapshotから速やかに復旧できるようにした

ここからデータストアの話

DB KPI とは？

DB(=MySQL)の性能を測る Key Performance Indicators
Threads_runningを特に重視して、いろいろな値を秒単位で取得し、DBに格納しています。
トラブルシューティングの強い味方

DB KPI in iemo

EC2にMySQLは立てないことにした。
何かあったらログで見られれば十分という判断。

ここからまた別の話

移行時に困ったこと

ElastiCache(Redis)のメモリサイズが不足
困ったこと一度作成したCache Clusterのインスタンスタイプを変更できない異なるインスタンスタイプのノードをレプリケーショングループに加えることもできない

どうやったか

インスタンスタイプを上げた別のCache Clusterを作成し、アプリケーション側で向き先変更
今回はRedis上のデータロストは許容した

そしてGlobal Infraへ

iemo運用移管では、既存の構成にあまり手を加えずに運用を引き取ったが、iemoだけ他のサービスと揃っていないのは運用メンバーに負担がかかるので、構成を揃えていく方針。
Global Infra DeNA の内政フレームワーク各種監視・運用ツールが入ったパッケージオンプレミス、AWS環境に両対応

Amazon Cognito

弊社のsuzuki.ryoがCognitoについてLTをしました。本人が別途記事を書くかもしれないので、あっさりと書きますｗ Cognito Syncについてのユースケースやコスト、他のサービスを活用ひた場合の比較について話していました。

Amazon Auroraのちょっとしたこと

@con_mameさんによるAuroraにLTです。

まず注意から始まります。

Amazon Auroraは現在Preview中のため、頻繁に更新が行われています今回お話する内容は2015/6/26現在の情報をなっている点ご注意下さい

Amazon Aurora

クラウド時代にAmazonが再設計したRDBMS
高いクエリ実行並列度・データサイズが大きい環境で性能を発揮
効果要請・高速なフェイルオーバ・PITRを実現するための多くのチャレンジ Log Stracture Stoage SOA

Service Oriented Architecture

ログとストレージレイヤをシームレースにスケールするストレージサービスに移動
EC2、DynamoDB、SWFなどのAWSサービスを管理コンポーネントに採用
S3を利用して99.999999999%の可用性!でストリーミングバックアップ

レプリケーション

MySQLレプリケーションからの改善点 * Consistency - 異常を修復 * Latency - 同期 vs 非同期レプリケーション * network - I/Oを効率的に行う

Log Structured Storage

追記型のストレージ・システム
シーケンシャルに読み出すことが出来る
常に最新のデータが末尾にある
これらの特徴によりS3への継続的バックアップや高速なリカバリ、書き込み性能の向上を実現

Establishing our ecosystem

MariaDBのVP ProductsのRoger Levyが「MariaDB ｃonnectorsはAuroraとシームレスに動作します」と述べており、数々のプロダクトがAurora Readyを表明しています。

Auroraのパフォーマンスを引き出すために

クエリ並列度が高い、データサイズが大きいケースで効果を発揮
ロック機構やQuery cacheなどに手を入れて性能向上を行っている write heavyな環境ではquery cacheのoffがおすすめ CPUを効率的に利用する改善により、CPU利用率がMySQLと比較して高くなるが、性能が落ちにくくなっている

新しいロックマネージャ

(自分の理解が不足しているので、内容があやふやになります) AuroraではMySQLに比べてロックを行う範囲が広くしていが、ロックの前半がLatch-freeになっておりAtomic lock insertが行える？そうです。ロックマネージャはこちらの論文を参考にしているようです。なお、この論文が基になっていますが仕様そのものではないのでご注意ください

パフォーマンス測ってみる

複数のインスタンスから同時に負荷をかけ並列度を上げる
単一のインスタンスからだけでは、インスタンス毎のNW帯域の制限に達する可能性がある
高負荷環境でもスループット低下を抑える改善が入っているためCPU/メモリ利用率がRDS for MySQLと比較して高くなるケースがある

defaultパラメータの違い

MySQLとAurorではパラメータが異なっている場合があります。 * innodb_change_buffering 今のところ変更負荷 Secondary indexへの更新などにちょっと影響 もちろん報告済

結果

AuroraとMySQL 5.6.23を比較すると、Auroraが5倍スループット出る

よく見ると

Auroraがデッドロックが少し出やすいがリトライを行ってもMySQLよりスループットがでる
CPU / Memoryの使用率がMySQLより高いがスループットが出ている分散ロック機構によりCPUリソースを使い切ってスループットを出している。

何をみるか？

よく聞かれる質問

CPU利用率高いんだけど？
メモリ利用率多いんだけど？
Disk IOが多めなんだけど？

見てほしいこと

Auroraはマシンリソースを最大限利用してスループットを出す設計です
システムトータルでパフォーマンスが向上
管理コスト、障害耐性、データ保全性

まとめ

AuroraはMySQL互換ですが、マシンリソースの使い方が根本的に違います
Auroraが得意な場面・状況を理解してパフォーマンスを測定マシンリソースを使い切りそうになりながらもMySQLと比べるとスループットやレスポンスタイムの落ち方が緩やか
何かあったらご連絡ください！(by @con_mame)