Sansanにおけるインフラから見たRDBMSの運用/Operation of RDBMS as seen from infrastructure in Sansan

Transcript

1. Sansanにおけるインフラから⾒た RDBMSの運⽤

2. 岩下 訓 (Satoshi Iwashita) ೥ʹ4BOTBOʹ+PJO ࣾ಺Πϯϑϥͱͷ݉຿Λܦͯ4BOTBOαʔϏεͷΠϯϑϥ୲౰ͱͯ͠ैࣄ ޷͖ͳݴޠ͸1ZUIPO ޷͖ͳ"84αʔϏε͸3PVUF  झຯ͸%5.ͱϩʔυόΠΫ

   Sansan事業部プロダクト開発部 インフラチーム

3. Sansan Builders Box 突然ですが RDBMSは何を使ってますか？

4. Sansan Builders Box Sansanにおけるデータストア - サービスのメインDB - フィードのためのDB - キャッシュ

   - 画像ストレージ - ログ分析、KPI、監視などの運⽤⽬的

5. Sansan Builders Box Sansanにおけるデータストア Web/API Main DB Massaging/Batch Custmers Dev/Ops

   Analyst Web Sales/Front Zabbix/grafana kibana

6. Sansan Builders Box Agenda - SansanのDBの特徴 - PostgreSQLの活⽤ - 運⽤まわりで活⽤しているもろもろ

7. SansanのDBの特徴

8. Sansan Builders Box SansanのDBの特徴 - .NET なのに PostgreSQL (元々はOracleだった) -

   全てオンメモリ - ⽔平分散 - HINT句を駆使 - 32KBのブロックサイズ - LDAPによるユーザー認証

9. Sansan Builders Box なぜオンメモリなのか - オンプレ時代の2011年頃、ioDriveを導⼊ - ioDriveの温度が⾼まる > 76℃を超えるとパフォーマンス劣化

   > 85℃を超えるとシャットダウン - 運⽤負荷の増⼤、事業へのインパクト - データを分割してパフォーマンス改善を図ることに

10. Sansan Builders Box ⽔平分散 - 巨⼤化してきたデータを分割することによる性能向上が⽬的 - 採⽤したアーキテクチャ > クライアント:

    テナントIDを管理する共通DBに問い合わせ > 共通DB: テナントのデータが格納されているノードの場所を教える > クライアント: 該当ノードに接続 - ⽔平分散により1ノードのデータ量が減る > ioDrive で⽴ち⾏かないのであればオンメモリ化しかないのでは？？

11. Sansan Builders Box AWS移⾏ - 同時期はAWS移⾏の真っ只中 > 既にフロントはAWSで稼働 > DB接続はサイト間VPNでしのいでいた

    > VPNは安定しているとは⾔えず、細かいエラーが⽇常的に発⽣ - この頃に r3 インスタンスが登場 > ⼤容量メモリに全てのデータを乗せることができそう

12. Sansan Builders Box オンメモリ化 - PostgreSQLはOSのファイルキャッシュを信頼する - 全てのデータをファイルキャッシュに > find

    $PG_DATA/base -type f –exec cat {} + > /dev/null 2>&1 - オンメモリ化でとにかく参照系が⾼速化した - そして引くほど⾼コスト(⾦の弾丸)

13. Sansan Builders Box オンメモリ化が進み - スケールに課題 > スケールアウト(データの分割)は運⽤負荷が⾼い > スケールの際に⻑時間メンテナンスをせざるを得ない

    > 多ノード構成もなかなかしんどい • r3.8xlarge * 11(nodes) * 2(hotstandby) > そしてデータの総量が3TBを超えてきた頃に。。。。。。。

14. Sansan Builders Box X1インスタンスの登場 - 244GB → 2TB までメモリがスケールアップできる -

    歓喜 - 運⽤負荷の低減を⽬的に即座にスケールイン判断

15. Sansan Builders Box スケールイン - 各DBクラスタをX1インスタンスにコピー > pg_basebackupが活躍 - ポートをわけてそのまま起動

    - ⾒たことのないDBインスタンスが誕⽣

16. Sansan Builders Box スケールイン - 各DBクラスタをX1インスタンスにコピー > pg_basebackupが活躍 - ポートをわけてそのまま起動

    - ⾒たことのないDBインスタンスが誕⽣

17. Sansan Builders Box X1インスタンスを運⽤してみて - スケールアウトの頻度が下がった > 3ヶ⽉に1回 → 2年に1回

    - Reserved Instanceを購⼊する⼿が震える - 構成変更などで新規X1を構築する時に insufficient capacity > 時間的余裕をもった構築をオススメします

18. PostgreSQLの活⽤

19. Sansan Builders Box 活⽤しているPostgreSQLの機能など - Streaming Replication - Parallel Sequential

    Scan - pg_hint_plan - 32KB Block Size - LDAP

20. Sansan Builders Box Streaming Replication - かつては slony-I でレプリケーション >

    難解で、DDLの反映にも癖があり、とてもつらかった - 9系からPostgreSQL本体の機能でレプリケーション可能になった > ⾮同期レプリケーションとして利⽤ > 設定が簡単、全てのDDLが(ほぼリアルタイムで)複製される > pg_basebackupによって物理的に同じDBを複製できるという安⼼感 > ただし物理ログシッピングのため、NW転送が侮れない

21. Sansan Builders Box Parallel Sequential Scan - Sequential Scanを並列化してくれる -

    9.6 から - Seq Scan をせざるを得ない⼀部機能に多⼤な恩恵 > 3.25倍も⾼速化した機能があった - 並列スキャンのためのプロセスが⽣成される > CPUの性能、コア数と要相談

22. Sansan Builders Box pg_hint_plan - HINT句によって実⾏計画を制御するExtention > https://www.sraoss.co.jp/technology/postgresql/3rdparty/pg_hint_plan.php - Sansanでは多くの機能で活⽤

    > テナントごとに異なるデータ量の増加に伴い、意図しない実⾏計画となることが > 数百倍の速度改善など、⽬覚ましい効果を発揮することも > ヒント句は⿇薬ではないかと揶揄されることも > ⽤法、⽤量を守って正しくお使いください > Pg10からの拡張統計情報に期待

23. Sansan Builders Box Block Sizeの拡張 - 名刺情報の1レコードが⼤きいことも性能上の原因の1つでは？ > Toastの肥⼤化も顕著となっていた -

    Block Sizeを拡張し、オーバーヘッドをなくす取り組みを実施 > http://pgsqldeepdive.blogspot.com/2012/12/ssdpostgresql.html > 実際に検索において(劇的ではないものの)性能の向上が⾒られた - なお、RDSではBlock Sizeは変更不可なので将来的に不安あり > 不要なカラムがあれば削除するなど鋭意対応中

24. Sansan Builders Box LDAP認証 - 調査などで本番DBを⾒たいことはやっぱりある - マイグレーションも開発チームでよしなに実施してほしい - だからこそアカウンティングはしっかりしたい(共有IDはNG)

    - 本番環境に独⽴したActive Directoryを構築し、利⽤することに - LDAPでユーザー認証して共有IDを廃⽌ > 実はこれがRDSを使っていない最も⼤きい理由 > ただし、最近Aurora PostgresqlでIAM認証がサポートされたので移⾏する機運UP！

25. DB運⽤まわりで活⽤しているもろもろ

26. Sansan Builders Box コンテンツ - 冗⻑化 - バックアップ - ログ管理

27. Sansan Builders Box 冗⻑化 - Pacemaker + Corosync > DBノードの冗⻑化(Active/Standby)

    > VIP、pgpool-IIのリソース管理 > pingdによるNW監視でスプリットブレイン対策 - pgpool-II > ⾃動フェイルオーバー > コネクションプーリング(冗⻑化とは無関係)

28. Sansan Builders Box 冗⻑化 - Pacemaker + Corosync > DBノードの冗⻑化(Active/Standby)

    > VIP、pgpool-IIのリソース管理 > pingdによるNW監視でスプリットブレイン対策 - pgpool-II > ⾃動フェイルオーバー > コネクションプーリング(冗⻑化とは無関係)

29. Sansan Builders Box VIP - VPC の Route Table 書き換え⽅式

    > サーバー側でIPエイリアスを作成し、仮想IPアドレスのようなものを設定 • 実IPアドレス eth0 -> 10.0.0.1/32 • 仮想IPアドレス eth0:0 -> 172.255.255.1/32 > Route Table で仮想IPアドレスとEC2 (ENI)をマッピング > Pacemakerでリソース移動が発⽣した際によしなに書き換える • Boto3 を駆使したスクリプトで⾃動化

30. Sansan Builders Box スプリットブレイン対策 - 両系のDBがActiveとして起動しないようにする対策 > データ不整合を防ぐ対策 - それぞれから⾃サブネット外の複数箇所にping

    (default_ping_set) - 全ての監視対象へのpingが失敗したらスイッチオーバー実施 - スイッチオーバー後、⼀定期間ACTのDBに接続できなくなったらフェイルオーバー実⾏ - 最悪、両系がACTになったことを検知したら、両⽅共にDownする > multiple-active=block

31. Sansan Builders Box スプリットブレイン対策 pgpool-II VIP PostgreSQL ping PostgreSQL ping

    pgpool-II VIP promote

32. Sansan Builders Box バックアップ - EBSスナップショット > EBSスナップショットは⽇次で取得 > 取得も世代管理も⾃前のスクリプトで⾃動化

    - WAL(トランザクションログ)アーカイブ > PITRが⽬的 > 実際に問題が発⽣した際には⾮常に強⼒ > PITRは⼿順化し、定期的にテストしておくとよいでしょう > ⾃作スクリプトで随時S3へアーカイブ

33. Sansan Builders Box リストア - > όοΫΞοϓΛ͍ͨ͠ਓ͸͍ͳ͍ɺຊ౰ʹٻΊΒΕ͍ͯΔͷ͸ϦετΞͰ͋Δ > SRE本 26.1.2

    - ⽇次でリストアをテスト > SnapshotからEBSを作成 > 普段寝かせているリストアインスタンスにアタッチして起動 > リストアをチェックするスクリプトが⾃動実⾏ > 簡単なクエリを叩いてリストアの成否を判別 > バックアップからの⼀連の流れをshellscript & pythonで⾃動化

34. Sansan Builders Box ログ管理 - CSVログ + Fluentd + Elasticsearch

    + Kibana で可視化 > SlowestやMost ConsumingなどをDBクラスターごとに集計 > アプリ側でapplication_nameを指定してもらうと、集計に便利なのでオススメです > ログイン失敗や誰が接続したかなどのセキュリティに関するログもダッシュボード化 - fluent-plugin-slack > アプリケーション利⽤以外のロールから実⾏されたクエリをリアルタイムで通知 > 監査と悪意の抑⽌が⽬的

35. 今後の展望

36. Sansan Builders Box 今後の展望 - まだしばらくはPostgreSQLを使いそう > Table Partitioning >

    拡張統計情報への期待 > Pg11のParallel Joinに期待 > ロジカルレプリケーション - Aurora PostgreSQL > IAM 認証ができるようになったのはとても⼤きい

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

38. None