PostgreSQLプラットフォームの徹底比較（コンテナからクラウドまで）

2020/11/13のPostgreSQL Conference Japan 2020、チュートリアルセッション用のスライドです。

Transcript

1. PostgreSQLの
   プラットフォーム徹底比較！
   ～ クラウドからコンテナまで ～
   PostgreSQL Conference Japan 2020 , 11/13
   Takahiro, Kobayashi
   ( @tzkb)
   

   View Slide

2. 2
   最近やっていること
   • PGConf.Asia 2019
   “Building PostgreSQL as a Service
   with Kubernetes”
   • July Tech Festa 2020
   “マイクロサービスの今こそ！
   理解して拡げる分散システムの基礎知識”
   ＋ ＝∞
   

   View Slide

3. 3
   1. あなたのDBはどこに？
   2. まずはここから、RDS for PostgreSQL
   3. そしてAuroraの世界へ
   4. PostgreSQL on Kubernetesという選択肢
   5. ちょっと変わった マネージド の世界
   アジェンダ
   

   View Slide

4. 4
   あなたのDBはどこに？
   1
   

   View Slide

5. 5
   PostgreSQLプラットフォームを整理してみると
   • 現在はオンプレミスからクラウド(マネージドサービス含む)、
   コンテナまで様々な環境でPostgreSQLが稼働する。
   ベアメタル EC2
   ホスト
   コンテナ
   ランタイム
   オーケスト
   レーション
   IaaS
   マネージドサービス
   (DBaaS)
   Kubernetes
   Service
   オンプレミス
   Kubernetes
   EKS
   Amazon Aurora
   Amazon RDS
   本日の対象
   

   View Slide

6. 6
   ポスグレのプラットフォームは？ @PostgreSQLアンカンファレンス 2020
   • オンプレが健在（回答者に若干の偏りあり）。
   • VMベースが多いけど、ベアメタルとクラウド同数ぐらい？
   • サービス別ではAmazon RDSが抜けているが、Auroraも多い。
   

   View Slide

7. 7
   マネージドなデータベースを使うのはなぜ？
   （建前）
   • ベストプラクティスでしょ？
   • 構築もらっくらく。
   • 運用もほぼ自動。
   （本音）
   • インストールとか面倒。
   • 開発が本業。DBAいない。
   • おれたちは雰囲気でDBやってる。
   DB
   

   View Slide

8. 8
    パブリッククラウドで PostgreSQLを使う際の選択肢、
   どれぐらい知っていますか。
    RDS、Auroraなど各サービスの特徴を理解しましょう。
    昨今のクラウド上ではコンテナ、 Kubernetesを前提と
   したサービスも出てきています。
    それらの仕組みは理解して、これからのビジネスに最適な
   PostgreSQLプラットフォームを一緒に考えましょう。
   本日のゴール
   

   View Slide

9. 9
   まずはここから、RDS for PostgreSQL
   2
   

   View Slide

10. 10
    (今更ですが) Amazon RDS for PostgreSQLとは
    • AWSが運用してくれる PostgreSQL。
    • コミュニティで開発されているピュアPostgreSQLで、これまで
    自身のサーバにインストールしていたものと、同じものが使える
    （但し一部の拡張は使えない）。
    • インフラ構築不要、インストールも不要で使い始められる。
    • バックアップ・リストアも簡単。
    • Multi-AZで高可用性を担保、リードレプリカも構築できる。
    • 各種メトリクスもAWSコンソールから確認可能。
    

    View Slide

11. 11
    RDS for PostgreSQLがもたらす効果
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    オンプレミス Amazon RDS
    ユーザ
    による管理 による管理
    

    View Slide

12. 12
    RDS for PostgreSQLで制限されること
    制限事項（例） 具体的な例
    バージョン選択 現在の最新は12.4（13はBeta）、但し利用可能Verは多数。
    リソース上限 r5.24xl(96vCPU、768GBメモリ)、ストレージは最大64TB
    リソース下限 t3.mic(2vCPU、1GBメモリ)
    一部パラメータが変更不可 full_page_writesなど一部のパラメータは変更できない
    Extensionが限られる pg_hint_planなど一部はインストール可、全てではない。
    OSログインできない ssh接続によるOSログインはできない。
    • 通常のPostgreSQLと比較すると下記のような制限がある。
    

    View Slide

13. 13
    どんな時に使うのか？ RDS for PostgreSQL
    • 使わない理由がない。
    • AWSでPostgreSQLを使うなら、
    特定バージョンや特殊なエクステンションが必要な時を除き、
    いつでも。
    • これまでの運用・チューニングスキルがそのまま活かせるのも
    ポイント。
     例：Autovacuum関連のパラメータ設定等は基本的に流用可能で、
    ワークロードに最適されたPostgreSQLを利用できる。
    

    View Slide

14. 14
    そしてAuroraの世界へ
    3
    

    View Slide

15. 15
    Amazon Auroraとは
    • クラウド向けに構築された、PostgreSQL互換のDBMS。
    • つまり、ピュアなPostgreSQLではない。
    • 商用DBと同等のパフォーマンスと可用性を1/10のコストで実現
    することを目標としている。
    • Multi-AZよりも高い3-AZの可用性を実現。
    • 高い性能(PostgreSQL互換では3倍とも)と拡張性。
    • エンタープライズのニーズに応える各種サービスを展開。
     Aurora Serverless
     Global Database
     マルチマスタークラスタ
    

    View Slide

16. 16
    Auroraのコンセプト 「THE LOG IS THE DATABASE.」
    Compute
    SQL
    Transactions
    Caching
    • ComputeとStorageにDBを分離。ログをStorageに送信する。
    • 3つのAZに展開した分散ストレージ
    にデータを格納する形式。
    ※実際は6つのコピー
    • Compute側からはログを送信し、
    それらの永続化(タイミング含め)は
    ストレージに一任される。
    • レプリカノードへのデータ更新は
    キャッシュ同期で行う。
    Compute
    SQL
    Transactions
    Caching
    Storage
    Logging
    Storage
    Logging
    Storage
    Logging
    P R
    

    View Slide

17. 17
    Amazon Aurora PostgreSQL Compatibleで制限されること
    制限事項（例） 具体的な例
    バージョン選択 現在の最新は11.8互換のVer3.3、選択可能Verは少ない
    リソース上限 r5.24xl(96vCPU、768GBメモリ)、ストレージは最大128TB
    リソース下限 t3.med(2vCPU、4GBメモリ)
    一部パラメータが変更不可 checkpointなどアーキテクチャが異なり、それらは利用不可
    Extensionが限られる pg_hint_planなど一部はインストール可、全てではない。
    I/O料金の存在 データ保持量(GB単位)とI/O料金(リクエスト辺り)の課金
    • RDS以上にAuroraでは制約も大きい。
    

    View Slide

18. 18
    たくさんのAuroraファミリー
    Auroraの各種サービス 特徴
    Aurora PostgreSQL
    互換エディション
    3つのAZに跨る6つのレプリカを保持し、高い可用性を持つ。
    AWSに最適化された構成で約3倍と言われる高い性能。
    ※他と区別するために、Aurora Provisioned Clusterとも。
    Aurora Serverless アプリケーションのワークロードに応じて、DBクラスタを自動的
    に起動・停止し、スケールアップ/ダウンを行う。
    Global Database 複数のAWSリージョンに跨ってレプリカを構築可能。リージョン
    障害時には切り替えることでDR対応ができる。
    マルチマスタークラスタ 2つのプライマリインスタンスを構成可能、ダウンタイムをより短
    縮できる。 ※PostgreSQLでは未対応
    • 一言でAuroraといっても、、、使い分けられますか？
    

    View Slide

19. 19
    Amazon Aurora Serverlessとは
    Compute
    Storage Storage Storage
    • リクエストベースでインスタンスを起動、無風時は停止も可能。
    • つまり、ゼロスケールが可能なDBクラスタと言える。
    Request Router
    VPC
    Endpoints
    NLB
    • オンデマンドにCompute(インスタンス)
    は起動され、利用していない時は
    停止される。
    • 停止時はストレージ料金のみ。
    • 基本的には特定AZのComputeが
    スケールアップ/ダウンする。
    • 障害時は別AZでComputeを起動
    するが、FO時間は未定義。
    

    View Slide

20. 20
    Aurora Serverlessの注意点
    • 柔軟性は理想的にも見えるが、通常のAuroraとは大きく異なる。
    • AWSでは次のようなユースケースを想定。
     利用頻度が少なく、不定期なワークロード
     負荷が予測できないワークロード
     開発やテスト環境として
    • PostgreSQLバージョンは、10.7のみ。
    • 通常のAuroraで使える拡張・AWSサービスも使えない。
     postgres_fdw
     Performance Insightなど
    そもそもAuroraを使うべき？
    

    View Slide

21. 21
    Amazon Aurora Global Databaseとは
    R P R
    • Region(地域)を跨いで、Auroraのレプリケーションが可能。
    • Region障害があった際に、もう一方でサービスを継続できる。
    Primary Region Secondary Region
    • DBMSレベルではなく、
    ストレージレベルのレ
    プリケーション。
    • レプリケーションのレ
    イテンシは低く保たれ、
    通常1分以内でFOが
    可能とされている。
    

    View Slide

22. 22
    どんな時に使うのか？ Amazon Aurora
    • より高い可用性、性能を求める時（＞コスト）。
    • Oracle(そしてExadata)などの商用の高性能・高可用性DBからの
    移植に向いている。
    • Oracle Data Guard等のソリューションを使っていた場合にも。
    • ピュアPostgreSQLでない点には注意。
    • 「クエリ実行計画の管理」など、Aurora独自機能の理解や使い方
    を理解する必要あり。
    • 運用やコストの考え方で、Aurora固有の考慮ポイントが出てくる
    ため、それらに習熟する必要がある。
    

    View Slide

23. 23
    PostgreSQL on Kubernetesという選択肢
    4
    

    View Slide

24. 24
    PostgreSQL on Kubernetesとは
    • コンテナ向けプラットフォーム(オーケストレータ)である、
    Kubernetes上でPostgreSQLを稼働させる構成。
    • (コンテナイメージがあれば) どのバージョンのPostgreSQLも
    利用できる。拡張も自由に組込み可能。
    • IaCとの相性が良く、宣言的にPostgreSQLの実行できます。
    • お手持ちのKubernetesで（ ）、すぐにお試し可能です。
    え、Kubernetesって？？
    

    View Slide

25. 25
    PostgreSQL on Kubernetesが出来ること
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    on
    K8sクラスタ
    による管理
    バージョン選択 任意のバージョンを選べる
    リソース上限 Nodeのキャパシティ次第
    リソース下限 CPUはmill core単位で指定可
    パラメータ 全て変更可能
    Extension 全て導入可能
    OSログイン 可能（任意のユーザ作成も可）
    

    View Slide

26. 26
    マネージドPostgreSQLと比較して
    • マネージドは便利だが、全工程で最適とは限らない。
    特徴 • 開発者向け
    • 1人で1DBが理想
    • ユーザ/内部テスト
    • リリース確認用
    • 本番サービス用
    マネージド
    向き？
    • No.
    • スキーマも辛いが1人
    1インスタンスも辛い
    • Yes.
    • インスタンスが増え
    ていくことも。
    • Yes.
    • 可用性も担保できる
    開発環境 テスト/ステージング 本番環境
    

    View Slide

27. 27
    例えば、開発環境では
    • DB作成をオンデマンドに、開発者自身が行える。
    apiVersion: v1
    kind: Pod
    metadata:
    name: postgres-tzkb
    spec:
    containers:
    - name: postgres12-1
    image: postgres:12.1
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1024Mi
    volumeMounts:
    - name: pg-vol
    mountPath: /var/lib/postgresql/data
    

    View Slide

28. 28
    テスト環境も柔軟に拡張できる
    Kubernetesの仕組みを使って、
    アプリケーションとDBのデプ
    ロイメントをまとめて、宣言的
    に行える。
    (DB利用で頻出の専門用語)
    • StatefulSet（sts）
    – 安定的なストレージ利用、一
    意なホスト名などデータベー
    スでの利用に向いている。
    • Persistent Volume（PV）
    – PV/PVC/StorageClassを用い
    て、データを永続化。
    AP
    AP
    AP
    連結テスト ユーザ確認
    PV
    AP
    AP
    AP
    PVC
    PVC
    PVC
    PVC
    PV
    PV
    PV
    

    View Slide

29. 29
    本番環境では、Operatorがベストプラクティス
    operator
    pgcluster pgbackups
    pgreplicas
    S3等にバックアップが可能
    AZ-a AZ-b AZ-c • 左図はCrunchy Dataの
    PostgreSQL Operatorの概要。
    • Streaming Replicationの構成
    を自動的に行う。
    • 高可用性を備えたクラスタが
    深い知識無しで構築可能。
    • AWS上で適切な設計を行えば、
    Multi-AZ対応も可能。
    • バックアップなども実行可能、
    DBAの負荷を軽減できる。
    R
    P R
    

    View Slide

30. 30
    PostgreSQL Operatorの例
    • Crunchy Data以外にもPostgreSQL Operatorが存在。
    開発元 Operatorの特徴
    Crunchy Data
    早くからPostgreSQLのKubernetes対応を打ち出し、Operatorも順調に進化
    している。PostgreSQLコミュニティでの存在感も強く、関連エコシステムと
    の統合(pgAdmin、pgBackRest等)も得意。
    Zalando
    Kubernetesを早くから商用サービスで運用しており、実績が豊富。Operator
    も同社で大規模に利用されており、2年以上の運用実績を持つ。Kubernetes
    コミュニティでの発言力も高い。
    EDB
    PostgreSQLの機能強化版 EDB Postgresを提供、更にそれをKubernetes上
    で稼働させるEDB Kubernetes Operatorが開発されている。利用実績は海外
    を含めて、まだ多いとは言えない模様。
    KubeDB AppCodeが開発しているマルチDBMSなOperator。ただし、最近の開発
    スピードに疑問が残る（止まっている？）。
    

    View Slide

31. 31
    どんな時に使うのか？ PostgreSQL on Kubernetes
    • アプリケーションをKubernetesで動かしている時。
    • マネージドサービスより柔軟なリソース配分を行いたい時。
    • マイクロサービスと組み合わせるケース。大量に乱立する
    インスタンスの管理コストを下げる可能性を秘めている。
    • 開発・テスト環境でのコンテナDB利用は加速すると思われる。
    • なお、Kubernetes自体の管理はDBに限らず、大きな課題。
    • EKSなどのマネージドなKubernetesサービスを利用している場合、
    その上で動かすのも現実的な選択肢。
    

    View Slide

32. 32
    マイクロサービスの原則：Database per Service
    • 共有DBではなく、サービス単位のDB。
    • 論理的な分割でも良いが、障害時の波及範囲を抑える必要あり。
    BFF
    注文管理
    商品
    配送
    顧客
    参照系
    Pod
    Pod
    Pod
    Pod
    Pod
    Pod
    

    View Slide

33. 33
    転ばぬ先の PostgreSQL on Kubernetes アンチパターン
    • 使ってはいけない時
    • Kubernetesを良く知らない
    • 移行元のPostgreSQLが巨大で、フルチューンされている
    ⇒ どうしてもという場合はDB分割を検討した方が良い
    • 使わない方が良い時
    • オートスケールを想定している場合
    ⇒ 現状ではマネージドサービスのオートスケールを選ぶべき
    • 分散ストレージなどと組み合わせるケース
    ⇒ 複雑性が各レイヤに存在し、障害ケースの想定が難しい
    • Kubernetesの外側にバックアップを取れないケース
    ⇒ クラスタ全損まで考慮すべき
    

    View Slide

34. 34
    ちょっと変わった マネージド の世界
    5
    

    View Slide

35. 35
    クラウドは当たり前の時代、
    • 偉い人はこう言いました。 注：フィクションです。
    「A○Sの障害が起きたら、
    どうするんだ!!
    マルチクラウドにしろ！ 」
    

    View Slide

36. 36
    マルチクラウド対応のサービス例：Box Zones
    • 頑張れば出来るが、コストは当然高い。
    Tokyo
    Osaka USA
    複製
    R P
    メタデータ
    「さて、ファイルは、、、」
    • 左図はBox社の
    “Box Zones Japan”
    の構成イメージ。
    • 実際のファイルは、
    AWS東京とAzure大阪に
    二重化される。
    • メタデータは米国に。
    • つまり、
    マルチ＋ハイブリッド
    

    View Slide

37. 37
    マネージドサービスの大きな流れ
    • クラウドプロバイダが提供するマネージドサービス(DBaaS) は、
    事業者の障害でサービス全断の可能性がある。
    • 独自拡張のPostgreSQLのために、移植性や将来性に懸念が残る
    部分もある。
    • ユーザニーズに応えるために、マルチクラウドの対応は今後更に
    加速する。
    • そして、サービス展開のプラットフォームとして、Kubernetes
    を使う形も見られるようになっている。
    • ピュアPostgreSQLを、マルチクラウドかつグローバルに展開し、
    顧客のビジネスをサポート可能なサービスが出てきている。
    

    View Slide

38. 38
    Azure Arc enabled data servicesとは
    • Azure data servicesをオンプレ/マルチクラウド/エッジに展開。
    Azure Arc
    DB管理
    • オンプレ/Azure他のクラウド、
    エッジのKubernetesクラスタに
    Azure data servicesを展開可能。
    • つまり、Hyperscale(Citus)を
    Kubernetesクラスタがあれば、
    どこでも利用可能に。
    • Azureによるフルマネージドな
    DBaaS、ただしロケーションを
    選択可能。
    • 現時点でプレビュー版。
    

    View Slide

39. 39
    Hyperscale(Citus)とは
    • ノード間でデータを分割して保持、
    一つのDBのように見せる。
    • コーディネータが処理を振り分け、
    負荷を分散する。
    • AzureのHyperscale(Citus)はシャー
    ド毎のデータも冗長化されている。
    • 多数のノードを管理する必要があり、
    マネージドで運用負荷を軽減する効果
    が大きい。
    • PostgreSQLをスケーラブルな分散データベースにする拡張。
    • マネージドサービスとしては、Azureが提供している。
    コーディネータ
    

    View Slide

40. 40
    つまり、マネージドサービスの意味が拡張される？
    • Kubernetesさえあれば、マネージドサービスがどこでも・
    何でも管理できるようになってきている。
    ベアメタル EC2
    ホスト
    コンテナ
    ランタイム
    オーケスト
    レーション
    IaaS
    マネージドサービス
    (DBaaS)
    Kubernetes
    Service
    オンプレミス
    Kubernetes
    EKS
    マネージドサービスとは
    何をマネージするのか？
    実はこの辺りも？
    

    View Slide

41. 41
    マネージドサービスはオンプレミスを取り込むか？
    • クラウドとオンプレの境界をぼかす仕組みとも言える、
    Azure StackやAWS Outpostsが既にリリースされている。
    対象サービス 特徴
    RDS on Outposts •PostgreSQL対応はもちろん、
    Auroraも稼働する。
    EKS •Kubernetesが動けば、つまり。
    EC2 •当然、VM環境としても使える。
    EBS
    （AWS Outpostsの筐体イメージ）
    

    View Slide

42. 42
    マルチクラウドに展開可能な、Crunchy Bridge
    • Crunchy Dataが展開するマネージドPostgreSQL。
    US East
    East US
    メインサイト
    DRサイト
    • AWSとAzureを選択可能。
    • マルチリージョンなレプリカ展開
    が可能。
    • マルチクラウドなレプリカ展開も
    可能。
    • DRやクラウドプロバイダの障害に
    対応できる。
    • 展開できるリージョンに制限あり。
    • 現状で日本は未展開。
    

    View Slide

43. 43
    どんな時に使うのか？ ちょっと変わったマネージド
    • マルチクラウドの可用性を担保したい時。
    • Sharding(Citus)なマネージドPostgreSQLを利用したい時。
    • マルチクラウドの要件を持つビジネスは多いとは言えないが、
    マルチリージョンはDRで求められるケースがある。
    • 発展途上であることを理解し、PoCから慎重に行う必要あり。
    • DBaaSのコントロールプレーンがどこにあるかは、気にしない
    時代に入るかもしれない。課金単位などにも注意が必要。
    

    View Slide

44. 44
     パブリッククラウドで PostgreSQLを使う際の選択肢、
    どれぐらい知っていますか。
     RDS、Auroraなど各サービスの特徴を理解しましょう。
     昨今のクラウド上ではコンテナ、 Kubernetesを前提と
    したサービスも出てきています。
     それらの仕組みは理解して、これからのビジネスに最適な
    PostgreSQLプラットフォームを一緒に考えましょう。
    （再掲）本日のゴール
    豊富なPostgreSQLプラットフォームの選択肢を
    理解して、使いこなそう！
    

    View Slide

45. 45
    Questions?
    @tzkb
    @tzkoba
    

    View Slide