Sharding with sql alchemy

© 2017 e-Seikatsu Co., Ltd.
Sharding
with
SQLAlchemy
松崎明 (Akira Matsuzaki / @akipom)

自己紹介
松崎明
CTO / 常務取締役 @
Python 歴 7年 (その前はJava 10年ぐらい)
DB/インフラ周りも一通り行ける (15年ぐらいやってます)
フロントエンドは最近弄ってない (ここ6年ぐらい)
旨い酒と美味い飯が大好物
ちなみにCTO歴は11年ぐらい (プログラマ歴は25年ぐらい)
基本的にLinuxデスクトップでお仕事 (Linux大好き)
最近はGo弄ってることもある (でも今日は喋りません)

© 2017 e-Seikatsu Co., Ltd.© 2017 e-Seikatsu Co., Ltd.
マルチテナント型サービスの悩み
まずは課題から

マルチテナント型サービス運用の悩み
マルチテナント
=
複数ユーザ(企業)が同居
=
B2B(企業向け)サービスだとありがち

企業A
企業B
企業C 利用者が少ない頃はそうでもないが

サービスが成長してくると
どうスケールアウトするかが重要に

どこがスケールアウトしにくいか
• 全ユーザで共通
• ノード数/ホスト数で
スケールアウトしやすい
アプリケーションデータベース (RDBMS)
• ユーザ毎に情報が違う
• ノード数/ホスト数で
スケールアウトしにくい
• 特に書き込み系がツラい

DBのスケールアウトしづらい側面
• 左図は典型的なDB構成
• 読み込み系は、スレーブを増やすことで、
ある程度スケールアウトできる
• 書き込み系は、マスターに集中するので、
スケールアウトしづらい
• 書き込み系処理が増えると、必然的に
レプリケーション量も増える
write
App
read
replication
Slaves
Master
Hot Stand-by
replication

ユーザ毎に全部割る
• メリット
– シンプル
– アプリ側は考えること少ない
– 障害発生時の影響が限定的
• デメリット
– アプリのデプロイ大変
– 自動化頑張る必要性
– 監視対象多くて死ねる
– リソース効率は良くないかも

DBだけインスタンスごと割る
• メリット
– アプリは共通、データは固有を
そのまま体現
– DBスケールアウトしにくい問題は解決
– アプリ側のリソース効率は悪くない
• デメリット
– アプリ-DB間の接続数ヤバい
– 何かと運用が面倒なDBの数が多い

スキーマだけ割る
• メリット
– アプリは共通、データは固有を
一応体現
– アプリ側のリソース効率は悪くない
• デメリット
– DBスケールアウト問題が未解決

3パターン合わせ技
• 銀の弾丸はない
• ユーザ毎のスキーマを複数まとめて
DBインスタンスに格納
• アプリ側もいくつかの塊にクラスタ化
• データ量やスループットを見ながら
調整しつつ運用

前説が長くなりましたが
これをでどう扱うのか？
が
このトークのテーマです

SQLAlchemy概要
SQLAlchemyの簡単な紹介と前提知識の準備

そもそも ORM って何？
ORM = Object-relational Mapping (Mapper)
book_id
1
2
3
title
AAA
BBB
CCC
author_id
1
2
3
publisher_id
1
2
3
num_pages
120
300
280
birth_date
1963-03-05
1982-11-21
1975-09-28
author_id
1
2
3
name
著者太郎
本花子
John Doe
publisher_id
1
2
3
name
XX出版
YY社
ZZ Publishing
class Book(object):
title = None
num_pages = 0
__author_id = None
__publisher_id = None
@classmethod
def get_by_id(self, id):
…
return book
@property
def author(self):
return Author.get_by_id(
self.__author_id)
@property
def publisher(self):
return Publisher.get_by_id(
self.__publisher_id)
class Author(object):
name = None
birth_date = None
gender = GENDER_UNKNOWN
@classmethod
…
return author
class Publisher(object):
name = None
@classmethod
…
return publisher
オブジェクト指向的な世界リレーショナルDBな世界

Python の ORM
SQLAlchemy
django ORM
peewee
Pony
単体のORMとしては最も有名
Django のビルトインORM
シンプルで軽量さが売りのORM
generator式や lambda でクエリが
書ける Pythonic なORM
今現在、アクティブに開発が続けられているORMは少ない

SQLAlchemy の構成
SQLAlchemy ORM SQLAlchemy Core
SQL文、DB接続、トランザクション管理等、
RDBMSをそのまま扱うための機能群を提供。
DBのリレーショナルモデルをそのまま扱う
スキーマ指向のモジュール群。
DBに格納されたデータを Python の
オブジェクトとして自然に扱うための
機能を提供。
ドメインモデル指向のモジュール群で、
一般的にはこちらを使う。
内部的には Core で提供される機能を使って
いる。

2種のマッピング
Classical Mapping
Python オブジェクト(を表すクラス)と
Table を表すクラスを別個に定義し、
この2つを紐づける(マッピングする)方法。
古いバージョンからある方法だが、今でも利
用可能。
Declarative Mapping
1つのクラス定義で、テーブル定義と
マッピングを同時にやる方法。
バージョン 0.6 あたりから導入され、現在で
はこちらが推奨されている。
Table を表すクラスは自動生成される。

Autoload
Autoload しない
Python のクラス内で DBのカラムや、
テーブル間のリレーションを定義し、
それのみを用いる方法。
SQLAlchemy から DBのスキーマを作成する
こともできるが、標準機能では ALTER
TABLEはできない。
ALTERを行うためには、Alembic や
SQLAlchemy-Migrate のような補助ツールを
使う必要がある。
SQLAlchemy と DBのスキーマ定義がずれる
と、色々問題が発生したりする。
Autoload する
DBのスキーマ定義に基づいて、
カラム定義を自動でロードする方法。
Classical Mapping を使用する場合には、
テーブル間のリレーションは手動定義の必要
あり。
Declarative Mapping を使用する場合には、
0.9.1から導入された Automap Base を使うこ
とで、リレーションも推定してくれるように
なった。(明示的に指定することも可能)
動的型付け言語だからこそできる芸当。

Table と Mapped Objectの関係
<<instance>>
Metadata
<<instance>>
Table
<<class>>
Table
インスタンス化
<<class>>
Mapped
Class
<<instance>>
Mapped
Class
インスタンス化
マッピング
集約
Table インスタンスと
Python クラス定義が
マッピングされている
スキーマ情報の
コレクション

Session, Engine, Pool, Dialect, Connection
Session
Mapped
Object
オブジェクトの
ライフサイクル管理
トランザクション管理
Mapped
Object
ユーザが扱う
データモデル
Engine
Engine
接続先のDBの表現
DBの接続URL
接続パラメータ
…etc
Pool
Dialect
DB
Connection
Connection
Pool
Dialect
DB
Connection
Connection
DBMSの種類の表現
MySQL, PostgreSQL, Oracle …
物理接続
接続の管理

コードサンプル
from sqlalchemy imoport create_engine
from sqlalchemy.orm import Session
from sqlalchemy.ext.auto_map import automap_base
# Mapped Class のベースクラスを作成
Base = automap_base()
# Engine を定義
engine = create_engine(‘mysql+pymysql://user:password@host_name:3306/?charset=utf8mb4’)
# Table と Mapped Class を生成
Base.prepare(engine, reflect=True)
# 生成されたMapped Class はテーブル名と同じになっているので、モジュールレベルの変数に格納
Book = Base.classes.book
Author = Base.classes.author
Publisher = Base.classes.publisher
# 単一のEngine から Session を作成
session = Session(engine)
# データのロード(先頭の100行)
for book in session.query(Book).order_by(Book.book_id)[:100]:
print(book.title)
# 新規Bookインスタンスの作成
new_author = Author(name=“foo”)
new_publisher = Publisher(name=“bar”)
new_book = Book(title=“Foo Bar”, author=new_author, publisher=new_publisher)
# Sessionへ追加・コミット
session.add(new_book)
Session.commit()

Shardingへの対応方法
ようやく役者が出そろったので

実現したいこと
Master/Slave パターンへの対応
書き込み系はMasterへ、参照系はSlaveへ自動振り分けしたい
Sharding パターンへの対応
ユーザ情報などに基づいて、接続先DBやスキーマを自動振り分けしたい
整理すると何らかのコンテキスト情報に基づいて
単一の Session 内で Engine を切り替えたいだけ

Session 内で Engine 切り替え
Session
Mapped
Object
Mapped
Object
ユーザが扱う
データモデル
Engine
Engine
DBの接続URL
…etc
Pool
Dialect
DB
Connection
Connection
Pool
Dialect
DB
Connection
Connection
物理接続
接続の管理
つまりここ

実は SQLAlchemy で用意されてます
https://github.com/zzzeek/sqlalchemy/blob/rel_1_1/lib/sqlalchemy/ext/horizontal_shard.py
ソース
https://docs.sqlalchemy.org/en/latest/_modules/examples/sharding/attribute_shard.html
サンプルコード
※ 「SQLAlchemy Sharding」でググれば出てきます
「書き込み系はMasterへ、参照系はSlaveへ自動振り分けしたい」
ただし下記の機能がない

公式の ShardedSession のポイント
Engine の選択で重要なのは Session.get_bind()

実際にやること
1. カスタムSessionクラスを作る
ShardedSession のサブクラスでもいいし、Session のサブクラスでもいい
2. 書き込み系の処理中かどうかを表すSessionの内部変数を作る
一度でも書き込み系の処理が走ったら、commit() または rollback() が
呼ばれるまでは、master を参照するようにする。(一貫性保証のため)
3. get_bind() をオーバーライドする
詳細は次ページで。

get_bind() のオーバーライド内容
1. clause 引数が渡された場合
sqlalchemy.sql.expression.UpdateBase のインスタンスかどうかで
更新系SQLかどうか判断できる。
であれば、内部変数を「更新中」とマークする。
isinstance(clause, UpdateBase) is True
2. mapper 引数が渡された場合
ORM系の更新処理の場合、Session._flushing 変数が True になる。
https://github.com/zzzeek/sqlalchemy/blob/rel_1_1/lib/sqlalchemy/orm/session.py#L733
この値を評価して、内部変数を「更新中」とマークするか判断する
3. Engineを選択する
内部変数が「更新中」なら、master を指す Engine を、
そうでなければ、slave を指す Engine からラウンドロビンやランダムで選択

注意点
Engine のメモリフットプリントが意外と大きい
それは
この方法には大きな落とし穴があります
Engine は一度生成されると、インタプリタが終了するまで消えない
かつ
という点です
(CPython で実測15MB程度食います)
Shard が多数、あるいは Slave多数だと
メモリが足りなくなります

単一DBインスタンスに複数スキーマの場合
最初の方で触れた
単一DBインスタンスに複数スキーマ
の場合では、
もう一つ別のアプローチが取れます

SQLAlchemy イベントリスナ
https://docs.sqlalchemy.org/en/latest/core/events.html

Poolからのチェックアウト時にスキーマ切替
Session
Mapped
Object
Mapped
Object
ユーザが扱う
データモデル
Engine
Engine
DBの接続URL
…etc
Pool
Dialect
DB
Connection
Connection
Pool
Dialect
DB
Connection
Connection
物理接続
接続の管理
今度はここ

実際にやること
1. イベントハンドラの関数を作る
Schema選択アルゴリズムは、Shard 選択と同様の感じで。
ただし引数で、Mapped Object や Clause は渡されないため、
呼び出しタイミングは、get_bind() より後であることを利用して、
Threadlocalな変数に、選択したスキーマ情報を載せておく形になります。
また、スキーマの変更SQLはRDBMS固有のため、RDBMS毎に関数を用意する必要があります
2. Engine初期化後にイベントハンドラを登録する
sqlalchemy.event.listen(engine, ‘checkout’, handler_func)
または
@sqlalchemy.event.listen_for(engine, ‘checkout’)
デコレータで登録できます。

まとめ

1. カスタム Session クラスを用意すれば、DB接続周りで色々できる
2. イベントリスナーを有効活用しよう
Sharding 対応や Master/Slave対応など、そこまで難しい実装はいらない
今回紹介したイベント以外も色々あるので、うまく活用すれば色々できる
3. とはいえ銀の弾丸はない
リソースは常に有限なので、無限にスケールできる単一のソリューションはない
全体のアーキテクチャバランスを取りながら、複数の手法を組み合わせよう

ご清聴ありがとうございました

やるなら
この後ジョブフェアでLTします

Sharding with sql alchemy

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Sharding with sql alchemy

Ähnlich wie Sharding with sql alchemy (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

Sharding with sql alchemy